Was ist ein Aktivitätsdiagramm?

Wissen kompakt: Ein Aktivitätsdiagramm visualisiert die zeitliche Abfolge von Aktivitäten und Aktionen in Geschäftsprozessen, Workflows, Anwendungsfällen oder Algorithmen.

Aktivitätsdiagramm Definition

Ein Aktivitätsdiagramm ist ein Ausdrucksmittel der Unified Modeling Language (UML), mit dem zeitliche Abläufe innerhalb eines Systems beschrieben werden. Gemeinsam mit dem Anwendungsfall- und Zustandsdiagramm gehört es zu der Gruppe der sogenannten Verhaltensdiagramme. In einem Verhaltensdiagramm werden einzelne Aspekte eines Systems und deren Veränderungen zur Laufzeit visualisiert.1

Das Aktivitätsdiagramm – im Englischen: activity diagram – wird zur Modellierung von Abläufen genutzt, wie sie bspw. in Geschäftsprozessen, Workflows, Anwendungsfällen oder Algorithmen vorkommen. Mit ihm ist es möglich, komplizierte Abläufe mit Varianten, parallelen Flüssen oder Wiederholungen übersichtlich darzustellen. Im Vergleich zu textuellen, oft in natürlicher Sprache verfassten Beschreibungen, lässt es sich meist leichter nachvollziehen. 

Aktivitätsdiagramm - am Beispiel mit einer Build-Pipeline

Wesentliche Elemente im Aktivitätsdiagramm

Für das Verständnis von Aktivitätsdiagrammen ist die Unterscheidung von verschiedenen Begriffen wichtig:

Aktivitäten und Aktionen

Eine Aktivität (activity) beschreibt die Ablaufreihenfolge von Aktionen und kann Eingabe- und Ausgabeparameter als Vor- bzw. Nachbedingungen besitzen, die bei Beginn oder Beendigung der Aktivität gelten müssen. Sie wird als abgerundetes Rechteck dargestellt.

Eine Aktion (action) ist ein atomarer Bestandteil einer Aktivität. Sie lässt sich wiederholt ausführen und kann andere Aktionen oder Aktivitäten aufrufen. Die Summe der Aktionen determiniert das Verhalten einer Aktivität. Die UML kategorisiert 44 Arten von Aktionen, bspw.

  • kommunikationsbezogene Aktionen für Signale und Ereignisse,
  • objektbezogene Aktionen zum Erzeugen und Löschen von Objekten,
  • variablenbezogene Aktionen wie das Setzen oder Löschen einzelner Werte von Variablen, oder
  • linkbezogene Aktionen zur Navigation oder zum Erzeugen oder Löschen von Links zwischen Objekten.

Dargestellt werden Aktionen mit abgerundeten Rechtecken innerhalb einer Aktivität.

Knoten und Kanten

In der UML 2.5 Spezifikation der Object Management Group (OMG) tauchen die Begriffe Knoten und Kanten 1.986 Mal bzw. 786 Mal auf.2 Kanten sind die Verbindungslinien zwischen Knoten, Knoten sind die Punkte, an denen „etwas“ passiert.

Unterschieden werden drei Arten von Knoten:

  1. Aktivitätsknoten (activity nodes),
  2. Steuerungsknoten (control nodes) und
  3. Objektknoten (object nodes).

Aktivitätsknoten repräsentieren sowohl Aktionen, die Eingaben empfangen und diese zu Ausgaben für andere Knoten verarbeiten, oder andere Aktivitäten aufrufen, als auch Gruppen von Aktionen.

