Sequence Diagrams

By Zvika Gutterman Adam Carmi

Agenda
Interaction Diagrams A First Look at Sequence Diagrams Objects Messages Control Information Examples
Sequence Diagrams 2

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 3

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 4

Interaction Diagrams (Cont.)

UML
Collaboration Diagrams
Emphasizes structural relations between objects

Sequence Diagram
The subject of this tutorial

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.

Sequence Diagrams

A Sequence Diagram
member: LibraryMember borrow(book) ok = mayBorrow() book:Book :Book Copy

[ok] borrow(member) setTaken(member)

Sequence Diagrams

A Sequence Diagram
X-Axis (objects)
member: LibraryMember borrow(book) ok = mayBorrow() book:Book :Book Copy

message
[ok] borrow(member)

Life Line
setTaken(member)

Object

Y-Axis (time)

Activation box

condition
Sequence Diagrams 8

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.
myBirthdy :Date

The Life-Line represents the objects life during the interaction

Sequence Diagrams 9

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 10

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 11

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 12

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
doYouUnderstand()

:B

Caller Blocked

yes
Sequence Diagrams

return (optional)
13

Object Creation
An object may create another object via a <<create>> message.
Preferred
:A
<<create>>

:B

:A
<<create>>

:B

Constructor
Sequence Diagrams 14

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

15

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.
Sequence Diagrams 16

Control Information (Cont.)

Iteration examples:
:CompoundShape
draw() *draw()

:Shape

:Driver

:Bus

*[until full] insert()

The syntax of expressions is not a standard

Sequence Diagrams

17

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 statecharts).
Sequence Diagrams 18

Example 1
:Violations Dialog :Violations Controller :Violations DBProxy

Clerk
lookup viewButton() id=getID()

Lookup Traffic Violation

May be a pseudomethod
display(v)

getViolation(id)

<<create>>

v:Traffic Violation

DB is queried and the result is returned as an object

19

Sequence Diagrams

Example 2
Active object Client
print(doc,client) enqueue(job)

Printing A Document
:Queue
:Printer Proxy

:PrintServer

Repeated forever with 1 min interludes

[job] done(status)

job=dequeue() [job]print(job.doc) status

Sequence Diagrams

20