Metamodellbasierte und hierarchieorientierte ... - RosDok

3.2 Workflow-Metamodell 35
der BPMN 1.2 Spezifikation übernommen [BPM09]. Damit wurden alle Elemente im BPMN-Prozessmodell
bezeichnet, die mit Kanten verbunden werden. In der neueren BPMN Spezifikation [BPM11] wurde ein
Metamodell entwickelt, in dem FlowObjects nun als FlowElements bezeichnet werden (s. Abbildung 2.5(c)).
Die Klasse Process beschreibt Prozessobjekte. Diese werden über das Attribut name bezeichnet. Zudem
können spezielle Prozesse anhand der Klasse CancelProcess im Workflowmodell verwendet werden, die
während der Ausführung vom Nutzer abgebrochen werden können. Näheres dazu wird in Unterabschnitt
3.2.4.5 erläutert. Über die Assoziation includes werden Prozessobjekte mit FlowObjects verbunden und
damit als Elemente vom Prozess aufgenommen. Aus praktischen Gründen brauchen nicht alle zugehörigen
Modellierungselemente mit dem Prozessobjekt verlinkt werden. Es gilt hier der Grundsatz: Wenn ein
Modellierungselement zu einem Prozess gehört, dann auch die, die indirekt über beliebige Assoziation aus
dem Metamodell erreichbar sind. Die Berechnung der transitiven Hülle, um alle enthaltenen Modellelemente
einzusammeln ist Teil des Metamodells und Thema in Unterabschnitt 3.2.3.2. Somit spart man viele Verbindungen
der Assoziation includes in den Prozessmodellen. Diese werden dadurch deutlich übersichtlicher
und lesbarer.
Die abstrakte Klasse FlowObject hat wiederum die abstrakte Klasse FlowOperator als Unterklasse. Deren
Unterklassen stellen Flussoperatoren dar. Diese werden bei EPKs als Konnektoren, bei Aktivitätsdiagrammen
als ControlNodes und BPMN als Gateways bezeichnet. Die Klasse AndOperator repräsentiert einen And-
Konnektor in EPKs bzw. einen split- bzw. join-Knoten bei UML-Aktivitätsdiagrammen. Führen mehrere
seq-Links in den Knoten, ist dieser Knoten als join anzusehen. Die Kontrollflüsse werden an diesem
Knoten synchronisiert. Es wird also auf die Abarbeitung aller verbundener Aktivitäten gewartet, bis die
nachfolgenden Aktivitäten ausgeführt werden können. Hat der Knoten dagegen mehrere seq-Links, die
herausführen ist ein split vorhanden. Die damit verbundenen Aktivitäten können dann also unabhängig
voneinander ausgeführt werden. Analog zu UML-Aktivitätsdiagrammen können auch beim DMWM-Ansatz
hybride AndOperator-Knoten existieren, in die mehrere seq-Links hineingehen und auch herauskommen.
Diese Knoten sind dann sowohl als join als auch als split-Knoten anzusehen.
Des Weiteren gibt es bei den Flussoperatoren die Klasse MergeOperator, die dazu dient, Flüsse zusammenzuführen,
ohne sie zu synchronisieren. Als letztes gibt es noch die Klasse Discriminator. Diese Klasse
wird für ein spezielles Workflow Pattern benötigt. Aktivitätsabfolgen, die mit seq-Links verknüpft werden,
werden nicht synchronisiert. Bereits nach Erledigung der ersten Vorgängeraktivität, können die Nachfolgeaktivitäten
abgearbeitet werden. Alle weiteren Vorgänger-Aktivitäten können dann ohne weitere Konsequenzen
beendet werden. In Unterabschnitt 3.2.4.2 erfolgt eine näher Erklärung zum Workflow Pattern und zu deren
Modellierung in DMWM.
Die abstrakte Klasse ActivityGroup umfasst die reflexive Assoziation exceeded. Hiermit können ebenso
wie bei der seq-Assoziation Aktivitäten und Gruppen von Aktivitäten verbunden werden. Es können damit
eine Art Timeout-Punkte im Prozessmodell definiert werden, die bei Überschreitung andere Aktivitäten
überspringen und nicht weiter ausführen lassen. Die Semantik dieser Beziehung wird für die cancellation
and force completion Workflow Patterns benötigt und in Unterabschnitt 3.2.4.5 näher beschrieben.
Die zentrale Klasse im Metamodell von Abbildung 3.2 ist Activity. Die Klasse hat ein Attribut state, das mit
Werten der Enumeration State belegt wird. Zudem umfasst die Klasse die Operationen start(), finish(), skip()
und fail(). Die spezielle Klasse Cancel umfasst des Weiteren die Operation cancel(). Die Operationen stellen
die Schnittstelle für den Nutzer bereit, der anhand dieser mit den Aktivitäten zur Runtime interagiert und
damit den Workflow steuern kann. Wie bereits in Unterabschnitt 1.2.1 beschrieben, liegt die Bestimmung
der Ausführungsreihenfolge des Workflows beim Nutzer. Dieses ist analog zu [Peš08] ein eher deklarativer
Ansatz, der weniger die Automatisierung der Workflows zum Ziel hat. Die Zustände und Methoden bei den
Aktivitätsobjekten bilden die Grundlage zur Definition der Zustandsdiagramme von Abbildung 3.3.