1. 1 Ch 18. Object Design Examples With Grasp Objectives Design use case realizations. Apply GRASP to assign responsibilities to classes. Apply UML to illustrate and think through the design of objects.

2. 2 Ch 18. Object Design Examples With Grasp We are not repeating what we did in Ch 17. This chapter applies OO design principles and the UML to the case studies, to show larger examples of reasonably designed objects with responsibilities and collaborations.

3. 3 Ch 18. Object Design Examples With Grasp The last chapter on basic OO design principles looked at little fragments of design problems. In contrast, this chapter demonstrates the larger picture of designing the domain objects for an entire use case scenario. We will see larger-scale collaborations and more complex UML diagrams.

4. 4 Ch 18. Object Design Examples With Grasp Please note that the GRASP patterns by name are not important; they're just a learning aid that helps us think methodically about basic OO design. Key Point The assignment of responsibilities and design of collaborations are very important and creative steps during design, both while diagraming and while coding.

5. 5 Ch 18. Object Design Examples With Grasp We will learn through detailed explanations of how an OO developer might reason while designing by principles. In fact, over a short time of practice, these principles become ingrained, and some of the decision-making happens almost at a subconscious level. No "magic" is needed in object design, no unjustifiable decisions are necessary - assignment of responsibilities and the choice of collaborations can be rationally explained and learned. OO software design really can be more science than art, though there is plenty of room for creativity and elegant design.

6. 6 Ch 18. Object Design Examples With Grasp Objectives – Design use case realizations. Let us talk about use case realization first. A use-case realization describes how a particular use case is realized within the Design Model, in terms of collaborating objects.

7. 7 Ch 18. Object Design Examples With Grasp More precisely, a designer can describe the design of one or more scenarios of a use case; each of these is called a use case realization (though non-standard, perhaps better called a scenario realization). Use case realization is a UP term used to remind us of the connection between the requirements expressed as use cases and the object design that satisfies the requirements.

8. 8 Ch 18. Object Design Examples With Grasp

9. 9 Some relevant artifact-influence points include the following: – The use case suggests the system operations that are shown in SSDs. – The system operations become the starting messages entering the Controllers for domain layer interaction diagrams. See Figure on next slide.Figure This is a key point often missed by those new to OOA/D modeling.  Domain layer interaction diagrams illustrate how objects interact to fulfill the required tasks - the use case realization.

10. 10 Ch 18. Object Design Examples With Grasp

11. 11 Ch 18. Artifact Comments SSDs, System Operations, Interaction Diagrams, and Use Case Realizations. In the current NextGen POS iteration we are considering scenarios and system operations identified on the SSDs of the Process Sale use case: – makeNewSale – enterItem – endSale – makePayment

12. 12 Ch 18. Artifact Comments

13. 13 Ch 18. Artifact Comments If we use communication diagrams to illustrate the use case realizations, we will draw a different communication diagram to show the handling of each system operation message. Of course, the same is true for sequence diagrams.

14. 14 Ch 18. Artifact Comments

15. 15 Ch 18. Artifact Comments

16. 16 Ch 18. Artifact Comments Use Cases and Use Case Realizations Naturally, use cases are a prime input to use case realizations. The use case text and related requirements expressed in the Supplementary Specifications, Glossary, UI prototypes, report prototypes, and so forth, all inform developers what needs to be built. But bear in mind that written requirements are imperfect - often very imperfect.

17. 17 Ch 18. Artifact Comments Operation Contracts and Use Case Realizations use case realizations could be designed directly from the use case text or from one's domain knowledge. For some complex system operations, contracts may have been written that add more analysis detail. For example

18. 18 Ch 18. Artifact Comments

19. 19 Ch 18. Artifact Comments In conjunction with contemplating the use case text, for each contract, we work through the postcondition state changes and design message interactions to satisfy the requirements.

