Aktivitätsdiagramme: Chronologische Abläufe von Aktivitäten mit UML übersichtlich darstellen

UML 2 spezifiziert eine Aktivität (englisch: activity) als Verhalten, das untergeordnete Einheiten (Aktionen und Objekte) einer Reihenfolge unterlegt. Dafür nutzt sie Daten- und Kontrollfluss-Modelle. Das Aktivitätsdiagramm kann als Teil eines größeren Systems in Verbindung mit weiteren Diagrammtypen dargestellt werden. Ein großes, abgerundetes Rechteck kennzeichnet die Aktivität als abgeschlossenes System (kann auch weggelassen werden). Unten im Beispielbild sehen Sie die Aktivität „Spargel kochen“. Den Titel schreiben Sie in den Kopf des großen Rechtecks. Der Körper wiederum beherbergt Kanten (Pfeile) und Knoten (Rechtecke). Diese symbolisieren die detaillierten Aktionen, Objekte und Kontroll- bzw. Datenflüsse der Aktivität.

Nur wenn die auf den Pins festgelegten Bedingungen erfüllt sind, gehen Daten eine Aktion ein (Eingabepin) oder gibt die Aktion ein Ergebnis aus (Ausgabepin). Auch wenn eine Aktion mehrere eingehende Kontrollflüsse aufweist, muss jeder einzelne ein Token anbieten, bevor eine Aktion startet.

Bei Aktionen innerhalb eines Aktivitätsdiagramms enthält die abstrakte Syntax die einfache Form des abgerundeten Rechtecks. Es gibt jedoch spezifische Aktionen, die Modellierer für genauere Beschreibungen verwenden können. Einige davon drückt UML mit einer eigenen Notation aus. Das sind die Unterarten der Aktionen:

1. Opaque Actions sind „undurchsichtige Aktionen“. Sie fungieren als Platzhalter oder werden durch konkrete (nicht durch UML festgelegte) Textsyntax spezifiziert.
2. Invocation-Actions sind Aktionen, die ein bestimmtes Verhalten hervorrufen – direkt oder indirekt. Dazu gehören:

• Call-Actions: Eine Call-Behavior-Action ruft direkt ein Verhalten auf. Eine Call-Operation-Action hingegen sendet eine Anfrage an ein Objekt, das ein verbundenes Verhalten aufruft. Die Start-Object-Behavior-Action bringt ein Objekt direkt dazu, sein Instanzverhalten auszuführen. Ist keines festgelegt, kann es das übergeordnete Klassenverhalten (classifier-Behavior) anstoßen.
  
  Die Notation einer Aktion, die ein Verhalten hervorruft, besteht aus einem abgerundeten Rechteck. Dort tragen Sie den Namen des jeweils aufzurufenden Verhaltens ein. Call-Behavior-Actions markieren Sie zudem mit einem Dreizack-Symbol, wie im Bild unten zu sehen. Dies soll die weitere hierarchische Verzweigung darstellen, die durch die Aktion entsteht.

• Send-Actions: Sendeaktionen im Aktivitätsdiagramm verschicken Daten immer asynchron (Sequenzdiagramme kennen beispielsweise auch synchrone Nachrichten). Das heißt, dass sie nicht auf eine Antwort vom Zielobjekt warten und somit den Objektfluss nicht blockieren. Die Aktion schließt ab, sobald die Nachricht ausgesendet wurde. Deshalb kann es zwar einen argument-Input haben, z. B. Parameter, produziert aber keinen result-Output. Zudem können Nachrichten gleich an mehrere Empfänger gehen. Send-Signal-Action, Broadcast-Signal-Action und Send-Object-Action gehören zu diesem Typ.
  
  Send-Signal-Actions weichen in ihrer Notation von der üblichen Form (dem abgerundeten Rechteck) ab. Stattdessen weist ein Fünfeck wie ein großer Pfeil in Richtung des gesendeten Signals. Besteht der Inhalt einer Send-Object-Action auch aus einem Signal, können Sie dieselbe Notation verwenden.

3. Object-Actions verändern den Zustand von Objekten (also Instanzen einer Klasse). Sie können diese erschaffen oder zerstören, mit anderen Instanzen vergleichen, sie auslesen und nachfolgend einer Klasse zuordnen oder die Klassifizierung ändern. Folgende Instanzen von Objektaktionen existieren dementsprechend unter UML 2:

