Object Design Examples with GRASP Chapter 18 Applying

Object Design Examples with GRASP Chapter 18 Applying UML and Patterns Craig Larman

Objectives § Design use-case realizations. § Apply the GRASP patterns to assign responsibilities to classes. § Use the UML interaction diagram notation to illustrate the design of objects. § Assign responsibilities and design object collaborations § Important and creative steps during design § While diagramming or programming.

Use-Case Realizations n A Use Case Realization describes how a particular use case is realized in the design model, in terms of collaborating objects. n UML interaction diagrams are used to illustrate use-case realizations. n Principles and Patterns can be applied during this design work. n The interaction diagrams involve message interaction between software objects n Names come from conceptual classes in the Domain Model, plus other classes of objects

Creating Interaction Diagrams n Create a separate interaction diagram for each system operation n Using the contract responsibilities and post conditions and use case description as a starting point, design a system of interacting objects to fulfill the tasks. n Apply the GRASP and other patterns to develop a good design.

Communication Diagram n Using the controller pattern, the Register class could be chosen as the controller for handling the events of Process Sale.

Sequence Diagram example n One Sequence Diagram and system event message handling.

Multiple Sequence Diagram n However, it is often that the sequence diagram is too complex or long.

Contracts and Use-Case Realizations n Contract responsibilities, post-conditions, and use-cases are starting point for designing system of interacting objects to fulfill tasks. n It may be possible to design use-case realizations directly from the use-case text. n For each contract, we work through the responsibilities and post-condition state changes, and design message interactions to satisfy requirements.

Partial Interaction Diagram

Omitting Contracts n If we omit the contract creation we could still construct the interaction diagrams n By returning to the use-cases and thinking through what must be achieved. n However, the contracts n Organize and isolate the information in a workable format and n Encourage investigative work during the analysis phase rather than the design phase.

Domain Model and Use-Case Realization n Some of the software objects that interact via messages in the interaction diagrams are inspired from the Domain Model. The existing domain model is not likely to be perfect. Errors and omissions are to be expected. n You will discover new conceptual classes that were previously missed, ignore conceptual classes that were previously identified, and do likewise with associations and attributes. n

Object Design : Contract n Name : make. New. Sale() n Responsibilities : Make a new sale for a cashier to request to start a new sale, after a customer has arrived with things to buy. n Cross-References: Use Cases : Process Sale n Pre-Conditions: None n Post-Conditions: A Sale instance si was created si was associated with the current register Attributes of the si were initialized.

Choosing the Controller Class n Our design choice involves choosing the controller for the system operation message make. New. Sale(). n Using the Controller pattern, here are some choices: n Represents the overall system, device, or subsystem: Register, Po. S system. n Represents a receiver or handler of all system events of a use-case scenario : Process. Sale. Handler, Process. Sale. Session.

Applying the GRASP Controller Pattern n From those choices, we choose the register as our controller. n By applying the GRASP controller pattern, we can design a use-case realization by drawing an interaction diagram which begins by sending a make. New. Sale message to Register software object.

Creating a New Sale n A software sale object must be created, and the GRASP creator pattern suggests assigning the responsibility for creation to a class that aggregates, contains, or records the object to be created. n The register is also a good choice to create the sale object by the creator pattern.

Creating a New Sale Communication Diagram

Use-Case Realization Design n The design was not difficult. n 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.

Contract for enter. Item ( ) n Name: enter. Item(item. ID : item. ID, quantity : integer) n Responsibilities : Enter sale of an item and add it to the sale. Display the item description and price. n Cross References : Use-Cases : Process. Sale. n Pre-Conditions: There is an underway sale. n Post-Conditions: A Sales. Line. Item instance ‘sli’ was created. (instance created)

Contract for enter. Item ( ) sli was associated with current sale. (association formed) n sli. quantity became quantity. (attribute modification) n sli was associated with a Product. Specification, based on item. ID match. (association formed) n

