In diesem Kapitel wird die Kurzbezeichnung Methode AD für alle Theorieelemente zur Erfassung und Darstellung von Aktivitäten eingeführt. Entsprechend Methode EPK für alle Theorieelemente zur Erfassung und Darstellung von Ereignisgesteuerte Prozessketten.

9.1 Einführung

Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Aktivitäten auf Petrinetzen aufbauende Graphen [OMG 2003a, S. 370].

Graphen

Im vorigen Abschnitt wurde es schon mehrfach angesprochen: Aktionen als elementare Verhaltenseinheiten sind eingebettet in einen größeren Zusammenhang, zu dem sie ihren Beitrag leisten:

• die Aktion Getränkeausgabe ist Teil des Gesamtsystems Getränkeautomat
• eine Aktion Kalkulationsdurchführung kann Teil eines Geschäftsprozesses Angebotserstellung sein

Definition

Den „größeren Zusammenhang“ bilden hier bei der UML die Aktivitäten (activities). Sie beschreiben zusammenhängende Tätigkeitsfolgen. Aufbauend auf dem oben vorgestellten Konzept der Aktionen stellen sie somit Folgen von Aktionen dar. Umgekehrt und im Nachtrag zum vorigen Abschnitt liefern Aktivitäten somit den „Lebensraum“ von Aktionen:

Zusammen-
hängende Tätigkeitsfolgen

„Actions are contained in activities, which provide their context.“ ([OMG 2003a, S. 203], Hervorhebung durch den Verfasser)

Wesentlich für das Konzept der Aktivitäten sind wiederum die Token, die durch die Aktivität fließen und den sog. Tokenfluss ausmachen:

“The semantics of activities is based on token flow.” [OMG 2003a, S. 286]

Das ist der Grund, weshalb in diesem Abschnitt oft von Token und Tokenfluss die Rede sein wird. Vgl. die grundsätzlichen Anmerkungen zum Token-Konzept in Abschnitt 8.6.

Mit Aktivitäten ist es möglich, Folgen von Tätigkeiten zu modellieren, seien es nun Tätigkeiten im Sinne von Geschäftsprozessen („Auftragsabwicklung“) oder im Sinne von Systemverhalten („Karte einziehen, Karte prüfen, usw.). Die UML-Autoren geben im Text und in den Beispielen zahlreiche Hinweise darauf, an welche Arten von Tätigkeitsfolgen sie denken [OMG 2003a, S. 284]:

• Aktivitäten können prozedurale Programmstrukturen beschreiben. Dann sind sie Methoden, die zu bestimmten Operationen von Klassen gehören.
• Aktivitäten können Geschäftsprozesse beschreiben, im Rahmen der Geschäftsprozessanalyse und im Rahmen der Vorgangsbearbeitung[1] (workflow). Dass die UML-Autoren hier tatsächlich an Geschäftsprozesse denken, wird deutlich, wenn sie darauf hinweisen, dass Ereignisse hier oft interne sein können, z.B. die Beendigung einer Aufgabe, aber auch externe, z.B. der Anruf eines Kunden.
• Aktivitäten können auch bei der Modellierung von Informationssystemen benutzt werden, um unterschiedliche „system level processes“ festzulegen.

Aktivitäten vs. Aktionen

Der Zusammenhang zwischen Aktionen und Aktivitäten sollte oben klar geworden sein. Die UML-Autoren fassen ihn wie folgt zusammen [OMG 2003a, S. 283]:

• Eine Aktion stellt einen einzelnen Schritt in einer Aktivität dar, der in dieser Aktivität nicht stärker unterteilt wird.
• Eine Aktivität repräsentiert Verhalten, das aus einzelnen Elementen besteht, die Aktionen sind.
• Eine Aktion ist einfach aus der Sicht der Aktivität, in der sie enthalten ist. Sie kann aber komplex in ihren Auswirkungen sein.
• Eine Aktivität modelliert Verhalten, das an vielen Stellen wiederverwendet werden kann.

Der Kontrollfluss

Die Elemente einer Aktivität, die Aktionen darstellen, werden Aktivitätsknoten genannt. Eine Aktivität besteht dann aus Aktivitätsknoten (activity nodes) und Aktivitätskanten (activity edges). Die Aktivitätskanten sind gerichtet und verbinden die Knoten [Anmerkung] . Mit diesen Knoten und Kanten werden die verschiedenen Flussmodelle dargestellt.

Knoten und Kanten
für Aktivitäten

Mit dem Begriff Fluss ist im Zusammenhang mit Aktivitäten gemeint, dass die Ausführung eines Knotens zur Ausführung anderer Knoten führt. Dies ist das, was gängigerweise mit Kontrollfluss bezeichnet wird. Wie üblich, ist auch hier die Vorstellung die, dass die Kontrolle entlang der Knoten weitergegeben wird: Wenn eine Aktion fertig ist, geht die Kontrolle an die nächste weiter, und so fort.

Kontrollfluss

Die Aktivitätsknoten enthalten „Verhalten“ (behavior) unterschiedlichster Art, z.B. eine Berechnung, den Aufruf einer Operation oder die Bearbeitung von Objektinhalten. Sie können auch Kontrollflusselemente enthalten für die Verzweigung bzw. das Zusammenführen von Kontrollflusszweigen. Diese können durch eine Gleichzeitigkeit von Aktionen, durch Entscheidungen oder durch Parallelverarbeitung verursacht sein.

Aktivitätsknoten etwas genauer

Einführendes Beispiel

Zu Beginn ein einführendes und (hoffentlich) motivierendes Beispiel, das fast alle Elemente von Aktivitäten enthält. Es soll nur einen ersten Eindruck von Aktivitäten als Konstrukt der UML geben. Elemente und Syntax werden danach ausführlich erläutert.

Anmerkung: In der folgenden Abbildung sind einigen Elementen Kreise mit Nummern zugeordnet. Diese gehören nicht zur UML, sondern dienen der Verbindung von erläuterndem Text und Abbildung.

Betrachten wir die Abbildung. Wie zu erwarten war, besteht eine Aktivität aus einer Menge von Aktionen. Eine ist mit (3) markiert. Wie im vorigen Abschnitt schon ausgeführt, stehen die Aktionen in einem Zusammenhang, dargestellt durch die Aktivitätskanten (gerichtete Pfeile). Der einfachste solche Zusammenhang ist das „Aufeinanderfolgen“, dann führt eine Kante einfach von der einen Aktion zur nächsten.

Aktivität = Menge von Aktionen

Dieses „Aufeinanderfolgen“ kann, so deutet es die Stelle (9) an, auch durch Informationen „begleitet“ sein: Beim Voranschreiten der Tätigkeitsfolge von Rechnung senden zu Zahlung durchführen spielt die Rechnung eine Rolle.

Informationen im Fluss

Die Aktivität insgesamt ist zusammenhängend und nach „außen“ abgrenzbar. Dies wird in der Abbildung durch die Grenzlinie ausgedrückt, hier markiert durch (11).

Wie es sich für die Modellierung von Tätigkeitsfolgen gehört, gibt es einen Startpunkt (1), manchmal auch mehrere, und einen Schlusspunkt (2), oder auch mehrere. Diese Aktivität kann aber auch durch einen von außen kommenden Auftrag (15) initiiert werden (Parameterknoten, vgl. unten).

Die Strukturierung kennt, so deutet es das Beispiel an, Entscheidungsvorgänge, z.B. an Position (4). Diese werden später Verzweigung (decision node) genannt. Hier geht es darum, ob der Auftrag angenommen oder abgelehnt wird. Diese beiden Alternativen sind an den Kontrollflusskanten textlich vermerkt (vgl. die Positionen (5) und (6)).

Verzweigung

Es gibt auch „Verschmelzpunkte“, wo unterschiedliche “Zweige” zusammengeführt werden (vgl. (10)). Diese werden später Zusammenführung (merge node) genannt.

Zusammenführung

Auch das von anderen Methoden bekannte gleichzeitige Anstoßen mehrerer Aktionen ist im Beispiel erkennbar, vgl. Position (7). Nach der Ausführung des Auftrags erfolgt zum einen die Lieferung, zum anderen wird die Rechnung versandt. Ein solches Element wird später Gabelung (fork node) genannt.

Gabelung

Sozusagen die Umkehrung zeigt das grafische Element (8). Nur wenn die Lieferung erfolgte und wenn die Zahlung akzeptiert ist, geht es weiter in Richtung Auftrag schließen. Dies führt zu einem Element, das wir später Vereinigung (join node) nennen werden.

Vereinigung

Die Abbildung zeigt auch, dass für eine Aktivität Vor- und Nachbedingungen gestellt werden können. Vgl. (12) und (13).

In der oberen linken Ecke ist noch der Name der Aktivität angegeben (14).

Die obige Aktivität Auftragsbearbeitung enthält folgende Komponenten:

• Eine Verzweigung
• Eine Vereinigung  
• Eine Gabelung   
• Eine Zusammenführung  
• Einen Startknoten
• Einen Schlussknoten Aktivitätsende

Außerdem einen Objektknoten (vgl. unten), der als Input für die Aktivität fungiert.

Soweit das einführende Beispiel. Es wird in diesem Kapitel noch öfters angesprochen und vertieft erläutert.

Insgesamt zeigt es – auch bei oberflächlicher Betrachtung – durchaus einen Aufbau, der für die Modellierung von Tätigkeitsfolgen sinnvoll erscheint.

In Abschnitt 10.11.8 wird – im Rahmen eines Vergleichs der beiden Methoden EPK und AD – zu diesem Aktivitätsdiagramm eine äquivalente Ereignisgesteuerte Prozesskette vorgestellt.

Vergleich
EPK – AD

9.2 Aktivitätsknoten

Es gibt vier Arten von Knoten in Aktivitätsdiagrammen:

• Aktionsknoten (Knoten, die Aktionen repräsentieren oder sog. subordinate units, Gruppen von Aktionen)
• Objektknoten  (Knoten, die Objekte repräsentieren), auch mit Knoten zur Datenspeicherung)
• Parameterknoten (Knoten, die gleichzeitig Objektknoten und Parameter sind)
• Kontrollknoten  (Knoten zur Steuerung des Kontrollflusses).

Die Kontrollknoten sind noch unterteilt in:

• Knoten für Alternativen: Verzweigung und Zusammenführung
• Knoten für „Gleichzeitigkeit“: Gabelung und Vereinigung
• Knoten für den Abschluss: Aktivitätsende und Flussende
• Knoten für den Start: Startknoten

9.2.1 Aktionsknoten

Die Knoten in einer Aktivität, die Aktionen repräsentieren, werden Ak­tionsknoten genannt. Sie repräsentieren Aktionen, wie sie im vorigen Kapitel eingeführt wurden. Im obigen einführenden Beispiel sind also Auftragseingang, Auftrag ausführen, Lieferung, Auftrag schließen, Rechnung senden, Zahlung durchführen und Zahlung akzeptieren Aktionsknoten.

Aktionen in Knoten

Für die Aktivitäten stellen die Aktionen die kleinsten Einheiten für das Systemverhalten dar. Auch wenn die Definition kleinster Einheiten schwierig ist, ist doch eines klar: Das gesamte Verhalten (im Sinne von Systemen) bzw. die gesamte Tätigkeitsfolge (im Sinne von Geschäftsprozessen) von Aktivitäten wird zerlegt in sinnvolle Untereinheiten, die Aktionen – so wie dies bei jeder Modellierung von Abläufen der Fall ist.

Damit stellen Aktivitäten eine Sammlung von sinnvoll in einen Kontrollfluss gepackten Aktionen dar.

9.2.2 Objektknoten

Objektknoten repräsentieren Objekte im Sinne des objektorientierten Ansatzes. Mit ihrer Hilfe werden die in einer Aktivität vorkommenden Objekte erfasst. Die Aufgabe der Objektknoten ist es, den Objektfluss (flow of objects) in einer Aktivität zu modellieren.

Objekte in Knoten

Ein Objektknoten hat einen Typ und kann damit Ausprägungen annehmen. Allerdings nur solche, die dem Typ des Objektknotens entsprechen. Folgende Typen werden unterschieden:

• Objektknoten für Mengen
• Objektknoten vom Typ Signal
• Objektknoten für Objekte in spezifischen Zuständen
• Objektknoten mit einer oberen Grenze
• Objektknoten mit einer von FIFO abweichenden Sortierung

Grafische Darstellung von Objektknoten

Die folgende Abbildung zeigt die grafische Darstellung von Objektknoten: als Rechteck bzw. Sechseck mit einer Bezeichnung, die auch den Typ des Objektknotens angibt. Die mit der Nummer (1) versehene Grafik gibt die Grundform an.

Die Bezeichnung kann auch durch die Angabe des Objektzustandes  genauer gefasst werden. Diese Zustände werden in eckigen Klammern unter die Bezeichnung geschrieben (vgl. das Stichwortverzeichnis für Hinweise auf Beispiele). Obergrenzen (upper bounds) und eine von FIFO (Voreinstellung) abweichende Sortierung werden in geschweiften Klammern unter dem Objektknoten angegeben.

Die Zuordnung der Objekttypen zu den Grafiken gibt der Anmerkungsteil nach der Abbildung an.

Die obige Abbildung zeigt die grafische Darstellung folgender Objektknoten:

• Die Grundform (1)
• Objektknoten für Mengen (2)
• Objektknoten mit Signalcharakter (3)
• Objektknoten für Knoten mit Zuständen (4)
• Objektknoten mit einer oberen Grenze (5)
• Objektknoten mit einer spezifischen Sortierung (6)

Beispiele finden sich unten.

Auswahlverhalten

Es ist möglich, bei Objektknoten eine Auswahl festzulegen. Dies wird Auswahlverhalten (selection behavior) genannt. Es wird in einer Notiz (note symbol) angegeben, angeführt vom Schlüsselwort <<selection>> und an den Objektknoten angefügt, wie es die folgende Abildung zeigt.

Objekte auswählen

Datenspeicher

Ein Objektknoten zur Verwaltung von Informationen ist der sog. Datenspeicher (data store). Wie es der Begriff schon nahelegt, ist es seine Aufgabe, eine Art Pufferknoten für nicht-flüchtige Informationen zu sein (“central buffer node”) [OMG 2003a, S. 318].

Datenspeicher wurden eingeführt, um ältere Formen des Datenflusses zu modellieren. Unter „älteren Formen“ verstehen die UML-Autoren, dass Daten persistent sind und bei Bedarf genutzt werden. Unter neueren Formen, dass die Daten flüchtig (transient) sind und genutzt werden, wenn sie verfügbar sind [OMG 2003a, S. 319].

Anmerkung: vgl. Abschnitt 8.6 für eine Einführung in den Token-Begriff

Der Tokenfluss

Die Rolle der Datenspeicher wird klar, wenn der Tokenfluss betrachtet wird. Ein Datenspeicher behält alle Token, die zu ihm kommen und kopiert sie, wenn sie weiter im Kontrollfluss gehen müssen. Kommt ein Token an, der ein Objekt enthält und gibt es im Datenspeicher bereits einen Token mit diesem Objekt, dann ersetzt der neue Token den alten.

Token, für die es also im Fluss weitergeht, werden kopiert, so dass es so aussieht, als ob die Token niemals den Datenspeicher verlassen.

Die Darstellung ist wie bei Objektknoten, enthält aber die zusätzliche Beschriftung <<datastore>>.

Grafische Darstellung

9.2.3 Parameterknoten

Parameterknoten sind Objektknoten zur Modellierung von Input und Output von Aktivitäten. Da sie im Theoriegebäude der UML gleichzeitig Knoten und Parameter sind, erhielten sie die Bezeichnung „activity parameter node”, hier mit Parameterknoten übersetzt.

Input und Output von Aktivitäten

Parameterknoten haben entweder ankommende oder wegführende Kanten, nicht beides: wenn sie am Anfang der Aktivität stehen, keine ankommenden, wenn sie am Ende stehen, keine weggehenden.

Beispiel – Herstellung von Platinen

Hier liegen folgende Parameterknoten vor:

• Für den Output Defekte Computer und Fehlerfreie Computer.
• Für den Input Material für Produktion.

Der „Fluss“ beschreibt auf einfache und sehr abstrahierte Weise die Herstellung von Computern. Es werden Platinen hergestellt, die Computer zusammengebaut und dann getestet. Am Schluss der Aktivität sind die Computer qualitätsgeprüft mit positivem oder negativem Ausgang.

Die Verzweigung am Schluss entspricht einem exklusiven Oder, das hier ohne Operator realisiert ist.

Die obige Abbildung enthält folgende Knoten:

• Einen Parameterknoten für den Input
• Zwei Parameterknoten für den Output

Außerdem mehrere Objektknoten, die physische Objekte repräsentieren.

Parameterknoten erlauben auch die Spezifizierung durch streaming (vgl. Abschnitt 10.5.4) und durch Ausnahmen (vgl. Abschnitt 10.5.5). Vgl. Abbildung 10.5-16 für das obige Beispiel, ergänzt um die beiden Konzepte.

Streaming und Ausnahmen

Anmerkung zur Gliederung: Bevor die Betrachtung der Knoten mit den strukturierten Aktivitätsknoten und den Kontrollknoten fortgesetzt werden kann, müssen nun erst die Kanten eingeführt werden.

9.3 Aktivitätskanten

Es gibt zwei Arten von Kanten in Aktivitätsdiagrammen (Aktivitätskanten):

• Kontrollflusskanten (control flow edges)
• Objektflusskanten (object flow edges)

9.3.1 Kanten für den Kontrollfluss

Wie oben ausgeführt und im einführenden Beispiel gezeigt, wird der Kontrollfluss durch Kanten (edges) zwischen den Aktivitätsknoten ausgedrückt. Eine solche Aktivitätskante wird durch eine Pfeillinie zwischen je zwei Aktivitätsknoten dargestellt. Hat die Kante eine Gewichtung, wird diese in geschweiften Klammern angegeben. Hat sie eine Beschriftung, wird diese ebenfalls bei der Kante vermerkt. Vergleiche die folgende Abbildung für eine einfache Kante, eine mit Gewichtung und eine mit Beschriftung.

Die Kanten und ihre Darstellung

Über eine Aktivitätskante kann zu einem Zeitpunkt eine beliebige Anzahl von Token passieren. Die Gewichtung  schreibt die Mindestanzahl von Tokens vor, die zur selben Zeit über die Kante gehen müssen. Das ist eine Festlegung, die jedesmal überprüft bzw. berechnet wird, wenn ein neuer Token für die Quelle zur Verfügung steht.

Gewichtung

Das Ergebnis der Prüfung muss eine positive ganze Zahl oder Null sein. Wenn die Mindestzahl von Token vorhanden ist, werden alle Token der Quelle dem Ziel auf einmal angeboten.

Ein eventueller Wächter (Guard, vgl. Exkurs unten) muss für alle Token den Wert wahr ergeben. Klappt dies nicht und fällt dadurch die Zahl der dem Ziel angebotenen Token unter die Gewichtung, werden gar keine Token angeboten.

Wächter

Eine Gewichtung von Null (null weight) bedeutet, dass alle Token der Quelle dem Ziel angeboten werden.

Beispiele

Das folgende Beispiel spiegelt den Sachverhalt wider, dass beim Zusammenstellen einer Fußballmannschaft insgesamt 11 Spieler zu finden sind.

Das zweite Beispiel enthält eine Gewichtung, die durch ein Attribut angegeben wird. Damit wird der Sachverhalt erfasst, dass erst alle Teilaufgaben erledigt sein müssen, bevor die Rechnung dafür versandt wird.

Exkurs: Wächter (guards)

Hier und im weiteren wird ein Konzept benötigt, das die UML-Autoren guard bzw. guard condition nennen und das hier mit Wächter übersetzt wird. Dabei handelt es sich um Bedingungen, die geprüft werden, bevor ein bestimmter Schritt gegangen wird.

Bei Entscheidungsknoten (vgl. unten) haben z.B. die wegführenden Kanten Wächter, die festlegen, mit welcher Kante die Token „weiterziehen“. Bei Transitionen (vgl. Kapitel 13) wird durch Wächter bestimmt, ob sie „feuern“ dürfen, usw.

Es handelt sich dabei i.d.R. um einfache mathematische oder andere logische Ausdrücke wie z.B. „x<10“.

Wie oben schon gezeigt, können Aktivitätskanten auch beschriftet werden. Eine solche Bezeichnung beschreibt das Ergebnis der vorangehenden Aktion. Die UML-Autoren betonen, dass diese Bezeichnung innerhalb der Aktivität nicht eindeutig sein muss.

Beschriftung von
Aktivitätskanten

Beispiel

