Modellierung planbarer Abweichungen in Workflow-Management-Systemen [original]

183

Modellierung planbarer Abweichungen

in Workflow-Management-Systemen

Manfred Reichert, Thomas Bauer, Thomas Fries, Peter Dadam

Abteilung Datenbanken und Informationssysteme

Universität Ulm, D-89069 Ulm

{reichert, bauer, fries, dadam}@informatik.uni-ulm.de

Abstract: Workflow-Management-Systeme (WfMS) sind eine vielversprechende

Technologie für die Realisierung prozessorientierter Anwendungen. Allerdings

bieten heutige WfMS keine ausreichende Unterstützung zur Behandlung von Aus-

nahmen. Im ADEPT-Projekt haben wir deshalb fortschrittliche Modellierungs- und

Ausführungskonzepte entwickelt, die auf eine Erhöhung der Flexibilität von

WfMS zielen. Sie ermöglichen es zum einen, planbare Abweichungen vom Stan-

dardablauf eines Arbeitsprozesses bereits zur Modellierzeit festzulegen, zum ande-

ren können nicht vorhersehbare Abweichungen auch dynamisch zur Laufzeit er-

folgen. Dieser Beitrag konzentriert sich auf den erstgenannten Aspekt. Er zeigt auf,

wie sich planbare Abweichungen sinnvoll modellieren lassen, welche Anforderun-

gen dabei bestehen und welche Möglichkeiten bzw. Grenzen mit einem solchen

Ansatz verbunden sind. Unsere Erfahrung mit konkreten Anwendungen aus dem

Krankenhausbereich hat gezeigt, dass entsprechende Modellierungsmöglichkeiten

einen wichtigen Beitrag zur Erhöhung der Flexibilität von WfMS leisten.

1 Einleitung

WfMS bieten eine vielversprechende Technologie zur Realisierung prozessorientierter

Anwendungssysteme [Ob96]. Charakteristisch für viele WfMS ist die Trennung von

Prozesslogik und Anwendungscode [LR00]. Die Ablauflogik der Arbeitsprozesse (engl.

Workflows; kurz: WF) wird dem WfMS explizit durch die Modellierung bekannt ge-

macht und nicht im Programmcode „versteckt“. Dieser Ansatz bietet mehrere Vorteile:

Die systemseitige Durchführung der Ablaufsteuerung vereinfacht die Anwendungsent-

wicklung erheblich. Durch die explizite Beschreibung der Prozesslogik kann zudem das

zukünftige Systemverhalten vorab evaluiert werden, wodurch sich Entwurfsfehler noch

vor Implementierung der eigentlichen Anwendungskomponenten entdecken lassen. Aus

denselben Gründen sind spätere Änderungen in den Geschäftsprozessen und daraus

resultierende Anpassungen der Anwendungssysteme einfacher durchführbar.

Trotz dieser Vorteile sind WfMS in der betrieblichen Praxis nicht verbreitet. Ein wesent-

licher Grund hierfür ist ihre mangelhafte Flexibilität [MR99, We98]. So gestatten es

heutige WfMS nur eingeschränkt, vom einmal modellierten Standardablauf abzuweichen

(z.B. durch Auslassen von WF-Schritten). Dies ist aber oftmals unerläßlich, um flexibel

auf Ausnahmensituationen reagieren zu können. Beispiele für Ausnahmen sind die Ve r-

schlechterung des Zustands eines Patienten im Verlauf eines Behandlungsprozesses oder

Fehler bei der Herstellung eines Produktes. Ausnahmen beschreiben also Ereignisse,

deren Auftreten eine Abweichung vom „normalen“ Ablauf erfordert [SM95].

M. Glinz, G. Müller-Luschnat (Hrsg.): Proc. Modellierung 2002, Ar-

beitstagung der GI, Tutzing, März 2002, S. 183-194 (GI-Edition Lecture

Notes in Informatics, Band P-12)

184

Generell muss zwischen planbaren und nicht planbaren Ausnahmen bzw. Abweichungen

unterschieden werden. Für planbare Ausnahmen ist der Kontext ihres Auftretens ebenso

bekannt, wie die zu ihrer Behandlung notwendigen Aktionen. Dementsprechend können

diese Ausnahmen bereits bei der WF-Modellierung berücksichtigt werden. Bei nicht

planbaren Ausnahmen handelt es sich dagegen um a priori unbekannte Ereignisse, die

erst zur Laufzeit behandelt werden können. Zur besseren Differenzierung verwenden wir

im Folgenden die Begriffe A-priori- und A-posteriori-Flexibilität [Jo99].

Zur Erhöhung der A-posteriori-Flexibilität bietet ADEPT fortschrittliche Konzepte für

dynamische WF-Änderungen, die ausführlich in [RD98, Re00] beschrieben werden. Sie

gestatten es zur Laufzeit, die Struktur, den Zustand und die Attribute von WF-Instanzen

anzupassen. Zur Sicherung der Konsistenz werden bei der Durchführung solcher Ad-

hoc-Änderungen umfangreiche Korrektheitsüberprüfungen vorgenommen [Re00]. Die-

ser Beitrag behandelt Konzepte zur Verbesserung der A-priori-Flexibilität in WfMS.

Motivation hierfür bilden langjährige Erfahrungen mit Krankenhausabläufen [DRK00].

