Aktivitätsdiagramm-Beispiele

Eine Build-Pipeline ist das klarste erste Beispiel, weil die Nebenläufigkeit echt ist und nicht bloß gedacht. Unit-Tests, Linting und ein Abhängigkeitsscan laufen wirklich gleichzeitig, nichts stromabwärts kann starten, bevor alle drei fertig sind, und jeder hat das schon zugesehen.

Die Arbeit leisten die beiden durchgezogenen Balken. Der obere ist eine Gabelung: ein Token kommt an und drei gehen hinaus, also laufen alle drei Zweige. Der untere ist eine Vereinigung: sie wartet, bis auf jeder eingehenden Kante ein Token angekommen ist, bevor sie eines weiterlässt. Tauschen Sie eines gegen eine Raute, und das Diagramm behauptet etwas Falsches - eine Raute feuert beim ersten Token und wartet nie.

Beachten Sie die zwei getrennten Endknoten. Ein fehlgeschlagener und ein deployter Build sind verschiedene Enden, und sie als zwei umringte Scheiben zu zeichnen ist legal und klarer, als beide in einen zurückzuführen. UML setzt keine Grenze, wie viele Aktivitätsendknoten eine Aktivität hat.

Die meisten Geschäftsprozesse sind nicht nebenläufig. Sie sind eine Entscheidung mit mehreren Ausgängen, die später wieder zusammenkommen, und das ist die Form unten.

Drei Dinge in diesem Diagramm sind Absicht. Die Wächter sind erschöpfend: [sev 1], [sev 2 or 3] und [else] decken zusammen jedes Ticket ab, also kann kein Token an der Raute ankommen und nirgends hinkönnen. Ein Token ohne freigeschaltete ausgehende Kante ist ein stehengebliebener Prozess, und das ist ein Mangel, den man auf Papier abfangen sollte.

Die untere Raute ist eine Zusammenführung, keine Vereinigung, und der Unterschied zählt: nur einer der drei Pfade trägt je ein Token, auf alle drei zu warten würde also sofort verklemmen. Die Regel ist leicht zu merken - eine Raute schließt, was eine Raute geöffnet hat, und ein Balken schließt, was ein Balken geöffnet hat.

Schließlich ist jede Aktion eine Verbphrase im Imperativ: „Bereitschaft alarmieren“, nicht „Bereitschaftsalarmierung“. Substantive schleichen sich ein, wenn jemand ein System statt eines Prozesses beschreibt, und ein Diagramm aus Substantiven ist ein Klassendiagramm, das die falsche Form angenommen hat.

Das Paar Endknoten ist das Detail, das die meisten ersten Diagramme falsch machen, und der Fehler ist unsichtbar: das Diagramm sieht weiterhin richtig aus.

Nach der Gabelung sind zwei Token unterwegs. Der Audit-Zweig erreicht ein Flussende - den Kreis mit dem Kreuz -, das dieses Token verbraucht und sonst nichts. Der Kundenzweig erreicht ein Aktivitätsende, die umringte Scheibe, die die ganze Aktivität beendet und jedes andere Token darin verwirft.

Setzen Sie die umringte Scheibe stattdessen auf den Audit-Zweig, und das Diagramm sagt nun, dass die Bestellung abgebrochen wird, sobald die Logzeile geschrieben ist. Nichts daran sieht falsch aus, und genau deshalb lohnt es sich, den Unterschied einmal zu lernen: ein Flussende für einen Nebenzweig, der einfach fertig wird, und ein Aktivitätsende nur dort, wo Sie „wir sind fertig“ meinen.

Diese drei decken die Formen ab, aus denen fast jedes Aktivitätsdiagramm besteht. Was sich zwischen ihnen und Ihrem ändert, sind die Beschriftungen; was sich nicht ändern sollte, ist die Disziplin beim Umfang.

Ist das Publikum fachlich statt technisch, wird derselbe Prozess meist besser in BPMN gezeichnet, das reichere Ereignissemantik hat und das ist, was eine Prozess-Engine ausführt. Die beiden Notationen beantworten dieselbe Frage für verschiedene Räume.