Design und Implementierung eines Webservices für die automatisierte Generierung von BPMN 2.0 Prozessmodellen [original]

Fakultät für

Ingenieurwissenschaften,

Informatik und

Psychologie

Institut für Datenbanken

und Informationssyste-

Design und Implementierung eines

Webservices für die automatisierte Ge-

nerierung von BPMN 2.0 Prozessmodellen

Bachelorarbeit an der Universität Ulm

Vorgelegt von:

Leon Ahmadi-Moghaddam

[email protected]

1034441

Gutachter:

Prof.Dr.Manfred Reichert

Betreuer:

Michael Winter

2020

Fassung 29. Oktober 2020

2020 Leon Ahmadi-Moghaddam

Satz: PDF-L

TEX2ε

Kurzfassung

BPMN 2.0 ist ein branchenübergreifender Standard für die Modellierung von Pro-

zessen. Neben der grafischen Repräsentation der Modelle definiert der Standard

außerdem eine maschinell verarbeitbare XML-Repräsentation. Im Rahmen von Stu-

dienarbeiten zu der Verständlichkeit von BPMN-Modellen werden syntaktisch un-

terschiedliche Diagramme benötigt. Damit diese nicht wiederkehrend händisch mo-

delliert werden müssen, wurde der BPMN-Generator zur automatisierten Generie-

rung von Prozessmodellen auf der Grundlage gewisser Benutzereingaben (Anzahl

der Aktivitäten, Gateways, Events, etc.) entwickelt. Bei dem BPMN-Generator han-

delt es sich um einen Express.js-Webservice, der in einer Node.js-Umgebung aus-

geführt werden kann. Die Datenhaltung erfolgt über eine MongoDB-Instanz und

als Client dient ein gewöhnlicher Webbrowser. Die entwickelte Software zeichnet

sich durch einen modularisierten Entwurf aus, wodurch das Produkt einen hohen

Grad an Wartbarkeit und Erweiterbarkeit erhält. Im Vergleich zu bisherigen Model-

lierungsumgebungen wie dem Signavio Process Manager oder bpmn.io kann sich

der BPMN-Generator durch die Funktionalität der automatisierten Generierung her-

vortun und bietet somit einen anwendbaren Mehrwert.

iii

Inhaltsverzeichnis

Kurzfassung iii

Abkürzungsverzeichnis vi

1 Einleitung 1

1.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Implementierungsgegenstand . . . . . . . . . . . . . . . . . . . . . 3

1.3 Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Anforderungsanalyse 5

2.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 7

3 Technologie 9

3.1 Implementierungssprache: JavaScript und Node.js . . . . . . . . . . 9

3.1.1 Framework: Express.js . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Tests: Mocha . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Datenhaltung: MongoDB . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Entwurf 12

4.1 Systemstrukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Architekturentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 Feinentwurf: Klassen- und Objektentwurf . . . . . . . . . . . . . . . 14

5 Implementierung 17

5.1 Server-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2.1 Benutzereingabe im Frontend . . . . . . . . . . . . . . . . . . 20

Inhaltsverzeichnis

5.2.2 Generierung der Graph-Repräsentation durch ’generateDia-

gram’............................... 23

5.2.3 Transformierung in XML-Repräsentation durch ’generateXM-

LFromGraph’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.1 Die handleQuery-Funktion . . . . . . . . . . . . . . . . . . . 29

5.4 Datenexport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Anforderungsabgleich 32

7 Verwandte Arbeiten 34

7.1 Signavio Process Manager . . . . . . . . . . . . . . . . . . . . . . . 34

7.2 diagrams.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.3 bpmn.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.4 Lucidchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.5 Zeebe Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.6 Abgrenzung des BPMN-Generators . . . . . . . . . . . . . . . . . . 36

8 Zusammenfassung 37

8.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A Quelltexte 39

A.1 BPMNGraphGenerator.js . . . . . . . . . . . . . . . . . . . . . . . . 39

Literatur 43

Abkürzungsverzeichnis

BPM Business Process Management (Geschäftsprozess-Management)

BPMN Business Process Model and Notation

OMG Object Management Group

DBMS Datenbankmanagementsystem

1 Einleitung

Das Business Process Management (Geschäftsprozess-Management) (BPM) be-

schreibt die Disziplin der systematischen Erfassung, Analyse und Optimierung von

Geschäftsprozessen [7]. Ein Geschäftsprozess definiert eine Menge von Tätigkei-

ten, die in einer bestimmten zeitlichen Abfolge und unter Beachtung von Ereignis-

sen und Bedingungen ausgeführt werden, um ein gewisses Ziel zu erreichen [7].

Im Hinblick auf das ökonomische Prinzip liegt die Relevanz des BPM und somit das

unternehmerische Interesse, Geschäftsprozesse zu optimieren, nahe.

Die Prozessoptimierung folgt aus theoretischer Sicht dem Modell des BPM-Lebens-

zykluses. Dieser definiert mehrere Phasen, die zyklisch wiederkehrend ausgeführt

werden und so einen bestehenden Geschäftsprozess iterativ verbessern. Abbil-

dung 1.1 zeigt die Grundstruktur des Lebenszykluses nach [6]. Gemäß dieses Mo-

dells müssen Prozesse in der Organisation zunächst identifiziert und voneinander

abgetrennt werden. Im nächsten Schritt, der Prozess-Entdeckung, werden die Ist-

Zustände der Prozesse erfasst und als Modell festgehalten. Anschließend werden

Schwachstellen der bisherigen Prozesse auf der Grundlage der zuvor modellierten

Prozesse identifiziert und dokumentiert. In der Phase der konkreten Prozessop-

timierung werden mögliche Änderungen erarbeitet, die den Prozess verbessern.

Diese werden in einem Soll-Prozessmodell erfasst. Schließlich werden diese Soll-

Prozesse in der Organisation eingeführt und der Erfolg der Optimierungen wird

überwacht, woraufhin ggf. eine weitere Iteration des Lebenszykluses startet. [6]

Die Prozessoptimierung bedarf also einer formalen Erfassung des Soll- und des Ist-

Zustandes mit Hilfe von Prozessmodellierungssprachen. Sie dienen als Kommuni-

kations- und Bewertungsgrundlage und spezifizieren das gewünschte Ergebnis.

Darüber hinaus ist es möglich, Prozessmodelle von Softwaresystemen einlesen zu

lassen, um den Prozess vollständig oder zu Teilen zu automatisieren. Die Object

Management Group (OMG) definiert mit der Business Process Model and Nota-

1 Einleitung

Abbildung 1.1: Der BPM-Lebenszyklus nach [6].

tion (BPMN) 2.0 einen Modellierungs-Standard [4]. Konkret handelt es sich bei

BPMN 2.0 um eine grafische Modellierungssprache, die durch ein XML-basiertes

Format technisch implementiert wird. BPMN bietet durch die grafische Modellierung

den Vorteil, dass es leicht verständlich ist und somit interdisziplinär als Werkzeug

anerkannt wird, sowie die Möglichkeit der maschinellen Verarbeitung durch die De-

finition des Standards.

Zusammenfassend zeigt sich, dass das BPM mit den zugehörigen Modellierungs-

sprachen ein großes und praxisrelevantes wissenschaftliches Feld aufspannt. Wei-

terführende grundlegende Informationen und theoretische Hintergründe lassen sich

[7] und [4] entnehmen.

1 Einleitung

1.1 Problembeschreibung

Die Verständlichkeit von Prozessmodellen ist im wissenschaftlichen Bereich des

BPM ein zentrales Thema. Grafische Modellierungsansätze ermöglichen grund-

sätzlich ein leichteres Verständnis, doch auch etablierte Modellierungssprachen wie

BPMN können fehlinterpretiert werden. Es ist demnach erforderlich, durch wissen-

schaftliche Arbeiten Schwachstellen der Modellierung zu identifizieren. So haben

beispielsweise Mendling et al. auf der Grundlage von empirischen Studien die sie-

ben folgenden Richtlinien definiert, anhand derer bei dem Entwurf von Prozessmo-

dellen verständlichere Ergebnisse erzielt werden sollen [8]:

1. Reduziere die Anzahl der Elemente im Modell

2. Reduziere die Anzahl der Flüsse / Pfade eines Elements

3. Verwende nur ein Start- und ein End-Event

4. Verbessere die Struktur des Modells

5. Vermeide OR-Elemente

6. Benenne Aktivitäten nach dem Verb-Objekt Muster

7. Zerlege das Modell, wenn es mehr als 50 Elemente hat

Außerdem zeigen die Ergebnisse des Eye-tracking Experiments von Zimoch et al.,

dass unerfahrene Anwender Schwierigkeiten bei dem Verstehen von BPMN 2.0

Modellen haben, wohingegen Experten diese deutlich effizienter begreifen [12]. Für

die Durchführung solcher Studien ist es bislang notwendig, die Prozessmodelle

manuell zu erstellen. Diese Modellgenerierung soll durch eine Softwareanwendung

automatisiert werden.

1.2 Implementierungsgegenstand

Zum Zwecke der automatisierten Generierung von BPMN 2.0-Prozessmodellen

wurde im Rahmen dieser Arbeit eine Webanwendung entwickelt. Der Benutzer kon-

figuriert Diagramm-Parameter, auf deren Grundlage die Software ein oder mehre-

re BPMN 2.0-Diagramme generiert. Diese werden in einer Datenbank gespeichert

1 Einleitung

