Aktivitätsdiagramm

Aktivitätsdiagramm

Zweck

Aktivitätsdiagramme sind Diagramme zur Flussmodellierung. Sie stellen die Ak­tivitäten eines Systems dar, die Aktionen, aus den die Aktivitäten sich zu­sammensetzen und den Fluss durch die Aktivitäten. Es kann Kontrollfluss und Datenfluss modelliert werden.

Mit Aktivitätsdiagrammen können komplexe Abläufe in einem System modelliert werden (Geschäftsprozesse, Workflows).

Da Aktivit√§ten aus Aktionen und deren zeitlicher Verkn√ľpfung bestehen, k√∂nnen sie auch zur Modellierung der internen Logik komplexer Operationen verwendet werden und somit Algorithmen visualisieren.

Aktivitätsdiagramme können in Verantwortungsbereiche gegliedert werden. Da­mit können die Aktionen bestimmten Modellelementen, wie Klassen oder Komponenten zugeordnet werden.

Notation

 

SymbolBeschreibung
Aktivität (Activity) Eine Aktivität besteht aus Knoten (Aktivitäten, Aktionen, Kontroll- und Objektknoten) und Kanten (Pfeilen), die den Kontrollfluss durch die Aktivität darstellen. Die Aktivität wird als abgerundetes Rechteck dargestellt. In der lin­ken, oberen Ecke steht der Name der Aktivität, gefolgt vom Eingangsparameter und Typ. Die Rechtecke an beiden Seiten geben die Ein­gangs- bzw. Ausgangsparameter an. Die Sym­bole in der Aktivität stellen die Aktionen dar und die Pfeile den Kontrollfluss.
Aktion (Action) Eine Aktion ist in UML das Basiselement zur Spezifikation von Verhalten. Eine Aktion kann als nicht weiter zerlegbare Funktion angesehen werden. Sie transformiert eine Eingabe zu einer Ausgabe. Aktionen sind in Aktivitäten enthal­ten. Die UML 2.0 unterscheidet verschiedene Typen von Aktionen.
Signal (Send signal action, Accept event acti­on) Mit diesen Symbolen kann das Senden und Empfangen von Signalen bzw. Ereignissen dargestellt werden.
Zeitereignis (Accept time event action) √úber diese Symbol wird ausgedr√ľckt, dass eine Aktion zeitgesteuert angesto√üen wird.
Kontrollknoten werden benutzt um Kontrollstrukturen in einem Flussgraph anzugeben.
Entscheidung und Zusammenf√ľhrung Bei der Entscheidung wird nach Eintreffen des Tokens a entweder nach b oder nach c verzweigt. Die Bedingung, die erf√ľllt sein muss, kann als Ausdruck in eckigen Klammern an den Pfeilen angegeben werden. Bei der Zusammenf√ľhrung wird nach Ein¬≠treffen der Token a oder b nach c verzweigt.
Splitting, Synchronisation Bei einem Splitting-Knoten wird in mehrere parallele Threads verzweigt (wenn a da ist, feu­ern b und c). Ein Synchronisationsknoten syn­chronisiert mehrere Threads (wenn a und b da sind, feuert c).
Start-, Endknoten, Ablaufende Ein Startknoten (Initial Node) stellt den Be­ginn eines Ablaufes dar. Ein Endknoten (Ac­tivity Final Node) beendet eine Aktivität voll­ständig. Ein Ablaufende (Flow Final Node) terminiert einen Zweig einer Aktivität, die Ak­tivität selbst läuft weiter.
Pfeil/Kante Ein Pfeil beschreibt den Fluss zwischen den verbundenen Elementen. In einer eckigen Klammer kann eine Bedingung angegeben werden, die erf√ľllt sein muss, damit die Kante √ľberquert wird.
Objektknoten k√∂nnen in Aktivit√§tsdiagrammen Objekte oder Daten repr√§sentieren. Sie k√∂nnen als unabh√§n¬≠gige Knoten in einem Diagramm benutzt werden, bzw. als Parameter f√ľr Aktionen (In¬≠put, Output Pin). Beide Darstellungen sind √§quivalent. Im Bild oben ist a als Objekt einge¬≠zeichnet; im unteren Bild ist a Ausgangspa¬≠rameter der linken Aktion und Eingangspa¬≠rameter der rechten.
Kanten verbinden die Aktionen in einem Diagramm und stellen den Fluss dar. Kanten, die Kontroll­fluss modellieren, verbinden Aktionen direkt; Objektflusskanten verbinden die Pins der betei­ligten Aktionen.

 

 

Prinzip der Aktivitätsdiagramme

