Work�owevolution

Michael Schwipps

14. Februar 2006

Inhaltsverzeichnis

Inhaltsverzeichnis

1 Einleitung 4

2 Work�owmodelle 62.1 Flussdiagrammbasiertes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Petrinetzbasiertes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Änderungsstrategien und Evolutionsansätze 103.1 Klassi�zierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Work�ow Modi�cation Language . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Vererbung in Work�ows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 Minimaler Repräsentant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Abbildung von Schemaevolution in standardisierten WfM-Sprachen 194.1 Business Process Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Web Services Business Process Execution Language . . . . . . . . . . . . . . . . 204.3 Business Process Modeling Notation . . . . . . . . . . . . . . . . . . . . . . . . 204.4 XML Process De�nition Language . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 Yet Another Work�ow Language (YAWL) . . . . . . . . . . . . . . . . . . . . . 21

5 Schemaevolution in WfMS 22

6 Zusammenfassung 25

2

Abbildungsverzeichnis

Abbildungsverzeichnis

1 Flusssymbole: Aktivität, totale Verzweigung, bedingte Verzweigung, Start-/Stopsymbol,iterative Vereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 erstes PC-Bau-WF-Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 PC-Bau mit YAWL-symbolen (siehe Abbildung 9) . . . . . . . . . . . . . . . . 94 Änderungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 geändertes PC-Bau-WF-Schema. geänderte Tasks sind farbig hinterlegt. . . . . 136 Work�owde�nitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Klassenmodell für das Konzept des minimalen Repräsentanten . . . . . . . . . . 178 Symbole in Vererbungsdiagrammen . . . . . . . . . . . . . . . . . . . . . . . . . 189 YAWL-Symbole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2310 YAWL-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3

1 Einleitung

1 Einleitung

Diese Arbeit beschäftigt sich im Rahmen des Seminars �Schema Evolution� mit dem Themader Work�owevolution. Das Seminar wird von der Abteilung Datenbanken am Institut fürInformatik an der Universität Leipzig organisiert.

Die Work�ow Management Coalition [19] de�niert einen Work�ow wie folgt: �The automa-tion of a business process, in whole or part, during which documents, information or tasks arepassed from one participant to another for action, according to a set of procedural rules.� [13]Der Arbeitsablauf(engl.: Work�ow) konzentriert sich auf den reinen Ablauf der Aktivitäten.Die Ausführung der Aktivitäten(engl.: Tasks) bleibt auÿen vor, d.h. das die Aktivitäten durchden Work�ow veranlasst werden, aber deren Abarbeitung selbst nicht durch den Work�owbeschrieben wird. Das ursprüngliche Interesse an Work�ows und ihrer computerunterstütztenAusführung kam vor allem aus Unternehmen. Forschung und Entwicklung �ndet deshalb auchin den Wirtschaftswissenschaften statt. Zur Stärkung ihrer Wettbewerbsposition fordern Un-ternehmen, dass die Arbeitsabläufe e�zient sind. E�ziente Arbeitsabläufe werden allerdingsauch in anderen Bereichen(z.B. Behörden) erwartet. Die De�nition der E�zienz, insbesonderederen wirtschaftliche Konsequenzen und alle weiteren betriebswirtschaftlichen Zusammenhän-ge werden hier nicht betrachtet. Die Begri�e Arbeitsablauf, Prozess und Work�ow werden imFolgenden synonym verwendet. In Abbildung 2 ist ein Beispiel für einen Work�ow zu sehen.Dieser spezi�ziert den Bau eines PCs.Ähnlich wie bei Datenbanken wird zwischen dem Schema und den Instanzen unterschieden.Das Schema de�niert die statischen Aspekte eines Work�ows. Es wird in der Literatur auchals Work�owtyp bezeichnet und beschreibt den Work�ow. Das Schema enthält die Metadaten.Die Instanzen bilden die ausgeführten Prozesse. Instanzen werden auch als Fälle bezeichnet.Sie laufen nach einem Schema ab. Work�ows bzw. Schemata können hierarchisch aufgebautsein, d.h. eine Aktivität eines übergeordneten Work�ows startet einen Subprozess.

Für die automatisierte Steuerung der Arbeitsabläufe werden so genannte Work�ow-Manage-ment-Systeme(WfMS) eingesetzt. Weitere Einsatzgebiete der WfMS sind die computerunter-stützte Analyse, Planung, Dokumentation und Auswertung von Prozessen. WfMS unterstützenstrukturierte Prozesse. Im Gegensatz dazu geben Groupware-Systeme die Möglichkeit unstruk-turierte Prozesse zu bearbeiten. Die auszuführenden Aktivitäten sind in der Regel nicht Teildes WfMS. Die Systeme entkoppeln den Daten�uss der Applikation und den Kontroll�uss derProzesse. Sie ermöglichen auch das Einbinden von nicht rechnergestützten Aktivitäten undstellen ein Verbindungsglied zwischen den den einzelnen Aktivitäten zugeordneten Applika-tionen dar. Auf die Implementierung von WfMS bzw. die technische Umsetzung der Evolutionwird in dieser Arbeit nicht bzw. nur am Rande eingegangen.Folgenden Erwartungen werden (laut [11]) mit dem Einsatz von WfMS verknüpft.

� höhere Qualität der Verarbeitung Die höhere Qualität der Verarbeitung entsteht durchdas maschinelle Starten von Aktivitäten und die von persönlichen Präferenzen unab-hängigen Entscheidungen. Es können weder Aufgaben vergessen werden, noch werdenunnötige Aktivitäten durch das WfMS gestartet.

� schnelleres Bereitstellen benötigter Informationen Im Gegensatz zur physischen Vertei-lung von Dokumenten(z.B. Briefen) ist die Übermittlung von bearbeiteten Dokumenten

4

1 Einleitung

mittels WfMS deutlich schneller möglich, da sie sofort dem nächsten Mitarbeiter zuVerfügung steht, wenn der vorherigen Mitarbeiter seine Aktivität beendet hat.

� schnellere Abwicklung von Vorgängen, höherer Durchsatz Diese Erwartungen sind eineKonsequenz aus der vorhergenannten schnelleren Bereitstellung von Informationen.

� besserer Kunden-Service WfMS bieten beispielsweise die Möglichkeit dem Kunden denaktuellen Bearbeitungsstatus eines Auftrags mitzuteilen. Bei Paketzustellern ist diesinzwischen üblich.

� erhöhte Produktivität, reduzierte Ausführungskosten Die erhöhte Produktivität ergibtsich aus den geringe Wartezeiten für das Bereitstellen von Informationen. Die eingesetz-ten Ressourcen und Mitarbeiter werden besser ausgelastet.

� bessere Überprüfbarkeit von Abläufen Da sämtliche Work�ows durch das WfMS gestartetund überwacht werden, kann auch protokolliert werden, wann die einzelnen Aufgabenerledigt wurden.

� bessere Integration der Infrastruktur / vorhandener Datenbanken Im Gegensatz zu nichtcomputerunterstützten Arbeitsabläufen, ist es dem WfMS möglich, auf vorhanden Da-tenbanken elektronisch zuzugreifen.

� besseres Verständnis des Produktionsprozesses Dieser Punkt ergibt sich zwangsweise ausder Notwendigkeit einen Arbeitsablauf im WfMS zu de�nieren. Schlecht motiviertenÄnderungen des Arbeitsablauf steht der Aufwand entgegen diese demWfMS mitzuteilen.

� Flexibilität hinsichtlich Umstellung / Anpassung der Abläufe an geänderte AnforderungenDie De�nition von Work�ows in WfMS ist arbeitsaufwendig und verursacht dementspre-chend Kosten im Unternehmen. Von dem WfMS wird eine möglichst einfache Anpassungder Prozesse erwartet.

Dem stehen folgende Befürchtungen und Probleme gegenüber

� Kontrolle und Überwachung der Mitarbeiter Sie kann zu einer schlecht motivierten Be-legschaft führen. Mögliche Konsequenzen sind zunächst das Umgehen des WfMS undanschlieÿend ein Verlust an Produktivität.

� Funktionsde�zite Sie können beispielsweise dann auftreten, wenn Schnittstellen zu ex-ternen Systemen fehlen oder nicht alle denkbaren bzw. umzusetzenden Kontroll�üssedurch das WfMS unterstützt werden.

� unzureichende Flexibilität Sie ist dann gegeben, wenn die Erwartungen an die Flexibilitätnicht erfüllt werden können.

� Umstellungs- und Integrationsprobleme Sie entstehen beispielsweise durch fehlende Schnitt-stellen auf bestehende Systeme. Diese sind unabhängig davon, ob die Schnittstellen aufSeiten des WfMS oder des externen Systems nicht existieren. Fehlende Schnittstellen füh-ren dazu, dass die Systeme nicht miteinander interagieren können. Umstellungsproblemetreten nur bei Einführung des WfMS auf. Integrationsprobleme bestehen dauerhaft.

