Leopold Franzens Universität Innsbruck. Highlighting in Prozessmodellen. Institut für Informatik Forschungsgruppe Quality Engineering.

Transkript

1 Leopold Franzens Universität Innsbruck Institut für Informatik Forschungsgruppe Quality Engineering Highlighting in Prozessmodellen Bachelorarbeit (SS2013) Betreuerin: Assoz.-Prof. Priv.-Doz. Dr. Barbara Weber Carmen Vierthaler 22. April 2013

2 Zusammenfassung Mit der Cheetah Experimentierplattform können Experimente zu Geschäftsprozessmodellen durchgeführt werden. Im Zuge dieser Bachelorarbeit wird geprüft, welche Hilfsmittel für Anwender sinnvoll sein können, um Prozessmodelle leichter zu verstehen. Die Cheetah Experimentierplattform wird für den Teilbereich BPMN um ausgewählte Markierungswerkzeuge erweitert, die Anwendern bei Experimenten zur Verfügung gestellt werden können. Ein ausgewähltes Markierungswerkzeug wird im Rahmen eines Versuches mit 15 Teilnehmern verwendet, um zu prüfen, ob die Verständlichkeit von Geschäftsprozessmodellen dadurch positiv beeinflusst wird. Die Erkenntnisse diese Versuches sollen in zukünftige Experimente einfließen, die wesentlich mehr Teilnehmer umfassen. In Kapitel 2 werden verwendete Standards, die bestehende Cheetah Experimentierplattform sowie verwandte Arbeiten vorgestellt. In Kapitel 3 werden Technologien erläutert, die für die Bachelorarbeit genutzt werden. In Kapitel 4 werden die Anforderungen erhoben und in Form von Use Cases beschrieben. In Kapitel 5 wird die Implementierung erläutert. In Kapitel 6 wird die Bedienung der Funktionen aus Anwendersicht erläutert. In Kapitel 7 wird der durchgeführte Versuch mit einer der neuen Funktionen beschrieben. In Kapitel 8 wird die Arbeit zusammengefasst und ein Ausblick auf zukünftige Arbeiten geboten. 2

3 Abstract " Cheetah Experimental Platform" fosters experiments on business process models. One part of the bachelor thesis is the analysis of possible requirements for tools in " Cheetah Experimental Platform" that could be useful to improve model understandability. In particular, the BPMN part of " Cheetah Experimental Platform" will be extended with new tools for marking. One of the marking tools will be used within an experiment with 15 subjects to check if there is a positive influence on model understandability. The results should be used in future experiments with more subjects. Chapter 2 introduces used standards, " Cheetah Experimental Platform" and related work. Chapter 3 covers technologies which are used in this thesis. Chapter 4 focuses on requirement analysis and presents a set of requirements in terms of use cases. Chapter 5 describes the implementation. Chapter 6 provides a user guide on how to work with the functionalities. Chapter 7 describes the conducted experiment, where one of the new functions was put to use. Chapter 8 provides a summary of this thesis and describes future work. 3

4 Danksagung Mein Dank gilt Assoz.-Prof. Priv.-Doz. Dr. Barbara Weber für die außerordentlich gute Betreuung und die angenehme Zusammenarbeit. Des weiteren möchte ich mich bei Dipl.- Ing. Stefan Zugal für die Unterstützung in Bezug auf die technischen Aspekte bedanken. 4

5 Inhaltsverzeichnis 1 Einleitung 10 2 Hintergrund BPMN Cheetah Experimentierplattform Syntax Highlighting Mögliche Syntax Anpassungen Artikel zu Syntax Highlighting Petrinetze Software und verwendete Werkzeuge Eclipse Rich Client Platform Graphical Editing Framework Anforderungsanalyse Vorgehensweise Ideensammlung Thema Markieren Andere Arten der Markierung Paarweises Markieren Suche von Aktivitäten Thema Überblick Benutzerfreundlichkeit Diskussion der Vorschläge Anforderungen Allgemein Use Cases Use Case Beschreibungen Implementierung SW-Architektur der CEP

6 5.2 Erweiterung Allgemeiner Ablauf bei Verwendung der Markierungswerkzeuge Ablauf bei Verwendung des Markierungswerkzeugs für Aktivitäten Ablauf weitere Knoten bzw. Kanten Logik des Markingtools Besonderheiten für Umsetzung Logdaten für Änderungen durch das Markierungswerkzeug Replay-Funktion Benutzerhandbuch CustomTool Programmstart BPMN-Editor Markierungswerkzeug Administrationsanwendung Programmstart Replay durchführen Daten exportieren Ablauf Experimenterstellung bis Analyse Experiment erstellen Experiment durchführen Ergebnisse analysieren Versuch Vorbereitung des Versuchs Ablauf des Versuchs Analyse des Versuchs Demographische Daten Anzahl korrekt beantworteter Fragen Benötigte Zeit und mentaler Aufwand Meinung zu Einsatz des Markierungswerkzeugs Schlussfolgerung Zusammenfassung und Ausblick 68 6

7 Abbildungsverzeichnis 2.1 BPMN-Notation BPMN-Beispiel Beispiel Experiment Ablauf Beispiel Experiment Ablauf Use Cases Allgemeines Sequenzdiagramm Sequenzdiagramm Aktivitäten Codeeingabe Eindeutige Nummer (ID) des Modellingprozesses Modellierungsanwendung Hintergrund ändern Farbe auswählen Hintergrund ändern Hintergrund ändern Linie ändern Linie ändern Linie ändern Linie ändern Linie ändern Linie ändern Linie ändern Menü um Replay zu starten Auswahl für Replay Menü für Replay durchzuführen Menü für Export von Daten Auswahl für Export von Daten Auswahl der Daten für Export

8 7.1 Ablauf des Versuchs Beispiel für eine Verständnisfrage im Versuch Einschätzung der Kenntnisse Korrekte Antworten Durchschnitt, Minimum und Maximum Mentaler Aufwand Durchschnitt, Minimum und Maximum Feedback zu einfacher Bedienbarkeit

9 Tabellenverzeichnis 5.1 Eigenschaften der einzelnen Markierungswerkzeugen Liste der Markierungswerkzeuge Einschätzung eigener Kenntnisse Korrekte Antworten für Gruppe Korrekte Antworten für Gruppe Antwortdauer Gruppe Antwortdauer Gruppe Antwortdauer Gruppe Antwortdauer Gruppe

10 1 Einleitung Geschäftsprozessmodellierung beschäftigt sich mit der graphischen Darstellung von Geschäftsprozessen in zeitlicher bzw. logischer Abfolge. Die sich daraus ergebenden Vorteile sind Zeit- und Kostenreduktion sowie Verbesserung der Kommunikation sowie Agilität. Geschäftsprozessmanagement ist zwar eine etablierte Disziplin, die wachsende Komplexität der Prozessmodelle stellt Anwender jedoch vor immer größere Herausforderungen [4]. Geschäftsprozesse werden häufig mit Hilfe der Business Process Model and Notation (BPMN) modelliert. Die Cheetah Experimentierplattform (CEP) wurde entwickelt, um die Modellverständlichkeit zu untersuchen [7]. Ziel der Untersuchungen ist das Finden von Einflussfaktoren bzw. Möglichkeiten wie Anwender unterstützt werden können, um die Modellverständlichkeit zu verbessern. CEP unterstützt verschiedene Modellierungssprachen wie beispielsweise BPMN. CEP ermöglicht die effiziente Durchführung kontrollierter Experimente. Der Inhalt dieser Arbeit ist die Entwicklung von Zusatzfunktionen für CEP sowie die Durchführung eines Versuchs unter Verwendung einer dieser Zusatzfunktionen. Die Erkenntnisse dieses Versuchs sollen in zukünftige Experimente einfließen. Die restliche Arbeit ist wie folgt gegliedert: In Kapitel 2 werden verwendete Standards, die bestehende Cheetah Experimentierplattform sowie verwandte Arbeiten vorgestellt. In Kapitel 3 werden Technologien erläutert, die für diese Bachelorarbeit genutzt werden. In Kapitel 4 werden die Anforderungen erhoben und in Form von Use Cases beschrieben. In Kapitel 5 wird die Implementierung erläutert. In Kapitel 6 wird die Bedienung der Funktionen aus Anwendersicht erläutert. In Kapitel 7 wird der durchgeführte Versuch mit einer der neuen Funktionen beschrieben. 10

11 In Kapitel 8 wird die Arbeit zusammengefasst und ein Ausblick auf zukünftige Arbeiten geboten. 11

12 2 Hintergrund In diesem Abschnitt werden verschiedene Themen behandelt, die als Grundlage für die Bachelorarbeit dienen. Inhalt dieser Arbeit ist die Erweiterung der Cheetah Experimentierplattform für BPMN, daher wird auf BPMN (siehe Abschnitt 2.1) sowie den Zweck von CEP und deren Funktionen eingegangen (siehe Abschnitt 2.2). Des Weiteren werden bereits durchgeführte Arbeiten im Zusammenhang mit Highlighting vorgestellt (siehe Abschnitt 2.3). 2.1 BPMN Über Geschäftsprozesse können Unternehmen ihre Geschäftsabläufe darstellen. Diese Prozesse können entsprechend der Definition von Business Process Model and Notation (BPMN) erfolgen [1]. Es handelt sich bei BPMN um eine Graphnotation. Im Graph gibt es Knoten und Kanten. Zu den Knoten zählen beispielsweise Aktivitäten, Startund Endereignis und Gateways, die Pfeile (Sequence Flow) zählen zu den Kanten. Diese Elemente werden in der Abbildung 2.1 graphisch dargestellt und deren Funktionsweise nun erläutert. Die verwendeten Symbole sind in Abbildung 2.1 dargestellt und werden im Folgenden erläutert: Jeder Prozess beginnt mit einem Startereignis (Startevent). Die Pfeile (Sequence Flow) definieren die Flussrichtung und verbinden die einzelnen Objekte. Eine andere Bezeichnung für Pfeile sind Kanten. Jede Aktivität (Task) hat eine Beschriftung, welche festlegt, welche Aufgabe innerhalb dieses Objektes ausgeführt wird. Um Abläufe realisieren zu können, die nicht nur sequentiell abgearbeitet werden, benötigt man Verzweigungen (sogenannte Gateways). Gateways treten immer paarweise auf. Das Split -Gateway führt Verzweigungen ein und das Join -Gateway führt diese wieder zusammen. 12

13 Abbildung 2.1: BPMN-Notation Abbildung 2.2: BPMN-Beispiel Beim AND-Gateway handelt es sich um ein paralleles Gateway. Alle Kanten, deren Flussrichtung sich vom Split -Gateway entfernen, werden durchlaufen. D.h. alle Aktivitäten, die folgen, werden parallel ausgeführt (d.h. in beliebiger Reihenfolge). Beim XOR-Gateway handelt es sich um eine exklusive oder -Funktion. Das bedeutet, dass nur eine der Kanten, deren Flussrichtung sich vom Split -XOR-Gateway entfernen, durchlaufen wird. Der weitere Verlauf hängt von der Evaluation der Transitionsbedingung ab. Der Prozess endet immer beim Endknoten (Endevent). Diese Punkte werden anhand eines einfachen Beispiels erläutert. In Abbildung 2.2 ist ein Beispiel eines einfachen Geschäftsprozessmodells in BPMN abgebildet. Der Prozess beginnt beim Startknoten und die Aktivität Ware bestellen wird zuerst ausgeführt, anschließend wird die Aktivität Bezahlart wählen ausgeführt. Entsprechend der Flussrichtung wird das Split- XOR-Gateway ausgeführt. Aufgrund des XOR- Split -Gateways wird nur eine der Kanten in Flussrichtung genützt und zwar abhängig von der Evaluation der Transitionsbedingung. In diesem einfachen Fall gibt es nur 13

