Sequence diagrams, also known as sequence charts, order diagrams, or sequential diagrams, are a type of UML interaction diagram that describes the behavior of objects. They are mainly used to more intuitively represent the chronological order of interactions between objects, focusing on the time flow sequence of sending, receiving, processing, and returning messages by various objects.
A sequence diagram is a two-dimensional diagram where the horizontal axis represents objects and the vertical axis represents time. Messages are transmitted horizontally between objects and are arranged vertically in chronological order.
Sequence diagrams can also show the control structure between objects. For example, in a sequence diagram for a banking scenario, lifelines can represent a customer, a bank teller, or a bank manager, and the communication between the customer, bank teller, and bank manager is represented by the messages passed between them.
Supports real-time multi-user co-creation with shareable links for instant information transfer
Automatically generates graphics from text input and applies style enhancements
Prebuilt themes with full customization for personalized designs
Supports icons, images, labels, LaTeX formulas, code blocks, links, attachments and more
Export: PNG, VISIO, PDF, SVG | Import: VISIO, Mermaid
Real-time cloud storage, multi-device sync, version history, and secure data protection
The main elements of a sequence diagram include six types: roles, objects, lifelines, control focus, messages, and combined fragments.
Objects are represented at the top of a sequence diagram as a rectangle. There are generally three methods of naming objects:
1) Display both object name and class name, for example: “iPhone:Phone”
2) Display only the object name, not the class name, for example: “iPhone:”
3) Display only the class name, not the object name, for example: “:Phone”
Messages are generally divided into synchronous messages, asynchronous messages, return messages, and self-associated messages.
Synchronous Message: After sending a message, the object waits for the receiving object to respond and return the message before proceeding with other tasks, represented by a “solid line arrow”;
Asynchronous Message: After sending a message, the object does not need to wait for the receiving object's return message and can continue with other tasks, represented by a “solid line with greater than sign”;
Return Message: Returns from a process call, represented by a “dashed line arrow”;
Self-Associated Message: Represents a method's self-call, or a method within an object calling another method, represented by a “semi-closed rectangle with a solid line arrow below”.
A combined fragment is a logical grouping represented by a rectangle, which includes conditional structures that affect the message flow. It is used to define special conditions and subprocesses for any part of any lifeline by specifying conditions or application areas of subprocesses.
There are 13 types of combined fragments, which can be used to describe various control and logical structures in a compact and concise manner.
Sequence diagrams can be used at different stages of the development process to describe the interaction between objects in a system.
Analysis: In the analysis phase, sequence diagrams can help identify the classes needed by the system and the operations objects perform in interactions.
Design: In the design phase, sequence diagrams illustrate how the system works to complete interactions.
Construction: During the construction of the system architecture, sequence diagrams can be used to illustrate the behavior of design patterns and the mechanisms used by the system.
Sequence diagrams and collaboration diagrams are both UML interaction diagrams that can be converted into each other, have similar responsibilities, are message-driven, and have sequentiality.
However, there are also significant differences. Sequence diagrams express the chronological order of messages generated between objects, while collaboration diagrams express the cooperative relationships between objects.
There are generally three naming conventions for objects:
1) Show both object name and class name
2) Show only the object name, not the class name
3) Show only the class name, not the object name
All three naming conventions are standard; choose the one that is easiest for the reader to understand.
No. Sequence diagrams emphasize vertical time arrangement, with events occurring in order from top to bottom. Therefore, the "lines" + "arrows" of a subsequent message must be below the previous message, not above it.
Sometimes, we need to indicate that the interval between sending a message and returning a message must be less than a specified time. In this case, a special method can be used in the sequence diagram, such as {t2-t1<1s}.
No. Sequence diagrams are used to describe message interactions between objects, while behavior flows or operation paths should be expressed using flowcharts, activity diagrams, or state diagrams.
It is best not to place all interactions on a single diagram, as this can lead to a cluttered and difficult-to-read graphic. Complex interactions can be divided into multiple sub-diagrams, with each sequence diagram focusing on a single use case or functional scenario.
No. Synchronous messages indicate that a return result must be awaited (e.g., function calls), while asynchronous messages indicate that execution continues after sending (e.g., sending message queues). Mixing them can lead to concurrency logic errors.
Return messages help analyze whether interaction results are processed, especially in method calls and service responses, so return messages should be created when drawing sequence diagrams, with return values clearly specified.
ProcessOn is an online diagramming tool that supports online drawing of sequence diagrams and offers a large number of sequence diagram templates for cloning. It can perfectly replace Visio, and you're welcome to try it.