Abbildbarkeit unstrukturierter Prozessmodelle auf strukturierte Workflows - Eine Untersuchung am Beispiel BPMN und ADEPT [original]

Abbildbarkeit unstrukturierter

Prozessmodelle auf strukturierte Workﬂows

Eine Untersuchung am Beispiel BPMN und ADEPT

Bachelorarbeit

der Fakultät für Ingenieurwissenschaften und

Informatik der Universität Ulm

vorgelegt von

Nicolas Mundbrod

August 2008

Prüfer der Arbeit:

Professor Dr. Manfred Reichert

Institut für Datenbanken und Informationssysteme

Amtierender Dekan: Prof. Dr. Helmuth Partsch

Gutachter: Prof. Dr. Manfred Reichert

Tag der Abgabe: 15. August 2008

Eidesstattliche Erklärung

Hiermit erkläre ich an Eides statt, dass ich diese Bachelorarbeit selbständig angefertigt

und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle

wörtlich oder sinngemäß übernommenen Ausführungen wurden als solche gekenn-

zeichnet. Weiterhin erkläre ich, dass ich diese Arbeit in gleicher oder ähnlicher Form

nicht bereits einer anderen Prüfungsbehörde vorgelegt habe.

Ulm, den 15. August 2008 Nicolas Mundbrod

Danke

Zu allererst möchte ich meinen Betreuern Prof. Dr. Manfred Reichert und Jens Kolb

meinen Dank für ihre Hilfe bei der Erstellung dieser Arbeit aussprechen.

Die Diskussionen mit ihnen, ihre Ratschläge und ihre große Hilfsbereitschaft haben

mir bei der Erstellung der Arbeit sehr geholfen.

Weiterhin möchte ich mich bei meiner Freundin Sarah Fritz für ihren großen Rückhalt

während der Erstellung dieser Arbeit bedanken.

Nicht zuletzt möchte ich meiner Familie danken, die mir durch ihre uneingeschränkte

Unterstützung das Studium und somit auch diese Arbeit ermöglichten.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Prozessorientierung ............................... 1

1.2 Problemstellung und Zielsetzung ....................... 3

1.3 Struktur der Arbeit ............................... 5

2 Grundlagen 6

2.1 Prozesse ..................................... 6

2.2 Workﬂows .................................... 8

2.3 Zusammenhang und Abgrenzung ...................... 10

3 Strukturelle Eigenschaften 13

3.1 Strukturelle Klassiﬁzierung von Workﬂows ................. 13

3.2 Bewertung und Folgen struktureller Eigenschaften ............. 18

4 Modellierung 25

4.1 Bekannte Formen ................................ 25

4.2 BPMN ...................................... 26

4.3 ADEPT ...................................... 32

5 Abbildbarkeit der BPMN auf ADEPT 39

5.1 Äquivalenz .................................... 39

5.2 Grundlagen der Abbildbarkeit ........................ 41

5.3 Abbildbarkeit von Modellen mit strukturellen Mängeln .......... 44

5.4 Automatisierbarkeit ............................... 53

6 Schlussbetrachtung 56

Zusammenfassung

Die letzten Jahre haben eine Vielzahl an unterschiedlichen Notationen zur Modellie-

rung von Prozessen oder Workﬂows hervorgebracht. Die Notationen unterscheiden

sich neben ihrer unterschiedlichen Symbolik besonders in der Ausdrucksmächtigkeit.

So existieren Notationen ohne Einschränkungen bis hin zu Notationen mit sehr weit

reichenden syntaktischen Restriktionen, wie z.B. die Blockstruktur. Das Voraussetzen

von strukturellen Einschränkungen vereinfacht es Workﬂow-Management-Systemen

(WfMS) Analysen durchzuführen und z.B. Deadlocks zu erkennen. Die zur Model-

lierung benötigten Notationen weisen durch syntaktische Restriktionen im Vergleich

zu syntaktisch uneingeschränkten Notationen eine höhere Komplexität und oftmals ei-

ne geringere Ausdrucksmächtigkeit auf. Daher existiert eine Konkurrenzsituation zwi-

schen den Ausdrucksmöglichkeiten und der Ausdrucksmächtigkeit der Notation, so-

wie den Anforderungen der WfMS um unabdingbare Eigenschaften des Workﬂows zu

sichern.

Das Ziel dieser Arbeit ist es, die Abbildbarkeit unstrukturierter Prozessmodelle auf

strukturierte Workﬂows wissenschaftlich zu untersuchen und den Stand der bereits

publizierten Verfahren zu erfassen. Es werden Muster innerhalb eines unstrukturierten

Prozess-Modells identiﬁziert, die eine Abbildung auf strukturierte Modelle ausschlie-

ßen. Darüber hinaus soll versucht werden, die Abbildungen in automatische, semi-

automatische und manuelle zu unterteilen.

Zur Veranschaulichung wurden die Business Process Modeling Notation (BPMN) der

Object Management Group (OMG) als unstrukturierte Notation und ADEPT1des Insti-

tuts für Datenbanken und Informationssysteme (DBIS) als strukturierte Notation aus-

gewählt.

1ADEPT steht für Application Development based on Encapsulated Premodelled Process Templates

Kapitel 1

Einleitung

Die meiste Zeit geht dadurch verloren, daß man nicht zu Ende denkt.

Alfred Herrhausen (1930-1989)

dt. Bankier, Vorstandsspr. Dt. Bank

1.1 Prozessorientierung

Fritz Nordsieck, einer der Hauptvertreter der betriebswirtschaftlichen Organisations-

lehre, erkannte schon 1932 in seiner Dissertation Die schaubildliche Erfassung und Unter-

suchung der Betriebsorganisation den Vorteil einer Orientierung an Prozessen:

„Der Betrieb ist in Wirklichkeit ein fortwährender Prozess, eine ununterbrochene Leistungs-

kette. [...] Anzustreben ist in jedem Fall eine klare Prozessgliederung.“[1]

Im Zuge des stärker werdenden globalen Wettbewerbes, der einen zusätzlichen

Kosten- und Preisdruck verursacht, rücken die Flexibilität auf neue Marktgegebenhei-

ten zu reagieren und eine hohe Automatisierbarkeit in den Fokus.

Eine Prozessorientierung bietet in diesem Fall Vorteile, denn es wurde erkannt, dass je-

des von einem Unternehmen angebotene Produkt (Geschäftsziel) das Resultat einer ko-

ordinierten Abfolge von Aktivitäten (Geschäftsprozess) ist. Ein Geschäftsprozess und

das daraus entstehende Produkt sind folglich zwei Seiten einer Medaille (Schaubild

1.1).

Prozess Produkt

Schaubild 1.1: Prozess und Produkt – zwei Seiten einer Medaille

Diese Erkenntnis ist wichtig, folgt doch aus ihr, dass durch die Verbesserung des

Geschäftsprozesses, die dabei entstehenden Produkte ebenfalls verbessert werden kön-

nen. Angehörige der Wirtschaftswissenschaften sind deshalb daran interessiert, Ge-

schäftsprozesse im Bezug auf Efﬁzienz und Qualität optimieren zu können. Sie wollen

unter anderem die „Time-to-Market“ neuer Produkte wie auch die Anpassungszeit be-

stehender Produkte an neue Marktgegebenheiten minimieren, die Kosten verringern

und die Kundenzufriedenheit steigern.

Um Geschäftsprozesse zu analysieren und zu optimieren, werden in der Regel Model-

le anhand einer graphischen Notation erstellt. Bis heute hat sich keine Notation den

Stellenwert in der Prozessmodellierung erworben, der vergleichbar wäre mit zum Bei-

