Blue indicates advice or rules not dictated by UML itself, but borrowed from other practices and theories.
Italics are for examples.
The Sequence Diagram is one of the behavioral diagrams in UML, and it belongs to a broader category called interaction diagrams. As Captain Obvious would say, these diagrams focus on interactions between participants in a process — and the Sequence Diagram is no exception. It visualizes how objects exchange messages over time. Think of it as similar to an activity diagram, but with a focus on who talks to whom when, rather than the steps of a process. This makes the sequence diagram especially useful when you have a process involving many participants and need to show the order and flow of interactions.
Elements and Connections:
We’ll mix elements and connections here to highlight the diagram’s key features:
Lifeline — represents a participant in the interaction. It’s like a partition in an activity diagram. Drawn as a rectangle (the object/participant) with a dashed line (“lifeline”) extending downward, indicating its active lifespan in the process.
By UML standards, the name inside the rectangle would be: objectName : className
But since we’re business analysts, we usually don’t show object and class details — we simply name the participant directly.
If the participant is external to the system (like in use case diagrams), you can use an actor icon to show that. In our example of a pizzeria, the person ordering pizza is outside the system and is therefore modeled as an actor.
Message — the essential connection. It represents an interaction between participants. Philosophically, not all messages are literal — they could represent clicking a button, for example. Messages are arranged top-to-bottom based on their order in the process. Each message is labeled with the interaction’s nature or data being passed.
Execution: You’ll see “tubes” along lifelines where messages occur — these are Executions (Execution Specifications, Activations). Many just refer to them as activation bars.
These bars represent a time span during which a participant is actively doing something in the context of the process. Some modeling tools generate them automatically when you add messages to the diagram. You can label them to show what the participant is doing — though in practice, this is often skipped.
Still, reading them correctly helps: in our earlier example, the actor is “active” from the moment the order is submitted to when it's confirmed — logical, as they're engaged in placing the order. After that, they're inactive until the pizza is delivered.
More about messages:
1) Messages can be synchronous or asynchronous.
Synchronous message (solid arrowhead — all messages in the earlier diagram are like this) means the sender waits for a response before continuing. That is, the diagram should include a reply.
Asynchronous message (open arrowhead) means the sender does not wait for a response and proceeds immediately after sending.
2) Messages can be shown explicitly as responses to prior requests. Such reply messages are drawn as dashed arrows.
3) A message can indicate that it creates an object (e.g., a data object in an IT system). In that case, the message arrow points into the rectangle representing the newly created object (not its dashed lifeline). That object becomes a new participant (Lifeline) in the diagram. In an Activity Diagram, this would be done with Object or Pins. For clarity, it’s useful to add the stereotype «create».
4) A message can indicate that it destroys an object. In that case, we place an X mark at the end of the object's lifeline to show that it ceases to exist after receiving the message. The message itself isn’t styled differently, but again, for clarity, you can add «destroy».
5) Self-message: a message to oneself. This is a looped arrow returning to the sender. Formally, it indicates the object is invoking its own internal function, but for analysts (who don’t write code), this is usually used to emphasize key steps that the participant performs independently, without involving others.
Let’s add all that to the diagram:
What else?
Combined Fragment — this is an element used to show more complex process flows than simple sequential message exchanges. It’s shown as a rectangular region enclosing a “complicated” block of messages, with a keyword at the top indicating the fragment type.
Most useful fragments:
alt — shows alternatives (branches) in the process. It’s split into sections, each showing one possible path and its condition (in square brackets).
opt — shows optional interaction. Unlike alt (where one path out of several is followed), opt indicates that the entire fragment happens only if a certain condition is met.
There are other fragment types — loops, parallel flows, etc. We won’t cover them here as they are rarely used, but the formatting is similar to alt and opt.
Common Mistakes:
Overloading the reader.
You’ve probably already noticed: once we add fragments, object creation/destruction, and self-messages — the diagram becomes barely readable. You have to squint and focus, really working your brain. Keep that in mind. Any model is just that — a limited representation of what we’re modeling. Don’t try to show everything (data creation and deletion, all possible branches and steps). This is not an Activity Diagram, nor a Data Flow Diagram. A Sequence Diagram emphasizes the order, timing, and interaction between participants. If the diagram starts turning into a monster, consider showing some of that content in other diagrams more suitable for it.
Sequence Diagram vs Activity Diagram.
This is essentially a continuation of the previous point, but let’s call it out explicitly. At first glance, a Sequence Diagram may seem like just an Activity Diagram for multi-actor processes. It also shows process dynamics, but the focus (and this is key) is more on how participants interact, rather than on process steps. In an Activity Diagram, what stands out are the steps, branches, loops, and other algorithmic elements. In a Sequence Diagram, it’s the participants and the order and method of their interactions. Some business analysis gurus believe that Sequence Diagrams are more complex and confusing than Activity Diagrams — and dislike them for this reason (arguing that business stakeholders better understand Activity Diagrams). Still, it’s a useful tool to have in your arsenal. When you need to emphasize communication, a Sequence Diagram can illustrate it more clearly. Just make sure you understand what you're trying to show. For instance, illustrating a use case scenario — in my view — is not the best use of a Sequence Diagram. It’s a matter of taste, of course, but most use case discussions focus on steps, exceptions, and alternatives — not participant interaction. Unless you’re working close to a systems analyst, where system components are part of your requirements, this often isn’t necessary. And when a use case has only two participants — the actor and the system — you’ll end up showing all the steps as Self messages, and all exceptions/alternatives as Combined Fragments, which just clutters the diagram. That doesn’t really simplify communication.
Ignoring Response Messages.
Response messages (dashed arrows) are a widely accepted way to show that a certain interaction is a reply to a prior request. Many people experienced with such diagrams can quickly scan and identify responses this way — so don’t ignore the importance of thinking through message types and when/how to use different arrow styles.
Confusing Synchronous and Asynchronous Messages.
It’s not always critically important, but if you're using different arrowheads, make sure not to mix them up. Synchronous messages require a response. For instance, when a user clicks a link, they wait for the system to show a new page — they can’t continue in the process until they get the page or an error. On the other hand, when a user places an order, they usually don’t wait for an email confirmation that the order was created — they move on with the process of receiving the order. That’s asynchronous. If waiting for the email is necessary, then be deliberate about it and mark it as synchronous.