Steuerungsknoten steuern den Ablauf einer Aktivität inklusive der Spezifikation von alternativen Flüssen durch Verzweigungen bzw. Vereinigungen. Zu den Steuerungsknoten zählen

  • der Startknoten (initial node) – auch Anfangsknoten genannt – als initialer Ausgangspunkt für einen Ablauf. Sind mehrere Startknoten vorhanden, werden Aktivitäten parallel begonnen, fehlt der Startknoten, dann beginnen alle Aktivitäten parallel, die keine eingehenden Kanten haben. Dargestellt wird der Startknoten mit einem schwarzen Kreis.
  • die Entscheidungsknoten (decision node), die explizite Entscheidungsoptionen – meist geknüpft an Bedingungen – für alternative Abläufe anbieten. Implizite Entscheidungen liegen vor, wenn alternative Abläufe ohne Verwendung eines Entscheidungsknoten dargestellt werden; da dies zu fehlerhaften Interpretationen führen kann, sollte auch implizite Entscheidungen verzichtet werden. Entscheidungsknoten werden als Rauten dargestellt.
  • die Gabelung (fork node) als Punkt in einer Aktivität, der einen Fluss in mehrere parallele bzw. nebenläufige Flüsse unterteilt. Dies wird auch Splitting genannt. Die Gabelung wird als Balken mit einer eingehenden und mehreren ausgehenden Kanten dargestellt.
  • die Vereinigung (join node) als Punkt in einer Aktivität, an dem mehrere Flüsse zu einem gemeinsamen Fluss synchronisiert werden; entsprechend wir von Synchronisation gesprochen. Die Vereinigung wird als Balken mit mehreren eingehenden und einer ausgehenden Kante dargestellt.
  • die Zusammenführung (merge node) als Punkt in einer Aktivität, an dem mehrere Kanten zu einer gemeinsamen Kante ohne Synchronisation zusammengeführt werden. Die Zusammenführung wird beim Definieren von Schleifen benutzt.
  • das Flussende (flow final), das den Fluss in einer Aktivität beendet, jedoch ohne dabei auf andere Flüsse der Aktivität Einfluss zu nehmen. Das Flussende wird mit einem durchgekreuzten Kreis dargestellt.
  • der Endknoten bzw. das Aktivitätsende (activity final) zur unmittelbaren Beendigung aller Flüsse in einer Aktivität, auch dann, wenn Aktivitäten mehrere Endknoten besitzen. Dargestellt wird der Endknoten mit einem schwarzen Kreis mit weißem Rand.

Objektknoten bilden das Gerüst, um Daten und Werte innerhalb einer Aktivität während eines Ablaufs zu transportieren; ihre Spezifikation definiert den Fluss der Objekte. Zu den Objektknoten gehören

  • Aktivitätsparameterknoten (activity parameter nodes) zur Übergabe von Parametern beim Aufruf von Aktionen. Unterschieden werden Eingabeparameter bzw. Eingabe-Pins (input pins) und Ausgabeparameter bzw. Ausgabe-Pins (output pins). Ein „besonderer“ Eingabeparameter ist der Werte-Pin (value pin), der eine Aktion aktiviert, sofern die Auswertung einer Werte-Spezifikation (value specification) einen definierten Wert liefert.
  • zentrale Pufferknoten (central buffer nodes), die als Puffer zwischen eingehenden und ausgehenden Kanten fungieren, und Daten aus verschiedenen Quellen konsolidieren, ohne jedoch in direkter Verbindung zu Aktionen zu stehen. Die persistente Speicherung von Daten erfolgt in Datenspeicherknoten (data store nodes).
  • Erweiterungsknoten (expansion nodes), die verwendet werden, um einen Sammlungseingang oder -ausgang für eine Erweiterungsregion (expansion region) anzugeben. Ein Sammlungseingang (collection input) einer Erweiterungsregion enthält eine Sammlung, die innerhalb der Region in ihre einzelnen Elemente zerlegt und deren Inhalt pro Element einmal ausgeführt wird. Ein Sammlungsausgang (collection output) fasst einzelne Elemente, die durch die Ausführung der Region erzeugt werden, zu einer Sammlung zur Verwendung außerhalb der Region zusammen.

Bei den Kanten lassen sich zwei Ausprägungen unterscheiden:

  1. Kontrollflüsse bzw. Kontrollfluss-Kanten und
  2. Objektflüsse bzw. Objektfluss-Kanten.

Während ein Kontrollfluss Aktionen und Aktivitäten verbindet und eine Abhängigkeit zwischen Vorgänger- und Nachfolgerknoten ausdrückt, übermittelt ein Objektfluss zusätzlich Daten zwischen den Konten. Optisch werden beide Ausprägungen mit einer durchgezogenen Linie mit offener Pfeilspitze dargestellt, wobei die Objektflüsse zwischen den Objekt-Pins oder den Aktivitätsknoten gezogen werden (erkennbar an kleinen Rechtecken an einer Aktion oder Aktivität).

Sowohl Kontrollflüsse als auch Objektflüsse lassen sich mit dem Pufferknoten aufteilen; bspw. können Daten in einem Warenkorb per central buffer node zwischengespeichert und zu einem späteren Zeitpunkt wieder abgerufen werden. Wird der Prozess vor dem Abruf beendet, werden die entsprechend zwischengespeicherten Daten gelöscht. Bei der Verwendung des data store nodes würden die Daten auch bei Beendigung des Prozesses erhalten bleiben.

Partitionen und Token