spiel der von der Object Management Group (OMG, http://www.omg.org) publizier-

ten Uniﬁed Modeling Language (UML, [2]) für objektorientiertes Design und Analyse.

Doch strebt die OMG mit ihrer Notation zur Prozessmodellierung namens Business

Process Modeling Notation (BPMN) ebenfalls eine Standardisierung in diesem Bereich

an. Die OMG präzisiert die Ziele der BPMN in der Speziﬁkation der BPMN vom Fe-

bruar 2008 im Vorwort des Textes wie folgt:

„The primary goal of BPMN is to provide a notation that is readily understandable by

all business users, from the business analysts that create the initial drafts of the processes, to

the technical developers responsible for implementing the technology that will perform those

processes, and ﬁnally, to the business people who will manage and monitor those processes.“ [3]

Gerade durch das Ziel der leichten Verständlichkeit aller am Prozess beteiligten Per-

sonen und der entsprechenden Umsetzung erreichte die BPMN in kurzer Zeit einen

relativ hohen Verbreitungsgrad [4], obwohl sie die direkte Unterstützung der Prozesse

durch Informationstechnik nicht anbietet.

Die Wurzeln des Gedankens, Geschäftsprozesse durch Informationssysteme zu unter-

stützen und zu begleiten, ﬁndet sich in den 1970er Jahre, ebenfalls angesprochen durch

Fritz Nordsieck:

„Denken wir [...] an eine moderne Datenverarbeitung. Auch sie stellt einen deutlichen Pro-

zeß dar, der sogar in verschiedenen Abschnitten mit dem Betriebsprozeß verknüpft ist und ihn

ständig begleitet, wenn nicht sogar steuert.“[5], S.9

Um einen Geschäftsprozess oder Teile dessen zu automatisieren, können Workﬂows

(dt. Arbeitsﬂuss) verwendet werden (Deﬁnition und Details siehe später in Kapitel 2).

Kurzgefasst könnte ein Workﬂow als die verfeinerte, operative technische Sicht auf

einen zuvor fachlich, eventuell abstrakt erstellten Geschäftsprozess, oder auf Teile des-

sen, angesehen werden. Während bei einem Geschäftsprozess das Hauptaugenmerk

darauf liegt, was und in welcher Reihenfolge etwas getan wird, erweitert man in Bezug

auf den Workﬂow die Sicht hauptsächlich wie etwas und von wem etwas getan wird.

Ein Software-System, das die Ausführung von Workﬂows deﬁniert, vornimmt und ver-

waltet, wird als Workﬂow-Management-System (WfMS) bezeichnet. Die Speziﬁkation

eines Workﬂows für die Ausführung durch ein WfMS ﬁndet, analog zur Modellierung

von Prozessen, durch Modelle statt. Jedoch setzt ein WfMS zumeist strukturelle An-

forderungen an das Modell eines Workﬂows, damit Laufzeitfehler, wie zum Beispiel

Deadlocks, verhindert werden.

Das WfMS ADEPT21des Institutes für Datenbanken und Informationsysteme (DBIS)

der Universität Ulm setzt für die Modellierung der Workﬂows in der zum System ge-

hörenden Notation ADEPT eine Blockstruktur für die Modellierung von Workﬂows

voraus. Damit können die aus einer fehlerhaften Modellierung resultierende Laufzeit-

fehler von vornherein ausgeschlossen werden. Jedoch bietet ADEPT zusätzliche Kan-

ten zur Synchronisation an, die die Ausdrucksstärke der blockstrukturierten Notation

zusätzlich erweitert (siehe Kapitel 4).

1.2 Problemstellung und Zielsetzung

Der Übergang von der Erfassung und Analyse von Geschäftsprozessen durch eine No-

tation wie BPMN hin zur Umsetzung der Prozesse durch Workﬂows, in zum Beispiel

ADEPT, ist leider nicht als nahtlos anzusehen und resultiert aus den konzeptionellen

Unterschieden der Notationen zu Modellierung von Geschäftsprozessen und Work-

ﬂows.

Die Geschäftsprozessmodelle werden in der Regel von Personen erstellt, die einem

der Informatik fremden Umfeld zuzuordnen sind. Notation zur Modellierung von Ge-

schäftsprozessen sollten somit den technischen Aspekt der späteren Umsetzung ver-

nachlässigen, damit die Prozessmodelle leicht verständlich sind und als Diskussions-

grundlage dienen können. Die Modellierung der Prozesse kann nur gelingen, wenn

die entsprechenden Fachkräfte der Abteilungen in die Modellierung der Prozesse mit

eingebunden werden. Die Geschäftsleitung, wie auch der Modellierer selbst, sind eben-

falls an einer möglichst selbsterklärenden Notation interessiert. Nicht zuletzt sollen Ge-

schäftsprozesse auch sehr abstrakt und generell erfasst werden können.

Um möglichst efﬁzient und ungebunden die Prozesse erfassen zu können, ist der

Wunsch nach einer Notation, die möglichst ausdrucksstark und keinerlei Beschrän-

kungen unterworfen ist, ebenfalls verständlich. Deshalb setzt die BPMN in der Mo-

dellierung der Geschäftsprozesse keinerlei strukturelle Einschränkungen, die für eine

eventuell spätere Ausführung durch eine WfMS notwendig wären, voraus.

Falls nun ein Geschäftsprozess, oder ein Teil dessen, durch IT untersützt und dies durch

ein WfMS geschehen soll, stellt sich zwangsläuﬁg die Frage, ob es möglich ist, die be-

reits existenten Prozessmodell in das WfMS übernehmen zu können und diese gege-

benfalls „nur“ noch um technische und operative Details verfeinern zu können. Des-

halb ist es das Ziel dieser Arbeit, den Stand der bereits publizierten Arbeiten über die

Abbildbarkeit von unstrukturierten Prozessmodellen auf (block-)strukturierte Work-

ﬂows zu untersuchen, um zu ergründen, ob und in wie weit die Lücke zwischen der

Prozessmodellierung und Workﬂowmodellierung zu schließen ist. In Bezug auf kom-

plexe, groß dimensionierte Prozessmodelle wäre eine Abbildung ein erheblicher Vorteil

gegenüber einer expliziten Nachmodellierung der Modelle für das WfMS. Ohne gene-

1Die Entwicklung von ADEPT2 wurde durch das Land Baden-Württemberg im Rahmen des

AristaFlow-Projektes (http://www.aristaﬂow.de) ﬁnanziert

relle Aussagen zur Abbildung einzuschränken, sollen zur Konkretisierung und Ver-

anschaulichung zwei Notationen in die Untersuchung mit eingebunden werden. Zum

Einen die bereits erwähnte BPMN als unstrukturierte Notation und zum Anderen die

Notation ADEPT des gleichnamigen WfMS des Instituts DBIS der Universität Ulm als

blockstrukturierte Notation.

Um die Zielsetzung dieser Arbeit zu präzisieren, sollen an dieser Stelle für diese Un-

tersuchung der Abbildbarkeit relevante Fragen aufgeführt werden. Nach der Untersu-

chung der Abbildbarkeit sollen diese Fragen während der Schlussbetrachtung in Kapi-

tel 6 nochmals aufgegriffen und beantwortet werden.

•Ist jedes Prozessmodell modelliert in der BPMN auf ADEPT abbildbar?

•Falls nicht, existiert eine Teilmenge an Elementen in der BPMN, die eine vollständige

Abbildung nach ADEPT ermöglichen?

•Kann jedes Prozessmodell, das erfolgreich beendet werden kann (well-behaved), in einen

in ADEPT modellierten Workﬂow umgewandelt werden?

•Gibt es bereits existente Abbildungen der BPMN auf andere blockstrukturierte Notatio-

nen als ADEPT?

•In welcher Form wirken sich Erweiterungen der blockstrukturierten Notation ADEPT

auf die Abbildbarkeit aus?

•Könnte die blockstrukturierte Notation ADEPT um weitere Elemente bzw. Konstrukte

erweitert werden, um die Abbildbarkeit zu erhöhen?

1.3 Struktur der Arbeit

An dieser Stelle soll ein Überblick über den weiteren Verlauf dieser Arbeit gegeben

werden. So sollen im folgenden Kapitel 2 die Begriffe Prozess und Workﬂow präzisiert

werden und der Zusammenhang dieser Begriffe erläutert werden. In Kapitel 3 wird die

Bedeutung und Folgen von Struktur in einem Modell eines Prozesses bzw. eines Work-

ﬂows untersucht werden. Dazu werden unstrukturierte und blockstrukturierte Model-

le klar deﬁniert und die Unterschiede dieser Modelle betont. Die Folgen von struktu-

rellen Mängeln, die in unstrukturierten Modellen auftreten können, werden ebenfalls

aufgeführt und eingeordnet. Kapitel 4 soll die Notationen BPMN und ADEPT vorstel-

len und zuvor einen kurzen Anriss über weitere Möglichkeiten zur Modellierung von

Prozessen geben. Es sollen die für eine Abbildung interessanten Elemente vorgestellt

werden und anschließend die Modellierung von grundlegenden Modellen anhand von

Schaubildern aufgezeigt werden. Eine Einbeziehung der Ergebnisse aus Kapitel 3 er-

folgt ebenfalls.

Nach der Schaffung der Grundlagen soll in Kapitel 5 die Untersuchung der Abbild-

barkeit der Notation BPMN auf die Notation ADEPT durchgeführt werden. Es wird

zuerst der Begriff der Äquivalenz von Prozessmodellen und Workﬂows erläutert, um

dann anhand von Ergebnisse aus bereits publizierten Arbeiten die Abbildbarkeit zu

untersuchen. Es wird außerdem auf die Automatisierbarkeit der Abbildungen Bezug

genommen.

Abschließend ﬁndet in Kapitel 6 eine Zusammenfassung und Bewertung der Ergebnis-

se statt.

Kapitel 2

Grundlagen

Denn wer schwimmen will, muss zu den Flüssen gehen.

Isaac Newton (1643-1727)

englischer Physiker und Mathematiker

Hinter den Begriffen Prozessmodell,Workﬂow,BPMN und ADEPT aus dem Titel die-

ser Arbeit verbergen sich viele Begriffe und Themen, die in den folgenden Seiten näher

erläutert und präzisiert werden sollen. Die Begriffe werden auch erläutert um Missver-

ständnissen vorzubeugen, da in der Literatur oftmals Begriffe wie Prozess und Workﬂow

unterschiedlich und wechselseitig verwendet werden. Es soll weiterhin der Zusam-

menhang zwischen Prozessen und Workﬂows herausgestellt werden.

2.1 Prozesse

In der Einleitung dieser Arbeit wurde bereits die Idee der Prozessorientierung kurz vor-

gestellt. Um eine spätere Untersuchung von Prozessmodellen zu erlauben, bietet es sich

zuerst an, zuerst die Bedeutung des Wortes „Prozess“ im deutschen Sprachgebrauch zu

ergründen. Neben der Bedeutung der gerichtlichen Durchführung von Rechtstreitigkeiten,

die im Folgenden nicht berücksichtigt wird, präzisiert der Duden das Wort Prozess mit

den Worten Vorgang,Ablauf,Verfahren und Entwicklung. Ein präzise Deﬁnition erfolgt

durch die Literatur in [6]:

Deﬁnition 2.1 Ein Prozess ist ein allgemeiner Ablauf mehrerer Abschnitte, bei denen es sich

um Aufgaben, Ausführungen, Arbeitsschritte o.ä. handeln kann. Zwischen diesen Prozessab-

schnitten bestehen bestimmte Abhängigkeiten.

Intuitiv stellt ein Prozessmodell ein Modell eines Prozesses dar. Es folgt aber auch hier

eine ausführliche Deﬁnition analog zu [6].

Deﬁnition 2.2 Ein Prozessmodell beschreibt die Struktur eines realen Prozesses. Es be-

stimmt alle möglichen Pfade entlang des Prozesses und bestimmt die Regeln für die Wahl der

Pfade. Weiterhin bestimmt das Prozessmodell alle Aktivitäten, die ausgeführt werden müssen.

Die praktische Umsetzung der Modellierung eines Prozesses soll anhand eines Bei-

spiels aufgezeigt werden. Betrachtet werden soll ein Bestellprozess eines ﬁktiven Ver-

sandhandels. Dieser Prozess besteht aus einer Menge an Aktivitäten, die in koordinier-

ter Form ausgeführt werden. Nach Eingang einer Bestellung wird eine Rechnung ver-

sandt und gleichzeitig soll der Artikel für den Versand vorbereitet werden. Nach Erhalt

des Betrags der Rechnung und nach Abschluss der Vorbereitungen wird das bestellte

Produkt versandt. Das Schaubild 2.1 soll diesen kleinen Beispielprozess anhand eines

Prozessmodells illustrieren.

Bestelltung

rtikel

Versand Rechnung

Versand

vorbereiten

Betrag

eingegangen

Versand Artikel

Schaubild 2.1: Einfacher Bestellprozess eines Versandhandels

Man erkennt, dass Modelle besser geeignet sind, Abhängigkeiten zwischen Aktivi-

täten darzustellen, als textuelle Beschreibungen. Im Speziellen für großdimensionierte

und damit im zunehmenden Maße komplex werdende Prozesse sind Modelle uner-

lässlich, da sie textuell kaum in einem angemessenen und verständlichen Rahmen zu

erfassen wären. Außerdem ist es möglich, Prozesse abstrakt zu modellieren, den techni-

schen Aspekt der Realiserung zu vernachlässigen, und somit den Schwerpunkt auf die

Prozessstruktur und die Interaktion zwischen abstrakten Aktivitäten zu setzen. Dies ist

ein bedeutender Punkt, da Prozessmodelle somit prinzipiell nicht an bestimmte Strate-

gien oder Plattformen zur Umsetzung gebunden sind.

Natürlich kann die graphische Modellierung von Prozessen in verschiedenen Arten

und Notationen erfolgen. Die Granularität der Modellierung, also wie detailliert der

Prozess modelliert wird, kann ebenfalls variieren und ist, wie die Wahl der Notati-

on, dem Modellierer überlassen. Zur Modellierung des Beispielprozesses wurde eine

vereinfachte Version der Business Process Modelling Notation (BPMN) verwendet, die

später in Kapitel 4 ausführlich beschrieben wird. Die Ausführungsbeschränkungen,

die zuvor textuell beschrieben wurden und die sich darauf beziehen, welche Aktivi-

tät wann ausgeführt wird, werden durch Kontrollﬂusselemente realisiert.

Im Beispiel sind dies die Pfeile und die Rauten. Ein Pfeil von Aktivität „Versand Rech-

nung“ nach „Empfange Betrag“ bedeutet, dass erst die Rechnung verschickt wird und

danach der Betrag in Empfang genommen werden kann. Die erste Raute mit dem Plus

in der Mitte bedeutet, dass die Zweige, in denen einerseits die Rechnung verschickt und

danach die Zahlung eingeht und anderseits der Artikel zum Versand vorbereitet wird,

parallel ablaufen. Die zweite Raute mit dem Plus, in der die zwei paralellen Zweige

einmünden, bedeutet, dass der Artikel erst versandt wird, wenn die Aktivitäten beider

einmündeten Zweige beendet sind. Nach dem Versand des Artikels ist der Prozess be-

endet.

Prozesse, wie der Beispielprozess, die sich auf ein Unternehmen und der Verwirkli-

chung dessen Geschäftsziele beziehen, werden als Geschäftsprozesss (GP) oder aus

dem Englischen ebenfalls gebräuchlich als Business Processes (BP) bezeichnet. In den

neunziger Jahren des letzten Jahrhunderts entstand ein deutlicher Trend zur Orien-

tierung nach Prozessen innerhalb von Unternehmen. Unter anderem legten Michael

Hammer und James Champy in ihrer Arbeit [7] aus dem Jahr 1993 den Grundstein

für das sogenannte Business Process Reengineering und empfahlen die radikale Neu-

gestaltung der Geschäftsprozesse eines Unternehmens. Selbst in der Neufassung der

Normenreihe des Qualitätsmanagement (ISO 9000 ff.) im Jahr 2000 wurde der Prozess-

gedanke in den Vordergrund gestellt [6].

In der Folge soll die Deﬁnition eines Geschäfsprozesses nach [8], basierend bzw. ähnlich

zu den Deﬁnitionen in [7], [9] und [6], erfolgen:

Deﬁnition 2.3 Ein Geschäftsprozess besteht aus einer Menge an Aktivitäten, die koordiniert

in einem organisatorischem und fachlichem Umfeld ausgeführt werden. Diese Aktivitäten ver-

wirklichen gemeinsam ein Geschäftsziel. Jeder Geschäftsprozess wird von einer einzelnen Orga-

nisation durchgeführt, aber er kann mit Geschäftsprozesse anderer Organisationen interagieren.

Um Irritationen zu vermeiden soll angemerkt werden, dass wenn in der Folge von

Prozessen oder Prozessmodellen die Rede ist, in der Regel Geschäftsprozesse bzw.

Geschäftsprozessmodelle gemeint sind.

2.2 Workﬂows

In Bezug auf die Automatisierbarkeit spielen Informationssysteme eine wichtige Rolle.

Der Wunsch in einer durchgängigen, vorgangsorientierten Rechnerunterstützung von

Teilen oder des gesamten Geschäftsprozesses mündet im Begriff des „Workﬂows“, zu

Deutsch „Arbeitsablauf“.

Deﬁnition 2.4 Ein Workﬂow ist ein teilweise oder vollständig automatisierter Geschäftspro-

zess, in dem Dokumente, Informationen oder Aufgaben zwischen Teilnehmern entsprechend

einer Menge von Ausführungsregeln übertragen werden.

Kurzgefasst ist ein Workﬂow die verfeinerte, operative technische Sicht auf einen zu-

vor fachlich, eventuell abstrakten Geschäftsprozess oder auf Teile dessen. Während bei

einem Geschäftsprozess das Hauptaugenmerk darauf liegt, was und in welcher Rei-

henfolge etwas getan wird, erweitert man in Bezug auf den Workﬂow die Sicht haupt-

sächlich auf wie etwas und von wem etwas getan wird. Die Deﬁnition des Workﬂows

hält sich weitgehend an die Deﬁntion der Workﬂow Management Coalition (WfMC)

[10]. Die WfMC wurde im August 1993 gegründet um die Aktivitäten von Herstellern,

Benutzern und Akademikern rund um das Thema Workﬂow zu bündeln. Heute hat

die WfMC über 300 Mitglieds-Organisationen. Unter Hersteller sind hauptsächlich die

Produzenten von Workﬂow Management Systeme (WfMS) zu verstehen. Eine Präzisie-

rung dieser Systeme erfolgte ebenfalls durch die WfMC [8]. Die folgende Deﬁnition ist

daran angelehnt.

Deﬁnition 2.5 Ein Workﬂow Management System ist ein Softwaresystem, das mit Hilfe

von Software die Ausführung von Workﬂows deﬁniert, vornimmt und verwaltet. Es basiert

auf einer oder mehreren Workﬂow-Engines und ist in der Lage, Deﬁnitionen von Prozessen

zu interpretieren, mit Beteiligten des Workﬂows zu interagieren und, falls es erfordlich ist, die

Nutzung von IT-Werkzeuge und IT-Programme in Anspruch zu nehmen.

Unter der „Deﬁnition von Prozessen“ in der Deﬁnition des WfMS ist die Speziﬁkation

der Workﬂows, typischerweise durch ein Modell, zu verstehen. Die Modellierung der

Workﬂows erfolgt weitesgehend analog zur bereits vorgestellten Modellierung eines

Prozesses. Im Vordergrund steht koordinierte Abfolge von Aktivitäten. Jedoch werden

in Modellen für Workﬂows weitaus mehr die operativen technischen Faktoren berück-

sichtigt und es werden sehr oft strukturelle Eigenschaften der Modelle vorausgesetzt,

damit die Workﬂows korrekt ausgeführt werden können (detailiert in Kapitel 3). Das

Wort Workﬂow wird, wie im Titel dieser Arbeit, oft auch synonym für die entspre-

chende Speziﬁkation oder Modell des Workﬂows verwendet. Eine Übersicht, welche

Konzepte und Begriffe mit dem Term „Workﬂow“ abgedeckt und verbunden werden,

ist in der Arbeit [11] von Diimitrious Georgakopoulos et al. zu ﬁnden.

Natürlich sind Workﬂow-Management-Systeme nicht die einzige Möglichkeit, einen

Geschäftsprozess oder Teile dessen durch IT zu untersützten. Gegenüber einer viel-

leicht klassischen Lösung, bei der eine maßgeschneiderte Software zur Unterstüt-

zung des Prozesses geschaffen wird, oder Spezialsoftware wie zum Beispiel ein CRM-

System1, führt jedoch ein WfMS den Prozessgedanken zu Ende, da es die Vorteile der

Prozessorientierung übernimmt. Die klassische Lösung einer maßgeschneiderten Soft-

ware würde der Prozessorientierung des Unternehmens eventuell nicht gerecht wer-

den, da es die Flexibilität in der Anpassbarkeit der Prozesse stark beeinträchtigen wür-

de. Nach einer Änderung eines Prozesses würde die entsprechende Software für diesen

Fall umgeschrieben oder eventuell sogar neugeschrieben werden müssen, was oftmals

mit enormen Kosten und Zeitaufwand verbunden ist. Workﬂows sind, durch ihre ex-

plizite Repräsentierung in Modellen, leichter anpassbar. Die Progammlogik ist in den

Anwendungen, die zur Unterstützung der einzelnen Aktivitäten vorhanden sind oder

geschaffen werden, gekapselt. Der Wunsch nach Integration von heterogener Unter-

nehmenssoftware und Komposition in Prozessen mündet auch in dem aktuellen stark

aufkommenden Interesse in service-orientierten Architekturen (SOA) und BPEL. Lei-

der fehlt es der BPEL bisher in der Unterstützung der menschliche Interaktion mit

Prozessen, die in Workﬂows realisierbar ist. Abhilfe soll hier der Draft BPEL4People

1CRM-System = System zur Kundenpﬂege

schaffen. Die Vorstellung dieser Bestrebung und SOA im Generellen würde aber den

Rahmen dieser Arbeit sprengen. Es sei hier auf entsprechende Literatur wie [12] ver-

wiesen.

Zusätzlich reizvoll am Workﬂow-Konzept ist die Überlegung, die fachlich erstellten

Prozessmodelle eventuell „nur“ verfeinern und um operative technische Aspekte er-

weitern zu müssen. Doch sind die Anforderungen der WfMS bzw. der BPMS hinsicht-

lich eines ausführbaren Modells ausgeprägter. Die Modelle müssen unter anderem Be-

nutzerzuordnungen und Datenspeziﬁkation enthalten und es müssen zur Bearbeitung

von Aktivitäten zum Beispiel Standardsoftware eingebunden werden. Eine unabding-

bare Anforderung eines jeden WfMS muss es sein, dass die Workﬂowmodelle nicht zu

Laufzeitfehlern des Systems führen. Deshalb setzen WfMS im Allgemeinen strukturel-

le Eigenschaften ihrer Modelle voraus, da diese die Modellierung von inkorrekten Mo-

dellen, die zum Beispiel Deadlocks verursachen, verhindern. Es wird später im Detail

darauf eingegangen und gezeigt, dass es Konstrukte innerhalb von Prozessmodellen

gibt, die nicht ausführbar sind und sein dürfen. Beispielsweise werden, um Verklem-

mungen, die das erfolgreiche Beenden eines Workﬂows verhindern, zu vermeiden,

Schleifen nur in bestimmter, geordneter Weise zugelassen. Bei den blockstrukturier-

ten Modellierungssprachen, die strukturell am stärksten eingeschränkten Notationen,

korrespondiert sogar jede speziﬁsche Verzweigung im Kontrollﬂuss mit einem gleich-

bedeutenden Zusammenführen des Kontrollﬂusses und ergeben somit einen Block. Es

kann bewiesen werden, dass diese Modelle keine Verklemmungen verursachen und

somit den Anforderungen des WfMSs gerecht werden. Aalst et al. zeigen in ihrer Ar-

beit Workﬂow Patterns [13], dass alle aktuellen WfMS blockstrukturierten Workﬂow-

modelle unterstützen. Außerdem bieten viele von ihnen sogar die Möglichkeit an, das

Laufzeitverhalten der Workﬂows vor der Einführung zu simulieren und entsprechend

zu prüfen.

2.3 Zusammenhang und Abgrenzung

Nach Klärung der erwähnten Begrifﬂichkeiten ist es nun möglich, Beziehungen und

Abhängigkeiten zu identiﬁzieren und eine Einordnung vorzunehmen. Rund um das

Thema Prozessorientierung innerhalb eines Unternehmens ergeben sich vielfältige

Aufgaben. Das Modellieren und Erfassen von Geschäftsprozssen, unabhängig ob diese

hinzukommen oder schon bestehen, ist ein Grundvorgang. Wie schon erwähnt stellt

sich bei diesem Vorgang unter anderem die nicht unerhebliche Frage, in welcher Form

Prozesse erfasst werden sollen.

Nach der Modellierung ergibt sich zwangsläuﬁg die Frage nach der Umsetzung der

Geschäftsprozesse. Unter der Annahme, dass zumindest Teile aus den Geschäftspro-

zessen durch IT unterstützt werden sollen, stellt sich das Problem, wie dies geschehen

soll. Es ist natürlich dem Unternehmen überlassen, ob es auf ein Workﬂow Manage-

ment System, auf eine Business Rules Engine2oder auf eine Spezialsoftware, wie zum

2Ein System zur efﬁzienten Ausführung von Geschäftsregeln (Business Rules)

Beispiel ein CRM-System, zurückgreift. Natürlich ist wie bereits erwähnt eine eigens in

Auftrag gegebene Software denkbar.

Der Umsetzung folgend sollte die Ausführung der Prozesse möglich sein. Dies bedeu-

tet die Prozesse nach den gegebenen Modellen instanziieren zu können und sie dabei

überwachen zu können. Hierbei sollten Kennzahlen über die Ausführung festgehalten

werden um zum Beispiel den Status einer Prozessinstanz erfassen zu können. Eventuell

unterstützt die Ausführungsplattform auch Anpassungen der Prozesse in der Laufzeit.

Diese Anpassungen sollten ebenfalls dokumentiert werden.

Die Metriken und Dokumentation der Anpassungen erweisen sich als nützlich, wenn

die Prozesse evaluiert werden sollen. Die Evaluation sollte regelmäßig erfolgen und hat

den Sinn einer konstanten Hinterfragung und Optimierung der Prozesse. Eine Anpas-

sung der Prozesse würde selbstverständlich wieder in einer Modellierung bzw. Verfei-

nerung bestehender Prozesse münden.

Die erwähnten Vorgänge der Modellierung, Umsetzung, Durchführung und Evaluati-

on können im Begriff des Geschäftsprozessmanagement (GPM) zusammengefasst wer-

den. Die englische Version „Business Process Management“ (BPM) ist im deutschen

Sprachraum ebenfalls häuﬁg vorzuﬁnden. Eine präzise Deﬁnition erfolgt analog nach

[8]:

Deﬁnition 2.6 Geschäftsprozessmanagement beinhaltet Konzepte, Methoden und Techni-

ken für das Design, die Administration, die Konﬁguration, das Erlassen und die Analyse von

Geschäftsprozessen.

Um eine Einordnung vorzunehmen, wird in Schaubild 2.2 die Idee des höllandischen

Forschers Will van der Aalst aufgenommen, der in [14] die Kernaspekte des GPM erläu-

tert und anschaulich als sogenannten Business Process Lifecycle (dt. Geschäftsprozess

Lebenszyklus) darstellt.

Prozessanalyse

und

Prozess-

modellierung

Prozess-

ausführung

Prozess-

implementierung

Prozess-

evaluation

Schaubild 2.2: Geschäftsprozess-Lebenszyklus

Das Schaubild soll die Grundidee des Geschäftsprozessmanagement unterstrei-

chen, dass nach der erfolgreichen Umsetzung und laufenden Durchführung die Be-

trachtung der Prozesse nicht abgeschlossen ist, sondern durch die Evaluation eine neue

Phase in der Modellierung, Umsetzung und anschließender Durchführung beginnt.

Geschäftsprozesse sind damit einem ständigen Verbesserungsprozess unterworfen und

sind in dieser Weise der Wirklichkeit sehr nahe. Die Anforderungen an Unternehmen

und an ihre Produkte unterliegen gerade im Zuge der Globalisierung einem ständigen

Wandel und deshalb nimmt die Bedeutung der Fähigkeit, die Produkte rasch den neu-

en Gegebenheiten anzupassen zu können, immer mehr zu.

Es ist anzumerken, dass Hersteller der klassischen Workﬂow Management Systeme ih-

re Systeme dahingehend anpassen, dass sie den kompletten Zyklus des Geschäftspro-

zessmanagements unterstützen wollen [14]. Der Wandel in diese Richtung betrifft auch

die Begrifﬂichkeiten der „Prozesse“ und „Workﬂows“ dahingehend, dass die Terme

Prozess und Workﬂow sich mehr und mehr in ihrem Gebrauch und Bedeutung über-

lappen. Die Entwicklung der WfMS in Richtung Geschäftsprozessmanagement spiegelt

sich in der Einführung der sogenannten Geschäftsprozessmanagementsysteme wider

(nach [8]):

Deﬁnition 2.7 Ein Geschäftsprozessmanagementsystem ist ein generisches Softwaresys-

tem, das durch die explizite Prozessrepräsentation angetrieben, die Ausführung von Ge-

schäftsprozessen koordiniert.

Ob Notationen, die ursprünglich zur Modellierung von Workﬂows erdacht wurden,

zur Modellierung von abstrakten und fachlichen Prozessen geeignet sind, sollte durch-

aus kritisch hinterfragt werden. Gerade in Unternehmen wäre eine einheitliche Nota-

tion zu Modellierung von Prozessen und Workﬂows als Diskussionsgrundlage beson-

ders interessant. Die wirft aber weitere Fragen auf, die im nächsten Abschnitt detailiert

behandelt werden.

Kapitel 3

Strukturelle Eigenschaften

Zeitmanagement ist Unsinn. Sie können die Zeit nicht managen - nur Ihr Verhalten.

Michael Kastner (*1946)

dt. Psychologe u. Hochschullehrer

In diesem Kapitel sollen die bereits erwähnten, für eine Abbildung interessanten

strukturellen Eigenschaften von Prozessen bzw. Workﬂows untersucht werden. Es wur-

de bereits erläutert, dass WfMS strukturelle Merkmale der Workﬂow-Modelle für eine

korrekte Ausführung voraussetzen. Falls erweiternde Aspekte außen vor gelassen wer-

den und Prozesse wie auch Workﬂows hauptsächlich aus einer zeitlichen Koordination

von Elementen betrachtet werden, ist eine strukturelle Klassiﬁkation von Prozessen

prinzipiell gleichbedeutend mit einer Klassiﬁkation von Workﬂows. Deshalb wird an-

gemerkt, dass der Begriff Workﬂow in diesem Fall synonym für Prozessmodell bzw.

Workﬂow-Modell verwendet wird. Dies erklärt sich aus dem Umstand, dass ein Work-

ﬂow die betont operative technische Sicht eines Prozesses ist. Da das Ziel dieser Arbeit

eine Abbildung eines Prozessmodelles auf einen Workﬂow ist, ist die Semantik der Ele-

mente in Bezug auf die Ausführung im Besonderen von Bedeutung.

3.1 Strukturelle Klassiﬁzierung von Workﬂows

Die folgenden Passagen werden eine Klassiﬁzierung von Workﬂows vornehmen, um

Aussagen über ihr Verhalten und Eigenschaften treffen zu können. Workﬂows können

anhand ihrer unterschiedlichen strukturellen Restriktionen unterschieden werden. Die

mächtigste Klasse sind die strukturell unbeschränkten Workﬂows. Sie unterliegen kei-

nerlei Beschränkung und besitzen deshalb eine hohe Ausdruckskraft. Aber es obliegt

der Veranwortung des Modellierers einen Workﬂow korrekt, also z.B. ohne Deadlocks,

zu modellieren und ist deshalb für die Anwendung in unternehmenskritischen Berei-

chen keinesfalls zu empfehlen. Strukturell beschränkte Notationen hingegen besitzen

strukturelle Einschränkungen in der Modellierung eines Workﬂows. Sie besitzen aber

den Vorteil, dass sie durch ihre Struktur per Deﬁnition schon Eigenschaften, wie zum

Beispiel die Verhinderung von Deadlocks, besitzen.

Um theoretische Grundlagen zu schaffen, und die Ergebnisse nicht durch spezielle Ei-

genschaften einer bestimmten Notation zu verfälschen, sollen im Folgenden zwei Meta-

notationen, die auf gemeinsamen Elementen basieren, zur Modellierung von unstruk-

turierten und blockstrukturierten Workﬂows deﬁniert werden.

Die Metanotationen bilden die Grundlage für die theoretischen Ergebnisse der folgen-

den Abschnitte und beschränken sich dabei auf reine Kontrollaspekte ohne syntak-

tische Zusätzen, die in Notationen in der Praxis zwangsläuﬁg von Nöten sind. Au-

ßerdem ist durch die Schaffung entsprechender Grundlagen in diesen Notationen ei-

ne Transportierung der Ergebnisse für die beiden Notationen BPMN und ADEPT gut

möglich.

3.1.1 Unstrukturierte Workﬂows

Deﬁnition 3.1 Ein unstrukturierter Workﬂow ist ein aus Aktivitäten, Kontrollelementen

und Kanten bestehender gerichteter Graph (nach [15]). Formal defniert ist ein unstrukturierter

Workﬂow ein Tripel Γu={A, E, K}.EsseiAdie Menge der Aktivitäten, Edie Menge der

Kanten und Kdie Menge der Kontrollelementen.

Es gelten folgende Annahmen:

1. Jedes Kontrollelement κ∈Kist von einem der folgenden Typen: Start, Ende, Split-

Parallel1, Join-Parallel2, Split-Auswahl, Join-Auswahl.

2. Kanten werden benützt, um Aktivitäten und Kontrollelemente zu verbinden. Eine Kante

e∈Evon Element u zu Element v (u, v ∈A∪K) wird durch =(u, v)repräsentiert.

3. Der Eingangsgrad d−(n)gibt die Anzahl der Kanten an, die in einen Knoten (Kontroll-

element oder Aktivität) n innerhalb eines Modells einmünden. Der Ausgangsgrad d+(n)

gibt an, wie viele Kanten von diesem Knoten n ausgehen.

4. Jedes Modell hat einen Start- und einen Endknoten. Es gilt für einen Startknoten g∈K

vom Typ Start: d−(g)=0und d+(g)=1. Für einen Endknoten f∈Kvom Typ Ende

gilt: d−(f)=1und d+(f)=0. Die Beschränkung auf einen Startknoten bzw. Endkno-

ten ist keine Einschränkung der Ausdrucksmächigkeit, da das Verhalten von mehreren

parallelen Startknoten oder Endknoten durch Kontrollelemente nachbildbar wäre.

5. Jede Aktivität a∈Ahat genau einen Vorgänger und einen Nachfolger, es folgt: d−(a)=

d+(a)=1.

6. Ein Kontrollelement s∈Kvom Typ Split-Parallel oder Split-Auswahl hat genau einen

Vorgänger und zwei Nachfolger: d−(s)=1und d+(s)=2.

Ein Kontrollelement j∈Kvom Typ Join-Parallel oder Join-Auswahl hat genau zwei

Vorgänger und einen Nachfolger: d−(j)=2und d+(j)=1. Somit kann durch den

Eingangs- und Ausgangsgrad bestimmt werden, ob ein Kontrollelement ein Split- oder

1engl. to split = sich teilen

2engl. to join = verbinden

ein Join-Element ist.

Die Festlegung auf zwei eingehende bzw. ausgehenden Kanten ist keine Einschränkung,

da Kontrollelemente hintereinander ausführbar sind, und dient rein der besseren An-

schaulichkeit in diesem Kapitel.

7. Es wird festegelegt, dass in mindestens einem Pfad von einem Split- zu einem Join-

Element eine Aktivität vorhanden sein muss.

8. Jede Aktivität bzw. jedes Kontrollelement liegt auf mindestens einem Pfad vom Start- zum

Endknoten. Folglich gibt es keine Elemente, die nicht mit dem Workﬂow verbunden sind.

Die Elemente eines von uns deﬁnierten Workﬂows wurden in der folgenden Abbil-

dung 3.1 graphisch dargestellt.

(a) Start (b) Ende (c) Aktivität (d) Split-Parallel (e) Join-Parallel (f) Split-Auswahl (g) Join-Auswahl

and or

ES or

and

Schaubild 3.1: Graphische Notation der Workﬂow-Elemente

3.1.1.1 Ausführungssemantik

Um eventuellen Missverständnissen vorzubeugen und die Vorstellung der Notationen

BPMN und ADEPT zu erleichtern, soll auf die Semantik der deﬁnierten Elemente de-

taillierter eingegangen werden.

Die Kanten eines Workﬂows dienen als Kontrollkanten, die den zeitlichen Ablauf inner-

halb eines Workﬂows deﬁnieren. Beispielsweise wird bei einer Kante von Aktivität A

nach Aktivität B, B erst dann ausgeführt, wenn A erfolgreich beendet wurde. Die nach

einem Split-Parallel nachfolgenden Pfade werden zeitlich parallel ausgeführt. Analog

folgt, dass ein Join-Parallel nur dann ausgeführt werden kann, wenn beide eingehen-

den Pfade als erfolgreich ausgeführt markiert wurden. Wir setzen außerdem voraus,

dass nach einem Split-Auswahl-Kontrollelement genau ein Pfad ausgeführt wird. Dies

entspricht einer sogenannten XOR-Semantik. Eine Or-Semantik, also einer Auswahl m

aus n Pfade, wobei 1≤m≤n, ist durch die Kombination von Split-Parallel- und Split-

Auswahl-Kontrollelementen darstellbar.

Für das Join-Auswahl-Kontrollelement ergeben sich für die Bewertung der eingehen-

den Kanten zwei Möglichkeiten:

1. Diskriminator - Einfache Ausführung: Das Join-Auswahl Element wird genau dann

einmal ausgeführt, wenn der erste eingehende Pfad ausgeführt wurde. Der zwei-

te Pfad werden nach seiner Ausführung nicht beachtet und verworfen.

2. Mehrfache Ausführung: Jede erfolgreich ausgeführte eingehende Kante bewirkt das

Ausführen des Kontrollelementes. Dabei werden die Aktivitäten nach dem Kon-

trollelement eventuell mehrmals ausgeführt, was zu Korrektheitsproblemen des

Workﬂows führen kann.

Eine Untersuchung der Folgen der unterschiedlichen Semantik des Join-Auswahl

Elementes ﬁndet in Abschnitt 3.2.1.2 statt.

3.1.2 Blockstrukturierte Workﬂows

Ein blockstrukturierter Workﬂow soll aus den Elementen, die bereits durch vorige De-

ﬁnition der strukturell unbeschränkten Workﬂows bekannt sind, deﬁniert werden. Ob-

wohl die Syntax und Semantik der Elemente identisch sind, wird durch die Form der

Deﬁnition eine Struktur in der Anordnung der Elemente explizit vorgegeben.

Deﬁnition 3.2 Ein blockstrukturierter Workﬂow Γs={A, E, K}ist ebenfalls ein Tripel

aus Aktivitäten, Kontrollelementen und Kanten. Der Aufbau der Modelle sei jedoch über die

Kontrollelemente Start S und Ende E (S, E ∈K) und einen strukturellen Platzhalter X

deﬁniert. Es existieren eine Kante von S zu X und eine Kante von X zu E. Dieser Sachverhalt

ist zur Anschauung in Schaubild 3.2 dargestellt.

Schaubild 3.2: Strukturierter Workﬂows – Basisstruktur

Der Platzhalter X kann durch eine einzelne Aktivität oder durch eines der Konstrukte, die

im Folgenden deﬁniert werden, ersetzt werden. Es ist außerdem möglich, X durch eine Kante

vom Kontrollelement Start zum Kontrollelement Ende zu ersetzen, und somit einen Workﬂow

ohne Aktivitäten und nur einem Start und Ende zu konstruieren.

Für die Deﬁnition der Konstrukte werden die Variablen Y und Z ebenfalls als Platzhalter

benutzt. Sie können wie X wiederum durch eines der Konstrukte oder durch eine einzelne

Aktivität ersetzt werden. Des Weiteren ist es möglich, innerhalb der Sequenz-, der Auswahl-

und der Schleifen-Struktur, eine der Variablen (also entweder Y oder Z) inklusive der einmün-

denen und ausgehenden Kante durch eine Kante vom Vorgänger- zum Nachfolger-Element zu

ersetzen. Beispiele hierzu sehen Sie in der Abbildung 3.4.

•Seien Y und Z strukturelle Platzhalter. Eine Konkatenation der strukturellen Platzhalter

Y und Z, bei der eine Kante von Y nach Z führt, wird Sequenz genannt.

•Seien s∈Kein Split-Auswahl Element, j∈Kein Join-Choice Element, Y und Z

strukturelle Platzhalter. Das Modell mit den Kanten (s,Y), (Y,j), (s,Z) und (Z,j) stellt

eine Auswahl-Struktur dar.

•Seien s∈Kein Split-Parallel Element, j∈Kein Join-Parallel Element, Y und Z

strukturelle Platzhalter. Ein Konstrukt mit den Kanten (s,Y), (Y,j), (s,Z) und (Z,j) stellt

eine Parallele-Struktur dar.

•Seien j∈Kein Join-Auswahl Element, s∈Kein Split-Auswahl Element, Y und Z

strukturelle Platzhalter. Ein Konstrukt mit den Kanten (j,Y), (Y,s), (s,Z) und (Z,j) stellt

eine Schleifen-Struktur dar.

Sequenz Parallel-Struktur

and

or Y

Auswahl-Struktur Schleifen-Struktur

jss j j s

Schaubild 3.3: Strukturierte Workﬂows – Konstrukte

Wie bereits angeführt, Beispiele für Variationen der Basiskonstrukte als Schaubild:

Sequenz ohne Z

Auswahl-Struktur ohne Z Schleifen-Struktur ohne Y

js js

Schaubild 3.4: Strukturierte Workﬂows – Variationen der Konstrukte

Die Deﬁnition der Platzhalter Y und Z verhindern das Benötigen sogenannter

„Null-Aktivitäten“, um zum Beispiel den direkten Weg eines Split-Elements zu einem

Join-Element zu simulieren.

Um anschaulich zu verdeutlichen, dass ein blockstrukturiertes Modell aus den korrekt

ineinander verschachtelten Grundkonstrukten besteht und diese dann „Blöcke“ bilden,

wurde Schaubild 3.5 gewählt.

or or C

and

Schaubild 3.5: Strukturierte Workﬂows - Veranschaulichung der Blockstruktur

Es ist anzumerken, dass jede Aktivität innerhalb eines blockstrukturierten Work-

ﬂows wie aus Schaubild 3.5 auch selbst wiederum einen blockstrukturierten Workﬂow

darstellen kann.

Diese hierarchische Verschachtelung, in der eine Akvität auch auch ein Subworkﬂow

bzw. ein Subprozess darstellen kann, ist nicht auf blockstrukturierte Modelle beschränkt

und kann natürlich auch in unstrukturierten Modellen existieren.

3.1.3 Weitere Formen

Natürlich existieren Zwischenformen innerhalb der Spanne zwischen den strukturell

unbeschränkten unstrukturierten Workﬂows und den strukturell stark eingeschränk-

ten blockstrukturierten Workﬂows. Einige WfMS, wie z.B. IBM MQ Series/Workﬂow

und InConcert, lassen die Modellierung strukturell unbeschränkter azyklischer Work-

ﬂows zu, während die Modellierung von Schleifen auf ein vorgefertigtes Konstrukt

eingeschränkt wird [16]. Die Klasse der Workﬂows mit eingeschränkten Schleifen (engl.

Restricted Loop Workﬂow Models, RLWM) soll aber nicht Gegenstand weiterer Unter-

suchungen sein. Der Grund hierfür ist, dass die Ergebnisse dieser Untersuchung auf

diese Klasse portierbar sind. Im folgenden Abschnitt wird dies ersichtlich werden.

3.2 Bewertung und Folgen struktureller Eigenschaften

Ein wesentliches Bestandteil der blockstrukturierten Workﬂows ist es, dass durch den

Umstand der Einschränkung der Modellierung auf blockstrukturierte Konstrukte eine

eins-zu-eins Beziehung zwischen jedem Split- und Join-Element desselben Typs gibt.

In einem unstrukturierten Workﬂow kann diese Beziehung ebenfalls auftreten, ist aber

keineswegs eine Voraussetzung. Folglich kann festgestellt werden, dass die Klasse der

blockstrukturierten Workﬂows eine Teilmenge der Klasse der strukturell unbeschränk-

ten Workﬂows ist. Um einen Zusammenhang zur Ausdrucksmächtigkeit einer Notati-

on herzustellen, soll dieser Begriff erläutert werden.

Deﬁnition 3.3 Die Ausdrucksmächtigkeit einer Notation sei deﬁniert als Anzahl der ver-

schiedenen Modelle, die in einer Notation modellierbar sind.

Es folgt somit, dass unstrukturierte Workﬂows eine höhere Ausdrucksmächtigkeit

besitzen als blockstrukturierte Workﬂows. Diese Sachverhalte ergeben sich unmittel-

bar aus den Deﬁnitionen des blockstrukturierten Workﬂows und bedürfen keines Be-

weises. Eine Einordnung der Klasse der Workﬂow-Modelle mit beschränkten Schlei-

fen als Teilmenge der strukturell unbeschränkten Workﬂows und als Obermenge der

blockstrukturierten Workﬂows ist ebenfalls in der Literatur gegeben [16]. Insgesamt er-

gibt sich ein Zusammenhang dieser drei Klassen, der in Schaubild 3.6 graﬁsch illustriert

wurde.

strukturell unbeschränkte Workflows

Workflows mit eingeschränkten Schleifen

blockstrukturierte Workflows

Schaubild 3.6: Zusammenhang der Workﬂow-Klassen

Eine Untersuchung der Abbildungsmöglichkeiten von unstrukturierten Modellen

auf blockstrukturierte schließt durch diesen Zusammenhang die Untersuchung der Ab-

bildung der Klassen der Workﬂows mit eingeschränkten Schleifen auf blockstrukturier-

te Workﬂows mit ein.

Der unterschiedliche Grad an Struktur innerhalb der Workﬂow-Modelle impliziert Fol-

gen für die Modellierung, die im folgenden Abschnitt untersucht werden sollen. Es

wird auf die zwei Hauptprobleme in diesem Zusammenhang, namentlich Deadlocks

und multiple Instanzen einer Aktivität im Detail eingegangen.

Abschließend soll ein Zusammenhang zwischen Ausdrucksmächtigkeit und Sicherheit

gegenüber Fehlern aus strukturellen Mängel hergeleitet werden, um das Kapitel abzu-

runden.

3.2.1 Folgen struktureller Mängel

Durch die, gegenüber blockstrukturierten Workﬂows, erweitertenden Möglichkei-

ten der Modellierung ist es in unstrukturierten Workﬂows möglich, Konstrukte zu

modellieren, die schwerwiegende Folgen für die spätere Instanziierung der Modelle

haben können. Gerade bei Workﬂows, die in einem hohem Maße wichtig für den

Geschäftsbetrieb eines Unternehmens sind, kann dies schwerwiegende Folgen mit

sich ziehen. So können beispielweise Produktionsausfälle und Datenverluste mit

den entsprechenden Folgen für ein Unternehmen verursacht werden. Bei Workﬂows

im klinischen Umfeld sind Laufzeitfehler eventuell mit noch gravierenderen Kon-

sequenzen verbunden. Es ist deshalb notwendig mit gebotener Sorgfalt zu prüfen,

ob ein Workﬂow strukturelle Mängel besitzt und welche Folgen diese Mängel mit

sich ziehen. Im Folgenden wird auf die zwei Hauptprobleme im Näheren eingegangen.

3.2.1.1 Deadlocks

Durch die mangelnde Vorschrift an Struktur für unstrukturierte Workﬂows, kann der

Modellierer Konstrukte modellieren, die zu Verklemmungen (engl. Deadlocks) führen.

Verklemmungen haben zur Folge, dass der Endzustand, also hier das Kontrollelement

Ende, niemals erreicht werden kann. Das Schaubild 3.7 zeigt einen einfachen Workﬂow,

der in dieser Form niemals den Endzustand erreichen wird. Der Join-Parallel kann erst

Aktivität C aktivieren, wenn in den beiden einmündenden Pfade alle Aktivitäten, in

diesem Fall A und B, ausgeführt wurden. Da nur ein Pfad durch den Split-Auswahl

zur Ausführung gebracht wird, kann somit Aktivität C niemals ausgeführt werden.

and

Schaubild 3.7: Erste Deadlock-Variante

Das Modell in Schaubbild 3.8 zeigt einen verschachtelten Workﬂow, in dem der

letzte Join-Parallel ebenfalls zwei erfolgreich ausgeführte Pfade erwartet. Durch den

rot gekennzeichneten Split-Auswahl wird aber nur ein Pfad ausgeführt werden. Der

Workﬂow kann somit nicht terminieren.

and

Schaubild 3.8: Zweite Deadlock-Variante

Einen Sonderfall spiegelt der folgende Workﬂow in Schaubild 3.9 wider. Ein Schlei-

fe, die in dieser Form durch einen Join-Parallel und einen Split-Parallel konstruiert wur-

de, führt ebenfalls dazu, dass der Workﬂow nicht terminieren kann. Da der Join-Parallel

auf die beiden eingehenden Kanten wartet, aber eine Kante nur ausgeführt werden

kann, wenn der Join-Parallel bereits geschaltet wurde, ist eine Verklemmung die Folge.

and and

Schaubild 3.9: Dritte Deadlock-Variante

3.2.1.2 Multiple Instanzen einer Aktivität

Neben Deadlocks, die eine Terminierung des Workﬂows verhindern, ergeben sich

durch die fehlende strukturelle Einschränkung bei unstrukturierten Workﬂows eine

weitere Problemquelle. Es wurde bereits erwähnt, dass der Join-Auswahl semantisch

einerseits als Diskriminator wirken kann oder andererseits eine mehrfache Ausführung

unterstützt. Falls der Join-Auswahl eine mehrfache Ausführung unterstützt, ergeben

sich durch die Modellierung bestimmter Konstrukte innerhalb eines Modells Folgen,

die in der Literatur als Problem der multiplen Instanzen einer Aktivität oder als Problem

der fehlenden Synchronisation bezeichnet werden.

Der Workﬂow in Schaubild 3.10 soll dieses Problem illustrieren. Nach dem Split-

Parallel werden beide Pfade aktiviert und die Aktivitäten A und B ausgeführt.

Nachdem die Aktivitäten erfolgreich beendet wurden, wird Aktivität C zweimal

ausgeführt, da der Join-Auswahl bei entsprechender Semantik der mehrfachen Aus-

führung Aktivität C zweimal aktiviert. Besonders kritisch ist dieser Fall, falls Aktivität

C nun auf Ressourcen wie Daten zugreift. So kann es beispielsweise zu unvorgesehe-

nem Verhalten kommen, falls nachdem Aktivität C das erste Mal beendet wurde und

die Ressource für eine andere Aktivität freigegeben wird, aber die zweite Instanz der

Aktivität C nochmals auf die Ressource zugreift. Ebenfalls kritisch zu sehen ist der Fall,

dass nach dem Beenden der ersten Instanz von C, der Workﬂow terminiert werden

soll, obwohl eine zweite Instanz der Aktivität C eventuell noch nicht beendet wurde.

and

Schaubild 3.10: Multipl. Instanzen einer Aktivität – erste Variante

In Schaubild 3.11 treten prinzipiell die gleichen Probleme wie in Schaubild 3.10 auf.

Es soll aber auch aufgezeigt werden, dass es, wie in Schaubild 3.8, schwieriger ist, das

Problem zu identiﬁzieren.

and

Schaubild 3.11: Multipl. Instanzen einer Aktivität – zweite Variante

Das Schaubild 3.12 zeigt eine Schleifenvariante, die ebenfalls zu multiplen Instan-

zen einer einzelnen Aktivität führen kann. Ein weiteres Problem ist es, dass diese Schlei-

fe niemals beendet werden kann und somit eine Endlosschleife innerhalb des Work-

ﬂows darstellt.

or and

Schaubild 3.12: Multipl. Instanzen einer Aktivität – dritte Variante

3.2.2 Zusammenhang Ausdrucksmächtigkeit und Sicherheit

Durch die vorgestellten Folgen struktureller Mängel kann es also vorkommen, dass

Workﬂows nicht erfolgreich terminieren können. Eine erfolgreiche Beendigung eines

Workﬂow beinhaltet das Erreichen des Kontrollelements Ende, ohne dass weitere Ak-

tivität zu diesem Zeitpunkt vor der Ausführung stehen oder in diesem Moment aus-

geführt werden. Es wird deshalb der Begriff well-behaved (zu deutsch brav, artig) analog

zu [17] verwendet:

Deﬁnition 3.4 Ein Workﬂow ist well-behaved, wenn er unter allen Ausführungsmöglichkei-

ten erfolgreich terminiert.

Jeder blockstrukturierte Workﬂow ist automatisch well-behaved. Dies folgt durch den

Umstand, dass blockstrukturierte Workﬂows rein aus der Komposition der Grundkon-

strukte bestehen und diese nicht zu Deadlocks führen können [16]. Die Umkehrung

dieses Satzes gilt aber nicht. Es gibt also Workﬂows, die nicht blockstrukturiert sind,

aber dennoch well-behaved sind.

Ein Beispiel für diesen Sachverhalt gibt der Workﬂow in Schaubild 3.13.

and

Schaubild 3.13: Beispiel - Well-behaved und nicht blockstrukturierter Workﬂow

Die Behauptung, dass dieser Workﬂow keine blockstrukturierte, äquivalente Form

besitzt, soll bewiesen werden.

Beweis 1 Als Beweis ist zu betrachten, dass die Aktivitäten B und C nicht voneinander ab-

hängig sind. Sie müssen deshalb in einer blockstrukturierten Variante des Workﬂows in einer

parallelen Struktur auf verschiedenen Pfaden sein. Es ist ebenfalls zu beobachten, dass die Ak-

tivität D von Aktivität B abhängt und die Aktivität E von Aktivität C abhängt. Deshalb muss

Aktivität D innerhalb der parallelen Struktur nach B kommen und Aktivität E nach C. Aktivi-

tät D kann nicht außerhalb der Struktur sein, da sie dann auch von C abhängen würde. Falls

E außerhalb der Struktur wäre, würde diese Aktivität erst nach Aktivität D ausgeführt wer-

den. Die bisherigen Erkenntnisse sind zum besseren Verständnis im folgenden Schaubild 3.14

dargestellt.

and

Schaubild 3.14: Beweisskizze unstrukturierte artige Workﬂows

Da aber Aktivität E von den Aktivitäten B und C abhängt, ist ein Widerspruch gegeben.

Denn Aktivität E muss sich, wie bereits erklärt, innerhalb der parallelen Struktur beﬁnden. Es

gibt also für diesen unstrukturierten Workﬂow kein blockstrukturiertes Äquivalent.

Im folgenden Kapitel wird im Rahmen der Vorstellung von ADEPT die Erweiterung

der blockstrukturierten Notationen um Synchronisationkanten aufgezeigt. Mit Zuhil-

fenahme dieser Kanten ist es möglich, einen blockstrukturierten Workﬂow mit den

entsprechende Eigenschaften zu modellieren, der äquivalent zum Workﬂow in Schau-

bild 3.13 ist. Nach dem Beweis, dass es Workﬂows gibt, die well-behaved, aber nicht

blockstrukturiert sind, soll ein Zusammenhang zwischen den strukturellen Einschrän-

kungen, die zu einer Verminderung der Ausdrucksstärke einer Notation führen, und

der wachsenden Sicherheit gegenüber einer Modellierung von Laufzeitfehlern verur-

sachenden Konstrukten hergestellt werden.

Es wurde bereits erläutert durch welche Konstrukte Deadlocks oder multiple Instanzen

einer einzelnen Aktivität aufreten können. Äquivalente blockstrukturierte Abbildun-

gen dieser Konstrukte sind nicht möglich, da diese ebenfalls zu Deadlocks oder mul-

tiplen Instanzen führen müssten und diese in einer blockstrukturierten Notation nicht

vorkommen können. Außerdem verhindern die Klasse der Workﬂows mit beschränk-

ten Schleifenkonstrukten die Modellierung von Deadlocks und multiplen Instanzen

über Schleifenkonstrukten. Es werden also die Möglichkeiten zur Modellierung von

Laufzeitfehlern eingeschränkt, wenngleich nicht vollkommen ausgeschlossen.

Aus diesen Erkenntnissen folgt, dass die Sicherheit einer Notation vor Modellierung

von Laufzeitfehler SNwie z.B. Deadlocks reziprok proportional zur Ausdrucksmäch-

tigkeit einer Notation ANist. Der Sachverhalt, illustriert in Schaubild 3.15, ist rein von

qualitativer Aussage und keinesfalls quantitativ zu verstehen.

strukturell unbeschränkte Workflows

Workflows mit eingeschränkten Schleifen

blockstrukturierte Workflows

Ausdrucksmächtigkeit AN

Sicherheit vor Laufz.-Fehlern SN

Schaubild 3.15: Vergleich Ausdrucksmächtigkeit u. Sicherheit v. Notationen

Mit dieser Erkenntnis soll dieses Kapitel abgeschlossen werden. Eine im höchsten

Maße ausdrucksstarke Notation, die gleichzeitig das Modellieren von Laufzeitfehlern

verhindert, kann somit als konzeptioneller Widerspruch angesehen werden.

Kapitel 4

Modellierung

Niemand plant, zu versagen, aber die meisten versagen beim Planen.

Lee Iacocca (*1924)

amerik. Manager und Rhetoriker

Nach den theoretischen Ausführungen über den Zusammenhang von Ausdrucks-

stärke und Sicherheit vor Laufzeitfehlern, sowie der theoretischen Einführung der un-

strukturierten wie blockstrukturierten Notationen in Kapitel 3, sollen nun die zwei No-

tationen BPMN und ADEPT1vorgestellt werden. Weiterhin werden die Ergebnisse aus

Kapitel 3 auf diese Notationen übertragbar. Zuvor soll ein kurzer Überblick über die

verschiedenen Möglichkeiten der Modellierung erfolgen.

4.1 Bekannte Formen

Bei der Wahl einer Notation zu Modellierung von Prozessen oder Workﬂows stellt

sich die Frage nach dem Zweck der Modellierung und ebenfalls dem fachlichen Hin-

tergrund des Modellierers. Für eine Erfassung, Analyse und Optimierung von Ge-

schäftsprozessen auf strategischem Level ist eine Notation zur Modellierung von Work-

ﬂows möglicherweise zu überladen und bietet eventuell zu wenig Abstraktionsmög-

lichkeiten. Dazu können, wie bereits angeführt, die Details und strukturellen Beschrän-

kungen, die für eine spätere Ausführung benötigt werden, ein Hindernis darstellen.

Jedoch enthalten die bereits erwähnten BPMS proprietäre Notationen, die zur Mo-

dellierung der strategischen Geschäftsprozesse und späteren Verfeinerung dienen sol-

len. Bekannte herstellerunabhängige Notationen, die sich zur Modellierung von Ge-

schäftsprozessen auf strategischem Level anbieten sind die bereits erwähnte BPMN,

die in diesem Kapitel detaillierter vorgestellt wird, die ereignisgesteuerten Prozessket-

ten (EPK), die wesentlicher Bestandteil des ARIS-Konzeptes sind und die UML Aktivi-

tätendiagramme [2].

Auf eine explizite Nennung herstellerbezogenene Notationen zur Modellierung von

1ADEPT steht für Application Development based on Encapsulated Premodelled Process Templates

Workﬂows für ein WfMS soll an dieser Stelle verzichtet werden. Ein Überblick bekann-

ter Notation zur Modellierung von Workﬂows ist beispielsweise in [18] und [19] gege-

ben. In diesen Arbeiten werden die Notation unter anderem anhand von Workﬂow-

Patterns [13] bezüglich ihrer Ausdrucksmächtigkeit und Angemessenheit evaluiert.

Um Ausführungseigenschaften der Workﬂows zu analysieren beruhen einige Notatio-

nen auf formale Modelle, wie beispielsweise die Petri-Netze [20].

Das WfMS ADEPT2 [21, 22] des Insitituts für Datenbanken und Informationssysteme

der Universität Ulm besitzt mit der Notation ADEPT eine eigene Notation zur Model-

lierung von Workﬂows, die ebenfalls auf einer fundierten formalen Grundlage beruht

[23]. In ADEPT wurde neben der Sicherheit der Workﬂows vor Laufzeitfehleren, wie

Deadlocks, der Schwerpunkt auf ein, für eine blockstrukturierte Notation, hohes Maß

an Flexibilität gelegt. Eine detailierten Vorstellung erfolgt in Abschnitt 4.3.

4.2 BPMN

Die BPMN wurde ursprünglich von der BPMI (Business Process Management Initiati-

ve) entwickelt [3]. Diese schloss sich 2003 mit der OMG zusammen, so dass die BPMN

unter dem Dach der 1993 gegründeten OMG weiterentwickelt wird. Die Notation setzt

ihren Schwerpunkt auf den Kontrollﬂuss. Die momentan aktuelle Version 1.1 ist da-

tiert auf den 6. Februar 2006, eine verbesserte Version 2.0 ist in Planung. Die Ziele der

OMG [24] waren es, eine Notation zu speziﬁzieren, die von allen Beteiligten eines Ge-

schäftsprozesses schnell verstandenden wird. Nach einer Analyse in [4] wurde dieses

Ziel erreicht, da BPMN im geschäftlichem Umfeld (u.a. Prozessdokumentation, Prozes-

soptimierung, Unternehmensanalyse) wie im technischen Bereich (u.a. Prozesssimu-

lation) gleichermaßen Akzeptanz ﬁndet. Nach der Auffassung der OMG soll BPMN

sich zum Standard für die Modellierung von Pozessen entwickeln, vergleichbar in der

Bedeutung mit der Uniﬁed Modeling Language (UML) für objekt-orientiertes Design

und Analyse [8]. Im Juni 2008 unterstützen laut der OMG (www.bpmn.org) 47 Her-

steller von Werkzeugen zur Modellierung von Geschäftsprozessen BPMN. Es ist zwar

möglich, neben abstrakten Prozessen auch bis zu einem gewissen Grad operative Pro-

zessmodelle zu modellieren, jedoch unterstützt die BPMN nicht nativ die direkte Aus-

führung der Modelle. Doch existieren bereits Abbildungen [25, 26, 27] zum Beispiel

zur ausführbaren Business Process Execution Language for Web Services (BPEL4WS

oder BPEL, [28]), dem de facto Standard in der Implementierung von Geschäftspro-

zessen auf Basis von Web-Services [12]. Es kann aber festgehalten werden, dass es ohne

Nacharbeiten nicht möglich ist, operative Prozesse mit BPMN zu modellieren und diese

direkt nach der Abbildung in BPEL auszuführen. Eine Arbeit bezüglich den konzeptio-

nellen Unterschieden der BPMN und BPEL stellt [27] dar.

Die Modelle werden in der BPMN in einem sogenannten Business Process Diagramm

erfasst, das aus den BPMN-Elementen besteht. Im Folgenden werden nur die Kernele-

mente der BPMN, die relevant für eine spätere Untersuchung der Abbildung sind, vor-

gestellt. Analysen und Bewertungen der BPMN und die Speziﬁkationen der Elemente

der BPMN sind in [3, 29, 8, 30] zu ﬁnden.

4.2.1 Elemente

Viele der folgenden Elemente haben ein Äquivalent in der bereits in Kapitel 3 vorge-

stellten unstrukturierten Metanotation. Eine deutsche Kurzübersicht über alle vorhan-

denen Elemente der BPMN inklusive kurzen Erläuterungen ist auf der Webseite des

Hasso-Plattner-Instituts2der Universität Potsdam zu ﬁnden.

Analog zur Metanotation besitzt ein Modell in BPMN ein Start- und ein End-Ereignis

und natürlich Aktivitäten. Bezüglich der Möglichkeiten der Anordnung der Elemente

in der BPMN sei an dieser Stelle auf die Spezifaktion in [3] verwiesen. Im Folgenden

werden rein die für eine kontrollﬂussbasierte Untersuchung der Abbildung relevan-

ten Elemente gemäß der Speziﬁkation vorgestellt. In jedem Abschnitt wird durch ein

Schaubild die Symbolik illustriert und die Bedeutung durch Ergänzungen festgelegt.

4.2.1.1 Aktivitäten

Eine Aktivität wird in der BPMN als Rechteck mit gerundeten Kanten dargestellt. Un-

ter anderem haben zum Beispiel Subprozesse ebenfalls die gleiche Erscheinung. Diese

sind aber mit einem Plus in einem kleinen Quadrat innerhalb des Rechteckes zusätzlich

gekennzeichnet. Schaubild 4.1 zeigt eine Aktivität in BPMN.

Schaubild 4.1: BPMN – Aktivität

4.2.1.2 Kanten

Es gibt in BPMN drei verschiedene Kanten. Den Sequenzﬂuss, den bedingten Fluss,

dem eine Bedingung angeheftet ist, und den Standardﬂuss. Der bedingte Fluss ermög-

licht es in BPMN, eine Verzweigung ohne ein Kontrollelement zu realisieren und die-

ser Verzweigung eine Bedingung zu Grunde zu legen. Die Verzweigung ohne Gateway

wird in Abschnitt 4.2.1.4 behandelt. Mit dem Standardﬂuss ist es möglich, bei einer Ver-

zweigung den Pfad zu kennzeichnen, der gewählt werden soll, wenn die Bedingungen

der restlichen Pfade nicht zutreffen. Der Sequenzﬂuss ist jedoch die Kante der Wahl

um auszudrücken, dass eine Aktivität nach einer anderen ausgeführt werden soll. Sie

ist die Kante, die wir in der Untersuchung der Abbildbarkeit berücksichtigen werden,

da die weiteren Kanten eine Untersuchung der Abbildung komplexer werden lassen.

2dt.BPMN-Poster:http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_

1_Poster_DE.pdf

Sequenzfluss Bedingter Fluss Standardfluss

Schaubild 4.2: BPMN – Kanten

4.2.1.3 Ereignisse

Um in BPMN den Start- bzw. das Ende eines Prozesses auszudrücken, werden Ereig-

nisse (auch Events genannt) verwendet. Das Startereignis ist ein symmetrischen Kreis

mit einfacher Kontur. Das Endereignis zur Markierung des Endes eines Prozesses ist

ebenfalls ein symetrischer Kreis. Dieser besitzt aber eine deutlichere Kontur. BPMN

erlaubt es die Kreise mit dem Grund des Ereignisse zu füllen, also z.B. könnte das Ein-

treffen einer Nachricht den Start eines Prozesses auﬂösen. Auf diese Erweiterungen soll

in dieser Arbeit verzichtet werden, da diese von keiner Relevanz für diese Arbeit sind.

Ebenfalls weitgehend vernachlässigt werden sogenannte Zwischenereignisse, die wäh-

rend eines Prozesses auftreten können oder den Prozess verzögern können. Beispiele

für Zwischenereignisse sind das Ereignis des Empfangs oder Versands einer Nachricht.

Details zu Ereignissen sind in [3] und in kürzerer Fassung in [8] zu ﬁnden.

Startereignis Zwischenereignis Endereignis

Grundform

Beispiel für

eine Erweiterung

Schaubild 4.3: BPMN – Ereignisse

4.2.1.4 Gateways

Gateways dienen in BPMN zur Steuerung des Kontrollﬂusses. Das parallele Gateway

besitzt wie das Daten-basierte exklusive Gateway (im Verlauf der Arbeit schlicht als

„exklusives Gateway“ benannt) eine Entsprechung in den Kontrollelementen der

Metanotation aus Kapitel 3. So bringt das parallele Gateway, wenn es als Split-Element

eingesetzt wird, zum Ausdruck, dass die ausgehenden Pfade parallel ausgeführt

werden sollen. Wenn das parallele Gateway als Synchronisierer mehrerer Pfade dient,

wird der ausgehende Pfad nur im Falle der erfolgreichen Ausführung aller eingehen-

den Pfade aktiviert. Bei der Verwendung des exklusiven Gateway als Split-Element

wird genau ein Pfad zur Ausführung ausgewählt, während bei der Verwendung zur

Synchronisation der ausgehende Pfad, nachdem ein eingehender Pfad erfolgreich

ausgeführt wurde, aktiviert wird. Die restlichen eingehenden Pfade werden nicht

ignoriert und somit erlaubt das exklusive Gateway die Ausführungssemantik einer

mehrfachen Ausführung. Das exklusive Gateway kann einerseits als Raute ohne Inhalt

oder als Raute mit dem Buchstaben „X“ als Markierung dargestellt werden.

Neben diesen zwei für die Untersuchung hauptsächlich relevanten Elemente existieren

noch das Ereignis-basierte exklusive Gateway, das inklusive Gateway und das komplexe

Gateway. Das Ereignis-basierte exklusive Gateway dient als exklusives Split-Element,

das auf den Eintritt von Ereignissen wartet. Das inklusive Gateway erlaubt eine Aus-

wahl m aus n Pfaden (für 1≤m≤n) sowie das Synchronisieren der entsprechenden

Pfade. Das komplexe Gateway als Split-Element ist zur Ausführung von komplexen

Bedingungen für die Pfade zu verwenden. Eine Simulation der Bedingungen durch

parallele und exklusive Gateways sollte möglich sein, wenngleich diese Umwandlung

von komplexer Natur sein kann. Als Join-Element kann das komplexe Gateway, mit

den entsprechenden Attributen versehen, zur Verwendung als Diskriminator in BPMN

dienen. Das so eingesetzte komplexe Gateway aktiviert somit nach erfolgreicher

Ausführung eines Pfades das folgende Element und ignoriert alle weiteren erfolgreich

ausgeführten Pfade.

Exklusives

Gateway

Ereignis-basiertes

exklusives Gateway

Paralleles

Gateway

Inklusives

Gateway

Komplexes

Gateway

Schaubild 4.4: BPMN – Gateways

BPMN erlaubt im Gegensatz zu der Metanotation aus Kapitel 3 und ADEPT die

Modellierung von Verzweigungen und Synchronisationen ohne entsprechende Split-

und Join-Elemente. Eine Verzweigung von zwei (oder mehr Kanten) kann in ein par-

alleles Gateway (mehrere parallele Gateways) transformiert werden. Die Berücksich-

tigung von bedingtem Fluss und Standardﬂuss würde in einer Transformation von

diesen Kanten in exklusive und eventuell parallele Gateways münden. Schaubild 4.5

zeigt ein Prozessmodell mit einer Verzweigung ohne Gateway. Diese Verzweigung ent-

spricht einer Verzweigung durch ein paralleles Gateway.

Das Schaubild 4.5 zeigt außerdem ein Beispiel für das Zusammenführen zweier Kan-

ten in eine Aktivität ohne ein Gateway. Diese Form der Modellierung ist gleichwertig

zur Modellierung mit einem exklusiven Gateway. Dieses Prozessmodell besitzt also das

Problem der multiplen Instanzen einer Aktivität.

Schaubild 4.5: BPMN – Prozessmodell ohne Gateways

Es sei darauf hingewiesen, dass die Verzweigungen bzw. das Zusammenführung

von Kanten ohne Gateways für die Untersuchung der Abbildbarkeit in Kapitel 5 in

äquvialente Formen mit Gateways, wie bereits vorgestellt, überführt werden.

4.2.1.5 Daten

Die Dokumentation der Zugriffe auf Daten durch Aktivitäten erfolgt durch Datenob-

jekte. Die Verbindung dieser Objekte zu Aktiviäten wird durch Assoziationen, die als

gestrichelte Linien aufgeführt sind, hergestellt. Assoziationen können Richtungen ha-

ben, die durch Pfeile ausgedrückt werden. Es kann somit der Schreibvorgang oder der

Lesevorgang einer Aktivität auf ein Datenobjekt dargestellt werden.

Datenobjekt ungerichtete

Assoziation

gerichtete

Assoziation

beidseitig gerichtete

Assoziation

Schaubild 4.6: BPMN – Daten

4.2.1.6 Weitere Elemente

Auf eine detaillierte Vorstellung weiterer Elemente, wie zum Beispiel Swimlanes und

Pools, die zur Repräsentation von Rollen dienen, oder Transaktionen, die zur Fehler-

behandlung in Prozessen genutzt werden können, wird an dieser Stelle verzichtet. Der

Grund liegt im zeitlichen Rahmen dieser Arbeit.

4.2.2 Grundlegende Modelle in BPMN

Um einen Eindruck in die Modellierung von Modellen durch die BPMN zu vermit-

teln, werden in den folgenden Schaubildern die Modellierung der blockstrukturierten

Grundkonstrukten gezeigt. Außerdem soll ein ausführlicher, unstrukturierter Beispiel-

prozess gezeigt werden. Für die Konstrukte wurde auf das Einfügen der Start- und

Endereignisse verzichtet, da diese bei einer Abbildung in der Regel nicht alleinstehend,

sondern innerhalb eines größeren Modelles vorkommen werden.

Die Schaubilder 4.7, 4.8 und 4.9 dürften aufgrund der Vorstellung der Elemente in vor-

hergehenden Abschnitten und den Ergebnisse aus Kapitel 3 selbsterklärend sein. Ei-

ne Besonderheit stellt die Modellierung von Schleifen in BPMN dar. Schleifen können

beispielsweise wie in Schaubild 4.10 modelliert werden. Natürlich ist das exklusive

Gateway als Join-Element nicht notwendig, da die Kante auch direkt in die folgende

Aktivität münden könnte. Es existeren aber auch noch weitere Sonderelemente in der

BPMN zur Modellierung von Schleifen. Es darf aber darauf hingewiesen werden, dass

diese Elemente sich prinzipiell auf das Konstrukt in Schaubild 4.10 abbilden lassen.

Task Task

Schaubild 4.7: BPMN – grundl. Modelle – Sequenz

Task

Schaubild 4.8: BPMN – grundl. Modelle – Auswahlstruktur

Task

Schaubild 4.9: BPMN – grundl. Modelle – Parallele Struktur

Task

Schaubild 4.10: BPMN – grundl. Modelle – Schleifenmöglichkeit

Um die Modellierung eines kompletten Prozesses in BPMN zu demonstrieren, wur-

de Schaubild 4.11 ausgewählt. Es wurde bewusst auf ein blockstrukturiertes Modell

verzichtet, um die Modellierung unstruktrurierte Modelle in BPMN zu demonstrieren.

Task

Task Task Task Task

Schaubild 4.11: BPMN – grundl. Modelle – Beispiel eines kompl. Prozesses

4.2.3 Einordnung

Die BPMN schreibt für die Modellierung der Modelle bzw. der Diagramme keine

Vorgaben bezüglich der Einschränkung von Schleifen oder der Schaffung von syme-

trischen Blöcken vor. Die Ergebnisse für unstrukturierte Workﬂows aus Kapitel 3 sind

damit auf BPMN übertragbar. Damit ist BPMN eine sehr ausdrucksstarke Notation, die

keinerlei strukturellen Einschränkungen besitzt, um die Modellierung von Deadlocks,

multiplen Instanzen einer Aktivität oder Endlosschleifen zu verhindern.

4.3 ADEPT

Nach der Vorstellung der unstrukturierten Notation BPMN soll nun die blockstruktu-

rierte Notation ADEPT vorgestellt werden. ADEPT entstand im Zusammenhang mit

der Entwicklung des gleichnamigen WfMS am Institut für Datenbanken und Infor-

mationssysteme der Universität Ulm [31]. Die erste verfügbare Version des Workﬂow-

Management-Systems ADEPT stammt aus dem Jahr 1998. Die Grundlagen für die Ent-

wicklung dieses WfMS liegen unter anderem in Forschungsarbeiten zur Demonstrati-

on von Adhoc-Flexibilität in einer blockstrukturierten Notation [23] und der verteilten

Ausführung von Workﬂows [32]. Um neuen Forschungsergebnissen gerecht zu wer-

den, wurde die Entwicklung und Implementierung des WfMS ADEPT2 im Rahmen

des AristaFlow-Projektes3im Jahre 2004 begonnen. Im Jahr 2008 erfolgte die Ausgrün-

dung in die AristaFlow GmbH und die Entwicklung zur Produktreife.

In die Implementierung des WfMS ADEPT2 sollen aktuelle Forschungskonzepte ein-

ﬂießen. So soll ADEPT2 durch Eigenschaften bestechen, die in zu dieser Zeit ver-

fügbaren Workﬂow-Management-Systemen wenn überhaupt nur bedingt unterstützt

werden. Beispiele hierfür sind die Prozess-Schema-Evolution, die Prozesskomposition

per „plug-and-play“ oder die Beachtung von semantischen Einschränkungen [31]. Das

Prinzip der Prozess-Schema-Evolution [33] erlaubt es, Änderungen am Workﬂowmo-

dell (Schema) vorzunehmen und diese Änderungen, falls der Zustand der Instanzen

dies erlaubt, auf bereits laufende Instanzen zu übertragen.

4.3.1 Elemente

Die Modellierung in ADEPT erfolgt wie in BPMN graphisch als gerichteter Graph. Im

Gegensatz zu BPMN ist die Menge an Symbolen jedoch überschaubarer. Jedes Modell

besteht grundsätzlich aus Knoten und Kanten. Kontrollelemente, die zum Aufbau

von z.B. parallen Strukturen benötigt werden, sind bezüglich ihrer Darstellung an

die Knoten angeheftet. Knoten und Kanten werden durch ihren Typ unterschieden.

Jedes Modell eines Workﬂows in ADEPT besitzt ebenfalls wie die Metanotation

und BPMN einen Start- und einen End-Knoten. Im Folgenden werden die für eine

kontrollﬂussbasierte Untersuchung der Abbildung relevanten Elemente vorgestellt

(nach [23]). In jedem Abschnitt wird durch ein Schaubild die Symbolik illustriert und

die Bedeutung durch Ergänzungen erläutert.

4.3.1.1 Knoten

Ein Knoten in ADEPT wird generell als Rechteck dargestellt. Ein Knoten ohne nähe-

re Typbezeichung sei im Folgenden als Aktivität zu betrachten und entspricht somit

der Aktivität der Metanotationen sowie der Aktivität in BPMN. Die Knoten, die den

Start bzw. das Ende eines Workﬂows repräsentieren, besitzen jeweils einen eigenen

Typ. So ist der eindeutige Startknoten vom Typ (in Schaubildern annotiert mit NT,

engl. nodetype, dt. Knotentyp) „STARTFLOW“ und der eindeutige Endknoten vom

Typ „ENDFLOW“. Ebenfalls einen eigenen Typ besitzen die Knoten zum Starten (NT

= STARTLOOP) und zum Beenden (NT = ENDLOOP) eines Schleifenkonstruktes. Die

Modellierung eines Schleifenkonstrukts wird in Abschnitt 4.3.2 vorgestellt.

3http://www.aristaﬂow.de

NT = STARTFLOW

NT = ENDFLOW

NT = STARTLOOP

NT = ENDLOOP

Aktivität

Schaubild 4.12: ADEPT – Knoten

4.3.1.2 Kanten

Kanten können, wie die bereits vorgestellten Knoten, von unterschiedlichem Typ (in

Schaubildern annotiert mit ET, engl. edgetype, dt. Kantentyp) sein. Die Kante zur Kenn-

zeichnung der sequentiellen Abfolge zweier Aktivitäten ist vom Typ „CONTROL_E“.

Kanten werden generell durch einen einfachen Pfeil mit gefüllte Pfeilspitze dargestellt

(vgl. Schaubild 4.13).

Die Kante zur Verbindung des letzten Knotens einer Schleife (NT = ENDLOOP) mit

dem ersten Knoten der Schleife (NT = STARTLOOP) besitzt den Typ „LOOP_E“. Wei-

tere existente Kanten sind Kanten, die nach dem Auftreten eines Fehlers bei einer Ak-

tivität einen Rücksprung erlauben (ET = FAILURE_E) und sogenannte Synchronisati-

onskanten. Die Kanten zum Abfangen und Behandeln von Fehlern werden aufgrund

des zeitlichen Rahmens nicht behandelt.

Synchronisationskanten erweitern jedoch die Ausdrucksstärke der blockstrukturierten

Notation ADEPT. Anschaulich werden die Linien der Synchronisationskanten gestri-

chelt dargestellt. Sie unterstützen die Synchronisation der zeitlichen Ausführung von

Aktivitäten aus unterschiedlichen Zweigen einer parallelen Struktur. Es werden zwei

Arten der Synchronisation unterstützt:

•Sanfte Synchronisation: Eine Synchronisationskante vom Typ „SOFT_SYNC_E“

von einer Aktivität A zu Aktivität B bedeutet, dass B erst dann ausgeführt wird,

wenn entweder A erfolgreich ausgeführt wurde, oder A nicht mehr ausgeführt

werden kann.

•Strikte Synchronisation: Eine Synchronisationskante vom Typ „STRICT_SYNC_E“

von einer Aktivität A zu Aktivität B bedeutet, dass B erst dann ausgeführt wird,

wenn zuvor A erfolgreich ausgeführt wurde.

Um redundante Ausführungseinschränkungen zwischen Aktivitäten zu vermei-

den, unterliegt die Nutzung der Synchronisationskanten Einschränkungen. Wie bereits

erwähnt sollen nur Aktivitäten aus unterschiedlichen Zweigen einer parallelen Struk-

tur verbunden werden. Weiterhin ist eine Verbindung einer Aktivität innerhalb einer

Schleife mit einer Aktivität außerhalb dieser untersagt.

Schaubild 4.13 zeigt einen durch Synchronisationskanten erweiterten blockstrukturier-

ten Workﬂow in ADEPT, der außerdem äquivalent zum unstrukturierten Prozessmo-

dell aus Schaubild 3.14 (aus Kapitel 3) ist. Durch die Nutzung von Synchronisati-

onskanten ist es folglich möglich, für bestimmte unstrukturierte Prozessmodelle ein

blockstrukturiertes äquivalentes Modell zu ﬁnden, das lediglich durch Synchronisata-

tionskanten erweitert wurde. Synchronisationskanten erweitern also die Ausdrucks-

mächtigkeit einer blockstrukturierten Notation.

NT = STARTFLOW NT = ENDFLOW

ET = SOFT_SYNC_E

Schaubild 4.13: ADEPT – Beispiel für Synchronisationskanten

4.3.1.3 Kontrollelemente

Im Gegensatz zur BPMN besitzen Elemente zum Aufteilen oder Synchronisieren des

Kontrollﬂusses in ADEPT keine freistehende Symbole, sondern werden an die Aktivitä-

ten angeheftet. Das Split-Element an die vorhergehende Aktivität, das Join-Element an

die Nachfolgende Aktivität. Es existieren AND- und OR-Splits, sowie AND- und OR-

Joins. Im Vergleich zur blockstrukturierten Metanotation entspricht ein OR-Split einem

Split-Auswahl, ein OR-Join einem Join-Auswahl, ein AND-Split einem Split-Parallel

und ein AND-Join einem Join-Parallel. Die Semantik eines OR-Joins in ADEPT ist die

eines Diskriminators (siehe Abschnitt 3.1.1.1).

OR-Split OR-Join AND-Split AND-Join

Schaubild 4.14: ADEPT – Kontrollelemente

4.3.1.4 Daten

Die Eingabe- und Ausgabe-Daten einer Aktivität und der Fluss der Daten zwischen

Aktivitäten repräsentieren eine bedeutenden Aspekt innerhalb eines WfMS. In ADEPT

wird durch verschiedene Maßnahmen [23] die Konsistenz der Daten gewährleistet. An-

notiert werden die Daten, wie in Schaubild 4.15 gezeigt, ähnlich zur BPMN durch An-

notationskanten und einem Datensymbol.

Datenobjekt Datenfluss

Schaubild 4.15: ADEPT – Daten

4.3.2 Grundlegende Modelle in ADEPT

Analog zu Abschnitt 4.2.2 während der Vorstellung von BPMN sollen an dieser Stelle

grundlegende Konstrukte gezeigt werden, die in ADEPT modelliert wurden. Gleich-

zeitig stellen diese Konstrukte auch die Basis der blockstrukturierten Notation ADEPT

dar. Die Modelle in ADEPT bestehen prinzipiell, wie die in Kapitel 3 vorgestellten

blockstrukturierten Workﬂows, rein aus der Komposition der hier vorgestellten Grund-

konstrukte. Natürlich sind die Split- und Join-Elemente nicht auf zwei aus- bzw- ein-

gehende Kanten beschränkt.

In den Schaubildern 4.16, 4.17, 4.18 und 4.19 sind die 4 grundlegenden Konstrukte Se-

quenz, Auswahlstruktur, parallele Struktur und Schleife illustriert.

Schaubild 4.16: ADEPT – grundl. Modelle – Sequenz

Schaubild 4.17: ADEPT – grundl. Modelle – Auswahlstruktur

Schaubild 4.18: ADEPT – grundl. Modelle – parallele Struktur

NT = STARTLOOP NT = ENDLOOP

Schleifenbedingung

ET = LOOP_E

Schaubild 4.19: ADEPT – grundl. Modelle – Schleife

ADEPT erweitert die Basis der Grundkonstrukte im Gegensatz zu den blockstruk-

turierter Workﬂows aus Kapitel 3 um das Konstrukt „parallele Struktur mit ﬁnaler Aus-

wahl“. In diesem Konstrukt werden zwei oder mehr Pfade parallel ausgeführt. Der OR-

Join aktiviert nach dem erfolgreichen Beenden eines Pfades den nachfolgenden Pfad

und behandelt die restlichen Aktivitäten auf den noch nicht beendeten Pfaden gemäß

ihr Status, indem sie abgebrochen oder rückgängig gemacht werden [23].

Schaubild 4.20: ADEPT – grundl. Modelle – parallele Struktur mit ﬁnaler Auswahl

Um einen Einblick in die Modellierung durch ADEPT zu geben, wurde der Beispiel-

workﬂow in Schaubild 4.21 ausgewählt. Die Einbeziehung einer Synchronisationskante

ist ebenfalls dargestellt.

NT = STARTFLOW

NT = STARTLOOP

NT = ENDFLOW

NT = ENDLOOP

Schleifenbedingung

I J

ET = SOFT_SYNC_E

ET = LOOP_E

Schaubild 4.21: ADEPT – grundl. Modelle – Beispielworkﬂow

4.3.3 Einordnung

Die Modellierung in ADEPT erfolgt in blockstrukturierter Weise, wie es bereits in Ka-

pitel 3 vorgestellt wurde. Dies bedeutet, es existieren in ADEPT keine überlappende

Blöcke, sondern nur korrekt verschachtelte Modelle. Die Grundkonstrukte bilden die

Modelle, die in Abschnitt 4.3.2 vorgestellt werden. Die Sequenz, das parallele Kon-

strukt und das bedingte Konstrukt sind äquivalent zu den Modelle aus Kaptel 3. Das

Schleifenkonstrukt kann keine Aktivitäten auf der rückwärts gerichteten Kante besit-

zen. Dies stellt aber keine Einschränkung dar, da hierfür eine Transformation existiert.

Die parallele Struktur mit ﬁnaler Auswahl ist als Erweiterung zu sehen, und produziert,

da der Join-Auswahl als Diskriminator wirkt, keine multiplen Instanzen nachfolgender

Aktivitäten. Die Intention dieses Konstruktes ist es, Aktivitäten in den Zweigen paral-

lel auszuführen. Nachdem alle Aktivitäten eines einzelnen Zweiges vollständig ausge-

führt wurden, aktiviert die Join-Auswahl die nachfolgenden Aktivitäten und ignoriert

das erfolgreiche Beenden weiterer Zweige.

Neben dem Konstrukt parallele Struktur mit ﬁnaler Auswahl wurde die zweite Erwei-

terung des blockstrukturierten Ansatzes durch ADEPT, namentlich die Synchronisa-

tionkanten bereits in Abschnitt 4.3.1.2 vorgestellt. ADEPT besitzt also, im Vergleich zu

einer klassischen blockstrukturierten Notation zwei Erweiterungen, die aber erwiese-

nermaßen die Sicherheit vor Deadlocks und multiplen Instanzen einer Aktivität nicht

beeinträchtigen [23].

Kapitel 5

Abbildbarkeit der BPMN auf ADEPT

Der gute Redner wird Vergleiche anwenden und Beispiele vorbringen.

Marcus Tullius Cicero (106-43 v. Chr.)

röm. Redner u. Schriftsteller

Nach der Schaffung von, für die Untersuchung der Abbildbarkeit bedeutenden

Grundlagen durch die vorigen Kapitel, soll im Folgenden die Abbildbarkeit unstruktu-

rierte Prozessmodelle auf blockstrukturierte Workﬂows anhand der Notationen BPMN

und ADEPT untersucht werden. Hierzu werden die Ergebnisse bereits publizierter Ar-

beiten aufgegriffen und angepasst. Anpassungen sind unter anderem durch die vor-

gestellten Erweiterungen der blockstrukturierten Notation ADEPT durch zum Beispiel

Synchronisationskanten nötig.

Um die Abbildbarkeit zu evaluieren, wird zuvor in Abschnitt 5.1 das Prinzip des Nach-

weises der Äquivalenz zweier Modelle angeführt. Anschließend wird die Abbildbar-

keit von BPMN und ADEPT anhand einer Fallunterscheidung erörtert. Abschließend

soll die Automatisierbarkeit der Abbildungen betrachtet und eine Möglichkeit zur

kombinierten Analyse und Transformation vorgestellt werden.

5.1 Äquivalenz

Um Abbildungen auf ihre Richtigkeit zu veriﬁzieren, ist es von Nöten eine Deﬁnition

zu geben, die festlegt, wann zwei Workﬂows unter den Gesichtspunkten des Kontroll-

ﬂußes äquivalent sind. Ähnlich zu Kapitel 3 ist hier unter einem Workﬂow die zeitlich

koordinierte Abfolge von Aktivitäten zu verstehen und ermöglicht somit die Übertra-

gung der Ergbnisse auf die Äquivalenz von Prozessmodellen mit Modellen von Work-

ﬂows.

Eine Möglichkeit die Äquivalenz von zwei Workﬂows zu zeigen ist das Prinzip der

„bisimulation games“, das u.a. in [16] vorgestellt wird. Das Konzept der „bisumulati-

on games“ beruht prinzipiell auf der Nachahmung des Kontrollﬂußes eines Workﬂows

durch den anderen Workﬂow. Dazu eine Deﬁnition:

Deﬁnition 5.1 Workﬂow A und Workﬂow B sind äquivalent, wenn Workﬂow A jeden Schritt

(z.B. das Starten des Workﬂows, eine Aktivität starten/beenden, etc.) von Workﬂow B imitieren

kann und Workﬂow B jeden Schritt von Workﬂow A imitieren kann.

Um die Schritte besser vergleichbar zu machen, können Modelle zweier Notationen

beispielsweise auf einen Formalismus wie Petri-Netze abgebildet werden [16]. Auf-

grund der Vorstellung des Prinzips dieses Vorgehens sollen aber diese Details außen

vor bleiben.

Es soll weiterhin festgehalten werden, dass es neben äquivalenten Workﬂows noch so-

genannte quasi-äquivalente Workﬂows gibt.

Deﬁnition 5.2 Ein Abbildung von Workﬂow A auf Workﬂow B ist quasi-äquivalent, wenn

Workﬂow A Workﬂow B simulieren kann, aber Workﬂow B nicht Workﬂow A simulieren kann.

Um das Verständnis für einen quasi-äquivalenten Workﬂow zu fördern, soll in

Schaubild 5.1 ein in der BPMN notiertes Beispiel gezeigt werden. Hier stellt Workﬂow

A gegenüber Workﬂow B eine quasi-äquivalente Abbildung dar.

Workflow A

Workflow B

Schaubild 5.1: Äquivalenz – Quasi-Äquivalent Beispiel

Aus dem Schaubild geht hervor, dass Workﬂow A ausdrucksstärker als Workﬂow B

ist. Mögliche Ausführungspfade1der Aktivitäten für Workﬂow A sind XYZ, YXZ, XZY

und YZX. Workﬂow B besitzt nur die Ausführungspfade XYZ und YXZ. Deshalb kann

Workﬂow A die Ausführungschritte von Workﬂow B simulieren. Der inverse Fall trifft

nicht zu.

1Ausführungspfad = Reihenfolge für die Beendigung unter der Annahme einer Serialisierung

5.2 Grundlagen der Abbildbarkeit

Die Untersuchung bezüglich der Abbildbarkeit legt ihren Schwerpunkt auf den Kon-

trollﬂuss. Es wurde bereits erwähnt, dass auf die Abbildung von Details wie zum Bei-

spiel von Rollen in Form von Swimlanes und Pools, speziellen Ereignissen oder die

Behandlung von Fehlern durch Kompensationsprozesse aus zeitlichen Gründen ver-

zichtet wird.

5.2.1 Abbildungen der Elemente

Um die Abbildbarkeit zu gewährleisten, müssen als Basis die Abbildungen der einzel-

nen Elemente aus BPMN auf entsprechende Elemente in ADEPT aufgeführt werden.

Dies erfolgt in den folgenden Abschnitten.

5.2.1.1 Aktivitäten

Die Aktivitäten in BPMN haben ihr äquivalentes Pendant in den Knoten in ADEPT.

Schaubild 5.2 illustriert diesen Zusammenhang.

Aktivität

Task

Schaubild 5.2: Abbildungen der Elemente – Aktivitäten

5.2.1.2 Ereignisse

Die Abbildung des Start- und End-Ereignisses aus Modellen in der BPMN erfolgt in-

tuitiv auf den Startknoten und Endknoten in ADEPT. Zwischenereignisse sollen, wie

bereits bei ihrer Vorstellung erwähnt, auf eine Aktivität in ADEPT abgebildet werden.

So soll je nach Bedeutung des Ereignisses, das Senden und Empfangen eines Signals

durch eine für diesen Zweck erschaffene Aktivität behandet werden. Eine detailierte

Behandlung der vielfältigen Ereignisse aus der BPMN ist aus zeitlichen Gründen nicht

möglich.

Aktivität

NT = STARTFLOW

NT = ENDFLOW

Ereignisse

in BPMN

Knoten

in ADEPT

Schaubild 5.3: Abbildungen der Elemente – Ereignisse

5.2.1.3 Gateways

Die in der BPMN vorhandenen exklusiven Gateways (XOR) und die parallelen Ga-

teways besitzen je nach ihrer Funktion als Split- oder Join-Element ein Äquivalent in

ADEPT. Dies ist im folgenden Schaubild verdeutlicht dargestellt.

Split Join

Schaubild 5.4: Abbildungen der Elemente – Gateways

Das komplexe Gateway soll, wenn es als Join-Element mit der Semantik des Dis-

kriminators fungiert, auf das entprechende Element in ADEPT abgebildet werden. Zu

inklusiven Gateways ist anzuführen, dass das inklusive Gateway, wenn es als Split-

Element dient, durch ein paralleles Gateway und exklusive Gateways simuliert werden

kann. Ein Join durch ein inklusives Gateway ist ebenfalls rekonstruierbar.

Das Ereignis-basierte Gateway, das an sich nur als Split-Element eingesetzt wird, kann

durch ein Hilfskonstrukt (Schaubild 5.5) simuliert werden. Aktivität A wartet dabei, bis

ein entsprechendes Ereignis eingetreten ist und speichert dies bei Eintreten dement-

sprechend in ein Datenobjekt. Aktivität B wählt anhand des Datenobjekts den ge-

wünschten Pfad aus.

...

... AB

Schaubild 5.5: Abbildungen der Elemente – Hilfskonstrukt Ereignis-basiertes Gateway

5.2.1.4 Daten

Falls eine Aktivität A in BPMN auf ein Datenobjekt zugreift und eine Aktivität B das

Objekt liest, sollte in ADEPT der selbe Zugriff auch nach einer Abbildung gewährleistet

sein. Da ADEPT komplexe Regeln für den korrekten Zugriff auf Datenobjekte voraus-

setzt, ist die korrekte Abbildung der Datenobjekte kein Trivialität und soll in dieser

Arbeit ausgeblendet werden.

5.2.2 Abbildungen von blockstrukturierten Grundmustern

Es sollen in den folgenden Schaubildern 5.6, 5.7, 5.8, 5.9 und 5.10 die Abbildungen

von in der BPMN modellierten blockstrukturierten Konstrukten auf die äquivalente

Konstrukte in ADEPT illustriert werden. Diese Abbildungen stellen den Fall dar,

dass innerhalb eines Modells in der BPMN die blockstrukturierten Basiskonstrukte

identiﬁziert werden können. Diese Konstrukte innerhalb eines Modells in BPMN

könnten durch einzelne pseudo Aktivitäten ersetzt werden, und das Modell weiter

analysiert werden. Das Modell würde sich, falls es blockstrukturiert wäre, neben dem

Start- und dem Endknoten auf eine einzelne (pseudo) Aktivität reduzieren.

Schaubild 5.6: Abbildungen Grundmuster – Sequenz

Schaubild 5.7: Abbildungen Grundmuster – Auswahlstruktur

Schaubild 5.8: Abbildungen Grundmuster – Parallele Struktur

NT = STARTLOOP NT = ENDLOOP

Schleifenbedingung

ET = LOOP_E

Schaubild 5.9: Abbildungen Grundmuster – Schleife

Schaubild 5.10: Abbildungen Grundmuster – Parallele Struktur mit ﬁnaler Auswahl

5.3 Abbildbarkeit von Modellen mit strukturellen Mängeln

Durch die Reduzierung eines Prozessmodells in BPMN um die abbildbaren Grundmus-

ter, werden, falls das Modell nicht blockstrukturiert ist, die Konstrukte, die eine Abbil-

dung des Modells verhindern könnten, sichtbar. Die Reduktion eines Prozessmodells

kann also zu Identiﬁzierung der „Problemstellen“ einer Abbildung innerhalb eines Pro-

zessmodells dienen. Dieses Prinzip der kombinierten Analyse und Identiﬁkation von

unstrukturierten Konstrukten wird in [34] im Detail erläutert. Auf die Behandlung von

strukturellen Mängeln innerhalb eines Modells soll im folgenden Abschnitt eingegan-

gen werden.

5.3.1 Formen struktureller Mängel

Um eine Untersuchung von Konstrukten mit strukturellen Mängeln in angemessener

Form zu ermöglichen, werden an dieser Stelle zwei Annahmen getroffen.

Es soll zum Einen eine möglichst weitgehende Transformation der inklusiven, kom-

plexen und Ereignis-basierten Gateways in Konstrukte aus exklusiven und parallelen

Gateways stattﬁnden. Es wurde bewusst der Term „möglichst weitgehend“ gewählt,

denn ein Transformation der exklusiven Gateways und inklusiven Gateways, die als

Join-Elemente dienen, ist nicht unter allen Umständen möglich. Das Einbeziehen die-

ser beiden Gateways soll in späteren Ergebnissen dieser Arbeit ebenfalls noch möglich

sein. Ein kurzes Beispiel soll auf diesen Sachverhalt eingehen. Schaubild 5.11 zeigt ein

Prozessmodell, das ein inklusives Gateways als Split-Element über zwei Aktivitäten

mit einem komplexen Gateway (als Diskriminator) verbindet. Eine Transformation des

inklusiven Gateways in zwei exklusive und ein paralleles Gateway ist möglich. Um

jedoch die Semantik des Diskriminators aufrechtzuerhalten, wird das komplexe Gate-

way weiterhin benötigt (Schaubild 5.12).

Schaubild 5.11: Beispiel Diskriminator in BPMN

A D

Schaubild 5.12: Beispiel Diskriminator in BPMN – Transformation

Für die folgenden Untersuchungen soll außerdem vorausgesetzt werden, dass je-

des Split-Gateway mit mehr als zwei ausgehenden Pfaden in zwei oder mehrere Ga-

teways mit jeweils zwei ausgehenden Pfaden aufteilt werden soll. Jedes Join-Gateway,

das mehr als zwei eingehende Pfade besitzt, soll analog in zwei oder mehrere Gateways

mit jeweils zwei eingehenden Pfaden aufteilt werden.

Aufgrund dieser Voraussetzungen kann folgende Deﬁnition nach [15] eingeführt wer-

den und für die folgenden Abschnitte verwendet werden.

Deﬁnition 5.3 Ein Split-Gateway s korrespondiert zu einem JOIN-Gateway j, wenn zwei

minimale Pfade, die aus den zwei verschiedenen Ästen von s ausgehen, als erstes in j münden.

Das korrespondieren Paar wird mit (s,j) bezeichnet.

Mit dem Wort „minimal“ soll zum Ausdruck gebracht werden, dass kein anderes

Gateway auf einem Teil des Pfades die korrespondierende Eigenschaft mit s besitzt.

Zusätzlich wird in [15] erläutert, dass jedes Split-Element mindestens ein korrespon-

dierendes Join-Element besitzen muss. Dadurch können in der Folge Paare von Gate-

ways identiﬁziert werden, die zu multiplen Instanzen oder Deadlocks führen können

(Schaubild 5.13).

Deﬁnition 5.4 Ein Paar korrespondierender Gateways (s,j) ist falsch zugeordnet, wenn s ein

exklusives und j ein paralleles Gateway (Deadlock) oder s ein paralleles Gateway und s ein

exklusives Gateway (multiple Instanzen) ist.

Deadlock

multiple Instanzen

einer Aktivität

Task

Schaubild 5.13: Falsch zugeordnete Paare in BPMN

Es ergeben sich also, wie bereits in Kapitel 3 vorgestellt, die Probleme der Deadlocks

und multiplen Instanzen einer Aktivität durch missbräuchliche Gegenüberstellung von

bestimmten Gateways. Um die Ergebnisse aus Kapitel 3 vollständig aufzugreifen, er-

gibt sich in BPMN neben falsch zugeordneten Paaren auch die unzulässige Verschach-

telung als das zweite Problem bei einer Abbildung von Prozessmodellen in der BPMN

auf Workﬂows in ADEPT. Die blockstrukturierte Notation ADEPT erlaubt es, wie der

Name es schon sagt, keine „Überlappungen“ der von den Gateways gebildeten Blöcke.

Schaubild 5.14 zeigt den Fall einer solchen Überlappung in der BPMN.

Schaubild 5.14: Beispiel einer unzulässigen Verschachtelung

Es folgt für diese Art der Überlappungen eine Deﬁntion nach [15].

Deﬁnition 5.5 Ein Paar korrespondierender Gateways (s,j) ist unzulässig verschachtelt mit

einem anderen Paar korrespondierender Gateways (u,v), wenn s (oder j) in einem (bestimmten)

Pfad von u nach v ist, aber j (oder s) nicht in diesem Pfad ist.

Der Pfad von Gateway u, über das Gateway s, weiter zur Aktivität C und schließlich

nach Gateway v zeigt, dass das Modell aus Schaubild 5.14 unzulässig verschachtelte

Paare an Gateways besitzt.

5.3.2 Azyklisch unstrukturierte Modelle

Falls ein Prozessmodell eine oder mehrere unzulässige Verschachtelungen vorweist,

müssen diese analysiert werden, ob es möglich ist, die Verschachtelungen in äquiva-

lente blockstrukturierte Konstrukte zu transformieren.

Für ein unzulässig verschachteltes Konstrukt, das nur aus exklusiven Gateways besteht

und somit keine Parallelität vorweisen, ist eine vollständige Transformation in ein

blockstrukturiertes Modell möglich. Das Vorgehen wird in [15] wie folgt beschrieben

(angepasst):

Die Aktivitäten, die zwischen zwei benachbarten exklusiven Join-Gateways liegen, wer-

den dupliziert und über das vordere Gateway geschoben und anschließend werden die zwei

exklusiven Join-Gateways vertauscht.

Anmerkung: Mit dem „vorderen Gateway“ ist das Gateway gemeint, das sich

näher am Anfang des Konstruktes beﬁndet.

Angewandt auf das Prozessmodell aus Schaubild 5.14 ergibt sich ein äquivalentes

blockstrukturiertes Prozessmodell illustriert in Schaubild 5.15. Die Abbildung dieses

dann blockstrukturierten Prozessmodells nach ADEPT erfolgt durch die in Abschnitt

5.2.2 bereits vorgestellten Abbildungen der blockstrukturierten Grundmuster.

B D

Schaubild 5.15: Unzulässige Verschachtelung aus exklusiven Gateways

Es wurde bereits in Abschnitt 4.3.1.2 während der Vorstellung der Synchronisati-

onskanten gezeigt, dass das unzulässig verschachtelte Modell in Schaubild 5.16 eine

äquivalente Form in ADEPT besitzt, jedoch kein rein blockstrukturiertes Pendant.

Task

Schaubild 5.16: Unzulässige Verschachtelung aus parallelen Gateways

Es wäre mühsam und nicht sachgerecht, jede einzeln Möglichkeit der unzulässigen

Verschachtelung gesondert mit einem Beispiel anzuführen. Deshalb soll anhand der

Prozessmodelle pm1 und pm2 aus den Schaubildern 5.17 und 5.18 und der Tabelle

5.1 eine Übersicht über die Möglichkeiten der Abbildungen dieser Konstrukte gegeben

werden. Die Tabelle lehnt sich an Ergebnisse aus [15] an und wurde entsprechend für

die Abbildung der BPMN auf ADEPT modiﬁziert.

G1S G1J

G2J

G2S

Schaubild 5.17: Muster unzulässiger Verschachtelungen - pm1

G1S G1J

G2J

G2S

Schaubild 5.18: Muster unzulässiger Verschachtelungen - pm2

Die Split-Gateways G1S und G2S können entweder ein exklusives Gateway oder

ein paralles Gateway sein. Die Join-Gateways können entweder ein paralleles Gateway,

ein exklusives Gateway, ein inklusives Gateway oder auch ein komplexes Gateway (als

Diskriminator) sein.

Es wurde deshalb bei den Eigenschaften und der Aussage über die Abbildbarkeit der

Modelle der Typen 3, 7, 13, 15 und 16 eine Markierung in Form eines Sterns (*) angefügt.

Dies soll bedeuten, dass wenn das „OR“ oder die „OR“s in einer Tabellenzeile durch

inklusive oder komplexe Gateways ersetzt werden, ist das unstrukturierte Konstrukt

well-behaved und es exisitiert eine äquivalente Abbildung nach ADEPT, die meistens

zusätzlich durch Synchronisationskanten realisiert werden.

Falls aber in einem Konstrukt eines der Join-Gateways in Form eines exklusiven Gate-

ways realisiert wird, wird das Konstrukt zu multiplen Instanzen einer Aktivität führen

und es existiert nur eine quasi-äquivalente Abbildung.

Typ G1S G1J G2S G2J Eigenschaften Abb. ADEPT

1OR OR OR OR Well-behaved Ja

2OR OR OR AND Deadlock Nein

3OR OR AND OR * mult. Inst. * qu.-äquiv.

4OR OR AND AND Deadlock Nein

5AND AND OR OR Deadlock Nein

6AND AND OR AND Deadlock Nein

7AND AND AND OR * mult. Inst. * qu.-äquiv.

8AND AND AND AND Well-behaved Ja

9OR AND OR OR Deadlock Nein

10 OR AND OR AND Deadlock Nein

11 OR AND AND OR Deadlock Nein

12 OR AND AND AND Deadlock Nein

13 AND OR OR OR * mult. Inst. * qu.-äquiv.

14 AND OR OR AND * mult. Inst. * qu.-äquiv.

15 AND OR AND OR Deadlock Nein

16 AND OR AND AND * mult. Inst. * qu.-äquiv.

Tabelle 5.1: Abbildbarkeit unzulässig verschachtelter Konstrukte

Die Modelle pm1 und pm2 sind generischer Natur, da die Aktivitäten auch als re-

duzierte Teilprozesse angesehen werden können. Trotzdem ergeben sich neben der un-

zulässigen Überlappung von zwei korrespondierenden Gateways auch Situationen, in

denen mehrfache Überlappungen auftreten können. Einige können nicht durch die Ab-

bildungen aus Tabelle 5.1 aufgelöst werden.

Ein Problem ist das Auftreten des Sachverhalts innerhalb eines Modelles, der in Schau-

bild 5.19 dargestellt ist.

Task

Schaubild 5.19: Unzulässige Verschachtelung – Erweiterung

Falls sich dies als das „Ende“ einer sogenannten überlappenden Struktur (engl.

overlapped structure, Schaubild 5.20) heraustellt, existiert eine äquivalente blockstruk-

turierte Abbildung, die in Schaubild 5.21 durch BPMN illustriert wird. Diese nach

ADEPT abzubilden, sollte durch ihre blockstrukturierte Form keine Umstände berei-

ten.

Schaubild 5.20: Unzulässige Verschachtelung – Überlappende Struktur

Schaubild 5.21: Unzulässige Verschachtelung - Blockstr. Abbildung überlappende

Struktur

5.3.3 Zyklische unstrukturierte Modelle

Bisher wurden nur azyklische Modelle in der Untersuchung berücksichtigt. Jedoch

wurde in Kapitel 3 bereits angemerkt, dass neben falsch zugeordneten Paaren und der

unzulässigen Verschachtelung, auch Schleifen eine Quelle von Deadlocks und multi-

plen Instanzen sein können. Obwohl an dieser Stelle auf eine Nachmodellierung der

Schleifen-Konstrukte aus Abschnitt 3.2.1, die zu Deadlocks oder multiplen Instanzen

führen, verzichtet wird, sei festgehalten, dass diese Konstrukte, in der BPMN model-

liert, natürlich nicht nach ADEPT abbildbar sind.

Weiterhin wurde bereits in Abschnitt 5.2.2 gezeigt, dass die Abbildung eines

blockstrukturierten Schleifenkonstruktes aus der BPMN nach ADEPT möglich ist.

Neben der „falschen Konstruktion“ einer Schleife existieren aber leider zyklische Kon-

strukte, die in ihrer Form ähnlich zu den unzulässigen Verschachtelungen in azykli-

schen Modellen sind. So bedarf es für den Eintritt sowie des Austritts aus einer Schlei-

fenkonstruktion einer weitergehenden Untersuchung. Die Schaubilder 5.22 und 5.23

illustrieren die Muster des unzulässigen Eintritts in eine Schleife sowie des unzulässi-

gen Austritts aus einer Schleife.

B E

G2J

G2S

Schaubild 5.22: Unzulässiger Eintritt in eine Schleife

G2S G2J

B E

Schaubild 5.23: Unzulässiger Austritt aus einer Schleife

Es gibt ebenfalls Aufstellungen über die Abbildbarkeit dieser Konstrukte aus [15]

und sie wurden wie zuvor für die Abbildung der BPMN auf ADEPT modiﬁziert. Die

Tabellen 5.22 und 5.23 geben damit Aufschluss über die Abbildbarkeit der Konstrukte

des unzulässigen Eintritts in eine Schleife und des unzulässigen Austritts aus einer

Schleife. Analog zu Abschnitt 5.3.2 wurde eine Kennzeichnung (*) verwendet, falls das

Modell well-behaved ist, wenn das Join-Gateway G2J durch ein inklusives Gateway

oder durch ein komplexes Gateway mit der Wirkung eines Diskriminators anstatt eines

exklusiven Gateways ersetzt wird.

Die Möglichkeiten zur Ersetzung der Gateways G2S und G2J sind ebenfalls analog nach

Abschnitt 5.3.2 gegeben.

Typ G2S G2J Eigenschaften Abb. ADEPT

1N AND OR * multiple Instanzen * quasi-äquivalent

2N OR AND Deadlock Nein

3N OR OR Well-behaved Ja

4N AND AND Deadlock Nein

Tabelle 5.2: Abbildbarkeit unzulässiger Eintritt in eine Schleife

Typ G2S G2J Eigenschaften Abb. ADEPT

1A AND OR * multiple Instanzen Nein

2A OR AND Deadlock Nein

3A OR OR Well-behaved Ja

4A AND AND Well-behaved Nein

Tabelle 5.3: Abbildbarkeit unzulässiger Austritt aus einer Schleife

Es soll auf drei Ergebnisse gesondert eingegangen werden, da diese Ergebnisse für

eine Untersuchung der Abbildung von Relevanz sind. Zum Einen soll auf die Form

der blockstrukturierten Abbildung des Konstrukts 3A eingegangen werden und zum

Anderen auf den Umstand, weshalb die Konstrukte 1A und 4A keine äquivalente

blockstrukturierten Pendants besitzen.

Ein Konstrukt von Typ 3A besitzt eine äquivalente Abbildung nach ADEPT, die aller-

dings nur durch das Einbeziehen von Hilfsvariablen konstruierbar ist. Hilfsvariablen

sind in diesem Kontext Datenobjekte, die dazu dienen, den gewählten Kontrollﬂuss

festzuhalten und diese Information zu einem späteren Zeitpunkt wieder verfügbar zu

machen. Beispielsweise kann in einem Datenobjekt der gewählte Pfade an einem ex-

klusives Split-Gateway gespeichert werden, um später anhand dieser Information den

Pfad bei einer weiteren Verzweigung auswählen zu könne. Für einen Beweis, dass das

Konstrukt 3A nur durch das Einbeziehen von Hilfsvariablen in einer blockstrukturier-

ten Form konstruierbar ist, sei auf [15] verwiesen. Aufgrund der Größe des Schaubilds

sei an dieser Stelle auf eine Illustration verzichtet. Es sei jedoch festgehalten, dass unter

der Einführung von Hilfsvariablen die Nachvollziehbarkeit des Kontrollﬂusses eines

Prozessmodells bzw. eines Workﬂows erheblich leidet.

Es soll weiterhin der Beweis erbracht werden, dass ein unzulässige Austritt aus einer

Schleife vom Typ 1A nicht in eine blockstrukturierte Form gebracht werden kann (nach

[15]). Der Beweis erfolgt durch Widerspruch.

Beweis 2 Unter der Annahme, dass eine blockstrukturierte Abbildung des Konstruktes vom

Typ 1A existiert, müsste diese Abbildung aus einer parallelen Struktur und einem Schleifen-

Konstrukt bestehen. Die parallele Struktur würde Aktivität E und D enthalten. Wenn die par-

allele Struktur innerhalb der Schleife wäre, stellt dies ein Widerspruch dar, da D sich außerhalb

der Schleife beﬁndet. Wäre die parallele Struktur außerhalb der Schleife, wäre dies ebenfalls ein

Widerspruch, denn E liegt innerhalb der Schleife. Es folgt, dass die Annahme einen Widerspruch

darstellt.

Ein Nachweis, dass für ein Konstrukt vom Typ 4A ebenfalls keine Abbildung existiert,

würde analog erfolgen. Damit ist festzuhalten, dass das Konstrukt vom Typ 4A, obwohl

es well-behaved ist, keine Abbildung nach ADEPT besitzt.

5.4 Automatisierbarkeit

Durch die vorigen Abschnitte wurde bereits aufgezeigt, dass es für Konstrukte inner-

halb eines Prozessmodells äquivalente, quasi-äquivalente und auch keine Abbildungen

gibt.

Die Abbildungen von Konstrukten, die ein blockstrukturiertes Pendant besitzen, kön-

nen automatisiert, ohne das Mitwirken einer Fachkraft, erfolgen. Bei Konstrukten, für

die nur eine quasi-äquivalente Abbildung existiert, könnte sich der Umstand ergeben,

dass eine Abbildung in dieser Form vom Modellierer nicht gewünscht wird. Es sollte

bei einer Abbildung eine Abfrage, ob eine Abbildung in ein quasi-äquivalentes Mo-

dell durchgeführt werden soll, erfolgen. Eine Software könnte die Abbildung begleiten

bzw. auch durchführen, und diese Form der Rücksprache realisieren. Auch die Behand-

lung von erkannten Deadlocksituation bei unzulässig verschachtelten Gateway-Paaren

könnte in dieser Form realisiert werden, wenngleich die Erkennung eines Vorschlags

für die Abbildung des Deadlock sich weitaus schwieriger gestalten kann.

Ein Beispiel für solch einen Ansatz könnte die Behandlung des Deadlocks des unzuläs-

sig verschachtelten Konstrukts vom Typ 4 sein (siehe Tabelle 5.1). Ein Vorschlag für die

Behandlung des Konstrukts ist in Schaubild 5.24 zu sehen.

ET = SOFT_SYNC_E

Schaubild 5.24: Vorschlag einer Abbildung der unzulässigen Verschachtelung Typ 4

Natürlich existieren Konstrukte, die Deadlocks verursachen, für die sich ein, bezüg-

lich der Ausführungsemantik möglichst naheliegender Vorschlag, nicht ﬁnden lässt.

Ein Deadlock vom Typ 2 aus den unzulässigen Verschachtelungen ist hierfür eventuell

ein Beispiel.

5.4.1 Kombinierte Analyse und Transformation

Die Forscher Hauser et al. stellen in ihrer Arbeit Combining Analysis of Unstructured

Workﬂows with Transformation to Structered Workﬂows [17] einen Algorithmus vor, mit

dem es möglich sein soll, die Analyse und eine Abbildung zu automatisieren.

Ein vollständige Vorstellung der Details der Arbeit würde dem zeitlichen Rahmen der

Arbeit nicht gerecht. Es soll aber an dieser Stelle auf die Prinzipien dieser Arbeit einge-

gangen werden.

5.4.1.1 Algorithmus

Das Ziel des Algorithmus ist es, einen sogenannten Regionenbaum eines Modells auf-

zubauen. Dieser Baum wird durch den Algorithmus über Regeln aufgebaut. Prinzipiell

wird jedem Element eines Modells eine einzelne, eindeutige Region zugewiesen. In

der Arbeit wurden Regeln identiﬁziert, die es erlauben, zwei Regionen zu einer neuen

zusammenzufassen, wenn diese den Regeln entsprechen. Die Regeln sind so gewählt,

dass wenn die zwei Regionen konform zu einer Blockstruktur sind, es die neue Region

ebenfalls ist. Im Modell ersetzt die neue Region die zwei vorigen. Durch das wieder-

holte Ausführen dieses Vorgangs lässt sich ein Binärbaum von den Blättern zur Wurzel

aufbauen. Gleichzeitig reduziert der Algorithmus, falls das Modell blockstrukturiert

ist, das Modell auf eine einzelne Region. Ein Beispiel für einen Regionenbaum und das

dazugehörige Modell wird in den Schaubildern 5.25 und 5.26 dargestellt.

Task

Task Task

Task

Task Task

Task

Task Task

Task

Schaubild 5.25: Algorithmus – Beispielprozess

R1+2+3+4+5+6+7+8+9+10 (Pst)

R1+2+3+4+5+6+7+8 (Pt)R9+10 (Pt)

R1+2+3+4 (Pt)R5+6+7+8 (Cst)

R5+6+7 (Cst)R2+3+4 (Pt)

R5+6 (Ct)

R5R6

R9R10

R3+4 (Cst)

R3+4 (L)R2

R3R4

Schaubild 5.26: Algorithmus – Regionenbaum des Beispielprozesses

Für den Fall, dass zwei benachbarte Regionen nicht zusammengefügt werden kön-

nen, weil keine der Regeln für eine blockstrukturierte Abbildung zutreffen, existiert ein

weiterer Satz von Regeln, der das Identiﬁzieren von Deadlocks oder multiplen Instan-

zen einer Aktivität ermöglicht. Nach der Identiﬁkation eines bestimmten Falls, könnte

das Eingreifen einer Fachperson erfolgen.

Der Algorithmus ist in einer allgemeinen, generellen Form verfasst. Um einer Abbil-

dung der BPMN auf ADEPT gerecht zu werden, sind Anpassungen vor allem der Re-

gelsätze von Nöten. Nichtsdestotrotz stellt der Ansatz aus [17] eine hilfreiche Mög-

lichkeit dar, eine Automatisierbarkeit im Sinne eines Mittelwegs aus automatisierbaren

Abbildungen und Eingreifen einer Fachperson zu realisieren.

Kapitel 6

Schlussbetrachtung

Wer recht erkennen will, muß zuvor in richtiger Weise gezweifelt haben.

Aristoteles (384-322 v. Chr.)

griech. Philosoph

Nach der Untersuchung der Abbildbarkeit der Notation BPMN auf ADEPT soll

abschließend eine Zusammenfassung der Ergebnisse gegeben werden. Dazu bietet

es sich an, die in der Einleitung aufgeführten Fragen zu beantworten, um damit die

Resultate dieser Arbeit zu erörtern.

Ist jedes Prozessmodell modelliert in der BPMN auf ADEPT abbildbar?

Die Antwort dieser Frage ist leider „Nein“. Es wurde in Kapitel 5 gezeigt, dass es

eine Vielzahl an Mustern innerhalb eines Prozessmodells in BPMN gibt, die kein

Äquivalent in ADEPT besitzen. Die Gründe hierfür liegen in der Konzeption der

Notation BPMN und ADEPT. BPMN wurde klar mit dem Grundsatz der leichten

Verständlichkeit für die Modellierer gechaffen. Die damit implizierten Folgen in Form

des Mangels an strukturellen Vorschriften sind das Kernproblem einer Abbildung auf

ADEPT. Des Weiteren steigert die hohe Vielfalt an Elementen in BPMN die Komplexität

eines Algorithmus, der eine Abbildung inklusive einer Behandlung der strukturellen

Mängel durchführen könnte.

Existiert eine Teilmenge an Elementen in BPMN, die eine vollständige Abbildung nach

ADEPT ermöglichen?

Es wurde bereits erwähnt, dass es für jedes Modell ohne Parallelität (ohne parallele

Gateways) eine blockstrukturierte Abbildung existiert. Natürlich ist das Ausschließen

der parallelen Gateways nicht realitätsnah. Mit dem Einbinden der parallelen Gate-

ways treten aber die Probleme auf, die im vorigen Kapitel bereits erläutert wurden.

Zu diesen zählen eben Laufzeitfehler wie Deadlocks und multiple Instanzen einer

Aktivität, die in einem Workﬂow nicht auftreten dürfen.

Kann jedes Prozessmodell, das erfolgreich beendet werden kann (well-behaved), in einen

in ADEPT modellierten Workﬂow umgewandelt werden?

Nein. In Abschnitt 5.3.3 wurde gezeigt, dass ein Austritt aus einer Schleife vom Typ 4A

zwar well-behaved ist, aber keine äquivalente blockstrukturierte Form besitzt. Es gibt

somit Konstrukte, die einerseits in ADEPT nicht darstellbar sind und andererseits keine

Laufzeitfehler, wie Deadlocks oder multiple Instanzen einer Aktivität, verursachen.

Gibt es bereits existente Abbildungen der BPMN auf andere blockstrukturierte Notatio-

nen als ADEPT?

Es existieren diverse Untersuchungen [25, 35, 26, 27] der BPMN auf die blockstruktu-

rierte BPEL. In der BPEL existieren wie in ADEPT blockstrukturierte Grundkonstrukte

und die Vorschrift, Schleifen nur durch ein entsprechendes Grundkonstrukt modellie-

ren zu können. Jedoch bietet BPEL Erweiterungen wie die Elemente „ﬂow“ und „link“,

die unstrukturierte parallele Konstrukte ermöglichen, sowie den sogenannten „event

handler“ [35]. Viele dieser Arbeiten orientieren sich sehr stark an der Überwindung

der Abbildungsbarrieren anhand dieser Sonderkonstrukte. Das Ziel dieser Arbeit ist

es, die Abbildbarkeitsbarrieren zwischen BPMN und ADEPT zu erläutern.

In welcher Form wirken sich Erweiterungen der blockstrukturierten Notation ADEPT

auf die Abbildbarkeit aus?

Ein interessantes Resultat ist die Erweiterung der Abbildungsmöglichkeiten einer

unstrukturierten Notation auf eine blockstrukturierte Notation durch Synchronisation-

kanten. Diese erlauben eine Abbildung unzulässig verschachtelter Konstrukte, die nur

aus parallelen Gateways bestehen, in eine äquivalente blockstrukturierte Form.

Könnte die blockstrukturierte Notation ADEPT um weitere Elemente bzw. Konstrukte

erweitert werden, um die Abbildbarkeit zu erhöhen?

Eine Erweiterung könnte das Einfügen eines Elementes wie das inklusive Gateway

sein. Die Semantik des inklusiven Gateway als Join-Element, bei dem das Gateway auf

alle aktivierten Pfade wartet und erst nach erfolgreicher Ausführung aller aktivierten

Pfade den nachfolgenden Pfad aktiviert, fehlt in dieser Form als einzelnes Element

in ADEPT. Ein blockstrukturiertes Konstrukt zur Modellierung dieses Umstands ist

natürlich durch exklusive und parallele Gateways simulierbar, wäre aber subjektiv

über ein eigenes Element intuitiver modellierbar.

Nach der Beantwortung ausgewählter Fragen zur Abbildbarkeit der BPMN auf

ADEPT bleibt insgesamt festzustellen, dass die mangelnde vollständige Abbildbarkeit

unstrukturierter Prozessmodelle auf Workﬂows auf die Konzeption der Notationen

zurückzuführen ist. Der Wunsch der strukturell uneingeschränkten Modellierung

ist nicht mit den unabdingbaren Ansprüchen der Software, die die Prozesse bzw.

Workﬂows ausführen sollen, nach Sicherheit vor Ausführungsfehlern zu vereinbaren.

Es sollte aber möglich sein, durch angepasste Algorithmen eine weitestgehende

Abbildung der unstrukturierten Prozessmodelle durchzuführen, um die Workﬂows

nicht komplett nachmodellieren zu müssen.

Literaturverzeichnis

[1] F. Nordsieck, Die schaubildliche Erfassung und Untersuchung der Betriebsorganisation,

6. Auﬂage. C.E. Poeschel Verlag, Stuttgart, 1962.

[2] Object Management Group, “Uniﬁed modelling language,” Speciﬁcation Version

2.1.2, November 2007.

[3] O. M. Group, “Business Process Modeling Notation, v1.1,” http://www.bpmn.

org/Documents/BPMN%201-1%20Speciﬁcation.pdf, Tech. Rep., 2008.

[4] J. Recker, “BPMN modeling: Who, where, how and why,” BPTrends, vol. 5, no. 3,

2008.

[5] F. Nordsieck, Betriebsorganisation. Lehre und Technik, Textband. 2. Auﬂage. C.E. Poe-

schel Verlag, Stuttgart, 1972.

[6] C. R. von Hagen and W. Stucky, Business-Process- und Workﬂow-Management: Pro-

zessverbesserung durch Prozess-Management, Teubner, 2004.

[7] M. Hammer and J. Champy, Reengineering the corporation : A manifesto for business

revolution, 1st ed., Harper Business, 1993.

[8] M. Weske, Business Process Management: Concepts, Languages, Architectures. Sprin-

ger, 2007.

[9] T. Davenport, Process innovation: Reengineering work through information technology,

Harvard Business School Press, 1993.

[10] L. Fischer, Ed., BPM and Workﬂow Handbook 2007. Workﬂow Management Coali-

tion, 2007.

[11] D. Georgakopoulos, M. F. Hornick, and A. P. Sheth, “An Overview of Workﬂow

Management: From Process Modeling to Workﬂow Automation Infrastructure,”

Distributed and Parallel Databases, vol. 3, no. 2, pp. 119–153, 1995.

[12] N. Josuttis, SOA in der Praxis: System-Design für verteilte Geschäftsprozesse, 1. Auﬂage.

Dpunkt Verlag, Heidelberg, 2008.

[13] Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, Bartek Kiepuszewski and Ali-

stair P. Barros, “Workﬂow Patterns,” Distributed and Parallel Databases, vol. 14, no. 1.

[14] W. M. P. van der Aalst, A. H. M. ter Hofstede, and M. Weske, “Business Process

Management: A Survey,” in Business Process Management, 2003, pp. 1–12.

[15] R. Liu and A. Kumar, “An Analysis and Taxonomy of Unstructured Workﬂows,”

in Business Process Management, W. M. P. van der Aalst, B. Benatallah, F. Casati, and

F. Curbera, Eds., vol. 3649, 2005, pp. 268–284.

[16] B. Kiepuszewski, A. H. M. ter Hofstede, and C. Bussler, “On Structured Workﬂow

Modelling,” in CAiSE, ser. Lecture Notes in Computer Science, B. Wangler and

L. Bergman, Eds., vol. 1789. Springer, 2000, pp. 431–445.

[17] R. Hauser, M. Friess, J. M. Kuster, and J. Vanhatalo, “Combining Analysis of Un-

structured Workﬂows with Transformation to Structured Workﬂows,” in EDOC

’06: Proceedings of the 10th IEEE International Enterprise Distributed Object Computing

Conference. Washington, DC, USA: IEEE Computer Society, 2006, pp. 129–140.

[18] B. Kiepuszewski, “Expressiveness and Suitability of Languages for Control Flow

Modelling in Workﬂows,” Ph.D. dissertation, Queensland University of Technolo-

gy, Brisbane, Australia, 2002.

[19] N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst and N. Mulyar, “Workﬂow

Control-Flow Patterns - A Revised View,” http://www.workﬂowpatterns.com/

documentation/documents/BPM-06-22.pdf, 2006.

[20] Wil M.P. van der Aalst and Arthur H.M. ter Hofstede, “Veriﬁcation of workﬂow

task structures: A petri-net-based approach,” Inf. Syst., vol. 25, no. 1, pp. 43–69,

2000.

[21] Manfred Reichert and Peter Dadam, “A Framework for Dynamic Changes in

Workﬂow Management Systems,” in DEXA Workshop, 1997, pp. 42–48.

[22] Manfred Reichert, Stefanie Rinderle and Peter Dadam, “ADEPT Workﬂow Ma-

nagement System: Flexible Support for Enterprise-Wide Business Processes – Tool

Presentation –,” in W.M.P van der Aalst et al.: BPM 2003, LNCS 2678, Springer-Verlag

Berlin Heidelberg 2003, 2003, pp. pp. 370–379.

[23] Manfred Reichert and Peter Dadam, “ADEPT ﬂex – Supporting Dynamic Changes

of Workﬂows Without Losing Control,” Journal of Intelligent Information Systems,

vol. 10, no. 2, pp. 93–129, 1998.

[24] S. White, “Introduction to BPMN,” http://www.bpmn.org/Documents/

Introduction%20to%20BPMN.pdf, Object Management Group, Tech. Rep.,

2004.

[25] Chun Ouyang, Marlon Dumas, Arthur H.M. ter Hofstede and Wil M.P. van der

Aalst, “Pattern-based translation of BPMN process models to BPEL web services,”

International Journal of Web Services Research (JWSR), vol. 5, no. 1, pp. 42–62, 2007.

[Online]. Available: http://eprints.qut.edu.au/archive/00006810/

[26] Chun Ouyang, Wil M.P. van der Aalst, Marlon Dumas and Arthur H.M. ter Hofste-

de, “Translating BPMN to BPEL,” http://eprints.qut.edu.au/archive/00003615/,

2006.

[27] J. Recker and J. Mendling, “On the Translation between BPMN and BPEL: Concep-

tual Mismatch between Process Modeling Languages,” in CAiSE 2006 Workshop

Proceedings - Eleventh International Workshop on Exploring Modeling Methods in Sys-

tems Analysis and Design (EMMSAD 2006), T. Latour and M. Petit, Eds., June 2006,

pp. 521–532.

[28] A. Alves, A. Arkin, S. Askary, B. Bloch, F. Curbera, Y. Goland, N. Kartha, Sterling,

D. König, V. Mehta, S. Thatte, D. van der Rijn, P. Yendluri, and A. Yiu, “Web ser-

vices business process execution language version 2.0,” OASIS Committee Draft,

May 2006.

[29] J. Recker, M. Indulska , M. Rosemann and P. Green, “How good is BPMN really?

Insights from theory and practice,” in Proceedings of the 14th European Conference

on Information Systems. Goeteborg, Sweden, 2006, pp. 1582–1593. [Online]. Available:

http://eprints.qut.edu.au/archive/00004636/01/4636.pdf

[30] Petia Wohed, Wil M. P. van der Aalst, Marlon Dumas, Arthur H. M. ter Hofstede

and Nick Russell, “Pattern-based analysis of BPMN - an extensive evaluation of

the control-ﬂow, the data and the resource perspective (revised version),” http://

www.workﬂowpatterns.com/documentation/documents/BPM-06-17.pdf, 2006.

[31] Kevin Göser, Martin Jurisch, Hilmar Acker, Ulrich Kreher, Markus Lauer, Stefa-

nie Rinderle, Manfred Reichert and Peter Dadam, “Next-generation Process Ma-

nagement with ADEPT2,” in BPM (Demos), ser. CEUR Workshop Proceedings,

M. Adams and S. W. Sadiq, Eds., vol. 272. CEUR-WS.org, 2007.

[32] T. Bauer, “Efﬁziente Realisierung unternehmensweiter Workﬂow-Management-

Systeme,” Ph.D. dissertation, Universität Ulm, 2001.

[33] Stefanie Rinderle, Manfred Reichert and Peter Dadam, “Flexible Support of Team

Processes by Adaptive Workﬂow Systems,” Distributed and Parallel Databases,

vol. 16, no. 1, pp. 91–116, 2004.

[34] Wasim Sadiq and Maria E. Orlowska, “Applying Graph Reduction Techniques

for Identifying Structural Conﬂicts in Process Models,” Lecture Notes in Computer

Science, vol. 1626, p. 195ff, 1999.

[35] Chun Ouyang, Marlon Dumas, Wil M.P. van der Aalst and Arthur H.M. ter Hofs-

tede, “From Business Process Models to process-oriented Software Systems: The

BPMN to BPEL Way,” http://eprints.qut.edu.au/archive/00005266/, 2006.