Entwicklung eines Workflow-Management-Systems basierend auf UML-Aktivitätsdiagrammen

Inhaltsverzeichnis

Ehrenwörtliche Erklärung

Kurzfassung

1 Einleitung
1.1 Workflow-Management-Systeme
1.2 UML-Aktivitätsdiagramme
1.3 Überblick
1.4 Verwandte Arbeiten

2 Workflow-Management-Systeme
2.1 Anforderungen an Workflow-Management-Systeme
2.2 Die Workflow Management Coalition (WfMC)
2.2.1 Hintergrund
2.2.2 Ergebnisse der WfMC
2.2.3 Das Workflow Reference Model
2.2.4 Das Process Definition Interchange Interface
2.2.5 Das Workflow Application Programming Interface (WAPI)
2.3 Existierende Systeme
2.3.1 Staffware Process Suite
2.3.2 COSA Workflow
2.3.3 Lotus Workflow 3.0
2.3.4 MQSeries Workflow

3 UML-Aktivitätsdiagramme und deren Verwendung für Workflow-Management- Systeme
3.1 Beschreibung des verwendeten Metamodells
3.1.1 Abstrakte Syntax
3.1.2 Einschränkungen der UML
3.2 Nicht verwendete Konstrukte und unklare Definitionen
3.2.1 Nicht verwendetete Konstrukte
3.2.2 Unklare Definitionen bezüglich Object Flow States
3.2.3 Der Begriff „well nested“
3.3 Semantik zur Ausführung von Aktivitätsdiagrammen
3.3.1 Der Event Manager
3.3.2 Der Router
3.3.3 Transitionen
3.3.4 Object Flow States
3.4 Ausführungsbeispiel
3.5 Vergleich mit dem Metamodell der WfMC

4 Das Workflow-Management-System FlowSys
4.1 Allgemeine Beschreibung der Funktionalitäten
4.2 Implementierte Funktionen des WAPI
4.2.1 WAPI Connect Functions
4.2.2 WAPI Process Control Functions
4.2.3 WAPI Activity Control Functions
4.2.4 WAPI Process Status Functions
4.2.5 WAPI Activity Status Functions
4.2.6 WAPI Worklist Functions
4.2.7 Zusätzlich implementierte Funktionen
4.3 Fallstudie
4.3.1 Beschreibung des Fallbeispiels
4.3.2 Anmeldung an der Workflow-Engine
4.3.3 Das zentrale Workflowfenster
4.3.4 Der Workflow-Editor
4.3.5 Die Workflow-Applikation

5 Design und Implementierung
5.1 Architektur
5.2 RMI (Remote Method Invocation)

6 Schlußbetrachtung
6.1 Zusammenfassung
6.2 Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Ehrenwörtliche Erklärung

Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.

Ich bin damit einverstanden, dass meine Arbeit veröffentlicht wird, insbesondere dass die Arbeit Dritten zur Einsichtnahme vorgelegt oder Kopien der Arbeit zur Weitergabe an Dritte angefertigt werden.

Abbildung in dieser Leseprobe nicht enthalten

Kurzfassung

Workflow-Management-Systeme müssen in folgenden drei Bereichen Unterstützung leisten: bei der Definition und Modellierung von Workflows und den dazugehörigen Aktivitäten, der Ausführung und Verwaltung der einzelnen Workflowinstanzen und der Interaktion mit Benutzern und externen Applikationen.

Es existieren mittlerweile viele kommerzielle Workflow-Management-Systeme, die unterschiedliche abstrakte Sprachen zur Modellierung von Workflows verwenden. Entscheidend bei der Wahl einer bestimmten Modellierungssprache sind deren Ausdrucksstärke und eine eindeutig definierte Semantik.

Das Ziel dieser Arbeit bestand darin, ein Workflow-Management-System zu entwer fen und zu implementieren, das als abstrakte Modellierungssprache UML Aktivitätsdiagramme verwendet. UML-Aktivitätsdiagramme werden zwar in der Theo rie schon länger untersucht, in kommerziellen Systemen finden sie aber bisher noch selten Verwendung. Dies liegt unter anderem daran, dass die UML-Spezifikation in Bezug auf die Semantik von Aktivitätsdiagrammen einige Unklarheiten aufweist.