Hier hat sich gezeigt, dass Ausnahmen oftmals a priori bekannt sind und deshalb bereits

bei der WF-Modellierung berücksichtigt werden können. Dadurch verringert sich auch

die Häufigkeit der vergleichsweise teuren Ad-hoc-Modifikationen zur Laufzeit.

Um die Anforderungen an die Modellierung planbarer Abweichungen besser zu verste-

hen, sind sowohl die Sicht des Modellierers als auch der späteren Anwender zu beach-

ten. Aus Modellierersicht muss der Regelfall von ausnahmebedingten Abweichungen

getrennt beschreibbar sein. Darüber hinaus darf unter der Einbeziehung von Aus-

nahmebehandlungen die Übersichtlichkeit der WF-Modelle nicht leiden oder sich der

Aufwand für ihre Erstellung wesentlich erhöhen. Aus Anwendersicht ist es wichtig, dass

„normale“ Aktivitäten von ausnahmebedingten Aktionen, deren Ausführung eine Ab-

weichung vom Standardablauf bedeutet, unterscheidbar sind.

Abschnitt 2 fasst wichtige Grundlagen zusammen, die für das weitere Verständnis nötig

sind. In Abschnitt 3 zeigen wir, wie sich planbare Vorwärtssprünge modellseitig abbil-

den lassen. Abschnitt 4 behandelt planbare Rückwärtssprünge. Es folgen in Abschnitt 5

eine Diskussion verwandter Ansätze und in Abschnitt 6 eine kurze Zusammenfassung.

2 Grundlagen

Für jeden zu unterstützenden Prozesstyp muss eine WF-Modell erstellt und im WfMS

hinterlegt werden. Ein solches WF-Modell beschreibt, welche Arbeitsschritte (sog. Akti-

vitäten) von welchen Benutzern in welcher Reihenfolge und unter Nutzung welcher

Daten und Programme bearbeitet werden sollen. Zur Modellierung der verschiedenen

WF-Aspekte dient das ADEPT-Basismodell. Es ermöglicht die Überprüfung statischer

und dynamischer Modelleigenschaften, etwa im Hinblick auf die Terminierung des WF,

die Erfüllbarkeit von Zeitbeschränkungen oder die Vollständigkeit von Datenflüssen.

Für die Modellierung verfolgen wir einen blockbasierten Ansatz, bei dem Sequenzen,

Verzweigungen (AND/AND; XOR/XOR; AND /XOR) und Schleifen als Blöcke mit je-

weils genau einem Ein- und Ausgangsknoten modelliert werden. Solche Kontrollblöcke

können geschachtelt sein, dürfen sich aber nicht überlappen. Um die Ausdrucks-

mächtigkeit des Metamodells zu erhöhen, umfaßt es zusätzliche Konstrukte, etwa zur

185

Beschreibung von Wartet-Auf-Be-

ziehungen zwischen Aktivitäten

paralleler Zweige. Ein einfaches

Beispiel zeigt Abb. 1.

Nach Erzeugung und Start einer

WF-Instanz wird diese über ihre

komplette Lebensdauer hinweg

vom WfMS kontrolliert. Dazu wird

ein Ausführungsgraph verwaltet,

dessen Knoten und Kanten be-

stimmte Zustandsmarkierungen be-

sitzen. Es gibt wohldefinierte Re-

geln, die festlegen, unter welchen

Markierungen eine Aktivität akti-

viert werden darf und welche Fol-

gemarkierungen sich im Anschluss

an ihre Ausführung ergeben. Hier-

auf basierend steuert das WfMS

die WF-Ausführung, bietet die zur

Bearbeitung anstehenden Aktivi-

täten zuständigen Akteuren in Ar-

beitslisten an, führt automatische Schritte selbständig durch und ruft die für die Ausfüh-

rung von Aktivitäten passenden Programme (mit den richtigen Daten) auf.

3 Planbare Vorwärtssprünge

Ausnahmebedingt kann es erforderlich werden, die Bearbeitung von Aktivitäten zu über-

springen oder Aktivitäten vorzeitig auszuführen (vgl. Bsp. 1).

Beispiel 1: (Überspringen von Aktivitäten):

Die Abwicklung einer medizinischen Untersuchung umfasst mehrere Arbeitsschritte: Anordnung

der Untersuchung, Planung des Untersuchungstermins, Vorbereitung und Aufklärung des Patien-

ten, Untersuchungsdurchführung sowie Erstellung und Validation eines Befundes (vgl. Abb. 1).

Bereits bei dieser einfachen Prozesskette müssen Benutzer bei Bedarf in flexibler Form vom Stan-

dardablauf abweichen können. So muss die Untersuchung im Ausnahmefall auch ohne die an-

sonsten übliche Terminvereinbarung und ohne die standardmäßigen Vorbereitungen notfallmäßig

durchgeführt werden können. D.h. Anwender müssen diese Schritte überspringen können.

Häufig sind solche Abweichungen vom „normalen“ Ablauf planbar. Ist etwa a priori

bekannt, dass die Bearbeitung einer Aktivität in Ausnahmefällen vorgezogen werden

können muss, so sollte dies im WF-Modell abbildbar sein. Dadurch wird das WfMS in

die Lage versetzt, die betreffende Aktivität zur Laufzeit als „Ausnahmeschritt“ anzubie-

