Muster basierte Generierung von realistischen Workflow-Modellen

Transkript

1 Institut für Parallele und Verteilte Systeme Abteilung Verteilte Systeme Universität Stuttgart Universitätsstraße 38 D Stuttgart Studienarbeit Nr Muster basierte Generierung von realistischen Workflow-Modellen Felix Zwirn Studiengang: Informatik Prüfer: Betreuer: Prof. Dr. Rothermel Dipl.-Inf. Hannes Wolf begonnen am: 1. Dezember 2009 beendet am: 2. Juni 2010 CR-Klassifikation: H.4.1, D.2.13

2

3 Inhaltsverzeichnis 1 Einleitung 7 2 Workflow Modell nach Wolf 9 3 Workflow Patterns als Grundlage modellgetriebener Generierung von Workflow Modellen Workflow Patterns nach Van der Aalst Workflow Patterns nach Thom Workflow Generierung mit Hilfe von Workflow Patterns Pattern Darstellung im Generator Approval Pattern Bi-directional Performative Decision Information request Notification Question-answer Pattern Unidirectional Performative Generierung Decision Splits Ausführungsmodel Generierung Decision Split Verteilung Event Typen Request Events Review Events Yes - No Activity Execution Events Information Events Validierung der Ergebnisse Generator für Workflows Korrelationswahrscheinlichkeiten der Pattern Ausführungsmodell und Decision Split Verteilung

4 7 Zusammenfassung 51 Literaturverzeichnis 53 4

5 Abbildungsverzeichnis 2.1 Beispiel für zwei Swimlanes Verwendete Darstellung bei den Pattern Diagrammen Approval Pattern Bi-directional Performative Pattern Decision Pattern Information Request Pattern Notification Pattern Question-Answer Pattern Unidirectional Performative Pattern Beispiel für Workflow Generierung, Bild Beispiel für Workflow Generierung, Bild Beispiel für Workflow Generierung, Bild Beispiel für Workflow Generierung, Bild Vergleich für Rekursionstiefe Beispiel für den Baum einer Bedingung Beispiel für Event Listen Sequenz Beispiel für verschiedene Bedingungen einer Transition Decision Deadlock Beispiel für die Verzweigungs Verteilung Anzahl der Aktivitäten in den erzeugten Workflows Grad der Verzweigung des Decision Patterns Links: Verteilung der Patterns; Rechts: Patterndichte von Chiao Auftreten der Pattern in einem Workflow Erstes gewähltes Pattern Korrelationswahrscheinlichkeit für das Approval Pattern Korrelationswahrscheinlichkeit für das Bi-directional Performative Pattern Korrelationswahrscheinlichkeit für das Decision Pattern Korrelationswahrscheinlichkeit für das Information Request Pattern Korrelationswahrscheinlichkeit für das Notification Pattern Korrelationswahrscheinlichkeit für das Question-Answer Pattern Korrelationswahrscheinlichkeit für das Unidirectional Performative Pattern

6 Ergebnis der Transitionen Auswahl (in Prozent) und die zugrundeliegende Verteilung (in Klammern)

7 1 Einleitung Ein Workflow ist ein Modell, das reale Arbeit repräsentiert. Ziel eines Workflows ist es eine klare Vorgabe und damit eine mögliche Automatisierung der Ausführung, zu schaffen. In heutigen Firmen sind Workflows nicht mehr weg zu denken. Für die Forschung stehen jedoch nur wenige Workflows zu Verfügung. Viele Firmen hüten ihre Workflows als bestes Firmengeheimnis. Ohne zur Verfügung stehender Datenbasis ist aber die Forschung an Algorithmen, die auf Workflows arbeiten nicht möglich. Damit ausreichend Workflows für eine Basis erzeugt werden können, wurde diese Arbeit geschaffen. Ziel dieser Arbeit war es, einen Generator für realistische Workflows zu entwickeln. Insbesondere Workflow mit starker menschlicher Interaktion sollten von dem Generator erzeugt werden. Als Workflow Modell für den Generator verwende ich das Flow Application Model von [Wol09]. Das Modell von Wolf beschreibt nicht nur die Workflow Modelle, sondern unterstützt auch Einflüsse aus der realen Welt. Diese Einflüsse werden Events genannt. Mit einem Workflow und einer dazu passenden Sequenz von Events kann anschließend eine Workflow Engine einen Durchlauf durch den Workflow erzeugen. Wie das Modell ausschaut, behandele ich in Kapitel 2 Zusätzlich verwende ich Workflow Activity Patterns von Thom et al. um damit Workflows zu generieren. Diese Patterns beschreiben Abläufe in Workflows. Also mehrere Arbeitsschritte, die zusammen eine Aufgabe erledigen. Wenn zum Beispiel jemand über etwas informiert wird, so ähnelt sich das Vorgehen, egal ob der Person ein Brief, eine oder eine Telefonische Nachricht geschickt wird. Das Senden der Information ist eine Aufgabe, die durch ein bestimmte Muster beschrieben werden kann. Die Workflow Patterns von Thom et al. wurden durch die Analyse realer Workflows gewonnen. Dass sich Workflows ausschließlich mit Hilfe dieser Patterns erzeugen lassen [LHT09a], erleichterte mir die Arbeit. Da ich so auf weitere Strukturen verzichten konnte. Wie die Patterns ausgewählt wurden und welche Alternativen ich zu den Workflow Activity Patterns von Thom hatte, erkläre ich in Kapitel 3. In den Arbeiten zu den Workflow Activity Patterns lassen sich Analysen zu den Korrelationswahrscheinlichkeiten zwischen den Patterns finden. Die Korrelationswahrscheinlichkeiten geben die Wahrscheinlichkeit für ein Pattern nach einem anderen Pattern an. Der Generator nutzt die Korrelationswahrscheinlichkeiten um das jeweils nächste Pattern auszuwählen. Er erzeugt ein Pattern nach dem anderen bis die vorgegebene Workflow Größe erreicht wurde. 7

8 1 Einleitung Der Benutzer kann dabei über die Generatorparameter die Größe und den Verzweigungsgrad des Workflows bestimmen. Die Entwicklung wurde von mir in zwei Arbeitsschritte unterteilt. Im ersten Schritt modellierte ich die Patterns von Thom für den Generator (Kapitel 4). Danach implementierte ich den Generator, jedoch ohne Events. Die Events und die Erzeugung von Sequenzen von Events behandelte ich in einem zweiten Entwicklungsschritt (Kapitel 5). Die Resultate, die der Generator erzeugte, präsentiere ich im Kapitel 6. Abschließend werde ich einen Ausblick auf zukünftige Erweiterungen des Generators aufzeigen (Kapitel 7). 8

9 2 Workflow Modell nach Wolf Ein Workflow beschreibt reale Arbeit. Dabei werden die einzelnen Arbeitsschritte in Aktivitäten festgelegt. Im Workflow ist definiert, welche Arbeit von wem, wo, wann und wie erledigt wird. Er macht damit eine klare Vorgabe und ermöglicht somit eine Automatisierung der Ausführung. Durch die klare Vorgabe erhält der Betrieb auch eine Dokumentation seiner Arbeitsabläufe, dies ist allerdings nur ein Nebenprodukt des Workflows. Ein Workflow Management System definiert und verwaltet eine Serie von Aufgaben. Es erlaubt es in der Regel verschiedene Workflows für verschiedene Aufgaben zu definieren. Im Modell von Wolf übernimmt die Workflow Engine diese Aufgabe. Sie wird, mit einem Workflow und einer Sequenz von Events als Eingabe, gestartet und erzeugt einen Durchlauf durch den Workflow. Die, in diesem Modell betrachteten, Anwendungen bestehen aus je einem Workflow Modell und einer Menge von Events auf die das Modell reagiert. Ich werde zuerst die Events erklären, bevor ich zum Workflow Modell komme. Events zeigen dem Workflow, dass in der realen Welt ein Ereignis stattgefunden hat, welches einen Einfluss auf ihn ausübt. Diese Ereignisse der realen Welt sind meist menschliche Handlungen. Sie können komplexe Situationen sein, zum Beispiel, dass eine Krankenschwester eine Blutprobe in ein Kühlfach legt, damit später Analysen von diesem Blut durchgeführt werden können. Aber die Ereignisse können auch einfacher sein, so wie die Messung der Temperatur eines Patienten. Die Events werden verschiedenen Event Typen zugeordnet. Durch die Event Typen werden die Events gruppiert. Das bietet mir große Flexibilität beim Festlegen von Events durch den Generator. Wenn ich festlege, dass an einer bestimmten Stelle, in einem Workflow, verschiedene Events vom selben Typ auftreten können, aber immer nur eins, so muss ich nur den Typ festlegen, die Events jedoch können später erzeugt werden. Ein Beispiel wäre der Event Type Anfrage verschicken, er könnte die Events Telefonische Anfrage, Schriftliche Anfrage enthalten. Ich kann also festlegen, dass an einer bestimmten Stelle der Event Typ Anfrage verschicken auftreten muss und der Generator erzeugt nun die Workflows entweder mit dem Event Telefonische Anfrage oder aber mit dem Event Schriftliche Anfrage. Die Auswahl trifft der Generator ohne mein Zutun und schafft somit gleichzeitig eine größere Varianz in den erzeugten Modellen. Das Workflow Modell von Wolf besteht aus einer Menge von Aktivitäten und Transitionen. Ein Workflow wird als Graph, mit den Aktivitäten als Knoten und den Transitionen als Kan- 9

