Design

1
Design

• Dan Fleck
• CS 421
• George Mason University

2
What is the design phase?

• Analysis phase describes what the system should
  do
• Analysis has provided a collection of classes and
  descriptions of the scenarios that the objects
  will be involved in. These functions are
  clustered in groups with related behavior.
• The design phase is to work out how the system
  should do these things. This is the goal of the
  design phase.

3
Analysis --gt Design
4
Analysis --gt Design
5
Analysis --gt Design
6
Analysis --gt Design
7
Oversimplification

• Analysis
• Classes
• Attributes
• Operations
• Relationships
• Behavior

Design Objects Data Structures Algorithms Messagi
ng Control
8
The Design Spec

• Architecture Design -
• Layers of the software (e.g.model, view,
  controller (MVC))
• Categories of classes (e.g. UI, Business logic,
  interfaces)
• Component design -
• Description of classes/methods/algorithms
• State machines for classes
• UI design
• sample screens
• UI guidelines/standards were using
• detailed description of how UI components work
• Data design -
• database design
• data structures were using.

9
The Design Spec

• But really, how do I do it?
• Find examples and use what you think is helpful
  from them!
• http//www.mhhe.com/engcs/compsci/pressman/graphic
  s/Pressman5sepa/common/cs2/design.pdf
• http//www.cmcrossroads.com/bradapp/docs/sdd.html

10

• The goal of design is to think with your brain,
  not your hands! - Dan Fleck

11
Applied Design

• We know what to do now, but that is just a set of
  documents..
• How do we create a GOOD design?

12
Good Design

• Design Principles
• What should you try to do?
• Design Patterns
• How have people done it before you?
• Design Metrics
• How do you know you have done it well?

13
Single Responsibility Principle

• Each class should have a single overriding
  responsibility (high cohesion)
• Each class has only one reason for why it should
  change

14
Principle of Least Knowledge (aka Law of Demeter)

• Only talk to your immediate friends
• Object O has a method M.
• M may call other methods in O
• M may call methods of any parameter passed into
  the M method
• M may call methods of any object it creates
• Any object contained in O

Purpose Reduce Coupling
15
Principle of Least Knowledge (aka Law of Demeter)

• Simplified
• I can play by myself
• I can play with toys given to me
• I can play toys I made myself
• I can play with my own toys (but not take them
  apart)

Purpose Reduce Coupling
16
Dependency Inversion Principle

• Depend on abstractions, not concretions
• Program to interfaces not implementations
• Program to most abstract class possible
• Why? Concrete classes may change a lot. Abstract
  classes/Interfaces generally change very little.
• How can we ensure interfaces change very little?
  See next slide!

17
Interface Segregation Principle

• Dont make large multipurpose interfaces
  instead use several small focused ones.
• Dont make clients depend on interfaces they
  dont use.
• Class should depend on each other through the
  smallest possible interface.
• Why? When I change something I want to minimize
  changes for everyone else.

18
Remove Cyclic Dependencies

• Do not have cyclic dependencies in your packages
• Decomposition into independent modules
• Why?

GUI
Logic
BusinessLogic
UserLogic
ErrorHandling
19
Design Patterns

• Proven solutions to common problems
• Capture design expertise
• Aid in meeting quality metrics
• Core patterns are from the Gang of Four
  (GoF)OOPSLA - 1994

20
Singleton Pattern

• Problem I want to limit the application to only
  one instance of a particular class, but need
  global access to that class.
• Normally used to control access to key resources.
• Solution?

override new, make static accessor method.
21
Singleton Pattern (in Java)

• public class MySingleton
• private static MySingleton instance
• private MySingleton()
• // do anything you need to do
• public static MySingleton getInstance()
• if (instance null) instance new
  MySingleton()
• return instance

22
Factory (GoF95)

• Define an interface for a group of objects
• Create a Factory to decide which specific object
  needs to be instantiated
• Think of a multi-document application framework.
  An application object may know when an object
  needs to be created, but not which object. How
  do we create the correct object when needed?
• Can also be used when a complex initialization of
  objects is necessary, for instance when
  aggregation is heavily used.
• Can also be used to take advantage of
  memory-optimization like object pools, cached
  objects, etc.

23
Factory (GoF95)
Socket
EncryptedSocket
Encryption
instanceIEncryptFactorycipher Encryption
Encrypts/Decrypts with
encryptOut decryptIn
EncryptionFactory
DESEncryption
RSAEncryption
Requests Creation
CreateEncryption(Key) Encryption
Creates
24
Command (GoF95)

• Encapsulate commands in objects, so we can queue
  them, undo them or make macros.

managerCmdMgr

Concrete Command
doIt()bool undoIt()bool
- data
doIt()bool undoIt()bool
doIt()bool undoIt()bool
25
Flyweight (GoF95)

• I have a bunch of classes, but I need to minimize
  the number of objects I am using.
• Instances of the objects contain the same
  information and can be used interchangeably
• Avoid the expense of multiple instances.
• Example DocChar class used to hold characters in
  a line of text

26
Visitor (GoF95)

• If you need to perform an operation in multiple
  objects in a complex structure you could create
  the logic in each class.
• ORthe visitor pattern creates a single class
  that implements the logic and knows how to
  visit each object in your complex structure

27
Visitor (GoF95)

• I need to apply different operations to a
  collection of objects.
• I want to centralize these operations
• I want to reduce coupling
• For example in a word processor, grammar check,
  spell check, table of contents builder, outliner
  all need to traverse the document.

28
Visitor Diagram
Object with Structure
concrete visitor
concrete visitor
navigates
Individual Elements
Visitor
29
Design Patterns Summary

• Many design patterns exist
• Implementations are usually available in every
  language
• Use them as guides where appropriate and make
  sure you understand the tradeoffs for each one.
  They arent always good for YOUR situation

30
Design Metrics

• Class Size
• Methods per class
• Lack of Cohesion (count of methods with
  dissimilar purpose)
• Coupling Between Classes (count of other classes
  that this class refers to)
• Depth of Inheritance Tree
• Method Complexity - tools can do this

31
Design Summary

• The design phase is when you plan HOW you
  implement your analysis
• Use
• Design Principles
• Design Patterns
• Design Metrics

32
What should you know

• Analysis what the system should do
• Design how it should do it
• Meaning of the parts of the design spec
• Design Principles
• Single Responsibility Principle - write it
• Law of Demeter. Describe it and state why it is
  good.
• 3 rules of Dependency Inversion Principle
• Why you need to remove cyclic dependencies
• Metrics
• Definition of cohesion and coupling - not how to
  calculate it, but what it means!
• Be able to describe patterns - singleton,
  factory, command

33
References

• Luc Berthouze, University of Sussex,
  http//www.informatics.sussex.ac.uk/users/lb203/se
  /SE08.pdf
• Robert Martin, Principles and Patterns,
  http//www.objectmentor.com/resources/articles/Pri
  nciples_and_Patterns.pdf
• Bob Waters, Georgia Tech, CS2340 Slides,
  http//www.cc.gatech.edu/classes/AY2007/cs2340_sum
  mer/