Sequence Diagrams
Help Material
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
• Often used to model the way a use case is
purpose.
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
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 4
A Sequence Diagram
member: :Book
book:Book
LibraryMember Copy
borrow(book)
ok = mayBorrow()
[ok] borrow(member)
setTaken(member)
Sequence Diagrams 5
A Sequence Diagram
X-Axis (objects)
member: :Book
book:Book
LibraryMember Copy
borrow(book) Object
ok = mayBorrow()
Life
Y-Axis (time)
Line
message
Activation
[ok] borrow(member)
setTaken(member) box
condition
Sequence Diagrams 6
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 7
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
Sequence Diagrams 8
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 9
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()
– Prefer modeling return values as part of a
method invocation, e.g. ok = isValid()
– Model a return value when you need to refer to
it elsewhere, e.g. as a parameter passed in
another message.
Sequence Diagrams 10
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 (optional)
Blocked yes
Sequence Diagrams 11
Object Creation
• An object may create another object via a
<<create>> message.
Preferred
:A :B :A
<<create>> <<create>>
:B
Constructor
Sequence Diagrams 12
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 13
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 14
Control Information (Cont.)
• Iteration examples:
:CompoundShape :Shape :Driver :Bus
draw()
*draw() *[until full] insert()
The syntax of
expressions is
not a standard
Sequence Diagrams 15
Indicating selection and
loops
• frame: box around part of a sequence diagram to indicate selection or loop
– if -> (opt) [condition]
– if/else -> (alt) [condition], separated by horizontal dashed line
– loop -> (loop) [condition or items to loop over]
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)
<<create>> v:Traffic
Violation
v DB is queried
display(v)
and the result
is returned as
an object
Sequence Diagrams 18
Example 2 - Observer Pattern
??? : ConcreteSubject ob1 : ob2 :
ConcreterObserver ConcreterObserver
notify( )
update( )
getState( )
for each
observer
update( )
getState( )
Sequence Diagrams 19
Printing A
Example 3 Document
Active :Printer
:PrintServer :Queue
object Proxy
Client
print(doc,client) enqueue(job)
queued
job=dequeue()
Repeated
forever with 1
[job]print(job.doc)
min interludes
status
[job] done(status)
Sequence Diagrams 20
Helping Material
https://www.youtube.com/watch?v=cxG-qWthxt4&list=PLGLf
Vvz_LVvQ5G-LdJ8RLqe-ndo7QITYc&index=4
https://www.uml-diagrams.org/sequence-diagrams-examples.ht
ml
Sequence Diagrams 21