10 2 Workflow Modell nach Wolf ten, dargestellt. Die Logik des Workflows wird durch die Transitionen realisiert. Aktivitäten sind kein Teil der Prozesslogik. Eine Aktivität ist ein atomarer Arbeitsschritt des Workflows. Diese Arbeitsschritte können sowohl externe Tätigkeiten, wie eine menschliche Interaktion, als auch interne Tätigkeiten, zum Beispiel wenn das System einen Eintrag in eine Datenbank macht, sein. Um auf Einflüsse aus der realen Welt eingehen zu können, müssen Aktivitäten mit Event Typen versehen werden. Die konkrete Ausprägung des Event Typs ist für die Aktivität jedoch ohne Belang, sie wird erst bei den Transitionen benötigt. Aktivitäten repräsentieren die Knoten im Graphen des Workflows. Sie können ein mandatory Marker enthalten, dieser besagt, dass die Aktivität durchgeführt werden muss, bevor der Workflow abgeschlossen werden kann. Dadurch ist es möglich optionale Zweige zu definieren. Wenn ein Pfad im Workflow keine Aktivität hat, die mandatory ist, so muss dieser Pfad nicht durchlaufen worden sein, damit der Workflow abgeschlossen werden kann. Eine Transition verbindet zwei Aktivitäten und entspricht somit den Kanten im Graphen. Damit nun die Logik des Workflows festgelegt werden kann, erhalten Transitionen Bedingungen. Eine Bedingung legt fest, welche Events an der Quellaktivität eingetreten sein müssen, damit die Transition schaltet. Wenn keine Events eintreten müssen, ist die Bedingung leer. Transitionen ohne Bedingungen schalten automatisch weiter, wenn die Aktivität aus der sie stammt abgeschlossen wurde. Eine Aktivität gilt als abgeschlossen, wenn alle aus ihr hervorgehenden Transitionen evaluiert wurden. Die Bedingungen sind logische Prädikate über Events. Dazu gehören Und, Oder, Nicht und Events. Damit Events den Transitionen zugewiesen werden können, müssen, die von einer Bedingung verwendeten Event Typen, in der Quellaktivität notiert werden. Wenn eine Transition also ein Event Telefonische Anfrage erwartet, so muss Anfrage verschicken als Event Type mit der Aktivität, aus der die Transition stammt, registriert werden. Durch die Art und Weise wie Transitionen funktionieren, kann es zu Blockaden kommen. Eine Verzweigung mit zwei exklusiven Bedingungen, deren Zweige später wieder zusammengeführt werden, kann nie korrekt durchlaufen werden. Deswegen wird der Transitions Marker eingeführt. Dieser Marker legt fest, dass eine Transition nicht schalten muss, damit die nachfolgende Aktivität aktiviert wird. Weiterhin ist die Semantik so definiert, dass wenn eine Aktivität als eingehende Kanten nur Transitionen mit Marker hat, mindestens eine dieser Transitionen schalten muss, damit die Aktivität aktiv werden darf. Die bisher genannten Strukturen sind die aus [Wol09], die von mir in dieser Arbeit verwendet werden. Um den Aufgabenbereich in einem Workflow hervorzuheben, gibt es Swimlanes. Abbildung 2.1 verdeutlicht dies. Tätigkeit A ruf Tätigkeit B auf. Tätigkeit B wird von einem anderen Bearbeiter durchgeführt als Tätigkeit A. Nachdem Tätigkeit B abgeschlossen wurde, kommt Tätigkeit A an die Reihe, Tätigkeit A wird vom selben Bearbeiter vollzogen wie Tätigkeit A. Deswegen sind Tätigkeiten A und A in Swimlane A während Tätigkeit B in Swimlane B ist. 10

11 Abbildung 2.1: Beispiel für zwei Swimlanes Das Modell von Wolf unterstützt keine Swimlanes, um sie trotzdem hervorzuheben habe ich mich dafür entschieden Transitionen mit Marker zu setzen. Im Beispiel von Abbildung 2.1 würde Tätigkeit A eine Transition mit Marker zu Tätigkeit A haben. Das Modell von Wolf vereint Workflows mit Listen von Events. Die Logik wird dabei durch die Transitionen realisiert, während die Aktivitäten Tätigkeiten in der realen Welt repräsentieren. 11

12

13 3 Workflow Patterns als Grundlage modellgetriebener Generierung von Workflow Modellen Wie Eingangs bereits erwähnt, habe ich Workflow Patterns als Grundlage für den Generator verwendet. Die Anforderung an den Generator war es, realistische Workflows zu erzeugen. Um möglichst realitätsnah zu sein, war ich bemüht einen Bezug zur Realität zu finden. Wenn Patterns durch die Analyse existenter Workflows gefunden wurden, sollten diese Patterns ausreichen, um damit realistische Workflows zu generieren. Da ich aber nur aus Patterns die Workflows erzeugen wollte, hatte ich die Bedingung, dass die Patterns ausreichen, um nur durch diese Patterns, vollständige Workflows zu beschreiben. Es durfte also keiner weiteren Komponenten benötigen, um die Workflows zu generieren. Zusätzliche Komponenten würden weitere statistische Daten bringen, die beachtet werden müssen. Es müsste also ein Zusammenhang zwischen den Patterns und anderen Komponenten analysiert werden. Ohne den Zusammenhang wäre die Erzeugung von Workflows reine Willkür. Deswegen wollte ich mich nur auf die Patterns beschränken. Zuerst musste ich Patterns finden, die meine Anforderungen erfüllten. Ich benötigte Patterns zu denen sich zusätzlich statistische Informationen zu ihrem Auftreten finden ließen. Wenn ich wusste, wie oft ein Pattern durchschnittlich auftritt, so konnte ich damit den Generator testen. Wenn er Workflows erzeugte, in denen dieses Pattern genauso oft auftrat, so erfüllte das eine meiner Anforderungen an ihn. Außerdem suchte ich nach Korrelationswahrscheinlichkeiten zwischen den Patterns. Diese Werte sollte der Generator verwenden, um die Reihenfolge der Patterns zu bestimmen. Was macht einen Workflow realistischer, als wenn er Werte, die in der realen Welt gefunden werden, wiedergibt. Da ich versuchte Workflows mit großer menschlicher Interaktion zu generieren, sollten mir die Patterns dies nach Möglichkeit erleichtern. Von den verschiedenen Arbeiten zum Thema Workflow Patterns sind mir zwei Arbeitsgruppen aufgefallen. 3.1 Workflow Patterns nach Van der Aalst Die erste Gruppe von Patterns, die ich fand, war von Van der Aalst et al. 13

14 3 Workflow Patterns als Grundlage modellgetriebener Generierung von Workflow Modellen Er beschreibt in seinen Arbeiten Control-Flow und Data-Flow Patterns. Die Control-Flow Patterns beschreiben dabei eine Sicht auf die Tätigkeiten, zum Beispiel welche Daten von der Tätigkeit verwendet werden, wer sie durchführt und wo. Die Data-Flow Patterns beschreiben die Sicht auf den Fluss der Daten im Workflow. Eine Sicht auf die Daten wird jedoch vom Modell von Wolf nicht unterstützt. Die Control-Flow Patterns betrachten Strukturen in Workflows, die bestimmte Situationen beschreiben. Dazu gehören zum Beispiel das Sequenz Pattern, welches eine sequentielle Abfolge von Aktivitäten repräsentiert. Sie dienen dazu, gängige Situationen wie auch XOR- Verzweigungen darzustellen. Insgesamt identifiziert van der Aalst 43 verschiedene Control- Flow Patterns [NR06]. Die von ihm beschriebenen Patterns sollen als fundamentale Grundlage für moderne Workflow Beschreibungssprachen dienen und somit ausreichen um jeden Workflow zu beschreiben. Van der Aalst et al. haben diese Pattern genau für diesen Zweck konstruiert. Sie entstanden zwar anhand von realen Situationen in Workflow Systemen, die heutzutage je nach System unterschiedlich implementiert werden. Die Patterns wurden so implementiert, dass sie ausreichen um jeden Workflow zu beschreiben. Dies erfüllte eine meiner Anforderungen an Patterns. Jedoch verfügten die Arbeiten von Van der Aalst und weiterführende Arbeiten, über kein Indiz, das Informationen zum Auftreten der Pattern oder den Korrelationswahrscheinlichkeiten erhoben wurden. Ohne statistische Informationen zum Auftreten der Patterns, waren die Patterns für mich leider von wenig Nutzen bei der Generierung von realistischen Workflow Modellen. Ich musste sie also fallen lassen. Nachdem Betrachten der Workflow Patterns von van der Aalst, beschäftigte ich mich mit den von Thom et al. identifizierten, Workflow Activity Patterns. 3.2 Workflow Patterns nach Thom Die Workflow Activity Patterns von Thom et al. beschreiben die Prozesse, die in Workflows auftreten können. Sie zeichnen sich dadurch aus, dass sie nicht einfach nur eine Situation in einem Workflow beschreiben, sondern eine komplette Abfolge von Aktivitäten. Für die meisten Workflows müssen solche Prozesse immer wieder neu geschrieben werden. Thom analysierte inwieweit sich diese Prozesse durch Patterns erfassen lassen um damit den Entwicklungsaufwand von Workflows zu reduzieren [LHT09b]. Durch empirische Studien kam Thom zu zwei Resultaten: Nachweise dafür, dass Workflow Activity Patterns in allen Workflow Anwendungen aus der realen Welt und (process-aware) Informationssystemen auftreten. 14

