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