Metamodellbasierte und hierarchieorientierte ... - RosDok

44 Deklarative UML metamodellbasierte Workflowmodellierung
✞
1 context Activity inv seqActivity:
2 let activities:Set(Activity) = pred.oclAsType(Activity)−>select(a|a.isDefined)−>asSet in
3 let ops:Set(Group) = pred.oclAsType(Group)−>select(o | o.isDefined)−>asSet in
4 (self.state = #running or self.state = #done) implies
5 activities−>union(ops.activity)−>forAll(a | a.state=#done or a.state=#skipped)
6
7 context XorDecision inv doneSelectedXor:
8 self.state=#done implies self.guard[decision]−>select(g|g.selected)−>size = 1
✝
Listing 3.7: Definition der Sequenz (WCP1) und Exclusive Choice (WCP4)
☎
✆
Objekt and2 das Synchonization Pattern ausgedrückt.
Die deklarative OCL-Invariante zur Klasse AndOperator besagt, dass alle Aktivitätsobjekte bzw. Gruppen
von Aktivitäten, die mit pred verbunden sind, abgearbeitet sein müssen, bevor die succ-Aktivitäten starten
können. Die OCL-Invariante wird hier nicht explizit angegeben. Zu dieser Invariante ist zu sagen, dass
FlowOperator-Objekte nicht über die seq-Beziehung verbunden sein dürfen. Diese Eigenschaft ist als
Soundness-Eigenschaft in einer OCL-Invariante festgelegt, analog zu denen, die in Abschnitt 3.2.6 näher
vorgestellt werden.
Die Workflow Patterns 4&5 werden in Abbildung 3.4(c) näher betrachtet. Für den choice-Operator (WCP4)
wird eine XorDecision-Entscheidungsaktivität gewählt. Während der Ausführung dieser Aktivität muss
der Nutzer genau einen Pfad auswählen, der danach auszuführen ist. Die Auswahl findet über die select()-Operation
der zugehörigen Guard-Objekte (s. Abbildung 3.2) zur Runtime statt. Dass genau ein
Pfad auszuwählen ist, wird in der OCL-Invariante doneSelectedXor in Listing 3.7 spezifiziert. Die nicht
ausgewählten Aktivitäten werden geskippt. Dieses Verhalten betrifft jedoch die imperative Spezifikation der
Prozessausführung, welche in Kapitel 4 näher betrachtet wird.
Der merge-Operator (WCP5) wird mit dem MergeOperator-Objekt in Abbildung 3.4(c) ausgedrückt. Die
Prozesspfade werden dort zusammengeführt. Die zugeordnete OCL-Invariante besagt, dass eine Aktivität
im Zustand done sein muss, damit die Folgeaktivitäten gestartet werden können.
3.2.4.2 Advanced Branching and Synchronization Patterns
In diesem Abschnitt werden mit Abbildung 3.5 weitergehende temporale Beziehungen behandelt, die etwas
kompliziertere Verzweigungs- und Synchronisierungsbeziehungen darstellen.
Ein prominentes Beispiel ist mit dem Multichoice und dem Structured Synchronizing Merge (WCP6&7) in
Abbildung 3.5(a) ausgedrückt. Diese Patterns wurden bereits von EPKs mit OR-Konnektoren verwendet. Es
kann vom Nutzer mit der OrDecision-Aktivität mehr als nur eine Folgeaktivitätskette ausgewählt werden.
Die nicht ausgewählten Aktivitätsketten werden bis zum zugehörigen MergeOperator geskippt. WCP7
besagt mit structured-Bezeichnung, dass zu jeder Entscheidung ein zugehöriger Merge vorhanden sein
muss. Analog zur Invariante doneSelectedXor aus Listing 3.7 besagt die Invariante für OrDecision, dass
mindestens eine Aktivität nach Beendigung der Aktivität ausgewählt sein muss.
In Abbildung 3.5(b) ist dann das MultiMerge-Pattern (WCP8) modelliert. Dieses besagt, dass die Anzahl
der vorher ausgeführten pred-Aktivitäten, die Iterationszyklen der in der Gruppe enthaltenen Aktivitäten
bestimmt. Sind also Aktivität a1 und a3 ausgeführt worden, müssen genau zwei Iterationszyklen beim
Multimerge-Objekt m1 durchgeführt werden. Somit müssten die Aktivitäten a4 und a5 zweimal ausgeführt
werden.
Das Structured Discriminator Pattern (WCP9) wird im DMWM-Metamodell mit der Klasse Discriminator