Metamodellbasierte und hierarchieorientierte ... - RosDok

3.2 Workflow-Metamodell 39
hungen anhand von OCL definiert, die von Workflow Patterns nicht abgedeckt sind, aber Bestandteile des
Metamodells und damit der neuen Sprache sind. Eine detaillierte Analyse der Elemente, die die Workflow
Patterns abdecken wird in Abschnitt 3.2.4 folgen.
3.2.3.1 Angabe der Objektlebenszyklen mit OCL
Die Lebenszyklen von Aktivitätsobjekten sind mit Hilfe von UML-Zustandsautomaten in Abbildung 3.3
spezifiziert. Die Transitionen werden durch Operationsaufrufe repräsentiert. Diese Art der Spezifikation
von Objektlebenszyklen ist in der UML Spezifikation [UML10, Kap. 15.1] mit Protocol State Machines
bezeichnet.
Die State Charts können über OCL Vor- und Nachbedingungen ausgedrückt werden. Der Zustand des
Objekts ist durch das Attribut state im Zusammenhang mit der Enumeration State im Klassendiagramm
angegeben. In Listing 3.3 ist anhand der angegebenen OCL Vor- und Nachbedingung die Transition mit
dem Operationsaufruf start() aus Abbildung 3.3(a) angegeben. Die Vorbedingung isActivityWaiting gibt an,
dass der Zustand des Aktivitätobjekts waiting sein muss. Die Nachbedingung isActivityRunning spezifiziert
die Zustandsänderung auf Zustand running. Zusätzlich ist in Listing 3.3 noch die OCL-Spezifikation für die
Operation finish() angegeben. Analog werden die weiteren Transitionen für die Operationsaufrufe skip(),
fail() und cancel() von Abbildung 3.3(a) mit Hilfe von OCL gebildet. Diese werden hier jedoch nicht weiter
angegebenen.
✞
1 context Activity::start()
2 pre isActivityWaiting: state=#waiting
3 post isActivityRunning: state=#running
4
5 context Activity::finish()
6 pre isActivityRunning: state=#running
7 post isActivityDone: state=#done
8
9 context IterationGroup::nextIteration()
10 pre isDoneSkippedOrCanceled: self.activity−>forAll(state=#done or state=#skipped or state=#canceled)
11 post isIGWaiting: self.activity−>forAll(state=#waiting)
✝
Listing 3.3: OCL-Vor- und Nachbedingungen für Transitionen im Zustandsdiagramm der Klasse Activity
☎
✆
In Listing 3.3 ist noch die Spezifikation für die Operation nextIteration() spezifiziert. Diese Operation ist wie
im Abschnitt 3.2.1 erwähnt der Klasse IterationGroup zugeordnet. Entsprechend der Zustandsdiagramme
von Abbildung 3.3 besagt die Vorbedingung, dass alle zur Gruppe gehörende Aktivitäten im Zustand
done, skipped oder canceled sein müssen. Die Nachbedingung besagt, dass die Aktivitäten auf waiting
zurückzusetzen sind.
Im Gegensatz zum Automaten von normalen Aktivitäten in Abbildung 3.3(a) haben Iterationsaktivitäten den
Objektlebenszyklus von Abbildung 3.3(b). Vergleicht man die Automaten, können die Vor- und Nachbedingungen
für die start()-Operation für die Iteration Klasse gleich bleiben. Die Vor- und Nachbedingungen
werden vererbt, so dass für diese Operation keine neuen Bedingungen angegeben werden müssen. Für die
Operation finish() sieht es da anders aus. Setzt man den Automaten in OCL-Vor- und Nachbedingungen um,
ergibt sich eine Spezifikation von Listing 3.4.
Schließlich sei hier noch das Design by contract Prinzip [Mey92] im Zusammenhang mit dem Substitutionsprinzip
[LW94] erwähnt. Dieses besagt, dass Objekte der Unterklassen Objekte der Oberklassen
ersetzen können und dieses auch für Verhaltenspezifikation gelten soll. Objekte der Unterklassen sollen