Aktivitätsdiagramme: Chronologische Abläufe von Aktivitäten mit UML übersichtlich darstellen
Das Aktivitätsdiagramm ist ein Diagrammtyp innerhalb der Unified Modeling Language (UML). Diese grafische Modellierungssprache legt Formen für die Darstellung objektorientierter Programmierung fest. Sie spezifiziert 14 Diagrammtypen. Diesen sind jeweils bestimmte Formen zugeordnet. Mithilfe der Notationsregeln lassen sich Systeme und Prozesse abstrahieren sowie übersichtlich darstellen. UML modelliert nicht nur Software-Systeme, sondern auch Geschäftsprozesse. In beiden Bereichen sind Aktivitätsdiagramme besonders praktische Helfer. Doch zu welchem Zweck sollte man ein Aktivitätsdiagramm erstellen?
Der Zweck von Aktivitätsdiagrammen
UML-Aktivitätsdiagramme (im Englischen activity diagrams) gehören zur Gruppe der Verhaltensdiagramme in der UML. Während ein Strukturdiagramm den Zustand eines Systems erfasst, also die vorhandenen Objekte und deren Hierarchien sowie Verbindungen untereinander zu einem bestimmten Zeitpunkt, beschreiben Verhaltensdiagramme den chronologischen Fluss der Datenströme. Neben dem Aktivitätsdiagramm gehören das Anwendungsfalldiagramm (use case diagram) und das Zustandsautomatendiagramm (state machine diagram) zu dieser Gruppe. Aktivitätsdiagramme ähneln in ihrer Verwendung und Notation den Flussdiagrammen (besonders Programmablaufpläne), sind aber auf die objektorientierte Programmierung zugeschnitten.
Grundsätzlich kann man sagen: Das Aktivitätsdiagramm modelliert den Ablauf von Aktivitäten. Das können Prozesse innerhalb eines Computersystems, Use-Case-Abläufe oder Geschäftsabläufe sein. Die Aktivität, z. B. „ein Käse-Omelette zubereiten“, zerfällt dabei in viele kleine Teil-Aktivitäten: die Aktionen. Diese können etwa chronologisch stattfinden. Eine Aktion wäre beispielsweise „Eier aufschlagen“, gefolgt von der Aktion „Eier mit Gewürzen verquirlen“. Die erste Aktion bedingt die zweite. Sie sind sozusagen im Fluss.
Auch parallele Abläufe sind damit darstellbar. Kümmern sich zwei Leute um die Zubereitung eines Omeletts, ermöglicht das die gleichzeitigen Aktionen „Eier aufschlagen“ und „Kräuter hacken“. Somit hat die Aktivität zwei Startpunkte. Von diesen Punkten aus starten die Personen mit ihrer Aktivität. Dabei gehen sie von einer Aktion zur nächsten über. In einem Anwendungsfall wären diese Personen Akteure. Im Aktivitätsdiagramm spielen sie zwar eine wichtige Rolle, erhalten aber keine eigene Notation. Sie bewegen sich von einem Startpunkt zu einem Endpunkt und durchqueren dabei Kontroll- oder Objektflüsse, um von einer Aktion zur nächsten zu gelangen. Dazwischen gibt es gelegentliche Schranken, sogenannte Pins, die sie nur unter bestimmten Bedingungen durchlassen, z. B. wenn beide Personen anwesend sind.
Im Aktivitätsdiagramm bezeichnet man diese „Personen“ als Token. Es gibt zwei Arten von Token im UML-Aktivitätsdiagramm: Die erste ist das Objekttoken, das eine Information an den Aktionsknoten übermittelt, dort eine Aktion startet und (soweit vorgegeben) das Ergebnis als Wert speichert. Entsprechen Ergebnis und Token den Vorgaben, die in einem Pin festgelegt wurden, schickt dieser Ausgabepin das Objekttoken über einen Objektfluss zur nächsten Aktion. Bevor das Token diese Aktion starten kann, muss es den Vorgaben des Eingabepins entsprechen. Kontrolltoken hingegen wandern nur über Kontrollflüsse und dienen als Marker. Sie starten eine Aktion, übermitteln aber keine Daten.
Im beschriebenen Beispiel „Käse-Omelette zubereiten“ verwenden wir das Aktivitätsdiagramm, um den zeitlichen Ablauf eines Anwendungsfalls darzustellen. Anwendungsfalldiagramme hingegen stellen die Systemvoraussetzungen dar, die im Anwendungsfall gegeben sein sollten.
UML-2-Aktivitätsdiagramme können Sie natürlich nicht nur für Anwendungsfälle des täglichen Lebens nutzen. Sie helfen Ihnen in erster Linie dabei, die Abläufe in Software-Systemen strukturiert darzustellen. Damit machen beispielsweise Wirtschaftsanalysten Vorgaben für Software-Entwickler. Über die grafische Sprache tauschen sich die Experten auf einer allgemein verständlichen und übersichtlichen Ebene aus. Sind alle Abläufe geklärt und Fehler ausgebügelt, dient das Aktivitätsdiagramm als saubere Vorlage für die Programmierung.
Binden Sie ein passendes UML-Tool in Ihre integrierte Entwicklungsumgebung ein, kann das Diagramm mittels XML-Konvertierung in eine Programmiersprache als Code-Framework agieren.
Die Object Management Group (OMG), die die UML spezifiziert, fasst die möglichen Aufgaben von UML-2-Aktivitätsdiagrammen wie folgt zusammen:
- Prozedurale Computerprogrammierung, die Aktivitäten Hierarchien zuweist
- In objektorientierten Modellen agieren Aktivitäten als Methoden, die Abläufe näher beschreiben
- Zur Darstellung von Workflows und Geschäftsprozessen
- Bei computergestützten Anwendungssystemen spezifizieren Aktivitäten Prozesse auf Systemlevel
Die Notationen für UML-Aktivitätsdiagramme
Die Formen innerhalb der UML kann man als Satzbausteine der Sprache verstehen. Deshalb ordnet die Modellierungssprache jeder Form eine Bedeutung zu. Modifikatoren beschreiben diese näher und setzen sie in Bezug zueinander. Zudem verlangen Formen teilweise bestimmte andere Formen oder Label, damit ein sinnvolles Diagramm entsteht. So wie gesprochene Sprache nur sinnvoll ist, wenn gewisse grammatische Grundregeln eingehalten werden, funktioniert UML als Kommunikationsmittel nur, wenn Sie die Spezifikationen einhalten.
UML 2.5 ist die aktuellste Spezifikation der Modellierungssprache und wird daher die Grundlage dieser Ausführungen darstellen. UML legt die Notation der Diagrammtypen auf Basis ihrer Anwendungsgebiete fest. Da das UML-Aktivitätsdiagramm den Ablauf von Systemprozessen und Anwendungsfällen abbildet, ordnet die Metamodellierung ihm entsprechende Formen zu.
Wie werden nun die einzelnen Bestandteile visuell dargestellt und welche Funktionen erfüllen die Symbole im UML Aktivitätsdiagramm?
Aktivitäten
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.
Aktivitäten gelten in UML als Klassen (deren Metaklasse ist das Verhalten). Somit lassen sie sich durch Eigenschaften näher bestimmen. Das kann untergeordnete Elemente beeinflussen. Eine Aktivität gilt als abgeschlossen, wenn ein Token von seinem Startpunkt über die Aktionen bis zum Endpunkt gewandert ist. Der Endpunkt zerstört das Token. Dies gilt auch für alle weiteren Token, sodass die Aktivität alle synchronen Aktionen stoppt.
UML 1 definiert Aktivitätsdiagramme anders als UML 2. Die frühere Version wies ihnen die Rolle eines spezialisierten Zustandsmaschinendiagramms zu, was ihre Einsatzbereiche eingrenzte. Wenn Sie ein UML-Tool nutzen, sollten Sie daher darauf achten, dass es die gewünschte Formulierung unterstützt – idealerweise UML 2.5 oder höher.
Aktionen: Aktivitätsknoten, die das Verhalten darstellen
Eine Aktion (englisch: action, executable node) ist ein Modellelement, das der Aktivität hierarchisch untergeordnet ist: Die Aktion ist eine Instanz der Klasse Aktivität. Aktionen repräsentieren ein Verhalten innerhalb eines Systems. Sie sind die Grundbausteine, mit denen Verhalten in UML ausgedrückt wird. Sie finden sowohl in Aktivitätsdiagrammen als auch in Interaktionen Verwendung.
Wenn Sie ein Aktivitätsdiagramm erstellen, nutzen Sie die Notation „Aktion“, um die ausführbaren Teilbereiche einer Aktivität darzustellen. Im Beispiel oben ist die Aktion „Spargel schälen und in Topf geben“ ein Schritt auf dem Weg zur Vollendung der Aktivität „Spargel kochen“. Aktionen nehmen Input-Informationen auf, verarbeiten diese und produzieren Output-Informationen. Eine Aktion hört nicht auf, bis sie abgeschlossen ist.
Innerhalb der UML-Aktivitätsdiagramme gehören Aktionen zu den Aktivitätsknoten. Sogenannte Kanten (Pfeile) verbinden die Aktionen miteinander. Dabei unterscheidet UML zwischen Objektflüssen (Datenflüsse) und Kontrollflüssen (transportiert Kontrolltoken). Aktionen verarbeiten an sich nur Kontrollflüsse. Wenn Datenflüsse zwischen Aktionen wandern, akzeptieren Pins (Objektknoten) die Objekttoken als Input, wandeln sie zur Verarbeitung in der Aktion um und generieren anschließend den Objekt-Output, der als Objekttoken weiterwandert.
Die Kategorie Aktivitätsknoten wurde in UML 2 eingeführt. Es gibt drei Unterarten: Kontrollknoten, Objektknoten und ausführbare Knoten (die Aktionen). Zwischen diesen dreien gibt es keine Hierarchien. Solange sie nicht hintereinandergeschaltet oder innerhalb einer Aktivitätsgruppe näher definiert sind, können Sie in beliebiger Reihenfolge (also sobald eintreffende Token die gestellten Bedingungen eines Knoten erfüllen) oder parallel ausgeführt werden.
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:
- Opaque Actions sind „undurchsichtige Aktionen“. Sie fungieren als Platzhalter oder werden durch konkrete (nicht durch UML festgelegte) Textsyntax spezifiziert.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Reply-Actions verfügen über eine Verbindung zu den Accept-Call-Actions. Zum einen sollten die Trigger übereinstimmen, damit die Antwort-Aktion im Fall eines Call-Events auf die vorher ausgeführte Rufannahme-Aktion reagieren kann. Zum anderen platziert das übergeordnete Verhalten deren Output-Wert im Return-Information-Input-Pin der Reply-Action.
- Unmarshall-Actions fragen die Werte von Objekt-Strukturmerkmalen ab. Um das Objekt zu erkennen, besitzen sie einen Objekt-Input-Pin. Die gewonnenen Werte gibt es auf einem Output-Pin aus.
Müssen strukturierte Daten eines Objekts oder auch elementare Daten eines Programm in andere Programme oder Programmteile übertragen werden oder will man diese speichern, so wandelt man sie in ein dafür geeignetes Format um. Dieser Prozess nennt sich Marshalling (auch: Marshaling). Der gegenläufige Prozess, Unmarshalling (bzw. Unmarshaling), wandelt diese „eingefrorenen“ Daten wieder in ausführbare Objekte um. Ein Beispiel dafür ist die Übertragung von UML-Diagrammen aus einem Tool mittels XML-Umwandlung in ein anderes Programm.
- 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.
- 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.
- Reduce-Actions (Reduzierungsaktionen) rufen solange ein Verhalten hervor, bis aus einer Sammlung von Werten ein einziger Wert hervorgeht. Dafür kombiniert die Aktion die Sammlungselemente. Die Aktion verfügt daher über zwei in-Parameter aber über nur einen out- oder return-Parameter.
- Raise-Exception-Actions (Aktionen, die eine Ausnahme verursachen) beendeen sich selbst, sobald sie eine Ausnahme verursachen. Somit enden sie nicht wie normale Aktionen, die stoppen, wenn die Aktion bis zu Ende ausgeführt wurde. Sie verbreiten sich nach außen durch das System bis zum nächsthöheren strukturierten Aktivitätsknoten. Verfügt dieser über einen Handler, der mit der Ausnahme übereinstimmt, stopp die Aktion. Andernfalls verbreitet sie sich weiter.
Objektknoten: Aktivitätsknoten, die Objekttoken lenken
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:
- 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).
- 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.
- Pufferknoten: Ähnlich wie Pins verwenden Sie den Pufferknoten (Central-Buffer-Node) direkt im Aktivitätsdiagramm. Dieser Objektknoten speichert bzw. puffert Werte an einer beliebigen Stelle im Diagramm. Im Gegensatz zum Pin steht er aber für sich alleine, ohne an einen Aktivitätsknoten gebunden zu sein. Sowohl eingehende als auch ausgehende Objekte verbindet der Pufferknoten über den Objektfluss mit anderen Objektnoten, beispielsweise mit einem Pin.
Der Pufferknoten dient dazu, eingehende und ausgehende Objektflüsse zu puffern. Somit akzeptiert er alle eingehenden Objekttoken und stellt diese für ausgehende Objektflüsse zur Verfügung. Erst wenn ein Objektnoten am anderen Flussende frei wird und die Objektparameter akzeptiert, schickt er das Token weiter. Laut UML-Notation besteht dieser Knoten aus einem einfachen Rechteck. Seine spezielle Funktion zeigen Sie mit dem Stereotyp <<centralBuffer>> an.
- Datenspeicherknoten: So wie Pufferknoten schalten Sie auch Datenspeicherknoten zwischen Objektflüsse, ohne sie an eine Aktion zu binden. Diese Unterart des Pufferknotens hat eine Besonderheit: Sie speichert eine Kopie jedes ausgesendeten Tokens, bis die übergeordnete Aktivität abgeschlossen ist. Dafür existiert jeder Wert nur einmal auf dem Datenspeicherknoten. Speichert der Knoten also bereits ein Objekttoken mit einer festen Identität, nimmt er keine neuen Token mit genau denselben Eigenschaften auf.
Wie bei allen Objektnoten stellt man den Datenspeicherknoten als Rechteck dar. Zur Unterscheidung schreiben Sie den Stereotyp <<datastore>> in den Kopf.
Kontrollknoten: Aktivitätsknoten, die Kontrolltoken lenken
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:
- 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.
- 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.
- 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.
- 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.
Ein Verbindungsknoten bündelt mehrere eingehende Flüsse zu einem einzigen ausgehenden Fluss. Im Gegensatz zum Synchronisationsknoten fügt der Verbindungsknoten aber keine Token zu einem neuen zusammen oder synchronisiert die Typen der eingehenden Kanten. Deshalb müssen für einen ausgehenden Kontrollfluss alle eingehenden Kanten ebenfalls Kontrollflüsse sein. Für Objektflüsse gilt dasselbe. Der Verbindungsknoten bietet einfach alle eingegangen Token für die ausgehende Kante an.
Wollen Sie unter UML ein Aktivitätsdiagramm erstellen und das Konzept im Team bearbeiten, ist es wichtig, die Notation einzuhalten. Nur so gewährleisten Sie die allgemeine Verständlichkeit dieser grafischen Modellierungssprache. In diesem Artikel haben wir Ihnen die wichtigsten Aktivitätsknoten und Kanten mit ihren Funktionen vorgestellt. Zudem zeigten wir alle grundlegenden und spezifischen Notationen für Aktivitätsdiagramme nach UML-2.5.1-Spezifikation. Die erschöpfend erklärte Spezifikation aller UML-Aktivitätsdiagramm-Symbole finden Sie auf der Website der Object Management Group.