Technische Konzeption und Realisierung der Modellierungskomponente für ein datenorientiertes Prozess-Management-System [original]

Technische Konzeption und Realisierung der

Modellierungskomponente für ein datenorien-

tiertes Prozess-Management-System

Andreas Pröbstle

andreas.pr[email protected]

Studiengang: Informatik

1. Gutachter: Prof. Dr. Manfred Reichert

2. Gutachter: Prof. Dr. Peter Dadam

Betreuerin: Dipl. Medieninf. Vera Künzle

begonnen am: 01.11.2010

beendet am: 28.04.2011

Inhaltsverzeichnis

1. Einleitung 9

1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2. Entwicklung eines Modellierungsprogrammes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

1.3. Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

2. Grundlagen PHILharmonicFlows 11

2.1. Aufbau von PHILharmonicFlows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

2.1.1. Datenstruktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

2.1.2. Prozessstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

2.1.3. Benutzerintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

2.2. Definition eines Anwendungsbeispiels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

2.3. Einordnung des Anwendungsbeispiels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

3. Technische Grundlagen 21

3.1. Auswahl des Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

3.2. Das Eclipse Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

3.2.1. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

3.2.2. Eclipse Rich Client Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

3.2.3. Eclipse Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.2.4. Graphical Editig Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

3.3. Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

3.3.1. OSGi Service Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

3.3.2. Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

3.3.3. Model-View-Controller-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

4. Überblick Oberfläche 31

4.1. Anfangsbildschirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

4.2. Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

4.3. Oberfläche der Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

4.3.1. Objekttypen-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

4.3.2. Wertetypen-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

4.4. Prozessstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

5. Implementierung 37

5.1. Implementierung Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1. Paket für Editoren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.2. Paket für die Inhalte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2. Implementierung Daten-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1. Datenstruktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.2. Prozessstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3. Implementierung Oberfläche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.1. PHILharmonicFlowsEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.2. Erzeugung neuer Modell-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.3. Implementierung des Objekttypeneditors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.4. Wertetypen-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.3.5. Details des Mikroprozess-Editors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6. Diskussion 85

6.1. Erweiterungsmöglichkeiten des Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.1. Entwurf eines zusätzlichen Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.2. Implementierung zusätzlicher Modell-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.1.3. Integration des Eigenschaftsfensters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2. Abwandlungen zum Oberflächenkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2.1. Aufspaltung der Navigationsleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2.2. Darstellung der Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.2.3. Abwandlungen des Eigenschaftsfensters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.2.4. Unterschiede der Prozessstruktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7. Zusammenfassung und Ausblick 97

7.1. Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Literaturverzeichnis 99

Bildnachweis 101

A. Überblick über die Paketstruktur 103

B. Glossar 107

Abbildungsverzeichnis

Abbildung 1.: Die Hauptkomponenten und ihre Funktionen (nach [17]) 12

Abbildung 2.: Beispiele für zyklenfreie Datenstruktur 13

Abbildung 3.: Beispiele für Zyklus Datenstruktur 13

Abbildung 4.: Prozesskontext von Mikroprozess Instanzen 16

Abbildung 5.: Der Prozessablauf des Beispielprozesses 19

Abbildung 6.: Datenstruktur des Beispielprozesses 20

Abbildung 7.: Eclipse Architektur 22

Abbildung 8.: Die Eclipse Oberfläche 24

Abbildung 9.: Darstellung Draw2d 26

Abbildung 10.: Klassendiagramm des Beobachter-Entwurfsmusters 28

Abbildung 11.: Verwaltung der Kommandos 29

Abbildung 12.: Das MVC-Konzept in Eclipse[2] 30

Abbildung 13.: Benutzeroberfläche bei Programmstart 31

Abbildung 14.: Ansicht der Palette 32

Abbildung 15.: Objekttypen-Editor 33

Abbildung 16.: Ansicht des Wertetypen-Editors 34

Abbildung 17.: Der Mikroprozess-Editor 36

Abbildung 18.: Paketdiagramm 38

Abbildung 19.: Paketdiagramm des Modell-Hauptpakets 39

Abbildung 20.: Aufteilung Paket DataModel 40

Abbildung 21.: Grundlegende Klassen 41

Abbildung 22.: Klassendiagramm Datenstruktur 43

Abbildung 23.: Klassendiagramm DataModell 44

Abbildung 24.: Beispiel für Zyklenentwicklung 48

Abbildung 25.: Aufbau SimplePredicateType 53

Abbildung 26.: Klassenaufbau der Prädikate 53

Abbildung 27.: Beispiel für Schachtelung der Prädikate 54

Abbildung 28.: Klassendiagramm Prozessstruktur 55

Abbildung 29.: Abhängigkeiten MicroProcessType 56

Abbildung 30.: Ausschnitt eines Beispielgraphs mit externen und internen Transitionen 57

Abbildung 31.: Klassendiagramm ausgehend von StateType 58

Abbildung 32.: Hierarchisches Klassendiagramm der Mikroprozessschritte 58

Abbildung 33.: Beziehungen der Prozessschritte zu Mikrotransitionen 59

Abbildung 34.: Beispiel für Prioritätenänderung 60

Abbildung 35.: Beziehungen der Prozessschritte zu Mikrotransitionen 65

Abbildung 36.: Zusammenhang Editoren 67

Abbildung 37.: Ansicht Palette 69

Abbildung 38.: Beispiel Eigenschaftsfenster mit Tabreitern 70

Abbildung 39.: Kontextmenu im Object Type Editor für eine Relation 72

Abbildung 40.: Attribute Kategorie der properties view 73

Abbildung 41.: Data Context Kategorie der properties view 74

Abbildung 42.: Darstellung von Relationen im Objekttypen-Editor 75

Abbildung 43.: Ansicht der Wertetypen-Editor Perspektive 76

Abbildung 44.: Ansicht der Mikroprozess-Editor Perspektive 77

Abbildung 45.: Darstellung eines Mikroprozesses 79

Abbildung 46.: Eigenschaftsfenster mit Mikrowertschritt-Tabelle 79

Abbildung 47.: Eigenschaftsfenster einer Mikrotransition 80

Abbildung 48.: Lineare Anordnung von Mikroschritten 81

Abbildung 49.: Anordnung der Mikroschritte, gegliedert in Zustände 81

Abbildung 50.: Navigationskonzept der Palette 86

Abbildung 51.: Erweiterungspunkte für das Eigenschaftsfenster in der plugin.xml 88

Abbildung 52.: Navigationsleiste im Konzept (links) und in der Implementierung (rechts) 89

Abbildung 53.: Datenstruktur Konzept 91

Abbildung 54.: Datenstruktur Implementierung 91

Abbildung 55.: Alternative Datenstruktur mit rechtwinkliger Linienführung 92

Abbildung 56.: Eigenschaftsfenster Konzept 92

Abbildung 57.: Eigenschaftsfenster Implementierung 92

Abbildung 58.: Prozessstruktur Implementierung 94

Abbildung 59.: Prozessstruktur Konzept 95

Codebeispiele

Beispielcode 1.: Erzeugen einer neuen Elternrelation 47

Beispielcode 2.: Entfernen einer Elternrelation 49

Beispielcode 3.: Aktivierung einer Relation 51

Beispielcode 4.: Hinzufügen einer ausgehenden Transition 61

Beispielcode 5.: Hinzufügen einer eingehenden Mikrotransition 63

Beispielcode 6.: Ordnungskorrektur nach dem Löschen einer Transition 64

Beispielcode 7.: Pseudocode für Anordnung der Mikroschritte 83

Einleitung

1.1. Motivation