Zwei Aktionen, Paket packen und Paket versenden, sind durch eine beschriftete Kante verbunden. Die Bedeutung ist wie folgt: Wenn die Aktion Paket packen erledigt ist, wird die Aktion Paket versenden angestoßen und ausgeführt. Die Kantenbeschriftung drückt dann das Ergebnis der vorangegangenen Aktion aus.

Bei der Darstellung eines Kontrollflusszweiges ist es auch möglich, Verknüpfer (Konnektoren / connectors) einzufügen. Dies geschieht durch einen Kreis, der eindeutig bezeichnet ist (im Rahmen des jeweiligen Modells) und der die Rolle der Zielaktion auf der einen Seite und die der Ausgangsaktion auf der anderen Seite übernimmt.

Verknüpfer

Dieses Element erlaubt z.B. die grafische Aufteilung großer Aktivitäten, ähnlich wie mit Prozesswegweisern bei Ereignisgesteuerten Prozessketten (vgl. [Staud 2006, Abschnitt 4.7]).

Der Tokenfluss

Die in den obigen Beispielen vorhandenen Kontrollkanten bilden nur den Kontrollfluss ab, nichts anderes. Über sie können nur Kontrolltoken passieren.

Nur Kontrolltoken

Sollen Objekte oder Daten transportiert werden, bedarf es der Objektflusskanten, die im nächsten Abschnitt vorgestellt werden.

9.3.2 Kanten für den Objektfluss – Objektflusskanten

Objektflusskanten (object flows bzw. object flow edges) sind ebenfalls Aktivitätskanten, aber solche, über die Objekte oder Daten passieren können. Sie modellieren also den Fluss von Daten und von Objekten in einer Aktivität.

Es gibt somit in Aktivitäten zwei verschiedene „Flüsse“: die Kontrollflüsse und die Objektflüsse. Diese Trennung ist unabdingbar, die beiden Flüsse stellen unterschiedliche, wenn auch zusammenhängende, Aspekte dar. Der Zusammenhang ergibt sich daraus, dass beide Flüsse auf denselben in der Aktivität erfassten Aktionen ablaufen.

Zwei „Flüsse“ auf denselben Aktionen

Die Trennung zwischen Kontroll- und Datenflüssen ist strikt: Alle Kanten, die zu Objektknoten führen oder weggehen, müssen Objektflusskanten sein.

Es gibt unterschiedliche grafische Darstellungsformen für Objektflüsse und Objektflusskanten. Hier die erste. Bei dieser werden die Kanten nicht direkt zwischen den beiden Aktionen (oder subordinate behaviors) angeordnet, sondern über einen Objektknoten geführt, der das zu transportierende Objekt repräsentiert. Die erste Kante führt von der ersten Aktion zum Objekt, die zweite vom Objekt zur zweiten Aktion.

Notation 1

Beispiel

Das Beispiel zeigt einen Objektknoten Auftrag im Objektfluss, der Objekte der Klasse Aufträge enthält. Die Aktion Auftrag ausführen erzeugt ausgeführte Aufträge, Auftrag versenden „verbraucht“ diese. Der Aufruf von Auftrag ausführen muss beendet sein, dann kann Auftrag versenden beginnen.

Weiter unten wird gezeigt, wie diese Situation mit Pins und ihren Symbolen dargestellt wird.

Das folgende Modellfragment (aus dem einführenden Beispiel) zeigt deutlich die Absichten der UML-Autoren mit diesem Konzept. Die Aktion Rechnung senden bewirkt einen Transportvorgang des Objekts Rechnung (vom Unternehmen zum Kunden!), der die Aktion Zahlung durchführen anstößt.

9.3.3 Objektflüsse und Pins

Oben (in Abschnitt 9.5) wurde schon das Konzept der Pins eingeführt. Jetzt kann es vertieft werden.

Ein Pin repräsentiert einen Objektknoten, der den Input und den Output von Aktionen modelliert. Er hält also fest „was“ in die Aktion hineinfließt und „was“ aus ihr herauskommt (für dieses „was“ haben die UML-Autoren das Konzept der Token).

Ist die Aktion ein Aufruf, die UML-Autoren sprechen dann von einer aufrufenden Aktion (invocation action) (vgl. oben), dann müssen die Anzahl von Pins und deren Typen gleich sein wie die Anzahl Parameter und die Typen des aufgerufenen Verhaltens oder der Verhaltenseigenschaft (behavioral feature). Die Pins werden nach ihrer Reihenfolge auf die Parameter abgebildet.

Beispiele

Das folgende Beispiel zeigt denselben Vorgang wie oben, jetzt aber mit ausdrücklich ausgewiesenen Objektknoten-Pins (object node pins) und ihren Symbolen. Die Pinsymbole repräsentieren beim linken Knoten das zur Verfügung gestellte und abgehende Objekt, auf der rechten Seite das geforderte und empfangene Objekt.

Die Pins werden grafisch durch Rechtecke angedeutet und mit dem Namen des Objekts beschriftet.

Die folgende Abbildung zeigt, wie mehrere Objektflüsse zwischen zwei Aktionen bei dieser Notation dargestellt werden. Im Beispiel geht es um einen Auftrag bzgl. einer Maschine. Zuerst werden die Teile beschafft, dann wird die Maschine zusammengebaut. Der Objektfluss besteht zum einen in der Weitergabe des Auftrags, zum anderen in der Weitergabe der Teile.

Noch ein
Transportvorgang

Auch dieses Beispiel macht deutlich, dass die UML-Autoren mit diesem Konzept tatsächlich reale Transportvorgänge von physischen und digitalen Objekten meinen.

Das dritte Beispiel verdeutlicht die Verwendung von mehreren Pins. Folgendes wird mit Hilfe der Pins „transportiert“:

• Aufträge
• Teile
• PC Designs

Die Abbildung zeigt auch anschauliche Beispiele für den Zustand (state) von Objekten und deren Änderung.  Das Objekt Auftrag ändert ihn vom Anfangszustand (beim Eingang des Auftrags) in Auftrag [akzeptiert] und am Schluss in Auftrag [zusammengebaut]. Die Zustandsänderung wird also in eckigen Klammern angeboten.

Zustand (state) von Objekten

Zustände und ihre Änderungen sind wesentliche Aspekte von Zustandautomaten, die in Kapitel 13 besprochen werden.

Bleibt noch der Zusatz {stream} bei dem Pin / Objektkknoten PC-Designs. Dieses streaming-Konzept wird in Abschnitt 10.5-4 erläutert.

Der Ablauf

Das kleine Fragment aus einem größeren Geschäftsprozess zeigt, dass die Aktion Auftrag zusammenbauen insgesamt drei Objekte über ihre drei Input-Pins erhält: Auftrag, Teile, PC-Design. In der Aktion wird dann der Zusammenbau vorgenommen und der Output-Pin trägt das Objekt Auftrag [zusammengebaut].

Tokenfluss

Token sind hier dann zum einen Kontrolltoken, die das „Weitergehen“ im Kontrollfluss modellieren, zum anderen die angeführten Objekttoken.

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Mehrere Input-Pins
• Mehrere Output-Pins

Außerdem eine streaming-Festlegung.

Kurznotation

Neben obiger grafischer Darstellung führen die UML-Autoren auch eine optionale Kurznotation ein. Diese greift, wenn der Output-Pin einer Aktion mit einem gleichnamigen Input-Pin einer anderen Aktion verbunden ist. Dann kann dies unter Verwendung nur eines Symbols wie in der folgenden Abbildung ausgedrückt werden. Der „standalone pin“, so wird er genannt, steht dann gleichzeitig für einen Output-Pin und ein Input-Pin.

Auch die Darstellung mit nur einem Rechteck als Symbol für das Objekt wird von den UML-Autoren als standalone pin bezeichnet.

Ohne Kanten

Stehen inhaltlich und damit auch für die grafische Darstellung keine Kanten zur Verfügung, ist die in der folgenden Abbildung gezeigte Ersatzdarstellung möglich. Dabei werden Pfeile in das Rechteck des Pin gezeichnet. Weist der Pfeil zu der Aktion, handelt es sich um einen Input-Pin, weist der Pfeil weg von der Aktion um einen Output-Pin.

Mit Klassendiagramm

In der Abbildung unten wird der Objektknoten Auftrag durch einen Ausschnitt aus einem Klassendiagramm näher erläutert. Das Klassendiagramm zeigt, dass zu einer Auftragsausführung in Wirklichkeit drei Dinge gehören:

• ein Auftrag
• Auftragspositionen und
• die Anforderungen des Kunden an den Versand, hier kurz Abwicklung genannt.

Mit Auswahl (Auswahlverhalten)

Eine Auswahl mittels Auswahlverhalten kann nicht nur auf die Kanten gelegt werden, sondern auch auf die Pins. Dies geschieht wiederum mit dem Schlüsselwort <<selection>> in einem Anmerkungssymbol und durch Anbindung mittels einer gestrichelten Linie.

Beispiele

Die ersten beiden Abbildungen zeigen eine Auswahl, die bei den Objektknoten vermerkt ist. Es sind zwei Darstellungen einer Situation, in der verlangt ist, dass die Aufträge nach ihrer Priorität ausgeführt und bei gleicher Priorität nach dem FIFO-Prinzip (first in/first out) behandelt werden.

Die folgenden Beispiele zeigen die Festlegung der Auswahl über den Objektfluss. Das erste stimmt inhaltlich mit den obigen überein.

Im folgenden Beispiel erfasst die linke Aktion das Beendigen der Arbeit an einem Auftrag. Daraus entstehen Objekte des Typs abgeschlossener Auftrag. Durch die Notwendigkeit, dem Kunden eine Notiz zu senden (ausgedrückt durch die entsprechende Aktion), wird ein Objekt Kunde benötigt. Die <<transformation>> legt nun fest, dass eine Abfrage mit Hilfe des jeweiligen Auftrags das Kundenobjekt bestimmt.

Die obige Abbildung enthält u.a. ein Objekt mit Zustand, zwei Pins und einen Hinweis auf die Verarbeitung der Daten (transformation).

Das dritte Beispiel zeigt eine Spezifizierung von Objekten. Es wird ausgedrückt, dass die Aktion Auftrag erteilen Objekte des Typs Auftrag erzeugt und dass die Aktion Auftrag ausführen diese liest und dann ausführt.

Das obige Beispiel enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Zwei Objekte mit Zuständen.
• Mehrere Pins

Außerdem zwei Spezifizierungen von Objekten.

9.3.4 Ständiger Fluss mit „streaming“

Bindet man eine Aktion in den Kontrollfluss bzw. einen Objekt- oder Parameterknoten in den Objektfluss ein, dann modelliert man konkret folgendes:

• Eine Aktion wird einmal aktiv, dann geht es weiter zum nächsten Element (Kontrollknoten, Aktion, Parameterknoten).
• Ein Objekt dient bei Parameterknoten entweder genau einmal als Input oder genau einmal als Output.
• Ein Objekt dient als Objektknoten im Objektfluss genau einmal (vgl. die Beispiele mit dem Objekt „Rechnung“ u.a. in den Abbildungen 10.3-1 und 10.5-7).

Mit dem Konzept des streaming bietet die UML nun die Möglichkeit, einen ununterbrochenen regelmäßig ablaufenden Fluss von Aktionen, Objektknoten und Parameterknoten zu modellieren.

Aktiv bleiben

Bei Aktionen

Die Vorstellung ist hier, dass die betreffende Aktion nicht nur einmal Input annimmt, ihre Aufgabe ausführt und Output abgibt, sondern dass es regelmäßig weitergeht. Eine Aktion bleibt also ständig weiter aktiv. Die UML-Autoren nennen dies fortgesetztes Verhalten (continuous behavior).

Innere Schleife

Streaming erlaubt somit einer Aktion (im Rahmen ihrer Aktionsausführung) Input anzunehmen und Output abzugeben während sie bereits aktiv ist. Somit kann die Aktion während einer Ausführung mehrere Token annehmen und abgeben, an einem Pin oder auch an mehreren.

In der grafischen Notation wird dies durch die textliche Anmerkung {stream} bei der Aktion, dem Parameterknoten oder dem Objektkknoten ausgedrückt. Falls die PIN-Notation gewählt wurde, kommt die Anmerkung in die Nähe des Pin-Symbols. Die Voreinstellung ist in allen Fällen „nonstream“.

Bei Objekten in Parameterknoten

Bei Objekten in Parameterknoten ist die Bedeutung wie folgt:

• Bei Input: Das Objekt kommt ständig an, wird ständig in den Fluss „reingereicht“. Vgl. Abbildung 10.5-24 für ein Beispiel.
• Bei Output: Das Objekt wird ständig erzeugt und nach „außen“ weitergereicht.

Beispiele

Oben im Beispiel der Abbildung 10.5-10 war eine Aktion mit dem Zusatz {stream} enthalten. Die Aktion Design erstellen erstellt nicht nur ein einzelnes Objekt PC Design, sondern ständig neue und bietet sie auf seinem Outputtoken an. Die Aktion Auftrag zusammenbauen nimmt sich dann die Objekte PC Designs wie sie sie benötigt.

Im folgenden Beispiel ist Auftrag ausführen ein ständiger Vorgang, der in regelmäßigen Abständen Objekte des Typs Auftrag [ausgeführt] erzeugt. Der Auftragsversand ist ebenfalls ein ständiger Vorgang, der regelmäßig die ausgeführten Aufträge erhält und dann den Auftragsversand realisiert.

Die obige Abbildung enthält zwei Beispiele für streaming und ein Objekt mit Zustandsfestlegung.

Die entsprechende Darstellung mit den Pinsymbolen zeigt die folgende Abbildung.

Die obige Abbildung enthält zwei Beispiele für streaming mit Pins.

Es gibt auch die Möglichkeit, streaming mit der Kante grafisch auszudrücken. Dabei wird dann entweder die Pfeilspitze der Kanten schwarz eingefärbt oder die Rechtecke der Pins (vgl. [OMG 2003a, S. 358f]).

9.3.5 Ausnahmen modellieren

Es stört doch sehr, dass bei den Aktionen im Regelfall nur das positive Ergebnis einer Aktion modelliert wird. Das haben wohl auch die Autoren der UML gemerkt und deshalb zumindest für „Ausnahmen“ eine Modellierungsmöglichkeit geschaffen, die Ausnahmeanmerkung (exception notation). Sie bedeutet, dass eine zusätzliche wegführene Kante angelegt wird (ohne Operator!), die eine Ausnahme erfassen soll. In der grafischen Darstellung wird dies beim jeweiligen Pin durch ein Dreieck vermerkt.

Nur das positive Ergebnis

Die zwei folgenden Abbildungen zeigen ein Beispiel in zwei verschiedenen Notationen. Die Aktion Zahlungsannahme hat die zwei Pins akzeptierte Zahlung und zurückgewiesene Zahlung. Zahlungsannahme führt normalerweise zu einer Zahlung, die akzeptiert wird und dem Konto gutgeschrieben wird. In Ausnahmefällen ist es jedoch möglich, dass die Zahlung zurückgewiesen wird, z.B. weil sie nicht korrekt ist. Dies wird dann durch das Dreieck an der jeweiligen Kante beim Pin vermerkt.

Ausnahme
zurückgewiesene Zahlung

Die folgende Darstellung ist diejenige, die die Objektknoten im Objektfluss angibt. Auch hier wird die „Ausnahmekante“ durch ein Dreieck markiert.

Die obigen beiden Abbildung enthalten u.a. folgende Komponenten:

• Zahlreiche Pins
• Eine Ausnahmeanmerkung
• Objektknoten im Objektfluss

Außerdem Verzweigungen mit exklusivem Oder ohne Operatorsymbol.

Diese zweite Kante führt – bezogen auf die Aktion – zu einer impliziten nicht grafisch ausgedrückten Verknüpfung mit einem exklusiven Oder. Zusätzlich wird die Information weitergegeben, dass der eine Fall nur in Ausnahmefällen eintritt.

Exlusives Oder

Beispiel – Streaming und Ausnahme

Das folgende Beispiel nimmt das aus Abbildung 10.4-4 wieder auf und ergänzt es um die beiden Konzepte streaming und Ausnahme.

Der Zusatz {stream} bei dem Parameterknoten Material für Produktion bedeutet (vgl. oben), dass es einen ständigen Fluss von Produktionsmaterial gibt, wodurch die ständig weitergehende Herstellung von Platinen gespeist wird.

Die Festlegung einer Ausnahme verlangt ja mindestens zwei Kanten, wovon dann eine die Kennzeichnung als Ausnahme erhält. Im folgenden Beispiel beschreibt die eine Kante das Standardergebnis, das zu Computern ohne Fehler führt. Der andere Parameterknoten repräsentiert das Ausnahmeergebnis, dass ein Computer fehlerhaft ist. Dies wird durch ein Dreieck festgehalten. Auch der entsprechende Output-Parameterknoten wird so markiert.

Die obige Abbildung enthält ein Aktivitätsdiagramm mit folgenden Komponenten:

• Einen Parameterknoten mit streaming
• Eine Ausnahmeanmerkung
• Mehrere Objektknoten im Objektfluss

Außerdem eine Verzweigung mit exklusivem Oder ohne Operatorsymbol.

9.3.6 Abgrenzung zwischen den Kantenarten

Die UML-Autoren betonen die Abgrenzung von Kontroll- und Objektfluss sehr stark, ja sie haben sogar den Objektfluss als Ausgangspunkt, wenn sie ausführen, das das Konzept des Kontrollflusses eingeführt wurde, um die Abfolge von Verhalten in den Fällen modellieren zu können, wo keine Objekte fließen [OMG 2003a, S. 316].

Am Anfang war der Objektfluss

Zusammengefasst gilt, dass Objekte und Daten nicht über eine Kontrollflusskante gelangen können (ebenda, S. 315), d.h., Kontrollflüsse dürfen keinen Objektknoten an einem ihrer Enden haben. Dies greift auch bzgl. der im nächsten Abschnitt vorgestellten Kontrollknoten (Operatoren). Die Kanten, die zu einem Kontrollknoten hin- oder wegführen, sind entweder alle Objektflüsse oder alle Kontrollflüsse. Eine Vermischung ist nicht zulässig [OMG 2003a, Seite 317].

Obiges gibt einen guten Einblick in die Philosophie der UML-Autoren. Hier war – entsprechend der Kernaufgabe Systemanalyse und Systemdesign – und entsprechend der dafür notwendigen elementaren Beschreibungsebene tatsächlich der Objektfluss “zuerst da” und sozusagen im Zentrum der Betrachtung. Der Kontrollfluss kam dann später dazu.

Am Anfang:
Objektflüsse

9.4 Strukturierte Aktivitätsknoten

Sie tragen zwar die Bezeichnung Knoten, sind aber tatsächlich auch Aktivitäten, allerdings solche, die in anderen, größeren enthalten sind und dort ähnlich wie ein Knoten wahrgenommen werden.

Knoten mit Inhalt

Diese sog. strukturierten Aktivitätsknoten stellen eine Gruppierung von zusammengehörigen und zusammenwirkenden Aktionen dar. Es sind, aus der Sicht „ihrer“ Aktivität, ausführbare Knoten, die in sich untergeordnete Knoten als activity group enthalten.

Es kann Kontrollkanten und Pins geben, die mit ihm, dem strukturierten Aktivitätsknoten, verbunden sind. Die Ausführung jeder in ihn eingebetteten Aktion kann erst beginnen, wenn der strukturierte Aktivitätsknoten seine Objekt- und Kontrolltoken erhalten hat. Die Outputtoken des strukturierten Aktivitätsknotens stehen erst zur Verfügung, wenn alle eingebetteten Aktionen fertig sind.

Wofür wird ein solches Konzept benötigt? Für ein allgemeines grundsätzliches Problem jeder Modellierung von Tätigkeitsfolgen, der Bewältigung unterschiedlicher Detaillierungsgrade. Durch die strukturierten Aktivitätsknoten kann, rekursiv auch in mehreren Ebenen, in einem Aktivitätsknoten eine kleinere Aktivität definiert werden, in einem Knoten dieser wieder eine, usw. Somit können verschachtelte Strukturen entstehen.

Wofür?

Dies kann z.B. dazu benutzt werden, auf der obersten Ebene eher globale Knoten anzulegen, die dann in einem oder in mehreren Schritten verfeinert werden.

Eine weitere eher auf die technische Realisierung von Software zielende Begründung führen die UML-Autoren an. Dabei geht es um Probleme mit der Parallelverarbeitung.

Bewältigung
Parallel-
verarbeitung

Bei der Ausführung von Aktionen in Aktivitäten und darüber hinaus können sich Fragen bzgl. der Parallelverarbeitung stellen. Z.B. kann es schwierig sein, Zugriff und Änderung des Objektspeichers fehlerfrei zu gestalten.

