Chapter 17
Initial Object Design Inputs:
• requirements meetings
• various Use Cases – 10% complete
• Key risks addressed with preliminary programming
• System Sequence Diagrams
• The Domain Model
• Glossary
• Use Case post-conditions clarify proposed
achievements.
Object Design Activities:
• Test-first development (test code <--> production code)
• Some UML modeling
• Sequence Diagrams concurrent with Class Diagrams
• Apply GRASP principles and GoF Design Patterns
• Follow RDD – responsibility-driven design
• Class diagrams are intended for understanding, not
documentation
Object Design Outcome:
• Add methods to appropriate classes.
• This simplistic description hides the deep principles and
issues involved and he consequences of getting it
wrong.
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
enterItem
(itemID, quantity)
d = getProductDescription(itemID)
addLineItem( d, quantity )
inputs and outputs
of a day of design
Register
ProductCatalog
...
makeNewSale()
enterItem(...)
...
...
*
1
getProductDescription(...)
...
: Sale
Responsibility-Driven Design (RDD):
• Think in terms of responsibilities, roles and
collaborations
• Two kinds:
– doing
– knowing
•
Think about responsibility “granularity”
•
Responsibilities happen in conjunction with
collaborations between objects.
Responsibility-Driven Design (RDD):
• Doing:
– doing something itself
– initiating action in others
– controlling or coordinating activities across various
objects
Responsibility-Driven Design (RDD):
• Knowing:
– knowing about private data
– knowing about related objects
– knowing about secondary data it can calculate (result
of a method call)
Guidelines:
• Domain Model guides what classes “know”
• Results in “low representational gap”
• keep your eye on responsibility “granularity”
– big responsibilities get spread over many classes
– small responsibilities may take only one method
• Collaboration is everywhere – methods talk to one
another
RDD as Metaphor:
• An OO Design seen as a community of collaborating
responsible objects.
GRASP:
• General Responsibility Assignment Software Patterns or
Principles
• Basic principles to follow when assigning responsibilities
• Used in place of experience
• based on recognized successful patterns
GRASP Principles:
• Information Expert: assign responsibility to the
knowledgeable class; the one with the necessary info
• Creator: Creation responsibility goes to the class that
– contains an object
– aggregates an object
– has initializing data
• Controller: A class that represents the overall system,
“root”, a device, a subsystem or a Use Case goal. This is
the first class beyond the UI.
• Low Coupling: Keep unnecessary coupling to a
minimum. Typically one of many alternatives.
GRASP Principles:
• High Cohesion: assign responsibility so cohesion
remains high. Typically one of many alternatives.
• Polymorphism: Assign responsibilities as behaviour
varies by type. Use polymorphism.
• Pure Fabrication: When a highly cohesive set of
behaviours needs a home and no domain object does it.
• Indirection: Use an intermediate object when you don't
want to classes to know about each other.
• Protected Variations: Protecting against instability if
variations need frequent tweaking. Identify places of
predictable instability and protect them with an interface.
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
)
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
What GRASP principles are applied here?
:P
a
y
m
e
n
t
Patterns:
• A pattern is a named description of a problem and its
solution that can be applied to new contexts.
• Naming a pattern is important. If you can't name it you
don't understand it.
• Patterns are all old friends. Keep to the tried and true.
• “New” pattern is an oxymoron.
• Own the GoF book – Design Patterns
Fig. 17.3
What GRASP patterns are in use?
Fig. 17.5
Board aggregates Square. Start there.
Find the GRASP patterns in use here:
• Creator: Board creates Square (LRG) since it
aggregates squares.
• Information expert: To retrieve one square one needs to
know about all squares. This is Board's job as
aggregator.
• Low Coupling: Knowing about squares as a collection
and then individually means low coupling.
• Controller:
• High Cohesion:
Fig. 17.4
Fig. 17.6
Find the GRASP patterns in use here:
• Low Coupling: Knowing about squares as a collection
and then individually means low coupling.
• Controller:
• High Cohesion:
Fig. 17.7
Fig. 17.8
Fig. 17.9
Fig. 17.10
Fig. 17.11
Fig. 17.12
Sale
time
1
Contains
1..*
Sales
LineItem
quantity
*
Described-by 1
Product
Description
description
price
itemID
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
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
Fig. 17.14
Sale
time
1
Contains
1..*
Sales
LineItem
quantity
*
Described-by 1
Product
Description
description
price
itemID
Fig. 17.14
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.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
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.16
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
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
:P
roduct
D
escription
getS
ubtotal()
P
roduct
D
escription
description
price
item
ID
N
ewm
ethod
getP
rice()
Fig. 17.17
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
:P
roduct
D
escription
getS
ubtotal()
P
roduct
D
escription
description
price
item
ID
N
ewm
ethod
getP
rice()
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
)
p
:P
a
y
m
e
n
t
:
S
a
l
e
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
)
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
(
)
:
P
a
y
m
e
n
t
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
(
)
:
P
a
y
m
e
n
t
Fig. 17.20
System
endSale()
enterItem()
makeNewSale()
makePayment()
...
Fig. 17.20
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.
Fig. 17.21
pressesbutton
: Cashier
actionPerformed( actionEvent )
UI Layer
:SaleJFrame
systemoperationmessage
enterItem(itemID, qty)?
Domain
Layer
: ???
Whichclassof object shouldberesponsiblefor receivingthis
systemevent message?
It issometimescalledthecontroller or coordinator. It doesnot
normallydothework, but delegatesit toother objects.
Thecontroller isakindof "facade" ontothedomainlayer from
theinterfacelayer.
Fig. 17.22
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.22
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
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
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.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
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
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.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
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