Metamodellbasierte und hierarchieorientierte ... - RosDok

Weitere Magazine

Empfehlungen

Info

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-
120 Workflow-Ausführung und -Management mit Aufgabenmodellen (a) Ausführung der Aufgabe CheckPatientCondition (b) Ausführung der Aufgabe AdjustMedication Abbildung 6.2: MCTT-Modelle zur Runtime dargestellt im MCTT-Plugin cation gestartet wurde. Mit diesem Aufruf wurden die davor gelegenen Aufgaben durch den temporalen Operator SuspendResume unterbrochen. Nachdem diese Aufgabe wieder beendet wird, sind die Aufgaben EmergencySurgery und AssistEmergencySurgery wieder startbar. Zusätzlich zum PatientData Objekt ist in Abbildung 6.2(a) ersichtlich, dass ein weiteres DataRead-Fenster geöffnet ist. Dieses wird durch die Interpretation des DataRead-Objekts getAllDeseases geöffnet. Damit
Seite 1 und 2:
Metamodellbasierte und hierarchieor
Seite 3 und 4:
Zusammenfassung In dieser Arbeit we
Seite 5:
Danksagung Ich möchte mich als ers
Seite 8 und 9:
3.2.6 Sicherstellung statischer Eig
Seite 10 und 11:
Kapitel 1 Einleitung Geschäftsproz
Seite 12 und 13:
1.2 Eigenschaften und Vorteile der
Seite 14 und 15:
1.2 Eigenschaften und Vorteile der
Seite 16 und 17:
1.3 Aufbau der Arbeit und Hinweise
Seite 18 und 19:
Kapitel 2 Grundlagen: Modellierung
Seite 20 und 21:
2.2 Daten- und Metamodellierung 11
Seite 22 und 23:
2.3 Modellierung in der HCI mit nut
Seite 24 und 25:
2.5 Geschäftsprozessmodellierung 1
Seite 26 und 27:
Seite 28 und 29:
Seite 30 und 31:
Seite 32 und 33:
Seite 34 und 35:
Seite 36 und 37:
Seite 38 und 39:
Kapitel 3 Deklarative UML metamodel
Seite 40 und 41:
3.1 Einführung 31 • Paketdiagram
Seite 42 und 43:
3.1 Einführung 33 Im folgenden wer
Seite 44 und 45:
3.2 Workflow-Metamodell 35 der BPMN
Seite 46 und 47:
3.2 Workflow-Metamodell 37 hinterle
Seite 48 und 49:
3.2 Workflow-Metamodell 39 hungen a
Seite 50 und 51:
3.2 Workflow-Metamodell 41 ✞ ☎
Seite 52 und 53:
3.2 Workflow-Metamodell 43 Workflow
Seite 54 und 55:
3.2 Workflow-Metamodell 45 (a) WCP6
Seite 56 und 57:
3.2 Workflow-Metamodell 47 (a) WCP1
Seite 58 und 59:
3.2 Workflow-Metamodell 49 Abbildun
Seite 60 und 61:
3.3 Datenintegration 51 beiden Bezi
Seite 62 und 63:
3.3 Datenintegration 53 Bei UML-Akt
Seite 64 und 65:
3.3 Datenintegration 55 Die OCL-Anf
Seite 66 und 67:
3.4 Organisationsmodellierung bei D
Seite 68 und 69:
3.4 Organisationsmodellierung bei D
Seite 70 und 71:
3.5 Realisieren von DMWM mit USE 61
Seite 72 und 73:
Seite 74 und 75:
Seite 76 und 77:
Kapitel 4 Metamodellbasierte Workfl
Seite 78 und 79: 4.2 Instanziierung und Grundlagen z
Seite 86 und 87: 4.3 Workflow Runtime-Plugin 77 (a)
Seite 88 und 89: 4.3 Workflow Runtime-Plugin 79 Ents
Seite 94 und 95: 4.4 Analyse ausgeführter Prozesse
Seite 96 und 97: 4.5 Verwandte Arbeiten 87 ✞ 1 use
Seite 98 und 99: 4.5 Verwandte Arbeiten 89 Prozesse
Seite 100 und 101: Kapitel 5 Hierarchieorientierte Wor
Seite 102 und 103: 5.1 Einführung 93 der Aufgaben ein
Seite 104 und 105: 5.2 Transformation von CTT zu Aktiv
Seite 110 und 111: 5.3 Definition konsistenter CTT-Auf
Seite 118 und 119: 5.4 Entscheidungsmodellierung und D
Seite 124 und 125: Kapitel 6 Workflow-Ausführung und
Seite 126 und 127: 6.2 Modellausführung von MCTT-Aufg
Seite 130 und 131: 6.3 TTMS: A Task Tree Based Workflo
Seite 140 und 141: 6.4 Weitere Ansätze 131 verfolgten
Seite 142 und 143: Kapitel 7 Zusammenfassung und Ausbl
Seite 144 und 145: 7.1 Fazit 135 Das Metamodell gibt f
Seite 146 und 147: 7.3 Ausblick 137 7.3 Ausblick Einig
Seite 148 und 149: Tabellenverzeichnis 4.1 Die für DM
Seite 150 und 151: Abbildungsverzeichnis 2.1 Eine Kred
Seite 152 und 153: Listingsverzeichnis 3.1 OCL-Invaria
Seite 154 und 155: Literaturverzeichnis [Aal11] [AAM +
Seite 156 und 157: LITERATURVERZEICHNIS 147 [BCC07] BR
Seite 158 und 159: LITERATURVERZEICHNIS 149 [DeM79] [D
Seite 160 und 161: LITERATURVERZEICHNIS 151 [JABK08] [
Seite 162 und 163: LITERATURVERZEICHNIS 153 [MPS02] [M
Seite 164 und 165: LITERATURVERZEICHNIS 155 Process Ma
Seite 166 und 167: LITERATURVERZEICHNIS 157 [Wes07] WE
Seite 168: die zwei Action Languages ASSL und
Alle anzeigen

Metamodellbasierte und hierarchieorientierte ... - RosDok

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?