Geschäftsprozessmanagement (BPM) verspricht eine höhere Flexibilität, Prozesskontrolle und

Transparenz innerhalb komplexer Organisationen und zeigt sich somit als einer der wichtigsten

Erfolgsfaktoren für die zukünftige Entwicklung. Jedoch zögern noch viele Unternehmen aus

Mangel an Ressourcen oder Kompetenz mit der Einführung von BPM-Lösungen1. Allerdings

zeigt sich ein großes Interesse an der Einführung von BPM in den Unternehmen. Die Notwen-

digkeit zum Einstieg zeigen auch Studien, die die richtige Beherrschung von BPM als Existenz-

voraussetzung definieren [2].

In der Praxis zeigt sich jedoch das eingeschränkte Anwendungsfeld der herkömmlichen Prozess-

Management-Software, die für fest durch Aktivitäten strukturierte Prozesse entworfen ist. Viele

der heutigen Prozesse - gerade im Dienstleistungsbereich - sind jedoch nicht durch eine feste

Abfolge von Aktivitäten geprägt. Vielmehr erfolgt die Ausführung der Arbeitsschritte flexibel

und wird nur durch das Vorliegen der für einen Arbeitsschritt nötigen Daten bestimmt.

Eine aktuelle Entwicklung in diesem Bereich sind die datenorientierten Prozess-Management-

Systeme. Diese beschreiben nicht feste Abfolgen der Bearbeitungsaktivitäten des Prozesses. Viel-

1 Laut einer Studie von trovarit [1] setzen 75% der Unternehmen bisher noch keine BPM Lösung ein

Einleitung

mehr bieten sie die Flexibilität Aktionen vorzunehmen sobald ihre Vorbedingungen erfüllt sind

und die Ausführung der Aktion nicht der Konsistenz des Prozesses schadet.

1.2. Entwicklung eines Modellierungsprogrammes

Ziel dieser Arbeit ist die Implementierung eines Modellierungsprogrammes für das datenori-

entierte Prozess-Management-System PHILharmonicFlows1 auf der Basis eines bestehenden

Usability-Konzepts. Mit der Modellierungsumgebung soll der Benutzer graphisch unterstützt

die Modelle für Prozesse entwerfen, aus denen zur Laufzeit automatisch die Aufgabenlisten und

Datenformulare generiert werden. Da bei der Modellierung viele Regeln und Vorgehensweisen

beachtet werden müssen ist es wichtig den Benutzer dabei zu unterstützen. Dies passiert sowohl

durch verständliche Hinweise und Fehlermeldungen wie auch durch aktive Benutzerführung,

indem fehlerhafte Vorgehensweisen erst gar nicht angeboten oder automatisch korrigiert wer-

den. Für einen flexiblen und längerfristigen Einsatz soll die Modellierungsumgebung zudem

möglichst plattformunabhängig implementiert und für spätere Änderungen und Erweiterungen

offen konzipiert sein.

1.3. Struktur der Arbeit

Zunächst werden in Kapitel 2 die Grundlagen des PHILharmonicFlows Konzepts näher erläu-

tert und anhand eines Beispiels deren praktischer Einsatz gezeigt. Im Anschluss gibt Kapitel 3

einen Überblick über die verwendeten Technologien zur Umsetzung. Außerdem werden Infor-

mationen über grundlegende verwendete Konzepte bei der Implementierung gegeben. In Kapi-

tel 4 erfolgt eine kurze Einführung in die entwickelte Oberfläche um die Details der Implemen-

tierung besser verstehen und in den Gesamtkontext einordnen zu können. Anschließend erfolgt

in Kapitel 5 eine Erläuterung der Implementierung. Dabei werden sowohl die Datenklassen als

auch der Oberflächenentwurf beleuchtet. Die dabei aufgetretenen Abweichungen vom Oberflä-

chenkonzept und deren Hintergründe wie auch die Erweiterungsschnittstellen werden in Kapi-

tel 6 beschrieben.

1 Process, Humans and Information Linkage for harmonic Business Flows.

Grundlagen PHILharmonicFlows

Das Ziel des PHILharmonicFlows Projekts ist die Entwicklung eines datenorientierten Pro-

zess-Management-Systems (PMS). Herkömmliche Prozess-Management-Systeme definieren

Prozesse als Abfolge von Aktivitäten in denen jeweils festgelegte Arbeitsvorgänge erfolgen. Der

Austausch der Anwendungsdaten zwischen den Aktivitäten erfolgt über einen parallel zum Pro-

zessfluss entwickelten Datenfluss, der den Aktivitäten Ein- und Ausgabewerte zuordnet.

Umständlich ist bei dieser Vorgehensweise die Änderung von Daten außerhalb

des normalen Prozessfortschritts. Beispielsweise kann sich in einem Bewerbungs-

prozess die Adresse eines Bewerbers zu jedem Zeitpunkt während des Prozessab-

laufs ändern. Da der Zugriff auf die Anwendungsdaten für Benutzer nur über

Aktivitäten möglich ist, muss für alle möglichen Änderungen eine Aktivität bei der Modellie-

rung berücksichtigt werden, was die Prozesse stark verkompliziert und der Übersicht schadet.

PHILharmonicFlows stellt dagegen die Anwendungsdaten in den Mittelpunkt. Diese bestim-

men direkt durch ihr Vorhandensein den Prozessfortschritt, wodurch ein ständiger integrierter

Zugang für Datenänderungen und Prozessablaufsteuerungen ermöglicht wird.

Grundlagen PHILharmonicFlows

2.1. Aufbau von PHILharmonicFlows

Das Framework teilt sich in die Modellierungs- und die Laufzeitumgebung auf. Für die weitere

Betrachtung legen wir den Fokus auf die Modellierungsumgebung, deren Entwicklung Aufgabe

dieser Arbeit ist. Die Modellierungsumgebung setzt sich dabei aus drei Hauptkomponenten

zusammen. Diese ermöglichen die Modellierung der Datenstruktur, den Entwurf der Prozess-

struktur und die Vergabe der Benutzerrechte. Die Aufteilung der Hauptkomponenten und die

ihnen zugeordneten Funktionen können der Abbildung 1 entnommen werden.

Abbildung 1.: Die Hauptkomponenten und ihre Funktionen (nach [17])

2.1.1. Datenstruktur

Die Datenstruktur definiert die Anwendungsdaten des Projekts. Sie wird durch die Objektty-

pen, deren Attributen und Relationen gebildet und kann anhand eines relationellen Daten-

modells beschrieben werden. Objekttypen dienen dabei als Container für zusammengehörige

Attribute und sind durch Schlüssel eindeutig identifizierbar. Die Attribute sind als Felder für

einzelne Datenwerte konzipiert und werden durch einen gewählten Datentyp klassifiziert und

einem Namen zur Anzeige definiert.

Einige der modellierten Objekttypen können zueinander in Beziehung stehen. Diese Be-

ziehungen können mittels gerichteter Relationen dargestellt werden, die somit die Ab-

Grundlagen PHILharmonicFlows

hängigkeit der Objektinstanzen zur Laufzeit anhand von 1:n Beziehung beschreiben.

Mittels der Relationen lassen sich die Objekttypen, sofern sich durch die Relationen

kein Zyklus ergibt, hierarchisch nach Ebenen anordnen (siehe Abbildung 2). Der obers-

ten Ebene gehören dabei diejenigen Objekttypen an, die sich nicht auf andere beziehen.

Beim Auftreten eines Zyklus wie links in Abbildung 3 zwischen A, C und F muss dieser vor der

Ebenenermittlung aufgelöst werden. Dazu wird eine Relation als Zyklusrelation markiert und