20. 20 Ch 18. Artifact Comments The Domain Model and Use Case Realizations The Domain Model inspires some of the software objects, such as a Sale conceptual class and Sale software class. The existing Domain Model - as with all analysis artifacts - won't be perfect; you should expect errors and omissions. You will discover new concepts that were previously missed, ignore concepts that were previously identified, and do likewise with associations and attributes.

21. 21 Ch 18. What’s Next? The remainder of this chapter is organized as follows: A relatively detailed discussion of the design of the NextGen POS. Likewise, for the Monopoly case study. Applying UML and patterns to these case studies, let's get into the details…

22. 22 Ch 18. Use Case Realization for NextGen POS

23. 23 Ch 18. Use Case Realization for NextGen POS

24. 24 Ch 18. How to Design makeNewSale? The makeNewSale system operation occurs when a cashier initiates a request to start a new sale, after a customer has arrived with things to buy. The use case may have been sufficient to decide what was necessary, but for this case study we wrote contracts for all the system operations, to demonstrate the approach.

25. 25 Ch 18. How to Design makeNewSale?

26. 26 Ch 18. How to Design makeNewSale? The first design choice. CHOOSE THE CONTROLLER CLASS By the Controller pattern, here are some choices: Represents the overall "system," "root object," a specialized device, or a major subsystem. Represents a receiver or handler of all system events of a use case scenario.

27. 27 Ch 18. How to Design makeNewSale? If the first choice – Store a kind of root object because we think of most of the other domain objects as "within" the Store. – Register a specialized device that the software runs on; also called a POSTerminal. – POSSystem a name suggesting the overall system If the second choice – ProcessSaleHandler constructed from the pattern "Handler" or "Session" – ProcessSaleSession

28. 28 Ch 18. How to Design makeNewSale? Choosing a device-object facade controller like Register is satisfactory if there are only a few system operations and if the facade controller is not taking on too many responsibilities (in other words, if it is not becoming incohesive). Choosing a use case controller is suitable when we have many system operations and we wish to distribute responsibilities in order to keep each controller class lightweight and focused (in other words, cohesive). In this case, Register suffices since there are only a few system operations.

29. 29 Ch 18. How to Design makeNewSale? Based on the Controller pattern, the interaction diagram shown below begins by sending the system operation makeNewSale message to a Register software object.

30. 30 Ch 18. How to Design makeNewSale?

31. 31 Ch 18. Creating a New Sale How to Design makeNewSale? The GRASP Creator pattern suggests assigning the responsibility for creation to a class that aggregates, contains, or records the object to be created. Look at the domain model on page 22. It reveals that a Register may be thought of as recording a Sale; – indeed, the word "register" in business has for hundreds of years meant the thing that recorded (or registered) account transactions, such as sales. Thus, Register is a reasonable candidate for creating a Sale.

32. 32 Ch 18. Creating a New Sale How to Design makeNewSale? By having the Register create the Sale, we can easily associate the Register with it over time so that during future operations within the session, the Register will have a reference to the current Sale instance. In addition to the above, when the Sale is created, it must create an empty collection (such as a Java List) to record all the future SalesLineItem instances that will be added. This collection will be contained within and maintained by the Sale instance, which implies by Creator that the Sale is a good candidate for creating the collection.

33. 33 Ch 18. Creating a New Sale How to Design makeNewSale?

34. 34 Ch 18. How to Design makeNewSale? The design was not difficult, but the point of its careful explanation in terms of Controller and Creator was to illustrate that the details of a design can be rationally and methodically decided and explained in terms of principles and patterns, such as GRASP.

35. 35 Ch 18. Use Case Realization for NextGen POS

36. 36 Ch 18. How to Design enterItem? The enterItem system operation occurs when a cashier enters the itemID and (optionally) the quantity of something to be purchased.

37. 37 Ch 18. How to Design enterItem? The first design choice - Who is controller? Based on the Controller pattern, as for makeNewSale, we will continue to use Register as a controller.

38. 38 Creating a New SalesLineItem - How to Design enterItem? Look at the domain model,

