Metamodellbasierte und hierarchieorientierte ... - RosDok

98 Hierarchieorientierte Workflowmodellierung
entschieden werden, ob Aufgabe B oder C auszuführen ist. Diese Entscheidung muss bei CTT implizit
vom Nutzer getroffen werden und basiert nicht auf Daten, wie z.B. bei BPMN (vgl. Abschnitt 2.5.2.3). Für
eine explizite Entscheidungsmodellierung fehlt die Angabe der Entscheidungstätigkeit und die Kriterien
zur Pfadauswahl, wie es z.B. bei EPKs gefordert wird (vgl. Abschnitt 2.5.2.1). Somit ist die Entscheidung,
welche Aktivität auszuführen ist, implizit zu fällen. Bei den Workflow Patterns wird diese Art als Deferred
Choice bezeichnet [AHKB03] und repräsentiert im Vergleich zur expliziten Entscheidungsmodellierung
eher die Ausnahme bei Workflowmodellen. Eine Diskussion, wie eine explizite Entscheidungsmodellierung
für Aufgabenmodelle erfolgen kann, wird in Abschnitt 5.4 gegeben.
Der zweite betrachtete Operator in der Tabelle 5.2 ist der Concurrency-Operator ( ||| ). Für die Transformation
wird für das Aktivitätsdiagramm ein fork- und join-Operator strukturiert eingesetzt. Die Aufgaben B und C
stehen zwischen diesen beiden Operatoren und können somit unabhängig voneinander ausgeführt werden.
Der Disabling-Operator ( [> ) wird daraufhin betrachtet. Bei dem zugehörigen Aktivitätsdiagramm ist eine
Eigenheit von CTT zu sehen, die diesen Operator angeht und von der LOTOS-Semantik abweicht. Die
Aufgabe C muss bei CTT in jedem Falle ausgeführt werden, auch wenn B schon beendet wurde. In diesem
Falle endet der Kontrollfluss beim Aktivitätsdiagramm im Objektknoten B [finished] und die Exeception
Region bleibt weiterhin aktiv. Es wird somit in jedem Fall auf das Signal zur Abarbeitung der Aktivität C
gewartet. Bei LOTOS ist C dagegen nicht weiter ausführbar, wenn B schon beendet wurde. Die operationale
Semantik ist dort präziser an der eigentlichen Bezeichung des Operators, die aussagt, dass die nachfolgende
Aufgabe die Vorgängeraufgabe deaktiviert. Bereits beendete Aufgaben können eigentlich nicht deaktiviert
werden.
OrderIndependency ( |=| ) wird in Tabelle 5.2 im Aktivitätsdiagramm so umgesetzt, dass hinter dem Choice-
Operator die möglichen Ablaufsequenzen der beteiligten Aktivitäten spezifiziert sind. Beim Choice-Operator
wird dann entschieden, welche Aktivität als erstes auszuführen ist. Die übrig gebliebene bleibt danach
auszuführen.
Der Enabling-Operator ( » ) wird als letztes in der Tabelle 5.2 transformiert. Die sequenzielle Abfolge von
Aufgabe A und B wird beim Aktivitätsdiagramm durch eine simple Kontrollflusskante ausgedrückt, die die
Abarbeitungsreihenfolge spezifiziert.
Aus Tabelle 5.1 sind des Weiteren noch die Operatoren Concurrency with Information Exchange und
Enabling with Information Passing vorhanden. Wie dort in der operationalen Semantik-Spalte angegeben,
unterscheidet sich die Ablaufsemantik dieser Operatoren nicht von Concurrency bzw. Enabling. CTT gibt
mit diesen Operatoren lediglich an, dass Informationen zwischen den Geschwisterknoten ausgetauscht
werden. Eine genauere Angabe der Daten und deren Inhalt ist in CTT nicht möglich. Aktivitätsdiagramme
verlangen bei der Datenintegration mit Objektflüssen eine Typangabe der Objekte, die zwischen Aktivitäten
ausgetauscht werden (s. Abschnitt 3.3.1). Da die Konzepte hier nicht zueinander passen, werden für diese
spezifischen Operatoren keine Transformation vorgestellt.
Der einzige temporale CTT-Operator, dessen Kontrollflusssemantik nicht in einem Aktivitätsdiagramm
dargestellt werden kann ist Suspend-resume. Für dessen Umsetzung im Aktivitätsdiagramm wäre ein
History-Zustand, analog zu dem, der bei UML-Zustandsdiagrammen vorhanden ist [UML10, Kap.15],
notwendig. Das Merken des Ausführungszustandes der unterbrochenen Aufgabe ist notwendig, um zu
diesem zurückzukehren, wenn die unterbrechende Tätigkeit beendet wurde. Da der History-Zustand aber für
Aktivitätsdiagramme nicht verfügbar ist, kann die Transformation ohne Erweiterung der Sprachmittel der
Aktivitätsdiagramme nicht ausgedrückt werden und bleibt offen.