Archyno
UMLDiagrammes de comportement

Exemples de diagrammes de séquence UML

Trois flux, chacun ayant besoin de ce que les autres n'utilisent pas : une connexion qui se branche, un paiement qui réessaie, et un événement auquel personne ne répond.

6 min de lectureUML 2.5.17 sur 28

User«boundary»Login page«control»Identity service«entity»Attempt logsubmit(email, password)authenticate(email, password)tokenredirect to dashboardrecord(failure)AuthErrorshow erroraltcredentials validrejected
A login. The alt fragment carries both outcomes, and the failure branch does work of its own.

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

«control»Checkout«boundary»Payment gateway«entity»Order storecharge(amount)503 transientbackoff()charge(amount)authorizedmarkPaid(orderId)loop3 times, while transient
A retry. The failing reply is inside the loop, because it is the reason the loop exists.

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

«control»Order service«boundary»Event broker«control»Warehouse«control»Email servicepublish(OrderPlaced)OrderPlacedOrderPlaced
A publication. Three open arrowheads, no replies, and no claim about who runs first.

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

  1. 01An alt fragment carries every outcome; if only one branch has a guard, you meant opt.
  2. 02Give a loop both a bound and a condition, and keep the failing reply inside it.
  3. 03Open arrowhead plus no reply means asynchronous. Do not draw a return that did not happen.
  4. 04Draw a self-call when the delay or decision is part of the story, not for ordinary internal work.
  5. 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.

04Questions fréquentes

Quel est un bon exemple de diagramme de séquence UML ?

La connexion est l'exemple classique parce qu'elle se branche, et le branchement est précisément ce qu'un diagramme de séquence sait faire et pas une liste numérotée. Ensuite, une boucle de reprise et une publication asynchrone valent le détour : ensemble, elles couvrent les trois formes dont presque tout flux réel est fait.

Comment montrer une reprise dans un diagramme de séquence ?

Par un fragment loop autour des messages répétés, avec une garde nommant le nombre et la condition, par exemple trois fois, tant que l'erreur est transitoire. Tracez aussi la réponse en échec dans la boucle : une boucle contenant seulement la requête cache la raison de la reprise.

Comment dessine-t-on un message asynchrone ?

Par un trait plein terminé par une pointe ouverte, et non par la pointe pleine d'un appel synchrone, et sans flèche de retour ensuite. L'absence de réponse est le propos : l'émetteur n'a pas attendu, et une flèche de retour en pointillés affirmerait le contraire.

Tous les articles