Um dies zu realisieren, kann es sinnvoll sein, die Effekte einer Gruppe von Aktionen von den Effekten anderer Aktionen zu isolieren. Dies wird ermöglicht durch die Gruppierungsmöglichkeit als strukturierter Aktivitätsknoten und dadurch, dass ein Attribut desselbigen, mustIsolate, auf wahr gesetzt wird.

Ist ein strukturierter Aktivitätsknoten auf diese Weise isoliert, dann kann auf kein Objekt, das bei einer Aktion in diesem Knoten benutzt wird, von einer Aktion von außerhalb zugegriffen werden, bis der strukturierte Aktivitätsknoten als Ganzes fertig ist.

Irgendwelche parallelen Aktionen, die zu Zugriffen auf solche Objekte führen könnten, müssen ihre Ausführung verschieben, bis der Knoten fertig ist.

Wie wird eine solche Isolation erreicht und wie werden damit Probleme mit der Paralellverarbeitung vermieden? Z.B. durch Sperrmechanismen oder durch Sequentialisierung (in eine Reihenfolge bringen) der Ausführung.

Ein solches Element verlangt nach der Einhaltung bestimmter Regeln. Hier die wichtigsten:

Regeln

• Strukturierte Aktivitätsknoten dürfen sich nicht überlappen, die Knoten des einen dürfen nicht zu einem anderen gehören.
• Sie dürfen verschachtelt sein.
• Die Kanten eines strukturierten Aktivitätsknotens müssen ihre Quell- und Zielknoten innerhalb des strukturierten Aktivitätsknotens haben.
• Kein Unterknoten des strukturierten Knotens darf mit der Ausführung beginnen, bevor der Knoten selbst einen Kontrolltoken verbraucht hat.
• Ein Kontrollfluss von einem strukturierten Aktivitätsknoten weg bedeutet: Ein Token wird nur dann produziert, wenn keine Token in dem Knoten oder in denen, die er rekursiv enthält, mehr übrig sind.

Zugriff

Außerdem gilt, dass auf einen Objektknoten, der in einem strukturierten Aktivitätsknoten enthalten ist, nur innerhalb des Knotens zugegriffen werden kann. Es gelten dieselben Regeln wie für Kontrollflüsse. Ein Input-Pin auf einem strukturierten Aktivitätsknoten bedeutet, dass im Knoten keine Aktion mit der Ausführung beginnen darf, bis alle Input-Pins Token erhalten haben. Ein Output-Pin auf einem strukturierten Aktivitätsknoten macht erst dann Token nach außen verfügbar, wenn keine Token in ihm und in den Knoten, die er rekursiv enthält, zurückbleiben.

Verschachtelung – Ebenen

Insgesamt entstehen so z.B. drei Ebenen bei der Beschreibung von Abläufen: Aktionen, strukturierte Aktivitätsknoten und Aktivitäten. Aktionen sind die Elementarbestandteile, strukturierte Aktivitätsknoten die erste Gruppierung von sinnvoll miteinander agierenden Aktionen (die erste Aggregation), Aktivitäten dann die Gesamtheit (die zweite Aggregation). Die UML-Autoren sprechen hier auch von verschachtelten Knoten.

Drei Ebenen der Prozess- bzw.
Unternehmens-
modellierung

Grafische Darstellung

Ein strukturierter Aktivitätsknoten wird durch ein Rechteck rund um seine Knoten und Kanten dargestellt. Das Rechteck hat eine gestrichelte Linie und runde Ecken. Am oberen Rand wird das Schlüsselwort <<structured>> angefügt.

9.5 Kontrollknoten

Die Kontrollknoten dienen der Strukturierung des Kontrollflusses innerhalb der Aktivität. Sie haben somit immer mit Aktivitätskanten zu tun, die zu ihnen hin- oder von ihnen wegführen und die sie der Logik eines Verknüpfungsoperators unterwerfen.

Hinführende und wegführende Kanten

Auch wenn die Begrifflichkeit der UML-Autoren eine andere ist, so definieren sie doch ein exklusives ODER. Ist es verzweigend, kommt also eine Kante an und und gehen mehrere weg, wird es Verzweigung genannt. Ist es verknüpfend, kommen also mehrere Kanten und geht nur eine weg, wird es Zusammenführung genannt.

Exklusives Oder

Ebenso liegt ein logisches UND vor. Ist es verzweigend, wird es Gabelung genannt, ist es verknüpfend Vereinigung.

UND

Weiter gibt es Knoten, die das Ende von Aktivitäten signalisieren. Für die gesamte Aktivität Aktivitätsende (activity final), für einzelne Kontrollflüsse Flussende (flow final). Ein letzter Knoten, der Startknoten (initial node), gibt einen Startpunkt der Aktivität an.

Die folgende Abbildung gibt eine Gesamtübersicht und zeigt die grafischen Grundelemente:

• Die Raute für Verzweigung und Zusammenführung.
• Der Balken für Gabelung und Vereinigung.
• Der gefüllte Punkt für den Startknoten.
• Der Kreis mit innerem Punkt für den Knoten Aktivitätsende.
• Der Kreis mit einem Kreuz im Inneren für den Knoten Flussende.

9.5.1 Verzweigung

Eine Verzweigung (decision node) repräsentiert eine exklusiv-ODER-Verknüpfung in den wegführenden Kanten, d.h., die wegführenden Kanten sind alternativ. Semantisch bedeutet dies, dass die Kanten alternative Aktionen ansteuern.

Die grafische Darstellung geht von einer Raute aus. Eine Kante führt hin, mehrere führen weg.

Grafische Darstellung

Im Beispiel der folgenden Abbildung kommt nach der Aktion Auftragseingang die Prüfung, ob der Auftrag angenommen oder abgelehnt wird. Diese ist durch die Verzweigung modelliert. Die alternativen Ergebnisse der Prüfung werden an die weiterführenden Kanten geschrieben. Diese stoßen dann jeweils eine entsprechende Aktion an: Auftrag ablehnen bzw. Auftrag annehmen.

Beispiel

Es kann auch eine Bedingung für den Entscheidungsprozess definiert werden. Diese wird decision input behavior genannt, in einer Notiz angegeben und durch das Schlüsselwort <<decisionInput>> gekennzeichnet. Vgl. die folgende Abbildung.

Variante

Ein decision input behavior hat einen Inputparameter und einen Outputparameter. Der Inputparameter muß zu dem Objekttoken (object token) passen, der über die hinführende Kante ankommt. D.h., er muß vom selben Typ sein. Das decision input behavior darf keine Seiteneffekte haben.

In Abbildung 10.12-2 findet sich ein Beispiel. Dort ist die Bedingung für den Entscheidungsknoten, dass der Lagerbestand kleiner ist als die Nachbestellmarke.

Jeder Token, der bei einem Entscheidungsknoten ankommt, kann nur zu einer der wegführenden Kanten gelangen (dies entspricht dem exklusiven Oder). In der Sprache der UML-Autoren: Die Token werden nicht vervielfältigt.

Tokenfluss nur zu einer Kante

Die hinführenden Kanten bieten den wegführenden Kanten die Token an. In der Regel bestimmen die Wächter der wegführenden Kanten, mit welcher von ihnen es weiter geht. Die Reihenfolge, in der die Wächter ausgewertet werden, ist nicht definiert. Der Modellierer sollte es so einrichten, dass jedes Token nur für eine einzige wegführende Kante gewählt werden kann, um eine „Wettlaufsituation“ (vgl. Abschnitt 10.10-6 und dort Abbildung 10.10-7) zwischen den wegführenden Kanten zu vermeiden [OMG 2003a, S. 320].

Für den Fall, dass keine der wegführenden Kanten einen Token akzeptiert, sollte ein „Else-Wächter“ definiert werden (für höchstens eine Kante). Dieser kommt also dann zu Wirkung, falls der Token von allen anderen wegführenden Kanten nicht akzeptiert werden kann. Das entspricht der üblichen Restkategorie, die bei solchen Verzweigungen immer berücksichtigt werden muss, bzw. dem Else-Zweig in der Programmierung von Verzweigungen.

Restkategorie – Else

Falls Bedingungen für den Entscheidungsknoten durch ein decision input behavior definiert sind, wird jeder Token zuerst bezüglich dieser Bedingungen geprüft, bevor der Abgleich mit den Wächtern der wegführenden Kanten erfolgt. Das Ergebnis dieser Prüfung steht den Wächtern zur Verfügung.

Tokenfluss bei
decision input
behavior

Decision input behaviors wurden eingeführt, um redundante Neuberechnungen in Wächtern zu vermeiden.

9.5.2 Zusammenführung

Eine Zusammenführung (merge node) repräsentiert eine exklusive Oder-Verknüpfung in den hinführenden Kanten, d.h., die hinführenden Kanten sind alternativ. Es handelt sich somit um einen Kontrollknoten, zu dem mehrere Aktivitätskanten hinführen und von dem genau eine wegführt.

Verschmelzer

Seine Aufgabe ist es, Kontrollflusszweige, die zuvor z.B. im Rahmen einer Verzweigung aufgeteilt wurden, wieder zusammenzuführen.

Grafische Darstellung

Die grafische Darstellung geht wiederum, wie bei einer Verzweigung, von einer Raute aus. Hier kommen nun aber zuführende Aktivitätskanten und genau eine wegführende dazu.

Beispiel

Im folgenden Beispiel (vgl. dazu das EPK-Beispiel in [Staud 2006, Abbildung 4.4-29]) erfolgt der Versand einer Paketsendung entweder mit DHL, mit DPS oder mit UPS. Anschließend wird die Rechnungsstellung angestoßen.

Der Tokenfluss

Alle Token der ankommenden Kanten werden den wegführenden angeboten. Da immer nur eine hinführende Kante aktiv wird, wird genau ein Token weitergereicht.

Zusammenführung + Verzweigung

Es kommt vor, dass eine Zusammenführung und eine Verzweigung unmittelbar hintereinander folgen. Dann können die beiden Knoten grafisch zusammengefasst werden, wie es die folgende Abbildung zeigt.

In Bezug auf die Semantik bedeutet dies, dass in einer konkreten Situation genau eine der ankommenden Kanten aktiv wird und dass der Kontrollfluss zu genau einer der wegführenden Kanten führt.

Beispiel

Die Situation im folgenden Fragment kann man sich wie folgt vorstellen: Ein Handelshaus hat einen Teil der Kunden schon auf Rechnungen umgestellt, die per E-Mail verschickt werden. Die meisten erhalten aber die Rechnung noch per Brief. Wenn dann eine Paketsendung fertig und verschickt ist, muss entschieden werden, auf welche Weise anschließend die Rechnung verschickt wird.

9.5.3 Gabelung

Ein Gabelung (fork node) repräsentiert eine Und-Verknüpfung in den wegführenden Kanten, d.h., alle wegführenden Kanten werden aktiviert, wenn der Kontrollfluss beim Knoten ankommt.

Gabelungen wurden eingeführt, um Parallelität von Kontrollflusszweigen in Aktivitäten modellieren zu können.

Grafische Darstellung

Die grafische Darstellung geht von einem Balken aus. Hier kommen nun aber eine zuführende und mehrere wegführende Aktivitätskanten dazu.

Beispiel

Im folgenden Beispiel wird zuerst die Aktion Auftrag ausführen ausgelöst. Diese startet dann zwei Aktionen: Auftrag versenden und Rechnung senden.

Der Tokenfluss

Die Token kommen über die hinführende Kante bei dem Knoten an. Sie werden dann allen wegführenden Kanten angeboten. Wenn das Token von allen diesen akzeptiert wurde, werden sie vervielfältigt und jeweils eine Kopie geht weiter zu einer Kante.

Auch bei diesem Knoten sind auf den wegführenden Kanten Wächter möglich. Falls dies so ist, führen die UML-Autoren aus, muss der Modellierer sicherstellen, dass keine Vereinigungen weiter vorne im Fluss (downstream joins) von den Token abhängen, die durch die kontrollierte Kante kommen. Falls dies nicht vermieden werden kann, sollte ein Entscheidungsknoten eingeführt werden, der für den Fall, dass der Wächter den einzigen Kantenfluss zum Vereinigungs-Knoten blockiert, den Token flussabwärts führt.

Wächter

Abbildung 10.10-1 (Fehlerbehandlung) zeigt ein Beispiel. Vgl. auch die Ausführungen dort.

9.5.4 Vereinigung

Eine Vereinigung (join node) repräsentiert eine UND-Verknüpfung bzgl. der hinführenden Kanten, d.h., alle hinführenden Kanten müssen aktiv werden, nur dann geht es über den Knoten weiter. Er ist somit ein Kontrollknoten, zu dem mehrere Aktivitätskanten hinführen und von dem genau eine wegführt.

Grafische Darstellung

Die grafische Darstellung geht wiederum, wie bei einem Gabelung, von einem Balken aus. Hier kommen nun aber zuführende Aktivitätskanten und genau eine wegführende dazu.

Beispiele

Im folgenden Beispiel werden zuerst Rohstoffe bereit gestellt, Fremdteile beschafft und Kapazitäten eingeplant. Erst wenn all dies geschehen ist, kann die Produktion geplant werden (vgl. dazu das EPK-Beispiel in [Staud 2006, Abbildung 4.4-6]).

Das nächste Beispiel zeigt die Vereinigung in Zusammenhang mit einem Objektknoten vom Typ Signal (vgl. Abschnitt 10.4-2), der Signaltoken abgibt, und mit einer Kantengewichtung, die hier einfach aussagt, dass alle Angebotsvorschläge in Betracht gezogen werden.

Die Abbildung enthält u.a. folgende Komponenten:

• Eine Gewichtung an einer Aktivitätskante
• Eine Vereinigung
• Einen einfachen Objektknoten
• Zwei Objektknoten vom Typ Signal

Außerdem die Einbindung eines Objekts in den Kontrollfluss.

Hintergrund

Die UML-Autoren führen aus, dass die Vereinigung eingeführt wurde, um Parallelität in Aktivitäten zu unterstützen [OMG 2003a, S. 341]. Mit Parallelität kann dann nur gemeint sein, dass der Kontrollfluss über die Vereinigung erst dann weitergeht, wenn alle Aktionen vor den hinführenden Kanten ausgeführt wurden. Insofern ist auch verständlich, wenn sie ausführen, dass eine Vereinigung mehrere Kontrollflüsse synchronisiert [OMG 2003a, S. 338].

Kontrollflüsse synchronisieren

Der Tokenfluss

Wenn auf allen ankommenden Kanten ein Token angeboten wird, werden der wegführenden Kante Token gemäß den folgenden Regeln angeboten [OMG 2003a, S. 339]:

• Falls alle angebotenen Token Kontrolltoken sind, dann wird der wegführenden Kante ein Kontrolltoken angeboten.
• Falls einige der angebotenen Token Kontrolltoken sind und andere Datentoken, dann werden nur die Datentoken der wegführenden Kante angeboten.

Die Funktionalität eines UND-Operators erläutern die UML-Autoren mit Hilfe der Token wie folgt: Das reservierte Wort “and” als Join-Spezifika­tion bedeutet, dass von jeder ankommenden Kante mindestens ein Token verlangt wird.

Voreinstellung: AND

Wie sehr die Überlegungen der UML-Autoren ins Detail gehen zeigt die folgende Festlegung des Tokenflusses: Falls der wegführenden Kante Token angeboten werden, muss die Weitergabe (traversal) akzeptiert oder abgelehnt werden, bevor weitere Token der wegführenden Kante angeboten werden. Falls Token zurückgewiesen werden, werden sie der wegführenden Kante nicht länger angeboten [OMG 2003a, S. 339].

Falls zusätzlich eine Join-Spezifikation angegeben wird, wird sie wie in der nächsten Abbildung angegeben, zur Grafik hinzugefügt.

Join-Spezifikation

Beispiel

Das folgende Beispiel enthält eine solche Festlegung des Joins. Die Festlegung besagt: Erst wenn beide Aktionen abgeschlossen sind und wenn zusätzlich die eingeworfenen Münzen den Getränkepreis abdecken, dann wird das Getränk ausgegeben.

In Abschnitt 10.11.8 wird – im Rahmen eines Vergleichs der beiden Methoden EPK und AD – zu diesem Aktivitätsdiagramm eine äquivalente Ereignisgesteuerte Prozesskette vorgestellt.

Vergleich
EPK – AD

Vereinigung und Gabelung zusammen

Ähnlich wie oben für die Zusammenführung und die Verzweigung gezeigt, können auch Vereinigung und Gabelung direkt hintereinander fallen und grafisch zu einem Element verschmelzen.

Hier liegt zuerst eine Vereinigung vor, deren einzige wegführende Kante nicht angezeigt wird. Unmittelbar danach folgt die Gabelung, deren einzige hinführende Kante ebenfalls nicht angezeigt wird. Solche Strukturen sind bei Operatoren durchaus üblich, bei Ereignisgesteuerten Prozessketten entsprechen dem Beispiel hier zwei unmittelbar aufeinanderfolgende UND-Operatoren in einem Operatorkreis.

9.5.5 Startknoten

Ein Startknoten (initial node) markiert den Start der Aktivität. Er gibt an, welcher Fluss startet, wenn die Aktivität aufgerufen wird. Eine Aktivität kann mehr als einen Startknoten haben. Wird dann die Aktivität gestartet, starten mehrere Kontrollflüsse, einer bei jedem Startknoten[3]. Ein Startknoten hat keine ankommenden Kanten und genau eine wegführende.

Graphische Darstellung

Startknoten werden durch einen eingefärbten schwarzen Kreis dargestellt. Die folgende Abbildung zeigt ein Beispiel, gleich mit einer nachfolgenden Aktion.

Beispiel

Weitere Beispiele finden sich in den folgenden Aktivitäten.

Der Tokenfluss

Wenn die Aktivität startet, wird ein Kontrolltoken auf dem Startknoten platziert. Die Token in einem Startknoten werden allen wegführenden Kanten angeboten. Hat eine Aktivität mehr als einen Startknoten, wird entsprechend zu obigem auf jedem Starknoten der Token platziert.

Der Einfachheit halber sind Startknoten eine Ausnahme von der Regel, dass Kontrollknoten keine Token halten können, wenn diese daran gehindert werden, im Kontrollfluss voranzuschreiten. Dies ist gleichbedeutend damit, einen Pufferknoten zwischen dem Startknoten und seinen wegführenden Kanten zwischenzuschalten [OMG 2003a, S. 335].

Keine Speicherung in Kontrollknoten

Außerdem weisen die UML-Autoren darauf hin, dass Kontrollflüsse auch von anderen Knoten starten können, so dass nicht unbedingt Startknoten da sein müssen, um eine Aktivität zu starten [ebenda].

9.5.6 Schlussknoten

Es gibt zwei Aktivitätsknoten, die eine Beendigung von Kontrollflüssen modellieren: Aktivitätsende (activity final) modelliert die Beendigung der gesamten Aktivität, Flussende (flow final) die Beendigung eines einzelnen Kontrollflusses.

Aktivitätsende

Ein Aktivitätsende stoppt, sobald es erreicht wird, alle Kontrollflüsse in einer Aktivität. Eine Aktivität kann mehr als ein Aktivitätsende haben. Ist dies so, beendet das erste, das erreicht wird, die Aktivität, einschließlich der Flüsse, die zu anderen Schlussknoten führen.

Aktivitätsende

Grafische Darstellung

Ein Knoten Aktivitätsende wird wie folgt dargestellt:

Der Tokenfluss

Ein Aktivitätsende akzeptiert alle Token von ankommenden Kanten. Erreicht dann ein Token einen solchen Knoten, wird die Aktivität beendet und der Token wird zerstört. Irgendwelche Objektknoten, die als Output deklariert sind, werden aus der Aktivität rausgegeben.

Beispiel

Im folgenden Beispielsfragment soll nach der Aktion Ware versenden die gesamte Aktivität beendet werden.

Während obiger Knoten Aktivitätsende dem Üblichen entspricht, das man von Methoden der Ablaufbeschreibung kennt, zeigt der nachfolgende Knoten Flussende Modellierungsmöglichkeiten auf, die zumindest in der Prozessmodellierung so nicht betrachtet werden.

Flussende

Ein Flussende ist ein Schlussknoten, der nur den Kontrollfluss beendet, mit dem er verknüpft ist, alle übrigen aber bestehen lässt. Dem liegt die Überlegung zugrunde, dass es sinnvoll ist, wenn nur einzelne Kontrollflusszweige abgeschaltet werden können.

Ein Zweig endet, alle anderen machen weiter

Die Vorstellung der UML-Autoren ist hier also, dass eine gesamte Aktivität auch aus voneinander unabhängigen Kontrollflusszweigen bestehen kann, die getrennt abgeschaltet werden können. Mehr dazu unten.

