Metamodellbasierte und hierarchieorientierte ... - RosDok

46 Deklarative UML metamodellbasierte Workflowmodellierung
(a) WCP12: Multiple Instances without Synchronization
(b) WCP13: Multiple Instances with a Priori Design-Time
Knowledge
(c) WCP14: Multiple Instances with a Priori Run-Time Knowledge
(d) WCP15: Multiple Instances without a Priori Run-Time
Knowledge
Abbildung 3.6: Multiple Instance Patterns
verwendet. Die operationale Semantik der Klasse ist wiefolgt: Zur Runtime müssen alle über die Assoziation
instance verbundenen Ausführungsinstanzen im Zusand waiting sein, damit die übergeordnete MultiInstance-
Aktivität ebenfalls in den Zustand waiting versetzt werden kann. Damit kann die Folgeaktivität a2 erst dann
ausgeführt werden, wenn alle Instanzen von mi abgearbeitet, d.h. synchronisiert sind. Im Gegensatz zu
WCP12 müssen die einzelnen Ausführungsinstanzen in WCP13 nicht synchronisiert werden. Somit kann in
Abbildung 3.6(b) die Aktivität mi in den Ausführungszustand done versetzt werden, auch wenn noch einzelne
Ausführungsinstanzen ausgeführt werden. Folglich darf die Folgeaktivität a2 ohne Synchronisierung der
Ausführungsinstanzen gestartet werden.
Die Klasse MIRuntime aus Abbildung 3.2 repräsentiert WCP14. Bei diesem Pattern wird erst zur Runtime
beim Starten der Aktivität die Anzahl der zu erzeugenden Instanzen festgelegt. Hierfür wird die Operation
enterNoOfInst() aus dem Metamodell genutzt. Die einzelnen Ausführungsinstanzen werden analog zum
Verhalten von WCP12 synchronisiert. In Abbildung 3.6(c) ist somit die Aktivität a2 erst dann zu starten,
wenn alle Instanzen von mi beendet wurden.
Das letzte Multiinstanz-Pattern ist in Abbildung 3.6(d) mit der Klasse MIRuntimeWithAdd angewendet
worden. Das Verhalten der Objekte dieser Klasse ist analog zum WCP14, wird jedoch um die Operation
addInstance() erweitert. Dem Nutzer steht über diese Operation die Möglichkeit offen, neue Ausführungsinstanzen
während der Ausführung hinzuzufügen. Erst nachdem die Multiinstanz-Aktivität beendet wurde,
können auch keine weiteren Instanzen erzeugt werden.
Die oben beschriebene Ausführungssemantiken der verschiedenen MultiInstance-Patterns sind anhand der
unterschiedlichen OCL-Invarianten im Metamodell spezifiziert. Diese Invarianten werden hier jedoch nicht
weiter angegeben.
3.2.4.4 State-based Patterns
Abbildung 3.7 zeigt die drei Patterns, die zu den State-based Patterns gehören. Das Deferred Choice-Pattern
kann sehr einfach modelliert werden (s. Abbildung 3.7(a)). Die OCL-Invariante allWaitingXorOneRunningOthersSkipped
zur Definition der Semantik ist in Listing 3.8 spezifiziert. Sie besagt, dass zum einen alle
Aktivitäten aus der DeferredChoice-Gruppe im Zustand waiting sein dürfen. Wenn sich zum anderen eine
Aktivität im Zustand running befindet, müssen alle anderen im Zustand skipped überführt worden sein.
Das nächste Pattern ist Interleaved Parallel Routing, welches in Abbbildung 3.7(b) modelliert wurde. Es ist
ähnlich einfach zu modellieren wie der vorher betrachtete Deferred Choice. Der Unterschied liegt darin,
dass mit InterleavedParallelRouting ein anderes Gruppenobjekt verwendet wurde, in dem eine andere
OCL-Invariante gilt. Damit gilt eine andere Semantik, die mit der Invariante atMostOneRunning in Listing
3.8 spezifiziert wurde. Sie besagt, dass höchstens eine Aktivität der Gruppe zur gleichen Zeit ausgeführt