und können von dem Anwender in die Dateiaustauschformate PNG, PDF, XML und

SVG exportiert werden. Die im Zuge des Softwareentwicklungsprozesses entstan-

denen Ergebnisse der Anforderungsanalyse, des Entwurfs und der Implementie-

rung werden in der folgenden Ausarbeitung vorgestellt. Die entwickelte Anwendung

wird namentlich als ’BPMN-Generator’ ausgewiesen.

1.3 Struktur der Arbeit

In der fortlaufenden Ausarbeitung werden Entscheidungen und Überlegungen des

Softwareentwicklungsprozesses erläutert und begründet. Zunächst werden mit den

funktionalen und nichtfunktionalen Anforderungen an das System die Ergebnisse

der Anforderungsanalyse vorgestellt. Anschließend wird in Kapitel 3 die Wahl der

eingesetzten Technologien begründet. Kapitel 4 diskutiert die Entwurfsentscheidun-

gen, insbesondere im Hinblick auf die Systemstrukturierung, den Architekturentwurf

sowie den Feinentwurf der Software. Hierfür werden veranschaulichende Diagram-

me herangezogen und Bezug auf die einzelnen Komponenten genommen. Das

darauf folgende Kapitel 5 stellt die Implementierung der wichtigsten Bestandtei-

le vor und gibt somit auf Codeebene einen Überblick über das Projekt. Daraufhin

werden die in Kapitel 2 vorgestellten Anforderungen an das Projekt auf der Grund-

lage der abgeschlossenen Softwareentwicklung reflektiert und eventuelle Abwei-

chungen begründet. Mit Kapitel 7 folgt eine Vorstellung verwandter Arbeiten, ins-

besondere ähnlicher Modellierungsumgebungen für BPMN 2.0 Diagramme, die an-

schließend vom BPMN-Generator abgegrenzt werden. Schlussendlich werden die

erarbeiteten Ergebnisse zusammengefasst und es wird ein Ausblick auf die Weiter-

entwicklung des Services gegeben.

2 Anforderungsanalyse

Ein essenzieller Bestandteil des Softwareentwicklungsprozesses ist die Anforde-

rungsanalyse. In dieser Phase werden sowohl funktionale als auch nichtfunktionale

Anforderungen an das zu entwickelnde Softwaresystem erarbeitet und festgehalten.

Diese dienen als Kommunikationsgrundlage für die Erwartungen des Auftraggebers

und setzen somit den Rahmen für den Software-Entwurf und die anschließende Im-

plementierung. Funktionale Anforderungen betreffen die Funktionalität des zu ent-

wickelnden Systems, während nichtfunktionale Anforderungen auf Qualitäts- und

Entwicklungsaspekte eingehen. Die Anforderungen sollen präzise und vollständig

formuliert werden, um eine Bewertungsgrundlage für die Software zu schaffen.

Trotz der gewissenhaften Definition und Formulierung von funktionalen Anforderun-

gen in der Analysephase, können sich diese im Laufe des dynamischen Software-

entwicklungsprozesses verändern. In agilen Vorgehensmodellen ist es deshalb üb-

lich, die Anforderungen iterativ zu definieren. Die Erreichung der in den folgenden

Abschnitten definierten Anforderungen für den BPMN-Generator wird deshalb in

Kapitel 6 analysiert und Abweichungen werden ggf. begründet.

2.1 Funktionale Anforderungen

Bei der zu entwickelnden Software handelt es sich um einen Webservice, dem der

Benutzer über eine Webbrowser-Schnittstelle Parameter für die Generierung von

BPMN-Diagrammen übergeben kann. Die generierten Diagramme sollen anschlie-

ßend persistiert werden und der Nutzer soll diese in unterschiedliche Austausch-

formate exportieren können. Die erarbeiteten Anforderungen sind im Folgenden

gelistet.

2 Anforderungsanalyse

Name Beschreibung

FA-01: Plattform Die Anwendung stellt ein Web-Interface bereit, welches über

einen Browser erreicht werden kann.

FA-02: Benutzer-

schnittstelle

Die Benutzerschnittstelle umfasst zwei Ansichten:

•Meine Modelle: Hier kann der Benutzer Modelle, die in

einer Datenbank gespeichert sind, einsehen, herunter-

laden und löschen.

•Generator: Hier kann der Benutzer Parameter setzen

(siehe FA-03), auf deren Grundlagen BPMN-Modelle

generiert werden.

FA-03: Eingabe-

parameter des

Generators

Zum Generieren der BPMN-Modelle setzt der Benutzer Pa-

rameter, auf deren Grundlage die BPMN-Modelle generiert

werden. Mindestens von der Software unterstützt werden:

•Anzahl der Aktivitäten

•Anzahl der XOR- und AND-Gateways

•Anzahl der Start- und End-Events

•Anzahl der zu generierenden Modelle

FA-04: Valide

Syntax

Alle generierten BPMN-Modelle sind gemäß des BPMN 2.0

Standards in syntaktisch korrekter Form. Sofern es nicht mög-

lich ist, die vom Benutzer definierte Anzahl unterschiedlicher

Diagramme zu generieren (z.B. aufgrund der Restriktionen

durch die anderen Parameter), wird dem Benutzer eine Feh-

lermeldung ausgegeben.

Tabelle 2.1: Funktionale Anforderungen an den BPMN-Generator.

2 Anforderungsanalyse

Name Beschreibung

FA-05: Persis-

tenz

Die von dem Generator generierten Modelle können wahlwei-

se in einer Datenbank gespeichert werden. Alle gespeicher-

ten Modelle sind über die Ansicht “Meine Modelle” einsehbar

(siehe FA-02). Alternativ können die generierten Modelle auf

dem lokalen Gerät gespeichert werden.

FA-06: Ausgabe-

format

Die generierten Modelle können in folgende Formate expor-

tiert werden:

•XML

•PDF

•PNG

Tabelle 2.1: Funktionale Anforderungen an den BPMN-Generator.

2.2 Nichtfunktionale Anforderungen

Da sich ein gelungenes Softwareprodukt ebenfalls durch weitere, nicht die Funk-

tionalität betreffende Aspekte auszeichnet, werden darüber hinaus nichtfunktionale

Anforderungen definiert. Hierbei sind die Robustheit, Wartbarkeit, Erweiterbarkeit

sowie die Dokumentation und Tests meist zentraler Gegenstand der Betrachtung.

Name Beschreibung

NA-01: Wart-

barkeit und

Erweiterbarkeit

Die Software ist zu einem hohen Grad modularisiert und ist

mit Rücksicht auf Wartbarkeit und Erweiterbarkeit entworfen.

NA-02: Robust-

heit

Fehlerhafte Eingaben werden vom System abgefangen und

dem Benutzer wird eine Fehlermeldung angezeigt.

Tabelle 2.2: Nichtfunktionale Anforderungen an den BPMN-Generator.

2 Anforderungsanalyse

Name Beschreibung

NA-03: Behand-

lung von Lauf-

zeitfehlern

Bei einem Auftreten von Laufzeitfehlern behandelt das Sys-

tem diese angemessen. Sie werden im Log dokumentiert und

dem Benutzer wird eine Fehlermeldung angezeigt.

NA-04: Testab-

deckung

Unit-Tests unterstützen das Entwickeln eines robusten Sys-

tems.

NA-05: Doku-

mentation

Der Quellcode sowie die Schnittstellen des Systems werden

dokumentiert.

Tabelle 2.2: Nichtfunktionale Anforderungen an den BPMN-Generator.

Diese nichtfunktionalen Anforderungen sorgen direkt und indirekt für ein besse-

res Benutzererlebnis, eine einfachere Fehlersuche und -beseitigung durch den Ent-

wickler sowie eine schnellere Einarbeitung für projektfremde Entwickler. Sie setzen

somit ebenfalls ein Mindestmaß an Qualität voraus, bevor die Software dem Auf-

traggeber übergeben werden kann.

3 Technologie

Gemäß der funktionalen Anforderung FA-01 stellt der BPMN-Generator eine Benut-

zerschnittstelle über einen Webbrowser zur Verfügung. Demnach erfolgen clientsei-

tige Benutzereingaben, die serverseitig der Anwendungslogik folgend verarbeitet

werden.

Der Webservice ist mit dem Express.js-Framework in Node.js implementiert und

persistiert die Daten durch ein MongoDB-Datenbankmanagementsystem (DBMS).

Hieraus ergeben sich folgende Systemanforderungen:

•Node Version v12.18.3

•Express.js

•Mocha 8.1.3

•MongoDB Version 4.4.0

Konkrete Hintergründe zu den einzelnen Technologien werden in den folgenden

Abschnitten vorgestellt.

3.1 Implementierungssprache: JavaScript und

Node.js

Eine der prominentesten Programmiersprachen im Bereich der Webentwicklung ist

JavaScript, welche ihren Ursprung in der Frontend-Entwicklung hat. Sie wurde in

der ersten Hälfte der 1990er Jahre von Netscape für den Browser ’Netscape Na-

vigator’ zum Zweck, das Internet dynamischer zu machen, entwickelt [9]. Darauf

folgte die Standardisierung der Sprache von der Normungsorganisation ’ECMA In-

ternational’ unter dem Namen ECMAScript [9].

3 Technologie

Mit Node.js ist 2009 [9] zudem eine JavaScript-Laufzeitumgebung für das Backend

hinzugekommen. Heutzutage stellt die Node.js-Entwicklung einen sehr prominen-