Grafische Darstellung

Knoten des Typs Flussende werden wie folgt grafisch dargestellt:

Der Tokenfluss

Ein Flussende zerstört alle Token, die bei ihm ankommen, aber nur diese. Es hat, im Gegensatz zum Aktivitätsende, keine Wirkung auf die Token in anderen Kontrollflüssen.

Beispiel

Im folgenden Aktivitätsfragment sei die Situation wie folgt: Zahlreiche Komponenten werden gebaut und installiert. Die Aktion Stelle Komponente her ist in einer Schleife. Nach jeder Komponentenherstellung wird zum einen die Aktion Baue Komponente ein aktiviert, zum anderen kommt es aber auch zu einem Entscheidungsvorgang, der in der Grafik durch die Verzweigung angegeben ist.

Komponenten
installieren und
zusammenbauen

Da wird geprüft, ob weitere Komponenten herzustellen sind oder nicht. Die beiden möglichen Ergebnisse sind [weitere Komponenten zu bauen] bzw. [keine weiteren Komponenten zu bauen]. Dieser Entscheidungsvorgang wird jedesmal, nach der Herstellung jeder Komponente, durchgeführt.

Irgendwann kommt es hier zu der Entscheidung, dass keine weiteren Komponenten zu bauen sind. Dann wird dieser Kontrollfluss (diese Wiederholschleife rund um die Herstellung) durch den Knoten Flussende abgebrochen.

Betrachten wir den zweiten Teil, ab der Aktion Baue Komponente ein. Nach dieser Aktion (bzw. in ihr) kommt es zur Entscheidung, ob weitere Komponenten zu installieren sind oder nicht. Falls weitere zu installieren sind, wird ein Flussende erreicht, das diesen Kontrollflusszweig beendet. Falls keine weiteren Komponenten zu liefern sind, startet die Aktion Anlage liefern, nach dieser beendet ein Aktivitätsende die gesamte Aktivität.

Zweiter Teil

Da die Aktion Baue Komponente ein direkt von Stelle Komponente her angestoßen wird, gibt es keinen Anstoß mehr, wenn diese endet. Dann sollten auch tatsächlich keine weiteren Komponenten zu installieren sein, so dass das Aktivitätsende erreicht wird.

Die Beschreibung in [OMG 2003a] zeigt aber, dass die UML-Autoren sich vorstellen, eine Aktion könne auch ohne unmittelbaren Anstoß durch den Kontrollfluss weiterarbeiten:

Weiter ohne Anstoß

„When the last component is built, the end of the building iteration is indicated with a flow final. However, even though all component building has come to an end, other behaviors are still executing. When the last component has been installed, the application is delivered.“ [OMG 2003a, S. 332]

Hier würde also die Aktion Baue Komponente ein solange weitermachen, bis auch die zuletzt gelieferte Komponente eingebaut ist. Voraussetzung ist natürlich, dass alle benötigten Komponenten vorher auch hergestellt wurden.

Danach wird dann die gesamte Aktivität beendet. In der Grafik ist dies durch den Knoten Aktivitätsende festgehalten.

Aktivitätsende

Die Abbildung enthält u.a. folgende Komponenten:

• Zwei Flussenden
• Zwei Verzweigungen
• Eine Schleife (Rückschleife)
• Ein Aktivitätsende
• Eine Gabelung

Außerdem ein Beispiel für ein unmittelbares Hintereinanderfolgen einer Gabelung und einer Verzweigung.

In Abschnitt 10.11.8 wird – im Rahmen eines Vergleichs der beiden Methoden EPK und AD – zu diesem Aktivitätsdiagramm eine äquivalente Ereignisgesteuerte Prozesskette vorgestellt.

Vergleich
EPK – AD

Aktivitätsende vs. Flussende

Nach der Motivation für den Knoten Aktivitätsende muss man nicht fragen. Jeder Modellierungsansatz, der Abläufe modelliert, hat ein solches Element.

Was aber ist die Motivation für den Knoten Flussende neben der oben schon angeführten, die sich aus den Anforderungen der Systemanalyse ergibt? Die UML-Autoren nennen zwei Situationen für seinen Einsatz.

Weitere Motive

Die erste Situation

Eine Aktivität beschreibt ja eine bestimmte abgegrenzte Folge von Tätigkeiten. Falls für alle Aufrufe einer solchen Tätigkeitsfolge dieselbe Aktivität benutzt wird, fließen unterschiedliche Tokenströme durch dieselbe Aktivität. In so einem Fall ist es u.U. nicht gewünscht, alle Token zu vernichten, wenn eines einen Schlussknoten erreicht. Benutzt man nun an einer solchen Stelle ein Flussende, dann werden nur die Token zerstört, die diesen erreichen, die anderen bleiben bestehen.

Das korrespondiert mit dem oben angeführten Verweis auf den Systemgedanken. Man stelle sich eine Systemkoponente vor, die von mehreren Aktivitäten benutzt wird, z.B. in einem Geldautomaten eines Parkhauses die Komponente, die Geldscheine erfasst und ihren Wert festhält. Benötigt wird Sie bei der Eingabe von Geld in den Automaten durch die Mitarbeiter, bei der Ausgabe von Geld an abhebende Kunden, evtl. bei der Rückgabe von Restgeld, usw. Dann ist durchaus vorstellbar, dass eine solche Komponente „isoliert“ abgeschaltet werden soll.

Die zweite Situation

Für unterschiedliche Aufrufe einer Aktivität sollen Varianten derselben benutzt werden. Dann kann durch ein Flussende erreicht werden, dass Token unterschiedlicher Aufrufe sich nicht gegenseitig beeinträchtigen [OMG 2003a S. 298].

Hintergrund: Bei der Modellierung von Abläufen hat man oft das Problem, dass man dieselbe Ablauffolge in leichter Variation benötigt. Die einfache Lösung ist, die Ablauffolge mehrfach – dupliziert – einzusetzen. Dies führt aber zu einer Vermehrung von Modelelementen, weshalb man u.U. die Variation innerhalb eines Modellelements abfängt.

Anstatt nun also eine Aktivität zu duplizieren und jeweils eine bestimmte Variante in einer Aktivität zu modellieren, fängt man die Varianten innerhalb der Aktivität ab. Dann kann es sinnvoll sein, bestimmte Kontrollflüsse bei einem Durchgang abzuschalten, die anderen aber nicht.

Tieferliegender Grund

Obiges, zusammen mit dem Theorieelement selbst, gibt einen Hinweis auf einen tiefer liegenden Grund: Auf eine andere Sichtweise, die hier von den UML-Autoren eingenommen wird. Eine, die die Gesamtheit aller Geschäftsprozesse ins Visier nimmt und sie in einem systemähnlichen Zusammenspiel sieht. Vgl. hierzu Abschnitt 10.11 und Kapitel 14.

Gesamtsicht

9.6 Aufruf von Aktivitäten

Wie können Aktivitäten aufgerufen werden? Die erste Variante ist der (nicht dokumentierte) Aufruf durch externe Ereignisse. Z.B. wenn ein Kundenauftrag eintrifft, ein Angebot erstellt werden muss oder sich ein Kunde dem Geldautomaten nähert und diesen aktiviert. In Anlehnung an die Ausführungen bei den Ereignisgesteuerten Prozessketten kann da vom Ereignisraum (des Unternehmens, der Anwendung) gesprochen werden, der sich durch das Ereignis artikuliert (vgl. unten).

Aufruf aus dem
Ereignisraum

Die Ereignisse dieses Ereignisraumes werden deutlicher, wenn das objektorientierte Modell insgesamt vorliegt. Da werden (auf Systemebene) Aktivitäten üblicherweise indirekt, als Methoden, die an Operationen gebunden sind, aufgerufen.

Einbindung in
objektorientierte Modelle

Die zweite Variante ist, dass eine Aktivität A eine Aktivität B aufruft. Dann enthält Aktivität A eine Aktion, die diesen Aufruf signalisiert. Die folgende Abbildung zeigt ein Beispiel. In Aktivität A gibt es das Aktionssymbol Angebotserstellung mit dem Symbol

, das eine gleichnamige Aktivität aufruft und dort den Startknoten aktiviert.

Aufruf durch eine andere Aktivität

Diese aufrufende Aktion ist genauso in den Kontrollfluss eingebettet wie eine normale Aktion. D.h., sie hat neben einer hinführenden auch eine wegführende Aktivitätskante. Vgl. hierzu das Beispiel in den Abbildungen 10.11-4 und 10.11-5.

9.7 Aktivitäten aufteilen

Das Problem, den Aktionen einer Aktivität die Träger (z.B. die Organisationseinheiten) zuzuordnen, lösen die UML-Autoren wie folgt: Sie führen ein allgemeines Konzept ein, Ähnlichkeit zwischen Aktionen erfassen zu können und nennen dies activity partition. Im Falle der Träger von Aktionen besteht dann die Ähnlichkeit darin, denselben Träger zu haben.

Ähnlichkeit zwischen Aktionen

Grafisch wird dies auf unterschiedliche Weise realisiert. Zum Beispiel über sog. Schwimmbahnen, wie es die folgende Abbildung zeigt.

Das Beispiel der folgenden Abbildung ist vom einleitenden Teil bekannt: Aktivität Auftragsbearbeitung. Vgl. das Stichwortverzeichnis für die Fundorte aller Varianten dieser Aktivität.

 Abbildung 9.8-1:       Aktivität Auftragsbearbeitung – mit Schwimmbahnen
Quelle: [OMG 2003a, S. 310, Figure 226] – leicht verändert. Übersetzung durch den Verfasser

Die obige Aktivität Auftragsbearbeitung mit Schwimmbahnen enthält folgende Komponenten:

• Eine Zuweisung von Organisationseinheiten durch Schwimmbahnen
• Eine Verzweigung
• Eine Vereinigung  
• Eine Gabelung   
• Eine Zusammenführung
• Einen Startknoten
• Einen Schlussknoten Aktivitätsende

Außerdem ein Objekt im Kontrollfluss.

Dabei wird die gesamte Aktivität in Bahnen aufgeteilt, in denen sich jeweils die Aktionen eines Trägers befinden. Im obigen Beispiel ist die oberste Bahn der Abteilung Auftragsbearbeitung zugeordnet. Entsprechend sind in ihr die Aktionen Auftragseingang, Auftrag ausführen, Lieferung und Auftrag schließen angesiedelt.

Träger in Bahnen

Die zweite Bahn enthält die Aktionen, die durch das Finanzwesen realisiert werden, die dritte die vom Kunden realisierte Aktion. Das ist hier – natürlich – der Zahlvorgang. Der Objektknoten, der ja jetzt nicht nur eine Wanderung von einer Aktion zur nächsten signalisiert, sondern auch den Wechsel der Bahn, wird auf die Grenzlinie gesetzt.

Die Lösung mit Schwimmbahnen nutzen viele Ansätze zur Modellierung von Abläufen. Sie ist geeignet, falls es sich um eine überschaubare Anzahl von Organisationseinheiten handelt.

Mehrdimensionale Schwimmbahnen

Die Lösung mit Schwimmbahnen gibt es auch mehrdimensional. Vgl. [OMG 2003a, S. 311ff] und insbesondere Abbildung 228, wo in der einen Dimension die Abteilungen und in der anderen die geografischen Standorte angesiedelt sind. Eine solche Lösung ist jedoch nur möglich, falls nicht mehr als zwei Dimensionen vorliegen und diese nur wenig Ausprägungen haben.

Schwimmbahnen -
mehrdimensional

Träger zu den Aktionen

Eine weitere von den UML-Autoren vorgeschlagene Lösung besteht darin, im Symbol für die Aktionen die Träger zu vermerken, so wie es die folgende Abbildung zeigt.

Träger der Aktion direkt bei der Aktion

Im Anschluss an die Ausführungen oben kann diese Variante für die Einbindung von Organisationseinheiten nur sehr begrüßt werden. Sie erlaubt auch die Modellierung größerer Modelle mit zugeordneten (zahlreichen) Trägern von Aktionen.

Es bleibt allerdings die Frage, was getan werden muss, wenn z.B. mehrere Organisationseinheiten Träger einer Aktion sind, was in Geschäftsprozessen oft vorkommt, zumindest in der Geschäftsprozessmodellierung. Dies würde sehr unübersichtlich. Auch diese Lösung erscheint daher stark vom Umfeld System her geprägt, wo die Zahl der Akteure sich bei einem Modellelement doch arg in Grenzen hält – im Gegensatz zu Geschäftsprozessen. Hier schlägt also die Orientierung an Systemen sogar bis in die konkrete Gestaltung der Grafik durch.

Betrachteter Gegenstand prägt Grafiken

Offen bleibt auch, wie Beziehungen zwischen den Organisationseinheiten einer Aktion modelliert werden könnten („Das macht die Materialwirtschaft mit der Lagerhaltung oder mit der Produktionsplanung“). Eine solche Struktur liegt in der Praxis tatsächlich oft vor.

9.8 Zeitliche Dimension

9.8.1 Ereignisse im Zeitablauf

Alle theoretischen Ansätze, die Abläufe bzw. Tätigkeitsfolgen modellieren, müssen die zeitliche Dimension mitberücksichtigen. In der Version 2.0 der UML geschieht dies auch, wobei die Konzepte zur Einbeziehung von Zeitaspekten sehr eng mit dem Ereigniskonzept zusammenhängen, weshalb hier beide gemeinsam betrachtet werden.

Ähnlich wie bei Ereignisgesteuerten Prozessketten ist bei Aktivitäten keine explizite Berücksichtigung der Zeitachse vorgesehen. Nur in der Erfassung des Hintereinanderfolgens der einzelnen Aktionen wird zumindest die relative zeitliche Position der Aktionen erfasst. Mit den Aktivitätskanten und den verschiedenen Knoten ist dies umfassend modelliert und im Kontrollfluss festgehalten. Ähnlich sehen es auch die UML-Autoren:

Keine explizite
Berücksichtigung der Zeit

“The UML does not provide for the specification of a time metric, but only describes sequences of executions.” [OMG 2003a, S. 265]

Ganz anders mit Ereignissen. Diese müssen als Konzept bei der Modellierung von Abläufen vorhanden sein und sie sind es auch hier in vielfältiger Form. Booch et al. definieren wie folgt:

Ereignisse

„Ein Ereignis ist die Spezifikation eines signifikanten Vorkommens, das sich zeitlich und räumlich zuordnen lässt.“ [Booch, Rumbaugh und Jacobson 2006, S. 336]

Grundsätzlich gilt hier wie bei Ereignisgesteuerten Prozessketten, dass Ereignisse entweder von außen kommen oder intern entstehen. Wobei intern hier bedeutet, dass das Ereignis innerhalb einer Aktivität auftritt.

In der UML werden Ereignisse in enger Verbindung mit Verhalten gesehen: Ereignisse lösen Verhalten aus [OMG 2003a, S. 8]. Den umgekehrten Tatbestand, dass Verhalten auch zu bestimmten Ereignissen führt, sehen/benötigen die UML-Autoren nicht, bzw. modellieren ihn auf andere Weise, durch Festlegung der jeweils folgenden Aktionen.

Ereignisse lösen Verhalten aus

Folgende unterschiedlichen Ereignisse werden hier u.a. unterschieden:

Liste von Ereignissen

• call behavior event
• call event
• call invocation event
• change event
• invocation event
• receiving event
• send invocation event
• signal event
• start event
• termination event
• time event
• trigger event

Die meisten stellen nur Bezeichnungen für bestimmte Ereignisarten dar ohne tiefere theoretische Bedeutung, einige der v.a. durch den Tokenfluss inhaltlich begründeten werden im folgenden erläutert.

Ereignisauftreten

Um ihr Theoriegebäude lückenlos zu halten, benötigen die UML-Autoren auch ein Theorieelement für den Zeitpunkt, in dem ein Ereignis eintritt. Dies ist das Ereignisauftreten (event occurrence ).

Mit diesem Konzept wird auch die Beziehung zwischen Ereignissen und Aktionen hergestellt, indem die UML-Autoren definieren, dass das Auftreten von Ereignissen Zeitpunkte darstellt, denen Aktionen zugeordnet sind [OMG 2003a, S. 416].

9.8.2 Verbindung von Ereignissen und Aktionen

Den UML-Autoren genügt es nicht, dass ein Ereignis eintritt und eine Aktion anstößt, hier ist dieser Vorgang detaillierter konzeptionell vorgedacht und modelliert.

Eine wichtige Rolle spielt dabei die accept event action. Sie ist definiert als eine Aktion, die auf das Eintreten eines Ereignisses wartet, das bestimmten Bedingungen genügt [OMG 2003a, S. 217]. Die „Philosophie“ der UML-Autoren an dieser Stelle kann wie folgt beschrieben werden:

• Ereignisse werden durch die Objekte unabhängig von Aktionen entdeckt.
• Die Ereignisse werden durch das Objekt gespeichert. D.h., sie äußern sich durch Daten in irgendeiner Form.

Damit kann dann formuliert werden: accept event actions gehen mit Ereignissen um, die von dem betroffenen Objekt entdeckt werden [OMG 2003a, S. 217].

Es versteht sich, dass nur Kontrollkanten zu einer accept event action führen dürfen. Es wäre nicht sinnvoll, Objekttoken mit ihr zu konfrontieren.

Wie werden Ereignisse dann bemerkt? Z.B. als Signal und damit als signal event. Ist das Ereignis ein solches, dann enthält der Ergebnistoken ein signal object, dessen Entgegennahme durch das owning object das Ereignis auslöst.

signal und
signal event

Für eine solche Aktion, die auf einem signal event beruht, nutzen die UML-Autoren auch die Bezeichnung accept signal action.

Ist das Ereignis ein time event, dann enthält der sich ergebende Token den Zeitpunkt, zu dem das Ergebnis eintrat. Für die Aktion, die darauf beruht, nutzen die UML-Autoren auch die Bezeichnung wait time action.

time event

Liegt ein call event oder ein change event vor, ist das Ergebnis ein Kontrolltoken.

change event oder call event

Start einer accept event action

Falls eine accept event action keine ankommenden Kanten hat, startet die Aktion, wenn ihre Aktivität oder ihr strukturierter Aktivitätsknoten es tun. Außerdem gilt, dass eine solche Aktion immer in der Lage ist, Ereignisse zu akzeptieren, egal wie viele. Sie hört auch nicht auf, wenn sie ein Ereignis akzeptiert hat, sondern steht weiterhin in Warteposition, ist also weiterhin aktiv. Dies weicht ab von der ansonsten üblichen Festlegung in der UML.

Graphische Darstellung

Eine accept event action wird durch ein Fünfeck mit Einbuchtung dargestellt, eine wait time action durch ein Stundenglas. Vgl. die folgende Abbildung.

Beispiele

Das erste Beispiel zeigt ein “Signal”, das die Stornierung eines Auftrags verlangt. Die Akzeptanz des Signals stößt dann die Aktion Auftrag stornieren an.

Die obige Abbildung enthält folgende Merkmale bzw. Komponenten:

• Die Modellierung eines Zeitpunkts
• Eine accept event action

Außerdem ein Signal, das eine Aktion auslöst.

Vor dem nächsten Beispiel wird noch ein weiteres Element (eine weitere Aktion) benötigt, das die Aussendung eines „Signals“ modelliert.

Send signal action ist diese Aktion, die mit ihrem Input ein einzelnes Signal (signal instance) erzeugt und zum Zielobjekt überträgt. Dort kann diese das „Feuern“ einer Transition in einem Zustandsautomaten (vgl. Kapitel 13) oder die Ausführung einer Aktivität veranlassen. Eventuelle Argumentwerte werden übergeben und das angesprochene „Verhalten“ beginnt sofort mit der Ausführung.

send signal action

Grafische Darstellung

Die grafische Darstellung erfolgt durch ein Fünfeck mit Spitze, wie es die nachfolgende Abbildung zeigt.

Beispiele

Das erste Beispiel ist Teil einer Auftragsverarbeitung, in der zwei Signale gesendet werden.

Auftrags-
verarbeitung mit Signalen

Ein Auftrag wird auf der Basis einer Kundenbestellung bearbeitet. Das Lager wird aufgefordert, das gewünschte zusammenzustellen und zu versenden (erstes Signal). Dort wird der Auftrag ausgeführt und verschickt. Dann wird eine Rechnung erzeugt und dem Kunden zugeschickt (zweites Signal).

In der nächsten Abbildung wird folgender Ablauf modelliert: Wenn die Auftragsbearbeitung fertig ist, wird mit Hilfe einer send signal action ein „Signal“ zur Zahlungsaufforderung rausgeschickt. Danach wartet die Aktivität, bis der Zahlungseingang bestätigt wird (durch das accept event action). Das Zahlungseingangssignal wird nur angenommen, wenn das Signal zur Zahlungsaufforderung vorher gesandt wurde. Wenn dann der Zahlungseingang bestätigt ist, wird der Auftrag verschickt.

