Coming up: What is the design phase?Coming up: What is the design phase?

Design

Dan FleckCS 421

George Mason University

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.

Coming up: Analysis --> Design

Analysis --> Design

Coming up: Analysis --> Design

Analysis --> Design

Coming up: Analysis --> Design

Analysis --> Design

Coming up: Analysis --> Design

Analysis --> Design

Coming up: Oversimplification

The Design SpecArchitecture 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• (Think: individual classes)

UI design• sample screens• UI guidelines/standards we’re using • detailed description of how UI components work

Data design - • database design • data structures we’re using.Coming up: The Design Spec

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/graphics/Pressman5sepa/common/cs2/design.pdf

http://www.cmcrossroads.com/bradapp/docs/sdd.html

Coming up: The Design Spec

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

Coming up: Applied Design

Applied Design

We know what to do now, but that is just a set of documents..

How do we create a GOOD design?

Coming up: Good Design

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?

Coming up: Single Responsibility Principle

Single Responsibility Principle

• Each class should have a single overriding responsibility (high cohesion)

• Each class has only one reason for why it should change

Coming up: Single Responsability Example

Single Responsability

Example

Coming up: Example: Paperboy and the Wallet

StudentnameaddressgradesfileToSavecalculate GPAstoreStudent

Why might this class definition change?

Example: Paperboy and the Wallet

CustomergetFirstName()getLastName()getWallet()

WalletaddMoney(int a)subtractMoney(int

a)countMoney()

PaperBoy’s getPayment method:payment = 2.00; // “I want my two

dollars!” Wallet theWallet =

myCustomer.getWallet(); if (theWallet.getTotalMoney() >

payment) { theWallet.subtractMoney(payment);

} else { // come back later and get my money

} Coming up: Principle of Least Knowledge (aka Law of Demeter)

What is wrong with this? What is wrong with this?

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– M can call methods on any object

contained in O

Purpose: Reduce CouplingComing up: Principle of Least Knowledge (aka Law of Demeter)

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 CouplingComing up: Example: Paperboy and the Wallet

Example: Paperboy and the Wallet

CustomergetFirstName()getLastName()getWallet()

WalletaddMoney(int a)subtractMoney(int

a)countMoney()

Bad because the paperboy needs to know about the Wallet, and also the customer has to hand the wallet to the paperboy

Bad because the paperboy needs to know about the Wallet, and also the customer has to hand the wallet to the paperboy

Coming up: Example: Paperboy and the Wallet

What is wrong with this? What is wrong with this?

Example: Paperboy and the WalletCustomer

getFirstName()getLastName()getPayment(int

amt)

WalletaddMoney(int a)subtractMoney(int

a)countMoney()

PaperBoy’s getPayment method:payment = 2.00; // “I want my two

dollars!” int amt=

myCustomer.getPayment(payment);

if (amt >= payment) { // say thanks!

} else { // come back later and get my money

}

Better – paperboy only accesses what he needs and models the real world!

Better – paperboy only accesses what he needs and models the real world!

This example from: http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf

Coming up: Dependency Inversion Principle

Remove Cyclic Dependencies

• Do not have cyclic dependencies in your packages

• Decomposition into independent modules

• Why?GUI

Logic

UserLogic BusinessLogic

ErrorHandlingComing up: Design Patterns

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

Coming up: Singleton Pattern

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.

Coming up: Singleton Pattern (in Java)

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; }}

Coming up: Factory (GoF95)

Factory (GoF95)• Define an interface for a group of objects• Create a Factory to decide which specific object needs

to be instantiated

• The goal: decouple knowledge of the object instantiation from the Class that needs the object.

• 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.

Coming up: Factory (GoF95)

ClientClient FactoryFactory ProductProductUsesUses Creates

Creates

Factory (GoF95)Encryption

encryptOutdecryptIn

DESEncryption RSAEncryption

Socket

EncryptedSocket

instance:IEncryptFactorycipher: Encryption

<<interface>>IEncryptFactory

CreateEncryption(Key): Encryption

RequestsCreation

EncryptionFactory

CreateEncryption(Key): EncryptionCreates

Encrypts/Decrypts with

Coming up: Factory (GoF95)

Client

Product

Factory

Factory (GoF95)Encryption

encryptOutdecryptIn

DESEncryption RSAEncryption

Socket

EncryptedSocket

instance:IEncryptFactorycipher: Encryption

<<interface>>IEncryptFactory

CreateEncryption(Key): Encryption

RequestsCreation

EncryptionFactory

CreateEncryption(Key): EncryptionCreates

Encrypts/Decrypts with

Coming up: Command (GoF95)

How do we add another encryption method?

How do we add another encryption method?

Client

Product

Factory

Concrete Command

Command (GoF95)• Encapsulate commands in objects, so

we can queue them, undo them or make macros.

Abstract Command

+doIt():bool+undoIt():bool MacroCommand

+doIt():bool+undoIt():bool +doIt():bool

+undoIt():bool

- data

*+ manager:CmdMgr

Coming up: Flyweight (GoF95)

What makes a design “bad”

• Rigidity: It is hard to change because every change affects too many other parts of the system.

• Fragility: When you make a change, unexpected parts of the system break.

• Immobility: It is hard to reuse in another application because it cannot be disentangled from the current application.

Coming up: Design Patterns SummaryFrom: http://www.objectmentor.com/resources/articles/dip.pdfFrom: http://www.objectmentor.com/resources/articles/dip.pdf

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 aren’t always good for YOUR situation

Coming up: Design Metrics

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

Coming up: Design Summary

Design Summary

• The design phase is when you plan HOW you implement your analysis

• Use – Design Principles– Design Patterns– Design Metrics

Coming up: What should you know

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.– 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

Coming up: References

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/Principles_and_Patterns.pdf

• Bob Waters, Georgia Tech, CS2340 Slides, http://www.cc.gatech.edu/classes/AY2007/cs2340_summer/

• http://www.surfscranton.com/architecture/VisitorPattern.htm

End of presentation