Es wurde zunächst untersucht, welche Anforderungen an ein WorkflowManagement-System gestellt werden und welche Standards die Workflow Management Coalition für die Entwicklung vorschlägt. Für die Implementierung wurde ein Metamodell für UML-Aktivitätsdiagramme entworfen. Dieses entspricht weitestgehend dem Metamodell der UML-Spezifikation. Für die Ausführung musste anschließend eine eindeutige Semantik festgelegt werden, die vor allem für die Modellierung und Ausführung von Geschäftsprozessen geeignet ist.

Zuletzt wurde das entwickelte Workflow-Management-System mit dem Namen Flow Sys anhand eines konkreten Fallbeispiels getestet. Bei dem Fallbeispiel handelte es sich um einen möglichen Geschäftsprozess, der bei der Bearbeitung einer Kundenreklamation durchlaufen wird.

1 Einleitung

1.1 Workflow-Management-Systeme

Die Workflow Management Coalition (WfMC)²⁵, eine offene Gruppe mit Mitgliedern aus Industrie und Forschung, die Standards für die Beschreibung von WorkflowManagement-Systemen entwickelt, definiert den Begriff Workflow (oft auch als Geschäftsprozess, Prozess oder Arbeitsablauf bezeichnet) wie folgt:

„ The automation of a business process, in whole or part, during which docu ments, information or tasks are passed from one participant to another for ac tion, according to a set of procedural rules. “

Unter einem Workflow versteht man also einen alltäglichen Arbeitsablauf in einem Unternehmen, der nach bestimmten Regeln und mit einem bestimmten Ziel durchgeführt wird. Dabei werden Dokumente, Informationen oder Aufgaben zwischen den einzelnen Teilnehmern zur Bearbeitung weitergereicht.

Ein Workflow besteht üblicherweise aus mehreren logischen Schritten, die man als Aktivitäten bezeichnet. Eine Aktivität kann entweder manuell von einem Teilnehmer am Workflow durchgeführt werden oder automatisch durch eine Maschine bzw. ein System.

Da sich Workflows im Laufe der Zeit relativ häufig verändern, werden sie nicht unmit telbar durch ein Programm codiert, sondern in abstrakter Form beschrieben. Diese Workflowbeschreibungen (meist Workflowdefinitionen, oft aber ebenfalls Workflows genannt) sind leicht zu verändern und werden von einem Workflow-Management System interpretiert und ausgeführt. Neue Entwicklungen ermöglichen auch die Mo difikation während der Laufzeit. Für die abstrakte Beschreibung von Workflows wer den meist Sprachen verwendet, die eine intuitive graphische Notation besitzen und sich an Petrinetzen oder verwandten formalen Modellen orientieren.

Der Begriff Workflow-Management-System wird von der WfMC folgendermaßen defi niert:

"A system that completely defines, manages and executes workflow proc esses through the execution of software whose order of execution is driven by a computer representation of the workflow process logic."

Die Aufgabe eines Workflow-Management-Systems besteht darin, Workflowdefinitionen bzw. -beschreibungen zu interpretieren, die in den meisten Fällen mit einem externen Programm erstellt wurden. Es ermöglicht die Automatisierung eines Geschäftsprozesses, indem es die durchzuführenden Aktivitäten entsprechend der Workflowbeschreibung verwaltet.

Das Workflow-Management-System soll in den folgenden drei Bereichen Unterstützung leisten:

- Bei der Modellierung und Definition von Arbeitsabläufen und deren Aktivitäten.
- Bei der Verwaltung aller auszuführenden Instanzen von Workflowdefinitionen und der Steuerung der einzelnen Aktivitäten einer bestimmten Workflowinstanz.
- Bei der Interaktion mit Anwendern und externen Applikationen während der Aus führung einer Workflowinstanz.

1.2 UML-Aktivitätsdiagramme

UML-Aktivitätsdiagramme sind noch relativ neu und stellen eine Mischung verschie dener, bereits länger bekannter Darstellungsformen für die Modellierung von Prozes sen, dar. Sie basieren unter anderem auf Zustandsdiagrammen, Flussdiagrammen und Petrinetzen. Da Aktivitätsdiagramme noch nicht lange existieren, liegen auch noch keine umfangreichen Erfahrungen vor. Sie werden zwar in der Theorie schon länger untersucht, in der Praxis finden sie aber bisher noch selten Verwendung.