14 Abbildung 2.3: Beispiel Experiment Ablauf 1 zwei Möglichkeiten. Wurde eine Überweisung gewählt, wird anschließend die Aktivität Mittels Überweisung bezahlen ausgeführt. Andernfalls wird die Aktivität Mit Kreditkarte bezahlen ausgeführt. Nach dem Join -XOR-Gateway ist keine weitere Aktivität vorgesehen und der Prozess wird mit dem Endknoten beendet. 2.2 Cheetah Experimentierplattform Die Cheetah Experimentierplattform (CEP) wurde entwickelt, um empirische Forschung im Zusammenhang von Geschäftsprozessmodellierung effizient durchführen zu können [6]. Die Experimente sollen dabei effektiv, effizient und kontrolliert durchführbar sein. Die CEP bietet Vorteile in den Phasen Design, Durchführung und Analyse der Experimente. In der Designphase werden die verwendbaren Objekte, der genaue Ablauf von Aufgaben, Tutorials, Befragungen sowie die möglichen Prozessmodellierungswerkzeuge für den Anwender im Rahmen einer Konfiguration festgelegt. In der Ausführungsphase wird der Teilnehmer des Experiments insbesondere durch die Ablaufsteuerung unterstützt und so wird großteils verhindert, dass für die Experimentauswertung unbrauchbare Ergebnisse entstehen. In der Analysephase können die gesammelten Daten effektiv ausgewertet werden. Zusätzlich sind im Gegensatz zu papierbasierenden Experimenten detaillierte Informationen zum zeitlichen Ablauf verfügbar. Die Informationen sind so detailliert, dass die einzelnen Schritte des Anwenders Schritt für Schritt nachvollzogen werden können. Experimente lassen sich aus verschiedenen Komponenten zusammensetzen. Mögliche Komponenten sind eine Umfrage zur Erfahrung der Probanden, ein Tutorial als Vorbereitung für die Teilnehmer auf das Experiment, eine Möglichkeit einer Rückmeldung zum Experiment in Freitext-Form sowie die eigentliche Aufgabenstellung des Experiments an den Probanden. Dem Teilnehmer können entweder Fragen zu bestehenden Modellen oder eine Modellierungsaufgabe gestellt werden. In Abbildung 2.3 ist beispielhaft dargestellt, wie ein Experiment für den Teilnehmer aussehen kann. In diesem Fall werden dem Teilnehmer Fragen zu seiner Erfahrung gestellt. Anschließend wird die Modellverständlichkeit abgeprüft, indem zu einem bestehen- 14

15 Abbildung 2.4: Beispiel Experiment Ablauf 2 den Modell Fragen gestellt werden. Der Teilnehmer beantwortet diese Fragen mit Wahr, Falsch oder Weiß nicht. Am Ende kann der Anwender eine Rückmeldung zum Experiment geben. Der in Abbildung 2.4 dargestellte Ablauf beginnt ebenfalls mit einem Fragebogen zur Erfahrung des Anwenders, anschließend wird der Teilnehmer über ein Tutorial geschult. Da es sich um ein Modellierungsexperiment handelt, wird der Teilnehmer darauf trainiert, wie Start- und Endknoten, Aktivitäten oder Gateways anzulegen und mit Kanten zu verbinden sind. Es könnten auch die Anwendungen weiterer Werkzeuge geschult werden, die der Anwender nutzen soll. Am Ende besteht die Möglichkeit, eine Rückmeldung zum Experiment zu geben. CEP bietet die Möglichkeit, BPMN- oder deklarative Prozessmodelle zu verwenden. Die Interaktionen eines Probanden mit der Modellierungsumgebung können unabhängig vom verwendeten Prozessmodell nachvollzogen werden. Die Replay-Funktion zeigt die Reihenfolge, in der beispielsweise BPMN Start- und Endkonten, Gateways, Aktivitäten oder Kanten hinzugefügt wurden. Zusätzlich sind auch Aktionen wie das Verschieben, Umbenennen oder Löschen von Objekten erkennbar. Diese Daten können auch ausgewertet werden und ermöglichen so die Analyse umfangreicher Experimente. 2.3 Syntax Highlighting Das Thema Syntax Highlighting wurde in verschiedenen Arbeiten behandelt. Eine theoretische Aufzählung sowie eine praktische Umsetzung in Petrinetzen werden in diesem Abschnitt beschrieben Mögliche Syntax Anpassungen Der erhöhten Komplexität von Geschäftsprozessmodellen kann beispielsweise mit visuellen Repräsentation des Models begegnet werden. Der Artikel behandelt verschiedene theoretischen Möglichkeiten der visuellen Repräsentation. Dazu zählen Layout Guidance, Highlight, Representation und Naming Guidance [4]. 15

16 2.3.2 Artikel zu Syntax Highlighting Petrinetze Der Artikel Syntax Highlighting in Business Process Models [8] beschäftigt sich mit Syntax Highlighting in Prozessmodellen. Zur Verbesserung der Verständlichkeit werden zusammengehörende Transitionen farblich gleich markiert. Die Highlighting-Funktion wird im Rahmen eines Experiments mit Experten sowie Neulingen getestet. Insbesondere wird untersucht, wie sich das Vorhandensein der Highlighting-Funktion auf die Verständlichkeit der Modelle (gemessen als Anzahl richtiger Antworten und Antwortgeschwindigkeit) auswirkt. Die Daten von Experten und Neulingen werden getrennt ausgewertet. Die Hypothese, dass Neulinge durch das Hilfsmittel eine größere Anzahl an Fragen richtig beantworten, hat sich bestätigt, die dafür benötigte Zeit hat sich jedoch nicht wesentlich verbessert. Der Unterschied fällt bei Experten wie erwartet geringer aus, da die bereits vorhandenen Fähigkeiten, Modelle zu lesen, verbessert werden, jedoch nicht in gleichem Ausmaß wie bei Neulingen. Zudem wird die These geäußert, dass die Unterschiede bei komplexeren Modellen möglicherweise größer ausfallen würden. Das beschriebene Highlighting beschränkt sich auf ein bestimmtes Anwendungsfeld, der Anwender kann nur zwischen Highlighting der Transitionen oder Deaktivierung unterscheiden und keinerlei sonstigen Einfluss nehmen. In dieser Bachelorarbeit soll der Fokus auf der Arbeitsweise des Anwenders liegen und ihm entsprechende Freiheiten bieten. 16

17 3 Software und verwendete Werkzeuge In diesem Abschnitt werden die verwendeten Technologien beschrieben. Da CEP auf Eclipse Rich Client Platform (RCP) aufbaut, wird RCP in Abschnitt 3.1 behandelt. Der graphische Editor von CEP basiert auf Graphical Editing Framework GEF, welches in Abschnitt 3.2 vorgestellt wird. 3.1 Eclipse Rich Client Platform Eclipse Rich Client Plattform (RCP) bietet ein Grundgerüst auf dessen Basis eigene Anwendungen entwickelt werden können [3]. Die Funktionalitäten lassen sich in Plug-ins getrennt entwickeln und in einer Anwendung in der gewünschten Konstellation zusammenfassen. Zielplattform Eclipse RCP besteht aus diversen Plug-ins. Welche Plug-ins zur Verfügung stehen, wird über die Zielplattform (Target Platform) definiert. Diese Zielplattform kann die Eclipse IDE selbst sein oder von dieser Standard-Einstellung abweichen. Über eine abweichende Zielplattform kann die Auswahl an verfügbaren Plug-ins eingeschränkt werden. Dadurch arbeiten alle Entwickler mit derselben Version und demselben Funktionsumfang und zwar unabhängig von der verwendeten IDE-Version. 3.2 Graphical Editing Framework Das Eclipse Projekt Graphical Editing Framework (GEF) stellt das gleichnamige Framework GEF sowie Draw2D zur Verfügung [2]. Draw2D Draw2D ist ein schlankes Zeichen-Framework, um Informationen über SWT canvas graphisch darzustellen. Es werden jedoch keinerlei Interaktionen zur Verfügung gestellt. 17

18 GEF GEF baut auf den Draw2D Funktionen auf. Durch GEF lassen sich selbst definierbare Modelle graphisch darstellen, wobei die Repräsentation jeder Modellkomponente unter Verwendung von Draw2D definiert werden kann. Die Reaktion auf Interaktionen des Anwenders können vielfältig gestaltet werden. GEF ist nach dem Schema des Model-View-Controller-Patterns (MVC) aufgebaut. MVC sieht eine Modell-, eine View- und eine Controller-Komponente vor. Das Modell im MVC-Schema enthält Daten, welche dauerhaft gespeichert werden sowie die Geschäftslogik. Bei Modell-Objekten können Listener registriert werden, die bei Veränderungen im Modell verständigt werden. Die View des MVC-Schemas ist verantwortlich für das Darstellung und die Weitergabe von Events an registrierte Listener. Der Controller des MVC-Schemas verbindet das Modell mit der View und aktualisiert die View bei Änderungen des Modells. Außerdem ist er verantwortlich für das Aktualisieren des Modells, falls von der View generierte Events beim Controller eingehen. 18

19 4 Anforderungsanalyse 4.1 Vorgehensweise Die Anforderungserhebung wurde mit einer Sammlung möglicher Ideen begonnen. Im Mittelpunkt standen dabei Hilfsmittel, die dem Anwender das Verstehen und Beantworten von Fragen zu Geschäftsprozessmodellen erleichtern könnten. Geplant ist eine Erweiterung von CEP in Bezug auf BPMN (siehe Abschnitt 2.1), daher wurden entsprechende Experimente verwendet. Diese Ideen wurden strukturiert und diskutiert. Darauf aufbauend erfolgte die Definition der Use Cases. 4.2 Ideensammlung In Zusammenarbeit mit fünf Personen erfolgte die Ideensammlung für die Erweiterung von CEP. Diesen Personen wurde je ein Experiment in Papierform und ein Experiment in elektronischer Form zur Verfügung gestellt. Der Auftrag an die Teilnehmer lautete, Ideen zu sammeln, die für die Bearbeitung der Fragestellungen hilfreich sein könnten. Zudem wurden sie darauf aufmerksam gemacht, auf Hilfsmittel zu achten, die sie für die Beantwortung der Fragen intuitiv benutzen. Beispielsweise, ob sie mit dem Finger oder mit einem Kugelschreiber ein Objekt markieren. Bei den gesammelten Ideen sollten die Teilnehmer keine Filterung vorab vornehmen, um die Bewertung nicht vorwegzunehmen. Das Experiment in Papierform wurde anhand der Arbeit Imperative versus Declarative Process Modeling Languages: An Empirical Investigation [5] erstellt. Zum Zweck der Ideensammlung wurden die dort beschriebenen imperativen Geschäftsprozessmodelle und Fragen herangezogen. Beim verwendeten elektronischen Experiment handelte es sich um ein CEP-Experiment, welches in der wissenschaftlichen Arbeit Assessing the Impact of Hierarchy on Model Understandability - A Cognitive Perspective [10] verwendet wurde. Das Experiment ist online unter [9] verfügbar. Dieses Experiment benutzt ein hierarchisches Geschäftsprozessmodell. Bei hierarchischen Prozessmodellen werden Teile eines Prozesses als Subprozess dargestellt. Der Anwender kann sich Subprozesse sowie die übergeordneten Prozesse in CEP anzeigen lassen. Die Ergebnisse waren entsprechend 19