ten Ansatz, moderne Webservices zu realisieren, dar. Die Laufzeitumgebung ge-

stattet, sowohl im Frontend als auch im Backend JavaScript zu verwenden. Folglich

werden Kontextwechsel reduziert, die Kommunikation vereinfacht sowie die Wieder-

verwendbarkeit des Codes erleichtert. Da es sich um eine plattformübergreifende

Technologie handelt, lässt sich die Anwendung in vielen Ungebungen problemlos

ausführen. Die Entwicklung betriebssystemabhängiger Clients ist ebenso nicht not-

wendig. Darüber hinaus stellen eine Vielzahl von Modulen Funktionen bereit, die

den Entwicklungsaufwand reduzieren.

3.1.1 Framework: Express.js

Express.js bietet als Framework serverseitige Funktionalitäten zur Entwicklung von

Webanwendungen. Es lässt sich leicht eine REST-Schnittstelle entwickeln, über

die clientseitig Dienste aufgerufen werden können. Dies ermöglicht die Entwicklung

unterschiedlicher Client-Implementationen, wohingegen die serverseitige Logik für

alle Clients zur Verfügung steht. Für den BPMN-Generator zeigt sich hier ein großer

Vorteil, wenn neben der Web-Benutzerschnittstelle zusätzlich beispielsweise eine

Java-Applikation entwickelt werden soll. Ferner lässt sich das Routing in Express.js

auf einfache Art und Weise konfigurieren und aufgrund der Unterstützung von View-

Engines können Webpages mit dynamischen Inhalten gefüllt werden. Im BPMN-

Generator Projekt kommt die View-Engine ’Pug’ zum Einsatz.

3.1.2 Tests: Mocha

Zur Qualitätssicherung der Software ist das Schreiben und Ausführen von Tests

unabdingbar. Tests können Implementierungsfehler frühzeitig aufdecken bzw. nach

Codeänderungen die Korrektheit der Software indizieren. Durch sogenannte Black-

Box-Tests wird die korrekte Funktionsweise von Softwareeinheiten im Hinblick auf

ihre Ein- und Ausgabe geprüft. Meist werden als Eingabeparameter Repräsentan-

ten verschiedener Werte-Äquivalenzklassen gewählt und es werden Grenzwerte

geprüft. Mit einem Test-Framework kann dabei die notwendige Testumgebung auf-

gebaut werden und die Tests können kontrolliert und ggf. auch automatisiert ausge-

3 Technologie

führt werden. In der Node.js-Umgebung unterstützt beispielsweise das Framework

Mocha das Definieren und die Ausführung von Tests. Mocha ist als Entwicklungs-

Abhängigkeit in der package.json-Datei gelistet.

3.2 Datenhaltung: MongoDB

Für die Persistierung der Daten dient ein MongoDB-DBMS. Die dokumentorientierte

NoSQL-Datenbank ist zur Speicherung von Dokumenten im BSON-Format ausge-

legt. Im Gegensatz zu einer relationalen Datenbank bietet die MongoDB mit den

Dokumenten eine flexible Lösung, hierarchisch organisierte Daten in einem Ein-

trag zu speichern, ohne dabei ein Schema zu erzwingen [3]. Hierdurch ist es mög-

lich, ohne einen großen Transformationsaufwand JSON-Objekte aus der Node.js-

Anwendung in die Datenbank zu schreiben, bzw. von ihr auszulesen. Im BPMN-

Generator Projekt dient das MongoDB-DBMS zur Persistierung der Diagramme

(Diagram, siehe Abschnitt 5.3) und Diagramm-Sammlungen (DiagramSet, siehe

Abschnitt 5.3).

4 Entwurf

Die Entwurfsphase ist für die Qualität und Wartbarkeit der Software von elementarer

Bedeutung. Sie folgt auf die Analysephase und geht der Implementation voraus. Die

Entscheidungen und Ergebnisse dieser Phase bestimmen die spätere Architektur,

Struktur und Implementierung der Software. Die folgenden Abschnitte arbeiten die

Entwurfsentscheidungen des BPMN-Generators heraus.

4.1 Systemstrukturierung

Die Struktur der BPMN-Generator Anwendung folgt dem Client-Server Modell. Der

Server implementiert die gesamte Logik der Anwendung, während der Browser als

Client nur die Benutzerschnittstelle anbietet. Zwischen Client und Server liegt ein

Netzwerk, über welches sie kommunizieren können. Da lediglich ein Server die ge-

samte Funktionalität der Anwendung bereitstellt, lässt sich von einem zweischichti-

gen Client-Server-Modell reden. Ferner lässt sich der Client als thin-Client bezeich-

nen, da dieser keine Logik implementiert.

Ein entscheidender Vorteil des Client-Server-Entwurfs ist die zentrale Steuerung

der Anwendung. Clients können von unterschiedlichen Orten auf den Dienst zugrei-

fen und Daten verändern. Durch die Implementierung einer geeigneten API ist es

darüber hinaus möglich, den Dienst plattformübergreifend und durch unterschiedli-

che Client-Implementationen zugänglich zu machen. Im Fall des BPMN-Generators

genügt lediglich ein Browser, um die Anwendung zu nutzen.

Abbildung 4.1 zeigt den Kommunikationsablauf einer Anfrage des Clients als UML-

Sequenzdiagramm. Ein HTTP-Request trifft bei der Anwendung ein, sofern not-

wendig werden Daten aus der MongoDB-Instanz abgefragt und schließlich sendet

4 Entwurf

:App:Client (Browser) :MongoDB

HTTP Request

ggf. Datenabfrage

Daten

HTTP Response

Abbildung 4.1: Das UML-Sequenzdiagramm stellt die Kommunikation der Anwen-

dungskomponenten bei einem HTTP Request dar.

die Anwendung das Ergebnis der Anfrage zurück an den Client. Anfragen des Cli-

ents können demzufolge manipulierend auf Anwendungsdaten zugreifen. Anhand

der Abbildung wird nochmals hervorgehoben, dass der Client lediglich die HTTP-

Anfragen und -Antworten behandeln können muss, um die Dienste des Servers

nutzen zu können.

4.2 Architekturentwurf

Der Architekturentwurf einer Anwendung ist eng verknüpft mit ihrer Wartbarkeit

und Erweiterbarkeit. Wie auch schon im vorherigen Abschnitt, lassen sich hierbei

grob die Komponenten ’MongoDB’, ’Client/Browser’ und ’App’ unterscheiden. Ab-

bildung 4.2 zeigt diese Komponenten und ihre Verknüpfungen untereinander als

UML-Komponentendiagramm. Die App implementiert die Logik und ist zwischen

Datenspeicher und Client geschaltet. Ferner lässt sich die Anwendung selbst in

weitere Teil-Komponenten untergliedern. Für die Kommunikation mit der Daten-

haltungsschicht ist demnach eine Middleware zuständig, die von der Express.js-

Komponente genutzt wird. Letztere definiert die Schnittstelle des Servers und be-

stimmt somit das Verhalten der Anwendung. Die konkrete Logik wiederum ist in

weitere Komponenten ausgelagert, beispielsweise ist der BPMNGraphGenerator

für die Generierung der BPMN-Diagramme zuständig.

4 Entwurf

«component»

MongoDB

«component»

app

«component»

mongo_middleware

«component»

Express.js (routes)

«component»

BPMNGraphGenerator

«component»

Browser

Abbildung 4.2: UML-Komponentendiagramm der wichtigsten Komponenten des

BPMN-Generators.

Dieser Architekturentwurf ermöglicht durch die lose Kopplung zwischen Logik, Be-

nutzerschnittstelle und Datenhaltung eine leichte Wartbarkeit. Durch die Middle-

ware kann darüber hinaus Funktionalität zur Datenabfrage hinzugefügt werden oder

sogar das gesamte DBMS ausgetauscht werden, ohne dass große Teile der Anwen-

dung angepasst werden müssen. Es bedarf lediglich einer Anpassung der Middle-

ware. Durch die Zentrierung der Logik in der serverseitigen Anwendung ist es dar-

über hinaus möglich, weitere Client-Implementationen bereitzustellen, die mit der

Schnittstelle der Anwendung kommunizieren. Außerdem vereinfacht die Modulari-

sierung der logischen Komponenten die Wiederverwendung des Codes in unter-

schiedlichen Programmteilen oder Projekten.

4.3 Feinentwurf: Klassen- und Objektentwurf

Ausführungsstartpunkt der Anwendung ist die Datei /bin/www.js, in welcher der

HTTP-Server sowie die App (app.js) instanziiert werden. In der Datei app.js wird

die Express.js-Anwendung erzeugt und konfiguriert. Insbesondere wird der von der

Datei routes/index.js exportierte Router als Express.js-Middlewarefunktion für

den Root-Pfad /gesetzt. Die bisher beschriebenen Programmteile setzen folg-

lich das Fundament der Webservice-Anwendung und das Verhalten des Servers

wird demnach durch die Konfiguration des Routers in der Datei routes/index.js

bestimmt. Abbildung 4.3 zeigt die genannten und weitere Einheiten des BPMN-

4 Entwurf

/lib

app.js

routes/index.js

bin/www

Express

Mongoose

/models

utils

+ generateDiagramSet( diagramSettings ): [graphXML]

+ zipDiagrams( [diagramExports] ): Promise

middleware/mongo

+ handleQuery(uri, promiseFn): Promise

+ getDiagramsWithIds(Array, Obj): Promise