Zahlungs-
aufforderung als Signal

Auf diese Weise kann das Aussenden der Rechnung und das Warten auf den Zahlungseingang auch modelliert werden. Dies ist allerdings nur für eine Grobmodellierung geeignet, da sie keine Präzisierung erlaubt.

Das nächste Beispiel zeigt die wait time action im Einsatz. Hier ist modelliert, dass an jedem Monatsende das Ereignis eintritt. Da diese Aktion keine hinführenden Kanten hat, ist sie so lange aktiv, wie ihre Aktivität oder ihr strukturierter Knoten.

An jedem Monatsende

Sie erzeugt am Ende eines jeden Monats einen Output. Damit können dann monatliche Gehaltszahlungen wie in der folgenden Abbildung modelliert werden.

Das folgende Beispiel zeigt dieses Element in Kombination mit einer Vereinigung. Einmal jährlich werden aus einer Personaldatenbank Daten über die Angestellten abgerufen. Danach wird die Beurteilung der Angestellten durchgeführt.

Die obige Abbildung enthält u.a. folgende Komponenten:

• Das Element wait time action

• Eine Vereinigung
• Einen Objektknoten  des Typs Datenspeicher

Außerdem eine Aktivitätskante mit Gewichtung.

9.8.3 Verhalten von Aktionen

Was geschieht nun genau, wenn eine Aktion aktiviert wird? Hier haben die UML-Autoren eine sehr detaillierte Vorstellung, die auf dem Konzept der Aktionsausführung beruht, das in Abschnitt 9.4 schon kurz vorgestellt wurde.

Aktionsausführung

Die UML-Autoren definieren eine Aktionsausführung als das Laufzeitverhalten einer zur Ausführung gebrachten Aktion.

Kommt es zur Ausführung einer Aktion, wird zuerst eine solche Aktionsausführung erzeugt. Damit dies geschieht, müssen alle Voraussetzungen für die Objekt- und Kontrollflüsse erfüllt sein, d.h. allen Input-Pins müssen Token angeboten worden sein und diese müssen sie angenommen haben.

Die Aktionsausführung verbraucht dann die Kontroll- und Objekttoken des Input und entfernt sie von den Quellen der Kontrollknoten und von den Input-Pins. Sie ist dann in Stand gesetzt und kann mit der Ausführung beginnen [OMG 2003a, S. 281].

Der Start

Eine Aktion macht so lange weiter bis sie fertig ist. Die meisten Aktionen verarbeiten nur ihren Input. Einige gehen darüber hinaus und arbeiten mit Variablen aus ihrem strukturierten Aktivitätsknoten oder dem self ob­ject. Das ist das Objekt, zu dem die Aktivität gehört, in der die Aktionsausführung stattfindet.

Die eigentliche Arbeit

Wenn sie fertig ist, bietet eine Aktionsausführung allen ihren Output-Pins Objekttoken an. Allen ihren wegführenden Kontrollkanten werden Kontrolltoken angeboten. Danach endet sie. Die Outputtoken stehen nun zur Verfügung, um die Anforderungen anderer Aktionsausführungen bzgl. der Kontroll- oder Objektflüsse zu erfüllen.

Das Ende

Wie lange sind Aktionen aktiv?

Grundsätzlich gilt, dass jede Aktion in einer Aktivität entweder einmal, mehrmals oder auch nicht ausgeführt werden kann [OMG 2003a, S. 265]. Aktionen sind, darauf weisen die UML-Autoren an dieser Stelle ebenfalls hin, eine Angelegenheit, die Zeit verbraucht, die also eine bestimmte Zeitspanne für ihre Realisierung benötigt.

Einmal, mehrmals oder auch nicht

Der einfache Fall, dass eine Aktion in der Abarbeitung des Kontrollflusses einmal aufgerufen und ausgeführt wird und dies in einer Wiederholschleife vielleicht auch mehrfach, ist zwar meistens gegeben, aber bei weitem nicht immer, wie die folgenden Ausführungen zeigen.

Ausnahme accept event action

Eine erste Ausnahme findet sich im Umfeld der accept event action. Hier wird ausgeführt, dass eine solche Aktion, wenn sie keine hinführenden Kanten hat, zusammen mit ihrer Aktivität (oder ihrem strukturierten Aktivitätsknoten) startet. Sie ist dann aber immer in der Lage, Ereignisse zu akzeptieren, egal wie viele und hört auch nicht auf, wenn sie ein Ereignis akzeptiert hat, sondern steht weiterhin in Warteposition, ist also weiterhin aktiv. Die UML-Autoren betonen aber ausdrücklich den Ausnahmecharakter dieses Verhaltens [OMG 2003a, S. 217f].

Immer aktiv

Ereignisraum

Was der Verfasser in seinen Veröffentlichungen als Ereignisraum bezeichnet, die Gesamtheit aller möglichen Ereignisse um einen Geschäftsprozess herum, kennen die UML-Autoren auch und bezeichnen es als event pool. Dieser ist einem Objekt zugeordnet und wird auch dafür verwendet, Ereignisse zu speichern (ihr Erscheinen festzuhalten), die nicht unmittelbar genutzt werden können. Später können sie dann berücksichtigt werden. Ein solcher Ereignisspeicher wird auch input event pool des Objektes genannt.

Ereignisse speichern im
event pool

Implizite Schleife in der Aktion?

Vor allem in den Abschnitten zu den Schlussknoten (Flussende und Aktivitätsende) und in den Beispielen gewinnt man den Eindruck, dass sich die UML-Autoren auch vorstellen, dass eine Aktion längere Zeit „weitermacht“, also ihre Leistung (z.B. Komponenteneinbau) nicht nur einmal erbringt, sondern mehrfach. Z.B. über eine implizite Schleife.

Schleife in der
Aktion?

Vgl. dazu die Abbildung 10.6-19. Sie entspricht [OMG 2003a, Figure 251], diese wird auszugsweise in [OMG 2003a, Figure 253] wiederholt. In beiden Fällen führen die UML-Autoren aus, dass nach dem Bau der letzten Komponente der Knoten Flussende greift und die Herstellung der Komponenten endet, dass anderes Verhalten aber weiterhin aktiv ist, hier die Aktion Baue Komponente ein.

Wenn es nicht so wäre, wäre auch das Beispiel sinnlos. Der Komponenteneinbau geht also so lange weiter, bis alle Komponenten verbaut sind.

Das Streaming-Konzept

Das oben besprochene streaming-Konzept durchbricht ebenfalls das einfache Schema „Aktion wird gestartet – läuft ab – ist beendet“. Der Zusatz {stream} an einem Pin erlaubt einer Aktion, Token anzunehmen, während die Aktion bereits ausgeführt wird. M.a.W.: Damit können dann z.B. Objekte jederzeit während der Ausführung einer Aktion ankommen, nicht nur am Anfang.

Implizite Schleife
und
Ständiger Fluss

Dies gilt immer, wenn ein Verhalten mit streaming-Parameter aufgerufen wird.

Obige Regeln gelten somit für Input, der ankommt, nachdem ein Verhalten gestartet wurde und für Output, der verschickt wird, bevor das Verhalten endet (Stream-Inputs und Stream-Outputs).

Mehrfach aktiv?

Normalerweise kann ein Verhalten, das bereits aktiv ist, nicht nochmals gestartet werden. Dies geht erst wieder, wenn der Aufruf abgearbeitet ist. Manchmal ist aber auch der andere Fall wünschenwert bzw. nötig. Die UML-Autoren definieren wie folgt:

Aktiv werden obwohl schon aktiv

• Kann ein Verhalten zu ein und demselben Zeitpunkt mehrfach aktiv sein, dann wird es reentrant genannt.
• Kann ein Verhalten zu einem Zeitpunkt nur einmal ausgeführt werden, dann wird es non-reentrant genannt.

Ein Aufruf eines Verhaltens vom Typ non-reentrant führt somit nicht zum Start des Verhaltens, wenn das Verhalten bereits ausgeführt wird. In diesem Fall versammeln sich die Tokens an den Input-Pins der aufrufenden Aktion (invocation action), falls ihre obere Grenze größer als eins ist, oder woanders stromaufwärts (weiter vorn im Fluss).

Präzisierung durch token

Der Aufruf eines Verhaltens vom Typ reentrant, das bereits aktiv ist, startet eine neue Ausführung mit neu angekommenen Token, auch wenn das Verhalten bereits mit Token des früheren Aufrufs ausgeführt wird.

reentrant und streaming

Ein Verhalten vom Typ reentrant kann keine streaming-Parameter haben, da dabei grundsätzlich mehrere Ausführungen des Verhaltens zur selben Zeit stattfinden und es schwer zu klären wäre, welche Ausführung die streaming-Token erhalten sollte [OMG 2003a, S. 353].

9.8.4 Token

In Abschnitt 8.6 wurde das Token-Konzept grundsätzlich eingeführt, danach wurde es öfters bei anderen Theorieelementen thematisiert, jetzt kann es ergänzend beschrieben werden.

Ein Knoten (node) in einem Aktivitätsdiagramm ist immer etwas dynamisches, da er ja aus einer “subordinate unit” oder gleich aus Aktivitäten besteht. Ihn zu aktivieren heißt Aktionen auszulösen. Er beginnt mit der Ausführung, wenn bestimmte Bedingungen auf seinen Inputtoken erfüllt sind. Die möglichen Arten von Bedingungen hängen von der Art des Knotens ab. Wenn der Knoten mit der Ausführung beginnt, werden Token von seinen Inputkanten (von einigen oder auch allen) akzeptiert und der Token ist dem Knoten zugeordnet.

Inputtoken

Wenn dann ein Knoten die Ausführung beendet, wird ein Token von dem Knoten entfernt und einigen oder allen seinen Outputkanten werden Token angeboten [OMG 2003a, S. 284].

Outputtoken

In Zusammenhang mit der Semantik des Operators Vereinigung findet sich folgende Beschreibung, die den Umgang mit Kontrolltoken klärt:

Kontrolltoken

“If all the tokens offered on the incoming edges are control tokens, then one control token is offered on the outgoing edge.” [OMG 2003a, S. 339]

So kann man die „Semantik“ dieses Operators treffend beschreiben.

In Bezug auf die Startknoten gilt: Wenn die Aktivität gestartet wird, wird dem Startknoten ein Kontrolltoken zugeordnet. Dieser wird dann allen abgehenden Kanten angeboten [OMG 2003a, S. 335].

Kontrolltoken und Startknoten

Hat eine Aktivität mehr als einen Startknoten, dann werden beim Start der Aktivität mehrere Flüsse gestartet, für jeden Startknoten einer, mit je einem Kontrolltoken [ebenda].

Ein Schlussknoten akzeptiert alle Token der ankommenden Kanten. Kommt ein Token bei einem Aktivitätsende an, werden alle Kontrollflüsse in der zugehörigen Aktivität abgebrochen. D.h.: die Aktivität ist beendet, der Token und alle übrigen noch irgendwo aktiven werden zerstört.

Token und
Schlussknoten

Token können bei Kontrollknoten nicht verweilen, um auf das Weitergehen im Kontrollfluss zu warten. Kontrollknoten dienen nur als Steuerelemente. Sie verwalten Token auf ihrem Weg zwischen Objektknoten und Aktionen. Dort, in Objektknoten und Aktionen, können die Token für eine bestimmte Zeit verweilen. Eine Ausnahme von dieser Regel sind die Startknoten.

Token und
Kontrollknoten

Knoten und Kanten haben Tokenflussregeln. Knoten kontrollieren, wenn Token reinkommen oder rausgehen. Kanten haben Regeln dafür, wann ein Token vom Quellknoten genommen und zum Zielknoten transportiert werden darf.

Tokenflussregeln

Ein Token „durchquert“ eine Kante, wenn er die Regeln für Zielknoten, Kante und Quellknoten erfüllt. Das bedeutet, dass ein Quellknoten den weggehenden Kanten nur Token anbieten kann, er kann sie nicht der Kante aufzwingen, weil die Token von der Kante oder dem Zielknoten abgewiesen werden können.

Durchqueren einer Kante

Abschließend noch einige weitere Aspekte, die das Token-Konzept der UML-Autoren verdeutlichen:

• Es gibt Interaktionen zwischen ihnen.
• Token können Engpässe erreichen, auf andere Token warten, die vor ihnen sind und die weiter flussabwärts gehen sollen.
• Token können sich gegenseitig vernichten mit den Knoten Aktivitäts- und Flussende.
• Token werden den Input-Pins von Aktionen angeboten.
• Token können von Aktionen verbraucht werden.
• Es gibt auf einem Knoten Inputtoken und Outputtoken.

Zusammengefasst kann festgehalten werden, dass mit dem Element der Token die vielen Flüsse in Systemen, Abläufen und Geschäftsprozessen veranschaulicht werden. Die UML-Autoren stellen sich den Kontrollfluss, bzw. die Flüsse von Kontrollinformationen, Objekten und Daten als „wandernde Token“ vor.

Wandernde Token

9.9 Beispiele

Hier nun – zur Verdeutlichung und Vertiefung – einige einfache Beispiele zu den oben eingeführten Knoten.

9.9.1 Fehlerbehandlung

Stellen wir uns einen Hersteller von mechanischen Geräten vor, dem Geräte zur Reparatur eingeschickt werden. Die erste Aktion (ganz links) beschreibt den Vorgang, dass der Fehler dokumentiert wird. Danach wird mit Hilfe einer Gabelung zum einen die Reparatur veranlasst, zum anderen zu einer Entscheidung weitergeleitet, die klärt, ob es sich um einen Fall der Priorität 1 handelt oder nicht. Die Entscheidung wird mit einer Verzweigung modelliert.

Die Bedingung für die Alternative ([priority=1]) wird als Wächter (guard) bezeichnet. Ist also die Priorität so hoch, wird die Bedeutung des Fehlers eingeschätzt (für Wartung, Produktion, usw.) und die Produktionsplanung (PP) überarbeitet.

Wächter

Im anderen Kontrollflusszweig wird das Gerät repariert und dann getestet. Auf der rechten Seite kommt zuerst eine Zusammenführung, die die beiden alternativen Zweige von [priority=1] und [else] zusammenführt. Dann eine Vereinigung für die beiden durch die Gabelung entstandenen Zweige. Erst wenn diese realisiert ist, geht es zur Freigabe des Geräts weiter.

Hier kann man nun erkennen, was die UML-Autoren mit ihrem öfters thematisierten stromabwärts wartenden Join meinen. Stellen wir uns vor, bei der Verzweigung gäbe es den „Else-Zweig“ nicht. Dann würde, läge keine Priorität 1 vor, der obere Zweig niemals bei der Vereinigung ankommen und würde niemals überwunden. Deshalb empfehlen sie in einer solchen Konstellation die Einführung eines Else-Zweiges [OMG 2003a, S. 296f].

Die Abbildung enthält u.a. folgende Komponenten:

• Eine Verzweigung 
• Eine Vereinigung 
• Eine Gabelung
• Eine Zusammenführung 
• Einen  „Else-Ausgang“
• Einen Wächter  

Außerdem wird hier ein Problem von oben geklärt, der „flussabwärts wartende Join“ (vgl. Abschnitt 10.6.3).

9.9.2 Lagerentnahme

Die erste Aktion links modelliert eine Lagerentnahme bzgl. einer Auftragsposition des zu bearbeitenden Auftrags. Die nachfolgende Gabelung stößt zum einen die Aktion Vorbereitung Lieferung, zum anderen eine Prüfung an, ob der Lagerbestand noch ausreichend ist (vgl. den decision input).

Die Prüfung wird durch eine Verzweigung modelliert und durch Angabe des decision input präzisiert. Es wird geprüft, ob nach der Lagerentnahme der Lagerbestand unter die Nachbestellmarke gefallen ist. Falls dies so ist, erfolgt eine Nachbestellung, falls nicht, endet dieser Zweig.

decision input

Das Flussende bedeutet, dass dieser eine Kontrollflusszweig, die Aktivitätskante mit dem Ergebnis [falsch] aus der Prüfung, ob der Lagerbestand unter die Nachbestellmarke gefallen ist, beendet wird. Der andere Kontrollflusszweig ist weiter aktiv.

Der Schlussknoten so wie er hier eingesetzt wird ist nur nötig durch das Token-Konzept. In einer Ereignisgesteuerten Prozesskette würde hier einfach der Prozess nicht fortgesetzt.

Die Abbildung enthält u.a. folgende Komponenten:

• Eine Verzweigung 
• Eine Gabelung    
• Ein Flussende  

Außerdem einen „decision input“.

9.9.3 Aspekte des Personalwesens

Die Aktion Einstellung Angestellte führt zu einem neuen Objekt in der Personaldatenbank. Die Aktion Zuweisung Arbeitsgebiet wird nur – dank des Auswahlverhaltens – für die Angestellten aktiviert, denen kein Arbeitsgebiet zugeordnet ist.

Einmal jährlich wird das wiederholte Zeitereignis aktiv. Mit ihm zusammen kann dann die Aktivitätskante von der Personaldatenbank die Aktion Beurteilung Angestellte anstoßen.

Die Gewichtung der Kontrollkante mit „weight=all“ bedeutet, dass die Beurteilung für alle Angestellten vorgenommen wird.

Die beiden Vorgänge, Einstellung Angestellte und Beurteilung Angestellte hängen inhaltlich nicht zusammen. Sie sind hier wohl nur zusammengebracht worden, um den Einsatz der entsprechenden Theorieelemente aufzeigen zu können.

Die Abbildung enthält u.a. folgende Komponenten:

• Eine Vereinigung 
• Einen Datenspeicher    
• Ein wiederholtes Zeitereignis  

Außerdem ein Auswahlverhalten (selection) auf einer Aktivitätskante.

9.9.4 Teiledesign und Teilebeschaffung

Dieses Beispiel umfasst zwei Aktivitäten, bei denen es darum geht, Standardteile bzw. –komponenten für den Bau des Flugzeuginneren zusammenzustellen. Dabei sind zwei Gruppen von Ingenieuren tätig. Diejenigen, die für das Design verantwortlich sind, die Designingenieure (design engineer), und diejenigen, die die Teile- bzw. Komponentenbeschaffung realisieren, Beschaffungsingenieure (standards engineer).

Die Aktivität Teiledesign beschreibt einige Arbeitsschritte beim Design von Teilen. Von dieser Aktivität wird die andere aufgerufen. Hier liegt also das erste Beispiel für einen Aktivitätsaufruf durch eine Aktivität vor.

Die Aktivität Teilebeschaffung beschreibt einige Aspekte des Suchvorgangs, wenn bestimmte Teile angefordert werden und gesucht werden müssen.

In der Aktivität Teiledesign ist durch eine Linie in der Mitte der Abbildung die Zuordnung der Personen zu den Aktivitäten angegeben. Die Aktivitäten der oberen Hälfte werden vom Designingenieur realisiert, die der unteren Hälfte vom Beschaffungsingenieur. Diese Darstellung wählten die UML-Autoren wohl in Anlehnung an die Schwimmbahnenkonstruktion.

Zuordnung von
Personen

Aktivität Teiledesign

Der Prozess beginnt damit, dass der Designingenieur bei seiner Arbeit den Bedarf für ein Standardteil feststellt (Teilebedarf). Dies wurde hier von den UML-Autoren als Aktion modelliert, was etwas irritierend ist, da es sich eigentlich um ein Ergebnis handelt. Gemeint ist aber wohl einfach die Tätigkeit, die zur Erkenntnis des Teilebedarfs führt.

Dadurch wird eine Standardteilesuche angestoßen. Diese führt entweder dazu, dass das Teil gefunden wird oder nicht, was durch einen Entscheidungsknoten (eine Verzweigung) modelliert ist. Wird es gefunden, startet die Aktion Teil verwenden.

Wird das Teil nicht gefunden, kommt es zur Aktion Teil beschaffen. Diese wird von einem Beschaffungsingenieur realisiert und zwar als eine Aktion, die eine gleichnamige Aktivität aufruft. Letzteres ist durch das Symbol rechts unten im Aktionssymbol angegeben.

Aufruf einer
anderen Aktivität

Der Kontrollfluss geht damit weiter in die Aktivität Teilebeschaffung. Nach seiner Rückkehr liegt dann entweder das Ergebnis [Teil beschafft] oder [else] vor. Falls ersteres vorliegt wird wiederum die Aktion Teil verwenden ausgeführt. Für zweiteres wird die Aktivität beendet. Der weitere Verlauf bleibt unklar, auch die positive Beendigung der Aktivität.