15 3.2 Workflow Patterns nach Thom Nachweise dafür, dass mit diesen Patterns, bis zu einem bestimmten Feinheitsgrad, alle analysierten Workflows zu modelliert werden können und es keiner weiteren Strukturen bedarf. Damit waren zwei meiner Anforderungen schon erfüllt. Erstens reichten die Patterns aus, um Workflows komplett anzufertigen. Zweitens stammten sie alle aus realen Workflows. Sie waren nicht, wie die von van der Aalst gefundenen, konstruiert. Die Arbeiten von Thom und von Chiao befassten sich außerdem mit den Wahrscheinlichkeiten für das Auftreten der Patterns. Vor allem aber Chiao et al. beschäftigte sich auch mit den Korrelationswahrscheinlichkeiten von Patterns [CC08]. Thom untersuchte in diesem Zusammenhang den Unterschied zwischen Workflows mit starker menschlicher Interaktion (Human-Intensive) und denen mit hoher Systeminteraktion (System-Intensive). Die für mich interessanten Workflows waren hierbei diejenigen, die starke menschliche Interaktion aufwiesen. Es war nicht möglich zu allen Patterns die Korrelationswahrscheinlichkeiten zu finden. Deswegen wählte ich zum Teil selbst Werte, die für mich realistisch erschienen. Das ist bedauerlich, da hierdurch der Parameter des Generators, der für den Realismus der Workflows sorgt, keinen Bezug zu den Analysen hat. Damit es möglich ist, wenn die Werte zur Verfügung stehen, diesen Mangel beim Generator zu beheben, können die Korrelationswahrscheinlichkeiten nachträglich angepasst werden. Nachdem ich nun also Patterns gefunden hatte, die für mich in Frage kamen, musste ich die Pattern an mein gegebenes Workflow Modell anpassen. Thom beschreibt sieben verschiedene Workflow Activity Patterns [LHT09a]. Die Patterns lagen in UML vor [LHT09a] und manche auch in BPMN [CC08], [LHT09b]. Ich versuchte nun eine Darstellung zu wählen, die der von BPMN möglichst nahe kam und trotzdem das gegebene Modell erfüllte. Letztlich wählte ich als Ausgangslage die Darstellung von BPMN, da diese, der im Code realisierten, Repräsentation vom Modell von Wolf am Nächsten kam. Zu jedem Pattern gibt es verschiedene Design Choises. Design Choises ist verschiedene Varianten des Patterns. Jede passt zu eine bestimmten Situation. Es wird zum Beispiel unterschieden, ob eine Anfrage an eine oder mehrere Zielpersonen geht. Im folgenden Kapitel werde ich die sieben Pattern und die Design Choices, die in [LHT09a] genannt werden, vorstellen. 15

16

17 4 Workflow Generierung mit Hilfe von Workflow Patterns In diesem Kapitel werde ich über die Entwicklung des Generators für Workflows sprechen. Er sollte mit Hilfe von Workflow Patterns realistische Workflows erzeugen. Er sollte hierfür über mehrere Iterationen hinweg, Patterns zu einem Workflow hinzufügen. Dazu modellierte ich in einem ersten Entwicklungsschritt die Patterns von Thom, so dass sie in das Modell von Wolf passten. Um möglichst realistische Workflows zu erzeugen, sollte sich der Generator der Korrelationswahrscheinlichkeiten der Patterns bedienen. Mit den Wahrscheinlichkeiten wählte er das Nachfolgepattern zu einem Pattern aus. So wollte ich Workflows erzeugen, die möglichst ähnlich zu denen in der realen Welt waren. Damit der Generator die sieben Workflow Aktivity Patterns von Thom et al. verwenden konnte, musste ich sie an das Modell von Wolf anpassen. Kontrollflussstrukturen wie Verzweigungen (Splits oder Forks) und Zusammenführungen (Joins) musste ich hierbei als Aktivitäten modellieren. Die Semantik musste dabei in die Transitionen überführt werden. Dies sehe ich als eine der größten Schwächen von Wolfs Modell. Es unterstützt keine Form der Control-Flow Patterns, wie sie van der Aalst vorstellt. Daraus resultiert, dass jede dieser Strukturen von Hand modelliert werden musste. Die erste Fassung des Generators erzeugte noch Workflow Modelle ohne die ihnen zugrunde liegende Logik. Dadurch war es mir möglich, mich erst auf das Erzeugen von Modellen mithilfe der Korrelationswahrscheinlichkeiten zu konzentrieren. Erst im zweiten Schritt fügte ich die Semantik zu den Patterns. Da die Logik durch Bedingungen an den Transitionen geregelt wurde, musste ich darauffolgend auch Event Typen für die Aktivitäten bestimmen. Die verwendeten Event Typen, sowie das Erzeugen von Event Listen behandele ich in Kapitel 5. Zunächst betrachte ich die Darstellung der Patterns im Generator. 4.1 Pattern Darstellung im Generator Um die Patterns im Generator zu verwenden, musste ich zuerst alle Kontrollstrukturen durch Aktivitäten ersetzen. Danach legte ich fest, ob und wenn ja, welche Aktivitäten mandatory sein sollten. Wie Eingangs erwähnt, müssen mandatory Aktivitäten abgeschlossen werden, 17

18 4 Workflow Generierung mit Hilfe von Workflow Patterns damit der Workflow korrekt beendet wird. Ich entschied mich bei den Patterns grundsätzlich die letzte Aktivität auf mandatory zu setzen. Dadurch wollte ich erreichen, dass jedes der verwendeten Patterns auch durchlaufen wird, was mir Anfangs sinnvoll erschien. Wie später noch gezeigt wird, führte diese Entscheidung zu Problemen mit Pfaden, die nicht durchlaufen wurden. Ich werde nun die Patterns, wie sie in [LHT09a] vorliegen inklusive ihrer Design Choises, vorstellen. Ich habe mich bei allen Design Choices für die Single-Variante entschieden, da ich keine statistischen Informationen über das Auftreten der verschiedenen Möglichkeiten hatte. Außerdem war mir bewusst, dass die generierten Workflows nur eine grobe Modellierung repräsentierten. Es war also von wenig Belang, ob die unterschiedlichen Design Choises unterstützt wurden oder nicht. Zusätzlich präsentiere ich zu jedem Pattern ein Beispiel und eine Grafik, wie es, im Generator nach dem Modell von Wolf, dargestellt wurde. Abbildung 4.1: Verwendete Darstellung bei den Pattern Diagrammen Abbildung 4.1 zeigt, die bei den Diagrammen verwendeten Strukturen. Wie zu Sehen, benötige ich Aktivitäten, mandatory und nicht mandatory, und Transitionen, mit Marker und ohne. Um die Swimlanes hervorzuheben, mussten Transitionen eingefügt werden, die für die Logik nicht nötig waren. Um zu verdeutlichen, dass diese Transitionen nicht nötig wären, versah ich sie mit einem Marker. Dies erleichterte mir zusätzlich die Erzeugung von Event Listen, wie man in Kapitel 5 sehen wird Approval Pattern Das Pattern beschreibt verschiedene Formen der Einwilligung im Zusammenhang von Prozessen. 18

19 4.1 Pattern Darstellung im Generator Beschreibung Das Approval Pattern beschreibt eine Aktivitätenabfolge in der ein Antragsteller einen Antrag auf Genehmigung stellt. Dieser Antrag wird bearbeitet und eine Genehmigung oder Ablehnung anschließend an ihn zurückgeschickt. Hierbei kann je nach Design Choice der Vorgang der Genehmigung weiter unterteilt werden. Beispiel Ein Arzt will einen seiner Patienten operieren. Er benötigt hierfür die Einwilligung des Patienten. Er wird also dem Patienten eine Einverständnisserklärung überreichen. Der Patient wird sie entweder unterschreiben oder nicht. Wenn er sie unterschreibt, so wird sie archiviert und der Chirurg benachrichtigt. Wenn nicht, so wird der Chirurg darüber informiert, dass er die Operation nicht durchführen kann. Design Choices Single Approval Ein Antragsteller stellt einen Antrag an exakt eine Person. Der Antrag wird bearbeitet und entweder genehmigt oder abgelehnt. Iterative Approval Basierend auf einer Liste von Bearbeitern bekommt der erste Bearbeiter den Antrag, wird er genehmigt, so bekommt ihn der Zweite, usw. Ein Antrag gilt als genehmigt, wenn alle Bearbeiter ihn genehmigt haben. Ansonsten wird der Antrag abgelehnt. Concurrent Approval Gleichzeitig wird der Antrag von einer Reihe Bearbeitern ausgeführt und erst wenn alle ihre Genehmigung durchgeführt haben, wird eine abschließende Entscheidung getroffen. Das von mir verwendete Approval Pattern entspricht dem aus [CC08]. Beim Approval Abbildung 4.2: Approval Pattern Pattern (Abbildung 4.2) wird zuerst der Antrag gestellt, das heißt ein Sender verschickt ein Dokument und ein Bearbeiter empfängt es. Als Nächstes wird der Antrag bearbeitet und das Ergebnis an den Antragsteller (Sender) zurückgeschickt. Zum Schluss wird das Ergebnis der Genehmigung notiert. Eine Zusage muss zusätzlich noch in einer Datenbank 19

20 4 Workflow Generierung mit Hilfe von Workflow Patterns gespeichert werden. Die Bedingungen der Beiden ausgehenden Transitionen vom XOR sind in der Darstellung nicht abgebildet. Die Workflow Engine startet eine Aktivität erst dann, wenn alle eingehenden Transitionen abgeschlossen wurden. Deswegen erforderte Notify result of review, dass ich die beiden eingehenden Transitionen mit einem Marker versehen musste Bi-directional Performative Dieses Pattern repräsentiert eine Anfrage auf Durchführung einer Aktivität, wobei auf diese Aktivität gewartet wird. Beschreibung Die Durchführung einer weiteren Aktivität wird von einem Akteur beantragt. Danach wartet er bis der Empfänger ihn informiert, dass die Aktivität durchgeführt wurde. Beispiel Ein Arzt untersucht einen Patienten. Dabei wird dem Patienten Blut abgenommen. Dieses Blut soll nun im Labor untersucht werden. Dem Labor wird also das Blut zugeschickt und das Labor beginnt mit der Untersuchung. Erst wenn das Labor seine Ergebnisse dem Arzt zukommen lässt, kann dieser die Untersuchung abschließen. Design Choices Single-Request-Response Ein Antragsteller schickt einen Antrag an einen Empfänger und wartet darauf, dass der Empfänger die Durchführung der Aktivität bestätigt. Multi-Request-Response Der Sender schickt eine Anfrage an mehrere Empfänger. Er wartet danach bis er von allen eine Antwort erhalten hat, dass die Aktivität durchgeführt wurde. Abbildung 4.3: Bi-directional Performative Pattern Das Bi-directional Performative Pattern (Abbildung 4.3) verschickt zuerst eine Anfrage auf Durchführung eine Aktivität. Nachdem diese empfangen wurde, kann ein weiteres Pattern 20

