Metamodellbasierte und hierarchieorientierte ... - RosDok

3.2 Workflow-Metamodell 49
Abbildung 3.9: Ein DMWM-Workflowmodell für einen Krankenhaus-Notfallprozess als Objektdiagramm
der Nutzer basierend auf der Guard-Spezifikation den adäquaten Prozesspfad auswählen muss. Mit den
Guards critical und stable wird angegeben, in welchem Zustand sich der Patient befindet. Wählt der Nutzer
critical aus, so befindet sich der Patient in einem kritischen Zustand und es hat mit EmergencySurgery
eine Notoperation zu erfolgen. Bei einem stabilen (stable) Zustand hat mit der Aktivität NormalSurgery
eine normale Operation zu erfolgen. Bei den Operations-Aktivitäten wurden jeweils Assistenz-Aktivitäten
mit der in Abschnitt 3.2.3.3 erwähnten Parallel-Beziehung modelliert. Somit haben diese Aktivitäten
gezwungenermaßen parallel zu erfolgen. Als letzte Aktivität ist dann noch WakeUp im Prozessmodell
vorhanden, die durch die seq-Beziehung nach allen Aktivitäten der SurgeryCheck-Gruppe zu erfolgen hat.
Die Zustände und Attributbelegungen der Aktivitätsobjekte spielen für die in diesem Abschnitt betrachtete
Modellierungsphase noch keine Rolle und können hier vernachlässigt werden. Diese werden erst für
die Runtime relevant, die in Kapitel 4 im Zusammenhang mit dem Workflow-Runtime-Plugin betrachtet
wird. Auch das Designtime-Plugin, das aus den Workflowmodellen ASSL-Instanziierungsprozeduren zur
persistenten Speicherung und deren Folgenutzung zur Runtime generiert, wird dort näher erklärt.
3.2.6 Sicherstellung statischer Eigenschaften der Modelle
In diesem Kapitel wurden bisher nur OCL-Constraints vorgestellt, die die operationale Semantik der DM-
WM-Sprache betreffen. Ein wichtiger zusätzlicher Aspekt von DMWM ist die Soundness-Überprüfung
während der Designtime mit OCL. Im Metamodell sind OCL-Invarianten spezifiziert, die potenzielle
Deadlocks, die zur Runtime entstehen können, schon während der Designtime identifizieren.
In Listing 3.9 werden zwei Invarianten vorgestellt, die Deadlocks identifizieren. Deadlocks sind dann
gegeben, wenn die auf OCL-Contraints basierenden temporale Beziehungen sich widersprechen und damit
die Prozessausführung blockieren würden.
Ein solches Problem tritt z.B. dann auf, wenn der Modellierer einen Zyklus von Sequenzen bildet, welches
in Abbildung 3.10 angegeben ist. Während der Runtime würde dann folgendes Problem auftauchen. Die
OCL-Invariante seqActivity von Listing 3.7 fordert, dass die pred-Aktivitäten abgearbeitet sein müssen
bevor die mit self angegebene, aktuell betrachtete Aktivität gestartet werden kann. Diese Zusicherung