20 der offenen Fragestellung breit gefächert. Das Resultat der Ideensammlung wurde in Gruppen zusammengefasst und wird nachfolgend beschrieben Thema Markieren Das Thema Markieren von Objekten war ein häufig gewünschtes Thema. Es gibt dabei unterschiedlichste Ansätze. Aktivitäten und Gateways manuell markieren Wird eine Aktivität mit der Maus ausgewählt, soll dieses Objekt markiert werden. Diese Funktion soll auch für AND- und XOR-Gateways anwendbar sein. Dadurch kann der Anwender die für ihn relevanten Objekte hervorheben. Beim manuellen Markieren hat der Anwender die Freiheit, entsprechend seiner Vorlieben Markierungen durchzuführen. Verschiedene Ideen, wie eine Markierung aussehen könnte, wurden in diesem Abschnitt zusammengefasst. Markieren von Kanten Kanten sollen mit der Maus ausgewählt und dadurch markiert werden. Durch diese Markierungen kann der Anwender beispielsweise einen Pfad hervorheben oder bei einem AND-Gateway alle relevanten Kanten, die bereits abgearbeitet wurden, hervorheben. Ansonsten hängt der Einsatz des Hilfsmittels vom Anwender ab. Initiale Markierung AND- oder XOR-Gateways sollen initial unterschiedlich markiert werden, um sie besser unterscheiden zu können. Im Zuge der beiden Experimente stellte sich heraus, dass es wiederholt zu Verwechslungen der verschiedenen Typen von Gateways kam. Aus diesem Grund besteht der Wunsch einer besseren Unterscheidbarkeit der Gateways. Beispielsweise könnte für einen der Gateway-Typen eine andere Hintergrundfarbe verwendet werden. Der Anwender hat jedoch keinen Einfluss auf die Funktion, da immer alle Gateways vom gleichen Typ gleich behandelt werden und die Art der Markierung vorab definiert wird. Vorstellbar wäre es auch, die Funktion für den Anwender konfigurierbar zu gestalten und ihn die Art der Markierung selbst wählen zu lassen. Dies ändert jedoch nichts daran, dass alle Gateways gleichen Typs gleich behandelt werden. Varianten für die Umsetzung von Markierungen auf unterschiedliche Arten erfolgen. Die Markierung von Objekten könnte Hintergrund: Der Hintergrund einer Aktivität bzw. [eines Gateways kann geändert werden. Abhängig davon, ob ein Objekt hervorgehoben werden soll, oder alle Objekte eines bestimmten Typs markiert werden, kann die Farbwahl erfolgen und gut sichtbare oder dezente Farben verwendet werden. 20

21 Linienstärke: Die Linien der Objekte bzw. der Kanten könnten durch das Markieren verbreitert werden. Dies könnte für den Ausdruck von Unterlagen von Vorteil sein. Linie strichliert: Der Rahmen eines Objektes bzw. einer Kante könnte beim Markieren von durchgängigen Linien auf strichlierte Linie geändert werden. Linie farbig: Ähnlich wie das Ändern der Farbe des Hintergrundes könnte auch die Farbe der Linie geändert werden Andere Arten der Markierung Ein anderer Zugang, wie Hilfsmittel Anwender unterstützen könnten, ist die Idee eines Tokens sowie eines manuellen Schleifenzählers. Token: Anstatt Aktivitäten und Gateways oder Kanten zu markieren, könnte die für den Anwender relevante Position im Geschäftsprozessmodell mittels Tokens markiert werden. Dabei könnte es sich um einen Kreis mit schwarzem Hintergrund handeln, welcher nicht zum Modell gehört und vom Anwender verschoben werden kann und so immer die aktuelle Position anzeigt. Schleifenzähler: Wird ein Ablauf durchdacht und besteht die Notwendigkeit denselben Abschnitt mehrfach zu durchlaufen, könnte der Anwender die Anzahl der Durchläufe markieren. Dafür könnte ein Zähler zur Verfügung stehen, der bei Benutzereingabe hochgezählt wird. Beispielsweise könnt der Zähler auf ein Maus- Ereignis reagieren, wenn er angeklickt wird Paarweises Markieren Falls es Gateways in einem Geschäftsprozessmodell gibt, ist das Wissen, welche Gateways zusammengehören, im Normalfall wichtig, um das Geschäftsprozessmodell richtig zu verstehen. Je nach Größe des Modells kann sich das Finden dieser Gateway-Paare unterschiedlich aufwändig gestalten. Funktionen, die das Auffinden erleichtern könnten, sind folgende: Gateways manuell markieren Der Anwender verwendet eine Funktion, um ausgewählte Gateways zu markieren. Dies wurde bereits in Abschnitt behandelt. Wünschenswert wäre es, die Hintergrundfarbe selbst wählen zu können, um verschiedene Gateway-Paare unterschiedlich zu kennzeichnen. 21

22 Gateways teil-automatisiert markieren Das Suchen des zugehörigen Gateways kann aufwändig sein und das Ergebnis einer manuellen Suche könnte bei unübersichtlichen bzw. großen Geschäftsprozessmodellen auch zum falschen Ergebnis führen. Daher wäre eine Funktion wünschenswert, die beim Markieren eines Gateways das zugehörige Gegenstück ebenfalls markiert. Der Anwender steuert dabei, welches Gateway-Paar markiert werden soll. Automatisiert Gateways markieren Anstatt jedes Gateway-Paar selbst zu markieren, könnten die vorhandenen Gateways jeweils paarweise in einer eigenen Farbe markiert werden. Der Anwender hat dabei keinen Einfluss auf die Funktion Suche von Aktivitäten Das Finden der relevanten Aktivitäten war ein wesentlicher zeitlicher Aspekt, um die Fragen im elektronischen Experiment zu beantworten. Daher wären folgende Funktionen wünschenswert: Suchfunktion Aktivitäten sollen anhand ihrer Bezeichnung über eine Suchfunktion gesucht werden können und alle relevanten Aktivitäten hervorgehoben werden. Suche gleicher Aktivitäten gleichen Aktivitäten hervorgehoben werden. Wird eine Aktivität vom Anwender ausgewählt, sollen alle Automatisch gleiche Aktivitäten markieren mit gleicher Farbe markiert werden Gleiche Aktivitäten sollen initial bereits Thema Überblick Im Rahmen des elektronisch durchgeführten Experiments mit dem größeren Geschäftsprozesses wären Funktionen, die den Überblick verbessern würden, wünschenswert. Ansicht verkleinern / vergrößern Um einen besseren Überblick zu bekommen, wäre eine Funktion von Vorteil, mit der man die Ansicht verkleinern und wieder vergrößern kann. Insbesondere, wenn diese Funktion mit einer Markierungsfunktion kombiniert werden würde, um die Position der relevanten Objekte auch bei verringertem Zoom gut erkennen zu können. 22

23 Parallele Betrachtung Um den Prozess an verschiedenen Positionen betrachten zu können, wäre ein weiteres Fenster von Vorteil. Darin könnten auch Subprozesse dargestellt werden. Überblicksfunktion Um einen besseren Überblick zu erhalten, wäre eine Funktion, mit der man auf eine Ansicht mit stark verkleinerten Objekten wechseln könnte, von Vorteil. Der Unterschied zum Zoom ist, dass die Bezeichnungen der Aktivitäten in dieser Ansicht nicht relevant sind. Eine Kombination mit einer Markierungsfunktion erscheint ebenfalls sinnvoll. Subprozesse einblenden Beim durchgeführten Experiment handelte es sich um ein hierarchisches Geschäftsprozessmodell. Bei hierarchischen Prozessmodellen werden Prozesse modulisiert und als eigene Subprozess dargestellt. Der Anwender kann sich die Subprozese einzeln sowie die übergeordneten Prozsse anzeigen lassen. Das Anzeigen von Subprozessen im übergeordneten Prozess bzw. das Wieder-Ausblenden wäre wünschenswert Benutzerfreundlichkeit Im elektronischen Experiment stehen keine Funktionen für Zurück zur vorherigen Frage bzw. für das Beenden der Software zur Verfügung. Aus Anwendersicht wäre das praktisch. 4.3 Diskussion der Vorschläge Die Vorschläge wurden diskutiert und dabei stellte sich heraus, dass für die Experimente möglichst einfache Funktionen wichtig sind. Diese sollen leicht erlernbar sein, beispielsweise über Tutorials, um so ein eventuell vorhandenes Ungleichgewicht an Erfahrungen im Teilnehmerfeld auszugleichen. Es soll verhindert werden, dass es durch eine bessere Nutzung von Funktionen zu Verzerrungen des Ergebnisses kommt und so weitere Einflussfaktoren berücksichtigt werden müssten. Zudem soll der Anwender das Experiment im Normalfall nicht abbrechen können, nicht zurückgehen und bereits gegebene Antworten nicht revidieren können. Dadurch fallen Vorschläge rund um das Finden von Aktivitäten, Überblicksfunktionen und Benutzerfreundlichkeit weg. Der Fokus soll auf dem Thema Markieren liegen, dem Anwender soll möglichst viel Freiheit gegeben werden und die Funktionen sollen sehr einfach zu bedienen sein. Von Vorschlägen zu teil- oder automatisierten paarweisen Markierungen wird zum jetzigen Zeitpunkt Abstand genommen, da der Anwender im Vorfeld 23

24 nicht eingeschränkt werden soll. In der Arbeit wird im Folgenden das Thema Markieren weiterverfolgt und im Rahmen der Use Cases genauer spezifiziert. 4.4 Anforderungen Die Anforderungen, welche im Rahmen der Bachelorarbeit umgesetzt werden sollen, werden in Form von Use Cases und Use Case Beschreibungen spezifiziert sowie durch allgemeine Vorgaben festgelegt Allgemein Die bestehende CEP wird erweitert und die zu entwickelnden Hilfsmittel integriert. Der Anwender wird wie gewohnt diese neuen Funktionen über das CEP Menü auswählen. Die Funktionen sollen intuitiv umgesetzt werden, damit der Schulungsaufwand für Experimente gering ausfällt und diese gut vom Teilnehmer angenommen werden. 24

25 Abbildung 4.1: Use Cases 25

26 4.4.2 Use Cases Use Case Beschreibungen Akteur Kurzbeschreibung Vorbedingung Basisablauf Nachbedingung Alternativer Ablauf Hintergrund eines Objektes anpassen Experiment-Teilnehmer Die Hintergrundfarbe eines Objektes wird geändert. Werkzeug und Objekt wurde ausgewählt, wobei nur Knoten und keine Kanten erlaubt sind. Für das ausgewählte Objekt wird die Hintergrundfarbe geändert. Wird das Werkzeug das erste Mal auf das Objekt angewandt, wird die Hintergrundfarbe auf die Werkzeug-Farbe geändert. Wird das Werkzeug ein zweites Mal angewandt, wird die Hintergrundfarbe auf die Originalfarbe zurückgesetzt. Dadurch wird eine Togglefunktion umgesetzt. Die Hintergrundfarbe wurde verändert und eventuell bereits geänderte Linien-Eigenschaften bleiben davon unberührt. Jeder Vorgang wird als Grundlage für die Replay-Funktion mitgeloggt. Falls der Teilnehmer das Werkzeug mit eigener Farbauswahl verwendet, bestimmt der Teilnehmer die Farbe selbst. Wendet der Anwender verschiedene Hintergrund-Werkzeuge auf dasselbe Objekt an, wird der Hintergrund mit der neuen Farbe überschrieben. 26

27 Linien bzw. Rahmen eines Objektes anpassen Akteur Experiment-Teilnehmer Kurzbeschreibung Die Linieneigenschaften eines Objektes werden geändert. Vorbedingung Werkzeug und Objekt wurde ausgewählt Basisablauf Für das ausgewählte Objekt werden die Linieneigenschaften geändert. Zu den Linieneigenschaften zählen die Farbe, Stärke und der Stil. Unter Stil versteht man beispielsweise eine durchgängige oder strichlierte Linie. Durch die Auswahl des Werkzeugs können die Linieneigenschaften einzeln oder Kombinationen davon geändert werden. Wird das Werkzeug das erste Mal auf das Objekt angewandt, werden die Linieneigenschaften auf die Werkzeug- Linieneigenschaften geändert. Wird das Werkzeug ein zweites Mal angewandt, werden die Linieneigenschaften, welche durch das Werkzeug verändert wurden, auf die Originaleigenschaften zurückgesetzt. Dadurch wird eine Togglefunktion umgesetzt. Nachbedingung Die Linieneigenschaften wurden verändert und zwar nur jene, die das konkrete Werkzeug beeinflusst. Diese Funktion hat keine Auswirkung auf die Hintergrundfarbe, d.h. es kann sowohl der Hintergrund als auch die Linieneigenschaften mit den entsprechenden Werkzeug verändert werden. Jeder Vorgang wird als Grundlage für die Replay-Funktion mitgeloggt. Alternativer Ablauf Falls ein Teilnehmer das Werkzeug mit eigener Farbauswahl verwendet, bestimmt der Proband die Farbe selbst. Werden verschiedene Werkzeuge zu Linieneigenschaften auf dasselbe Objekt angewandt, werden nur die Eigenschaften des Werkzeugs überschrieben und etwaige andere Eigenschaften bleiben davon unberührt. Dies gilt sowohl für das Setzen der Werkzeug-Linieneigenschaften als auch das Zurücksetzen auf die Originalwerte. 27

28 Akteur Kurzbeschreibung Vorbedingung Basisablauf Nachbedingung Aktivität markieren/demarkieren Experiment-Teilnehmer Eine Aktivität wird markiert bzw. demarkiert. Aktivität ist vorhanden. Der Teilnehmer wählt ein Werkzeug und anschließend eine Aktivität aus. Durch die Wahl des Werkzeugs wird festgelegt, ob der Hintergrund oder die Rahmenlinie geändert wird. Der Hintergrund oder die Linieneigenschaften der Aktivität wurden verändert. Akteur Kurzbeschreibung Vorbedingung Basisablauf Nachbedingung Startknoten markieren/demarkieren Experiment-Teilnehmer Startknoten wird markiert bzw. demarkiert. Startknoten ist vorhanden. Der Teilnehmer wählt ein Werkzeug und anschließend den Startknoten aus. Durch die Wahl des Werkzeugs wird festgelegt, ob der Hintergrund oder die Rahmenlinie geändert wird. Der Hintergrund oder die Linieneigenschaften des Startknotens wurden verändert. Akteur Kurzbeschreibung Vorbedingung Basisablauf Nachbedingung Endknoten markieren/demarkieren Experiment-Teilnehmer Endknoten wird markiert bzw. demarkiert. Endknoten ist vorhanden. Der Teilnehmer wählt ein Werkzeug und anschließend den Endknoten aus. Durch die Wahl des Werkzeugs wird festgelegt, ob der Hintergrund oder die Rahmenlinie geändert wird. Der Hintergrund oder die Linieneigenschaften des Endknotens wurden verändert. 28

29 AND-Gateway markieren/demarkieren Akteur Experiment-Teilnehmer Kurzbeschreibung Ein AND-Gateway wird markiert bzw. demarkiert. Vorbedingung AND-Gateway ist vorhanden. Basisablauf Der Teilnehmer wählt ein Werkzeug und anschließend das AND- Gateway aus. Durch die Wahl des Werkzeugs wird festgelegt, ob der Hintergrund oder die Rahmenlinie geändert wird. Nachbedingung Der Hintergrund oder die Linieneigenschaften des AND- Gateways wurden verändert. XOR-Gateway markieren/demarkieren Akteur Experiment-Teilnehmer Kurzbeschreibung Ein XOR-Gateway wird markiert bzw. demarkiert Vorbedingung XOR-Gateway ist vorhanden. Basisablauf Der Teilnehmer wählt ein Werkzeug und anschließend das XOR- Gateway aus. Durch die Wahl des Werkzeugs wird festgelegt, ob der Hintergrund oder die Rahmenlinie geändert wird. Nachbedingung Der Hintergrund oder die Linieneigenschaften des XOR- Gateways wurden verändert. Akteur Kurzbeschreibung Vorbedingung Basisablauf Nachbedingung Kante markieren/demarkieren Experiment-Teilnehmer Eine Kante wird markiert bzw. demarkiert. Kante ist vorhanden. Der Teilnehmer wählt ein Werkzeug und anschließend eine Kante aus. Die Eigenschaften der Linie werden geändert. Die Linieneigenschaften der Kante wurde verändert. 29

30 Akteur Kurzbeschreibung Vorbedingung Basisablauf Nachbedingung Replay durchführen Experiment-Designer Die durchgeführten Aktivitäten können über das Replay abgespielt werden. Gespeichertes CEP Experiment ist vorhanden. CEP bietet bereits die Möglichkeit, in einer eigenen Anwendung gespeicherte Experimente aufzurufen und die Erstellung eines Modells Schritt für Schritt abspielen zu lassen (siehe Abschnitt 6.2). Diese Funktion ist zu erweitern, damit die Markierungsvorgänge ebenfalls dargestellt werden. Alle Loginformationen zu Markierungsvorgängen müssen angezeigt und alle Replay Funktionen wie Play, Schritt nach vorne bzw. zurück, Undo, etc. verwendbar sein. Akteur Kurzbeschreibung Vorbedingung Basisablauf Nachbedingung Undo-Funktion ausführen Experiment-Designer Jeder der Markierungsbefehle kann zurückgesetzt werden Gespeichertes CEP Experiment ist vorhanden. In jedem Befehl ist eine Undo-Funktion vorzusehen, die den Befehl aufhebt und den vorherigen Zustand wiederherstellt. Vorheriger Zustand muss wiederhergestellt sein. Die umgesetzten Funktionen sollen folgende Merkmale aufweisen: Die neuen Funktionen sollen in das bestehende Menü integriert werden. Die Funktionen sollen einzeln in der Konfiguration für das Experiment aktivierbar sein. Die neuen Funktion sollen abspielbar sein (Replay-fähig) (siehe Abschnitt 6.2.2) Die neuen Funktion sollen rückgängig gemacht werden können (Undo-fähig) Die Markierungsfunktionen für das BPMN-Modell sollen folgende Funktionalitäten ermöglichen: Der Hintergrund soll für alle BPMN-Knoten wie Aktivitäten, AND- und XOR- Gateways und Start- und Endknoten änderbar sein. 30

31 Es soll die Möglichkeit geben, für die Farbe des geänderten Hintergrundes eine voreingestellte oder vom Anwender selbst gewählte Farbe zu verwenden. Die Rahmeneigenschaften bzw. Linieneigenschaften sollen für alle Knoten sowie Kanten änderbar sein. Zu diesen Eigenschaften zählen die Farbe, der Stil sowie die Strichstärke der Rahmen bzw. Linien. Analog zur Konfigurierbarkeit der Hintergrundfarbe soll auch die Rahmenfarbe auf eine voreingestellte oder vom Anwender ausgewählte Farbe gesetzt werden können. Der Stil soll auf eine strichlierte Linie änderbar sein. Die Stärke der Rahmenlinie soll änderbar sein und dadurch die normale Strichstärke auf eine breitere geändert werden. Verschiedene Rahmeneigenschaften sollen gleichzeitig geändert werden können und so beispielsweise die Farbe und Strichstärke mittels einem Markierungswerkzeug geändert werden. Aufgrund des Einsatzes von CEP in Experimenten mit mehr als 100 Teilnehmern und den umfangreichen bestehenden Zusatzfunktionen sollen die Erweiterungen so weit als möglich als Plug-in umgesetzt werden und es sollen möglichst wenig Erweiterungen der zentralen Funktionen erfolgen. 31

32 5 Implementierung Im Folgenden wird CEP und die zugehörigen Abläufe beschrieben, soweit dies für die Erläuterung der durchgeführten Implementierungen relevant ist und zum Verständnis beiträgt. 5.1 SW-Architektur der CEP Die bestehende CEP wird lokal als Desktop Anwendung ausgeführt. Die Daten eines Experiments oder einer Prozessmodellierung können in XML-Dateien zwischengespeichert und am Ende des Experiments in eine SQL Datenbank transferiert werden. Alternativ lassen sich die Daten direkt in die Datenbank speichern. CEP nutzt RCP (siehe Abschnitt 3.1), das GEF Framework (siehe Abschnitt 3.2) sowie Bibliotheken und Frameworks von Drittanbietern. CEP wurde für verschiedene Anwendungen erweitert, die Pakete, welche für diese Bachelorarbeit notwendig sind, lauten: com.mysql.jdbc ist eine Bibliothek, die Funktionen für die Kommunikation mit mysql Datenbanken bietet. com.thoughtworks.xstream ist Framework, das Funktionen zur Serialisierung von Java Objekten bietet, die als XML-Dateien persistent gespeichert und wieder eingelesen werden können. org.apache.commons.math ist eine Bibliothek, die mathematische Funktionen zur Verfügung stellt. org.cheetahplatform.common ist ein CEP Paket, das allgemeine Funktionen zu User Interface, Logging oder Datumsfunktionen zur Verfügung stellt. org.cheetahplatform.core ist ein CEP Paket, das verschiedene Services wie die Generierung eindeutiger IDs sowie diverse Interfaces zur Verfügung stellt. org.cheetahplatform.modeler ist ein CEP Paket, dass das Modell sowie den Großteil der Programmlogik von CEP enthält. 32

33 org.cheetahplatform.modeler.admin.basic ist ein CEP Paket, das Replay-Funktionen sowie Analysefunktionalitäten enthält. org.cheetahplatform.survey ist ein CEP Paket das die Durchführung von Umfragen im Rahmen von Experimenten ermöglicht. 5.2 Erweiterung Allgemeiner Ablauf bei Verwendung der Markierungswerkzeuge Das Sequenzdiagramm in Abbildung 5.1 beschreibt die Interaktion der einzelnen Objekte, wenn eines der Markierungswerkzeuge vom Anwender verwendet wird. Der Fokus dieser Darstellung liegt auf den Aspekten, die für die Implementierung und das Verständnis relevant sind, ohne Anspruch das GEF Framework (siehe Abschnitt 3.2) im Detail zu erläutern. Wird das Markierungswerkzeug auf verschiedene BPMN-Objekte (siehe Abschnitt 2.1) angewandt, läuft die Interaktion mit derselben Logik ab, jedoch sind Objekte anderen Typs betroffen. Um einen besseren Überblick zu bieten, wird zuerst ein allgemeines Sequenzdiagramm vorgestellt. Im Anschluss daran werden die Besonderheiten behandelt, die vom jeweiligen BPMN-Objekt abhängen, auf welches das Markierungswerkzeug angewandt wird. Im Sequenzdiagramm in Abbildung 5.1 werden neue Begriffe verwendet, die vorab erläutert werden. Figure: Objekte von diesem Typ werden in der graphischen Benutzeroberfläche, in der View, verwendet. Es handelt sich um eine Draw2D Klasse (siehe Abschnitt 3.2). Für jedes BPMN-Objekt (siehe 2.1) gibt es Subklassen von Figure, die für die graphische Repräsentation der Objekte zuständig sind. EditPolicy: Über die EditPolicy wird u.a. festgelegt, wie auf die Eingaben des Anwenders reagiert werden soll. Dies hängt beispielsweise vom verwendeten Werkzeug ab und je nach Werkzeug auch welches Objekt auf der Benutzeroberfläche vom Anwender ausgewählt wurde. Auf die Besonderheiten beim Markierungswerkzeug wird in den Abschnitten sowie eingegangen. EditPart: Pro Modellobjekt gibt es einen dafür zuständigen EditPart. Der EditPart steuert die Anlage eines neuen Modellobjektes, kennt dieses und registriert sich, um über Änderungen am Modellobjekt informiert zu werden. Zudem wird auch die Anlage des für die Benutzeroberfläche notwendigen Objektes gesteuert, dieses wird 33

34 gespeichert und der EditPart für das View-Objekt registriert. Dadurch wird der EditPart verständig, falls Änderungen an der View auftreten. Es handelt sich bei den verwendeten View-Klassen um Subklassen von Figure. Markingtool: Das enthält die Logik welche Änderungen konkret durchzuführen sind. Die Logik wird in Abschnitt beschrieben. Der Anwender wählt über das Menü indirekt eine Subklasse von Markingtool aus und legt so fest, welcher Typ von gewünscht sind. Modelobject: Bei den Modellobjekten handelt es sich um Knoten (Nodes) oder Kanten. Die BPMN-Aktivitäten, Start- und Endknoten, AND- und XOR-Gateways (siehe Abschnitt 2.1) zählen zu Knoten und die BPMN-Kanten zu den Kanten (Edges) im Modell. Modellobjekte enthalten im allgemeinen Eigenschaften zum Objekt, die persistent gespeichert werden oder vom Anwender änderbar sind. Descriptor: Descriptoren gibt es für verschiedene Arten von Modelltypen. Beispielsweise gibt es einen Descriptor für Aktivitäten, einen für AND-Gateways, etc. Ihre Aufgabe ist beispielsweise die Anlage neuer Modellobjekte oder die Erstellung neuer Objekte für die View. Gesteuert wird der Descriptor vom EditPart. Im Sequenzdiagramm Abbildung 5.1 ist der Ablauf dargestellt, wenn ein Anwender ein Markierungswerkzeug verwendet und eines der vorhandenen Objekte auf der Benutzeroberfläche mit der Maus anklickt. Der User wählt über die Benutzeroberfläche aus dem Menü das gewünschte Markierungswerkzeug und das zu markierende Objekt aus. Dadurch wird ein Maus-Ereignis (mouse event) generiert. Über die installierten EditPolicies sind erlaubte Aktionen festgelegt. Um den richtigen EditPart zu ermitteln wird u.a. der Typ des Markingtools herangezogen. Ist ein EditPart ermittelbar ist die Änderung erlaubt und die Methode im Markingtool, welche für das Ereignis zuständig ist, wird aufgerufen. Handelt es sich um das Ereignis, das ausgelöst wird, wenn die Maustaste losgelassen wird, ermittelt das Markingtool die zu ändernden Eigenschaften. Diese Logik wird im Abschnitt behandelt. 34

35 Abhängig von den Änderungen wird ein entsprechendes Kommando mit den neuen Werten erstellt und ausgeführt. Das Kommando legt die für die Auswertung bzw. das Replay notwendigen Logdaten an und ändert das Modellobjekt. Über den EditPart für das Objekt, wird abhängig vom Typ des Objektes ein Descriptor aufgerufen, welcher die Änderung an dem Figure-Objekt durchführt. Im Zuge dieser Änderung wird ein repaint() ausgeführt und die Benutzeroberfläche mittels EditPart und Descriptor aktualisiert Ablauf bei Verwendung des Markierungswerkzeugs für Aktivitäten Nun wird ein konkreter Fall behandelt und das Markierungswerkzeug auf eine BPMN- Aktivität (siehe 2.1) angewandt. Dadurch wird je nach dem welches Markierungswerkzeug verwendet wird, der Hintergrund einer Aktivität oder die Rahmeneigenschaften verändert. Die Aktivitäten zählen zu den Knoten. (siehe Abschnitt 5.2.1) Das konkrete Sequenzdiagramm ist in Abbildung 5.2 dargestellt. Bei der Behandlung von Aktivitäten ist folgendes zu beachten: Der Vorgang wird vom Anwender angestoßen und dadurch ein Maus-Ereignis generiert. Die NodeEditPolicy ist die konkrete EditPolicy (siehe Abschnitt 5.2.1), die für Aktivitäten relevant ist. Diese kümmert sich um das Maus-Ereignis. Der Ablauf in Bezug auf EditPolicy und Markingtool ist analog zum allgemeinen Ablauf (siehe Abbildung 5.1). Durch das Kommando wird der Logeintrag erstellt und das Modellobjekt geändert. In diesem Fall ist dies die Aktivität (Node) (siehe Abschnitt 5.2.1). Eine Änderung des Modells führt im NodeEditPart dazu die Änderung in der View anzustoßen. Der für Aktivitäten zuständige Descriptor ist der ActivityDescriptor (siehe Abschnitt 5.2.1). Über den NodeEditPart wird die Änderungslogik im ActivityDescriptor aufgerufen sowie die entsprechende Methoden des View-Objektes. 35

36 Der ActivityDescriptor ruft für die Änderung der Aktivität Methoden von GenericActivityFigure, einer Subklasse von Figure, auf. Aufgrund der Änderungen am View-Objekt wird ein repaint() ausgeführt und die Benutzeroberfläche mittels NodeEditPart und ActivityDescriptor aktualisiert Ablauf weitere Knoten bzw. Kanten Start- und Endknoten sowie AND- und XOR-Gateways zählen ebenfalls zu den Knoten (siehe Abschnitt 2.1). Das Sequenzdiagramm für diese Objekte ist analog zum Ablauf von Aktivitäten (siehe Abschnitt 5.2.2), nur dass andere Objekte beteiligt sind. Deren Aufgaben sind jedoch gleich. Die für diese Knoten zuständige EditPolicy ist GraphEditPolicy. Für den Teil der View ist die Figure-Subklasse PathFigure sowie deren Subklassen für AND- und XOR- Gateways relevant. Die für Kanten relevante EditPolicy ist die EdgeBendPointEditPolicy, das Modellobjekt SelectablePolylineConnection sowie der Descriptor EdgeDescriptor Logik des Markingtools Das Markingtool ermittelt auf Basis des durch den Anwender verwendeten Markierungswerkzeugs und abhängig vom jeweiligen Knoten bzw. der jeweiligen Kante wie diese anzupassen sind. Das Markingtool generiert wie in Abbildung 5.1 dargestellt das entsprechende Kommando für das Ändern des Hintergrundes bzw. das Ändern der Linieneigenschaften und übergibt die neuen Werte an das Kommando. Dabei können durch ein Kommando zum Ändern der Linieneigenschaften die Farbe, die Strichstärke und der Stil der Linie angepasst werden. Die Information, welche Eigenschaft jedes Markierungswerkzeug hat, wird in den jeweiligen Subklassen von Markingtool definiert. Diese Subklassen erfüllen die Vorgaben laut Tabelle 5.1. D.h. in der Subklasse für Markingtool1 ist definiert, dass der Hintergrund zu ändern ist und dass die Farbe gelb zu verwenden ist. Das Markingtool3 ändert den Hintergrund, in der Farbe, die der Anwender ausgewählt hat. Markingtool4 ändert die Linienfarbe in orange und MarketingTool6 ändert die Strichstärke. Markingtool7 ändert 2 Eigenschaften und zwar sowohl die Linienfarbe auf grün als auch die Strichstärke auf fett. Analog zu Markingtool3 kann der Anwender bei Markingtool9 die Farbe der Linie selbst bestimmen. Die restlichen Einträge in Tabelle 5.1 sind weitere Ausprägungen zu den bereits erwähnten. Das Markingtool bzw. dessen Subklassen sind für folgende Logik verantwortlich: 36

37 Klasse Name im Menü Zweck Farbe Stärke Stil MarkingTool1 mark bg color 1 Hintergrund ändern gelb - - MarkingTool2 mark bg color 2 Hintergrund ändern rot - - MarkingTool3 mark bg own color Hintergrund ändern A - - mit ausgewählter Farbe MarkingTool4 mark border color 1 Linie ändern orange - - MarkingTool5 mark border color 2 Linie ändern grün - - MarkingTool6 mark border bold Linie ändern - fett - MarkingTool7 mark border bold Linie ändern grün fett - color 1 MarkingTool8 mark border dash Linie ändern - - strichliert MarkingTool9 mark border own color Linie ändern mit ausgewählter Farbe Tabelle 5.1: Eigenschaften der einzelnen Markierungswerkzeugen A - - Der Anwender wählt ein Markierungswerkzeug aus, mit dem er direkt die Subklasse festlegt. Über diese Subklassen wird definiert, ob die Markierung über die Veränderung des Hintergrundes bei Knoten oder durch die Veränderung der Rahmeneigenschaften von Knoten bzw. im Falle einer Kante der Linieneigenschaften angepasst werden soll. Markierungswerkzeuge mit fixer Farbauswahl enthalten die Information, welche Farbe verwendet werden soll. Handelt es sich um ein Markierungswerkzeug, bei dem der Anwender die Farbe auswählt, wird ihm eine Farbpalette zur Farbauswahl angeboten. Die Funktion, dass der Anwender die Farbe selbst auswählen kann, gibt es sowohl für Hintergrundfarben als auch für Rahmenfarben. Im Falle der Rahmeneigenschaften wird festgelegt, ob die Rahmenfarbe, die Stärke oder der Typ geändert werden soll bzw. eine Kombination aus diesen Eigenschaften. Um die Bedienung möglichst einfach zu gestalten, ist die Funktionen als Toggle Funktion ausgeführt. D.h. klickt ein Anwender mit demselben Markierungswerkzeug ein weiteres Mal auf dasselbe Objekt, wird der Originalzustand hergestellt. Da diese Informationen initial nicht im Modell enthalten sind, wird bei Verwendung eines Markierungswerkzeugs die Information dank der generischen Attribute im Modell gespeichert. 37

38 Bei Toggle werden nun die gespeicherten mit den neuen Information verglichen. Gibt es keine Abweichungen der für das Markierungswerkzeug relevanten Eigenschaften, so handelt es sich um den zweiten Aufruf und diese Eigenschaften werden zurückgesetzt. Entsprechend der Anforderung wird bei Verwendung des Markierungswerkzeugs mit unterschiedlichen Eigenschaften jeweils nur die eigenen Eigenschaften verändert. Aus diesem Grund wären auch eine Kombination aus verändertem Hintergrund und verändertem Rahmen genauso wie Markierungswerkzeuge mit farbigem und fettem Rahmen möglich Besonderheiten für Umsetzung Folgende Besonderheiten sind im Rahmen der Umsetzung zu beachten: In CEP war es nicht vorgesehen, die Hintergrundeigenschaften bzw. Rahmeneigenschaften durch den Anwender ändern zu lassen. CEP hat bereits die Möglichkeit geboten die Hintergrundfarbe aufgrund von Benutzeraktionen zu ändern. Die verwendete Farbe wurde in der View festgelegt und war aber vom Anwender nicht änderbar. Auf dieser Funktionalität wird im View wird aufgebaut. Für die Änderung des Hintergrundes wird die dafür notwendige Logik u.a. in den Viewklassen implementiert. Allgemein ist zu sagen, dass die Farb- und Stil-Eigenschaften in den Komponenten festgelegt wird, die zur View zu zählen sind. Beim Ändern der Linieneigenschaften wird bewusst auf die im Draw2D vorhandene Funktion für Rahmen verzichtet, um die neuen Funktionen entsprechend dem Konzept von CEP zu implementieren. Die Funktionen sollen alle so umgesetzt werden, dass ein erneutes Anwenden eines Markierungswerkzeugs zur ursprünglichen Werte führt. Da Markingtool keine View- Komponente ist, werden entsprechende Erweiterungen in allen relevanten View- Klassen vorgenommen, damit sie dem CEP-Konzept entspricht. 38

39 5.2.6 Logdaten für Änderungen durch das Markierungswerkzeug Die Grundlage für die Datenanalyse sowie die Replay-Funktion (siehe Abschnitt 6.2.2) sind Logdaten, die in einem vorgegebenen Format anzulegen sind. Jeder Logeintrag enthält die Information für welches Objekt der Logeintrag ist, beispielsweise eine Aktivität. Die dafür verwendete Klasse ist AuditTrail_entry. Die Daten vom Markierungswerkzeug sollen in einem lesbaren Format im Logeintrag gespeichert werden. Bei jeder Ausführung eines Kommandos für das Markieren wird ein Logeintrag angelegt. Damit ersichtlich ist, dass es sich um eine Änderung des Markierungswerkzeugs handelt, wird der neu definierte Typ MARK_NODE verwendet. In einem Logeintrag besteht die Möglichkeit Attribute frei zu definieren, d.h. eine Bezeichnung und einen Wert anzugeben. Über diese Attribute wird gespeichert, ob es sich bei der Änderung um eine Änderung des Hintergrundes oder der Linieneigenschaften handelt. Beide Varianten werden anhand eines Beispiels erläutert. Hintergrundfarbe als Attribute im Log speichern Wird die Hintergrundfarbe geändert, so wird ein Attribut mit der Bezeichnung background_color sowie die verwendete Farbe im Logeintrag gespeichert. Die Farbe wird im Format: RGB int, int, int als Text hinterlegt, beispielsweise RGB 255, 0, 128. Linieneigenschaften als Attribute im Log speichern Ebenfalls neu ist das Speichern der Attribute beim Ändern der Linieneigenschaften. Da die Informationen als Text und gut lesbar abgespeichert werden sollen, werden drei einzelne Attribute genutzt. Diese lauten: property_border_color um die Farbe zu speichern im selben Format wie für background_color property_border_style um den Stil zu speichern, Wert ist ein Integer property_border_width um die Linienstärke zu speichern, Wert ist ein Integer Zusätzlich gibt es das Attribut property_border. Logik zum Speichern der Hintergrundfarbe Wird ein Knoten markiert und dessen Hintergrund eingefärbt, wird im Logeintrag ein Attribut angelegt (siehe Abschnitt 5.2.6). Wird dieselbe Markierungsfunktion auf denselben Knoten angewandt, wird über ein neues Kommando ein neuer Logeintrag generiert und dort das gleichnamige Attribute angelegt, jedoch ohne Inhalt. So ist auch das Rücksetzen im Log für Analysen bzw. für das die Replay-Funktion erkennbar. 39

40 Logik zum Speichern der Liniendaten Wird ein Knoten oder eine Kante markiert und deren Linieneigenschaften geändert, wird ein Attribut mit dem Namen PROPER- TY_BORDER im Logeintrag erstellt und mit der Information "geändert"gekennzeichnet. Zudem werden die einzelnen Attribute laut Abschnitt 5.2.6) angelegt und Daten zu Farbe, Stil bzw. Linienstärke gesichert. Wird beispielsweise nur die Farbe geändert, wird auch nur dieses Attribut angelegt. Wird die gleiche Markierungfunktion auf denselben Knoten angewandt, werden die Werte auf Originalwerte zurückgesetzt. Im Logeintrag für dieses Kommando wird nur das Attribut PROPERTY_BORDER mit dem Wert original_value angelegt. Dadurch ist aus dem Log ersichtlich wann es zum Rücksetzen kommt bzw. wird diese Information für das Replay-Funktion benötigt. Die Logdaten können beispielsweise als XML-Dateien exportiert werden. Ein konkreter Logeintrag für das Ändern des Hintergrundes einer Aktivität sieht beispielsweise folgendermaßen aus: <AuditTrailEntry> <Data> <Attribute name="id">1374</attribute> <Attribute name="descriptor">bpmn.activity</attribute> <Attribute name="name">export data to SPSS file</attribute> <Attribute name="background\_color"> RGB {255, 255, 0}</Attribute> </Data> <WorkflowModelElement>Activity \&apos;export data to SPSS file\&apos;</workflowmodelelement> <EventType>MARK\_NODE</EventType> <Timestamp> T14:26: </Timestamp> </AuditTrailEntry> Replay-Funktion Mit der Replay-Funktion kann ein vom Anwender durchgeführtes Experiment Schritt für Schritt nachvollzogen werden und die einzelnen Schritte, die dieser durchgeführt hat, nachvollzogen werden. Die Replay-Funktion ist im Abschnitt beschrieben. Die Markierungswerkzeuge werden für Experimente zur Verfügung stehen. Um die Datenanalyse zu ermöglichen, werden alle Aktivitäten rund um das Markieren in einem Log festgehalten und diese Informationen können auch für das Replay verwendet werden. Das 40