damit für die Berechnung der Ebenen nicht mehr als ausgehende Beziehung berücksichtigt. So-

mit kann der Zyklus aufgelöst werden und es ist eine hierarchische Anordnung wie im rechten

Teilbild von Abbildung 3 zu sehen möglich, in der die Relation von A nach F markiert wurde.

Bei vielen Prozessen ist es notwendig auf bestimmte Ereignisse, also der Belegung bestimmter

Attribute mit speziellen Werten, gesondert zu reagieren. Diese Möglichkeit wird durch die

Datenkontexte ermöglicht. Zur Definition der Datenkontexte werden logische Ausdrücke

Abbildung 2.: Beispiele für zyklenfreie Datenstruktur

Abbildung 3.: Beispiele für Zyklus Datenstruktur

Grundlagen PHILharmonicFlows

für die einzuschränkenden Attribute des Objekttyps erstellt, anhand derer zur Laufzeit die

Eingaben überprüft werden können. Für die Definition der Datenkontexte kann es notwen-

dig sein auf ein Attribut eines übergeordneten Objekttyps zuzugreifen um den logischen

Ausdruck auf bestimmte Fälle einzuschränken. Um dies zu ermöglichen wurde das Konzept

des virtuellen Attributs eingeführt. Dieses kann in einem Objekttyp angelegt werden und

bietet lesenden Zugriff auf ein ausgewähltes Attribut eines übergeordneten Objekttyps und

kann damit als lediglich lesbarer Zeiger verstanden werden.

Eine Sonderform der Objekttypen sind die Benutzertypen. Diese stellen Benutzer dar, die

mit dem System interagieren können und verwalten somit noch die Zugriffsrechte und Ände-

rungsbefugnisse, die in der Hauptkomponente Benutzerintegration verwaltet werden. Innerhalb

der Datenstruktur werden die Benutzertypen jedoch ebenso wie die Objekttypen behandelt.

Eine zweite Sonderform stellen die Wertetypen da. Diese können jedoch nicht in Relation zu

anderen Objekttypen gesetzt werden und gehören keiner Datenebene an. Sie definieren statt-

dessen Wertebereiche für Attribute, die zur Laufzeit ausgewählt werden können.

2.1.2. Prozessstruktur

In der Prozessstruktur wird der Ablauf des modellierten Prozesses definiert. Diese setzt sich

aus den beiden Teilbereichen Mikro- und Makroprozess zusammen.

Mikroprozess

Jedem Objekttyp ist ein Mikroprozess zugeordnet, der dessen Ausführungsverhalten be-

schreibt. Mikroprozesse werden durch Mikroschritte, Transitionen und Zustände ge-

bildet. Mikroschritte definieren dabei Bedingungen, die für das Fortschreiten des Prozesses

notwendig sind. Dabei kann zwischen leeren, atomaren und wertespezifischen Prozess-

schritten unterschieden werden. Leere Mikroschritte stellen dabei keine Bedingung und

können somit zur Laufzeit immer erreicht werden. Atomaren Mikroschritten sind Attri-

bute zugeordnet. Diesem zugeordneten Attribut muss ein Wert zugewiesen werden, damit

der atomare Mikroschritt erreichbar ist. Wertespezifische Mikroschritte besitzen ebenso

ein zugeordnetes Attribut. Jedoch reicht es hier nicht aus, dass dem Attribut ein beliebiger Wert

zugewiesen wird. Ein wertespezifischer Mikroschritt erfordert einen bestimmten Wert für

das Attribut um erreichbar zu sein. Dieser geforderte Wert wird in einem Mikrowertschritt

des Mikroschritts definiert.

Grundlagen PHILharmonicFlows

Für eine Untergliederung des Mikroprozesses sind zusammengehörige Mikroschritte in Zu-

ständen zusammengefasst. Dabei erhält jeder Zustand einen die Änderungen beschreibenden

Namen.

Mikrotransitionen bilden die möglichen Übergänge zwischen den Mikroschritten ab und

bilden zusammen für jeden Mikroprozess einen gerichteten Graphen von dem Startmikro-

prozessschritt zu den Endmikroprozessschritten. Es kann zwischen internen, externen

impliziten und externen expliziten Transitionen unterschieden werden. Falls Quelle und

Ziel einer Transition demselben Mikrozustand angehören, spricht man von einer internen

Transition. Diese sind immer als implizit eingestuft. Das heißt sie können zur Laufzeit schal-

ten, sobald der folgende Mikroschritt erreichbar ist. Externe Transitionen verbinden dage-

gen Mikroschritte verschiedener Zustände miteinander. Implizite externe Transitionen

können dabei genau wie interne Transitionen schalten, sobald der folgende Mikroschritt

erreichbar ist. Externe explizite Transitionen benötigen dagegen die Bestätigung eines be-

rechtigten Benutzers um zu schalten. Jeder Mikroschritt kann mehrere ausgehende Transiti-

onen besitzen. Da zur Laufzeit jedoch nur eine Transition schalten darf ist jeder Transition

eine eindeutige Prioritätsstufe zugeordnet. Dadurch ist ein eindeutiger Ablauf gewährleistet, da

bei mehreren erfüllbaren Transitionen nur die erfüllbare mit der höchsten Priorität geschaltet

wird.

Schleifentransitionen ermöglichen den Rücksprung zu anderen vorhergehenden Zustän-

den innerhalb des Mikroprozesses. Schleifentransitionen verbinden im Gegensatz zu an-

deren Transitionen zwei Zustände miteinander.

Jeder Mikroprozess besitzt mindestens einen Startzustand mit dem Startmikroschritt

und beliebig viele Endmikrozustände, die jeweils nur einen Endmikroschritt enthalten

dürfen. Mit Erreichen des Endzustands ist der Mikroprozess beendet.

Synchronisation der Mikroprozesse

Innerhalb der Datenstruktur sind die Beziehungen der Objekttypen untereinander definiert.

Diese Abhängigkeiten besitzen zur Laufzeit ebenfalls Auswirkungen auf das Verhalten der Mik-

roprozesse untereinander. So sind Mikroprozessinstanzen höherer Ebenen oft von der Ausfüh-

rung der Instanzen der unteren Ebenen abhängig. Aus diesem Grund müssen die Mikroprozesse

des Gesamtprozesses untereinander synchronisiert werden.

Mittels der Prozesskontexttypen kann dabei festgelegt werden, dass die untergeordneten

Mikroprozesse nur angelegt werden dürfen, solange sich der übergeordnete Mikroprozess in

bestimmten Zuständen aufhält. Im Beispiel in Abbildung 4 ist der Beginn und das Ende des

Grundlagen PHILharmonicFlows

Prozesskontexttyps durch einen gestrichelten Pfeil zwischen den Zuständen Stellenausschrei-

bung und Bewerbungsgespräch dargestellt. Dabei darf beispielsweise ein Bewerbungsgespräch

nur zwischen der 1. Veröffentlichung und dem Ende der Bewerbersuche begonnen werden.

Mikroprozesse sind oft auf Informationen von untergeordneten Mikroprozessinstanzen ange-

wiesen. Da eine Mikroprozessinstanz viele untergeordnete Instanzen besitzen kann müssen die-

se zusammengefasst werden. Dazu dient der Aggregationstyp. Die Aggregation erfolgt dabei

nach dem Fortschritt der untergeordneten Prozesse zu einem ausgewählten Zustand.

Makroprozess

Für die Koordination der Zustände verschiedener Objekttypen untereinander gibt es die Mak-

roprozesse. Jeder Makroschritt ist dabei einem Zustand eines Objekttyps zugeordnet. Somit

können durch Makrotransitionen zwischen den Makroschritten die Abhängigkeiten zwi-