UML-Aktivitätsdiagramme beschreiben die Ablaufmöglichkeiten eines Systems oder Prozesses. Ein Aktivitätsdiagramm ist eine spezielle Form des Zustandsdiagramms, das überwiegend Aktivitäten enthält und zur Modellierung des Kontroll- und Objektflusses bei Prozessen verwendet wird. Aktivitäts- und Zustandsdiagramme besitzen viele gemeinsame Elemente auf der Ebene des Metamodells.

Eine Aktivität ist ein Zustand mit einer internen Aktion und einer oder mehreren ausgehenden Transitionen. Sie stellt einen einzelnen Schritt in einem Prozess bzw. Arbeitsablauf dar. Wenn eine ausgehende Transition nicht explizit durch ein Ereignis ausgelöst wird, dann wird sie, wie bei einem Zustandsdiagramm, durch die Beendigung der internen Aktion ausgelöst.

Aktivitäten lassen sich hierarchisch schachteln, das heisst eine Aktivität kann wiederum aus mehreren Unteraktivitäten bestehen, die durch ein eigenes Aktivitätsdiagramm dargestellt werden. Aktivitätsdiagramme ermöglichen auch die Modellierung von nebenläufigen Aktivitäten und Verzweigungen. Sie beinhalten das Konzept von Partitionen bzw. Verantwortlichkeitsbereichen, mit denen die Aktivitäten bestimmten Elementen oder Strukturen zugeordnet werden können. Im speziellen Fall der Geschäftsprozessmodellierung können mit Hilfe der Verantwortlichkeitsbereiche auch Organisationsstrukturen abgebildet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aktivitätsdiagramm Kundenreklamation

UML-Aktivitätsdiagramme sind somit geeignet zur organisatorischen Modellierung von Geschäftsprozessen bzw. Workflows. In diesem Kontext treten Ereignisse häufig innerhalb des Systems auf, ausgelöst zum Beispiel durch Überschreiten eines bestimmten Zeitlimits, aber auch außerhalb des Systems, ausgelöst durch ein externes Ereignis, wie zum Beispiel den Eingang einer Bestellung. Abbildung 1 zeigt ein Beispiel für ein typisches UML-Aktivitätsdiagramm. Es stellt den Geschäftsprozess nach Eingang einer Kundenreklamation dar.

1.3 Überblick

Die Aufgabe der Diplomarbeit bestand darin, ein Workflow-Management-System zu entwickeln, das als abstrakte Modellierungssprache UML-Aktivitätsdiagramme ver wendet. Aktivitätsdiagramme können, wie bereits weiter oben beschrieben, dazu verwendet werden, Arbeitsabläufe bzw. Geschäftsprozesse in den unterschiedlichs ten Bereichen eines Unternehmens oder einer Organisation zu modellieren. UML Aktivitätsdiagramme müssen also nicht nur modelliert und abgespeichert, sondern auch ausgeführt werden können. Die Ausführung sollte sich an einem Algorithmus, der von Rik Eshuis und Roel Wieringa an der Universität von Twente entworfen wur de⁸, orientieren. Dieser unterstützt allerdings keinen Objektfluss, in UML Aktivitätsdiagrammen dargestellt durch so genannte Object Flow States. Da die UML-Spezifikation bezüglich der Semantik von Object Flow States einige Unklarhei ten aufweist, bestand eine Teilaufgabe der Diplomarbeit darin, zu analysieren, wel che Semantik den Object Flow States zugeordnet werden kann. Diese sollte dann auch in der Implementierung des Systems umgesetzt werden.

Die Architektur des Workflow-Management-Systems, genannt FlowSys, orientiert sich an den von der Workflow Management Coalition (WfMC)²⁵ entworfenen Standards. Eine weitere Aufgabe bestand darin, diese Standards vorzustellen und anschließend zu analysieren, in wie weit diese Standards von dem implementierten System eingehalten werden bzw. in ihm abgebildet werden können.

Das gesamte Workflow-Management-System ist so aufgebaut, dass die Workflow- Engine, die für die Ausführung der Aktivitätsdiagramme zuständig ist, unabhängig auf einem Serverrechner laufen kann. Externe Workflowapplikationen, die auf unter schiedlichen entfernten Rechnern installiert sein können, kommunizieren mit ihr aus schließlich über ein Interface, das sich an dem von der WfMC spezifizierten Interface orientiert. Die Workflowapplikation besteht logisch gesehen aus zwei getrennten