ten, ohne dass zu ihrer Auswahl aufwendige Interaktionen (wie im Fall von Ad-hoc-

Änderungen) notwendig werden. Wichtig ist, dass die Zielaktivität eines Vorwärts-

sprungs dem Anwender in einer anderen Form präsentiert wird als ein „normaler“ Ar-

beitsschritt. Zu diesem Zweck muss es möglich sein, bei der Modellierung zwischen

präferierten Ausführungsreihenfolgen und Ausnahmepfaden zu unterscheiden.

Untersuchung

durchführen

Patien

vorbereiten

Termin

planen

Patient

aufklären

Untersuchung

anordnen

Befund

erstellen

Befund

validieren

Termin

Befund

LOOP

Prozessvariable

AND-Join-Knoten

Termin

Datenfluss Kontrollfluss

min 1 day

AND-Split-Knoten

weitere

Untersuchung? ja

nein

Role = Arzt

Role = Radiologe

Actor =

Actor(Untersuchung durchführen)

Abb. 1: Workflow-Modellierung in ADEPT

186

3.1 Definition und Änderung von Ausführungsprioritäten

In diesem Abschnitt diskutieren wir Erweiterungen des ADEPT-Basismodells, die eine

solche Unterscheidung ermöglichen.

Festlegung von Ausführungsprioritäten bei der WF-Modellierung

Um definieren zu können, ob eine Aktivität bei ihrer Aktivierung als normaler Arbeits-

schritt oder als Ausnahmeschritt angeboten werden soll, führen wir als weiteres Modell-

element statische Ausführungsprioritäten ein. Handelt es sich um einen Ausnahme-

schritt, muss ihm bei der Modellierung die Priorität EXCEPTIONAL zugewiesen wer-

den, andernfalls REGULAR (Voreinstellung). Die Ausführung von Ausnahmeschritten

erfolgt nach denselben Regeln wie im Fall normaler Arbeitsschritte. Die Art und Weise,

in der sie in Arbeitslisten angeboten werden, bleibt aber dem Anwendungsentwickler

überlassen. Denkbar sind das Ein-/Ausblenden von Ausnahmeschritten, die Darstellung

von Arbeitslisteneinträgen in unterschiedlichen Farben oder die Präsentation von nor-

malen und ausnahmebedingten Arbeitsschritten in getrennten Arbeitslisten.

Die Verwendung von Ausführungsprioritäten erweist sich in Verbindung mit Parallel-

verzweigungen bei finaler Auswahl (AND-Split / XOR-Join) als nützlich. Hier kommt es

zur gleichzeitigen Aktivierung paralleler Zweige, wobei für das Fortschreiten der WF-

Kontrolle immer nur die Ausführung eines Teilzweiges notwendig ist. Bei kombinierter

Anwendung mit Ausführungsprioritäten lassen sich somit präferierte Ausführungszwei-

ge von Ausnahmepfaden unterscheiden. Ein Beispiel zeigt Abb. 2.

Im dargestellten Ausführungsgraphen sind die Aktivitäten B und D gleichzeitig aktiviert.

Infolge der zugeordneten Ausführungsprioritäten wird B den Benutzern als regulärer

Arbeitsschritt und D als Ausnahmeschritt angeboten. Dementsprechend wird als Ausfüh-

rungssequenz die Bearbeitung der Schritte A, B, C und E in der angegebenen Reihenfol-

ge präferiert. Prinzipiell kann aber auch Aktivität D anstelle von B und C ausgeführt

werden, etwa wenn eine Ausnahme ihre Ausführung zwingend erfordert.

Änderung von Ausführungsprioritäten während der WF-Ausführung

Abhängig vom WF-Status muss es möglich sein, eine Aktivität das eine Mal als Ausnah-

meschritt und das andere Mal als regulären Arbeitsschritt zu behandeln. Soll z. B. die

Bearbeitung in Ausnahmefällen vorzeitig erfolgen können, im Normalfall aber erst nach

COMPLETED

ACTIVATED

tTRUE_SIGNALED

•

-Ausführungsprioritäten (¬ = REGULAR, - = EXCEPTIONAL)

Reguläre Arbeitsschritte ¬

Ausnahmeschritte -

B (aktiviert)

D (aktiviert)

•

AND-Split XOR-Join

Abb. 2: Verwendung von Ausführungsprioritäten

187

Abschluß bestimmter anderer Schritte, so stellt sie vor Beendigung dieser Schritte eine

Abweichung dar, während sie danach regulären Charakter besitzt.

Solche Sachverhalte lassen sich mit Hilfe statischer Prioritäten allein nicht modellieren.

Es muss deshalb möglich sein, die Ausführungspriorität einer Aktivität im Verlauf der

WF-Ausführung zu ändern. Zu diesem Zweck führen wir Priorisierungskanten ein.

Einer Priorisierungskante ist eine der beiden Prioritäten REGULAR oder EXCEPTIONAL

zugeordnet. Bei erfolgreicher Beendigung ihrer Quellaktivität wird ihrer Zielaktivität die

Kantenpriorität als Ausführungspriorität zugewiesen. Besitzt eine Aktivität Y z.B. die

statische Ausführungspriorität EXCEPTIONAL und wird zur Laufzeit eine in Y einmün-

dende Priorisierungskante mit Kantenpriorität REGULAR signalisiert (d.h. die Quellakti-

vität wurde erfolgreich beendet), so wird die Ausführungspriorität von Y ebenfalls auf

