Metamodellbasierte und hierarchieorientierte ... - RosDok

40 Deklarative UML metamodellbasierte Workflowmodellierung
✞
1 context Iteration::finish()
2 pre isIterRunning: state=#waiting or state=#running
3 post isIterDone: state@pre=#waiting implies state=#done
4 post isIterWaiting: state@pre=#running implies state=#waiting
✝
Listing 3.4: OCL-Vor- und Nachbedingungen für die Operation finish() der Klasse Iteration
☎
✆
also das Verhalten der Oberklasse haben und evtl. zusätzliche Funktionalität hinzufügen. Das hat zur Folge,
dass Vorbedingungen von gleichen Operationen nur gleich bleiben oder abgeschwächt werden können.
Nachbedingungen können nur gleich bleiben oder verschärft werden.
Bei der Programmiersprache Eiffel werden zur Umsetzung für Operationen, die in Unterklassen überschrieben
werden folgende Klauseln verwendet. Vorbedingungen können mit require else nur
abgeschwächt werden. D.h. die Vorbedingungen der Oberklasse und die Vorbedingungen der Unterklasse
werden mit einem or logisch verknüpft. Nachbedingungen können mit ensure then nur
verschärft werden. Dort werden die Nachbedingungen der Oberklasse mit der Unterklasse mit dem logischen
and verknüpft.
In der OCL-Spezifikation werden zwar contracts in Verbindung mit Vor- und Nachbedingungen erwähnt
[OCL10], aber das Substitutionsprinzip, das eine Abschwächung der Vorbedingung und Verschärfung
der Nachbedingung erfordert wird nicht vorgegeben. Das Verhalten ohne Substitutionsprinzip ist für das
DMWM-Metamodell das gewünschte.
Sollte bei der Implementierung des DMWM-Ansatzes das Design by contract inkl. Substitutionsprinzip
gelten, müssten die bisher vorgestellten Vor- und Nachbedingungen angepasst werden. Ein Problem würde
ansonsten bei der Nachbedingung von finish() auftreten. Ein Objekt, das sich im Zustand running befindet,
wird durch die Verknüpfung der Zeile 7 in Listing 3.3 und Zeile 4 in Listing 3.4 mit dem logischen and
Operator die Nachbedingung state=#done and state=#waiting erhalten. Diese würde offensichtlich ein
Widerspruch enthalten.
3.2.3.2 OCL-Hilfsfunktionen im Metamodell
In UML lassen sich Operationen im Klassendiagramm mit OCL-Termen verknüpfen, wovon u.a. in der
UML-Spezifikation gebrauch gemacht wird [UML10]. Die Operationen haben nach dem Prinzip von OCL
keine Seiteneffekte auf das Objektmodell.
Mit dieser Eigenschaft ist die Möglichkeit zur Berechnung der transitiven Hülle bei reflexiven Assoziationen
gegeben. Ein Beispiel ist dafür in [KHGB] spezifiziert. Auch für DMWM werden verschiedene transitive
Hüllen unter Verwendung der OCL berechnet.
Die Operation getSuccObjects() in Listing 3.5 ist u.a. für die Soundness-Prüfung der Prozessmodelle
notwendig, um potenzielle Deadlocks schon während der Designtime zu finden. Dieses Thema wird in
Abschnitt 3.2.6 näher behandelt. Die dort eingeführten OCL-Invarianten benötigen diese Operationen.
Die Operation getFlowObjects() in Listing 3.5 wird u.a. für das Einsammeln der Modellierungselemente
im Prozessmodell benötigt. Wie in Abschnitt 3.2.1 beschrieben, müssen somit nicht alle Elemente im
Prozessmodell mit dem entsprechenden Prozessobjekt über die Assoziation includes verbunden werden. Sie
können indirekt über die Berechnung der transitiven Hülle dem Prozessobjekt zugeordnet werden.
Im DMWM-Metamodell, dem Klassendiagramm von Abbildung 3.2, sind die hier vorgestellten Funktionen
aus Übersichtlichkeitsgründen weggelassen worden. Dort sind nur die Operationen aufgeführt, die eine
Schnittstelle zum Nutzer darstellen.