Príklady UML sekvenčných diagramov

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.

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.

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.

For the method rather than the examples, read how to draw a sequence diagram; for the full notation, the sequence diagram article.