REGULAR gesetzt. Das bedeutet, dass die Ausführung dieses Schrittes keine Abwei-

chung mehr darstellt und Y deshalb wie ein normaler Arbeitsschritt behandelt wird.

Ein Beispiel zeigt Abb. 3. Hier wird die Aktivität D zuerst als Ausnahmeschritt (vgl.

Abb. 3 a) und nach Signalisieren der Priorisierungskante C → D als regulärer Schritt

angeboten (vgl. Abb. 3 b). Insgesamt erlauben es die vorgestellten Erweiterungen, präfe-

rierte Ausführungsreihenfolgen und Ausnahmepfade voneinander zu unterscheiden.

3.2 Modellierung von Vorwärtssprüngen

Wir zeigen nun, wie sich obige Modellelemente für die Modellierung planbarer Vor-

wärtssprünge (Shortcuts) nutzen lassen. Dabei unterscheiden wir Vorwärtssprünge mit

und ohne Nachholen der übersprungenen Schritte. Auch Mischformen sind möglich,

werden hier aus Platzgründen aber nicht behandelt. Voraussetzung für die Modellierung

Priorisierungskante mit Kantenpriorität REGULAR

NS = COMPLETED

NS = ACTIVATED

ES = TRUE_SIGNALED

Prioritäten (¬ = REGULAR, -

= EXCEPTIONAL)

Reguläre Arbeitsschritte

Ausnahmeschritte

C (aktiviert)

D (aktiviert)

Reguläre Arbeitsschritte

Ausnahmeschritte

D (aktiviert)

Beendigung von C +

Signalisieren der Priorisierungskante

Ausnahmeschritt

Regulärer Schritt

Abb. 3: Änderung der Ausführungspriorität eines Aktivitätenknotens

188

eines Shortcut ist, dass die Zustände in denen er wählbar sein soll und die Aktivität(en),

deren Bearbeitung im Ausnahmefall vorgezogen werden soll(en), a priori bekannt sind.

Aus Sicht des Modellierers erfolgt die Definition auf semantisch hoher Ebene, unter

Verwendung einer speziellen Sprungkante (Shortcut-Kante). Diese wird intern in eine

Darstellung des ADEPT-Basismodells übersetzt, wodurch eine präzise Ausführungsse-

mantik resultiert. Ein Beispiel zeigt Abb. 4 a. Die Shortcut-Kante A → F spiegelt die

Modellierersicht wider. Sie besitzt folgende Semantik: Nach erfolgreicher Beendigung

der Quellaktivität nsSC (Knoten A im Bsp.) werden nicht nur die normalen, im Kontroll-

fluß nachfolgenden Aktivitäten von nsSC (B im Bsp.) aktiviert, sondern auch die Zielakti-

vität ndSC des Vorwärtssprungs (Knoten F im Bsp.). Diese wird solange wie ein Aus-

nahmeschritt behandelt, bis ndSC auf „normalen“ Wege aktiviert wird (In unserem Bsp.

trifft dies zu, nachdem E beendet wird.) Tritt dieser Fall ein und wurde ndSC zuvor nicht

gestartet, wird die Aktivität in der Folge wieder wie ein normaler Arbeitsschritt behan-

delt. Wird ndSC dagegen vorzeitig gestartet, d.h. noch während der Status eines Ausnah-

meschrittes besteht, müssen die dadurch übersprungenen Schritte (Knoten B, C oder D,

E) gesondert behandelt werden. Hierzu werden nachfolgend zwei Varianten diskutiert.

Überspringen ohne Nachholen

Eine Möglichkeit zur Behandlung übersprungener Aktivitäten ist, auf ihre Bearbeitung

komplett zu verzichten. Wählt ein berechtigter Akteur den Zielknoten eines Shortcut aus,

während dieser den Status eines Ausnahmeschrittes besitzt, werden alle Aktivitäten

zwischen dem Start- und Endknoten des Shortcut (im Bsp. B, C bzw. D und E) – abhän-

gig von ihrem aktuellen Ausführungsstatus – kompensiert, abgebrochen oder deaktiviert.

Anschließend wird mit der Ausführung des Sprungknotens (im Bsp. E) fortgefahren.

Ein Beispiel zeigt Abb. 4: Auf der linken Seite ist ein Shortcut dargestellt, wie er vom

Modellierer definiert wird. Die rechte Seite zeigt seine Umsetzung in ADEPT. Sie ba-

siert auf Ausführungsprioritäten und dem Konstrukt der Parallelverzweigung mit finaler

Auswahl (AND-Split/XOR-Join). Ein Teilzweig enthält den Kontrollblock, dessen Akti-

vitäten bei Anwendung des Shortcut kompensiert, abgebrochen oder ausgelassen werden

sollen. Der andere besteht aus einer vordefinierten, als Ausnahmeschritt gekennzeich-

neten Sprungaktivität <“Springe zu“ + Sprungknoten>, die für berechtigte Akteure nach

Beendigung des Shortcut-Quellknotens (A im Bsp.) und vor (regulärer) Aktivierung des

Shortcut-Zielknotens (F im Bsp.) wählbar ist. Bei Auswahl der Sprungaktivität wird der

obere Teilzweig beendet, woraufhin der untere Teilzweig abgebrochen und zurückge-

setzt wird. Anschließend wird mit der Ausführung am Knoten F fortgefahren. Werden