Aktivit√§tsdiagramme zeigen den Ablauf von Aktivit√§ten. Sie definieren die Ak¬≠tionen, aus den sich Aktivit√§ten zusammensetzen und die zeitliche Reihenfolge ih¬≠rer Ausf√ľhrung. Verzweigungen des Kontrollflusses und gleichzeitig ablaufende, parallele Zweige sind m√∂glich. Um die ausgef√ľhrten Aktionen verfolgen zu k√∂nnen, werden die Zweige eines Aktivit√§tsdiagramms mit Tokens belegt. Ein To¬≠ken ist eine Marke, die den Kontrollfluss markiert. In jedem Thread existiert ein Token. Tokens besitzen kein Symbol in der UML. Sie sind virtuelle Elemente, die den Kontrollfluss markieren.

 

 

Dieses Diagramm stellt das Prinzip des Token-Modells dar. Nachdem der Ab¬≠lauf gestartet wurde, wird das erste Token, links im Bild, erzeugt. Danach wird die Aktion a1 ausgef√ľhrt und das Token auf den Ausgang von a1 gelegt. Durch die Verzweigung in die beiden Threads p1 und p2 wird am Anfang beider Threads je ein Token gesetzt. Die Aktionen p1 und p2 werden ausgef√ľhrt; die Tokens werden auf die Ausg√§nge von p1 und p2 gelegt. Wenn beide Tokens da sind, wird das Eingangstoken f√ľr a2 gestartet. A2 wird ausgef√ľhrt, das Token auf den Ausgang von a2 gelegt, die Aktivit√§t wird beendet und das Token vernichtet.


Aktionstypen

Die UML 2.0 definiert verschiedene Typen von Aktionen, die f√ľr bestimmte Zwe¬≠cke verwendet werden k√∂nnen, z. B. Aktionen zum

  • Erzeugen, L√∂schen von Objekten

  • Lesen und Schreiben von Attributwerten

  • Aufrufen von Operationen

  • Empfangen und Senden von Signalen

  • u. a.

 

Verantwortungsbereiche (Partitions)

Aktivit√§ten k√∂nnen komplexe Abl√§ufe darstellen, die durch unterschiedliche Modellelemente ausgef√ľhrt werden, bzw. f√ľr die unterschiedliche Elemente verantwortlich sind. Zur Zuordnung der Aktionen einer Aktivit√§t zu den verant¬≠wortlichen Elementen k√∂nnen Aktivit√§tsdiagramme in Partitionen (Activity Parti¬≠tion) unterteilt werden. Da ein entsprechend aufgeteiltes Diagramm wie eine in Schwimmbahnen eingeteiltes Schwimmbecken aussieht, werden die Activity Partitions auch swimlanes genannt.

 

 

Dieses Bild zeigt ein Aktivitätsdiagramm, das in die Bereiche Partition 1 und Partiti­on 2 unterteilt ist. Die Aktionen a1 und a3 gehören zu der Partition 1; die Aktion 2 gehört zu der Partition 2. Partitionen können senkrecht und waagrecht angelegt werden.

 

Verfeinern von Aktivitäten

 

Aktivitäten können in weiteren Aktivitätsdiagrammen verfeinert werden. Das zu verfeinernde Element wird mit einem Gabelsymbol gekennzeichnet und kann in einem Unterdiagramm verfeinert werden. So können Hierarchien von Ak­tivitätsdiagrammen modelliert werden. Alle Aktivitäten sind auf der untersten Hierarchieebene auf Aktionen abzubilden.

Anwendungsbereich

Aktivit√§tsdiagramme werden zur Modellierung von Abl√§ufen und deren Steuerung benutzt. In Aktivit√§tsdiagrammen werden die einzelnen Verfahrensschritte von Aktivit√§ten und die Reihenfolge in der sie ausgef√ľhrt werden dargestellt. Sie k√∂nnen von der Modellierung von Gesch√§ftsprozessen bis zur Visualisierung von Kontrollfl√ľssen benutzt werden. Eine Aktivit√§t setzt sich aus den Aktionen zu¬≠sammen, die im Aktivit√§tsdiagramm enthalten sind.

Aktivit√§tsdiagramme k√∂nnen in einem Projekt √ľberall verwendet werden, wo Verhalten beschrieben werden muss, bzw. wo Datenfl√ľsse oder Kontrollfl√ľsse modelliert werden sollen.


Zusammenhang

Da Aktivitätsdiagramme sehr vielfältig einsetzbar sind, können vielfältige Bezie­hungen zwischen Aktivitätsdiagrammen und anderen Diagrammen der UML be­stehen.