schen Zuständen verschiedener Objekttypen dargestellt werden. Jeder Makroprozess besitzt

genau einen Startmakroschritt und mindestens einen Endmakroschritt.

Das Konzept der Makroinputs ermöglicht die Einmündung verschiedener Makrotransitio-

nen mit verschiedener Semantik in einen Zustand. Dabei ist festgelegt, dass für Makrotransi-

tionen, die in denselben Makroinput münden eine „and“-Semantik gilt und zwischen verschie-

denen Makroinputs eine „or“-Semantik gilt.

Makrotransitionen haben als Ursprung also einen Makroschritt und enden in einem Ma-

kroinput, der zu einem Makroschritt gehört. Rückwärtsgerichtete Transitionen werden

Abbildung 4.: Prozesskontext von Mikroprozess Instanzen

Grundlagen PHILharmonicFlows

bei der Konstruktion als Schleifen erkannt und ausgezeichnet. Sie sind als einzige ausgehende

Transitionen aus den Endmakroschritten und als eingehende Makrotransitionen für

den Startmakroschritt erlaubt.

Makrotransitionen werden anhand der Beziehung der referenzierten Objekttypen ihrer

Quelle und ihres Ziels in „top-down“, „bottom up“, „transverse“ und „self“ eingeteilt.

Dabei beschreibt eine „top down“ Beziehung, dass der Objekttyp des Quellmikrozustands

dem Objekttyp des Zielmikrozustands direkt oder indirekt übergeordnet ist und „bottom-

up“ das Gegenteil davon. „Transverse“ bedeutet, dass sich die beiden beteiligten Objektty-

pen auf einen gemeinsamen Objekttyp zurückführen lassen, jedoch nicht direkt aufeinander.

„Self“ bedeutet, dass Quelle und Ziel der Makrotransition derselbe Objektktyp sind. Somit

ergibt sich für Makrotransitionen die Einschränkung, dass sich die Objekttypen von Quelle

und Ziel auf einen gemeinsamen Objekttyp zurückverfolgen lassen müssen.

2.1.3. Benutzerintegration

Mit der Definition eines Objekttyps als Benutzertyp wird eine neue Benutzerrolle angelegt.

Zur Laufzeit steht jede ihrer Instanzen für einen entsprechenden Anwender.

Benutzerrollen können anhand von Rechtetabellen Lese- und Schreibrechte auf die Attribute

der Objekttypen zugeordnet werden. Diese können in obligatorische und optionale Rechte

unterschieden werden. Dabei wird vom System überwacht, dass für jedes Attribut mindestens

eine Benutzerrolle die Schreibrechte erhält um Deadlocks zu vermeiden.

2.2. Definition eines Anwendungsbeispiels

Um ein besseres Verständnis des Konzepts zu erlangen soll dieses noch anhand eines praktischen

Beispiels anschaulicher dargestellt werden. Als Anwendungsbeispiel wird ein sehr vereinfachter

Bewerbungsprozess verwendet (frei nach [6]). Die einzelnen Stationen des Prozesses sind dabei

vereinfacht in Abbildung 5 dargestellt.

Dabei wird eine Stelle von einer Firma ausgeschrieben für die sich Bewerber mit einem Online-

Formular bewerben können. Zur Entscheidungsfindung holt die Personalabteilung von einem

Mitarbeiter der zuständigen Fachabteilung eine Beurteilung der Bewerbung ein. Die Beurtei-

lung enthält dabei eine Empfehlung ob der Bewerber zu einem Vorstellungsgespräch eingeladen

Grundlagen PHILharmonicFlows

werden soll. Falls die Empfehlung positiv ist erhält der Bewerber anschließend eine Einladung

zum Vorstellungsgespräch.

2.3. Einordnung des Anwendungsbeispiels

Zur Anschauung sollen nun die Einheiten aus dem in Kapitel 2.2 beschriebenen Anwendungs-

beispiel auf das Konzept übertragen werden. Dabei beschränkt sich die Einordnung auf die

in der Arbeit behandelten Themen der Datenstruktur und der Mikroprozesse. Ausgangspunkt

jedes PHILharmonicFlows Prozess ist die Datenstruktur. Diese setzt sich aus den Objekttypen

zusammen. Im Beispiel sind die Stellenausschreibung, die Bewerbung, das Vorstellungsgespräch

und die Beurteilung die Objekttypen. Benutzertypen sind der Bewerber und der Mitarbeiter.

Die modellierte Datenstruktur ist dabei in Abbildung 6 dargestellt. Bewirbt sich ein Bewerber

auf eine Stelle wird eine neue Bewerbung angelegt. Nachdem geprüft worden ist ob die Bewer-

bung die Anforderungen der Stelle erfüllt erfolgt die Beurteilung durch einen Mitarbeiter der

Fachabteilung und bei einer Empfehlung die Einladung zum Vorstellungsgespräch. Um bei der

Erstellung der Beurteilung Redundanzen zu vermeiden muss festgestellt werden, ob es ein Wie-

derbewerber ist. Dafür muss Beurteilung ein virtuelles Attribut auf den entsprechenden Wert in

Bewerbung besitzen. Dieser Spezialfall eines Wiederbewerbers kann durch einen Datenkontext

abgefangen und gesondert behandelt werden.

Für die Stellenausschreibung werden Wertetypen definiert. Die Wertetypen beschreiben dabei

die Anforderungen für eine zugehörige Stelle.

Als Beispiel für den Mikroprozess wollen wir den des Objekttyps Bewerbung herausgreifen. Als

erster Schritt erfolgt die Eingabe der Daten im Formular (Erfassung), anschließend erfolgt

die Bestätigung der Daten (Bestätigung). Diese Schritte sind im Zustand Bewerbung er-

fassen zusammengefasst. Anschließend wird auf das Ergebnis der Beurteilung gewartet (Be-

urteilungeinholen). Wenn das Ergebnis der Beurteilung eine Empfehlung war, schaltet

der wertespezifische Mikroschritt Beurteilung als wahr und der Bewerber wird zu einem

Vorstellungsgespräch eingeladen (Vorstellungsgesprächeinladen). Ansonsten wartet

der Prozess, da der Endzustand Ablehnung nur durch eine explizite Transition verbunden

ist, da eine Ablehnung von einem Mitarbeiter der Personalabteilung persönlich autorisiert wer-

den muss. Im Falle eines erfolgreichen Vorstellungsgesprächs schaltet der wertspezifische Mik-

roschritt Einstellung als wahr und der Prozess endet im Endzustand Zusage, ansonsten

endet er im Endzustand Ablehnung.

Grundlagen PHILharmonicFlows

Abbildung 5.: Der Prozessablauf des Beispielprozesses

Grundlagen PHILharmonicFlows

Abbildung 6.: Datenstruktur des Beispielprozesses

Technische Grundlagen

Dieses Kapitel soll die Entscheidungen für die bei der Implementierung gewählten Technologi-

en erläutern und diese einführen. Darüber hinaus werden einige der wichtigsten verwendeten

Konzepte vorgestellt.

3.1. Auswahl des Frameworks

Als Programmiersprache für die Implementierung war von Beginn an Java festgelegt. Als mög-

liche Bibliotheken für die graphenbasierten Editoren bieten sich damit die beiden quelloffenen

Bibliotheken JGraph[16] und Eclipse GEF[13] an. Dabei fiel die Wahl nach der Evaluation der

beiden auf das Eclipse GEF. Ausschlaggebend für diese Entscheidung war die bessere Dokumen-

tation und Unterstützung durch Foren und Tutorials für GEF. Außerdem bietet GEF eine gute

