Metamodellbasierte und hierarchieorientierte ... - RosDok

6.2 Modellausführung von MCTT-Aufgabenmodellen 119
Boolean-Variablen suspended und startable deklariert. Mit Hilfe dieser und den Operationen isSuspendedByOrderIndependency(),
isSuspendedBySuspendResume() und isSuspendedByEnabling() wird in den
Zeilen 5-14 geprüft, ob die Aufgabe durch entsprechende temporale Operatoren ausgesetzt wurde oder
gestartet werden kann. Die Aufgabe wird gestartet, indem deren Zustand auf running gesetzt wird (s. Zeile
16). Darauf folgend werden in den Zeilen 17-22 Seiteneffekte auf verbundene Aufgaben durchgeführt,
die auf Basis der entsprechenden temporalen Operatoren geschehen müssen. Zunächst werden die skip()-
Operationen aufgerufen, die bei optionalen oder mit Choices verbundenen Aufgaben auftreten können. Des
Weiteren können mit dem Starten der Aufgabe andere übersprungen oder ausgesetzt werden, wenn diese
mit dem Disabling bzw. SuspendResume-Operator verbunden sind. Dieses passiert mit den disableTasks()
und suspendTasks()-Operationsaufrufen in Zeile 20 und 21. Als letztes wird in Zeile 22 die setStartStamp()
Operation aufgerufen, welche das start-Attribut der Klasse LeafTask auf den entsprechenden Zeitpunkt setzt
(s. Abbildung 5.4).
Im Gegensatz zum hier vorgestellten SOIL-Code wurde wie bereits erwähnt beim DMWM-Ansatz der
imperative Teil mit ASSL umgesetzt. Das DMWM-Metamodell und der ASSL-Code lag in unterschiedlichen
Dateien vor. Mit der Verwendung von SOIL hat sich diese Verwendung bei MCTT geändert, da die
imperativen Operationen nun direkt im Metamodell integriert sind. Da die Bedignungen und der imperative
Code nun in einer Datei vorliegen, sind in Listing 6.1 die Vor- und Nachbedingungen in den Zeilen 25
und 26 mit spezifiziert. Mit diesen Bedingungen wurde die start()-Transition der Zustandsautomaten von
Abbildung 5.5 umgesetzt.
Ein weiterer Unterschied von der ASSL zur SOIL-Verwendung liegt darin, dass bei den ASSL-Prozeduren,
wie in Listing 4.1 angegeben die entsprechende Aufgabe als Parameter übergeben werden musste. Diese ist
bei SOIL nicht mehr notwendig, da die Operation auf einem entsprechenden LeafTask-Objekt ausgeführt
wird. Die Syntax von SOIL liegt damit näher an einer objektorientierten Programmiersprache als dieses
noch bei ASSL der Fall war.
6.2.2 Taskmodel-Plugin für USE
In diesem Abschnitt wird die Ausführung des Aufgabenmodells von Abbildung 5.11 im MCTT-Workflow-
Plugin thematisiert. Die Aufgabenmodelldarstellung, die Interaktionsschnittstelle für den Nutzer und die
Darstellung der Datensicht wird in Abbildung 6.2 präsentiert.
Die Darstellung des Workflows ist ganz ähnlich zum DMWM-Plugin. Das Workflowmodell ist ebenfalls
in einem Baum gezeigt und die Ausführungszustände der Aufgaben werden farblich gekennzeichnet. Die
Farbzuordnungen sind die gleichen wie bei DMWM, die in Tabelle 4.3 vorgestellt wurden. Jedoch ist
mit suspended ein zusätzlicher Ausführungszustand bei MCTT hinzugekommen, für den die Farbe Türkis
verwendet wurde. Die Buttons zur Nutzerinteraktion sind mit start, finish, skip und fail die gleichen wie
beim DMWM-Plugin geblieben.
In Abbildung 6.2(a) ist die Aufgabe CheckPatientCondition gestartet und ausgewählt. Damit werden die
entsprechenden Datensichten für diese Aufgabe angezeigt. Das Workflowmodell von Abbildung 5.11 zeigt,
dass die Aufgabe mit PatientData als Entscheidungsobjekt verbunden ist. Somit wird über die Eingabe
von Daten über den weiteren Verlauf des Workflows entschieden. Hier wurde dem Attribute urgency der
Wert 6 zugeordnet. Mit der Spezifikation des Datachoice1-Objekts aus Abbildung 5.11 ist ersichtlich, dass
damit die Aufgabe HandleCriticalPatient zur Ausführung ausgewählt werden müsste. Nach Beendigung der
Aufgabe CheckPatientCondition ist in Abbildung 6.2(b) ersichtlich, dass die Aufgabe HandleStablePatient
übersprungen wurde. Dafür muss dann also HandleCriticalPatient ausgeführt werden.
Die Aufgabe ist jedoch in Abbildung 6.2(b) nicht enabled, da zwischenzeitlich die Aufgabe AdjustMedi-