Archyno
UMLDiagrammes de comportement

Comment dessiner un diagramme de séquence UML

Un scénario, les participants qu'il touche réellement, le chemin nominal dans l'ordre, puis les branches - et un arrêt net à un écran.

7 min de lectureUML 2.5.18 sur 28

Guest«boundary»Booking site«control»Availability«entity»Reservationsrequest(dates, roomType)isFree(dates, roomType)truereserve(dates, guest)reservationIdconfirmation
After step three. One scenario, straight through - and already the ordering is settled.

01Steps one and two: one scenario, then its participants

Write the scenario as a sentence before drawing anything. "A guest books a room that is available" is a scenario. "Booking" is not - it is a use case, which covers every run including the ones that fail, and a diagram that tries to be all of them is the diagram that ends up eighty messages long. If your sentence contains the word "or", you have two scenarios or one alt fragment, and you should decide which before continuing.

Then list the participants that scenario actually touches, and place them left to right in the order it reaches them. The actor goes leftmost. Four or five is the working range; if you have seven, at least two of them are implementation details that the flow does not reason about, and deleting them will not lose anything a reader needed.

02Step three: the happy path, in order, and nothing else

Draw the run where everything works, top to bottom, with no fragments at all. That is the diagram in the hero above, and it is finished as a piece of work even though it is not finished as a diagram - the ordering is settled, which is the expensive part.

Two conventions carry most of the meaning. A message label is an operation with its arguments, not a description: isFree(dates, roomType) tells a reader what the receiver must offer, where "checks availability" tells them a story they already knew. And every reply is dashed - a solid arrow coming back is a second call, and it means something different.

Activation bars are optional in UML 2.5.1 and worth drawing. They are the only thing on the diagram that shows a synchronous call is blocking its caller for the whole nested exchange beneath it, which is usually the fact the diagram was drawn to establish.

03Steps four and five: the branches, and stopping

Guest«boundary»Booking site«control»Availability«entity»Reservationsrequest(dates, roomType)isFree(dates, roomType)verdictreserve(dates, guest)reservationIdconfirmationalternatives(dates)nearbyDatesoffer alternativesaltroom freeno room
The same flow after step four. The alt is wrapped around the point where the answer starts to matter.

Only now add the fragments, and add them one at a time, asking of each: does this branch change what the reader must build? A branch that returns an error and stops rarely does, and is better recorded in the use case text. A branch that does other work - like offering alternative dates above - always does, and belongs on the diagram.

Wrap the frame around the point where the paths diverge, not around the whole diagram. The alt above starts after the availability verdict comes back, because everything before that is common to both outcomes; a frame around all nine messages would be technically legal and would tell the reader nothing about where the decision is.

Then stop at one screen. This is not a soft guideline: a sequence diagram exists to make an order visible at a glance, and a diagram that has to be scrolled has given that up while keeping all of the cost. When a flow will not fit, split it at a natural seam, give each half a name, and reference the second from the first with a ref fragment - or draw an interaction overview diagram above the set.

In one line each

  1. 01Write the scenario as a sentence first. If it contains 'or', decide between two diagrams and one alt.
  2. 02Participants go left to right in the order the flow reaches them, actor first.
  3. 03Draw the happy path with no fragments. Labels are operations with arguments; every reply is dashed.
  4. 04Add a branch only if it changes what gets built, and wrap the frame at the point paths diverge.
  5. 05One screen. Past that, split and use a ref fragment.

Three finished flows to copy from: the worked examples.

04Questions fréquentes

Par où commencer un diagramme de séquence ?

Par un scénario écrit sous forme de phrase, pas par les cases. Un diagramme de séquence décrit un seul déroulement, donc si vous ne savez pas dire lequel en une phrase, vous n'avez pas encore de diagramme : vous avez un cas d'utilisation, et c'est une autre image.

Dans quel ordre placer les participants ?

De gauche à droite dans l'ordre où le flux les touche pour la première fois, l'acteur tout à gauche. Toute autre disposition garantit des flèches qui se croisent, et ici ce n'est pas une question de style : cela rend l'ordre de lecture réellement ambigu.

Quelle longueur pour un diagramme de séquence ?

Un écran, soit une quinzaine de messages. Au-delà, le diagramme n'est plus lu de haut en bas mais fait défiler, et l'ordre qui était toute la raison de le tracer cesse d'être visible. Découpez-le et renvoyez à la seconde moitié par un fragment ref.

Tous les articles