die Aktivitäten des unteren Zweiges dagegen auf normalem Wege beendet, d.h. ohne

dass die Sprungaktivität zur Ausführung kommt, wird umgekehrt diese Ausnah-

meaktivität deaktiviert. Die Ausführung von F stellt dann keine Abweichung mehr dar.

Bei der Shortcut-Definition werden verschiedene Überprüfungen vorgenommen, die eine

korrekte Ausführung sicherstellen sollen. So wird z.B. geprüft, ob das zugehörige Daten-

fluss-Schema auch nach Umsetzung des Shortcut korrekt ist. Trifft dies bereits vor Hin-

zunahme der Shortcut-Kante zu, reduzieren sich die notwendigen Datenflussanalysen auf

die Fragestellung, ob Lesezugriffe auf Prozessvariablen, die von Knoten des Sprungbe-

reichs geschrieben werden, auch nach Auslassung dieser Knoten versorgt sind [Re00].

189

Überspringen mit Nachholen

Bei vorzeitiger Bearbeitung von Aktivitäten ist es nicht zwingend erforderlich, dass die

dadurch übersprungenen Arbeitsschritte ausgelassen werden. Statt dessen ist es oftmals

sinnvoll, diese parallel weiter zu bearbeiten. Für Aktivitäten des Sprungbereichs bedeutet

das, dass die Effekte bereits beendeter Aktivitäten erhalten, begonnene Aktivitäten fort-

geführt und noch nicht aktivierte Aktivitäten ausführbar bleiben sollen. Dieser Sachver-

halt läßt sich in ADEPT ebenfalls modellieren. Der Modellierer muss dazu bei der Defi-

nition des Shortcut nsSC → ndSC einen weiteren Knoten nnSC festlegen, bis vor dessen

Aktivierung die übersprungenen Schritte beendet bzw. nachgeholt werden sollen.

Ein Bsp. zeigt Abb. 5 a. Die Aktivitäten F und G sind nach Beendigung von A vorzeitig

bearbeitbar, wobei die dadurch übersprungenen Aktivitäten (B, C bzw. D, E im Beispiel)

vor Aktivierung von H beendet sein müssen. Die interne Umsetzung dieses Shortcut illu-

striert Abb. 5 b). Nach Beendigung von A wird B als regulärer Schritt und F als Ausnah-

meschritt angeboten. Treten bei der WF-Ausführung keine Ausnahmen auf, d.h. werden

jeweils nur Aktivitäten mit Priorität REGULAR bearbeitet, wird der untere Teilzweig der

durch (A, H) gebildeten Verzweigung beendet, bevor F gestartet wird. F und G sind dann

wieder als „normale“ Schritte ausführbar. Führt ein Benutzer dagegen F zuvor aus, liegt

eine ausnahmebedingte Abweichung vor. In jedem Fall werden die Knoten des Sprung-

bereichs vor Aktivierung von H beendet. Formale Bedingungen für die korrekte Ver-

wendung von Shortcuts und Graphtransformationsregeln finden sich in [Re00].

3.3 Diskussion und Zusammenfassung

Die vorgestellten Modellierungskonzepte können noch verallgemeinert werden. Bei-

spielsweise sind auch Vorwärtssprünge abbildbar, bei denen die übersprungenen Schritte

wahlweise nachgeholt oder ausgelassen werden. Konzeptuell ergeben sich hieraus keine

neuen Fragestellungen, so dass wir an dieser Stelle auf eine Darstellung verzichten.

Trivialerweise lassen sich durch die Verwendung von XOR-Verzweigungen auch auto-

matische Vorwärtssprünge modellieren. Allerdings ist es in der Praxis nicht immer mög-

lich, alle potentiellen Vorwärtssprünge a priori im WF-Modell zu berücksichtigen

[DRK00]. Deshalb werden auch Mechanismen benötigt, die es Akteuren zur Laufzeit

gestatten, Ad-hoc-Vorwärtssprünge durchzuführen (siehe [RD98]).

Umsetzung des Sprungs im ADEPT-Basismodell

A B

Shortcut-Kante

Vorwärtssprung ohne Nachholen (Sicht

des Modellierers)

Springe zu F

¬ - Prioritäten (¬ = REGULAR, -

= EXCEPTIONAL)

Sprungbereich

AND-Split XOR-Join

XOR-Split XOR-Join

Abb. 4: Modellierung von Vorwärtssprüngen ohne Nachholen und Umsetzung in ADEPT

190

4 Planbare Rückwärtssprünge

In ADEPT können auch verschiedene Arten von Rücksprüngen modelliert werden, von

denen die wichtigsten nachfolgend betrachtet werden. Es lassen sich sowohl normale

Schleifenrücksprünge als auch Fehlerrücksprünge, bei denen der WF in einen früheren

Bearbeitungszustand rückgesetzt wird, modellieren. Dadurch können z.B. Aktivitäten-

fehlschläge (siehe Bsp. 2) automatisch behandelt werden.

Beispiel 2 (Scheitern einer Aktivitätenbearbeitung):

Wir beziehen uns auf Bsp. 1. Bei diesem Ablauf kann die Durchführung der medizinischen Inter-

vention aus unterschiedlichen Gründen fehlschlagen, etwa aufgrund unterlassener Vorbereitungen

