Metamodellbasierte und hierarchieorientierte ... - RosDok

2 Einleitung
Verlust an Semantik, weil sich nicht alle Modellierungselemente in Petri-Netze übersetzen lassen.
Der hierarchieorientierte Ansatz hat des Weiteren die Eigenschaft, mehrere Abstraktionsebenen in einem
Modell auszudrücken. Hierbei spielen die Modellierung von Zielen einzelner Aktivitäten bzw. Aktionen eine
Rolle. Beide Ansätze sind visuell und direkt ausführbar. Es müssen keine Transformationen von visuellen
zu textuell ausführbaren Sprachen oder Petri-Netzen gemacht werden.
Abschnitt 1.1 führt Probleme auf, die sich bei den etablierten Modellierungssprachen gezeigt haben. Ziele
und Lösungperspektiven, die mit dieser Arbeit entstanden sind, werden aufgezeigt. Eine prägnante
Aufzählung der Vorteile der hier verfolgten Ansätze findet in Abschnitt 1.2 statt. Außerdem werden Abgrenzungen
vorgenommen, die angeben, wofür die neu eingeführten Techniken, Sprachen und Werkzeuge zur
Geschäftsprozessmodellierung eingesetzt werden können bzw. (noch) nicht geeignet sind. Des Weiteren
beschreibt dieser Abschnitt den wissenschaftliche Entstehungsprozess dieser Arbeit anhand der entstandenen
Publikationen. Der Abschnitt 1.3 beschreibt schließlich den weiteren Aufbau und die Struktur.
1.1 Probleme etablierter Ansätze und Ziele der Arbeit
Aktuell populäre, verbreitete Sprachen zur Workflowmodellierung verfolgen einen imperativen Stil, der
angibt, wie ein Prozess abzulaufen hat. Dabei wird beispielsweise bei EPKs und BPMN über Startereignisse
ein definierter Anfang und über Endereignisse ein definiertes Ende spezifiziert. Dazwischen wird über
Ketten von Aktivitäten angegeben, wie man vom Start zum Ende gelangt. Dieser Ansatz kann für bestimmte
Einsatzzweck zu restriktiv sein und den Nutzer in bestimmten Situationen in der Ausführung der Tätigkeit
zu sehr einschränken.
Der hier vorgestellte Ansatz verfolgt dagegen einen deklarativen und damit flexibleren Stil, Workflows zu
beschreiben (vgl. [APS09]). In den Modellen sind die modellierten Aktivitäten grundsätzlich unabhängig
voneinander. Daraufhin können Ablaufreihenfolgen über die Constraintsprache OCL verboten werden. Alle
anderen Ablaufpfade bleiben im Modell weiterhin erlaubt. Mit den verbietenden OCL-Constraints kommt
der Modellierer nicht in Kontakt, da sie hinter visuellen Modellierungselementen verborgen sind. Somit
wird eine intuitive visuelle Modellierung unterstützt. Mit dem deklarativen Ansatz werden dem Endnutzer
während der Runtime mehr Möglichkeiten für die Prozessausführung gegeben. Es gibt zwar bereits Sprachen,
die deklarativ Workflows beschreiben, aber keine nutzt einen metamodellbasierten Ansatz, der noch weitere
im Folgenden angegebene Vorteile bietet.
In den bisherigen Workflow-Modellierungssprachen fehlen ausführbare Ansätze, die eine visuelle Datenmodellierung
z.B. über UML-Klassendiagramme mit Workflowmodellen verbindet. Etablierte Modellierungssprachen
wie z.B. eEPKs in ARIS (s. Abschnitt 2.5.2.1) sind nicht ausführbar. Dagegen werden
in Workflowsystemen, die ausführbare Workflows unterstützen (z.B. YAWL [AH05]) nur nicht intuitive
XML-basierte Datenspezifikationen genutzt. Eine visuelle Datenmodellierung mit unmittelbarer Nutzung
der Modelle zur Ausführung ist hier nicht vorgesehen. Der Ansatz, der mit dieser Arbeit verfolgt wird,
nutzt die grafische Workflow- und Datenmodelle unmittelbar ohne jegliche Transformation zur Ausführung.
Damit wird eine Art rapid prototyping für Workflowmodelle unterstützt. Dynamische Modelleigenschaften
im Zusammenhang mit Daten, die während des Prozesses abgefragt bzw. erhoben werden, werden damit
validiert.
Etablierte Ansätze für die Modellierung von Workflows nutzen an Petri-Netzen angelehnte Modellierungssprachen,
welche unstrukturierte Modelle [KHB00] erlauben, die das Verständnis beim Endanwender
erschweren können [LG08]. Bei Programmiersprachen wurde unstrukturierter Programmcode mit goto-Anweisungen
als schädlich für das Verständnis des Programms angesehen [Dij68]. Entsprechend haben sich