21 4.1 Pattern Darstellung im Generator eingefügt werden. Es, wird eine Transition von Receive activity request nach Report completion of activity request gesetzt. Diese Transitionen sollen den Pfad verdeutlichen. Nachdem die Durchführung der Aktivität vollständig abgeschlossen wurde, verschmelzen die beiden Pfade wieder. Die Transition von Send activity request zum AND-Join wurde mit einem Marker versehen. Da sie zwar den primären Pfad kennzeichnet, aber der andere Pfad derjenige ist, der durchlaufen werden muss Decision Beim Decision Pattern wird eine Entscheidung in den Workflow eingeführt, die zwischen verschiedenen Folgepfaden auswählt. Beschreibung Während der Prozessdurchführung werden eine oder mehrere Aktivitäten gestartet. Anschließend kommt es zu einer Verzweigung mit n Pfaden. Es werden 0 bis n verschiedene Ausführungszweige gewählt. Beispiel Ein Patient kommt zum Arzt und erklärt seine Symptome. Der Arzt beginnt nun mit seiner Diagnose. Der Arzt identifiziert das Leiden und schlägt verschiedene Therapien vor. Der Patient kann nun wählen welche Therapien er wählt. Design Choices Single-Desicion Entschieden durch die Ausführung der ausgelösten Aktivität wird ein oder mehrere Nachfolgezweige ausgeführt. Multi-Desicion Die Entscheidung basiert auf mehreren ausgelösten Aktivitäten. Abbildung 4.4: Decision Pattern Das Decision Pattern (Abbildung 4.4 besteht aus einem Bi-directional Performative gefolgt von einem OR-Split. Diese alternative Schreibweise wird in [LHT09a] beschrieben. Auf die Art und Weise, wie Verzweigungen erzeugt wurden, gehe ich später (Kapitel 4.3) noch ein Information request Das Information Request Pattern kann als Spezialisierung des Bi-directional Performative Patterns gesehen werden, [LHT09a]. Bei diesem Pattern werden Informationen beantragt - aus Sicht des Workflows ist es jedoch egal, wie die Informationen gesammelt werden. 21

22 4 Workflow Generierung mit Hilfe von Workflow Patterns Beschreibung Ein Akteur beantragt bestimmte Informationen von einem Prozessteilnehmer. Er fährt mit seiner Arbeit fort, nachdem er die Informationen erhalten hat. Beispiel Ein Patient will wissen, wann er seinen nächsten Untersuchungstermin hat. Er ruft beim Arzt an und bekommt von der Sprechstundenhilfe die Daten. Ihn interessiert es nicht, ob dabei die Daten aus einer Datenbank oder aus einem Kalender an der Wand kommen. Design Choices Single-Information Request Der Akteur beantragt Informationen von genau einem Empfänger. Multi-Information Request Es werden Informationen von mehreren Prozessteilnehmern angefordert. Der Akteur arbeitet weiter, nachdem er die Informationen von jedem erhalten hat. Abbildung 4.5: Information Request Pattern Beim Information Request wird eine Anfrage verschickt, diese wird bearbeitet und die Antwort, in diesem Fall die benötigten Informationen, wird zurückgeschickt Notification Das Notification Pattern besteht aus einer Aktivität, die einen Akteur über die Beendigung eine Aktivität informiert oder systemrelevante Nachrichten verschickt. Beschreibung Der Zustand oder das Ergebnis einer Aktivität wird an einen oder mehrere Teilnehmer gesendet. Beispiel Ein Arzt informiert einen Patienten darüber, dass die Blutuntersuchung ergeben hat, dass er gesund ist. Dadurch, dass er gesund ist, muss er nicht wieder erscheinen. Es wird also auf Patientenseite kein weiterer Prozess angestoßen. Design Choices 22

23 4.1 Pattern Darstellung im Generator Single-Notification Die Nachricht wird an einen Empfänger gesendet. Multi-Notification Mehrere Empfänger erhalten eine Benachrichtigung. Abbildung 4.6: Notification Pattern Das Notification Pattern (Abbildung 4.6) schickt eine Benachrichtigung an einen Empfänger. Beim Notification Pattern wurden von mir beide Aktivitäten als mandatory Aktivitäten modelliert. Um zu überprüfen, ob die Aktivität Receive Notification korrekt ausgeführt wurde, das heißt, zeigen, dass die Nachricht empfangen wurde, musste sie mandatory sein. Die Entscheidung Send Notification auch als mandatory Aktivität zu modellieren, kam daher, dass ich bei jedem Pattern die letzte Aktivität als mandatory Aktivität haben wollte Question-answer Pattern Dieses Pattern beschreibt eine Frage Antwort basierende Interaktion, wobei ein oder mehrere Teilnehmer gewählt werden um die Frage zu beantworten. Beschreibung Während ein Akteur einen Prozess durchführt, kann es zu einer Frage bezüglich der Durchführung kommen. Dafür muss nun der System Support diese Frage und später die Antwort weiterleiten. Es müssen hierbei diejenigen ausgesucht werden, die die Frage beantworten können. Der Fragesteller muss warten bis er die Antwort(en) erhält. Beispiel Ein Krankenschwester weiß nicht, welches Mittel ein Patient bekommt. Sie muss nun also schauen, wer der behandelnde Arzt ist und ihm die Frage stellen. Sie kann dem Patienten erst dann sein Medikament verabreichen, wenn die Frage geklärt wurde. Design Choices Single-Question-Answer Basierend auf der Beschreibung der Frage wird ein Spezialist ausgewählt. Der Sender wartet bis er eine Antwort auf seine Frage bekommt. Multi-Question-Answer Basierend auf der Beschreibung der Frage werden mehrere Spezialisten ausgewählt. Der Sender wartet bis er eine Antwort von jedem der Spezialisten erhalten hat. 23

24 4 Workflow Generierung mit Hilfe von Workflow Patterns Abbildung 4.7: Question-Answer Pattern Beim Question-Answer Pattern (Abbildung 4.7) wird, nachdem die Frage beschrieben wurde, geklärt, wen sie betrifft. Sie wird dann an die Bearbeiter gesendet und bearbeitet. Erst nachdem die Antwort angekommen ist, darf der Fragesteller weiter arbeiten Unidirectional Performative Das Uni-directional Performative Pattern beschreibt eine einseitig gerichtete Anfrage zur Durchführung einer Aktivität. Beschreibung Ein Akteur leitet die Durchführung einer Aktivität ein. Er selbst wartet dabei nicht auf das Ergebnis dieser Aktivität. Beispiel Ein Patient hat das Krankenhaus verlassen. Die verantwortliche Krankenschwester benachrichtigt das Putzpersonal, dass das Zimmer gereinigt werden muss. Das Putzpersonal reinigt das Zimmer und geht danach seinen weiteren Tätigkeiten nach. Design Choices Single-Request Ein Sender schickt eine Anfrage zur Durchführung einer Aktivität an einen Empfänger. Anschließend nimmt er seine Arbeit auf. Multi-Request Ein Akteur schickt Anfragen an mehrere Empfänger gleichzeitig. Danach führt er seine Arbeit fort, ohne auf Antworte zu warten. Beim Unidirectional Performative Pattern (Abbildung 4.8) wird von einem Akteur eine Aktivität angestoßen. Das kann dazu führen, dass eine zusätzliche Ebene im Workflow geöffnet wird. Es ist damit, neben dem Bi-directional Performative und der Decision, das einzige Pattern, welches die Breite des Workflows erhöht. Wichtig an diesem Pattern ist die Durchführung der gestarteten Aktivität, deswegen ist Execute activity request mandatory gesetzt. 24

25 4.2 Generierung Abbildung 4.8: Unidirectional Performative Pattern 4.2 Generierung Der Generator erzeugt Workflows mithilfe von Patterns. Die Auswahl der Patterns geschieht nach Korrelationswahrscheinlichkeiten. Sie geben vor welches Pattern mit welcher Wahrscheinlichkeit nach welchem anderen Pattern kommt. Außerdem legen sie die Wahrscheinlichkeit fest, mit der ein Pattern als erstes Pattern ausgewählt wird. Es kommt bei den Pattern zum Öffnen neuer Swimlanes und zu Verzweigungen. Der durchschnittliche Verzweigungsgrad und die Abweichung werden vom Benutzer als Eingabe dem Generator mitgegeben. Die Tiefe in die der Generator gehen darf, wird über eine vom Benutzer bereitgestellte Binominalverteilung festgelegt. Der Benutzer spezifiziert hierbei die maximale Tiefe und die Wahrscheinlichkeit in die nächste Tiefe zu gehen. Der Generator fügt dabei iterativ Patterns so lange zu einem Workflow hinzu, bis eine, vom Benutzer festgelegte, untere Aktivitätenschranke erreicht wurde. Danach erzeugt der Generator Joins und verbindet damit die Enden des Workflows. Dies geschieht bis zur oberen Aktivitätenschranke, die der Benutzer zusammen mit der unteren Schranke angibt. Wenn es nur noch einen einzigen Join gibt, so werden keine weiteren hinzugefügt, selbst wenn die obere Schranke noch nicht erreicht wurde. Um die Workflows zu generieren, verwende ich die Korrelationswahrscheinlichkeiten der Patterns. Der Generator erzeugt ein erstes Pattern und wählt das Nachfolgepattern anhand dieser Wahrscheinlichkeiten. Die Wahl des ersten Patterns wird dabei auch über eine Korrelationswahrscheinlichkeit festgelegt. Die Wahrscheinlichkeiten werden auf Teilintervalle zwischen 0 und 1 abgebildet. Es wird vom Generator in jedem Iterationsschritt eine Zufallszahl zwischen 0 und 1 erzeugt. Das Intervall, in dem diese Zufallszahl liegt, wählt das Nachfolgepattern. Das Nachfolgepattern wird nun an der Endaktivität des vorhergehenden Patterns hinzugefügt. 25

26 4 Workflow Generierung mit Hilfe von Workflow Patterns Betrachten wir ein Beispiel mit einer unteren Schranke von 11 und einer oberen von 15. Wie im Beispiel 4.9 zu sehen, wurde zuerst ein Approval Pattern erzeugt. Die Endaktivität, Abbildung 4.9: Beispiel für Workflow Generierung, Bild 1 Notify result of review, wird nun als Anfügepunkt für ein nächstes Patterns genutzt. Da das Approval Pattern sehr groß ist, habe ich die restlichen Aktivitäten zusammengefasst. Damit dem Workflow ein Pattern hinzugefügt werden kann, merkt sich der Generator an welche Aktivitäten Patterns hinzugefügt werden können. Das Pattern wird anschließend dem Workflow hinzugefügt und mit der ausgewählten Aktivität verbunden. Abbildung 4.10: Beispiel für Workflow Generierung, Bild 2 In diesem Beispiel wird (Abbildung 4.10) nun ein Unidirectional Performative hinzugefügt. Die neuen Anfügepunkte sind Send activity request und Execute activity request. Dadurch, dass zwei Anfügepunkte vorliegen, wurde eine zweite Swimlane eröffnet. Dies läuft so lange weiter bis die untere Schranke für Aktivitäten erreicht wird. Abbildung 4.11 zeigt wie das letzte Pattern die untere Schranke von 11 überschreitet. Ab jetzt wird das gesamte Approval Pattern nur noch zusammengefasst gezeigt, damit die Abbildung übersichtlicher wird. Hinterher werden Joins hinzugefügt bis die obere Schranke erreicht wird. Die Joins sind jeweils eine einzelne Aktivität. Alle in einen Join eingehenden Transitionen werden dabei mit einem Marker versehen. Dadurch wird ein Join aktiv, sobald es einen Pfad gibt, der zu diesem Join führt. Wenn es außer einem einzigen Join keine Aktivitäten, an die ein Join angefügt werden 26

27 4.2 Generierung Abbildung 4.11: Beispiel für Workflow Generierung, Bild 3 darf, mehr gibt, so wird die Generierung beendet. Der Generator beendet hier seine Arbeit, obwohl die obere Schranke noch nicht erreicht wurde. Abbildung 4.12: Beispiel für Workflow Generierung, Bild 4 In unserem Beispiel werden nun nacheinander zwei Joins hinzugefügt (Abbildung 4.12). Damit ist die Aktivitätenanzahl bei 14, die obere Schranke von 15 wurde zwar noch nicht erreicht, jedoch gibt es nur noch einen Anfügepunkt, das letzte Join. Der Generator beendet also die Erzeugung des Workflows. Damit haben wir zwei der Generatorparameter, die untere und obere Aktivitätenschranke. Wenn ein Unidirectional oder ein Bi-directional Performative Pattern hinzugefügt wurde, besteht die Möglichkeit, dass in einer zweiten Swimlane ein Pattern eingefügt wird. Dies geschieht nach einer Binominalverteilung. Je mehr Pattern in der zusätzlichen Swimlane hinzugefügt wurden, desto unwahrscheinlicher ist es, dass ein zusätzliches Pattern hinzugefügt wird. Damit die Swimlane bekannt ist, wird für den Generator gespeichert in welcher Swimlane eine Aktivität liegt. Wie Abbildung 4.13 zeigt, ist es dabei unerheblich, ob die Folgepatterns in einer Ebene sind oder gar noch weitere Ebenen öffnen. Die maximale Rekursionstiefe und die Wahrscheinlichkeit der Binominalverteilung sind 27

28 4 Workflow Generierung mit Hilfe von Workflow Patterns Abbildung 4.13: Vergleich für Rekursionstiefe folglich die nächsten zwei Parameter des Generators, wobei die Rekursionstiefe die maximale Anzahl an Patterns in den folgenden Ebenen ist. Damit nach dem rekursiven Einfügen in ein Bi-directional Performative Pattern auch wieder eine Verbindung zurück erzeugt wird, wird bei der Pattern Erzeugung auch übergeben, ob es eine Zielaktivität gibt. Der Generator erzeugt eine Transition vom Ende des Patterns zur Zielaktivität. Wenn der Workflow fertig erzeugt wurde, durchläuft er noch einmal alle Report completion of activity request des Bidirectional Performative Patterns durch. Hat die Aktivität mehr als eine eingehende Transition, so wurde ein Zwischenpattern eingefügt. Nun setzt der Generator einen Marker auf die Transition von Receive activity request nach Report completion of activity request. Diese Maßnahme dient der Erzeugung von Event Listen. Außerdem wird die Transition nicht mehr benötigt und wäre es möglich, so würde sie gelöscht werden. Doch das Workflow Modell erlaubt es nicht, das Transitionen wieder entfernt werden. Kommen wir zu den letzten zwei Parametern. Das Decision Pattern beinhaltet eine Verzweigung. Der Grad dieser Verzweigung wird durch eine Normalverteilung bestimmt. Der Generator nimmt also einen mittleren Grad für Verzweigungen und eine durchschnittliche Abweichung, um weiter Patterns an die Decision zu kleben. Durch die Anzahl der Aktivitäten kann der Benutzer daher die Größe des Workflows einstellen. Ebenso kann er durch den Grad der Decision und die Rekursionstiefe die Breite des Workflows bestimmen. Wenn der Benutzer den Grad der Decision Verzweigung nutzt um die Breite zu erhöhen, so kommt es meist zu ausgefransten Workflows. Dies sind Workflows mit vielen offenen Enden. Wählt der Benutzer jedoch die Rekursionstiefe der Performative Patterns, so sind die Workflows mit weniger offenen Enden. Damit sind nun alle Parameter des Generators bekannt. Sie ermöglichen eine breite Basis von Workflow Modellen. 28

29 4.3 Decision Splits 4.3 Decision Splits Die Verzweigungen des Decision Patterns will ich genauer ausführen. Technisch gesehen erzeugt der Generator ein Bi-directional Performative Pattern und verbindet es mit einer einzelnen Aktivität. Es wird nun mithilfe der Normalverteilung eine Zufallszahl erzeugt. Die Zahl bestimmt, wie oft die Decision als Endaktivität registriert wird. Damit wird festgelegt, wie viele weitere Patterns zur Decision hinzugefügt werden dürfen. Nun werden, soweit es die Schranken noch erlauben, weitere Patterns hinzugefügt. Es fehlt noch die Verzweigungslogik, die über die Bedingungen der Transitionen geregelt wird. Als einer der letzten Arbeitsschritte des Generators wird diese festgelegt. Dazu wählt der Generator, nachdem das Workflow Modell erzeugt wurde, alle Decision Split Aktivitäten und erzeugt für die Transitionen zufällig Bedingungen. Wenn eine Verzweigung also drei ausgehende Transitionen hat, t 1, t 2, t 3. Und wir drei Events haben A, B, C. So war mein erster Ansatz zu sagen t 1 A, t 2 B und t 3 C. Damit ergab sich jetzt allerdings das Problem, dass ich für jede Kante einen eigenen Event Typen benötigte (siehe Kapitel 5). Ich wollte jedoch die Anzahl der Event Typen klein halten. Der neue Ansatz sieht nun vor, dass die Typen paarweise kombiniert werden. Wie dieser Ansatz jedoch im Detail ausschaut, verrät das nächste Kapitel. Betrachten wir als also Events und wie sie erzeugt werden. 29

30

31 5 Ausführungsmodel Generierung Das Flow Application Model besteht zum Einen aus einem Workflow Modell und zum Anderen aus einer Menge von Events. Das Ausführungsmodell eines Workflows erzeugt nun diese Events. Die Events werden dabei zu Event Listen zusammengefasst. Wenn die Workflow Engine ein Workflow Modell und eine zu dem Workflow gehörende Event Liste als Eingabe bekommt, so sollte das einen gültigen Durchlauf durch den Workflow erzeugen. Wenn ich im Folgenden von Generator spreche, meine ich damit die Erzeugung von Event Listen. Er ist ein Teil des Ausführungsmodelles. Wie bereits erwähnt, wird die Logik der Workflows durch die Bedingungen an den Transitionen festgelegt. Betrachten wir die Bedingungen genauer. Eine typische Bedingung (Abbildung 5.1) verbindet verschiedene Event Typen mit einem Und. Dabei bilden die Events einen semantischen Zusammenhang. In diesem Fall ist es das Vorbereiten eines Reviews, Abbildung 5.1: Beispiel für den Baum einer Bedingung indem ein digitales Dokument geöffnet wird, in Kombination mit einer Korrektur dieses Dokuments. Dies ist die von mir verwendete Form von Bedingungen. Theoretisch werden auch Oder und Nicht unterstützt, jedoch wurden diese Strukturen von mir nicht benötigt. Event Listen sind aus Event Instanzen aufgebaut. Event Instanzen sind die konkreten Ausprägungen der Events. Eine Event Instanz wird dabei über die Aktivität bei der sie auftritt, identifiziert. Sie beinhaltet weiterhin den Event Typen und die tatsächliche Situation, also das entsprechende Event. Die Event Instanzen müssen in der jeweiligen Event Liste in chronologischer Reihenfolge auftreten. Abbildung 5.2 zeigt was ich meine. Die Events der Aktivität 1 müssen vor Denen von Aktivität 2 kommen, und die von Aktivität 3 und Aktivität 4 vor Aktivität 5. Ob aber Aktivität 3 vor Aktivität 4 oder Aktivität 4 vor Aktivität 3 kommt ist unerheblich. Das Ausführungsmodell muss also nicht nur Event Instanzen zu 31

32 5 Ausführungsmodel Generierung Abbildung 5.2: Beispiel für Event Listen Sequenz den Bedingungen erzeugen, sondern es muss diese auch in der Reihenfolge aufführen, in der die Events benötigt werden. Damit die Events so gereiht aufgelistet werden, versucht der Generator die Events in dieser Reihenfolge zu erzeugen. Er beginnt bei der Aktivität ohne eingehende Transitionen, da diese immer den Anfang eines Workflows kennzeichnet. Der Generator folgt den ausgehenden Transitionen und erzeugt dabei die Event Instanzen für die Bedingungen und fügt sie einer, für sich, globalen Event Liste hinzu. Abbildung 5.3: Beispiel für verschiedene Bedingungen einer Transition Es werden dabei die Bedingungen, die in Baumform vorliegen, genommen und für sie Event Listen erzeugt. Es kann nun dazu kommen, dass in einer Bedingung ein Oder vorkommt (Abbildung 5.3). Die Transition darf schalten wenn entweder die Bedingung 1 oder die Bedingung 2 eingetreten ist. Der Generator erzeugt nun temporäre Event Listen für jede dieser Bedingungen. Das heißt, wenn zwei Bedingungen durch ein Oder getrennt sind, erzeugt der Generator zwei Listen - eine für jede Bedingung. Danach wählt er zufällig eine der erzeugten Event Listen aus. Die gewählt temporäre Event Liste wird an die globale Liste angehängt. Es werden für alle ausgehenden Transitionen Event Instanzen generiert. Das Decision Pattern ist hierbei eine Ausnahme, über die ich später sprechen werde. Nachdem für alle ausgehenden Transitionen die Events generiert wurden, wird die nächste Aktivität gewählt. Der Generator führt eine Liste, in die er alle Aktivitäten einträgt, die als nächstes gewählt werden können. Wenn also zu einer Transition Event Instanzen erzeugt wurden, trägt der 32

33 Generator das Ziel dieser Transition in diese Liste ein. Nun wählt der Generator zufällig eine Aktivität dieser Liste und erzeugt für diese die Event Instanzen. Aktivitäten, die bereits besucht wurden, werden dabei nicht noch einmal besucht. Sobald es keine weiteren Aktivitäten in dieser Liste mehr gibt, ist die Erzeugung von Event Instanzen abgeschlossen. Eine wichtige Ausnahme sind hierbei Transitionen mit Marker. Diese Transitionen werden vom Generator ignoriert, außer das Ziel der Transition ist Notify result of review von Approval Pattern oder eine Join Aktivität. Bei diesen Beiden werden für die Transition Event Instanzen generiert, auch wenn sie einen Marker hat. Ich will erklären, wieso allgemein Transitionen mit Marker ausgelassen werden. Transition mit Marker sind Transitionen, die nicht schalten müssen, damit die nachfolgende Aktivität schalten darf. Um das im Ausführungsmodell darzustellen werden sie ignoriert. Die Ausnahme sind Aktivitäten bei denen alle eingehenden Transitionen mit einem Marker versehen wurden. Hier muss nur eine der Transitionen schalten. Da eine solche Konstellation nur bei Join und beim Approval Pattern vorkommt, behandelt der Generator diese separat. Betrachten wir jetzt die Ausnahme des Decision Patterns. Es öffnet mehrere unterschiedliche Pfade im Workflow. Es muss aber nicht jeder dieser Pfade gewählt werden. Die Decision Split Verteilung legt fest, für welche der Transitionen der Generator Event Instanzen erzeugen muss. Nur Aktivitäten, die von einer Transition für die Event Instanzen erzeugt wurden, erreichbar sind werden in die Liste der Aktivitäten mitaufgenommen. Ttrotzdem birgt das Decision Pattern noch einen weiteren Fallstrick. Betrachten wir den Fall, dass sich mehrere Pfade öffnen und in mindestens zwei davon weitere Patterns hinzugefügt werden (Abbildung 5.4). Angenommen, es wird ein Question Pattern und ein Notification Abbildung 5.4: Decision Deadlock Pattern erzeugt, danach werden alle drei Patterns mit einem Join verbunden. Gehen wir davon aus, dass entweder die Transition zum Question Pattern oder die zum Notification Pattern gewählt wird. Es werden also zu einem der Beiden die Event Instanzen erzeugt. Da sowohl Question Answer als auch Notification Pattern eine Aktivität enthalten, die mandatory ist, kann dieser Workflow niemals korrekt terminieren. Ich hatte nun mehrere Varianten, wie ich das Problem beheben könnte. Die erste sah vor, dass 33

34 5 Ausführungsmodel Generierung sobald eine Decision auftritt, alle nachfolgenden Aktivitäten die laut Generator mandatory sein sollten auf nicht mandatory gestellt werden. Nur die Joins würden weiterhin mandatory sein. Wenn nun aber zwei Joins in exklusiven Pfaden waren, so könnte das Problem weiterhin auftreten. Die alternative Lösung für die ich mich entschieden habe, ist Folgende. Das Ausführungsmodell erzeugt zu einer Event Liste eine zweite Liste. Eine Liste mit Aktivitäten, die mandatory sind und für die Laufzeit des Workflows auf nicht mandatory gesetzt werden müssen. Nach Durchführung des Workflows müssen sie dann wieder auf mandatory gesetzt werden. Ich sehe das als eine weitere Design Schwäche des Workflow Modelles, die ich überbrücken musste. Wenn das Workflow Modell local mandatory Aktivitäten erlauben würde, könnte dieses Problem damit vermieden werden. Local mandatory Aktivitäten sind Aktivitäten, die nur in einem Pfad mandatory sind. Das heißt nur wenn dieser Pfad betreten wird müssen die Aktivitäten ausgeführt werden. Betrachten wir, wie bei den Decision Splits die Transitionen gewählt werden, für die der Generator Event Instanzen erzeugt. 5.1 Decision Split Verteilung Beim Decision Pattern beginnt die eigentliche Arbeit des Ausführungsmodelles. Das Ausführungsmodell soll die Events an den Decision Splits nach einer vorgegebenen Verteilung wählen. Die Verteilung ist im Ausführungsmodell gespeichert. Da das Workflow Modell die ausgehenden Transitionen nicht sortiert liefert, speichert sich das Ausführungsmodell zu jeder Verzweigung die Transitionen sortiert ab. Mit dieser Sortierung wird gewährleistet, dass der selbe Verteilungswert immer zur gleichen Transition gehört. Durch die Verteilung kann der Benutzer festlegen, dass bestimmte Pfade häufiger, bzw. immer gewählt werden. Die Verteilung legt zu jedem Pfad einer Verzweigung einen Intervall fest. Diese Intervalle liegen alle zwischen 0, 0 und 1, 0. Wenn zu einer Verzweigung Event Instanzen erzeugt werden sollen, wird nun vom Generator eine Zufallszahl zwischen 0, 0 und 1, 0 erzeugt. Alle Pfade für die die Zufallszahl im Intervall liegt, werden gewählt. Es werden demzufolge Event Instanzen zu den Transitionen erzeugt. Am Beispiel 5.5 sieht man gut, wie der Nutzer festlegen kann, welche Pfade verwendet werden sollen. In diesem Beispiel werden der Erste und der letzte Pfad exklusiv gewählt. Der Mittlere wird bei gleich verteilten Zufallszahlen in 30% der Fälle gewählt. Im vorhergehenden Kapitel erwähnte ich, dass bei meinem ersten Ansatz für die Verzweigungslogik für jede Transition ein eigener Event Typ von Nöten gewesen sei. Dies lag daran, dass die Workflow Engine ein Mapping von Event Typ nach Event erstellt. Wenn also der Fall t 1 A, t 2 B 1 und t 3 B 2, wobei B 1, B 2 beide vom gleichen Typ sind, vorliegt. Wenn 34

35 5.2 Event Typen Abbildung 5.5: Beispiel für die Verzweigungs Verteilung der Generator die Bedingungen zu den Transitionen t 2, t 3 auswählt, so akzeptiert die Engine entweder B 1 oder B 2. Es wird also t 2 oder t 3 gewählt, aber nicht wie gewünscht beide. Der aktuelle Ansatz sieht eine Kombination der Event Typen vor. Ich habe mich dabei dafür entschieden, die Event Typen paarweise zu kombinieren. Damit kann ich Σ n k=2 (k 1) Kombinationen bei n Event Typen erzeugen. Er reduziert also die Anzahl der benötigten Event Typen. Es kommt damit allerdings zu Synergien. Wenn bei dem Beispiel folgende Transitionslogik gewählt wird: t 1 A B, t 2 B C und t 3 A C. So werden, wenn zwei der Transitionen gewählt werden sollen, alle drei gewählt. Das ist allerdings für meinen Betreuer und mich besser als die erste Variante, bei der für jede Transition ein eigener Event Type benötigt wird. Für die Erzeugung der Event Instanzen ist es jedoch nicht von Belang welcher Ansatz gewählt wird. Das Ausführungsmodell erzeugt dementsprechend Listen mit Event Instanzen, die dann von der Workflow Engine den Aktivitäten zugewiesen werden. 5.2 Event Typen Ich erläutere nun welche Events und Event Typen das System verwendet und wie sie ausgewählt wurden. Damit die erzeugten Workflows den Workflows mit starker menschlicher Interaktion ähnlich wurden, entschied ich mich dazu, Events zu erzeugen, die den externen Einfluss, auf den Workflow, wiedergeben. Ich entschied mich dafür nicht zu jeder Aktivität Event Typen zu generieren. Wichtige Schritte im Workflow wurden mit Event Typen versehen. Ich erschuf zuerst Event Typen, die allgemeinen Tätigkeiten der gewählten Aktivitäten entsprachen, wie zum Beispiel eine Anfrage überprüfen. Nachdem die Event Typen und ihre semantischen Zusammenhänge standen erzeugte ich 35

36 5 Ausführungsmodel Generierung zu jedem Typ einige Events, wie zum Beispiel Brief probe lesen oder Telefonnummer überprüfen. Es folgt eine Auflistung der Event Typen und ihrer Ausprägungen, also den Events die an den Typ gebunden sind Request Events Die drei Event Typen, Prepare Request, Verify Request und Send Request wurden bei jeder Form der Anfrage verwendet. Semantisch gehören sie also zusammen. Wichtig ist anzumerken, dass es zum oral request keinen Send Request gibt. Sowohl formal als auch informal letter teilen sich die gleichen Verify Request und Send Request. Dies sind die Events der jeweiligen Event Typen: Prepare Request Prepare phone call Prepare formal letter Prepare informal letter Prepare oral request Verify Request Check phone number Proofread letter Verify that oral request was understood Send Request Make phone call Send letter 36

37 5.2 Event Typen Review Events Auch die Event Typen Prepare Review und Perform Review haben einen semantischen Zusammenhang. Eingesetzt wurden sie nur bei der Perform document review Aktivität des Approval Patterns. Dies sind ihre Event Typen: Prepare Review Perform Review Open digital document Open paper document Proofread document Yes - No Der Typ Yes No Answer wurde verwendet, um die Logik des XOR-Split beim Approval Pattern zu modellieren. Yes No Answer Yes No Activity Execution Events Bei beiden Performative Pattern wurden die Event Typen Prepare Activity Execution und Start Activity verwendet. Ihre Events lauten: Prepare Activity Execution Prepare phone call Prepare real world activity Write TODO-list Start Activity 37

38 5 Ausführungsmodel Generierung Make phone call Start real world activity Hand over TODO-list Information Events Der Event Typ Send Information wurde beim Information Request Pattern verwendet. Seine Events sind: Send Information Send legal Document Send information brochure Present research data Explain circumstance 38

39 6 Validierung der Ergebnisse In diesem Kapitel werde ich über die statistische Auswertung der generierten Workflow Modelle und deren Ausführungsmodellen sprechen. Ich wollte sehen inwieweit, die von mir verwendeten, Parameter sich in den erzeugten Workflows wiederfinden ließen. Bei der Analyse wurden von mir der durchschnittliche Grad der Verzweigungen, die Anzahl der Aktivitäten und die Korrelationswahrscheinlichkeit der Workflow Patterns überprüft. Bei den Ausführungsmodellen wollte ich die Verteilung der Decision Verzweigungen testen. Hierfür wollte ich zu einer Menge von Workflows jeweils eine Anzahl an Event Listen erzeugen. Durch die Traces, also die abgeschlossenen Durchläufe durch den Workflow, wollte ich bestimmen welche Transitionen nach einer Verzweigung, wie oft ausgewählt wurden. Die Anzahl sollte den Werten der vorgegebenen Verteilung entsprechen. Durch einen Fehler im Programm war es mir leider nicht möglich die Traces zu erzeugen, und somit Ausführungsmodelle zu testen. Die Komponente, die für Verteilung zuständig ist, und die Erzeugung der Event Instanzen für eine Bedingung konnte ich jedoch separat testen. 6.1 Generator für Workflows Um möglichst genaue Ergebnisse bei der Validierung des Generators zu verzeichnen, führte ich verschiedene Messreihen durch. In jeder Messreihe wurden mehrere Experimente ausgeführt. Jedes Experiment erzeugte und analysierte eine vorgegebene Anzahl von Workflows. Für jedes Experiment eines Versuches wurden die Aktivitätengrenzen erhöht. Die obere Grenze lag dabei immer 10 Aktivitäten über der Unteren. Dies legte ich fest, da das größte Pattern sieben Aktivitäten enthält und bei einem Unterschied von mehr als 10 es sonst zu Ketten aus Joins kam. Betrachten wir zunächst die Aktivitätenschranken. Ich erzeugte einen Versuch mit 50 Experimenten, wobei die Aktivitätenschranke immer um 5 erhöht wurde. Zu jedem Experiment erzeugte ich Workflows. Das Ergebnis (Abbildung 6.1) entsprach ganz meinen Annahmen. Die untere Aktivitätenschranke wurde nie unterschritten, die Obere nie übertreten. Solange die obere Aktivitätenschranke mindestens sieben Aktivitäten über der Unteren liegt, kann sie nicht überschritten werden. Dies liegt daran, dass das größte Pattern sieben Aktivitäten enthält. 39

40 6 Validierung der Ergebnisse Abbildung 6.1: Anzahl der Aktivitäten in den erzeugten Workflows Die mittlere Anzahl an Aktivitäten lag dabei, ab ca. 80 Aktivitäten bei der oberen Aktivitätenschranke. Wir erinnern uns, dass der Generator so lange Joins hinzufügt, bis entweder die obere Schranke erreicht wurde oder alle Pattern zu einem Join vereint wurden. Beim geringen Abstand zwischen oberer und unterer Schranke kann man davon ausgehen, dass ab einer gewissen Anzahl an Pattern es nicht mehr möglich ist, zu so einem letzten Join zu kommen. Da durch wachsende Worflowgröße auch die Anzahl von Decision Patterns und somit die Breite des Workflows, ansteigt. Deswegen ist Anfangs die untere Aktivitätenschranke noch nahe der eingestellten Schranke, während bei größeren Workflows die obere und untere Aktivitätenanzahl gleich sind. Beim Grad der Verzweigungen überprüfte ich, ob er im Mittel beim eingestellten Wert von 4 lag. Der Grad der Verzweigung kann erst bei größeren Workflows sinnvoll betrachtet werden, da bei kleinen Workflows zu wenige Patterns hinzugefügt werden. Wenn der mittlere Grad vier betragen soll, aber nur drei Patterns große Workflows erzeugt werden, so ist es schwer möglich diesen Grad zu erreichen. Der Grad wird in diesem Fall nur durch das hinzufügen von Joins erreicht. Die Messungen ergaben einen durchschnittlichen Verzweigungsgrad bei 3, 45, der maximale 40

41 6.1 Generator für Workflows Abbildung 6.2: Grad der Verzweigung des Decision Patterns Grad lag bei 24 und der Untere bei 0. Gefordert war ein durchschnittlicher Grad von 4 mit einer Varianz von 0, 3. Das Ergebnis der Analyse ist insofern befriedigend, als dass der mittlere Grad der Verzweigungen im Rahmen der Messgenauigkeit liegt. Folgeversuche zeigten, dass sie der mittlere Wert zwischen 3, 2 und 4, 6 bewegte. Dies ist zwar etwas mehr als durch die Varianz von 0, 3 vorgegeben, lässt sich aber durch die Art der Erzeugung der Workflows erklären. Auch das der untere Grad bei 0 und der Obere bei 24 lagen, erkläre ich mir der Art, wie die Workflows erzeugt werden. Wenn die untere Aktivitäten Schranke überschritten wird, erzeugt der Generator kein weiteres Pattern, sondern fügt Verschmelzungen hinzu. Es kann also passieren, dass der Generator mit einer Verzweigung aufhört und bereits die untere Aktivitätenschranke erreicht hat. Fügt er nun jedoch alle Joins an andere Aktivitäten dran, so wird diese Verzweigung einen Grad von 0 aufweisen. Umgekehrt kann es passieren, dass der Generator die maximale Anzahl Nachfolgepatterns zu einer Decision hinzufügt und danach mit Joins weitere Aktivitäten zu der Decision hinzugefügt werden. Somit kommt es zu einem Grad der deutlich über dem durchschnittlichem Grad von 4 liegt. Bevor ich die Korrelationswahrscheinlichkeit überprüfte, wollte ich schauen wie die Verteilung der Patterns aussah. Die Verteilung, die ich anstrebte, basierte auf der Dichte von Patterns aus [CC08]. Die von mir erreichte Verteilung weißt mehr Bi-directional Performative Patterns und leicht weniger Decision Patterns auf, als sie sollte. 41

42 6 Validierung der Ergebnisse Abbildung 6.3: Links: Verteilung der Patterns; Rechts: Patterndichte von Chiao Zu jedem Decision Pattern wird auch ein Bi-directional Performative erzeugt. Um die Verteilung zu berechnen wurde jedes Aktivität, die zu einem Pattern gehört, gezählt. Im Namen der Aktivität lässt sich das Pattern, zu dem die Aktivität gehört, herauslesen. Dann wurde die jeweilige Aktivitätenanzahl durch die Anzahl der Aktivitäten des jeweiligen Patterns geteilt. Ich zählte nun die Gesamtzahl an Patterns. Um die Verteilung zu erhalten, subtrahierte ich die Anzahl der Decisions von dem Bi-directional Performatives und teilte alle Patterns durch die Gesamtanzahl. Und da passierte auch der Fehler. Die Bi-directional Performatives, die durch die Decision erzeugt wurden, tauchten in der Gesamtanzahl auf und verschoben dadurch das Ergebnis. Behebt man dieses Fehler, so ist die Verteilung in einem generierten Workflow ähnlich dem eines Workflows aus der realen Welt. Als nächstes befasste ich mich damit, wie viel Prozent der erzeugten Workflows die jeweiligen Patterns enthalten. Wie erwartet, steigt mit wachsender Größe der Workflows das Auftreten der einzelnen Patterns. Das Auftreten beschäftigte mich, weil anfangs durch einen Fehler ab ca. 55 Aktivitäten, immer mehr Decision Patterns erzeugt wurden. Das Auftreten der anderen Patterns war jedoch rückläufig. Wie aber Abbildung 6.4 zeigt, konnte dieser Fehler behoben werden. 6.2 Korrelationswahrscheinlichkeiten der Pattern Die Auswertung der Korrelationswahrscheinlichkeiten war der wichtigste Teil und auch der Aufwendigste. Nicht nur galt es deutlich mehr Zahlen zu sammeln, auch die visuelle 42

43 6.2 Korrelationswahrscheinlichkeiten der Pattern Abbildung 6.4: Auftreten der Pattern in einem Workflow Darstellung war eine Herausforderung. Ich habe mich dafür entschieden zu jedem Pattern das Vorkommen der Nachfolgepatterns separat aufzuführen. Außerdem gebe ich die eingestellten Werte als Diagramm, jeweils rechts, mit an. Die Korrelationswahrscheinlichkeiten legten fest, welches Pattern als nächstes eingefügt werden sollte. Um sie zu bestimmen, zählte ich die Patterns, die jeweils vor der ersten Aktivität eines Patterns auftraten. Da vor dem Decision Pattern immer ein Bi-directional Performative Pattern eingefügt wurde, musste ich hierbei schauen, wie das Pattern vor dem Bi-directional Performative lautete. Betrachten wir zunächst aber das Erste erzeugte Pattern (Abbildung 6.5). Ich bediente mich hierbei beim Auftreten der Patterns (Vergleich: Dichte nach [CC08]). Wie zu sehen ist, war die Anzahl der Bi-directional Performative Patterns deutlich über dem vorgegebenen Wert, während die der Decision Patterns reduziert war. Das liegt daran, dass das Validierungsprogramm bei den Korrelationswahrscheinlichkeiten falsch zählt. Es berechnet für jedes auftretende Pattern, wobei es nach der ersten Aktivität eine Patterns geht, welches Pattern davor kam. Beim Decision Pattern wird geschaut, welches Pattern vor dem Bi-directional Pattern kam. Dadurch kommt es aber dazu, dass vor jedem Decision Pattern das entsprechnde Bi-directional Pattern auch ausgewertet wurde, obwohl 43

44 6 Validierung der Ergebnisse Abbildung 6.5: Erstes gewähltes Pattern nur das Decision Pattern gezählt werden sollte. Wie leicht zu sehen ist, ist die Anzahl an Bi-directional Patterns gleich dem Vorgabewert plus dem Vorgabewert des Decision Patterns. Dieser Fehler pflanzt sich leider durch alle Diagramme fort. Ein Versuch ihn zu beheben, resultierte in falschen Werten beim Betrachten der Korrelationswahrscheinlichkeiten des Bi-directional Performatives, mit stellenweise negativem Auftreten. Ich entschied mich also dafür die aktuellen, falsch gezählten, Diagramme beizubehalten. Neben dem bereits genannten Fehler beim Decision Pattern ist beim Approval Pattern (Abbildung 6.6) nur auffällig, dass beim ersten Experiment, die Wahrscheinlichkeiten alle bei 0 liegen. Das liegt daran, dass das Approval Pattern eine Aktivitätenanzahl von sieben Aktivitäten hat. Die untere Schranke für die Aktivitätenanzahl lag bei 5 im ersten Experiment. Dadurch konnte nach dem Approval Pattern kein weiteres Pattern eingefügt werden. Bei Workflows mit nur einem Pattern kann es aber keine Nachfolgepatterns geben und somit auch keine Korrelationswahrscheinlichkeiten berechnet werden. Ansonsten sind die Wahrscheinlichkeiten der Nachfolger des Approval Patterns, entsprechend der vorgegebenen Werte. Die Analyse des Bi-directional Performative Pattern (Abbildung 6.7) zeigte kein besonderen Eigenheiten auf. Die Größe des Patterns, es besteht aus vier Aktivitäten, lässt sich an den Wahrscheinlichkeiten erkennen. Es ist sichtbar, dass schon im ersten Experiment Nachfolgepatterns gewählt wurden. Die Werte entsprechen denen, die vorgegeben wurden. 44

45 6.2 Korrelationswahrscheinlichkeiten der Pattern Abbildung 6.6: Korrelationswahrscheinlichkeit für das Approval Pattern Das Diagramm des Decision Patterns (Abbildung 6.8) lässt, wie das des Approval Patterns, erkennen, dass dieses Pattern größer als fünf Aktivitäten ist. Somit kann es zum ersten Experiment keine Korrelationswahrscheinlichkeiten geben. Da, wie zuvor schon erwähnt, erst ab einer gewissen Workflowgröße der vorgegebene Grad der Verzweigungen zu erreichen ist, sind die Werte der ersten Experimente noch ungenauer als die von späteren. Bei den späteren Experimenten wurden größere Workflows erzeugt. Mit Ausnahme des Fehlers beim Zählen der Decision und Bi-directional Performative Patterns kam es auch beim Information Request Pattern (Abbildung 6.9) zu keinen Ungereimtheiten. Es ist am Diagramm erkennbar, dass dieses Pattern seltener auftritt als andere, da das Diagramm eine stärkere Streuung hat. Mit Streuung meine ich, dass die Linien nicht glatt sind. Nichtsdestotrotz ähneln die Werte den eingestellten Korrelationswahrscheinlichkeiten. Auch beim Notification Pattern (Abbildung 6.10) ist erkennbar, dass das Bi-directional Performative Pattern für jedes Decision Pattern ein weiteres mal gezählt wird. Bis auf diese Ausnahme entsprechen die Werte aber den Erwartungen. Beim Question-Answer Pattern (Abbildung 6.11) ist eine stärkere Streuung der Ergebnisse zu erkennen. Ich erkläre das damit, dass dieses Pattern seltener auftritt als die Anderen. Es gibt dadurch weniger Messdaten als zu anderen Patterns. Die erhobenen Daten ähneln den Vorgaben, trotz der Streuung. 45

46 6 Validierung der Ergebnisse Abbildung 6.7: Korrelationswahrscheinlichkeit für das Bi-directional Performative Pattern Auch das Question-Answer Pattern zählt mehr als fünf Aktivitäten, womit es zu keinen Daten im ersten Versuchsschritt kam. Die Korrelationswahrscheinlichkeiten des Unidirectional Performative Pattern (Abbildung 6.12) entsprechen den Vorgaben. Wie mir die Diagramme bestätigt haben, werden die Korrelationswahrscheinlichkeiten korrekt von dem Generator angewendet um den Nachfolger für ein Pattern auszuwählen. Die mit dem Generator erzeugten Workflows erfüllen damit meine Anforderungen für realistische Workflows. 6.3 Ausführungsmodell und Decision Split Verteilung Das Ausführungsmodell enthält den Generator für die Event Listen. Er passt die Transitionen der Decision Pattern Verzweigungen an eine Verteilung an. Zu testen war, dass die Event Listen, die vom Ausführungsmodell eines Workflows erzeugt werden, immer zu gültigen Durchläufen des Workflows führen. Durch einen Fehler im Ausführungsmodell führen jedoch nur um die 90% der Event Listen zu gültigen Durchläufen. Damit könnte ich die Traces der Durchläufe nicht nutzen, um das Ausführungsmodell zu testen. 46

47 6.3 Ausführungsmodell und Decision Split Verteilung Abbildung 6.8: Korrelationswahrscheinlichkeit für das Decision Pattern Stattdessen habe ich jedoch die Komponenten des Ausführungsmodelles getestet. Die Komponenten sind: Erzeugung der Event Instanzen zu einer Bedingung Anwenden der Decision Pattern Verteilung Auswahl des Nachfolgepatterns Die Erzeugung der Event Instanzen zu einer Bedingung testete ich mit Ein-Pattern-Workflows. Ich erstellte also Workflows, die jeweils nur aus einem Pattern bestanden und ließ für sie Event Listen erzeugen. Bei 50 Workflows, mit Patterns ausgewählt nach der Korrelationswahrscheinlichkeit für das erste Pattern, wurden jeweils 10 Event Listen erzeugt. Jede dieser 10 Event Listen wurde zusammen mit dem Workflow der Engine als Parameter übergeben. Das Resultat war, dass zu jeder dieser Event Listen ein gültiger Durchlauf erzeugt wurde. Der Fehler lag also nicht in der Erzeugung der Event Instanzen. Danach testete ich die Anwendung der Verteilung für die Decision Verzweigungen. Ich ließ mir zu jedem Grad zwischen 0 und Verteilungen erzeugen. Bei Verzweigungen ab einem Grad von 7 oder mehr sollten alle nachfolgenden Transitionen gewählt werden. Abbildung 6.13 zeigt die Situation bis zum Grad 7. Es steht jeweils in Prozent, wie oft die Verzweigung gewählt wurde, dahinter steht in Klammer das Intervall für das diese Verzweigung gewählt werden sollte. Aus der Abbildung schließe ich, dass die Transitionen zu 47

48 6 Validierung der Ergebnisse Abbildung 6.9: Korrelationswahrscheinlichkeit für das Information Request Pattern denen Event Instanzen erzeugt werden sollen, nach der vorgegebenen Verteilung ausgewählt werden. Diese Komponente ist somit nicht für den Fehler verantwortlich. Die Auswahl des Nachfolgepatterns bleibt somit für mich als letzte Fehlerquelle. Beim Betrachten verschiedener fehlerhafter Event Listen konnte ich bestätigen, dass die Events nicht immer in der korrekten Reihenfolge erzeugt wurden. In bestimmten Fällen wählt der Generator für Event Listen eine falsche Aktivität als Nachfolger. Die resultierende Event Liste erfüllt somit nicht mehr die Anforderung, dass die darin vorkommenden Events chronologisch sein müssen. Deswegen kann daraufhin die Workflow Engine keinen gültigen Durchlauf erzeugen. Bis der Fehler gefunden wurde, müssen deswegen die fehlerhaften Listen aussortiert werden, wenn man das Ausführungsmodell nutzen möchte. 48

49 6.3 Ausführungsmodell und Decision Split Verteilung Abbildung 6.10: Korrelationswahrscheinlichkeit für das Notification Pattern Abbildung 6.11: Korrelationswahrscheinlichkeit für das Question-Answer Pattern 49

50 6 Validierung der Ergebnisse Abbildung 6.12: Korrelationswahrscheinlichkeit für das Unidirectional Performative Pattern Abbildung 6.13: Ergebnis der Transitionen Auswahl (in Prozent) und die zugrundeliegende Verteilung (in Klammern) 50