39. 39 Creating a New SalesLineItem - How to Design enterItem? A Sale contains SalesLineItem objects. Taking inspiration from the domain, we determine that a software Sale may similarly contain software SalesLineItem. Hence, by Creator, a software Sale is an appropriate candidate to create a SalesLineItem.

40. 40 Creating a New SalesLineItem - How to Design enterItem? We can associate the Sale with the newly created SalesLineItem by storing the new instance in its collection of line items. Also the postconditions indicate that the new SalesLineItem needs a quantity when created;

41. 41 Creating a New SalesLineItem - How to Design enterItem? Therefore, the Register must pass it along to the Sale, which must pass it along as a parameter in the create message. – In Java, that would be implemented as a constructor call with a parameter.

42. 42 Creating a New SalesLineItem - How to Design enterItem? To summary, by Creator, a makeLineItem message is sent to a Sale for it to create a SalesLineItem. The Sale creates a SalesLineItem, and then stores the new instance in its permanent collection. The parameters to the makeLineItem message include the quantity, so that the SalesLineItem can record it, and the ProductDescription that matches the itemID.

43. 43 Creating a New SalesLineItem - How to Design enterItem? The ProductDescription that matches the itemID. Why bother with ProductDescription? Two reasons (1):

44. 44 Creating a New SalesLineItem - How to Design enterItem? Two reasons (2):

45. 45 Creating a New SalesLineItem - How to Design enterItem? Display Item Description and Price? Because of a principle of Model-View Separation, it is not the responsibility of non-GUI objects (such as a Register or Sale) to get involved in output tasks. Therefore, although the use case states that the description and price are displayed after this operation, we ignore the design at this time. All that is required with respect to responsibilities for the display of information is that the information is known, which it is in this case.

46. 46 Finding a ProductDescription - How to Design enterItem? The SalesLineItem needs to be associated with the ProductDescription that matches the incoming itemID. This implies that we must retrieve a Product- Description, based on an itemID match. Before considering how to achieve the lookup, we want to consider who should be responsible for it. Thus, a first step is: Start assigning responsibilities by clearly stating the responsibility.

47. 47 Finding a ProductDescription - How to Design enterItem? To restate the problem: Who should be responsible for knowing a ProductDescription, based on an itemID match? This is neither a creation problem nor one of choosing a controller for a system event. It is about Information Expert.

48. 48 Finding a ProductDescription - How to Design enterItem?

49. 49 Finding a ProductDescription - How to Design enterItem? Analyzing the Domain Model reveals that the ProductCatalog logically contains all the ProductDescriptions. Taking inspiration from the domain, we design software classes with similar organization: a software ProductCatalog will contain software ProductDescriptions.

50. 50 Finding a ProductDescription - How to Design enterItem? Then by Information Expert, ProductCatalog is a good candidate for this lookup responsibility since it knows all the ProductDescription objects. – The lookup can be implemented, for example, with a method called getProductDescription (abbreviated as getProductDesc in some of the diagrams). Who should send the getProductDescription message to the ProductCatalog to ask for a ProductDescription? (Register?Sales? SaleLineItem?...) Some reasonable assumptions have to be made…

51. 51 Finding a ProductDescription - How to Design enterItem? It is reasonable to assume that a long-life Register and a ProductCatalog instance were created when the application is first executed. And that the Register object is permanently connected to the ProductCatalog object. With that assumption (which we might record on a task list of things to ensure in the design when we get to designing the initialization), We know that the Register can send the getProductDescription message to the ProductCatalog.

52. 52 Finding a ProductDescription - How to Design enterItem? This implies another concept in object design: visibility. Visibility is the ability of one object to "see" or have a reference to another object. (Ch 19) Visibility For an object to send a message to another object, it must have visibility to it. Since we assume that the Register has a permanent connection or reference to the ProductCatalog, it has visibility to it, and hence can send it messages such as getProductDescription.

53. 53 The Final Design - How to Design enterItem?

54. 54 The Final Design - How to Design enterItem?