5

2 Work�owmodelle

In einer sich schnell ändernden Umwelt ist die Anpassung und Änderung von Geschäftspro-zessen für Unternehmen zunehmend von Bedeutung. Lassen sich die Abläufe in den Verwal-tungssystemen nicht schnell genug an die Erfordernisse anpassen, zwingen sie die Anwenderdazu, die Systeme zu umgehen bzw. falsch zu nutzen. Derartige Aktionen untergraben dieZuverlässigkeit des Systems und machen beispielsweise die Überwachung von Aufgaben undderen statistische Auswertung unnötig schwierig wenn nicht gar unmöglich. Es ist also erfor-derlich zunächst zu untersuchen, in welchem Rahmen Anpassungen notwendig sind, inwieweitsie vermieden werden können und welche Stolpersteine zu beachten sind.Die Änderung eines Work�ows genauer dessen Schemas wird als Evolution bezeichnet. Gibtes Instanzen des Schemas, müssen diese in Abhängigkeit von der Änderungsstrategie ebenfallsangepasst werden. Die ökonomischen Zusammenhänge und Konsequenzen der Evolution wer-den im Rahmen dieser Arbeit nicht betrachtet.Exceptions bzw. Ausnahmen sind dazu gedacht unerwartete und unerwünschte Situationenabzufangen bzw. zu behandeln. Sie trennen die Prozess- von der Ausnahmebehandlungslogik,um so das Prozessdesign übersichtlicher und lesbarer zu gestalten. Exceptions können bei-spielsweise aus technischen Störungen, wie Strom- oder Netzwerkausfällen, oder menschlichenFehler resultieren. Auf Ausnahmen muss in der Regel sofort und im Einzelfall reagiert werden.Die Behandlung erfolgt entweder durch Weitergabe an einen übergeordneten Work�ow oderdurch spezielle Aktionen wie z.B. einem Neustart oder einem Rollback der Aktivität.Eine weitere Form der Änderung von Work�ows bilden die so genannten ad-hoc Work�ows.Die leider sprachlich schlecht von ad-hoc (momentane) Änderungen abgegrenzt sind. Ad-hocWork�ows geben dem Endanwender die Möglichkeit im Bedarfsfall ein Work�owschema zude�nieren und zu instantiieren. In der Praxis war das Erfordernis dieser Möglichkeit beimAufkommen von WfMS eine sehr verbreitete Meinung. Damals wurde zwischen strukturier-ten, semi-strukturierten und unstrukturierten Prozessen unterschieden. Beispielsweise lassensich kreative Prozesse nur schwer bis ins letzte Detail (vor-)strukturieren und damit durchein WfMS ausführen. Mit so genannten ad-hoc Work�ows sollte der Anwender in die Lageversetzt werden, diesem Umstand Rechnung zu tragen. Jedoch hat sich dieses Vorgehen nichtdurchgesetzt. Im späteren Verlauf folgten dann die bereits erwähnten Groupware Systeme,die diese Art von Prozessen unterstützen. Wenn hier im Folgenden von ad-hoc Änderungengesprochen wird, ist die momentane Änderung eines Work�owschemas gemeint. Eine Ad-hocÄnderung betri�t ein konkretes Work�owschema, für das eine Instanz erzeugt wird. Genaufür diese Instanz erfolgt dann eine Änderung. Für andere gleichzeitig laufende Instanzen oderzukünftige Instanzen spielt die Änderung keine Rolle. Im Unterschied zu Exceptions werdenhier erwartete Einzelfälle (z.B. Sonderanfertigungen eines Produkts) eingeordnet.

Diese Arbeit setzt sich zum Ziel auf die Grundlagen zweier theoretischer Work�owmodelleeinzugehen, die Möglichkeiten der Work�owevolution zu klassi�zieren, deren Rahmenbedin-gung zu spezi�zieren und Ansätze der Evolution in Standard und WfMS-Implementierungenzu beleuchten. Nach dem in Abschnitt 2 ein Vergleich verschiedener De�nitionsansätze erfolgt,geht es in Kapitel 3 mit der Beschreibung der Änderungsmöglichkeiten weiter.

2 Work�owmodelle

In diesem Abschnitt sollen einzelne Ansätze zur Work�owmodellierung verglichen werden.Aufgrund dieser unterschiedlichen Ansätze unterscheiden sich dann auch die Änderungs- bzw.

6

2 Work�owmodelle

Abbildung 1: Flusssymbole: Aktivität, totale Verzweigung, bedingte Verzweigung, Start-/Stopsymbol, iterative Vereinigung

Evolutionsmöglichkeiten.Allen Ansätzen ist gemein, dass die auszuführenden Aktivitäten als atomar angesehen werden.

2.1 Flussdiagrammbasiertes Modell

Der im folgenden betrachtete Ansatz (nach Casati [5]) orientiert sich an Flussdiagrammen.Es liegt sowohl eine formale De�nition als auch eine graphische Notation für die einzelnenElemente vor.Im folgenden soll kurz die graphische Notation der Elemente des Diagramms (siehe Abbildung1) beschrieben werden.

� Aktivitäten werden als Rechteck dargestellt.

� Konnektoren sind nur für Verzweigung(fork) oder Vereinigung(join) de�niert.

� Start- und Endeknoten haben ein spezielles Symbol

Verzweigungen haben genau einen Vorgänger und mehr als einen Nachfolger. Es gibt be-dingte (conditional) und unbedingte (total) Verzweigungen. Bei der bedingten Verzweigungwerden nur diejenigen Nachfolger aktiviert, deren Bedingung erfüllt ist. Sie werden als Rautedargestellt. Bei der unbedingten Verzweigung werden alle Nachfolger aktiviert. Ihre Darstel-lung erfolgt als Kreis. Verzweigungen können den Beginn einer parallelen Abarbeitung vonAktivitäten markieren.Vereinigungen haben einen Nachfolger und mehr als einen Vorgänger. De�niert sind iterati-ve und totale(gesamte/gemeinsame) Vereinigungen. Bei einer iterativen Vereinigung wird derNachfolger bei jeder Beendigung eines Vorgängers aktiviert. Sie wird graphisch als gefüllterKreis dargestellt. Bei einer totalen Vereinigung wird gewartet, bis alle Vorgänger beendet sind.Anschlieÿend wir der Nachfolger aktiviert. Ihre Darstellung erfolgt als leerer Kreis. Totale Ver-einigungen synchronisieren Parallelverarbeitung.

Als anschaulicher Beispiel diene hier Abbildung 2. Zyklen bzw. Schleifen und damit dasmehrfache Ausführen von Aktivitäten sind möglich. Neben der graphischen Notation gibt es,wie bereits angedeutet, eine formale De�nition eines Work�ows. Ein Work�ow W , wird alsQuadrupel ΣW =< TasksW , V arsW , σW , ςW > beschrieben. TaskW ist die Menge der Ak-tivitäten von W und V arsW ist die Menge der Variablen von W . Die Nachfolgerfunktion σverbindet jede Aktivität t aus TasksW mit einer Menge von Aktivitäten aus W . Die Bedin-gungsfunktion ς ordnet jedem Task aus W eine Bedingung zu. Die beiden Funktionen σ undς de�nieren die Flussstruktur (engl.: Routing). Verkürzt dargestellt bedeutet dies, dass nachBeendigung einer Aktivität t mittels σ alle Nachfolgeaktivitäten ermittelt werden. Für jedeNachfolgeaktivität p wird nun mittels der Bedingungsfunktion ς(p) geprüft, ob p ausgeführtwerden soll.Die Funktionen σ und ς müssen einige Bedingungen erfüllen, damit der Work�ow syntaktischkorrekt ist. Work�ows gelten unter folgenden Voraussetzung als korrekt:

7

2 Work�owmodelle

Plug VideoRAM

Hard DriveAdd 1.6 GB

1.44 MBInsert FDD

MotherboardPlug

ControllerInsert Disk

Insert CPU

MotherboardPrepare

Get Cabinet

BestCD4xInsert CD−ROM

Abbildung 2: erstes PC-Bau-WF-Schema

� transitive Hülle der Nachfolgerfunktion: Die transitive Hülle der Nachfolgerfunktion σ∗

wird wie folgt de�niert: σ∗(t) = {p : (p ∈ σ(t)) ∨ (∃s : s ∈ σ(t) ∧ p ∈ σ(s))}

� Erreichbarkeit Sie fordert das jede Aktivität t ausgehend vom Startknoten erreichbarist. t ∈ σ∗(′start′)

� Vorgängerfunktion Die Vorgängerfunktion de�niert für einen Task s die Menge der Tasksπ(s) die s als Nachfolger haben. π(s) = {t : s ∈ σ(t)}