Komponenten, dem Workflow-Editor und dem Workflow-Client. Aktivitätsdiagramme, die mit dem Editor erstellt wurden, können in der Datenbank der Workflow-Engine als so genannte Workflowdefinitionen abgespeichert werden. Der Workflow-Client ermöglicht es, Instanzen dieser Workflowdefinitionen zu starten oder an einer bereits gestarteten Workflowinstanz teilzunehmen.

Die Diplomarbeit baut auf dem Ergebnis der abgeschlossenen Projektarbeit auf. Das Ergebnis der Projektarbeit war ein Editor für UML-Aktivitätsdiagramme. Mit Hilfe des Editors ist es möglich, UML-Aktivitätsdiagramme zu zeichnen, auf Korrektheit bezüg lich der UML-Spezifikation²⁰ zu überprüfen und anschließend abzuspeichern.

Anhand eines konkreten Fallbeispiels wird zuletzt der Umgang mit dem entwickelten Workflow-Management-System demonstriert.

1.4 Verwandte Arbeiten

Es gibt bereits eine Reihe von Arbeiten, die sich mit der Verwendung von UMLAktivitätsdiagrammen für die Workflowmodellierung und Ausführung von Workflows beschäftigt haben. Sollen UML-Aktivitätsdiagramme in Zukunft zu einem Standard im Bereich der organisatorischen Prozessmodellierung werden, dann müssen sie mit alternativen Modellierungssprachen (Petrinetze, Ereignisgesteuerte Prozesskette, Aktivitätenmodell), wie sie zum Beispiel bereits in kommerziellen WorkflowManagement-Systemen eingesetzt werden, verglichen werden.

Marlon Dumas und Arthur H.M. ter Hofstede ⁷ untersuchen die Ausdrucksstärke und Eignung von Aktivitätsdiagrammen für die Definition von Workflows, indem sie systematisch auswerten, welche Workflowmuster mit ihnen dargestellt werden können. Diese Analyse zeigt die relativen Stärken und Schwächen von Aktivitätsdiagrammen. Es wird gezeigt, dass mit Hilfe von Aktivitätsdiagrammen in der Praxis Situationen abgebildet werden können, die mit den Modellierungssprachen der meisten kommerziellen Workflow-Management-Systeme nicht hätten modelliert werden können. Andererseits zeigt die Analyse auch einige Fälle, bei denen die Modellierung mit Aktivitätsdiagrammen scheitert. Zusammenfassend stellt die Analyse drei wichtige Vorteile von Aktivitätsdiagrammen gegenüber alternativen Modellierungssprachen, die in kommerziellen Systemen verwendet werden, heraus:

- Sie unterstützen das Senden und Empfangen von Signalen auf der konzeptionel len Ebene.
- Sie unterstützen sowohl Zustände, in denen eine Aktivität ausgeführt wird, als auch Zustände in denen nur auf das Auftreten eines bestimmten Ereignisses ge wartet wird.
- Aktivitäten können beliebig hierarchisch geschachtelt werden.

Die Analyse offenbart aber auch einige Nachteile von Aktivitätsdiagrammen:

- Einigen Elementen fehlt es an einer präzisen Syntax und Semantik. So sind zum Beispiel die Regeln zur Schachtelung von Forks und Joins nicht ausreichend de finiert, genauso wenig wie die Konzepte von Dynamic Invocations und Deferred Events.
- Sie unterstützen einige Synchronisationsarten nicht vollständig, wie zum Beispiel den N-out-of-M Join.

Die Analyse dieser Arbeit konzentriert sich ausschließlich auf den Kontrollfluss. Workflows können aber auch aus der Sicht des Objektflusses betrachtet werden. Eine weitere Betrachtungsweise könnte ein Vergleich zwischen den Konstrukten und Konzepten von UML-Aktivitätsdiagrammen und denen des Referenzmodells der Workflow Management Coalition²⁶ sein.