Integration innerhalb der Eclipse RCP Umgebung, die somit als Plattform für die Entwicklung

des Frameworks genutzt werden konnte.

Bei Eclipse besteht derzeit die Wahl zwischen der Eclipse 3 Generation und Eclipse 4. Eclipse

4 stellt dabei eine flexiblere und durch Cascading Style Sheets (CSS) anpassbare Oberfläche

zur Verfügung. Jedoch liegt der Fokus der Entwicklung noch auf der Eclipse 3 Reihe, sodass

viele Plug-Ins wie zum Beispiel auch das GEF Eclipse 4 noch nicht unterstützen. Somit wird

Technische Grundlagen

die Eclipse 3 Generation in Verbindung mit dem GEF zur Implementierung von PHILharmo-

nicFlows genutzt.

3.2. Das Eclipse Framework

In diesem Kapitel erfolgt eine Betrachtung der Technologien, die als Grundlage für die Imple-

mentierung des PHILharmonicFlows Rahmenwerks dienen. Grundlegendes Programm dabei

ist Eclipse. Einerseits wird es in seiner Ausprägung als integrierte Entwicklungsumgebung (Ec-

lipse IDE) zur Implementierung der Klassen genutzt. Darüber hinaus wird die Eclipse Rich

Client Platform (RCP) mithilfe des Graphical Editing Frameworks (GEF) für die Darstellung

der graphischen Benutzeroberfläche verwendet.

Abbildung 7.: Eclipse Architektur

Technische Grundlagen 

3.2.1. Eclipse

Eclipse[11] ist eine quelloffene Softwareentwicklungsumgebung, die aus einer integrierten Ent-

wicklungsumgebung (IDE) und einem erweiterbaren Plug-In System besteht. Ursprünglich von

IBM als IDE für Java entwickelt wurde Eclipse 2001 schließlich in ein Open-Source Projekt

überführt. Seit 2004 ist die Eclipse Foundation für die Weiterentwicklung zuständig [3].

Nachdem Eclipse zunächst nur als erweiterbare IDE konzipiert war, wurde mit Eclipse 3.0 ein

Systemwechsel auf eine OSGi Service Platform basierende Architektur vollzogen [4]. Seitdem

basiert Eclipse mit „Equinox“ auf einem Kern, der mithilfe von Plug-Ins die Funktionalitäten

zur Verfügung stellt [siehe Abbildung 7]. Eclipse ist somit seitdem keine hartcodierte Gesamt-

lösung, sondern eine flexible, komponentenbasierte Lösung, die durch Hinzufügen weiterer

Plug-Ins in den Plug-In Ordner der Eclipse Umgebung erweitert und angepasst werden kann.

Die Plug-Ins sind vollständig in Java realisiert.

Für die Erstellung der Oberflächen nutzt Eclipse das eigens entwickelte schwergewichtige Stan-

dard Widget Toolkit (SWT). Schwergewichtig heißt, dass es zur Darstellung - ähnlich dem

Abstract Window Toolkit (AWT) aus der Java Standardbibliothek und im Gegensatz zu Swing

(ebenfalls in der Java Standardbibliothek), welches auf jeder Plattform gleich aussieht - die grafi-

schen Elemente des Betriebssystems nutzt. Somit ist Eclipse nicht direkt plattformunabhängig,

wird jedoch für die meisten Systeme und Architekturen bereitgestellt1 und wird daher ebenfalls

als plattformunabhängig bezeichnet. Je nach Verwendungszweck gibt es für die verbreitetsten

Systeme, Windows, Linux und Macintosh, vorkonfigurierte Eclipse Pakete zum Download. Die

derzeit aktuelle Eclipse Distribution ist Eclipse Helios (3.6.2) von Februar 2011.

3.2.2. Eclipse Rich Client Platform

Die Eclipse Rich Client Platform[12] (Eclipse RCP) umfasst den Eclipse Kern und diejenigen

Plug-Ins, die für eine lauffähige Anwendung notwendig sind. Sie bietet damit eine Grundlage

für die Entwicklung beliebiger eigenständiger Anwendungen, sogenannter Rich Client Appli-

cations, auf Basis eines OSGi-Frameworks [5]. Die so erzeugten Anwendungen sind plattform-

übergreifend auf allen Systemen und Architekturen nutzbar, auf denen Eclipse unterstützt wird.

Die Definition der von der Anwendung benötigten Plug-Ins und die Auflistung der von der

Anwendung benutzten Einstiegspunkte (die Modulbeschreibung) ist dabei in der plugin.xml

des Projekts definiert. Das Oberflächendesign wird ebenfalls durch Eclipse verwaltet. Für die

1 Downloadseite: http://archive.eclipse.org/eclipse/downloads/drops/R-3.6.1-201009090800/index.php

Technische Grundlagen

Erstellung der GUI Komponenten verwendet Eclipse die eigene SWT Bibliothek. Da SWT die

Darstellungskomponenten des jeweiligen Betriebssystems nutzt, erhält die erzeugte Anwendung

ohne manuelle Anpassungen ein für die jeweilige Plattform typisches Aussehen.

3.2.3. Eclipse Oberfläche

Die Eclipse Oberfläche [Abbildung 8] bietet verschiedene Möglichkeiten zur Darstellung von

Inhalten. Die wichtigsten Komponenten sind dabei der Editor, die Views und die Perspektiven.

Editor

Der Editorbereich ist der zentrale Bildschirmbereich für die Bearbeitung einer ausgewählten

Datei. Die Darstellung der Daten kann sowohl in Textform, beispielsweise bei einem Quelltext-

editor, wie auch in graphischer Form, zum Beispiel bei einem UML-Editor, erfolgen. Es können

verschiedene Dateien in unterschiedlichen Editoren gleichzeitig geöffnet werden, jedoch darf

es nur einen einzigen Editorbereich je Programmfenster geben in dem die einzelnen Editoren

dann anhand von Tabreitern angeordnet werden.

Abbildung 8.: Die Eclipse Oberfläche

Technische Grundlagen 

View

Views sind frei bewegliche Fenster die durch Drag & Drop frei innerhalb des Programmfens-

ters bewegt, angeordnet, gestapelt und geschlossen werden können. Sie können auch außerhalb

des Hauptfensters als eigenständige Fenster angeordnet werden. Die Views ermöglichen sowohl

die Anzeige von allgemeinen Informationen als auch die Detailanzeige von aktuell im Editor

ausgewählten Objekten. Darüber hinaus können sie allgemeinen Zwecken wie der Navigation

innerhalb einer Ordnerstruktur dienen.

Perspektive

Perspektiven sind festgelegte Anordnungen des Editors und ausgewählter Views auf der Pro-

grammoberfläche. Dabei ist in der Perspektive festgelegt welche Views angezeigt werden und

wie diese auf dem Bildschirm angeordnet werden. Beim Hinzufügen einer neuen View wird

dabei der Bereich einer bestehenden View oder des Editors in einem anzugebenden Verhältnis

gesplittet, sodass die Fläche in zwei kleinere rechtwinklige Bereiche aufgeteilt ist. Durch diese

Vorgehensweise wird verhindert, dass es leere Flächen in einer Perspektive gibt.

3.2.4. Graphical Editig Framework

Das Graphical Editing Framework (GEF)[13] ist ein Framework, welches die Erzeugung gra-

phischer Editoren innerhalb der Eclipse Plattform ermöglicht. Es ist nach dem Model-View-

Controller Entwicklungsmuster [siehe 3.3.3] aufgebaut und macht auch von den Entwurfsmus-

tern der Softwareentwicklung regen Gebrauch. Das GEF besteht aus drei einzelnen Plug-Ins,

