Sequence Diagrams

By
Zvika Gutterman
Adam Carmi
Sequence Diagrams 2
Agenda
Interaction Diagrams
A First Look at Sequence Diagrams
Objects
Messages
Control Information
Examples
Sequence Diagrams 3
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 4
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 5
Interaction Diagrams (Cont.)
UML
Collaboration Diagrams
Emphasizes structural relations between objects
Sequence Diagram
The subject of this tutorial
Sequence Diagrams 6
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 7
A Sequence Diagram
member:
LibraryMember
book:Book
:Book
Copy
borrow(book)
ok = mayBorrow()
[ok] borrow(member)
setTaken(member)
Sequence Diagrams 8
A Sequence Diagram
member:
LibraryMember
book:Book
:Book
Copy
borrow(book)
ok = mayBorrow()
[ok] borrow(member)
setTaken(member)
X-Axis (objects)
Y
-
A
x
i
s

(
t
i
m
e
)

Object
Life
Line
message
Activation
box
condition
Sequence Diagrams 9
Object
Object naming:
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 objects life
during the interaction
myBirthdy
:Date
Sequence Diagrams 10
Messages
An interaction between two objects is
performed as a message sent from one
object to another (simple operation call,
Signaling, RPC)
If object obj
1
sends a message to another
object obj
2
some link must exist between
those two objects (dependency, same
objects)
Sequence Diagrams 11
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 12
Return Values
Optionally indicated using a dashed arrow
with a label indicating the return value.
Dont 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 13
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()
Caller
Blocked
return
(optional)
yes
Sequence Diagrams 14
Object Creation
An object may create another object via a
<<create>> message.
:A :B
<<create>>
Constructor
:A
<<create>>
:B
Preferred
Sequence Diagrams 15
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 16
Control information
Condition
syntax: [ expression ] message-label
The message is sent only if the condition is true
example:
Iteration
syntax: * [ [ expression ] ] message-label
The message is sent many times to possibly
multiple receiver objects.
[ok] borrow(member)
Sequence Diagrams 17
Control Information (Cont.)
Iteration examples:
:Driver
*[until full] insert()
:Bus
The syntax of
expressions is
not a standard
:CompoundShape :Shape
*draw()
draw()
Sequence Diagrams 18
Control Information (Cont.)
The control mechanisms of sequence
diagrams suffice only for modeling simple
alternatives.
Consider drawing several diagrams for
modeling complex scenarios.
Dont use sequence diagrams for detailed
modeling of algorithms (this is better done
using activity diagrams, pseudo-code or state-
charts).
Sequence Diagrams 19
getViolation(id)
Example 1
Clerk
:Violations
Dialog
:Violations
Controller
:Violations
DBProxy
lookup
viewButton()
id=getID()
v:Traffic
Violation
display(v)
<<create>>
v
Lookup
Traffic
Violation
May be a
pseudo-
method
DB is queried
and the result
is returned as
an object
Sequence Diagrams 20
print(doc,client)
Example 2
Client
:PrintServer :Queue
:Printer
Proxy
enqueue(job)
status
Printing A
Document
job=dequeue()
[job]print(job.doc)
[job] done(status)
Repeated
forever with 1
min interludes
Active
object