oder fehlender Einwilligung des Patienten. Abhängig vom konkreten Grund des Scheiterns können

unterschiedliche Ausnahmebehandlungen notwendig werden, wie der Abbruch des Ablaufs oder

die Wiederholung bestimmter Schritte und die nochmalige Durchführung der Intervention.

4.1 Semantische Fehler und Fehlerrücksprungkanten

Zur Modellierung planbarer Rücksprünge führen wir Fehlercodes und -kanten ein. Feh-

lercodes definieren semantische Fehler einer Aktivität (im Bsp. „unterlassene Vorberei-

tung“ oder „fehlende Einwilligung“), die zur Modellierzeit bekannt sind und deren Auf-

treten zur Laufzeit zum Scheitern der Aktivitätenbearbeitung führt. Aufgabe des WF-

Modellierers ist es, für solche a priori bekannten Ausnahmefälle geeignete Behandlungs-

formen festzulegen. Als mögliche Reaktionen unterstützt ADEPT die Wiederholung der

Bearbeitung, die Ausführung alternativer Aktivitäten, das Überspringen der Aktivität,

das Rücksetzen der Bearbeitung oder den kontrollierten Abbruch des WF.

Zur Definition von Rücksetzoperationen können Fehlerkanten verwendet werden. Eine

Fehlerkante nfail → nbwd wird mit einem Fehlercode der Quellaktivität nfail verknüpft.

Priorisierungskanten mit

Priorität REGULAR

‚

Vorwärtssprung mit Nachholen (Sicht des Modellierers)a)

Transformation in Darstellung des ADEPT-Basismodellsb)

Njump

Nskip

••

Vorzuziehende Schritte

‚

AND-Split AND-JoinXOR-Split XOR-Join

Abb. 5: Umsetzung von Vorwärtssprüngen mit Nachholen

191

Schlägt die Ausführung von nfail fehl und wird der entsprechende Code gesetzt, so wird

die WF-Bearbeitung unterbrochen und vor den Knoten nbwd zurückgesetzt. Einige Bei-

spiele zeigt Abb. 6. Die Fehlerkante I→H beschreibt einen Rücksetzoperation innerhalb

eines Parallelzweiges, und die Kante K→F definiert einen Rücksprung in einen paralle-

len Teilzweig hinein. Einen Sonderfall beschreibt die Kante B→Start, bei deren Aus-

führung der WF vollständig rückgesetzt und abgebrochen wird.

Start

End

Fehlerkante

Fehlerkante Fehlerkante

ec1

XOR-Split XOR-Join/

AND-Split AND-Join

Abb. 6: Modellierung von Rücksprüngen durch Fehlerkanten

4.2 Automatische Fehlerrücksprünge

Automatische Fehlerrücksprünge werden mithilfe der vorgestellten Fehlercodes und

-kanten modelliert. Bei ihrer Ausführung werden die Zustandsmarkierungen des WF-

Graphen zurückgesetzt, so dass anschließend mit der Kontrolle am Rücksprungknoten

fortgefahren werden kann. Des weiteren werden für abgeschlossene bzw. laufende Akti-

vitäten des Rücksetzbereichs interne Effekte (z.B. Schreiboperationen auf Prozess-

variablen) zurückgenommen. Externe Auswirkungen (z.B. Änderungen von An-

wendungsdaten) können durch die Ausführung von Kompensationsprogrammen rück-

gängig gemacht werden. ADEPT orientiert sich dabei am Sagas-Konzept [El92]. Ein

Beispiel zeigt Abb. 7. Hier wird nach Fehlschlag der Aktivität K der Fehlercode ec1

gesetzt. Dies führt zur Signalisierung der Fehlerkante K → F, was einen Rücksprung in

den oberen Teilzweig der durch (D, J) definierten Parallelverzweigung bewirkt.

4.3 Benutzerinitiierte Fehlerrücksprünge

Für berechtigte Akteure muss es möglich sein, direkt in die Kontrolle der WF-Ausführ-

ung einzugreifen, indem sie den Ablauf unterbrechen und in einen früheren Bearbei-

tungszustand zurücksetzen. Solchen benutzerinitiierten Rücksprüngen liegen in der

Mehrzahl der Fälle exogene Ursachen zugrunde, so dass der genaue Kontext ihres Auf-

tretens a priori nicht oder nur ungefähr beschreibbar ist. Abhängig davon, ob eine Mo-

dellierung möglich ist oder nicht, unterscheiden wir zwischen planbaren Rücksprüngen

und Ad-hoc-Rücksprüngen. Letztere klammern wir hier aus (siehe [Re00]).

Beispiel 3 (Benutzerinitiierte Rücksprünge)

Wir beziehen uns auf Bsp. 1. Läßt der aktuelle Zustand des Patienten die Untersuchung nicht mehr

zu oder sollen zuvor getroffene Entscheidungen revidiert werden, muss der behandelnde Arzt die

Ablaufkontrolle zurückerlangen können, solange die Untersuchung noch nicht stattgefunden hat.

Dazu müssen ggf. laufende Tätigkeiten (z.B. Vorbereitungen des Patienten) unterbrochen oder

zuvor abgeschlossene Schritte (z.B. Festlegung des Untersuchungstermins) storniert werden.

192

RegainControl

nsRC

ndRC

Abb. 8: RegainControl

COMPLETED

ACTIVATED

TRUE_SIGNALED