Auffällig an diesem Beispiel ist, dass es eine Aktion gibt (Teil verwenden), zu der mehrere Kanten führen. Aus der Logik des Beispiels folgt, dass die beiden Kanten in einem exklusiven ODER – Verhältnis stehen. Vgl. hierzu die Ausführungen in Abschnitt 10.12.

Aktivität Teilebeschaffung

Auch in der Aktivität Teilebeschaffung werden den Aktionen wiederum die zwei Personengruppen Designingenieur und Beschaffungsingenieur zugeordnet. Diesmal durch eine senkrechte Linie und durch Beschriftung der jeweiligen Bereiche.

Die Aktivität startet mit der Expertenteilesuche. Diese führt zu einem gefundenen Teil oder nicht, was durch eine Verzweigung (exklusives Oder) mit entsprechenden Kantenbeschriftungen modelliert wird. Ist die Suche erfolgreich, wird die Aktivität gleich wieder beendet, modelliert durch den Knoten Aktivitätsende. In der übergeordneten Aktiviät bedeutet dies, dass die Aktion Teil beschaffen abgeschlossen ist und dort die Aktivität wie oben beschrieben zu Ende geht.

Expertenteilesuche

War die Suche nicht erfolgreich, führt dies dazu, dass ein Standardteil verändert werden muss. Teil dieses Prozesses ist es, die Suchbedingungen zu prüfen. Es kann sein, dass der Flugzeugdesigner die Suche wegen der großen Anzahl von Teilen und Teilegruppen nicht korrekt formuliert hat. Falls, mit der überprüften Suchanfrage, kein Teil gefunden wird, führt dies zu einer Reihe von Alternativen: entweder zur Veränderung eines vorhandenen Teils oder zur Erzeugung eines neuen Standardteils. Die Bewältigung dieser Problematik leistet ein Beschaffungsingenieur und zwar einer, der sich im jeweiligen Bereich auskennt. Dem wird diese Aufgabenstellung deshalb zugewiesen.

Zuweisung an Beschaffungs-
ingenieur

Als erstes prüft er die Anforderungen an das Teil. Dies geschieht in einem ständigen Austausch mit dem Designingenieur, im Modell ersichtlich durch den Zusatz „stream“ an den beiden Kanten, mit denen die Aktionen Prüfung Anforderungen und Genehmigung Anforderungen verbunden sind.

Prüfung Anforderungen

Der Designingenieur muß sozusagen die Festlegungen des Beschaffungsingenierus „absegnen“. Methodisch interessant sind die beiden Kanten mit dem Zusatz [stream]. Wie oben (Abschnitt 10.5-4) ausgeführt wurde bedeutet dies, dass die Aktionen aktiv bleiben, auch wenn sie schon gestartet wurden. Hier stellen sich die UML-Autoren also ein ständiges Hin und Her von Prüfung und letztendlicher Absegnung der Anforderungen vor.

Genehmigung Anforderungen

Modelltechnisch liegt hier eine Unschärfe in der Modellierung, bzw. Klärungsbedarf vor. Bevor es von Prüfung Anforderungen weiter geht zur konkreten Klärung des weiteren Vorgehens (hier Festlegung PartModWorkflow genannt), muss die mit [stream] festgelegte kooperative Klärung bis zur Genehmigung der Anforderungen vollständig abgeschlossen sein. Es liegt also eigentlich eine Reihenfolge bei den Kanten vor, die von Prüfung Anforderungen wegführen: Zuerst die „Stream-Kanten“ – Hin und Zurück – dann der weitere Fortgang. Dies ist im Modell nicht ersichtlich.

Zuerst „stream“!

Das „fortgesetzte Verhalten“ der Aktion muss ja spätestens dann sein Ende finden, wenn es zur nächsten Aktion weitergeht.

Letztendlich wird dann die Aktion Festlegung PartModWorkflow angestoßen und durchgeführt, wobei – wie oben ausgeführt – aus inhaltlichen Gründen die Erledigung des „Stream-Vorgangs“ vorher erfolgen muss.

Festlegung PartModWorkflow

Anschließend wird, weiterhin vom Beschaffungsingenieur, der PartModWorkflow geplant. Der dabei entstehende Arbeitsplan wird dem Flugzeugdesigner zur Genehmigung zurückgegeben.

Planung Part Mod Workflow

Dieser prüft mit drei möglichen Ergebnissen:

Prüfung Arbeitsplan

• Er gibt ihn zurück zur nochmaligen Planung ([neue Planung]) durch den Beschaffungsingenieur.
• Er bricht die Aktivität ab.
• Er ist zufrieden mit der Planung. Dann werden vom Beschaffungsingenieur die zwei Aktionen PartModWorkflow ausführen und Produktionsanfrage stellen angestoßen.

Der PartModWorkflow wird durchgeführt und zwar in ständiger Abstimmung mit dem Designingenieur, der gegebenenfalls zusätzliche Informationen liefert. Dies ist durch den Zusatz [stream] an den zwei Kanten modelliert.

PartModWorkflow ausführen

Auch hier liegt wieder die oben schon angemerkte Unschärfe in der Modellierung mit dem stream-Zusatz vor. Inhaltlich macht der weitere Fortgang zur Gabelung nur Sinn, wenn die Aktion PartModWorkflow ausführen vorher voll durchgeführt ist.

Reihenfolge

Man muss wohl grundsätzlich annehmen, dass die UML-Autoren sich vorstellen, dass bei Vorliegen einer Verknüpfung mit stream und einer weiteren Kante, zuerst die mit stream abgearbeitet wird.

Das Szenario am Ende dieser Aktivität ist wiederum methodisch interessant: Die Aktivität kommt zu einem Ende, wenn entweder der PartModWorkflow ausgeführt und die Produktionsanfrage akzeptiert wurde, oder wenn die Produktionsanfrage abgelehnt wurde. Dies wird mit Hilfe einer Verzweigung und einer Gabelung modelliert.

Schluss der Aktivität

Das eine ist der positive, das andere der negative Schluss der Aktivität. Wie oben schon ausgeführt, sind die möglichen Beendigungen dieser Aktivität in der übergeordneten Aktivität zu den zwei Ergebnissen „Teil beschafft“ und „else“ zusammengefasst.

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Ein Aktivitätsende
• Einen Startknoten
• Aufruf einer Aktivität
• Zwei Verzweigungen 

Außerdem eine Zuordnung von Personen

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Mehrere Aktivitätsenden
• Einen Startknoten
• Eine Gabelung
• Eine Vereinigung
• Eine Schleife (Rücksprung)
• Mehrere Verzweigungen 
• Einen Startknoten
• Eine Zuordnung von Personen  
• Eine Zusammenführung

Außerdem zweifaches fortgesetztes Verhalten mit dem Zusatz [stream] .

9.9.5 Problembehandlung

Ein Problem taucht auf (z.B. mit einem technischen Gerät), es muss festgehalten werden (Problem aufzeichnen). Wird es aufgezeichnet, geht es in der Aktivität weiter, falls nicht (Gründe dafür sind im Beispiel nicht angegeben), endet die Aktivität.

Im weitergehenden Kontrollfluss kommt nun gleich eine weitere Entscheidung, modelliert durch eine Verzweigung. Aus den Kantenbeschriftungen ist erkennbar, dass es darum geht, ob die Problemdarstellung richtiggestellt ist oder nicht.

Entscheidung nach Entscheidung

Auch dieses in der Prozessmodellierung benötigte Strukturmerkmal, zwei direkt aufeinanderfolgende Entscheidungsschritte (konkret: zwei direkt aufeinander folgende Verzweigungen) ist hier also möglich.

Was die eigentlichen Entscheidungsvorgänge angeht, muss hier wohl angenommen werden, dass beide in der Aktion Problem aufzeichnen stattfinden.

Falls die Problemdarstellung richtig gestellt ist, erfolgt gleich ein Sprung ans Ende der Aktivität zu den zwei gleichzeitig angestoßenen Aktionen Ergebnisse bekannt machen und Ergebnisse festhalten.

Falls nicht ([else]) wird das Problem reproduziert (Aktion Problem reproduzieren). Danach steht wieder eine Entscheidung mit folgenden Alternativen an:

• [nicht reproduzierbar]. In diesem Fall wird die Problembeschreibung korrigiert (wie auch immer) und es erfolgt ein Sprung zum abschließenden Teil.
• [Problem und Lösung bekannt]. Auch danach geht’s ab zum abschließenden Teil.
• [identisch zu früheren Problemen]. In diesem Fall erfolgt ein Sprung direkt vor die Aktion Lösung prüfen. Dazu unten mehr.
• [Problem ist reduzierbar]. In diesem Fall erfolgt ein Sprung vor die Aktion Problem ID und Lösung. Hier gilt das Problem als identifiziert und die Lösung als gefunden. Danach geht es weiter zu Lösung prüfen.

Die Aktion Lösung prüfen wird entweder gestartet, wenn das Problem identisch ist zu früheren oder wenn die Lösung gefunden wurde. Sie bedeutet wohl “nochmaliges Nachdenken über das Ganze”, denn aus ihr heraus kommt es entweder zur Erkenntnis „Problem nicht gelöst“ oder „else“ (“alles ok”).

Aktion
Lösung prüfen

Falls hier die Erkenntnis gewonnen wurde, dass das Problem nicht gelöst ist, wird nochmals in der Aktion Problem ID und Lösung nach einem korrekten Ergebnis gesucht (“Zurück zur nochmaligen Bearbeitung”). Damit liegt hier also eine Rückschleife vor.

Die Schlusssequenz zeigt das aus der Modellierung von Abläufen bekannte Phänomen, dass zwei Aktionen angestoßen werden und dass es erst dann weitergeht (zum Aktivitätsende), wenn beide erledigt sind. Modelliert wird dies hier durch eine Gabelung und eine Vereinigung.

Die Abbildung enthält u.a. folgende Komponenten bzw. Strukturmerkmale:

• Zwei Aktivitätsenden
• Einen Startknoten
• Eine Schleife (Rücksprung) 
• Eine Gabelung
• Eine Vereinigung
• Mehrere Verzweigungen 
• Mehrere Zusammenführungen

Außerdem mehrere unmittelbar aufeinander folgende  Verzweigungen (Entscheidungen) und eine  Rückschleife.

In Abschnitt 10.11.8 wird – im Rahmen eines Vergleichs der beiden Methoden EPK und AD – zu diesem Aktivitätsdiagramm eine äquivalente Ereignisgesteuerte Prozesskette vorgestellt.

Vergleich
EPK – AD

9.9.6 Auslagenerstattung

Hier geht es um die Erstattung von Auslagen, die Beschäftigte eines Unternehmens für das Unternehmen getätigt haben. Z.B. Kauf eines Fachbuches, von Büromaterial oder von Software. So etwas fällt in größeren Unternehmen täglich mehrere Hundert Mal an. D.h. täglich werden mehrere Hundert Instanzen dieses Prozesses erzeugt. Folgende Regeln gelten für den Prozess:

• Beträge unter 200 Euro werden automatisch genehmigt.
• Beträge gleich oder höher 200 Euro benötigen die Genehmigung des Vorgesetzten.
• Im Falle einer Ablehnung erhält der Angestellte eine Begründung per E-Mail.
• Falls innerhalb von 7 Tagen nichts passiert, dann muss der Angestellte eine E-Mail zum Stand des Verfahrens erhalten.
• Falls die Anfrage nicht innerhalb von 38 Tagen erledigt ist, wird sie ungültig. Der Angestellte erhält eine entsprechende Nachricht und muss das Ganze nochmals vorlegen.

Das Beispiel zeigt zwei Flüsse, die “um die Wette” fließen, eine Struktur vor der die UML-Autoren immer wieder warnen. Der erste, der das Aktivitätsende erreicht, bricht die ganze Aktivität und damit den anderen Fluss ab. Die beiden Flüsse sind in derselben Aktivität, so dass sie Daten gemeinsam nutzen können, z.B. zur Klärung der Frage, wer im Falle der Zurückweisung informiert werden muss.

Wettlaufsituation

Die Abbildung enthält u.a. folgende Komponenten bzw. Strukturmerkmale:

• Ein Aktivitätsende
• Einen Startknoten   
• Eine Gabelung
• Mehrere Verzweigungen 
• Mehrere Zusammenführungen

Außerdem eine „Wettlaufsituation“ und einen Timer.

Was meinen die UML-Autoren, wenn sie hier von einer Wettlaufsituation sprechen? Nun, im oberen Teil läuft ganz normal der Genehmigungsprozess ab, in zwei alternativen Flüssen. Der untere Fluss aber stellt eine Art Zeitablaufkontrolle (time check path) dar. Das Verhältnis zwischen diesem und den beiden obigen veranschaulichen die UML-Autoren mit der Klausursituation. Entweder der Studierende wird vor Ablauf der Zeit fertig oder es läuft zuerst die Zeit ab. Beides beendet den Prozess der Klausurerstellung.

Zeitablaufkontrolle

Das Beispiel entstammt Workflow-Modellen, daher auch dieser Timer. In der klassischen Prozessmodellierung würde man eine andere Lösung finden.

9.9.7 Vorschlagswesen

Im folgenden Beispiel geht es um Abläufe rund um ein Vorschlagswesen. Die Abläufe sind wie folgt: Die erste Aktion Vorschlag verändern wird entweder durch den Start der Aktivität aufgerufen oder aber durch eine Schleife. Dazu gleich mehr. Danach wird die Aktion Vorschlag prüfen ausgeführt. Mit dieser kommt es zu einem Entscheidungsvorgang, einer Verzweigung. Der Vorschlag wird entweder zurückgewiesen, geändert oder angenommen.

Vorschläge
wahrnehmen, ändern und prüfen

• Im Falle der Annahme wird die Aktivität Vorschlag annehmen ausgeführt. Danach endet die Aktivität, modelliert durch einen Knoten Aktivitätsende.
• Im Falle der Ablehnung wird diese bekanntgegeben. Auch hier endet dann die Aktivität, wiederum modelliert durch einen Knoten Aktivitätsende.
• Wird beschlossen, den Vorschlag zu ändern, werden mit Hilfe einer Gabelung zwei Aktionen angestoßen. Zum einen die Benachrichtigung bzgl. des Änderungswunsches, zum anderen die Aktion Vorschlag verändern am Anfang der Aktion. Es kommt also zu einem Rücksprung. Dieser benötigt vor der ersten Aktion eine Zusammenführung.

Man vermisst in diesem Beispiel schon sehr schmerzhaft die Angabe der Träger der Aktionen. Dies würde die Aussagekraft sehr erhöhen.

Die Abbildung enthält u.a. folgende Komponenten bzw. Strukturmerkmale:

• Zwei Aktivitätsenden
• Einen Startknoten   
• Eine Gabelung
• Eine Verzweigung 
• Eine Zusammenführung

Außerdem eine Rückschleife.

Die beiden Knoten Aktivitätsende hätten auch zusammengefasst werden können.

9.10 Aktivitäten und UMOD

9.10.1 Grundsätzliche Eignung

Welchen Beitrag können Aktivitäten zu einer Unternehmensmodellierung grundsätzlich leisten? Die Antwort fällt leicht: Nur einen für die Modellierung von Tätigkeitsfolgen, für die Ablauf- bzw. Prozessmodellierung. Da aber sehr umfassend.

Nur für Tätigkeitsfolgen

Dies führt automatisch zu einem Vergleich der Methode AD mit der Methode EPK, als der klassischen Methode der Geschäftsprozessmodellierung. Durch folgende Fragen und Betrachtungen soll deshalb hier die Eignung von Aktivitäten für die Prozessmodellierung ausgeleuchtet werden:

Es bleibt dabei:
AD =
Aktivitätsdiagramm
EPK =
Ereignisgesteuerte
Prozesskette.

• Welche Theorieelemente sind für die Prozessmodellierung geeignet?
• Welche weiteren Theorieelemente enthalten Potential für eine Fortschreibung der Prozessmodellierung?
• Welche Defizite liegen bezüglich der Prozessmodellierung vor?
• Wie steht es um die Qualität der grafischen Gestaltung?
• Wie steht es um die Verknüpfung mit der übrigen objektorientierten Theorie?
• Vergleich einiger Strukturmerkmale von Aktivitätsdiagrammen und Ereignisgesteuerten Prozessketten
• Direkte Gegenüberstellung von Aktivitätsdiagrammen und Ereignisgesteuerten Prozessketten

9.10.2 Theorieelemente für die Prozessmodellierung

Dieser Abgleich soll in Anlehnung an die in Abschnitt 15.3 vorgestellten Basiskomponenten einer Methode zur Prozessmodellierung durchgeführt werden. Sie enthalten die für eine Modellierung von Tätigkeitsfolgen im einfachsten Fall notwendigen Theorieelemente. Die Nummerierung ist die von Abschnitt 15.3.

(1) Elementare Tätigkeiten

Diese sind in Aktivitätsdiagrammen durch die Aktionen gegeben und zwar in vollem Umfang. Auch in der Hinsicht, dass hier auf verschiedenen Niveaus zusammengefasst werden kann, was – wegen der Übersichtsgewinnung – für eine Unternehmensmodellierung unabdingbar ist.

Auch auf verschiedenen Niveaus

(2) Träger der Tätigkeiten

Auch diese sind vorgesehen. Entweder durch die Schwimmbahnen oder durch Eintrag innerhalb des Aktionssysmbols. Die Ausarbeitung geht hier allerdings nicht sehr weit. Was ist, wenn (auf dem jeweiligen Aggregationsniveau) mehrere Träger eine Tätigkeit realisieren? Was ist, wenn es Beziehungen zwischen den Trägern gibt?

Begrenzt

(3) Informationen, auf Trägern aller Art

Ihre Erfassung ist direkt nicht vorgesehen. Es ist also nicht möglich zu erfassen, dass die eine Information benötigt wird, die andere entsteht und die nächste verarbeitet wird. Und dies – natürlich – für Informationsträger aller Art. Vgl. die Ausführungen hierzu in Abschnitt 10.11.4 (Defizite).

Nicht vorgesehen

(4) Informationsverarbeitung

Die Modellierung dieser Vorgänge ist direkt und aussagekräftig nicht vorgesehen. Vgl. die Ausführungen hierzu in Abschnitt 10.11.4 (Defizi­te).

… während der Realisierung der elementaren Tätigkeiten

(5) Ereignisse

Grundsätzlich liegt ein Ereigniskonzept vor, vgl. Abschnitt 10.10. Ereig­nisse werden auch stark ausdifferenziert, sowohl inhaltlich wie metho­disch. Auch ein Äquivalent zum Ereignisraum, event pool genannt, liegt vor.

Ereignisse werden aber in den grafischen Darstellungen nicht ausdrücklich ausgewiesen. Dies kann man machen, es dient aber nicht der Übersichtlichkeit und es birgt Gefahren, z.B. die im folgenden Absatz geschilderte.

Zumindest in den Beispielen entsteht der Eindruck, dass in den Aktivitätsdiagrammen sehr oft Aktion gleich „Funktion + positivem (Ergebnis-) Er­eig­nis“ gesetzt wird. Es wird also vom positiven Ergebnis ausgegangen und nur dieses modelliert. Die Ausführungen zur Theorie geben hier direkt keine Antwort. Ist es Absicht oder Ausdruck einer von Systemen geprägten Modellierung?

Aktion nur mit positivem Ende?

Für eine Prozessmodellierung ist es aber keineswegs tauglich. Hier müssen oft verschiedene mögliche Ergebnisse einer Tätigkeit bedacht werden. Vgl. zu den möglichen Folgerungen hieraus Abschnitt 10.11.9 und die Gesamteinschätzung in Kapitel 14.

Nicht in der Prozess-
modellierung

(6) Kontrollfluss

Ein Kontrollflusskonzept liegt vor, als Abfolge der Aktionen. Auch die zwei Verzweigungsmöglichkeiten einer jeden Basismodellierung, das exklusive ODER (XODER) und das UND liegen vor. Für ersteres als Verzweigung und Zusammenführung, für zweiteres als Gabelung und Vereinigung.

XODER und UND

Etwas unscharf ist in den Abbildungen die Erfassung des Entscheidungsvorgangs beim exklusiven Oder. Zumindest in vielen Beispielen kann der Eindruck entstehen, dass der Entscheidungsvorgang im Symbol für die Verzweigung (also außerhalb der davor angesiedelten Aktion) angesiedelt ist.

Die UML-Autoren scheinen die Zusammenführung von Kontrollflüssen auch ohne Operator zu akzeptieren. So deuten es zumindest einige Beispiele an. Z.B. in Abbildung 10.11-4. Hier kommen zu einer Aktivität zwei Kontrollflüsse – ohne Operator. Ähnlich in Abbildung 10.11-5 in Verbindung mit dem streaming-Konzept.

