Design with GRASP - LUMSsuraj.lums.edu.pk/~cs463s06/lectures/W7_GRASP.pdf · Use-Case Realization “…describes how a particular use case is realized within the design model, in

1

Design with GRASP

Week 6April 18, 2007

COMP5028 Object-Oriented Analysis and Design (S1 2007)© Dr. Ying Zhou, School of IT, The University of Sydney

2

Agenda

Object design basicsMonopoly game design and GRASP principles introductionUse Case Realization using GRASPFrom Design to codeMonopoly Game Use Case Realization (self study material)


3

Object Design

“Identify requirements, create a domain model, add methods to the software classes, define messages to meet requirements…”Too Simple!

What methods belong where?How do we assign responsibilities to classes?

The critical design tool for software development is a mind well educated in design principles and patterns.


4

Object Design: inputPOS project inputs

Use case text of Process SaleDefining the behavior

System sequence diagramIdentifying the system operation messages

The operation contractStating events to design for, and detailed post-condition to satisfy

Supplementary specification Defines non-functional goals

GlossaryData format, data related with UI and database

Domain modelinitial attempt of software object in the domain layer of software architecture


5

Object Design: activities and output

Design activitiesCoding immediately

Ideally using test-driven developmentShort UML modeling

Apply OO Design principles and design patternsDesign output

UML diagrams for difficult parts of the systemUI prototypes and database models


6

Responsibility Driven DesignResponsibility is a contract or obligation of a classWhat must a class “know”? [knowing responsibility]

Private encapsulated dataRelated objectsThings it can derive or calculate

What must a class “do”? [doing responsibility] Take action (create an object, do a calculation)Initiate action in other objectsControl/coordinate actions in other objects

Responsibilities are assigned to classes of objects during object design


7

Examples of responsibilities

“A Sale is responsible for creating SalesLineItems” (doing)“A Sale is responsible for knowing its total”(knowing)Knowing responsibilities are related to attributes, associations in the domain modelDoing responsibilities can be expressed at different granularities.Doing responsibilities are implemented by means of methods.


8

Domain model and responsibilities

Domain model illustrates attributes and associations => inspires the “knowing”responsibilitiesResponsibilities are defined in conceptual levelMethods fulfill responsibilities

AloneThrough collaboration with other objects and methods


9

Responsibilities and UML

: Sale

makePayment(cashTendered): Paymentcreate(cashTendered)

abstract, implies Sale objects have a responsibility to create Payments


10

GRASP principles

General Responsibility Assignment Software PatternsThe five basic principles in Monopoly game design:

Creator Information ExpertHigh CohesionLow CouplingController


11

Creator: problemProblem

Who creates the Square objectStart point: domain model


12

Creator: principle

ProblemWho creates an A object

SolutionAssign class B the responsibility to create an instance of class A if one of these is true

B “contains” AB records AB closely uses AB has the Initializing data for A


13

Creator: Solution


14

Information ExpertProblem

Who knows about a Square object, given a key?Alternatively, who should be the receiver of message getSquare(name)

Board knows about all squaresBoard has the information necessary to fulfill this responsibility


15

Information Expert: principle

ProblemWhat is a general principle of assigning responsibilities to objects

SolutionAssign a responsibility to the class that has the information needed to fulfill it


16

Low coupling

ProblemHow to reduce the impact of change, to support low dependency, and increase reuse?

SolutionAssign a responsibility so that coupling remains low


17

Coupling

How strongly one element is connected to, has knowledge of, or depends on other elementsIllustrated as dependency relationship in UML class diagram

A

E

BC

DF


18

Example of poor design


19

High cohesion

ProblemHow to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?

SolutionAssign responsibilities so that cohesion remains high


20

Cohesion

How strongly related and focused the responsibilities of an element areFormal definition (calculation) of cohesion

Cohesion of the two methods is defined as the intersection of the sets of instance variables that are used by the methodsIf an object has different methods performing different operations on the same set of instance variables, the class is cohesive


21

Example


22

Controller

ProblemWhat first object beyond the UI layer receives and coordinates (“controls”) a system operation

SolutionAssign the responsibility to an object representing one of these choices

