Aktivitätsdiagramm
Mit Aktivitätsdiagrammen (Activity diagrams) können zeitliche Abläufe beschrieben werden. Damit ist es möglich Prozesse, Workflows und Algorithmen auf verschiedenen Abstraktionsniveaus zu beschreiben. Häufig werden Aktivitätsdiagramme zur näheren Beschreibung von Use Cases (Anwendungsfälle) eingesetzt. Use Cases können auch mit natürlicher Sprache, sogenannten Szenarien, beschrieben werden, allerdings bleibt dabei die Übersicht nur bei sehr einfachen Abläufen erhalten.
Mit Aktivitätsdiagrammen hingegen ist es möglich, auch sehr komplexe Abläufe mit vielen Ausnahmen, Varianten, Sprüngen und Wiederholungen noch übersichtlich und verständlich darzustellen. In der Praxis ist es heute üblich, textuelle Szenarien als Diagramme aufzulösen, um die darin enthaltenen Aussagen als ansprechbare Elemente im Modell verfügbar zu haben. Neben Aktivitätsdiagrammen können auch andere Verhaltensdiagramme, wie das Zustandsdiagramm, Sequenzdiagramm, etc., zur Beschreibung von Use Cases verwendet werden.
Hinweis: Die Semantik der einzelnen Modellelemente unterscheidet sich teilweise trotz gleicher Bezeichnungen erheblich von den Modellelementen in UML 1.x.
Das Aktivitätselement von UML 1.x ist der Aktion gewichen, während ein ganzes Aktivitätsmodell nun Aktivität genannt wird. Einige Hinweise zu den UML-Versionen finden sich am Ende des Kapitels über Aktivitätsdiagramme.
Aktivität
Die Aktivität (Activity) beschreibt die Ablaufreihenfolge von Aktionen. Sie wird durch ein Rechteck mit abgerundeten Ecken dargestellt. In dem Rechteck befinden sich die Knoten und Kanten der Aktivität. Die Knoten der Aktivität sind in der Regel Aktionen. Es gibt eine Menge verschiedener Aktionen. Am häufigsten wird die „normale“ Aktion verwendet. Zwei weitere wichtige Aktionen sind die CallBahaviourAction und CallOperationAction, um innerhalb einer Aktivität ein Verhalten aufzurufen, welches anderswo definiert ist. Es ist aber auch erlaubt, dass innerhalb einer Aktivität weitere Aktivitäten gezeichnet werden – Substrukturierung.
Wie jedes Verhalten (Behavior) in der UML kann auch eine Aktivität Parameter haben. Ein- oder ausgehende Objekte einer Aktivität werden als Parameter der Aktivität bezeichnet. Diese Objekte werden auf dem Rechteck der Aktivität platziert und optional unterhalb des Namens der Aktivität mit Typangabe aufgelistet.
Das folgende Beispiel zeigt eine Aktivität zur Produktion von Sechserpacks. Die Aktivität hat zwei Parameter: einen Eingangsparameter Produzierte Flaschen im Zustand [leer] und einen Ausgangsparameter Neues Sechserpack. Die genaue Deklaration der Aktivitätsparameter steht links oben direkt unter dem Namen der Aktivität.
Abb. 17: Beispiel für eine Aktivität „Produktion von Sechserpacks“
In der Aktivität befinden sich verschiedene Arten von Knoten und Kanten.
Die Rechtecke mit den abgerundeten Ecken innerhalb der Aktivität sind Aktionen. Die kleinen Rechtecke an den Aktionen sind sogenannte Pins. Sie stellen die eingehenden bzw. ausgehenden Objekte für die Aktionen bereit.
Tokenkonzept für Aktivitätsdiagramme
Bis UML 1.x waren Aktivitätsdiagramme als Mischung von Zustandsdiagrammen, Petrinetzen und Ereignisdiagrammen definiert, was zu allerlei theoretischen und praktischen Problemen führte.
Seit der UML 2.x liegt den Aktivitätsdiagrammen eine aus den Petrinetzen entlehnte Tokensemantik zugrunde, mit der präzise Regeln für den Ablauf- und Objektfluss, inklusive Parallelisierung und Zusammenführung geschaffen wurden. Ein Token entspricht dabei genau einem Ablauf- Thread, der erzeugt und vernichtet werden kann. Dabei repräsentiert das Token entweder das Fortschreiten des Ablauf- oder des Datenflusses. Durch die formalere Spezifikation der Semantik der Aktivitätsdiagramme besteht nun die Möglichkeit, eine automatische Verifikation durch Simulation von Aktivitätsdiagrammen durchzuführen.
Durch die Überarbeitung des UML Aktivitätsdiagramm haben sich folgende Begriffe geändert:
- Die einzelnen elementaren, nicht teilbaren Schritte in einem Ablauf heißen nicht mehr Aktivitäten, sondern Aktionen.
- Eine Menge von Schritten, also letztendlich ein Ablaufdiagramm bzw. Teilablauf, wird nun Aktivität
- Während bis UML 1.x jede eingehende Transition einen Ablaufschritt gestartet hat, ist jetzt eine implizite Synchronisation vorhanden, d.h. , alle eingehenden Objekt- und Kontrollflüsse müssen vorliegen, damit die Aktion startet.
- Ebenso wird ein Aktionsknoten erst dann verlassen, wenn alle ausgehenden Kanten feuern können. In UML 1.x war es genau umgekehrt, wenn mehrere ausgehende Kanten (früher Transitionen genannt) notiert waren, musste über entsprechende Bedingungen sichergestellt werden, dass stets nur eine Kante feuern Jetzt wird gewartet, bis alle Bedingungen für alle ausgehenden Kanten erfüllt sind, bevor gefeuert wird.
- Es existieren einige neue Elemente:
- Aktivitäten können Objektknoten als Ein- und Ausgangsparameter haben.
- Es können Vor- und Nachbedingungen für Aktivitäten definiert
- Anfangs- und Endaktivität heißen jetzt Startknoten und Endknoten
Verbindungen
Die Verbindungen zwischen Aktionen werden in Kontrollfluss- und Objektfluss-Kanten unterschieden (ControlFlow bzw. ObjectFlow). In der Notation sind beide Kanten gleich: eine durchgezogene Linie mit offener Pfeilspitze.
Unterschieden werden Objektfluss-Kanten explizit, indem sie zwischen Object-Pins oder Aktivity-Nodes gezogen werden (kleines Rechteck an Aktion oder Aktivität), zu einem oder von einem Datastore, Central Buffer Node oder Objekt führen.
Abb. 18: Kontrollfluss Objektfluss (a)
Ein Kontrollfluss verbindet Aktionen und Aktivitäten. Nachdem Karte einlesen abgeschlossen ist, fließt das gedachte Token entlang des Kontrollflusses, falls Karte überprüfen bereit ist, aktiviert zu werden.
Bei einem Objektfluss werden zusätzlich zur Kontrolle auch Daten übermittelt. Falls mehrere Objekttoken ankommen, werden diese standardmäßig nach FIFO weiter gereicht. Alternativ zur Pin-Notation kann auch ein Objekt verwendet werden.
Abb. 18 Kontrollfluss Objektfluss (b)
Abb. 18: Kontrollfluss Objektfluss (c)
Ein Spezialfall von Objektflüssen sind Object-Streams. Dabei handelt es sich um einen kontinuierlichen Fluss an Daten (Objekten). Vergleichbar mit einem Förderband, auf dem stetig Flaschen abgefüllt werden.
Objektflüsse und Kontrollflüsse können auch aufgeteilt werden. Ein Central Buffer Node oder ein Datastore können verwendet werden, um Daten vorübergehend bzw. permanent zu speichern
Waren können im Warenkorb (Central Buffer Node) zwischengespeichert werden und später wieder abgerufen werden. Falls der Prozess vorher beendet wird, werden zwischengespeicherte Daten vernichtet – im Gegensatz zum Data Store.
Abb. 18 Kontrollfluss Objektfluss (d)
Verzweigungen
Eine Verzweigung des Prozesses wird mittels Rautensymbol (Decision) erreicht. Eine Decision kann beliebig viele ausgehende Kanten haben (in der Regel mindestens 2). Falls mehrere ausgehende Kanten vorhanden sind, wird dies als Switch interpretiert. Alternativ kann ein Switch durch mehrere hintereinander geführte Decisions ausgedrückt werden, dies ist allerdings ein schlechter Modellierungsstiel. Zu beachten ist, dass jede ausgehende Kante einer Decision eine Wächterbedingung (Guard) besitzt.
Abb. 19 Explizite vs. Implizite Decision
Hinweis: Wächterbedingungen müssen vollständig sein
(x< 0 und x > 0; Fehler bei x==0) und dürfen sich nicht überlappen (x <=0 und x >= 0; Fehler bei x==0).
Alternativ zur Decision können die ausgehenden Kanten mit ihren Wächterbedingungen direkt aus einer Aktion/Action führen.
Achtung: Mehrere, nicht beschriftete Ausgänge aus einer Aktion/Activity bedeuten jedoch Splitting (Parallelisierung).
Da dies leicht verwechselt werden kann, wird üblicherweise das Rautensymbol für Verzweigung (Decision) gesetzt, wodurch klargestellt ist, dass nur ein einziger Ausgang gewählt wird (disjunkt).
Zusammenführen
Durch eine Decision wird im Prozess ein alternativer Weg ausgewählt. Besteht der Bedarf Schleifen zu definieren, ist es notwendig, ein Merge Element zu verwenden.
Wird auf ein Merge Element verzichtet und die rückführende Kante direkt in eine Action/Activity geführt, impliziert dies die Zusammenführung zweier nebenläufiger Prozesse (impliziter Join).
Wird also die rückführende Kante direkt in Termin auswählen geführt, muss an jeder Kante ein Token anliegen. Dies wird in diesem Beispiel nie passieren und führt zu einem blockierten Prozess (dead-Lock).
Zwei eingehende Kanten in eine Action/Activity sind nach UML nicht verboten (siehe Abb.20), die implizite Join Semantik muss allerdings bedacht werden. Um falsche Interpretationen zu vermeiden, sollte auf implizite UML Semantik gänzlich verzichtet werden.
Abb. 20 Mergen
Splitting (Parallelisierung) und Synchronisation
Mit einem Splitting Knoten (Fork Node) wird ein Prozessfluss parallelisiert, um nebenläufige Prozesse zu modellieren. Nebenläufigkeit heißt zeitlich unabhängig, muss allerdings nicht zwangsläufig gleichzeitig bedeuten. Reiseunterlagen erstellen und Angebot reservieren (Abb.21) können, müssen aber nicht gleichzeitig durchgeführt werden. Ein Fork darf auch mehr als zwei abgehende Kanten haben.
Beim Fork Node wird jedes eingehende Token dupliziert, auf jeder abgehenden Kante beginnt ein Token zu laufen. Kann ein Token an einer ausgehenden Kante nicht weiter gereicht werden, wird es in einer FIFO-Liste zwischengespeichert, bis die nachfolgende Aktion/Aktivität dieses Token aufnehmen kann. Dies ist eine Ausnahme bei UML Aktivitätsdiagrammen, da in der Regel an „pseudo“-Knoten keine Tokens stehen bleiben.
Nebenläufige Prozesse können mittels Synchronisation (Join Node) zusammengeführt werden. Dazu muss an jeder eingehenden Kante ein Token (Kontroll- oder Objekttoken) anliegen. Nach dem Zusammenführen werden alle anliegenden Kontrolltoken und identische Objekttoken zu einem verschmolzen. Im Gegensatz dazu werden alle anliegenden Objekttoken weitergereicht! Lediglich identische Objekttoken werden verschmolzen und nur einmal weiter gereicht.
Abb. 21 Splitting und Synchronisation
Abb. 22 Join Specification
Der Join Node hat eine Implizite und Semantik. Wenn lediglich eine Auswahl an nebenläufigen Prozessen vollendet sein muss, um den Prozess synchron fortzuführen, bietet die UML die Join Specification (JoinSpec). Damit besteht die Möglichkeit eine Bedingung zu definieren, welche das Zusammenführen beschreibt. Im Beispiel muss an der Kante a und b oder a und c ein Token anliegen. Der Film muss auf jeden Fall ausgesucht werden, wie bezahlt wird, ist egal.
Schachteln von Aktivitätsdiagrammen
Aktivitäten bestehen in der Regel aus Aktionen, welche die einzelnen Schritte einer Aktivität beschreiben. Dies ist vergleichbar mit einer Operation/Funktion einer Programmiersprache und den einzelnen Anweisungen in der Operation. Genauso wie eine Operation andere Operationen aufrufen kann, besteht diese Möglichkeit auch bei Aktionen in Aktivitäten.
Das Schachteln hilft a) mit dem üblichen A4-Format (auch über mehrere Seiten hinweg) auszukommen und b) die Inhalte so zu gliedern, dass sie eine für den jeweilig verantwortlichen Freigeber passende Detailtiefe aufweisen.
Das Aufrufen einer Aktivität wird durch eine Call Behavior Action durchgeführt.
Werden Teile eines Use Cases nur unter speziellen Bedingungen ausgeführt, können diese Teile als eigene Anwendungsfälle modelliert und mittels «extend» Beziehung eingebunden werden.
Call Behavior Actions sind grafisch durch ein Gabel-Symbol in der rechten unteren Ecke von anderen Aktionen unterscheidbar.
In Abb.23 wird in der Aktivität Geld abheben mehrmals die Aktivität Karte ausgeben aufgerufen. Karte ausgeben kann wiederum durch beliebige Actions beschrieben worden sein.
Hinweis: Durch Call Behavior Actions kann das Problem von duplizierten Aktionen/Aktivitäten vermieden werden. Der Trick ist, eine Aktivität zu definieren, welche durch Call Behavior Actions beliebig oft aufgerufen werden kann.
Zu beachten ist, dass lediglich Aktivitäten (Activities) durch Call Behavior Actions aufgerufen werden können.
Abb. 23 Aufruf einer Aktivität mittels Aktion
Call Operation Actions sind vergleichbar mit Call Behavior Actions, sie rufen allerdings kein Verhalten (Aktivität) auf, sondern direkt Operationen, die anderswo definiert sind (z. B. Operationen einer Klasse). Durch die Aktion Fehlermeldung in Abb. 23 wird z. B. die Operation fehlermeldungAusgeben() der Klasse ATM aufgerufen.
Durch Call Operation Actions können Aktivitätsdiagramme und Strukturdiagramme, wie das Klassendiagramm, explizit verbunden werden und somit definiert werden, wo ein bestimmtes Verhalten realisiert wird. Einerseits wird das von Qualitätssystemen (SPICE, CMMI, …) eingefordert, andererseits senkt der geringe Aufwand, den Verweis anzulegen, den Aufwand bei späteren Änderungswünschen dramatisch.
Abb. 24 Strukturierte Aktivitäten
In Enterprise Architect besteht die Möglichkeit, Elemente zu strukturieren. Ein strukturiertes (composite) Element besitzt einen Link zu einem Diagramm, in dem weiterführende Informationen definiert sind. Grafisch werden verlinkte Elemente mittels Brille/Kette in der rechten unteren Ecke dargestellt.
Diese Möglichkeit ist nicht in der UML-Spezifikation definiert, bietet aber eine gute Strukturierungsmöglichkeit von Diagrammen.
Mit dieser Kaskadierung von Diagrammen behält man auch bei komplexen Abläufen die Übersicht. Diese Untergliederung in Sub-/Detailmodelle kann hilfreich und auch notwendig sein:
- um hinreichende Unterteilung um Standardpapierformat einhalten zu können und
- zur Erzeugung von Detailgliederungen, die in verschiedene Dokumente eingebunden werden und von verschiedenen Verantwortungsträgern freigegeben werden.
Verantwortlichkeitsbereiche (Swimlanes)
Einzelne Aktionen im Aktivitätsdiagramm werden im Normalfall von einem zuständigen Actor durchgeführt. Um in einem Diagramm die Zuordnung der einzelnen Aktionen zu den Akteuren darstellen zu können, gibt es die Möglichkeit, sogenannte Swimlanes (Verantwortlichkeitsbereiche) einzuführen.
Diese senkrecht oder waagrecht verlaufenden Bahnen symbolisieren den Actor und stellen die Aktivitäten durch die grafische Zuordnung der einzelnen Aktionen zu einer Bahn in dessen Verantwortlichkeitsbereich. Alternativ zur Swimlane können auch Partitions verwendet werden. Partitions sehen Swimlanes sehr ähnlich, sind aber Teil des Modells und nicht nur im Diagramm eingezeichnet. Die Abb. 25 zeigt die Verwendung von Partitions.
Abb. 25
Asynchrone Prozesse
Durch Kontrollflüsse und Objektflüsse werden Aktivitäten und Aktionen verbunden. Die so definierten Prozesse sind „synchron“, d.h., es ist determiniert, welche nachfolgenden Schritte möglich sind, alternativen werden ebenfalls direkt mittels Decision modelliert.
Durch Verwendung von Signalen (Send Signal Action, Receive Signal Action und Timer Action) ist es möglich, zwei oder mehrere Prozesse zu entkoppeln. Durch ein Send Signal wird ein Broadcast Signal gesendet. Alle Receive Signals, für welche dieses Signal bestimmt ist, werden aktiv. Für eine bessere Lesbarkeit können Abhängigkeiten durch Dependency Kanten vom Receive Signal zum Send Signal Element definiert werden.
Die Abbildung 25 zeigt, dass die Aktion Pizza bestellen (eine Send Signal Action) aus geführt wird und das Signal zum Backen der Pizza in der Pizzeria von der Aktion (eine Receive Signal Action) Bestellung entgegennehmen aufgefangen wird.
Hinweis: Receive Signal Actions brauchen nicht zwangsläufig eine eingehende Kante. Die Regel besagt, dass alle Aktivitäten/Aktionen welche keine eingehende Kante besitzen mit einem Token belegt werden.
Bei Unterbrechungsbereichen verhalten sich Signal Actions unterschiedlich und werden nur aktiv, sobald der Unterbrechungsbereich betreten wird.
Abb. 26 Unterbrechungsbereich
Unterbrechungsbereich
Der Unterbrechungsbereich (Interruptable Activity Region) definiert einen speziellen Bereich eines Prozesses. Wird der Unterbrechungsbereich betreten, kann der ausgeführte Prozess zu jedem beliebigen Zeitpunkt unterbrochen werden und ein alternativer Pfad gewählt werden.
Der Unterbrechungsbereich kann durch Eintreffen eines Signals (Receive Signal) oder durch Ablauf eines Zeit-Events (Time Event) unterbrochen werden. Eine Unterbrechung des Prozesses wird durch einen Unterbrechungspfeil (Interrupt Flow) definiert.
Führt eine Kontroll-/Objektfluss-Kante in den Unterbrechungsbereich hinein, wird der Bereich aktiv und somit auch die Time Event Actions und Receive Signal Actions. Führt eine Kontroll-/Objektfluss-Kante wieder aus dem Unterbrechungsbereich heraus, wird der Unterbrechungsbereich ordnungsgemäß verlassen und dadurch wieder inaktiv.
Solange der Unterbrechungsbereich aktiv ist, kann er über Unterbrechungspfeile an beliebigen Stellen verlassen werden. Eventuell ausgeführte Aktivitäten/Aktionen werden gestoppt. Die UML-Spezifikation enthält keine Beschreibung darüber, wie bereits angefangene Aktivitäten/Aktionen behandelt werden, falls sie unterbrochen werden. Eine Best-Practice Interpretation ist, dass ein Rückgängigmachen (Rollback) der teilweise durchgeführten Aktionen/Aktivitäten durchgeführt wird. Hinweis: Der Interrupt-Flow muss von einem Element in der Interruptregion auf ein Element außerhalb der Region zeigen.
Im obigen Beispiel wird der Unterbrechungsbereich nach der Bestellung einer Pizza betreten. Während auf die Pizza gewartet wird, wird die Aktivität fernsehen ausgeführt. Da fernsehen keine ausgehende Kante besitzt, würde der Prozess hier stehen bleiben. Der Unterbrechungsbereich, und somit auch die Aktivität fernsehen, wird unterbrochen, sobald die Pizza geliefert wird, oder länger als eine Stunde gewartet wurde.
| Name/Symbol | Verwendung |
|---|---|
 | Das Symbol der Aktion besteht aus einem Rechteck mit abgerundeten Ecken. Per Definition ist eine Aktion ein einzelner Schritt, der nicht mehr unterteilt werden kann und auch nicht durch äußere Einflüsse unterbrechbar ist. |
 | Das Symbol der strukturierten Aktivität wird mit dem Symbol der Aktivität dargestellt.Im rechten unteren Bereich ist ein Brillen/Ketten-Symbol angebracht. Dieses Element verlinkt zu einem anderen Diagramm. Nicht Teil des UML Standards, allerdings ein wertvolles Strukturierungskonstrukt. |
 | Eine Call Behavior Action erlaubt das Aufrufen von beliebigen Verhalten (Aktivitäten) aus einem bestehenden Prozess. Damit kann die redundante Definition von Aktivitäten/Aktionen verhindert werden. |
 | Eine Call Operation Action ruft ein konkretes Verhalten eines Strukturelementes auf, z. B. die Operation einer Klasse. Elementname und Verhaltensname werden durch „::“ getrennt. ([Elementname]::[Verhaltensname]) |
 | Zwei Aktionen werden mit einem Pfeil verbunden, wenn der Aktivitätsfluss von einer zur nächsten Aktion/Aktivität wechselt. Die Pfeilspitze zeigt in die Richtung des Prozessflusses. Der Pfeil kann eine Bedingung als Beschriftung erhalten, wenn der Prozessfluss nur bei dieser Bedingung stattfindet. Dies ist der Fall, wenn mehrere Transitionen aus einer Aktivität herausgehen oder der Fluss durch eine Raute (Decision) aufgeteilt wird. |
 | Mit dem Rautensymbol (Decision) kann der Prozessfluss verzweigt oder wieder zusammengeführt (Merge) werden. Geht eine Kante ein und mehrere ab, handelt es sich um die Verzweigung (Decision), gehen mehrere Kanten ein und eine ab, handelt es sich um eine Wegezusammenführung (Merge). Bei einer Wegezusammenführung wird in der Regel keine Beschriftung eingesetzt. |
 | Wenn in einem Prozess Daten erzeugt und verwendet werden, können diese als Objekte (Instanzen von Klassen) repräsentiert werden. Das Objekt kann ohne Typ angegeben werden (wie in der Abbildung links). Bei typisierten Objekten steht der Typ-Name nach dem Objekt-Namen. Die Notation ändert sich auf: Object-Name:Typ-Name |
 | Der Objektfluss beschreibt die Übergabe der Kontrolle von einer Aktivität/Aktion zur nächsten und überträgt zusätzlich zur Kontrolle, Daten (Objekte). Ausgangspunkt und Endpunkt des Objektflusses ist in der Regel ein Objekt. Dies kann ein ObjektNode (kleines Quadrat an Aktivität/Aktion), ein Objekt (Instanz einer Klasse), ein Central Buffer Node (transienter Pufferknoten) oder ein Datastore (persistenter Pufferknoten) sein. ObjectNodes können wie Instanzen einer Klasse einen Typ besitzen (:Flasche) und zusätzlich ihren Zustand definieren ([abgefüllt]). |
 | Durch Splitting (Fork) kann der Prozessfluss in mehrere nebenläufige Prozessflüsse aufgeteilt werden. Beim Fork wird das eingehende Token (Kontroll- oder Daten-Token) vervielfältigt. Jede ausgehende Kante bekommt ihr eigenes Token. |
 | Durch die Synchronisation (Join) können nebenläufige Prozessflüsse zusammengeführt werden. Dabei findet eine Synchronisation statt, d.h., die Abarbeitung wird so lange angehalten, bis alle Teilflüsse (Token) am Synchronisationselement angekommen sind. Die UND Semantik des Join kann durch Join Specifications redefiniert werden (siehe Abb. 22). |
 | Der Startpunkt ist der Ausgangspunkt des Prozesses. Sind mehrere Startpunkte vorhanden, werden die davon betroffenen Zweige des Prozesses nebenläufig gestartet. Falls kein Startpunkt vorhanden ist, werden alle Knoten, die keine eingehenden Kanten haben, als Startpunkte interpretiert. Für ein besseres Verständnis sollte darauf geachtet werden, einen Startpunkt pro Prozess zu definieren. |
 | Nachdem alle Aktionen der Aktivität abgearbeitet wurden, endet der Prozessfluss dieser Aktivität. Dieser Punkt wird mit dem Endpunkt dargestellt. Ein Aktivitätsdiagramm darf eine beliebige Anzahl von Endpunkten (Activity Final) enthalten; bei endlos laufenden Prozessen kann er fehlen. Durch die Verwendung mehrerer Endpunkte kann die Terminierung des Prozesses, an unterschiedlichen Punkten im Prozess, besser dargestellt werden. Achtung: Werden Endpunkte innerhalb verschachtelten Aktivitäten verwendet, beendet der Endpunkt nicht den gesamten Prozess, sondern lediglich alle Tokens, die im Subprozess am Laufen sind. |
 | Abbruch, Flow Final bedeutet, dass ein Token, der dieses Symbol erreicht, vernichtet wird. Der Prozesszweig wird hier abgebrochen. Falls noch weitere Token vorhanden sind, wird der Gesamtprozess weiter ausgeführt, handelt es sich jedoch um den letzten Token, wird der gesamte Prozess beendet. |
 | Möchte man Zuständigkeitsbereiche im Prozessfluss modellieren, z. B. Aktionen/Aktivitäten, welche verschiedenen Paketen/Komponenten/Aktor angehören, kann man die Verantwortlichkeitsbereiche mit senkrechten oder waagrechten Linien modellieren. Der Name des Bereichs, der zwischen zwei Linien liegt, wird im oberen Bereich mit dem Namen des zuständigen Elements beschriftet. |
 | Ein Send-Signal ist eine Action, die verwendet wird, um während der Ausführung eines Prozesses asynchrone Nachrichten an andere Prozesse zu senden. |
 | Ein Receive Signal ist eine Action, welche auf ein Signal (Event) wartet. Nach Eintreffen des Signals wird die Aktion ausgeführt und der Flow weitergeführt. Receive Events werden verwendet, um Asynchronität zu modellieren. Wenn das Receive Event keine eingehenden Kanten besitzt und das Element, welches das Receive Event beinhaltet aktiv ist, ist es „feuerbereit“. |
 | Ein Time Event erzeugt periodisch einen Output (Token). Der Output triggert weitere Aktionen und kann auch in Zusammenhang mit Interruptable Activity Regions verwendet werden. Wenn das Time Event keine eingehenden Kanten besitzt und das Element welches das Time Event beinhaltet aktiv ist, ist es „feuerbereit“. |
 | Eine Interruptable Activity Region ist ein Bereich, der durch Ereignisse (Receive Events, Time Events) verlassen werden kann. Alle aktuell ausgeführten Aktionen werden unterbrochen und der alternative Weg wird weiter verfolgt. |
 | Ein Datastore ist ein persistenter Pufferknoten. Er wird eingesetzt, um Daten aus Objektflüssen aufzunehmen. Damit kann ausgedrückt werden, dass in einem Prozess auf vorhandene Daten zugegriffen wird, bzw. neue Daten persistent gespeichert werden. |
 | Ein Central Buffer Node ist ein transienter Pufferknoten. Er verhält sich wie ein Datastore, mit dem Unterschied, dass gespeicherte Daten nach Beendigung der Aktivität, mittels Activity Final, gelöscht werden. Er hat also die Semantik einer lokalen Variablen einer Operation in OO Programmiersprachen. |
 | Ein Interrupt Flow wird verwendet, um eine Interruptable Activity Region zu verlassen. |
