Object-Oriented Analysis and Design
CHAPTERS 15: UML INTERACTION DIAGRAMS
1
What will we learn?
UML Interaction Diagrams – What are they, how to create them
2
UML Interaction Diagrams
There are two types: Sequence and Communication diagrams
We will first look at the notation used to represent these, and then later look at
important principles in OO design
We’ll look at various examples here to learn how to create the diagrams
3
UML Sequence Diagrams
Sequence diagrams are more detailed than communication diagrams
They often represent a series of method calls between objects in a system
The sequence is represented in what is called “fence format”, and each new
object in the sequence is added to the right in the diagram
Interactions between objects are usually method calls, but may also be object
creation/deletion
Especially useful for message flow diagrams, with request-reply pairs
4
Example: Sequence Diagram
:A
myB : B
public class A
{
private B myB = new B();
doOne
doTwo
doThree
Public void doOne()
{
myB.doTwo();
myB.doThree();
}
}
5
UML Communication Diagrams
Communication diagrams illustrate object interaction in a graph or network format; objects may
be placed anywhere in the diagram
doOne
:A
1: doTwo
2: doThree
myB : B
6
Which is best?
Depends on the situation; sequence diagrams are mostly preferred because they can capture
more detail, but communication diagrams are useful for capturing object interaction on
whiteboard or wall sketches
Recall that with Agile UP, much of the design is done at the whiteboard in small groups
In general, more notational tools are available for sequence diagrams, and it is usually easier to
read the call flows
Communication diagrams are much easier to edit and change
Just add in new objects anywhere
Communications diagrams are also much more space efficient
One possible approach: Start with communications diagram, and if needed, then develop
sequence diagrams
7
Reading a Sequence Diagram
: Register
: Sale
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered)
: Payment
We would say “The message makePayment is sent to an instance of Register. The Register
instance sends the makePayment message to the Sale instance. The Sale instance creates an
instance of a Payment.” Here, “message” is a method call.
8
Reading a Communication Diagram
direction of message
makePayment(cashTendered)
:Register
1: makePayment(cashTendered)
:Sale
1.1: create(cashTendered)
:Payment
This diagram has the same intention as the sequence diagram on the previous slide.
9
Interaction Diagrams Are Important
Often left out in favor of class definition diagrams, but these diagrams are
important and should be done early
They describe how the objects interact, and may give clues to the operations
and attributes needed in the class diagrams
These diagrams are part of the Design Model artifact, and are started in the
Elaboration phase in Agile UP
10
Sequence Diagrams: Lifeline Box Notation
Basic notation for the entities that make up the sequence diagram – they are
called lifeline boxes and represent the participants in the particular sequence
being modeled
Note that a participant does not need to be a software class, but it usually is for
our purposes
The standard format for messages between participants is:
return = message(parameter: paramerType) : returnType
Type information is usually omitted, as are parameters
11
lifeline box representing an
unnamed instance of class Sale
:Sale
lifeline box representing a
named instance
s1 : Sale
lifeline box representing the class
Font, or more precisely, that Font is
an instance of class Class – an
instance of a metaclass
«metaclass»
Font
List is an interface
lifeline box representing an
instance of an ArrayList class,
parameterized (templatized) to
hold Sale objects
sales:
ArrayList<Sale>
lifeline box representing
one instance of class Sale,
selected from the sales
ArrayList <Sale> collection
sales[ i ] : Sale
in UML 1.x we could not use an
interface here, but in UML 2, this (or
an abstract class) is legal
x : List
related
example
12
Sequence Diagrams: Messages
Messages are notated as solid arrows with filled in arrowheads between lifelines
The lifelines are the dotted lines that extend below each participant box, and literally show the lifespan of
the participant
The first message may come from an unspecified participant, and is called a “found message”. It
is indicated with a ball at the source
Messages can be synchronous (sender waits until receiver as finished processing the message,
and then continues – blocking call) or asynchronous (sender does not wait, more rare in OO
designs)
Dashed arrow is used to indicate return of control, e.g. after receipt of synchronous message.
May contain a value.
13
: Register
: Sale
doX
doA
a found message
whose sender will not
be specified
doB
doC
doD
execution specification
bar indicates focus of
control
typical sychronous message
shown with a filled-arrow line
14
Sequence Diagrams: Specifics
The execution specification bar or activation bar indicates that the operation is
on the call stack
Usually replies to messages are indicated with a value or a dotted line (see next
slide)
It is possible to have a message to “self” (or “this”)
Sequence diagrams can also indicate instance creation (see later slide)
Likewise, instances can be destroyed (indicated by “X” at the end of lifeline)
15
: Register
: Sale
: Register
doX
d1 = getDate
getDate
aDate
doX
clear
16
: Register
note that newly created
objects are placed at their
creation "height"
: Sale
makePayment(cashTendered)
create(cashTendered)
: Payment
authorize
: Sale
create(cashTendered)
: Payment
...
«destroy»
X
the «destroy» stereotyped
message, with the large
X and short lifeline
indicates explicit object
destruction
17
Sequence Diagrams: Specifics
Diagram frames may be used in sequence diagrams to show:
Loops
Conditional (optional) messages
Nesting (a conditional loop)
Relationships between diagrams
See next slides for examples
18
:A
:B
makeNewSale
a UML loop
frame, with a
boolean guard
expression
loop
[ more items ]
enterItem(itemID, quantity)
description, total
endSale
: Foo
: Bar
xx
opt
[ color = red ]
calculate
yy
19
lineItems[i] :
SalesLineItem
: Sale
t = getTotal
loop
[ i < lineItems.size ]
st = getSubtotal
i++
This lifeline box represents one
instance from a collection of many
SalesLineItem objects.
lineItems[i] is the expression to
select one element from the
collection of many
SalesLineItems; the ‘i” value
refers to the same “i” in the guard
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
20
: Foo
: Bar
xx
opt
[ color = red ]
loop(n)
calculate
21
sd AuthenticateUser
:A
:B
:B
:C
:C
authenticate(id)
doX
doA
doM1
doB
doM2
authenticate(id)
ref
ref
AuthenticateUser
DoFoo
sd DoFoo
:B
:C
interaction occurrence
doX
note it covers a set of lifelines
doY
note that the sd frame it relates to
has the same lifelines: B and C
doZ
22
Polymorphism and Asynchronous/Synchronous Calls
Polymorphism – inheriting an operation from a superclass
Can show this by first showing the message to the abstract class, and then breaking out
individual diagrams for the sub-classes
Asynchronous messages: does not have to wait for response, does not block
Initiate new thread of execution
Notation: Usually notated with a “stick” arrow, but not always.
Often context is clear from the system being modeled
23
Payment {abstract}
Payment is an abstract
superclass, with concrete
subclasses that implement the
polymorphic authorize operation
authorize() {abstract}
...
CreditPayment
DebitPayment
authorize()
...
authorize()
...
object in role of abstract
superclass
polymorphic message
:Register
:Payment {abstract}
doX
authorize
:DebitPayment
stop at this point – don’t show any
further details for this message
:Foo
authorize
:CreditPayment
:Bar
authorize
doA
doX
doB
separate diagrams for each polymorphic concrete case
24
a stick arrow in UML implies an asynchronous call
a filled arrow is the more common synchronous call
active
object
System :
Class
:ClockStarter
In Java, for example, an asynchronous call may occur as
follows:
// Clock implements the Runnable interface
Thread t = new Thread( new Clock() );
t.start();
the asynchronous start call always invokes the run method
on the Runnable (Clock) object
to simplify the UML diagram, the Thread object and the
start message may be avoided (they are standard
“overhead”); instead, the essential detail of the Clock
creation and the run message imply the asynchronous call
startClock
create
:Clock
run
runFinalization
25
Communication Diagram Notation
For a communication diagram, identify the objects and establish the links
between them
A link is a connection between objects, indicates some kind of navigation or visibility between
objects is possible
Use links to list messages that may flow between objects
Each message is listed on the link, numbered, with a small arrow to indicate
direction
There can be multiple messages on the links
26
Messages in a Communication Diagram
msg1
1: msg2
2: msg3
3: msg4
: Register
:Sale
3.1: msg5
all messages flow on the same link
27
Communication Diagram Messages - Notes
Usually the starting message is not numbered
It is possible to have messages from the object to itself – do this with a link from
the object to itself, and notate the message on that link
If the message is creating an object, the message is usually named “create” (may
include parameters)
Sometimes “new” is also used, and also <<create>> above the message
The messages are numbered to indicate order, and nested messages are
normally notated as n.x, where x is the message number in the nested
sequence.
28
Messages Numbering
first
second
third
msg1
1: msg2
:A
:B
1.1: msg3
2.1: msg5
2: msg4
:C
fourth
fifth
2.2: msg6
sixth
:D
29
Communication Diagram Messages – Other Qualities
A conditional message may be indicated with a condition in square brackets
before the message
Mutually exclusive conditional paths – two sequence paths depending on a
condition
Looping can also be shown
Like sequence diagrams, multiple communication diagrams can be used to
indicate polymorphism
Asynchronous calls/messages are usually indicated with stick arrows
See following slides for examples
30
Messages – Conditional and Looping
conditional message, with test
message1
: Foo
1 [ color = red ] : calculate
runSimulation
: Bar
: Simulator
1 * [ i = 1..n ]: num = nextInt
: Random
iteration is indicated with a * and an optional
iteration clause following the sequence number
31
Messages – Mutually Exclusive Conditional Paths
unconditional after
either msg2 or msg4
:E
1a and 1b are mutually
exclusive conditional paths
2: msg6
1a [test1] : msg2
msg1
:B
:A
1a.1: msg3
1b [not test1] : msg4
:D
1b.1: msg5
:C
32
Sequence Diagram - Example
33
34
35
36
37
Takeaways from Chapter 15
Understand the basics of reading UML sequence diagrams, and how they show
interaction between the objects that make up the system.
38
Next …
System Sequence Diagrams – Chapter 10
39