Forschungsprojekt ECOMODForschungsgruppe Unternehmensmodellierung

Referenzgeschäftsprozesse und Strategien im E-Commerce

 Überblick
Einführung: Geschäftsprozessmodellierung vs. Workflow Management
Geschäftsprozessmodellierung (GPM) und Workflow Management (WfM) sind zentrale Themen der Wirtschaftsinformatik. Auf den ersten Blick erscheinen beide Ansätze sehr ähnlich: GPM und WfM haben eine prozessorientierte Sicht auf Organisationen. Diese prozessorientierte Sichtweise umfasst Aktivitäten und deren Beziehungen innerhalb eines Unternehmens und im Kontext des Unternehmens. Beziehungen zwischen Geschäftsprozessen können mittels Kontrollflußangaben, hierarchischer Dekomposition und/oder generischen Beziehungen näher spezifiert werden. Die Beziehungen zum organisationalen Kontext können über die Zuordnung von Organisationseinheiten (Abteilungen, Rollen) und Ressourcen (Werkzeuge, technische Infrastruktur) abgebildet werden. Trotz der Gemeinsamkeiten von GPM- und WfM-Ansätzen, lassen sich deutliche konzeptuelle Unterschiede feststellen, welche näher betrachtet werden müssen, bevor die Konzepte beider Ansätze sauber aufeinander abgebildet werden können. GPM und WfM repräsentieren unterschiedliche Abstraktionsebenen der prozessorientierten Sichtweise auf Unternehmen. Die folgende Übersicht zeigt typische Unterschiede auf, die in der Literatur erwähnt werden:
GeschäftsprozessmodellierungWorkflow Management
  • Beinhaltet auch manuelle Aktivitäten/Prozesse [FrLa03]
  • "Konzeptuelle Ebene" des Unternehmens (z.B. [Böhm00])
  • Geschäftsprozesse können zu den verschiedensten Ressourcen in Beziehung stehen (d.h. nicht nur IT) [Jung01]
  • Fokussiert auf die Verarbeitung digitaler Geschäfts- bzw. Bürodokumente [FrLa03]
  • Manuelle Prozesse und Prozesse der Entscheidungsfindung können nicht abgebildet werden [FrLa03]
  • Betonung liegt auf der Nutzung von Technologien [Böhm00, S. 3]
  • Workflows sind Geschäftsprozesse kombiniert mit IT [Sta97]
Überblick der Inhalte
Auf diesen Seiten beschreiben wir einen Ansatz für die Abbildung von Konzepten einer gegebenen Geschäftsprozessmodellierungssprache auf Workflow Schemata. (Die Inhalte wurden bereits als Arbeitsbericht Nr. 47 veröffentlicht.)
Komplettes Beispiel ansehen.



 Ansatz
Softwaregenerierung auf der Basis von Geschäftsprozessen
Die Implementierung basiert auf der Abbildung von Geschäftsprozessmodellen auf Workflowmodelle und der entsprechenden Konfiguration eines Workflowmanagementsystems (WFMS). Der Gesamtansatz ist in der folgenden Abbildung zusammen mit der verwendeten Software, zugehörigen Dokumenten und Modellierungssprachen dargestellt.
Das Modellierungswerkzeug MetaEdit+ wurde verwendet für
  • die Modellierung von Geschäftsprozessen (unter Verwendung der Modellierungssprache MEMO-OrgML) und
  • für die Abbildung von Geschäftsprozesen auf Workflowbeschreibungen in XPDL.
Die Enhydra Shark Workflow-Engine wurde als Laufzeitumgebung für die Workflows eingesetzt (für weitere Details siehe Implementierungsaspekte):
  • Die Workflow-Engine verwendet die generierte Workflowbeschbreibung für die Ausführung von Workflows.
  • Zusätzlich können Benutzer verwaltet und mit Workflowteilnehmern (Participants) in Beziehung gesetzt werden.
  • Java-Anwendungen können entwickelt und in der Workflow-Engine mit Workflow-Anwendungen verknüpft werden.
Oben
Überblick der Modelle und ihrer Beziehungen
Für die Umsetzung der Abbildung von Geschäftsprozessmodellen auf eine lauffähige Anwendung wurden vier verschiedene Diagrammarten verwendet. Die untenstehende Grafik erläutert den Zusammenhang der verschiedenen Modellarten und zeigt jeweils ein beispielhaftes Modell.
Workflow-Spezifikationsdiagramm Prozessdekomposition
Das Ausgangsdiagramm für die Generierung von Workflowspezifikationen in XPDL ist das Workflowspezifikationsdiagramm. Es beinhaltet alle Teilnehmer (einen oder mehrere), Workflow-Daten (null oder mehr) und die für den Workflowprozess notwendigen Anwendungen (null oder mehr). Weitere Informationen finden Sie im Abschnitt Grundlagen der Workflowmodellierung. Das Workflowspezifikationsdiagramm beinhaltet eine Referenz zu einem Prozessdekompositionsdiagramm, welches alle (Sub-)Prozesse beinhaltet, die in dem gegebenen Workflow verwendet werden. Der oberste Prozess der Dekompositionshierarchie repräsentiert den Workflowprozess selber und es sind weitere dekomponierte Prozesse möglich. Mindestens ein elementarer Prozess muss jedem komponierten Prozess in dem Dekompositionsdiagramm über eine Dekompositionsbeziehung zugeordnet werden. Nähere Informationen finden Sie im Abschnitt Grundlagen der Geschäftsprozessmodellierung.
Prozessmodell Workflow-Aktivitätsspezifikationsdiagramm
Der Kontrollfluss jedes dekomponierten Prozesses muss mit Hilfe eines Prozessmodells näher spezifiert werden. Dieses Diagramm muss all Teilprozesse des jeweiligen komponierten Prozesses beinhalten. Weitere Informationen hierzu finden Sie im Abschnitt Grundlagen der Geschäftsprozessmodellierung. Jeder Elementarprozess in einem Prozessdekompositionsdiagramm muss mit Hilfe eines Workflow-Aktivitätsspezifikationsdiagrammes näher beschrieben werden. Dieses Diagramm beinhaltet Angaben zur Verknüpfung workflowrelevanter Daten (eigentliche Parameter) mit den formalen Parametern einer Workflow-Anwendung. Weitere Informationen hierzu finden Sie im Abschnitt Grundlagen der Workflowmodellierung.
Oben



 Grundlagen - Geschäftsprozessmodellierung
Einleitung
Auf die Analyse, Repräsentation und das Management von Wissen innerhalb von Organisation und ihrer Prozesse wurde schon immer viel Wert gelegt [KoPl00]. Es wurde viel an der Entwicklung und Evaluation von Ontologien für die Prozessmodellierung, der Spezifikation von Prozessmodellierungssprachen sowie der Methoden und Konzepte für die Geschäftsprozessmodellierung gearbeitet (vgl. z.B. [WaWe93], [Web97], [GrRo99], [EJLT99], [SuOs97], [Herb97], und [Öst95]). Geschäftsprozessmodelle können für verschiedene Zwecke genutzt werden:
  • Dokumentation von Prozessen einer Organisation zur Unterstützung der Kommunikation
  • Analyse von Geschäftsprozessen
  • Simulation von Prozessen
  • Unterstützung des Business Process Reengineerings
  • Softwareentwicklung prozessorientierter Anwendungen
Geschäftsprozessmodelle stellen ein übliches Medium für die Kommunikation zwischen Fachleuten und Neueinsteigern dar. Sie repräsentieren domänensprezifische Konzepte und ermöglichen eine besser Weitergabe vorhandenen Wissens über die Organisation und ihrer Prozesse. Die Analyse von Geschäftsprozessen erfordert eine detaillierte Beschreibung von Geschäftsprozessmodellen sowie verwandter Konzepte (im Hinblick auf den Zweck der Analyse).
In Abhängig vom Ziel der Analyse muss eine Modellierungssprache bestimmte Sprachmittel zur Modellierung aller Aspekte innerhalb des Betrachtungswinkels zur Verfügung stellen. Analysen könnten zum Beispiel der Aufdeckung von Schwächen innerhalb bestehender Prozesse dienen. Entsprechende Sprachmittel, die von einer Prozessmodellierungssprache zur Verfügung gestellt werden, dienen der Ermittlung von Medienbrüchen, redundanten Prozessen oder anderen Verbesserungspotentialen. Eine weitergehende Optimierung ist abhängig vom Formalisierungsgrad der Beschreibung des Geschäftsprozessmodells. Die Anpassung und Änderung der Prozesse im Sinne eines Business Process Reengineerings könnte aufgrund identifizierter Schwächen notwendig werden.
Geschäftsprozessmodellierung mit MEMO-OrgML
MEMO (Multi-Perspective Enterprise Modelling) ist eine Methode zur Modellierung von Organisationen aus verschiedenen Sichten sowie auf unterschiedlichen Abstraktionsebenen. MEMO beinhaltet verschiedene Sprachen zur Modellierung von statischen, funktionalen und dynamischen Aspekten eines Unternehmens. Eine dieser Sprachen ist MEMO-OrgML (Organisation Modelling Language), mit deren Hilfe die Modellierung der Strukturen und Prozesse einer Organisation unterstützt wird. Ressourcen-Modellierung war innerhalb der ersten Konzeptualisierung von MEMO-OrgML nicht vorgesehen, wird jedoch in naher Zukunft hinzugefügt werden.

Ein einführendes Beispiel eines mit MEMO-OrgML modellierten Prozesses ist in der unteren Abbildung zu sehen. Ein Auftrag geht bei der Vertriebsabteilung ein, dessen Daten direkt anschließend geprüft werden (Prozess Nr. 1 'Check Data'). Bei gültigen Daten (Ereignis Nr. 4 'Valid Data') wird der Auftrag weiter bearbeitet, bei ungültigen Daten (Ereignis Nr. 3) wird er abgebrochen. Auf den Abbruch eines Auftrags folgt das Senden einer Ablehnungsnachricht an den Kunden in Prozess Nr. 9 ('Compose Rejection Message'). Eine weitere Bearbeitung des Auftrags umfasst die Eingabe der Daten in das Auftrags-Management-System (Prozess Nr. 2 'Enter Order') gefolgt von den parallel ausgeführten Prozessen 6, 7 und 8. Prozess Nr. 6 ist ein komponierter Prozess, der aus einem oder mehreren Subprozessen besteht. Der Prozess namens 'Compose Acceptance Message' (Nr. 7) stellt einen teilautomatisierten Prozess dar, der durch die Vertriebsabteilung ausgeführt wird. Prozess Nr. 8 ist ein vollständig automatisierter Prozess, durch den eine Standard-Email-Nachricht an den Kunden gesendet wird.
Die folgende Auflistung gibt einen kurzen Überblick der Sprachkonzepte und ihrer Notation in MEMO-OrgML.
Prozesssymbole

Abstrakter Prozess Aggregierter Prozess Manueller Prozess


Teilautomatischer Prozess Automatischer Prozess Kontinuierlicher Prozess


Vom Auftragnehmer durchgeführter Prozess Von autonomer Institution durchgeführter Prozess Von externer Organisation durchgeführter Prozess ('Black Box')
Dekompositionshierarchie

Stellt die Dekompositionsbeziehung zwischen aggregierten bzw. abstrakten Prozesstypen und anderen Prozesstypen dar.
Ereignissymbole

Start-Ereignis End-Ereignis Relevante Änderung des Informationsbestandes
(unspezifiziertes Ereignis)


Nachricht eingetroffen Zeitbezogenes Ereignis -
Zeitintervall ist abgelaufen
Zeitbezogenes Ereignis -
Zeitpunkt erreicht
Kontrollstrukturen

Prozess erzeugt Ereignis Ereignis löst Prozess aus


Parallele Ausführung Synchronisation nach der Terminierung einer der parallelen Prozesse


Synchronisation nach der Terminierung aller paralleler Prozesse
Ausnahmen

Ausnahmen werden systemweit festgelegt
(z.B. Zusammenbruch des Kommunikationskanals, Time-Out)
Anmerkungen (natürlichsprachlich)

Hier können Bedingungen (Constraints) annotiert werden.    Hier können sonstige Anmerkungen festgehalten werden.
Oben
Weitere Konzepte der Geschäftsmodellierung
Neben den oben genannten prozessorientierten Konzepten gibt es zwei weitere Konzepte, die für eine prozessorientierte Modellierung von Organisationen zentral sind. Organisationseinheiten entsprechen Abteilungen, Geschäftsbereichen oder Rollen, die den Geschäftsprozessen als verantwortliche Akteure zugeordnet werden.
Organisationseinheiten
Die statische Struktur einer Organisation kann durch ein Organigramm beschrieben werden, das eine Organisation anhand ihrer Untereinheiten sowie deren Beziehungen zueinander darstellt. Das Meta-Modell zur Modellierung von Organigrammen ist in Teil a) der Abbildung auf der rechten Seite dargestellt. Eine abstrakte Organisationseinheit kann entweder eine Position oder eine Organisationseinheit repräsentieren. Jede Organisationseinheit stellt eine Komposition anderer abstrakter Organisationseinheiten dar. Eine Position dient der elementaren Beschreibung der Verantwortlichkeiten eines Mitarbeiters. Teil b) der rechten Abbildung zeigt ein Beispiel für ein Organigramm: Die dargestellte Firma besteht dabei aus drei Abteilungen: Einkauf, Produktion und Vertrieb.

Organisationseinheiten und Rollen sind den Geschäftsprozessen zugeordnete Elemente, welche sich auf menschliche Akteure beziehen, die für die Ausführung eines Geschäftsprozesses verantwortlich sind. Die hier beschriebenen Organisationseinheiten und Positionen können Geschäftsprozessen zugeordnet werden. Rollen sind in Organigrammen nicht notwendigerweise definiert, können jedoch Geschäftsprozessen zugeordnet werden.
Ressourcen
Ressourcen sind bei der Prozessmodellierung essentiell [PSO99]. Prozesse und ihre Beziehungen beschreiben hauptsächlich dynamische Aspekte sowie die Reihenfolge von Ereignissen. Den Prozessen zugeordnete Ressourcen spezifizieren zusätzlich Subjekte und Objekte der Geschäftsprozesse. Ressourcen sind im Allgemeinen nicht in unbegrenzter Menge verfügbar (vgl. [Nübe01], [PSO99]). Infolgedessen muss die Nutzung von knappen Ressourcen bei der Analyse oder Simulation der Prozesse sowie der Entwicklung einer Workflow-Anwendung oder eines Informationssystems berücksichtigt werden. Da sich die Modellierungssprache für Ressourcen in MEMO-OrgML momentan in Entwicklung befindet, wird an dieser Stelle keine graphische Notation, jedoch eine kurze Einführung in das zugrunde liegende Meta-Modell gegeben. Ein Auszug dieses Meta-Modells ist in der folgenden Abbildung zu sehen. Die Klasse 'AbstractResource' stellt die Wurzel der Generalisierungshierarchie für Ressourcen dar. Jede Ressource hat einen Namen ('name: String'), eine textuelle Beschreibung ('description: String') und eine Liste von Attributen ('attributes[0..*]:ResourceAttribute'). Jedes Ressourcen-Attribut ist ein Name-Typ-Paar für die Spezifikation der benutzerdefinierten Attribute der Ressourcen.
In der Prozessmodellierung unterscheidet man generell zwischen menschlichen, physischen und immateriellen Ressourcen. Eine menschliche Ressource ist eine Abstraktion unterschiedlicher Perspektiven auf die Mitarbeiter. Beispiele für solche Perspektiven sind konkrete Angestellte, durch Mitarbeiter erfüllte Rollen oder geschäftsorientierte Funktionen. Physische Ressourcen umfassen alle materiellen Objekte, die innerhalb eines Geschäftsprozesses benötigt werden. Beispiele für physische Ressourcen sind Produktionsstätten, Rohstoffe oder Computer Hardware. Im Gegensatz dazu besitzen immaterielle Ressourcen keine physische Erscheinungsform. Daten, Informationen, Software oder auch Wissen sind Beispiele für immaterielle Ressourcen.

Menschliche Ressourcen (Human Resources) sind Abstraktionen von Personen, Mitarbeitern, Rollen oder anderen Perspektiven auf die Mitarbeiterschaft. Sie können mit konkreten Personen oder Mitarbeitern einer Organisationen sowie abstrakten Organisationseinheiten in einem Organigramm assoziiert werden. Daher kann eine menschliche Ressource durch verschiedene Aspekte charakterisiert werden. Eine menschliche Ressource:
  • kann eine aktive Rolle spielen
  • kann für die Ausführung von E-Business-Prozessen verantwortlich sein
  • benötigt spezielle Qualifikationen und Kompetenzen für ihren Job
Der Typ 'HumanResource' ist ein Untertyp von AbstractResource und besitzt die zwei Attribute 'qualification' und 'competenceProfile' vom Typ String. Die Qualifikation stellt ein objektiv beschreibbares Kriterium für die Fähigkeiten einer menschlichen Ressource dar. Normalerweise wird das Zeugnis über die Qualifikation von einer etablierten Ausbildungseinrichtung ausgestellt. Die Kompetenz einer menschlichen Ressource reflektiert die Eignung der Personen. Daher entspricht ein Kompetenzprofil der Summe relevanter persönlicher Stärken.

Physische Ressourcen umfassen alle innerhalb eines Geschäftsprozesses genutzten materiellen Objekte, die weder menschlich noch immateriell sind. Nach Heinen [Hei88, S. 242] kann im Kontext der industriellen Produktion zwischen nicht-konsumierbaren Ressourcen (Potentialfaktoren) und konsumierbaren Ressourcen (Repetierfaktoren) unterschieden werden. Potentialfaktoren werden während des Produktionsprozesses nicht verbraucht und sind somit auch danach verfügbar, während Repetierfaktoren entweder einen Teil des resultierenden Produktes ausmachen oder verbraucht werden, so dass sie nicht mehr verfügbar sind [SS01, S. 89 ff]. Wir abstrahieren an dieser Stelle von physischen Ressourcen, da diese im Kontext der Workflow-Anwendungen sowie der präsentierten Perspektiven irrelevant sind.

Immaterielle Ressourcen sind solche ohne physisches Erscheinungsbild. Software, im Sinne einer Menge von Programmen, die auf Computer-Hardware laufen, stellt eine zentrale Ressource im Prozess der Workflow-Unterstützung dar. Der Metatyp Software besitzt zwei Attribute: systemRequirements und scalability - beide vom Typ String. Systemvoraussetzungen werden in Form von Text modelliert und beschreiben die Umgebung für die Ausführung eines Softwaresystems (z.B. Prozessorarchitektur, minimaler Hauptspeicher oder Betriebssystem). Skalierbarkeit entspricht der Fähigkeit eine wachsende Anzahl von Clients zu unterstützen. Der Metatyp Information wurde entwickelt, um Informationen oder Wissen zu repräsentieren, die innerhalb der Workflows relevant sind. Als Attribute besitzt er name (eine symbolische Referenz auf eine Informationen-Instanz) und typeDefinition vom Typ String, der die Strukturierung der Informationen beschreibt. Beispiele für Informationen sind spezielle Kundendaten oder bestimmtes Unternehmenswissen.
Oben



 Grundlagen - Workflowmodellierung
Dieser Abschnitt gibt eine Einführung in grundlegende Konzepte, Technologien und Standards im Bereich des Workflow Managements.
WfMC und Workflow Spezifikationssprachen
Die Workflow Management Coalition (WfMC) wurde 1993 gegründet und ist eine Allianz von Unternehmen und Organisationen, die sich mit dem Thema Workflow Management beschäftigen. Die Zielsetzung der WfMC liegt in der Festlegung einheitlicher Begrifflichkeiten im Workflow Management und der Etablierung standardisierter Schnittstellen. Diese Schnittstellen beziehen sich sowohl auf die Definition, die Durchführung, die Verwaltung von Workflows als auch auf die Referenzierung externer Dokumente und Anwendungen [Jung01, S. 126 ff]. Die Konzeptualisierung der verschiedenen Schnittstellen ist im nachfolgend abgebildetetn WfMC-Referenzmodell dargestellt. Der Kern des Referenzmodells [Holl95] umfasst die so genannten Workflow-Enactment-Services, die eine oder mehrere Workflow-Engines zur Ausführung von Workflows verwenden. Eine Workflow-Engine ist eine Software, die Workflows verwalten und entspr. einer gegebenen Workflowdefinition ausführen kann.
WfMC Referenzmodell
WfMC-Referenzmodell [Holl95, S. 20]
Die fünf verschiedenen Schnittstellendefinitionen (Interfaces) hängen mit der Integration verschiedener externer Gesichtspunkte zusammen:
  • Schnittstelle 1 spezifiziert den Austausch von Workflow-Modellen zwischen externen Modellierungsprogrammen und einem Workflow Management-System. Externe Programme können grafische oder textbasierte Editoren für Workflow-Definitionen sein. Allgemein einsetzbare Modellierungsprogramme, die den WfMC-Standard unterstützen, können ebenfalls für die Spezifikation von Workflows verwendet werden [Holl95, Seite 20].
  • Schnittstelle 2 beschreibt den Datenaustausch zwischen einem WfMS und einer Workflow-Client-Anwendung. Workflow-Client-Anwendungen sind Programme, die eng mit der Workflow-Engine selber in Beziehung stehen. Üblicherweise bieten Sie grundlegende Funktionalitäten wie Nachrichtendienste und Datentransfer [Holl95, S. 31 ff].
  • Schnittstelle 3 setzt die notwendige Integration von externen Programmen um. Üblicherweise werden die notwendigen Funktionen nicht vollständig durch das WfMS zur Verfügung gestellt. Folglich muss es eine Schnittstelle zu anderen Programmen geben, die bereits im Unternehmen eingesetzt werden [Holl95, S. 35 ff]. Beispiele für solche Programme sind betriebliche Anwendungssoftware und spezifische Werkzeuge.
  • Ziel von Schnittstelle 4 ist die Integration von anderen Workflow Management Systemen. Die Spezifikation sieht den Aufruf entfernt stattfindender Aktivitäten, Datentransfer sowie Möglichkeiten zur Synchronisation zwischen verschiedenen Workflow-Enactment-Services vor. [Jung01, S. 126] [Holl95, S. 41 ff].
  • Schnittstelle 5 beschreibt die Kommunikation zwischen Workflow-Enactment-Dienstleistungen und externen Kontroll- bzw. Verwaltungswerkzeugen.
Schnittstelle 1 ist der Teil des WfMC-Referenzmodells, der für die Abbildung von Geschäftsprozessmodellen auf Workflows am wichtigsten ist. Hier werden verschiedene Arten von Workflows (Prozessen) sowie assoziierte Organisationseinheiten und Anwendungen definiert. Die system-spezifische Integration von Anwendungen wird mit Hilfe der Schnittstelle 2/3 umgesetzt [Holl95, Seite 20].
Die Workflow Prozess-Defintions-Sprache (Workflow Process Definition Language (WPDL)) war der erste Versuch der WfMC einen Standard für den Austausch von Workflowdefinitionen zu spezifizieren. Als Standard für Austauschmodelle stellt es keine graphische Notation zur Verfügung. Inzwischen wurde WDPL durch die XML Prozess Definitions Sprache (XPDL), eine XML-basierte Dokumentendefinition für Workflows, ersetzt (siehe [Nori02]).
Top
XML Prozess Definitions Sprache (XPDL)
Das Metamodell (siehe folgende Abbildung) stellt die von XPDL unterstützten Konzepte dar. Dieses Metamodell enthält statische Entitäten (z.B. Daten oder Anwendungen) und dynamische Konzepte (Prozesse). Statische Entitäten werden repräsentiert durch die Metatypen
  • Workflow Relevant Data (Workflow-relevante Daten),

  • Workflow Participant Specification (Workflow-Teilnehmer-Spezifikation) und

  • Workflow Application Declaration (Workflow-Anwendungs-Deklaration).
Workflow-relevante Daten werden initialisiert, erzeugt, von externen Anwendungen gelesen und während des Ablauf des Workflows verwendet [Nori02, Seite 10]. Sie können bspw. durch einen Vorgang in einem Workflow erstellt oder aus externen Datenquellen (z.B. einem Unternehmensinformationssystem) gewonnen werden. Das Erstellen von neuen Datensätzen oder das Digitalisieren von Dokumenten sind mögliche Datenquellen im Workflow-Kontext. Beispiele für externe Datenquellen sind gemeinsame Datenbanken, die relevante Daten für ein Unternehmen enthalten.
Die Workflow-Teilnehmer-Spezifikation beschreibt die Ressourcen, die einen gegebenen Workflow-Prozess ausführen [Nori02, S. 9]. Sie muss sich nicht zwangsläufig auf Menschen oder eine einzelne Person beziehen. Sie repräsentiert vielmeher eine abstrakte Ressource oder Rolle, die von einer oder mehreren Personen sowie einer Maschine ausgefüllt werden kann. Dennoch steht Workflow-Participant immer für eine in einer Organisation verfügbare Resource bzw. für eine in Entität in einem Organisationsdiagramm. Die Workflow-Anwendungsdeklaration beschreibt die Softwareanwendungen, die für die Ausführung von Workflow-Prozessen benötigt werden [Nori02, Seite 9]. Diese Anwendungen werden in der Regel durch die Workflow-Engine initiiert und Workflow-relevante Daten werden dabei als Parameter übergeben. Beispiele für Workflow-Anwendungen sind interne Anwendungen sowie externe Anwendungen wie zum Beispiel betriebliche Informationssysteme oder gemeinsame Büroanwendungen. Interne Anwendungen werden i.d.R. als Teil des Workflow-Management-Systems bereit gestellt oder können mit Hilfe proprietärer Entwicklungsumgebungen oder -sprachen selbst erstellt werden.
XPDL Meta-Modell
XPDL Metamodell [Nori02, S. 12]
Eine Workflow-Prozess-Definition besteht aus der Beschreibung statischer Entitäten (Daten, Anwendungen, Teilnehmer) und des dynamischen Systemverhaltens. Dynamische Aspekte des Metamodells werden durch die Entitätstypen Transition Information sowie Workflow Process Activity und die folgenden konkreten Subtypen repräsentiert:
  • Block Activity (Blockaktivität),
  • Atomic Activity (Einzelaktivität) und
  • Sub-Process Definition (Subprozessdefinition).
Unter einer Aktivität wird eine bestimmte Arbeitseinheit verstanden, die von einem Teilnehmer (Participant) unter Verwendung bestimmter Anwendungssoftware und relevanter Daten ausgeführt wird (siehe [Nori02, S. 8]). Zudem ist jede Tätigkeit durch einen Anfangs- und Endzeitpunkt charakterisiert sowie dadurch, ob sie automatisch durch das WfMS ausgeführt werden kann oder durch einen Workflow-Teilnehmer ausgeführt werden muss. Die Transitionsinformation (Transition Information) spezifiziert den Kontrollfluss zwischen den einzelnen Aktivitäten [Nori02, S. 9]. Sie besteht aus einer Anfangs- und Endaktivität und einer Bedingung unter der die Transaktion durchgeführt wird. Eine atomare Tätigkeit ist eine unteilbare Arbeitseinheit, die in einem Durchgang erledigt werden muss. Eine Subprozess-Definition erlaubt das Einbetten einer anderen Workflow-Prozess-Definition. Ein Tätigkeitsblock besteht aus einem Satz von weiteren Tätigkeiten (Typ Activity Set). Die Semantik eines Tätigkeiten-Satzes ist ähnlich zu dem eines Makros. Wenn ein Satz von Tätigkeiten während der Ausführung eines Workflow-Prozesses aufgerufen wird, werden die Tätigkeiten, die in dem Satz enthalten sind, in die aufrufende Prozessdefinition kopiert [Mato03, Seite 13].
Top
Grundlegende Workflowkonzepte
Aktivitäten und Transitionen sind die wichtigsten Konzepte für die Beschreibung dynamischer Aspekte in Workflow-Systemen. Aktivitäten entsprechen festgelegten Arbeitseinheiten, die entweder atomar sind oder aus einer Menge von Aktivitäten bestehen. Der Kontrollfluß zwischen Aktivitäten wird mit Hilfe von Transitionen spezifiziert. Folglich definiert eine Transitionsbeziehung die Reihenfolge zwischen zwei Aktivitäten. Eine Aktivität kann gestartet werden, wenn seine Vorgänger-Aktivitäten (verbunden über Transitionen) beendet sind. Transitionen, Aktivitäten und statische Entitäten werden zu sogenannten Workflowprozessdefinition zusammen gefasst.
Workflowprozessdefinitionen
Eine Workflowprozessdefinition fasst alle Element zusammen, die für die Ausführung eines Workflows wichtig sind. Das Meta-Modell macht deutlich, dass diese Elemente dynamische (Aktivitäten und Transitionen) und statische Aspekte (Daten, Anwendungen, Teilnehmer) beinhalten. Zusätzliche Attribute sind eindeutige Bezeichner, ein Name und zwei Header:
  • Der Prozess Header umfasst das Erstellungsdatum, eine textuelle Beschreibung und verschiedene zeitbezogene Eigenschaften eines Workflowprozesses (z.B. geschätzte Durchlaufzeit).
  • Der re-definierbare Header besteht aus Informationen zu dem Autor der Prozessdefinition, einem Länder-Code, dem Veröffentlichungsstatus, verantwortlichen Teilnehmern und einer Versionsnummer.
Eine Aktivitätenmenge (activity set) besteht aus Aktivitäten und Transitionen. Alle Transisitonen in einer Aktivitätsmenge können nur von den in der Menge enthaltenen Aktivitäten aus starten und in diesen enden. In anderen Worten: es gibt keine Transitionen, die die Aktivitätenmenge verlassen oder von Außen kommen. Die Eigenschaften (Attribute) eine Aktivitätsmenge sind eine Liste von Aktivitäten, eine Liste von Transistionen und ein eindeutiger Bezeichner.
Workflowprozessaktivitäten
In der untenstehenden Abbildung werden die verschiedenen Arten von Aktivitäten eine Workflowprozessdefinition aufgelistet. Eine atomare Aktivität ist ein unteilbare Verrichtungseinheit, die gesteuert vom WfMS ausgeführt wird. Eine solche Aktivität kann automatisch ausgeführt werden oder durch einen Teilnehmer (human participant) und nutzt i. A. workflowrelevante Daten. Eine Blockaktivität führt eine Aktivitätsmenge aus und hat kein eigenes Verhalten. Der Aufruf einer Aktivitätsmenge ist mit dem Starten der ersten Aktivität in der Menge gleichzusetzen. Die Ausführung endet mit der letzten Aktivität der jeweiligen Aktivitätenmenge (siehe untenstehende Abbildung, [Nori02, S. 30]). Eine so genannte route activity ist eine Aktivität ohne Verhalten. Sie dient nur dazu bestimmte Transitionsbedingungen abzubilden (siehe weiter unten).
Aktivitäten in XPDL [Nori02, S. 30]
Verschiedene Aktivitäten in XPDL [Nori02, S. 30]
In XPDL ist nur ein allgemeines XML-Element für Aktivitäten vorgesehen (Activity). Spezifische Elemente für Block- oder Route-Aktivitäten gibt es nicht. Die Differenzierung der verschiedenen Aktivitätstypen wird über die Annotation alternativer Attribute unterstützt. Diese Attribute sind Route, Implementation und BlockActivity. Zusätzlich können Aktivitäten bzgl. ihres Automatisierungsgrades (automatisch vs. manuell) sowie der Implementierungsalternativen (keine Implementierung, Werkzeug oder 'subflow') spezifiziert werden:
  • Eine automatisierte Aktivität kann durch die Workflow Engine vollständig unter Verwendung interner und externer Anwendungen gesteuert werden.
  • Manuelle Akivitäten erfordern die Einbindung einer Person.
  • Die so genannten no-implementation Aktivitäten können durch das WfMS nicht unterstützt werden. Sie sind üblicherweise manuelle Aktivitäten, die ohne die Unterstützung des WfMS ausgeführt werden können.
  • Eine werkzeuggestützte Implementierung impliziert die Nutzung einer Anwendungssoftware.
  • Ist der Implementierungstyp auf subflow gesetzt, so muss die Ausführung an eine andere Workflowprozessdefinition weiter delegiert werden. Hierbei können Parameter mitgegeben werden und die Art der Synchronisation kann spezifiert werden. Bei synchroner Ausführung muss der aufrufende Prozess warten, bis der aufgerufene Prozess beendet ist. Der aufgerufene Prozess könnte bspw. nach der Beendigung Parameterwerte an den aufrufenden Prozess übergeben. Während einer asynchronen Ausführung muss der aufrufende Prozess nicht auf den aufgerufenen Prozesse warten und die Übergabe von Parameterwerten durch den aufgerufenen Prozess ist nicht möglich.
Zusätzliche Informationen für Aktivitäten sind 'Deadlines' und Simulationsinformation:
  • Eine Deadline beschreibt den Ablauf einer fest gelegten Zeitdauer (z.B. ein Meilenstein im Projektmanagement oder ein sonstiger Termin). Das Auftreten einer Deadline kann synchron behandelt werden (d.h. die aktuelle Aktivität wird unterbrochen) oder asynchron (d.h. die Behandlung der Deadline kann parallel zur aktuellen Aktivität statt finden).
  • Die Simulationsinformation enthält Hinweise bzgl. der Simulation eines Modells. Beispiele sind Durchschnittskosten, erwartete Dauer und durchschnittliche Wartezeiten.
Wie in der obigen Abbildung gezeigt wird, kommen bei jeder Aktivität verschiedene Transitionen zusammen (join elements) und es gibt eine Menge von ausgehenden Transitionen (split elements). Eingehende Transitionen (join) und ausgehende Transitione (split) können jeweils entweder parallel oder alternativ ausgeführt werden. Alternativ ausgehende Transitionen (XOR) spezifizieren, dass genau eine der Transitionen ausgeführt werden darf. Alternativ eingehende Transitionen werden zur Synchronisation alternativ ausgehender Transitionen (split) verwendet. Die parallele Ausführung von Aktivitäten wird mit einem AND-split begonnen (d.h. parallele ausgehende Transitionen) und mit einem AND-join beendet (d.h. parallel eingehende Transitionen). Einschränkungen bzgl. der parallelen oder alternativen Verbindungen können über so genannte conformance classes spezifiziert werden:
  • Eine NON-BLOCKED conformance class stellt keine formale Bedingungen an die Verknüpfung von parallelen und alternativen ein- oder ausgehenden Transitionen.
  • Eine LOOP-BLOCKED conformance class erfordert, dass der Graph der aus den Aktivitäten gebildet wird, ein gerichteter azyklischer Graph ist (DAG).
  • Eine FULL-BLOCKED conformance class stellt die Bedingung, dass es zu jedem AND-split genau ein AND-join gibt, sowie zu jedem XOR-split genau ein XOR-join. Zusätzlich wird gefordert, dass jeder Pfad, der von einem Split ausgeht, das zugehörige Join erreichen muss.
Transitionen
Eine Transition beschreibt zumindest einen Teil des Kontrollflusses zwischen Aktivitäten. Die Information darüber, ob die ein- oder ausgehenden Transitionen alternativ oder parallel sind, wird der jeweiligen Aktivität zugeordnet. Zusätzliche Information über eine Transition wird in dem so genannten transition information-Element festgehalten. Dieses beinhaltet:
  • den Namen (d.h. eine Zeichenkette),
  • eine textuelle Beschreibung und
  • eine Bedingung.
Während die Beschreibung natürlichsprachlich formuliert wird, sollte die Bedingung zumindest semi-formal die Umstände für das Schalten einer Transition in einem boolschen Ausdruck spezifizieren. Zusätzlich wird hier der Start- und Endknoten festgehalten. Folglich wird jede Transition über genau eine Ursprungs-Aktivität (from) und genau eine Ziel-Aktivität (to) und einen boolschen Ausdruck, der die Schaltbedingung spezifiziert, beschrieben. Es gibt vier verschiedene Arten von Bedingungen in XPDL:
  • CONDITION: Eine Transition kann schalten, wenn die Bedingung als wahr ausgewertet wird.
  • OTHERWISE: Benennt eine Transition, die immer dann geschaltet wird, wenn keine andere Transition sich als wahr erweist.
  • EXCEPTION: Dies ist eine besondere Transition, die bspw. eine spezielle Bedingung anstoßen kann.
  • DEFAULTEXCEPTION: Wird angestoßen wenn alle anderen EXCEPTION conditions als 'false' ausgewertet wurden.
Top
Weitergehende Workflowkonzepte
Workflows werden von eine WfMS verwaltet und ausgeführt indem bestimmte Aufgaben (als Teil einer Workflowinstanz) einer bestimmten Ressource zugeordnet werden. Solch eine Ressource kann entweder eine Person sein (human participant) oder eine Workflowanwendung. Ein 'Human Participant' entspricht i. A. einer Rolle, die von einer bestimmten Person im Unternehmen eingenommen wird. Eine Workflowanwendung kann entweder intern vom WfMS bereitgestellt werden oder unabhängig vom WfMS über geeignete Schnittstellen verfügbar gemacht werden.

Da mit XPDL systemunabhängige Workflowbeschreibungen erstellt werden sollen, stellt XPDL nur abstrakte Konzepte für die Zuordnung von Humanressourcen und Softwareanwendungen bereit.
Workflow Participants
Entsprechend der XPDL-Spezifikation sind Workflowteilnehmer (Workflow Participants) "an abstraction level between the real performer and the activity, which has to be performed" [Nori02, p. 43]. Die Workflow Engine muss jeden abstrakten Teilnehmer (participant) auf einen Benutzer aus der Umgebung des WfMS abbilden. Die Beschreibung eines abstrakten Teilnehmers beinhaltet einen eindeutigen Namen und Typ. Mögliche Typen von Workflow-Teilnehmern sind:
  • RESOURCE: Eine spezifische Ressource, die dem WfMS zur Verfügung steht.
  • RESOURCE_SET: Eine Menge von Ressourcen.
  • ROLE: Ein Rollenbezeichner, der direkt mit einer Rolle in der Organisation übereinstimmt. Dies kann bspw. eine Funktion oder eine bestimmte Qualifikation sein.
  • ORGANIZATIONAL_UNIT: Ein beliebiges Element aus einem Organigramm.
  • HUMAN: Eine Person, die direkt mit dem WfMS interagiert (z.B.: 'John Miller')
  • SYSTEM: Eine Softwareanwendung, die als Teilnehmer in einem vollständig automatisierten Workflow auftritt.
Über das 'Performer'-Attribut einer Aktivität können diese Teilnehmer einer Aktivität in einem Workflow zugeordnet werden.
Workflow-Anwendungsdeklaration
Workflowanwendungen können in interne und externe Anwendungen unterteilt werden [Jung01]:
  • Eine interne Workflowanwendung wird als Teil des WfMS implementiert. Sie werden i. A. mit Hilfe einer proprietären Programmiersprache implementiert, die vom WfMS bereit gestellt wird. Im Rahmen von XPDL werden diese Anwendungen Prozeduren ('Procedures') genannt.
  • Eine externe Anwendung ist ein unabhängiges Softwarepaket, welches von dem WfMS genutzt wird.
In XPDL wird eine Workflowanwendung über einen eindeutigen Bezeichner, seinen Typ und die Liste der Parameter spezifiziert. Wie die Beschreibung der Workflow-Teilnehmer entspricht der Bezeichner einer Anwendung auch nur einem symbolischen Verweis. Die Interpratation eines solchen Verweises muss von dem jeweiligen WfMS übernommen werden. Es gibt WfMS die nur interne, nur externe oder auch beide Arten von Anwendungen unterstützen [Jung01].
Top



 Abbildung der Konzepte
Auf dieser Seite präsentieren wir die Abbildung von Konzepten der Geschäftsprozessmodellierung auf Workflow-Beschreibungen in XPDL.
Workflow-Prozessdefinitionen
Im Allgemeinen besteht jede Workflow-Prozessdefinition in XPDL aus Aktivitäten, Transitionen, Anwendungen, Teilnehmern und allgemeinen Eigenschaften eines Workflows. Somit umfasst solch eine Workflow-Prozessdefinition relevante Aktivitäten und entsprechende Ressourcen. Zusätzlich besteht eine Workflow-Prozessdefinition aus zwei unterschiedlichen Headern und einem Body. Die beiden Header sind der Definitions-Header und der neu definierbare Header (re-definable header). Der Definitions-Header eines Workflow-Prozesses ist gültig für alle Teilaktivitäten, der neu definierbare Header kann durch so genannte Subflows überschrieben werden. Die folgende Tabelle fasst die Hauptelemente der Workflowprozessdefinition in XPDL noch einmal zusammen:
NameBeschreibung
Definitions-Header
  • Meta-Informationen eines Prozesses und
  • Instanzenspezifische Daten
  • Z.B.: Version, temporäre Einheit, geschätzte Dauer, Priorität
Neu definierbarer Header
  • Meta-Informationen eines Workflow-Prozesses
  • Eigenschaften können in Subprozessen überschrieben werden
  • Z.B.: Autor, Publikationsstatus
Aktivitätenmenge
  • Menge von Aktivitäten und Transitionen
Definitions-Header für Workflow-Prozesse
Attribute eines Definitions-Headers für Workflow-Prozesse sind in der Tabelle auf der rechten Seite aufgelistet1. Das Erstellungsdatum wird einer Prozessdefinition während ihrer Definition zugeordnet und repräsentiert somit die Definitionszeit eines Workflow-Schemas. Diese Information kann dem MEMO-OrgML unterstützenden Modellierungstool entnommen werden und ist nicht Teil der MEMO-Sprachspezifikation. Die Workflow-Prozessbeschreibung kann als Beschreibung des Prozesses der obersten Ebene einer Dekompositions-Hierarchie in MEMO-OrgML angesehen werden.
Die Gülitg-von- und Gültig-bis-Attribute erlauben die Spezifikation einer Zeitspanne für die Gültigkeit einer Prozessdefinition. Somit kann eine Prozessdefinition nur zwischen gültig von und gültig bis genutzt werden (ein leerer String bedeutet unbegrenzte Gültigkeit). Da MEMO-OrgML kein äquivalentes Konzept aufweist, wird stets von einer unbegrenzten Gültigkeit für alle Prozesse ausgegangen. Die anderen Attribute enthalten nur Informationen zu Workflow-Instanzen. Die Dauer- und Grenzattribute (die Grenze muss durch ein spezifisches WfMS interpretiert werden und hat im Kontext von XPDL keine Bedeutung) beinhalten die erwartete Dauer der Ausführung des gegebenen Workflow-Prozesses durch die Nutzung einer spezifischen Dauereinheit. Die Zeitschätzung ist eine Aggregation von Warte- und Arbeitszeit sowie der Dauer. Die Wartezeit bezieht sich auf die Vorbereitungszeit einer Prozessausführung, während die Arbeitszeit mit der erwarteten Ausführungszeit korreliert. Diese Konzepte sind in MEMO-OrgML nicht enthalten und müssen den Prozessmodellen hinzugefügt werden.
OrgML (Meta-Daten)XPDL: Definitions-Header
Erstellungsdatum (meta)Erstellt (Erstellungsdatum)
ProzessbeschreibungBeschreibung
 -Dauer & Dauereinheit
 -Grenze (anbieterspezifisch)
 -Priorität
 -Zeitschätzung
 -Gültig von/bis
 -Wartezeit
 -Arbeitszeit
Neu definierbarer Header für Workflow-Prozesse
Die Attribute eines neu definierbaren Headers für Workflow-Prozesse sind in der Abbildung auf der rechten Seite aufgelistet. Die Meta-Informationen über den Autor und die Version eines Modells können aus den im Modellierungstool verfügbaren Daten abgeleitet werden. Die Annotation einer Codepage hat einen eher technischen Grund; sie spezifiziert die Zeichenmenge, die zur Präsentation von Text genutzt wird. Länderschlüssel werden durch die ISO im ISO 3166 Standard spezifiziert. Der Publikationsstatus gibt an, ob eine Prozessdefinition in Revision (UNDER_REVISION), veröffentlicht (RELEASED) oder im Einsatz (UNDER_TEST) ist. Verantwortlich bezieht sich auf die für die Ausführung eines gegebenen Workflow-Prozesses verantwortliche Organisationseinheit. Die verantwortliche Person bzw. Rolle kann von der Organisationseinheit im MEMO-Diagramm abgeleitet werden.
OrgML (Meta-Daten)XPDL: Neu definierbarer Header
Modellierer (meta)Autor
 - Codepage
 -Länderschlüssel
 -Publikationsstatus
OrganisationseinheitVerantwortliche(r)
Version (meta)Version
Generierung von Headern
XPDL-Workflow-Header beinhalten Informationen über einen Workflow-Prozess (z.B. Autor, Version), Prozessinformationen (z.B. Beschreibung, Verantwortliche) und Informationen zu Instanzen (z.B. Dauer, Zeitschätzung). Diese Art von Informationen gehören zu keiner Sprachspezifikation. Stattdessen können sie durch ein Modellierungstool verwaltet und dann direkt auf eine XPDL-basierte Beschreibung abgebildet werden. Einige Prozessinformationen (z.B. Priorität) sind in MEMO-OrgML noch nicht verfügbar und müssen durch eine Prozessdefinition ergänzt werden. Instanzenspezifische Informationen sollten in einer Geschäftsprozess-Modellierungssprache zur konzeptionellen Modellierung nicht enthalten sein. Sie könnten lediglich als zusätzliche Informationen (wie ein Workflow-Diagramm für Geschäftsprozesse) für existierende Geschäftsprozesse auf einer anderen Abstraktionsebene dienen.
Oben
Abbildung von Ressourcen, Anwendungen und relevanten Informationen
Auf den ersten Blick könnte der Eindruck entstehen, dass die Abbildung von Ressourcen auf Workflow-Teilnehmer, Workflow-Anwendungen und Workflow-relevante Daten einfach ist. Diese Aufgabe wird jedoch von einigen Details bzgl. der Abstraktion von Ressourcen einerseits und den in XPDL gegebenen Konzepten andererseits behindert.
Human-Ressourcen
In Anlehnung an MEMO-OrgML ist eine menschliche Ressource eine Abstraktion von Personen, Angestellten, Rollen oder anderen mitarbeiterbezogenen Aspekten. In XPDL ist ein Workflow-Teilnehmer eine Abstraktionsebene zwischen dem realen Ausführenden und der Aktivität, die ausgeführt werden muss. Während der Laufzeit werden diese abstrakten Definitionen evaluiert und konkreten Menschen und/oder Programmen zugeordnet [Nori02, S. 43]. Die Abbildung eines abstrakten Akteurs (wie in einer XPDL-Beschreibung gegeben) auf einen konkreten Akteur (z.B. der Anwender eines WfMS) muss durch das Workflow-Management-System erfolgen.
Wie in der Tabelle auf der rechten Seite zu sehen ist, können Name und Beschreibung der Ressourcen-Eigenschaften direkt auf eine XPDL-Datei abgebildet werden. Die Eigenschaften-Attribute Qualifikation und KompetenzProfil werden vernachlässigt, da sie keine direkte Übereinstimmung in XPDL besitzen. Ein von XPDL benötigter eindeutiger Bezeichner kann während der Abbildung von OrgML auf XPDL generiert werden.
Die Spezifikationen von "Teilnehmertyp", "erweiterte Attribute" und "externe Referenzen" sind eine Erweiterung eines Geschäftsprozessmodells (mit MEMO-OrgML modelliert). Alternativen für einen Teilnehmertyp sind Ressurcen, Rollen, Organisationseinheiten, Menschen und Softwaresysteme [Nori02, S. 44].
OrgML: Human-RessourceXPDL: Teilnehmer
 -ID
NameName
BeschreibungBeschreibung
 -Teilnehmertyp
 -Erweiterte Attribute
 -Externe Referenzen
Attribute -
Qualifikation -
KompetenzProfil -
Erweiterte Attribute sind Name-Wert-Paare und erlauben die Annotation von systemspezifischen Informationen für verschiedene WfMS-Produkte. (Beachten Sie den Unterschied zwischen Ressourcen-Attributen und erweiterten Attributen: Ein Ressourcen-Attribut ist ein Name-Typ-Paar, ein erweitertes Attribut dagegen ein Name-Wert-Paar.) Der Name wird zur Identifikation des erweiterten Attributs genutzt und der Wert enthält für bestimmte WfMS relevante Informationen. Eine externe Referenz ist eine Referenz auf ein externes Dokument, das die Spezifikation einer Einheit enthält, die im Zusammenhang mit dem Workflow steht. Ein solches Dokument kann z.B. eine global verfügbare XML-DTD (zur Spezifikation der Struktur einer Workflow-Einheit) oder eine Schnittstellendefinition von Web-Services (mittels WSDL) sein. Alle genannten Erweiterungen müssen von einer workflowspezifischen Erweiterung von Geschäftsprozessmodellen zur Verfügung gestellt werden.
Software
Die Deklaration einer Workflow-Anwendung in XPDL verweist i. A. auf eine Software, die innerhalb eines Geschäftsprozesses genutzt wird. Eine Workflow-Anwendung repräsentiert ein Software-Tool, das für die Ausführung eines Workflows benötigt wird. Beliebige Anwendungen können durch das WfMS aufgerufen werden, da XPDL von konkreten Implementierungen abstrahiert. Jede Anwendung wird in XPDL als symbolische Referenz definiert, die durch das WfMS konkreten Anwendungen zugeordnet werden muss.
Die Ressourcen-Eigenschaften (bzgl. Software) Name und Beschreibung können direkt auf ein XPDL-Dokument abgebildet werden. Die Eigenschaften SystemAnforderungen und Skalierbarkeit werden vernachlässigt, da sie keine Übereinstimmung in XPDL besitzen. XPDL benötigt einen eindeutigen Bezeichner, der in MEMO-OrgML nicht ausgedrückt werden kann. Dennoch kann solch ein Bezeichner OrgML-Modellen explizit zugeordnet werden (was eine kleine Erweiterung der Sprache erfordern würde) oder während der automatischen Abbildung von OrgML auf XPDL generiert werden. Externe Attribute und externe Referenzen werden wie die gleichen Attribute der Human-Ressourcen (siehe oben) behandelt.
Das Attribut "Formale Parameter" entspricht einer Liste von einzelnen formalen Parametern, die durch folgende Eigenschaften spezifiziert werden:
  • ID: Bezeichner
  • Datentyp: Typ des formalen Parameters
  • Beschreibung: Textuelle Beschreibung des formalen Parameters
  • Index: Position in der Parameterliste
  • Modus:
    • IN: read-only Parameter
    • OUT: write-only Parameter
    • INOUT: Parameter, die als Input- und Output-Parameter genutzt werden
Die ID eines formalen Parameters muss innerhalb des Namensraums eines Prozesses eindeutig sein.
OrgML: SoftwareXPDL: Anwendung
 -ID
NameName
BeschreibungBeschreibung
 -Formale Parameter
 -Erweiterte Attribute
 -Externe Referenzen
SystemAnforderungen -
Skalierbarkeit -
Informationen
In der Geschäftsprozessmodellierung entspricht die Beschreibung von Informationen normalerweise der Spezifikation von Informationstypen, die innerhalb eines Geschäftsprozesses genutzt werden. Im Gegensatz dazu werden workflowrelevante Daten mit Variablen assoziiert, die konkrete Informationen enthalten. Diese Variablen werden im Allgemeinen durch einen eindeutigen Namen referenziert (als Bezeichner) und entsprechen einem gegebenen Typ.
Eine geeignete ID für eine Workflow-Spezifikation kann automatisch generiert werden. Name, Beschreibung und Datentyp können direkt aus den korrespondierenden Attributen des MEMO-Prozessmodells abgeleitet werden (siehe die Tabelle auf der rechten Seite). Erweiterte Attribute werden wie die erweiterten Attribute von Human-Ressourcen und Anwendungen behandelt. Zusätzlich kann einer Variable ein initialer Wert zugeordnet werden. Ob eine Variable von einem komplexen Datentyp ist und welche Länge sie haben kann, wird durch die Attribute IsArray (die Variable ist ein mehrwertiger Typ) und Länge (obere Grenze einer Sequenz) bestimmt.
OrgML: InformationenXPDL: Data
 -Id
NameName
BeschreibungBeschreibung
TypBeschreibungDatentyp
 -Erweiterte Attribute
 -Initialer Wert
 -Is Array
 -Länge
Oben
Abbildung von Prozesstypen
MEMO-OrgML unterstützt mehrere unterschiedliche Arten von Prozesstypen, die auf entsprechende in XPDL gegebene Konzepte abgebildet werden müssen. In MEMO-OrgML sind Konzepte wie komponierte, manuelle, automatisierte und teilautomatisierte Prozesse vorhanden. In XPDL existieren generische und Block-Aktivitäten. In diesem Abschnitt werden konzeptionelle Beziehungen zwischen MEMO-OrgML-Prozessen und XPDL-Aktivitäten diskutiert.
Manuelle Prozesse
Es gibt verschiedene alternative Optionen zur Abbildung manueller Prozesse auf Workflows (vgl. den entsprechenden Arbeitsbericht für weitere Informationen). Die gewählte Alternative beinhaltet die Abbildung von manuellen Prozessen auf Workflow-Aktivitäten. Jeder manuelle Prozess wird mit einem menschlichen Akteur und ohne Anwendung (application) auf eine Aktivität abgebildet. Somit entsprechen manuelle Prozesse einer Art Dummy-Aktivität in einem Workflow-Schema. Solch eine Dummy-Aktivität dient nur der Vollständigkeit eines manuellen Prozesses. Das Ende eines manuellen Prozesses kann den Start eines folgenden Prozesses auslösen. Daraus folgt die notwendige Bestätigung jeder manuellen Aktivität im WfMS. Auf diese Weise können der Prozess an sich sowie entsprechende Teilnehmer (menschliche Ressourcen) auf das Workflow-Modell abgebildet werden.
OrgML: Manueller ProzessXPDL: Generische Aktivität
IDID
NameName
BeschreibungBeschreibung
OrganisationseinheitAusführender
 -Transitions-Restriktionen:
  • Join: AND, XOR
  • Split: AND, XOR
Die ID wird aus dem Bezeichner des manuellen Prozesses generiert und die Attribute Name und Beschreibung können direkt von der Prozessdefinition auf das XPDL-Dokument abgebildet werden. Die Organisationseinheit eines manuellen Prozesses kann auf den Ausführenden der Workflow-Aktivität abgebildet werden. Die Transitions-Restriktion spezifiziert, ob alle eingehenden Transitionen (Join) synchronisiert (AND) oder alternativ (XOR) und ob alle ausgehenden Transitionen (Split) parallel (AND) oder alternativ (XOR) sind. Diese Informationen werden durch die Art der ein- und ausgehenden Kanten des Geschäftsprozessmodells bestimmt.
Ein paralleler Split wird auf einen AND-Split, ein alternativer Split auf einen XOR-Split abgebildet. Analog dazu wird ein paralleler Join auf einen AND-Join und ein alternativer Join auf einen XOR-Join abgebildet. Informationen, die nicht im Geschäftsprozessmodell enthalten, jedoch notwendig für die Spezifikation einer Workflow-Aktivität sind, werden in der Tabelle unten aufgelistet.
Da die meisten workflowrelevanten Daten nicht in einem Geschäftsprozessmodell enthalten sind, wird eine Erweiterung dieser Modelle benötigt. Wir erstellen für jeden Geschäftsprozess ein so genanntes Workflow-Diagram, das auf ein Workflow-Schema abgebildet werden muss. Dieses Diagramm enthält alle zusätzlichen Informationen für die Implementierung und Simulation von Geschäftsprozessen in einer Workflowumgebung.
AttributBeschreibung
DeadlineSpezifikation einer Deadline und einer Aktion, die auszuführen ist, wenn die Deadline erreicht ist.
DokumentationBezeichner einer externen Dokumentationsdatei (z.B. URL oder ein Dateiname).
StartmodusManueller Modus: Der Anwender muss die Aktivität manuell starten (um auf den Beginn seiner Arbeit hinzuweisen)
Endmodus Manueller Modus: Das Ende der Aktivität muss über eine Interaktion des Anwenders angezeigt werden.
ImplementierungNein: Implementierung durch manuelle Prozeduren
IconReferenz auf eine externe Datei, die eine Grafik für die Repräsentation einer Aktivität enthält.
GrenzeErwartete maximale Dauer der Ausführung eines Prozesses (anbieterspezifisch)
PrioritätEin Wert, der die initiale Priorität eines Prozesses beschreibt.
SimulationsinformationenSchätzungen für die Simulation einer Aktivität.
Teilautomatisierte Prozesse
In MEMO-OrgML werden teilautomatisierte Prozesse durch menschliche Ressourcen ausgeführt, wobei IT-Ressourcen (Soft- und Hardware) verwendet werden. Somit basieren teilautomatisierte Prozesse auf menschlichen und softwaretechnischen Ressourcen. Diese Art von Prozessen kann auf generische Aktivitäten abgebildet werden.
Die Abbildung von allgemeinen Informationen auf einen teilautomatisierten Prozess ist äquivalent zur Abbildung auf einen manuellen Prozess. Die meisten workflowspezifischen Informationen können durch die Nutzung eines Workflow-Diagramms generiert werden. Zusätzlich sind Start- und Endmodus sowie die Implementierung des Prozesses festzulegen.
AttributBeschreibung
StartmodusManueller Modus: Der Anwender muss die Aktivität manuell starten (um auf den Beginn seiner Arbeit hinzuweisen)
Endmodus Manueller Modus: Das Ende der Aktivität muss über eine Interaktion des Anwenders angezeigt werden.
ImplementierungTool: Die Implementierung wird durch eine Anwendung unterstützt.
Vollautomatisierte Prozesse
Ein automatisierter Prozess wird ohne die Intervention von menschlichen Beteiligten ausgeführt. Trotzdem kann einem automatisierten Prozess eine Organisationseinheit zugeordnet werden; d.h. sie ist verantwortlich für die Ausführung dieses Prozesses. Grundsätzlich kann die Abbildung eines automatisierten Prozesses wie die eines manuellen Prozesses gehandhabt werden (siehe Tabelle). Im Gegensatz zu einem manuellen oder teilautomatisierten Prozess hat die Zuordnung eines Ausführenden keine Auswirkung auf die Ausführung eines automatisierten Prozesses.
AttributBeschreibung
StartmodusAutomatisiert: Durch das System ausgelöst.
EndmodusAutomatisiert: Durch das System ausgelöst.
ImplementierungTool: Die Implementierung wird durch eine Anwendung unterstützt.
Aggregierte Prozesse
Aggregierte Prozesse in MEMO-OrgML haben keine inhärente Implementierung, sondern bestehen aus anderen Prozessen. Eine Block-Aktivität in XPDL entspricht einer Menge von Subaktivitäten und hat keine eigenen Ressourcen. Wir werden keine Teilflüsse nutzen, da jeder Teilfluss seine eigene Menge von Ausführenden und Tools enthält und Namensräume in OrgML nicht unterstützt werden. Dennoch wird jeder aggregierte Prozess auf eine Block-Aktivität abgebildet und alle enthaltenen Prozesse werden in einer Aktivitätenmenge gesammelt.
Abbildung von Kontrollfluss und Ereignissen
Die Art des Kontrollflusses wird durch die Definition der Workflow-Aktivität bestimmt. Alle ausgehenden Transitionen einer Aktivität sind entweder parallel (AND) oder alternativ (XOR). Gleichsam ist jeder Join (eingehende Transition) entweder eine parallele oder alternative Synchronisation. Die Spezifikation von Joins und Splits wird mit einer Prozessdefinition assoziiert.
In XPDL existieren keine Ereignisse als spezifische Konzepte. Daher existiert keine direkte Übereinstimmung zwischen Ereignissen in einem Geschäftsprozessmodell und einem Workflow-Schema. Nichtsdestotrotz können in einem Geschäftsprozessmodell vorhandene Ereignisse zur Definition der Schaltungsbedingungen einer Transition genutzt werden. Wie in der Tabelle auf der rechten Seite zu sehen ist, kann der Name und die Beschreibung eines Ereignisses auf eine XPDL-Beschreibung abgebildet werden. Die ID kann aus der Ereignis-ID und dem Kontext erstellt werden. Die Bedingung muss der Aktivitätenbeschreibung hinzugefügt werden. Vorangehende und nachfolgende Aktivitäten können aus dem Geschäftsprozessmodell abgeleitet werden.
OrgML: EreignisXPDL: Transitions-Information
IDID
NameName
BeschreibungBeschreibung
TypBeschreibungBedingung
 -Von (Menge von Aktivitäten)
 -Nach (Menge von Aktivitäten)
Oben
Fußnoten:
  1. Für ein verbesserte Lesbarkeit wurden die XPDL-Attributnamen auf dieser Seite ins Deutsche übersetzt. Die englischen Attributnamen können Sie auf der zugehörigen englischsprachigen Seite nachlesen.



 Implementierungsaspekte
Als Grundlage für die Entwicklung eines Prototypen zur Softwaregenerierung dient die Abbildung von Geschäftsprozessmodellen auf XPDL-Dokumente. Die zugrunde liegende Vision ist die automatische Generierung von Software (d.h. ausführbarer Programme) aus Modellen. Um dieses Ziel zu erreichen, nutzten wir den folgenden Ansatz:
  1. Erstellung von Geschäftsprozessmodellen mit MEMO-OrgML

  2. Erweiterung der Geschäftsprozessmodelle um workflowrelevante Informationen

  3. Abbildung der Geschäftsprozessmodelle auf XPDL-Dokumente

  4. Ausführung der Prozesse, basierend auf den XPDL-Dokumenten mittels einer Workflow-Engine
    (einschließlich dem Import der XPDL-Beschreibung in das WfMS und der Anpassung des WfMS)
MetaEdit+ 4 und die Shark Workflow Engine von Enhydra wurden zur Entwicklung eines Prototypen der Softwaregenerierung verwendet.

(Download: Patch für Import in MetaEdit)


Implementierung einer Modellierungssprache mit MetaEdit+
Wir implementierten ein MEMO-OrgML Modellierungstool mit MetaEdit+. MetaEdit+ ist ein Werkzeug zur Entwicklung von Modellierungstools und momentan in Version 4 verfügbar. Grundlegende Konzepte von MetaEdit+ sind Objekte, Beziehungen, Rollen und Diagramme.
  • Objekte repräsentieren die Knoten innerhalb eines Diagramms.
  • Beziehungen repräsentieren die Kanten zwischen Objekten.
  • Rollen spezifizieren zusätzliche Informationen über die Erscheinung eines Objektes in einer gegebenen Beziehung.
  • Gültige Verbindungen von Objekten durch Beziehungen unter der Nutzung von Rollen werden in Diagrammen definiert.
Implementierung von MEMO-OrgML
Es wurden die zwei wichtigsten Diagrammtypen (MEMO-OrgML) implementiert: Dekompositionsdiagramme und Prozessmodelle. Ein Prozess-Dekompositions-Diagramm formuliert Dekompositions-Beziehungen zwischen Prozessen. Jeder komponierte Prozess besteht aus elementaren und/oder komponierten Prozessen. Jeder untergeordnete Prozess (bzgl. einer Dekompositions-Beziehung) dient als ein Teil. Ein Teil kann entweder ein anderer komponierter oder ein elementarer Prozess sein.

Ein komponierter Prozess in einem Prozess-Dekompositions-Diagramm kann durch ein Prozessmodell-Diagramm weiter spezifiziert werden. Solch ein Diagramm kann durch eine so genannte Explosion mit einem gegebenen Modellelement verknüpft werden. Eine Explosion ist ein in MetaEdit+ enthaltenes Konzept, das die Verknüpfung eines Objektes in einem Diagramm mit einem anderen Diagramm erlaubt. Dieses Konzept kann zur Verknüpfung eines komponierten Prozesses mit einem Prozessmodell-Diagramm genutzt werden. (Für weitere Informationen und Beispiele siehe den entsprechenden Arbeitsbericht.)
Implementierung zusätzlicher Diagramme
Um ein Geschäftsprozessmodell auf ein XPDL-Dokument abzubilden, müssen dem Geschäftsprozessmodell fehlende Informationen hinzugefügt werden. Der Abschnitt über die konzeptionelle Abbildung beschreibt Regeln zur Abbildung der Konzepte von MEMO-OrgML auf XPDL-Konzepte. Da die Sprachkonzepte von MEMO-OrgML noch nicht abschließend dokumentiert sind, haben wir uns - aus praktischen Gründen - für eine Erweiterung der existierenden Prozessmodellierungs-Konzepte um zusätzliche Diagramme entschieden, die die für eine gültige XPDL-Beschreibung benötigten Informationen enthalten. Um dieses Ziel zu erreichen, wurden zwei Diagrammtypen hinzugefügt: Das Workflow-Spezifikations-Diagramm und das Workflowaktivitäten-Spezifikations-Diagramm. Ein Workflow-Spezifikations-Diagramm ergänzt ein Geschäftsprozessmodell um Abstraktionen hinsichtlich des Workflows. Dieser Diagrammtyp beinhaltet Objekte der folgenden Typen:
  • Workflow-Prozess: Ein Workflow-Prozess enthält eine Referenz auf einen entsprechenden Geschäftsprozess. Dieser korrespondierende Geschäftsprozess ist im Allgemeinen ein komponierter Prozess, der wiederum aus anderen Geschäftsprozessen und ihren Kontrollflüssen besteht. Geschäftsprozesse werden entsprechend der Regeln im Abschnitt über die Abbildung auf XPDL-Aktivitäten abgebildet. Zusätzlich ist ein Link auf die Dokumentation eines Geschäftsprozesses und die Annotation von erweiterten Attributen möglich.

  • Workflow-Teilnehmer: Ein Workflow-Teilnehmer ist ein XPDL-spezifisches Konzept, das den Akteur eines Workflows bestimmt. Solch ein Teilnehmer wird mit einer Organisationseinheit in MEMO-OrgML assoziiert und durch erweiterte Attribute sowie einer Teilnehmerklassifizierung ergänzt. Mögliche Teilnehmerklassifizierungen sind im Abschnitt über Workflowmodellierung aufgeführt.

  • Workflow-Anwendung: Eine Anwendung (Application) ist die Spezifikation eines Werkzeugs mit Bezug auf den jeweiligen Workflow. Solch ein Werkzeug kann entweder eine interne Prozedur oder eine externe Anwendung sein (der Abschnitt über Workflowmodellierung enthält weitere Informationen hierzu). Das Anwendungsobjekt in einer Workflow-Spezifikation enthält einen eindeutigen Bezeichner, den Namen und formale Parameter einer Workflow-Anwendung.

  • Workflow-Informationen: Ein Workflow-Informationen-Objekt spezifiziert die innerhalb eines Workflows genutzten Informationen und kann als Variable angesehen werden. Diese Spezifikation beinhaltet einen eindeutigen Bezeichner, einen Namen und einen Datentyp sowie einen Defaultwert und andere XPDL-spezifische Aspekte (siehe Abschnitt Abbildung der Konzepte).

Ein Workflowaktivitäten-Spezifikations-Diagramm wird mit einem elementaren Prozess assoziiert (durch Nutzung einer Explosion). Die Workflowaktivitäten-Spezifikation beschreibt die Workflow-Anwendung sowie aktuelle Parameter, die für die Ausführung eines solchen Prozesses genutzt werden. Im Allgemeinen assoziiert ein Workflowaktivitäten-Spezifikations-Diagramm also einen Prozess mit einer Anwendung und ordnet aktuelle Parameter zu. Somit bindet eine mit einem Prozess assoziierte Aktivitäten-Spezifikation eine Anwendung an Workflow-Informationen. Zusätzlich wird spezifiziert, ob eine Anwendung eine interne Prozedur oder ein externes Werkzeug darstellt.
Oben
Generierung von XPDL-Dokumenten mit MetaEdit+
Die Abbildung von MEMO-OrgML-Modellen auf XPDL-konforme Workflow-Definitionen wird durch die Nutzung des Codegenerierungs-Mechanismus von MetaEdit+ realisiert. MetaEdit+ enthält eine Sprache für die Spezifikation von Abbildungen zwischen internen Modellen und externen textuellen Spezifikationen. Jede Workflowprozess-Spezifikation wird auf eine XPDL-Datei abgebildet. Der Header der XML-Datei basiert auf der Prozessdefinitionssprache und beginnt mit dem XML-Header (der die XML-Version und die Zeichencodierung bestimmt). Die WfMC empfiehlt die Generierung von mindestens einem Package für jede XPDL-Datei [Nori02, S. 19]. (Für detaillierte Informationen über die Struktur und die Syntx des Headers siehe den entsprechenden Arbeitsbericht.)

Jede generierte XPDL-Datei besteht aus genau einer Package-Definition und einer in diesem Package enthaltenen Workflow-Definition. Die Workflow-Definition besteht aus den folgenden Teildefinitionen:

  • Datenfelder
  • Teilnehmer
  • Anwendungen
  • Aktivitätenmengen
  • Aktivitäten
  • Transitionen

Die Spezifiktation von Datenfeldern, Teilnehmern und Anwendungen wird aus den Workflow-Spezifikations-Diagrammen abgeleitet. Anschließend werden die Aktivitätenmengen auf der Basis des Workflow-Spezifikations-Diagramms generiert. Für jeden komponierten Prozess im Dekompositionsdiagramm gibt es eine Aktivitätenmenge (ausgenommen des Wurzel-Prozesses). Der Wurzel-Prozess wird auf die Package-Spezifikation und die Workflowprozess-Spezifikation abgebildet. Jeder komponierte Prozess, der Teil der Komposition des Wurzel-Prozesses ist, wird auf eine Aktivitätenmenge abgebildet. Jede Aktivitätenmenge enthält die zugehörigen Prozesse sowie ihre Transitionen.
Nach der Generierung des Headers, der Datenfelder des Workflowprozesses, den Teilnehmern und Anwendungen sowie den Aktivitätenmengen werden MEMO-OrgML-Prozesse auf Workflowaktivitäten abgebildet. Jeder Prozess (komponiert oder elementar) wird mittels der direkten Abbildung, die hier beispielhaft erläutert wird, und den Regeln in der Tabelle auf der rechten Seite auf genau eine Aktivität abgebildet.
  • Ein manueller Prozess wird durch einen Menschen ausgeführt und benötigt keine IT-Ressourcen. Daher benötigt die korrespondierende Aktivitäten-Spezifikation einen Workflow-Teilnehmer und erlaubt keine Annotation von Workflow-Anwendungen. Die Workflowaktivität muss manuell gestartet und auch manuell beendet werden.
  • Ein teilautomatisierter Prozess benötigt ebenfalls einen Teilnehmer, jedoch muss auch eine Workflow-Anwendung spezifiziert werden. Sie muss durch den menschlichen Teilnehmer gestartet und beendet werden.
  • Ein automatisierter Prozess wird automatisch (durch das WfMS) gestartet und beendet. Er benötigt nicht notwendigerweise einen Teilnehmer (dieser kann annotiert werden), jedoch eine Workflow-Anwendung.
  • Eine Block-Aktivität enthält eine Menge von Aktivitäten (eine Aktivitätenmenge) und benötigt weder einen Teilnehmer, noch eine Anwendung. Daher wird ein komponierter Prozess auf eine Blockaktivität (sowie eine Aktivitätenmenge, die seine nachfolgenden Prozesse beinhaltet) abgebildet.
Prozesstyp (MEMO OrgML)Aktivitäten-Spezifikation in XPDL
Manueller ProzessTeilnehmer: notwendig
Anwendung: nicht anwendbar
Startmodus: manuell
Endmodus: manuell
Teilautomatisierter ProzessTeilnehmer: notwendig
Anwendung: notwendig
Startmodus: manuell
Endmodus: manuell
Automatisierter ProzessTeilnehmer: nicht notwendig
Anwendung: notwendigt
Startmodus: automatisch
Endmodus: automatisch
Komponierter ProzessTeilnehmer: nicht notwendig
Anwendung: nicht notwendig
Startmodus: nicht anwendbar
Endmodus: nicht anwendbar
Eine Transition zwischen zwei Workflowaktivitäten entspricht einer gefolgt-von Beziehung. Eine in Aktivität A beginnende und in Aktivität B endende Transition bedeutet, dass Aktivität B (erst) nach der Terminierung von Aktivität A gestartet werden kann. Informationen über die Art des Kontrollflusses sind in einer Transitionen-Spezifikation nicht enthalten. Sie sind jedoch Teil der Aktivitäten-Spezifikation. Ein weiterer konzeptioneller Unterschied zwischen Prozessmodellen in MEMO-OrgML und XPDL-Aktivitäten sind die fehlenden Ereignisse in einer Workflow-Spezifikation. Die Abbildung des Kontrollflusses in MEMO-OrgMl auf XPDL-Transitionen wird durch ein abstraktes Beispiel in der Abbildung unten erläutert. Dieses Beispiel besteht aus vier Prozessen und drei Ereignissen. Prozess A wird von Ereignis Nr. 10 gefolgt, das wiederum in der parallelen (oder nebenläufigen) Ausführung von Prozess B und C mündet. Die Terminierung von Prozess B ist an das Eintreten von Ereignis Nr. 11 geknüpft, die von C an das Eintreten von Nr. 12. Wenn beide Ereignisse eingetreten sind (paralleler Join), kann Prozess D gestartet werden.
Die Generierung von Transitionen basiert auf einem einfachen Algorithmus: Jedes MEMO-Ereignis wird auf midestens eine Transition abgebildet. Für jede Kombination aus Start- (von) und Endpunkten (nach) existiert eine Transition. Das im obigen Modell enthaltene Ereignis Nr. 10 wird bspw. auf zwei Transitionen abgebildet: Eine Transition von A nach B und eine von A nach C. Der eindeutige Bezeichner jeder Transition wird durch die Konkatenation der Bezeichner des vorangehenden Prozesses, der Ereignis-ID und dem Bezeichner des nachfolgenden Prozesses generiert. Informationen über die Art des Kontrollflusses werden mit dem vorangehenden Prozess assoziiert. Die Beschränkung der Split-Transition von Prozess A wird auf AND gesetzt. Die Ereignisse 11 und 12 werden auf jeweils eine Transition abgebildet und die Beschränkung der Join-Transition von Prozess D wird auf AND gesetzt.
Oben
Nutzung von Shark/Enhydra als Workflow Engine
Für die Ausführung von XPDL-Dateien wurde eine in der Programmiersprache Java implementierte frei verfügbare (open source) Workflow-Engine genutzt. Die Shark-Engine unterstützt den XPDL-Standard der WfMC vollständig und erlaubt die Assoziation von Workflow-Teilnehmern mit konkreten Benutzern sowie von Workflow-Anwendungen (in XPDL) mit Prozeduren.
Abbildung von Teilnehmern auf Benutzer
Workflow-Teilnehmer können durch Nutzung der hier aufgeführten XPDL-Konzepte deklariert werden. Verschiedene Typen von Teilnehmern sind
  • Ressource (auch: Ressourcenmenge)
  • Rolle
  • Organisationseinheit
  • Person
  • System
Die Shark-Engine stellt einen Mechanismus zur Assoziation von Teilnehmern mit spezifischen Benutzern des WfMSs zur Verfügung. Dieser ist anwendbar, wenn der Teilnehmer vom Typ Ressource (Ressourcenmenge), Rolle oder Organisationseinheit ist. In Abhängigkeit vom Kontext kann bspw. die Rolle eines Sachbearbeiters einem spezifischen Benutzer zugeordnet werden und nach der Reorganisation des Unternehmens einem anderen Benutzer neu zugeordnet werden. Falls ein Teilnehmer nicht automatisch auf einen Shark-Benutzer abgebildet werden kann, wird die Aktivität dem Administrator zugeordnet. Falls der Teilnehmertyp 'Person' (human resource) ist, wird der Teilnehmer auf den WfMS-Benutzer mit demselben Namen abgebildet. Zum Beispiel: Ein Workflow-Teilnehmer des Typs Mensch mit dem Namen jjung wird mit dem lokalen Benutzer (in der Enhydra Shark-Engine) namens jjung assoziiert. Falls der Teilnehmer vom Typ 'System' ist, wird von einem Softwaresystem als Akteur ausgegangen und die Aktivität wird von einer Workflow-Anwendung ausgeführt. Somit muss die Assoziation von Workflow-Teilnehmern mit WfMS-Benutzern normalerweise durch einen Administrator definiert werden. Eine solche Assoziation wird für menschliche Teilnehmer und Softwaresysteme ausgelassen. Im letzteren Fall kann die Workflow-Engine die Zuordnung automatisch durchführen.
Aktualisierung von Workflowdaten
Der XPDL-Standard stellt keinen Mechanismus zur Manipulation von workflowrelevanten Daten zur Verfügung, ausgenommen der Ausführung von Workflow-Anwendungen. Die Shark-Engine erlaubt die Manipulation von Daten durch die Nutzung erweiterter Attribute für Workflowaktivitäten. Im Folgenden werden die zusätzlichen Attribute aufgelistet:
  • Name: VariableToProcess_UPDATE  -  Wert: <workflow-data>
  • Name: VariableToProcess_VIEW  -  Wert: <workflow-data>
Das erste Attribut spezifiziert Daten, die in Rahmen einer Workflowaktivität manipuliert werden können, das zweite erlaubt nur die Anzeige eines Variablenwertes. Der symbolische Bezeichner <workflow-data> muss durch einen spezifischen Namen der Workflowdaten ersetzt werden.
Abbildung von Workflow-Anwendungen auf Prozeduren/Anwendungen
Eine Workflow-Anwendung wird durch eine Anwendungsdeklaration (wie hier erläutert) in einem XPDL-Dokument spezifiziert. Eine solche Spezifikation enthält lediglich eine symbolische Referenz auf eine konkrete Anwendung. Normalerweise unterscheidet die WfMC zwischen einer Prozedur (eine im WfMS implementierte Anwendung) und einer Anwendung (eine externe Softwarekomponente). Die aktuelle Version der Shark-Engine unterstützt nur in Java implementierte interne Prozeduren. Die Assoziation einer Workflow-Anwendung mit einer Prozedur wird durch die Shark-Engine durchgeführt. Jede Anwendung, die in einer XPDL-Spezifikation enthalten ist, muss mit einer Java-Klasse assoziiert werden, die unter Kontrolle der Shark-Engine steht. Eine solche Java-Klasse muss im Storedprocedure-Verzeichnis der Shark-Installation abgelegt sein und muss eine 'public static' Methode namens execute ohne Rückgabewert implementieren.
Oben



 Literatur
Dieser Abschnitt zum Thema 'Abbilden von Geschäftsprozessen auf Workflows' basiert auf folgendem Arbeitsbericht:
Jung, J.: Mapping of Business Process Models to Workflow Schemata - An Example using MEMO-OrgML and XPDL,
Arbeitsberichte des Institut für Wirtschaftsinformatik, Nr. 47, April 2004.
Literaturreferenzen
[Böhm00]Böhm, M.: Entwicklung von Workflow-Typen: Ein Leitfaden der methodischen Anwendungsentwicklung am Beispiel ausgewählter Workflow-Aspekte, Berlin et al.: Springer, 2000
[EJLT99]Eertink, H.; Janssen, W.; Luttighuis, P.O.; Teeuw, W.; Vissers, C.: A Business Process Design Language, In: Wing, J.; Woodcock, J.; Davies, J. (Eds.): FM '99, Vol. I, LNCS 1708, Springer, 1999, pp. 76-95
[FrLa03]Frank, U.; Laak, Bodo van: Anforderungen an Sprachen zur Modellierung von Geschäftsprozessen, Research Report of the IS Research Institute, University of Koblenz, Nr. 34, 2003
[GrRo99]Green, P.; Rosemann, M.: An Ontological Analysis of Integrated Process Modelling, In: Jarke, M.; Oberweis, A. (Eds.): CAiSE '99, LNCS 1626, Springer, 1999, pp. 225-240
[Hei88]Heinen, E.: Produktions- und Kostentheorie, In: Jacob, H. (Hrsg.): Allgemeine Betriebswirtschaftslehre, pp. 209-299, Gabler, 5. Edition, 1988.
[Herb97]Herbst, H.: Business Rule-Oriented Conceptual Modeling, Physica- Verlag, 1997
[Holl95]Hollingsworth, D.: The Workflow Reference Model, Document Number TC00-1003, Winchester: Workflow Management Coalition, 1995
[Jung01]Junginger, S.: Workflowbasierte Umsetzung von Geschäftsprozessen, Dissertation, Universität Wien, 2001
[KoPl00]Koubarakis, M.; Plexousakis, D.: A Formal Model for Business Process Modelling and Design, In: Wangler, B.; Bergman, L. (Eds.): CAiSE 2000, LNCS 1789, Springer, 2000, pp. 142-156
[Mato03]Matousek, P. :Verification of Business Process Models, PhD Thesis, Technical University of Ostrava, 2003
[Nori02]Norin, R.: Workflow Process Definition Interface: XML Process Definition Language, Document Number WfMC.TC-1025, Lighthouse Point (Fl): Workflow Management Coalition, 2002
[Nübe01]Nübel, H.: The resource renting problem subject to temporal constraints, In: OR Spektrum (2001) 23, pp. 359-381.
[Öst95]Österle, H.: Business Engineering: Prozess- und Systementwicklung, Springer, 1995
[PSO99]Podorzhny, R.M.; Staudt Lerner, B.; Osterweil, L.J.: Modeling Resources for Activity Coordination and Scheduling, In: Ciancarini, P.; Wolf, A.L. (Eds.): COORDINATION '99, LNCS 1594, Springer, 1999, pp. 307-322
[SS01]Schiemenz, B.; Schönert, O.: Entscheidung und Produktion. Lehr und Handbücher der Betriebswirtschaftslehre, München, Wien, Oldenbourg Verlag, 2001
[Sta97]Stark, H.: Understanding Workflow, In: Lawrence, P.: "Workflow Handbook 1997." Chichester et al.: Wiley, 1997, pp. 5-25
[SuOs97]Sutton, S.M.; Osterweil, L.J.: The Design of a Next-Generation Process Language, In: Jazayeri, M.; Schaure, H. (Eds.): Software Engineering - ESEC/FSE '97, LNCS 1301, Springer, 1997, pp. 142-158
[WaWe93]Wand, Y.; Weber, R.: On the Ontological expressiveness of Information Systems Analysis and Design Grammar, In: Journal of Information Systems, Vol. 3, Nr. 2, 1993, pp. 217-237
[Web97]Weber, R.: Ontological Foundations of Information Systems, Coopers and Lybrand Accounting Methodology, Monograph No. 4, 1997
Weitere Links