+ getDiagramSets( Obj, Obj ): Promise

+ getDiagramSetsWithIds( [IDs] ): Promise

+ saveDiagramSet( String, String, [diagrams] ): Promise

bpmn_xml

BPMNGraphGenerator

+ generateDiagram( diagramSettings ): [BPMNGraphNode]

BPMNExporter

+ exportBPMN( [bpmnXmlStrings] ): Promise

BPMNGraphNode

BPMNTransform

+ generateXmlFromGraph( [BPMNGraphNode] ): xmlString

Abbildung 4.3: UML-Klassendiagramm des BPMN-Generators mit den zentralen

Klassen und Paketen.

4 Entwurf

Generators. Auf die die Logik implementierenden Komponenten wird im Folgenden

näher eingegangen.

Listing 4.1 zeigt zunächst die von der Utils-Datei zur Verfügung gestellten Funk-

tionen. Zum einen generiert generateDiagramSet(diagramSettings) mehrere

BPMN-Diagramme auf Grundlage der übergebenen Parameter. Hierfür werden zu-

nächst durch den BPMNGraphGenerator Graphen erstellt, die die Struktur der ge-

nerierten BPMN-Diagramme repräsentieren. Anschließend werden diese Graphen

durch BPMNTransform in einen XML-String umgewandelt, um die standardisierte

BPMN 2.0 Repräsentation des Diagramms zu erhalten. Zum anderen erstellt die

Funktion zipDiagrams(data) eine ZIP-Datei aus allen übergebenen PDF-, PNG-,

XML- und SVG-Dateien. Diese wird bei Erfolg als Buffer zurückgegeben.

1module . exports = {

2generateDiagramSet : generateDiagramSet ,

3zipDiagrams: zipDiagrams

4};

Listing 4.1: Modulschnittstelle der utils-Datei.

Eine weitere zentrale Komponente der Anwendung ist die Middleware für das DBMS.

Sie bietet Funktionen zur Abfrage und zum Schreiben von Daten der MongoDB-

Datenbank an und nutzt für den Zugriff auf die Datenbank die Bibliothek ’Mongoo-

se’. Außerdem bietet der BPMNExporter der Middleware die Funktionalität, BPMN-

XML-Strings in weitere Austauschformate zu exportieren. Die Implementierung ei-

ner solchen Middleware bietet hinsichtlich des Entwurfs einige qualitative Vorteile.

Einerseits können komplexere Zugriffsoperationen auf die Datenbank in einer Funk-

tion gekapselt werden. Dadurch kann Code-Redundanz vermindert werden und die

konkrete Implementation von der Funktion getrennt werden. Andererseits trennt die

Middleware die Datenhaltungsschicht von der Logik und ermöglicht dadurch un-

komplizierte Anpassungen der Datenzugriffe bei beispielsweise Versionswechseln

der Datenbank oder einem Wechsel des gesamten DBMS.

Insgesamt ermöglicht der modularisierte Entwurf eine schnelle und einfache An-

passbarkeit einzelner Softwarekomponenten, eine leichtere Wiederverwendung im-

plementierter Funktionen sowie eine bessere Einarbeitung von projektfremden Ent-

wicklern, da die Komponenten eindeutiger identifiziert werden können.

5 Implementierung

Nach dem Entwurf steht im Zentrum des Softwareentwicklungsprozesses die Imple-

mentierung der Software. Auch wenn viele qualitätsbeeinflussende Entscheidungen

bisher schon getroffen wurden, kommt es bei der Implementierung darauf an, den

Code in einer nachvollziehbaren und verständlichen Art und Weise zu schreiben,

zu gliedern und zu dokumentieren. Gegenstand dieses Kapitels sind konkrete Im-

plementationsbeispiele des BPMN-Generators.

5.1 Server-Schnittstelle

Die Anwendung ist gemäß des Client-Server-Modells aufgebaut. Der Client sen-

det folglich Anfragen an den Server, welche dieser bearbeitet und beantwortet. Die

Schnittstelle zwischen Client und Server lässt sich grundsätzlich als REST-API be-

trachten. Die Funktionen, die über die entsprechenden Pfade zur Verfügung gestellt

werden, sind im Folgenden vorgestellt.

GET

Pfad Funktion

/Leitet auf die Seite /generate

weiter.

/generate Erzeugt die ’Generator’-Ansicht.

In dieser Ansicht wird dem Be-

nutzer im Browser ein Formular

für das Setzen der Diagramm-

Parameter angezeigt.

Tabelle 5.1: Client-Server Schnittstelle für HTTP-GET-Anfragen.

5 Implementierung

Pfad Funktion

/my_models Erzeugt die ’Meine Diagramme’-

Ansicht. Es werden alle in der Da-

tenbank gespeicherten Diagram-

me geladen und übersichtlich im

Browser dargestellt.

/diagram/:diagramId/preview Zeigt die Vorschau-Ansicht des

Diagramms mit der im Pfad defi-

nierten diagramId an.

/diagram/:diagramId/download Lädt die Export-Dateien des Dia-

gramms mit der im Pfad definier-

ten diagramId, komprimiert die-

se in einer ZIP-Datei und sendet

diese an den Client.

/diagramset/:diagramSetId/preview Zeigt die Vorschau-Ansicht des

DiagramSets mit der im Pfad de-

finierten diagramSetId an.

/diagramset/:diagramSetId/download Lädt die Export-Dateien der

Diagramme aus der Diagramm-

Sammlung mit der im Pfad

definierten diagramSetId, kom-

primiert diese in einer ZIP-Datei

und sendet diese an den Client.

Tabelle 5.1: Client-Server Schnittstelle für HTTP-GET-Anfragen.

POST

Pfad Funktion

/generate Generiert Diagramme auf Grund-

lage der mitgegebenen Eigen-

schaften. Leitet schließlich auf

die Seite /my_models um.

Tabelle 5.2: Client-Server Schnittstelle für HTTP-POST-Anfragen.

5 Implementierung

DELETE

Pfad Funktion

/diagram/:diagramId Löscht das Diagram-Dokument

mit der im Pfad definierten

diagramId .

/diagramset/:diagramSetId Löscht das DiagramSet-

Dokument mit der im Pfad

definierten diagramSetId

inklusiver aller zugehörigen

Diagram-Dokumente.

Tabelle 5.3: Client-Server Schnittstelle für HTTP-DELETE-Anfragen.

Im aktuellen Entwurf ist diese Schnittstelle für die Ansteuerung mit einem Web-

browser ausgelegt. Durch entsprechende Anpassungen könnte diese jedoch auch

von weiteren zu implementierenden Clients aufgerufen werden. Denkbar wäre auch

ein Microservice, der die Dienste des BPMN-Generators nutzt, um in Folge von ge-

wissen Ereignissen automatisiert Diagramme zu generieren. Somit ließe sich die

Anwendung von der klassischen Mensch-Computer-Interaktion entkoppeln.

5.2 Generator

In Abschnitt 4.3 wurde bereits herausgearbeitet, dass zur Generierung der BPMN

Diagramme die beiden Komponenten BPMNGraphGenerator und BPMNTransform

zuständig sind. Erstere bietet die Funktion generateDiagram(diagramSettings)

an, die ein Array von BPMNGraphNodes zurückliefert. Ein BPMNGraphNode ist eine

einfache Datenstruktur, die einen Knoten in einem Graphen mit gewissen Vorgän-

gern und Nachfolgern repräsentiert. Das zurückgegebene Array enthält alle Knoten,

die ein Start-Event des generierten Diagramms repräsentieren. Darüber hinaus gibt

das Funktionsargument diagramSettings die vom Benutzer eingegebenen Para-

meter zur Generierung der Diagramme an. Listing 5.1 zeigt ein Beispiel für das

diagramSettings-Argument.

5 Implementierung

2noTasks: 7,

3noStartEvents : 2,

4noEndEvents : 3,

5noIntermediateEvents: 2,

6noXorSplits : 1,

7noXorJoins : 1,

8noAndSplits : 3,

9noAndJoins : 2,

10 copies : 4

11 }

Listing 5.1: Ein Beispiel für das Konfigurations-Objekt diagramSettings.

Die andererseits von BPMNTransform bereitgestellte Funktion generateXMLFrom-

Graph transformiert die Graph-Repräsentation des Diagramms in eine XML-Re-

präsentation, die anschließend gespeichert und in andere Formate exportiert wer-

den kann. Die nächsten Abschnitte betrachten nochmals genauer den Weg von

der Frontend-Benutzereingabe über die Generierung einer Graph-Repräsentation

durch generateDiagram hin zur Umwandlung in eine XML-Datei durch die Funk-

tion generateXMLFromGraph.

5.2.1 Benutzereingabe im Frontend

Zur Generierung der dynamischen Webpages dient die View-Engine ’Pug’. Für die-

se lassen sich sogenannte Templates erstellen, denen im Backend weitere Daten

übergeben werden können. Das Rendern der Seite wird in den Routing-Funktionen

des Express.js-Servers angestoßen, wie Listing 5.2 zeigt. Demzufolge wird bei ei-

ner HTTP-GET Anfrage an den Pfad /generator die Seite ’generator’ mit dem Titel

’Generator’ zurückgesendet. Diese wird von dem Webbrowser empfangen und dem

Benutzer präsentiert.

In der Datei /views/generator.pug wird gemäß der Template-Sprache die Struk-

tur der Seite definiert. Ein Auszug dessen findet sich in Listing 5.3. Die Datei defi-