• Create-Object-Actions generieren Instanzen einer Klasse, also Objekte.
• Destroy-Object-Actions zerstören das Objekt auf ihrem Input-Pin.
• Test-Identity-Actions untersuchen, ob zwei Werte auf ihrem Input-Pin dasselbe Objekt darstellen.
• Read-Self-Actions ermitteln ihr eigenes Kontextobjekt.
• Value-Specification-Actions untersuchen Wertespezifikationen. Die Notation trägt das Label value specification.
• Read-Extent-Actions finden alle Objekte einer Klasse sowie Objekte von deren Spezifikationen. Aus praktischen Gründen grenzen Modellierer meist die Reichweite ein.
• Reclassify-Object-Actions ändern die Klasse für das Objekt auf ihrem Input-Pin.
• Read-Is-Classified-Object-Actions ermitteln, ob ein Objekt auf ihrem Input-Pin einer Klasse angehört.
• Start-Classifier-Behavior-Actions stoßen für ein Objekt ein Verhalten an, das durch dessen Klasse bestimmt ist. Das Verhalten verläuft dann asynchron.

4. Link-Actions verändern das Verhalten von Assoziationen (Beziehungen zwischen Classifiern, meist zwei Klassen) und ihren Instanzen, den Links. Dazu gehören:

• Read-Link-Actions rufen Werte (Link-End-Data) auf einer Seite einer Assoziation ab.
• Create-Link-Actions erzeugen Links (sie besitzen keine Output-Pins, da Links an sich keine Daten sind) und Linkobjekte.
• Destroy-Link-Actions tilgen Links und Linkobjekte, wenn diese einem festgelegten Link-End-Data-Wert entsprechen.

5. Link-Object-Actions beeinflussen ähnlich wie Link-Actions das Verhalten von Linkobjekten, betrachten aber die Objekte unter anderen Gesichtspunkten. Das sind Instanzen von Link-Object-Actions:

• Read-Link-Object-End-Actions rufen Endobjekte von Link-Objekten ab.
• Read-Link-Object-End-Qualifier-Actions rufen Classifier-Endwerte von Link-Objekten ab.
• Create-Link-Object-Actions sind spezielle Create-Link-Actions, mit denen man Link-Objekte erzeugt.

6. Structural-Feature-Actions bestimmen das Verhalten von Strukturmerkmalen in Aktivitätsdiagrammen. Dafür benötigen sie einen Input-Pin, denn ihnen wird in der Regel sowohl ein Objekt als auch ein statisch spezifiziertes Strukturmerkmal eines Classifiers zugeschrieben. Die Strukturmerkmal-Aktion beeinflusst beide Elemente. Folgende Typen gibt es:

• Read-Structural-Feature-Action lesen die Werte der Strukturmerkmale und geben diese als Output weiter.
• Add-Structural-Feature-Value-Actions benötigen ein Value-Input-Pin. Dieses gibt den Wert vor, den die Aktion einem Strukturmerkmal zuweist.
• Remove-Structural-Feature-Value-Actions ziehen einen Wert von einem Strukturmerkmal ab. Ein Value-Input-Pin mit Multiplizität 1..1 gibt diesen Wert vor.
• Clear-Structural-Feature-Actions entfernen sämtliche Werte eines Strukturelements.

7. Variable-Actions beeinflussen statisch spezifizierte Variablen, die von einer Aktivität oder einem strukturierten Aktivitätsknoten (Structured-Activity-Node) definiert werden. Es gibt drei Arten:

• Add-Variable-Value-Actions benötigen ebenfalls einen Value-Input-Pin. Dieser muss vom gleichen Typ sein wie die Variable und fügt ihr genau einen Wert zu.
• Remove-Variable-Value-Actions entfernen einen vom Pin vorgegebenen Wert.
• Clear-Variable-Actions entfernen alle Werte einer Variablen.

8. Accept-Event-Actions gehören zu den sogenannten Wartepunkten (wait points). Das heißt, dass die Aktion auf ein Ereignis (Event) aus dem Ereignispool des Kontextobjekts wartet. Die Aktion besitzt Trigger, also Auslöser, die beim Eintreten einer oder mehrerer vorgeschriebener Zustände die Aktion auslösen. UML beschreibt drei Spezialisierungen:

• Accept-Call-Actions verfügen über einen Trigger, der Call-Events (Rufereignisse) akzeptiert. Zwei Result-Output-Pins und ein Return-Information-Output-Pin komplettieren das Arrangement. Soll eine Reply-Action ausgeführt werden, lagern die nötigen Informationen dafür im Return-Information-Output-Pin.

