Metamodellbasierte und hierarchieorientierte ... - RosDok

136 Zusammenfassung und Ausblick
über das Datenmodell gelöst worden. Das Workflowmodell bezieht also Datenelemente in die Spezifikation
der Ablauflogik mit ein, was sehr nützlich und wichtig ist. Bei TTMS ist der Datenaspekt mit einer Dokumentensicht
zwar integriert, hat aber keinen Einfluss auf die Ausführungslogik. Hier wäre analog zu YAWL
oder MCTT ein datenbasierter Choice wünschenswert gewesen. Bei TTMS wurde die explizite Entscheidungsmodellierung
stattdessen durch Decisionnodes implementiert, die an die Entscheidungsmodellierung
von EPKs angelehnt ist.
Die Praktikabilität der vorgestellten Ansätze zur Workflowmodellierung auf Basis der entwickelten Softwareprototypen
konnte anhand zahlreicher Modelle unterschiedlicher Komplexität evaluiert und bestätigt
werden. Auch größere Modelle wurden damit erzeugt. So wurde z.B. ein Kfz-Inspektionsprozess einer
Autowerkstatt mit DMWM und MCTT modelliert, der jeweils aus ca. 60 Aktivitäten und insgesamt über 100
Modellelemente bestand. Die Ausführung der Workflowmodelle ist bei den metamodellbasierten Ansätzen
direkt im Modellierungstool realisiert worden. Auch die Ausführung der großen Modelle war mit dem
jeweiligen Runtime-Plugin möglich, wobei sich gezeigt hat, dass die Ausführung auf Basis von SOIL (bei
MCTT) deutlich schneller war als die mit ASSL (bei DMWM).
7.2 Weiterführende Diskussion
Metamodelle sind dazu geeignet, beliebige Aspekte bzw. Eigenschaften für Workflowsprachen zu definieren.
Alle Aspekte in einem allumfassenden Metamodell aufzunehmen, wäre mit dem hier gewählten Ansatz und
Tool technisch durchaus realisierbar. Jedoch stellt sich nicht nur die Frage nach der Sinnhaftigkeit dieser
Idee, sondern auch die nach der Vereinbarkeit der Ziele, welche die zugrundeliegenden Philosophien der
einzelnen Sprachen verfolgen. Folgende Gründe führen zu einer skeptischen Beurteilung dieser Fragen.
Eine wichtige Eigenschaft bei den MCTT-Modellen ist die Strukturiertheit, die durch das MCTT-Metamodell
vorgegeben ist. Werden nun Elemente aus anderen Sprachen wie z.B. DMWM aufgenommen, so geht die
vorher garantierte Strukturiertheit zugunsten der Mächtigkeit verloren. Die Situation würde sich weiter
verschärfen, wenn zusätzlich Teile aus den Metamodellen von UML-Aktivitätsdiagrammen oder BPMN
für eine imperative Prozessmodellierung in das integrierte Metamodell aufgenommen werden würde. Ein
solches Metamodell stellt zur deklarativen und hierarchieorientierten Workflowmodellierung die Möglichkeit
bereit, auch konventionelle Prozessmodelle zu erstellen. Somit wäre eine Sprache, die über ein solches
Metamodell definiert wird, sehr mächtig und könnte weit mehr ausdrücken als die einzelnen einfachen
Sprachen.
Jedoch birgt ein solcher Ansatz gravierende Nachteile. Zusätzlich zur Gefahr, dass die Prozessmodelle
recht unübersichtlich werden, ergibt sich das Problem inkonsistenter Semantik. Ein Widerspruch ist beispielsweise
mit der expliziten Angabe des Prozessendes bei imperativen und der impliziten Angabe bei
deklarativen Prozessmodellen gegeben. Es erscheint daher sinnvoller, Metamodelle zu verwenden, bei denen
die Modellierungsphilosophie und Semantik der Modellierungselemente klar definiert und konsistent ist.
Ein integriertes allumfassendes Metamodell kann eine solche Sprache nicht bereitstellen.
Dagegen ist eine einfach zu realisierende Zusammenstellung der Modellierungselemente über die Verwendung
von Metamodellen durchaus möglich. Metamodelle können zur Definition von domänenspezifische
Sprachen eingesetzt werden und damit genau die vom Nutzer gewünschten Modellierungselemente definieren
und bereitstellen [Kle08]. Genauso können Workflowmodellierungssprachen an Nutzeranforderungen
recht einfach adaptiert werden. Da sich Modellierungselemente widersprechen können, ist aber auf die
Konsistenz der Sprache zu achten. OCL-Invarianten können hier helfen, wie es für DMWM und MCTT in
dieser Arbeit gezeigt wurde.