niert ein HTML-Formular, das für jeden Eingabeparameter ein input-Element hat.

5 Implementierung

Hierbei ermöglicht Pug die komfortable Möglichkeit, die input-Elemente innerhalb

einer Schleife zu definieren, wodurch Redundanz reduziert werden kann. Abbildung

5.1 zeigt das so erzeugte Web-Formular in der Darstellung eines Webbrowsers.

1router . get (’/ generator ’, (req , res ) => {

2res. render (’generator ’, { title : ’Generator ’});

3});

Listing 5.2: Verhalten der Anwendung bei einer HTTP-GET-Anfrage auf dem Pfad

’/generate’

Abbildung 5.1: Die Browser-Darstellung der Generator-Seite.

Die Eingaben des Benutzers werden gemäß des onchange-Attributs von der Funk-

tion validateForm im Frontend validiert und bei fehlerhaften Konfigurationen wer-

den die betroffenen Eingaben visuell hervorgehoben. Sind alle Eingaben korrekt,

wird die ’Save’-Schaltfläche aktiviert und beim Absenden durch den Benutzer wird

gemäß der form-Definition eine HTTP-POST Anfrage an den Pfad /generate ge-

sendet. Im Server wird daraufhin die Formular-Eingabe als diagramSettings-Ob-

jekt (siehe Listing 5.1) formatiert und der generateDiagramSet-Funktion der utils-

Datei als Parameter übergeben. Listing 5.4 zeigt die Implementation dieser Funk-

tion. Sie stellt das Bindeglied zwischen den in den nächsten beiden Abschnitten

vorgestellten Funktionen generateDiagram und generateXMLFromGraph dar.

5 Implementierung

1h1 Generator

2form ( action =’/ generate ’ method =’post ’)

3div( class =’twocolumns generatorcolumns ’)

4div. leftcolumn

5h2 Model Elements

6each input in [’Activities ’, ’XOR -SPLIT -

Gateways ’, ’XOR -JOIN - Gateways ’, ’AND -

SPLIT - Gateways ’, ’AND - JOIN - Gateways ’,

’Start - Events ’, ’End - Events ’,

’Intermediate -Events’]

7div.row

8label (for= input )= input

9input (type=’number ’ value =0 name =

input id= input , onchange =

’validateForm()’)

10 div.rightcolumn

11 h2 General

12 div.row

13 label (for=’prefix_input ’) Diagram Set

Name

14 input (type =’text ’ name=’ diagram_set_name

’ id=’ diagramset_input ’ value=’

Diagram Set ’)

15 // [...]

16 div.row

17 button Save

Listing 5.3: Die Pug-Template Definition der Generator-Webpage in der Datei

/views/generator.pug.

