Metamodellbasierte und hierarchieorientierte ... - RosDok

36 Deklarative UML metamodellbasierte Workflowmodellierung
Neben Cancel gibt es noch diverse weitere spezielle Aktivitäten, die mit Vererbungsbeziehungen zur Klasse
Activity im Metamodell vorhanden sind. Zu ihnen gehört die Klasse Iteration, welche die Eigenschaft hat,
dass sie mehrfach ausgeführt werden kann. Damit hat sie ein anderes Verhalten verglichen zu dem, das im
Objektlebenszyklus in Abbildung 3.3(a) dargestellt ist. Ruft der Nutzer die Operation start() auf, leitet er
einen neuen Iterationszyklus ein. Damit wird ein neues Aktivitätsobjekt erstellt und mit Hilfe der Assoziation
iteration an das Iterationsobjekt gehängt. Der start()-Aufruf wird an das neu erstellte Aktivitätsobjekt
weiterdelegiert. Das Verhalten ist in einem Sequenzdiagramm in Abbildung 4.6(b) veranschaulicht. Anhand
dessen können zur Runtime die Anzahl und die Zeitpunkte der einzelnen Operationsaufrufe festgehalten
werden. Die abstrakte Klasse MultiInstance enthält Aktivitäten, von denen mehrere Instanzen zur gleichen
Zeit unabhängig abgearbeitet werden können. Näheres dazu und den zugehörigen Unterklassen wird in
Unterabschnitt 3.2.4.3 erklärt.
Mit Decision ist eine weitere spezielle Aktivität im Metamodell vorhanden. Diese Klasse stellt Entscheidungsaktivitäten
dar, in denen der Nutzer zur Runtime entscheidet, welcher Pfad zu nehmen ist. Während der
Designtime werden die Kriterien zur Entscheidungsauswahl in den zugeordneten Guards festgelegt. Die mit
diesen verbundenen Aktivitäten werden dann aktiviert, wenn der Nutzer den entsprechenden Pfad ausgewählt
hat. Diese Modellierungsphilosophie wird auch in EPKs verfolgt, in denen vor Entscheidungskonnektoren
eine Funktion zu modellieren ist, in der die Entscheidung aktiv zu treffen ist (s. Abschnitt 2.5.2.1). In BPMN
wird dafür ein datenbasierter Choice verwendet (s. Abschnitt 2.5.2.3). Mit der Klasse XorDecision wird
festgelegt, dass genau ein Pfad zur Runtime ausgewählt werden muss. Bei OrDecision muss mindestens ein
Pfad, es können aber auch mehrere ausgewählt werden. Diese Auswahlmöglichkeiten haben sich bei den
Sprachen EPK, BPMN und YAWL bewährt. Zusätzlich gibt es bei DMWM die Möglichkeit mit der Klasse
NandDecision, keinen Prozesspfad auszuwähen. In diesem Falle würden alle über Guards mit der Entscheidungsaktivität
verbundenen Prozesspfade geskippt werden. Das Verhalten der Entscheidungsaktivitäten und
die Benutzung zur Runtime wird Thema in Abschnitt 4.2.4 sein.
Ein weiterer wichtiger Aspekt im Metamodell ist die Gruppierung von Aktivitäten. Dieser wird ausgedrückt
durch die Klasse Group und durch die Aggregationsbeziehung group. Gruppen können spezielle temporale
Beziehungen ausdrücken. Hierüber können diverse Workflow Patterns sehr einfach modelliert werden. Dazu
gehört beispielsweise die Deferred Choice und Interleaved Parallel Routing-Beziehung, die in Abschnitt
3.2.4.4 näher erläutert werden.
Eine temporale Beziehung, die nicht bei den Workflow Patterns wiederzufinden ist, ist die Parallel-Beziehung.
Bei Aktivitäten, die zu einer solchen Gruppe gehören, wird zugesichert, dass diese parallel auszuführen
sind. Hier sind Assistenz- oder Observierungstätigkeiten denkbar, die zugesichert parallel geschehen müssen.
Beispiele für die Deferred Choice und Parallel-Gruppen werden im Modellierungsbeispiel von Abschnitt
3.5.3 verwendet. Abschnitt 3.2.4 gibt vorher eine formalere strukturierte Betrachtung der temporalen
Beziehungen mit einer Workflow Pattern-Analyse.
Eine letzte wichtige Gruppe im Metamodell stellt die Klasse IterationGroup dar. Alle Aktivitäten, die dieser
Gruppe zugeordnet sind, können zurückgesetzt werden, indem die Operation nextIteration() aufgerufen
wird. Hier ist zu beachten, dass nur bei in der Gruppe komplett abgearbeiteten Iterationszyklen anhand
dieser Operation ein neuer Iterationszyklus eingeleitet werden kann. Die durch OCL ausgedrückte formale
Semantik dafür wird in Abschnitt 3.2.3.1 näher vorgestellt. Eine spezielle Klasse, die von IterationGroup
abgeleitet wurde, ist MultiMerge. Diese realisiert das gleichnamige Workflow Pattern. Eine genauere
Betrachtung dazu wird in Abschnitt 3.2.4.2 gegeben.
Das in Abbildung 3.2 vorgestellte Klassendiagramm repräsentiert ein einziges (integriertes) Metamodell
sowohl für die Modellierung von Workflows (zur Designtime) als auch für die Beschreibung der Workflowinstanzen
(zur Runtime). Im Metamodell ist die operationale Semantik der Modellelemente mit OCL