Metamodellbasierte und hierarchieorientierte ... - RosDok
Metamodellbasierte und hierarchieorientierte ... - RosDok
Metamodellbasierte und hierarchieorientierte ... - RosDok
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
104 Hierarchieorientierte Workflowmodellierung<br />
2.6 starke Ähnlichkeiten zum MCTT-Metamodell. Die Dekomposition der Funktionen bzw. Aufgaben,<br />
die bei den EPKs bzw. in ARIS synonym bezeichnet werden [KNS92], wird im ARIS-Metamodell mit<br />
der Assoziationsklasse FUNKTIONSSTRUKTUR bezeichnet. Die sequenzielle Ablaufspezifikation wird<br />
mit der Assoziationsklasse ANORDNUNG angegeben, wofür bei MCTT Enabling verwendet wird. Beim<br />
MCTT-Metamodell gibt es zusätzlich noch fünf weitere von der Ablaufsemantik unterschiedliche temporale<br />
Beziehung, die bereits erklärt wurden.<br />
(a) Lebenszyklus eines LeafTask-Objekts<br />
(b) Lebenszyklus eines LeafTask-Objekts als Iteration<br />
Abbildung 5.5: Lebenszyklen von Aufgabenobjekten modelliert in UML-Zustantsautomaten<br />
Die in Abbildung 5.5 vorgestellten Zustandsdiagramme unterscheiden sich von denen des DMWM-Ansatzes<br />
(s. Abbildung 3.3), indem ein zusätzlicher Zustand suspended eingeführt <strong>und</strong> die Transition mit nextIteration()<br />
zum Rücksetzen der Aktivitätszustände weggelassen wurde. Der neue Zustand suspended ist notwendig,<br />
um den temporalen CTT-Operator SuspendResume umzusetzen. In Abbildung 5.5(a) ist der Lebenszyklus<br />
eines normalen LeafTask-Objekts angegeben. Dieser Lebenszyklus gilt, wenn das Aufgabenobjekt selber<br />
<strong>und</strong> keines seiner Oberaufgaben eine Iterationsmarkierung hat. Sollte hingegen bei der Blattaufgabe oder<br />
einer ihrer Oberaufgaben das Attribut tempOp mit ITER belegt sein, gilt der Lebenszyklus von Abbildung<br />
5.5(b).<br />
Analog zu dem DMWM-Ansatz (s. Abschnitt 3.2.1) werden OCL-Vor- bzw. Nachbedingungen an den<br />
Operationen in der Klasse LeafTask verwendet, um die Zustandsautomaten umzusetzen. Im Zusammenhang<br />
mit diesen Bedingungen muss geprüft werden, ob die akutelle Aufgabe oder eine ihrer Oberaufgaben eine<br />
Iteration oder eine normale Aufgabe ist. Bei einer normalen Aufgabe ist entsprechend der Zustandsautomat<br />
von Abbildung 5.5(a) umzusetzen <strong>und</strong> im anderen Fall der von Abbildung 5.5(b).<br />
5.3.3 OCL-Invarianten zum Prüfen von strukturellen Eigenschaften<br />
Für eine Anwendung der CTT-Aufgabenmodelle in der Workflowmodellierung ist es notwendig, eine<br />
verlässliche Prüfung der Konsistenzeigenschaften der Modelle zur Designtime zu haben. Hier bieten die<br />
etablierten Sprachen wie Petri-Netze <strong>und</strong> Tools dafür So<strong>und</strong>ness-Prüfungen an, wohingegen Aufgabenmodelle<br />
noch Schwächen aufweisen, wie in Abschnitt 5.3.1 vorgestellt. Um entsprechende Prüfungen auch für<br />
Aufgabenmodelle bereitzustellen, werden in diesem Abschnitt OCL-Konsistenzbedingungen definiert, die<br />
im Metamodell hinterlegt <strong>und</strong> bereits während des Modellierens zur Designtime vom UML-Tool geprüft<br />
werden. Auf Verletzungen wird der Modellierer unmittelbar hingewiesen.<br />
Zunächst kann die baumartige Modellierung anhand von OCL-Invarianten sichergestellt werden. Alle<br />
Nachbarn im Aufgabenbaum müssen zudem über binäre temporale Beziehungen verb<strong>und</strong>en sein. Diese<br />
gr<strong>und</strong>legende Eigenschaft für CTT-Aufgabenbäume wird in den ersten zwei OCL-Invarianten von Listing<br />
5.1 festgelegt.<br />
Invariante taskStructure ist der Assoziationsklasse TempOp zugeordnet <strong>und</strong> prüft die Nachbarschaft der mit<br />
temporalen Operatoren verb<strong>und</strong>enen Aufgaben. Dieses wird sichergestellt, indem der Vaterknoten der linken<br />
mit dem der rechten Aufgabe auf Gleichheit überprüft wird. Die Invariante startTaskAndEndTaskExists
Change language