Metamodellbasierte und hierarchieorientierte ... - RosDok

2.5 Geschäftsprozessmodellierung 25
Vor- und Nachteile der einzelnen Flexiblitätskategrien lassen sich diskutieren. „Flexible by change“ hat
z.B. den Vorteil gegenüber „flexible by design“, dass die Geschäftsprozesse vorhersagbarer ablaufen und
dadurch z.B. eine bessere Ressourcenplanung möglich ist. Es werden nur Änderungen im Prozessmodell
vorgenommen, wenn entsprechende Ausnahmen auftreten. Außerdem braucht der Nutzer nicht ständig zu
entscheiden, welche Aktivität er als nächstes zu tun hat. Dieses hat in der Regel eine Zeitersparnis zur Folge.
Die ADEPT Prozessmodelle sind blockorientiert und daher strukturiert. Die Prozessmodelle sind damit
weniger fehleranfällig und gut lesbar [LM10]. Die Modellierung der Workflows mit dem Editor wird
auch als „correct by construction“ [DRRM11] bezeichnet. Das Modellierungswerkzeug erlaubt nur gültige
Prozessmodelle und weist ungültige, die evtl. Deadlocks beinhalten zurück.
2.5.2.7 DECLARE
Mit DECLARE wird eine „flexible by design“ Strategie angewendet [APS09]. Der Fokus der Modelle liegt
nun nicht mehr darin, Nutzer durch den Prozess zu führen und Ausführungsreihenfolgen von Aktivitäten
festzulegen. Die Strategie liegt hier darin, dem Nutzer alle Freiheiten der Workflowausführung zu überlassen
und nur explizit nicht erlaubte Aktivitätssequenzen zu verbieten. Der Ansatz basiert auf LTL-Formeln zur
Spezifikation, welche Aktivitätssequenzen nicht erlaubt sind [Peš08].
Da eine textuelle Constraint basierte Workflowmodellierung sehr unintuitiv und nicht praktikabel ist, wurde
für diesen Ansatz eine grafische Repräsentation entwickelt. Temporale Relationen lassen sich im DECLARE-
Designer – dem Workflow Editor – definieren. Damit lassen sich Prozessmodelle grafisch modellieren, die
dann letztendlich jedoch deklarative Prozessmodelle darstellen. Daraufhin lassen sich diese Modelle in eine
Ausführungsumgebung laden und ausführen [Peš08].
In der DECLARE-Ausführungs-Engine werden Rollen und ausführende Personen verwaltet und Zuordnungen
während der Ausführung vorgenommen. Der Administrator hat die Aufgabe, die Rollen und Personen
anzulegen und die Zuordnungen vorzunehmen. Hierarchische, grafische Organisationsmodelle, die z.B.
von ARIS aus Abbildung 2.2(b) bekannt sind, können hier nicht verwendet werden. Ebenso wie das
Organisationsmodell wird auch das Datenmodell nur sehr minimalistisch behandelt. Es können In- und
Outputdaten für einzelne Aktivitäten definiert werden. Hier sind jedoch nur primitive Datentypen möglich.
Zusammengesetzte Datentypen, Vererbung, Assoziationen, Aggreationen und Kompositionen sind nicht
vorgesehen.
Jedoch ist eine Schnittstelle zum WfMS YAWL implementiert, so dass Kontrollflussspezifikationen für lose
strukturierte Prozesse von DECLARE und stärker strukturierte Prozesse wieder von YAWL übernommen
werden können. Zusätzlich ist auch eine Schnittstelle zum ProM-Tool (s. [ADG + 07]) vorgesehen, die es
ermöglicht, unter DECLARE abgearbeitete Prozesse zu analysieren.
2.5.3 Metamodelle für Geschäftsprozessmodellierungssprachen
In diesem Abschnitt werden einige Metamodelle für verschiedene Modellierungssprachen in Abbildung
2.5 vorgestellt. Auffällig ist, dass es viele Ähnlichkeiten, aber auch sprachspezifische Unterschiede bei den
Metamodellen existieren.
Mit UML hat sich die Technik des Metamodellierens etabliert. Die Metamodelle werden häufig durch
umgangssprachliche Zusicherungen oder formale OCL-Invarianten, die an Klassen des Metamodells assoziiert
werden, deutlich verfeinert. Abbildung 2.5(b) zeigt einen Ausschnitt des UML-Metamodells für
Aktivitätsdiagramme [UML10, S.306ff]. Im Abschnitt der UML-Spezifikation zu den Aktivitätsdiagrammen
[UML10, Kapitel 12] sind für die Zuweisungen der Constraints zu den Klassen zumeist jedoch um-