Ein Work�owschema ist korrekt, genau dann wenn alle Aktivitäten der Flussstruktur er-reichbar sind. Als Konsequenz aus der Erreichbarkeit ergibt sich, dass ein Pfad existiert, derden Start- mit dem Endeknoten verbindet.

2.2 Petrinetzbasiertes Modell

In [1, 2, 3] bauen Work�ows auf Petrinetzen auf. Dazu wird ein eigenes WF-Netz de�niert.WF-Netze sind annotierte, stark verbunden Stellen-/Transitionsnetze. Sie sind korrekt, genau

8

2 Work�owmodelle

Insert Disk Controller

Insert CPU

Prepare Motherboard

Plug Video RAM

Add 1.6 GB Hard Drive

Insert CD_Rom BestCD 4x

Insert FDD 1.44 MB

Plug Motherboard

Get Cabinet

Container=Minitower

Container=Tower

Abbildung 3: PC-Bau mit YAWL-symbolen (siehe Abbildung 9)

dann wenn sie sicher sind, korrekt beendet werden und keine toten Transitionen haben. Füreine vollständigere Entwicklung von WF-Netzen aus Petrinetzen sei auf [1] verwiesen.Verschiedene Aspekte eines Geschäftsprozesses werden als Perspektiven bzw. Sichten be-

zeichnet. Es werden folgenden Sichten unterschieden.

1. Prozesssicht In dieser Perspektive erfolgt die De�nition des Work�owschemas.

2. Organisationssicht In dieser Sicht werden die Organisationsstruktur und die Beteiligtenfestgelegt. Es werden die Beziehung zwischen Rollen, Gruppen und anderen organisato-rischen Aspekten (z.B. Verantwortlichkeiten und Verfügbarkeiten) beschrieben. Rollensind aufgrund funktionaler Aspekte klassi�zierte Ressourcen. Gruppen sind Ressourcen,die auf Basis organisatorischer Aspekte klassi�ziert werden. Die Ressourcen reichen da-bei von beteiligten Menschen (z.B. Mitarbeitern) bis zu eingesetzten Geräten. Auf sie

9

3 Änderungsstrategien und Evolutionsansätze

wird nur über die de�nierten Gruppen und Rollen zugegri�en.

3. Informationssicht In der Informationsperspektive dreht sich alles um die Steuer(engl.:control)- und Produktionsdaten. Steuerdaten werden zu Work�owmanagementzweckenbenötigt, z.B. für Entscheidungen bei Verzweigungen. Produktionsdaten (z.B. Dokumen-te oder Formulare) werden in den Aktivitäten benötigt und haben keinen Ein�uss aufdas Routing.

4. Operationssicht Diese Sicht beschreibt die elementaren Operationen, die durch Ressour-cen und Applikationen ausgeführt werden. In der Prozesssicht werden diese Operationentypischerweise zum Erstellen, Lesen und Ändern der Steuer- und Produktionsdaten inder Informationssicht genutzt. Die meisten Operationen werden durch Anwendungspro-gramme implementiert.

5. Integrationssicht Die Integrationssicht verbindet die anderen vier Sichten. Die Aktivitä-ten und Work�owprozessde�nitionen der Prozesssicht werden mit den Rollen, Gruppenund Ressourcen der Organisationssicht verbunden. Auÿerdem werden die Daten der In-formationssicht und die Operationen der Operationssicht integriert.

Durch den Ansatz der Perspektiven ändert sich auch der Katalog der durch Änderungenam Work�ow auftretenden Fehler. Die grundsätzliche Unterscheidung zwischen semantischenund syntaktischen Fehlern bleibt allerdings bestehen. Hinzu kommt beispielsweise die Di�e-renzierung von transienten und permanenten sowie single- und multi-perspektiven Fehlern.Transiente Fehler sind Fehler, die ausschlieÿlich in transformierten Instanzen eines Work�owsauftreten und deren Ursache in einer unsachgemäÿem Transformation begründet liegt. Per-manente Fehler sind demgegenüber Fehler, die unabhängig von der Transformation auftreten.Singleperspektive Fehler treten nur in einer Perspektive auf. Multiperspektive Fehler betre�enmehrer Perspektive.

3 Änderungsstrategien und Evolutionsansätze

Wie bereits in der Einleitung (Abschnitt 1) erwähnt, gibt es unterschiedliche Ursachen dieeine Anpassung von Arbeitsabläufen erforderlich machen. In diesem Abschnitt sollen zunächstdie Änderungsstrategien klassi�ziert werden. Anschlieÿend wird dann auf zwei Ansätze zurEvolution eingegangen.

3.1 Klassi�zierung

Änderungsstrategien lassen sich, wie in Abbildung 4 zu sehen, in unterschiedliche Klasse ein-teilen. Die einfachen Lösungen lassen sich wie folgt weiter aufteilen.

� Abort bezeichnet ein Vorgehen, bei dem alle laufenden Work�owinstanzen abgebrochenwerden. Die bisher erfolgten Arbeitsschritte und erstellten Produkte werden dadurchwertlos. Das auch als �fordward recovery� bezeichnete Verfahren ist das einzige, bei demdas WfMS nicht mehrere Versionen kennen muss. Es ist also aus technischer Sicht keineVersionierung erforderlich.

� Flush fordert, das zunächst alle Work�owinstanzen, die nach dem bestehenden Schemaangefangen wurden, auch nach diesem Schema beendet werden müssen. Während dessen

10

3 Änderungsstrategien und Evolutionsansätze

einfache Strategien

Änderungsstrategien

fortgeschritten Strategien

parallel Versionen Evolutionim enger Sinne

AbortForward Recovery Flush Backward recovery

Detour

VererbungWorkflow ModificationLanguage

Repräsentantminimaler

Transfer

Abbildung 4: Änderungsstrategien

dürfen keine neuen Instanzen gestartet werden. Erst wenn alle Instanzen abgearbeitetsind, werden neue Instanzen nach neuem Schema gebildet.

� Backward recovery bezeichnet ein Verfahren, bei dem zunächst die bereits erfolgten Ar-beitsschritte rückabgewickelt werden. Anschlieÿend werden die Instanzen nach dem neu-en Schema erneut ausgeführt.

Die genannten Varianten sind aber oft nicht möglich. So können beispielsweise gesetzlicheÄnderungen eine (im Verhältnis zur Work�owlaufzeit) sofortige Änderungen erfordern. DerAbbruch eines Prozesses ist in der Regel mit dem Verlust von Arbeitsergebnissen verbunden.Eine Rückabwicklung (engl.: rollback) ist gerade bei physischen Aktivitäten häu�g nicht mög-lich bzw. unter ökonomischen Gesichtspunkten nicht sinnvoll.

Als fortgeschrittene Strategie lassen sich folgende Verfahren kategorisieren.

� Parallele Versionen treten dann auf, wenn es zulässig ist neue Work�owinstanzen nachneuem Schema zu starten, während bestehende Instanzen noch nach dem alten Schemaarbeiten.

� Transfer bezeichnet die Möglichkeit bestehende Instanzen (eines alten Schemas) in einneues Schema zu überführen.

� Detour ist für eine Sonderbehandlung von Fällen gedacht, die zwar nach einem neuenSchema abgearbeitet werden sollten, aber nicht überführt werden können. Das Verfahrenführt neben dem alten und dem neuen Schema noch mindestens ein weiteres Schema ein,nach dem dann eine Menge von Instanzen abgearbeitet wird.

11

3 Änderungsstrategien und Evolutionsansätze

Die Klassi�zierung ist nicht eindeutig, so spricht Dadam in [6] nur von Work�owevolution,wenn laufende Prozesse geändert werden. Der in Abbildung 4 aufgeführte Punkt �minimalerRepräsentant� beschreibt ein Verfahren, wie der Transfer auf Vererbungsbasis e�zienter de�-niert werden kann.

In [5] wird zwischen statischer und dynamischer Work�owevolution unterschieden.Die statische Work�owevolution bezieht sich auf die Work�owde�nition, das heiÿt auf Ände-rungen am Schema. Das Entwurfswerkzeug muss Möglichkeiten zur Verfeinerung von Work-�ows bieten. Darüber hinaus sollte es sicherstellen, dass die Entwürfe syntaktisch korrektsind.Die dynamische Work�owevolution bezieht sich auf die Änderung der Schemata laufenderWork�owinstanzen. Da nur Detour und Transfer Prozessinstanzen ändern, sind die dynami-sche Work�owevolution aus [5] und der Work�owevolutionsbegri� aus [6] identisch.Aalst unterscheidet darüber hinaus zwischen momentanen (zeitweisen/ad-hoc) Änderungen