wovon Draw2d und das GEF-Plugin für die weitere Betrachtungen im Rahmen dieser Arbeit

wichtig sind.

Draw2d

Draw2d [15] ist ein auf Diagramme spezialisiertes Vektorgraphik-Toolkit für Eclipse. Es ist Teil

des GEF Projekts, kann aber auch eigenständig verwendet werden. Draw2d ist ein nur auf SWT

basierendes leichtgewichtiges Plug-In für die Anzeige graphischer Komponenten. Dabei stellt ein

SWT Canvas die Zeichenfläche bereit auf der die Draw2d-Objekte, sogenannte Figuren (IFigu-

re) platziert werden können. Figuren werden anhand einer Eltern-Kind Beziehung verwaltet, das

Technische Grundlagen

heißt die Elternfigur besitzt Grenzen, in denen sie und ihre Kinder gezeichnet werden können.

Für die Anordnung der Kinder bietet Draw2d verschiedene Layout-Manager zur Auswahl. Für

die graphischen Elemente stehen verschiedene Komponenten wie beispielsweise Rechtecke, Ellip-

sen, Label und Buttons zur Verfügung. Diese können durch Connections miteinander verbunden

werden, deren Wegfindung anhand verschiedener Vorgaben und Arten gestaltet werden kann.

Außerdem können die Connections mit Dekorationen wie Pfeilen oder Labeln versehen werden.

Für einen besseren Überblick ermöglicht es die Erstellung einer Übersicht des Editors durch ein

Thumbnail. Dieses kann in der Outline-View von Eclipse als navigierbares Übersichtsfenster

verwendet werden.

Abbildung 9.: Darstellung Draw2d

GEF -Plugin

Das GEF-Plugin bildet in GEF die Controller Schicht einer MVC-Architektur. Zentrales In-

terface dabei ist das EditPart. Für jedes Modellobjekt, dass im GEF-Editor editiert werden soll,

muss ein EditPart existieren. Bei der Erzeugung des EditParts wird ein Listener für das zugrun-

deliegende Modell eingerichtet, der das EditPart über Änderungen der zugrundeliegenden Da-

ten informiert. Anschließend wird aus dem EditPart die Draw2d Figur für die Darstellung im

Editor erzeugt. Zur Definition der möglichen Operationen auf dem EditPart werden EditPoli-

cies für bestimmte Editieroperationen angelegt. Diese definieren beispielsweise ob die Objekte

verschoben oder skaliert werden dürfen oder welche Kindobjekte darauf abgelegt werden kön-

nen. Ein EditPart kann über mehrere verschiedene EditPolicies verfügen, jedoch ist zu beach-

ten, dass für jede Editieroperation nur eine EditPolicy existieren darf. Die Interaktion zwischen

dem Benutzer und den EditParts erfolgt durch sogenannte Requests, welche die gewünschten

Technische Grundlagen 

Änderungen kapseln. Ein Request wird dabei durch eine Benutzerinteraktion im Editor erzeugt.

Das EditPart leitet das Request dann an die für diesen Typ des Request zuständige EditPolicy

weiter. Anhand der EditPolicy wird daraus ein Command Objekt1 für die gewünschte Aktion

erstellt, das die Informationen zur Ausführung des Vorgangs enthält. Durch die Ausführung der

execute-Methode der Kommando-Klasse erfolgt dann die gewünschte Operation.

3.3. Konzepte

An dieser Stelle sollen verschiedene Begriffe und Konzepte, die für das Verständnis der Arbeit

wichtig sind, erläutert werden.

3.3.1. OSGi Service Platform

Die Spezifikation der OSGi Service Platform wird von der OSGi Alliance herausgegeben und

beschreibt eine dynamische, modulare Softwareplattform für die Java Programmiersprache. Wir

wollen uns hier nur auf die für das Verständnis der Eclipse Architektur nötigen Grundlagen

konzentrieren. Ein OSGi-Framework besteht aus dem Kern und einzelnen Modulen. Die Mo-

dule bestehen dabei in der Regel aus mehreren in verschiedene Pakete aufgeteilte Java-Klassen

und einer Modulbeschreibung, in der auch Abhängigkeiten von anderen Modulen vermerkt

sind. Anhand dieser ist es möglich einzelne Module zur Laufzeit hinzuzufügen, auszutauschen

oder zu löschen. Die OSGi Spezifikation erlaubt somit ein aus einzelnen Modulen bestehendes

dynamisches Gesamtsystem zu entwerfen.

3.3.2. Entwurfsmuster

Entwurfsmuster beschreiben bewährte Vorgehensweisen für häufig auftretende Probleme in der

Softwareentwicklung. Sie beschreiben dabei Lösungsansätze und Wege und bestehen nicht aus

fertigem Code wie Bibliotheken. Sie sind daher programmiersprachenunabhängig verwendbar.

Im Gegensatz zu Architekturmustern, die das globalere Zusammenspiel der Komponenten ei-

ner Anwendung beschreiben, beziehen sich die Entwurfsmuster meist auf kleinere, umrissene

Teilprobleme. Die Verwendung von Entwurfsmustern ist bei der Entwicklung hilfreich, da auf

bereits bestehendes Wissen und Erfahrungen von anderen zurückgegriffen werden kann und

1 siehe „Kommando“ auf Seite 29

Technische Grundlagen

nicht jedes Problem mit einem eigenen neuen Ansatz erschlossen werden muss. Auch erleichtert

es die Beschreibung und Dokumentation der Vorgehensweise indem man auf Bezeichnungen

eines einheitlichen Vokabulars zurückgreifen kann. Die Entwurfsmuster sollten jedoch nicht

als Wundermittel angesehen werden, die die Entwicklung guter Software garantieren. Oft ver-

ursacht der übermäßige Gebrauch von Entwurfsmustern zusätzliche Komplexität der Software

und verhindert einfachere Lösungen. Daher sollte bei der Verwendung der Entwurfsmuster be-

achtet werden, dass sie ein bestehendes Problem lösen und sie nicht nur der Verwendung wegen

Umgesetzt werden.

Populär wurden die Entwurfsmuster in der Softwareentwicklung mit der Veröffentlichung des

Buchs „Design Patterns“ der sogenannten Viererbande1 im Jahr 1994.

Kurzbeschreibung verschiedener Entwurfsmuster

Um ein besseres Verständnis und einen besseren Überblick zu gewinnen, sollen hier im Folgen-

den verwendete Entwurfsmuster vorgestellt werden.

Beobachter

Das Beobachter-Entwurfsmuster kann verwendet werden, wenn abhängige Klassen (Beobach-

ter) über Änderungen einer Klasse (Subjekt) informiert werden sollen. Der Aufbau des Beob-

1 (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)

+registriere(eing. Beobachter)

+deregistriere(eing. Beobachter)

+benachrichtige()

Subjekt

+aktualisiere()

AbstrakterBeobachter

+aktualisiere()

KonkreterBeobachter

1 *

Abbildung 10.: Klassendiagramm des Beobachter-Entwurfsmusters

Technische Grundlagen 

achter Entwurfmusters ist in Abbildung 10 dargestellt. Die Beobachter registrieren sich dabei

im Subjekt. Das Subjekt schickt bei einer Änderung seines Zustands einen Broadcast an die Ak-

tualisierungsmethode aller registrierten Beobachter, die auf diese Nachricht dann entsprechend

reagieren können.

Kommando

Das Kommando-Entwurfsmuster unterstützt die Ausführung von Befehlen. Dazu werden alle

für den gewünschten Vorgang benötigten Daten in einem Kommando-Objekt gespeichert, die