9. Structured Actions deklariert UML 2 im Aktivitätsdiagramm sowohl als Aktionen als auch als Aktivitätsgruppe (s. o.). Das heißt zum einen, dass ihr Verhalten durch Aktivitätsknoten und -kanten bestimmt wird, zum anderen, dass bestimmte Unterarten dieser Aktionen aufgrund ihrer Semantik ein bestimmtes Verhalten für die ausführbaren Knoten vorschreiben – insbesondere in Bezug auf deren Abfolge.

Das sind die Unterarten von strukturierten Aktionen:

• Conditional-Nodes (Konditionalknoten) bestehen aus einer oder aus mehreren Klauseln, die die unterschiedlichen Zweige der möglichen ausführbaren Aktionen abbilden. Eine Klausel enthält ein Test- und ein Körper-Segment die wiederum schnittmengenfreie, ausführbare Knoten umfassen. Zuerst führt die Klausel die Aktion im Test-Bereich aus. Ist dessen Output-Wert true, führt die Klausel die Aktion im Körper-Bereich aus.
• Loop-Nodes (Schleifenknoten) beschreiben eine Gruppe von Aktionen, die sich innerhalb einer Schleife wiederholen. Die Aktionen unterteilen sich in drei Abschnitte: Setup, Test und Body. Der Loop führt immer zuerst das Setup aus. Danach folgen Test oder Body, die sich dann abwechselnd wiederholen.
• Sequence-Nodes (Sequenzknoten) erlegen den ausführbaren Knoten innerhalb ihrer Grenzen eine Reihenfolge auf. Diese stellen Sie mit Datenflüssen als Aktivitätskanten (also einfachen Pfeilen) dar. Kanten können frei in die Struktur hinein und aus ihr heraus zeigen.

10. Expansion-Regions sind eine weitere Form der strukturierten Aktivitätsknoten. Sie akzeptieren eine oder mehrere Sammlungen von Werten als Input. Auf dem Weg in die Expansionsregion kopiert der Eingabe-Pin jedes eingehende Token auf die Anzahl der Sammlungselemente. Alle inliegenden Knoten arbeiten sich an jedem einzelnen Wert der Sammlung ab. Ein Durchlauf gilt als eine Expansionsausführung (expansion execution).
    
    Ein sogenannter Expansionsknoten (eine Art Objektknoten) zeigt die Schnittstelle der Expansionsregion an. Nach außen hin zeigen sie ihre Werte als Sammlung an, nach innen gelten die einzelnen Elemente der Sammlung als Wert. Für die Notation zeichnen Sie ein abgerundetes Rechteck mit gestrichelter Linie. Die Expansionsknoten stellen sich als Rechtecke mit Segmenten dar und werden, wie unten zu sehen, direkt auf der Linie gezeichnet. Die Segmentierung soll die Liste der Wertesammlungen darstellen.

Objektknoten sind Unterarten der Aktivitätsknoten. Allgemein ist ein Objekt in der UML die kleinste wertbesetzte Instanz. Im Aktivitätsdiagramm stellen Objekte Daten dar. Während eine Aktion ausgeführt wird, halten die Objektknoten diese Daten fest. Denn nur Kontrolltoken können direkt eine Aktion durchlaufen. Objekttoken hingegen gehen als Wert bei einem Eingabepin ein und werden vom Ausgabepin auf dem Objektfluss weitergeleitet.

Objektknoten wurden im UML-2-Aktivitätsdiagramm das erste Mal eingeführt. Sie sind typisierte Elemente. Entspricht ein Objektknoten einem bestimmten Typ, so müssen Objekttoken, die auf ihm wandern, entsprechende Werte aufweisen. Eine Ausnahme sind Null-Token, die ohne einen Wert auskommen – sie gehen mit jedem Objektknoten konform.

Objektknoten schreiben die Reihenfolge vor, in der Token sie verlassen. Dafür gibt es vier Möglichkeiten:

• Ungeordnet (nicht festgelegt)
• Geordnet (vom Modellierer festgelegtes Verhalten)
• FIFO (First In First Out): Die Reihenfolge beim Ein- und Austritt bleibt gleich
• LIFO (Last In First Out): Die Reihenfolge ist genau umgekehrt

