BPMN 2.0 Metamodel. Christoph Zimmer

Transkript

1 BPMN 2.0 Metamodel Christoph Zimmer Fachhochschule Aachen, Fachbereich Elektrotechnik und Informatik, Eupener Straße 70, Aachen, Germany Zusammenfassung: Kapitel 1 liefert eine kurze Einführung in die Thematik von BPMN 2.0. In Kapitel 2 werden die Entstehung von BPMN und die verschiedenen Versionen und ihr Funktionsumfang behandelt. Außerdem erfolgt die Einführung in die verschiedenen Diagrammarten. Die Elemente für diese Diagrammarten und ihr Zusammenspiel wird in Kapitel 3 im Detail erklärt. Kapitel 4 liefert zum Abschluss eine Übersicht über verfügbare Editoren im Bereich des BPMN 2.0. Zum Abschluss wird die Transformation in andere Modulierungssprachen wie BPEL und XPDL, als auch deren Besonderheiten in Kapitel 5 vorstellt. Keywords: BPMN, BPMN 2.0, Workflow, Workflow-Modulierung, Kollaborationsdiagramm, Prozessdiagramm, Choreographiediagramm, Konversationsdiagramme, BPMN2BPEL, BPMN2XPDL 1 Einleitung In der heutigen Zeit ist eine gute Kommunikation zwischen Business und IT ausschlaggebend für ein erfolgreiches Unternehmen. Beim Modulieren von Businessstrategien, Workflows oder der eigentlichen Softwareentwicklung ist deshalb die Benutzung einer einheitlichen Sprache, welche die technischen, als auch die betriebswirtschaftlichen Aspekte vereint, wichtig. Für solche Zwecke werden häufig Modulierungssprachen eingesetzt, von denen sich mehrere Modelle in der Industrie etabliert haben. Wie wichtig die Kommunikation über eine solche Metasprache ist zeigte eine Studie aus dem Jahre Eine häufigere Abstimmung zwischen IT-Strategie und Unternehmensstrategie erhöht offensichtlich die Wahrscheinlichkeit des Unternehmenserfolges. Die Studie kommt außerdem zu dem Schluss, dass je häufiger eine Strategie synchronisiert wird, desto höher ist die Wahrscheinlichkeit für Erfolge. [1] 2 Historie / Begrifflichkeit Das Potenzial einer solchen Modulierungssprache erkannte auch der IBM-Mitarbeiter Stephen A. White und begann in den Jahren 2000/2001 mit der Ausarbeitung und

2 Entwicklung des BPMN kam es zu der Veröffentlichung der BPMN 1.0 unter der Business Process Management Initiative (BPMI), einer Organisation, die Standards im Bereich der Geschäftsprozessmodellierung definiert hatte. Im Juni 2005 wurde die BPMI von der Object Management Group (OMG), eine zweckgebundene Vereinigung, die sich mit der Entwicklung von Standards der objektorientierten Softwareentwicklung befasst, übernommen veröffentlichte die OMG die BPMN-Version 1.2. Seit diesem Zeitpunkt gilt das BPMN als offizieller Standard der OMG. [2], [3] Die aktuelle Version 2.0 wurde im Februar 2011 veröffentlicht. Seitdem genießt BPMN 2.0 eine zunehmende Popularität und eine verbreitete Anwendung gilt als wahrscheinlich, da bereits große Firmen wie IBM, Oracle und SAP auf die neue Version setzen und entsprechende Produkte auf den Markt gebracht haben. [4] 2.1 Fokus von BPMN 2.0 Wie bereits oben beschreiben basiert BPMN 2.0 auf den Vorgängerversionen. Dabei wurde der Fokus in der neuen Version auf der Verbesserung und Verfeinerung verschiedener Funktionen gelegt. Metamodell Objekttypen Beziehungstypen Eigenschaften Gesamtkomplexität BPMN ,30 BPMN ,07 BPMN ,70 UML ,40 Tabelle 1 Berechnung der Gesamtkomplexität der verschiedenen BPMN-Versionen im Vergleich zur aktuellen UML-Version [6] Dies führt zwingend auch eine Steigerung der Komplexität mit sich. Dies muss nicht immer schlecht sein, da zwar die Dauer der Einarbeitun gszeit steigt, dafür aber komplexe Problemstellung detaillierter moduliert werden können. So wurden in der neuen Version, im Vergleich zur Vorgängerversion, zum Beispiel der Austausches von Nachrichten, die Beschreibung der Beteiligung von Menschen an modellierten Prozessen oder die Möglichkeit Ereignisse komponieren oder korrelieren zu können ergänzt. [2],[5] 2.2 Diagrammarten in BPMN 2.0 Diagrammname Erklärung Einführung Kollaborationsdiagramm Darstellung von Nachrichtenaustausch zwischen Version 1.0 Prozessbeteiligten und deren Prozessbeteiligten Prozessdiagramm Abläufe zur Durchführung einer Aufgabe mit ihren einzelnen Schritten zu definieren und darzustellen Version 1.2