41 bestehende Replay ist über die Admin-Funktionen aufrufbar, dort kann auf die Daten zugegriffen werden. Um die neuen Funktionen zu integrieren wurde das AbstractGraph- Command erweitert, um die Markierungen verarbeiten zu können. Über die Logeinträge ist der Typ des Logeintrages bekannt. Wie in Abschnitt beschrieben, wurde dieser für die Markierungsfunktionen mit MARK_NODE definiert. Im AbstractGraphCommand wird auf diesen Typ abgefragt und bei Bedarf die Methode createcommand() aufgerufen. Die Methode der Klasse MarkCommandCreate verarbeitet die Logdaten und erstellt je nach Inhalt der Logdaten eine neue Instanz der Klasse MarkCommandBG für das Änderung der Hintergrundfarbe bzw. eine Instanz der Klasse MarCommandBorder für das Ändern der Linieneigenschaften. Ab der Erstellung des Kommandos wird der gleiche Ablauf durchlaufen, wie wenn ein Anwender beispielsweise den Hintergrund ändern möchte und über das Markingtool ein Kommando erstellt wurde. 41

42 Abbildung 5.1: Allgemeines Sequenzdiagramm 42

43 Abbildung 5.2: Sequenzdiagramm Aktivitäten 43

44 6 Benutzerhandbuch Im Benutzerhandbuch werden die neuen Funktionen vorgestellt sowie allgemeine Funktionen von CEP, die für die Durchführung von Experimenten notwendig sind. Im Folgenden wird das entwickelte Plug-in mit den neuen Funktionen im Abschnitt 6.1 vorgestellt sowie wichtige Funktionen wie Replay bzw. Export im Abschnitt CustomTool Mit CustomTool Software kann ein Experiment-Designer ein BPMN-Modell (siehe Abschnitt 2.1) erstellen und alle neu entwickelten Markierungswerkzeuge verwenden. Diese werden in diesem Abschnitt im Detail beschrieben Programmstart Die Anwendung wird über Cheetah.exe aufgerufen. Diese Datei befindet sich im eclipse Verzeichnis, welches ein Unterverzeichnis von CustomTool ist. Anschließend ist in diesem Fall der Code 256 einzugeben (siehe Abbildung 6.1). Abbildung 6.1: Codeeingabe Das darauf folgende Fenster zeigt eine eindeutige Nummer, eine ID (siehe Abbildung 6.2). Unter dieser Nummer wird das im Folgenden zu erstellende Modell in der zentralen Datenbank gespeichert und kann später mit dieser ID abgerufen werden. Über die Schaltfläche Start Modeling wird der Editor aufgerufen. 44