Rik Eshuis und Roel Wieringa präsentieren in ihrer Arbeit einen Ausführungsalgorithmus für UML-Aktivitätsdiagramme⁸, der für Workflow-Management-Systeme geeignet sein soll. Dieser orientiert sich sehr stark an der Semantik zur Ausführung von UML-Zustandsmaschinen, weicht allerdings in einigen Punkten geringfügig davon ab. Der größte Unterschied zur Semantik der UML-Spezifikation²⁰ besteht darin, dass eine Aktivität in einem Zustand extern, z.B. durch einen Anwender, ausgeführt wird, und nicht innerhalb einer Transition durch das System selbst. Da das Workflow-Management-System FlowSys auf diesem Ausführungsalgorithmus basiert, wird an dieser Stelle nicht weiter darauf eingegangen.

In einer weiteren Arbeit ⁹ vergleichen Rik Eshuis und Roel Wieringa Petrinetze mit Aktivitätsdiagrammen. Petrinetze sind schon seit längerer Zeit eine weit verbreitete Technik zur Modellierung von Workflows. Neuerdings werden dafür aber auch immer häufiger UML-Aktivitätsdiagramme verwendet, obwohl ihre Syntax und Semantik noch nicht vollständig definiert sind. Trotzdem sind sie Petrinetzen sehr ähnlich. Um dies zu belegen, versuchen die beiden Autoren die Semantik von Aktivitäts diagrammen zu formalisieren, und vergleichen sie anschließend mit der Semantik von Petrinetzen. Sie stellen fest, dass der Hauptunterschied zwischen der Semantik von Petrinetzen und der von ihnen definierten Semantik von UML Aktivitätsdiagrammen darin besteht, dass mit Petrinetzen in sich geschlossene, akti ve Systeme modelliert werden können, die nicht auf externe Ereignisse reagieren. Mit UML-Aktivitätsdiagrammen können dagegen offene, reaktive Systeme modelliert werden. Da allerdings Workflow-Management-Systeme offen sind und auf externe Ereignisse reagieren sollen, kommen sie zu dem Schluss, dass Petrinetze weniger gut für die Workflowmodellierung geeignet sind, als Aktivitätsdiagramme.

In Bezug auf die Beurteilung der Ausdrucksstärke von Aktivitätsdiagrammen bietet die Arbeit¹ eine gute Grundlage. In dieser Arbeit werden die Anforderungen an Sprachen zur Definition von Workflows systematisch mit Hilfe so genannter Workflowmuster analysiert. Es werden eine Reihe von Workflowmuster bzw. Kon strukten vorgestellt, die nach Meinung der Autoren für die Definition von Workflows zur Verfügung stehen sollten. Basierend auf diesen Mustern vergleichen sie mehrere kommerziell verfügbare Workflow-Management-Systeme. Sie kommen zu dem Er gebnis, dass die heutigen Sprachen zur Definition von Workflows die grundlegenden Konstrukte wie Sequenz, Iteration, Verzweigung und Zusammenführung unterstüt zen. Allerdings werden selbst diese grundlegenden Konstrukte nicht einheitlich inter pretiert und es ist oftmals unklar, wie komplexere Konstrukte unterstützt werden könnten.

In der Arbeit⁴ wird für UML-Aktivitätsdiagramme eine präzise Semantik vorge schlagen, um einige der Unklarheiten zu beseitigen, die aufgrund der nicht ganz ein deutigen Definitionen in der UML-Spezifikation entstehen. Zur Beschreibung der Se mantik werden abstrakte Zustandsmaschinen verwendet. Dadurch entsteht gleichzei tig eine neue Unterklasse von abstrakten Zustandsmaschinen, genannt Aktivitätsdia gramm-Maschinen, deren Verwendung in der Softwareentwicklung durch UML-Tools unterstützt wird.

