Chapter 17
GRASP
• General Responsibility Assignment
Software Patterns (Principles)
• OOD: after identifying requirements,
create domain model, define
responsiblities and assign methods to
classes
• define “messaging” (who sends the
message)
• Patterns are a big part
Grasp Patterns
• Controller: go-between, UI and Domain
– enhances low coupling
– enhances reuse
– represents “system” from the Use Case point
of view
– shared: User Controller handles CreateUser
and DeleteUser use cases
Fig. 17.20
system-level
operations
System
endSale()
enterItem()
makeNewSale()
makePayment()
...
Fig. 17.21
pressesbutton
: Cashier
actionPerformed( actionEvent )
UI Layer
:SaleJFrame
systemoperationmessage
enterItem(itemID, qty)
Domain
Layer
: ???
W
hichclassof object shouldberesponsiblefor receivingthis
systemevent message?
It issometimescalledthecontroller or coordinator. It doesnot
normallydothework, but delegatesit toother objects.
Thecontroller isakindof "facade" ontothedomainlayer from
theinterfacelayer.
big delegator
Fig. 17.22
“system” or “handler”
e
n
te
rIte
m
(id
,q
u
a
n
tity
)
e
n
te
rIte
m
(id
,q
u
a
n
tity
)
:R
e
g
is
te
r
:P
ro
c
e
s
s
S
a
le
H
a
n
d
le
r
Fig. 17.23
System
endSale()
enterItem()
makeNewSale()
makePayment()
makeNewReturn()
enterReturnItem()
...
system operations
discovered during system
behavior analysis
Register
...
endSale()
enterItem()
makeNewSale()
makePayment()
makeNewReturn()
enterReturnItem()
...
allocation of system
operations during design,
using one facade controller
ProcessSale
Handler
System
endSale()
enterItem()
makeNewSale()
makePayment()
enterReturnItem()
makeNewReturn()
...
HandleReturns
Handler
...
...
endSale()
enterItem()
makeNewSale()
makePayment()
enterReturnItem()
makeNewReturn()
...
allocation of system
operations during design,
using several use case
controllers
each one
handles a
separate
use case
Grasp Patterns
• Creator: not always a factory. B creates
instances of A if:
– B objects aggregate, record or closely use
many A objects
– B objects have all the info needed to create
an A object
When to use a factory? in cases of significant complexity (AvailableStack),
conditional creation (froma family of similar classes)
Fig. 17.12
Sale
time
1
Contains
1..*
Sales
LineItem
quantity
*
Described-by 1
Product
Description
description
price
itemID
Fig. 17.13
:R
e
g
is
te
r
:S
a
le
m
a
k
e
L
in
e
Ite
m
(q
u
a
n
tity
)
c
re
a
te
(q
u
a
n
tity
)
:S
a
le
s
L
in
e
Ite
m
Grasp Patterns
• High Cohesion: evaluative pattern; keep
objects appropriately focused,
manageable and understandable.
– responsibilities are strongly related
• Low Cohesion: hard to comprehend, hard
to reuse, hard to maintain and adverse to
change
Fig. 17.26
:R
e
g
is
te
r
:S
a
le
m
a
k
e
P
a
y
m
e
n
t()
c
re
a
te
()
p:P
a
y
m
e
n
t
a
d
d
P
a
y
m
e
n
t(p)
Fig. 17.27
:R
e
g
is
te
r
:S
a
le
m
a
k
e
P
a
y
m
e
n
t()
m
a
k
e
P
a
y
m
e
n
t()
c
re
a
te
()
:P
a
y
m
e
n
t
Grasp Patterns
• Indirection: low coupling through use of
intermediary objects.
– Controller is an example
Grasp Patterns
• Information Expert: Responsibility
delegation principle
– put the responsibility with the object having
the most info needed to fulfill the responsibility
– state the responsibility clearly first
Who should be responsible for knowing the grand total of a sale?
– Look in Design Model first, then the Domain
Model
– Expert is the most “intuitive” of patterns
Fig. 17.14
Domain Model Figure
Sale
time
1
Contains
1..*
Sales
LineItem
quantity
*
Described-by 1
Product
Description
description
price
itemID
Fig. 17.15
t=
g
e
t
T
o
t
a
l
:
S
a
l
e
S
a
l
e
t
i
m
e
.
.
.
N
e
w
m
e
t
h
o
d
g
e
t
T
o
t
a
l
(
)
Fig. 17.16
getTotal() needs getSubtotal().
another Expert
th
is
n
o
ta
tio
n
w
illim
p
ly
w
e
a
r
e
ite
r
a
tin
g
o
v
e
ra
ll
e
le
m
e
n
ts
o
fa
c
o
lle
c
tio
n
S
a
le
tim
e
...
t=
g
e
tT
o
ta
l
:S
a
le
1
*
:s
t=
g
e
tS
u
b
to
ta
l
lin
e
Ite
m
s
[i]:
S
a
le
s
L
in
e
Ite
m
g
e
tT
o
ta
l(
)
S
a
le
s
L
in
e
Ite
m
q
u
a
n
tity
N
e
w
m
e
th
o
d
g
e
tS
u
b
to
ta
l(
)
Fig. 17.17
getSubtotal() needs getPrice()
S
ale
tim
e
...
t =getT
otal
:S
ale
1*: st =getS
ubtotal
lineItem
s[ i ] :
S
alesLineItem
1.1: p:=getP
rice()
getT
otal()
S
alesLineItem
quantity
yet another Expert
:P
roduct
D
escription
getS
ubtotal()
P
roduct
D
escription
description
price
item
ID
N
ewm
ethod
getP
rice()
Grasp Patterns
• Low Coupling: evaluative and supports:
– lower dependency between the classes,
– change in one class having lower impact on
other classes,
– higher reuse potential.
Fig. 17.18
m
a
k
e
P
a
y
m
e
n
t
(
)
:R
e
g
i
s
t
e
r
1
:c
r
e
a
t
e
(
)
2
:a
d
d
P
a
y
m
e
n
t
(
p
)
Register unnecessarily put in the
middle between Sale and Payment
p
:P
a
y
m
e
n
t
:
S
a
l
e
Fig. 17.19
m
a
k
e
P
a
y
m
e
n
t
(
)
:R
e
g
i
s
t
e
r
1
:m
a
k
e
P
a
y
m
e
n
t
(
)
:
S
a
l
e
1
.
1
.c
r
e
a
t
e
(
)
Register not involved in Payment
:
P
a
y
m
e
n
t
Grasp Patterns
• Polymorphism: variation of behaviours
based on type assigned to types where
the variation happens:
– lower dependency between the classes,
– change in one class having lower impact on
other classes,
– higher reuse potential.
Grasp Patterns
• Protected Variations: protects objects
from variations in other objects:
– wrap the variation behind an interface facade,
– adapter pattern,
– uses polymorphism
Grasp Patterns
• Pure Fabrication: no relationship to
domain objects but:
– achieves low coupling, high cohesion, and
the reuse potential
– alternative if Information Expert not available.
Object Design Overview
•
•
•
•
•
Iterative context.
requirements workshop
2-3 fully developed use cases
high risks addressed
some progress on domain model
Inputs and Relationship to OOD
• Use Case text: visible behaviour; our
object will “realize” this behaviour
• System Sequence Diagrams: system-level
messages. These are the initial messages
in our program sequence diagrams
OOD Activities:
• Tools: GRASP, GoF Design Patterns
• Metaphor: assign responsibilities to
collaborating objects
• Modeling Purpose: Understanding, not
documentation.
• Next slide shows some activity inputs and
outputs
Fig. 17.1
Sample UP Artifact Relationships
Domain Model
Sale
Business
Modeling
Sales
LineItem
1..*
1
date
...
...
...
quantity
Use-Case Model
Process Sale
Process
Sale
use
case
names
Cashier
Requirements
Use Case Diagram
starting events to
design for, and
detailed postcondition to
satisfy
Design
non-functional
requirements
functional
requirements
that must be
realized by
the objects
Use Case Text
system
events
ideas for
the postconditions
inspiration for
names of
some
software
domain
objects
Supplementary
Specification
1. Customer
arrives ...
2. ...
3. Cashier
enters item
identifier.
domain rules
: System
Glossary
Operation:
enterItem(…)
Post-conditions:
-...
: Cashier
system
operations
make
NewSale()
enterItem
(id, quantity)
item details,
formats,
validation
System Sequence Diagrams
Operation Contracts
Design Model
: Register
: ProductCatalog
: Sale
enterItem
(itemID, quantity)
d = getProductDescription(itemID)
addLineItem( d, quantity )
Register
ProductCatalog
...
makeNewSale()
enterItem(...)
...
...
*
1
Sale
getProductDescription(...)
...
1
addLineItem
Responsibility Driven Design
• Responsibility: Obligation or contract
• Kinds of Responsibilities:
– Doing:
• doing, initiating in others, controlling activities
– Knowing:
• private data, related objects, calculations (guided
by Domain Model and low rep'l gap
Example: A Sale objects is responsible for creating a SalesLineItem
object and knowing the running total
– Collaboration:
• objects need help from otehrs
GRASP Principles
• A learning aid for object design based on
patterns for assigning responsibilties
• Relationship to UML and Responsibilities
• Sequence Diagrams give us an
opportunity to assign responsibilities
Fig. 17.2
:S
a
le
m
a
k
e
P
a
y
m
e
n
t(c
a
s
h
T
e
n
d
e
re
d
)
c
re
a
te
(c
a
s
h
T
e
n
d
e
re
d
)
:P
a
y
m
e
n
t
a
b
s
tra
c
t,im
p
lie
sS
a
leo
b
je
c
tsh
a
v
ea
re
s
p
o
n
s
ib
ilitytoc
re
a
teP
a
y
m
e
n
ts
Sales objects responsible
for creating payment objects
What are Patterns?
• a software system whose design is guided
by the use of general principles or
idomatic solutions
Pattern Name
Information Expert
Problem
What is a basic principle by which to assign
responsiblilities to objects?
Solution
Assign responsibilities to the class that possesses the
most information neededto fulfill it.
What are Patterns?
• A pattern is a named description of a
(problem, solution) pair can be applied in a
new context.
• patterns come with advice on how they
should be used.
• Patterns are known by their names
“We'll expose the services of the persistence
subsystem with a Facade, use an Abstract Factory for the
Mappers classes and Proxy for lazy materialization”
Example
• In a molopoly game what object creates
(invokes creation of) the individual squares
that players can land on?
– B objects aggregate, record or closely use
many A objects
– B objects have all the info needed to create
an A object
A = Square ==> B = ?
Fig. 17.3
Creator Pattern
Fig. 17.4
Fig. 17.5
Example
• In a molopoly game what objects know
about a Square (given a key or square
name)? Such an object is an Information
Expert.
Again the answer is Board; this is reassuring.
Fig. 17.6
Example
• All other things being equal we should
prefer a solution that exhibits low
coupling.
• Low coupling tends to reduce the time,
effort and defects associated with
mmodifying software.
• Does Expert support Low Coupling?
Fig. 17.7
Example
• UI objects should not contain “business”
logic
• UI objects should delegate any needed
domain task to another.
• The Controller patter answers the question
“What first object after the UI layer should
receive a message from the UI layer for
service?
System Sequence Diagram
What class should have
this responsibility?
Controller Design
• Controllers should either:
– represent the overall system ( a device the
software is running within) or a major
subsystem; both variations of the Facade
pattern, or
– represent a use case scenario context (such
as a session controller)
Fig. 17.9
Example
• In the monopoly game, a MonopolyGame
class represents the overall system.
• In the ATM example the ATM represents
the device the software is running within.
• a PlayMonopolyGameHandler acts as a
Session Controller (but we only have one
session!).
Fig. 17.10
design based on
Controller
:MonopolyGame
play game
what next?
Example
• Next slide shows two design approaches
possible.
• Either one class does all the work or else
work is delegated to other classes.
• Lession to learn: low cohesion leads to
high coupling.
Fig. 17.11
Fig. 17.24
presses button
: Cashier
actionPerformed( actionEvent )
UI Layer
system operation message
:SaleJFrame
1: enterItem(itemID, qty)
controller
Domain Layer
:Register
1.1: makeLineItem(itemID, qty)
:Sale
Fig. 17.25
presses button
Cashier
actionPerformed( actionEvent )
UI Layer
:SaleJFrame
It is undesirable for an interface
layer object such as a window to get
involved in deciding how to handle
domain processes.
Business logic is embedded in the
presentation layer, which is not useful.
Domain Layer
SaleJFrame should not
send this message.
1: makeLineItem(itemID, qty)
:Sale