1. Object Design Examples with GRASP (Ch. 18)

2. 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

3. 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

4. Use Case Realization Key point:
System operations in the SSDs are the starting messages into the domain layer controller objects

5. Fig. 18.3

6. Use Case Realization
Operation contracts are useful for generating interaction diagrams
Conceptual classes inspire design classes

7. 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 -

8. Contract CO1: makeNewSale
Operation: makeNewSale()
Cross references: Process Sale use case
Preconditions: None
Postconditions: - A Sale instance s was created (instance creation) - s was associated with a Register (association formed) - Attributes of s were initialized

9. 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

10. Fig. 9.17

11. 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.

12. Fig. 18.5

13. How to Design makeNewSale?
Using Controller and Creator principles we get the sequence diagram:

14. How to Design makeNewSale?
Summary: Register creates the Sale which in turn creates an empty collection of SalesLineItems

15. How to Design enterItem?
enterItem occurs when cashier enters the itemID and the quantity of something to be purchased
Operation Contract CO2: enterItem -

16. 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)

17. 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

18. 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

19. 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)

20. Fig. 9.17

21. 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

22. Fig. 18.7

23. How to Design enterItem?
Partial DCD related to enterItem design:

24. How to Design endSale?
endSale event occurs when cashier pushes a button indicating end of a sale
Contract CO3: endSale
Operation: endSale()
Cross references: Process Sale use case
Preconditions: There is a sale underway
Postconditions: - Sale.isComplete became true (attribute modification)

25. 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

26. Fig. 18.9

27. How to Calculate Sale Total?
From the Process Sale use case:
Main Success Scenario:
Customer arrives …
Cashier tells System to create a new sale
Cashier enters item identifier
System records sale line item and …
Cashier repeats steps 3-4 until done.
System presents total with tax
Total is needed in step 5 not concerned with presentation but want to determine who knows total (who has responsibility)

28. 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

29. 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

30. Fig

31. Fig & 18.12

32. 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

33. 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

34. 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.

35. Fig