und dauerhaften. Bei momentanen Änderungen soll nur eine Instanz des Prozesses geändertwerden. Bei dauerhaften Änderungen werden mindestens alle neue Instanzen eine Work�owsnach dem neuen Schema abgearbeitet. So kann beispielsweise nur für einen Kunden eine Son-deranfertigung eines Produkts erstellt werden. Der generelle Prozess bleibt davon aber unbe-rührt. Diese Klassi�kation ist unabhängig von der in Abbildung 4 aufgezeigten.

3.2 Work�ow Modi�cation Language

In [5] wird eine Work�ow Modi�cation Language (WFML) de�niert. Sie dient dazu, Än-derungen von Work�owschemata zu beschreiben. Es wird eine (möglichst kleine) Menge anPrimitiven de�niert, die Modi�kationen eines Work�ows erlauben und dabei die Korrektheitsowohl für das Schema als auch für die Instanzen eines Work�ows erhält. Bei diesem An-satz werden Konzepte aus der Analyse der Schemaevolution objektorientierter Datenbankenwiederverwendet, da es sich nach Angabe der Autoren um ein ähnliches Problem handeltund deshalb die Lösung ebenfalls ähnlich sein sollte. Die Konsistenz wird in Struktur- undVerhaltenskonsistenz unterschieden. Bei der Strukturkonsistenz geht es um die statische Ei-genschaften des Schema. Das geänderte Schema muss syntaktisch korrekt sein, das heiÿt esdarf keine compile-time-errors enthalten. Bei der Verhaltenskonsistenz geht es um die Anpas-sung der laufenden Instanzen des Schemas. Sie fordert, dass die Anwendung (eines Primitivesder WFML) auf einen Work�ow diesen von einem Zustand in einen neuen legalen Zustandüberführt. Ein Zustand ist legal, genau dann wenn die Ausführung ohne Laufzeitfehler fort-gesetzt werden kann.Sowohl die Verhaltens- als auch die Strukturkonsistenz werden durch alle Primitiven garan-tiert. Dadurch ist die Konsistenz auch für die Anwendung einer Sequenz von Primitiven gege-ben. Casatis WFML teilt die Primitive wie folgt auf

� Deklarationsprimitive ändern die Deklaration der Work�owvariablen und -aktivitäten.AddVar(VarName v, DefaultValue d) fügt Variablen hinzu und ändert ihren Standard-wert. RemoveVar(VarName v) entfernt Variablen. Variablen verschwinden implizit, wennsie aufgrund der Flussstruktur nicht mehr benötigt werden. AddTask(Task t) fügt Akti-vitäten hinzu.

� Flussprimitive ändern die Flussstruktur des Schemas. Sie modi�zieren beispielsweise die

12

3 Änderungsstrategien und Evolutionsansätze

Container=Tower

Containter=Minitower

Get Cabinet

MotherboardPrepare

Insert CPU

ControllerInsert Disk

MotherboardPlug

Insert FDD1.44 MB

Hard DriveAdd 1.6 GB

RAMPlug Video

Insert AudioCardNiceLabs

NiceLabs 4xInsert CD−ROM

Abbildung 5: geändertes PC-Bau-WF-Schema. geänderte Tasks sind farbig hinterlegt.

Reihenfolge in der die einzelnen Aktivitäten abgearbeitet werden. AddSuccessor(Task t,Task s) fügt der Aktivität t den Nachfolger s hinzu. RemoveSuccessor(Task t, Task s)entfernt den Nachfolger s aus der Menge der Nachfolger von Tasks t. ModifyConditi-on(Condition c, Task t) ändert die Startbedingungen der Aktivität t.

Die Modi�kation in Abbildung 5 werden durch folgende Anweisungen erreicht:AddSuccessor(Insert_Cd-rom_BestCd_4x, Insert_Cd-rom_NiceLabs_4x)AddSuccessor(Insert_Cd-rom_NiceLabs_4x, Insert_AudioCars_NiceLabs)RemoveSuccessor(Insert_FDD_1.44_MB, Insert_Cd-rom_BestCd_4x)

Die einzelnen Anweisungen einer WFML-Sequenz müssen atomar und in der gegebene Rei-henfolge ausgeführt.Die Modi�kation des Schemas kann auch für aktive Prozesse durchgeführt werden. Läuft ge-

13

3 Änderungsstrategien und Evolutionsansätze

rade eine Aktivität, wird die Änderung des Schemas für diese Instanz nach Beendigung derAktivität umgesetzt. Die nächste Aktivität wird entsprechend dem geänderten Schema aus-geführt. O�ensichtlich führt das für RemoveSuccessor(Insert_FDD_1.44_MB, Insert_Cd-rom_BestCd_4x) genau dann zu einem Problem, wenn diese Aktivität gerade ausgeführtwird. In dem diesem Fall muss die Entscheidung, ob der Task beendet oder rückgängig ge-macht wird, durch den Anwender getro�en werden.Die Änderung des Work�ows für den Bau des Rechners wird nur dann garantiert wirksam,wenn Insert_FDD_1.44_MB, Insert_Cd-rom_BestCd_4x noch nicht erfolgt. Für den Fall,dass es während der Migration erfolgt, kann wegen der Anwenderentscheidung keine generel-le Aussage getro�en werden. Danach spielt die Migration o�ensichtlich keine Rolle mehr. Eswird deshalb der Begri� der �compliance�, d.h. der Erfüllung eines Work�owschemas de�niert.Dazu wird ein (initiales) Ausgangsschema ΣW.I und ein (�nales) Zielschema ΣW.I benötigt.

Satz 3.2.1. ComplianceEine Instanz C des Schemas W.I erfüllt das Schema W.F , genau dann wenn∀tn, tn ∈ CompletedW.I

C , gilt η(τ(ΣW.I), τ(SW.IC (tn)), tn) = η(ΣW.I , SW.I

C (tn), tn).

Die dabei genutzten Symbol bedeuten folgendes:

� CompletedWC bezeichnet die Menge der beendeten Aktivitäten der Instanz C.

� SWC (tn) ist der Status von C nach Beendigung von tn

� η(ΣW , SWC (tn), tn) beschreibt den Prozess der Ausführung von C.

� τ beschreibt die Anwendung eine WFML-Primitive.

Würde die Migration erst nach Beendigung von Insert_FDD_1.44_MB, Insert_Cd-rom_-BestCd_4x versucht, entspricht C nicht dem Schema W.F . In diesem Fall wird von einerbedingten Migration gesprochen, Um C dennoch nach W.F zu migrieren sind andere Modi�-kationen nötig (z.B. Rollback), die auÿerhalb der Möglichkeiten der WFML liegen. Im Falleder Erfüllung von W.F durch C wird von unbedingter Migration gesprochen.Die Work�ow Modi�cation Language zeichnet sich dadurch aus, dass sie alle vorstellbarenArbeitsabläufe de�nieren kann. So lässt sich aus einem Nullwork�ow, einem Work�ow ohneElemente, jeder andere Work�ow erstellen. Eher nachteilig ist, dass bei der Migration Nut-zerentscheidungen erforderlich sind. Die �compliance� kann allerdings maschinell festgestelltwerden und so Verstösse durch Nutzerentscheidungen gegen sie aufdecken. Dadurch kann derAnwender auf Fehler seinerseits hingewiesen.

3.3 Vererbung in Work�ows

In [1, 2] unterscheidet man zunächst zwischen �Flexibilität durch Kon�guration� (�exibilityby con�guration) und �Flexibilität durch Adaption� (�exibility by adaption). Ziel der Arbeitensind vor allem die Reduzierung �echter� Änderungen, die einfache Verwaltung mehrerer Ver-sionen bzw. Varianten und die Fehlervermeidung.

Bei der �Flexibilität durch Kon�guration�(FdK) handelt es sich nicht um eine Evolution inSinne dieser Arbeit, da deren Hauptziel die Vermeidung von Änderungen ist. FdK erreichtsein Ziel durch eine Erweiterung der Möglichkeiten zur De�nition der Flussstruktur. So wirdbeispielsweise die Unterstützung ein Funktion SEQUENCE(<Menge von Aktivitäten>) zur

14

3 Änderungsstrategien und Evolutionsansätze

Erweiterung der De�nitionsmöglichkeiten von Work�ows vorschlagen.In bisherigen Systeme ist der Work�owmodellierer immer gezwungen eine explizite Reihen-folge innerhalb einer Sequenz festzulegen, auch dann wenn dies sachlich nicht geboten ist.SEQUENCE(A,B,C) ermöglicht es nun festzulegen, dass die Tasks A, B und C sequentiellauszuführen sind, legt aber deren Reihenfolge nicht fest. Stellt man später fest, dass es docheine sinnvolle Reihenfolge gibt, ist man nicht mehr gezwungen eine bestehende Reihenfolgezu ändern, sondern löst lediglich die SEQUENCE(A,B,C) auf. Auf die Grenzen dieses Verfah-rens wird hier nicht weiter eingegangen. Die Autoren weisen darauf hin, dass sich nicht allemöglichen Anpassungen durch dieses Verfahren abfangen lassen.

