Ch 18 Object Design Examples With Grasp Objectives

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

Ch 18. Object Design Examples With Grasp l We are not repeating what we did in Ch 17. l 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. 2

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

Ch 18. Object Design Examples With Grasp l 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 l 4 The assignment of responsibilities and design of collaborations are very important and creative steps during design, both while diagraming and while coding.

Ch 18. Object Design Examples With Grasp l We will learn through detailed explanations of how an OO developer might reason while designing by principles. l In fact, over a short time of practice, these principles become ingrained, and some of the decision-making happens almost at a subconscious level. l 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 5 design. l

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

Ch 18. Object Design Examples With Grasp l 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). l 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. 7

Ch 18. Object Design Examples With Grasp 8

Ch 18. Object Design Examples With Grasp l 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. l • 9 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.

Ch 18. Object Design Examples With Grasp 10

Ch 18. Artifact Comments l SSDs, System Operations, Interaction Diagrams, and Use Case Realizations. l In the current Next. Gen POS iteration we are considering scenarios and system operations identified on the SSDs of the Process Sale use case: – – 11 make. New. Sale enter. Item end. Sale make. Payment

Ch 18. Artifact Comments 12

Ch 18. Artifact Comments l 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. l Of course, the same is true for sequence diagrams. 13

Ch 18. Artifact Comments 14

Ch 18. Artifact Comments 15

Ch 18. Artifact Comments Use Cases and Use Case Realizations l Naturally, use cases are a prime input to use case realizations. l 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. l But bear in mind that written requirements are imperfect - often very imperfect. 16

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

Ch 18. Artifact Comments 18

Ch 18. Artifact Comments l 19 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.

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

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

Ch 18. Use Case Realization for Next. Gen POS 22

Ch 18. Use Case Realization for Next. Gen POS 23

Ch 18. How to Design make. New. Sale? l The make. New. Sale system operation occurs when a cashier initiates a request to start a new sale, after a customer has arrived with things to buy. l 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. 24

Ch 18. How to Design make. New. Sale? 25

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

Ch 18. How to Design make. New. Sale? l If the first choice – – – l If the second choice – – 27 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 Process. Sale. Handler constructed from the pattern <use-case-name> "Handler" or "Session" Process. Sale. Session

Ch 18. How to Design make. New. Sale? l 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). l 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). l In this case, Register suffices since there are only a few system operations. 28

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

Ch 18. How to Design make. New. Sale? 30

Ch 18. Creating a New Sale l l l 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; – l 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. 31 How to Design make. New. Sale?

Ch 18. Creating a New Sale How to Design make. New. Sale? l 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. l 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 Sales. Line. Item instances that will be added. l 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. 32

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

Ch 18. How to Design make. New. Sale? l 34 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.

Ch 18. Use Case Realization for Next. Gen POS 35

Ch 18. How to Design enter. Item? l 36 The enter. Item system operation occurs when a cashier enters the item. ID and (optionally) the quantity of something to be purchased.

Ch 18. How to Design enter. Item? l l 37 The first design choice - Who is controller? Based on the Controller pattern, as for make. New. Sale, we will continue to use Register as a controller.

Creating a New Sales. Line. Item l 38 Look at the domain model, - How to Design enter. Item?

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

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

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

Creating a New Sales. Line. Item - How to Design enter. Item? l To summary, by Creator, a make. Line. Item message is sent to a Sale for it to create a Sales. Line. Item. l The Sale creates a Sales. Line. Item, and then stores the new instance in its permanent collection. l The parameters to the make. Line. Item message include the quantity, so that the Sales. Line. Item can record it, and the Product. Description that matches the item. ID. l 42

Creating a New Sales. Line. Item l l l 43 - How to Design enter. Item? The Product. Description that matches the item. ID. Why bother with Product. Description? Two reasons (1):

Creating a New Sales. Line. Item l 44 Two reasons (2): - How to Design enter. Item?

Creating a New Sales. Line. Item - How to Design enter. Item? l Display Item Description and Price? l 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. l Therefore, although the use case states that the description and price are displayed after this operation, we ignore the design at this time. l 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. 45

Finding a Product. Description - How to Design enter. Item? l The Sales. Line. Item needs to be associated with the Product. Description that matches the incoming item. ID. l This implies that we must retrieve a Product. Description, based on an item. ID match. l 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. 46

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

Finding a Product. Description 48 - How to Design enter. Item?

Finding a Product. Description - How to Design enter. Item? l Analyzing the Domain Model reveals that the Product. Catalog logically contains all the Product. Descriptions. l Taking inspiration from the domain, we design software classes with similar organization: a software Product. Catalog will contain software Product. Descriptions. 49

Finding a Product. Description l Then by Information Expert, Product. Catalog is a good candidate for this lookup responsibility since it knows all the Product. Description objects. – l - How to Design enter. Item? The lookup can be implemented, for example, with a method called get. Product. Description (abbreviated as get. Product. Desc in some of the diagrams). Who should send the get. Product. Description message to the Product. Catalog to ask for a Product. Description? (Register? Sales? Sale. Line. Item? . . . ) Some reasonable assumptions have to be 50 made… l

Finding a Product. Description - How to Design enter. Item? l It is reasonable to assume that a long-life Register and a Product. Catalog instance were created when the application is first executed. l And that the Register object is permanently connected to the Product. Catalog object. l 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), l We know that the Register can send the get. Product. Description message to the Product. Catalog. 51

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

The Final Design 53 - How to Design enter. Item?

The Final Design 54 - How to Design enter. Item?