View
235
Download
0
Category
Preview:
DESCRIPTION
3 Architecture
Citation preview
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
Recommended