Die Methode der Ereignisgesteuerten Prozesskette (EPK) ¹⁴, die im Rahmen der Architektur Integrierter Informationssysteme (ARIS) ²³ am Institut für Wirtschaftsin- formatik in Saarbrücken entwickelt wurde, baut auf der Grundlage von Petrinetzen auf. Sie hat sich mittlerweile zu einer Standard-Methode im Bereich der Geschäfts prozessmodellierung etabliert. Eine Ereignisgesteuerte Prozesskette besteht aus den Grundelementen Ereignisse und Funktionen (Aktivitäten), die durch Pfeile (Transitio nen) und Verknüpfungsoperatoren zu einer komplexen Ablauffolge hintereinander geschaltet werden. Funktionen beschreiben komplexe Tätigkeiten, die weiter untergliedert werden können. Es können Bedingungen formuliert werden, die während der Ausführung einer Prozessinstanz geprüft werden. Ist die Bedingung erfüllt, spricht man von einem „eingetretenen“ Ereignis. Ereignisse besitzen keine Entscheidungslogik. Deshalb existieren zusätzlich Verknüpfungsoperatoren (und, oder, exklusives oder), um komplexere Ablauflogiken darstellen zu können. Das Grundmodell der EPK kann um weitere Beschreibungselemente zur Abbildung von Datenflüssen, Organisationseinheiten oder Anwendungssystemen erweitert werden. Solch ein Diagrammtyp wird als erweiterte Ereignisgesteuerte Prozesskette (eEPK) bezeichnet.

Markus Nüttgens, Thomas Feld und Volker Zimmermann diskutieren in ihrer Arbeit ¹⁸, wie prozess- und objektorientierte Methoden miteinander kombiniert werden können. Dazu wird zunächst untersucht, wie Modelle zur Geschäftsprozessmodellierung in objektorientierte Modelle übersetzt werden können. Unter anderem werden dabei auch Ereignisgesteuerte Prozessketten in UML-Aktivitätsdiagramme transformiert. Dies belegt ebenfalls, dass UML-Aktivitätsdiagramme gut für die Modellierung von Geschäftsprozessen geeignet sind.

2 Workflow-Management-Systeme

2.1 Anforderungen an Workflow-Management-Systeme

Workflow-Management-Systeme müssen grob betrachtet in drei Bereichen Unterstützung leisten. Bei der Definition und Modellierung von Workflows und den dazugehörigen Aktivitäten, der Ausführung und Verwaltung der einzelnen Workflowinstanzen und der Interaktion mit Benutzern und externen Applikationen.

In der Definitionsphase wird ein Geschäftsprozess der realen Welt mit Hilfe eines entsprechenden Werkzeuges in eine formale, vom Computer ausführbare Repräsentation übersetzt. Diese Repräsentation wird in den meisten Fällen als Prozess- oder Workflowdefinition bezeichnet. Die Prozessdefinition besteht normalerweise aus mehreren Zuständen, in denen eine bestimmte Aktivität ausgeführt wird, und Regeln, die die Reihenfolge der einzelnen Aktivitäten festlegen. Die Darstellung einer Prozessdefinition erfolgt entweder in textueller oder graphischer Form.

Zur Laufzeit wird die Workflowdefinition von einer Software interpretiert, der so genannten Workflow-Engine. Es können beliebig viele Instanzen einer Workflowdefinition gestartet und ausgeführt werden. Die Verwaltung der einzelnen Instanzen übernimmt ebenfalls die Workflow-Engine. Während der Ausführung muss die WorkflowEngine dafür sorgen, dass die einzelnen Aktivitäten gemäß der Workflowdefinition abgearbeitet werden und gegebenenfalls die dafür verantwortlichen Personen benachrichtigen bzw. die entsprechende Softwareapplikation starten.

In vielen Fällen ist es erwünscht, dass ein Workflow von mehreren WorkflowManagement-Systemen unterschiedlicher Hersteller ausgeführt wird. Um Informationen und Aufgaben von einem System zum anderen weiterreichen zu können, müssen entsprechende Interfaces definiert und standardisiert sein. Dadurch wird es möglich, aus mehreren Systemen unterschiedlicher Hersteller eine zusammengesetzte Workflowapplikation zu entwickeln, die als logische Einheit arbeitet.

Die Hauptaufgabe von Workflow-Management-Systemen besteht darin, sicherzustel len, dass die zu erledigenden Aufgaben von der richtigen Person zur richtigen Zeit durchgeführt werden - und das so effizient wie möglich. Workflows beziehen sich immer auf einen ganz bestimmten Fall, zum Beispiel die Annahme und Bearbeitung einer Bestellung. Ein Fall wird bearbeitet, indem die Aufgaben in einer bestimmten Reihenfolge durchgeführt werden. Die Workflowdefinition legt fest, wie diese Reihen folge aussieht. Aufgaben werden entweder durch externe Systeme (z.B. Drucker, Fax, Softwareanwendung) oder Personen durchgeführt. Diese können Ereignisse auslösen, auf die das Workflow-Management-System reagiert, indem es entspre chend der Workflowdefinition den Workflowteilnehmern neue Aufgaben zur Bearbei tung zuteilt. Mehrere ähnliche Fälle können durch die gleiche Workflowdefinition rep räsentiert werden.