Bei �Flexibilität durch Adaption� emp�ehlt Aalst ein Vererbungskonzept. Dazu wurden dieaus der objektorientierten Programmierung bekannten Methoden auf Work�ows übertragen.Für die Informations- und die Operationssicht ist die Übertragung recht einfach. Klassenentsprechen den Work�owschemata und Objekte den Fällen bzw. Instanzen. Das klassischeVererbungsschema reduziert sich allerdings auf den statischen Aspekt. Nur Klassen könnenVererbungsbeziehungen aufbauen. Ein Objekt kann seine Klasse nicht wechseln. Es behält sievom Instantiieren bis zum Terminieren.Es wird seitens der Autoren bemerkt, dass die Vererbung dynamischen Verhaltens auf dereinen Seite nicht gut verstanden ist, auf der anderen Seite aber den wesentlichen Teil derProzesssicht und des Prozessmanagements ausmacht.Es werden vier Vererbungsbegri�e unterschieden. Im Folgenden sei x grundsätzlich Unterklas-se von y. Von Protokollvererbung spricht man, wenn bei Ausführung aller Aktivitäten aus x,die auch in y vorkommen, es nicht möglich ist, das Verhalten von x und y zu unterscheiden. Siefasst alle neuen Tasks zusammen und vergleicht deren sichtbares Verhalten. Die Routingmus-ter der Superklassen bleibt auch in den Unterklassen erhalten. Protokollvererbung �blockiert�die neuen Aktivitäten.Von Projektionsvererbung wird gesprochen, wenn bei Ausführung beliebiger Tasks aus xnur die E�ekte der Tasks beachtet werden, die auch in y vorkommen. Projektionsvererbungversteckt die neuen Aktivitäten. Die Routingmuster der Superklasse bleiben erhalten. Dabeide Vererbungsbegri�e orthogonal sind, führen die Autoren noch den Begri� der Proto-koll/Projektionsvererbung ein. Von Life-Cycle-Vererbung wird gesprochen, wenn durch dasBlockieren einiger neuer Aktivitäten in x und das Verstecken aller anderen neuen Aktivitätendas Verhalten von x und y nicht mehr unterscheidbar ist. Sie ist die allgemeinste Form derVererbung. Die Vererbungsbegri�e klassi�zieren Mengen von Work�ows.In Abbildung 6 sei N0 die Ausgangs- bzw Superklasse. N0 ist unter folgenden Vererbungs-

begri�en Superklasse:

� N1 - Protokoll- und Projektionsvererbung Da sich N1 wie N0 verhält, wenn man Dblockiert(Protokollvererbung). Ignoriert man nur die Ergebnisse von D, verhält es sichebenfalls wie N0(Projektionsvererbung).

� N2 - Protokollvererbung Da sich N2 wie N0 verhält wenn man D blockiert, handelt essich um Protokollvererbung. Lässt man D zu, verhält es sich anders wie N0. Projekti-onsvererbung ist dementsprechend nicht gegeben.

� N3 - Projektionsvererbung Es kann sich bei N3 nicht um Protokollvererbung handeln,da N3 nicht ausgeführt werden kann, wenn D geblockt wird. Wenn die Ergebnisse von D

15

3 Änderungsstrategien und Evolutionsansätze

B

A

C

B

A

C

N0

B

A

C

B

A

C

D

N4

B

A

C

B

A

C

D

N3

B

A

C

B

A

C

D

N2

B

A

C

B

A

C

D

N1

Abbildung 6: Work�owde�nitionen

lediglich ignoriert werden, kann N3 vollständig ausgeführt werden. Es verhält sich dannwie N0 unter Projektionsvererbung.

� N4 - Projektionsvererbung Die Begründung ist hier analog zu N3. Beim Blockieren vonD kann N4 nicht beendet werden.

Auÿerdem stehen N1 bis N4 in einer Life-Cycle-Vererbungsrelation zu N0.

Die Konzepte hinter den Vererbungsbegri�en machen lediglich eine Aussage über die Bezie-hung der Schemata zueinander. Sie haben keine konstruierenden Funktion.Deshalb werden auf Basis der verschiedenen Vererbungsbegri�e die folgenden Transformati-onsregeln de�niert.

� Die Transformationsregel PT erhält die Protokoll und life-cycle-Vererbung. PT erweitertdie Superklasse um neue Alternativen. In der erzeugten Unterklasse gibt es alternativeRouten mit neuen Aktivitäten.

� Die Transformationsregel PP bewahrt alle 4 Vererbungsformen. PP fügt neue Aktivitä-ten hinzu, die nur das Verhalten aufschieben.

� Die Transformationsregel PJ erhält die Projektionsvererbung und life-cycle-Vererbung.PJ fügt neue Task zwischen bestehende ein. Die eingefügten Aktivitäten können einfacherNatur sein oder zusammengesetzt, d.h. vollständige Unterwork�ows, sein.

� Die Transformationsregel PJ3 erhält wie PJ die Projektionsvererbung und die life-cycle-Vererbung und fügt parallel Verhalten hinzu.

16

3 Änderungsstrategien und Evolutionsansätze

1..*

1

processnode

routingelement

concreteprocess

genericprocess

tasknon−atomicconcrete process

case instantiation

1..*

*

* *

**

*

*11

1

1

1

*

{disjoint,complete}

{disjoint,complete}

{key}

is_child_of

min_rep_of

inst_ofinst_by

is_instance_of

has

contains

connects

Abbildung 7: Klassenmodell für das Konzept des minimalen Repräsentanten

Die Transformationsregeln passen zu oft benutzten Designkonstrukten. Es handelt sich umdie Auswahl, die sequentielle Komposition und die parallele Komposition. Unter Beachtungder Regeln ist Vererbung garantiert. Auÿerdem kann jeder Work�ow ohne Laufzeitprobleme(wie z.B. Deadlock oder unnötige mehrfaches Ausführung) konvertiert werden. Die Vererbungbeschränkt die Änderung und eignet sich für momentane und evolutionäre Änderungen. Sieist geeignet, um Erweiterungen vorzunehmen und vermeidet transiente Fehler. Gerade wegender Möglichkeit Fehler in geänderten Work�ows zu machen, bevorzugt Aalst grundsätzlich�Flexibilität durch Kon�guration�.

3.4 Minimaler Repräsentant

Wie bereits dargestellt, besteht das Hauptproblem der Evolution in der Transformation lau-fender Prozesse von einem in ein anderes Schema. Dazu wird in [3] der Begri� des minimalenRepräsentanten eingeführt. Der Aufsatz abstrahiert von der reine Evolution von Prozessenund sucht nach Gemeinsamkeiten. Durch diesen Ansatz können auch Informationen für dieFührung eines Unternehmens aus den unterschiedlichen Prozessen zusammengefasst werden.Wie in Abbildung 7 zu sehen, können Prozessknoten entweder ein konkreter oder ein ge-

nerischer Prozess sein. Über die generischen Prozesse lässt sich eine beliebig tiefe Kette vonProzessknoten bauen. An deren Ende und nur da be�ndet sich ein konkreter Prozess. Dieserkonkrete Prozess stellt den minimalen Repräsentanten aller generischer Prozesse der Kette dar.Ein generischer Prozess kann beliebig viele Kinder haben. Dies ermöglicht den Aufbau vonProzesshierarchien. Konkrete Prozess sind ihrerseits entweder Aktivitäten oder nicht-atomarebzw. zusammengesetzte Prozesse. Die zusammengesetzten Prozess bilden dann die Grundlage

17

3 Änderungsstrategien und Evolutionsansätze

tasks non−atomicconcrete processes

genericprocesses

children

parentminimalrepresentative

constraintC

Abbildung 8: Symbole in Vererbungsdiagrammen

für die Fälle. Die Fälle sind zugleich Instanzen der generischen Prozesse. Generische Prozesselassen sich nicht instantiieren. Für die einzelnen Elemente gelten Beschränkungen, auf die hiernicht weiter im Detail eingegangen werden soll. Dazu gehört zum Beispiel, dass die Beziehun-gen zwischen den generischen Prozessen azyklische sein müssen.Routingelement wie Verzweigung und Vereinigung stehen etwas abseits. Sie sind zwar Teilkonkreter Prozesse, aber nicht hierarchisch gliederbar.Das Klassendiagramm zeigt 3 Arten von Informationen.

1. Routinginformationen beschreiben nicht-atomare konkrete Prozesse. Sie spezi�zieren,welche Aktivitäten, nicht-atomare konkrete Prozesse und generische Prozesse genutztwerden und in welcher Reihenfolge dies geschieht.