3 Choreographiediagramm Konversationsdiagramme Darstellung der Kommunikation zwischen verschiedenen Verantwortlichen Überblick über die Kommunikation zwischen den verschiedenen Beteiligten schaffen Version 2.0 Version 2.0 Tabelle 2 Übersicht über Diagrammtypen in BPMN 2.0 In der aktuellen Version verfügt BPMN über insgesamt 4 verschiedene Arten von Diagrammen (Tabelle 2). Mit Hilfe dieser ist es möglich die verschiedenen Aspekte von Geschäftsprozessen zu modellieren. Die einzelnen Bestandteile der Diagramme werden im folgenden Kapitel genauer betrachtet. 3 Modellieren mit BPMN 2.0 Für die Modellierung von BPMN 2.0 gibt es einen offiziellen GUIDELINE ( welcher die Nationen und ihre Kombinatorik beschreibt. Da eine vollständige Erklärung und Erläuterung den Rahmen dieser Ausarbeitung sprengen würde, wird sich auf die wichtigsten Aspekte beschränkt. Für die Modulierung eines Workflows reichen im Prinzip Stift und Papier, die Verwendung eines Modulierungstools ist aber sinnvoll, da zum Beispiel Änderungen leicht einfließen können und, wie im späteren Kapitel unten beschrieben, die Transformation in Ausführungssprachen möglich ist. Für die folgenden Abbildungen wurden das OpenSource Tool Yaoqiang BPMN Editor in der Version verwendet ( 3.1 Prozessdiagramm Prozessdiagramme modellieren Abläufe von Verantwortlichen, Verantwortlichkeitsbereiche und Personengruppen. Öffentliche Prozesse stellen dabei meist eine vereinfachte Form eines privaten Prozesses dar. Während öffentliche Prozesse allgemein zugänglich sind und sich meist auf das Kommunikationsverhalten von Prozessen und dessen Beteiligten beziehen, ist die Ambition bei privaten Prozessen den schematischen Ablauf so detailliert wie nur möglich zu modulieren. Im Folgenden wird zuerst mit der Modellierung von Abläufen begonnen, bevor auf die Kommunikation zwischen verschiedenen Prozessen eingegangen wird. Tasks, Events und Sequence-Flows Die Abbildung 1 zeigt gleich zwei Grundelemente privater Prozessdiagramme auf. Zum Einen unterscheidet man generell drei Arten von Ereignissen in BPMN 2.0: Start-Events, Intermediate-Events und End-Events. Wie bei der Automatentheorie definieren Start und End einen gültigen Ein- und Ausstieg in einem Prozess. Intermediate Events beschreiben Ereignisse die sich im Ablauf eines Prozessdurchlaufes ereignen bzw. ereignen können.

4 Abbildung 1. Prozessablauf mit Tasks, Events und Sequence-Flows Zum anderen wird mit dem Modellierungselement Task eine Aufgabe im Ablauf beschrieben. Ein Prozess beschreibt also eine Aufgabe und die Tasks sind kleine Teilaufgaben die für die Umsetzung notwendig sind. Eine Verbindung der Tasks und Ereignisse werden durch Sequence-Flows realisiert. Dargestellt werden diese mittels durchgezogener Pfeile. Gateways Gateways beschreiben in der BPMN nichts anderes als eine Aufspaltung bzw. Zusammenführung von Kontrollflüssen. Ein einfaches Beispiel für eine Aufspaltung ist in Abbildung 2 zu erkennen. Hierbei wird nach dem Eingang eine Bestellung überprüft, ob diese auch bezahlt worden ist. Je nachdem zu welchem Ergebnis die Überprüfung kommt, wird der Versand initialisiert oder beispielsweise eine Mahnung vorbereitet. Abbildung 2 Beispiel für ein Gateway Bei den Gateways gibt es verschiedene Spezialisierungsmöglichkeiten, welche hier nur kurz vorgestellt werden, da ein detailliertes Eingehen den Umfang der Ausarbeitung überschreiten würde. Abbildung 3 Symbole für Gateways Wie in Abbildung 3 zu erkennen ist, werden die verschiedenen Arten der Gateways wie, auch schon in Abbildung 2, durch eine Raute gekennzeichnet.

5 Das Parallel Event Gateway (Ein Kreuz als Modellierungssymbol) führt alle ausgehenden Pfade unabhängig von einander aus. Eine Ausführung nach einem zusammenführenden Parallel Gateway erfolgt erst, wenn alle zusammenführenden Pfade beendet wurden. Das Exclusive Gateway (X als Modellierungssysmbol) bedient sich der XOR- Semantik. Dabei wird ausgehend von der Bedingung immer genau einer der von dem Gateway ausgehenden Pfade behandelt. Mit einem Kleene-Stern als Modellierungssysmbol können beliebig viele Pfade parallel ausgeführt werden. Eine eventuelle Beschränkung kann durch Kommentare oder narrative Beschreibungen definiert werden. Somit ist zum Beispiel die Modellierung einer 2-aus-5-Gateways möglich. Im Abhängigkeit von eintreffenden Events, die im unteren Abschnitt genauer erläutert werden, verhält sich das Event-Based-Gateway (durch ein Fünfeck gekennzeichnet). Derjenige Pfad, dessen Event als erstes eintritt, wird ausgeführt. Es ist außerdem möglich über dieses Gateway zeitgesteuerte Events (Time-Events) zu modellieren. Ein Inclusive-Gateway beschreibt ein Gateway, bei dem es keine Begrenzung im Bezug auf die Anzahl der ausführbaren Pfade gibt. Jede Verzweigung ist mit gesonderten Bedingungen versehen. Diese werden separat überprüft und alle gültigen Pfade werden anschließend ausgeführt. Darüber hinaus gibt es die Möglichkeit einen Default-Pfad anzugeben. Dieser wird jedoch nur dann ausgeführt, wenn keine der Bedingungen der anderen Pfade erfüllt sind. Daten und Datenfluss Genau wie Tätigkeiten und Abläufe wird bei einem Prozessmodell auch die Übergabe von Daten benötigt. Daten können (wie in Abbildung 4) über einen Input in die Prozessmodellierung importiert und wieder über einen Output exportiert oder in einen Data-Store gespeichert werden. Abbildung 4 Beispiel für Daten und Datenflüsse Bei dem Wechsel in einen anderen Task gibt es zusätzlich die Möglichkeit Daten über ein Data-Object mit zu übergeben. Datenströme können auch in so genannten Collections zusammengefasst werden.

6 Pools und Lanes Eine Strukturierung der Prozessabläufe wird in BPMN 2.0, wie auch schon in den Vorgängerversionen über Pools und Lanes gelöst. Dabei kann ein Pool immer in verschiedene Lanes unterteilt werden. Ein klassisches Beispiel ist in der Abbildung 5 zu sehen. Hierbei ist die Abteilung für den Bestellservice als Pool abgebildet. Die Aufgaben des Callcenters und Bestellservices werden als Lanes modelliert. Allgemein beschrieben stellt ein Pool also einen Prozessbeteiligten dar. Dabei kann es sich sowohl um eine Person, eine Gruppierung oder eine Maschine handeln. Es gibt daraufhin weiter die Möglichkeit Pools weiter zu gliedern. Die dabei verwendeten Lanes können zum Beispiel ein Unternehmen in verschiedene Abteilungen unterteilen. Die Gliederungstiefe des Lanes ist dabei unendlich tief. So kann die Abteilung daraufhin in verschiedene Tätigkeitsfelder unterteilt werden usw. Abbildung 5 Beispiel für den Wechsel zwischen Lanes [7], Eine Verbindung zwischen zwei Lanes, wie in Abbildung 6 dargestellt, wird nicht durch die oben erwähnten Sequence-Flow realisiert. Man verwendet hierfür Message- Flows (gestrichelte Pfeile). Abbildung 6 Beispiel für den Wechsel zwischen zwei Lanes [7] Die Überlegung dahinter ist, dass die verschiedenen Prozessbeteiligten eines Pools über Nachrichten (Messages) in Verbindung treten. Ein möglicher Nachrichtenaustausch wie in Abbildung 6 dargestellt, könnte beispielsweise eine Bestellung per sein, und bei der Produktauslieferung eine entsprechend der Bestellung beiliegende Rechnung.

7 Spezielle Tasks Es ist sinnvoll die Aufgabe eines Tasks durch Symbole zu verstärken. Dadurch gewinnt das Diagramm an Aussagekraft und wird einfacher lesbar. Außerdem wird der Kommentierungsgrad dadurch verringert. Im Folgenden möchte ich auf die wichtigsten Tasksymbole aufmerksam machen. Eine grafische Darstellung der Symbole ist in der Abbildung 7 zu finden. Ein Service Task symbolisiert den Aufruf (synchron) einer (Web)-Applikation. Dabei wird auf eine Antwort gewartet bis der Prozess weiterläuft. Der Send Task symbolisiert eine asynchrone Kommunikation mit einen (Web)- Service. Das bedeutet es wird nicht auf eine Antwort gewartet. Ein Receive Task ist das Gegenteil eines Send Tasks. Das bedeutet, es wird auf die Nachricht eines (Web)-Services gewartet. Bis diese eintrifft wartet der Prozess. Wird eine Tätigkeit durch einen Menschen ausgeführt, der durch das BPMN unterstützt wird, so bedient man sich dem Symbol des User Tasks. Ein Beispiel hierfür wäre das Raussuchen von Kundeninformationen in einer Datenmaske. Führt ein Mensch eine Tätigkeit aus, ohne das er durch das BPMN unterstützt wird, so spricht man von einem Manual Task. Das Nachfüllen des Wassertanks der Kaffeemaschine wäre ein Beispiel hierfür. Abbildung 7. Grafische Darstellung für spezielle Tasks Marker für Tasks Es gibt die Möglichkeit zusätzlich bei jedem Task einen Marker einzufügen. Die entsprechende Symbolik kann aus der Abbildung 8 entnommen werden. Bei dem Multi-Instance-Task (Parallel) werden, auf Eingabewerten basierend, parallel mehrere Instanzen des Tasks gebildet. Dieser gilt als abgearbeitet, wenn eine definierte Bedingung erfüllt wurde. Der Multi-Instance-Task (Sequenziell) verhält sich ähnlich wie der parallele Task. Nur werden hier die Instanzen sequenziell ausgeführt. Soll ein Task solange ausgeführt werden, bis eine Bedingung nicht mehr erfüllt ist, so wird sie mit dem Loop-Symbol versehen. Müssen bei einem Fehler oder Ähnlichem abgearbeitete Tasks wieder rückgängig gemacht werden, so modelliert man dies mit Hilfe eines Compensation Tasks. Ein Task wird dabei stets als atomare Einheit verstanden. Abbildung 8. Grafische Darstellung von Markern in Tasks

8 Spezielle Events Die oben erwähnten Events (Start, End und Intermediate) lassen sich über Symbole (Abbildung 9) erweitern. Da viele Symboliken, unabhängig von der Event-Art, das Gleiche aussagen, werden diese bei der Erläuterung zusammengefasst. Es wird jedoch nur auf die wichtigsten eingegangen. Message: Der Briefumschlag wird beim Empfangen bzw. Versenden von Nachrichten verwendet. Als Startzustand startet der entsprechende Prozess nach Eintreffen einer Nachricht; als Endzustand wird eine Nachricht zu einem anderen Prozess gesendet. Signal: Das Signal verhält sich ähnlich wie die Message. Es wird bei diesem Verfahren nur kein Empfänger adressiert und es können mit seiner Hilfe mehrere Prozesse gleichzeitig gestartet werden. Timer: Der Timer ermöglicht es eine bestimmte Zeit zu warten, bis der Prozess angestoßen wird, oder bis der Prozess weiterläuft. Error: Diese Spezialisierung gibt einen Error zurück und beendet einen Subprozess sofort, wobei auch alle aktiven Threads beendet werden. Terminate: Beendet den Prozess und alle Subprozesse und dessen Theads unmittelbar. Abbildung 9. Wichtigste Spezialisierung von Events (Start-, End- und Intermediate) 3.2 Choreographiediagramm Choreographiediagramme werden benutzt, um Austausch von Nachrichten in Prozessen zu modellieren, analysieren und gegebenenfalls du modifizieren. Diese Diagramme können dann leichter in Message Exchange Pattern (MEPs) transformiert werden. Diese Nachrichtenaustauschmuster bedienen sich gängiger Architekturen um den Nachrichtenaustausch zweier oder mehrerer Beteiligter zu entwerfen. Die beiden bedeutendsten Pattern sind das einseitige Senden einer Nachricht (Single Message) und das synchrone Versenden einer Nachricht und das Warten einer Antwort (Request/Response). Choreographietasks Zum Entwerfen der oben erwähnten MEPs wird das Modellierungselement Choreographietask verwendet. Jedes Choreographietask stellt dabei genau einen Nachrichtenaustausch zwischen zwei Beteiligten dar. Ein Choreographiediagramm erlaubt das strukturierte Zusammenspiel mehrerer Choreographietasks um den gesamten Nachrichtenverkehr eines Arbeitsablaufes im Sinne der MEPs darzustellen. Die beiden gängigsten MEPs sind als Choreographietasks in Abbildung 10 dargestellt.

9 Abbildung 10 Beispiel für Choreographietasks Ein Choreographietask besteht üblicherweise aus 3 Teilkomponenten. Das zentrale Feld in der Mitte beschreibt den Namen bzw. den Arbeitsvorgang. Die beiden Felder ober- und unterhalb des Namensfeldes nennen die beiden Beteiligten welche am Nachrichtenaustausch beteiligt sind. Die Farbgebung zeigt dabei an, wer Sender (weißes Feld) und wer Empfänger (graues Feld) ist. Die Nachricht wird dabei durch einen Briefumschlag dargestellt. Der helle Briefumschlag dient als Zeichen von initialen Nachrichten, der dunkle als entsprechende Antwort. Marker Die Choreographietasks können genau wie auch die Tasks in den Prozessdiagrammen mit Markern versehen werden. Die Bedeutung wird im Folgenden erläutert und ihre Symbolik kann in der Abbildung 11 entnommen werden. Abbildung 11 Marker in Choreographietasks Der Loop-Marker bedeutet im Bezug auf das Senden von Nachrichten, dass der Sender wiederholt sendet, solange eine bestimmte Bedingung (durch Kommentare angegeben) erfüllt ist. Ein Choreographietasks mit dem Multi-Instance-Marker (Parallel) steht dafür, dass eine Nachricht gleichzeitig mehrmals vom Sender zum Empfänger gesendet wird. Es gibt die Möglichkeit Nachrichten auch sequenziell zum Empfänger zu senden. Dafür wird der Multi-Instance-Marker (Sequenziell) verwendet. Versieht man den Empfänger mit dem Multi-Instance-Marker (Parallel), so möchte man damit aussagen, dass die Nachricht an verschiedene Empfänger gesendet wird, die durch einen Sammelbegriff zusammengefasst werden können.

10 Sequence-Flows / Events / Gateways Wie in Abbildung 12 erkennbar wird, wie auch schon im Prozessdiagramm, der Sequenz-Flow zur Verbindung von Choreographietasks verwendet. Die Verwendung von Events, wie hier in der Abbildung Start- und Endzustand, ist auch möglich. Eine Verwendung jeglicher im vorherigen Kapitel vorgestellter Gateways ist ebenfalls möglich. Abbildung 12 Beispiel für ein Choreographiediagramm 3.3 Kollaborationsdiagramm Das Kollaborationsdiagramm kombiniert die Elemente von Prozessdiagramm und Choreographiediagramm zu einer neuen Diagrammart. Das heißt es werden Prozesse und ihre Aufläufe mit dem Nachrichtenaustausch der beteiligten Personen und Gruppierungen in Verbindung gebracht. In Abbildung 13 ist die Kommunikation zwischen den zwei minimierten Pools Kunde und Zeitungsverlag zu sehen. Es handelt sich dabei um eine beidseitige Kommunikation die zeitversetzt von links nach rechts geschieht. Nach dem Auftrag mit Anzeigetext kommt es zur Rücksendung eines Probeauszuges und einer anschließenden Rückmeldung zum Probeauszug. Abgeschlossen wird die Kommunikation mit dem Senden einer Bestätigung seitens des Zeitungsverlages. Abbildung 13 Kommunikation zwischen zwei minimierten Pools Da der Vorgang im Detail schon moduliert worden ist, lassen sich die beiden Pools auch maximieren. Wie man bei der Maximierung des Zeitungsverlages erkennen kann (Abbildung 14), gibt es einen Kommunikationsablauf der durch den Choreographiediagrammteil übernommen wird.

11 Abbildung 14 Kommunikation zwischen zwei maximierten Pools Der Prozessablauf des Zeitungsverlages wird durch eine eintreffende Nachricht angestoßen und gibt bei seiner Beendung eine Meldung heraus, die als Bestätigung vom Kundenprozess interpretiert wird. Wartet einer der beiden Prozesse auf eine Antwort, so bleibt dieser stehen, bis der andere Prozess ihm antwortet. Zusammenfassend ist also zu sagen, dass sich die Kollaborationsdiagramme sehr gut eignen um einen Überblick in verschiedene Ebenen zu schaffen. 3.4 Konversationsdiagramm Die letzte Diagrammart in BPMN 2.0 ist das Konversationsdiagramm. Dieses bietet die Möglichkeit die Kommunikation zwischen Organisationseinheiten stark zu abstrahieren. Kommunikationen werden dabei über den sogenannten Conversation- Node zusammengefasst. Die in Abbildung 15 dargestellte Kommunikation bezieht sich dabei auf das im vorherigen Kapitel aufgegriffene Beispiel. Allgemein ist zu sagen, dass es für das Zusammenfassen keine Begrenzung oder Richtlinien gibt. Denkbar wäre also beispielsweise auch eine Zusammenfassung in 2 Conversation Nodes. Abbildung 15 Zwei Organisationseinheiten verbunden über Conversation-Node

12 4 Editoren für BPMN 2.0 Im Internet findet sich eine große Masse an Editoren für BPMN. Viele dieser bieten auch die Unterstützung für BPMN V 2.0. Im folgendem werden einige dieser Editoren vorgestellt. Augenmerk wird dabei auf Ihren Funktionsumfang und die Integration in die Entwicklungsumgebungen Eclipse (Java) und Microsoft Visual Studio (C, C++, C#, etc.) gelegt. Generell kann gesagt werden, dass alle vorgestellten Produkte die Möglichkeit eines Import/Export von BPMN konformen Dateien bieten. BPMN-Elemente und Fragmente lassen sich bei allen Lösungen per Drag-and-Drop hinzufügen. Modulierte Prozessabläufe werden in XML konformer BPMN-Syntax abgespeichert und können somit auch mit anderen Editoren geöffnet werden. 4.1 Yaoqiang BPMN Editor Opensource Dieser bereits oben erwähnte BPMN Editor wurde unter der GPLv3 veröffentlich und kann kostenlos heruntergeladen werden. Da es sich bei diesem Tool um eine Java- Anwendung handelt brauch es nicht installiert werden und läuft Plattformunabhängig. Die BPMN- Syntax kann jederzeit zu dem jeweilig modulieren Prozess eingesehen werden und bei Bedarf auch angepasst werden. Eine Integration in eine Entwicklungsumgebung gibt es nicht. 4.2 objectif - Kommerziell Diese Software wird von der Firma microtool GmbH vertrieben. Mit ihr lassen sich sowohl UML als auch BPMN/BPMN 2.0 Diagramme erstellen. Eine Integration in Visual Studio und Eclipse als Plugin ist möglich. Ein sogenanntes Round-Trip- Engineering, bei dem Änderungen am Diagramm Einflüsse auf den Quelltext haben wird vom Hersteller aufgeführt. Als Plattform wird Windows in allen gängigen Versionen unterstützt. Eine Einzelplatzlizenz ist für zu erwerben. 4.3 BPMN 2.0 Modeler - Eclipse Eine Integration von BPMN in die Eclipse-Entwicklungsumgebung ist über die Installation des BPMN 2.0 Modeler möglich. Dieser bietet in der neuen Version auch eine Unterstützung für BPMN 2.0 an. In Java-Projekte lassen sich so passende BPMN-Diagramme integrieren, die auch bei der Dokumentation referenziert werden können. 4.4 BPMN Visualization Source Code Kit Visual Studio Über dieses Visualization-Plugin lässt sich ein BPMN-Editor in Visual-Studio 2010 integrieren. Das Plugin ist kostenlos sieht aber in seiner Aufmachung etwas veraltet aus. Funktionell kann es aber einzig für die visuelle Erstellungen von Diagrammen verwendet werden, was eine Sinnvolle Integration in die Umwicklungsumgebung in Frage stellt.

13 5 Transformation in Ausführungssprachen (BPEL und XPDL) Neben BPMN gibt es im Bereich des Business Process Management (BPM) noch weitere Sprachen, mit welchen sich der Ablauf von Geschäftsprozessen festhalten lässt. Dabei werden im Zusammenhang mit BPMN oft die beiden Ausführungssprachen BPEL (Buisness Process Execution Language) und XPDL (XML Process Definition Language) verwendet. Diese beiden Sprachen ergänzten BPMN an der Stelle wo es Lücken aufwies (Ausführungssemantik und im Speicherformat). In den folgenden beiden Unterpunkten wird die Möglichkeit der Transformation zu BPEL und XPEL vorgestellt. 5.1 BPMN zu BPEL BPEL ist, genau wie BPMN XML, orientiert. Allerdings ist BPMN graphenorientiert während BPEL den Ansatz der Blockorientierung verfolgt. Der BPEL-Standard selbst definiert keine grafischen Symbole für die Darstellung der definierten Ablaufprozesse. Aus diesem Grund wurde und wird BPMN für die visuelle Darstellung von BPEL verwendet. Der BPMN-Standard definiert für die Umwandlung zu BPEL sogar ein Vorgehensmodell [9]. Die Möglichkeiten und die Komplexität von BPMN entsprechen aber nicht denen von BPEL. So können manche Prozesse die in BPMN moduliert worden sind umgesetzen bzw. transformiert werden. Wie sich aus der Tabelle 1 entnehmen lässt, hat sich die Komplexität mit der aktuellen Version von gesteigert, was eine automatisierte Transformation noch schwieriger macht und noch weniger BPMN-Diagramme ihre Aussagekraft in BPEL behalten. Es lassen sich Parallelen erkennen zwischen der BPEL-XML-Syntax und der Syntax von BPMN 2.0. Abbildung 16 Einfaches Beispiel für einen in BPMN 2.0 modulierten Automaten <process> <if> <sequence><task A/></sequence> <elseif> <sequence><task B/></sequence> </elseif> </if> </process> Code 1 BPEL-Code zur Abbildung 16 Während BPEL die Hierarchie durch XML-Ebenen versucht darzustellen, regelt BPMN 2.0 dies im Quelltext über IDs und Referenzen. So kennt BPEL zum Beispiel keine Unterprozesse was Beispielsweise das Terminieren eines Unterprozesses, falls

14 der Hauptprozess beendet wurde, unmöglich macht. Webserviceaufrufe sind dabei klar eine Stärke von BPEL, wobei hingegen entsprechende Rollenkonzepte komplett fehlen <process id="_1"> <startevent id="_2"><outgoing>_6</outgoing></startevent> <endevent id="_3"><incoming>_7</incoming></endevent> <exclusivegateway id="_4"> <incoming>_6</incoming> <outgoing>_10</outgoing> <outgoing>_13</outgoing> </exclusivegateway> <exclusivegateway id="_5"> <incoming>_11</incoming> <incoming>_14</incoming> <outgoing>_7</outgoing> </exclusivegateway> <sequenceflow id="_6" sourceref="_2" targetref="_4"/> <sequenceflow id="_7" sourceref="_5" targetref="_3"/> <task id="_8"> <incoming>_13</incoming> <outgoing>_14</outgoing> </task> <task id="_9"> <incoming>_10</incoming> <outgoing>_11</outgoing> </task> <sequenceflow id="_10" sourceref="_4" targetref="_9"/> <sequenceflow id="_11" sourceref="_9" targetref="_5"/> <sequenceflow id="_13" sourceref="_4" targetref="_8"/> <sequenceflow id="_14" sourceref="_8" targetref="_5"/> </process> Code 2 BPMN-Code zur Abbildung 16 (mit stark vereinfachten Metainformationen) 5.2 BPMN zu XPDL Anders als bei BPEL ist XPDL genau wie BPMN graphenorientiert. XPDL arbeitet dabei genau wie BPMN mit Referenzen (Code 3). Diese Sprache wurde vorrangig für das Ausführen von Aufgaben von Menschen entwickelt (Workflows). Ein Rollenkonzept ist vorhanden, ein Umgang beispielsweise mit Fehlersituationen fehlt leider ganz. [10] <WorkflowProcess> <Activities> <Activity Id="id_1"></Activity> <Activity Id="id_2"> <Route ExclusiveType="Data" GatewayType="Exclusive"/> <TransitionRestriction> <Join ExclusiveType="Data"/> <Split ExclusiveType="Data" Type="Inclusive"> <TransitionRefs> <TransitionRef Id="tra3"/> <TransitionRef Id="tra2"/> </TransitionRefs> </Split> </TransitionRestriction> </Activity> <Activity Id="id_3"> <Route ExclusiveType="Data" GatewayType="Exclusive"/> <TransitionRestriction> <Join ExclusiveType="Data" Type="Exclusive"/>

15 <Split ExclusiveType="Data"/> </TransitionRestriction> </Activity> <Activity Id="id_4"></Activity> <Activity Id="id_5"></Activity> <Activity Id="id_6"></Activity> </Activities> <Transitions> <Transition From="id_1" Id="tra1" To="id_2"></Transition> <Transition From="id_2" Id="tra2" To="id_4"></Transition> <Transition From="id_2" Id="tra3" To="id_5"></Transition> <Transition From="id_4" Id="tra4" To="id_3"></Transition> <Transition From="id_5" Id="tra5" To="id_3"></Transition> <Transition From="id_3" Id="tra6" To="id_6"></Transition> </Transitions> </WorkflowProcess> Code 3 BPEL-Code zur Abbildung 16 (mit stark vereinfachten Metainformationen) 5.3 Fazit BPEL und XPDL schließen sich also nicht gegenseitig aus und liefern gerade im Umgang mit BPMN in seinen Vorgängerversionen eine sinnvolle Ergänzung. Mit der neuen Version 2 von BPMN ist allerdings auszugehen, dass BPEL und XPDL in Zukunft an Bedeutung verlieren werden, da BPMN 2.0 über ein eigenes umfangreiches XMP-Metamodel verfügt und Lücken der Vorgängerverion gefüllt hat. Dies erkannte schon 2010 Frank Leymann von der Univerität Stuttgart. [8] Mit der neuen Serialisierung der BPMN in dessen Version 2.0 sollen die Vorteile von XPDL und BPEL also vereint werden, vorausgesetzt der Standard setzt sich in er Industrie fort. Literatur 1. Öfter mal miteinander reden! Kommunikation zwischen IT und Business als Erfolgsfaktor, 2. Business_Process_Model_and_Notation, 3. Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN), Eugen Laban, 2010, 4. Praxishandbuch BPMN, Freund, Rücker, Towards an Interoperable Metamodel Suite: Size Assessment as One Input, 2012, Brian Henderson-Sellers1, Muhammad Atif. Qureshi1, and Cesar Gonzalez-Perez