1

Design Model Use-Case realizations with GRASP

Larman chapter 17

2

UP artifacts and process Context

: Sy stem

enterItem(id, quantity )

endSale()

makePay ment(amount)

Process Sale

1. Customerarriv es ...2. ...3. Cashierenters itemidentif ier.4....

Use Cases System Sequence Diagrams

Operation: enterItem

Post-conditions:- A SalesLineItem instancesli was created- . . .

Operation: makeNewSale

Post-conditions:- . . .

Contracts

makeNewSale()

: Cashier

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

domain objects

systemevents

systemoperations

the domain objects, attributes, andassociations that undergo state changes

Domain Model

Use-Case Model

some ideas and inspiration for the post-conditions derive from the use cases

Design Model

: Register

enterItem(itemID, quantity )

: ProductCatalog

spec := getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

. . .

in addition to the use cases,requirements that must besatisfied by the design of thesoftware

requirements thatmust be satisfied bythe design of thesoftware

3

Architecture

Log4J

Technical Serv ices

Domain

Presentation

Pricing

PricingStrategyFactory

Text

ProcessSaleConsole

used in quickexperiments

Persistence

DBFacade

«interf ace»ISalePricingStrategy

Taxes

«interf ace»ITaxCalculatorAdapter

Serv icesFactory

Sales

Register Sale

Swing

ProcessSaleFrame

Pay ments

CreditPay ment«interf ace»

ICreditAuthorizationServ iceAdapter

Serv iceAccess

Inv entory

«interf ace»IInv entory Adapter

Jess

A generalpurposethird-partyrules engine.

POSRuleEngine

POSRuleEngineFacade

SOAP

not the Jav aSwing libraries,but our GUIclasses based onSwing

4

The Domain Model and Use-Case Realizations

• Some objects are inspired from the Domain Model

• Sale as conceptual class• Sale as design class

– You will discover new concepts when working with the design model

• Some objects are completely unrelated to the Domain Model

5

Lowering the representation gab

Pay ment

amount

Sale

datetime

Pay s-f or

Pay ment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pay s-f or

UP Domain Model

Stakeholder's v iew of the noteworthy concepts in the domain.

UP Design Model

The object dev eloper has taken inspiration f rom the real-world domain increating sof tware classes. Theref ore, the representational gap betweenhow stakeholders conceiv e the domain, and its representation in sof tware,has been lowered.

1 1

1 1

inspiresobjects

andnames in

conceptualclasses

designclasses

6

System Sequence Diagram

enterItem(itemID, quantity )

:Sy stem: Cashier

endSale()

makePay ment(amount)

Process Sale Scenario

description, total

total with taxes

change due, receipt

* [more items]

makeNewSale()

7

Object Design : makeNewSaleContract CO1: MakeNewSale

Operation : MakeNewSale()

Cross References : Use Cases : Process Sale

Preconditions : None

Postconditions :

•A Sale instance s was created

•S was associated with the Register

•Attributes of s were initialized

:Register

makeNewSale()

:Salecreate()

Register creates aSale by Creator

create() :SalesLineItem

by Creator, Salecreates an emptymultiobject (such asa List) which willev entually holdSalesLineIteminstances

CAUTION:This is not a SalesLineItem instance. This is acollection object (such as a List) that canhold SalesLineitem objects.

by CreatorandController

this activ ation is implied to be within theconstructor of the Sale instance

8

Object Design : enterItemContract CO2: enterItem

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

Cross References : Use Cases : Process Sale

Preconditions : There is an underway sale

Postconditions :

•A SalesLineItem instance sli was created

• sli was associated with the current Sale

• sli.quantity became quantity

•Sli was associated with a ProductSpecification, based on itemID match

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

1: spec := getSpecif ication(id) 2.1: create(spec, qty )

1.1: spec := f ind(id)

:Register :Sale

:ProductCatalog

sl: SalesLineItem

SalesLineItem:SalesLineItem:Product

Specif ication

2.2: add(sl)

by Expert

by Controller

This find message is to theMap object (the multiobject),not to a ProductSpecif ication.

CAUTION:This is a multiobject collection (such as a Map), not aProductSpecif ication. It may contain manyProductSpecif ications.

CAUTION:This is a multiobject collection (such as a List), not aSalesLineItem. It may contain many SalesLineItems.

by Creator

add the newly createdSalesLineItem instance to themultiobject (e.g., List)

9

Object Design : endSaleContract CO3: endSale

Operation : endSale()

Cross References : Use Cases : Process Sale

Preconditions : There is an underway sale

Postconditions :

•Sale.isCompleted became true

:RegisterendSale() s : Sale1: becomeComplete()

{public v oid becomeComplete( ){ isComplete = true;}} { s.isComplete = true }

a constraint implementation in a note box

observ e the outer braces around the methodsignif y ing a constraint within a note box

a constraint that doesn't def ine thealgorithm, but specif ies what must hold astrue

// a notecreated by Craig

or with constraints, notes and algorithms ……….

:RegisterendSale() s :Sale1: becomeComplete()

by Expertby Controller

10

Calculating the Sale Total

:Saletot := getTotal() 1 *: st := getSubtotal()

:ProductSpecif ication

1.1: pr := getPrice()

: SalesLineItem*

by Expert by Expert

recall this special notation toindicate iteration ov er theelements of a collection

11

Object Design : makePaymentContract CO4: makePayment()

Operation: makePayment(amount:Money)

Cross References : Use Cases : Process Sale

Preconditions : There is an underway sale

Postconditions :

•A Payment instance p was created

•P.amountTendered became amount

•P was associated with the current Sale

•The current Sale was associated with the Store 1: makePay ment(cashTendered)

1.1: create(cashTendered)

:Register :Sale

:Pay ment

makePay ment(cashTendered)

by Controller by Creator and Low Coupling

12

Logging a Sale

• Who is responsible for knowing all the logged sales, and doing the logging ?

Store

...

addSale(s : Sale)...

SalesLedger

...

addSale(s : Sale)...

Store is responsible f orknowing and addingcompleted Sales.

Acceptable in earlydev elopment cy cles if theStore has f ewresponsibilities.

SalesLedger is responsiblef or knowing and addingcompleted Sales.

Suitable when the designgrows and the Storebecomes uncohesiv e.

Sale

...

...

Sale

...

...

Logs-completed Logs-completed* *

1 1

1: makePay ment(cashTendered)

1.1: create(cashTendered)

:Register s :Sale

:Pay ment

makePay ment(cashTendered)

:Store

2: addSale(s)

completedSales: SalecompletedSales: Sale

2.1: add(s)

by Expert

note that the Sale instance is named's' so that it can be ref erenced as aparameter in messages 2 and 2.1

13

Applications Start uppublic class Main{

public static void main(String[] args){

// Sote is the initial domain object.// The Store creates some other domain

objects

Store store = new Store();Register register = store.getRegister();ProcessSaleJFrame frame =

new ProcessSaleJFrame( register);}

}

14

Connecting the UI Layer to the Domain Layer

:Register

Cashier

:ProcessSaleJFrame

actionPerf ormed( actionEv ent )

1: enterItem(id, qty ) sy stem ev ent

UILayer

DomainLayer

presses button