UML sequence diagram examples
Three flows, each needing something the others do not: a login that branches, a payment that retries, and an event that is never answered.
6 min readUML 2.5.17 of 28
01A login, where the branch is the point
Read the diagram above as two stories sharing a beginning. Everything above the alt frame happens either way; inside it, exactly one compartment runs, and the guards in square brackets say which. That is the thing a sequence diagram does that a numbered list of steps cannot, and it is why this flow is the standard first example.
The detail worth copying is in the failure branch. It does not simply return an error: it fires record(failure) at the attempt log first, drawn with an open arrowhead because nothing waits for it. A diagram whose failure path is one arrow labelled "error" is a diagram that has not thought about the failure path, and the throttling requirement everybody discovers three weeks later is exactly what lives in that branch.
02A payment, where the loop and the self-call are the point
Two things here do not appear on a first sequence diagram. The loop fragment's guard names both a bound and a condition - [3 times, while transient] - because a loop with no bound is a diagram promising an outage, and one with no condition does not say what stops it early.
The other is backoff(), a message from Checkout to itself, drawn as an arrow that leaves a lifeline and returns to it. Self-calls are worth drawing exactly when the delay or the decision is part of the story - here it is the whole reason the second attempt succeeds - and worth omitting when they are ordinary internal work.
Note also what is not here: no dashed reply after markPaid(orderId). The order store answers, of course, but the answer carries nothing this flow reasons about, and drawing every reply is how a diagram of six interesting messages becomes a diagram of twelve.
03An event, where nothing is answered
This is the example almost nobody draws, and the one most worth having. Every arrow is asynchronous - solid line, open head - and there is not a single dashed return. The order service publishes and moves on; the warehouse and the email service each receive the event, and nothing on this diagram says which of them finishes first, because nothing in the system does either.
Drawing this flow with filled arrowheads and replies would be a different system: one where publishing blocks until both consumers have run, which is precisely the property a broker exists to remove. The notation distinguishes them, and the distinction is worth more here than anywhere else in UML.
In one line each
- 01An alt fragment carries every outcome; if only one branch has a guard, you meant opt.
- 02Give a loop both a bound and a condition, and keep the failing reply inside it.
- 03Open arrowhead plus no reply means asynchronous. Do not draw a return that did not happen.
- 04Draw a self-call when the delay or decision is part of the story, not for ordinary internal work.
- 05Omit replies that carry nothing the flow reasons about.
For the method rather than the examples, read how to draw a sequence diagram; for the full notation, the sequence diagram article.
04Common questions
What is a good example of a UML sequence diagram?
A login is the standard one because it branches, and branching is the thing a sequence diagram does that a numbered list cannot. Beyond that, a retry loop and an asynchronous publication are worth drawing, because between them they cover the three shapes almost every real flow is made of.
How do I show a retry in a sequence diagram?
With a loop fragment around the messages that repeat, and a guard naming both the count and the condition, such as three times, while transient. Draw the failing reply inside the loop as well - a loop that contains only the request hides the reason the retry happens.
How do you draw an asynchronous message?
As a solid line with an open arrowhead, rather than the filled head a synchronous call carries, and with no reply arrow after it. The absence of a reply is the point: the sender did not wait, and drawing a dashed return would claim it did.
Related reading