Represents the overall system, root object, device or subsystemRepresents a use case scenario within which the system operations occurs


23

Example


24

Example


25

Example


26

Use-Case Realization

“…describes how a particular use case is realized within the design model, in terms of collaborating objects” [RUP]Individual scenarios are realized

Use case -> System events -> System sequence diagram ->System operation contracts -> Interaction diagrams -> Design classes


27

System operation

The system operations in the SSD are used as the start messages into the domain layerIf communication diagrams are used, one per system operationSame for sequence diagram

:RegisterenterItem

:RegisterendSale

:RegistermakePayment

1: ???

1: ???

1: ???

:RegistermakeNewSale 1: ???

makeNewSale, etc., are the system operations from the SSD

each major interaction diagram starts with a system operation going into a domain layer controller object, such as Register

DOMAIN LAYERUI LAYER

Window objects or

GUI widget objectsor

Web control objects

. . .


28

One diagram per system operation

: Register

: Sale

makeNewSalecreate

: Register

enterItem(...)

: ProductCatalog

desc = getProductDesc( itemID )

. . .

UI LAYER

Window objects or

GUI widget objectsor

Web control objects

. . .

DOMAIN LAYER


29

Design makeNewSale

Choosing the controller classA façade controller is satisfactory if there are only a few system operationsUse Register here.

Creating a new SaleRegister create SaleSale create a collection to store SalesLineItems


30

Design makeNewSale

:Register

makeNewSale

:Salecreate

Register creates a Sale by Creator

create lineItems :List<SalesLineItem>

by Creator, Sale creates an empty collection (such as a List) which will eventually hold SalesLineItem instances

by Creator and Controller

this execution specification is implied to be within the constructor of the Sale instance


31

Design: enterItem

[Larman 2002]


32

Design enterItem

Choosing controller classDisplay item description and price (ignore at this stage)Create a new SalesLineItemFinding a ProductDescriptionVisibility to ProductCatalogTemporary and persistent storage

We can defer database design and use temporary memory object instead


33

Design enterItem

2: makeLineItem(desc, qty)enterItem(id, qty)

1: desc = getProductDesc(id) 2.1: create(desc, qty)

1.1: desc = get(id)

:Register :Sale

:ProductCatalog

sl: SalesLineItem

lineItems : List<SalesLineItem>: Map<ProductDescription>

2.2: add(sl)

by Expert

by Controllerby Creator

add the newly created SalesLineItem instance to the List


34

Partial Design Class Diagram

SalesLineItem

quantity : Integer

...

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID: ItemID

...

1..*

1..*

Register

...

enterItem(...)...

Sale

isComplete : Booleantime : DateTime

makeLineItem(...)...1

1

1

catalog

currentSale

descriptions{Map}

lineItems{ordered}

description


35

Design endSale

Who should be responsible for knowing the grand total of a saleWhat information do we need to compute the grand total

SalesLineItem

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1


36

Create diagrams in parallel

Sale

time...

getTotal()

:Salet = getTotal

New method

1. The new responsibility is conveyed by an operation in aninteraction diagram. A new method is created in the designclass to express this.


37

Create diagram in parallel

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()New method

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] : SalesLineItem

this notation will imply we are iterating over all elements of a collection

2. Responsibility for each subtotal is assigned to theSalesLineItem


38

Create diagrams in parallelSale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()

ProductDescription

descriptionpriceitemID

getPrice()New method

:ProductDescription

1.1: p := getPrice()

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] :SalesLineItem

3. Responsibility for each item price is assignedto the ProductSpecification


39

Design makePayment

[Larman 2002]


40

Design makePaymentCreating Payment instanceHow should we assignment responsibilities of creating Payment instance and associate it with the Sale.


41

Options

: Register p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

: Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()


42

Final Solution

Creating payment

1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register :Sale

:Payment

makePayment(cashTendered)

by Controller by Creator and Low Coupling


43

Design makePayment

Logging a sale

Store

...

addSale(s : Sale)...

SalesLedger

...

addSale(s : Sale)...

Store is responsible for knowing and adding completed Sales.

