Object Design Examples with GRASP (Ch. 18). Use Case Realization Use Case Realization – how a...
-
Upload
pamela-booth -
Category
Documents
-
view
217 -
download
0
Transcript of Object Design Examples with GRASP (Ch. 18). Use Case Realization Use Case Realization – how a...
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
Use Case Realization
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
Use Case Realization
• 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
How to Design makeNewSale?
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
How to Design makeNewSale?
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.
How to Design makeNewSale?
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
How to Design makeNewSale?
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)
How to Design enterItem?
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
How to Design enterItem?
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
How to Design enterItem?
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
How to Design enterItem?
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
How to Design enterItem?
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
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)
How to Calculate Sale Total?
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
How to Calculate Sale Total?
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
How to Design Start Up
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
How to Design Start Up
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