Zusammen-
führung von Kontrollflüssen ohne Operator

Ein Element, das den Start der Tätigkeitsfolge angibt, ist vorhanden: der Startknoten. Auch die oft vorkommende Ralweltsituation mehrerer alternativer Startpunkte ist damit problemlos modellierbar.

Start

Ein Element, das die Beendigung der Tätigkeitsfolge angibt, ist ebenfalls vorhanden, das Aktivitätsende. Auch hier gilt, dass die üblichen Situationen (alternative Abschlüsse, Beendigung nach Teilaufgaben) damit ohne Schwierigkeit modelliert werden können.

Gesamtende

(7) Ebenen – Kapselung

Kapselung in dem Sinne, dass Tätigkeiten zusammengefasst und dann als neues Element in die sequentielle Abfolge gebracht werden, muss in einer Methode zur Prozessmodellierung vorhanden sein. In Aktivitäts­diagram­men ist dies auch der Fall (vgl. oben). In einer einzelnen Aktion können durchaus mehrere Tätigkeiten zusammengefasst sein.

Horizontale Anordnung

Auch die Bildung von Ebenen unterschiedlicher Detaillierung für Übersichtsnotationen in der Unternehmensmodellierung ist damit mög­lich. Sogar mit exakten Verweisen zwischen den Ebenen, durch die sog. Strukturierten Aktivitätsknoten. Allzuviel ist das aber nicht.

Vgl. zu den damit entstehenden Möglichkeiten in der Unternehmensmodellierung Abschnitt 10.5.

(8) Verweise, Verknüpfungen

Verweise liegen in einfacher Form vor (vgl. Abschnitt 10.8 und das Beispiel Teiledesign und Teilebeschaffung in Abschnitt 10.11-4). Durch ein grafisches Symbol in einer Aktion wird dabei der Verweis deutlich gemacht. Die Bezeichnung der Aktion ist auch die Bezeichnung der eingebetteten Aktivität.

Von einem Aktivitätsdiagramm zum nächsten

(9) Berücksichtigung der zeitlichen Dimension

Sie ist – zumindest in der einfachsten Form – vorhanden, entsprechend dem Grundgedanken, dass Aktionen durch Ereignisse ausgelöst werden und dass ihre Beendigung ebenfalls durch ein Ereignis markiert werden kann. Wie die UML-Autoren dies in ihr Theoriegebäude umsetzen ist in Abschnitt 10.9 kurz beschrieben.

Ereignis –
Tätigkeit –
Ereignis

(10) Träger

Ein solches Konzept liegt nicht vor, zumindest nicht deutlich aufbereitet. In die Richtung deutet der Begriff „subject“  (vgl. Exkurs in Abschnitt 12.1). Auch wenn dieses dann als das „system under consideration“ [OMG 2003a, S. 503] definiert wird. Letzteres spiegelt auch die Unschärfe in der Abgrenzung zwischen Systemen und Geschäftsprozess wider.

… des gesamten Geschäftsprozesses

9.10.3 Weitere Theorieelemente

Der obige Abschnitt fragte ab, ob die grundsätzlichen Elemente für eine Methode zur Prozessmodellierung bei Aktivitätsdiagrammen vorhanden sind. Hier werden nun weitere Elemente der Methode AD vorgestellt, die einen Hinweis auf die Denkweise der UML-Autoren geben und die vielleicht für eine Weiterentwicklung der Prozessmodellierung genutzt werden können.

Der Hinweis zielt insgesamt auf eine stärker integrierte Sichtweise des Prozessgeschehens, auf eine Gesamtsicht aller Prozesse eines Unternehmens.

Gesamtsicht – Eine neue Sichtweise

Einzelprozesse oder Gesamtheit der Prozesse

Es gibt tatsächlich einige Aspekte der Methode AD, die einen deutlichen Hinweis zur Überwindung einer Einzelprozesssicht geben. Diese ist in der Prozessmodellierung immer noch die Regel und auch zu Recht, wird aber in der Zukunft nicht genügen. Bevor dies vertieft wird, hier die Aspekte, von denen die Hinweise stammen.

Arbeitet man gewöhnlich mit Geschäftsprozessen, kommt einem das oben vorgestellte Theorieelement Flussende überflüssig vor. Wird – z.B. bei einer EPK – ein Geschäftsprozess gestartet, kann er auf folgende Weise enden:

Flussende

• Falls nur ein Kontrollflusszweig vorliegt durch ein Ereignis am Ende desselbigen. Dieses wird dadurch zu einem Schlussereignis.
• Falls in der Schlussphase des Geschäftsprozesses mehrere von einem ODER bzw. XODER – Operator herrührenden Kontrollflusszweige vorliegen durch das Ereignis am Ende des Kontrollflusszweiges, der bei der jeweiligen Instanz des Geschäftsprozesses aktiv ist. Dieses wird dadurch ebenfalls zu einem Schlussereignis.

In beiden Fällen endet damit der Geschäftsprozess als Ganzes, wodurch die Schlussereignisse dem UML – Element Aktivitätsende entsprechen. Einen Bedarf, einzelne Zweige abzuschalten, gibt es insoweit nicht.

Etwas ähnliches wie Beenden einzelner Zweige liegt bei Ereignisgesteuerten Prozessketten vor, wenn mehrere durch UND verknüpfte Kontrollflusszweige vorliegen. Dies drückt ja Teilaufgaben aus und jedes Ende signalisiert die Erledigung einer solchen. Also auch hier kein Bedarf an einem Flussende.

Kurz gesagt: Ein Flussende ergibt keinen Sinn, wenn ein Prozess gestartet wird, seinen Kontrollfluss durchläuft und dann auf die beschriebene Weise endet. Einen Sinn macht solch ein Element erst, wenn mehrere unabhängig voneinander agierende Kontrollflüsse vorliegen.

Keinen Bedarf an einem Flussende

Dies ergibt sich z.B., wenn das Blickfeld auf mehrere Geschäftsprozesse oder sogar auf alle Geschäftsprozesse eines Unternehmens bzw. sogar zusätzlich auf das Prozessumfeld des Unternehmens erweitert wird. Dann sind zahlreiche Prozesse aktiv, zwischendurch auch nicht, werden wieder aktiviert, usw. Dann kann man sich ein Element Flussende im Sinne von Abschalten einzelner Teilprozesse durchaus vorstellen. So wird z.B. der Prozess Angebotserstellung nur benötigt, wenn eine Kundenanfrage eingeht, usw.

Mehrere zusammenwirkende Geschäftsprozesse

Das entscheidende ist also die Perspektive. Löst man sich von der Betrachtung einzelner Geschäftsprozesse, ordnet man sozusagen alles in den übergreifenden Geschäftsprozess Leistungserbringung (eines Unternehmens) ein, entsteht ein unternehmensweites Prozessmodell und jeder Geschäftsprozess ist Teil davon.

Leistungs-
erbringung

Damit sind wir von der Konstruktion her in Richtung System gerückt: Die Geschäftsprozesse eines Unternehmens als ein System.

Richtung System

So weit wie manche jetzt vielleicht denken, sind wir davon nicht entfernt. Siehe die weitgehend automatisierten Geschäftsprozesse der Internetunternehmen. Dass die Theorieelemente der UML diesen Hinweis geben rührt von ihrer Herkunft vom Systemdenken her und ist insofern nicht überraschend.

Geht man von Systemen aus, muß man gar nicht fragen und es wurde oben schon angedeutet. In einem komplexen System werden natürlich Komponenten und d.h. ihre Aktivitäten aktiv oder auch wieder inaktiv, wenn sie nicht mehr benötigt werden. Hier ist es durchaus sehr sinnvoll, einzelne Subsysteme sozusagen zwischendurch abschalten zu können.Vgl. zu diesen Überlegungen auch Kapitel 14.

Aus Systemsicht

Mit obigem sind auch die von den UML-Autoren vorgestellten nicht alternativen Startknoten sinnvoll.

Nicht alternative Startknoten

Aus der Prozessmodellierung ist man gewöhnt, dass es zwar mehrere Startknoten geben kann, dass diese aber alternativ sind. D.h. die Standard­prozessmodellierung geht davon aus, dass ein Prozess einmal gestartet wird, seine Aufgabe erfüllt und dann fertig ist. Wenn er wieder benötigt wird, wird er wieder gestartet. Aber bei jeder Instanz des Geschäftsprozesses immer nur jeweils von einem Startereignis.

Bei einer Gesamtsicht und –modellierung, wäre der Einbau nicht alternativer Startpunkte unvermeidlich.

Auch die von den UML-Autoren immer wieder thematisierte Nebenläufigkeit, das parallele unabhängig voneinander erfolgende Agieren einzelner Prozesse, ist dann nicht nur vorstellbar sondern notwendig.

Nebenläufigkeit

Ein weiterer Hinweis ergibt sich durch die Elemente restart und streaming, mit denen das Grundschema durchbrochen wird, dass eine Tätigkeit erst neu starten kann, wenn die vorige Aktivierung beendet ist.

Ständiger Neustart

Ersteres bedeutet, dass ein Prozess, der noch aktiv ist, gleich nochmals gestartet werden kann. In der Standardprozessmodellierung wird unausgesprochen davon ausgegangen, dass ein einmal gestarteter Prozess erst abgewickelt sein muß, bevor er neu gestartet werden kann. Dies ist auch durch die grafische Darstellung des Kontrollflusses, nicht anders möglich.

Restart

Auch das streaming-Konzept gehört hierher. Wie oben dargestellt, bedeutet streaming, dass eine bereits aktive Aktion weiterhin Input annehmen und Output abgeben kann. Sie bleibt also permanent aktiv.

streaming

Durch Systemorientierung zur Gesamtsicht

Insgesamt also deutliche Hinweise auf eine Sicht der Unternehmensabläufe, die durch eine Systemorientierung geprägt ist. Für die Prozessmodellierung wird dieser Hinweis durch den Trend zur Automatisierung der Geschäftsprozesse bedeutsam (vgl. dazu auch Kapitel 14), denn von Menschen getragene Geschäftsprozesse können kaum mit diesen Merkmalen versehen werden.

9.10.4 Defizite in Hinblick auf die Prozessmodellierung

Die Methode AD weist auch einige Defizite auf, die eine Einsetzbarkeit in der Prozessmodellierung stark einschränken.

Informationen, auf Trägern aller Art

In jedem Geschäftsprozess werden zahlreiche Informationen erzeugt, bearbeitet / verändert, gelöscht und transportiert und das auf allen möglichen Trägern. Dies muss in der Prozessmodellierung erfasst werden. Die Methode AD leistet dies nur unzureichend. Sie hat hierfür kein schlüssiges Konzept. Elemente wie Objekt und Objektflüsse durch Objektflusskanten reichen da nicht aus.

Verarbeitung und
Entstehung von Informationen nicht erfassbar.

Auf Umwegen, über das Konstrukt der Objekte, ist es dann ein Stück weit möglich. Erfasst werden kann der Objektfluss, wenn also ein Informationsobjekt (in der Prozessmodellierung typischerweise ein Geschäftsobjekt) in der Tätigkeitsfolge weitergereicht wird. Vermisst wird hier die Möglichkeit Informationsverarbeitung und –entstehung sauber zu erfassen.

Dieses Defizit rührt sicherlich daher, dass in einem Systemumfeld die Frage der Berücksichtigung aller Arten von benutzter Information nicht so nahe liegt, wie in der Prozessmodellierung. In der klassischen Prozessmodellierung muss aus vielerlei Gründen jegliche Information betrachtet werden, die eine Rolle spielt. Z.B., um Defizite in der Informationsverarbeitung zu entdecken, um beispielsweise eine bisher auf Papier erfolgte CAD-Archivierung durch eine digitale zu ersetzen (vgl. Abschnitt 6.1 in [Staud 2006]).

Systemdenken vs. Prozessdenken

Bei Systemen ist dies dagegen viel übersichtlicher. Die benötigten Informationen stehen entweder vollständig durchstrukturiert zur Verfügung (z.B. als Variablen oder Datenbankeinträge) oder werden über fest definierte Kanäle in strukturierter Form abgefragt (beim Geldautomat: Nutzereingabe, Kontoabfrage).

Systemorientierung

Informationsverarbeitung während der Realisierung der elementa­ren Tätigkeiten (Aktionen, Funktionen)

Der erste Eindruck ist: Die Möglichkeit, dies zu beschreiben, liegt nicht vor. Dies kann aber eigentlich nicht sein, selbst wenn man die Herkunft von der Systemanalyse bedenkt.

Keine Informations-
verarbeitung?

Nach einigem Nachdenken wird klar, dass es ein solches Element nicht geben kann, weil in diesem Theorieansatz nicht zwischen Prozess- und Funktionsmodellierung unterschieden wird. Weil die Informationsverarbeitung, die wir in der Prozessmodellierung den einzelnen Funktionen zuordnen, hier im Ablauf selbst steckt.

Funktions-
modellierung
vs.
Prozess­
modellierung

Dies gibt einen deutlichen Hinweis auf die Philosophie der UML-Autoren. Vgl. hierzu die Zusammenfassung zu diesem Kapitel in Abschnitt 10.11.9 und die Gesamteinschätzung in Kapitel 14.

Anmerkung: In der Prozessmodellierung ergeben sich immer wieder Funktionen mit einer tiefen inneren Struktur, mit z.T. komplexen Abläufen (z.B. „Kalkulation erstellen“, „Prognoserechnung durchführen“). Diese werden in der Prozessmodellierung nur über die Bezeichnung erfasst und in den Prozessablauf eingefügt („Was wird getan?“). Es wird aber nicht ausgeführt, wie die Funktion konkret realisiert wird („Wie wird es getan?“). Insofern wird bei der Modellierung von Geschäftsprozessen zwischen Funktions- und Pro­zess­modellierung unterschieden. Dies sollte nicht verwechselt werden mit der Zusammenfassung von Tätigkeiten für abgehobenere Prozessbeschreibungen.

Näheres hierzu in Abschnitt 15.2.

Organisationseinheiten bzw. Träger der Aktionen

Die Erfassung der Organisationseinheiten (bzw. Träger der Aktionen) ist nicht überzeugend. Weder sind mehrere Träger (bei einer Aktion) vorgesehen, noch Beziehungen zwischen diesen. Auch die grafische Einbindung ist untauglich (vgl. unten).

Keine komplexen Trägerstrukturen

Trennung von Tätigkeit und Ereignissen

Es liegt wohl daran, dass die Ereignisse erst als Bestandteile der Aktionen thematisiert werden und nicht auf derselben Ebene wie die Aktionen, dass sie in der praktischen Modellierung nicht so richtig deutlich werden. Dieser Punkt stellt insofern nicht so sehr ein Defizit der Theorie dar, gibt aber doch einen Hinweis auf einen Schwachpunkt.

Wie äußert sich dieses Defizit? Wie oben schon ausgeführt, sind in den praktischen Beispielen oftmals Aktion und positives Ergebnisereignis unausgesprochen zusammengefasst. Es gibt – in Aktivitäten – also gar kein sichtbares Ereignis. Ein Scheitern oder einfach nur alternative Ergebnisse sind nicht im Modell ausgedrückt. Vgl. dazu die oben angeführten Beispiele.

Nur positive Ergebnisse?

Dies ist der Prozessmodellierung völlig fremd. Hier sind sehr oft alternative Ergebnisse und auch ein Scheitern in der Modellierung vorgedacht.

Eine Ursache hierfür ist das Systemdenken. Bei der Modellierung von Systemen ist die Detaillierung zwangsläufig so groß, dass sich weniger Verzweigungen ergeben und dass nicht bei jeder Aktion ein Scheitern angedacht wird.

Kein Oder-Operator

Für Aktivitätsdiagramme ist kein Oder-Operator (nicht-exklusives ODER) vorgesehen. Das ist bedauerlich, denn in der Prozessmodellierung wird dieser durchaus benötigt. D.h. die Semantik „Mindestens eines der verknüpften Ereignisse muß eintreten, damit es weitergeht“ oder „Mindestens eine der verknüpften Funktionen muß realisiert werden“ kommt tatsächlich vor.

Komfort

Dieser Operator kann zwar durch eine Kombination von XODER- und UND-Operatoren ersetzt werden, was aber umständlich ist. Insofern ist das nicht exklusive ODER eine sinnvolle Ergänzung der Operatoren der Prozessmodellierung, die hier aber fehlt.

Vgl. zu den Hinweisen, die dieses Fehlen gibt, Abschnitt 10.11 und Kapitel 14.

9.10.5 Grafische Gestaltung

Es ist nun mal so: Eine Methode zur Prozessmodellierung muss auch eine Umsetzung der Modelle in Grafiken umfassen.

Die grafische Umsetzung der Aktivitäten in Aktivitätsdiagramme ist insgesamt akzeptabel, wobei die Übersichtlichkeit noch steigt, wenn der Kontrollfluss von oben nach unten angeordnet wird (vgl. die Beispiele unten). In einigen Punkten ist sie allerdings auch verbesserungswürdig. Z.B. bei der Erfassung der Organisationseinheiten (Träger der Aktionen). Die Zuordnung der Organisationseinheiten wird in allen drei Darstellungsvarianten schnell unübersichtlich.

Unzureichend:
Träger der Aktion

Auch die Einbindung der Objekte ist nicht überzeugend gelöst. Sie ist auch schwierig wenn, wie in Aktivitätsdiagrammen, der Fluss der Objekte neben dem Kontrollfluss ausgedrückt werden soll.

Auch die Darstellung wirklich umfassender und zahlreicher Verzweigungen, wie sie in Geschäftsprozessen nötig sind, ist umständlich. Dies gilt auch für die Verdeutlichung der Entscheidungsprozesse, die den Verzweigungen des Kontrollflusses zugrundeliegen.

Insgesamt gilt, dass Aktivitätsdiagramme bei der Darstellung wirklicher Geschäftsprozesse (vgl. z.B. die Geschäftsprozesse in Kapitel 6 von [Staud 2006] sowie WebZumBuch_UM01) schnell unübersichtlich werden.

„Wirkliche Geschäftsprozesse“

9.10.6 Verknüpfung mit der übrigen objektorientierten Theorie

Die Methode AD ist mit den übrigen Theorieelementen der UML kaum verknüpft. Sie ist sicherlich eine effiziente Methode zur Modellierung der Abläufe in Systemen und kann auch Hinweise geben für eine Weiterentwicklung der Prozessmodellierung, einen Integrationsbeitrag leistet sie aber nicht. Weder zum „Strukturteil“ (objektorientiertes Modell, Klassendiagramm) noch zu den übrigen Elementen der objektorientierten Theorie.

Aufgepfropft

Die einzige denkbare Verknüpfung ist die, dass Aktionen Methoden (einer Klasse) sind, oder Aktivitäten durch Methoden aufgerufen werden.

Das ist schon überraschend. Vielleicht drücken aber auch die Aktivitätsdiagramme nur den Wunsch der UML-Autoren aus, stärker das Prozessgeschehen im Theoriegebäude zu berücksichtigen.

9.10.7 Vergleich der beiden Methoden (AD und EPK)

Vergleicht man die beiden Methoden wird schnell deutlich, dass die Modelle auf einer mittleren methodischen Ebene beinahe problemlos ineinander überführt werden können. Schwieriger wird es, methodisch oder in der grafischen Darstellung, wenn die Prozessbeschreibung tiefer geht:

Wie immer in diesem Text:
AD =
Aktivitätsdiagramm

• wenn zum Beispiel die EPK zahlreiche detaillierte Verzweigungen enthält mit oder ohne den nicht-exklusiven ODER-Operator.
• wenn in die EPK zahlreiche Organisationseinheiten eingebaut sind.
• wenn zum Beispiel in einem Aktivitätsdiagramm Konzepte wie Ne­benläufigkeit, streaming, unabhängige Startknoten (d.h. solche, die Richtung Gesamtsicht zielen, vgl. oben) umgesetzt sind.

Im folgenden nun einige Ergebnisse des Methodenvergleichs auf dieser Ebene. Anschließend folgen einige direkte Vergleiche von EPKs und Aktivitätsdiagrammen. Weiteres dazu findet sich in WebZumBuch_UM01.

Die strikte Trennung von Objekt- und Kontrollfluss, wie er für Aktivitätsdiagramme vorgesehen ist, kann in Ereignisgesteuerten Prozessketten nicht realisiert werden. Hier sind Objekte (im Sinne von Geschäftsobjekten) immer mit der Funktion (Tätigkeit) verbunden, bei der sie gelesen, erzeugt, verändert oder transportiert werden.

Spezifizierung Objektfluss