1function generateDiagramSet ( diagramSettings ) {

2let res = [];

3for (let i = 0; i < diagramSettings .copies ; i++) {

4let bpmn_graph_heads = BPMNGraphGenerator.

generateDiagram ( diagramSettings );

5 Implementierung

5let xml = BPMNTransform . generateXMLFromGraph (

bpmn_graph_heads);

6res.push (xml);

8return res;

Listing 5.4: Die Implementation der Funktion ’generateDiagramSet’.

5.2.2 Generierung der Graph-Repräsentation durch

’generateDiagram’

Das Herzstück der Anwendung ist zweifelsfrei die Generierungslogik der Diagram-

me. Vereinfachend werden hierfür einige Einschränkungen vorgenommen, aus de-

nen Nebenbedingungen für die Diagramme folgen. Der Generierungsprozess wird

exemplarisch mit den in Listing 5.1 definierten Parameter-Werten vorgestellt, die,

wie im vorherigen Abschnitt gezeigt, durch den Benutzer gesetzt werden.

1function generateDiagram ( diagramSettings ) {

2let remainingElements = Object . assign ({} ,

diagramSettings ); // clone

3let graphHeads = generateDiagramFramework (

remainingElements);

4enrichDiagramFramework ( graphHeads , remainingElements

);

5return graphHeads ;

Listing 5.5: Die Implementierung der Funktion ’generateDiagram’.

Der Startpunkt der Generierung ist die Funktion generateDiagram des BPMNGraph-

Generators, deren Implementierung in Listing 5.5 zu sehen ist (weitere Auszüge

des BPMNGraphGenerators lassen sich im Anhang nachschlagen). Zunächst wird

durch die generateDiagramFramework-Funktion ein Grundgerüst des Diagramms

5 Implementierung

aufgebaut, in dem die Start- und End-Events sowie die Gateways enthalten sind,

jedoch noch nicht alle Aktivitäten. Dieser Schritt hat bei gleichbleibender Eingabe

stets das gleiche Ergebnis und gliedert sich in die Join-Phase,Middle-Phase und

Split-Phase. Abbildung 5.2 zeigt die Ergebnisse dieser Phasen auf Basis der Ein-

gabeparameter (siehe Listing 5.1) in grafischer Repräsentation.

Abbildung 5.2: Die drei Generierungs-Phasen ’Join-Phase’, ’Middle-Phase’ und

’Split-Phase’

In der Join-Phase werden alle Start-Events zunächst durch AND-JOIN-Gateways

zu einem Pfad zusammengeführt. Konkret werden die ersten beiden Events durch

ein Gateway zusammengeführt und anschließend wird iterativ dieser neu entstan-

dene Pfad durch ein weiteres Gateway mit dem nächsten Start-Event verbunden.

Folglich werden in dieser Phase bei nStart-Events genau (n-1) AND-JOIN-Gate-

ways benötigt. In Abbildung 5.2 werden lediglich zwei Start-Events mit einem Gate-

way zu einem Pfad zusammengeführt.

Sehr ähnlich zu der Join-Phase ist die Split-Phase, die umgekehrt arbeitet: Mit

AND-SPLIT-Gateways wird der Pfad aufgespaltet, sodass jeder Pfad schließlich

durch ein End-Event beendet wird. Bei mEnd-Events werden also (m-1) AND-

SPLIT-Gateways benötigt. Im Beispiel sind es zwei Gateways, die in drei End-

Events münden.

Schließlich werden in der Middle-Phase alle verbliebenen Gateways positioniert.

Diese werden dabei geschachtelt und jeweils mit einer Aktivität verbunden. Die Zahl

der (verbliebenen) AND-SPLIT- bzw. XOR-SPLIT-Gateways muss also mit der Zahl

der AND-JOIN- bzw. XOR-JOIN-Gateways übereinstimmen. Bei lSPLIT- und l

JOIN-Gateways muss es für die Middle-Phase mindestens (l+1) Aktivitäten geben.

5 Implementierung

Aus den in der Join-,Middle- und Split-Phase getroffenen Modellierungsregeln

ergeben sich die im Folgenden gelisteten Vorbedingungen für die Diagramme:

#StartEvents > 0

#EndEvents > 0

#XOR-JOIN ≥0

#XOR-JOIN = #XOR-SP LIT

#AND-JOIN ≥(#StartEvents −1)

#AND-SP LIT ≥(#EndEvents −1)

#AND-JOIN −(#StartEvents −1) = #AND-SP LIT −(#EndEvents −1)

#AND-JOIN −(#StartEvents −1) + #XOR-JOIN + 1 ≤#T asks

Diese Bedingungen werden bei der Programmausführung durch die in Listing 5.6

angegebene Funktion validateDiagramSettings geprüft. Sollten diese nicht er-

füllt sein, wird ein Fehler geworfen und der Benutzer wird über eine Ausgabe in-

formiert. Darüber hinaus werden diese Bedingungen ebenfalls im Frontend geprüft

und ungültige Eingaben werden nicht zugelassen.

1function validateDiagramSettings ( diagramSettings ) {

2// at least one start - and one end -event

3let valid = diagramSettings . noStartEvents > 0 &&

diagramSettings . noEndEvents > 0;

5// correct number of Gateways in join - and split -

phase

6valid = valid && diagramSettings . noAndJoins >= (

diagramSettings . noStartEvents - 1)

7&& diagramSettings . noAndSplits >= (

diagramSettings . noEndEvents - 1)

9// correct number of Gateways in middle - phase

10 valid = valid && diagramSettings . noXorJoins >= 0

11 && diagramSettings . noXorJoins ===

5 Implementierung

diagramSettings . noXorSplits

12 && ( diagramSettings . noAndJoins - (

diagramSettings . noStartEvents - 1)

13 === diagramSettings . noAndSplits - (

diagramSettings . noEndEvents - 1))

15 // enough tasks

16 valid = valid && diagramSettings . noAndJoins -

diagramSettings . noStartEvents

17 + diagramSettings . noXorJoins + 1 <=

diagramSettings . noTasks

19 if (! valid ) {

20 throw new Error (’Invalid diagram Settings .’);

21 }

22 }

Listing 5.6: Implementierung der Funktion validateDiagramSettings.

Nachdem nun das Grundgerüst des Diagramms als Graph-Repräsentation gene-

riert wurde, übernimmt die Funktion enrichDiagramFramework. Diese fügt die ver-

bliebenen Aktivitäten und Intermediate-Events zufällig in das Diagramm ein. Das

auf Grundlage der Benutzereingabe (Listing 5.1) generierte Grundgerüst (Abbil-

dung 5.2) wird folglich angereichert und nimmt beispielsweise die in Abbildung

5.3 vorliegende Gestalt an. Durch die Wiederholung dieses Prozesses lassen sich

schließlich mehrere Diagramme generieren. Im folgenden Abschnitt wird betrach-

tet, wie die auf diesem Wege generierten Diagramm-Graphen in ein XML-Format

umgewandelt werden.

5.2.3 Transformierung in XML-Repräsentation durch

’generateXMLFromGraph’

BPMN 2.0 stellt einen Modellierungsstandard für Geschäftsprozesse dar. Teil die-

ses Standards ist die Definition der Syntax und Semantik aller grafischen Model-

lierungselemente. Darüber hinaus definiert BPMN 2.0 eine maschinell verarbeit-

5 Implementierung

A B C

D E F

Abbildung 5.3: Ein Beispiel für ein generiertes Diagramm, das aus dem Grund-

gerüst in Abbildung 5.2 angereichert wurde, indem enrichDiagram-

Framework die verbliebenen Aktivitäten zufällig eingefügt hat.

bare Repräsentation im XML-Format [4]. Zur Transformation eines BPMN-Modells

aus der Graph-Repräsentation in ein XML-Dokument ist demnach die Kenntnis des

XML-Schemas notwendig.

Für die Verarbeitung durch das Programm bietet es sich an, eine Klassen-Reprä-

sentation der einzelnen XML-Elemente zu definieren. Diese Klassen können für

jedes Element neu instanziiert werden und ihre Eigenschaften können einfach an-

gepasst werden. Außerdem ermöglicht die Überführung in die Klassen-Repräsen-

tationen die Beachtung von Typ-Hierarchien der XML-Elemente, die in Abbildung

5.4 dargestellt sind. So ist beispielsweise ein FlowElement der übergeordnete Typ

aller im Diagramm darstellbaren Elemente. Diese gliedern sich auf in sogenannte

FlowNodes, also alle Knoten des Diagramms, sowie die als SequenceFlows be-

zeichneten Verbindungspfeile. Durch die Zusammensetzung dieser XML-Objekte

entsteht schließlich eine vollständige Repräsentation der zu generierenden XML-

Datei, die anschließend in einen XML-String umgewandelt wird.

1function generateXMLFromGraph ( startNodes )

Listing 5.7: Signatur der Funktion generateXMLFromGraph.

Rekapitulierend ist das Ergebnis des in Abschnitt 5.2.2 vorgestellten Generierungs-

prozesses eine Graph-Repräsentation (mit BPMNGraphNodes) des Diagramms. An-

stelle aller Knoten des Graphen genügt es, die Startknoten stellvertretend für den

gesamten Graphen anzugeben, da die verbliebenen Knoten iterativ aus den Nach-

folgern ermittelt werden können. Wie Listing 5.7 zeigt, werden ebendiese Startkno-

5 Implementierung

ten der Funktion generateXmlFromGraph als Parameter übergeben. Anschließend

wird wie beschrieben die Struktur der XML-Repräsentation rekursiv durch Objekte

aufgebaut und in einen XML-String umgewandelt.

5.3 Datenhaltung

Die Datenhaltung erfolgt in einem MongoDB-DBMS. Die URI des MongoDB-Ser-

vers lässt sich in der Datei /app/settings/mongo_settings.json konfigurieren.

Zuständig für den Zugriff auf die Datenbank ist die Middleware des MongoDB-

DBMS (/lib/middleware/mongo.js), die Funktionen zum Lesen und Schreiben

von Daten anbietet. Auf dem MongoDB-Server sind die beiden Collections ’dia-

grams’ und ’diagramSets’ angelegt, in denen jeweils Dokumente abgelegt sind. Die

korrespondierenden Schemas sind entsprechend mit Diagram und DiagramSet be-

nannt.

Das Diagram-Schema (siehe Listing 5.8) definiert mehrere Felder, die neben den

unterschiedlichen Austauschformaten eines Diagramms zusätzlich Metainformatio-

nen, wie das Erstellungsdatum oder den Namen des Diagramms speichern. Das

Feld diagramId stellt eine eindeutige Kennung des Dateneintrags dar.

2" diagramId ": { " type ": " String ", " index ": true },

3" name ": " String ",

4" createdAt ": " Date ",

5" lastChangedAt ": { "type": " Date ", "default ": " Date.

now" },

6" xml ": " String " ,

7" svg ": " String " ,

8" png ": " Buffer " ,

9" pdf ": " Buffer "

10 }

Listing 5.8: MongoDB-Schema des Typs ’Diagram’.

5 Implementierung

Bei der Generierung von Diagrammen werden meist mehrere Diagramme gene-

riert. Jedes einzelne wird gemäß des Schemas aus Listing 5.8 in der diagrams-

Collection als einzelnes Dokument gespeichert. Um diese zusammengehörigen

Diagramme gruppieren zu können, wird zusätzlich ein sogenanntes DiagramSet

gespeichert. Dieses enthält neben Metainformationen eine Liste aller diagramIds,

die zum entsprechenden DiagramSet gehören (siehe Listing 5.9).

2" diagramSetId ": " String ",

3" diagramSetName ": " String " ,

4" createdAt ": " Date ",

5" diagramIds ": [" String "]

Listing 5.9: MongoDB-Schema des Typs ’DiagramSet’.

5.3.1 Die handleQuery-Funktion

Die Middleware der MongoDB exportiert sämtliche Funktionen zur Abfrage der Da-

tenbank. Eine zentrale Funktion ist allerdings die handleQuery-Funktion, die bei

jeder Abfrage verwendet werden muss. Die Implementation dieser Funktion ist in

Listing 5.10 gezeigt.

1function handleQuery (uri , asyncFn ) {

2return new Promise (( resolve , reject ) => {

3initializeConnection (uri ).then (() => {

4asyncFn ().then (( data ) => {

5closeConnection (). then (() => {

6resolve ( data );

7}). catch ( reject );

8}).catch (( err) => {

9closeConnection (). finally (() => {

10 reject ( err );

11 });

5 Implementierung

12 });

13 }).catch (( err) => {

14 closeConnection (). finally (() => {

15 reject ( err );

16 });

17 });

18 });

19 }

Listing 5.10: Die Implementation der Funktion ’handleQuery’.

Diese Funktion stellt eine generische Implementation der Datenbankabfrage dar.

Grundsätzlich kann hierdurch sichergestellt werden, dass vor jeder Datenbankab-

frage eine Verbindung zur Datenbank hergestellt wird und insbesondere, dass die-

se nach der Abfrage wieder geschlossen wird. Die eigentliche Abfrage der Daten

ist in der als Parameter übergebenen Funktion asyncFn definiert, die ein Promise

zurückliefern muss und nach erfolgreichem Verbindungsaufbau ausgeführt wird.

Durch diesen Entwurf wird dem Entwickler die Verantwortung für den Verbindungs-

aufbau und -abbau abgenommen und die Entstehung inkonsistenter Zustände wird

unterbunden. Darüber hinaus wird redundanter Code vermieden, der durch den

wiederholten Aufbau und Abbau der Verbindung entstehen würde.

5.4 Datenexport

Zum Austausch der Diagramme sollen diese in unterschiedliche Formate exportiert

werden können. Die Exporte werden bereits beim Speichern des Diagramms in die

Datenbank geschrieben. Die Funktionalität des Exportierens wird von der Funktion

exportBPMN des BPMNExporters bereitgestellt. Diese speichert zunächst temporä-

re Dateien der XML-Repräsentation im .bpmn-Format, welche anschließend durch

das Fremdmodul bpmn-to-image in das SVG- und PNG-Format umgewandelt wer-

den. Daraufhin wird die SVG-Datei in eine PDF-Datei exportiert und die temporä-

ren Dateien werden gelöscht. Diese Export-Dateien werden im Falle des XML- und

SVG-Formats als UTF-8 codierter String in die Datenbank geschrieben. Das PNG-

und PDF-Format wird in binärer Repräsentation gespeichert.

5 Implementierung

FlowElement

+ name: String

c FlowElement(:FlowElementsContainer, name: String)

FlowNode

+ dimensions: FlowNodeDimensions

+ incoming: SequenceFlow[]

+ outgoing: SequenceFlow[]

c FlowNode(:FlowElementsContainer, name, dimensions)

+ addIncoming(SequenceFlow): void

+ addOutgoing(SequenceFlow): void

Event Gateway

+ ﬁeld: type

+ method(type): type

ThrowEventCatchEvent

EndEventIntermediateThrowEventIntermediateCatchEventStartEvent

Task

Activity

ParallelGateway

+ ﬁeld: type

+ method(type): type

ExclusiveGateway

+ ﬁeld: type

+ method(type): type

Process

+ processType:

+ isClosed: boolean

+ isExecutable: boolean

c Process(...)

BaseElement

+ id: String

c BaseElement()

Deﬁnitions

+ name: String

FlowElementsContainer

+ ﬂowElements: FlowElement[]

+ addFlowElement(:FlowElement): void

SequenceFlow

+ dimensions: SequenceFlowDimensions

+ sourceRef: FlowNode

+ targetRef: FlowNode

c SequenceFlow(sourceRef, targetRef)

SequenceFlowDimensions

+ waypoints: [obj]

FlowNodeDimensions

+ x: int

+ y: int

+ width: int

+ height: int

Abbildung 5.4: UML-Klassendiagramm der Klassen, welche die XML-Elemente

auf der Grundlage des im BPMN 2.0 Standards definierten XML-

Schemas repräsentieren.

6 Anforderungsabgleich

Nach der Fertigstellung der Implementation ist es sinnvoll, den Erfolg des Soft-

wareentwicklungsprozesses zu beurteilen. Hierbei können die anfangs definierten

Anforderungen an das System als Maßstab herangezogen werden. Dabei ist es

möglich, dass alle Anforderungen vollständig erfüllt wurden oder sich diese im Lau-

fe des Prozesses verändert haben und somit verfehlt wurden. Die folgende Tabelle

gibt eine Übersicht des Anforderungsabgleichs für den BPMN-Generator.

Name +/o/- Beschreibung

FA-01: Plattform + Der Express.js-Server stellt seinen Dienst über

die durch einen Webbrowser erreichbare Benutzer-

schnittstelle bereit.

FA-02: Benutzer-

schnittstelle

+ Die Ansichten sind über die Pfade /my_models und

/generator erreichbar.

FA-03: Eingabe-

parameter des

Generators

Die geforderten Eingabeparameter sind gegeben. Es

wird zusätzlich zwischen SPLIT- und JOIN-Gateways

unterschieden. Außerdem kann auch die Anzahl der

Intermediate-Events gesetzt werden.

FA-04: Valide

Syntax

o Die generierten Diagramme können aufgrund der vor-

genommenen Einschränkungen nur eine valide Syn-

tax aufweisen, auch wenn hierdurch die Anzahl der

möglichen generierbaren Diagramme gemindert wird.

Sollten die eingegebenen Parameter keine entspre-

chende Generierung zulassen, wird dem Nutzer dar-

über hinaus eine Fehlermeldung ausgegeben. Es ist

jedoch nicht garantiert, dass sich alle generierten

Diagramme unterscheiden.

6 Anforderungsabgleich

FA-05: Persis-

tenz

o Im Laufe der Entwicklung stellte es sich als sinnvol-

ler heraus, alle generierten Diagramme in der Da-

tenbank zu speichern und diese anschließend über

einen Datenexport verfügbar zu machen. Ein Vorteil

dessen ist, dass die Anwendung dadurch als Verwal-

tungstool agieren kann und alle generierten Diagram-

me gesammelt zu finden sind.

FA-06: Ausgabe-

format

+ Es ist ein Export in die Formate XML, PDF, PNG und

SVG möglich.

NA-01: Wart-

barkeit und

Erweiterbarkeit

+ Die Modularisierung der Software wurde in dieser

Ausarbeitung mehrmals angesprochen. Sowohl die

Struktur des Systems als auch der konkrete Feinent-

wurf berücksichtigen den Grundsatz der Modularisie-

rung. Hierdurch wird die Wartbarkeit und Erweiterbar-

keit des Systems verbessert.

NA-02: Robust-

heit

+ Es erfolgt sowohl im Frontend als auch im Backend

eine Validierung der Benutzereingaben. Bei fehlerhaf-

ten Eingaben wird der Benutzer durch entsprechende

Hinweise informiert.

NA-03: Behand-

lung von Lauf-

zeitfehlern

o Laufzeitfehler, wie z.B. die Nichterreichbarkeit der

MongoDB-Instanz, werden vom System angemessen

behandelt und dem Benutzer wird dieser meist in-

klusive ’Stacktrace’ ausgegeben. Aus diesem Grund

wurde auf eine ausführlichere Dokumentation der

Fehler in einer Log-Datei verzichtet, da der Anwen-

der dieser Anwendung meist unmittelbar an der Be-

hebung des Fehlers beteiligt ist.

NA-04: Testab-

deckung

+ Es wurden Unit-Tests entwickelt, die die zentralen

Funktionen der Anwendung testen.

NA-05: Doku-

mentation

+ Der Quellcode zeichnet sich durch eine ordentliche

Struktur sowie einer Dokumentation der Funktionen

aus.

Tabelle 6.1: Anforderungsabgleich der funktionalen und nichtfunktionalen Anforde-

rungen. Für die Bewertung dienen die Zeichen ’+’ = ’vollständig erfüllt’,

’o’ = ’teilweise erfüllt’ und ’-’ = ’nicht erfüllt’.

7 Verwandte Arbeiten

Zur kontextuellen Abgrenzung und Hervorhebung von Vorteilen der entwickelten

Anwendung ’BPMN-Generator’ ist es sinnvoll, verwandte Softwarelösungen zu be-

trachten. Untersuchungsgegenstand sind die Modellierungstools ’Signavio Process

Manager’, ’diagrams.net’, ’bpmn.io’, ’Lucidchart’ und ’Zeebe Modeler’.

7.1 Signavio Process Manager

Der Signavio Process Manager ist ein Tool zur Modellierung von BPMN 2.0 Pro-

zessen. Gemeinsam mit anderen Tools kann es ferner zur Dokumentation, Analyse

und Optimierung der Prozesse eingesetzt werden. Somit handelt es sich bei dem

Signavio Process Manager um ein sehr professionelles aber auch kostenpflichtiges

Tool zur Verwaltung von BPMN Prozessmodellen. [1]

7.2 diagrams.net

Diagrams.net (ehemals draw.io) ist eine Software zur Erstellung von Diagrammen.

Neben UML- und Entity Relation Modellierungselementen stellt das Tool ebenfalls

BPMN-Elemente zur Modellierung bereit. Die Anwendung kann über einen Browser

oder auch über Desktop-Anwendungen aufgerufen werden. Die vom Nutzer erstell-

ten Diagramme können in gängige Austauschformate exportiert werden, allerdings

lässt sich keine BPMN 2.0-konforme XML-Datei erstellen. Insgesamt bietet das Tool

sehr flexible Möglichkeiten, grafische Modelle manuell zu erstellen und zu bearbei-

ten. [5]

7 Verwandte Arbeiten

7.3 bpmn.io

Die Camunda Services GmbH stellt mit bpmn.io ein kostenfreies Tool zur Modellie-

rung von BPMN 2.0 Prozessmodellen bereit. Das Tool ermöglicht das Erstellen und

Bearbeiten von Modellen im Browser. Die Modelle können anschließend im XML-

oder SVG-Format heruntergeladen werden. Demnach handelt es sich um ein über-

sichtliches und benutzerfreundliches Tool, das sich auch in eigene Anwendungen

integrieren lässt. [10]

7.4 Lucidchart

Lucidchart ist eine kostenpflichtige Software für die professionelle Modellierung von

BPMN-Diagrammen und vielen weiteren Modellierungstypen. Das Tool ist für die

Zusammenarbeit im Team ausgelegt und ermöglicht somit eine feine Zugriffsverwal-

tung sowie Kommentar- und Kommunikationsmöglichkeiten innerhalb der Software.

Außerdem bietet Lucidchart die Integration von Drittanbieterservices wie beispiels-

weise Atlassians Projektplanungssoftware Jira oder dem Kommunikationstool Slack

an. Somit lässt sich die Software als benutzerfreundlich charakterisieren und bie-

tet über die Modellierung von BPMN Diagrammen hinaus noch eine umfangreiche

Kollaborationsumgebung an. [2]

7.5 Zeebe Modeler

Mit dem zu der Workflow-Engine Zeebe gehörenden ’Zeebe Modeler’ lassen sich

ebenfalls BPMN-Diagramme definieren. Zeebe ermöglicht die Orchestrierung von

Microservices auf Grundlage eines in BPMN definierten Prozesses. Die Prozess-

diagramme lassen sich im XML-Format oder als Bilddatei speichern. Doch im Ge-

gensatz zu den bisher vorgestellten Modellierungsumgebungen dient der Zeebe

Modeler nicht nur ausschließlich der visuellen Modellierung von Prozessen. Fer-

ner können Schnittstellen zu automatisierten Aktivitäten und Events konfiguriert

werden. Es können also technische Einstellungen vorgenommen werden, mit Hil-

fe derer die Workflow-Engine die Aktivitäten orchestrieren kann. Damit geht der

7 Verwandte Arbeiten

Umfang des Zeebe Modelers über die Grundfunktionalitäten eines grafischen Mo-

dellierungstools hinaus. [11]

7.6 Abgrenzung des BPMN-Generators

Die vorgestellten Modellierungstools bieten allesamt die Möglichkeit an, Geschäfts-

prozesse manuell gemäß BPMN 2.0 zu modellieren. Der im Rahmen dieser Arbeit

entwickelte BPMN-Generator ermöglicht nun zusätzlich, BPMN-Modelle auf der Ba-

sis verschiedener Eingabeparameter automatisch zu generieren. Die bereitgestell-

ten Ausgabeformate ermöglichen zudem beispielsweise die manuelle Bearbeitung

eines generierten Diagramms in bpmn.io.

8 Zusammenfassung

Der Standard BPMN 2.0 ist im Bereich der Prozessmodellierung ein Gegenstand

elementaren Interesses. Es existieren zahlreiche Modellierungstools, mit deren Hil-

fe sich BPMN-Diagramme manuell erstellen und in unterschiedliche Formate ex-

portieren lassen. Damit die für Studienzwecke im Rahmen der Wahrnehmungs-

und Verständlichtkeitsforschung von BPMN 2.0 Prozessmodellen benötigten Dia-

gramme nicht stets händisch modelliert werden müssen, wurde im Rahmen dieser

Arbeit der BPMN-Generator zur automatisierten Generierung von Prozessmodellen

entwickelt.

Die in der Anforderungsanalyse erarbeiteten funktionalen und nichtfunktionalen An-

forderungen an die Software stellen im Laufe des Softwareentwicklungsprozesses

die Kommunikationsgrundlage und Zielvorgabe des Produkts dar. Es ist eine Web-

anwendung zu entwickeln, die auf Basis von Parametereingaben des Benutzers

automatisiert syntaktisch korrekte BPMN-Diagramme erstellt und diese in gewis-

sen Austauschformaten zum Export bereitstellt. Technologisch soll die Anwendung

in einer Node.js-Umgebung mit dem Framework Express.js und dem MongoDB-

DBMS implementiert werden.

Der Client-Server-Entwurf der Software zeichnet sich durch einen hohen Modu-

larisierungsgrad und eine Entkopplung der einzelnen Komponenten sowie insbe-

sondere der Datenhaltungs-, Benutzer- und Logikschicht aus. Dies verbessert die

Wartbarkeit und Änderbarkeit des Systems.

Der abschließende Anforderungsabgleich hat gezeigt, dass eine Vielzahl der an-

fangs definierten Anforderungen an das System erfüllt werden konnten. Das Ent-

wicklungsprojekt ist demnach zu einem erfolgreichen Abschluss gekommen.

8 Zusammenfassung

8.1 Ausblick

Im Hinblick auf die Erweiterbarkeit des BPMN-Generators offenbaren sich viele

mögliche Perspektiven. Zum einen kann die Generierung der BPMN-Diagramme

verbessert werden, indem die Regelmenge erweitert und verfeinert wird. Außer-

dem kann der Umfang des unterstützten BPMN 2.0 Standards erweitert werden,

sodass beispielsweise auch unterschiedliche Eventtypen sowie Pools und Swim-

lanes generiert werden können. Unter Umständen ist es ebenfalls vorteilhaft, be-

reits generierte Diagramme direkt in der Anwendung bearbeiten zu können, indem

z.B. der bpmn.io-Editor integriert wird. Dies würde dem Benutzer auf schnelle und

komfortable Weise das Ausbessern bzw. Anpassen der Diagramme ermöglichen.

Schließlich ist auch eine Benutzer- und Zugriffsverwaltung denkbar, wodurch Be-

nutzer sich authentifizieren müssen, um auf den Service zugreifen zu können.

Demzufolge zeigen sich mehrere Erweiterungsansätze, um die Grundfunktionalität

der aktuellen Anwendung zu erweitern. Folglich zeichnet sich das Potenzial des

BPMN-Generators ab, sich zu einer professionellen Modellierungs-, Generierungs-

und Verwaltungsumgebung von BPMN-Prozessmodellen zu entwickeln.

A Quelltexte

A.1 BPMNGraphGenerator.js

Hinweis: Dieses Listing enthält nur einen Auszug der Quelldatei.

1/**

2* Generates random diagram - graph ( BPMNGraphNode ) and

returns start -nodes . First a ’static ’ framework is

created which

3* is randomly enriched with remaining diagram - elements

4* @param diagramSettings : { noStartEvents , noEndEvents ,

noIntermediateEvents , noTasks , noAndSplits ,

5* noAndJoins , noXorSplits , noXorJoins } is not modified

by this function

6* @return [ BPMNGraphNode ] Start - nodes of the generated

diagram - graph

7*/

8function generateDiagram ( diagramSettings ) {

9let remainingElements = Object . assign ({} ,

diagramSettings ); // clone

10 let graphHeads = generateDiagramFramework (

remainingElements);

11 enrichDiagramFramework ( graphHeads , remainingElements

);

12 return graphHeads ;

13 }

A Quelltexte

15 /**

16 * Generate simple Framework of the diagram containing

Start - and End - Events and Gateways . Construction

follows

17 * certain rules (Join -Phase , Middle -Phase , Split -Phase )

and results in the same diagram - graph when

diagramSettings

18 * stay the same .

19 * @param diagramSettings is modified by this function

20 * @returns [ BPMNGraphNode ] containing the start - nodes

of the framework .

21 */

22 function generateDiagramFramework ( diagramSettings ) {

23 // validation

24 validateDiagramSettings ( diagramSettings );

26 let { joinPhaseGateways , middlePhaseGateways ,

splitPhaseGateways} = getPhaseGateways(

diagramSettings );

28 // handle Join -, Split - and Middle - Phase

29 let { heads , tail } = handleJoinPhase (

joinPhaseGateways , diagramSettings );

30 let splitPhaseHead = handleSplitPhase (

splitPhaseGateways , diagramSettings );

31 handleMiddlePhase (tail , splitPhaseHead ,

middlePhaseGateways , diagramSettings );

33 return heads ;

34 }

36 /**

37 * Validates DiagramSettings considering the

preconditions .

38 * @param diagramSettings settings of the diagram .

A Quelltexte

39 */

40 function validateDiagramSettings ( diagramSettings ) {

41 // correct number of Gateways

42 let valid = ( diagramSettings . noAndJoins -

diagramSettings . noStartEvents ===

43 diagramSettings . noAndSplits - diagramSettings .

noEndEvents ) &&

44 diagramSettings . noXorJoins === diagramSettings .

noXorSplits;

46 // at least one start - and one end - event

47 valid = valid && diagramSettings . noStartEvents > 0

&& diagramSettings . noEndEvents > 0;

49 // enough tasks

50 valid = valid && diagramSettings . noAndJoins -

diagramSettings . noStartEvents + diagramSettings .

noXorJoins < diagramSettings . noTasks

52 if (! valid ) {

53 throw new Error (’ Invalid diagram Settings . ’);

54 }

55 }

57 /**

58 * Takes diagram -graph with basic elements and adds

remaining Tasks and Events randomly

59 * @param heads [ BPMNGraphNode ] Start - Nodes of the

diagram - graph

60 * @param diagramSettings The settings of the diagram

61 */

62 function enrichDiagramFramework (heads , diagramSettings )

{

63 let remainingElements = Object . assign ({} ,

diagramSettings ); // clone

A Quelltexte

64 let diagramNodes = getDiagramNodes ( heads );

65 // filter end events

66 diagramNodes = diagramNodes .filter (( el) => el.type

!== DiagramElementType . END_EVENT );

68 while ( remainingElements . noTasks > 0 ||

remainingElements . noIntermediateEvents > 0) {

69 let insertNode ;

70 if ( remainingElements . noTasks > 0) {

71 insertNode = new Node ( DiagramElementType .

TASK);

72 remainingElements . noTasks --;

73 } else if (remainingElements.

noIntermediateEvents > 0) {

74 insertNode = new Node ( DiagramElementType .

INTERMEDIATE_EVENT );

75 remainingElements . noIntermediateEvents --;

76 }

78 // select random node and random successor of

this node and insert new node between them

79 let randomIndex = Math . floor ( Math . random () *

diagramNodes . length );

80 let randomSuccessorIndex = Math .floor (Math .

random () * diagramNodes [ randomIndex ].

successors . length );

81 insertNodeBetween ( insertNode ,

82 diagramNodes [ randomIndex ],

83 diagramNodes [ randomIndex ]. successors [

randomSuccessorIndex]);

84 }

85 }

Literatur

[1] BPMN-Suite zur Prozessmodellierung - Signavio Process Manager.https:

//www.signavio.com/de/products/process-manager/. 28.10.2020.

[2] BPMN Tool zur Prozessmodellierung.https : / / www . lucidchart . com /

pages/de/beispiele/bpmn-tool. 22.10.2020.

[3] S. Bradshaw und K. Chodorow. MongoDB: The Definitive Guide, 3rd Edition.

O’Reilly Media, Incorporated, 2018. ISBN: 9781491954454. URL:https://

books.google.de/books?id=VS-2tAEACAAJ.

[4] Business Process Model and Notation (BPMN). Object Management Group

(OMG). Jan. 2011.

[5] Diagram Software and Flowchart Maker.https : / / www . diagrams . net.

28.10.2020.

[6] M. Dumas, M. L. Rosa, J. Mendling und H. A. Reijers. Fundamentals of Busi-

ness Process Management. Springer Berlin Heidelberg, 2013.

[7] Jakob Freund und Bernd Rücker. Praxishandbuch BPMN. 5. Aufl. Carl Han-

ser Verlag München, 2017.

[8] J Mendling, H. A. Reijers und W. M. P. van der Aalst. Seven Process Mo-

deling Guidelines (7PMG). Techn. Ber. Humboldt University und Eindhoven

University of Technology, 2009.

[9] Axel Rauschmayer. Speaking JavaScript. 1st. O’Reilly Media, Inc., 2014. ISBN:

1449365035.

[10] Web-based tooling for BPMN, DMN and CMMN.https://bpmn.io. 28.10.2020.

[11] Zeebe - Workflow Engine for Microservices Orchestration.https://zeebe.

io. 28.10.2020.

Literatur

[12] Michael Zimoch, Rüdiger Pryss, Georg Layher, Heiko Neumann, Thomas

Probst, Winfried Schlee und Manfred Reichert. „Utilizing the Capabilities Offe-

red by Eye-Tracking to Foster Novices’ Comprehension of Business Porcess

Models“. In: International Conference on Cognitive Computing (ICCC’2018).

LNCS 10971. Springer, 2018, S. 155–163. URL:http://dbis.eprints.

uni-ulm.de/1616/.

Name: Leon Ahmadi-Moghaddam Matrikelnummer: 1034441

Erklärung

Ich erkläre, dass ich die Arbeit selbständig verfasst und keine anderen als die an-

gegebenen Quellen und Hilfsmittel verwendet habe.

Ulm,den .........................................................................

Leon Ahmadi-Moghaddam

29.10.2020