A Sequence Diagram is a UML interaction diagram that shows how objects communicate with each other in a specific sequence over time. It focuses on the order of messages exchanged between system components to perform a task.
- Illustrates interactions and message exchanges between objects in chronological order.
- Helps analyze use cases, understand system behavior, and design application workflows.
Example: In an online banking system, a Customer sends a login request to the Authentication System, which verifies the credentials and returns an access response. The diagram shows each message in the order it occurs.
Uses of Sequence Diagrams
Sequence diagrams are used to visualize the order of interactions between objects and understand how a system behaves over time.
- Visualizing Dynamic Behavior: Shows how objects interact step-by-step during the execution of a process or workflow.
- Clear Communication: Provides an easy-to-understand representation of system interactions for developers and stakeholders.
- Designing System Architecture: Illustrates communication between system components, supporting effective architecture design.
- Documenting System Behavior: Serves as documentation for understanding and maintaining system processes.
- Debugging and Troubleshooting: Helps identify bottlenecks, errors, and inefficiencies in object interactions and message flow.
Sequence Diagram Notations
1. Actors
An Actor in UML represents a role played by a user, system, or external entity that interacts with the system. Actors exist outside the system boundary and initiate or participate in system activities.
- Actors can be human users, external systems, devices, or organizations interacting with the system.
- They are represented using a stick-figure symbol and can appear multiple times in a diagram.
Example: 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.
2. Lifelines
A Lifeline in a UML Sequence Diagram represents an individual participant or object involved in an interaction. It shows the existence of an object over time and is displayed as a vertical dashed line below the participant's name.
- Each object or participant in a sequence diagram is represented by its own lifeline.
- Lifelines are placed at the top of the diagram and help track message exchanges over time.
We display a lifeline in a rectangle called head with its name and type. The head is located on top of a vertical dashed line (referred to as the stem) as shown above.
3. 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:
1. Synchronous messages
A synchronous message requires the sender to wait until the receiver finishes processing and sends a response. The interaction proceeds only after the reply is received.
- A large number of calls in object oriented programming are synchronous.
- We use a solid arrow head to represent a synchronous message.
2. Asynchronous Messages
An asynchronous message is a message where the sender does not wait for a response from the receiver. The sender continues its execution while the receiver processes the message independently.
- The sender does not pause or wait for a reply.
- Represented in UML by a line with an open arrowhead.
4. Create message
A Create Message is used to instantiate a new object in a sequence diagram when an interaction requires its creation. It is represented by a dotted arrow labeled create.
Example: The creation of a new order on a e-commerce website would require a new object of Order class to be created.
5. Delete Message
A Delete Message is used to destroy or remove an object from the system in a sequence diagram. It is represented by an arrow ending with an X, indicating the object's termination.
Example: In the scenario below when the order is received by the user, the object of order class can be destroyed.
6. 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.
Example: Consider a scenario where the device wants to access its webcam. Such a scenario is represented using a self message.
7. 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 arrow head with a dotted line. The interaction moves forward only when a reply message is sent by the receiver.
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.
8. 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.
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.
9. 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.
Example: Consider a scenario where a warning is generated.
The warning might be generated for the user or other software/object that the lifeline is interacting with. Since the destination is not known before hand, we use the Lost Message symbol.
10. 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.
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.
The above sequence diagram depicts the sequence diagram for an emotion based music player:
- Firstly the application is opened by the user.
- The device then gets access to the web cam.
- The webcam captures the image of the user.
- The device uses algorithms to detect the face and predict the mood.
- It then requests database for dictionary of possible moods.
- The mood is retrieved from the database.
- The mood is displayed to the user.
- The music is requested from the database.
- The playlist is generated and finally shown to the user.
Challenges of Using Sequence Diagrams
While sequence diagrams are useful for modeling interactions, they can become difficult to manage in large and complex systems.
- Complexity and Size: Large systems can result in lengthy diagrams that are difficult to read and maintain.
- Dynamic Nature: Diagrams require frequent updates as system requirements and interactions change.
- Ambiguity in Messages: Unclear message definitions can lead to misunderstandings and inaccurate representations.
- Concurrency and Parallelism: Representing multiple simultaneous interactions can increase diagram complexity.
- Real-Time Constraints: Modeling precise timing requirements and real-time behavior may require additional documentation.