45 Abbildung 6.2: Eindeutige Nummer (ID) des Modellingprozesses BPMN-Editor Im Editor ist auf der rechten Seite ein Menü Palette mit den zur Verfügung stehenden BPMN-Objekten vorhanden. Dieser Editor wurde um das Menü MarkingTools erweitert, welches sich unterhalb der Palette befindet (siehe Abbildung 6.3). Abbildung 6.3: Modellierungsanwendung Der in CEP bereits vorhandene Editor ermöglicht es Objekte neu anzulegen. Dafür ist der jeweilige Menüpunkt für das gewünschte Objekt mittels Maus aus dem Menü Palette auszuwählen und auf dem Editor zu platzieren. Wird das Startevent im Menü ausgewählt, kann der Startknoten mittels Mausklick im Editor platziert werden. Um eine 45

46 Aktivität zu erstellen, ist Activity im Menü auszuwählen und mittels Maus im Editor zu positionieren. Anschließend ist der Name der Aktivität einzugeben. Bei Bedarf können AND für AND-Gateway oder XOR für XOR-Gateway ausgewählt werden und am Schluss das Endevent. Dies sind alle möglichen Knoten. Zudem gibt es Kanten, welche die Flussrichtung angeben (siehe Abschnitt 2.1). Wird Sequence Flow ausgewählt, so wird mit einem Mausklick zuerst der Knoten ausgewählt, von dem die Kante ausgeht und mit dem zweiten Mausklick das Objekt gewählt, bei dem die Kante endet Markierungswerkzeug Die implementierten Markierungswerkzeuge können den Hintergrund der Knoten ändern bzw. die Linieneigenschaften der Knoten sowie der Kanten. Die neuen Markierungswerkzeuge sind in Tabelle 6.1 aufgelistet. Die in der ersten Spalte angeführt Nummer wird im Zuge der Erläuterungen genutzt. Nr. Bezeichnung Zweck Farbe Stärke Stil 1 mark bg color 1 Hintergrund ändern gelb mark bg color 2 Hintergrund ändern rot mark bg own color Hintergrund ändern mit A - - ausgewählter Farbe 4 mark border color 1 Linie ändern orange mark border color 2 Linie ändern grün mark border bold Linie ändern - fett - 7 mark border bold Linie ändern grün fett - color 1 8 mark border dash Linie ändern - - strichliert 9 mark border own color Linie ändern mit ausgewählter Farbe Tabelle 6.1: Liste der Markierungswerkzeuge A - - Mit dem Markierungswerkzeug mit Nr. 1 (siehe Tabelle 6.1) kann der Hintergrund eines beliebigen Knotens auf rot und über jenes mit Nr. 2 auf gelb geändert werden. Die Abbildung 6.4 zeigt das Ergebnis nachdem das Markierungswerkzeug mit Nr. 1 den Hintergrund der Aktivität a sowie des Endknotens auf gelb geändert hat und das Markierungswerkzeug mit Nr. 2 den Hintergrund der Aktivität b sowie eines XOR-Gateways auf rot. Mit dem Markierungswerkzeug mit Nr. 3 lassen sich der Hintergrund eines beliebigen Knotens auf eine beliebige Farbe ändern. Nach Anklicken des Markierungswerkzeugs 46