Acceptable in early development cycles if the Store has few responsibilities.

SalesLedger is responsible for knowing and adding completed Sales.

Suitable when the design grows and the Store becomes uncohesive.

Sale

...

...

Sale

...

...

Logs-completed5 Logs-completed5* *

1 1


44

Design makePayment

1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register s :Sale

:Payment

makePayment(cashTendered)

:Store

2: addSale(s)

completedSales: List<Sale>

2.1: add(s)

by Expert

note that the Sale instance is named's' so that it can be referenced as a parameter in messages 2 and 2.1


45

Design makePayment

Calculating the balanceWho is responsible for knowing the balance?

To calculate, sale total and payment tendered are requiredSale and Payment are partial Experts

Consider coupling…Sale already has visibility into PaymentPayment does not have visibility into SaleGiving Sale primary responsibility doesn’t increase overall coupling


46

getBalance design

s :Sale pmt: Payment1: amt = getAmountbal = getBalance

2: t = getTotal

{ bal = pmt.amount - s.total }


47

From UI to Domain Layer

Which class of object should be responsible for receiving this system event message?

It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from the interface layer.

actionPerformed( actionEvent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty)

UI Layer

Domain Layer

system operation message


48

Controller Choices

Represents the overall “system”, “root object”, device or subsystem

RegisterRepresents a receiver or handler of all system events of a user case scenario

:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)


49

Allocate system operationsRegister

...

endSale()enterItem()makeNewSale()makePayment()

makeNewReturn()enterReturnItem(). . .

System


makeNewReturn()enterReturnItem(). . .

system operations discovered during system behavior analysis

allocation of system operations during design, using one facade controller

ProcessSaleHandler

...


System


enterReturnItem()makeNewReturn(). . .

allocation of system operations during design, using several use case controllers

HandleReturnsHandler

...

enterReturnItem()makeNewReturn(). . .


50

Choosing a Controller

Façade controllerPRO: all events handled in one placeCON: can become too bloated

Use-case controllerPRO: manage many different events across different processesCON: adds additional classes; events can’t be managed (e.g. logged) in one place


51

Desirable coupling of UI layer to domain layer


:Register

: Cashier

:SaleJFrame

presses button

1: enterItem(itemID, qty)

:Sale1.1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

system operation message

controller

SalesJFrame needsto have a reference to Register object and will send message to it.


52

Less desirable coupling

Cashier

:SaleJFrame


:Sale1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

It is undesirable for an interfacelayer object such as a window to get involved in deciding how to handle domain processes.

Business logic is embedded in the presentation layer, which is not useful.

SaleJFrame should not send this message.

presses button


53

Object Design: startUpInitial system operationDelay until all other system operations have been considered

What objects need to be there through out the use caseWhat associations need to be there through out the use case

Create a set of domain objects that need to be there to support the use case executionFind a suitable initial object and request that object to create a set of other objectsDo the initialization design last


54

Create Initial Domain Object

[Larman 2003]


55

Designing Store.create()

Create: Store, Register, ProductCatalog,ProductDescriptionAssociate: ProductCatalog with ProductDescription; Store with ProductCatalog; Store with Register; Register with ProductCatalog


56

Designing Store.create()

:Store :Register

pc:ProductCatalog

create 2: create(pc)

1: create

1.2: loadProdSpecs()

descriptions:Map<ProductDescription>

1.1: create

1.2.2*: put(id, pd)

1.2.1*: create(id, price, description)

pd:ProductDescriptionthe * in sequence number indicates the

message occurs in a repeating section

pass a reference to the ProductCatalog to the Register, so that it has permanent visibility to it

by Creator create an empty collection object


57

Mapping Designs to Code

Class and interface definitionMethod definitions


58

Creating Class Definition from DCD

public class SalesLineItem{private int quantity;

private ProductDescription description;

public SalesLineItem(ProductDescription desc, int qty) { ... }

public Money getSubtotal() { ... }

}

SalesLineItem

quantity : Integer

getSubtotal() : Money

ProductDescription

description : Textprice : MoneyitemID : ItemID

...

1

description


59

Creating methods from interaction diagram


