object design examples with grasp (ch. 18)

Object Design Examples with GRASP (Ch. 18)

Use Case Realization

Use Case Realization – how a particular use case is realized within the design model in terms of collaborating objects– The use case suggests the system operations

that are shown in SSD’s– System operations become starting

messages entering the Controllers for domain layer interaction diagrams

– Domain layer interaction diagrams illustrate how objects interact to fulfill the required tasks

Examples from POS

The GRASP design principles will be illustrated by looking at the system operations:– makeNewSale– enterItem– endSale– makePayment

We will also look at the following design considerations:– Calculating Sale total– Designing Start Up


Key point:

System operations in the SSDs are the starting messages into the domain layer controller objects

Fig. 18.3

: Register

: Sale

makeNewSalecreate

: Register

enterItem(...)

: ProductCatalog

desc = getProductDesc( itemID )

. . .

UI LAYER

Window objects or

GUI widget objectsor

Web control objects

. . .

DOMAIN LAYER


• Operation contracts are useful for generating interaction diagrams

• Conceptual classes inspire design classes

How to Design makeNewSale?

Recall that makeNewSale system operation occurs when a cashier requests to start a new sale, after the customer has arrived with goods to buy

Operation Contract CO1: makeNewSale -

Contract CO1: makeNewSale

Operation: makeNewSale()Cross references: Process Sale use casePreconditions:NonePostconditions: - A Sale instance s was created

(instance creation)- s was associated with a Register

(association formed)- Attributes of s were initialized


First need to choose a controller for message makeNewSale

Choices for controller:– Object that represents overall system (a

façade controller): e.g. Store or Register– Object that represents use case scenario: e.g.

ProcessSaleHandler

Fig. 9.17

Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

ProductDescription

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1


Here we choose the façade controller Register

Remember Register is now a software object in the design model. It isn’t a physical register.

Fig. 18.5

:Register

makeNewSale

:Salecreate


Using Controller and Creator principles we get the sequence diagram:

: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


Summary: Register creates the Sale which in turn creates an empty collection of SalesLineItems

How to Design enterItem?

enterItem occurs when cashier enters the itemID and the quantity of something to be purchased

Operation Contract CO2: enterItem -

Contract CO2: enterItem

Operation: enterItem(itemID : ItemID, quantity : integer)

Cross references:Process Sale use case

Preconditions: There is a sale underway

Postconditions: - A SalesLineItem instance sli was created (instance creation)- sli was associated with the current

Sale (association formed)- sli.quantity became quantity (attribute

modification)

- sli was associated with a ProductDescription, based on itemID match (association formed)


First – who has responsibility for system event enterItem?

by Controller principle it will be Register

Note: use case states that description and price are displayed

But by Model-View Separation non-GUI objects should not get involved in output


Need to create and initialize a SalesLineItem and associate it with a Sale– From domain model a Sale contains

SalesLineItem objects– By Creator principle a Sale is given

responsibility for creating a SalesLineItem


Next we need to find a ProductDescription that matches the ItemID

Who should be responsible for knowing a ProductDescription based on an ItemID match?

Apply Information Expert principle -

From domain model => ProductCatalog knows all ProductDescriptions

So assign responsibility to ProductCatalog

=> operation: getProductDesc(id)

Fig. 9.17

Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

ProductDescription

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1


Who sends getProductDesc message?

Register is reasonable only if Register can see ProductCatalog

Visibility – ability of one object to “see” another object, required in order for an object to send a message to another object - we’ll return to this issue later

Fig. 18.7

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


Partial DCD related to enterItem design:

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

How to Design endSale?

endSale event occurs when cashier pushes a button indicating end of a sale

Contract CO3: endSaleOperation: endSale()

Cross references: Process Sale use case

Preconditions: There is a sale underway

Postconditions: - Sale.isComplete became true(attribute modification)

How to Design endSale?

First, who is responsible for system event endSale()?

=> using Controller we make it Register

Then, who should be responsible for setting the attribute isComplete to true?=> using Information Expert it should be Sale

Fig. 18.9

:RegisterendSale( s :Sale1: becomeComplete

by Expertby Controller

How to Calculate Sale Total?

From the Process Sale use case:Main Success Scenario:1. Customer arrives …2. Cashier tells System to create a new sale3. Cashier enters item identifier4. System records sale line item and …Cashier repeats steps 3-4 until done.5. System presents total with tax

Total is needed in step 5not concerned with presentation but want to determine who knows total (who has responsibility)


Responsibility: Who should know the sale total? (review domain model)

What information is required?– Sale total is sum of subtotals of all sales line-

items– Can calculate sales line-item subtotal using

line-item quantity and product description price


Summarize information:

Information Required for Sale Total Information Expert

ProductDescription.price ProductDescription

SalesLineItem.quantity SalesLineItem

all the SalesLineItems in the current Sale

Sale

Fig. 18.10

:Saletot = getTotal 1 * [i = 1..n]: st = getSubtotal

:ProductDescription

1.1: pr = getPrice

lineItems[ i ]: SalesLineItem

by Expert by ExpertUML: note the selector notation to select elements from the lineItems collection

Fig. 18.11 & 18.12

:Saletot = getTotal 1 *[ i = 1..n]: st = getSubtotal

:ProductDescription

1.1: pr = getPrice

lineItems[ i ] :SalesLineItem

«method»public void getTotal(){ int tot = 0; for each SalesLineItem, sli tot = tot + sli.getSubtotal(); return tot}

How to Design Start Up

Start Up use case –

Designing interactions involved in system initialization

Key: do initialization design last

Create an initial domain object -

responsible for creating other domain objects


POS system –

Review initialization requirements based on previous interaction diagrams:– Store, Register, ProductCatalog, ProductDescriptions

need to be created– ProductCatalog needs to be associated with

ProductDescriptions– Store needs to be associated with ProductCatalog– Store needs to be associated with Register– Register needs to be associated with ProductCatalog


POS system –

Choose Store as initial domain object

Guideline: Choose as an initial domain object a class at or near the root of the containment or aggregation hierarchy of domain objects. This may be a façade controller, such as Register, or some other object considered to contain all or most other objects, such as Store.

Fig. 18.20

: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 Creatorcreate an empty collection object

object design examples with grasp (ch. 18)

Documents