47 Abbildung 6.4: Hintergrund ändern 1 und Auswahl des zu markierenden Knotens, wird ein Fenster mit einer Farbauswahl zur Verfügung gestellt (siehe Abbildung 6.5). Abbildung 6.5: Farbe auswählen Der Hintergrund des bereits vorher ausgewählten Knotens wird mit der gewünschten Farbe eingefärbt. In diesem Beispiel wurde violett für die Aktivität c genutzt (siehe Abbildung 6.6). Wird mit demselben Markierungswerkzeug ein weiteres Mal ein Knoten ausgewählt, so wird der ursprüngliche Hintergrund hergestellt. In Abbildung 6.7 wurde mit Markierungswerkzeug mit Nr. 3 der Hintergrund der Aktivität c und nach Auswahl des Markierungswerkzeugs Nr. 1 der Hintergrund der Aktivität a entfernt. Mit dem Markierungswerkzeug Nr. 4 lassen sich die Linien eines jeden Objektes orange einfärben. In Abbildung 6.8 wurden die Linien des Startknotens, der beiden XOR- Gateways, der Aktivität a sowie allen Kanten ausgehend vom Startknoten in Richtung des AND-Gateways über die Aktivität a und das AND-Gateway bis zu dem Endknoten orange eingefärbt. Die Funktionalität des Markierungswerkzeuges Nr. 5 enspricht der von Markierungswerkzeug mit Nr. 4, jedoch färbt es Linien grün ein (siehe Abbildung 6.9). Zudem wird der 47