in einer zentralen Kommando Liste verwaltet werden. Die tatsächliche Ausführung des Kom-

mandos kann dadurch unabhängig von der Erstellung des Kommandos stattfinden. Durch die

Nicht

ausgeführte

Kommandos

ausgeführte

Kommandos

redo

undo

Abbildung 11.: Verwaltung der Kommandos

zusätzliche Speicherung der zur Umkehrung notwendigen Daten in den Kommando-Objektetn

ist ein Rückgängig-Mechanismus möglich. Dazu müssen nur die ausgeführten Kommandos

zusätzlich in einer zweiten Kommandoliste gespeichert werden. Durch Aufruf der Rückgängig-

Methode werden die Befehle wieder zurückgesetzt und das Kommando in die ursprüngliche

Liste zurückverschoben (siehe Abbildung 11).

3.3.3. Model-View-Controller-Architektur

Model-View-Controller (MVC) ist ein Muster der Softwaretechnik, welches die Datenlogik

vom Benutzerinterface trennt und somit eine unabhängige Entwicklung voneinander erlaubt.

Es wird heutzutage den Architekturmustern und nicht den Entwurfsmustern zugeordnet. Das

Technische Grundlagen

Muster sieht dabei die Aufteilung in die drei Einheiten Datenmodell (model), Präsentations-

schicht (view) und Steuerung (controller) vor. Abbildung 12 zeigt eine Übersicht über das Zu-

sammenspiel der Teilbereiche des Konzepts.

Das Modell verwaltet dabei die darzustellenden Daten und bietet die Methoden zur Änderung

und zum Abruf der Daten an. Bei Änderungen der anzuzeigenden Daten des Modells werden

die Controller benachrichtigt. Das Modell ist der einzige Speicherort für die persistenten Da-

ten.

Die View ist als Präsentationsschicht für die Darstellung der Modelldaten zuständig. Im GEF

besteht sie aus Draw2d Figuren. Ebenfalls Aufgabe der View ist es die Benutzerinteraktionen an

den Controller weiterzugeben.

Der Controller dient als Bindeglied zwischen der View und dem Modell. Dabei nimmt er die

von der View gemeldeten Benutzerinteraktionen entgegen und führt am Modell die zugeordne-

ten Methoden aus. Auch reagiert er auf Änderungsmeldungen der Modelldaten und aktualisiert

die View entsprechend. Der Controller ist somit der zentrale Punkt der Architektur, der sowohl

Modell als auch View kennt. In GEF wird er durch EditParts im GEF-Plugin realisiert.

Abbildung 12.: Das MVC-Konzept in Eclipse[2]

Überblick Oberfläche

Dieses Kapitel bietet einen kurzen Überblick über die Gestaltung der Benutzeroberfläche des

implementierten Frameworks, um die Einordnung der Implementierungsdetails zu erleichtern

und die Zusammenhänge zu veranschaulichen. Als Ausgangsbasis für die Umsetzung der Benut-

zeroberfläche von PHILharmonicFlows dient das Usability-Konzept von Nicole Wagner[17].

Abbildung 13.: Benutzeroberfläche bei Programmstart

Überblick Oberfläche

Auf die Hintergründe für die Unterschiede und Abweichungen wird später in Kapitel 6.2 ge-

nauer eingegangen.

4.1. Anfangsbildschirm

Zum Programmstart bietet sich dem Benutzer die zu diesem Zeitpunkt noch weitgehend de-

aktivierte Oberfläche wie in Abbildung 13. Die Oberfläche unterteilt sich in die drei Bereiche

Sidebar (rot umrandet), Editorbereich (gelb) und Eigenschaftsfenster (blau). Die Sidebar be-

steht wiederum aus drei einzelnen Teilfenstern, die ihre Funktionalität aber erst bei einem ge-

öffneten Projekt erhalten. Die Teilbereiche sind die „Outline“, die eine verkleinerte Übersicht

über den aktiven Editor bietet, das „Problems“ Fenster, in dem Fehlernachrichten gesammelt

werden und der „Palette“, die Werkzeuge für die geöffneten Editoren anbietet und die Aus-

wahl des gewünschten Editors ermöglicht. Geschlossene Fenster lassen sich über das „Window“

Menu wieder herstellen.

Um ein Projekt zu öffnen kann entweder ein neues mit dem Assistenten im „File“ Menu begon-

nen werden, oder ein bereits bestehendes über den „Open“ Dialog im „File“ Menu ausgewählt

werden. Mit dem Öffnen eines Projekts startet der Editor für die Datenstruktur.

Abbildung 14.: Ansicht der Palette

Überblick Oberfläche

Abbildung 15.: Objekttypen-Editor

4.2. Palette

Die Navigation zwischen den einzelnen Editoren ermöglicht die Palette in der Sidebar, die in

Abbildung 14 einzeln zu sehen ist. Um die Navigation zu vereinfachen sind inhaltlich zusam-

mengehörige Editoren innerhalb eines Hauptreiters zusammengefasst. Um die Unterscheidung

zu vereinfachen sind die Hauptreiter durch ein Symbol vor der Ebenenbezeichnung hervorge-

hoben. Innerhalb einer aktivierten Hauptkomponente sind die zugehörigen Reiter der Unter-

komponente, die jeweils den zugehörigen Editor öffnen, sichtbar. Dabei ist der jeweils aktive

Palettenreiter aus Gründen der Übersichtlichkeit farblich hervorgehoben. Unterhalb des akti-

vierten Palettenreiters werden die Modellierungselemente für den gewählten Editor angeboten.

4.3. Oberfläche der Datenstruktur

Unterhalb der Datenstruktur Hauptreiter der Palette besteht die Wahl zwischen dem Objekt-

typen-Editor und dem Wertetypen-Editor. Dabei ist der Objekttypen-Editor der zentrale Aus-

gangspunkt jedes Projekts, da hier mindestens ein Objekttyp angelegt werden muss, um weiter-

zuarbeiten.

Überblick Oberfläche

4.3.1. Objekttypen-Editor

Abbildung 15 zeigt das Framework mit geöffnetem Objekttypen-Editor. Im Editorfenster kann

nun mit den in der Palette angebotenen Elementen „Object Type“ für Objekttypen und „Rela-

tion Type“ für Relationen die Datenstruktur modelliert werden. Dazu werden diese ausgewählt

und im Editorfenster platziert. Die Objekttypen werden dabei im Editor als Rechtecke und die

Relationen als Pfeile zwischen den Rechtecken dargestellt. Zur Unterscheidung der Objekttypen

werden deren Namen mittig innerhalb der angezeigten Recktecke angezeigt. Zusätzlich wird in

der oberen linken Ecke angezeigt ob und wie viele Datenkontexte zum Objekttyp existieren und

rechts oben eine Figur, falls der Objekttyp als Benutzertyp typisiert ist. Alle Eigenschaften des

ausgewählten Objekts werden zusätzlich detailliert im Eigenschaftsfenster unterhalb des Editors

angezeigt. Dieses ist für eine einfachere Übersicht in mehrere Tabs unterteilt. Der gerade ausge-

wählte Objekttyp ist im Editor wie in Abbildung 15 („ObjectType1“ ist hier ausgewählt) zu er-

kennen mit einem blauen Rahmen markiert: Falls eine Relation ausgewählt ist, wird diese durch

zwei schwarze Punkte an den Enden hervorgehoben. In der „Outline“ in der Sidebar wird eine

navigierbare Übersicht über den Inhalt des Editorfensters gezeigt. Falls im Editor nicht der ge-

samte Bereich angezeigt werden kann, ist dabei der gerade dargestellte Bereich farbig hinterlegt.