1: desc = getProductDesc(id) 2.1: create(desc, qty)

1.1: desc = get(id)

:Register :Sale

:ProductCatalog

sl: SalesLineItem

lineItems : List<SalesLineItem>: Map<ProductDescription>

2.2: add(sl)


60

The Register class

ProductCatalog

...

getProductDesc(...)

Sale


becomeComplete()makeLineItem(...)makePayment(...)getTotal()

Register

...

endSale()enterItem(id: ItemID, qty : Integer)makeNewSale()makePayment(cashTendered : Money)

public class Register{private ProductCatalog catalog;private Sale currentSale;

public Register(ProductCatalog pc) {...}

public void endSale() {...}public void enterItem(ItemID id, int qty) {...}public void makeNewSale() {...}public void makePayment(Money cashTendered) {...}}

1

1

catalog

currentSale


61

The enterItem method


1: desc := getProductDescription(id)

:Register :Sale

:ProductCatalog

{ ProductDescription desc = catalog.ProductDescription(id); currentSale.makeLineItem(desc, qty);}


62

Collection classes in code

SalesLineItem

quantity : Integer

getSubtotal()1..*

Sale


becomeComplete()makeLineItem()makePayment()getTtotal()

public class Sale{...

private List lineItems = new ArrayList();}

A collection class is necessary to maintain attribute visibility to all the SalesLineItems.

lineItems


63

Defining the Sale.makeLineItemMethod

{ lineItems.add( new SalesLineItem(desc, qty) );}


2.1: create(desc, qty)

:Register :Sale

sl: SalesLineItemlineItems :List<SalesLineItem>

2.2: add(sl)


64

Order of implementation

SalesLineItem

quantity : Integer

getSubtotal()

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID : ItemID

...

Store

address : Addressname : Text

addSale(...)

Payment

amount : Money

...

1..*

1..*

Register

...

endSale()enterItem(...)makeNewSale()makePayment(...)

Sale


becomeComplete()makeLineItem(...)makePayment(...)getTotal()...

1

1

1

1

1

1

* 1

23

4

56

7

From least-coupled to most-coupled


65

Monopoly game project

Two system operations in the first iteration

InitializeIgnore at this stage

Play gameMain focus


66

Design playGame

Choosing the Controller Class

Represents the overall “system”, “root object”

MonopolyGame? *Represents a receiver or handler of all system events of a use case scenario

PlayGameHandler?


67

Game-Loop algorithm

Terminologyturn – a player rolling the dice and moving the pieceround – all the players taking one turn

Game loopfor N rounds

for each player pp takes a turn


68

Who is responsible for controlling the game loop

No object has it yet, assigning this to the MonopolyGame object is justifiable

The current round count

MonopolyGame objectAll players

Who has this informationInformation needed


69

Who takes a turn?When there are multiple partial information experts to choose from

Place the responsibility in the dominant information expertIf the first guideline does not apply, consider the coupling and cohesion impact of each and choose the bestConsider possible future evolution

Taking a turn might involve buying property, deposit money in bank.. Etc. A player should have all information regarding those activities

BoardAll the squares

MonopolyGameTwo die objects

PlayerCurrent location of the player

Who has the informationInformation Needed


70

Partial design diagrams


71

Taking a turn refine

Taking a turn involvesCalculating the face value of two dieCalculating the new square locationMoving the player’s piece from an old location to a new location

Who coordinate all thisPlayer

Visibility problemPlayer must have references to all those objects


72

Taking a turn


73

Command-Query Separation Principle

Style 1#public void roll(){

faceValue = //random num generation}public int getFaceValue(){

return faceValue;}

Style 2#public int roll(){

faceValue = //random num generationreturn faceValue;

}

Every method should either be:

A command method that performs an action often has side effects such as changing the state of objects and is void. A query that returns data to the caller and has no side effects – it should not permanently change the state of any objects.

But a method should not be both


74

Static design for playGame


75

Initialization and the start up use case

Documents

Design with GRASP - LUMSsuraj.lums.edu.pk/~cs463s06/lectures/W7_GRASP.pdf · Use-Case Realization “…describes how a particular use case is realized within the design model, in