Archyno
UMLVerhaltensdiagramme

Aktivitätsdiagramm-Beispiele

Drei Aktivitätsdiagramme von Prozessen, die Sie kennen - eine CI-Pipeline, eine Ticket-Triage und ein Fragment, das zwei Token unterschiedlich beendet - jeweils mit der Begründung für jeden Knoten.

8 Min. LesezeitUML 2.5.114 von 35

[all green][any failed]Build artifactforkRun unit testsRun lintersScan dependenciesjoinNotify authorDeploy to staging
A CI pipeline: one fork, three concurrent actions, a join that waits for all of them, and a decision on the result.

01Example 1: parallel work behind a fork

A build pipeline is the clearest first example because the concurrency is real rather than notional. Unit tests, linting and a dependency scan genuinely run at once, nothing downstream can start until all three have finished, and everybody has watched it happen.

The two solid bars are doing the work. The upper one is a fork: one token arrives and three leave, so all three branches run. The lower one is a join: it waits until a token has arrived on every incoming edge before letting one continue. Swap either for a diamond and the diagram now claims something false - a diamond fires on the first token through and never waits.

Note the two separate final nodes. A failed build and a deployed build are different endings, and drawing them as two ringed discs is both legal and clearer than routing both back into one. UML puts no limit on how many activity final nodes an activity has.

02Example 2: a three-way branch with exhaustive guards

Most business processes are not concurrent. They are a decision with several outcomes that later come back together, which is the shape below.

[sev 1][else][sev 2 or 3]Receive ticketPage on-callAuto-reply and closeQueue for the teamRecord resolution

Three things in this diagram are deliberate. The guards are exhaustive: [sev 1], [sev 2 or 3] and [else] between them cover every ticket, so no token can arrive at the diamond and find nowhere to go. A token with no enabled outgoing edge is a stalled process, and it is a defect worth catching on paper.

The lower diamond is a merge, not a join, and the difference matters: only one of the three paths ever carries a token, so waiting for all three would deadlock immediately. The rule is easy to hold - a diamond opens what a diamond closes, and a bar closes what a bar opened.

Finally, every action is a verb phrase in the imperative: “Page on-call”, not “On-call paging”. Nouns creep in when somebody is describing a system rather than a process, and a diagram of nouns is a class diagram that has taken the wrong shape.

03Example 3: the two ways a flow can end

The pair of ending nodes is the detail most first diagrams get wrong, and the mistake is invisible: the diagram still looks right.

Crossed circle: this token stops.Ringed disc: the whole activity stops.forkWrite audit entryConfirm to customer

After the fork, two tokens are in flight. The audit branch reaches a flow final - the circle with a cross - which consumes that token and nothing else. The customer branch reaches an activity final, the ringed disc, which ends the whole activity and abandons every other token in it.

Put the ringed disc on the audit branch instead, and the diagram now says the order is abandoned as soon as the log line is written. Nothing about it looks wrong, which is exactly why the distinction is worth learning once: use a flow final for a side branch that simply finishes, and an activity final only where you mean “we are done”.

04Turning these into your own

These three cover the shapes almost every activity diagram is made of. What changes between them and yours is the labels; what should not change is the discipline about scope.

Reach for it when

  • One process per diagram, with a name you could put in an email subject line.
  • Verb-phrase actions, so each box is something somebody or something does.
  • Swimlanes when the handoffs between roles are the point - lane crossings are where processes fail.
  • A guard of [else] on the last edge out of every decision, so the set is exhaustive.

Reach for something else when

  • More than about fifteen actions. Extract a subtree as its own activity instead.
  • A bar where alternatives rejoin, or a diamond where concurrent work does.
  • Error handling for every step. Draw the happy path, then one diagram for the failure that matters.
  • Modelling a single object's lifecycle - that is a state machine, not an activity.

If the audience is business analysts rather than engineers, the same process is usually better drawn in BPMN, which has richer event semantics and is what a process engine will execute. The two notations answer the same question for different rooms.

05What to remember

In one line each

  1. 01A bar forks and joins; a diamond branches and merges. A diamond never waits, and a bar always does.
  2. 02Guards belong on edges out of a decision and never on edges out of a fork.
  3. 03Make the guard set exhaustive - [else] on the last edge - or the process can stall.
  4. 04A flow final ends one token; an activity final ends everything. The wrong one looks identical.
  5. 05Actions are verb phrases. If the boxes are nouns, you are drawing the wrong diagram.

06Häufige Fragen

Was ist ein gutes Beispiel für ein Aktivitätsdiagramm?

Am klarsten ist eine CI-Pipeline: Artefakt bauen, dann hinter einer Verzweigung Tests, Linter und Abhängigkeitsscan parallel laufen lassen, an der Zusammenführung auf alle drei warten und je nach Ergebnis verzweigen. Sie nutzt jede wichtige Knotenart in etwa zehn Kästen.

Wie zeichnet man parallele Schritte in einem Aktivitätsdiagramm?

Legen Sie einen breiten Balken - die Verzweigung - quer über den Fluss und führen Sie von ihm je eine Kante in jede nebenläufige Aktion. Schließen Sie die Gruppe mit einem zweiten Balken, der Zusammenführung, die auf jeder eingehenden Kante ein Token abwartet. An den Kanten einer Verzweigung stehen nie Wächter, denn alle werden genommen.

Was ist der Unterschied zwischen Flussende und Aktivitätsende?

Das Flussende, ein Kreis mit Kreuz, beendet nur das Token, das es erreicht, der Rest der Aktivität läuft weiter. Das Aktivitätsende, eine umringte Scheibe, beendet die gesamte Aktivität und verwirft alle anderen Token. Die umringte Scheibe an einem Nebenzweig tötet stillschweigend den Hauptfluss.

Müssen die Wächter an einer Entscheidung jeden Fall abdecken?

Ja. Gilt kein Wächter, hat das Token kein Ziel und die Aktivität bleibt stehen - ein echter Defekt, keine Formsache. Die sichere Gewohnheit ist, der letzten Kante den Wächter [else] zu geben, womit die Menge konstruktionsbedingt lückenlos ist.

Wie viele Aktionen gehören in ein Aktivitätsdiagramm?

Etwa fünfzehn, danach ist es nicht mehr lesbar. Darüber hinaus lagern Sie einen Teilbaum als eigene Aktivität aus und verweisen mit einer einzigen Aufrufaktion darauf. Ein Diagramm, das man heranzoomen muss, prüft niemand mehr gegen die Wirklichkeit.

Alle Artikel