48 Abbildung 6.6: Hintergrund ändern 2 Abbildung 6.7: Hintergrund ändern 3 Endnoten ebenfalls grün eingefärbt. Die gelbe Hintergrundfarbe des Endknotens bleibt unverändert. Mit dem Markierungswerkzeug Nr. 6 wird die Linienstärke beeinflusst. In Abbildung 6.10 wurden beide AND-Gateways, Aktivität c sowie die Kanten zwischen beiden AND- Gateways markiert. Alle bisherigen Änderung wurden zurückgenommen und mit dem Markierungswerkzeug Nr. 7 die AND-Gateways, der Startknoten sowie die Aktivität c markiert und dadurch grün und fett dargestellt (siehe Abbildung 6.11). Mit dem Markierungswerkzeug Nr. 8 wird der Startknoten, das AND-Gateway, die Aktivität a sowie die dazwischenliegende Kanten markiert und dadurch strichliert dargestellt (siehe Abbildung 6.12). Mit dem Markierungswerkzeug Nr. 9 können Linien in einer beliebigen Farbe mar- 48

49 Abbildung 6.8: Linie ändern 1 Abbildung 6.9: Linie ändern 2 kiert werden. Nach Anklicken des Markierungswerkzeugs und Auswahl des zu markierenden Knotens oder Kante, wird ein Fenster mit einer Farbauswahl zur Verfügung gestellt (siehe Abbildung 6.5). Die Aktivität b, das in Flussrichtung liegende AND- sowie XOR-Gateway, der Endknoten und die dazwischenliegenden Kanten wurden mit dem Markierungswerkzeug Nr. 9 markiert, wodurch die Linien pink eingefärbt wurden(siehe Abbildung 6.13). Die Linien des AND-Gateways waren bereits vorher fett dargestellt, nun sind die zusätzlich pink. Dies entspricht der Anforderung nachdem nur jene Eigenschaften geändert werden sollen, welche das Markierungswerkzeug selbst ändert. Markierungswerkzeug Nr. 3 und Nr. 9 ermöglichen dem Anwender die Farbe selbst auszuwählen. Solange das Markierungswerkzeug aktiv bleibt, das bedeutet solange kein anderes Werkzeug wie neue Aktivität oder ein anderes Markierungswerkzeug ausgewählt wird, bleibt die Farbe gleich. Möchte der Anwender jedoch die Farbe ändern, so 49

50 Abbildung 6.10: Linie ändern 3 Abbildung 6.11: Linie ändern 4 muss er nur noch einmal auf dieses Markierungswerkzeug klicken, anschließend wird ihm die Möglichkeit geboten die Farbe neu auszuwählen. Ist die Modellierung abgeschlossen, ist der Vorgang über das Betätigen der Schaltfläche Finish Modeling, welche oben links zu finden ist, zu beenden. Die Daten zur Modellierung und zu den Markierungsvorgängen werden in einer zentralen Datenbank gespeichert (siehe Abbildung 6.14). 6.2 Administrationsanwendung Mit der bereits bestehenden Administrationsanwendung kann der Experiment-Designer beispielsweise eine bereits durchgeführte Modellierung eines Geschäftsprozessmodells abspielen und jeden Schritt des Modellierens einzeln nachvollziehen. Für die Analyse von 50

51 Abbildung 6.12: Linie ändern 5 Abbildung 6.13: Linie ändern 6 Experimenten lassen sich deren Daten exportieren. Diese Anwendung wurde erweitert, damit die neuen Markierungsfunktionen berücksichtigt werden. Der Aufruf der Administrationsanwendung sowie deren wichtigste Funktionen werden nun beschrieben Programmstart Die Anwendung wird über Cheetah.exe aufgerufen. Diese Datei befindet sich im eclipse Verzeichnis, welches ein Unterverzeichnis von AdminAnwendung ist. 51

52 Abbildung 6.14: Linie ändern Replay durchführen In der Benutzeroberfläche ist links oben der Menüpunkt Process zu finden. Replay ist über Process / Load / Replay aufzurufen (siehe Abbildung 6.15). Abbildung 6.15: Menü um Replay zu starten Im Fenster Select Model (siehe Abbildung 6.16) ist der gewünschte Eintrag anhand der angezeigten Informationen wie ID, Prozessname oder Uhrzeit auszuwählen und mit ok zu betätigen. Mit Hilfe des Menüs (siehe Abbildung 6.17) ist es möglich die Replayfunktion zu bedienen. Mit Play lässt sich der Vorgang starten und alle vom Anwender durchgeführten Interaktionen werden angezeigt. Mit Pause stoppt das automatische Abspielen und mit dem Balken unten rechts kann die Abspielgeschwindigkeit beeinflusst werden. Wenn der Vorgang gestoppt ist, lässt sich jeder Befehl einzeln der Reihe nach abrufen. Über next wird der nächste Befehl ausgeführt. Über previous wird ein Undo-Befehl ausgeführt und der zuvor durchgeführte Befehl dadurch neutralisiert. Mit first, jump back, jump forward und last kann man nicht nur einen Befehl, sondern mehrere auf einmal ausführen. Beendet wird das Replay mit X -Symbol im Fenster oben rechts Daten exportieren Über die bereits vorhandene Administrationsanwendung können Daten zu Versuchen exportiert werden. Die Daten zu einem Versuch müssen dafür in der Datenbank gespeichert 52

53 Abbildung 6.16: Auswahl für Replay sein. In der Benutzeroberfläche ist links oben der Menüpunkt Process zu finden (siehe Abbildung 6.18). Verschiedene Möglichkeiten für einen Export sind im Menüpunkt Process / Export angeführt (siehe Abbildung 6.18). Das Exportieren von Daten als CSV-Datei und der Export detaillierter Daten als XML-Dateien werden im Folgenden erläutert. Export als CSV-Datei Ergebnisse eines Experimentes können über die Funktion Export into csv als CSV-Datei exportiert werden. Die Funktion ist im Menü wie in Abbildung 6.18 ersichtlich, zu finden. Werden Daten zu einem Experiment exportiert, so werden abhängig vom Experiment die Fragen, die dem Teilnehmer gestellt wurden, dessen Antworten und die dafür benötigte Zeit exportiert. Dies können wie im Kapitel 7 beschriebenen Versuch Fragen zur Erfahrung mit Geschäftsprozessmodellen, Verständnisfragen zu Geschäftsprozessmodellen, Fragen zu mentalem Aufwand für jede gestellte Verständnisfrage, Fragen zu Benutzerfreundlichkeit und Potential sein. Eine CSV-Datei ist eine Datei, in welcher die Daten durch Strichpunkte getrennt sind. In diesem Format 53

54 Abbildung 6.17: Menü für Replay durchzuführen können Daten einfach weiterverarbeitet werden. Der Anwender trifft die Auswahl der Prozesse, deren Daten exportiert werden sollen (siehe Abbildung 6.19). Eine Möglichkeit nach der die Daten selektiert werden, ist die angeführte ID die in Abschnitt beschrieben wurde. Anschließend ist der Dateiname bzw. Speicherort anzugeben und die Schaltfläche Speichern zu betätigen. Dem Anwender kann die zu exportierenden Daten einschränken. Über der in Abbildung 6.20 dargestellten Benutzeroberfläche können nicht gewünschte Daten deaktiviert werden. Um den Export zu starten ist die Schaltfläche export zu betätigen. Export detaillierterer Daten zu einem Experiment Über die Funktion Export Experimental Workflow können umfangreiche Daten zum Experiment als XML-Dateien exportiert werden. Diese Dateien lassen sich gut weiterverarbeiten. Das Ergebnis des Exportes ist eine Datei, die Daten über alle ausgewählten Prozesse enthält und Einzeldateien, die detailliertere Informationen beispielsweise zu jeder durchgeführten Frage zu einem Geschäftsprozess beinhaltet. In diesen Daten ist auch die Verwendung des Markierungswerkzeugs durch den Teilnehmer dokumentiert. D.h. dort ist erkennbar, welche Objekte vom Anwender markiert wurden. Die Funktion Export Experimental Workflow ist im Menü wie in Abbildung 6.18 dargestellt zu finden. Analog zum Export von CSV-Dateien sind die relevanten Prozesse auszuwählen (siehe Abbildung 6.19) und der Dateiname anzugeben. Mit Betätigen der Schaltfläche Speichern wird der Export gestartet. 6.3 Ablauf Experimenterstellung bis Analyse Ein Experiment wird in drei Phasen durchgeführt. Die Vorbereitung mit Erstellung des Experimentes, die Durchführung des Experiments sowie die Analyse. 54

