Metamodellbasierte und hierarchieorientierte ... - RosDok

24 Grundlagen: Modellierung in ausgewählten Gebieten
der entsprechende Pfad wird automatisch genommen. Daten, die für den Nutzer zur Aufgabenausführung
benötigt werden, werden ebenfalls über XQuery abgefragt. Das Datenmodell liegt somit über textuelle
XML-Daten vor. Eine intuitive Datenmodellierung mit UML ist hier nicht vorgesehen.
Ressourcenallokationen kann das WfMS automatisch vornehmen und Aktivitäten-ausführenden Personen
zuweisen. Das Organisationsmodell liegt bei YAWL ebenfalls nicht grafisch vor. Rollen und Personenzuordnungen
lassen sich über das web-basierte Administrationsinterface festlegen. Anhand dieser Zuordnungen
und der vorher festgelegten Zuordnungsstrategie kann die YAWL-Engine dann die Arbeit automatisch an
die Nutzer verteilen.
Alle Workflow-Patterns lassen sich in YAWL ausdrücken und letztendlich mit dem WfMS ausführen. Die
Ausführungssemantik ist stark angelehnt an Petri-Netze. Aktivitäten lassen sich vom Nutzer starten und
wieder beenden. Für jede Aktivität wird ein Petri-Netz als Subnetz angelegt und dieser Sachverhalt durch
start- und finish Tansitionen ausgedrückt [AH05, Abb.7]. Von dieser Modellierung und Verhalten zur
Runtime wird in den YAWL-Workflowmodellen zur Designtime jedoch abstrahiert.
Wie schon in Abschnitt 2.5.1 erwähnt, bieten WfMS große Flexiblitätsvorteile gegenüber konventioneller
Software, die Geschäftsprozesse hart codieren. Soll ein Geschäftsprozess verändert werden, muss hier nicht
die Software angefasst werden, sondern es reicht, das Geschäftsprozessmodell anzupassen. Dieses kann
visuell mit dem YAWL-Editor geschehen. Daraufhin wird das Modell mit einem internen XML-Format auf
die YAWL-Engine übertragen und der Prozess kann für weitere Geschäftsvorfälle instanziiert werden.
Ein Nachteil gegenüber konventioneller Software ist die Usability der generischen Nuterschnittstelle im
WfMS. Die Schnittstelle passt sich nicht den aufgabenspezifischen Anforderungen an, sondern ist generisch
über die Web-Schnittstelle festgelegt.
2.5.2.6 ADEPT
Zusammen mit dieser Sprache ist ebenso wie bei YAWL ein Workflow Management System implementiert
worden [DRRM11]. Es wurde an der Universität Ulm entwickelt und steht für „Application DEvelopment
Based on Pre-Modeled Process Templates“. Es bietet zusätzliche Flexibilität für Geschäftsprozesse im
Vergleich zu anderen WfMSen. Modellinstanzen lassen sich hier nach bestimmten Regeln zur Laufzeit
verändern. Wenn sich z.B. während eines Geschäftsvorfalls herausstellt, dass Aktivitäten im Prozessmodell
fehlen oder für diesen speziellen Fall anders angeordnet werden sollen, so bietet das System eine Möglichkeit,
das Prozessmodell zur Runtime anzupassen. Autorisierungsmechanismen sind hier außerdem zu beachten.
ADEPT ermöglicht Spezifikationen inkl. Exception handlings und Adhoc-Änderungen bei Workflows.
Außerdem kann das Prozessschema verändert werden während Instanzen von ihm laufen und die laufenden
Instanzen werden darauf umgestellt. Dabei können Migrationsprobleme auftreten, die vom System beachtet
werden. Beispielsweise könnte keine Aktivität im Modellschema vor eine schon beendeten Aktivität in
einer laufenden Prozessinstanz eingefügt werden. ADEPT behandelt mit dieser Funktionalität die Workflow
Schema Evolution und Änderungspropagierung [DR09].
Die hier betrachtete Flexiblitätseigenschaft wird als „flexible by change“ bezeichnet [SMR + 08]. Der Nutzer
des WfMS wird bei diesem System durch den Geschäftsvorfall durch das System geführt und bei
Ausnahmefällen kann das Prozessmodell geändert werden. Zudem gibt es noch andere Flexiblitätskategorien
wie „flexible by design“. Dieses Prinzip wird von deklarativen Prozessspezifikationen verfolgt, die
Aktivitätsfolgen lediglich verbieten, die nicht erwünscht sind. Alle anderen Aktivitätsfolgen sind erlaubt.
Dem Nutzer werden daher im voraus meherer Ausführungsmöglichkeiten gegeben als bei imperativen
Prozesspezifikationen, die nur erlaubte Aktivitätsreihenfolgen spezifizieren.