Choosing the Controller Class n By the controller pattern, here are the choices. n Register or Retail System : represents the entire system(facade-controller) n Store : represents the overall business or organization. n Cashier : represents something in the realworld that is active or involved in the task. (role controller) n Process. Sale. Handler : represents an artificial handler of all system operations of a use-case. (use-case controller)

Choosing the Controller Class n Applying the GRASP Controller Pattern. n Choose a façade-controller like Register. n If not taking on too many responsibilities. n The register instance is a software abstraction that represents the register.

Creating a new Sales. Line. Item n The contract post condition indicate a responsibility to create a Sales. Line. Item instance. n A Sale contains Sales. Line. Item objects. n By creator pattern, the sale is an appropriate candidate for creating line items. n GRASP creator pattern n Assign the responsibility for creation to a class that aggregates, contains or records.

Making a new Sales. Line. Item n Sale Creation

Finding a product specification n The Sales. Line. Item needs to be associated with the Product. Specification that matches the incoming item. ID. n Who should be responsible for looking up the Product. Specification based on the item. ID match? n By the Expert pattern, Product. Catalog is a good candidate for the responsibility, since it logically contains all the Product. Specifications.

Visibility to a product catalog n Who should send the Specification message to the Product. Catalog to ask for a Product. Specification. n Assumption: A Register and a Product. Catalog instances were created during the initial Start Up use-case, and there is a permanent connection between them. n Based on this assumption, then it is possible to the Register to send the specification message to the Product. Catalog.

Visibility to a product catalog(2) n This implies another concept, visibility. n ‘Visibility’ is the ability of one object to ‘see’ or to have reference to another object. n In order for an object to send a message to another object it must have visibility to it.

Retrieving Product. Specification n Retrieving Product. Specification from a database. n It is unlikely that all the Product Specifications will actually be in memory. n They will most likely be stored in a relational or object DB and retrieved on demand. n However the issues surrounding information retrieval will be deferred for now for simplicity.

Interaction Diagram : enter. Item n Object Design based on the GRASP patterns.

Message to multi-objects n Notice that although the default interpretation of a message sent to a multi-object is that it is implicitly sent to all elements of the collection/container, it may have alternatively be interpreted as a message to the collection object itself.

Object Design : end. Sale n The end. Sale system operation occurs when a cashier presses a button indicating the end of sale. n A collaborating diagram can be constructed to satisfy the post-conditions of end. Sale. n The GRASP patterns will be used to choose and justify the messages.

Object Design : end. Sale Contract n Name : end. Sale() n Responsibilities : Record that it is the end of entry of sale items, and display sale total. n Cross References : Use Cases : Process Sale n Exceptions : If a sale is not underway, indicate that it was an error. n Pre-Conditions: There is an underway sale. n Post-Conditions: sale. is. Complete became true.

Choosing the Controller Class n Based on the Controller Pattern, as for enter. Item, we will continue to use register as a controller.

Setting the Sale. is. Complete attribute n The contract post-condition state: n Sale. is. Complete became true. n As always, Expert should be the first pattern considered unless it is a controller or creation problem (which is not). n Who should be responsible for setting the Sale. is. Complete attribute of the Sale to true. n By Expert, it should be the Sale itself.

Communication Diagram : end. Sale n Setting the Sale. is. Complete attribute (2)

Display of Information n It states in the responsibilities of the end. Sale contract that the sale total must be displayed. n Who should be responsible for the display of information: Model-View Separation Pattern. n Ignore any requirements that involve the display of information, with the following exception: n Ensure that all the information that must be displayed is known and available from the domain objects. For example, the sale total must be known by some object.

Constraints and Notes

Calculating the Sale Total n By Expert the Sale itself should be responsible for knowing its total. n How to find it? n State the responsibility. n Who should be responsible for knowing the sale total. n Summarize the information needed.

Calculating the Sale Total (2) n The sale total is the sum of the subtotals of all the saleslineitems. n Sales Line Item subtotal : line item quantity * product description price. n List the information required until to fulfill this responsibility and the classes that know this information.

Calculating the Sale Total (3)

Communication Diagram n Sale get. Total Communication Diagram

Communication Diagram (2) n Sale get. Total Communication Diagram