55 Abbildung 6.18: Menü für Export von Daten Experiment erstellen Zuerst wird ein Experiment zur Prüfung der Verständlichkeit generiert. Je nach der Art des Experimentes benötigt man unterschiedliche Modelle. Man kann beispielsweise ein Experiment mit zwei Geschäftsprozessmodellen verwenden. Zudem muss festgelegt werden, welche weiteren Komponenten gewünscht werden. Diese wurden im Abschnitt 2.2 erläutert. Die Person, welche das Experiment erstellt, generiert dazu eine Konfiguration. Über diese Konfiguration kann man festlegen, ob bzw. welches Markierungswerkzeug zu einem Geschäftsprozessmodell verwendet werden soll. Die Markierungswerkzeuge sind so entwickelt, dass es keine Einschränkung seitens des Markierungswerkzeugs gibt, welche Variante bzw. in welcher Kombination sie verwendet werden. Zudem lassen sich so beispielsweise zwei Konfigurationen definieren und über einen Code steuern, bei welchem Geschäftsprozessmodell ein Markierungswerkzeug zur Verfügung steht. Das bedeutet, wenn eine Hälfte der Teilnehmer die Variante 1 verwendet, führen diese beispielsweise den ersten Teil des Experimentes ohne Markierungswerkzeug durch und den zweiten Teil mit der Unterstützung durch das Markierungswerkzeug durch. Die ande- 55

56 Abbildung 6.19: Auswahl für Export von Daten re Gruppe erhält die Unterstützung für das Markierungswerkzeug in umgekehrter Reihenfolge, d.h. bereits beim ersten Modell können sie mit dem Markierungswerkzeug arbeiten und beim zweiten Geschäftsprozessmodell nicht. Durch eine ausgewogene Verteilung der vergebenen Codes für ein Experiment können verschiedene Einflussfaktoren reduziert bzw. neutralisiert werden Experiment durchführen Auf Basis dieses Experimentier-Workflows, erfolgt die Durchführung des Experimentes. Die Teilnehmer geben den vorgesehen Code ein und arbeiten das Experiment entsprechend den Vorgaben ab. Durch CEP wird sichergestellt, dass der Anwender weder den Vorgang unterbricht und später fortsetzt noch beliebige Daten eingibt, da Eingabeprüfungen sowie fixe Auswahlmöglichkeiten ohne Freitexteingabe vorhanden sind. Dadurch lassen sich die Experimente kontrolliert durchführen. Die neu entwickelten Markierungswerkzeuge steht nur in dem dafür vorgesehenen Modell zur Verfügung. Der Anwender kann dabei das Markierungswerkzeug beliebig verwenden. Jedes Mal, wenn das Markierungswerkzeug benutzt wird, wird ein Logeintrag erstellt, um dies nachvollziehen zu können. Dasselbe gilt, wenn das Kommando erneut auf dasselbe Objekt ausgeführt wird und 56

57 Abbildung 6.20: Auswahl der Daten für Export somit rückgängig gemacht wird. Weitere Informationen zu Logdaten sind in Abschnitt beschrieben Ergebnisse analysieren Die durch das Experiment enthaltenen Daten werden in diesem Schritt analysiert. Die Daten können für die Datenanalyse exportiert werden (siehe 6.2.3) oder über die Replay- Funktion (siehe Abschnitt 6.2.2) einzeln analysiert werden. Erkenntnisse aus den Analysen können in neue Experimente einfließen. 57

58 7 Versuch In diesem Abschnitt wird der durchgeführte Versuch behandelt. Dabei wird auf die Inhalte (siehe Abschnitt 7.1), den Ablauf (siehe Abschnitt 7.2), die Analyse der Ergebnisse (siehe Abschnitt 7.3) sowie die daraus resultierenden Erkenntnisse (siehe Abschnitt 7.4) eingegangen. 7.1 Vorbereitung des Versuchs In diesem Abschnitt werden die Probanden, die Variable mit ihren Ausprägungen, die Modelle sowie die Variablen, anhand derer das Ergebnis gemessen werden soll, vorgestellt. Zudem wird der Ablauf des Experimentes und dessen Komponenten erläutert. Probanden Für den Versuch wurden 15 Bachelorstudenten der Informatik oder Informatiker mit Bachelorabschluss herangezogen, wobei keine besonderen Kenntnisse zu Geschäftsprozessmodellen und BPMN-Notation vorausgesetzt wurden. Unabhängige Variable Die unabhängige Variable im Experiment war das Vorhandensein eines Markierungswerkzeuges mit den Ausprägungen Jaünd Nein. Bei Vorhandensein des Markierungswerkzeuges gleich Ja stand dem Teilnehmer das Markierungswerkzeug zum Einfärben des Hintergrundes von Knoten im Geschäftsprozessmodell zur Verfügung (siehe Abschnitt 6.1.3). Bei der Ausprägung Nein war dies nicht der Fall. Modelle Verwendet wurden zwei Geschäftsprozessmodelle. Diese und alle gestellten Fragen im Experiment stammen von einem CEP-Experiment, welches in der wissenschaftlichen Arbeit Assessing the Impact of Hierarchy on Model Understandability - A Cognitive Perspective [10] verwendet wurde. Das Experiment ist online verfügbar unter [9]. Aufgabe Den Probanden wurden jeweils Fragen zu beiden Modellen gestellt. 58

59 Response -Variablen Das Verständnis über das Modell wurde über die Anzahl der richtigen Antworten und die Verständnis-Geschwindigkeit wird über die Zeit gemessen, die für die Beantwortung der Fragen benötigt wird. Zudem wird der Teilnehmer nach jeder Frage nach dem mental effort befragt. Zweck Abgeprüft werden soll, ob die Verwendung des Markierungswerkzeuges einen Einfluss auf die Anzahl der korrekten Antworten, die dafür benötigte Zeit bzw. auf den dafür notwendigen mental effort hat. 7.2 Ablauf des Versuchs In diesem Abschnitt werden der Ablauf des Versuchs sowie Informationen zu den einzelnen verwendeten Komponenten erläutert. Der erste Schritt im Versuch war eine Kurzschulung der Teilnehmer zu Geschäftsprozessmodellen in Zusammenhang mit BPMN. Zudem wurden sie gebeten den Versuch zügig durchzuführen. Alle weiteren Schritte wurden mittels CEP abgewickelt und zwar mit der in Abbildung 7.1 dargestellten Konfiguration: Abbildung 7.1: Ablauf des Versuchs Code eingeben Jedem Teilnehmer wurde einer von zwei Codes gegeben, der festlegt, ob das Markierungswerkzeug beim ersten oder zweiten Geschäftsprozessmodell zur Verfügung steht. Die Hälfte der Teilnehmer erhielt den Code 1 und die andere Hälfte den Code 2, wobei die Zuordnung der Codes auf die Teilnehmer zufällig erfolgte. Diesen Code mussten sie für den Start des Versuchs eingeben. 59

60 Demographische Fragen Allen Teilnehmern wurden Fragen zu ihrer Erfahrung mit Geschäftsprozessmodellen sowie BPMN gestellt. Modell 1 : Anschließend wurden allen Teilnehmern Fragen zu Modell 1 gestellt. Probanden, welche Code 2 verwendeten, stand das Markierungswerkzeug im Modell 1 zur Verfügung. Diese Gruppe wird nun als Gruppe 2 bezeichnet und die Personen, welche Code 1 verwendeten als Gruppe 1. Der Anwender standen für die Beantwortung der Verständnisfragen zum Modell die Antwortmöglichkeiten Wahr, Falsch und Weiß nicht zur Verfügung. Zudem war zu jeder Frage eine kurze Erläuterung zu schreiben. Mentaler Aufwand (Mental Effort): Nach jeder Frage zum Modell wurde abgefragt, wie einfach bzw. aufwändig die Beantwortung der Frage empfunden wurde. Die möglichen Antworten warne in sieben Stufen gegliedert und die Skala begann mit Extremely low mental effort, enthielt Neither high nor low mental effort und reichte bis Extremely high mental effort. Befragung: Nach Beendigung der Fragen zu den Modellen wurden Fragen zur Einschätzung der Benutzerfreundlich sowie Potentials des Markierungswerkzeuges gestellt. Die Skala der 7 Antwortmöglichkeiten beginnt bei Extremely Likely, ging über Neither Likely nor Unlikely und endet bei Extremely Unlikely. Freiwillige Rückmeldung: Am Ende konnte der Teilnehmer ein Kommentar zum Versuch verfassen. In Abbildung 7.2 ist ein Beispiel für die Benutzeroberfläche dargestellt. In diesem Fall wird eine Verständnisfrage zu einem Versuch gestellt. Im Hauptbildschirm befindet sich das Geschäftsprozessmodell und im oberen Bereich die Frage, die zum Modell gestellt wird sowie die Eingabemöglichkeit für die Kurzbegründung. In diesem Fall steht dem Teilnehmer das Markierungswerkzeug zur Verfügung. Es befindet sich im Menü auf der rechten Seite. 7.3 Analyse des Versuchs Die Daten des Versuchs wurden anschließend ausgewertet. Konkret handelt es sich dabei um ausgewählte demographische Daten (siehe Abschnitt 7.3.1), die Anzahl korrekter Antworten (siehe Abschnitt 7.3.2), die Zusatzinformationen Zeit und mentaler Aufwand (siehe Abschnitt 7.3.3) sowie die Meinung zum Markierungswerkzeug selbst (siehe Abschnitt 7.3.4). 60

61 Abbildung 7.2: Beispiel für eine Verständnisfrage im Versuch Demographische Daten Den Teilnehmern wurden verschiedene Fragen zur Erfahrung rund um Prozessmodelle sowie BPMN gestellt. Wie zu Erwarten, ist keiner der Teilnehmer ein Experte auf diesem Gebiet. In Abbildung 7.3 ist die Antwort der Teilnehmer zur Frage I feel very confident in understanding process models created with the BPMN. in Form eines Historgramms dargestellt. Zwei Drittel der Teilnehmer bewertet die eigenen Kenntnisse zum Thema BPMN positiv. Das andere Drittel schätzt die eigenen Kenntnisse als nicht besonders gut ein. Wie in Tabelle 7.1 ersichtlich liegt der Durchschnitt bei 4,6. Der geringste Wert ist mit 1 der kleinst mögliche Wert. 61

62 Abbildung 7.3: Einschätzung der Kenntnisse Berechnungsart Wert Durchschnitt 4,6 Median 5 Minimum 1 Maximum 6 Tabelle 7.1: Einschätzung eigener Kenntnisse Anzahl korrekt beantworteter Fragen Alle 15 Versuche wurden vollständig durchgeführt und alle Fragen beantwortet. Die Anzahl der korrekt beantworteten Fragen werden getrennt nach den Gruppen 1 und 2 sowie nach Verwendung des Markierungswerkzeuges analysiert. In Tabelle 7.2 sind die korrekten Antworten der Gruppe 1 dargestellt. Den Teilnehmern der Gruppe 1 stand bei der Beantwortung der 8 Fragen zu Geschäftsprozessmodell 1 das Werkzeug nicht zur Verfügung. Diese Ergebnisse sind in Spalte Modell 1 (ohne Werkzeug) angeführt. Bei der Beantwortung der Fragen zum zweiten Geschäftsprozessmodell war es stand das Markierungswerkzeug zur Verfügung. Diese Ergebnisse sind in der zweiten Spalte angegeben. Der Durchschnittswert ist beim zweiten Modell mit 7,4 etwas höher als beim ersten Modell mit 6,8. Die Mediane sind in beiden Fällen 7. In Tabelle 7.3 sind die korrekten Antworten der Gruppe 2 dargestellt. Den Teilnehmern 62