Metamodellbasierte und hierarchieorientierte ... - RosDok

3.2 Workflow-Metamodell 37
hinterlegt. Diese wird erst zur Ausführung der Modelle relevant, sie ist jedoch bei der Workflowmodellierung
zur Designtime bereits vorhanden. Mit diesem Ansatz eröffnen wir uns die Möglichkeit, während der
Runtime die Modelle auf Basis des integrierten Metamodells zu verändern. Dieser Adaptivitätsaspekt zur
Workflowmodellierung wird in Abschnitt 4.3.4 beschrieben.
Die einzigen Daten, die für Workflowmodelle im Gegensatz zu Workflowinstanzen nicht benötigt werden sind
die Attribute start und finish in der Klasse Activity. In diesen Attributen werden die Zeitstempel festgehalten,
in denen die Zustandsänderungen der Aktivitätsobjekte stattgefunden haben. Aus Gründen der Einfachheit
wurden diese Attribute aber im Metamodell (auch für die Designtime) belassen, so dass im DMWM-
Metamodell diese Daten sowohl für Workflowmodelle als auch für Workflowinstanzen vorhanden sind. Die
Beziehungen zwischen Workflowmodell und Workflowinstanz und die dafür verwendeten Diagrammarten
werden in Abschnitt 4.2.3 näher erläutert.
3.2.2 Zustandsdiagramme
Die Aktivitätsobjekte und deren in Abbildung 3.3 dargestellten Objektlebenszyklen haben zunächst für die
Designtime keine Konsequenzen. Sie sind jedoch für die Runtime existentiell notwendig, indem sie die
Grundlage zur Definition der operationale Semantik der Workflowsprache DMWM legen.
In Abbildung 3.3 sind nun die Zustandsdiagramme der verschiedenen Aktivitätsklassen aus dem Metamodell
von Abbildung 3.2 zu sehen. Es gibt zwei verschiedene Arten von Aktivitätsklassen im Workflowmetamodell,
die für den Nutzer eine grundlegend unterschiedliches Verhalten haben. Das Verhalten der Aktivitäten vom
Typ Activity, Decision (inklusive Unterklassen), MultiInstance (inklusive Unterklassen) und Cancel wird
mit dem Zustandsautomaten von Abbildung 3.3(a) ausgedrückt. Ein anderes Verhalten haben Objekte der
Klasse Iteration, das durch das Zustandsdiagramm von Abbildung 3.3(b) spezifiziert wird.
In den Zustandsdiagrammen ist ersichtlich, dass die Übergänge auf Operationsaufrufen basieren, die in
(a) Lebenszyklus eines Aktivitätsobjekts
(b) Lebenszyklus eines Iterationsaktivitätsobjekts
Abbildung 3.3: Lebenszyklen von Aktivitätsobjekten modelliert in UML-Zustantsautomaten