Object Design
Interaction Diagrams
Design
Three ways developers design objects
Code. Design-while-coding (Java, C#, …), ideally with
power tools such as re-factorings. From mental model
to code.
Draw, then code. Drawing some UML on a
whiteboard or UML CASE tool, then switching to #1
with a text-strong IDE (e.g., Eclipse or Visual Studio).
Only draw. Somehow, the tool generates everything
from diagrams.
Agile Modeling and Lightweight UML Drawing
2
Static and Dynamic Modeling
Dynamic models, such as UML interaction diagrams
(sequence diagrams or communication diagrams), help
design the logic, the behavior of the code or the method
bodies
most of the challenging, interesting, useful design work happens
while drawing the UML dynamic-view interaction diagrams
Static models, such as UML class diagrams, help design the
definition of packages, class names, attributes, and method
signatures (but not method bodies).
The most common static object modeling is with UML class
diagrams
Spend significant time doing interaction diagrams, not just
class diagrams.
it's especially during dynamic modeling that we apply
responsibility-driven design and the GRASP principles
3
Static and Dynamic Modeling
4
Object Design Skill vs. UML
Notation Skill
Drawing UML is a reflection of making
decisions about the design.
The object design skills are what matter,
not knowing how to draw UML.
Fundamental object design requires
knowledge of:
principles of responsibility assignment
design patterns
5
Other Object Design Techniques: CRC (Class
Responsibility Collaboration) Cards
6
Dynamic Modeling
UML Interaction Diagrams
Interaction Diagrams
The UML includes interaction diagrams to illustrate how
objects interact via messages
The term interaction diagram is a generalization of two
more specialized UML diagram types:
sequence diagrams
communication diagrams
A related diagram is the interaction overview diagram; it
provides a big-picture overview of how a set of
interaction diagrams are related in terms of logic and
process-flow
New addition in UML 2.0
Sequence diagrams are the more notationally rich of the
two types, but communication diagrams have their use
as well, especially for wall sketching.
8
Sequence Diagram
:A m yB : B
doO ne
doTw o
d o T h re e
• Sequence diagram’s ‘fence’ format
• Time is increasing in the downward direction
9
Sequence Diagram
: A m yB : B
doO ne
doTw o
d o T h re e
public class A
{
private B myB = new B();
public void doOne()
{
myB.doTwo();
myB.doThree();
}
10 }
Communication Diagrams
doO ne
:A
1: doTw o
2 : d o T h re e
m yB : B
Same collaboration using communication diagram
Uses network (or graph) format
11
Interaction Diagrams
Sequence vs. Communication diagrams
Sequence Diagrams
Easier to see sequence of method calls over time
More expressive UML notation
Better support from many tools
Communication Diagrams
Better fit on limited space (page or whiteboard)
Easier to edit/amend
12
Example Sequence Diagram: makePayment
: Register : Sale
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered) : Payment
1. Someone(?) sends makePayment(..) msg to Register
2. Register sends makePayment(..) msg to Sale
3. Sale creates an instance of Payment
Who created Register & Sale? IDs show a fragment of system behavior
during isolated snapshot in time. This can be confusing and lead to
modeling errors/omissions!
13
Code
public class Sale
{
private Payment payment;
public void makePayment( Money cashTendered )
{
payment = new Payment( cashTendered );
//…
}
// …
}
14
Communication Diagram
direction of message
makePayment(cashTendered) :Register 1: makePayment(cashTendered) :Sale
1.1: create(cashTendered)
:Payment
Same collaboration using communication diagram
15
Lifeline boxes to show participants in interactions
lifeline box representing the class
lifeline box representing a Font, or more precisely, that Font is
lifeline box representing an
named instance an instance of class Class – an
unnamed instance of class Sale
instance of a metaclass
«metaclass»
:Sale s1 : Sale
Font
List is an interface
lifeline box representing an lifeline box representing
instance of an ArrayList class, one instance of class Sale, in UML 1.x we could not use an
parameterized (templatized) to selected from the sales interface here, but in UML 2, this (or
hold Sale objects ArrayList <Sale> collection an abstract class) is legal
sales: x : List
sales[ i ] : Sale
ArrayList<Sale>
related
example
16
Interaction Diagrams
Message expression syntax
Don’t have to use full syntax in all cases
return = msgName(param:paramType1, …) : returnType
Examples:
initialize(code)
initialize
d = getProductDescription(id)
d = getProductDescription(id:ItemID)
d = getProductDescription(id:ItemID) : ProductDescription
17
Singleton Objects
1
: Register
: Store the ‘1’ implies this is a
Singleton, and accessed
doX via the Singleton pattern
doA
18
Basic Sequence Diagram Notation
: Register : Sale
doX
doA
doB
a found message
whose sender will not
be specified doC
doD
execution specification
bar indicates focus of
control typical sychronous message
shown with a filled-arrow line
19
Illustrating Reply or Returns
: Register : Sale
More common return syntax
doX
d1 = getDate
getDate
aDate
A return from method call, usually considered optional
20
Messages to "self" or "this"
: R e g is te r
doX
c le a r
Objects commonly invoke their own methods
21
Creation of Instances
n o te th a t n e w ly c re a te d
: R e g is te r : S a le
o b je c ts a re p la c e d a t th e ir
c re a tio n "h e ig h t"
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 aym ent
a u th o riz e
Dashed line for ‘create’ really not needed, though its now official UML
Use ‘create’ for calls to a constructor
22
Object Lifelines and Object Destruction
: S a le
c re a te (c a s h T e n d e re d )
: P aym ent
th e « d e s tro y » s te re o ty p e d
... m e s s a g e , w ith th e la rg e
X a n d s h o rt life lin e
« d e s tro y » in d ic a te s e x p lic it o b je c t
X d e s tru c tio n
Usually not necessary for languages with automatic garbage
collection (e.g., Java)
23
Diagram Frames in UML Sequence
Diagrams
Looping
:A :B
makeNewSale
a UML loop loop [ more items ]
enterItem(itemID, quantity)
frame, with a
boolean guard
expression description, total
endSale
24
Conditional Messages
: Foo : Bar
xx
opt [ c o lo r = re d ]
c a lc u la te
yy
UML 2 frame showing an optional message
25
Conditional Messages in UML 1.x Style
Still Useful?
: Foo : Bar
xx
[ c o lo r = re d ] c a lc u la te
yy
The same interaction diagram using pre-UML 2 notation
Guards must evaluate to true for the message to be sent
26
Mutually Exclusive Conditional Messages
: A : B :C
doX
a lt [ x < 10 ]
c a lc u la te
[ e ls e ]
c a lc u la te
Alt frame show mutually exclusive interactions
27
Iteration over a collection using relatively
explicit notation.
lineItems[i] :
: Sale This lifeline box represents one
SalesLineItem
instance from a collection of many
t = getTotal SalesLineItem objects.
lineItems[i] is the expression to
loop select one element from the
[ i < lineItems.size ]
st = getSubtotal collection of many
SalesLineItems; the ‘i” value
refers to the same “i” in the guard
i++
in the LOOP frame
an action box may contain arbitrary language
statements (in this case, incrementing ‘i’)
it is placed over the lifeline to which it applies
The selector expression is used to select one object from a group.
Lifeline participants should represent one object, not a collection.
28
Code
public class Sale
{
private List<SalesLineItem> lineItems = new ArrayList<SalesLineItem>();
public Money getTotal()
{
Money total = new Money();
Money subtotal = null;
for ( SalesLineItem lineItem : lineItems )
{
subtotal = lineItem.getSubtotal();
total.add( subtotal );
}
return total;
}
// …
}
29
Iteration over a collection leaving things
more implicit
lin e Ite m s [i] :
: S a le
S a le s L in e Ite m
t = g e tT o ta l
lo o p
s t = g e tS u b to ta l
A 2nd technique for looping
30
Nesting of Frames
: Foo : Bar
xx
opt [ c o lo r = re d ]
lo o p (n )
c a lc u la te
A loop frame nested within an optional frame
31
Interaction occurrence, sd and ref frames
SD can contain frames that
reference other SDs sd AuthenticateUser
:B :C
:A :B :C
authenticate(id)
doX
doA doM1
doB
doM2
authenticate(id) ref
AuthenticateUser
ref sd DoFoo
DoFoo
:B :C
interaction occurrence doX
note it covers a set of lifelines doY
note that the sd frame it relates to doZ
has the same lifelines: B and C
32
Messages to Classes to Invoke Static (or
Class) Methods
message to class, or a
static method call
doX
1: locs = getAvailableLocales «m etaclass»
: Foo
Calendar
Notice there is no implied instance to the Calendar class (‘:’ is omitted)
33
Polymorphic Messages and Cases
P a ym e n t {a b stra ct}
P a ym e n t is a n a b stra c t a u th o rize () {a b stra c t}
su p e rcla ss , w ith co n cre te ...
su b cla s se s th a t im p le m e n t th e
p o lym o rp h ic a u th o riz e o p e ra tio n
C re d itP a ym e n t D e b itP a y m e n t
a u th o riz e () a u th o rize ()
... ...
o b je c t in ro le o f a b stra c t
p o lym o rp h ic m e ssa g e
su p e rcla ss
:R e g is te r :P a ym e n t {a b stra c t}
doX
a u th o rize sto p a t th is p o in t – d o n ’t sh o w a n y
fu rth e r d e ta ils fo r th is m e ssa g e
:D e b itP a y m e n t :F o o :C re d itP a ym e n t :B a r
a u th o rize a u th o riz e
doA doX
doB
34 se p a ra te d ia g ra m s fo r e a c h p o ly m o rp h ic co n cre te ca se
