Metamodellbasierte und hierarchieorientierte ... - RosDok

5.3 Definition konsistenter CTT-Aufgabenmodelle 105
stellt des Weiteren sicher, dass genau eine Aufgabe mit keiner Vorgängeraufgabe verbunden und damit
Startknoten ist. Analog dazu muss ein Endknoten existieren. Alle weiteren Aufgaben müssen in einer Kette
über die Assoziationsklasse TempOp verbunden sein, da durch die Invariante die Multiplizitätsbedingung 1
sowohl für die Rolle prev als auch für die Rolle next gilt.
✞
1 context TempOp inv taskStructure:
2 prev.compTask = next.compTask
3
4 context CompTask inv startTaskAndEndTaskExist:
5 task−>select(prev.isUndefined())−>size()=1 and
6 task−>select(next.isUndefined())−>size()=1
7
8 context Disabling inv noDisablingWithOptionalTasks:
9 next.hasNonOptionalLeafTaskDisabling()
10
11 context Choice inv noChoiceWithOptionalTasks:
12 prev.hasNonOptionalLeafTaskChoicePredecessor() and next.hasNonOptionalLeafTaskChoiceSuccessor()
✝
Listing 5.1: OCL-Invarianten zur Festlegung der strukturellen Eigenschaften von Aufgabenbäumen
☎
✆
Zwei Invarianten, die die Konsistenzprobleme von Abbildung 5.3(a) und 5.3(b) identifizieren sollen, sind in
den zwei unteren Invarianten von Listing 5.1 angegeben. Beide verwenden Operationsaufrufe, die seiteneffektfreie
OCL-Abfragen repräsentieren. Der Operationsaufruf hasNonOptionalLeafTaskDisabling geht
vom Disabling-Operator zum nächsten Aufgabenobjekt und traversiert die Unteraufgaben abhängig von den
temporalen Operatoren und deren Bindungsstärke. Die relevanten Aufgaben dürfen keine Optionalitätseigenschaft
besitzen.
Für die zweite Invariante werden die OCL-Operationen hasNonOptionalLeafTaskChoicePredecessor und
hasNonOptionalLeafTaskChoiceSuccessor verwendet. Entsprechend der temporalen Beziehungen und deren
Bindungsstärke werden auch hier die Unteraufgaben in der Baumhierarchie traversiert. Die relevanten
Aufgaben werden auf die Optionalitätseigenschaft geprüft, die nicht gesetzt sein darf. Auf die genaue
Umsetzung der OCL-Abfrageoperationen wird hier nicht eingegangen.
Im folgenden wird das USE-Tool analog zu DMWM in Abschnitt 3.5.3 eingesetzt, um MCTT-Aufgabenmodelle
zu modellieren. Zwei inkonsistente MCTT-Aufgabenmodelle sind in Abbildung 5.3 angegeben.
Dort ist zu sehen, dass die Inkonsistenzen durch die OCL-Invariantenüberprüfung unmittelbar während der
Designtime angezeigt werden und der Modellierer darauf hingewiesen wird. Werkzeuge zum Identifizieren
der Ursachen der Inkonsistenzen bei DMWM-Modelle wurden in Abschnitt 3.5.4 präsentiert. Diese können
ebenso bei MCTT eigesetzt werden.
In Abbildung 5.6(a) ist ein MCTT-Modell von Abbildung 5.3(a) zu sehen, bei dem die abbrechende Aufgabe
C als optional spezifiziert ist. Aus Gründen, die bereits in Abschnitt 5.3.1 erklärt wurden, ist dieses Modell
nicht sound.
Das USE-Tool evaluiert permanent die OCL-Invarianten und erkennt in Abbildung 5.6(a), dass die Invariante
noDisablingWithOptionalTasks verletzt wurde. Wie in Abschnitt 3.5.4 beschrieben, können hier Hilfsmittel
und Tools eingesetzt werden, um den Grund der Invariantenverletzung und involvierten Modellobjekte
herauszufinden.
Ein weiteres Beispiel ist in Abbildung 5.6(b) angegeben. Dafür wurde das CTT-Modell von Abbildung 5.3(b)
herangezogen und nachmodelliert. Aus Gründen, die ebenfalls bereits in Abschnitt 5.3.1 vorgestellt wurden,
ist das Modell inkonsistent. In Abbildung 5.6(b) ist des Weiteren zu sehen, dass die Invariantenverletzung von
noChoiceWithOptionalTasks angezeigt wird. Der Fehler ist damit erkannt worden und kann vom Modellierer