Sequence Diagram
Ashish Kumar
Dept. of CSE
Manipal University Jaipur
1
Sequence Diagram
An "interaction diagram" that models a single scenario
executing in the system
perhaps 2nd most used UML diagram (behind class
diagram)
Shows how objects communicate with each other over
time.
That is, sequence diagrams are used to model object
interactions arranged in time sequence and to
distribute use case behavior to classes.
They can also be used to illustrate all the paths a
particular use case can ultimately produce.
The diagram captures the behavior of a single use
case.
It shows objects and the messages that are passed
between these objects in the use case. 2
When to use a sequence diagram
A good design can have lots of small
methods in different classes.
Because of this it can be difficult to figure
out the overall sequence of behavior.
This diagram is simple and visually
logical, so it is easy to see the sequence of
the flow of control.
A sequence diagram also clearly shows
3
Characteristics of Sequence Diagram
Represents an interaction (messages) exchanged
among collaborating objects for a specific result
It shows time sequence not easily shown in a
communication diagram
It does not show relations between objects
It can show general forms that do not deal with
objects but with class interaction
Used more for real time types of applications
4
Sequence Diagrams Dimensions
Time: The vertical axis represents time
proceedings (or progressing) down the page.
Note that Time in a sequence diagram is all about
ordering, not duration. The vertical space in an
interaction diagram is not relevant for the
duration of the interaction.
Objects: The horizontal axis shows the
elements that are involved in the interaction.
Conventionally, the objects involved in the
operation are listed from left to right according to
when they take part in the message sequence.
However, the elements on the horizontal axis may
appear in any order.
5
Time & Objects
X-Axis (objects)
In Any
Order
Increasin
Y-Axis (time)
g Order
6
Object / Participant & Their Lifelines
Each object/participant has a corresponding
lifeline.
Each vertical dotted line is a lifeline,
representing the time that an object exists.
Squares with object type, optionally preceded by
"name :" :Name Object
Life line
Activation
7
Activation
Also known as Focus of control.
Thick box over object's life line; drawn when
object's method is on the stack
either that object is running its code, or it is on
the stack waiting for another object's method
to finish
Activation
nest to indicate recursion
Nesting
8
Object / Participant 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.
9
Messages
Messages (or signals) on a sequence diagram are
specified using an arrow from the participant
(message caller) that wants to pass the message
to the participant (message receiver) that is to
receive the message.
A Message (or stimulus) is represented as an
arrow going from the sender to the top of the
focus of control (i.e., execution occurrence) of the
message on the receiver's lifeline.
A message is labeled at minimum with the
message name.
Arguments and control information (conditions,
iteration) may be included.
Self calls are also allowed. 10
Message Type Notations
11
Object Creation & Destruction
Object Creation: when an element is
created during an interaction, the
communication that creates the element is
shown with its arrowhead to the element.
Object Destruction: When an element is
destroyed during an interaction, the
communication that destroys the element
is shown with its arrowhead to the
elements lifeline where the destruction is
marked with a large X symbol.
12
Frame
Box around part
of diagram to
indicate if or loop
if -> (opt)
[condition]
if/else -> (alt)
[condition],
separated by
horizontal dashed
line
loop -> (loop)
[condition or
items to loop over]
13
How to Produce Sequence Diagrams
Decide on Context: Identify behavior (or use
case) to be specified
Identify structural elements:
(a) Model objects (classes)
Identify which objects and actors will participate
(b) Model lifelines
Set the lifeline for each object/actor
(c) Model messages
Lay out the messages from the top to the bottom of
the diagram based on the order in which they are
sent
(d) Model activations
(e) Model Timing constraints
Validate, refine and elaborate as required 14
Example
15
Example : Use Case Level
16
Example
17
Thank You
18