Zur Festlegung der Reihenfolge bei der Durchführung von Aktivitäten gibt es einige grundlegende Konstrukte, die von einem Workflow-Management-System unterstützt werden müssen (Abbildung 2).

A) Sequentielle Reihenfolge (Sequence):

Wird eine Aktivität beendet, kann mit der Durchführung der darauf folgenden Aktivität begonnen werden. Dieses Konstrukt wird dazu verwendet, um aufeinander folgende Schritte in einem Workflow zu modellieren.

B) Parallele Verzweigung (Parallel Split, AND-split, fork):

Mehrere Aktivitäten können zur gleichen Zeit oder in beliebiger Reihenfolge durchge führt werden. Man kann zwischen einem expliziten und einem impliziten AND-split unterscheiden. Für den expliziten AND-split wird ein eigener Knoten mit mehreren ausgehenden Transitionen verwendet, die gefeuert werden, sobald der Knoten akti viert ist. Der implizite AND-split kann ohne eigenen dafür vorgesehenen Knoten rea lisiert werden. Jede Aktivität kann mehr als eine ausgehende Transition mit einer da zugehörigen Bedingung besitzen. Um eine parallele Ausführung zu erreichen, müs sen lediglich mehrere Bedingungen der ausgehenden Transitionen erfüllt sein.

C) Synchronisation (Synchronization, AND-join, synchronizer, join):

Dieses Konstrukt stellt einen Punkt in einem Workflow dar, an dem mehrere parallel laufende Kontrollflüsse in einen einzigen Kontrollfluss münden. Entsprechend dem AND-split kann zwischen einem expliziten und einem impliziten AND-join unterschie den werden.

D) Exclusive Verzweigung (XOR-split, decision, choice):

Knoten in einem Workflow mit einer eingehenden und mehreren ausgehenden Transitionen, von denen nur genau eine ausgewählt werden kann.

E) Einfache Zusammenführung (XOR-join, merge):

Punkt in einem Workflow, an dem mehrere alternative Kontrollflüsse ohne Synchronisation zusammenkommen.

Abbildung 2: 5 Grundlegende Konstrukte

F) Wiederholung (Loop, iteration, cycle):

Eine oder mehrere Aktivitäten in einem Workflow können mehrmals hintereinander ausgeführt werden.

G) Schachtelung (Subflow):

Eine Aktivität kann aus mehreren Detailaktivitäten bestehen, die einen eigenen untergeordneten Workflow darstellen.

2.2 Die Workflow Management Coalition (WfMC)

2.2.1 Hintergrund

Workflow-Management ist eine Technologie, die in den letzten Jahren immer mehr in Unternehmen und Organisationen zum Einsatz kommt, um die Effizienz von Arbeits abläufen zu steigern. Ihr Ziel ist die Automatisierung von Prozessen bzw. Arbeitsab läufen, deren Aktivitäten von Menschen, Maschinen oder Software-Anwendungen durchgeführt werden. Typische Einsatzgebiete für Workflow-Management sind Ar beitsabläufe in Büros, die aus sehr vielen Arbeitsschritten bestehen, und an denen eine Vielzahl von Mitarbeitern beteiligt ist. Solche Arbeitsabläufe findet man vor allem in Banken, Versicherungen und in der öffentlichen Verwaltung. Es gibt aber auch viele Einsatzgebiete in der Produktion.

Mittlerweile existiert eine große Menge an Softwareherstellern, die WorkflowManagement-Systeme anbieten, und es kommen laufend neue Produkte auf den Markt hinzu. Viele Hersteller haben sich auf ganz bestimmte Aufgabengebiete spezialisiert. Dies hat dazu geführt, dass in vielen Unternehmen und Organisationen die einzelnen Abteilungen unterschiedliche Systeme verwenden. Es gab lange Zeit keinen Standard für Workflow-Management-Produkte, der eine Zusammenarbeit von unterschiedlichen Produkten ermöglichte. Dadurch sind viele inkompatible „Inseln“ von Workflow-Management-Systemen entstanden.