FAILED

FEG

Fehlerkante

ec1

FEGec1

⇓Automatisches Rücksetzen

Fehlschlag von K mit

Fehlercode ec1 !

Historie des Datenelements d

vor dem Rücksprung

nodeId nodeIt value

F1 10

D1 13

⇓

Historie des Datenelements d

nach dem Rücksprung

nodeId nodeIt value

D1 13

b)a)

Aktivitäten- und Kantenzustände:

Schreibzugriff

Lesezugriff

Abb. 7: Partielles Zurücksetzen nach Neumarkierung einer Fehlerkante durch a) Anpassung von

Zustandsmarkierungen und b) Zurücknahme von Schreiboperationen auf Prozessvariablen

In ADEPT lassen sich Benutzerrücksprünge

mittels spezieller Rücksprungkanten (Regain-

Control) nsRC → ndRC modellieren: Ein Akteur

kann zwischen Beendigung von ndRC und Akti-

vierung des im Ablauf nachfolgenden Knotens

nsRC den WF in den Zustand vor Ausführung von

ndRC zurücksetzen. Abb. 8 zeigt die Sicht des

Modellierers. Der durch C → A beschriebene Be-

nutzerrücksprung ist wählbar, nachdem A beendet und bevor C aktiviert wird. Bei seiner

Selektion wird der WF in den Zustand vor Ausführung von A rückgesetzt.

4.4 Diskussion und Zusammenfassung

Auf Basis der vorgestellten Konzepte läßt sich ein breites Spektrum an Fehlerrücksprün-

gen modellieren. Allerdings ist es in der Praxis nicht immer möglich, alle Ausnahmen a

priori zu modellieren. Das gilt auch für den Fall, dass der WF zur Laufzeit strukturell

abgeändert wird und das Ziel des Rücksprungs eine Aktivität darstellt, die erst dyna-

misch während der WF-Ausführung eingefügt worden ist [Re00]. Aber selbst wenn diese

Fälle nicht auftreten, ist eine Modellierung nicht immer möglich. Beispielsweise sind

Rücksprünge in Teilzweige einer bedingten Verzweigung auf Modellebene nicht fest-

legbar, da a priori nicht bekannt ist, welcher Teilzweig zur Laufzeit ausgeführt wird. Aus

diesen Gründen können berechtigte Akteure in ADEPT auch Ad-hoc-Rücksprünge im

Ablauf vollziehen. Dazu kann der Benutzer aus einer Liste bereits beendeter oder lau-

fender Arbeitsschritte einen Rücksprungknoten auswählen, vor dessen Ausführung der

WF rückgesetzt werden soll. Details hierzu finden sich in [Re00].

193

5 Verwandte Arbeiten

Ein verbreiteter Formalismus zur WF-Modellierung sind Petri-Netze [Ob96]. Sie gehen

oftmals davon aus, dass alle Ausnahmen bereits zur Modellierzeit bekannt sind [Ob92].

In der Mehrzahl der Fälle werden jedoch keine speziellen Modellierungskonzepte ange-

boten. Statt dessen müssen Ausnahmen mit denselben Sprachmitteln beschrieben werden

wie Standardabläufe, was zu schwer verständlichen und unübersichtlichen Netzen führt

[EKR95]. Neuere Entwicklungen greifen diese Kritikpunkte auf und bieten flexiblere

Konzepte, etwa für das späte Modellieren von Subnetzen [HA97], die dynamische An-

passung von Netzmarkierungen [AM98], den Ad-hoc-Wechsel zwischen Netzkonfigu-

rationen [BO98, Aa99] oder die dynamische Änderung der Netzstruktur [EKR95].

Im HieraStates-Projekt [Te98] wurde eine WF-Metamodell basierend auf State- und

Activitycharts entwickelt. Es gestattet additive Änderungen (z.B. Hinzunahme neuer

Zustände) zur Laufzeit. Darüber hinaus können planbare Vorwärtssprünge mit Hilfe

spezieller Transitionen modelliert werden, die in verschiedenen Zuständen des Statechart

aktivierbar sind. Rücksprünge und Rücksetzoperationen sind nicht modellierbar.

Im WfMS-Umfeld gibt es mehrere Arbeitsgruppen, die sich mit planbaren und nicht

planbaren Abweichungen beschäftigen (z.B. [CFM99, EKR95, EL98, Jo99, We98]).

MOKASSIN [Jo99] bietet dem Modellierer ein erweiterbares WF-Metamodell, mit dem

spezielle Konstrukte für die Behandlung von Ausnahmen definiert werden können. In

Obligations [Bo95] ergibt sich ein WF-Ausführungsgraph durch die Überlagerung mehr-

erer Prozess-Schablonen, die unterschiedliche Sichten des Ablaufs widerspiegeln. Eine

Ausnahmebehandlung kann hier durch die Hinzunahme bzw. das Entfernen von

Schablonen erfolgen. Ansätze wie AgentWork [MR99] erlauben es, Ausnahmen auf

einer separaten Ebene durch einen Menge von Regeln zu beschreiben.

Eine detaillierte Diskussion dieser und weiterer Ansätze zur Behandlung von Ausnah-

men in WfMS findet sich in [Re00]. Von ADEPT aufgegriffene, in obigen Ansätzen

nicht behandelte Fragestellungen betreffen den Erhalt der Konsistenz von Zustandsmar-