Beispiel
Im folgenden Beispiel wird der Prozess zur Vorbereitung einer Feier beschrieben. Die Beschreibung wurde aus Gründen der Übersichtlichkeit in mehreren Diagrammen modelliert.
Abb. 27: Beispiel 1: Prozess zur Durchführung einer Feier
Abb. 27: Beispiel 2: Prozess zur Durchführung einer Feier
Die obige Abbildung beschreibt drei Aktivitäten, die nacheinander durchgeführt werden (Einkaufen, Kochen, Feiern). Die einzelnen durchzuführenden Aktionen des Einkaufens sind in der Aktivität Einkaufen angeführt.
Aus der Aktivität Einkaufen fließt ein Objektfluss mit der/den erworbenen Ware(n) in die Aktivität Kochen.
Die Typen (Ware, Speise) der Objekte (Object Nodes) sind als Klassen modelliert und können somit ebenfalls noch näher beschrieben werden.
Ersichtlich ist, dass Kochen Ware als Input bekommt und Speise weiterreicht. Kochen ist in einem eigenen Diagramm modelliert. Der Prozess des Kochens beginnt mit neben- läufigen Prozessen. Während gekocht wird, wird auch ein Lied gesungen.
Der nebenläufige Prozess Ein Liedchen singen wird mit einem Flow Final beendet. Das heißt, wenn die Aktion (Singen des Liedes) beendet ist, „stirbt“ dieser Zweig des Prozesses.
Der zweite nebenläufige Prozess beginnt mit dem Vorbereiten der Waren und dem anschließenden Zubereiten der Waren. In die Aktivität Waren zubereiten fließt Ware hinein und Speise wieder hinaus. Hier werden aus Waren Speisen. Ist die Speise ungenießbar, wird sie entsorgt und eine Pizza wird bestellt.
Das Bestellen der Pizza ist eine Send Signal Action und wird von Bestellung entgegennehmen (Receive Signal Action) aufgefangen. Dieses Signal triggert den Start eines unabhängigen weiteren Prozesses, das Backen der Pizza.
Nachdem die Pizza bestellt wurde, wird die Aktivität fernsehen ausgeführt. Dabei wird ein Unterbrechungsbereich (Interruptable Activity Region) betreten. Durch das Betreten der Region werden die in dem Unterbrechungsbereich enthaltenen Receive Signal Action und Time Event Action aktiv, d. h., der Timer beginnt zu laufen und die Receive Signal Action ist bereit, Signale aufzufangen. Hinweis: Befindet sich der Prozessfluss nicht im Unterbrechungsbereich, werden eventuell eintreffende Signale verworfen.
Befinden wir uns im Unterbrechungsbereich und das Signal des Pizza ausliefern (Send Signal Action) trifft ein, verlassen wir den Unterbrechungsbereich und fernsehen wird unterbrochen. Im nächsten Schritt wird die Pizza bezahlt und der Prozessfluss wird zusammengeführt (Merge Node nach dem Decision Node).
Alternativ wird der Unterbrechungsbereich verlassen, wenn die Pizza nicht innerhalb von einer Stunde eintrifft, dann läuft der Timer ab, der Unterbrechungsbereich wird verlassen und ein Butterbrot wird als Alternative gestrichen. Anschließend wird wieder zusammengeführt.
Nachdem die Speise auf den Teller gelegt wurde, ist die Aktivität Kochen beendet.
Durch die Send Signal Action Pizza bestellen wird asynchron ein weiterer Prozess gestartet. Dieser Prozess wird in einem eigenen Diagramm erstellt und erhöht so die Lesbarkeit des Modells.
Durch Anführen der Send und Receive Signal Action Pizza bestellen und Pizzadienst läutet, wird beschrieben, wer auf die gesendeten Signale reagiert.
Die Aktivität Pizza backen kann ebenfalls verfeinert werden, indem sie auf ein Diagramm verlinkt, welches den Prozess Pizza backen detaillierter beschreibt.
