Metamodellbasierte und hierarchieorientierte ... - RosDok

7.3 Ausblick 137
7.3 Ausblick
Einige Fragestellungen und offene Punkte sind während der Bearbeitung des Themas aufgetreten, die hier
erläutert werden. Die Erweiterungsmöglichkeiten betreffen sowohl die Design- als auch die Runtime der
entwickelten Sprachen. Des Weiteren lassen sich viele weitere Ansätze mit den hier vorgestellten Konzepten
bzw. Tools verbinden.
Wie bereits im Fazit angesprochen und in [MRR10] analysiert, sind Symbole zur Workflowmodellierung
wichtig und für das Modellverständnis förderlich. So wäre eine Umsetzung einer konkreten Syntax für die
Sprachen DMWM und MCTT sehr wünschenswert. Das UML-Objektmodell kann in USE zwar weiterhin
genutzt werden und das Workflowmodell abstakt darstellen, zusätzlich sollte aber ein USE-Plugin für die
Designtime das Objektmodell mit einer konkreten Syntax darstellen. Dort werden die Objekte je nach
Typ mit unterschiedlichen Symbolen visualisiert. Für die Designtime ist die Darstellung des kompletten
Modells als flexible anzuordnender Graf wichtig. Für die Ausführung setzt das entwickelte Runtime-Plugin
die Prozessdarstellung und Nutzerschnittstelle um. Hier werden die relevanten Aktivitäten dagegen über
verschiedenen Sichten in einem Baum oder Listen (Worklists) angeordnet.
Es können diverse weitere Sprachen durch Metamodelle ausgedrückt werden. Auch Petri-Netze gehören
dazu, für die u.a. in [JKBL10] ein UML-Metamodell entwickelt wurde. Speziell auf Workflows bezogen ist
eine Untersuchung interessant, die analysiert, ob OCL in der Lage ist, den von van der Aalst definierten
Soundness-Begriff für Workflow-Netze [AS11] metamodellbasiert zu spezifizieren. Auf Grundlage dessen
ließe sich mit dem UML-Tool USE Workflow-Netze modellieren, die just-in-time während der Designtime
auf Konsistenzeigenschaften geprüft werden könnten.
Auch eine Ausführung der Workflow-Netze ist mit den Techniken, die in dieser Arbeit verwendet wurden,
denkbar. Die operationale Semantik der Petri-Netze basiert jedoch nicht auf Zustandsdiagrammen, so wie
bei den in dieser Arbeit entwickelten Sprachen. In [Wac08] ist hierfür ein Petri-Netz-Metamodell entwickelt
worden, das auch die Ablaufsemantik für die Runtime umsetzt. Die operationale Semantik eines solchen
Metamodells lässt sich auch durch die OCL-basierten imperativen Sprachen ASSL oder SOIL umsetzen.
Das Plugin zur Darstellung der Prozessinstanzen und Nutzerschnittstelle ist zwar weitestgehend generisch
gehalten, basiert jedoch auf Zustandsänderungen, die vom Nutzer aufgerufen werden. Die Darstellung und
Ausführung der Modelle ist damit nicht unmittelbar adaptierbar, wie das z.B. ausgehend von der Sprache
DMWM zu MCTT möglich war.
Um die in dieser Arbeit entwickelten Sprachen und Tools für eine nutzerorientierte Validierung der Prozessmodelle
zu erweitern, können die Prozessmodelle mit Kontexinformationen, wie z.B. Bildern, angereichert
werden. Die Executable Use Case Modellierung verfolgt einen solchen Ansatz [JTF09]. Mit so einer
Erweiterung wird die Anschaulichkeit der Modellausführung für den Nutzer erhöht und damit die Diskussionsgrundlage
verbessert. Um dieses zu erreichen, ist eine Erweiterung sowohl der Modellierungs- als auch
der Ausführungsumgebung für DMWM bzw. MCTT notwendig.
Die Modelle sind bei DMWM und MCTT adaptiv, indem sie zur Runtime editiert werden können. Da jedoch
gewisse Modellierungselemente zur Runtime geschützt werden müssen, ist hier zunächst eine genauere
Analyse sinnvoll, die diese Elemente identifiziert. Auf dieser Basis kann dann ein Runtime-Modelleditor für
USE entwickelt werden, der die entsprechenden Elemente schützt und die anderen zum Editieren freigibt.
Bezüglich der Modellausführung gibt es bei DMWM und MCTT nicht mehrere Rollen-Perspektiven für
die Prozessausführung. Mit DMWM wurde eine Organisationsmodellierung integriert, jedoch werden die
unterschiedlichen Perspektiven bei der Prozessausführung nicht berücksichtigt. Hier ist eine Erweiterung
des Plugins sinnvoll, die jeder Rolle eine Perspektive auf den Prozess bereitstellt und die ihr zugeordneten