2. Vererbungsinformationen beschreiben die Beziehungen zwischen generischen Prozessenund seinen Kindern. Sie legen mögliche Instantiierungen generischer Prozesse durch kon-krete Prozesse fest und betre�en neben den beiden Prozessarten auch Prozessknoten, dieis_child_of und die min_rep_of Beziehung.

3. dynamische Informationen umfassen die Ausführung der Fälle und die Instantiierungder generischen Prozesse durch konkrete Prozesse. Sie involviert die is_instance_of -,die has-, die inst_by und die inst_of -Beziehung.

Die letzten beiden Informationsarten unterscheiden sich durch die beschriebenen Beziehungen.Zur Darstellung der Idee des minimalen Repräsentanten werden zwei Diagrammarten de-

�niert. Das Routingdiagramm de�niert für nicht-atomare konkrete Prozesse das Routing derFälle entlang der Prozessknoten. Auÿerdem werden generische Prozesse in diesen Diagramm-typ eingegliedert.Abbildung 8 zeigt ein Vererbungsdiagramm. Die Wurzel eines solchen Diagramms ist ein ge-nerischer Prozess, der als parent bezeichnet wird. Alle anderen Knoten sind dementsprechendKinder. Jeder nicht-atomare konkrete Prozess referenziert auf ein Routingdiagramm. Jedergenerische Kind-Prozess referenziert wiederum auf ein Vererbungsdiagramm. Jeder generischeProzesse hat, wie bereits geschrieben, einen minimalen Repräsentanten. Diese Beziehung wirdim Diagramm durch eine durchgezogene Linie markiert. Alle anderen Beziehungen werden

18

4 Abbildung von Schemaevolution in standardisierten WfM-Sprachen

durch gestrichelte Linien dargestellt. Der minimalen Repräsentant kann als Superklasse imobjektorientierten Sinne betrachtet werden. Es entstehen Prozessfamilien.Die wesentlich Idee des Konzept ist, dass der Wechsel nur zwischen Kindern eines generischen

Prozesses also Mitgliedern der selben Prozessfamilie erfolgt. Das reduziert die Möglichkeitenmöglicher Transformationen und verbessert so deren Handhabbarkeit. Würde man Trans-formationen von n Mitgliedern einer Prozessfamilie direkt auf jedes andere Familienmitgliedde�nieren, erhielte man n(n−1) Mappings. An dieser Stelle kommt nun der minimalen Reprä-sentant zum Tragen. Jede Transformation erfolgt nun über diesen Repräsentanten. Dadurchmüssen nur noch 2(n−1) Mappings von den Familienmitgliedern zum minimalen Repräsentan-ten de�niert werden. Kommt ein neues Mitglied hinzu, müssen nun nur noch zwei Mappingsde�niert werden � vom neuen Mitglied auf den minimalen Repräsentanten und umgekehrt.Die Idee hat allerdings auch Nachteile. Die Möglichkeiten der Transformation hängen von

den Möglichkeiten des minimalen Repräsentanten ab Informationen aufzunehmen. Sind diesesehr beschränkt, sind auch die Transformationsmöglichkeiten entsprechend eingeengt. NeueProbleme können zu neuen minimalen Repräsentanten führen und zu entsprechendem Auf-wand bezüglich der Mappinginformationen.Die Transformation zum minimalen Repräsentanten hin wird durch eine Generalisierungs-

funktion de�niert. Der umgekehrte Weg wird durch eine Spezialisierungsfunktion festgelegt.Alle Kinder haben einen Zustandsraum. Die Generalisierungsfunktion ist partiell und de�niertfür einige Zustände eines Kinds einen Übergang zum minimalen Repräsentanten. Diese Zu-stände werden als � jump states� bezeichnet. Alle anderen Zustände werden als �wait states�(Wartezustände) bezeichnet. Der Übergang hin zum minimalen Repräsentanten ist nur in den� jump states� möglich. Be�ndet sich ein Fall in einem �wait state�, wird die Transformation so-lange aufgeschoben bis ein � jump state� erreicht ist. Für diese Zeit wird der Fall entsprechenddem alten Schema abgearbeitet.Abschlieÿend sei noch gesagt, dass dieses Konzept zum Zeitpunkt des Erscheinens von [3]

in keinem Produkt verwirklicht ist.

4 Abbildung von Schemaevolution in standardisiertenWfM-Sprachen

Nachdem im letzten Abschnitt einige theoretische Ansätze zu Schemaevolution vorgestellt wur-den, soll in diesem Abschnitt auf mögliche Umsetzungen der Ideen und Vorschläge eingegangenwerden. Es werden Standards betrachtet, insbesondere formalen Sprachen und Austauschfor-mate und deren Möglichkeiten Work�owevolution zu unterstützen. Standards bilden ihrerseitshäu�g eine Grundlage für die Modelle in Produkten und Werkzeugen, die im nachfolgendeAbschnitt behandelt werden. Es soll die praktische Seite der Work�owevolution betrachtetwerden.Prozesse lassen sich blockstrukturiert und auf Basis von gerichteten Graphen de�nieren.

Während gerichtete Graphen sich eher mit graphischer Notation verbinden lassen und be-triebswirtschaftlich ausgebildeten Personen eher entgegen kommen, be�nden sich blockstruk-turierte Sprachen näher an den üblichen imperativen Programmiersprachen. Blockstrukturier-te Sprachen lassen sich relativ leicht in graphorientierte Sprachen umwandeln. Die umgekehrteRichtung ist schwieriger. Graphische Anwendungsprogramme, die eine blockorientierte Spra-che (z.B. BPML) als Zielformat haben, schränken deshalb die Möglichkeiten der Kanten desGraphen ein.

19

4 Abbildung von Schemaevolution in standardisierten WfM-Sprachen

4.1 Business Process Modeling Language

BPML ist eine Metasprache zur Beschreibung von Geschäftsprozessmodellen. Man kann siesich als blockorientierte Programmiersprache vorstellen. Rekursive Blockstrukturen spieleneine wesentliche Rolle bei der De�nition und Ausführung der Prozesse. Sie steuern den Ablauf(engl.: Routing). BPML ist als Implementierungssprache konzipiert. Es unterstützt rekursivebzw. hierarchische Prozessde�nitionen.Die Business Process Modeling Language konzentriert sich auf die De�nition von Webservices.Dies drückt sich durch folgende Punkte aus.

� Spezi�sche Aktivitätstypen für Nachrichtenaustausch, Event-behandlung, Ausgleich (com-pensation (in case of failure)) und Verzögerung.

� Attribute zur Unterstützung von Instanzkorrelation, zum Extrahieren von Nachrichten-teilen und zum lokalisieren bzw. orten von Serviceinstanzen

� Unterstützung von Transaktionen, Nutzung von Blockstrukturkontext, Ausnahmebe-handlung

4.2 Web Services Business Process Execution Language

An der Web Services Business Process Execution Language(WS-BPEL), vorher als BPEL4WSbekannt, wird innerhalb der OASIS zur Zeit an der Version 2.0 gearbeitet. WS-BPEL ist eineformale Sprache zur Spezi�kation von Geschäftsprozessen und �business interaction proto-cols�. Es ist spezialisiert auf den Austausch von Daten und Dokumenten über Webservicesund unterstützt so primär B2B-Transaktionen. Sie ist eine Untermenge von BPML und fürden allgemeinen Einsatz als Business Process Execution Language eher weniger geeignet. ZurVersionierung von Geschäftsprozessen äuÿert sich der Standard überhaupt nicht. BPEL4WSist im Jahr 2002 von IBM und Microsoft entwickelt worden. Die ihrerseits vorher die SprachenWSFL (IBM) und XLANG (Microsoft) propagierten.BPEL ist eine blockstrukturierte Programmiersprache, die den rekursiven Aufruf von Blöckenermöglicht. Die De�nition und Deklaration geschieht aber nur auf der Ebene der Prozesse undist dementsprechend nicht rekursiv. Dies ist vergleichbar mit der Möglichkeit, Funktionen nurin einer Ebene (wie z.B. in C) de�nieren zu können. Innerhalb eines Blocks werden graphba-sierte Konzepte zur Flussde�nition unterstützt. Diese sind auf azyklische Graphen beschränkt.Sie erlauben also keine Schleifen. BPEL unterstützt keine Unterprozesse.BPEL baut auf anderen Webtechnologien auf, wie z.B. WSDL 1.1, XML Schema 1.0, XPath1.0, und WS Addressing. In den BPEL-Dokumenten wird der Prozessablauf beschrieben. Erbezieht sich dabei auf in WSDL-Dateien beschriebene Webservices. WSDL-dateien beschrei-ben die Struktur der Nachrichten(Datencontainer), Operation und Porttypen. Sie binden auchdie Porttypen an ein festgelegtes Protokoll (z.B. SOAP). Diese Bindungen sind ihrerseits mitspeziellen URIs verbunden, die den Webservice anbieten.