Wollen Sie ein Aktivitätsdiagramm erstellen, haben Sie vier Typen von Objektknoten für die Modellierung zur Auswahl:

1. Der Pin: Pins wurden in dieser Ausführung bereits angeschnitten. In der ersten Grafik war die grundständige Notation von Pins zu sehen. Aufgrund ihrer Aufgabe als Verbindungsglied zwischen Aktionen und Objektflüssen zeichnen Modellierer sie üblicherweise als kleine Rechtecke direkt am Aktionssymbol. Eingabepins (auch „Input-Pins“) kennzeichnen Sie mit einem Pfeil (also einer Kante bzw. ein Objektfluss) in Richtung der Aktion. Bei Ausgabepins (auch „Output-Pins“) führt der Pfeil weg von der Aktion. Die folgende Grafik zeigt, wie Sie Pins gleichen Typs verkürzt darstellen können (links) oder wie Sie Ein- und Ausgabepins zeichnen, wenn Sie die Kanten weglassen (rechts).

2. Aktivitätsparameterknoten: Die Aktivität gehört zur Metaklasse der Verhaltensbeschreibung. Laut UML hat jedes Verhalten Parameter. Bevor ein Verhalten ausgeführt wird, können sie ihm Werte zur Verarbeitung einspeisen. Nach der Verarbeitung erhalten sie neue Werte zurück. Die Parameter sind in diesem Gefüge die Platzhalter, die es erlauben, diese Werte ein- bzw. auszugeben. Der Aktivitätsparameterknoten (Activity-Parameter-Node) übernimmt diese Aufgabe für das UML-Aktivitätsdiagramm. Somit stehen Aktivitätsparameterknoten jeweils am Anfang und am Ende einer Aktivität.
   
   Demzufolge hat ein solcher Knoten entweder nur eingehende oder nur ausgehende Aktivitätskanten. Input-Aktivitätsparameterknoten zeichnen Sie mit ausgehenden Kanten, Output-Aktivitätsparameterknoten mit eingehenden Kanten. Pro Parameter gibt es einen Aktivitätsparameterknoten, wobei beide vom selben Typ sind.

Innerhalb eines UML-Aktivitätsdiagramms wandern Token durch diverse Aktionen, bis die Aktivität abschließt, indem das erste Token am Endknoten ankommt. Da mehrere Token gleichzeitig diesen Prozess durchlaufen können, braucht es eine gewisse Ordnung. Um einen übersichtlichen Ablauf zu gewährleisten, nutzen Sie Kontrollknoten. Diese verwalten nur Kontrollflüsse auf Ihrem Weg vom Anfang des Aktivitätsdiagramms über die Aktionen bis zum Ende der Aktivität. Kontrollknoten können keine Token zwischenspeichern, im Gegensatz zu Objektknoten wie dem Pufferknoten.

Ein maßgeblicher Unterschied zwischen Objekt- und Kontrollflüssen ist, dass auf Kontrollflüssen nur Kontrolltoken wandern. Diese Token tragen, im Gegensatz zu Objekttoken, keine Daten mit sich. Sie sind lediglich Marker. Deshalb benötigen Aktionen keine Objektknoten (speziell Pins), um Kontrolltoken aufzunehmen und weiterzugeben. Ein Kontrolltoken startet eine Aktion, wandert zur nächsten und setzt diese dann in Bewegung. Es kontrolliert also die chronologische Ausführung der Aktivität.

Unter den UML-Aktivitätsdiagramm-Symbolen gestalten sich die Kontrollknoten wohl am vielfältigsten. Sie gehören zu den Aktivitätsknoten. UML 2 unterscheidet sechs Typen:

2. Startknoten (Initial-Nodes) beginnen eine Aktivität. Es kann mehr als einen Startknoten pro Aktivität geben. Beginnt eine Aktivität, versetzt der Startknoten den Kontrollfluss sofort in Bewegung. Existieren mehrere Startknoten, laufen die jeweiligen Kontrollflüsse gleichzeitig an. Auch strukturierte Aktivitätsknoten können Startknoten aufweisen. Diese laufen ebenso sofort an, wenn die strukturierte Aktivität initialisiert wird, solange keine Bedingungen für ihren Start gesetzt wurden. Da Initial-Nodes am Anfang stehen, sind alle ihre Kanten ausgehende Aktivitätskanten. Diese sind immer Kontrollflüsse.
   
   Eine weitere Besonderheit von Startknoten: Die Kontrolltoken, die auf den Startknoten zu Beginn einer Aktivität platziert werden, können dort ausharren, wenn der Kontrollfluss das angebotene Token nicht annimmt oder blockiert ist.

