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
 A Use Case Realization describes how a
particular use case is realized in the design
model, in terms of collaborating objects.
 UML interaction diagrams are used to
illustrate use-case realizations.
 Principles and Patterns can be applied during
this design work.
 The interaction diagrams involve message
interaction between software objects
 Names come from conceptual classes in the
Domain Model, plus other classes of objects
Creating Interaction Diagrams
 Create a separate interaction diagram for
each system operation
 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.
 Apply the GRASP and other patterns to
develop a good design.
Communication Diagram
 Using the controller pattern, the Register
class could be chosen as the controller for
handling the events of Process Sale.
Sequence Diagram example
 One Sequence Diagram and system event
message handling.
Multiple Sequence Diagram
 However, it is often that the sequence
diagram is too complex or long.
Contracts and Use-Case
Realizations
 Contract responsibilities, post-conditions, and
use-cases are starting point for designing
system of interacting objects to fulfill tasks.

It may be possible to design use-case
realizations directly from the use-case text.
 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
 If we omit the contract creation we could still
construct the interaction diagrams

By returning to the use-cases and thinking
through what must be achieved.
 However, the contracts
 Organize and isolate the information in a
workable format and
 Encourage investigative work during the
analysis phase rather than the design phase.
Domain Model and Use-Case
Realization
 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.
You will discover new conceptual classes that
were previously missed, ignore conceptual
classes that were previously identified, and do
likewise with associations and attributes.
Object Design : Contract
 Name : makeNewSale()
 Responsibilities : Make a new sale for a cashier
to request to start a new sale, after a customer
has arrived with things to buy.
 Cross-References: Use Cases : Process Sale
 Pre-Conditions: None
 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
 Our design choice involves choosing the
controller for the system operation message
makeNewSale().
 Using the Controller pattern, here are some
choices:
 Represents the overall system, device, or
subsystem: Register, PoS system.
 Represents a receiver or handler of all
system events of a use-case scenario :
ProcessSaleHandler, ProcessSaleSession.
Applying the GRASP Controller
Pattern
 From those choices, we choose the register
as our controller.
 By applying the GRASP controller pattern, we
can design a use-case realization by drawing
an interaction diagram which begins by
sending a makeNewSale message to
Register software object.
Creating a New Sale
 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.
 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
 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.
Contract for enterItem ( )
 Name: enterItem(itemID : itemID, quantity :
integer)
 Responsibilities : Enter sale of an item and
add it to the sale. Display the item description
and price.
 Cross References : Use-Cases :
ProcessSale.
 Pre-Conditions:
There is an underway sale.
 Post-Conditions:
A SalesLineItem instance ‘sli’ was created.
(instance created)
Contract for enterItem ( )



sli was associated with current
sale.(association formed)
sli.quantity became quantity.(attribute
modification)
sli was associated with a ProductSpecification,
based on itemID match.(association formed)
Choosing the Controller Class
 By the controller pattern, here are the
choices.




Register or Retail System : represents the
entire system(facade-controller)
Store : represents the overall business or
organization.
Cashier : represents something in the realworld that is active or involved in the task.
(role controller)
ProcessSaleHandler : represents an artificial
handler of all system operations of a use-case.
(use-case controller)
Choosing the Controller Class
 Applying the GRASP Controller Pattern.
 Choose a façade-controller like Register.
 If not taking on too many responsibilities.
 The register instance is a software
abstraction that represents the register.
Creating a new SalesLineItem
 The contract post condition indicate a
responsibility to create a SalesLineItem
instance.
 A Sale contains SalesLineItem objects.

By creator pattern, the sale is an appropriate
candidate for creating line items.
 GRASP creator pattern
 Assign the responsibility for creation to a class
that aggregates, contains or records.
Making a new SalesLineItem
 Sale Creation
Finding a product specification
 The SalesLineItem needs to be associated
with the ProductSpecification that matches
the incoming itemID.
 Who should be responsible for looking up the
ProductSpecification based on the itemID
match?
 By the Expert pattern, ProductCatalog is a
good candidate for the responsibility, since it
logically contains all the
ProductSpecifications.
Visibility to a product catalog
 Who should send the Specification message
to the ProductCatalog to ask for a
ProductSpecification.

Assumption: A Register and a ProductCatalog
instances were created during the initial Start
Up use-case, and there is a permanent
connection between them.
 Based on this assumption, then it is possible
to the Register to send the specification
message to the ProductCatalog.
Visibility to a product catalog(2)
 This implies another concept, visibility.
 ‘Visibility’ is the ability of one object to ‘see’ or
to have reference to another object.
 In order for an object to send a message to
another object it must have visibility to it.
Retrieving ProductSpecification
 Retrieving ProductSpecification from a
database.
 It is unlikely that all the Product Specifications will actually be in memory.
 They will most likely be stored in a relational
or object DB and retrieved on demand.
 However the issues surrounding information
retrieval will be deferred for now for simplicity.
Interaction Diagram : enterItem
 Object Design based on the GRASP patterns.
Message to multi-objects
 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 : endSale
 The endSale system operation occurs when a
cashier presses a button indicating the end of
sale.
 A collaborating diagram can be constructed
to satisfy the post-conditions of endSale.
 The GRASP patterns will be used to choose
and justify the messages.
Object Design : endSale
Contract
 Name : endSale()
 Responsibilities : Record that it is the end of
entry of sale items, and display sale total.
 Cross References : Use Cases : Process
Sale
 Exceptions : If a sale is not underway,
indicate that it was an error.
 Pre-Conditions:
There is an underway sale.
 Post-Conditions:
sale.isComplete became true.
Choosing the Controller Class
 Based on the Controller Pattern, as for
enterItem, we will continue to use register as
a controller.
Setting the Sale.isComplete
attribute
 The contract post-condition state:
 Sale.isComplete became true.
 As always, Expert should be the first pattern
considered unless it is a controller or creation
problem (which is not).
 Who should be responsible for setting the
Sale.isComplete attribute of the Sale to true.

By Expert, it should be the Sale itself.
Communication Diagram :
endSale
 Setting the Sale.isComplete attribute (2)
Display of Information
 It states in the responsibilities of the endSale
contract that the sale total must be displayed.
 Who should be responsible for the display of
information: Model-View Separation Pattern.
 Ignore any requirements that involve the display
of information, with the following exception:

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
 By Expert the Sale itself should be
responsible for knowing its total.
 How to find it?

State the responsibility.
 Who should be responsible for knowing the
sale total.
 Summarize the information needed.
Calculating the Sale Total (2)
 The sale total is the sum of the subtotals of all
the saleslineitems.
 Sales Line Item subtotal : line item quantity *
product description price.
 List the information required until to fulfill this
responsibility and the classes that know this
information.
Calculating the Sale Total (3)
Communication Diagram
 Sale getTotal Communication Diagram
Communication Diagram (2)
 Sale getTotal Communication Diagram