Die Workflow Management Coalition ²⁵ ist eine Gruppe bestehend aus mehreren Firmen, die sich mit dem Ziel zusammengeschlossen haben, eine Standardisierung für Workflow-Management-Systeme herbeizuführen. Es wurde festgestellt, dass alle Workflow-Management-Produkte einige gemeinsame Eigenschaften besitzen, die es ermöglichen sollten, einen gewissen Grad an Interoperabilität zu erreichen, indem für bestimmte Funktionen allgemeine Standards verwendet werden.

2.2.2 Ergebnisse der WfMC

Die Anfangsarbeit der WfMC bestand darin, ein Referenzmodell für Workflow Management-Systeme ²⁶ zu entwerfen, an dem sich die Entwickler neuer Systeme orientieren können. Es legt die grundlegenden Eigenschaften und Komponenten fest,

die ein Workflow-Management-System besitzen muss. Außerdem sorgt es für die Verwendung einer einheitlichen Terminologie.

Das Glossar ist ein ca. 30 Seiten umfassendes Dokument, das alphabetisch geordnet alle von der WfMC als für ihre Arbeit relevant erachteten Begriffe mit einer kurzen Erklärung auflistet. Dieses soll dazu beitragen, dass alle Hersteller die gleiche Terminologie verwenden. Diese Terminologie wird auch von der WfMC bei der Definition der im Folgenden beschriebenen Interfaces verwendet.

Die WfMC hat fünf Interfaces definiert, deren Funktionen als Standard für Workflow Management-Systeme gelten sollen und von diesen implementiert werden müssen.

- Interface I - The Process Definition Interchange²⁸: legt den Im- und Export von Workflowdefinitionen fest. Es beinhaltet ein Metamodell zur Beschreibung, eine Grammatik für den Austausch und APIs für die Manipulation von Workflowdefini tionen.
- Interface 2 - Workflow Client Application Programming Interface²⁷: definiert eine Reihe von Funktionen, die jedes Workflow-Management-System implementieren soll, um externen Applikationen, sowie anderen Systemen eine einheitliche Schnittstelle zur Verfügung zu stellen. Außerdem sollen dadurch externe Applikationen die Möglichkeit bekommen, mit unterschiedlichen Workflow-Management Systemen zusammenzuarbeiten.
- Interface 3 - Invoked Applications: wurde mit in das Interface 2 aufgenommen. Es besteht aus Funktionen zum Steuern externer Applikationen.
- Interface 4 - Interoperability²⁹: abstrakte Spezifikation, die festlegt, welche Funktionen notwendig sind, um eine Zusammenarbeit unterschiedlicher Workflow-Management-Systeme zu ermöglichen.
- Interface 5 - Audit Data Specification³⁰: legt fest, welche Informationen bei der Ausführung eines Workflows gesammelt und aufgezeichnet werden sollen.

2.2.3 Das Workflow Reference Model

Das Workflow Reference Model ²⁶ ist eine Referenzarchitektur für Workflow Management-Systeme, an dem sich Hersteller orientieren sollen, um eine Zusam menarbeit unterschiedlicher Systeme zu ermöglichen. Sie beschreibt die wesentli- chen Komponenten und Schnittstellen eines Workflow-Management-Systems (Abbildung 3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Workflow Reference Model

2.2.3.1 Workflow Enactment Service

Der Workflow Enactment Service stellt die Laufzeitumgebung zur Verfügung, in der Workflowinstanzen gestartet, verwaltet und ausgeführt werden. Für die Ausführung einer bestimmten Workflowinstanz und der Interaktion mit externen Komponenten ist jeweils eine eigene Workflow-Engine zuständig. Die WfMC definiert den Workflow Enactment Service wie folgt:

„ A software service that may consist of one or more workflow engines in order to create, manage and execute workflow instances. Applications may interface to this service via the workflow application programming interface (WAPI). ”

Die Interaktion externer Workflowapplikationen und anderer Workflow-Management Systeme mit dem Workflow Enactment Service geschieht über das sogenannte Workflow Application Programming Interface (WAPI).

Die Workflow-Engine ist für die folgenden Aufgaben zuständig:

[...]