UML-Aktivitätsdiagramm

Das UML-Aktivitätsdiagramm modelliert, wie ein Arbeitsablauf innerhalb eines einzigen Systems verläuft: die Folge der Aktionen, die Entscheidungen, die sie lenken, die Zweige, die parallel laufen, und die Objekte, die hindurchwandern. Es gehört zum UML-Modell, wo es einen Anwendungsfall realisiert, und es beruht auf einer Token-Semantik: Jeder Knoten bietet ein Token an und nimmt es entlang der Kanten wieder auf. Drei Merkmale trennen es von einem Flussdiagramm, dem es ähnelt: Wächter stehen in eckigen Klammern an den Kanten, Gabelungs- und Vereinigungsbalken drücken echte Nebenläufigkeit aus, und ein Objektfluss folgt dem Kontrollfluss. Man liest es auf drei Abstraktionsebenen, von der Unternehmenssicht bis zur Systemsicht, und sein Wert verdichtet sich auf den unteren Ebenen, wo ein Modell präzise genug wird, um simuliert oder ausgeführt zu werden.

Zweck

Das Diagramm spezifiziert formal, wie ein Anwendungsfall innerhalb eines Systems abläuft: die Reihenfolge der Aktionen, die Bedingungen, die den Fluss lenken, die gleichzeitigen Arbeitsschritte, die sich wieder synchronisieren müssen, und die Objekte, die von einer Aktion zur nächsten übergehen. Es ist ein Modellartefakt, an einen Anwendungsfall im UML-Modell angehängt und auf das umgebende Klassenmodell zurückverfolgt. Seine Token-Semantik macht es bis ins ausführbare Detail nutzbar, und sie ist zugleich das, was es von einem Flussdiagramm gleicher Erscheinung abhebt.

Einsatz

Wann einzusetzen

Realisierung eines Anwendungsfalls: das interne Verhalten zeigen, das den Anwendungsfall einlöst.
Echte Nebenläufigkeit in der Logik: zwei gleichzeitige Arbeitsschritte, die sich wieder synchronisieren müssen, getragen von einem Gabelungsbalken.
Lenkung über Wächterbedingungen: die vorgelagert getroffene Bedingung steht in eckigen Klammern an der Kante.
In das UML-Modell eingebettetes Artefakt: die Logik verweist auf den Anwendungsfall und das umgebende Klassenmodell.

Wann nicht einzusetzen

Ein nichttechnisches Publikum ist auf den Prozess einzustimmen: die Formalität bringt in diesem Fall nichts, das Flussdiagramm wählen.
Unabhängige Beteiligte tauschen Nachrichten über eine Organisationsgrenze hinweg aus: das ist eine Kollaboration, BPMN wählen.
Die Frage ist, was eine Funktion steuert und ausführt: IDEF / IGOE wählen.

Beschreibung

Ein Kontroll- und Objektfluss innerhalb eines einzigen Systems

Das Diagramm ist ein Graph aus Knoten, die durch Kanten verbunden sind, angetrieben von einer Token-Semantik: Ein Knoten bietet ein Token an, der nächste nimmt es auf, und es ist dieser Umlauf, der den Sinn trägt. Der Fluss beginnt an einem Startknoten, durchläuft Aktionen und endet an einem Aktivitätsendknoten; Entscheidungen sind hohle Rauten, die Gabelungs- und Vereinigungsbalken dicke Striche, und ein Objektknoten zeigt ein Objekt, das von einer Aktion zur nächsten übergeht. Es ist eine der Notationen der Prozessmodellierung, jene, die im Modell eines Systems lebt.

Zwei Eigenschaften trennen es von einem Flussdiagramm, das es nachahmt. Der Wächter entscheidet, die Raute lenkt nur: die Bedingung, in eckigen Klammern an der Kante notiert, lenkt den Fluss auf den Zweig, auf den sie zutrifft. Und der Gabelungsbalken drückt echte Nebenläufigkeit aus, zwei Zweige, die gleichzeitig laufen und sich an der Vereinigung wieder treffen, wo ein Flussdiagramm nur zwei Abläufe nebeneinanderstellen kann. Hinzu kommen der Objektfluss und die Zugehörigkeit zum UML-Modell, in dem das Diagramm einen Anwendungsfall realisiert. Partitionen oder Swimlanes benennen, wer eine Aktion ausführt, unterscheiden aber die Notation nicht: Das Flussdiagramm, BPMN und das Aktivitätsdiagramm nehmen sie alle auf.

Die drei Ebenen

Ein Prozessmodell entsteht auf drei Abstraktionsebenen, und sein Wert unterscheidet sich von Ebene zu Ebene. Auf der hohen Ebene, der Unternehmens- oder Kontextebene, vermittelt das Modell ein allgemeines Verständnis des Prozesses und seiner Bezüge zu benachbarten Prozessen; die formale Semantik nützt dort nichts, und eine Prozesslandkarte oder ein Flussdiagramm passen besser. Auf der operativen Ebene führt das Modell die Aktivitäten aus und benennt alle Ausgänge, Ausnahmen und Alternativpfade eingeschlossen: Hier gewinnt das Diagramm seinen Platz, indem bewachte Entscheidungen die Ausnahmen lenken und ein Gabelungsbalken die tatsächlich parallel laufenden Zweige zeigt. Auf der Systemebene, der untersten, wird das Modell präzise genug, um als Grundlage für eine Simulation oder Ausführung zu dienen, und die Token-Semantik ist genau das, was diese Ebene erreichbar macht.

