In my previous article, you learned about UML diagrams. In this article, we take a close look at the sequence diagram.
The examples provided below are based on the UML 2 specification. The UML 2.0 specification came out in 2005, but the most recent version is now UML 2.5.1 (which came out in 2017).
Explore the other articles in my UML Basics series, which covers the class diagram, the component diagram, and the sequence diagram.
As I reviewed this article in 2023, I realized that this article is so old that it references checks and physical cash. In 2023, I maybe write four checks a year and use physical cash every couple of months. However, I do still use money in digital form several days a week and I also use sequence diagrams several times a week. (I hope you enjoy this article and its cultural anachronisms.)
The diagram’s purpose
The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Much like the class diagram, developers typically think sequence diagrams were meant exclusively for them. However, an organization’s business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. Besides documenting an organization’s current affairs, a business-level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation. During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement. When that occurs, use cases are often refined into one or more sequence diagrams.
An organization’s technical staff can find sequence diagrams useful in documenting how a future system should behave. During the design phase, architects and developers can use the diagram to force out the system’s object interactions, thus fleshing out overall system design.
Deploy with confidence
Consistently deliver high-quality software faster using DevOps Continuous Delivery. Edit your code anywhere with Git repos and issue tracking, deliver continuously with an automated pipeline, get Insights to improve quality, and more.
One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement. Use cases are often refined into one or more sequence diagrams. In addition to their use in designing new systems, sequence diagrams can be used to document how objects in an existing (call it “legacy”) system currently interact. This documentation is very useful when transitioning a system to another person or organization.
The notation
Since this is the first article in my UML diagram series that is based on UML 2, we need to first discuss an addition to the notation in UML 2 diagrams, namely a notation element called a frame. The frame element is used as a basis for many other diagram elements in UML 2, but the first place most people will encounter a frame element is as the graphical boundary of a diagram. A frame element provides a consistent place for a diagram’s label, while providing a graphical boundary for the diagram. The frame element is optional in UML diagrams; as you can see in Figures 1 and 2, the diagram’s label is placed in the top left corner in what I’ll call the frame’s “namebox,” a sort of dog-eared rectangle, and the actual UML diagram is defined within the body of the larger enclosing rectangle.
In addition to providing a visual border, the frame element also has an important functional use in diagrams depicting interactions, such as the sequence diagram. On sequence diagrams incoming and outgoing messages (interactions) for a sequence can be modeled by connecting the messages to the border of the frame element (as seen in Figure 2). This will be covered in more detail in the “Beyond the basics” section below.
Notice that in Figure 2 the diagram’s label begins with the letters “sd,” for Sequence Diagram. When using a frame element to enclose a diagram, the diagram’s label needs to follow the format of:
Diagram Type Diagram NameShow more
The UML specification provides specific text values for diagram types (e.g., sd = Sequence Diagram, activity = Activity Diagram, and use case = Use Case Diagram).
The basics
The main purpose of a sequence diagram is to define event sequences that result in some desired outcome. The focus is less on messages themselves and more on the order in which messages occur; nevertheless, most sequence diagrams will communicate what messages are sent between a system’s objects as well as the order in which they occur. The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to.
Lifelines
When drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled. (Note: In fully modeled systems the objects (instances of classes) will also be modeled on a system’s class diagram.) Lifelines are drawn as a box with a dashed line descending from the center of the bottom edge (Figure 3). The lifeline’s name is placed inside the box.