4.3 Business Process Modeling Notation

Business Process Modeling Notation(BPMN) [18] ist ein Standard der Object ManagementGroup. Das Hauptziel besteht in der graphischen Notation von Geschäftsprozessen mittelsBusiness Process Diagram (BPD). Es soll die Kommunikation zwischen Anwendern und Ent-wicklern erleichtern und so die Lücke zwischen Prozessdesign und deren Implementierung

20

4 Abbildung von Schemaevolution in standardisierten WfM-Sprachen

schlieÿen.Dadurch soll eine schnellere Implementierung von Geschäftsprozessen erreicht werden. Ausorganisatorische Sicht wird dadurch die Änderungen von Prozessen unterstützt. Diagrammekönnen mit einem Versionsattribut versehen werden.Der Standard enthält ein Kapitel zur Abbildung von BPMN auf BPEL. Auf der Homepagedes Standards [18] ist ein Vergleich mit UML 2.0 Activity Charts zu �nden.

4.4 XML Process De�nition Language

Die XML Process De�nition Language(XPDL) [16] wurde durch die Work�ow ManagementCoalition verabschiedet. Die Sprache ist, wie der Name bereits sagt, xml-basiert und dient demAustausch von Geschäftsprozessde�nitionen. Sie ist als Dateiformat konzipiert und stellt einherstellerunabhängiges Austauschformat dar. Die Sprache enthält die Möglichkeit die Paket-und Prozessde�nitionen mit einem Versionsattribut zu versehen. Pakete sind eine Menge vonProzessen. Die aktuelle Version 2 wurde um Elemente erweitert, die den Austausch von BPMN-Modellen zu unterstützen.Sie ist eine graphorientierte Sprache, unterstützt aber auch Blöcke. Verschachtelte Prozessesind nicht möglich. Das Routing wird durch Übergänge (Transitionen) gesteuert. Diese Über-gänge können mit Bedingungen versehen werden und bilden die Kanten des Graphen. DieAktivitäten sind Knoten des gerichteten Graphen.XPDL legt sein Hauptaugenmerk auf die Verteilung der Arbeit.

� Es de�niert durch Aktivitätsattribute die Resourcen, die zur Ausführung benötigt wer-den. Bestimmt wird dies durch einen Ausdruck, der zur Laufzeit ausgewertet wird.

� Aktivitätsattribute spezi�zieren die Applikation, welche zur Ausführung der Aktivitätbenötigt werden.

� Beide genannten Punkt unterstützen die Notation der Ressourcen in Verbindung mitder Anwendungssoftware zur Ausführung der Aktivitäten.

4.5 Yet Another Work�ow Language (YAWL)

YAWL [4] wurde durch Professor Aalst und seine Mitarbeiter an der Universität Eindhovenentwickelt, stammt also nicht von einem Standardisierungsgremium. Es basiert auf einer Ana-lyse der bestehende Work�owmanagementsysteme und -standards und nutzt eine reichhaltigeMenge an Work�owmustern. In Tabelle 1 ist eine Übersicht [20] zu sehen, die die Unterstüt-zung einzelner Work�owmuster durch verschiedene Standards beschreibt. Die Analyse zeigte,dass sowohl die Standards (zum Zeitpunkt der Analyse) als auch die theoretischen Modellewie z.B. Petrinetze nur eingeschränkt nutzbar für die Darstellung der wesentlichen Mustersind.Es werden Petrinetze als Ausgangspunkt genutzt, um der Sprache ein sicheres theoretischesFundament zu geben. Das Fehlen einer derartigen Basis bei bestehenden Sprachen wie XPDLwird mit als Grund für die Entwicklung der YAWL genannt. Petrinetze bilden zwar den Aus-gangspunkt. Das Ergebnis der Nutzung von YAWL sind allerdings keine. Es handelt sich umTransitionssysteme.YAWL hat eine formale Semantik und bietet eine graphische Repräsentation bzw. Notation. InAbbildung 9 sind die Symbole aufgeführt. Die Autoren glauben, dass sich die Sprache wegen

21

5 Schemaevolution in WfMS

Muster StandardBPEL XLANG WSFL BPML WSCI

Sequence + + + + +Parallel Split + + + + +Synchronization + + + + +Exclusive Choice + + + + +Simple Merge + + + + +Multi Choice + - + - -Synchronizing Merge + - + - -Multi Merge - - - +/- +/-Discriminator - - - - -Arbitrary Cycles - - - - -Implicit Termination + - + + +MI without Synchronization + + + + +MI with a Priori Design Time Knowledge + + + + +MI with a Priori Runtime Knowledge - - - - -MI without a Priori Runtime Knowledge - - - - -Deferred Choice + + - + +Interleaved Parallel Routing +/- - - - -Milestone - - - - -Cancel Activity + + + + +Cancel Case + + + + +

Tabelle 1: Übersicht zu musterunterstützenden Standards

ihrer Ausdrucksstärke und ihrer formalen Semantik als Zwischensprache für die Übersetzunganderer Work�owsprachen anbietet.Bei YAWL besteht ein Work�ow aus einer Menge von Prozessen. Ein Prozess setzt sichaus Tasks zusammen. Diese werden in atomare und zusammengesetzte Task (engl.: composi-te tasks) unterteilt. Zusammengesetzte Tasks verweisen wiederum auf eine Prozessde�nition.Dadurch lässt sich eine hierarchische Struktur abbilden. Es gibt genau einen Wurzelprozess(top level process) innerhalb eines Work�ows. Auf diesen darf bzw. wird durch keinen zusam-mengesetzten Task verwiesen. Er bildet die Wurzel der hierarchischen Prozessde�nition. ImUnterschied zu Petrinetzen können sich in einem mittels YAWL de�nierten Work�ow mehrereTransitionen, d.h. Task hintereinander be�nden. Es müssen nicht immer Aus- und Eingangs-bedingungen de�niert werden.YAWL hat eine XML-Syntax. Es liegt ein Schema vor. Es wurde ein Prototyp für die Ausfüh-rung von Work�ows entwickelt. Auÿerdem ist ein Work�ow-Designer entwickelt worden. DieAbbildung 10 gibt einen kurzen Überblick über die Architektur den Systems. Die Werkzeugesind nicht noch einmal im Kapitel 5 aufgeführt.

5 Schemaevolution in WfMS

In diesem Abschnitt soll für einige ausgewählte Werkzeuge darüber Auskunft gegeben werden,inwieweit sie die Work�owevolution unterstützen.

22

5 Schemaevolution in WfMS

OutputCondition

Input Condition

Condition Atomic Task

Multiple Instanceof Atomic Task

Composite Task

Multiple Instanceof Composite Task

AND−join task

XOR−join task

OR−join taskOR−split task

XOR−split task

AND−split task

remove tokens

Abbildung 9: YAWL-Symbole

Fujitsu's Interstage Business Process Manager, vorher unter dem Namen I-Flow bekannt(davor als TeamWare Flow), basiert auf Java und ist eine kommerzielle Work�ow-engine. Esbietet Prozessmodi�kation zur Laufzeit der Prozesse durch das Hinzufügen von Unterpro-zessen. I-Flow enthält Internet Inter-ORB (IIOP) protokollbasierte Komponenten und kannexterne (Legacy) Software durch CORBA ansprechen.JBoss jBPM [22] bezeichnet sich als �exibles, erweiterbares Work�owmanagementsystem.

Es ist Open Source und java-basiert. Auÿerdem erhebt es den Anspruch das verbreitetsteSystem zu sein. In der aktuellen Version (3.0) unterstützt die Software die Versionierung vonWork�owde�nitionen. Neue Instanzen werden immer auf Basis der neuesten Version gebildet.Bestehende Instanzen können nicht auf eine neuere Version migriert werden. Sie laufen bis zumAbschluss in der Version in der sie gestartete wurden weiter. Es kann die ÄnderungsstrategieFlush genutzt werden.ActiveBPEL [21] ist eine Laufzeitumgebung zum Ausführen von Prozessen. Wie der Name

bereits andeutet, müssen diese in BPEL (siehe 4.2) de�niert sein. Hauptziel des Programm istdie vollständige Unterstützung des Standards.con:cern [23] ist eine Work�ow-engine, die nicht auf einer der Standardsprachen bzw. -

modelle aufbaut, sondern einen eigene Ansatz verfolgt. Ein Prozess ist als Menge von Aktivitätmit Vor- und Nachbedingungen de�niert. Eine Aktivität wird ausgeführt wenn die Vorbedin-gungen erfüllt sind, d.h. es erfolgt in Abweichung zu den üblichen Modellen keine expliziteFestlegung der Reihenfolge der Aktivität. Durch die Durchführung der Aktivität werden Nach-bedingungen erzeugt.Die Entwickler der Software glauben, das dieses Konzept bisherigen Ansätzen überlegen ist,wenn mindestens einer der folgenden Punkte zutri�t:

� komplexe Prozesse mit Ausnahmen und Spezialfällen

� Abhängigkeit der Aktivitätenreihenfolge von mehreren Faktoren

23

5 Schemaevolution in WfMS

Abbildung 10: YAWL-Architektur

� die Möglichkeit manuell in den Prozessablauf einzugreifen

� inhaltsbasierte Abhängigkeiten zwischen den Aktivitäten

� strenge/starke Anforderungen an Modularität und Flexibilität

� lose Prozesskopplung

con:cern erlaubt den direkten Eingri� in laufende Prozesse und das schrittweise Anpassender Prozesse an neue Erfordernisse. Damit verfügt die Software über eine der weitestgehenstenSchemaevolutionsmöglichkeiten. Inwieweit alle Vorbedingungen vom Anwender bereits vorher-gesehen werden können und Änderungen der Prozesse somit fehlerfrei möglich sind, wird hiernicht betrachtet. con:cern ist Open Source (LGPL) und läuft nach eigenen Angaben auf jedemJ2EE-kompatiblen Applikationsserver.Shark [24] ist ein erweiterbares Work�ow-engine-Framework, deren Implementierung auf

dem WfMC-Standard XPDL basiert. Die Verbindung zu den Aktivität, genauer deren Appli-kationen erfolgt über die WfMC �ToolAgents� API. Prozesse lassen sich über Enhydra JaWE,einen gra�schen XPDL-Editor entwerfen.

24

6 Zusammenfassung

WfMOpen [25] ist eine J2EE-basierte Implementierung eine Work�ow-engine auf Basis derStandards der Work�ow Management Coalition und der Object Management Group. AufBasis der OMG Work�ow Management Facility Speci�cation V1.2 wurde ein Interface entwi-ckelt, das auch den Anschluss von Diensten über CORBA an den Kern des WfMS ermöglicht.Work�ows werden mittels der (um einige Erweiterungen ergänzten) XML Process De�niti-on Language spezi�ziert. WfMOpen liefert Komponenten zur Ansteuerung von Webservicemittels SOAP.OpenWFE [26] ist ein Work�owmanagementsystem bestehend aus einer Work�ow-Engine,

einem webbasierten Prozessdesigner(Dro�o) und Komponenten zur Ansteuerung automati-scher Agenten(APRE). Automatischen Agent sind in diesem Zusammenhang Applikationen,die bei erreichen einer Aktivität automatisch durch das WfMS gestartet werden. Das Systemverfügt über die übliche Funktionalität laufende Prozesse zu Überwachen und den Nutzernihre Aufgabe mitzuteilen. Es steht unter einer BSD Lizenz und ist in Java implementiert,bietet aber Schnittstellen(REST) zu anderen Sprachen und Umgebung (C#, Python, Perl).Prozessde�nitionen werden durch eine eigene, erweiterbare, xml-basierte Sprache beschrieben.Die Dokumentation geht auf die Implementierung der von Prof. Aalst entwickelten Work-�owmuster [20] ein.

Leider muss festgestellt werden, dass die Unterstützung für eine vollständige Schemaevoluti-on bisher in keinem Tool gegeben ist. Zwar ist sind hier und da ein paar Ansätze zu erkennen,realisiert ist aber keines der Konzepte. Darüber hinaus ist festzustellen, dass wenn überhauptnur durch spezi�sche Erweiterungen der Standards Möglichkeiten zur Schemaevolution erö�-net werden.

6 Zusammenfassung

Diese Arbeit betrachtete verschiedene Ansätze zur De�nition von Work�ows und die darausentwickelten Möglichkeiten zur Work�owevolution. Auÿerdem wurden Standards verschiedenerGremien und einige Werkzeuge bezüglich ihrer Fähigkeiten zur Unterstützung der Evolutionuntersucht.Die Forschungsergebnisse zeigen, dass die Möglichkeiten der automatisierten Unterstützungvon Work�owevolution begrenzt sind. Die Grenze selbst ist allerdings noch nicht genau festge-legt. So überschreitet der Ansatz der Work�ow Modelling Language diese Grenze und erfordertdesöfteren Nutzereingri�e. Die Evolution auf Basis von Vererbung und die daraus abgeleitetenTransformationsregeln erfordern zwar keine direkten Nutzereingri�e, begrenzen aber die Mög-lichkeiten der Evolution. Bei den Standards und Werkzeugen kann das Fazit gezogen werden,dass noch einiges zu tun ist, bis die Möglichkeiten der bereits erforschten Evolutionsansätzeumgesetzt sind.

Literatur

[1] W.M.P. van der Aalst, T. Basten: Inheritance of work�ows: an approach to tacklingproblems related to change. Theoretical Computer Science, 2002

[2] W.M.P. van der Aalst, S. Jablonski: Dealing with work�ow change: Identi�cation of issuesand solutions. Int. J. Computer Syst., Science and Engineering 15(5), 267-276 (2000)

25

Literatur

[3] W.M.P. van der Aalst.: Generic Work�ow Models: How to Handle Dynamic Change andCapture Management Information? coopis, p. 115, Fourth IECIS International Conferenceon Cooperative Information Systems, 1999

[4] W.M.P. van der Aalst, L. Aldred, M. Dumas, A.H.M. ter Hofstedei :Design and imple-mentation of the YAWL system, http://is.tm.tue.nl/research/patterns/download/yawls_long_qutrep.pdf

[5] F. Casati, S. Ceri, B. Pernici, G. Pozzi: Work�ow evolution. Data and Knowledge Engi-neering 24(3), 211-238 (1998)

[6] S. Rinderle, P. Dadam: Schemaevolution in Work�ow-Management-Systemen. Informatik-Spektrum, Volume 26, Issue 1, Jan 2003, Pages 17 - 19

[7] S. Rinderle, M. Reichert, P. Dadam: E�ziente Verträglichkeitsprüfung und automatischeMigration von Work�ow-Instanzen bei der Evolution von Work�ow-Schemata. Informatik- Forschung und Entwicklung, Volume 17, Issue 4, Dec 2002, Pages 177 - 197

[8] M. Reichert, P. Dadam: ADEPT�ex - Supporting Dynamic Changes of Work�ows Wi-thout Losing Control. Journal of Intelligent Information Systems, Special Issue on Work-�ow Management Systems, 10(2):93-129, March / April 1998 http://www.informatik.

uni-ulm.de/dbis/01/staff/reichert/papers/journals/reda98c.pdf

[9] M. Kradolfer, A. Geppert: Dynamic Work�ow Schema Evolution based on Work�owType Versioning and Work�ow Migration. Proc. of the 4th International Conference onCooperative Information Systems, 1999

[10] R. Müller, E. Rahm: Dealing with Logical Failures for Collaborating Work�ows, Pro-ceedings of Fifth International Conference on Cooperative Information Systems (Coo-pIS), Eilat, Israel, Sep. 2000. Springer, Berlin, 2000: 210-223 http://lips.informatik.

uni-leipzig.de/pub/2000-40

[11] R. Müller, E. Rahm: Work�ow-Managment-System, Vorlesung Sommersemster 2003

[12] G. Vossen, J. Becker: Geschäftsprozeÿmodellierung und Work�ow-Management: Modell,Methoden, Werkzeuge, International Thomson Publishing 1996, ISBN 3-8266-0124-6

[13] Work�ow Management Coalition Terminology & Glossary, Februar 1999 http://www.

wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf

[14] BPML | BPEL4WS, A Convergence Path toward a Standard BPM Stack, August 2002,BPMI.org http://www.bpmi.org/downloads/BPML-BPEL4WS.pdf

[15] Work�ow & BPM Research http://www.workflow-research.de/Links/

[16] Work�ow Process De�nition Interface � XML Process De�nition Language, Version2.0, Document Number WFMC-TC-1025, Oct 2005 http://www.wfmc.org/standards/

docs/TC-1025_xpdl_2_2005-10-03.pdf

[17] R. Shapiro: A Comparison of XPDL and BPML and BPEL: Cape Visions, 2002 http:

//www.ebpml.org/A_Comparison_of_XPDL_and_BPML_BPEL.doc

26

Literatur

[18] Business Process Modeling Notation http://www.bpmn.org

[19] Work�ow Management Coalition http://www.wfmc.org

[20] Work�ow Patterns http://www.workflowpatterns.com

[21] ActiveBPEL http://www.activebpel.org

[22] JBoss jBPM http://www.jboss.com/products/jbpm

[23] con:cern http://con-cern.org/

[24] Enhydra Shark http://shark.objectweb.org/

[25] WfMOpen http://wfmopen.sourceforge.net

[26] OpenWFE http://web.openwfe.org/display/openwfe/Home

27