Aktivitätsdiagramme können die Abläufe von Anwendungsfällen aus Use Case Modellen beschreiben. Sie können verwendet werden, um z. B. den Ablauf eines Geschäftsprozesses, der einem Use Case zugeordnet ist, zu modellieren. Es ist aber auch möglich, dass mehrere Aktivitätsdiagramme den Ablauf eines Use Ca­ses modellieren; in einem Aktivitätsdiagramm könnte das Normalverhalten eines Use Case modelliert werden in einem weiteren könnte eine Alternative zum Nor­malverhalten beschrieben werden.

Da die Darstellung der Kontrollstrukturen höherer Programmiersprachen in der Notation der Aktivitätsdiagramme enthalten ist, können sie auch zur Spezifikation von Algorithmen verwendet werden.

Aktivit√§tsdiagramme m√ľssen mit den anderen Diagrammen in einem Projekt konsistent gehalten werden. Aktionen k√∂nnen Operationen bei den Klassen eines Modells erfordern.


Hinweise f√ľr die Praxis

Style Guide

  • Diagramme sollten √ľbersichtlich angeordnet werden. Kanten zwischen den Knoten sollten m√∂glichst kreuzungsfrei sein.

  • Besonders wenn Aktivit√§tsdiagramme mit Verantwortungsbereichen gezeichnet werden, entstehen gro√üe Diagramme. Zur Integration der Diagramme in einer Projektdokumentation sollte das Ausgabeformat (DIN A 4) ber√ľcksichtigt werden. Es kann sinnvoll sein gro√üe Diagramme √ľber mehrere Seiten zu zerlegen und diese √ľber Konnektoren miteinander zu verbinden.

  • Bei Entscheidungsknoten sollten die Bedingungen in der N√§he des Konnektors angegeben werden.

  • Entscheidungsknoten sollten einen Bezug zur Aktion haben, der sie nachfolgen.

  • Start- und Endknoten sollten angegeben werden, um unmissverst√§ndlich Beginn und Ende einer Aktivit√§t zu dokumentieren.

  • Die Pfeilspitzen sollten so angeordnet werden, dass Diagramme von oben nach unten und von links nach rechts lesbar sind.

 

Neu in UML 2.0

Die Aktivit√§tsdiagramme in UML 2.0 erfuhren die gr√∂√üten Ver√§nderungen gegen¬≠√ľber der UML 1.x.

In der UML 1.x waren die Aktivitätsdiagramme eine spezielle Form der Zustands­diagramme. In der UML 2.0 sind die Aktivitätsdiagramme eigenständig.

Einige Begriffe der UML 1.x wurden weiterverwendet, bekamen aber eine voll­ständig neue Bedeutung. Ein Aktivitätsdiagramm in UML 2.0 beschreibt eine Ak­tivität, die Teilschritte werden Aktionen genannt. In der UML 1.x wurden die Teil­schritte eines Aktivitätsdiagramms Aktivitäten genannt; die Aktivitäten der UML 1.x heißen jetzt Aktionen, das Aktivitätsdiagramm von UML 1.x heißt jetzt Ak­tivität.

Aktivit√§tsmodelle haben jetzt eine starke √Ąhnlichkeit zu Petrinetzen.

Ein Aktivitätsdiagramm darf mehrere Anfangszustände haben.

Signale, Zeitereignis und das Ablaufende wurden als neue Notationselemente ein¬≠gef√ľhrt. Zur Darstellung von Objektfl√ľssen k√∂nnen die "flie√üenden" Objekte als Objektknoten angegeben werden.

Aktivit√§tsdiagramme d√ľrfen Ein- und Ausgabeparameter enthalten.

Beispiel

Bei der Modellierung des Beispiels wurden folgende Annahmen getroffen:

Die Diagramme modellieren jeweils einen Geschäftsprozess zu einem Use Case.

Zur Darstellung der externen Ereignisse, die auf die Aktivitäten einwirken, sind die Akteure, die diese auslösen in den Diagrammen enthalten. Sie sind mit einer gerichteten Kante mit der Aktion, auf die sie zugreifen, verbunden.

Die Diagramme zeigen den Kontrollfluss, keinen Daten- oder Objektfluss.

 

Aktivitätsdiagramm EssenZahlen

Hier wurden Verantwortungsbereiche angegeben. Das Diagramm hat zwei Start­punkte, da die Aktionen "Essen eintippen" und "Karte einschieben" parallel er­folgen können. Die beiden Zweige werden auf dem folgenden Synchronisations­knoten miteinander synchronisiert.

 

Aktivitätsdiagramm KarteLaden

Das folgende Diagramm wurde ohne Verantwortungbereiche modelliert.