Abbildung 16.: Ansicht des Wertetypen-Editors

Überblick Oberfläche

4.3.2. Wertetypen-Editor

Im Wertetypen-Editor erfolgt die Definition der Wertetypen, mit denen Wertebereiche einzelner

Attribute beschrieben werden können. Wie in der Abbildung 16 zu sehen ist, werden bei geöff-

netem Wertetypen-Editor in der Palette keine zugehörigen Modellierungselemente angeboten.

Dies erübrigt sich, da die Editoroperationen direkt über Schaltflächen im Editorbereich erfol-

gen. Zu Beginn ist der Editorbereich bis auf eine Titelzeile leer. Diese bietet links ein Suchfens-

ter, welches die Navigationsfunktion der ausgegrauten „Outline“ ersetzt. Auf der rechten Seite

der Leiste befindet sich eine Schaltfläche zum Erzeugen neuer Wertetypen. Für jeden erzeugten

Wertetyp wird eine sogenannte Sektion erstellt, die sich dem Benutzer zuerst als Textzeile mit

dem Namen des Wertetyps zeigt. Falls der Name angeklickt wird öffnet sich der Wertetyp wie in

Abbildung 16 bei „value type2“ zu sehen. Innerhalb der nun ausgeklappten Sektion bietet sich

dem Benutzer eine Tabelle mit Schaltflächen zur Bearbeitung des Wertetyps. Als Orientierung

für den Benutzer ist die Titelzeile des ausgewählten Wertetyps farbig hinterlegt.

4.4. Prozessstruktur

Innerhalb der Prozessstruktur Kategorie befindet sich der Mikroprozess-Editor. Dabei teilt sich

der Editorbereich, wie in Abbildung 17 sichtbar, in zwei Teilfenster auf. Der obere Bereich,

der sogenante Strukturkompass zeigt eine Übersicht der Datenstruktur. In diesem wird der ge-

wünschte Objekttyp ausgewählt, der im darunter befindlichen Editor bearbeitet werden kann.

Bei der Platzierung der Modellierungselemente muss beachtet werden, dass die Zustände (State

Type) nur direkt auf der Editorfläche und die Mikroschritte ( Micro Step) nur innerhalb von

Zuständen platziert werden können. Dies vereinfacht im Gegensatz zu einem freien Platzieren

mit einer nachträglichen Zuordnung mögliche Fehler bereits in der Konstruktion, die der Be-

nutzer dann nicht im Nachhinein beheben muss. Als Hilfestellung bei der Konstruktion der

Mikrotransitionen dienen die Halbkreise an den Seiten der Mikroschritte. Der Start-Mikro-

schritt besitzt als einziger Schritt keinen Halbkreis auf der linken Seite um deutlich zu signalisie-

ren, dass keine eingehende Transition möglich ist. Der Halbkreis auf der rechten Seite wird bei

allen Mikroschritten ausgeblendet, die alle Bedingungen für einen möglichen End-Mikroschritt

erfüllen. Die Zuordnung von Attributen zu den Mikroschritten erfolgt durch einen Mausklick

auf das hervorgehobene Feld innerhalb des Mikroschritts. Daraufhin öffnet sich das in Abbil-

dung 17 rechts unten zu sehende Auswahlfenster, aus dem die gewünschte Referenz ausgewählt

Überblick Oberfläche

werden kann. Mikrowertschritte für einen ausgewählten Mikroschritt können über das Eigen-

schaftsfenster angelegt und gelöscht werden.

Abbildung 17.: Der Mikroprozess-Editor

Implementierung

Die Implementierung des Tools erfolgt innerhalb des Eclipse RCP [siehe 3.2.2]. Dabei wurden

die Editoren der Arbeitsfläche teilweise mithilfe des GEF [siehe 3.2.4] implementiert und ba-

sieren auf der Model-View-Controller Architektur [siehe Seite 29]. Die Klassen sind somit in die

Daten-Klassen, die den Modell Teil des MVC-Konzepts beschreiben und die Oberflächenklas-

sen aufgeteilt. Die Oberflächenklassen beinhalten dabei sowohl die View als auch die Controller

Komponente der MVC Architektur. Zur Veranschaulichung der Zusammenhänge werden un-

ter anderem UML-Diagramme eingesetzt, die mit dem Programm UModel von Altova1 erstellt

sind.

5.1. Implementierung Paketstruktur

Bevor auf die Besonderheiten der einzelnen Klassen eingegangen wird, erfolgt zuerst ein Über-

blick über deren Aufgliederung. Bei der Implementierung entstanden eine Vielzahl verschie-

dener Klassen die für verschiedene Zwecke notwendig sind. Für eine bessere Übersicht über

die Quellcodeklassen wurden diese anhand ihrer Verwendung systematisch in Pakete aufgeteilt.

1 UML Modellierungstool von Altova, welches alle 14 Diagrammtypen der UML 2.3 Spezifikation unter-

stützt.

Implementierung

Abbildung 18 bietet zur Veranschaulichung eine Übersicht über die für das Framework erstellten

Pakete. Um diese übersichtlicher zu strukturieren wurde versucht diese anhand einer einheitli-

chen Systematik zu untergliedern. Diese Untergliederung erfolgt durch mehrere Hauptpakete,

die zusammengehörige Unterpakete bündeln. Die Einteilung wurden dabei anhand der Funk-

tion der Pakete und der Einordnung zu den Hauptkomponenten des Konzepts vorgenommen.

Im folgenden soll zur Erleichterung ein kurzer Überblick über die Systematik der Gliederung

gegeben werden. Eine genaue aufgegliederte Beschreibung der einzelnen Pakete ist im Anhang

„A“, „Überblick über die Paketstruktur“ zu finden.

Abbildung 18.: Paketdiagramm

«namespace»

dialog

(from com::proebstle::wf::philharmonic::model::processStructure)

«namespace»

editPolicies

(from com::proebstle::wf::philharmonic::model::processStructure)

«namespace»

editParts

(from com::proebstle::wf::philharmonic::model::processStructure)

«namespace»

commands

(from com::proebstle::wf::philharmonic::model::processStructure)

«namespace»

provider

(from com::proebstle::wf::philharmonic::model::processStructure)

«namespace»

exceptions

(from com::proebstle::wf::philharmonic::model::processStructure)

«namespace»

properties

(from com::proebstle::wf::philharmonic::model::processStructure)

«namespace»

provider

(from deprecatedcom::proebstle::wf::philharmonic::model::tables)

«namespace»

properties

(from com::proebstle::wf::philharmonic::model::dataModel)

«namespace»

exceptions

(from com::proebstle::wf::philharmonic::model::dataModel)

«namespace»

editPolicies

(from com::proebstle::wf::philharmonic::model::dataModel)

«namespace»

commands

(from com::proebstle::wf::philharmonic::model::dataModel)

«namespace»

actions

(from com::proebstle::wf::philharmonic::model::dataModel)

«namespace»

editParts

(from com::proebstle::wf::philharmonic::model::dataModel)

«namespace»

tables

(from deprecatedcom::proebstle::wf::philharmonic::model)

«namespace»

tools

(from deprecatedcom::proebstle::wf::philharmonic::editor)

«namespace»

properties

(from com::proebstle::wf::philharmonic::model::general)

«namespace»

editor

(from deprecatedcom::proebstle::wf::philharmonic)

«namespace»

model

(from deprecatedcom::proebstle::wf::philharmonic)

«namespace»

editPolicies

(from com::proebstle::wf::philharmonic::view s)

«namespace»

structureCompass

(from com::proebstle::wf::philharmonic::view s)

«namespace»

proces s Structur e