Sequence Diagrams

LOG
O
Sequence Diagrams
Agenda
Interaction Diagrams
A First Look at Sequence Diagrams
Objects
Messages
Control Information
Examples
2
Sequence Diagrams
Interaction Diagrams
A series of diagrams describing the
dynamic behavior of an objectoriented 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.
3
Sequence Diagrams
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
4
Sequence Diagrams
Interaction Diagrams
(Cont.)
UML
 Collaboration Diagrams
• Emphasizes structural relations between objects
 Sequence Diagram
• The subject of this tutorial
5
Sequence Diagrams
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.
6
Sequence Diagrams
A Sequence Diagram
member:
LibraryMember
book:Book
:Book
Copy
borrow(book)
ok = mayBorrow()
[ok] borrow(member)
setTaken(member)
7
Sequence Diagrams
A Sequence Diagram
X-Axis (objects)
member:
LibraryMember
:Book
Copy
book:Book
borrow(book)
Y-Axis (time)
ok = mayBorrow()
message
[ok] borrow(member)
Life
Line
setTaken(member)
Object
Activation
box
condition
8
Sequence Diagrams
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
object’s life during the
interaction
9
myBirthdy
:Date
Sequence Diagrams
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)
10
Sequence Diagrams
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.
11
Sequence Diagrams
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()
12
Sequence Diagrams
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
yes
13
return
(optional)
Sequence Diagrams
Object Creation
An object may create another object
via a <<create>> message.
Preferred
:A
:B
:A
<<create>>
<<create>>
:B
Constructor
14
Sequence Diagrams
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>>
15
Sequence Diagrams
Control information
Condition
 syntax: ‘[‘ expression ’]’ message-label
 The message is sent only if the condition is
true
[ok] borrow(member)
 example:
Iteration
 syntax: * [ ‘[‘ expression ‘]’ ] message-label
 The message is sent many times to
possibly multiple receiver objects.
16
Sequence Diagrams
Control Information
(Cont.)
Iteration examples:
:CompoundShape
draw()
:Shape
:Driver
*draw()
:Bus
*[until full] insert()
The syntax of
expressions is
not a standard
17
Sequence Diagrams
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 statecharts).
18
Sequence Diagrams
Example 1
:Violations
Dialog
:Violations
Controller
:Violations
DBProxy
Lookup
Traffic
Violation
Clerk
lookup
viewButton()
id=getID()
getViolation(id)
May be a
pseudomethod
v
display(v)
19
<<create>>
v:Traffic
Violation
DB is queried
and the result
is returned as
an object
Sequence Diagrams
Example 2
Printing A
Document
Active
object
:PrintServer
:Queue
:Printer
Proxy
Client
print(doc,client)
Repeated
forever with 1
min interludes
enqueue(job)
job=dequeue()
[job]print(job.doc)
status
[job] done(status)
20
Sequence Diagrams