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 Objekteeiner 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.

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 genannt.
  • 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 kann. 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 werden.
    • Anfangs- und Endaktivität heißen jetzt Startknoten und Endknoten.

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.

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.

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 Datastorekö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

Eine Verzweigung des Prozesses wird mittels Rautensymbol (Decision) erreicht. Eine Decision kann beliebig viele ausgehende kanten haben (in der Regel min. 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.

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: Mehre, 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).

Abb. 19 Explizite vs. Implizite Decision

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!

Abb. 20 Mergen

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ühr zu einem blockierten Prozess (dead-Lock). Zwei eingehende Kanten in eine Action/Activity sind nach UML nicht verboten (siehe Abb. 21), die implizite Join Semantik muss allerdings bedacht werden. Um falsche Interpretationen zu vermeiden, sollte auf implizite UML Semantik gänzlich verzichtet werden!

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.

Abb. 21 Splitting und Synchronisation

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 anliegendenKontrolltoken und identische Objekttoken zu einem verschmolzen. Im Gegensatz dazu werden alle anliegenden Objekttoken weitergereicht! Lediglich identische Objekttoken werden verschmolzen und nur einmal weiter gereicht.

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 boder a und c ein Token anliegen. Der Film muss auf jeden Fall ausgesucht werden, wie bezahlt wird, ist egal.

Abb. 22 Join Specification

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.

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!

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

a) um hinreichende Unterteilung um Standardpapierformat einhalten zu können und

b) zur Erzeugung von Detailgliederungen, die in verschiedene Dokumente eingebunden werden und von verschiedenen Verantwortungsträgern freigegeben werden.

Abb. 24 Strukturierte Aktivitäten

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 (Verantwortlichkeits­bereiche) 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 Verantwortlichkeits­bereich. 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 nachfolgende Abb. 25zeigt die Verwendung von Partitions.

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 SignalElement definiert werden.

Das nebenstehende Beispiel zeigt, dass die Aktion Pizza bestellen (eine Send Signal Action) ausgeführt wird und das Signal zum Backen der Pizza in der Pizzeria von der Aktion (eine Receive Signal Action) Bestellung entgegennehmen aufgefangen wird.

Abb. 25 Send/Receive

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!

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.

Abb. 26 Unterbrechungsbereich

Im obigen Beispiel in 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

Aktion

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.

Strukturierte Aktivität

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.

Call Behavior Action

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.

Call Operation Action

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])

Kontrollfluss

 

 

 

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.

Verzweigung, Zusammenführung

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.

Objekt

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

Objektfluss

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] ).

Splitter

Durch Splitting (Fork) kann der Prozessfluss in mehrere nebenläufige Prozessflüsse auf­geteilt werden. Beim Fork wird das eingehende Token (Kontroll- oder Daten-Token) vervielfältigt. Jede ausgehende Kante bekommt ihr eigenes Token.

Synchronisation

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).

Startpunkt

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.

Endpunkt

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

 

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.

Swimlanes/Partition

 

 

Möchte man Zuständigkeitsbereiche imProzessfluss 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 obe­ren Bereich mit dem Namen des zuständigen Elements beschriftet.

Send Signal Action

Ein Send-Signal ist eine Action, die verwendet wird, um während der Ausführung eines Prozesses asynchrone Nachrichten an andere Prozesse zu senden.

Receive Signal Action

Ein Receive Signal ist eine Action, welche auf ein Signal (Event) wartet. Nach Eintreffen des Signals wird die Aktion ausgeführt und der Flow weiter gefü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“.

Time Event

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“.

Interruptable Activity Region

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.

Datastore

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.

Central Buffer Node

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.

Interrupt Flow

 

Ein Interrupt Flow wird verwendet, um eine Interruptable Activity Region zu verlassen.

 

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: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 weiter reicht.

Kochen ist in einem eigenen Diagramm modelliert. Der Prozess des Kochens beginnt mit nebenlä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 Pizzabestellen 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.