1. Endknoten beenden den Fluss einer Aktivität. Es gibt zwei Arten von Endknoten: Die Activity-Final-Node beendet die gesamte Aktivität, indem sie alle Token innerhalb der Aktivität zerstört, wenn das erste Token bei ihr eingeht. Nur Objekttoken im Output von Activity-Parameterknoten bleiben erhalten.
   
   Auch alle synchronen Aktionen stoppen damit. Asynchrone Aktionen laufen, bis sie abgeschlossen sind. Endknoten akzeptieren alle eingehenden Token. Im Gegensatz zum Startknoten verfügt ein Endknoten ausschließlich über eingehende Aktivitätskanten. Es ist mehr als ein Endknoten möglich.
   
   Zeichnen Sie ein Aktivitätsdiagramm mit mehr als einem Endknoten, stoppen womöglich Aktionen, bevor sie ihren Zweck erfüllt haben, weil ein Token bereits bis den ersten Endpunkt erreicht hat. Die Flow-Final-Node (das Ablaufende) stoppt einen Kontrollfluss und zerstört alle eingehenden Token. Andere Kontrollflüsse berührt dies nicht. Somit bietet sich dieser Endknoten als praktische Alternative an, wenn Sie im Aktivitätsdiagramm mehrere Endpunkte modellieren.

3. Parallelisierungsknoten und Synchronisationsknoten (Fork-Nodes und Join-Nodes), auch Gabelungen genannt, sind Kontrollknoten mit einer fast identischen Notation, die ihre Aufgaben jeweils spiegeln.
   
   Ein Parallelisierungsknoten teilt eine eingehende Aktivitätskante in mehrere, gleichzeitig abgehende Flüsse. Nur eine Aktivitätskante kann in den Parallelisierungsknoten eingehen. Ist es ein Kontrollfluss, sind alle ausgehenden Kanten auch Kontrollflüsse, für Objektflüsse gilt dasselbe Prinzip. Der Knoten erstellt Kopien des eingehenden Tokens für alle ausgehenden Flüsse. Wird ein Token am Ziel des ausgehenden Flusses angenommen, löscht sich das Token aus dem Quellknoten. Akzeptiert ein weiteres Ziel sein Token nicht, kann der Parallelisierungsknoten das Token ausnahmsweise halten, bis es akzeptiert wird.

Synchronisationsknoten funktionieren genau umgekehrt. Mehrere Kanten laufen bei ihnen ein, aber nur eine Kante geht ab. Besteht die Gesamtheit der eingehenden Kanten aus Kontrollflüssen, so verlässt auch ein Kontrollfluss den Knoten. Ist auch nur ein Objektfluss darunter, spezifiziert UML die ausgehende Kante als Objektfluss. Gehen in diesem Fall auch Kontrolltoken ein, verfallen diese und nur Objekttoken gehen aus. Haben zwei Objekte die gleiche Identität, verschmilzt der Knoten sie in ein Token. Generell gehen Token erst aus, wenn an alle eingehenden Kanten eines anbieten (and-Operation). Dies passiert unter dem Prinzip „First In First Out“. Schreiben Sie dem Synchronisationsknoten eine Wertespezifikation per joinSpec zu, wartet der Knoten auf Token, die explizit diese Anforderungen erfüllen, bevor er Token abgibt.

4. Verzweigungsknoten und Verbindungsknoten (Decision-Nodes und Merge-Nodes) teilen sich ebenso das gleiche Symbol im Aktivitätsdiagramm. Die Führung der Flüsse ist wieder das Unterscheidungsmerkmal dieser Knoten-Notationen.
   
   Ein Verzweigungsknoten benötigt mindestens eine, aber höchstens zwei eingehende Kanten. Die eine nennt UML eingehende Primärkante (primary incoming edge). Eine zweite heißt Verzweigungs-Input-Fluss (decision input flow). Ob ausgehende Flüsse Objekt- oder Kontrollflüsse darstellen, richtet sich nach dem Typ der Primärkante. Die Aufgabe des Knotens ist es, sich dann zwischen ausgehenden Kanten zu entscheiden. Der Knoten bieten seinen eingegangenen Knoten an, ohne ihn zu kopieren. Das Token kann also nur einen Weg nehmen.