Sequence Diagram
Sequence Diagram
Sequence Diagram
Unit 2, Lecture 4
Prepared By
Shruti bharadwaj
Assistant Professor,UCER,Praygraj
Sequence Diagram
• The sequence diagram represents the flow of
messages in the system and is also termed as an event
diagram.
• It helps in envisioning several dynamic scenarios.
• It portrays the communication between any two
lifelines as a time-ordered sequence of events, such
that these lifelines took part at the run time.
Purpose of a Sequence Diagram
• To model high-level interaction among active objects
within a system.
• To model interaction among objects inside a
collaboration realizing a use case.
• It either models generic interactions or some certain
instances of interaction.
Notations of a Sequence Diagram
1.Actors
2. Lifelines
3. Messages
4. Guards
1. Actors
• An actor in a UML diagram represents a type of role where it
interacts with the system and its objects.
• It is important to note here that an actor is always outside
the scope of the system we aim to model using the UML
diagram.
• We use actors to depict various roles including human users
and other external subjects.
• We represent an actor in a UML diagram using a stick person
notation. We can have multiple actors in a sequence diagram
Here the user in seat reservation system is
shown as an actor where it exists outside
the system and is not a part of the system.
Lifelines
• A lifeline is a named element which depicts an individual participant
in a sequence diagram.
• So basically each instance in a sequence diagram is represented by a
lifeline. Lifeline elements are located at the top in a sequence
diagram.
The standard in UML for naming a lifeline follows the following format
Instance Name : Class Name
Messages
• Communication between objects is depicted using messages.
• The messages appear in a sequential order on the lifeline.
• We represent messages using arrows.
• Lifelines and messages form the core of a sequence diagram.
Messages can be broadly classified into the
following categories
Synchronous Messages
• A synchronous message waits for a reply before the
interaction can move forward.
• The sender waits until the receiver has completed the
processing of the message.
• The caller continues only when it knows that the receiver has
processed the previous message i.e. it receives a reply
message.
• A large number of calls in object oriented programming are
synchronous.
• We use a solid arrow head to represent a synchronous
message.
A sequence diagram using a synchronous
message
Asynchronous Messages
• An asynchronous message does not wait for a reply from the
receiver.
• The interaction moves forward irrespective of the receiver
processing the previous message or not.
• We use a lined arrow head to represent an asynchronous
message.
Create message
• We use a Create message to instantiate a new object in the
sequence diagram.
• There are situations when a particular message call requires
the creation of an object.
• It is represented with a dotted arrow and create word
labelled on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-
commerce website would require a new object of Order class
to be created.
A situation where create
message is used
Delete Message
• We use a Delete Message to delete an object.
• When an object is deallocated memory or is destroyed
within the system we use the Delete Message symbol.
• It destroys the occurrence of the object in the system.
• It is represented by an arrow terminating with a x.
For example – In the scenario below when the order is
received by the user, the object of order class can be
destroyed.
For example – In the scenario below when the order is
received by the user, the object of order class can be
destroyed.
Self Message
Certain scenarios might arise where the object needs
to send a message to itself.
Such messages are called Self Messages and are
represented with a U shaped arrow.
For example – Consider a scenario where the device wants to
access its webcam. Such a scenario is represented using a self
message.
Reply Message
Reply messages are used to show the message being sent
from the receiver to the sender.
We represent a return/reply message using an open
arrowhead with a dotted line.
The interaction moves forward only when a reply message is
sent by the receiver.
For example – Consider the scenario where the device
requests a photo from the user. Here the message which
shows the photo being sent is a reply message.
Found Message
A Found message is used to represent a scenario where an unknown
source sends the message.
It is represented using an arrow directed towards a lifeline from an end
point.
For example: Consider the scenario of a hardware failure.
It can be due to multiple reasons and we are
not certain as to what caused the hardware
failure.
Lost Message
• A Lost message is used to represent a scenario where the recipient is
not known to the system.
• It is represented using an arrow directed towards an end point from a
lifeline.
For example: Consider a scenario where a warning is generated.
A scenario where lost message is
used
Guards
• To model conditions we use guards in UML.
• They are used when we need to restrict the flow of messages
on the pretext of a condition being met.
• Guards play an important role in letting software developers
know the constraints attached to a system or a particular
process.
For example: In order to be able to withdraw cash, having a
balance greater than zero is a condition that must be met as
shown below.
A sequence diagram for an emotion
based music player
Sequence diagram depicts the sequence diagram for an emotion based
music player: