| 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:
|
- Erstellung von Geschäftsprozessmodellen mit MEMO-OrgML
- Erweiterung der Geschäftsprozessmodelle um workflowrelevante Informationen
- Abbildung der Geschäftsprozessmodelle auf XPDL-Dokumente
- 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.
|
|
| Manueller Prozess | Teilnehmer: notwendig
Anwendung: nicht anwendbar
Startmodus: manuell
Endmodus: manuell |
| Teilautomatisierter Prozess | Teilnehmer: notwendig
Anwendung: notwendig
Startmodus: manuell
Endmodus: manuell |
| Automatisierter Prozess | Teilnehmer: nicht notwendig
Anwendung: notwendigt
Startmodus: automatisch
Endmodus: automatisch |
| Komponierter Prozess | Teilnehmer: 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 |