kierungen bei Sprüngen, die Modellierung planbarer Sprünge, die korrekte Behandlung

von Sprüngen in Verbindung mit Verzweigungen und Schleifen sowie die Unterstützung

von Sprüngen unterschiedlicher Semantik (z.B. Vorwärtssprünge mit/ohne Nachholen,

Schleifen-/Fehlerrücksprünge, automatische/spontane Sprünge).

6 Zusammenfassung

In diesem Beitrag haben wir Konzepte zur Modellierung planbarer Abweichungen in

WfMS vorgestellt. Der Modellierer kann solche Abweichungen in einer abstrakten und

verständlichen Notation formulieren. Durch ihre Übersetzung in einen begrenzten Satz

einfacher Modellelemente erzielen wir eine effiziente und korrekte Ausführbarkeit. Des

weiteren resultiert aus der getrennten Beschreibung von Standardablauf und Ausnahmen

eine verbesserte Strukturierung der Modelle. Wir haben gezeigt, wie sich durch die Mo-

dellierung von Abweichungen ein flexibles Ausführungsverhalten erzielen läßt. Berech-

tigte Akteure können in die WF-Kontrolle eingreifen, indem sie zukünftige Arbeits-

schritte vorzeitig ausführen oder den WF in frühere Bearbeitungszustände zurücksetzen.

194

Auch automatische Rücksprünge sind modellierbar. Die vorgestellten Konzepte bilden

einen wichtigen Beitrag zur Erhöhung der A-priori-Flexibilität in WfMS und lassen sich

prinzipiell auch auf andere WF-Beschreibungsformalismen anwenden.

Literaturverzeichnis

[Aa99]

W. van der Aalst: Generic Workflow Models: How to Handle Dynamic Change and

Capture Management Information? Proc. CoopIS’99, Edinburgh, 1999, S. 115–126

[AM98]

A. Agostini, G. de Michelis: Simple Workflow Models. Proc. Workshop on Work

flow

Management, Lissabon, 1998, S. 146–163

[Bo95] D. Bogia: Supporting Flexible, Extensible Task Descriptions In and Among Tasks. Dis-

sertation, University of Urbana, Illinois, 1995

[BO98]

E. Badouel, J. Oliver: Reconfigurable Nets, a Class of High Level Petri Nets Sup

port

ing

Dynamic Changes. Workshop Workflow Management, Lissabon, 1998, S. 129–145

[CFM99]

F. Casati, M. Fugini, I. Mirbel: An Environment for Designing Exceptions in Workflows.

Information Systems, 24(3):255-73, 1999

[DRK00] P. Dadam, M. Reichert, K. Kuhn: Clinical Workflows - The Killer Application for Pro-

cess-oriented Information Systems? Proc. BIS‘2000, Posen, 2000, S. 36–59

[EKR95]

C.A. Ellis, K. Keddara, G. Rozenberg: Dynamic Change within Workflow Systems. Proc.

Conf. Org. Computing Systems, Milpitas, S. 10–21, 1995

[El92]

A.K. Elmargarmid (Hrsg.): Database Transaction Models for Advanced Applications.

Morgan Kaufmann Publ., 1992

[EL98]

J. Eder, W. Liebhart: Contributions to Exception Handling in Workflow-Management.

Proc. EDBT-Workshop on Worklfow Management Systems, Valencia, 1998, S. 3-10

[Ha97] J. Hagemeyer, T. Hermann, K. Just-Hahn, R. Striemer: Flexibilität bei Workflow-

Management-Systemen. Proc. Software-Ergonomie'97, Dresden, 1997, S. 179–190

[Jo99] G. Joeris: Defining Flexible Workflow Execution Behaviors. Proc. Workshop on Enter-

prise-wide and Cross-Enterprise Workflow-Mgmt., Paderborn, 1999, S. 49–55

[LR00] F. Leymann, D. Roller: Production Workflow. Prentice Hall, 2000.

[MR99]

R. Müller, E. Rahm: Rule-Based Dynamic Modification of Workflows in a Medical

Domain. Proc. BTW '99, Freiburg, 1999, S. 429-448

[Ob92] A. Oberweis: Spezifikation von Mechanismen zur Ausnahmebehandlung mit Petri-Net-

zen. Automatisierungstechnik - at, 40(1):21-30, 1992

[Ob96]

A. Oberweis: Modellierung und Ausführung von Workflows mit Petri-Netzen, Teubner,

1996

[RD98] M. Reichert, P. Dadam: ADEPTflex – Supporting Dynamic Changes of Workflows With-

out Losing Control. Journal of Intelligent Information Systems, 10(2):93-129, 1998

[Re00] M. Reichert: Dynamische Ablaufänderungen in Workflow-Management-Systemen. Dis-

sertation, Universität Ulm, Mai 2000

[SM95]

D. Strong, S. Miller: Exceptions and Exception Handling in Computerized Information

Processes, ACM ToIS, 13(2):206-33, 1995

[Te98]

G. Teege: Flexible Workflows: Mitgestaltung durch die Ausführenden. Proc. Workshop

Flexibilität und Kooperation in Workflow-Management-Systemen, 1998, S. 13–21.

[We98]

M. Weske: Flexible Modeling and Execution of Workflow Activities. Proc. 31

Hawaii

Int'l Conf. on System Sciences, Software Technology Track, 1998, S. 713–722