Zu den häufig genutzten Elementen in Aktivitätsdiagrammen zählen Partitionen. Eine Partition visualisiert die logische Gruppierung von Knoten und Kanten innerhalb von Verantwortungsbereichen. Typische Verantwortungsbereiche unterscheiden bspw. Rollen, Abteilungen oder Subsysteme. Beispiel: Aktion 1 und 3 werden in Abteilung A, Aktion 2 und 4 in Abteilung B durchgeführt. Die Trennung der unterschiedlichen Verantwortungsbereiche wird mit sogenannten Schwimmbahnen (swimlanes) dargestellt. Denkbar sind auch hierarchische, multidimensionale und externe Partitionen.3 

Und last but not least gibt es die sogenannten Token. Die Tokensemantik ist aus den Petrinetzen entlehnt, wobei ein Token einem Ablauf-Thread entspricht, der erzeugt und vernichtet werden kann, und das Fortschreiten im Ablauf – quasi mittels virtuellem Zeigefinger – repräsentiert. Da es sich um einen Koordinationsmechanismus handelt, werden Token nicht im Diagramm visualisiert. Der Vorteil der Token liegt in der Möglichkeit, Aktivitätsdiagramme automatisiert zu verifizieren und somit auf ihre Korrektheit zu überprüfen.4

Vorteile von Aktivitätsdiagrammen

Seit der UML Version 2 nutzen Aktivitätsdiagramme ablauforientierte Konzepte oder Konzepte zur Darstellung nebenläufiger, kommunizierender Prozesse. Folglich bieten sie Notationselemente, mit denen sich Geschäftsprozesse, Workflows, Anwendungsfälle oder auch Algorithmen beschreiben lassen.

Neben diesem flexiblen Einsatz bietet die Verwendung von Aktivitätsdiagrammen weitere Vorteile:

  • Grundsätzlich sind sie mit etwas Übung leicht zu erstellen und zu verstehen.
  • Sie bieten unterschiedliche Abstraktionsniveaus und können Verantwortungsbereiche deklarieren.
  • Sie eignen sich zur Modellierung von objektorientierten und nicht-objektorientierten Systemen.
  • Sie lassen sich um Elemente aus anderen Notationen ergänzen.
  • Sie lassen sich automatisiert verifizieren. 
  • Und die Auswahl an Tools, die Aktivitätsdiagramme visualisiert, ist groß.5

Kurzum: Aktivitätsdiagramme sind ein hervorragendes Ausdrucksmittel zur Darstellung von Abläufen. 

Hinweise:

[1] Auch die Systems Modeling Language (SysML), die auf der UML aufbaut, kennt das Aktivitätsdiagramm. Und auch dort gehört es zur Gruppe der Verhaltensdiagramme, wobei die die SysML das Sequenzdiagramm als weiteres Verhaltensdiagramm deklariert. In der UML 2.5 wird das Sequenzdiagramm als Interaktionsdiagramm geführt.
[2] Dokumentation: OMG Unified Modeling Language Version 2.5
[3] Dr. Wieland Schwinger: Das Aktivitätsdiagramm
[4] Dissertation von Alexander Johannes Raschke: Zur automatischen Verifikation von UML 2 Aktivitätsdiagrammen
[5] Hier finden Sie eine Liste von UML-Toolherstellern, die allesamt das Aktivitätsdiagramm als ein zentrales Ausdrucksmittel der UML nutzen.

In manchen Publikationen wird darauf hingewiesen, dass sich Aktivitätsdiagramme und Projektablaufplänen (PAP) ähneln würden. Ein Projektablaufplan zeigt die zeitliche Abfolge von Arbeitspaketen mit Hilfe von Balken und ergänzt den Projektstrukturplan. Visualisiert wird der Projektablaufplan meist mit einem Gantt-Diagramm; damit ist es offensichtlich doch etwas anderes, auch wenn beide Diagramme Aktivitäten darstellen. Die Nähe zu Flussdiagrammen, die zur Darstellung von Geschäftsprozessen genutzt werden, ist hingegen offensichtlich.

Es gibt zahlreiche weitere Ausdrucksmittel, die in Aktivitätsdiagrammen verwendet werden, wie bspw. Pseudozustände, Signale, verlinkende (strukturierte) Aktivitäten, Call Behavior und Call Operation Actions etc. Hier empfiehlt sich ein Blick in die aktuelle Dokumentation der UML. 

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Was ist ein Use Case?

Was ist ein Use Case?

Wissen kompakt: Was ist ein Zustandsdiagramm?

Was ist ein Zustandsdiagramm?

Wissen kompakt: Wie funktionieren Workflows?

Wie funktionieren Workflows?