Sequence Diagrams

Interaction Diagrams
• A series of diagrams describing the dynamic
behavior of an object-oriented system.
– A set of messages exchanged among a set of
objects within a context to accomplish a
purpose.
• Often used to model the way a use case is
realized through a sequence of messages
between objects.
Sequence Diagrams 2
Interaction Diagrams (Cont.)
• The purpose of Interaction diagrams is to:
– Model interactions between objects
– Assist in understanding how a system (a use
case) actually works
– Verify that a use case description can be
supported by the existing classes
– Identify responsibilities/operations and assign
them to classes
Sequence Diagrams 3
Interaction Diagrams (Cont.)
• UML
– Collaboration Diagrams
• Emphasizes structural relations between objects
– Sequence Diagram
• The subject of this tutorial

Sequence Diagrams 4
 A First Look at Sequence
Diagrams
• Illustrates how objects interacts with each
other.
• Emphasizes time ordering of messages.
• Can model simple sequential flow,
branching, iteration, recursion and
concurrency.

Sequence Diagrams 5
 A Sequence Diagram

member: :Book
book:Book
LibraryMember Copy

borrow(book)
ok = mayBorrow()

[ok] borrow(member)
setTaken(member)

Sequence Diagrams 6
 A Sequence Diagram
X-Axis (objects)

member: :Book
book:Book
LibraryMember Copy

borrow(book) Object
Life
ok = mayBorrow()
Y-Axis (time)

Line
message
Activation
[ok] borrow(member)
setTaken(member) box
condition

Sequence Diagrams 7
 Object
• Object naming: myBirthdy
:Date
– syntax: [instanceName][:className]
– Name classes consistently with your class
diagram (same classes).
– Include instance names when objects are
referred to in messages or when several
objects of the same type exist in the diagram.
• The Life-Line represents the object’s life
during the interaction

Sequence Diagrams 8
 Messages
• An interaction between two objects is
performed as a message sent from one
object to another (simple operation call,
Signaling, RPC)
• If object obj1 sends a message to another
object obj2 some link must exist between
those two objects (dependency, same
objects)
Sequence Diagrams 9
 Messages (Cont.)
• A message is represented by an arrow between the
life lines of two objects.
– Self calls are also allowed
– The time required by the receiver object to process the
message is denoted by an activation-box.
• A message is labeled at minimum with the
message name.
– Arguments and control information (conditions,
iteration) may be included.

Sequence Diagrams 10
 Return Values
• Optionally indicated using a dashed arrow
with a label indicating the return value.
– Don’t model a return value when it is obvious
what is being returned, e.g. getTotal()
– Model a return value only when you need to
refer to it elsewhere, e.g. as a parameter passed
in another message.
– Prefer modeling return values as part of a
method invocation, e.g. ok = isValid()

Sequence Diagrams 11
 Synchronous Messages
• Nested flow of control, typically
implemented as an operation call.
– The routine that handles the message is
completed before the caller resumes execution.
:A :B

doYouUnderstand()
return
Caller
yes (optional)
Blocked
Sequence Diagrams 12
 Object Creation
• An object may create another object via a
<<create>> message.
Preferred
:A :B :A

<<create>> <<create>>
:B

Constructor

Sequence Diagrams 13
 Object Destruction
• An object may destroy another object via a
<<destroy>> message.
– An object may destroy itself.
– Avoid modeling object destruction unless memory
management is critical.
:A :B
<<destroy>>

Sequence Diagrams 14
 Control information
• Condition
– syntax: ‘[‘ expression ’]’ message-label
– The message is sent only if the condition is true
– example: [ok] borrow(member)

• Iteration
– syntax: * [ ‘[‘ expression ‘]’ ] message-label
– The message is sent many times to possibly
multiple receiver objects.
Sequence Diagrams 15
 Control Information (Cont.)
• Iteration examples:

:CompoundShape :Shape :Driver :Bus

draw()
*draw() *[until full] insert()

The syntax of
expressions is
not a standard

Sequence Diagrams 16
 Control Information (Cont.)
• The control mechanisms of sequence
diagrams suffice only for modeling simple
alternatives.
– Consider drawing several diagrams for
modeling complex scenarios.
– Don’t use sequence diagrams for detailed
modeling of algorithms (this is better done
using activity diagrams, pseudo-code or state-
charts).

Sequence Diagrams 17
 Example 1
:Violations :Violations :Violations Lookup
Dialog Controller DBProxy
Traffic
Clerk
lookup Violation
viewButton()

id=getID()

getViolation(id)
May be a <<create>> v:Traffic
pseudo- Violation
method
v DB is queried
display(v)
and the result
is returned as
an object

Sequence Diagrams 18
 Printing A
Example 2 Document

Active :Printer
:PrintServer :Queue
object Proxy
Client
print(doc,client) enqueue(job)

job=dequeue()
Repeated
forever with 1
[job]print(job.doc)
min interludes
status
[job] done(status)

Sequence Diagrams 19