Eine Kantengewichtung bei Objektflüssen, vgl. Abbildung 10.7-13 mit {weight=all}, ist in EPKs durch Spezifizierung der Funktion möglich. Überhaupt erweisen sich die Beschriftungen der Funktionen, Ereignisse, Organisationseinheiten und Informationsobjekte als ein Werkzeug, mit dem viel von den Modellaussagen bei Aktivitätsdiagrammen in Ereignisgesteuerten Prozessketten ausgedrückt werden kann.

Kanten-
gewichtung

Ein Auswahlverhalten, vgl. das Beispiel in Abbildung 10.11-3, wäre ebenfalls durch eine Funktion möglich.

Auswahl-
verhalten

Ein ständiger Fluss von Objekten mit {stream} ist in EPKs sinnvoll nicht zu realisieren. Das Grundkonzept ist hier die für die Prozessmodellierung übliche Vorstellung von sequentiell nacheinander ablaufenden elementaren Tätigkeiten. Ein streaming-Konzept sprengt den Rahmen dieses Grundkonzepts[5]. Dabei kann man sich Lösungen zu den Beispielen in den Abbildungen 10.4-20, 10.4-21 und 10.4-24 eher vorstellen als zum Beispiel in Abbildung 10.10-5, wo der streaming-Vorgang quasi parallel zum sonstigen Kontrollfuss angelegt ist.

streaming

Parameterknoten machen bei einer Übertragung keine Schwierigkeiten. Sie werden in einer EPK einfach als Informationsobjekte modelliert, die zu Beginn in den Prozess hineingegeben („Auftrag eingegangen“) oder am Ende als weiterzugebendes Ergebnis („Kalkulation weiterleiten“) herausgegeben werden.

Parameter-
knoten

Alle Elemente bei Aktivitätsdiagrammen die Richtung Gesamtsicht (vgl. oben und die Zusammenfassung unten) zeigen, sind in Ereignisgesteuerten Prozessketten nicht oder nur sehr schwer nachbildbar.

Die in den Beispielen öfters aufschimmernden Unklarheiten bzgl. der Festlegung des Entscheidungsprozesses (vgl. Beispiel Problembehandlung in Abbildung 10.11-6) muss bei einer Übernahme in eine EPK durch entsprechende Funktionen und Ergebnisereignisse modelliert werden. Die Erzwingung von Ereignissen, die Ergebnisse der vorangehenden Funktion erfassen, führt automatisch dazu.

Unklarheiten

Das Konzept der „Wächter“, also der Bedingungen, die geprüft werden, bevor ein bestimmter Schritt gegangen wird, ist problemlos in EPKs realisierbar, als Funktion, die genau die Überprüfung der Bedingung realisiert.

Wächter

Die Join-Spezifikation, bei der eine Vereinigung mit einer Festlegung präzisiert wird (vgl. die Abbildungen 10.7-14 und 10.7-15), ist problemlos in die Struktur „Funktion + Ergebnisereignisse“ abbildbar, als Bedingung dafür, dass der verknüpfende UND-Operator überwunden werden kann.

Join-Spezifikation

In einigen Beispielen, die auch wiederholt thematisiert werden, wird deutlich, dass sich die UML-Autoren ein Weiteragieren einzelner Aktionen trotz Abbruchs an anderer Stelle (durch ein Flussende) vorstellen. Vgl. dazu die Ausführungen am Ende von Abschnitt 10.10.3 und die Abbildung 10.7-19. Hier bleibt die Aktion Baue Komponente ein aktiv, auch wenn keine weiteren Komponenten herzustellen sind.

Innere Schleife

Dies ist gegenüber dem Grundkonzept eine deutliche Erweiterung der Möglichkeiten zur Ablaufbeschreibung (vgl. die Ausführungen zum Stichwort Gesamtsicht). Grundsätzlich auch eine sinnvolle, insbesondere wenn man an Systemanalyse und Programmrealisierung denkt, denn hier gibt es tatsächlich viele Komponenten, die aktiv sein müssen obwohl Teile des Systems nicht mehr aktiv sind.

Systemorientierung

In Ereignisgesteuerten Prozessketten ist zumindest dieses Aktivbleiben recht einfach durch Schleifen nachbildbar.

In der Methode EPK werden Ereignisse als solche direkt in den Kontrollfluss eingebunden und beeinflussen ihn auf vielfältige Weise.

Ereignisse

In der UML dagegen erfolgt die Kontaktaufnahme zwischen Ereignis und Ablaufbeschreibung über Aktionen, die in den Kontrollfluss eingebunden sind und die auf das entsprechende Ereignis warten. Dieses Warten könnte auch als implizite Schleife, wie es die UML-Autoren an anderer Stelle gern tun, interpretiert werden.

Ein wenig erinnert dies an die Konstruktion, wenn in Ereignisgesteuerten Prozessketten eine Funktion Warten eingebaut wird. Da bleibt dann der Prozess stehen, bis eines der angedachten Ergebnisereignisse eintritt.

Dieser Unterschied im Umgang mit Ereignissen hat eine tiefere Ursache. Da in der UML Tätigkeit (Verhalten) nicht von den möglichen Ergebnissen getrennt wird, ist nur auf die beschriebene Weise (durch eine Aktion die auf ein Ereignis wartet) die Einbindung externer Ereignisse möglich.

Letztendlich kann man diese Lösung, Ereignisse durch auf Ereignisse wartende Aktionen einzubinden, aber nur dann verstehen, wenn man akzeptiert, dass die UML durch ihre Hauptaufgabe, Systemanalyse und Vorbereitung der Programmierung geprägt ist. Denn für einen Programmierer ist eine solche Aktion ein direkter Hinweis auf ein Programmelement. Z.B. auf das, das beim Geldautomaten „Bereitschaft“ herstellt und das Karteneinzugserät samt Lesevorrichtung aktiv hält.

Klärung
Programm-
struktur

9.10.8 AD und EPK im direkten Vergleich

Wenigstens kurz soll hier noch betrachtet werden, wie es um die Übertragung von Aktivitätsdiagrammen in eine Methode der Standardprozessmodellierung (hierfür wurde die Methode EPK gewählt) steht. Ist sie möglich? Wo liegen die Probleme? Mehr dazu in WebZumBuch_UM01.

Von AD zu EPK

Alle hier verwendeten Aktivitätsdiagramme kommen oben in diesem Kapitel vor. Die größeren sind hier aber grafisch anders angeordnet – von oben nach unten und nicht nicht wie bei den UML-Autoren von links nach rechts. Dies dient dazu, den Vergleich mit den Ereignisgesteuerten Prozessketten zu erleichtern.

Aktivität Auftragsbearbeitung

Das einführende Beispiel zu diesem Kapitel kommt in mehreren Varianten vor (vgl. die Abbildungen 10.3-1, 10.9-1 und 10.9-2). Für diesen Vergleich wurde 10.9-2 genommen, eine der Versionen mit Angabe der Organisationseinheiten. Die folgende Abbildung zeigt das Aktivitätsdiagramm, danach ist die entsprechende EPK angegeben.

Die Übertragung ist fast problemlos. Der Parameterknoten Auftrag wird zu einem Informationsobjekt, das der Funktion Auftragseingang zugeordnet ist.

Parameterknoten = Informationsobjekt

Anmerkung zu den EPKs: Der Verfasser hält sich an die Originalversion von Scheer, mit einer Ausnahme: Informationsobjekte, die lediglich transportiert werden, erhalten eine Verbindungslinie zur Funktion ohne Pfeilspitze.

Grundsätzlich sind Aktionen (Aktivitätsdiagramm) und Funktionen (EPK) gleichzusetzen, EPK-seitig müssen nur die Ereignisse spezifiziert werden. Deshalb entsteht hier für die Aktion Auftragseingang eine gleichnamige Funktion im Sinne von „Eingehenden Auftrag bearbeiten“.

Aktion = Funktion
…
meist

Ebenso problemlos können die Träger der Aktionen (Organisationseinheiten) übernommen werden. Umgekehrt wäre es schwieriger. Wie soll man eine größere Zahl von Organisationseinheiten (insgesamt und bzgl. einzelner Funktionen/Aktivitäten) in einem Aktivitätsdiagramm ausdrücken?

Die nachfolgende Verzweigung wurde hier in der EPK mit einer eigenen Funktion (Machbarkeitsprüfung) gelöst. Diese Entscheidungsfindung hätte aber auch gleich in Auftragseingang mit hineingepackt werden können. Die Kantenbeschriftungen des Aktivitätsdiagramms werden dann zu „Ergebnisereignissen“ der Funktion.

Verzweigung

Die nachfolgende Gabelung (AD) kann durch einen entsprechenden UND-Operator ausgedrückt werden, ebenso wie die später folgende Vereinigung (AD).

Beim Einbau der Aktionen des Kunden in die Ereignisgesteuerte Prozesskette ist etwas Nachdenken nötig. Im Aktivitätsdiagramm ist die Handlung des Kunden (Zahlung durchführen) einfach in den Kontrollfluss, der ja ansonsten vom Unternehmen realisiert wird, eingebaut. Dies wird in der Prozessmodellierung typischerweise nicht so gemacht[6]. Dort wird zwischen dem Träger (oder den Trägern) des Prozesses und den Partnern des Prozesses entschieden. Dies ändert sich gerade, wenn zum Beispiel integrierte webbasierte Systeme für die Wertschöpfungsketten mehrerer zusammenarbeitender Unternehmen entwickelt werden, bzgl. der Kundenkontakte ist es aber meist so wie beschrieben: Die Handlungen des Kunden sind nicht Teil der Unternehmensprozsse.

Externe Aktivitäten

Die beiden in der Modellierung mit Ereignisgesteuerten Prozessketten typischen Vorgehensweisen sind in der EPK eingefügt. Entweder eine Wartefunktion (Warten auf Zahlungseingang) mit ihren Fortsetzungen (linke Seite, als Alternative gekennzeichnet) oder ein externes Ereignis (Zahlung eingegangen) mit seinen Fortsetzungen (rechte Seite) und der Einbindung durch den UND-Operator

Vgl. zu beiden Konzepten
[Staud 2006]

Das Zusammenführen der Verzweigungen am Ende des Aktivitätsdiagramms kann wieder direkt in der EPK abgebildet werden.

Verzweigungen zusammenführen

Die folgende Abbildung zeigt die Ereignisgesteuerte Prozesskette, die dieser Aktivität entspricht.

Komponentenverarbeitung

Auch eine Aktivität mit Schleifen, Aktivitäts- und Flussenden und einer insgesamt eigenwilligen Architektur (vgl. Abschnitt 10.6.6) lässt sich in eine EPK abbilden.

Die Aktion Stelle Komponente her wird zu einer entsprechenden Funktion. Die Rückschleife wird in der EPK durch einen XODER-Operator vor der Funktion modelliert (vgl. zu Rückschleifen in EPKs [Staud 2006, Abschnitt 5.1]).

Aktion zu Funktion

Das Anstoßen der Aktion Baue Komponente ein und des Entscheidungsvorgangs, ob weitere Komponenten zu bauen sind wird mit einem UND-Operator modelliert. Der Entscheidungsvorgang muss allerdings in der EPK durch eine eigene Funktion (Prüfen, ob weitere Komponenten herzustellen sind) realisiert werden.

Nach der Prüfung wird in der EPK der Rücksprung realisiert. Das Flussende (AD) einfach durch ein Schlussereignis.

Rücksprung

Im Kontrollfluss wird dann die Aktion Baue Komponente ein angestoßen. Ebenso in der EPK.

Danach muß wieder für die Verzweigung im Aktivitätsdiagramm eine Entscheidungsfunktion (Prüfen, ob weitere Komponenten zu installieren sind) eingefügt werden mit den entsprechenden „Ergebnisereignissen“.

Das Flussende bei [weitere Komponenten zu installieren] und die anhaltende Ausführung der Aktion Baue Komponetnen ein (vgl. die Ausführungen hierzu in Abschnitt 10.6.6) kann in der EPK durch eine Rückschleife modelliert werden (in der Abbildung dick gezeichnet).

Getränkeautomat

Das kleine Beispielsfragment von Abbildung 10.7-15 hilft, auf ein weiteres Merkmal vieler Beispiele von Aktivitätsdiagrammen in den UML-Unterlagen hinzuweisen.

Die im obigen Beispiel vorliegende Vereinigung entspricht dem UND-Operator, wie er in Ereignisgesteuerten Prozessketten verwendet wird. Das Beispiel oben macht aber folgendes deutlich: Im Vergleich mit EPKs ist eine Aktion hier gleich „Funktion + positivem (Ergebnis-)Ereignis“ dort. D.h., die UML-Autoren fassen das eigentliche „Geschehen“ in der Aktion mit dem positiven Ergebnis zusammen. Dies rührt daher, weil sie grundsätzlich weniger Verzweigungen realisieren und dann, wenn schon keine betrachtet werden, natürlich die positive Alternative genommen wird.

Aktion=Funktion + positives Ergebnis

Die Methode EPK dagegen trennt dies ganz grundsätzlich. Das „Geschehen“ in der Funktion ist getrennt von allen möglichen Ergebnissen. Diese werden durch die ja zwangsweise (von der Syntax erzwungenen) nachfolgenden Ereignisse modelliert.

Funktion –
Ereignis –
Funktion –
…

Obige Vereinigung würde bei EPKs durch eine Folge von Funktionen und Ereignissen modelliert. Die folgenden Abbildungen zeigen in zwei Varianten das obige Beispiel in EPK-Notation.

Die erste Abbildung realisiert die beiden Aktionen parallel, insgesamt eingebunden in ein durch zwei logische UND gebildetes Zeitfenster. Diese Lösung wird gewählt, wenn die Reihenfolge der Tätigketien nicht beachtet werden soll (wie ja auch im Aktivitätsdiagramm).

Angedeutet sind aber auch die Möglichkeiten des Scheiterns: Münzen nicht ausreichend bzw. Kein passendes Getränk gefunden. Hier würden in einer ernsthaften Prozessbeschreibung die dadurch notwendigen Tätigkeiten folgen.

Scheitern?

In der nächsten Abbildung sind die beiden Funktionen hintereinander angeordnet. Hier wird also eine Reihenfolge angenommen. Lediglich bei einer Funktion ist das mögliche Scheitern angedeutet.

Insgesamt macht dieses Beispiel deutlich, dass das ausdrückliche Anfordern von Ereignissen in Ereignisgesteuerten Prozessketten eine segensreiche Wirkung hat: Die Aussagekraft wird erhöht und außerdem wird das Erkennen von Verzweigungen eher angestoßen.

Erzwungene Ereignisse

Problembehandlung

Als nächstes nun ein Beispiel mit mehr (ernsthaftem) Prozesscharakter. Es ist die oben betrachtete Problembehandlung, hier allerdings aus Darstellungsgründen in eine senkrechte Anordnung gebracht.

Dieses Beispiel weist eine komplexe Verzweigungsstruktur auf, die aber ohne Schwierigkeit übertragen werden kann. Auch die zahlreichen Sprünge nach „flussabwärts“ können durch Einfügen entsprechender Operatoren in der EPK problemlos realisiert werden. Dasselbe gilt für die Rücksprünge. Sie werden in Aktivitätsdiagrammen, wie es ja auch sinnvoll ist, direkt auf einen Operator vor eine Aktion geführt. Entsprechend erfolgt in der EPK – wie dort ja auch syntaktisch vorgeschrieben – der Wiedereinstieg der Rückschleife mit Hilfe eines XODER-Operators vor eine Funktion.

Zahlreiche Verzweigungen, Sprünge und Rücksprünge

Bei den Entscheidungsvorgängen müssen wiederum Ergänzungen vorgenommen werden und zwar überall dort, wo die Entscheidungsfindung in der Aktivität nur über die Kantenbeschriftungen modelliert ist. Hier bei Problemdarstellung richtigstellen.

Auf das Wiederzusammenführen der Kontrollflüsse ganz am Ende des Aktivitätsdiagramms wurde in der EPK verzichtet. Dort ist das nicht üblich, das Ende wird durch die Schlussereignisse signalisiert.

Die andere Richtung

Die Übertragung in die andere Richtung, von Ereignisgesteuerten Prozessketten zu Aktivitätsdiagrammen ist – zumindest auf einer oberflächlichen Ebene – ebenfalls möglich. Dies kann allerdings hier aus Platzgründen nicht dargestellt werden. Vgl. WebZumBuch_UM01.

Von EPK nach AD

9.10.9 Zusammenfassung

Die obigen Ausführungen zeigen, dass Aktivitätsdiagramme von den Anforderungen der Systemanalyse geprägt sind, auch wenn die Beispiele in [OMG 2003a] etwas anderes suggerieren. Und dies – wie oben hoffentlich auch deutlich wurde – bis in die tieferen Schichten der Theorie. Dies hat, wie ebenfalls dargelegt wurde, zwei modelltechnisch bedeutsame Konsequenzen:

Systemorientierung

• Sie taugen nur eingeschränkt für die Prozessmodellierung
• Sie geben Hinweise für deren Weiterentwicklung (v.a. durch den Punkt “Gesamtsicht“)

Diese Hinweise sind von grundsätzlicher Bedeutung und erhalten noch mehr Gewicht, wenn man die Tendenz zu vollautomatisierten Geschäftsprozessen sieht. Sie wurden oben unter drei Bezeichnungen zusammengefasst:

• Funktionsmodellierung vs. Prozessmodellierung
• Systemdenken vs. Prozessdenken
• Gesamtsicht

Die Ursache für alle drei Aspekte ist die ausgeprägte Systemorientierung der UML-Autoren.

Letzendlich macht die parallele Betrachtung von Aktivitätsdiagrammen und einer Methode der Standardprozessmodellierung (hier EPKs) auch deutlich, dass Prozessmodellierung und systemnahe Modellierung verschiedene Dinge sind. Gemeinsam ist ihnen, dass sie Abläufe erfassen, danach kommen aber Besonderheiten der beiden Modellierungsebenen (Prozessebene, Systemebene), die zu unterschiedlichen Theorieausprägungen führen.

Systemdenken vs. Prozessdenken

Darüber hinaus wird deutlich: Wer in Systemen denkt, tut sich schwer, eine wirkliche Prozesssicht einzunehmen.

Sozusagen als Teilaspekt des obigen ergab sich dieser Punkt. Die für die Prozessmodellierung wichtige Unterscheidung von Funktions- und Prozessmodellierung ist in Systemen nicht brauchbar. Geht man, wie die UML-Autoren, (unausgesprochen) von Systemen aus, fällt es einem deshalb schwer, die Unterscheidung in das eigene Theoriegebäude einzubauen (außer in Beispielen).

Funktions-
modellierung vs. Prozess-
modellierung

Auch der Aspekt der speziellen Betrachtungsweise wurde oben ausführlich beschrieben, hier nur einige ergänzende Anmerkungen. Eine zentrale Botschaft der Aktivitätsdiagramme, abgeleitet aus ihrer systemnahen theoretischen Konstruktion ist (wenn man so will): Beendet die Einzelprozesssicht, kommt zu einer Gesamtsicht aller Prozesse eines Unternehmens, so wie bei Systemen.

Blickfeld, Blickwinkel

Dies ist tatsächlich ein Hinweis auf ein Defizit heutiger Standardprozessmodellierung und, nimmt man den Automatisierungstrend (vgl. unten) ernst, auf die Notwendigkeit einer ergänzenden systemnahen Prozessmodellierung, wie sie in Abschnitt 15.1 kurz beschrieben wird.

Defizit

In diesem Kapitel wurde mehrfach auf den Trend zur vollständigen Automatisierung von Geschäftsprozessen hingewiesen und auf deren Konsequenzen. Dies soll nicht bedeuten, dass die heutige ERP-Software (außerhalb der beschriebenen Web-Unternehmen) nicht auch schon teilweise automatisiert ist. Geht man von folgender einfachen Skala bezüglich des Automatisierungsgrades von Geschäftsprozessen aus:

Automatisierung

• unterstützt die Nutzer in einzelnen Funktionen (Stufe 1);
• unterstützt die meisten Funktionen, führt einige automatisiert aus, überlässt einige den beteiligten Menschen (Stufe 2);
• unterstützt alle Funktionen, führt fast alle automatisiert aus (auch die mit den Partnern des Geschäftsprozesses), überlässst den Menschen nur noch die Entscheidungen und die Ausnahmefälle (Stufe 3),

dann hat ERP-Software inzwischen die Stufe 2 erreicht.

Die Prozessmodellierung wird aber, da wir in Teilbereichen (die sich mit Sicherheit beständig vergrößern werden) inzwischen Stufe 3 erreicht haben, einen weiteren Schritt tun müssen. Sie wird, ergänzend zur Standardprozessmodellierung eine systemnahe Prozessmodellierung realisieren müssen (vgl. Abschnitt 15.1).

Systemnahe Prozess-
modellierung