Ein UML-Sequenzdiagramm zeichnen
Ein Szenario, die Teilnehmer, die es wirklich berührt, der Gutfall der Reihe nach, dann die Verzweigungen - und ein harter Schnitt nach einem Bildschirm.
7 Min. LesezeitUML 2.5.18 von 28
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
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
- 01Write the scenario as a sentence first. If it contains 'or', decide between two diagrams and one alt.
- 02Participants go left to right in the order the flow reaches them, actor first.
- 03Draw the happy path with no fragments. Labels are operations with arguments; every reply is dashed.
- 04Add a branch only if it changes what gets built, and wrap the frame at the point paths diverge.
- 05One screen. Past that, split and use a ref fragment.
Three finished flows to copy from: the worked examples.
04Häufige Fragen
Womit beginnt man ein Sequenzdiagramm?
Mit einem Szenario, als Satz geschrieben, nicht mit den Kästen. Ein Sequenzdiagramm beschreibt einen einzelnen Durchlauf, und wer nicht in einem Satz sagen kann welchen, hat noch kein Diagramm - sondern einen Anwendungsfall, und das ist ein anderes Bild.
In welcher Reihenfolge stehen die Teilnehmer?
Von links nach rechts in der Reihenfolge, in der der Ablauf sie zuerst berührt, mit dem Akteur ganz links. Alles andere garantiert kreuzende Pfeile, und kreuzende Pfeile sind hier kein Stilproblem: sie machen die Lesereihenfolge tatsächlich mehrdeutig.
Wie lang darf ein Sequenzdiagramm sein?
Ein Bildschirm, also etwa fünfzehn Nachrichten. Darüber wird das Diagramm nicht mehr von oben nach unten gelesen, sondern gescrollt, und die Reihenfolge, für die man es überhaupt gezeichnet hat, ist nicht mehr sichtbar. Teilen Sie es und verweisen Sie per ref-Fragment auf die zweite Hälfte.
Passend dazu