Das Aktivitätsdiagramm ist somit ein Artefakt der operativen und der Systemebene: Es arbeitet einen gewählten Entwurf aus und treibt ihn bis ins ausführbare Detail, ohne den Unternehmenskontext zu rahmen.

KI-Überlegungen

Zwei Anwendungen tragen. Der erste Entwurf: Aus der schriftlichen Beschreibung eines Anwendungsfalls schlägt ein Sprachmodell einen Graphen aus Aktionen, Entscheidungen und Enden vor, den die Analystin korrigiert. Und die Formprüfung, mechanisch, lässt sich gut delegieren: Hat jede Gabelung ihre Vereinigung, trägt jede Entscheidung Wächter an ihren Ausgängen, bleibt eine Aktion ohne eingehende Kante?

Was sich nicht delegieren lässt, liegt im Sinn. Zu entscheiden, dass zwei Zweige wirklich nebenläufig sind, verlangt Kenntnis davon, wie die Arbeit ausgeführt wird. Und die Frage, die allem vorausgeht, ein einziges System oder Beteiligte, die Nachrichten austauschen, entscheidet zwischen diesem Diagramm und BPMN: Sie wird im Feld beantwortet.

Mehr Details finden Sie in unserem BPMN-Tutorial.

Beispiele

Die Validierung einer Bestellung bei einem Schweizer Online-Händler, innerhalb seiner eigenen Systeme. Der Begriff, den die Zeichnung sichtbar macht, ist die echte Nebenläufigkeit: Bei einer vorrätigen Bestellung starten zwei Arbeitsschritte gleichzeitig und müssen sich vor der Bestätigung wieder treffen.

Die Validierung einer Bestellung bei einem Schweizer Online-Händler, als UML-Aktivitätsdiagramm gezeichnet: bei [vorrätig] gabelt sich der Fluss, um den Bestand zu reservieren und die Zahlung einzuziehen, parallel; danach vereinigen sich die beiden Zweige, bevor die Bestellung bestätigt wird; bei [nicht vorrätig] wird die Bestellung abgelehnt. Der dicke Balken markiert die echte Nebenläufigkeit, die Zielscheibe markiert das Aktivitätsende.

Die Bestellung, ein Objektknoten mit einem Gesamtbetrag von CHF 1'250, wandert von einer Aktion zur nächsten. Das Reservieren des Bestands und das Einziehen der Zahlung müssen nicht aufeinander warten, wo ein Flussdiagramm sie nur in eine Reihenfolge bringen könnte.

Ein einziger Punkt entscheidet, dass diese Zeichnung ein Aktivitätsdiagramm ist: Die Zahlung wird im System des Händlers verarbeitet. Tauschte der Zahlungsdienstleister Nachrichten über eine Organisationsgrenze hinweg aus, müsste daraus BPMN werden, mit zwei Pools und einem Nachrichtenfluss.

Visualisierungen

Die Geometrie ist der Inhalt. Die Rolle einer Kante liest man an ihrer Form: Ein Wächter in eckigen Klammern nennt die lenkende Bedingung, ein dicker Balken behauptet eine Nebenläufigkeit, die ein einfacher Strich nicht tragen könnte, eine Zielscheibe markiert das Aktivitätsende und eine offene Pfeilspitze kennzeichnet den Kontrollfluss.

Aufwand

Phase	Stufe	Begründung
Vorbereitung	Mittel	Der Anwendungsfall und der gewählte Entwurf müssen vor dem Zeichnen bestehen: Das ist die Substanz der Zeichnung.
Durchführung	Niedrig	Ein Anwendungsfall passt in ein Diagramm, in einer einzigen Sitzung gezeichnet. Der Aufwand steigt mit der Zahl der bewachten Zweige und der nebenläufigen Arbeitsschritte; die Grösse des Systems ändert daran nichts.
Dokumentation	Mittel	Das Diagramm lebt im UML-Modell und wird aktualisiert, wenn sich der Anwendungsfall oder das Klassenmodell ändert. Sein Wert beruht auf dieser gepflegten Konsistenz.

Werkzeuge

Ein Whiteboard genügt für einen ersten Entwurf: Ein Fluss aus Aktionen und zwei bewachte Zweige passen auf ein einziges Blatt. Allgemeine Zeichenwerkzeuge, diagrams.net, Lucidchart oder Visio, führen korrekte Schablonen, aber ihr Beitrag endet bei der Zeichnung, und die Verbindung zum Anwendungsfall überlebt dann nur im Kopf der Autorin. UML-Modellierungswerkzeuge, Enterprise Architect, Visual Paradigm oder Modelio, halten das Diagramm als Objekt des Modells: Es verweist auf den Anwendungsfall, den es realisiert, und auf die Klassen, die es bearbeitet, und das Werkzeug meldet eine Gabelung ohne Vereinigung oder eine Entscheidung ohne Wächter.

Quellen

OMG, Unified Modeling Language (UML), Version 2.5.1, die Activities-Klausel: die Token-Semantik, die Kontrollknoten (Startknoten, Entscheidung und Zusammenführung, Gabelung und Vereinigung, Aktivitätsende), die Wächter, der Objektfluss und die Partitionen.
IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: das Aktivitätsdiagramm unter den Notationen der Prozessmodellierung und die drei Ebenen eines Prozessmodells.
ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.5 UML: das Aktivitätsdiagramm als sekundäre Verwendung für die Geschäftsprozessmodellierung, im Bereich der Informationstechnologie.
ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.2 Swim Lanes: Swimlanes sind eine notationelle Ergänzung.