Konzeption, Implementierung und Integration einer Komponente für die Erstellung intelligenter Formulare [original]

Fakultät für Ingenieurwissenschaften und Informatik

Institut für Datenbanken und Informationssysteme

Diplomarbeit

Konzeption, Implementierung und

Integration einer Komponente für

die Erstellung intelligenter Formulare

Florian Micheler

9. Juni 2009

1. Gutachter: Prof. Dr. Manfred Reichert

2. Gutachter: PD Dr. Stefanie Rinderle-Ma

Betreuer: Dipl.-Inf. (U) Ulrich Kreher

Kurzfassung

Geschäftsprozesse in Unternehmen werden immer umfangreicher. Aus diesem Grund

werden schon lange computergestützte Systeme zu deren Umsetzung eingesetzt. Dadurch

ist es möglich, auch sehr komplexe Prozesse kontrollieren zu können. Die zunehmende

Komplexität ist aber nicht das einzige Problem. Es können neue Prozesse hinzukommen,

welche eine komplett andere Semantik haben; der Ablauf von vorhandenen Prozessen

kann sich ändern. Daher setzen bereits viele Unternehmen bei der Umsetzung ihrer Ge-

schäftsprozesse auf moderne Business-Process-Management-Systeme (BPM-Systeme).

Diese Systeme sind auf die Gestaltung und Ausführung von Prozessen spezialisiert.

Ein wichtiger Aspekt bei der Ausführung von Prozessen stellt die Interaktion von Pro-

zessen mit dem Benutzer dar. Diese Benutzer kommen dabei aus sehr unterschiedlichen

Branchen. Die Interaktion mit dem BPM-System muss daher so gestaltet sein, dass sich

alle Benutzer damit zurecht finden. Ein adäquates Mittel für eine unkomplizierte In-

teraktion stellen Formulare dar. Durch Formulare können dem Benutzer Informationen

zur Verfügung gestellt oder von diesem entgegengenommen werden.

Neben einer einfache Handhabung gibt es jedoch noch weitere Anforderungen an For-

mulare. Formulare müssen ausreichend flexibel sein, um auch komplexeres Verhalten

zu ermöglichen, beispielsweise um den Benutzer auf falsche Eingaben aufmerksam zu

machen. Ein weiterer wichtiger Aspekt ist eine einheitliche Darstellung der Formulare

innerhalb eines Unternehmens. Diese müssen immer gleich aufgebaut sein, unabhängig

davon, wo sich ein Mitarbeiter befindet und auf welcher Plattform die Formulare dar-

gestellt werden.

Die vorliegende Diplomarbeit befasst sich mit der Konzeption einer Softwarekompo-

nente, welche in der Lage ist, solche Formulare zu erstellen und darzustellen. Diese

Komponente besteht aus einer Entwicklungs- und einer Ausführungsumgebung. Die

Entwicklungsumgebung dient der einfachen und schnellen Erstellung von Formularen.

Die Ausführungsumgebung kümmert sich um die korrekte Darstellung der Formulare

in unterschiedlichen grafischen Umgebungen. Die Komponente wird prototypisch imple-

mentiert und in ein vorhandenes BPM-System integriert. Hierfür wird der Prototyp von

ADEPT2 verwendet. Bei ADEPT2 handelt es sich um ein BPM-System der nächsten

Generation, welches an der Universität von Ulm [Ulm09] unter der Leitung von Prof.

Dadam und Prof. Reichert entwickelt wurde.

Im Rahmen diese Arbeit werden auch vorhandene Produkte untersucht, die eine ähn-

liche Funktionalität zu der erstellenden Softwarekomponente bereitstellen. Dabei wird

geprüft, welche Produkte für das Erstellen von Formularen geeignet sind und ob sie sich

gegebenenfalls im Rahmen dieser Arbeit verwenden lassen.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation............................. 1

1.2 Aufgabenstellung ......................... 5

1.3 Aufbau............................... 5

2 Grundlagen 7

2.1 Grundlagen von BPM-Systemen . . . . . . . . . . . . . . . . . 7

2.1.1 Der Informationsbegriff . . . . . . . . . . . . . . . . . . 7

2.1.2 Benutzer eines BPM-Systems . . . . . . . . . . . . . . 8

2.1.3 Verwendung eines BPM-Systems . . . . . . . . . . . . 8

2.2 Unterstützung von Formularen bei ADEPT2 . . . . . . . . . . 12

2.3 Anwendungsintegration . . . . . . . . . . . . . . . . . . . . . . 13

2.4 JavaScript............................. 15

2.4.1 Allgemeine Einführung . . . . . . . . . . . . . . . . . . 16

2.4.2 JavaScript ausserhalb eines Web-Browsers . . . . . . . 18

2.5 Grafische Kontexte . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.1 Allgemeines........................ 20

2.5.2 Oberflächenentwicklung mit SWT . . . . . . . . . . . . 20

3 Anforderungen an eine Komponente zur Formularerstellung 25

3.1 Problemstellung.......................... 25

3.2 Anforderungen .......................... 30

3.2.1 Nichtfunktionale Anforderungen . . . . . . . . . . . . . 30

3.2.2 Funktionale Anforderungen . . . . . . . . . . . . . . . 36

3.3 Zusammenfassung......................... 54

4 Evaluierung vorhandener Systeme 57

4.1 Existierende Technologien und Produkte . . . . . . . . . . . . 57

4.2 Vergleichskriterien . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3 Vergleich.............................. 60

4.3.1 Inubit ........................... 60

4.3.2 Adobe Lifecycle . . . . . . . . . . . . . . . . . . . . . . 63

4.3.3 Microsoft Infopath . . . . . . . . . . . . . . . . . . . . 66

4.3.4 JAXFront ......................... 71

4.3.5 WJPForm ........................ 76

4.3.6 XForms .......................... 80

4.4 Fazit................................ 84

5 Entwurf einer Komponente zur Formularerstellung 87

5.1 Architektur ............................ 87

5.1.1 Aufbau........................... 87

5.1.2 Ablauf........................... 89

5.2 Entwurf des Datenmodells . . . . . . . . . . . . . . . . . . . . 92

5.2.1 Datentypen ........................ 92

5.2.2 Werte ........................... 95

5.2.3 Formularfelder . . . . . . . . . . . . . . . . . . . . . . . 95

5.2.4 Formularmodell . . . . . . . . . . . . . . . . . . . . . . 105

5.3 Entwurf der Entwicklungsumgebung . . . . . . . . . . . . . . . 107

5.3.1 Editoren für Datentypen . . . . . . . . . . . . . . . . . 108

5.3.2 Editor für Werte . . . . . . . . . . . . . . . . . . . . . 109

5.3.3 Editor für Anwendungslogik . . . . . . . . . . . . . . . 110

5.3.4 Editor für Composite Definition und Formularmodelle . 111

5.3.5 Assistent..........................113

5.4 Entwurf der Laufzeitumgebung . . . . . . . . . . . . . . . . . 114

5.4.1 Modellanpassung . . . . . . . . . . . . . . . . . . . . . 114

5.4.2 Modellübersetzung . . . . . . . . . . . . . . . . . . . . 115

5.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 122

6 Umsetzung der Konzepte 125

6.1 Datatyp ..............................125

6.2 Value................................126

6.3 Script ...............................128

6.4 FormCompositeDefinition . . . . . . . . . . . . . . . . . . . . 129

6.5 FormComposites .........................130

6.6 Reference .............................131

6.7 Form................................132

7 Zusammenfassung und Ausblick 135

7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 135

7.2 Ausblick..............................136

A Abbildungsverzeichnis vii

B Quellcodeverzeichnis ix

C Tabellenverzeichnis xi

D Literaturverzeichnis xiii

1 Einleitung

1.1 Motivation

Seit vielen Jahren vertrauen Unternehmen auf computergestützte Systeme,

die bei der Umsetzung von Geschäftsprozessen helfen. In großen Unterneh-

men werden diese Prozesse jedoch immer komplexer und daher immer schwe-

rer zu beherrschen. Hinzu kommt, dass sich Prozesse ändern können, was auch

Auswirkung auf die Software dieser Systeme hat.

Eine Möglichkeit, die Komplexität zu bewältigen, ist für jeden Prozess eines

Unternehmens eine individuelle Software zu entwickeln. Der Prozess dient

dabei als Anforderung für die neue Software. Dadurch wird eine optimale

Anpassung der Software an das jeweilige Umfeld gewährleistet. Allerdings

hat dieses Verfahren einige Nachteile:

1. Die Entwicklung individueller Software erfordert ausgebildetete Infor-

matiker und Softwareingenieure. Dieser Bedarf steigt mit der Komplex-

ität des Prozesses, was zu hohen Personalkosten führt.

2. Unternehmen, die nicht in der Lage sind die Entwicklung selbst durch-

zuführen, lagern diese in Softwarehäuser aus, welche sich jedoch erst

mit der Semantik der Geschäftsprozesse und den internen Abläufen des

Unternehmens vertraut machen müssen. Dies führt neben den hohen

Kosten zusätzlich zu einem hohen zeitlichen Aufwand für das Unter-

nehmen.

3. Es gibt keine Trennung von Prozesslogik und Anwendungslogik. Dies

erschwert Anpassungen der Software, wenn sich der Ablauf des Ge-

schäftsprozesses verändert. Daraus wiederum ergeben sich hohe Fol-

gekosten durch eine aufwendige Wartung der Software.

Aufgrund dieser Nachteile setzen immer mehr Firmen auf den Einsatz von

modernen Business-Process-Management-Systemen (BPM-Systemen). Diese

Systeme verfolgen andere Paradigmen als traditionelle Softwareentwicklung:

Anstatt eine eigene Software speziell für jeden einzelnen Geschäftsprozess

neu zu programmieren, werden diese Prozesse bei BPM-Systemen modelliert.

Dies führt zu einer klaren Trennung zwischen Prozess- und Anwendungslo-

gik (Abbildung 1). Die Prozesslogik beschreibt darin den Kontrollfluss des

Geschäftsprozesses. Damit wird festgelegt, welche Prozessschritte in welcher

Reihenfolge ausgeführt werden. Die Anwendungslogik hingegen beschreibt

den internen Ablauf eines Prozessschrittes. Sie ist in Form einzelner Anwen-

1 Einleitung

Waren

aussuchen Kundendaten

anlegen

Kundendaten

abrufen Ware

versenden Rechnung

versenden

Kunden nach

Daten fragen

Prozesslogik

Anwendungslogik

Name: Mustermann

Vorname: Max

KontoNr.: 1234567

Blz: 987654

Kreditkarte: Viso

Bank: Spaßkasse

Name: Mustermann

Vorname: Max

KontoNr.: 1234567

Blz: 987654

Kreditkarte: Viso

Bank: Spaßkasse

Name: Mustermann

Vorname: Max

KontoNr.: 1234567

Blz: 987654

Kreditkarte: Viso

Bank: Spaßkasse

Schnapps..........50,00

Bier...................25,00

Wein.................30,00

Säfte.................15,00

Gesamt..........120,00

------------------------------

=============

Abbildung 1: Trennung von Prozess- und Anwendungslogik

dungsbausteine in den Prozess integriert und kann mit Hilfe der Prozess-

logik beliebig kombiniert werden, um die unterschiedlichsten Geschäftspro-

zesse umzusetzen. Diese Trennung hat gegenüber der traditionellen Software-

entwicklung einige entscheidende Vorteile:

Zum Einen sind hier Wartbarkeit, Erweiterbarkeit und Anpassbarkeit zu

nennen. Bei Änderungen eines Geschäftsprozesses ist es beispielsweise aus-

reichend, den Kontrollfluss entsprechend anzupassen. Eine Änderung von

Quellcode ist nicht erforderlich, solange sich der interne Ablauf eines Pro-

zessschrittes nicht ändert.

Zum Anderen ist für die Modellierung kein ausgebildeter Informatiker not-

wendig. Um ein Modell des Prozesses zu erstellen oder zu ändern, reicht ein

Mitarbeiter, der mit der Semantik des Prozesses vertraut ist. Dies führt zu

einer erheblichen Senkung der Kosten und des zeitlichen Aufwands.

Bei den Prozessschritten werden unter anderem zwei Typen unterschieden:

•Prozessschritte für die Benutzerinteraktion

•Prozessschritte für die Datenverarbeitung

Bei den Prozessschritten für die Benutzerinteraktion geht es um den Aus-

tausch von Informationen zwischen Endanwender und System. Ein einfaches

Mittel hierfür stellen Formulare dar. Diese beinhalten Felder, die einerseits

dem Endanwender Informationen präsentieren und diesem andererseits die

Möglichkeit bieten, Daten einzugeben. Formulare sind einfach zu erstellen

1.1 Motivation

Formular:

Vorname: Max

Nachname: Mustermann

Anschrift:

Geburtsdatum:

sonstige Informationen

Formular:

Vorname: Max

Nachname: Mustermann

Anschrift:

Geburtsdatum:

sonstige Informationen

Formular:

Vorname: Max

Nachname: Mustermann

Anschrift:

Geburtsdatum:

sonstige Informationen

Formular:

Vorname: Max

Nachname: Mustermann

Anschrift:

Geburtsdatum:

sonstige Informationen

Prozessschritt

mit Formular

Prozessschritt für

Datenverarbeitung

Prozessschritte mit Formularen

und anschliessender Prüfung

der Eingaben

Abbildung 2: Prozess mit Dateneingaben und Datenverarbeitung

und zeigen den Endanwendern eine einheitliche Oberfläche. Formulare sind

daher ein festes Konzept vieler BPM-Systeme. Allerdings enthalten Formul-

are in vielen Systemen kaum Anwendungslogik oder die Integration der An-

wendungslogik geht zu Lasten der Bedienbarkeit.

Es gibt jedoch auch Prozessschritte, bei denen eine einfache Interaktion nicht

ausreichend ist. Dies ist beispielsweise der Fall, wenn fehlerhafte Eingaben

des Endanwenders erkannt werden sollen oder die eingegebenen Daten auf-

bereitet werden müssen, bevor sie an das System übergeben werden. Solche

Anforderungen sind durch Formulare nicht optimal abgedeckt und benötigen

zusätzliche Anwendungslogik.

Um diese Anforderungen dennoch zu erfüllen, werden zusätzlich Prozess-

schritte zur Datenverarbeitung in den Kontrollfluss des Geschäftsprozesses

integriert. Diese Prozessschritte erlauben die Integration zusätzlicher Anwen-

dungsbausteine, welche die benötigte Logik bereitstellen. Um die beispiel-

haft genannten Anforderungen umzusetzen, entwirft der Prozessmodellierer

einen Prozessschritt mit einem Formular, welches die Eingaben des End-

anwender entgegennimmt. Dem nachfolgenden Prozessschritt ordnet dieser

Prozessmodellierer einen Anwendungsbausteine zu, welche die eingegebenen

Daten prüft und gegebenenfalls auch weiterverarbeitet. Abbildung 2 zeigt

einen Prozess mit mehreren Formularen und datenverarbeitenden Prozess-

schritten. Dieses Vorgehen führt jedoch zu Nachteilen:

1. Die Anwendungsbausteine, welche die zusätzlich benötigte Logik ent-

halten, müssen zunächst entwickelt werden. Im beschriebenen Beispiel

muss ein Anwendungsbaustein entwickelt werden, welche die Einga-

1 Einleitung

Formular:

Vorname: Max

Nachname: Mustermann

Anschrift:

Geburtsdatum:

sonstige Informationen

Formular:

Vorname: Max

Nachname: Mustermann

Anschrift:

Geburtsdatum:

sonstige Informationen

Prozessschritt

mit intelligentem

Formular

Abbildung 3: Vereinfachter Prozess mit intelligenten Formularen

ben des Endanwenders im vorangegangenen Prozessschritt auf deren

Korrektheit hin überprüft. Dies bringt wiederum die Nachteile der tra-

ditionellen Softwareentwicklung mit sich, wie beispielsweise der Bedarf

an qualifiziertem Personal und hohe Kosten.

2. Prozessschritte mit Formularen, die zusätzliche Logik erfordern, müssen

in mehrere Prozessschritte aufgeteilt werden, was die Komplexität des

Prozesses unnötig erhöht. Das Abfragen der Benutzereingaben und

deren Prüfung ist semantisch gesehen ein einziger Schritt. Um diesen

umsetzen zu können, sind jedoch zwei Prozessschritte notwendig.

Ein neuer Ansatz zur Bewältigung der genannten Probleme ist die Verwen-

dung von „intelligenten“ Formularen. Sie bieten wie herkömmliche Formulare

eine einfach erstellbare Oberfläche. Zusätzlich ist eine Integration von An-

wendungslogik in den Formularen möglich, beispielsweise durch ausführbare

Skripte. Dies erhöht die Funktionalität und verringert damit den Bedarf an

zusätzlichen Prozessschritten. Für eine Prüfung der Eingaben eines Endan-

wender muss damit kein separater Anwendungsbaustein entwickelt und in

den Prozess eingebunden werden. Das Formular kann diese Prüfung selbst

durchführen.

Prozessschritte welche sich hauptsächlich mit der Datenverarbeitung beschäf-

tigen, können durch intelligente Formulare nicht ersetzt werden. Diese For-

mulare helfen jedoch datenverarbeitende Prozessschritte einzusparen und

vereinfachen damit die Prozesslogik eines Geschäftsprozesses. Abbildung 3

zeigt den selben Prozess, der auch in Abbildung 2 zu sehen ist. Es wurden

1.2 Aufgabenstellung

jedoch einige Prozessschritte durch intelligente Formulare ersetzt um den

Prozess zu vereinfachen.

1.2 Aufgabenstellung

Im Rahmen dieser Arbeit wird eine Softwarekomponente entwickelt, mit

deren Hilfe intelligente Formulare für Prozessschritte erstellt und dargestellt

werden können.

Dafür wird untersucht, welche Anforderungen an solche Formulare gestellt

werden. Hierzu zählen die Unterstützung von Formularfeldern für einfache

und komplexe Datentypen sowie Listen, das Darstellen der Formulare mit

unterschiedlichen Oberflächenbibliotheken sowie eine mögliche Automatisie-

rung des Erstellvorgangs. Dabei ist auch zu evaluieren, inwieweit die externe

Anbindung von Datenquellen sinnvoll ist.

Basierend auf diesen Anforderungen werden existierende Konzepte und Lö-

sungen bezüglich der Anforderungen detailliert diskutiert. Falls diese Kon-

zepte und Lösungen nicht adäquat sind, werden basierend auf der Diskus-

sion Konzepte für neue, intelligente Formulare entwickelt. Diese stellen auf

abstrakter Ebene Informationen zu verwendeten Oberflächenelementen, Lay-

outinformationen, Datenbindung sowie weitere Informationen zur Unterstüt-

zung der festgestellten Anforderungen zur Verfügung.

Anschliessend wird die Integration einer Softwarekomponente zur Unterstüt-

zung solcher Formulare für das ADEPT2-System entworfen und prototyp-

isch implementiert. Dies beinhaltet zum Einen einen Editor zur Erstellung

der Formulare inklusive der Anbindung an das entsprechende Prozessmodell.

Zum Anderen wird eine Laufzeitumgebung benötigt, welche die vom Edi-

tor erzeugten Formulardaten in eine konkrete Benutzeroberfläche inklusive

aller benötigten weitergehenden Funktionen transformiert. Diese kann dann

dem Endanwender angezeigt werden. Wichtig hierbei ist die einfache Aus-

tauschbarkeit der verwendeten Oberflächenbibliothek.

1.3 Aufbau

Zunächst werden in Kapitel 2 die Grundlagen behandelt, die im weiteren

Verlauf der Arbeit für das Verständnis nötig sind. Dazu zählen allgemeine

Grundlagen über die Erstellung von Prozessen mit BPM-Systemen und eine

Einführung von Formularen, die bereits in der ADEPT2-Implementierung

1 Einleitung

vorhanden sind. Ausserdem werden technische Grundlagen besprochen, wie

die Verwendung von JavaScript [ISO02] und SWT (Standard Widget Toolkit

[Ecl09a]).

In Kapitel 3 geht es um die Anforderungen, die an intelligente Formulare

gestellt werden. Dafür werden aufbauend auf der Motivation zunächst die

grundlegenden Probleme von Formularen erläutert. Anschliessend werden die

beteiligten Endanwender des Systems identifiziert und deren Anforderungen

an das System ausführlich diskutiert. Diese werden zusammen mit den all-

gemeinen Anforderungen in funktionale und nichtfunktionale Anforderungen

eingeteilt.

Nach der Vorstellung der Anforderungen werden in Kapitel 4 darauf

basierend Kriterien zusammengestellt, welche für eine Evaluierung bereits

existierender Produkte notwendig sind. Dabei wird geprüft, ob es Produkte

gibt, welche die gestellten Anforderungen bereits erfüllen. Diese Evaluierung

befasst sich mit vollständigen BPM-Systemen ebenso, wie mit eigenständigen

Programmen zur Gestalltung von Oberflächen und Formularen. Ausserdem

wird eine neue Technologie zur Darstellung von Formularen in Web-Browsern

untersucht.

In Kapitel 5 werden Lösungsansätze für eine eigene Entwicklung präsentiert.

Zunächst wird die Architektur der neuen Softwarekomponente diskutiert.

Diese beinhaltet unter anderem den Editor, mit dessen Hilfe Formulare für

einen Prozessschritt erstellt werden und die Umgebung für die Darstellung

dieser Formulare. Neben der Architektur werden noch andere Aspekte be-

sprochen, wie zum Beispiel das Datenmodell der Formulare und ein geeignetes

Format zum Transport von Formularen. Anschliessend werden verschiedene

Konzepte für die einzelnen Aspekte der Architektur vorgestellt, welche die

urspünglichen Anforderungen aus Kapitel 3 adäquat umsetzen.

Um die Arbeit abzurunden, wird die neue Softwarekomponente unter Ver-

wendung der vorgestellten Konzepte prototypisch implementiert und in das

ADEPT2-System integriert. Das Ergbnis wird in Kapitel 6 beschrieben. Da-

bei werden auch Probleme angesprochen, die bei der Implementierung aufge-

treten sind.

Kapitel 7 fasst das Ergebnis der Arbeit abschliessend zusammen. Es wird

beschrieben, was im Rahmen dieser Arbeit erreicht wurde und welche Prob-

leme nicht gelöst werden konnten. Zuletzt wird ein Ausblick darauf gegeben,

in welche Richtung sich die Entwicklung in Zukunft richten wird.

2 Grundlagen

Dieses Kapitel führt einige Grundlagen aus dem Softwareentwicklungs- und

BPM-Bereich ein, die für das Verständnis dieser Arbeit benötigt werden. Zu-

nächst wird das allgemeine Vorgehen beim Modellieren von Geschäftsprozes-

sen erläutert. Darauf aufbauend werden ausgewählte Aspekte von ADEPT2

vorgestellt. Im Anschluss werden die Grundlagen von JavaScript und der

Oberflächenentwicklung mit SWT [Ecl09a] diskutiert. Dieses Wissen wird

für die Entwicklung der Konzepte der neuen Komponente benötigt.

2.1 Grundlagen von BPM-Systemen

2.1.1 Der Informationsbegriff

Neben der Koordinierung von Arbeitsabläufen ist vor allem auch der Trans-

port von Informationen ein wichtiger Aspekt von BPM-Systemen. Diese In-

formationen werden beispielsweise durch Benutzereingaben erzeugt, durch

das BPM-System verwaltet und den Endanwendern präsentiert, um diese

bei ihrer Arbeit zu unterstützen.

Durch die Benutzereingaben werden zunächst jedoch nur Daten zur Verfü-

gung gestellt. Aus diesen Daten müssen Informationen gewonnen werden. Im

Verlauf dieser Arbeit spielt die Unterscheidung zwischen Daten und Infor-

mationen eine wichtige Rolle. Daher sollen diese beiden Begriff im Folgenden

voneinander abgegrenzt werden.

Bei Daten handelt es sich um Zeichen oder Zeichenketten. Sie sind durch die

DIN ISO/IEC 2382 [Int93] der International Organization for Standardiza-

tion [ISO09] definiert. Um daraus Informationen zu gewinnen, müssen die

Daten interpretiert werden. Die Daten selber geben allerdings keinen Auf-

schluss darüber wie diese zu interpretieren sind. Aus ihnen lassen sich daher

keine Informationen gewinnen.

Um Daten in einem BPM-System interpretierbar zu machen, wird jedem

Datum ein Typ zugewiesen, welcher Aufschluss darüber gibt, wie die Daten

zu interpretieren sind. Daten, welche beispielsweise vom Typ String sind,

lassen sich als Text interpretieren. Zu diesem Zweck gibt es in den meisten

BPM-System bereits vordefinierte Datentypen für einfache Informationen,

wie sie auch in vielen gebräuchlichen Programmiersprachen benutzt werden.

Einige solcher Typen sind:

2 Grundlagen

•String

•Integer

•Float

•Boolean

Zeichen oder Zeichenfolgen ohne einen Datentyp werden fortan als Daten

bezeichnet. Zeichen oder Zeichenfolgen mit einem Datentypen werden als

Informationen klassifiziert.

2.1.2 Benutzer eines BPM-Systems

BPM-Systeme sind häufig sehr komplex und umfangreich. Wird in einem

Unternehmen ein solches System eingesetzt, sind daher in der Regel viele un-

terschiedliche Benutzer mit unterschiedlichen Aufgaben und speziellem Fach-

wissen daran beteiligt. Diese Benutzer lassen sich in drei Gruppen einteilen

(Abbildung 4).

•Prozessmodellierer: Dies sind Personen, welche mit dem BPM-System

Geschäftsprozesse entwickeln. Sie sind in der Regel nicht selber in die

Ausführung eines Prozesses involviert.

•Anwendungsentwickler: Sie sind für die Entwicklung von Anwendungs-

bausteinen verantwortlich, die beispielsweise in einen Geschäftsprozess

integriert werden können. Auch diese Personen sind nicht an der Aus-

führung eines Prozesses beteiligt.

•Endanwender: Dies sind die Personen, welche während der Ausführung

eines Geschäftsprozesses in einem Unternehmen einbezogen sind, um

beispielsweise Daten einzugeben, oder um Arbeitsschritte durchzufüh-

ren, welche nicht unbdeingt durch ein computergestütztes System erle-

digt werden können (z. B. Verpacken der Ware).

2.1.3 Verwendung eines BPM-Systems

Um einen Geschäftsprozess mit einem BPM-System umzusetzen, gibt es meh-

rere Möglichkeiten. Eine sehr verbreitete Methode ist die Erstellung eines Mo-

dells des Geschäftsprozesses (Prozessmodell) mit Hilfe eines Graphen. Es gibt

verschiedene Systeme, welche diese Methode umsetzen, beispielsweise Inubit

[Inu09a] oder ADEPT2 ([Rei00], [Dad09]). Da es zwischen solchen Systemen

Unterschiede in den Details der Umsetzung und im Vokabular gibt, wird im

2.1 Grundlagen von BPM-Systemen

Prozessmodellierer: Entwicklerin für

Anwendungsbausteine:

If( a == 0 )

{

return b;

}

else

{

while( b != 0)

{

if( a > b )

?!?

Endanwender:

Abbildung 4: Benutzer eines BPM-Systems

Verlauf dieser Arbeit das Modell von ADEPT2 als Grundlage verwendet.

Die darin enthalten Prinzipien lassen sich jedoch auch auf andere Systeme

übertragen. ADEPT2 ist ein BPM-System der nächsten Generation, das auf

den Forschungsarbeiten [Dad06] von Prof. Reichert [Rei00] und Prof. Dadam

seit 1997 beruht und an der Universität von Ulm entwickelt wird. Bei der

Umsetzung von Geschäftsprozessen mit ADEPT2 sind mehrere Aspekte zu

beachten:

•Kontrollfluss

•Datenfluss

•Aktivitäten

Es gibt noch weitere Aspekte, wie beispielsweise die Behandlung von Aus-

nahmen, welche jedoch für diese Arbeit nicht relevant sind.

Mit dem Kontrollfluss wird die Reihenfolge der einzelnen Schritte des Ge-

schäftsprozesses (im weiteren Verlauf Prozessschritte genannt) festgelegt.

Hierzu wird zunächst der Geschäftsprozess mit Hilfe eines Graphen mo-

delliert. Dieser Graph besitzt Knoten, welche die einzelnen Prozessschrit-

te darstellen. Diese Prozessschritte sind wiederum durch gerichtete Kanten

miteinander verbunden, welche den Kontrollfluss repräsentieren. Jeder Graph

hat einen Start- und einen Endknoten. Innerhalb des Kontrollflusses sind

Konstrukte wie Schleifen oder Verzweigungen möglich. Wie ein Kontrollfluss

aussehen darf, ist in [Rei00] beschrieben. Abbildung 5 zeigt beispielhaft das

Modell eines Prozesses.

Der Datenfluss beschreibt den Transport von Informationen innerhalb des

Kontrolflusses. Hierzu werden dem Graphen zunächst sogenannte Datenele-

2 Grundlagen

Ende

Schritt 2b

Schritt 2a Schritt 3a

Start Schritt 1

Startknoten EndknotenProzessschritt

Kontrollfluß Verzweigung

Abbildung 5: Prozessmodell mit Prozessschritten und Kontrollfluss

mente in Form weiterer Knoten hinzugefügt. Jedes Datenelement repäsen-

tiert dabei eine bestimmte Information. Um die Informationen zwischen den

Prozessschritten zu transportieren, werden die Datenelemente jedem Pro-

zessschritt, in dem sie benötigt werden, durch eine weitere gerichtete Kante

zugeordnet. Dabei spielt die Richtung der Kante eine wichtige Rolle. Eine

Kante vom Prozessschritt zum Datenelement kennzeichnet einen sogenan-

nten schreibenden Zugriff. Dies bedeutet, dass bei einem entsprechenden Pro-

zessschritt das Datenelement mit Informationen versorgt wird. Eine Kante

vom Datenelement zum Prozessschritt bedeutet, dass die Informationen aus

dem Datenelement in dem Prozessschritt verwendet werden (lesender Zu-

griff). Weitere Informationen zu Datenelementen sind in [Rei06] zu finden.

In Abbildung 6 wird das Modell aus Abbildung 5 um den Datenfluss erwei-

tert.

Ein weiterer wichtiger Aspekt sind die Aktivitäten. Diese beschreiben die

Semantiken eines Prozessschrittes und den zugeordneten Datenelementen.

Ende

Schritt 2b

Schritt 2a Schritt 3a

Start Schritt 1

Datenelement Daten-

element 1 Daten-

element 2

Schreibender Zugriff

LesenderZugriff

Abbildung 6: Prozessmodell mit Datenfluss

2.1 Grundlagen von BPM-Systemen

Ende

Bestellung

verwerfen

Bestellung versenden

Rechnung vorbereiten Rechnung versenden

Start Bestellung

aufnehmen

Bestell-

informationen Rechnungs-

daten

Abbildung 7: Prozessmodell mit Aktivitäten

Eine Aktivität definiert, was während der Ausführung eines Prozessschrit-

tes geschehen soll, beispielsweise mit einer Anwendung, welche dem Pro-

zessschritt hinterlegt wird. Anwendungen, die als Aktivität in einen Prozess

integriert sind, werden in dieser Arbeit als Anwendungsbausteine bezeichnet,

um diese von alleinstehenden Anwendungen abzugrenzen. Die Datenelemente

der Prozessschritte dienen den Aktivitäten dabei als Parameter. Im weiteren

Verlauf der Arbeit werden Datenelemente daher als Prozessschrittparameter

bezeichnet. Lesender Zugriff auf Datenelemente sind Eingabeparameter der

Aktivität. Das bedeutet, dass die Informationen aus den Datenelementen zu

Beginn der Ausführung einer Aktivität dieser zur Verfügung gestellt wird,

um damit arbeiten zu können. Ein schreibender Zugriff auf ein Datenele-

ment bedeutet, dass die Aktivität nach der Ausführung Informationen für

das Datenelement bereitstellt. Abbildung 7 zeigt ein Prozessmodell mit Ak-

tivitäten.

Ein auf diese Weise erstelltes Modell eines Geschäftsprozesses kann nun in

einer Ausführungsumgebung instanziiert und ausgeführt werden. Diese Um-

gebung startet zunächst die Aktivität des ersten Prozessschrittes. Nachdem

die Aktivität beendet wurde, wird gemäß dem Kontrollfluss der nächste Pro-

zessschritt ermittelt und dessen Aktivität gestartet. Die Ausführung des Mo-

dells ist beendet, wenn der Endknoten erreicht wird. Bei der Ausführung

des Modells müssen nicht alle Prozessschritte durchlaufen werden. Durch

bedingte Verzweigungen können Bereiche des Graphen ausgelassen werden.

Abbildung 8 zeigt die Ausführung einer Prozessinstanz.

In ADEPT2 ist eine Entwicklungsumgebung (Process Template Editor) in-

tegriert. Mit diesem Editor ist der Prozessmodellierer in der Lage, alle

beschriebenen Aspkete der Erstellung eines Prozessmodells durchzuführen.

Abbildung 9 zeigt den Process Template Editor. Das Modellieren erfolgt

2 Grundlagen

Ende

Bestellung

verwerfen

Bestellung versenden

Rechnung vorbereiten Rechnung versenden

Start Bestellung

aufnehmen

Bestell-

informationen Rechnungs-

daten

abgearbeiteter

Prozessschritt

aktiver

Prozessschritt

ausstehender

Prozessschritt

ausgelassener

Prozessschritt

Abbildung 8: Instanz eines Prozessmodells

dabei mit Hilfe von Änderungsoperationen, welche den Graphen immer in

einem gültigen Zustand halten. Die Funktionsweise dieser Operationen ist

in [Jur06] beschrieben. Weitere Informationen zu dem Editor werden in den

entsprechenden Abschnitten dieser Arbeit erläutert.

2.2 Unterstützung von Formularen bei ADEPT2

Sehr häufig werden für Prozessschritte zwei Arten von Aktivitäten verwendet:

•Aktivitäten zur Interaktion mit einem Endanwender (Benutzerinterak-

tion), um beispielsweise Informationen von diesem zu erfragen.

•Automatische Aktivitäten zur Durchführung von datenverarbeitenden

Schritten.

Für Aktivitäten mit Benutzerinteraktionen gibt es in ADEPT2 bereits eine

Softwarekomponente, welche hierfür einfache Formulare bereitstellt. Diese

werden automatisch auf Basis der Prozessschrittparameter eines Formul-

ares erstellt. Das bedeutet, dass für das Formular zum Einen Felder gene-

riert werden, welche die Eingabeparameter anzeigen. Zum Anderen werden

Eingabefelder generiert, welche zur Laufzeit durch den Endanwender aus-

gefüllt werden. Dessen Eingaben stellen die Ausgabeparameter der Aktivi-

tät dar. Allerdings ergeben sich durch die Automatisierung auch einige Ein-

schränkungen:

1. Auf das Layout des Formulars kann kein Einfluss genommen werden.

Für jeden Parameter wird ein entsprechendes Formularfeld erstellt.

Diese Felder werden alphabetisch aufgelistet.

2.3 Anwendungsintegration

Abbildung 9: Process Template Editor von ADEPT2

2. Es ist nicht möglich, das Verhalten der Formulare durch Anwendungs-

logik flexibel zu gestalten. Auf semantisch falsche Eingaben durch

den Endanwender kann nicht reagiert werden, beispielsweise bei der

Eingabe einer negativen Zahl in einem Formularfeld für eine Altersan-

gabe.

In Abbildung 10 ist ein Modell eines Prozesses zu sehen, mit dem ein Ur-

laubsantrag erstellt und genehmigt werden kann. Der Prozess besteht aus

zwei Schritten. Die Aktivität des zweiten Schrittes hat dabei drei Eingabe-

parameter, welche die Daten des Antragsstellers beinhalten und zwei Ausga-

beparameter, welche durch einen Antragsprüfer angegeben werden müssen.

Diese Ausgabeparameter beinhalten die Entscheidung über die Genehmigung

des Urlaubs und gegebenenfalls eine Begründung. Abbildung 11 zeigt das au-

tomatisch generierte Formular für die zweite Aktivität.

2.3 Anwendungsintegration

Für Prozesse, bei denen diese Formulare keine ausreichende Funktionalität

bieten, müssen neue Anwendungsbausteine entwickelt und als Aktivitäten in

das BPM-System integriert werden. Im Folgenden Abschnitt wird der Auf-

bau der Ausführungsumgebung von ADEPT2 besprochen, welche integrierte

Anwendungsbausteine zur Laufzeit eines Prozesses ausführt.

2 Grundlagen

Eingabeparameter

für Aktivität "Antrag

genehmigen"

Aktivität mit automatisch

generiertem Formular

Ausgabeparameter

für Aktivität "Antrag

genehmigen"

Start Antrag stellen

Vorname

Antrag genehmigen Ende

Name Pers. Nr. genehmigt Begründung

Abbildung 10: Prozessmodell für einen Urlaubsantrag mit Formularaktivi-

täten

Abbildung 11: Generiertes Formular für eine Aktivität

Ausgangspunkt der Entwicklung eines neuen Anwendungsbausteines für

das System ist die Schnittstelle ExecutableComponent. Diese Schnittstelle

beschreibt die Methoden, welche von dem Baustein bereitgestellt werden

müssen, damit diese in der Ausführungsumgebung verwendet werden kön-

nen (Quellcode 1).

Um den erstellten Anwendungsbaustein innerhalb des Process Template Ed-

itor als Aktivität nutzen zu können, muss für die Implementierung der Exe-

cutableComponent noch eine ExecutableComponentDescription angelegt wer-

2.4 JavaScript

den. Diese Beschreibung enthält Metainformationen zu der neuen Kompo-

nente. Beispielsweise den Klassenpfad und den Klassennamen. Angaben über

benötigte Prozessschrittparameter sind ebenfalls möglich.

1public interface ExecutableComponent {

2public void init ( SessionContext sessionContext );

3public void initResume ( int savePointID , SessionContext

sessionContext );

4public void run () ;

5public boolean close ();

6public boolean reset ();

7public boolean signal ( int signal );

8public boolean suspend ();

9public boolean kill ();

10 public Vote prepareCommit () throws

IsNotSupportedException;

11 public boolean rollback () throws

IsNotSupportedException;

12 public void commit () throws IsNotSupportedException ;

13 }

Quellcode 1: Schnittstelle der ExecutableComponent

Zur Laufzeit führt das BPM-System den Prozess regulär aus. Dabei werden

die Aktivitäten der Prozessschritte gestartet. Enthält eine Aktivität dabei

eine integrierte Anwendung, wird diese gestartet und die Werte der Eingabe-

parameter übergeben. Die Ausführung des Prozesses wird unterbrochen, bis

die Anwendung beendet ist und die Werte für die Ausgabeparameter bereit-

stellt. Diese werden in die entsprechenden Datenelemente geschrieben, bevor

mit der Ausführung des Prozesses fortgefahren wird. Dieser Vorgang ist in

Abbildung 12 nochmals dargestellt.

2.4 JavaScript

Im späteren Verlauf dieser Arbeit wird verstärkt auf JavaScript für den Ein-

satz in Formularen zurückgegriffen. Daher werden nun die wichtigsten Grund-

lagen dieser Sprache erläutert.

2 Grundlagen

Prozessausführung

Ausführungsumgebung des BPM-System

Ausführung des integirerten

Anwendungsbausteins

Ausführung des Prozesses erreicht Aktivität

mit einer integirerten Anwendung und wird

unterbrochen. Eingabeparameter werden aus

den Datenelementen ausgelesen

Anwendung wird gestartet und erhält

Eingabeparameter

Ausführung der Anwendung ist beendet.

Ausgabeparameter werden an das

BPM-System übergeben

Werte der Ausgabeparameter werden in

Datenelemente geschrieben. Ausführung

des Prozesses wird fortgesetzt

Abbildung 12: Integration eines Anwendungsbausteins zur Laufzeit

2.4.1 Allgemeine Einführung

JavaScript ist eine prozedurale Skriptsprache, welche 1995 für den Netscape

Navigator entwickelt und später unter dem Namen ECMAScript [ISO02]

standardisiert wurde. Mittlerweile beherrschen aber die meisten gängigen

Web-Browser diese Sprache. Die Web-Browser stellen eine spezielle Laufzeit-

umgebung zur Verfügung, innerhalb der ein Skript interpretiert wird. Das

Skript selber wird dabei in ein HTML-Dokument eingebettet oder in einer

separaten JavaScript-Datei zur Verfügung gestellt. Innerhalb eines solchen

Skriptes hat der Entwickler Zugriff auf die Inhalte des HTML-Dokumentes

und des Web-Browser, wie beispielsweise Texte, Bilder, Formularelemente,

Links aber auch auf Cookies, Fenster des Web-Browser oder die Liste der be-

suchten Webinhalte. Ein Zugriff auf Ressourcen ausserhalb des Web-Browser

ist nicht möglich.

1<html ><head ><title>Test </ title>

2<script type=" text / javascript ">

3<! --

4function Quadrat ()

6var Ergebnis = document.Formular.Eingabe.value *

document . Formular . Eingabe . value;

2.4 JavaScript

7alert (" Das␣ Quadrat ␣ von␣" + document . Formular . Eingabe .

value + "␣=␣" + Ergebnis );

9// -->

10 </ script ></head >

11 <body >

12 <form name ="Formular" action ="">

13 <input type="text " name =" Eingabe " size="3">

14 <input type=" button " value=" Quadrat ␣ errechnen "

onclick =" Quadrat ()">

15 </ form >

16 </ body ></html>

Quellcode 2: JavaScript eingebettet in HTML [Mü08a]

Die Ausführung der Skripte basiert häufig auf Ereignissen, die beispielsweise

durch Benutzeraktionen im HTML-Dokument ausgelöst werden. Quellcode 2

zeigt ein einfaches JavaScript-Programm, welches in ein HTML-Dokument

eingebettet ist und durch das Aktivieren einer Schaltfläche ausgeführt

wird. In Abbildung 13 ist ein Web-Browser zu sehen, welcher das HTML-

Dokument darstellt.

Ein wichtiges Konzept von JavaScript ist die Objektorientierung [Joh95]. Dies

bedeutet, dass alle Zugriffe, beispielsweise auf das HTML-Dokument, über

entsprechende Objekte erfolgen. Wie in vielen anderen objektorientierten

Programmiersprachen auch, besitzen Objekte in JavaScript Attribute und

Methoden.

Abbildung 13: Ausführung von JavaScript in einem Web-Browser

2 Grundlagen

Das Konzept der Klassen gibt es in JavaScript dagegen nicht. Statt dessen

werden Prototypen verwendet. Um eigene Objekte mit individuellen Eigen-

schaften und Methoden zu erhalten, werden Objekte zunächst kopiert. Diesen

Kopien wiederum werden die benötigten Eigenschaften und Methoden hin-

zugefügt. Auf diese Weise ist auch Vererbung möglich, da die Methoden und

Eigenschaften des kopierten Objektes auch in dem neuen Objekt verfügbar

sind, wenn dies gewünscht ist. Dazu wird das kopierte Objekt als Prototyp

des neuen Objektes deklariert.

Eine weitere Eigenschaft von JavaScript ist die dynamische Typisierung.

Dadurch werden Variablen erst zur Laufzeit an einen bestimmten Typ gebun-

den. Zur Entwurfszeit ist nicht bekannt, welchen Typ eine Variable hat. Es

ist jedoch möglich zur Laufzeit den Typ einer Variable zu ermitteln und diese

Typinformation im Programmfluss zu verwenden.

Aufgrund der steigenden Beliebtheit von Web 2.0-Anwendungen [Alb07],

wird JavaScript immer häufiger dazu eingesetzt, den Aufbau des HTML-Do-

kumentes dynamisch zu verändern. Damit ist es möglich, während der Be-

nutzer mit dem Dokument arbeitet, neue Textfelder einzufügen, zu entfernen

oder zu ändern. Durch diese Möglichkeit lassen sich HTML-Dokumente nicht

mehr nur für das Präsentieren von Informationen einsetzen. Es ist möglich

damit komplette, auf HTML basierte Anwendungen mit einer aufwendigen

Benutzerinteraktion zu entwickeln.

2.4.2 JavaScript ausserhalb eines Web-Browsers

Die Verwendung von JavaScript ist nicht auf den Kontext eines Web-Browsers

beschränkt. JavaScript kann in jeder Anwendung genutzt werden, die in

der Lage ist, diese Sprache zu interpretieren. Eine entsprechende Laufzeit-

umgebung zu erstellen ist dabei recht aufwändig. Es gibt jedoch vorgefer-

tigte Umgebungen, welche in Anwendungen integriert werden können, um

JavaScript-Programme innerhalb dieser Anwendung zu interpretieren. Eine

Möglichkeit hierfür bietet die ScriptEngine [Ull09, Kapitel 10.6.3], welche in

Java 1.6 zur Verfügung steht. Diese ScripteEngine erlaubt die Ausführung

von JavaScript im Kontext eines Java-Programms.

Dabei ist zu beachten, dass sich die Kontexte grundlegend unterscheiden:

Im Kontext eines Web-Browsers kann beispielsweise mit Hilfe des document-

Objekt, auf den Inhalt des HTML-Dokument zugegriffen werden. Dies ist im

Kontext eines Java-Programms nicht möglich.

2.4 JavaScript

Abbildung 14: Funktionsweise der ScriptEngine

Es ist jedoch möglich, innerhalb der JavaScript-Programme auf ausgewählte

Objekte aus dem Kontext des laufenden Java-Programms zuzugreifen. Hier-

für wird der ScriptEngine der Quellcode des JavaScript-Programms über-

geben. Zusätzlich können Objekte aus dem Java-Kontext übergeben wer-

den. Diese Objekte werden dabei an Namen gebunden, mit denen innerhalb

des JavaScript-Programms auf die Objekte zugegriffen werden kann. Dabei

können alle Attribute und Methoden des Java-Objektes verwendet werden.

Abbildung 14 zeigt die Verwendung der ScriptEngine.

Wenn während der Ausführung des JavaScript-Programms eine Methode

eines Objektes aufgerufen wird, welches an ein Java-Objekt gebunden ist,

wird dieser Aufruf durch die ScriptEngine an die Methode des Java-Objektes

ausserhalb des JavaScript-Programms weitergereicht und dort ausgeführt.

Für das JavaScript-Programm ist dieser Vorgang völlig transparent.

2 Grundlagen

2.5 Grafische Kontexte

Wenn im Rahmen eines BPM-Systems grafische Oberflächen angezeigt wer-

den sollen spielt der grafische Kontext eine wichtige Rolle, da nicht jede

Oberfläche auf jedem PC dargestellt werden kann. Warum dies so ist, wird

im Folgenden Abschnitt erläutert. Weiterführend wird die Entwicklung von

Oberflächen mit Hilfe von SWT beschrieben.

2.5.1 Allgemeines

In großen Unternehmen gibt es eine Vielzahl von Mitarbeitern an unter-

schiedlichen Arbeitsplätzen. Diese Arbeitsplätze bieten nicht alle das selbe

Umfeld für den Einsatz eines BPM-Systems. Beispielsweise kann sich bereits

das verwendete Betriebssystem an jedem Arbeitsplatz unterscheiden. Einige

Mitarbeiter können Mac OS X [App07] an ihrem Desktop PC einsetzen,

während andere Palm OS [Pal09] auf ihren mobilen PDA einsetzen. Damit

dennoch alle Mitarbeiter in einen Geschäftsprozess mit eingebunden werden

können, muss sich ein BPM-System an unterschiedliche Systeme anpassen

können. Die wichtigste Aufgabe des BPM-Systems für den Mitarbeiter ist

die Interaktion mit dem Endanwender. Diese erfolgt meist durch die Ver-

wendung einer grafischen Oberfläche. Fast alle Betriebssystem stellen hierfür

eine oder mehrere Möglichkeiten zu deren Darstellung zur Verfügung. Diese

Möglichkeiten werden im Verlauf dieser Arbeit als grafische Kontexte be-

zeichnet. Jeder grafischer Kontext hat dabei bestimmte Voraussetzungen an

das Betriebssystem, um diesen nutzen zu können.

Daher bieten nicht alle Betriebssysteme die selben grafischen Kontexte an.

Das BPM-System muss deshalb in der Lage sein, mit unterschiedlichen gra-

fischen Kontexten umgehen zu können. Ein Beispiel für einen grafischen

Kontext ist eine HTML-Umgebung. Hiermit werden die Oberflächen zur Be-

nutzerinteraktion mit Hilfe eines HTML-Dokumentes dargestellt. Dies setzt

jedoch voraus, dass das Betriebssystem eine Anwendung zur Verfügung stellt,

um HTML-Dokument interpretieren zu können. Eine weitere Möglichkeit für

einen grafischen Kontext ist die Verwendung von PDF-Dokumenten. Auch

hier wird eine eigene Anwendung zur Darstellung vorausgesetzt.

2.5.2 Oberflächenentwicklung mit SWT

Eine andere Möglichkeit für einen grafischen Kontext sind Bibliotheken,

welche grafische Komponenten für die Entwicklung einer Oberfläche be-

2.5 Grafische Kontexte

reitstellen. Diese Bibliotheken werden meist in sogenannten Rahmenwerken

angeboten. Beispiele für Rahmenwerke sind [Wik09a]:

•AWT: Abstract Window Toolkit für Java [Sun09a]

•GTK: Gimp Toolkit für verschiedene Plattformen [GTK09]

•MFC: Microsoft Foundation Classes für ältere Windowssystme [Mic09a]

•Motif: Älteres Rahmenwerk für Posix-Systeme [Ope09]

•QT: Toolkit von Trolltech für verschiedene Plattformen [Tro09]

•Swing: Erweiterung von AWT [Sun09b]

•SWT: Standard Widget Toolkit aus dem Eclipse-Projekt [Ecl09a]

•Windows Forms: Rahmenwerk für .NET-Umgebungen [Mic09f]

•wxWidgets: Objektorientiertes Rahmenwerk für verschiedene Platt-

formen [WX09]

Welche dieser Rahmenwerke verwendet werden können, ist dabei nicht nur

vom verwendeten Betriebssystems abhängig, sondern auch von der einge-

setzten Programmiersprache. AWT und Swing sind für den Einsatz in Java-

Programmen entwickelt und betriebssystemunabhängig. SWT ist ebenfalls

für Java entwickelt, dessen Umsetzung unterscheidet sich allerdings je nach

Betriebssystem. Da die Implementierungen der grafischen Oberflächen von

ADEPT2 SWT verwenden, wird auch im Rahmen dieser Arbeit auf SWT

für die Entwicklung der Oberflächen zurückgegriffen. SWT ist ein quellof-

fenes Rahmenwerk, dass entwickelt wurde, um einen performanten und

portablen Zugriff auf die Bibliotheken für Benutzerschnittstellen des Be-

triebssystems zu gewähren. SWT greift dabei auf andere existierende Rah-

menwerke zurück, welche auf dem jeweiligen Betriebssystem verfügbar sind.

Auf einem GNU/Linux System wird beispielsweis GTK verwendet. Die Ein-

bindung in die Java-Umgebung erfolgt dabei durch das Java Native Interface

[Ull09, Kapitel 27], wodurch diese Kapselung vor dem Anwendungsentwickler

verborgen wird.

Die grafischen Benutzeroberflächen sind in SWT aus Composite aufgebaut.

Ein Composite ist eine Repäsentation für ein Steuerelement, welches zur

Darstellung von Informationen oder zur Interaktion mit dem Benutzer ver-

wendet wird. Die Bibliotheken von SWT enthalten Composite für die ge-

bräuchlichsten Steuerelemente, wie beispielsweise Textfelder, Beschriftungs-

felder, Schaltflächen, Listen, Tabellen oder Baumansichten. Für komplexere

2 Grundlagen

Abbildung 15: Einige Composite von SWT in unterschiedlichen Betriebssys-

temen [Ecl09a]

Steuerelemente ist es möglich, neue Composite anzulegen. Diese werden da-

bei hierarchisch aus bereits vorhandenen Composite aufgebaut. Abbildung 15

zeigt eine Oberfläche bestehend aus einem Register, einer Baumansicht,

einem Kontrollkästchen und einer Schaltfläche. Diese Oberfläche wird in un-

terschiedlichen Betriebssystemen dargestellt.

Um die Composite anzuordnen, wird dem übergeordneten Composite ein Lay-

out [Ecl09b] zugeordnet. Dieses Layout ist für die Positionierung der Compo-

site verantwortlich. Hierfür gibt es mehrere Implementierungen mit einem

unterschiedlichen Verhalten. Alternativ können die Positionsangaben auch

manuell gesetzt werden.

Um auf Aktionen von Benutzern reagieren zu können, verwendet SWT eine

Variante des Observer-Patterns [Joh95]. Alle Composite können verschie-

dene Ereignisse auslösen. Um über ein bestimmtes Ereignis informiert zu

werden, können sich interessierte Objekte an dem entsprechendem Compo-

site für das Ereignis registrieren. Diese Objekte müssen dafür jedoch eine

bestimmte Schnittstelle implementieren, welche Methoden enthält, die beim

Eintreten des Ereignisses aufgerufen werden.

Abbildung 16: Darstellung des SWT-Composite

2.5 Grafische Kontexte

Quellcode 3 zeigt eine Klasse, welche ein Composite mit einem Beschriftungs-

feld, einem Textfeld und einer Schaltfläche definiert. Durch das Auslösen der

Schaltfläche wird das Quadrat der Zahl berechnet, die in dem Textfeld ange-

geben wurde. Quellcode 4 demonstriert die Anwendung des neuen Composite.

Abbildung 16 zeigt dessen Darstellung.

1public class NeuesComposite extends Composite implements

SelectionListener {

2Text textFeld ;

3Label beschriftungsFeld ;;

4Button schaltflaeche;

6public NeuesComposite ( Composite parent , int style) {

7super(parent , style);

8setLayout(new GridLayout(3, false));

9beschriftungsFeld = new Label(this, SWT .None );

10 beschriftungsFeld . setLayoutData ( new GridData(GridData

.BEGINNING , GridData .BEGINNING , false ,false));

11 beschriftungsFeld . setText (" Eine ␣ Zahl ␣ eingeben ");

12 textFeld = new Text (this, SWT . BORDER );

13 textFeld.setLayoutData(new GridData(GridData.

BEGINNING , GridData . BEGINNING , false,false,

14 2, 1));

15 schaltflaeche = new Button ( this, SWT. PUSH );

16 schaltflaeche.setLayoutData(new GridData(GridData.

BEGINNING , GridData . BEGINNING , false,false));

17 schaltflaeche . setText (" Quadrat ␣ berechnen ");

18 schaltflaeche . addSelectionListener ( this );

19 }

21 public void widgetSelected ( SelectionEvent e) {

22 int num = Integer . parseInt ( textFeld . getText ());

23 MessageBox mb = new MessageBox ( getShell (), SWT .OK);

24 mb. setText (" Berechnung ");

25 mb. setMessage (" Das␣ Quadrat ␣ ist␣" + Integer . toString (

num * num));

26 mb.open ();

27 }

28 }

Quellcode 3: Benutzerdefiniertes Steuerelement als SWT-Composite

2 Grundlagen

1public static void main ( String [] args ) {

2Display display = new Display ();

3Shell shell = new Shell ( display );

4shell . setLayout ( new FillLayout());

5Composite composite = new NeuesComposite (shell , SWT.

None );

6shell .pack ();

7shell .open ();

9while(! shell . isDisposed () ) {

10 if(! display . readAndDispatch ()) {

11 display . sleep () ;

12 }

13 }

14 display . dispose ();

15 }

Quellcode 4: Verwendung eines Composite

3 Anforderungen an eine Komponente zur

Formularerstellung

Aufbauend auf den Grundlagen über BPM-Systeme, werden die Anforde-

rungen diskutiert, die sich für den Entwurf einer neuen Softwarekomponen-

te (im Folgenden als Komponente bezeichnet) zur Erstellung von Formul-

aren ergeben. Dabei spielt der bereits besprochene Konflikt zwischen der

Fähigkeit, Formulare automatisch zu generieren und einer ausreichenden

Funktionalität eine Rolle. Es gibt aber noch eine Vielzahl weiterer Aspekte,

welche berücksichtigt werden müssen. Im folgenden Abschnitt wird zunächst

auf die grundlegenden Problemstellungen der Generierung und Darstellung

von Formularen eingegangen. Im darauf folgenden Abschnitt werden die

genauen Anforderungen im Detail diskutiert.

3.1 Problemstellung

Der Endanwender soll durch Formulare bei seiner Arbeit mit einem BPM-

System unterstützt werden. Die Formulare sollen dabei sinnvoll auf die Ein-

gaben des Endanwenders reagieren können, um ihn beispielsweise auf Fehler

aufmerksam zu machen oder die eingegebenen Daten aufzubereiten. Die bis-

her eingesetzten Formulare, beispielsweise von ADEPT2, sind hierfür auf-

grund der fehlenden Anwendungslogik nicht geeignet. Um diese Ansprüche

erfüllen zu können werden intelligente Formulare benötigt. Dabei handelt es

sich um Formulare, deren Verhalten durch Anwendungslogik präzise gesteuert

werden kann.

Um das Problem besser zu verstehen, wird ausgehend von dem Modell eines

Geschäftsprozesses erläutert, wie intelligente Formulare in das Prozessmo-

dell integriert und dem Endanwender bereitgestellt werden. Dazu wird das

Vorgehen zum Erstellen von Prozessmodellen aus Kapitel 2 erweitert.

Zunächst wird wie bisher ein Modell des Geschäftsprozesses durch den

Prozessmodellierer erstellt. Dieser legt Prozessschritte und Parametern an.

Beim Zuordnen von Aktivitäten kommt eine Unterscheidung hinzu. Hier gibt

es drei mögliche Arten von Aktivitäten:

1. Aktivitäten für datenverarbeitende Prozessschritte

2. Aktivitäten zur Interaktion mit dem Endanwender ohne zusätzliche

Anwendungslogik

3 Anforderungen an eine Komponente zur Formularerstellung

1. Schritt: Modellierung

des Prozesses

Eingabelement Ausgabeelement

Aktivität

2. Schritt: Definition von Aktivitäten

und Parameter für Prozesschritte

Formular 2

Parameter 1

Formular

Parameter 2

Parameter 3

Absenden

3. Schritt: Erstellung der Formulare für

Aktivitäten mit Benutzerinteraktion

Neu:

Hier wird die Reihenfolge

der Prozessschritte festgelegt

Hier werden den Prozessschritten Aktivitäten

und Datenelmente als Parameter zugeordnet

Hier wird das Layout und das Verhalten des

Formulars festgelegt

Ende

Aktivität

Aktivität Aktivität

Daten-

element Daten-

element

Ergebnis: Fertiger, vollständiger Prozess mit

Aktivitäten, Parametern und Formularen

Start Aktivität

Abbildung 17: Entwurf des Prozesses mit Prozessschritten, Aktivitäten

Parametern und Formularen

3. Aktivitäten zur Interaktion mit dem Endanwender mit zusätzlicher An-

wendungslogik

Die ersten beiden Arten sind für den weiteren Verlauf dieser Arbeit nicht

weiter interessant. Sie wurden bereits in Kapitel 2 erläutert. Bei Aktivitäten

für Benutzerinteraktion mit zusätzlicher Anwendungslogik weicht das weitere

3.1 Problemstellung

Verfahren jedoch ab. Bei einer solchen Aktivität kann das Formular nicht au-

tomatisch durch das BPM-System erstellt werden. Es sind zusätzliche Infor-

mationen nötig, um beispielsweise die Semantik der Anwendungslogik oder

das Layout festzulegen.

Hierfür muss das bereits bestehende BPM-System um eine Komponente

erweitert werden, welche die Erstellung eines intelligenten Formulars er-

möglicht. Um die Verantwortlichkeiten während des Erstellvorgangs eines

Prozessmodells suber zu trennen wird im folgenden davon ausgegangen, dass

für die Erstellung des Formulars nicht der Prozessmodellierer, sondern ein

eigener Formularentwickler zuständig ist. Die Erweiterung des Vorgangs zur

Erstellung eines Prozessmodells wird in Abbildung 17 dargestellt. In dieser

Abbildung wird ein fester Ablauf bei der Erstellung des Prozessmodells vor-

ausgesetzt. Auch wenn die Reihenfolge beliebig ist, soll für den weiteren Ver-

lauf dieser Arbeit die in der Abbildung verwendeten Reihenfolge beibehalten

werden.

Nachdem der Prozess mit seinen Schritten, Aktivitäten und Formularen fer-

tiggestellt ist, kann dieser durch die Ausführungsumgebung gestartet wer-

den. Die einzelnen Prozessschritte werden dabei wie gehabt der Reihe nach

abgearbeitet. Sobald ein Schritt erreicht wird, für den ein Formular entwor-

fen wurde, wird das zugeordnete Formular dem Endanwender übergeben.

An dieser Stelle muss das bestehende System ebenfalls erweitert werden, da

dieses noch nicht in der Lage ist intelligente Formulare darzustellen. Nach der

Bearbeitung des Formulars durch den Endanwender, kann das System aus

dessen Eingaben die Ausgabeparameter bestimmen und mit der Ausführung

des Prozesses fortfahren. Abbildung 18 verdeutlicht das Vorgehen.

Das Ziel ist im Folgenden herauszufinden, wie diese Komponente aufgebaut

sein muss und wie deren Arbeitsablauf im Detail aussieht. Aus dem eben

beschriebenen Ablauf lassen sich bereits einige Rahmenbedingungen ableiten:

•Die zu entwickelnde Komponente wird kein eigenständiges Produkt.

Sie ist abhängig von einem bereits vorhandenen BPM-System und wird

immer in dessen Kontext ausgeführt werden.

•Der Ablauf vom Erstellen des Prozesses bis zum fertigen, durch den

Endanwender abgearbeiteten Formular ist in zwei Phasen unterteilt.

Die erste Phase ist die Entwurfszeit, zu der der Prozess, die Pro-

zessschritte, die dazugehörigen Parameter und Aktivitäten, sowie die

Formulare entworfen werden (Abbildung 17). Die zweite Phase ist die

Laufzeit, in welcher der Prozess gestartet und die einzelnen Prozess-

3 Anforderungen an eine Komponente zur Formularerstellung

Ende

Aktivität

Aktivität Aktivität

Daten-

element Daten-

element

Start Aktivität

Eingabe Information

Ausgabe

Absenden

Anwender

Formular

Prozessschritt besteht aus

Aktivität mit 2 Parametern

und einem Formular

Darstellung des Formulars

mit 2 Formularfeldern

Neu:

Abbildung 18: Ausführung eines Prozesses mit Formularen

schritte vom System abgearbeitet werden. Die Formulare werden zur

Bearbeitung an die Endanwender verteilt (Abbildung 18).

Um mehr über die Anforderungen der Komponente zu erfahren, ist eine tiefer-

gehende Analyse der beiden angeprochenen Phasen notwendig.

Während der Entwurfszeit wird ein Formular ausgehend von den Parame-

tern des Prozessschrittes erstellt. Hiefür werden Formularfelder angelegt und

mit den Parametern verknüpft. Die Parameter sind dabei an den Prozess

gebunden und können daher nur innerhalb des Prozesses geschrieben oder

gelesen werden. Mit welchen Werten die Parameter versorgt werden, wird

daher nur von den Aktivitäten bestimmt, denen diese Parameter zugeordnet

sind. Da das Verhalten von Aktivitäten jedoch dynamisch ist, lassen sich zur

Entwurfstzeit keine Aussagen über die Werte der Parameter machen.

Dies bedeutet, dass zur Entwurfszeit nur ein abstraktes Formular erstellt

werden kann. Um daraus ein konkretes Formulars zu machen, muss das ab-

strakte Formular mit Werten versorgt werden. Dies kann allerdings erst zur

3.1 Problemstellung

BPM-System

Entwurfsumgebung

Aktivitätengestaltung

Prozessmodellierung

Ausführungsumgebung

Prozessausführung

Persistente Datenhaltung

Datentransport

Formularerstellung

Neu ?

Formulardarstellung

Neu

Formularvervollstän-

digung

Neu

Abbildung 19: Überblick über das Gesamtsystem

Laufzeit geschehen, wenn die Werte für die Parameter vorliegen. Nachdem

ein konkretes Formular erstellt wurde kann es dem Endanwender angezeigt

werden.

Daraus ergebn sich zwei Subkomponenten, die jeweils die Aufgaben aus den

beiden Phasen erledigen. Diese Subkomponenten müssen in das BPM-System

integriert werden. Wie diese dabei einzuordnen sind, zeigt Abbildung 19.

Die Subkomponente für die Entwicklungsumgebung dient der Erstellung der

Formulare. Ihre Aufgabe ist es, den Formularentwickler dabei zu unter-

stützen, aus den Parametern der Prozessschritte Formularfelder zu erstellen.

Dies ist Schritt 3 aus Abbildung 17. Aufgrund der Tatsache, dass die Werte

3 Anforderungen an eine Komponente zur Formularerstellung

der Parameter noch nicht zur Verfügung stehen, wird nur ein abstraktes

Formular mit Informationen über das Aussehen und das Verhalten des For-

mulares erzeugt.

Die Subkomponente für die Ausführungsumgebung ist dafür verantwortlich,

die Formulare den Endanwendern bereitzustellen. Dies erfolgt in zwei Schrit-

ten. Zunächst wird das zuvor erstellte abstrakte Formular mit den Werten

der Parameter versorgt, um ein vollständiges Dokumente zu erhalten. An-

schliessend wird das Formular grafisch dem Endanwender angezeigt.

Diese beiden Subkomponenten werden an unterschiedlichen Stellen des BPM-

Systems eingebettet. Daher ist es außerdem noch nötig, die Informationen

über das erstellte Formular zwischen der Erstellungs- und Anzeigesubkom-

ponente zu transportieren. Die meisten BPM-Systeme bieten hierfür einen

Dienst für die persistente Verwaltung von Daten an. Es geht bei dieser An-

forderung daher nicht darum, wie das abstrakte Formular gespeichert wer-

den kann, sondern in welchem Format dies geschieht. Dieses Format muss

alle notwendigen Informationen kapseln und von beiden Subkomponenten

verstanden werden.

3.2 Anforderungen

Im Folgenden werden die Details der einzelnen Anforderungen diskutiert. Da-

bei fließen auch die gewonnen Erkentnisse über die Aufteilung in die Subkom-

ponenten ein. Die Anforderungen sind in zwei Kategorien eingeteilt: Nicht-

funktionale Anforderungen und funktionale Anforderungen. Zuerst werden

die nicht funktionalen Anforderungen besprochen, da diese allgemeine Be-

dingungen für das System definieren. Anschließend werden die funktionalen

Anforderungen näher erläutert, welche das Verhalten der Subkomponenten

betreffen.

3.2.1 Nichtfunktionale Anforderungen

3.2.1.1 Integrationsfähigkeit Eine Komponente zur Erstellung von

Formularen wird nicht als eigenständiges Programm genutzt werden. Das

bedeutet, dass der Einsatz nur im Kontext eines BPM-Systems sinnvoll ist.

Wenn die Komponente zur Formulargenerierung nicht zusammen mit dem

BPM-System entwickelt wird, sondern das BPM-System bereits existiert und

gegebenenfalls auch bereits im Einsatz ist, ist eine Integration der neuen

3.2 Anforderungen

Komponente in das Host-System notwendig. Dabei gibt es zwei Arten der

Integration, die beachtet werden müssen.

•logische Integration

•technische Integration

Logische Integration Die logische Integration findet bereits in der

konzeptionellen Phase der Softwareentwicklung statt. Hier geht es darum,

die zu integrierende Komponente inhaltlich an das Host-System anzupassen.

Dies bedeutet, dass die Konzepte, welche in dem bereits existierendem Sys-

tem umgesetzt worden sind, auch in der Komponente genutzt werden. Ist

dies nicht der Fall, können einige Apskete des BPM-Systems unter Umstän-

den durch den Einsatz der neuen Komponente nicht mehr genutzt werden.

Im Falle der Komponente für die Erstellung von Formularen, sind die BPM-

Datentypen ein Beispiel für ein solches Konzept. Im Idealfall werden die Da-

tentypen aus dem BPM-System auch in der neuen Komponente genutzt und

dort nicht erneut implementiert. Unter Umständen kann es jedoch sinnvoller

sein, eigene Datentypen für die Komponente zu implementieren, beispiels-

weise um die Informationen aus den Prozessschrittparameter unterteilen zu

können. In diesem Fall ist es notwendig, dass mindestens auch alle Daten-

typen aus dem BPM-System erneut implementiert werden.

Technische Integration Gegenstand der technischen Integration sind die

Schnittstellen des BPM-Systems und der Komponente. Um die Komponente

in der BPM-Suite nutzen zu können, müssen die beiden Programme aufeinan-

der abgestimmt sein und eine gemeinsame Schnittstellen verwenden. Es gibt

zwei Möglichkeiten eine gemeinsame Schnittstelle zu erreichen:

1. BPM-System an die Komponente anpassen

2. Komponente an das BPM-System anpassen

Die erste Möglichkeit hat den Vorteil, dass die neue Komponente den vollen

Funktionsumfang, den das existierende System anbietet, nutzen kann. Dies

setzt allerdings auch eine logische Integration der Komponente in das BPM-

System voraus. Die zu integrierende Komponente ist dann optimal auf das

Host-System zugeschnitten. Dem gegenüber steht allerdings ein wesentlich

höherer Aufwand, wenn die selbe Komponente in ein anderes System einge-

bunden werden muss. Dies erfordert ein erneutes Anpassen und Implemen-

tieren der Komponentenschnittstellen.

3 Anforderungen an eine Komponente zur Formularerstellung

Bei der zweite Möglichkeit geht es um die Entwicklung einer generischen

Komponente, die zu einer Vielzahl möglicher BPM-Systeme kompatibel ist.

Die Komponente muss, nachdem sie einmal entwickelt wurde, nicht mehr

geändert werden. Diese Möglichkeit hat allerdings auch den Nachteil, dass

man bei der Entwicklung des integrierenden Systems immer an die Schnitt-

stellen der Komponente halten muss. Ein weiterer Nachteil ist, dass eine

generische Komponente nicht logisch in ein BPM-System integriert werden

kann, da diese nicht für ein einzelnes BPM-System entwickelt wird.

Anforderung für diese Arbeit Die Komponente, welche im Rahmen

dieser Arbeit entwickelt wird, soll logisch in eine bereits existierende Imple-

mentierung von ADEPT2 integriert werden, um die Vorteile bereits imple-

mentierter Konzepte nutzen zu können. Da es sich bei der Implementierung

dieser Komponente im Rahmen dieser Arbeit um einen Prototypen handelt,

spielt die Generizität zumindest bei der Implementierung keine übergeord-

nete Rolle. Wichtig jedoch ist eine modulare Struktur des neuen Programms,

um das Ergebnis dieser Arbeit mit geringem Aufwand weiterentwickeln und

an andere BPM-Systeme anpassen zu können.

3.2.1.2 Einfache Bedienung Die Forderung nach einer einfachen Be-

dienbarkeit ist zunächst sehr abstrakt. Deshalb wird diese in den nächsten

Abschnitten konkreter formuliert. Es gibt im Grunde zwei Personengruppen,

welche mit der Komponente interagieren müssen:

•Die Formularentwickler

•Die Endanwender

Für beide Gruppen gelten dabei jeweils andere Anforderungen.

Einfachheit für Formularentwickler Für die Formularentwickler be-

zieht sich die Anforderung nach einer einfachen Bedienbarkeit auf die Ent-

wicklungsumgebung für Formulare. Es wird nicht davon ausgegangen, dass es

sich bei einem Formularentwickler immer um einen Informatiker handelt. Da-

her wird keine tiefergehende technische Programmierkenntnis vorausgesetzt.

Trotzdem muss das System leicht erlern- und bedienbar sein. Im Idealfall ist

die Entwicklungsumgebnug so intuitiv zu bedienen, dass nicht einmal eine

Schulung notwendig ist, um aus den Parametern des Prozessschrittes ein

Formular zu erstellen.

3.2 Anforderungen

Abbildung 20: Traditionelle Entwicklung einer Oberfläche

Dieses Ziel kann durch einen Assistenten erreicht werden, der den For-

mularentwickler durch gezielte Fragen den Hauptteil der Arbeit abnimmt

und triviale Aufgaben selbständig erledigt. Bei der Entwicklung von tradi-

tionellen Oberflächen, wie besispielswese SWT, muss der Entwickler Quell-

code angeben, der die Oberfläche zur Laufzeit anlegt. Dies ist in Abbildung 20

dargestellt. Mit speziellen Programmen können die Oberflächen auch grafisch

erstellt werden. Der Quellcode wird hierbei automatisch generiert. Der Ent-

wickler muss das Layout jedoch immer noch selbst gestalten.

Ein Assistent ist in einfachen Fällen in der Lage auch das Layout zu generie-

ren. Ein einfacher Fall liegt dann vor, wenn es sich bei den Parametern für

den Prozessschritt um einfache Daten handelt, und das Layout keine beson-

dere Anpassungen erfordert. Dies ist in Abbildung 21 dargestellt. In kom-

Vorname

Antrag genehmigen

Name Pers. Nr. genehmigt begründung

Abbildung 21: Entwicklung eines Formulars mit einem Assistenten

3 Anforderungen an eine Komponente zur Formularerstellung

plizierteren Fällen kann der Assistent den Formularentwickler involvieren,

um durch gezielte Fragen fehlende Informationen zu vervollständigen und

spezielle Wünsche und Anforderungen in das Formular zu integrieren.

Die Automatisierung der Formularerstellung ist dabei immer nur eine Op-

tion für den Formularentwickler. Um die Gestaltung der Formulare flexibel

zu halten und den Formularen bei Bedarf mehr Funktionalität, beispiels-

weise durch zusätzliche Anwendungslogik hinzuzufügen, muss eine manuelle

Änderung des Formulars durch den Formularentwickler immer möglich sein.

Einfachheit für Endanwender Für die Endanwender bezieht sich die

Einfachheit der Bedienung auf die Formulare selbst. Ein Formular ist dann

einfach zu bedienen, wenn ein Endanwender intuitiv in der Lage ist, ein

neues, bisher unbekanntes Formular zu lesen und zu bearbeiten. Das heißt,

dass keinerlei Schulungen im Umgang mit Formularen notwendig sind. Diese

Forderung ist wichtig, da die Endanwender aus den unterschiedlichsten Bran-

chen kommen können. Viele dieser Endanwender verfügen daher über kein

oder nur geringes technisches Verständnis. Für diese muss ein Formular eben-

so selbstverständlich benutzbar sein, wie für einen Informatiker.

Um dies zu erreichen, ist es wichtig, bei der Erstellung eines Formulares im-

mer auf die Komplexität zu achten. Die Komplexität eines Formulars hängt

zum Einen von Prozessschrittparameter ab und zum Anderen von deren

Darstellung im Formualr. Für diese Darstellung gibt es zwei Faktoren, die zu

beachten sind: Der Formularentwickler und der eben angesprochene Assis-

tent. Die Erstellung durch einen Formularentwickler kann nur durch hinre-

ichende Schulung bezüglich anwendungsfreundlicher Formularerstellung be-

einflusst werden. Für den Erstellvorgang durch den Assistenten hingegen ist

die Komponente verantwortlich. Es ist beim Entwurf eines Assistenten für

die Formularerstellung darauf zu achten, dass ein generiertes Formular auch

komplexe Parameter übersichtlich darstellt.

Zusammenfassung Für die Entwicklung der neuen Komponente ist es

sehr wichtig, dass sie den Formularentwickler bei seiner Arbeit unterstützt

und automatisierbare Aufgaben selbständig durchführt. Der Formularent-

wickler muss mit einem Minimum an Aufwand zu einem gutem Ergebnis kom-

men, aber trotzdem die Möglichkeit haben, das Formular teilweise oder voll-

ständig, individuellen Bedürfnissen anzupassen. Es ist ebenfalls von großer

Bedeutung, dass das vollständig generierte Formular auch bei komplexen

3.2 Anforderungen

Ein- und Ausgabeparametern immer so einfach gehalten wird, dass auch

fachfremde Endanwender problemlos damit zurecht kommen können.

3.2.1.3 Lizenz Ein weiteres wichtiges Thema bei der Entwicklung von

Software ist die Lizenz, welche für die Software verwendet wird. Besonders

bei Projekten, bei denen Software von Drittanbietern integriert wird, ist es

wichtig, sich mit dieser Frage auseinander zu setzen. Welche Lizenz für eine

Software verwendet werden darf, hängt hierbei von mehreren Faktoren ab.

Auf der einen Seite wird die Lizenz für eine Komponente von der verwende-

ten Lizenz des Host-Systems beeinflusst. Ein vorhandene System kann unter

einer Lizenz stehen, welche dazu verpflichtet, alle Quellen des Systems (ein-

schließlich der aller Komponenten) offen zu legen, wie zum Beispiel die GPL

[GNU91]. In diesem Fall darf die Komponente nicht mit einer Lizenz verse-

hen werden, welche genau dies verhindert. Wenn die Komponente für ein

spezielles System entwickelt wird und nicht unbedingt generisch sein muss,

richtet sich die Lizenz für die Komponente nach der Lizenz des Systems, in

welches die Komponente integriert werden soll.

Auf der anderen Seite ist es natürlich ebenso möglich, dass die Komponente

selbst wieder aus bereits existierenden Komponenten und Programmen be-

steht. Diese stehen ebenfalls wieder unter einer Lizenz, welche beachtet wer-

den muss. Eine Komponente eines Drittanbieters, welche nur für den privaten

Gebrauch der Software lizenziert ist, darf nicht in die eigene Komponente in-

tegriert und so vertrieben werden. In diesem Fall muss die Lizenz der eigenen

Software, also auf die Lizenzen der verwendeten Software, abgestimmt sein.

Es gibt auch Fälle, in denen beide Aspekte zutreffen. Wenn eine Kompo-

nente für ein System entwickelt wird und selber wieder bereits existierende

Software von anderen Herstellern integriert, müssen sowohl die Lizenzen der

integrierten Software, als auch die des integrierenden Host-Systems beachtet

werden.

Um das Ergebnis dieser Arbeit auch in Zukunft weiterentwickeln und diese

Entwicklungen veröffentlichen zu können, kommt es darauf an, dass die Kom-

ponente zur Erstellung von Formularen keine Lizenz verwendet, die dies-

bezüglich Restriktionen aufweist. Insbesondere bedeutet dies, dass auch die

Quellen offen gelegt werden müssen. Bei der Verwendung von Software welche

zur Einbettung in die Komponente vorgesehen ist, ist auf die Kompatibilität

der Lizenz zu achten. Da die Quellen der ADEPT2-Implementierung mo-

mentan nicht frei verfügbar sind, ist beispielsweise die GPL [GNU91] keine

Option im Rahmen dieser Arbeit.

3 Anforderungen an eine Komponente zur Formularerstellung

3.2.2 Funktionale Anforderungen

Nachdem im vorherigen Abschnitt die grundlegenden nichtfunktionalen An-

forderungen der neuen Komponente besprochen worden sind, werden in den

folgenden Abschnitten die Details für das Verhalten dieser Komponente

diskutiert. Begonnen wird mit den allgemeinen Askpekten. Dazu zählen

die Anforderungen zu den grafischen Kontexten, den Datentypen und auf

diesen aufbauend die grafischen Komponenten, die für die Darstellung der

Daten verantwortlich sind. Anschliessend werden die Anfoderungen zur An-

wendungslogik und der damit eng verbundenen Restriktionen für Formul-

are vorgestellt. Die darauf folgenden Abschnitte beschäftigen sich mit den

spezielleren Anforderungen, wie Formularhistorie, Lokalisierung und exter-

nen Datenquellen.

3.2.2.1 Grafische Kontexte Formulare dienen der Interaktion mit dem

Endanwender und sind daher Bestandteil der grafisschen Oberfläche eines

BPM-Systems. Für die Erstellung von Formularen gelten deshalb die sel-

ben Rahmenbedingen, wie für alle anderen grafischen Oberflächen des Sys-

tems. Welche Rahmenbedingen dies sind, ist wiederum vom verwendeten gra-

fischen Kontext abhängig, da unterschiedliche Kontexte auch unterschiedliche

Möglichkeiten bieten. Die Beschreibung des Layouts eines Formulars muss je-

doch unabhängig von den Möglichkeiten eines grafischen Kontextes erfolgen.

Motivation Ein BPM-System muss nicht auf einen grafischen Kontext

beschränkt sein. Prinzipiell können durch das System beliebig viele Kontexte

unterstützt werden. Das Problem dabei ist jedoch, dass nicht unbedingt bei

jedem Endanwender alle Kontexte umgesetzt werden können, beispielsweise,

weil die erforderliche Software zum Betrachten eines PDF-Dokumentes nicht

installiert ist. Es ist daher zwar zur Entwurfszeit bekannt, welche grafischen

Kontexte das BPM-System generell unterstützt, jedoch nicht, welche dieser

Kontexte bei welchem Endanwender verfügbar sein werden. Daher ist es nicht

möglich sich zur Entwurfszeit auf einen grafischen Kontext festzulegen, mit

dem das Formular beschrieben wird. Um Formulare denoch bei jedem End-

anwender darstellen zu können ist es notwendig, den grafischen Kontext, der

für die Darstellung eines Formulars verwendet wird erst zur Laufzeit festzule-

gen. Dazu muss das Formular zur Entwurfszeit jedoch kontextunabhänig be-

schrieben werden. Diese Beschreibung muss dann zur Laufzeit für einen der

vorhandenen Kontexte übersetzt werden.

3.2 Anforderungen

orderDate

deliveryOption

express

name

street

city

zip

country

Formular in einem PDF-Kontext Formular in einem SWT-Kontext

Abstrakte Formularbeschreibung

Abbildung 22: Formulare in unterschiedlichen Kontexten mit ähnlichem

Aussehen

Probleme Diese Anforderung erfordert beim Entwurf der Komponente

die Festlegung auf ein eigenes kontextunabhängiges Format zur Formular-

beschreibung. Dieses Format muss alle Informationen beinhalten, die nötig

sind, um das Formular zur Ausführungszeit für jeden Kontext zu überset-

zen, den das BPM-System zur Verfügung stellt. Ein Problem sind die unter-

schiedlichen Möglichkeiten der einzelnen Kontexte. In einem Formular inner-

halb eines SWT-Kontextes ist es beispielsweise möglich, baumartige Struk-

turen darzustellen. Bei einer Beschreibung des Formulars durch HTML ist

dies nur mit einigem Aufwand zu erreichen. Es muss jedoch sichergestellt wer-

den, dass ein Formular in allen vom BPM-System bereitgestellten Kontexten

ein ähnliches Aussehen und Verhalten hat.

Bei der Festlegung eines Formates für eine abstrakte Formularbescheibung

ist deshalb darauf zu achten, dass die Beschreibung in allen Kontexten auch

3 Anforderungen an eine Komponente zur Formularerstellung

umgesetzt werden kann. Ein Beispiel für die Umsetzung eines abstrakten

Formulars für zwei Kontexte zeigt Abbildung 22. Um ein Format für die

Beschreibung festzulegen, dürfen nur Elemente verwendet werden, welche

von allen Kontexten unterstützt werden.

Zusammenfassung Zur Beschreibung eines Formulars stehen meherere

grafischen Kontexte zur Verfügung, welche jedoch nicht alle beim Endan-

wender umgesetzt sein müssen. Um trotzdem die korrekte Darstellung bei

jedem Endanwender garantieren zu können, muss die Beschreibung des For-

mulars zur Entwurfszeit kontextunabhängig erfolgen. Zur Laufzeit muss diese

Beschreibung in jeden Kontext übersetzbar sein. Für die Beschreibung sind

deshalb nur Möglichkeiten zugelassen, die sich in allen Kontexten umsetzen

lassen.

3.2.2.2 Datentypen Die Hauptaufgabe von Formularen in einem BPM-

System ist die Präsentation und das Abfragen von Informationen. Wie be-

reits aus Kapitel 2 bekannt ist, werden Datentypen benötigt, um die Da-

ten aus dem BPM-System als Informationen interpretieren zu können. In

diesem Abschnitt wird erläutert, welche Art von Daten für das BPM-System

wichtig sind, und welche Datentypen benötigt werden, um diese Daten zu

interpretieren.

Einfache Informationen Ein großer Teil der Informationen die in einem

Geschäftsprozess vorkommen, lassen sich in mehrere Gruppen einteilen.

Dazu zählen Wahrheitswerte, Text und Zahlen. Datentypen für solche Infor-

mationen sind in vielen Programmiersprachen und BPM-Systemen bereits

vorhanden. Einige solcher Typen sind:

•String

•Integer

•Float

•Boolean

Komplexe Informationen Es gibt jedoch auch komplexere Informati-

onen, welche sich nicht durch einen dieser einfachen Datentypen beschreiben

lassen, wie beispielsweise eine Adresse.

3.2 Anforderungen

Adresse

Straße : STRING

Hausnummer : INTEGER

Postleitzahl : INTEGER

Stadt : STRING

Land : STRING

Abbildung 23: Strukturierter Datentyp für eine Adresse

Eine solche Information besteht in der Regel aus mehreren Elementen. Diese

Elemente, wiederum stellen eigene, getrennte Informationen dar. Die Adresse

besteht zum Beispiel aus den Elementen Straße, Hausnummer, Postleitzahl,

Stadt und Land (Abbildung 23).

Eine Adresse lässt sich daher nicht mittels eines einfachen Datentyps wie bei-

spielsweise einem String beschreiben. Die Informationen der einzelnen Ele-

mente der Adresse würden verloren gehen, wenn diese in einem gemeinsamen

Text gespeichert werden. Es lässt sich nicht zweifelsfrei festlegen welcher Teil

des Textes die Stadt und welcher Teil die Straße beinhaltet. Dafür ist eine

einheitliche Kodierung der Elemente innerhalb des Textes notwendig. Die

Verwendung einer entsprechenden Kodierung kann bei sehr komplexen Infor-

mationen jedoch zu unübersichtlichen Texten führen.

Wie eine komplexe Information zu interpretieren ist, ist immer von dessen

Struktur abhängig. Daher ist es möglich komplexe Informationen mit Hil-

fe von Datentypen zu beschreiben, welche ebenfalls eine komplexe Struktur

besitzen. Eine mögliche Darstellung der interpretierten Daten einer Adresse

wird in Abbildung 24 gezeigt.

Abbildung 24: Daten interpretiert als Adressinformation

3 Anforderungen an eine Komponente zur Formularerstellung

Dateien als Informationen Es gibt auch komplexe Informationen, die

sich selbst mit strukturierten Datentypen nur schwer beschreiben lassen. Bei-

spielsweise die Informationen, die in einer Excel-Tabelle oder einem Adobe-

Dokument zu finden sind. Besonders schwierig ist die Strukturierung von

Daten aus binären Dateien. Deren Inhalt ist zwar ebenfalls eine Informati-

on, jedoch lässt sich für beliebige binäre Daten keine einheitliche Struktur

angeben.

Deshalb müssen Dateien als Informationen in einem Formular separat behan-

delt werden. Auch hierfür soll die neue Komponente entsprechend vorberei-

tet werden. Es muss möglich sein, Dateien sowohl als Eingabe- wie auch als

Ausgabeparameter von Prozessschritten zu verwenden. Wird eine Datei als

Eingabeparameter verwendet, muss der Endanwender im Formular die Mög-

lichkeit erhalten diese zu speichern oder lokal in einer dafür vorgesehenen

externen Anwendung zu betrachten. Wird die Datei als Ausgabeparameter

angegeben, muss der Endanwender eine Datei auf seinem lokalen System dem

Formular hinzufügen können, um diese dem BPM-System zu übergeben.

Listenwertige Informationen Ebenso wichtig wie strukturierte Informa-

tionen sind listenwertige Informationen, wie beispielsweise eine Einkaufsliste

in einem Onlineshop. Eine solche Liste könnte zwar durchaus als komplexer

Datentyp gesehen werden, der aus mehreren Komponenten mit jeweils dem

selben Datentyp besteht (Abbildung 25). Allerdings hat dies den Nachteil,

dass die Länge der Liste durch die Anzahl der Komponenten nicht veränder-

bar ist. Für eine längere Liste muss ein neuer Datentyp mit mehr Kompo-

nenten erstellt werden.

Dies ist eine unzureichende Lösung, da die Anzahl der Elemente in der Liste

zur Ausführungszeit des Formulars variabel bleiben muss. Bei listenwertigen

Datentypen handelt es sich daher um einen weiteren Sonderfall, welcher von

der neuen Komponente beachtet werden muss.

Zusammenfassung Grundlage für Informationen sind die Daten aus den

Parametern der Prozessschritte. Diese Daten müssen interpretiert werden,

um Informationen zu erhalten. Es gibt verschiedene Arten von Informati-

onen, die in einem BPM-System von Bedeutung sind. Welche Informationen

konkret verwendet werden, ist zur Entwurfszeit nicht bekannt. Um das Sys-

tem also vor laufenden Änderungen zu bewahren, und auch in Zukunft mit

neuen Arten von Informationen umgehen zu können, muss die neue Kom-

ponente in der Lage sein, die Art der Informationen zu beschreiben. Hierfür

3.2 Anforderungen

Einkaufsliste

Posten1 : Einkaufsposten

Posten2 : Einkaufsposten

Posten3 : Einkaufsposten

Posten4 : Einkaufsposten

Posten5 : Einkaufsposten

Abbildung 25: Liste als strukturierter Datentyp mit fester Länge

sollen die bereits vorhandenen Datentypen des BPM-Systems, strukturierte

Datentypen, listenwertigen Datentypen oder Datentypen für Dateien verwen-

det werden.

3.2.2.3 Grafische Elemente Im letzten Abschnitt sind die Datentypen

besprochen worden, die dabei helfen, die Daten aus dem BPM-System als

Informationen zu interpretieren. In diesem Abschnitt geht es um die gra-

fische Repräsentation dieser Informationen im Formular. Es ist die Aufgabe

des Formularentwicklers die Parameter des Prozessschrittes im Formular auf

grafische Elemente abzubilden, welche die Informationen dieser Parameter

korrekt und sinnvoll anzeigen. Dabei gibt es zwei wichtige Aspekte zu beach-

ten:

Endanwendergewohnheiten BPM-Systeme werden von Unternehmen

aus allen Branchen benötigt. Die Endanwender, die mit diesem System ar-

beiten, sind daher meistens nicht der IT-Branche zuzuordnen. Der Umgang

mit einem PC hat sich in der Geschäftswelt dennoch stark etabliert. Da-

raus ergeben sich Gewohnheiten der Endanwender, was auch die Benutzung

von grafischen Oberflächen betrifft. Endanwender kennen aus der täglichen

Arbeit eine Reihe von grafischen Standardelementen, welche daher bereits

vertraut sind. Einige davon sind in Abbildung 26 aufgezeigt. Da das System

den Endanwender unterstützen soll, muss sich das System den Erwartungen

und Gewohnheiten des Endanwenders anpassen.

Eine weitere Gewohnheit der Mitarbeitern von Unternehmen betrifft den

Umgang mit nichtdigitalen Formularen. Digitale Formulare finden erst seit

einigen Jahren Verbreitung in Unternehmen. Um den Endanwender den Um-

3 Anforderungen an eine Komponente zur Formularerstellung

Abbildung 26: Standardelemente grafischer Oberflächen

stieg auf die neue Form der Formulare zu erleichtern ist es notwendig, dass

Formulare, welche von einem BPM-System erstellt werden, ein grafisches

Pendant der traditionellen Formulare darstellen. Abbildung 27 zeigt ein For-

mular für eine elektronische Überweisung. Die verwendeten Felder sind denen

eines traditionellen Überweisungsformulars (Abbildung 28) sehr ähnlich.

Abbildung 27: Beispielformular für elektronische Überweisungen [FID09]

3.2 Anforderungen

Abbildung 28: Traditionelles Überweisungsdokument

Grafische Elemente in unterschiedlichen Kontexten Neben den Ge-

wohnheiten der Endanwender gibt es noch einen weiteren Punkt, der die

bereits angedeutete Auswahl von grafischen Komponenten einschränkt: In

unterschiedlichen Kontexten gibt es teilweise unterschiedliche grafische Ele-

mente. In einer HTML-Umgebung stehen dem Formularentwickler bei-

spielsweise grafische Elemente zur Verfügung um Dateien zu übergeben

(Abbildung 29, links). In einem SWT-Composite muss ein solches Element

erst erstellt werden (Es gibt zwar einen sogenannten File-Dialog, es gibt

jedoch kein grafisches Element, welches diesen automatisch öffnet und die

angegeben Dateien verwaltet).

Auf der anderen Seite gibt es in einem SWT-Kontext grafische Elemente um

Baumstrukturen darstellen zu können (Abbildung 29, rechts). Dafür gibt es

in einem HTML-Kontext noch keine fertigen grafischen Elemente.

Selbst bei grafischen Elementen, welche in mehreren Kontexten vertreten

sind, kann es sein, dass sich diese Komponenten bezüglich ihrer Anwen-

dung oder ihres Verhaltens unterscheiden. Es gibt in einem HTML-Kontext

beispielsweise Schaltflächen, welche den Inhalt der grafischen Elemente des

HTML-Dokuments an einen entfernten Server senden. Im SWT-Kontext gibt

es ebenfalls Schaltflächen, jedoch haben diese ein anderes Verhalten. Dies

muss bei der Umsetzung der Formulare zur Ausführungszeit berücksichtigt

werden.

3 Anforderungen an eine Komponente zur Formularerstellung

Abbildung 29: Kontextbezogene grafische Elemente [Mü08b].

Zusammenfassung Der Formularentwickler hat die Aufgabe, die Infor-

mationen der Parameter grafisch auf das Formular abzubilden. Dabei stehen

verschiedene grafische Elemente zur Verfügung. Welche grafischen Elemente

eingesetzt werden können, orientiert sich zum Einen an den Gewohnheiten

des Endanwenders. Hier ist der Umgang mit traditionellen Formularen und

der Umgang mit grafischen Oberflächen von Softwaresystemen zu beachten.

Zum Anderen wird die Auswahl der Elemente durch die unterstützten gra-

fischen Kontexte beeinflusst.

3.2.2.4 Integration von Anwendungslogik In den letzten Abschnit-

ten wurden grundlegende Anforderungen bezüglich grafischen Kontexten und

Elementen und Datentypen dargelegt. Im folgenden Abschnitt soll darauf

aufbauend über die Integration von Anwendungslogik in Formulare disku-

tiert werden. Es wurde bereits erwähnt, dass ein Formular die Aufgabe hat,

Daten zu präsentieren und Daten von Endanwendern abzufragen. Für viele

Formulare sind diese Möglichkeiten ausreichend. Bei komplexeren Formularen

ist es jedoch auch sinnvoll, bereits im Formular mit diesen Daten arbeiten zu

können.

Gründe für Anwendungslogik in Formularen Es gibt Fälle in denen

eine präzisere Steuerung des Verhaltens von Formularen gewünscht ist. Ein

Beispiel mit einem Formular eines Onlineshops soll dies zeigen: Bei dem

Formular soll es möglich sein, verschiedene Artikel auszuwählen, welche alle

3.2 Anforderungen

Abbildung 30: Formular für Einkaufsliste mit automatischer Preisberech-

nung [Ein09]

einen definierten Preis haben. Das Formular muss den Gesamtpreis aller aus-

gewählter Artikel berechnen und dem Endanwender anzeigen. Bei einer Än-

derung der Posten der Einkaufsliste muss dieser Preis neu berechnet werden.

Abbildung 30 zeigt ein entsprechendes Formular.

Eine solche Anforderung kann auch mit normalen Formularen ohne zusät-

zliche Anwendungslogik gelöst werden, in dem man dem BPM-System die

Verantwortung der Berechnung übergibt. Dafür muss man nach jeder Än-

derung des Formulars dieses abschicken und anschließend in einem separaten

Prozessschritt den neuen Preis berechnen. Dannach wird ein neues Formular

mit der geänderten Einkaufsliste und dem geänderten Preis erstellt.

Diese Lösung ist jedoch nicht sehr elegant, da das BPM-System dabei einen

Teil der Anwendungslogik übernehmen muss, der nicht zur Semantik des

Prozesses gehört. Außerdem verursacht jede Änderung durch das Erstellen

eines neuen Formulares eine Wartezeit für den Endanwender. Besser ist es,

die Berechnung innerhalb des Formulars durchführen zu können und damit

Zeit zu sparen und das BPM-System nicht unnötig zu belasten.

Probleme mit Anwendungslogik in Formularen Wenn man Berech-

nungen durch das BPM-System in separaten Prozessschritten durchführt,

muss sich der Formularentwickler keine Gedanken um die Ausführung

von Anwendungslogik machen. Wird die Berechnung jedoch im Formular

durchgeführt, muss auch sichergestellt werden, dass diese Geschäftslogik in-

nerhalb der Ausführzeit des Formulars ausgeführt wird. Dies kann zu einem

Problem werden, wenn man sich nochmal mit den unterschiedlichen Kontex-

3 Anforderungen an eine Komponente zur Formularerstellung

ten befasst, in denen ein Formular ausgeführt werden kann. Die Kontexte

müssen die Verarbeitung von Geschäftslogik unterstützen. Wenn ein Formul-

ar als SWT-Anwendung realisiert wird, kann die Anwendungslogik als zusätz-

licher Quellcode implementiert werden. Bei einer Realisierung des Formulars

in Form eines PDF-Dokumentes ist zusätzliche Anwendungslogik jedoch ein

Problem. Bei diesem Dokumenttyp ist es nicht möglich, das Verhalten des

Dokumentes zu beeinflussen.

Selbst wenn bei allen eingesetzten Kontexten die Unterstützung zusätzlicher

Anwendungslogik möglich ist, gibt es noch ein weiteres Problem: Das Verhal-

ten der Logik muss in allen Kontexten identisch sein. Die Logik wird vom For-

mularentwickler zur Erstellzeit des Formulars beschrieben. Zu diesem Zeit-

punkt ist es jedoch nicht möglich zu sagen, in welchem Kontext das Formular

tatsächlich ausgeführt wird. Daher ist es notwendig, dass die Anwendungs-

logik auf abstrakte Weise beschrieben wird, ohne Details über den Kontext

beachten müssen.

Das löst das Problem jedoch nicht vollständig. Ähnlich wie bei den grafischen

Elementen ist die Ausführungsumgebung dafür verantwortlich die Anwen-

dungslogik semantiktreu von der abstrakten Beschreibung in eine zum Kon-

text kompatible Logik zu übersetzen.

Anforderung an die neue Komponente Die neu zu entwickelnde Kom-

ponente hat die Aufgabe, dem Formulardesigner die Entwicklung von For-

mularen mit einer hohen Funktionalität und einem intelligentem Verhalten

zu ermöglichen. Der Formularentwickler muss dabei die Möglichkeit haben,

das Formular auf Benutzereingaben reagieren zu lassen, beliebige Berechnun-

gen mit den Daten des Formulars durchzuführen, und das Ergebnis dieser

Berechnungen dynamisch zur Ausführzeit wieder im Formular zu präsen-

tieren. Dieses durch den Formularentwickler definierte Verhalten darf sich in

verschiedenen Kontexten nicht unterscheiden.

3.2.2.5 Lokalisierung In diesem Abschnitt wird die Anpassungs-

fähigkeit der Formulare an Endanwender erläutert. Zuerst werden mögliche

Gründe für die Fähigkeit von Formularen sich an Endanwender anpassen zu

können aufgezählt. Anschließend folgt eine Diskussion über zwei Ansatzpunk-

te für eine Anpassung des Formulars und ihre Probleme.

Motivation Häufig agieren große Unternehmen nicht nur auf nationaler

Ebene, sondern weltweit. Dies führt dazu, dass in dem Unternehmen Men-

3.2 Anforderungen

Abbildung 31: Barrierefreie Tastatur [BWF09]

schen aus unterschiedlichen Ländern zusammenarbeiten. Diese Mitarbeiter

arbeiten alle mit den selben Prozessen und daher auch mit den selben For-

mularen. Da man nicht annehmen darf, dass alle Mitarbeiter die selben

Sprachen beherrschen und die selbe Schrift benutzen, ist es für ein BPM-

System wichtig, Formulare anzubieten mit der alle Beteiligten zurechtkom-

men.

Ein weiterer wichtiger Grund für die Anpassungsfähigkeit von Formularen

ist die Berücksichtigung von Menschen, die auf Barrierefreiheit angewiesen

sind. Mitarbeiter, welche keine Sehfähigkeiten besitzen, müssen den Inhalt

von Formularen auf eine andere Weise wahrnehmen können. Die traditionelle

grafische Lösung ist hier nicht möglich. Der Inhalt muss verbal mitgeteilt wer-

den oder auf einer speziellen Hardware mit Unterstützung für Blindenschrift

präsentiert werden, wie sie in Abbildung 31 dargestellt ist.

Ansatzpunkte Eine Möglichkeit die Anpassung vorzunehmen, ist zur Ent-

wicklungszeit des Prozesses für jede Endanwendergruppe ein eigenes Formul-

ar zu erstellen, welches genau auf die Zielgruppe zugeschnitten ist. Zur Aus-

führungszeit des Formulars hat der Endanwender dann die Möglichkeit das

für ihn am besten geeignete Formular auszuwählen und mit diesem dann zu

arbeiten.

3 Anforderungen an eine Komponente zur Formularerstellung

Dieses Vorgehen ist aus mehreren Gründen sehr aufwändig. Zum Einen muss

für jede Endanwendergruppe ein eigenes Formular erstellt werden. Zum An-

deren können sich die Anforderungen an die Lokalisierung ändern, wenn bei-

spielsweise eine weitere Sprache angeboten werden muss. Dies erfordert ein

Anpassen aller bisher entworfenen Formulare.

Bessere ist es, wenn jedes Formular nur einmal entworfen wird und die Aus-

führungsumgebung das Formular für den jeweiligen Endanwender automa-

tisch zur Ausführungszeit anpasst. Dazu benötigt diese jedoch Informati-

onen über den entsprechenden Endanwender. Ein großes Problem bei diesem

Ansatzpunkt ist, dass die Sprache automatisch in eine vom Endanwender

beherrschte Sprache übersetzt werden muss. Die Technologie für eine sowohl

grammatikalisch, also auch semantisch korrekte Übersetzung ist jedoch bei

weitem noch nicht ausgereift, was zu Verwirrung bei unklar übersetzten

Textbausteinen führen kann.

Zusammenfassung Es gibt verschiedene Gründe für eine Lokalisierung

der Formulare an verschiedene Endanwender. Zum Einen sind das die sprach-

lichen Unterschiede der Endanwender. Zum anderen stellt die Barrierefreiheit

für manche Endanwender ein wichtiges Kriterium dar.

Hier sind zwei grundsätzliche Herangehensweisen denkbar: Die Anpassung

kann durch den Formularentwickler, durch das Erstellen mehrerer Formulare

für den selben Prozessschritt geschehen oder durch die Laufzeitumgebung

durch dynamisches Anpassen eines einzelnen Formulars.

Die neue Komponente für die Formularerstellung soll in der Lage sein, dem

Endanwender ein für ihn angepasstes Formular zu bieten, welches keine in-

haltlichen Unklarheiten durch die Lokalisierung enthält. Der Formularent-

wickler soll dennoch nicht gezwungen sein, für jede neue Sprache alle For-

mulare neu zu erstellen.

3.2.2.6 Anbindung externer Datenquellen Bis jetzt wurde davon

ausgegangen, dass alle Informationen, welche in dem Formular präsentiert

werden, auf den Parametern des Prozessschrittes basieren. Im Idealfall ist

dies auch so, da dadurch das BPM-System die volle Kontrolle über die Infor-

mationen hat, welche dem Endanwender dargestellt werden. Es ist allerdings

möglich, dass dem Endanwender die Informationen aus den Prozessschrittpa-

rametern nicht ausreichen, um das Formular Bearbeiten zu können. Daher ist

es wünschenswert, Daten und Informationen außerhalb des Zuständigkeits-

3.2 Anforderungen

bereiches des BPM-Systems in das Formular einbinden zu können, beispiels-

weise von einer externen Datenbank.

Allerdings ist dabei zu beachten, dass die Informationen bei jedem Aufruf

des Formulars variieren können, da sie nicht durch die Prozesslogik kontrol-

liert werden. Ein Endanwender, der das Formular heute bearbeitet, kann mit

anderen Werten arbeiten, wie ein Endanwender, welcher das selbe Formular

im selben Prozessschritt zu einem anderen Zeitpunkt bearbeitet.

3.2.2.7 Restriktionen für Formularfelder Dieser Abschnitt beschäf-

tigt sich mit der Beschränkung von Endanwendereingaben in Formularen,

wie zum Beispiel die Länge der Eingabe in einem Textfeld.

Motivation Nicht immer sind alle Eingaben sinnvoll, die in einem For-

mularfeld möglich sind. Welche Eingaben möglich sind, kann bereits durch

Angabe eines Datentyps beeinflusst werden. Dies verhindert, dass in ein Feld

ein Name eingegeben wird, obwohl beispielsweise eine Jahreszahl erwartet

wird. Etwas komplizierter wird es jedoch, wenn eine Eingabe eine bestimmte

Codierung (Syntax) erwartet. Bei einem Textfeld, welches für die Eingabe

eines deutschen Autokennzeichens gedacht ist, ist die Eingabe von Kräutertee

im Sinne des Datentyps durchaus korrekt. Die Syntax stimmt jedoch nicht.

Noch schwieriger wird die semantische Analyse der Eingabe. In einem Feld,

welches an einen ganzzahligen Datentypen gebunden ist und die Eingabe des

Alters einer menschlichen Person erwartet, ergibt die Eingabe 4711 oder -

3wenig Sinn. Es ist zwar möglich, jedoch ist die Eingabe semantisch nicht

korrekt.

Um die Benutzung von Formularen zu erleichtern, muss der Endanwender auf

falsche Eingaben hingewiesen werden oder im Idealfall sogar daran gehindert

werden. Die Formularfelder müssen dazu mit Restriktionen belegt werden,

welche den gültigen Wertebereich für die Eingaben beschränken.

Möglichkeiten der Restriktion Es gibt verschiedene Varianten solcher

Beschränken für Felder in Formularen.

•Untere und obere Schranken für Zahlenfelder

•Mindest- und Maximallänge für Textfelder

•Übereinstimmung mit regulärem Ausdruck

•Obligatorische Zeichen oder Zeichengruppen

3 Anforderungen an eine Komponente zur Formularerstellung

Eine Angabe von Schranken bei Zahlenfeldern lässt nur sinnvolle Eingaben

von Altersangaben zu. Mit regulären Ausdrücken kann die Korrektheit der

Syntax bei Textfeldern geprüft werden. Und durch die obligatorische Verwen-

dung bestimmter Zeichen bei Textfeldern kann die Sicherheit bei Eingabe von

Passwörtern verbessert werden.

Für die korrekte Angabe der Restriktionen ist der Formularentwickler wäh-

rend der Erstellzeit verantwortlich. Es stellt sich jedoch die Frage, wie die

Restriktionen umgesetzt werden. Durch die Verwendung der bereits disku-

tierten Anwendungslogik ist der Formularentwickler in der Lage bei jedem

Feld während der Eingabe zu prüfen, ob der Endanwender korrekte Angaben

macht. Dies führt allerdings zu einem erhöhten Aufwand bei der Erstellung,

da für jedes beschränkte Feld eine aufwendige Logik notwendig ist. Besser ist

es, die oben aufgezählten Restriktionsmöglichkeiten direkt an Formularfelder

binden zu können. Der Formularentwickler kann dann beim Anlegen eines

Formularfeldes direkt eine oder mehrere Beschränkungen mit angeben und

muss keine zusätzliche Anwendungslogik zu jedem Feld erstellen.

Probleme von Restriktionen Wie bereits im Abschnitt über Anwen-

dungslogik angesprochen, stellt sich auch hier die Frage nach der Kompatibi-

lität mit unterschiedlichen Kontexten, in denen das Formular bearbeitet wer-

den kann. Der Kontext muss die Möglichkeit Formularfelder zu beschränken

unterstützen. Ist dies nicht der Fall, ist eine Überprüfung der Angaben wäh-

rend der Ausführungszeit nicht möglich. Der Inhalt des Formulars muss dann,

nachdem der Endanwender die Bearbeitung abgeschlossen hat, bezüglich der

vorhandenen Restriktionen geprüft werden. Wenn in den Eingaben des End-

anwenders Fehler gefunden werden, muss dieser das Formular erneut bear-

beiten, um die Fehler zu beseitigen. Dies macht zum Einen zusätzliche Pro-

zessschritte nötig und zum Anderen erschwert dies die Bearbeitung des For-

mulars durch den Endanwender. Für diesen ist es besser, bereits bei der

Eingabe auf Fehler hingewiesen zu werden.

Zusammenfassung Nicht alle Eingaben der Endanwender bei Formularen

ergeben Sinn. Syntaktisch oder inhaltlich falsche Eingaben müssen durch Res-

triktionen verhindert werden. Der Formularentwickler kann dies durch Ge-

schäftslogik oder durch direkte Angabe der Beschränkungen erreichen. Die

Prüfung der Restriktionen kann während der Eingabe oder nach dem Ab-

schluss der Arbeiten an dem Formular durchgeführt werden. Wie bei der An-

wendungslogik gibt es die Problematik mit inkompatiblen Kontexten. Einer

3.2 Anforderungen

Prüfung der Eingaben nach der Bearbeitung macht zusätzliche Prozessschrit-

te nötig und führt zu einem größeren Aufwand für den Endanwender.

Die Komponente für Erstellung von Formularen ist so zu gestalten, dass

der Formularentwickler die Möglichkeit hat, Beschränkungen ohne großen

Aufwand umzusetzen. Für den Endanwender soll dies möglichst transparent

und komfortabel sein.

3.2.2.8 Wiederverwendung historischer Formulardaten

Motivation Ein Prozess besteht in der Praxis nicht nur aus einem einzel-

nen Prozessschritt mit einem Formular, sondern aus zahlreichen Prozess-

schritten mit vielen unterschiedlichen Formularen. Dabei stellen die einzel-

nen Formulare keine abgeschlossenen semantischen Einheiten dar. Vielmehr

bauen die Formulare aufeinander auf. Die Inhalte der Formulare befassen sich

dabei alle mit einer gemeinsamen Semantik, welche durch den gemeinsamen

Prozess definiert ist. Viele Formulare greifen dabei auf dieselben Prozess-

schrittparameter zurück, oder nehmen aufeinander Bezug, indem ein Formul-

ar auf ein anderes Formular aus einem bereits abgearbeiteten Prozessschritt

verweist.

Probleme möglicher Lösungsansätze Um den Endanwender bei sei-

ner Arbeit mit vielen unterschiedlichen und komplexen Formularen zu un-

terstützen, ist es von Vorteil, wenn in Formularen das Ergebnis bereits

abgearbeiteter Formulare des selben Prozesses mit dargestellt wird, wie es

in Abbildung 32 dargestellt ist. Der Endanwender hat damit einen besseren

Überblick über bisher im Prozess verwendeten Daten.

Hierfür gibt es die Möglichkeit diese Verantwortung entweder der Laufzeit-

umgebung oder dem Formularentwickler zu übertragen. Die Laufzeitumge-

bung kann für ein Formular die Ergebnisse aller bisherigen Formulare in

das aktuelle Formular einfügen. Der Endanwender hat dann alle Informati-

onen, welche er möglicherweise für die Bearbeitung des aktuellen Formulars

benötigt. Dies hat allerdings auch den Nachteil, dass das Formular schnell

unübersichtlich werden kann, wenn ein Prozess aus vielen Schritten besteht.

Eine Alternative ist die selektive Auswahl von Formularen und Formularfel-

dern durch den Formularentwickler bereits zur Erstellungszeit. Hierbei wer-

den nur diejenigen Informationen dargestellt, welche zusätzlich zu den Pro-

zessschrittparametern des Formulars zur Bearbeitung des Formulars relevant

3 Anforderungen an eine Komponente zur Formularerstellung

Parameter 1

Formular 1

Parameter 2

Parameter 3

Absenden

Parameter 1

Formular 2

Parameter 2

Parameter 3

Absenden

Parameter 4

Parameter 1

Formular 3

Parameter 2

Parameter 3

Absenden

Parameter 4

hist. Parameter

Zeitlicher Verlauf

Abbildung 32: Verwendung von Formularfeldern vorangegangener Formulare

sind. Für den Formularentwickler führt dies jedoch zu einem zusätzlichen

Aufwand durch das Aussuchen der Informationen.

Anforderung Es ist wichtig, dass die neue Komponente zur Erstellung von

Formularen dazu in der Lage ist, den Endanwender mit allen Informationen

zu versorgen, welche zusätzlich zu den gegebenen Prozessschrittparametern

für eine erfolgreiche Bearbeitung des Formulars nötig sind. Hierbei soll ver-

hindert werden, dass das Formular aufgrund der Informationsmenge unüber-

sichtlich wird, was die Bearbeitung erschwert. Die Erstellung der Formulare

hingegen darf für den Formularentwickler durch die Auswahl historischer

Formulardaten nicht mit großem zusätzlichem Aufwand verbunden sein.

3.2.2.9 Kontrolle der Komplexität Der letzte Abschnitt hat unter an-

derem die Probleme der zunehmenden Komplexität von Formularen durch

die Einbeziehung historischer Formularinformationen aufgezeigt. Dieser Ab-

schnitt geht auf die allgemeine Komplexität von Formularen ein. Zunächt

wird die Entstehung von Komplexität untersucht. Im Anschluss werd der

mögliche Umgang mit Komplexität diskutiert.

Entstehung von Komplexität Selbst wenn ein Formular keine Daten

vorangegangener Schritte beinhaltet, kann es vorkommen, dass ein Formular

unübersichtlich wird. Dies ist dann der Fall, wenn ein Formular auf einen

Prozessschritt mit zahlreichen Parametern basiert. Falls die Felder für diese

3.2 Anforderungen

Parameter nicht zusammenhängend im Formular angeordnet werden oder

nicht angeordnet werden können, führt das zu einer nicht unwesentlichen Er-

höhung der Komplexität für den Endanwender, der das Formular bearbeiten

muss.

Eine andere mögliche Ursache für zu umfangreiche Formulare ist die Kom-

plexität der Parameter selbst. Wenn die Formulardaten auf Parametern mit

strukturierten Datentypen basieren, wie sie im entsprechenden Abschnitt

vorgestellt wurden, können diese unter Umständen nicht durch einfache gra-

fische Elemente dargestellt werden. Es müssen komplexere grafische Elemente

verwendet werden, um die Informationen aus den Parametern vollständig

darzustellen. Erweist sich die Struktur eines solchen Datentyps als äußert

umfangreich, mit einer hohen Schachtelungstiefe, wirkt sich das auch auf das

Layout des Formulars selbst aus. Es werden mehr grafisch anzeigende Ele-

mente benötigt und dem Endanwender fällt es schwerer den Überblick zu

bewahren.

Möglicher Umgang mit Komplexität Komplexität entsteht bereits zur

Entwurfszeit. Dies fängt jedoch nicht beim Erstellen des Formulars an, son-

dern bereits bei der Erstellung des Prozesses. Der einfachste Weg ein Formul-

ar überschaubar zu halten ist, Prozessschritte mit zu vielen Parametern oder

mit Parametern, welche auf sehr komplexen Datentypen basieren, auf meh-

rere Prozessschritte aufzuteilen und somit auch die Komplexität auf mehrere

Formulare aufzuteilen.

In manchen Situationen ist dies jedoch nicht möglich, beispielsweise wenn die

Parameter eines Prozessschrittes logisch eine Einheit bilden. Wenn zusam-

menhängende Daten aufgeteilt werden, geht für die einzelnen Komponenten

der logische Zusammenhang verloren. Ein alternativer Ansatz ist es, dem

Formularentwickler die Möglichkeit zu geben, Parameter für ein Formular

zusammenzufassen, um diese zu strukturieren. Somit ist es möglich, die In-

formationen für ein Formular logisch in Blöcken zu gruppieren. Diese Blöcke

können dann beispielsweise in Subformularen dargestellt werden. Diese Sub-

formulare wiederum können als separate Dokumente behandelt oder in einem

einzelnen Formular durch ausblendbare Komponenten des Formulars darge-

stellt werden. Eine Lösung, welche den Formularentwickler mit einbezieht,

führt jedoch auch hier zu einer Erhöhung des Aufwandes beim Erstellen des

Dokumentes durch den Formularentwickler.

3 Anforderungen an eine Komponente zur Formularerstellung

3.3 Zusammenfassung

Dieses Kapitel hat die wichtigsten Probleme und Fragen erläutert, die für

einen Entwurf einer Komponente zur Erstellung von Formularen eine Rolle

spielen. Zunächst wurde der Vorgang besprochen, der nötig ist, um Formul-

are zu erstellen, in den Prozess einzubinden und darzustellen. Dabei hat sich

herausgestellt, dass die neue Komponente aus einer Entwurfsumgebung und

einer Laufzeitumgebung besteht. Anschliessend sind die funktionalen und

nichtfunktionalen Anforderungen erörtert worden. Die nichtfunktionalen An-

forderungen hingegen betreffen:

•Einfache Bedienbarkeit

•Lizenz für die neue Komponente

•Integrationsfähigkeit in ein vorhandenes System

Für eine einfache Bedienbarkeit ist es beispielsweise wichtig, dass die Kompo-

nente dazu in der Lage ist, Formulare größtenteils selbstständig zu generieren,

um den Formularentwickler bei seiner Arbeit zu unterstützen. Die funktionale

Anforderungen betreffen:

•Grafische Kontexte

•Datentypen

•Grafische Elemente

•Integration von Anwendungslogik

•Lokalisierung von Formularen

•Anbindung externer Datenquellen

•Restriktionen für Formularfelder

•Wiederverwendung historischer Formularfelder

•Kontrolle der Komplexität

Die grafischen Kontexte haben dabei eine besondere Bedeutung, da diese

massive Auswirkungen auf die anderen Anforderungen haben. Jeder gra-

fische Kontext stellt nicht nur unterschiedliche grafische Elemente zur Verfü-

gung, sondern ist auch für die Anwendungslogik, sowie Restriktionen verant-

wortlich. Es ist daher äusserst wichtig die Formulare während der Entwick-

lungszeit abstrakt zu beschreiben, um die Unterschiede zwischen verschiede-

3.3 Zusammenfassung

nen grafischen Kontexten zu verbergen. Die Umsetzung dieser abstrakten

Beschreibung ist die Aufgabe der Laufzeitumgebung.

3 Anforderungen an eine Komponente zur Formularerstellung

4 Evaluierung vorhandener Systeme

Die zusammengestellten Anforderungen des letzten Kapitels sind die Voraus-

setzung für die Evaluierung vorhandener Systeme. Die Evaluierung zeigt die

Stärken und Schwächen der einzelnen bereits verfügbaren Produkte auf. Da-

bei wird auch untersucht, ob die Produkte als Modul für die neue Kompo-

nente geeignet sind.

Zunächst wird ein Überblick über Produkte gegeben, welche sich mit der Be-

nutzerinteraktion basierend auf Formularen beschäftigen und daher für eine

Evaluierung im Rahmen dieser Arbeit geeignet sind. Anschliessend werden,

aufbauend auf den bereits diskutierten Anforderungen, Kriterien für einen

Vergleich der Produkte erläutert. Im darauf folgenden Abschnitt wird das

Ergebnis dieses Vergleichs besprochen und die Vor- und Nachteile der einzel-

nen Systeme dargestellt.

4.1 Existierende Technologien und Produkte

Es gibt mehrere Produkte und Technologien, welche für eine Evaluierung im

Rahmen dieser Arbeit beachtet werden müssen. Eine wichtige Produktgruppe

stellen BPM-Systeme dar, welche bereits Formulare zur Benutzerinteraktion

integriert haben. Ein Beispiele hierfür ist Inubit [Inu09a]. Bei Inubit han-

delt es sich um eine Suite für Modellierung, Simulation und Durchführung

branchenübergreifender Geschäftsprozesse.

Zwei weitere Produkte, welche im Rahmen dieser Arbeit evaluiert werden

sind Microsoft Infopath [Mic09f] und Adobe Lifecycle Designer [Ado09b].

Dabei handelt es sich jedoch nicht um BPM-Systeme. Diese Systeme sind von

ihrer Idee her nicht dazu ausgelegt, Prozesse zu gestalten oder auszuführen,

sondern konzentrieren sich auf den Aspekt der Oberflächenerzeugung.

Adobe Lifecycle Designer ist eine Softwarekomponente aus Adobe Lifecycle

Enterprise Suite (ES) [Ado09c] und ermöglicht die Erstellung interaktiver

Formulare, welche mit den aktuellen Versionen des Adobe Reader [Ado09d]

ausgefüllt werden. Infopath ist ein Produkt von Microsoft, welches ebenfalls

der Erstellung von interaktiven Formularen dient.

Neben diesen Produkten gibt es auch Produkte, die nicht alleinstehend ar-

beiten, sondern für die Integration in andere Programme vorgesehen sind,

beispielsweise JAXFront [JAX]. Hierbei handelt es sich ebenfalls um ein Pro-

dukt zur Erstellung und Darstellung von Formularen für die Benutzerin-

4 Evaluierung vorhandener Systeme

teraktion. Das Einbeziehen der Formulare in einen Geschäftsprozess ist mit

JAXFront jedoch nicht möglich. Dafür wird allerdings eine Schnittstelle ange-

boten, welche anderen Programmen die Integration von JAXFront erlaubt.

Ein weiteres Produkt, welches sich ausschliesslich mit der Erstellung von

Formularen befasst, ist WJP Form [WJP09]. Dabei handelt es sich um einen

Editor, der eingesetzt wird, um Formulare für den Prototypen von ADEPT2

zu gestalten. Dieses Produkt ist explizit auf ADEPT2 zugeschnitten und

ist nicht für den Einsatz in aderen BPM-Systemen ausgelegt. Das Produkt

verfolgt einen sehr pragmatischen Ansatz.

Neben diesen Produkten gibt es noch einen Standard des W3C (World Wide

Web Consortium [W3C09a]), der sich ebenfalls mit Formularen beschäftigt.

Dabei handelt es sich um XForms [W3C07], eine auf XML [W3C08] basierte

Erweiterung von HTML für die Darstellung von Formularen.

Die nachfolgende Aufzählung fasst die zu evaluierenden Produkte und Tech-

nologien zusammen:

•Inubit

•Adobe Lifecycle Designer ES

•Microsoft Infopath

•JaxFront

•WJP Form

•XForms

4.2 Vergleichskriterien

Um die Stärken und Schwächen dieser Produkte ermitteln zu können, müssen

Kriterien für die Untersuchung der einzelnen Produkte festgelegt werden. Ziel

dieses Abschnittes ist es, einen Katalog von Vergleichskriterien zusammen-

zustellen, mit dessen Hilfe jedes Produkt bewertet wird. Die Basis dieses

Katalogs bilden die Anforderungen aus Kapitel 3.

Das erste Kriterium, welches bei der Evaluierung untersucht wird, ist eine

einfache Bedienbarkeit des Systems. Die Akzeptanz eines Systems hängt stark

davon ab, wie schnell Anwender in der Lage sind, produktiv mit dem System

zu arbeiten.

4.2 Vergleichskriterien

Ein weiteres Merkmal, welches bereits zu Beginn der Untersuchung eines Pro-

dukts überprüft wird, ist die Lizenz, unter der das Produkt steht. Dabei spielt

nicht die Lizenz eine Rolle, welche zum Testen verwendet wird, sondern die

Lizenz, unter welcher das Produkt produktiv eingesetzt werden kann. Hier-

bei wird auch untersucht, ob die Lizenz eine Integration in ein vorhandenes

System erlaubt. Falls dies möglich ist, wird untersucht, wie die Integration

technisch durchgeführt werden kann.

Nachdem ermittelt worden ist, ob eine technische Integration möglich ist,

muss untersucht werden, ob das Produkt auch logisch integriert werden kann.

Die Schnittstelle zwischen dem BPM-System und der neuen Komponente

stellen die typisierten Parameter dar, welche einen Datentyp besitzen. Für

die Formularerstellung muss das Produkt daher auch mit diesen Datentypen

umgehen können, um die Parameter entsprechend ihres Datentyps korrekt

darzustellen. Dies ist ein weiteres Kriterium.

Um auch Daten in das Formular zu integrieren, welche nicht im Datenfluß

eines Prozesses vorkommen, wird auch die Möglichkait von externen Daten-

quellen untersucht. Dabei wird festgestellt, ob bei der Erstellung des Formu-

lars beispielsweise Datenbankverbindungen angegeben werden können.

Anschliessend folgt die Untersuchung der verfügbaren grafischen Elemente.

Dabei wird geprüft, welche grafischen Elemente zur Verfügung stehen und

gegebenenfalls wie damit die Parameter eines Prozesses dargestellt werden.

Da Parameter auch strukturierte Daten oder Listen sein können, ist ebenfalls

wichtig, wie das Produkt Strukturen und Listen grafisch umsetzt.

Aufbauend auf der Evaluierung der grafischen Elemente der Produkte wird

anschliessend geprüft, wie sich das Verhalten dieser Elemente steuern lässt

und wie Anwendungslogik in das Formular integriert werden kann.

Um die Formulare später auch bei allen Endanwendern einsetzen zu können,

ist es wichtig, dass das Produkt die Formulare für alle grafischen Kontexte

erstellen kann, die das BPM-System unterstützt. Für dieses Kriterium wird

deshalb ermittelt, für welche grafischen Kontexte die Formulare erzeugt wer-

den können.

Ein weiterer Aspekt, der bei der Verteilung der Formulare an unterschiedliche

Mitarbeiter eine Rolle spielt, ist die Sprache der Benutzer. Dafür muss das

Formular an die bevorzugten Sprachen der einzelnen Mitarbeiter anpassbar

sein. Für diesen Vergleichspunkt wird daher gepüft, ob eine Lokalisierung des

Formulars angeboten wird und wie diese umgesetzt wird.

4 Evaluierung vorhandener Systeme

Die folgende Aufzählung fasst die Kriterien für den Vergleich nochmals

zusammen:

•Einfache Bedienbarkeit durch den Formularentwickler

•Lizenz und Integrationsfähigkeit in vorhandene BPM-Systeme

•Unterstützte Datentypen

•Anbindung externer Datenquellen

•Verfügbare grafische Elemente

•Integration von Anwendungslogik

•Unterstützte grafische Kontexte

•Möglichkeit der Lokalisierung

4.3 Vergleich

4.3.1 Inubit

Inubit ist ein eigenständiges BPM-System. Dies beinhaltet auch die Verwal-

tung sogennanter Tasks. Tasks sind Aktivitäten, welche unter anderem die

Interaktion mit dem Endanwender ermöglichen. Ein sogenannte Taskgener-

ator dient dabei der Erstellung von Formularen für diese Interaktion. Die

Ein- und Ausgabeparameter für das Formular sowie die Beschreibung des

Formulars selber werden mit Hilfe von XML- und CSV[RFC05]-Kontainern

verwaltet.

Bedienbarkeit Für die Bedienung von Inubit sind umfangreiche technische

Kenntnisse notwendig. Zum Einen sind Kenntnisse über die Konzepte des

gesamten Systems notwendig. Dies zeigt sich unter anderem beim Anlegen

neuer Formulare. Hier müssen für die Grundkonfiguration des Tasks Angaben

gemacht werden, welche sich auf andere Aspekte des Systems beziehen, wie

beispielsweise Organigramme [Inu09b]. Bei Organigrammen handelt es sich

um Diagramme, welche die Organisationsstrukturen darstellen, etwa welche

Bearbeiter welche Rollen einnehmen.

Zum Anderen basiert die Kommunikation zwischen dem BPM-System und

den Formularen auf XML-Kontainern. Dies wird vor dem Formularentwickler

jedoch nicht verborgen. Für die Gestaltung des Formulars muss der Inhalt des

4.3 Vergleich

Abbildung 33: Entwicklungsumgebung für Formulare von Inubit

Kontainers teilweise direkt bearbeitet werden. Hierzu sind weitgehende XML-

Kenntnisse notwendig. Darauf wird auch im Handbuch [Inu09b, Kap 4.1]

hingewiesen.

Aufgrund dieser Anforderungen an den Entwickler erfüllt Inubit das Kriteri-

um nach einer einfachen Bedienbarkeit nicht. Das Produkt ist von diesem

Standpunkt aus nicht dazu geeignet, Formulare innerhalb der neuen Kompo-

nente zu erstellen. Abbildung 33 zeigt die Oberfläche der Formularentwick-

lungsumgebung von Inubit auf der unter anderem rechts oben eine Bauman-

sicht für den XML-Kontainer zu sehen ist.

Lizenz und Integrationsfähigkeit Bei Inubit handelt es sich um ein

kommerzielles Produkt, welches nicht weitergegeben oder kopiert werden

darf. Dieses Produkt ist aus Modulen aufgebaut. Auch wenn es möglich ist,

nur einzelne Module zu lizenzieren, sind diese logisch in das BPM-System in-

tegriert und nur in dessen Kontext lauffähig. Eine Integration in ein anderes

BPM-System ist daher nicht möglich.

Unterstützte Datentypen Die Prozessschrittparameter werden den For-

mularen entwender in Form eines XML- oder eines CSV-Kontainers über-

4 Evaluierung vorhandener Systeme

geben. Inbuit biete hierfür auch eine Konvertierung zwischen diesen bei-

den Kontainern an. Innerhalb des XML-Kontainers beispielsweise werden die

Struktur und die Werte der Parameter beschrieben. Somit stehen den For-

mularen alle Datentypen zur Verfügung, welche sich durch XML beschreiben

lassen. Dies schliesst auch beliebig strukturierte und listenwertige Datentypen

ein.

Externe Datenquellen In Inubit gibt es sogenannte Connectors, die es er-

möglichen auf Datenbestände ausserhalb des BPM-Systems zuzugreifen und

innerhalb des Systems zu nutzen. Diese Daten können anschliessend in einem

XML- oder CSV-Kontainer in ein Formular integriert werden.

Grafische Elemente Für die Gestaltung des Formulares und die Abbil-

dung der Parameter des Formulares stehen dem Entwickler folgende grafische

Elemente zur Verfügung:

•Kontrollkästchen

•Auswahlfelder

•Beschriftungsfelder

•Felder für Passwörter

•Elemente für die Darstellung von Bildern

•Auswahllisten

•Schaltflächen

Für listenwertige Texte stehen ausserdem Listenfelder zur Verfügung. Für

strukturierte Datentypen und strukturierte listenwertige Datentypen gibt es

eine Baumansicht, welche die Struktur des Datentypes grafisch darstellt. Ein

weiteres grafisches Element erlaubt das Einbinden von Dateien.

Mit diesen grafischen Elementen hat Inubit einen ausreichenden Vorrat für

die Präsentation von Informationen. Dadurch, dass für strukturierte Daten-

typen nur eine Baumansicht verwendet werden kann, fehlt es dem Produkt

jedoch an Flexibilität, was die Darstellung strukturierter Datentypen angeht.

Anwendungslogik Inubit besitzt eine Laufzeitumgebung für JavaScript.

Diese Umgebung ermöglicht die dynamische Ausführung von JavaScript-Pro-

grammen während der Laufzeit eines Prozesses. Das Skript wird dabei direkt

4.3 Vergleich

in den XML-Kontainer des Formulars eingebettet. Bei Schaltflächen inner-

halb des Formulars, besteht die Möglichkeit den hinterlegten JavaScript-Code

bei einem Auslösen der Schaltfläche auszuführen. Auf diese Weise lässt sich

die Anwendungslogik in Form von JavaScript-Programmen in das Formular

integrieren.

Grafische Kontexte Die erzeugten Formulare lassen sich für zwei unter-

schiedliche grafische Kontexte erstellen:

•HTML-Kontext

•Swing-(Java-)Kontext

Damit lassen sich Formulare bereits in einem großen Umfeld einsetzen. Die

Gestaltung des Formulars ist jedoch nicht vollständig kontextunabhängig. In

beiden Kontexten gibt es unterschiedliche grafische Elemente. Ein weiterer

Nachteil ist, dass der Kontext, in welchem das Formular ausgeführt werden

soll, bereits zur Entwicklungszeit festgelegt werden muss.

Lokalisierung Es ist möglich, statische Texte des Formulares sprachlich an

bestimmte Benutzergruppen anzupassen. Hierfür lassen sich Texte, welche im

Formular verwendet werden, automatisch in eine Excel-Tabelle exportieren.

Diese Tabelle muss anschliessend manuell übersetzt und unter Angabe der

Sprache wieder in das Formular importiert werden.

4.3.2 Adobe Lifecycle

Bedienbarkeit Adobe Lifecycle bietet eine übersichtliche Benutzerober-

fläche, welche intuitiv zu bedienen ist. Das Erstellen von Formularen ist

durch einen sogenanten WYSIWYG (What you see is what you get)-Editor

[Wik09b] möglich (Abbildung 34). Ein Bearbeiten von XML-Kontainern, wie

bei Inubit, ist nicht erforderlich.

Lizenz und Integrationsfähigkeit Adobe Lifecycle Designer ist Bestand-

teil von Adobe Lifecycle SE. Allerdings ist Lifecycle Designer auch als allein-

stehendes Produkt verfügbar und lauffähig. Das Produkt bietet jedoch keine

Programmierschnittstellen, um es in bestehende Systeme zu integrieren.

4 Evaluierung vorhandener Systeme

Abbildung 34: Entwicklungsumgebung für Formulare von Adobe Lifecycle

Designer

Unterstützte Datentypen In Adobe Lifecycle Designer werden die Infor-

mationen nicht anhand der Datentypen unterschieden. Welchen Typ ein Da-

tum hat, hängt allein von der grafischen Elementen, welche für die Anzeige

verwendet wird, ab. Es gibt jedoch die Möglichkeit, die Benutzereingaben

durch Angabe eines Musters einzuschränken. Damit lässt sich ein Textfeld

beispielsweise dazu verwenden, um eine Adresse oder ein Autokennzeichen in

einem bestimmten Format anzugeben.

Für die Verwendung in einer neuen Komponente ist Adobe Lifecycle Designer

nicht geeignet, da es für eine Integration erforderlich ist, dass das Produkt

mit den Datentypen der Prozessschrittparameter umgehen kann.

Externe Datenquellen Um Informationen dynamisch in das Formular

zu integrieren, stehen sogenannte Datenverbindungen zur Verfügung. Diese

Datenverbindungen erlauben das Importieren von Informationen aus folgen-

den Quellen:

•Datenbanken

•XML-Dateien

•Web-Services

4.3 Vergleich

Abhängig von der gewählten Datenverbindung lassen sich noch weitere De-

tails angeben, um spezifische Datensätze aus der Datenverbindung zu erhal-

ten. Bei einer Datenbank ist beispielsweise die Angabe von Abfrage-Kom-

mandos möglich. Eine Datenverbindung kann dabei direkt auf ein grafisches

Elemente abgebildet werden, um die Informationen aus der Datenverbindung

mit diesem Element darzustellen.

Grafische Elemente Adobe Lifecycle Designer bietet eine sehr große

Auswahl an grafischen Elementen für die Verwendung in Formularen. Dies

beinhaltet unter anderem auch Elemente, welche häufig in Anwendungen zu

finden sind. Typische Vertreter sind:

•Listenfelder

•Textfelder

•Optionsfelder

•Kombinationsfelder

•Schaltflächen

•Tabellen

Es sind auch grafische Elemente vorhanden, die weniger häufig verwendet

werden. Diese sind für die Darstellung von Parametern mit speziellen Daten-

typen geeignet. Einige Beispiele dafür sind:

•Eingabefelder für E-Mail-Adressen

•Auswahlfelder für Länder

•Barcodes

•Felder für digitale Unterschriften

•geometrische Elemente wie Kreise oder Rechtecke

Ausserdem können sogenante Fragmente erstellt werden. Ein Fragment ist ein

wiederverwendbarer Ausschnitt eines Formulars. Abbildung 35 zeigt einige

der verfügbaren grafischen Elemente.

Anwendungslogik Jedes Steuerelement kann mehrere unterschiedliche

Ereignisse auslösen, zum Beispiel ein Ereignis, welches das Ändern des Inhalts

durch den Benutzer signalisiert. Für jedes Ereignis kann durch ein Skript

4 Evaluierung vorhandener Systeme

Abbildung 35: Grafische Elemente für Formulare in Adobe Lifecycle Designer

das Verhalten beim Eintreten des Ereignisses festgelegt werden. Als Skript-

sprachen stehen dabei JavaScript, sowie FormCalc [Ado09a] zur Verfügung.

FormCalc ist eine von Adobe entwickelte Skriptsprache für Formulare. Damit

bietet Adobe Lifecycle Designer ausreichende Funktionalität für den Einsatz

in einer neuen Komponente.

Grafische Kontexte Adobe Lifecycle Designer erstellt aus den Formul-

aren PDF-Dateien, welche die Formulare darstellen. In Abbildung 36 wird

ein PDF dargestellt, das aus einem Formular erstellt wurde. Ausgabefor-

mate für andere grafische Kontexte sind nicht möglich. Die Erstellung von

PDF-Dateien ist jedoch nicht ausreichend für eine Verwendung in der neuen

Komponente.

Lokalisierung Die Angabe von Texten in unterschiedlichen Sprachen ist

nicht möglich.

4.3.3 Microsoft Infopath

Bedienbarkeit Das Produkt ist intuitiv zu bedienen und bietet für An-

wender anderer Microsoftprodukte eine vertraute Umgebung. Zum Erstellen

4.3 Vergleich

Abbildung 36: Mit Adobe Lifecycle Designer generiertes PDF-Dokument

von Formularen steht hier ebenfalls ein WYSISWYG-Editor zur Verfügung.

Abbildung 37 zeigt die Entwicklungsumgebung für Formulare.

Lizenz und Integrationsfähigkeit Microsoft Infopath ist unabhängig

von anderen Produkten lauffähig, lässt sich jedoch mit anderen Produk-

ten von Microsoft kombinieren. Microsoft SharePoint [Mic09g] (Dokumenten-

managementsystem, mit Weboberfläche zum verteilten arbeiten an gemein-

sam genutzen Dokumenten) kann beispielsweise genutzt werden, um die For-

mulare öffentlich zugänglich zu machen. Für das Anlegen von zusätzlichen

Steuerelementen oder die Integration von Anwendungslogik wird eine .NET-

Entwicklungsumgebung [Mic09b] benötigt. Eine Integration von Infopath in

bereits existierende Systeme ist nicht möglich.

4 Evaluierung vorhandener Systeme

Abbildung 37: Entwicklungsumgebung für Formulare von Microsoft Infopath

Unterstützte Datentypen Microsoft Infopath unterstützt folgende Da-

tentypen:

•String

•Integer

•Double

•Boolean

•URI

•Date

•Time

•DateTime

Strukturierte oder listenwertige Datentypen werden nicht untersützt. Für

eine Verwendung in einer neuen Komponente ist das Produkt daher nur be-

dingt geeignet.

Externe Datenquellen Microsoft Infopath bietet die Möglichkeit, Infor-

mationen aus verschiedenen externen Datenquellen dynamisch in das For-

mular zu integrieren. Zur Auswahl stehen dabei folgende Quellen:

4.3 Vergleich

•Datenbankanfragen (Nur Microsoft SQL-Server [Mic09c])

•Webservices

•XML-Dateien

•Inhalte einer Microsoft SharePoint-Bibliothek

Ebenso wie bei Adobe Lifecycle Designer ist die Auswahl eines definierten

Datensatzes möglich. Es ist auch möglich, während der Laufzeit des Formu-

lars Informationen an externe Dienste zu senden.

Grafische Elemente Für die Gestaltung des Layouts stehen dem Ent-

wickler folgende grafische Elemente zur Verfügung:

•Felder für einfachen Text

•Felder für formatierten Text

•Kombinationsfelder

•Listenfelder

•Felder für Datumsauswahl

•Kontrollkästchen

•Optionsfelder

•Schaltflächen

•Kontainer für Dateien

Ausserdem können selbst erstellte grafische Elemente als Formularfelder

verwendet werden. Das Erstellen eigener grafischer Elemente ist in In-

fopath jedoch nicht möglich. Dafür wird eine separate Entwicklungsumge-

bung benötigt.

Des weiteren bietet Infopath die Möglichkeit optionale oder sich wieder-

holende grafische Elemente zu verwenden. Dadurch lassen sich auch ohne

listenwertige Datentypen Listen von beliebigen Formularfeldern realisieren,

wie zum Beispiel eine Einkaufsliste.

Anwendungslogik Um das Verhalten des Formulares zu beeinflußen, kann

jedes Formularfeld durch sogenannte Regeln auf Benutzereingaben reagieren

und dabei bestimmte Aktionen ausführen. Folgende Aktionen sind möglich:

4 Evaluierung vorhandener Systeme

Abbildung 38: Dialoge zum Erstellen von Regeln für Formularfelder in Micro-

soft Infopath

•Dialogfeldmeldungen anzeigen

•Wert eines Formularfeldes setzen

•Daten einer externen Quelle abfragen

•Daten zu einer externen Quelle senden.

•Öffnen eines weiteren Formulars

Beim Aktivieren einer Schaltfläche ist ausserdem auch die Angabe von An-

wendungslogik möglich. Hierfür wird die Skriptsprache VBA (Visual basic

for Application [Mic09e]) verwendet. Abbildung 38 zeigt einen Dialog zum

Erstellen von Regeln für ein grafisches Element.

Grafische Kontexte Das Formular wird wahlweise in einem proprietärem

Format auf dem lokalem Arbeitsplatz gespeichert oder auf einem SharePoint-

Server hinterlegt. In beiden Fällen wird für das Darstellen des Formulars ein

4.3 Vergleich

eigener Betrachter verwendet. Es ist jedoch auch möglich, das Formular in

andere Formate zu exportieren. Dafür müssen jedoch entsprechende Export-

filter nachinstalliert werden. Diese können auch selbst entwickelt werden.

Eine Verwendung der erstellten Formulare für die neue Komponente ist daher

umständlich, jedoch durchaus möglich.

Lokalisierung Das Einstellen der Sprache der Formularfelder ist zur Ent-

wurfszeit möglich. Ein Anpassen der Sprache zur Laufzeit des Formulars wird

jedoch nicht unterstützt.

4.3.4 JAXFront

JAXFront ist ein Produkt zum Generieren grafischer Oberflächen auf Basis

eines XML-Kontainers. Der Endanwender hat dabei die Möglichkeit die Da-

ten dieses Kontainers zu bearbeiten. Im Gegensatz zu den XML-Kontainern

von Inubit wird die Struktur von XML jedoch vor dem Entwickler verborgen.

Die Architektur von JAXFront sieht eine Trennung der Oberflächenbeschrei-

bung, dem Geschäftsmodell und der Instanzdaten vor. Das Geschäftsmo-

dell beschreibt den syntaktischen Aufbau der Informationen in Form eines

XML-Schemas. Die Oberflächenbeschreibung legt die grafische Repräsen-

tation dieser Informationen fest und beinhaltet Regeln für das Verhalten

der Oberfläche. Die Instanzdaten legen zum Einen die Werte fest, die beim

Starten der Oberfläche dargestellt werden und zum Anderen die Werte, die

der Benutzer eingegeben hat. Diese Daten werden in Form eine XML-Datei

gespeichert. Abbildung 39 stellt die Architektur von JAXFront dar.

Das Produkt besteht aus zwei Architekturkomponenten:

1. Dem XUI-Editor, der es dem Entwickler erlaubt ausgehend von dem

Geschäftsmodell eine grafische Oberfläche zu erstellen.

2. Einem Renderer, der aus dem Geschäftsmodell, der Ober-

flächenbeschreibung und den Instanzdaten die eigentliche Oberfläche

erstellt.

Das Erstellen einer Oberflächenbeschreibung für das Geschäftsmodell ist da-

bei optional. Der Renderer ist in der Lage, basierend auf dem Geschäfts-

modell, eine Oberfläche selbständig zu generieren. Wird in der erstellten

Oberfläche jedoch ein bestimmtes Verhalten benötigt, muss die entsprech-

ende Anwendungslogik durch den XUI-Editor manuell hinzugefügt werden.

4 Evaluierung vorhandener Systeme

Abbildung 39: Architektur von JAXFront [JAX]

Um die Oberflächenbeschreibung mit Hilfe des XUI-Editors zu erstellen oder

durch den Renderer automatisch zu generieren, muss die XML-Datei mit

Geschäftsmodell bereits vorliegen. Ein Editor um dieses zu erstellen ist nicht

vorhanden.

Bedienbarkeit Der XUI-Editor ermöglicht das Anlegen und Bearbeiten

der grafischen Elemente, welche zur Darstellung der einzelnen Elemente aus

dem XML-Schema des Geschäftsmodells dienen. Die Möglichkeiten dabei

sind sehr vielfältig. Es ist dafür eine umfangreiche Dokumentation vorhan-

den, welche alle wichtigen Aspekte beschreibt.

Mit diesem Editor können jedoch nur Angaben über die Eigenschaften der

grafischen Elemente gemacht werden. Ein einfache Gestaltung der Oberfläche

in Form eines WYSIWYG-Editors ist nicht möglich. Abbildung 40 zeigt den

XUI-Editor von JAXFront. Leider zeigte der Editor in der vorliegenden Ver-

sion ausgeprägte Schwächen hinsichtlich seiner Stabilität. Um JaxFront pro-

duktiv einsetzen zu können, müssen diese Schwächen seitens der Hersteller

behoben werden.

4.3 Vergleich

Abbildung 40: XUI-Editor von JAXFront

Lizenz und Integrationsfähigkeit Der Editor von JAXFront ist ein al-

leinstehendes Produkt und kostenlos verfügbar. Der Renderer ist in fünf ver-

schiedenen Edition verfügbar. Tabelle 1 zeigt eine Übersicht dieser Edition

und der entsprechenden Kosten für die Lizenz.

Bis auf die „Formserver Edition“ sind alle Editionen für die Integration in

bestehende Systeme ausgelegt. Der Formserver ist ein Form-Solution-Service

auf Basis von J2EE [Sun06]. Dabei handelt es sich um ein vollständiges Pro-

dukt zur Erstellung, Verwaltung und Verteilung von Formularen. Dies bein-

haltet auch einen Datenhaltungsdienst und einen einfachen Workflow-Dienst.

Die „Community Editon“ ist frei erhältlich, um das Produkt testen und

evaluieren zu können. Diese Edition darf auch in vorhandene Produkte integ-

riert werden. Jedoch wird beim Rendern der Oberflächen ein Markenzeichen

eingeblendet. Die restlichen Edition sind der „Community Edition“ ähnlich,

bieten jedoch einen höheren Funktionsumfang und beinhalten kein Marken-

zeichen auf den Oberflächen.

Für die Integration in Java-Projekte steht eine spezielle Schnittstelle bereit,

die es erlaubt den Renderer zu verwenden.

4 Evaluierung vorhandener Systeme

Edition Lizenzkosten

Free Community Edition 0,-

Standard Edition 600,-

Professional Edition 1.200,-

Enterprise Edition 5.400,-

Formserver Edition 10.800,-

Tabelle 1: Übersicht über die verfügbaren Editionen des JAXFront Renderers

und der Lizenzkosten in Euro

Unterstützte Datentypen Die Datentypen für die Informationen wer-

den im XML-Schema des Geschäftsmodells festgelegt. Dadruch können alle

Datentypen verwendet werden, welche in XML möglich sind.

Externe Datenquellen In JAXFront ist es möglich Teile der Instanzdaten

von externen Datenbanken zu beziehen. Dies setzt das Vorhandensein eines

geeigneten JDBC (Java Database Connectivity [Sun09c]) voraus. Damit ist

es möglich, bestimmte Felder aus den Tabellen der Datenbank auf die In-

stanzdaten für ein Formularabzubilden. Die Werte, die sich zur Laufzeit in

den angegebenen Feldern der Tabelle befinden, werden in das Formular inte-

griert.

Grafische Elemente JAXFront bietet für alle Datentypen aus dem

Geschäftsmodell ein oder mehrere adäquate grafische Elemente zu deren

Darstellung an. Stehen für den Datentyp eines Elementes mehrere gra-

fische Repräsentationen zur Verfügung, hat der Entwickler die Möglichkeit

ein passendes Elemente zu wählen. Elemente für das Exportieren oder Im-

portieren von Dateien gibt es nicht.

Anwendungslogik Für jedes Element können unabhängig von dem ver-

wendeten grafischen Element Regeln erstellt werden mit deren Hilfe das Ver-

halten der Oberfläche angepasst werden kann. Dabei ist es möglich, Bedin-

4.3 Vergleich

Abbildung 41: Oberfläche für Swing gerendert

gungen und Aktionen festzulegen. Bei den Aktionen stehen vordefinierte Me-

thoden bereit, welche durch den Entwickler ausgewählt werden können, bei-

spielsweise das Ändern von Eigenschaften eines Formularfeldes. Die Angabe

einer Java-Klasse mit zusätzlicher Anwendungslogik ist ebenfalls möglich.

Die Klasse muss dafür eine bestimmte Schnittstelle von JAXFront imple-

mentieren.

Grafische Kontexte Der Renderer unterstützt das Darstellen der Ober-

fläche für die folgenden Kontexte:

•PDF

•HTML

•Swing (Java)

Damit bietet JAXFront ein breites Spektrum an Einsatzmöglichkeiten.

Welche Kontexte tatsächlich genutzt werden können, hängt von der verwen-

deten Edition ab. Abbildung 41 zeigt eine Oberfläche, die für den Swing-

Kontext gerendert ist. Im Gegegnsatz zu Inubit muss zur Entwurfszeit noch

kein grafischer Kontext festgelegt werden. Diese Wahl wird zur Laufzeit durch

das integrierende System getroffen.

4 Evaluierung vorhandener Systeme

Lokalisierung Alle Texte der grafischen Oberfläche können durch einen

National Language Support (NLS) in mehreren Sprachen angegeben werden.

Zur Laufzeit kann die entsprechende Sprache durch das Host-System aus-

gewählt werden.

4.3.5 WJP Form

Abbildung 42: Editor für Formulare von WJP

Bedienbarkeit Die Bedienung von WJP Form ist intuitiv und schnell er-

lernbar. In WJP Form steht ein WYSIWYG-Editor zur Verfügung um die

Oberfläche der Formulare zu erstellen. Der Editor wird in Abbildung 42

gezeigt.

Lizenz und Integrationsfähigkeit WJP Form wurde speziell für die

Integration in die auf ADEPT2-beruhende kommerzielle „AristaFlow BPM

Suite“ [Ari09] entwickelt. Eine Integration in ein anderes System ist daher

nicht vorgesehen. Es ist zwar möglich, eine WJP Form-Lizenz zu erwerben.

Sinnvoll ist dies jedoch nur mit dem oben genannten Produkt von AristaFlow

4.3 Vergleich

Abbildung 43: WJP Editor für Container

Unterstützte Datentypen Es werden die Datentypen aus dem Metamo-

dell von ADEPT2 unterstützt.

•Boolean

•DateTime

•Float

•String

•Integer

•UDT

UDT-Datentypen (User-Defined-Datatype) sind Datentypen mit einer frei

definierbaren Struktur. Diese können mit WJP Form genauer spezifiziert

werden. Hierfür steht ein Editor zur Verfügung mit dem sogenante Kontainer

angelegt werden können. Dabei handelt es sich um hierarchische Strukturen

deren Elemente, aus den Basisdatentypen bestehen. Die Prozessschrittpara-

meter können dabei mit solchen Kontainern assoziiert werden, um auf die

Elemente der Parameter zugreifen zu können. Abbildung 43 zeigt den Editor

für die Kontainer. Listenwertige Datentypen werden vom ADEPT2-Modell

momentan nicht unterstützt und stehen daher bei WJP Form nicht zur Ver-

fügung.

Externe Datenquellen Um zusätzliche Informationen in das Formular

zu integrieren, welche nicht als Prozessschrittparameter zur Verfügung ste-

hen, können Datenbankverbindungen zu Instanzen des Microsoft-SQL Server

4 Evaluierung vorhandener Systeme

angegeben werden. Für diese Verbindungen lassen sich zusätzlich Komman-

dos erstellen, welche Anfragen an die Datenbank darstellen und zur Laufzeit

des Formulars Informationen aus der Datenbank abrufen. Abbildung 44 zeigt

eine Datenbankverbindung und ein Kommando für eine Abfrage innerhalb

dieser Datenbank.

Abbildung 44: Übersicht über externe Datenbankverbindungen in WJP Form

Grafische Elemente Für die Gestaltung des Layouts stehen folgende gra-

fischen Elemente zur Verfügung:

•Schaltflächen

•Listenfelder

•Textfelder

•Optionsfelder

•Beschriftungsfelder

•Hypertextfelder

•Elemente für den Im- und Export von Dateien

•Steuerelemente zur Darstellung von Bildern

•Kombinationsfelder

Die Prozessschrittparameter können dabei auf die im Formular verwende-

ten grafischen Elemente abgebildet werden und dienen als Eingabedaten für

diese. Bei Prozessschrittparametern, die mit einem Kontainer assoziiert sind,

4.3 Vergleich

Abbildung 45: Dialog für die Behandlung von Ereignissen eines grafischen

WJP-Elements

können die Elemente des Kontainers als Eingabedaten für ein grafisches Ele-

ment verwendet werden. Alternativ können auch externe Datenquellen als

Eingabedaten für die grafischen Elemente verwendet werden. Zur Laufzeit

des Formulars stellen die grafischen Elemente die Werte der ihr zugeordneten

Parameter oder Datenquellen dar.

Eine Erstellung von eigenen grafischen Elementen für die Wiederverwendung

in anderen Formularen ist nicht möglich.

Anwendungslogik Für die Steuerung des Verhaltens von Formularen

steht die Verwendung von JavaScript oder VB (Visual Basic [Mic09d]) zur

Verfügung. Alle grafischen Elemente können unterschiedliche Ereignisse aus-

lösen. Diese Ereignisse können entweder Behandlungsroutinen in Form von

Skripten ausführen oder ein erneutes Laden der Eingabedaten der grafischen

Elemente auslösen. Durch ein erneutes Laden der Eingabedaten werden

Werte aktualisiert, welche aus einer externen Datenquelle bezogen werden.

Abbildung 45 zeigt im Hintergrund rechts der Mitte einen Dialog der die

Verwaltung der Ereignisse von grafischen Elementen ermöglicht. Im Vorder-

4 Evaluierung vorhandener Systeme

grund links unten ist ein Editor für die Behandlungsroutine in JavaScript zu

sehen.

Für häufig verwendetes Verhalten in einem Formular können auch glo-

bale Methoden definiert werden, welche innerhalb der Behandlungsroutine

aufgerufen werden können.

Grafische Kontexte Das Formular kann zur Laufzeit nur als HTML-Do-

kument dargestellt werden. Das ist nicht ausreichend für dein Einsatz in einer

Komponente zur Formularerstellung.

Lokalisierung Eine Lokalisierung des Formulars ist nicht möglich.

4.3.6 XForms

XForms ist eine Spezifikation des W3C-Konsortiums. Es handelt sich da-

bei um einen Standard Formulardarstellung. Eine mögliche Anwendung ist

die Integration von XForms in (X)HTML-Dokumente. Ein Web-Browser der

dieses Dokument darstellen soll, muss in der Lage sein XForms zu inter-

pretieren. Quellcode 5 zeigt wie ein XForms-Dokument in ein HTML-Doku-

ment integriert wird. In Abbildung 46 ist die Darstellung dieses Dokuments

in einem XForms-fähigen Web-Browser zu sehen. Als Web-Browser wird Fire-

fox [Moz09] verwendet. Damit dieser jedoch das Formular darstellen kann,

ist ein zusätzliches Plugin [Ree08] nötig.

1<html xmlns=" http :// www.w3. org /1999/ xhtml "

2xmlns:xf =" http :// www .w3. org /2002/ xforms " >

3<head >

4<title>2.1. a Introductory Example No. 1</title>

5<link rel ="stylesheet" href=" ../ driverPages / forms

/ TestSuite11 . css" type =" text/ css " />

6<xf: model >

7<xf: instance >

8<ecommerce xmlns="">

9<method >cc </ method>

10 <number />

11 <expiry />

12 </ecommerce>

13 </ xf: instance >

4.3 Vergleich

14 <xf:submission id=" submit " method =" post "

action =" http :// xformstest . org/cgi - bin/ echo

.sh" />

15 </xf: model >

16 </ head >

17 <body >

18 <xf: group >

19 <xf: label class=" title ">2.1. a Introductory

Example No. 1</xf:label>

20 </xf: group >

21 <xf: select1 ref =" method " xmlns="">

22 <xf: label>Select Payment Method :</xf: label>

23 <xf: item >

24 <xf: label>Cash </xf: label>

25 <xf: value>cash </xf: value>

26 </xf: item >

27 <xf: item >

28 <xf: label>Credit </xf: label>

29 <xf: value>cc</xf: value>

30 </xf: item >

31 </ xf: select1 >

32 <xf: input ref =" number " xmlns="">

33 <xf: label>Credit Card Number : </xf: label>

34 </xf: input>

35 <xf: input ref =" expiry " xmlns="">

36 <xf: label>Expiration Date :</xf: label>

37 </xf: input>

38 <xf: submit submission =" submit ">

39 <xf: label>Submit Now </xf: label>

40 </ xf : submit >

41 </ body >

42 </ html >

Quellcode 5: XForms-Dokuments, eingebettet in einem HTML-Dokument

[W3C09b](vereinfacht)

Bedienbarkeit Da es sich bei XForms um eine Spezifikation handelt, kann

über die Bedienung keine Aussage gemacht werden. Die Bedienung ist ab-

hängig von der verwendeten Implementierung.

4 Evaluierung vorhandener Systeme

Abbildung 46: Darstellung eines XForms-Dokuments in einem XForms-

fähigem Web-Browser [W3C09b](vereinfacht)

Lizenz und Integrationsfähigkeit Die W3C-Spezfikation von XForms

ist frei zugänglich und kann daher in jedem beliebigen System implementiert

werden.

Unterstützte Datentypen Die XForms-Spezifikation bietet ein große

Auswahl an Datyentypen, wie zum Beispiel:

•String

•Integer

•Byte

•Date

•Time

•AnyURI

•Email

•Base64

Häufig werden Datentypen noch weiter unterteilt. Den Integer-Datentyp gibt

es beispielsweise mit und ohne Vorzeichen sowie in verschiedenen Größen.

Ausserdem gibt es einen Datentyp der Listen beliebiger anderer Datentypen

repräsentiert. Durch die Verwendung von XML lassen sich aus diesen Daten-

typen auch komplexe Strukturen zusammenstellen.

Externe Datenquellen Die Spezifikation von XForms sieht keine An-

bindung von Daten aus externen Datenquellen vor.

Grafische Elemente Folgende grafischen Elemente stehen zur Verfügung

4.3 Vergleich

•Textfelder

•Auswahlfelder

•Optionsfelder

•Kontrollkästchen

•Menüs

•Dateiauswahl

•Passwortfelder

•Schaltflächen

•Bildfelder

•Gruppierungsfelder

•Schieberegler

Durch die hierarchische Struktur von XML können hier, ähnlich wie bei den

Datentypen, beliebige Strukturen von grafischen Elementen erstellt werden.

Anwendungslogik Der XForms-Standard stellt für alle grafischen Ele-

mente Ereignisse bereit. Diese Ereignisse können entweder eine JavaScript-

Methode aufrufen, welche beispielsweise durch den Browser ausgeführt wird,

oder eine URL aufrufen. Bei dieser URL kann es sich beispielsweise um ein

Skript handeln, welches auf Seiten des Servers ausgeführt wird. Die Antwort

des Servers kann dazu verwendet werden, um Teile des Dokumentes neu

aufzubauen. Innerhalb von XForms ist es möglich festzulegen, welche Teile

des XForms-Dokumentes durch die Antwort neu aufbgebaut werden soll.

Durch diese Techniken ist es, ähnlich wie mit Ajax [Wen06], möglich die

Anwendungslogik auf den Client und einen Server aufzuteilen. Damit ist

beispielsweise die Gestaltung eines Formulars denkbar, welches Details und

Abbildungen zu Produkten eines Onlineshops anzeigt. Bei einer Vielzahl an

Produkten ist es nicht sinnvoll ein Formular zu generieren, welches bereits

alle Details und Abbildungen zu allen Produkten enthält. Das Dokumen-

te wäre unter Umständenen mehrere hundert Megabyte groß. Sinnvoller ist,

es in einem Bereich des Formulars nur eine Liste der verfügbaren Produkte

anzuzeigen und in einem anderen Bereich die Details und Abbildungen eines

Produktes dynamisch nachzuladen.

4 Evaluierung vorhandener Systeme

Grafische Kontexte Die XForms-Spezifikation macht keine Angaben

zu untersetützten grafischen Kontexten. In welchem grafischen Kontext

ein XForms-Dokument dargestellt werden kann, hängt von der Imple-

mentierung des XForms-Interpreter ab. Ein Web-Browser, der das XForms-

Format versteht, ermöglicht beispielsweise einen HTML-Kontext. Eine Im-

plementierung, welche aus einem XForms-Dokument ein reines HTML-Do-

kument erzeugen kann, stellt ebenfalls eine Lösung für einen HTML-Kontext

dar. Eine sind aber auch Implementierungen denkbar, welche aus einem

XForms-Dokument ein SWT-Composite erstellt. Dadurch kann das XForms-

Dokument in einem SWT-Kontext dargestellt werden. Es ist dabei die Auf-

gabe der Implementierung die grafischen Elemente und das Verhalten der

Dokuments korrekt abzubilden.

Lokalisierung Der aktuelle XForms-Standard enthält momentan noch kei-

ne Möglichkeiten, Texte in einem XForms-Dokument an die Sprachen der Be-

nutzer anzupassen. In einer eigenen Implementierung kann diese Möglichkeit

jedoch integriert werden.

4.4 Fazit

Die Evaluierung hat gezeigt, dass es bereits verschiedene Ansätze für die

Erstellung und Integration von Formularen in anderen Systemen gibt. Jedoch

war keines der untersuchten Produkte in der Lage, alle Evaulierungskriterien

zu erfüllen.

Inubit ist für die Verwendung in einer Komponente zur Generierung von

Formularen ungeeignet, da die Entwicklungsumgebung ein fester Bestandteil

des BPM-Systems von Inubit ist. Dieses System ist nicht auf Erstellung von

allgemein verwendbaren Formularen ausgelegt.

Adobe Lifecycle Designer und Microsoft Infopath sind sehr ähnliche Produk-

te. Sie bieten eine komfortable Entwicklungsumgebung für die Gestaltung

von Formularen. Ihr größter Nachteil ist jedoch, dass die erzeugten Formul-

are kontextbezogen sind.

JAXFront wurde entwickelt um Benutzeroberflächen für Anwendungen zu

generieren und darzustellen. Die Integration in ein bestehendes System wird

dabei durch entsprechende Programmierschnittstellen ermöglicht. Aufgrund

der hohen Lizenzkosten und der fehleranfälligen Entwicklungsumgebung wird

JAXFront im Rahmen dieser Arbeit jedoch nicht verwendet.

4.4 Fazit

WJP Form wird derzeit zum Erstellen von Formularen für die „AristaFlow

BPM Suite“ verwendet. Allerdings fehlen diesem Produkt wichtige Funk-

tionsmerkmale wie zum Beispiel Lokalisierbarkeit der Formularoberflächen.

Zudem können WJP-Formulare derzeit nur für den HTML-Kontext übersetzt

werden.

XForms stellt einen guten Ansatz dar, da es ein frei verfügbarer Standard ist,

der einen großzügigen Funktionsumfang für die Beschreibung von Formularen

bereitstellt. Diese Technologie ist jedoch noch nicht ausreichend verbreitet.

Dies liegt unter anderem auch daran, dass es bisher kaum Implementierung-

en gibt. Für die Verwendung in einer Komponente eines BPM-System ist

XForms daher noch nicht geeignet.

Tabelle 2 zeigt die Ergebnisse der Evaluierung im Überblick.

4 Evaluierung vorhandener Systeme

Kriterium

Inubit

Adobe Lifecycle

MS Infopath

JAXFront

WJP Form

XForms

Bedienbarkeit - + + 0 + 0

Lizenz und

Integrations-

fähigkeit

- - - 0 0 +

Unterstützte

Datentypen

+ - 0 + 0 +

Externe

Datenquellen

+ + + + + -

Grafische

Elemente

0 + 0 0 0 +

Anwendungs-

logik

+ + + + + +

Grafische

Kontexte

0 - 0 + - 0

Lokalisierung 0 - 0 + - 0

Gesamt + 0 ++ +++++ ++++

Tabelle 2: Zusammenfassung der Evaluierungsergebnisse

5 Entwurf einer Komponente zur

Formularerstellung

Kapitel 4 hat gezeigt, dass es auf dem Markt Produkte gibt, welche einzelne

Probleme bei der Formularerstellung lösen. Jedoch kann keines der getesteten

Produkte die Anforderungen vollständig erfüllen.

In dieses Kapitel wird der Entwurf für eine Komponente zur Formularer-

stellung vorgestellt. Dafür wird zunächst die Architektur dieser Komponente

und ihre Einordnung in das BPM-System grob erläutert. Anschließend wird

der generelle Ablauf der Formularerstellung und -darstellung besprochen. Im

Anschluss daran werden Konzepte diskutiert, welche die Anforderungen aus

Kapitel 3 erfüllen. Diese Konzepte werden zu einem Entwurf zusammenge-

fasst, der die Grundlage für eine prototypische Implementierung darstellt.

Die Konzepte sind weitestgehend unabhängig von einem BPM-System. Um

eine Integration in ADEPT2 zu ermöglichen, müssen jedoch einige Details

bereits beim Entwurf an ADEPT2 angepasst werden. In diesen Fällen wird

explizit darauf hingewiesen.

5.1 Architektur

5.1.1 Aufbau

Kapitel 3 zeigte, dass für die neue Komponente eine Entwicklungsumge-

bung und eine Ausführungsumgebung benötigt wird. Dies bildet den Aus-

gangspunkt für den Entwurf. Für einen vollständigen Entwurf wird jedoch

noch ein Datenmodell für die Beschreibung von Formularen und ein Modul

für den Transport des Modells zwischen den beiden Umgebungen benötigt.

Abbildung 47 beschreibt den Aufbau der neuen Komponente und deren

Einordnung in das vorhandene BPM-System.

Um die Funktionsweise der Entwicklungs- und Ausführungsumgebung nach-

vollziehen zu können, wird zunächst das Datenmodell erläutert. Dieses

Datenmodell ermöglicht die Beschreibung von Formularmodellen. Ein For-

mularmodell enthält die Informationen des abstrakten Formulars und die

Werte für die Ein- und Ausgabeparameter. Das abstrakte Formular beinhal-

tet dabei drei Aspekte:

•Das Aussehen: Das Aussehen wird durch grafische Elemente wie Text-

felder, Listen und Schaltflächen definiert.

5 Entwurf einer Komponente zur Formularerstellung

Entwicklungsumgebung des

BPM-Systems

Prozesseditor Entwicklungsumgebung

für Formulare

Assistent

Formular-

editor

Datenmodell

Schnittstelle für XML Import/Export

Persistente Datenhaltung des BPM-Systems

Ausführungsumgebung des

BPM-Systems

Prozessaus-

führung

Ausführungsumgebung

für Formulare

Modul zur Ver-

vollständigung

von Formular-

modellen

Modul zur

Übersetzung

von Formular-

modellen

Architekturkomponenten des vorhandenen BPM-Systems

Subkomponenten und Module der neuen Komponente

Kontrollinformationen

Datentransport

Abbildung 47: Architektur der neuen Komponente und Eingliederung in das

BPM-System

5.1 Architektur

•Das Verhalten: Das Verhalten wird durch die Anwendungslogik fest-

gelegt, welche durch JavaScript-Programme beschrieben ist.

•Die Abbildung von Prozessschrittparametern auf die grafischen Ele-

mente des Formulars.

Die Entwicklungsumgebung ist für die Erstellung dieses Formularmodells zu-

ständig. Dafür benötigt die Entwicklungsumgebung zwei Module. Das erste

Module ist ein Assistent, der Teile des Formularmodells unter Berücksichti-

gung der Prozessschrittparameter automatisch generiert. Das zweite Modul

ist ein Editor, mit dem das Aussehen des Formularmodells verfeinert und

angepasst wird. Die Entwicklungsumgebung wird in die bereits vorhandene

Entwicklungsumgebung für Prozesse aus dem BPM-System integriert.

Die Ausführungsumgebung übersetzt das Formularmodell in ein konkretes

Formular. Für diesen Vorgang werden zwei Module benötigt. Ein Modul ver-

sorgt das Formularmodell zunächst mit den Werten der Prozessschrittpara-

meter. Das zweite Modul führt die eigentliche Übersetzung des Formular-

modells durch. Dabei ensteht ein konkretes, kontextabhängiges Dokument.

Dieses Dokument wird der Ausführungsumgebung des BPM-Systems über-

geben, welche dem Endanwender das Dokument dastellt. Die Ausführungs-

umgebung wird in die bereits existierende Ausführungsumgebung des BPM-

Systems integriert. Für die Integration der prototypischen Implementiertung

in das ADEPT2-System wird die aus Kapitel 2 vorgestellte Anwendungsin-

tegration angewendet.

Die Erstellung eines Formularmodells und dessen Übersetzung zu einem kon-

kreten Formular sind zeitlich und räumlich voneinander getrennt. Für den

Transport des Formularmodells muss dieses persistent gespeichert werden.

Diese Aufgabe übernimmt das BPM-System. Um das Modell dem BPM-

System zu übergeben, ist eine weitere Subkomponente notwendig, da das

BPM-System mit einem Formularmodell nicht umgehen kann. Diese Sub-

komponente erstellt einen Kontainer, in welchem das Modell gekapselt wird.

Dafür wird ein XML-basiertes Format verwendet. Dieses lässt sich einfach

serialisieren und dem System so übergeben. Um das Datenmodell wieder zu

deserialisieren, wird der Kontainer aus dem BPM-System geholt und die In-

formationen rekonstruiert.

5.1.2 Ablauf

5.1.2.1 Erstellung des Formularmodells Um mit der Erstellung des

Formularmodells zu beginnen, wird die Entwicklungsumgebung für Formul-

5 Entwurf einer Komponente zur Formularerstellung

Prozesseditor Assistent

Prozessmodellierer/

Formularentwckler

Entwicklungsumgebung des BPM-System

Entwicklungsumgebung

für Formulare

Der Prozessmodellierer beginnt mit der

Gestaltung eines Geschäftsprozesses und

startet den Prozesseditor

Für einen Prozessschritt wird eine Aktivität

mit Benutzerinteraktion gewählt. Für die

Gestaltung eines entsprechenden

Formulars wird die Entwicklungsumgebung

für Formulare gestartet

Zuerst erstellt der Assistent Teile des

Formularmodells automatisch

Anschliessend kann das Formularmodell

angepasst werden

Nachdem das Formularmodell fertig

erstellt ist, wird es serialisiert und an das

BPM-System übergeben

Die Entwicklungsumgebung für Formulare

wird beendet. Es können nun weitere

Formulare gestaltet werden oder die

Modellierung des Prozesses fortgesetzt

werden.

persistente

DatenhaltungFormulareditor

Abbildung 48: Erstellung eines Formularmodells

are von dem Prozesseditor gestartet. Dabei werden auch alle Ein- und Aus-

gabeparameter der Aktivität übergeben, für die ein Formular erstellt werden

soll. Die Entwicklungsumgebung für Formulare startet den Assistenten, wel-

cher mit Hilfe der verfügbaren grafischen Elemente, Formularfelder generiert.

Diese Formularfelder dienen der Darstellung der Eingabeparameter.

Nachdem der Assistent diese Aufgabe erledigt hat, hat der Formularentwick-

ler die Möglichkeit, das Layout des Formulars nachträglich anzupassen oder

zusätzliche Anwendungslogik in das Formular einzubinden. Nach dem Ab-

schluss der Arbeiten wird das erstellte Formularmodell in das XML-Format

serialisiert und dem BPM-System übergeben. Die Werte für die Parame-

ter sind zu diesem Zeitpunkt noch nicht im Formularmodell enthalten. An-

schließend wird die Kontrolle wieder an den Prozesseditor zurückgegeben.

Diese Vorgehen ist in Abbildung 48 dargestellt.

5.1.2.2 Ausführung des Formulars Um aus dem Formularmodell ein

konkretes Formular zu erzeugen, welches durch einen Endanwender bear-

beitet werden kann, sind mehrere Schritte notwendig. Diese Schritte sind in

Abbildung 49 dargestellt.

5.1 Architektur

Prozessausführung Modul zur Modell-

vervollständigung

Modul zur Modell-

übersetzung Transportschnitt-

stelle des Kontextes Endanwender

Ausführungsumgebung des BPM-System

Ausführungsumgebung für

Formulare

Prozess mit Formularaktivität ist erreicht.

Aufruf der Formularausführungsumgebung und

Übergabe der Werte für die Eingabearameter und

der Informationen über den grafischen Kontext

Vervollständigung des Formularmodells mit

Parameterwerten

Übersetzung in kontextabhängiges Dokument

Übergabe des Dokuments an das BPM-System

Bearbeitung des Dokuments durch den Benutzer

Rückgabe der Benutzereingaben

Auswerten der Benutzereingaben

Rückgabe der Werte für Ausgabeparameter

an das BPM-System

Abbildung 49: Ablauf einer Formularausführung

Der erste Schritt ist das Starten der Ausführungsumgebung für Formulare.

Dies geschieht während der Ausführung eines Prozesses durch das BPM-

System, sobald ein Prozessschritt mit einer Formularaktivität erreicht wird.

Dabei werden auch die Werte für die Prozessschrittparameter und die Infor-

mationen über den grafischen Kontext übergeben.

Die Ausführungsumgebung kann nun den XML-Kontainer mit dem erstel-

lten Formularmodell deserialisieren. Diesem Modell werden anschließend die

Werte der Eingabeparameter hinzugefügt. Danach wird das Modell dem

Übersetzer geben, welcher das nun vollständige Formularmodell mit Hilfe

der Kontextinformationen in ein entsprechendes Dokument erstellt. Hier-

bei handelt es sich beispielsweise um ein HTML-Dokument für einen Web-

Browser. Dieses Dokument wird dem BPM-System übergeben, welches dafür

verantwortlich ist, das Formular dem Anwender bereitzustellen und diesem

die Bearbeitung zu ermöglichen.

Während der Anwender das Formular bearbeitet, hat dieser die Möglichkeit,

Eingabeparameter zu betrachten und Werte für Ausgabeparameter anzuge-

5 Entwurf einer Komponente zur Formularerstellung

ben. Die Eingabeparameter sind dabei an Formularfelder gebunden, die nicht

verändert werden können. Die Ausgabeparameter sind ebenfalls an Formular-

felder gebunden, welche zu Beginn jedoch noch keine Werte enthalten. Diese

müssen erst durch den Endanwender eingegeben werden.

Sobald die Bearbeitung durch den Endanwender abgeschlossen ist, stellt das

BPM-System der Formularausführungsumgebung die Eingaben des Endan-

wenders zur Verfügung. Diese Eingaben sind dabei ebenfalls in einem kon-

textabhängigem Format. In einem HTML-Kontext werden diese durch eine

GET- bzw POST-Anfrage des HTML-Dokuments zur Verfügung gestellt. In

einem SWT-Kontext können die EIngaben des Benutzer durch sogenannte

Getter-Methoden abgerufen werden.

Das Übersetzungsmodul wertet die Eingaben des Endanwenders aus, um

die Werte für die Ausgabeparameter des Prozessschrittes zu erhalten. Diese

Werte werden zum Schluss an das BPM-System zurückgegeben. Der Prozess-

schritt ist damit vollständig abgearbeitet und die Ausführung des Prozesses

wird fortgesetzt.

5.2 Entwurf des Datenmodells

Das Datenmodell beinhaltet mehrere Konzepte, die für die Gestaltung und

Übersetzung von Formularmodellen benötigt werden:

•Datentypen: Bilden die Grundlage für alle weiteren Konzepte.

•Werte: Repräsentieren Informationen und haben einen Datentyp.

•Formularfelder: Dienen der Darstellung von Werten in Formularen.

•Formularmodelle: Beschreiben das Verhalten und das Aussehen von

Formularen.

Diese Konzepte werden in den folgenden Abschnitten eingehend erklärt.

5.2.1 Datentypen

Um die Daten, welche vom Endanwender abgefragt oder diesem präsen-

tiert werden, als Informationen interpretieren zu können, werden Datentypen

benötigt. Das ADEPT2-Modell bietet bereits eigene Datentypen an, jedoch

fehlen bei diesen Datentypen wichtige Konzepte wie listenwertige oder struk-

turierte Datentypen. Daher muss für die neue Komponente ein eigenes Modell

5.2 Entwurf des Datenmodells

für Datentypen erstellt werden. Neben den Grunddatentypen wie String,

Boolean,Integer,Float und Date sollen dabei noch Datentypen für

Aufzählungen (Enum), Datentypen für beliebige binäre Daten (Blob) sowie

Datentypen für die genannten listenwertigen und strukturierten Datentypen

zur Verfügung gestellt werden.

Strukturierte Datentypen bestehen aus Elementen, welche einen Namen

und einen Datentyp haben. Der Name eines Elements muss dabei inner-

halb des strukturierten Datentyps eindeutig sein. Der Datentyp eines Ele-

ments kann beliebig gewählt weren. Dies bedeutet, dass auch andere struk-

turierte Datentypen als Datentypen für die Elemente verwendet werden dür-

fen. Eine wichtige Bedingung ist dabei jedoch, dass hierbei keine zyklischen

Abhängigkeiten zwischen strukturierten Datentypen entstehen.

Listenwertige Datentypen sind Datentypen mit beliebig vielen Elementen,

welche alle den selben Datentyp besitzen. Dieser gemeinsame Datentyp ist

der Basistyp der Liste. Der Basistyp kann dabei jeder beliebige Datentyp

sein. Auch bereits vorhandene Listen sind möglich. Anders als bei struktu-

rierten Datentypen haben die Elemente einer Liste keine Namen, sondern

werden über ihren Index referenziert. Die Anzahl der Elemente einer Liste

ist dynamisch, das bedeutet, dass zur Laufzeit Elemente hinzugefügt oder

entfernt werden können.

Um diese neuen Datentypen in die neue Komponente zu integrieren, muss

eine Abbildung der neuen Datentypen auf die Datentypen des ADEPT2-

Metamodell vorgenommen werden. Dies ist wichtig, da die Parameter für

das Formular mit ADEPT2-Datentypen versehen sind. Die Abbildung muss

daher bijektiv sein, da zum Einen Werte mit ADEPT2-Datentypen aus dem

BPM-System kommen (Eingabeparameter) und zum Anderen Werte mit den

neuen Datentypen an das BPM-System übergeben werden (Ausgabeparame-

ter).

Die fünf Grunddatentypen (String,Boolean,Integer,Float und

Date) sind im ADEPT2-Metamodell bereits vorhanden. Daher können diese

direkt abgebildet werden. Die restlichen Datentypen werden als UDT abge-

bildet. UDTs haben einen eindeutigen Namen, der dazu genutzt wird,

den korrespondierenden Datentyp der neuen Komponente zu identifizieren.

Tabelle 3 zeigt die Beziehung zwischen den Datentypen von ADEPT2 und

denen der neuen Komponente.

5 Entwurf einer Komponente zur Formularerstellung

Formulardatentyp ADEPT2-Datentyp Beispiel

String String “Herr Müller“

“Textnachricht“

Boolean Boolean true

false

Integer Integer 4711

12358132134

Float Float 3,14159265

1.41421356

Date Date 01/01/1970 00:00:00

01/04/2009 12:30:00

Blob Udt Inhalt einer Datei

Aufzählung UDT Nord, Ost, Süd, West : Süd

Gelb, Grün, Rot, Blau : Rot

Liste Udt String[ ]: {“Hund“, “Katze“}

Float[ ]: {1.2, 9.6, 5.0}

Struktur Udt Adresse:

•Straße : String

•Postleitzahl : Integer

•Ort : String

•Land : Aufzählung

Tabelle 3: Zuordnung der neuen Datentypen auf ADEPT2 Datentypen

5.2 Entwurf des Datenmodells

5.2.2 Werte

Um innerhalb des Datenmodells Werte mit einem bestimmten Datentyp

verwenden zu können, wird eine Repräsentation für Werte benötigt. Diese

Werte können beispielsweise dazu verwendet werden, um die Benutzerein-

gaben von Formularfeldern zu speichern. Eine Repräsentation von Werten

wird ausserdem benötigt, um die Werte der Eingabeparameter von Prozess-

schritten im Formularmodell speichern zu können. Ein weitere Einsatzzweck

für eine Repräsentation von Werten ist die Möglichkeit, Standardwerten für

Formularfelder bereits zur Entwicklungszeit anzugeben. Diese Standardwerte

müssen ebenfalls im Modell hinterlegt werden.

Werte haben immer einen festen Datentyp, der nicht geändert werden kann.

Ein Wert für einen Prozessschrittparameter kann beispielsweise nur von

einem Formularfeld dargestellt werden, welches für diesen Datentyp ausgelegt

ist. Eine Besonderheit der Werte ist, dass jeder Wert auch null sein kann.

Diese Forderung kommt aus dem ADEPT2-Metamodell, welches null für

Werte generell zulässt. Ein Prozessschrittparameter der null ist muss da-

her auch innerhalb der Ausführungsumgebung für Formulare null sein. Wie

null-Werte durch Formularfelder dargestellt werden, muss für jedes Formul-

arfeld separat entschieden werden.

Um den Umgang mit Werten in der Entwicklungsumgebung zu erleichtern,

ist es möglich, bei Werten mit einem strukturierten Datentyp direkt auf

die Werte des Elemtes zuzugreifen. Hierfür wird die Punktnotation verein-

bart, welche bereits in den meisten Programmiersprachen verwendet wird,

um auf die Elemente strukturierter Objekte zuzugreifen. Der Ausdruck

wert.nachname steht beispielsweise für das Element nachname des Wertes.

Analog wird für den Zugriff auf die Elemente einer Liste die Notation eines

Indexoperators([]) vereinbart. Der Index des gewünschten Elementes steht

hierbei innerhalb den Klammern. Das erste Elemente erhält dabei den In-

dex 0. Der Ausdruck wert[4] steht beispielsweise für den Wert des fünften

Elementes der Liste.

5.2.3 Formularfelder

Mit den vorgestellten Datentypen ist es möglich, die Daten der Prozess-

schrittparameter zu interpretieren. Diese Parameter müssen grafisch im For-

mular dargestellt werden. Dafür werden Composite verwendet. Um Verwechs-

lungen zu vermeiden, werden die Composite, welche bei SWT verwendet wer-

5 Entwurf einer Komponente zur Formularerstellung

Abbildung 50: Beispiele für Composite

den, im folgenden als SWT-Composite bezeichnet. Composite sind Formul-

arfelder, welche aus grafischen Elementen aufgebaut sind, wie beispielsweise

Textfelder, Auswahlfelder oder Listen. Jedes Composite ist für Werte eines

bestimmten Datentyps spezialisiert. Um zum Beispiel einen Wert des Typs

String darzustellen wird ein Composite benötigt, welches ein Textfeld bein-

haltet. In Abbildung 50 werden vier unterschiedliche Composite gezeigt. In

Abbildung 51 ist ein Formular zu sehen, welches aus mehreren Composite

besteht.

Für die primitiven Datentypen enthält die Entwicklungsumgebnug bereits

passende Composite. Für Aufzählungsdatentypen ist ebenfalls ein Composite

enthalten, dass jedoch nicht für eine Aufzählung spezialisiert ist, sondern mit

allen Aufzählungen umgehen kann, da alle Aufzählungen die selbe Struktur

haben. Für listenwertige Datentypen kann ein entsprechendes Composite au-

tomatisch generiert werden, solange bereits ein Composite für den Basistyp

der Liste existiert. Für Listen von primitiven Datentypen und Aufzählungen

ist dies daher der Fall.

Strukturierte Datentypen haben jeweils einen unterschiedlichen Aufbau. Da-

her müssen für solche Datentypen neue Composite erstellt werden. Um ein

neues Composite für einen speziellen Datentyp zu definieren, werden Compo-

site Definition verwendet. Bei einer Composite Definition handelt es sich um

eine abstrakte Beschreibung des Aufbaus und des Verhaltens eines Compo-

5.2 Entwurf des Datenmodells

Abbildung 51: Formular bestehend aus mehreren Composite

site. Eine neue Composite Definition kann dabei aus bereits existierenden

Composite aufgebaut werden, um mit Hilfe dieser Composite die Elemente

eines strukturierten Datentyps darstellen zu können.

Um ein Composite zu erhalten, welches auf der neuen Composite Definiti-

on basiert, wird die Composite Definition instanziert. Das dadurch erzeugte

Composite kann in einem Formular verwendet werden, um damit einen Wert

des entsprechenden Datentyps darzustellen. Eine Composite Definition ver-

hält sich zu einem Composite (Instanz einer Composite Definition) dabei

ähnlich wie eine Klasse zu einem Objekt.

Composite und Composite Definition sind grundlegend für die Erstellung

von Formularen. Daher werden diese in den folgenden Abschnitten weiter

detailiert und voneinander abgegrenzt.

5.2.3.1 Composite Definition Eine Composite Definition beinhaltet

mehrere Aspekte, welche ein Composite beschreiben. Der erste Aspekt ist das

Layout (Layout), welches den Aufbau der Instanzen beschreibt. Des Weit-

eren gibt es Eigenschaften (Attributes), die für das Aussehen und teilweise für

das Verhalten des Composite verantwortlich sind. Ein weiterer Aspekt sind

Ereignisse (Events), welche durch Aktionen des Endanwenders ausgelöst wer-

den. Die Eingabe von Text in ein Textfeld stellt beispielsweise ein Ereignis

5 Entwurf einer Komponente zur Formularerstellung

dar. Der letzte Aspekt, der eng mit den Ereignissen verwandt ist, ist die

Anwendungslogik (Logic), welche das Verhalten des Composite zur Laufzeit

steuert.

Layout Jede Composite Definition, welche für die Darstellung eines struk-

turierten Datentyps zuständig ist, ist aus bereits existierenden Composite

aufgebaut. Diese Composite müssen optisch angeordnet werden. Dafür ist

das Layout verantwortlich. Das Layout legt die Positionierung der Compo-

site innerhalb der neuen Composite Definition fest. Jedes Composite, die aus

dieser Composite Definition abgelietet wird, hat daher den selben Aufbau.

Ein Ändern dieses Aufbaus zur Laufzeit ist nicht möglich.

Eigenschaften Composite besitzen Eigenschaften, welche das Verhalten

und das Aussehen von Formularfeldern steuern zu können, beispielsweise um

die Hintergrundfarbe festzulegen, oder einzustellen, ob Werte bearbeitet oder

nur dargestellt werden können. Jede Eigenschaft besitzt einen Namen, einen

Wert und einen Datentyp. Die Eigenschaft mit dem Namen editierbar könnte

beispielsweise einen booleschen Datentyp haben. Damit sind die Werte true

und false möglich. Diese Eigenschaft legt fest, ob der Inhalt eines Composite

nur angezeigt werden kann, oder ob ein Bearbeiten des Inhaltes durch den

Endanwender möglich ist.

Der Name muss innerhalb der Eigenschaften einer Composite Definition ein-

deutig sein, da die Eigenschaft über den Namen identifiziert wird. Der Da-

tentyp ist wichtig, um bei der Instanzierung der Composite Definition nur

Werte für die Eigenschaften zuzulassen, welche für diese Eigenschaft seman-

tisch sinnvoll sind. Für eine Eigenschaft maximaleTextLänge, welche zum

Beispiel die Länge der Eingabe in einem Textfeld beschränkt, ist der Wert

“Automobil“ nicht sinnvoll.

Es müssen nicht alle Composite dieselben Werte für die Eigenschaften be-

sitzen. Welche Eigenschaften ein Composite hat, wird in der entsprechenden

Composite Definition bestimmt. Welche Werte diese Eigenschaften haben,

wird dagegen erst bei der Erstellung eines entsprechenden Composite fest-

gelegt. Dadurch haben alle Composite, welche auf derselben Composite De-

finition basieren, dieselben Eigenschaften. Die Werte können sich jedoch un-

terscheiden, was zu einem unterschiedlichen Verhalten und Aussehen der

Composite zur Laufzeit führt. Um eine größtmögliche Flexibilität zu er-

reichen, lassen sich die Werte dieser Eigenschaften zur Laufzeit mit Hil-

fe von Anwendungslogik ändern. Ein Composite, welches nur das Anzeigen

5.2 Entwurf des Datenmodells

eines Wertes erlaubt, kann auf diese Weise zur Laufzeit so geändert werden,

dass auch ein Bearbeiten des Wertes möglich ist. Damit ist es beispielsweise

möglich, die Hintergrundfarbe von Textfeldern zur Laufzeit zu ändern, etwa

um den Endanwender auf fehlerhafte Eingaben hinzuweisen.

Eigenschaft Datentyp Erläuterung

hintergrundfarbe Integer Beschreibt die Farbe, welche im

Composite hinterlegt ist.

vordergrundfarbe Integer Beschreibt die Farbe der Schrift oder des

Rahmens eines Composite.

editierbar Boolean Legt fest, ob der Inhalt des Composite

durch den Endanwender verändert werden

kann.

tooltip String Zeichenfolge welche eingeblendet wird,

wenn die Maus über das Composite be-

wegt wird.

maximaleLänge Integer Legt die maximale Eingabelänge bei

einem Textfeld fest

inhalt abhängig von

Composite

Definition

Besondere Eigenschaft, die den Wert ent-

hält, der durch das Composite angezeigt

werden soll. Der Datentyp ist abhängig

davon, für welchen Datentyp die Compo-

site Definition erstellt wurde, beispiels-

weise String bei einem Composite zur

Darstellung von Texten.

Tabelle 4: Mögliche Eigenschaften für Composite und deren möglichen Da-

tentypen

Tabelle 4 zeigt eine beispielhafte Übersicht möglicher Eigenschaften einer

Composite Definition. Eine besondere Eigenschaft einer Composites Defini-

tion ist inhalt. Der Wert dieser Eigenschaft stellt den Wert dar, den das

Composite darstellen soll. Diese Eigenschaft gibt es daher in jeder Compo-

site Definition. Der Datentyp dieser Eigenschaft unterscheidet sich jedoch

5 Entwurf einer Komponente zur Formularerstellung

in jeder Composite Definition und ist davon abhängig, welche Werte das

Composite darstellen soll. Bei einem Textfeld hat diese Eigenschaft zum Bei-

spiel den Datentyp String. Bei einem Kontrollkästchen wiederum hat die

Eigenschaft den Datentyp Boolean.

Anwendungslogik und Ereignisse Eine weitere Möglichkeit, das Verhal-

ten eines Composite zu steuern, stellt die Verwendung von Anwendungslogik

dar. Jeder Composite Definition kann hierfür Anwendungslogik in Form von

JavaScript hinzugefügt werden. Für jede Composite Definition lassen sich

dabei Methoden mit einer Liste von sequentiell auszuführenden Befehlen

anlegen. Hierbei gibt es beispielsweise Befehle um die Eigenschaften von

Composite auszulesen oder zu verändern. Damit lassen sich, etwa in einem

Onlinehsop, Preise aus unterschiedlichen Felder auslesen, addieren und in

einem anderen Felder wieder anzeigen.

Um zur Laufzeit Methoden aus der Anwendungslogik auszuführen, wer-

den Ereignisse verwendet. Ereignisse werden durch die Composite ausgelöst.

Composite Definition, welche Composite verwenden, können deren Ereignis-

se abfangen, um darauf zu reagieren. Welche Ereignisse ausgelöst werden

können, wird dabei in der Composite Definition festgelegt, auf denen ver-

wendeten Composite basieren. Tabelle 5 zeigt Beispiele für solche Ereignisse.

Die Instanzen einer neun Composite Definition sind selbst wieder Composite

sind, welche ebenfalls Ereignisse verursachen können. Um diese Ereignisse

auszulösen, können in der Anwendungslogik der entsprechenden Composite

Definition spezielle Befehle verwendet werden.

5.2.3.2 Composite Ein Composite ist eine Instanz einer Composite De-

finition dar. Bei Instanzierung müssen die abstrakten Informationen der

Composite Definition mit konkreten Werten belegt werden. Hierzu gehören

Angaben über die Positionierung, die Eigenschaften und das Verhalten beim

Eintreten von Ereignissen. Ausserdem hat ein Composite einen Namen, der

die Instanz identifiziert. Über diesen Namen kann in der Anwendungslogik auf

das Composite zugegriffen werden, um beispielsweise dessen Eigenschaften zu

ändern.

Es gibt zwei Formen der Instanzierungen einer Composite Definition. Zum

Einen werden Composite Definition innerhalb anderer Composite Definition

instanziert. Die daraus resultierenden Composite werden im Layout der um-

schliessenden Composite Definition genutzt. Zum Anderen können Composite

Definition innerhalb eines Formulares instanziert werden. Diese Composite

100

5.2 Entwurf des Datenmodells

Ereignis Erläuterung

inhaltGeändert Tritt ein, sobald der Wert, den das Composite darstellt,

durch den Anwender geändert wurde.

erhalteFokus Tritt ein, sobald der Anwender das Composite aus-

gewählt hat.

verliereFokus Tritt ein, sobald der Anwender ein anderes Composite

ausgewählt hat.

aktiviert Tritt ein, sobald der Anwender die Schaltfläche eines

entsprechenden Composite betätigt hat.

Tabelle 5: Mögliche Ereignisse von Composite

werden für das Layout des Formulares verwendet, um die Parameter des

Prozessschrittes in dem Formular darzustellen. Diese beiden Formen der In-

stanzierung sind sehr ähnlich. Allerdings gibt es einige Unterschiede in den

Details bei der Belegung von Eigenschaften mit Werten.

Belegung von Eigenschaften Für die Belegung der Eigenschaften mit

Werten, können bereits zur Entwicklungszeit konkrete Werte angegeben wer-

den. Ein Beispiel verdeutlicht das:

Ein Formularentwickler entwirft eine Composite Definition mit mehreren

Textfeldern. Die Composite Definition der Textfelder legt fest, dass die Text-

felder die Eigenschaft hintergrundfarbe haben. Der Formularentwickler hat

nun die Möglichkeit festzulegen, welche Hintergrundfarben die einzelnen

Textfelder zur Laufzeit haben sollen. Dafür ordnet der Formularentwickler

der Eigenschaft hintergrundfarbe jedes Textfelds einen entsprechenden Wert

zu.

Alternativ dazu kann der Wert für eine Eigenschaft an einen Parameter des

Formulars gebunden werden, der den selben Datentyp hat, wie die Eigen-

schaft. In diesem Fall wird zur Laufzeit der Wert des Parameters als Wert für

die Eigenschaft eingesetzt. Dieser Wert ist zur Entwicklungszeit noch nicht

bekannt. Zur Laufzeit wird der Wert des Parameters bei der Übersetzung

des Formularmodells eingebunden. Handelt es sich bei diesem Parameter um

101

5 Entwurf einer Komponente zur Formularerstellung

einen Ausgabeparameter, ist dafür kein Wert verfügbar. In diesem Fall ist

der Wert für die Eigenschaft zu Beginn null. Während der Endanwender

das Formular bearbeitet, kann sich der Wert der Eigenschaft ändern. Dies ist

beispielsweise durch Anwendungslogik oder bei der Eigenschaft inhalt durch

den Endanwender selbst möglich. Nachdem der Endanwender das Formular

bearbeitet hat, wird der letzte Wert der Eigenschaft ermittelt und an das

BPM-System als Wert für den Ausgabeparameter übergeben. Diese Bindung

an einen Parameter ist nur bei einer Instanzierung innerhalb eines Formulars

möglich.

Bei der Instanzierung innerhalb eines anderen Composite Definition ist dies

nicht möglich. Jedoch können hier die Eigenschaften der verwendeten Compo-

site an die Eigenschaften der umschliessenden Composite Definition gebun-

den werden. Der Wert für die Eigenschaft einer Instanz der Composite De-

finition wird dabei ebenfalls zur Laufzeit ermittelt. Auf diese Weise können

Eigenschaften in der hierarchischen Composite-Struktur durchgereicht wer-

den.

Im oben erläuterten Beispiel hat der Formularentwickler die Möglichkeit der

neuen Composite Definition eine Eigenschaft mit dem Namen hintergrund

zu geben. Der Name könnte auch hintergrundfarbe lauten, aber zur besseren

Unterscheidung wurde ein anderer Name gewählt als hintergrundfarbe. Die

Eigenschaft hintergrundfarbe von einem oder mehreren Textfelder können

nun an die Eigenschaft hintergrund der Composite Definition gebunden wer-

den, um eine einheitliche Hintergrundfarbe zu erhalten. Auch hier ist zu

beachten, dass die Eigenschaften der Composite nur an Eigenschaften der

Composite Definition gebunden werden können, wenn diese den selben Da-

tentyp haben.

Es gibt noch eine weitere Möglichkeit, die Eigenschaften bei einer Instan-

zierung innerhalb einer Composite Definition zu belegen. Besitzt die um-

schliessende Composite Definition Eigenschaften mit einem strukturierten

Datentyp, können auch die Elemente des Wertes dieser Eigenschaft an die

Eigenschaften der verwendeten Composite gebunden werden. Ein weiteres

Beispiel soll dies verdeutlichen: Eine neue Composite Definition soll für die

Darstellung von Werten des Datentyps Adresse entwickelt werden. Dies

bedeutet, dass die Eigenschaft inhalt der neuen Composite Definition den

Datentyp Adresse hat. Der Aufbau dieses Datentyps ist in Tabelle 6 dar-

gestellt. Für die Darstellung der einzelnen Elemente einer Adresse verwen-

det die Composite Definition unter anderem mehrere Composite mit Text-

feldern. Diese Composite besitzen ebenfalls die Eigenschaft inhalt. Da die

Elemente von Adresse jeweils den Datentyp String (bzw. Integer für

102

5.2 Entwurf des Datenmodells

Element Datentyp

straße String

hausNr String

plz Integer

stadt String

land String

Tabelle 6: Elemente einer Adresse

die Postleitzahl) haben, erhält diese Eigenschaft bei den verwendeten Compo-

site auch den Datentyp String (bzw. Integer für das Composite, welches

die Postleitzahl darstellen soll). Diese Eigenschaft kann nun bei den ver-

wendeten Composite an die jeweiligen Elemente der Eigenschaft inhalt der

umschliessenden Composite Definition gebunden werden (Abbildung 52).

Lokalisierbarkeit und Barrierefreiheit Eine Besonderheit bei der Bele-

gung der Eigenschaften ist, dass für jede Eigenschaft mehrere Werte ange-

geben werden. Dies kann wird genutzt, um Formulare zu lokalisieren und

barrierefrei zu gestalten.

Um die Composite an unterschiedliche Sprachen anpassen zu können, müssen

alle Texte, welche später in diesem Composite zu sehen sind, in allen zu

unterstützenden Sprachen angegeben werden. Da alle Texte in Form von

Eigenschaften hinterlegt werden, ist es bei der Belegung von Eigenschaften

möglich, für jede Sprache eine andere Belegung zu wählen. Dies ist jedoch

optional, da bei manchen Eigenschaften die Belegung unabhängig von der

Sprache ist, beispielsweise eine Eigenschaft, welche die maximal Textlänge

in einem Textfeld darstellt. Später zur Laufzeit wird vom BPM-System die

Sprache für das Formular ermittelt und die entsprechende Belegung für die

Eigenschaft ausgewählt.

Um die Endanwendern, welche auf Barrierefreiheit angwiesen sind, zu unter-

stützen ist es auch möglich, den Eigenschaften Werte für eine entsprechende

Benachteiligung zuzuweisen. Zum Beispiel kann einer Eigenschaft, welche die

103

5 Entwurf einer Komponente zur Formularerstellung

Eigenschaften:

- inhalt : Adresse

.straße

.hausNr

.plz

.stadt

.land

- hintergrundfarbe : Farbe

- vordergrundfarbe : Farbe

...

Composite Definition

Name: AdressFeld Layout:

Straße

HausNr.

PLZ

Stadt

Land

Belegung der Eigenschaften

Eigenschaften:

- inhalt: inhalt.land

- maximaleTextLänge: 20

- hintergrundfarbe : 0x000000

- vordergrundfarbe : 0xFFFFFF

...

Composite

Name: landText Composite Definition: TextFeld

Belegung der Eigenschaften

Eigenschaften:

- inhalt: inhalt.plz

- maximaleTextLänge: 5

- hintergrundfarbe : 0x000000

- vordergrundfarbe : 0xFFFFFF

...

Composite

Name: plzText Composite Definition: ZahlenfeldFeld

Composites:

Das Layout der Composite

Definition besteht aus 10

Composites:

- Fünf Beschriftungsfelder

- Vier Textfelder

- Ein Zahlenfeld

Der dieses

Composite ist an die

Komponente

des der

umschliessenden

Composite Definition

gebunden

inhalt

.plz

inhaltes

Name der Instanz Name der der

zugehörigen Composite

Definition

Abbildung 52: Composite Definition mit Eigenschaften, einem Layout und

Composite

104

5.2 Entwurf des Datenmodells

Hintergrundfarbe eines Composite im Falle einer Fehleingabe darstellt, bei

Endanwendern mit einer Rot/Grün-Sehschwäche eine andere Farbe als Rot

gewählt werden.

Reagieren auf Ereignisse Eine weitere abstrakte Information der

Composite Definition sind die Ereignisse. In einer Comopsite Definition wird

festgelegt, welche Ereignisse die Composite später auslösen können. Bei der

Instanzierung muss angegeben werden, wie auf diese Ereignisse reagiert wer-

den soll. Hierfür können die definierten Ereignisse an die Methoden der An-

wendungslogik gebunden werden, welche in der umschliessenden Composite

Definition definiert sind. Die Ausführungsumgebung sorgt später dafür, dass

bei dem Eintreten eines Ereignisses bei einem Composite die zur Entwick-

lungszeit gebundene Methode aufgerufen wird.

5.2.4 Formularmodell

Das eigentliche Modell für ein Formular ist sehr einfach aufgebaut. Es be-

sitzt wie eine Composite Definition, ein Layout, welches festlegt aus welchen

Composite das Formular aufgebaut ist und wie diese Composite positioniert

werden. Bei der Belegung der Eigenschaften dieser Composite gibt es mehrere

Möglichkeit. Beispielsweise können diese mit den Parametern des Formulars

verknüpft werden. Damit kann ein Eingabeparameter mit der Eigenschaft

inhalt mit einem Composite verknüpft werden, um zu erreichen, dass dieses

Composite den Parameter grafisch darstellt. Eine weitere Möglichkeit be-

steht darin, mit den Parametern das Aussehen des Formulars zu beeinflußen.

Es ist möglich, einen Eingabeparameter den Datentyp Farbe zu geben und

diesen mit der Eigenschaft Hintergrundfarbe eines (oder mehrerer) Compo-

site zu verknüpfen. Zur Laufzeit des Formulars wird der Wert des Parameters

dann dazu genutzt um die Hintergrundfarbe des (oder mehrerer) Composite

festzulegen.

Neben den Ein- und Ausgabeparametern der Aktivitäten kann das Formul-

ar darüber hinaus noch weiter parametrisiert werden. Es können zusätzliche

virtuelle Parameter für externe Datenanbindungen angelegt werden. Diese

Parameter tauchen nicht im Datenfluß des Prozesses auf, sondern existieren

nur im Kontext des Formulars. Durch diese Parameter können dem Formular

zusätzlich Informationen zur Verfügung gestellt werden. Die Verwendung der

virtuellen Parameter unterscheidet sich nicht von den normalen Parametert.

Sie besitzen ebenfalls einen Datentyp und können daher auch an die Eigen-

schaften von Formularfeldern mit dem selben Datentyp gebunden werden.

105

5 Entwurf einer Komponente zur Formularerstellung

Als Quelle für die externe Daten können Verbindungen zu Datenbanken

und ein Abfragekommando für diese Datenabank angegeben werden. Diese

Abfragekommando muss durch einen korrekten Standard-SQL-Befehl [Unt03]

beschrieben werden. Der Aufbau dieses Befehls lässt bereits zur Entwick-

lungszeit Rückschlüsse über die zu erwartende Ergebnissmenge des Befehls

zu. Eine Ergebnissmenge ist eine Tabelle, welche aus einer oder mehreren

Spalten, sowie beliebig vielen Zeilen bestehen kann. Die Anzahl der Zeilen

ist abhängig vonm Inhalt der Felder in der Datenbank. Welche Spalten in der

Ergebnissmenge vorkommen ist abhängig vom verwendeten Abfragekomman-

do. Dadurch wird der Datentyp für den virtuellen Parameter festgelegt. Wird

ein Befehl verwendet, der ein einspaltiges Ergebnis liefert, wird ein primitiv-

er Datentyp verwendet. Da der Befehl keine Aussagen über den Datentyp

macht, der für diese Spalte in der Datenbank verwendet wird, muss der For-

mularentwickler den entsprechenden primitiven Datentyp selbst auswählen.

Bei einem Befehl, der mehrere Spalten zurückgibt, wird ein strukturierter

Datentyp für den virtuellen Parameter verwendet. Der Formularentwickler

muss hierbei wieder die passenden primitiven Datentypen für die einzelnen

Spalten angeben. Diese Datentypen werden für die Elemente des strukturi-

eten Datentyps verwendet. Da zur Entwurszeit auch keine Aussage über die

Anzahl der Ergebnisse des Abfragekommandos gemacht werden kann, ist

es dem Formularentwickler ausserdem überlassen, ob der Datentyp für den

virtuellen Parameter eine Liste des primitiven oder strukturierten Datentyps

sein soll oder nicht. Wird keine Liste gewählt, wird bei einer Rückgabe mit

mehreren Ergebnissen nur das erste Ergebnis verwendet. Bei einer Rückgabe

mit ohne ein Ergebniss wird null für den Wert verwendet.

Eine weitere Möglichkeit von virtuellen Parametern ist die Einbeziehung von

historischen Formulardaten. Dadurch können vom Formularentwickler die

Ausgabeparameter von Aktivitäten mit Formularen gewählt werden, welche

ebenfalls im aktuellen Formualr dargestellt werden sollen. Es können dabei

nur Aktivitäten von Formularen gewählt werden, welche im Kontrollflußes

vor dem aktuellen Formular liegen.

Des Weiteren enthält das Formularmodell ebenfalls einen Bereich für die

Anwendungslogik. In diesem Bereich können, wie bei der Composite Defini-

tion Methoden definiert werden, welche mit den Ereignissen der Composite

verknüpft und so zur Laufzeit beim Eintreten eines Ereignisses ausgeführt

werden. Bei der Anwendungslogik für Formulare gibt es einige spezielle Be-

fehle, die es erlauben, das Bearbeiten des Formulars zu beenden. Das fertige

Formular kann hierbei abgesendet, abgebrochen oder unterbrochen werden.

106

5.3 Entwurf der Entwicklungsumgebung

Datenmodell

Formularmodell

Datentypen

Adresse

Straße : STRING

Hausnummer : INTEGER

Postleitzahl : INTEGER

Stadt : STRING

Land : STRING

Composite

Name: AdressFeld Layout:

Eigenschaften:

- inhalt

- hintergrundfarbe

- vordergrundfarbe

Ereignisse:

- inhalt geändert:

- verliereFokus

- erhalteFokus

Straße

HausNr.

Plz

Stadt

Composite Definition

Werte

14367

"Herr Müller"

3,14159265

true

Abbildung 53: Übersicht über das Datenmodell

Dieses Datenmodell beinhaltet alle Aspekte die nötig sind um Formulare zu

beschreiben. Abbildung 53 zeigt alle Elemente des Datenmodell im Überblick.

5.3 Entwurf der Entwicklungsumgebung

Der Formularentwickler hat die Aufgabe, mit der Entwicklungsumgebung das

Formularmodell zu erstellen. Diese Umgebung bietet hierfür alle Werkzeuge

für die verschiedenen Aspekte des Datenmodells eines Formulars.

107

5 Entwurf einer Komponente zur Formularerstellung

Abbildung 54: Editor für strukturierte Datentypen (links) und Aufzählungen

(rechts)

5.3.1 Editoren für Datentypen

Um strukturierte Datentypen oder Aufzählungen in Formularen verwenden

zu können, müssen diese zunächt angelegt werden. Hierfür bietet die Entwick-

lungsumgebung eine Übersicht über vorhandene Datentypen (Abbildung 55),

sowie zwei Editoren für Datentypen (Abbildung 54).

Die Editoren ermöglichen das Erstellen von Aufzählungen und strukturierten

Datentypen. Für listenwertige Datentypen gibt es keinen eigenen Editor, da

Listen ausgehend von ihrem Basistyp automatisch generiert werden können.

Dazu wird bei der Verwendung einer Liste nur der Basistyp für die Liste

angegeben. Der Datentyp, welcher die Liste repräsentiert, wird implizit an-

gelegt.

Für die Erstellung von strukturierten Datentypen stehen sämtliche pri-

mitiven Datentypen, Aufzählungen und bereits existierende strukturierte

Datentypen zur Verfügung. Auch Listen dieser Datentypen sind erlaubt.

Zirkuläre Abhängigkeiten zwischen strukturierten Datentypen sind jedoch

nicht erlaubt. Auch beim Bearbeiten eines strukturierten Datentyps zu einem

späteren Zeitpunkt ist dies nicht zulässig.

Für das Erstellen von Aufzählungen können beliebige Namen für die Opti-

onen vergeben werden. Die Namen müssen sich voneinander unterscheiden.

Die Reihenfolge der Optionen kann festgelegt werden. Für jede Option lassen

sich zusätzlich weitere Namen für unterschiedliche Sprachen angeben. Der

richtige Name für eine Option wird zur Laufzeit ausgewählt.

108

5.3 Entwurf der Entwicklungsumgebung

Abbildung 55: Baumansicht der vorhandenen Datentypen

Die Datentypübersicht aus Abbildung 55 zeigt alle verfügbaren Datentypen.

Dies beinhaltet auch alle bereits angelegten strukturierten Datentypen und

Aufzählungen. Alle listenwertigen Datentypen, welche als Elemente eines

strukturierten Datentyps verwendet werden, sind ebenfalls zu sehen.

5.3.2 Editor für Werte

Diese Datentypen können beispielsweise verwendet werden, um sie den Eigen-

schaften von Composite zuzuweisen. Da diese Eigenschaften bereits zur Ent-

wicklungszeit mit einem Standardwert versehen werden können, ist ein wei-

terer Editor nötig, der das Anlegen und Bearbeiten von Werten für beliebige

Datentypen ermöglicht.

Aufgrund der Komplexität von strukturierten Datentypen ist ein einfacher

Editor mit einer Textzeile nicht ausreichend, um einen Wert zu definieren. Der

109

5 Entwurf einer Komponente zur Formularerstellung

Editor untersucht daher den Datentyp, für den ein Wert angegeben werden

soll.

Wenn es sich um einen einfachen Datentypen oder eine Aufzählung handelt,

wird der Formularentwickler aufgefordert einen entsprechenden Wert anzuge-

ben oder eine Option auszuwählen. Bei einem strukturierten Datentyp wird

der Formularentwickler nacheinander für jedes Element aufgefordert einen

Wert anzugeben. Hierfür wird auch der Datentyp des Elements untersucht.

Handelt es sich ebenfalls um einen strukturierten Datentyp, wird die Struktur

solange rekursiv untersucht, bis ein Element mit einem nichtstrukturierten

Datentyp erreicht wird. Bei einer Liste muss der Formularentwickler zunächst

entscheiden, wieviele Elemente die Liste enthalten soll und kann dann für je-

des Elemente einen Wert vom Basistyp der Liste angeben.

5.3.3 Editor für Anwendungslogik

Um die Anwendungslogik für Composite Definition und ein Formularmo-

dell zu erstellen, steht ein Texteditor zur Verfügung, welcher das Anlegen

von JavaScript-Methoden erlaubt. Innerhalb dieser Methoden kann die Logik

implementiert werden. Abhängig davon, ob es sich um Anwendungslogik für

Formulare oder Composite handelt stehen teilweise unterschiedliche Befehle

zur Verfügung. Bei Anwendungslogik für Formulare stehen die Befehle für

das Beenden der Formularbearbeitung bereit. Bei Composite gibt es Be-

fehle, welche die Ereignisse des Composite auslösen. Ausserdem ist in beiden

Fällen der Zugriff auf die verwendeten Composite durch dessen Instanznamen

möglich.

Um den Formularentwickler bei der Erstellung der Anwendungslogik zu un-

terstützen, werden die Eingaben des Formularentwicklers permanent auf syn-

taktische und semantische Korrektheit geprüft. Die semantische Korrektheit

bezieht sich dabei auf den Zugriff auf die Eigenschaften von Composite. Da

diesen Eigenschaften Datentypen zugewiesen sind, darf innerhalb der An-

wendungslogik keiner Eigenschaft ein Wert mit einem anderen Datentyp

zugewiesen werden. Die semantische Analyse informiert den Formularent-

wickler, wenn die Logik fehlerhafte Zuweisungen enthält.

Die syntaktische Analyse der Anwendungslogik stellt sicher, dass die eingege-

benen Befehle den syntaktischen Spezifikationen von JavaScript entspricht.

Dies ist wichtig, um zur Laufzeit eine fehlerfreie Ausführung der Anwen-

dungslogik zu gewährleisten.

110

5.3 Entwurf der Entwicklungsumgebung

Abbildung 56: JSEclipse: Editor für JavaScript-Code [Aja09]

Um die Arbeit mit dem Editor weiter zu vereinfachen, bietet der Editor

eine Funktion für dir automatische Vervollständigung von Eingaben an. Da-

bei werden Präfixe von möglichen Befehlen, Schlüsselwörtern oder Variblen

erkannt und auf Basis dieses Präfixes eine Liste möglicher Eingaben ange-

boten. Abbildung 56 zeigt JSEclipse [Aja09], das in der Lage ist, die Eingaben

des Entwicklers zu vervollständigen.

5.3.4 Editor für Composite Definition und Formularmodelle

Nachdem die Datentypen angelegt wurden, kann der Formularentwickler mit

Hilfe eines weiteren Editors die Composite Definition erstellen, welche für

Darstellung von Werten mit den neuen Datentypen geeignet sind.

Dabei wird zunächst entschieden, welche Datentypen das neue Composite

darstellen soll. Anschließend werden die Eigenschaften für die Composite De-

finition festgelegt und mit Datentypen versehen. Ausserdem werden Ereig-

nisse festgelegt, welche zur Laufzeit durch die Instanzen der neuen Composite

Definition ausgelöst werden können.

111

5 Entwurf einer Komponente zur Formularerstellung

Anschließend wird das Layout der Composite Definition festgelegt. Hier

steht dem Formularentwickler eine Oberfläche zur Verfügung, die es erlaubt

Composite zu platzieren.

Die Positionierung der Composite wird durch Angabe der X- und Y-Ko-

ordinaten der Composite relativ zur umschliessenden Composite Definition

oder zum umschliessenden Formular festgelegt. Diese ist aufgrund der Unter-

schiede bei der Positonierung grafischer Elemente in den verschiedenen gra-

fischen Kontexten notwendig. Der HTML-Kontext stellt durch CSS [W3C98]

eine sehr elegante Möglichkeit der Positionierung für grafische Elemente dar,

da der Formularentwickler hierbei keine Angaben zur exakten Positionierung

machen muss. Dies wird durch den darstellenden Web-Browser übernommen.

Für den SWT-Kontext kann diese jedoch nicht adäquat umgesetzt werden.

Dafür bietet SWT das Konzept der Layouts, womit der Formularentwickler

ebenfalls keine konkreten Angaben zur Positionierung machen muss. Dieses

Konzept wiederum lässt sich nicht problemlos im HTML-Kontext umsetzen.

Daher muss für die Erstellung eines Formularmodells eine Möglichkeit ange-

boten werden, welche in beiden Kontexten umsetzbar ist. Die Festlegung der

Position durch Angabe von Koordinaten ist sowohl im HTML-Kontext als

auch im SWT-Kontext möglich.

Wie auch bei den Datentypen stehen hier zunächst nur einige Composite

für die Darstellung primitiver Datentypen zur Verfügung, wie beispielswei-

se ein Textfeld für die Darstellung von String-Werten. Ausserdem ste-

hen Schaltlächen zur Verfügung, die genutzt werden können, um mit deren

Ereignissen Methoden der Anwendungslogik auszuführen. Auch bei der Er-

stellung von Composite Definition darf es keine zirkulären Abhängigkeiten

geben.

Mit Hilfe des Werteeditors können anschließend die Werte für die Eigen-

schaften, der im Layout verwendeten Composite, festgelgt werden. Alterna-

tiv können diese Werte auch von den Eigenschaften der neuen Composite

Definition durchgereicht werden. Wenn eine Eigenschaft der neuen Compo-

site Definition einen strukturierten Datentyp hat, ist es auch möglich, ein

Element dieser Eigenschaft durchzureichen und mit einer Eigenschaft eines

verwendeten Composite zu verknüpfen.

Des weiteren wird mit Hilfe des Logikeditors die Anwendungslogik für die

neue Composite Definition erstellt. Die Methoden dieser Logik können dann

mit den Ereignissen der verwendeten Composite verknüpft werden.

Für das Anlegen eines Formularmodells gibt es einen Editor, welcher dem

Editor für Composite Definition ähnlich ist. Es ist möglich über eine Ober-

112

5.3 Entwurf der Entwicklungsumgebung

fläche das Layout aus den vorhandenen Composite Definition zu gestalten

und deren Eigenschaften mit Werten oder Formularparameter zu verknüfen.

Anwendungslogik kann ebenfalls angegeben und mit den Ereignissen der im

Layout vorkommenden Composite verbunden werden.

5.3.5 Assistent

Viele Arbeitsschritte beim Erstellen von Formularen und Composite Defi-

nition sind automatisierbar. Um den Formularentwickler zu entlasten und

ihm die Arbeit zu erleichtern, steht in der Entwicklungsumgebung ein As-

sistent zur Verfügung, welcher einen Teil der Arbeit automatisch durchführt

oder durch gezielte Rückfragen an den Formularentwickler sogar vollständig

abschliesst.

Bei der Erstellung von Formularen untersucht der Assistent die Parameter

des Formulars und deren Datentypen. Anschließend sucht er nach Compo-

site Definition, welche für die Darstellung von Werten dieser Datentypen

geeignet sind. Diese werden anschließend durch den Assistent in dem For-

mular platziert. Werden mehrere brauchbare Composite Definition gefunden,

wird der Formularentwickler aufgefordert, das für diesen Fall zu verwendende

Composite auszuwählen. Für den Fall, dass keine passende Composite Defini-

tion zur Verfügung steht, bietet der Assistent dem Formularentwickler meh-

rere Möglichkeiten an. Der automatische Erstellvorgang kann abgebrochen

werden. Der Assistent kann für den Datentyp automatisch eine neue Compo-

site Definition erstellen und verwenden. Oder der Assistent untersucht die

einzelnen Elemente des Datentypes und sucht nach passenden Composite De-

finition, für die Datentypen der Elemente, um diese einzeln in das Formular

einzufügen.

Beim Erstellen von Composite Definition wird ähnlich vorgegangen. Der As-

sistent untersucht zunächst die Elemente des Datentyps, für den das neue

Composite die Darstellung übernehmen soll, und generiert dann das Layout

mit Hilfe von passenden vorhandenen Composite Definition. Anschließend

werden automatisch die Elemente des Datentypes der neuen Composite De-

finition mit den Inhalten der entsprechend erzeugten Composite verknüpft.

Sollten die verwendeten Composite und die neue Composite Definition Eigen-

schaften mit gemeinsamen Namen und Datentyp haben, schlägt der Assis-

tent vor, diese zu verbinden. Damit wird erreicht, dass universelle Eigen-

schaften zur Laufzeit automatisch einen sinnvollen Wert erhalten. Beispiels-

weise können viele Composite Definition die Eigenschaft hintergrundfarbe

haben. Wenn eine neue Composite Definition ebenfalls eine solche Eigen-

113

5 Entwurf einer Komponente zur Formularerstellung

schaft enthält ist es sinnvoll, den Wert dieser Eigenschaft weiterzuleiten.

Sollte ein anderes Verhalten erwünscht sein, kann dies manuell geändert wer-

den.

5.4 Entwurf der Laufzeitumgebung

Während der Ausführung eines Prozesses wird die Ausführungsumgebung für

die Formulare aufgerufen, sobald ein Prozessschritt mit einem hinterlegten

Formular erreicht wird. Die Ausführungsumgebung für die Formulare hat die

Aufgabe, das Formular für den Endanwender vorzubereiten und dem BPM-

System zu übergeben. Dies geschieht in zwei Schritten: Zunächst wird das

bereits erstellte Formularmodell mit den Werten für die Prozessschrittpara-

meter versorgt und angepasst. Anschließend wird aus dem Formularmodell

ein kontextabhängiges Formular erstellt. Zur Verdeutlichung wird dieser Vor-

gang anhand des HTML- und des SWT-Kontextes besprochen.

5.4.1 Modellanpassung

Bei der Anpassung müssen zwei Aspekte des Modells berücksichtigt werden,

welche zur Entwurfszeit nicht bekannt sind. Hierbei handelt es sich um die

Werte der Formularparameter und die Lokalisierung des Formulars.

Bisher enthält das Formularmodell nur eine abstrakte Beschreibung über das

Aussehen, das Verhalten und Angaben darüber, welche Prozessschrittpara-

meter von welchen Composite dargestellt werden. Welche Werte diese Pro-

zessschrittparameter haben, war bisher nicht bekannt. Diese Werte müssen

dem Formularmodell hinzugefügt werden, bevor dieses übersetzt werden

kann. Hierfür muss die Ausführungsumgebung die Werte zunächst aus dem

BPM-System abfragen und anschließend den entsprechenden Prozessschritt-

parameter aus dem Modell zuweisen.

Neben den Prozessschrittparameter verwendet das Formularmodell auch

virtuelle Parameter, deren Werte ebenfalls erst jetzt ermittelt werden können.

Für virtuelle Parameter, welche historische Formulardaten darstellen, wer-

den die entsprechenden Werte ebenfalls aus dem BPM-System abgefragt. Bei

virtuellen Parametern mit einer externen Datenanbindung wird die Daten-

bankverbindung aufgebaut und das Abfragekommando versendet. Aus der

erhaltenen Antwort wird ein Wert mit dem angegebenen Datentyp erstellt

und dem Formularmodell hinzugefügt.

114

5.4 Entwurf der Laufzeitumgebung

Um das Formular zu lokalisieren, muss ebenfalls das BPM-System befragt

werden, um beispielsweise Informationen über die benötigte Sprache zu erhal-

ten. Diese Informationen werden dem Modell hinzugefügt. Eine Auswertung

dieser Information findet erst bei der Übersetzung des Modells statt.

5.4.2 Modellübersetzung

Bei der Modellübersetzung muss zwischen den Kontexten unterschieden wer-

den, für die das Modell übersetzt werden soll. Welche Kontexte angeboten

werden können. hängt vom BPM-System ab. Für jeden Kontext, welches vom

BPM-System angeboten wird und von der neuen Komponente auch unter-

stützt werden soll, wird ein eigener Übersetzer benötigt. Daher ist es für den

Entwurf der neuen Komponente wichtig, zu entscheiden, welche grafischen

Kontexte unterstützt werden sollen.

Um bereits von Anfang an ein großes Einsatzfeld der Formulare abzudecken,

soll im Rahmen dieser Arbeit je ein Übersetzungsmodul für einen auf HTML

und einen auf SWT basierenden Kontext entwickelt werden. Die Unterschiede

in beiden Kontexten liegen in der Darstellung. Für den HTML-Kontext wird

ein HTML-Dokument erzeugt, welches später von einem Web-Browser dar-

gestellt wird. Für den SWT-Kontexte hingegen wird ein SWT-Composite

erzeugt, welches die Oberflächenbibliotheken des Betriebssystems nutzt, um

das Formular darzustellen.

Für die Übersetzung in einen bestimmten Kontext müssen jeweils zwei As-

pekte berücksichtigt werden. Zunächst wird erläutert, wie das Layout der

Composite und Formulare übersetzt wird. Anschließend wird gezeigt, wie

die Anwendungslogik umgesetzt wird, damit diese sich in beiden Kontexten

identisch verhält.

5.4.2.1 Übersetzung des Layouts Bei der Übersetzung des Layouts

müssen die Composite Definition in ein Format übersetzt werden, welches

das Aussehen der Composite Definition im Kontext der grafischen Umgebung

beschreibt. Für den SWT-Kontext handelt es sich dabei um eine Java-Klasse,

während für den HTML-Kontext ein HTML-Dokument verwendet wird.

Übersetzung für den SWT-Kontext Um ein Formular für den SWT-

Kontext zu übersetzen, erwartet das BPM-System die Instanz einer Java-

Klasse, welche auf einem SWT-Composite basiert. Diese Klasse muss jedoch

115

5 Entwurf einer Komponente zur Formularerstellung

Strasse

HausNr

Stadt/Plz

Land

4 Beschriftungsfelder 4 Textfelder 1 Feld für Ganzzahlen

Abbildung 57: Modell eines Composite für die Darstellung einer Adresse

Eigenschaft Datentyp Beschreibung

hintergrundFarbe INTEGER Legt die Hintergrundfarben der Text-

und Zahlenfelder fest

inhalt ADRESSE Legt die Adresse fest, welche dargestellt

werden soll

Tabelle 7: Eigenschaften des Adress-Composite

erst generiert werden. Das bedeutet, dass zunächst Java-Code erzeugt wer-

den muss und anschließend mit einem Java-Übersetzer in Java-Byte-Code

übersetzt werden muss. Dieser Byte-Code kann danach durch den Java-

Classloader in die laufende Java-Umgebung integriert werden. Damit steht

die Klasse zur Verfügung und kann zu einem Java-Objekt instanziert und

dem BPM-System übergeben werden. Dieses stellt mit Hilfe des erhaltenen

Objekts das Formular beim Endanwender dar.

Um das komplette Formularmodell zu übersetzten reicht eine Klasse nicht

aus. Sowohl für das eigentliche Formular, als auch für jede Composite Defi-

nition, die verwendet wird, wird Java-Code für eine separate Klasse erzeugt.

Innerhalb der Klasse für das Formular werden die Klassen der Composites

Definition instanziert, um daraus die Formularfelder zu erzeugen.

Bei der Übersetzung der Composite Definition werden die Eigenschaften auf

die Attribute der Klasse abgebildet. Für die Belegung der Eigenschaften der

Composite Definition mit Werten, werden entsprechende Methoden generiert.

116

5.4 Entwurf der Laufzeitumgebung

Abbildung 58: SWT-Composite für die Darstellung eines Adress-Composite

Da die Eigenschaften einen Datentyp haben, müssen auch alle im Formular-

modell verwendeten strukturierten Datentypen mit übersetzt werden. Für die

primitiven Datentypen ist keine Übersetzung erforderlich, da hierfür äquiva-

lente Java-Datentypen verwendet werden. Bei der Übersetzung der struktu-

rierten Datentypen wird für jeden Datentyp eine eigene Klasse generiert. Die

Elemente des Datentyps werden als Attribute der Klasse übersetzt. Diese At-

tribute sind öffentlich sichtbar und können direkt manipuliert werden, ohne

auf die Verwendung von Methoden zurückzugreifen. Der direkte Zugriff ist

für die Anwendungslogik wichtig, da innerhalb der Anwendungslogik eben-

falls direkt auf die Elemente von strukturierten Datentypen zugegriffen wird

und diese Semantik durch die ScriptEngine nicht verändert werden kann.

Für die Erstellung des Layouts von Composite Definition werden die Infor-

mationen über die Positionierung des Composite bei der Instanzierung der

Klasse für die Composite Definition mit übergeben. Die Klasse nutzt dann

die Methoden von SWT, um diese Composite an den richtigen Positionen

darzustellen.

Für die primitiven Composite, welche für die Darstellung primitiver Daten-

typen bereits vorhanden sind, werden entsprechende Klassen aus den SWT-

Bibliotheken verwendet. Hier gibt es beispielsweise Klassen, welche ein Text-

feld oder ein Auswahlfeld darstellen. Für das Zeichnen dieser Elemente ist

SWT verantwortlich. Diese SWT-Klassen werden durch das Übersetzungsmo-

dul ebenfalls in Klassen gekapselt, welche eine Composite Definition repräsen-

tieren. Dadurch wird gewährleistet, dass diese primitiven Composite trans-

parent genutzt werden können, d. h. ihre Schnittstelle unterscheidet sich nicht

von den Schnittstellen der Composite Definition, welche durch den Formul-

arentwickler erstellt wurden.

117

5 Entwurf einer Komponente zur Formularerstellung

Abbildung 59: (Vereinfachter) Java-Code für die Erstellung des Adress-

Composite im SWT-Kontext

118

5.4 Entwurf der Laufzeitumgebung

Abbildung 60: HTML-Dokument für die Darstellung eines Adress Composite

Wie eine Klasse für eine Composite Definition und ihre Verwendung aussieht,

demonstriert ein Beispiel. Abbildung 57 zeigt das Modell einer Composites

Definition, welches eine Adresse anzeigen soll. Diese Composite Definition

besteht aus mehreren Beschriftungsfeldern, Textfeldern, sowie einem Feld

für Ganzzahlen, welches für die Darstellung der Postleitzahl der Adresse zu-

ständig ist. Ausserdem besitzt die Composite Definition zwei Eigenschaften,

welche in Tabelle 7 gezeigt werden. Die Eigenschaft hintergrundFarbe, soll

eine Farbe repräsentieren, welche bei den Text- und Zahlenfelder hinterlegt

sind. Die Beschriftungsfelder sollen nicht hinterlegt werden. Die Eigenschaft

inhalt ist die Eigenschaft für den Wert der Adresse. Abbildung 59 zeigt

den erzeugten Java-Code. In Abbildung 58 ist die grafische Darstellung des

Composite als SWT-Composite zu sehen.

Übersetzung für den HTML-Kontext Innerhalb des HTML-Kontextes

ist das Übersetzen des Layouts mit einem größeren Aufwand verbunden.

HTML bietet zwar ebenfalls bereits grafische Elemente wie Textfelder oder

Auswahlfelder an. Jedoch sind diese statisch im HTML-Dokument integ-

riert. Die Eigenschaften dieser Elemente müssen jedoch während der Berar-

beitungszeit dynamisch geändert werden.

Um dieses Problem zu lösen, greift das Übersetzungsmodul für den HTML-

Kontext auf JavaScript zurück, da hiermit die dynamische Veränderung des

HTML-Dokumentes zur Ausführungszeit möglich ist. In JavaScript ist die

Erstellung und Verwendung von Klassen ebenfalls möglich. Daher kann bei

119

5 Entwurf einer Komponente zur Formularerstellung

Abbildung 61: (Vereinfachter) JavaScript-Code für die Erstellung des Adress-

Composite im HTML-Kontext

der Übersetzung der Composite Definition und deren Eigenschaften ähnlich

vorgegangen werden, wie bei der Übersetzung für den SWT-Kontext. Bei

der Übersetzung der Composite Definition für primitive Datentypen wird

auf die Verwendung der bereits vorhandenen HTML-Elemente für Formulare

zurückgegriffen. Diese können durch JavaScript zur Laufzeit dynamisch im

DOM-Modell der HTML-Dokumente eingefügt werden.

Um das Vorgehen zu verdeutlichen, wird wieder das Beispiel aus Abbildung

57 verwendet. Die Eigenschaften aus Tabelle 7 werden ebenfalls wieder über-

setzt. In Abbildung 60 ist ein Browser zu sehen, der das erzeugte HTML-

Dokument zeigt. Abbildung 61 zeigt den Code für eine JavaScript Klasse,

welche das Composite beim Aufruf des Konstruktors anlegt und eine Metho-

120

5.4 Entwurf der Laufzeitumgebung

Abbildung 62: Composite mit beispielhafter Anwendungslogik

de zum Setzen der Eigenschaften bereitstellt. Ausserdem ist der Code zum

Anlegen des Composite zu sehen. Dieser Code wird beim Initialisieren des

Formulars ausgeführt. In diesem Beispiel werden im Composite nur zwei der

Elemente einer Adresse verwendet, um den Code übersichtlich zu halten.

5.4.2.2 Übersetzen der Anwendungslogik Dadurch, dass bei der

Übersetzung des Layouts im HTML-Kontext JavaScript verwendet wird,

gestaltet sich die Übersetzung der Anwendungslogik recht einfach, da diese

bereits in JavaScript formuliert ist. Abbildung 62 zeigt ein Beispiel für ein

Composite mit Anwendungslogik. Um die Methoden, welche in der Anwen-

dungslogik definiert sind, nutzen zu können, ist es ausreichend, den Code

dieser Methoden in die JavaScript-Klassen der Composite Definition einzufü-

gen. Diese können dann durch die Methoden für die Behandlung von Ereignis-

sen aufgerufen. Abbildung 63 zeigt die Integration der Anwendungslogik aus

dem Beispiel in die Composite-Klassen für den HTML-Kontext.

Anwendungslogik im SWT-Kontext Die Übersetzung der Anwen-

dungslogik im SWT-Kontext gestaltet sich etwas umfangreicher. Da die

Composite Definition mit Hilfe von Java-Code umgesetzt ist, ist es nicht

möglich, die in JavaScript formulierte Anwendungslogik direkt als Methoden

in die Klassen zu integrieren. Um den JavaScript-Code dennoch verwenden

zu können, wird auf die Java-ScriptEngine [Ull09, Kapitel 10.6.3] zurückge-

griffen.

Mit Hilfe dieser ScriptEngine kann zur Ausführungszeit des Formulars in

einem SWT-Kontext, bei einem Auftreten eines Ereignisses die in JavaScript

formulierte Anwendungslogik ausgeführt werden. Dazu wird beim Eintreten

121

5 Entwurf einer Komponente zur Formularerstellung

Abbildung 63: Integration der Anwendungslogik in die Composite-Klassen

für den HTML-Kontext

des Ereignisses die ScriptEngine mit dem Code der Methode geladen, welche

diese Ereignisse behandeln. Ausserdem werden der ScriptEngine alle Java-

Objekte übergeben, welche für die Ausführung relevant sind. Innerhalb eines

Ereignisses in einer Composite sind dies die Instanzen der Composite, aus

denen das Composite aufgebaut ist. Die Namen, mit denen auf diese In-

stanzen zugegriffen werden, sind die Namen, welche für die Composite im

Layout des Componsite Definition vergeben wurden. Daher werden diese Na-

men auch verwendet, um die Java-Objekte zu binden. Innerhalb des Skripts

können auch Zugriffe auf die Methoden der Composite vorkommen. Daher

müssen bei den Java-Klassen, gleichnamige Methoden existieren. Abbildung

64 zeigt die Integration der in JavaScript formulierten Anwendungslogik in

eine Composite-Klasse für den SWT-Kontext.

5.5 Zusammenfassung

Dieses Kapitel hat einen Entwurf vorgestellt, der die Anforderungen aus

Kapitel 3 vollständig umsetzt. Der Entwurf besteht aus einer Entwicklungs-

und einer Ausführungsumgebung und einem gemeinsamen Datenmodell.

Das Datenmodell besteht aus mehreren Aspekten die zur Beschreibung von

Formularmodellen benötigt werden:

•Datentypen, um die Daten des BPM-System interpretieren zu können

122

5.5 Zusammenfassung

Abbildung 64: Integration der Anwendungslogik in die Composite-Klassen

für den SWT-Kontext

•Werte, um Informationen zu repräsentieren

•Composite zur Darstellung von Werten in grafischen Elementen

•Composite Definition zur Beschreibung von Composite

•Formularmodelle zur Beschreibung des Aussehens und des Verhaltens

von Formularen

Mit der Entwicklungsumgebung ist es möglich neue strukturierte Datentypen

und Aufzählungen zu erstellen, sowie Composite Definition und Formular-

modelle zu gestalten. Hierfür werden Editoren angeboten, welche auf die

jeweilige Aufgabe spezialisert sind. Mit einem Assistenten ist es ausserdem

möglich, Formularmodelle und Composite Definition größtenteils automa-

tisch generieren zu lassen.

Die Aufgabe der Ausführungsumgebung ist es, aus der abstrakten Beschrei-

bung des Formulars ein konkretes Dokument für den Endanwender zu erzeu-

gen. Hierfür muss zum Einen das erstellte Formularmodell mit den Werten

der Prozessschrittparameter, Daten aus externen Quellen und Informationen

zur Sprache und Einschränkungen des Endanwenders vervollstänigt werden.

123

5 Entwurf einer Komponente zur Formularerstellung

Zum Anderen muss das nun vollständige Formularmodell für den grafischen

Kontext des Endanwenders übersetzt werden. Dies wurde für den HTML-

und den SWT-Kontext erläutert.

Dieser Entwurf ist größtenteils unabhängig von konkreten BPM-Systemen.

In einigen Bereichen jedoch, beispielsweise die bei der Übersetzung für einen

grafischen Kontext, musste eine Anpassung an ADEPT2 vorgenommen wer-

den, um den Entwurf vollständig gestalten zu können. Bei einer Verwendung

in einem anderen BPM-System müssen diese Bereiche erneut angepasst wer-

den.

124

6 Umsetzung der Konzepte

Die vorgestellten Konzepte wurden im Rahmen dieser Arbeit in Form eines

Prototypen implementiert. Dafür wurden geeignete Schnittstellen entworfen:

•Datatype: Schnittstelle für Datentypen

•Value: Schittstelle für Repräsentation von Werten

•Script: Schnittstelle für Anwendungslogik

•FormCompositeDefinition: Schnittstelle für Composite Definition

•FormComposite: Schnittstelle für Composite

•Reference: Schnittstelle für virtuelle Parameter, basierend auf Value

•Form: Schnittstelle für Formularmodelle

Im folgenden Abschnitt werden die aufgezählten Schnittstellen im Detail er-

läutert.

6.1 Datatyp

Quellcode 6 zeigt die Schnittstelle Datatype. Mit dieser Schnittstelle

werden die Datentypen umgesetzt. Mit den Methoden isPrimitive(),

isPrimitive(Primitives type),isList(),isComplex(),isEnumeration() kann

überprüft werden, um welche Art von Datentyp es sich handelt. Han-

delt es sich um einen listenwertigen Datentyp, kann mit Hilfe der Metho-

de getListedDatatype() der Basistyp der Liste ermittelt werden. Wenn es

sich bei dem Datentyp um eine Aufzählung handelt, kann die Methode

getEnumerationOption() dazu genutzt werden, um die Option der Aufzäh-

lung zu ermitteln. Handelt es sich hingegen um einen strukturierten Da-

tentyp, lassen sich mit Hilfe der Methode getElementNames() zunächst die

Elemente der Struktur ermitteln. Durch die Methode getElementDatatype()

lässt sich der Datentyp eines Elements herausfinden. Da diese Elemente

selbst wieder einen strukturierten Datentyp haben können, lassen sich

dadurch komplexe Datentyphierarchien erstellen. Diese dürfen wie bereits

angesprochen, keine zyklischen Abhängigkeiten besitzen. Mit der Methode

getDependingDatatypes() können Datentypen ermittelt werden, zu denen eine

Abhängigkeit besteht. Bei listenwertigen Datentypen besteht die einzige Ab-

hängigkeit zu dem entsprechenden Basistyp. Bei strukturierten Datentypen

125

6 Umsetzung der Konzepte

werden die Abängigkeiten rekursiv für jedes Element ermittelt und verknüpft.

Primitive Datentypen und Aufzählungen haben keine Abhängigkeiten.

1public interface Datatype {

2enum Primitives {

3BOOLEAN ,

4INTEGER ,

5FLOAT ,

6STRING ,

7BLOB,

8DATE ;

10 String getName ();

11 Datatype getRelativeDatatype ( String relElementName )

12 boolean isPrimitive ( Primitives type );

13 boolean isPrimitive();

14 boolean isList ();

15 Datatype getListedDatatype ();

16 boolean isComplex();

17 Set <String > getElementNames ();

18 Datatype getElementDatatype ( String elementName )

19 boolean isEnumeration();

20 List <String > getEnumerationOptions ()

21 Set < Datatype > getDependingDatatypes ();

22 void addListener ( DatatypeListener listener );

23 void removeListener ( DatatypeListener listener );

24 }

Quellcode 6: Datatype-Schnittstelle

6.2 Value

Um einen Wert mit einem speziellen Datentyp anzulegen, wird die Schnitt-

stelle Value (Quellcode 7) benötigt, beispielsweise um beim Erstellen eines

Formularmodells Standardwerte für Eigenschaften der Composite anzugeben.

Hat ein Wert einen primitiven Datentyp, können mehrere Methoden genutzt

werden, um den Wert unterschiedlich zu interpretieren:

•Long getPrimitiveValueAsInteger()

•String getPrimitiveValueAsString()

•Boolean getPrimitiveValueAsBool()

126

6.2 Value

•Double getPrimitiveValueAsFloat()

•byte[] getPrimitiveValueAsBlob()

•Date getPrimitiveValueAsDate()

Es stehen auch korrespondierende Methoden bereit, um den Wert neu zu

setzen.

Handelt es sich bei dem Datentyp des Wertes um eine Liste, stehen andere

Methoden bereit um auf dessen Elemente zuzugreifen. Mit getListLength()

wird die Anzahl der Elemente in der Liste ermittelt. Durch die Methode

getListIndex(int index) wird auf ein bestimmtes Element der Liste zugegrif-

fen. Mit Hilfe der Methoden addListItem(Value value),removeListIndex(int

index) und setListItem(int index, Value value) wird der Inhalt der Liste ent-

sprechend manipuliert.

Hat der Wert hingegen einen strukturierten Datentyp, stehen die Methoden

getElementValue(String elementName) und setElementValue(String element-

Name, Value value) zur Verfügung. Damit kann der Wert eines Elements

ermittelt oder neu gesetzt werden.

Repräsentiert der Wert die Auswahl einer Aufzählung, ermittelt die Methode

getEnumOption() die ausgewählte Option. Mit setEnumOption(Strin option-

Name) kann die aktuelle Auswahl geändert werden.

Einen besonderen Wert, der für alle Datentypen möglich ist, ist der null-

Wert. Da durch die bisher beschriebenen Methoden nicht feststellbar ist, ob

ein Wert null ist, enthält die Schnittstelle die Methode isNull(), mit der

dies möglich ist.

1public interface Value {

2public Datatype getDatatype ();

3public boolean isNull ();

4public boolean isReadOnly();

5public Value getRelativeValue(String relativeElement);

6public int getListLength();

7public Value getListIndex ( int index);

8public void addListItem ( Value value );

9public void removeListIndex(int index );

10 public void setListItem(int index , Value value );

11 public Value getElementValue ( String elementName );

12 public void setElementValue ( String elementName , Value

value );

13 public Long getPrimitiveValueAsInteger ();

14 public void setPrimitiveInteger ( Long value );

127

6 Umsetzung der Konzepte

15 public String getPrimitiveValueAsString ();

16 public void setPrimitiveString(String value);

17 public Boolean getPrimitiveValueAsBool();

18 public void setPrimitiveBool ( Boolean value )

19 public Double getPrimitiveValueAsFloat();

20 public void setPrimitiveFloat ( Double value );

21 public byte [] getPrimitiveValueAsBlob();

22 public void setPrimitiveBlob(byte [] value );

23 public Date getPrimitiveValueAsDate();

24 public void setPrimitiveDate (Date value );

25 public String getEnumOption ();

26 public void setEnumOption ( String optionName );

27 }

Quellcode 7: Value-Schnittstelle

6.3 Script

Für die Angabe von Anwendungslogik wird die Schnittstelle Script

(Quellcode 8) verwendet. Die Anwendungslogik wird durch JavaScript-Code

beschrieben, der in JavaScript-Funktionen gekapselt wird. Diese Funktionen

können, wie in JavaScript üblich, mit Parametern versehen werden. Im

JavaScript-Code stehen diese Parameter als Objekte zur Vefügung. Eine In-

stanz der Schnittstelle Script kann beliebig viele Funktionen verwalten. Um

sämtliche Funktion zu erhalten, kann die Methode getFunctions() verwendet

werden. Damit erhält man die Funktionsnamen. Die dazugehörigen Parame-

ter können durch die Methode getFunctionParameters(String methodName)

ermittelt werden. Um den JavaScript-Code zu erhalten, steht die Methode

getFunctionCode(String methodName) bereit. Um den JavaScript-Code oder

die Parameter einer Funktion zu manipulieren, gibt es ebenfalls entsprechen-

de Methoden.

1public interface Script {

2Set <String > getFunctions ();

3List < String > getFunctionParameters ( String methodName );

4String getFunctionCode ( String methodName );

5void addFunction ( String functionName ,

6List <String > functionParameter , String fnuctionCode );

7void addFunctionParameter ( String functionName , String

functionName );

8void setFunctionCode ( String functionname , String

functionCode );

128

6.4 FormCompositeDefinition

9void removeFunction ( String functionName );

10 void removeFunctionParameter ( String functionName ,

String parameterName);

11 }

Quellcode 8: Script-Schnittstelle

6.4 FormCompositeDefinition

Um eine Composite Definition anzulegen, wird die Schnittstelle FormCom-

positeDefinition (Quellcode 9) verwendet. Jedes grafische Element, welches

durch eine Composite Definition beschrieben wird, kann nur Werte mit einem

bestimmten Datentyp darstellen. Dieser Datentyp wird durch die Methode

getSupportedDatatype() ermittelt und ist auch implizit der Eigenschaft inhalt

zugeordnet.

Um Informationen über die Eigenschaften einer Composite Definition zu er-

halten, stehen die Methoden getAttributes(),getAttributeDatatype(String at-

tribute),getAttributeDefaultValue(String attribute) und getAttributeDescrip-

tion(String attribute) bereit. Damit können die Namen der Eigenschaften

ermittelt werden, die zugeordneten Datentypen, die Standardwerte und eine

Beschreibung für den Formularentwickler.

Für mögliche Ereignisse, die ausgelöst werden können, gibt es zwei weitere

Methoden: Die Methode getEvents() gibt die Namen aller Ereignisse zurück.

Um eine Beschreibung eines Ereignisses für den Formularentwickler zu erhal-

ten, steht die Methode getEventDescription(String event) bereit.

Es gibt spezielle FormCompositedefinition, welche nicht durch den Formular-

entwickler angelegt werden können. Dabei handelt es sich um primitive Form-

Compositedefinition, welche grundlegende grafische Elemente darstellen, wie

zum Beispiel ein Textfeld, ein Beschriftungsfeld oder eine Schaltfläche. Sol-

che FormComopositeDefinintions stehen von Anfang an zur Verfügung. Mit

Hilfe der Methode isPrimitive() ist es möglich zu ermitteln, ob es sich um

eine primitive FormCompositeDefinition handelt.

Stellt eine FormCompositeDefinition kein primitives grafisches Element dar,

ist es aus Composite aufgebaut. Diese können durch die Methode getUsed-

Composites() ermittelt werden.

129

6 Umsetzung der Konzepte

Um das Verhalten der FormCompositeDefinition beim Eintreten von

Ereignissen zu steuern, enthält diese ein Script. Darauf kann durch die Me-

thode getScript() zugegriffen werden.

1public interface FormCompositeDefinition {

2String getName ();

3Datatype getSupportedDatatype ();

4Set <String > getAttributes ();

5Datatype getAttributeDatatype ( String attribute );

6Value getAttribDefaultValue ( String attribute );

7String getAttribDescription ( String attribute );

8Set < String > getEvents ();

9String getEventDescription ( String event );

10 Set < FormComposite > getUsedComposites ();

11 Script getScript ();

12 boolean isPrimitive();

13 }

Quellcode 9: FormCompositeDefinition-Schnittstelle

6.5 FormComposites

FormCompositeDefinition stellen grafische Elemente dar, die in einem For-

mular oder einer weiteren FormCompositeDefinition verwendet werden kön-

nen. Dafür muss jedoch zunächst ein Composite erstellt werden. Hierzu dient

die Schnittstelle FormComposite. Diese Schnittstelle dient zur Speicherung

von Instanzspezifischen Aspekten, wie zum Beispiel der Name der Instanz,

die relative Positionierung oder die Bindung von Ereignissen an Anwendungs-

logik.

Jedes FormComposite basiert auf einer FormCompositeDefinition. Diese kann

durch die Methode getDefinition() ermittelt werden. Der Name der Instanz

wird durch die Methode getInstanceName() zurückgegeben. Dieser Name

kann dazu genutzt werden, um in der Anwendungslogik eines Formulars oder

einer umschließenden Composite Definition auf das Composite zuzugreifen.

Folgende Methoden erlauben den Zugriff auf die Daten über die relative Po-

sitionierung:

•getInstanceX()

•getInstanceY()

•getInstanceWidth()

130

6.6 Reference

•getInstanceHeight()

Um die Werte für die Eigenschaften zu ermitteln, stehen ebenfalls mehrere

Methoden zur Verfügung. Durch getUsedAttributes() erhält man eine Liste

der Eigenschaften, für welche Werte angegeben sind. Für Eigenschaften, für

die kein expliziter Wert angegeben wurde, gilt der Standardwert, der in der

zugehörigen FormCompositeDefinition definiert wurde. Falls jedoch ein Wert

gesetzt wurde, kann dieser durch die Methode getInitialAttributeValue(String

attrib) ermittelt werden.

Ein analoges Schema wird für die Behandlung von Ereignissen verwendet.

Durch die Methode getUsedEvents() erhält man eine Liste von Ereignis-

sen, welche durch die umschließende Composite Definition oder ein Formul-

ar abgefangen werden. Die Methode getEventHandler(String event) ermittelt

den Namen der Funktion, die zur Behandlung des Ereignisses verwendet wird.

Der Name bezieht sich dabei auf die verfügbaren Funktionen aus dem Script

der umschließenden Composite Definition oder des umschließenden Formu-

lars.

1public interface FormComposite {

2public FormCompositeDefinition getDefinition();

3public String getInstanceName();

4public int getInstanceRow ();

5public int getInstanceColumn ();

6public int getInstanceWidth();

7public int getInstanceHeight ();

8public Set < String > getUsedAttributes ();

9public Value getInitialAttributeValue ( String attrib );

10 public void setInitialAttributeValue ( String attribute ,

Value value );

11 public Set < String > getUsedEvents ();

12 public String getEventHandler ( String event );

13 public void setEventHandler ( String event , String

function);

14 }

Quellcode 10: FormComposites-Schnittstelle

6.6 Reference

Die Werte für die Eigenschaften von Composite können auch an die Para-

meter des umschließenden Formulars gebunden werden, bzw. an die Eigen-

131

6 Umsetzung der Konzepte

schaften der umschließenden Composite Definition. Um dies zu realisieren,

wird eine weitere Schnittstelle benötigt. Quellcode 11 zeigt die Schnittstel-

le Reference, welche die Schnittstelle Value erweitert. Mit einer Reference

ist es möglich, auf Werte zu verweisen, die noch nicht zur Verfügung ste-

hen. Durch die neue Methode isValueReady() kann geprüft werden, ob der

Wert bereits verfügbar ist oder nicht. Wenn der Wert verfügbar ist, kann die

übliche Schnittstelle von Value verwendet werden, um diesen Wert abzufra-

gen. Ist der Wert noch nicht verfügbar, ist dies nicht möglich. Es gibt 4

Implementierungen der Schnittstelle:

•ParameterReference

•HistoricalParameterReference

•ContainerValueReference

•ExternalReference

Wird ein Wert für eine Eigenschaft in einer Composite innerhalb eines Formu-

lars angegeben, ist es mit einer ParameterReference möglich auf einen Ein-

oder einen Ausgabeparameter des Formulars zu verweisen. Möchte der For-

mularentwickler die Ausgabeparameter einer vergangenen Aktivität mit in

das Formular einbinden, kann dieser eine HistoricalParameterReference ver-

wenden. Mit der ContainerValueReference ist es möglich, auf den Wert einer

Eigenschaft von einer umschließenden Composite Definition zu verweisen.

Durch eine ExternalReference lassen sich Werte aus einer externen Daten-

bank beziehen. In allen vier Fällen ist die Angabe eines Elements möglich,

falls der referenzierte Wert einen strukturierten Datentyp besitzt.

1public interface Reference extends Value {

2boolean isValueReady ();

Quellcode 11: Reference-Schnittstelle

6.7 Form

Für die Erstellung eines Formularsmodells wird die Schnittstelle Form ver-

wendet (Quellcode 12). Sie bietet ähnlich wie die FormCompositeDefinition

ein Script an, um die Anwendungslogik des Formulars festzulegen. Diese

Anwendungslogik kann durch die Methode getScript() ermittelt werden. Um

das Layout des Formularmodells festlegen zu können, verfügt eine Form auch

132

6.7 Form

über FormComposites. Die Methode getUsedComposites() gibt eine Liste aller

verwendeten FormComposites zurück.

1public interface Form {

2String getName ();

3Set < FormComposite > getUsedComposites ();

4Script getScript ();

5void setName ( String name );

6void addComposite ( FormComposite composite );

7void removeComposite ( FormComposite composite );

8void moveComposite(FormComposite composite, int row ,

int col);

9void setScript ( Script script );

10 }

Quellcode 12: Form-Schnittstelle

133

6 Umsetzung der Konzepte

134

7 Zusammenfassung und Ausblick

7.1 Zusammenfassung

Die vorliegende Arbeit befasste sich mit der automatischen Erstellung von

Oberflächen für Benutzerinteraktionen in BPM-Systemen. Im Rahmen dieser

Arbeit wurden intelligente Formulare behandelt, die dem Austausch von

Informationen mit dem Benutzer dienen und ein flexibles Verhalten er-

möglichen. Das Ziel war es, Lösungen zu erarbeiten, welche die Erstellung

und Integration solcher Formulare in vorhandene BPM-Systeme ermöglicht.

Um die theoretischen Überlegungen auch praktisch umzusetzen, sollte ein

Prototyp in Form einer Softwarekomponente entwickelt werden, welcher in

das ADEPT2-System integriert werden konnte.

Nach der Diskussion der Grundlagen wurden die Anforderungen analysiert,

welche sich für eine neue Softwarekomponente ergeben. Dabei wurde unter

anderem gezeigt, dass die Komponente aus zwei Bereichen besteht: Einer

Entwicklungsumgebung, mit der die Formulare erstellt werden und einer

Laufzeitumgebung, welche diese Formulare dem Endanwender präsentiert.

Für die Präsentation spielt der verwendete grafische Kontext ein wichtige

Rolle. Nicht bei jedem Endanwender stehen alle grafischen Kontexte bereit,

die vom BPM-System angeboten werden. Es kann daher nicht mit Sicherheit

gesagt werden, in welchem grafischen Kontext das Formular dargestellt wer-

den muss. Daher muss die Entwicklungsumgebung die Formulare in einem

unabhängigen Format speichern. Die Laufzeitumgebung muss dieses dann

entsprechend, der zur Verfügung stehenden Kontexte interpretieren.

Nach der Erläuterung der Anforderungen wurden darauf aufbauend Krite-

rien für eine Evaluierung entwickelt. In dieser Evaluierung wurden Produk-

te und Technologien untersucht, die sich ebenfalls mit der Gestaltung und

Darstellung von grafischen Benutzeroberflächen befassen. Untersucht wurden

dabei Inubit, Adobe Lifecycle Designer, Microsoft Infopath, JAXFront, WJP

Form und XForms. Die Kriterien für die Evaluierung waren eine einfach Be-

dienbarkeit, Lizenz und Integrationsfähigkeit, unterstützte Datentypen, die

Möglichkeit externe Daten einzubinden, die verfügbaren grafische Elemente,

die Integrationsfähigkeit von Anwendungslogik, die möglichen grafische Kon-

texte sowie die Möglichkeit Formulare zu lokalisieren. Bei der eigentlichen

Evaluierung hat sich herausgestellt, dass die Verwendung von Formularen

bereits gut etabliert ist. Ein Produkt, welches alle Anforderungen erfüllen

kann, gab es jedoch nicht.

135

7 Zusammenfassung und Ausblick

Aus diesem Grund mussten eigene Konzepte untersucht werden, welche die

Anforderungen umsetzen. Neben der Entwicklungsumgebung und der Lauf-

zeitumgebung wurde auch ein gemeinsames Datenmodell besprochen. Dieses

Datenmodell beinhaltet mehrere Konzepte: Neben primitiven Datentypen

wurden Aufzählungen, listenwertige und strukturierte Datentypen einge-

führt. Damit können die Ein- und Ausgabeparameter von Aktivitäten mit

Formularen genauer spezifiziert werden, als mit den bisherigen Datentypen.

Für die Repräsentation von Daten mit einem bestimmten Datentyp wurde ein

Konzept für Werte vorgestellt. Um diese Werte grafisch darzstellen, werden

grafische Elemente in Formularen verwendet. Um langfristig flexible Darstel-

lungsmöglichkeiten zu haben wurden dafür Composite Definition eingeführt.

Diese sind aus bereits vorhandenen grafischen Elemente zusammengestellt

und verfügen über eine eigene Anwendungslogik. Dadurch sind sie in der

Lage auch Werte mit sehr komplex strukturierten Datentypen darzustellen

und den Endanwender beispielsweise bei falschen Eingaben auf die Fehler

hinzuweisen. Um diese Composite Definition für die Erstellung von Formual-

ren oder in weiteren Composite Definition zu verwenden, wurden zusätzlichen

noch Composite eingeführt. Diese bilden die Instanz einer Composite Defini-

tion und beinhalten nur Instanzspezifische Aspekte, wie zum Beispiel Anga-

ben über Positionierung oder den Instanznamen, der in der Anwendungslogik

dazu verwendet wird, um auf das Composite zuzugreifen.

Den Abschluss der Arbeit stellte eine prototypische Implementierung des

Entwurfs dar. Für Implementierung wurden Schnittstellen entwickelt, mit

denen sich die vorgestellten Konzepte umsetzen konnten. Diese Schnittstellen

wurden besprochen.

7.2 Ausblick

Während Formulare früher lediglich zum Austauschen von Daten zwischen

System und Endanwender genutzt wurden, ist es nun auch möglich Formul-

aren mit einem komplexen Verhalten zu verwenden. Diese hat den Vorteil,

dass triviale Prüfungen von Eingaben und das Aufbereiten von Daten be-

reits im Formular durchgeführt werden können. Dadurch werden beim Mod-

ellieren von Geschäftsprozessen Aktivitäten eingespart, welche diese Arbeiten

sonst in einem separatem Prozessschritt durchführen müssen. Die Prozes-

ses werden dadurch übersichtlicher. Unnötige Komplexität wird vermieden.

Dieser Vorteil wird noch deutlicher, wenn in einem Prozess das selbe For-

mular mehrmals benötigt wird. In diesem Fall kann nicht nur das Layout des

Formulars wiederverwendet werden. Da die Anwendungslogik, die das Ver-

136

7.2 Ausblick

halten festlegt im Formular integriert ist, muss diese Anwendungslogik nicht

erneut entworfen werden.

Ein weiterer Aspekt der neuen Formulare ist, dass diese größtenteils automa-

tisch generiert werden können. Für die Gestaltung von Formularen sind somit

keine teuren Softwareingenieure mehr nötig. Spezialisierte Mitarbeiter eines

Unternehmens sind ausreichend um die Benutzerinteraktionen in einem Ge-

schäftsprozess umzusetzen.

Intelligente Formulare sind daher ein wichtiger Schritt, wenn es darum geht

die Gestaltung von Geschäftsprozessen durch die Entwickler zu vereinfachen

und die Endanwender bei ihrer Arbeit zu unterstützen.

137

A Abbildungsverzeichnis

1 Trennung von Prozess- und Anwendungslogik . . . . . . . . . 2

2 Prozess mit Dateneingaben und Datenverarbeitung . . . . . . 3

3 Vereinfachter Prozess mit intelligenten Formularen . . . . . . . 4

4 Benutzer eines BPM-Systems . . . . . . . . . . . . . . . . . . 9

5 Prozessmodell mit Prozessschritten und Kontrollfluss . . . . . 10

6 Prozessmodell mit Datenfluss . . . . . . . . . . . . . . . . . . 10

7 Prozessmodell mit Aktivitäten . . . . . . . . . . . . . . . . . . 11

8 Instanz eines Prozessmodells . . . . . . . . . . . . . . . . . . . 12

9Process Template Editor von ADEPT2 . . . . . . . . . . . . . 13

10 Prozessmodell für einen Urlaubsantrag mit Formularaktivitäten 14

11 Generiertes Formular für eine Aktivität . . . . . . . . . . . . . 14

12 Integration eines Anwendungsbausteins zur Laufzeit . . . . . . 16

13 Ausführung von JavaScript in einem Web-Browser . . . . . . . 17

14 Funktionsweise der ScriptEngine . . . . . . . . . . . . . . . . . 19

15 Einige Composite von SWT in unterschiedlichen Betriebssys-

temen[Ecl09a] .......................... 22

16 Darstellung des SWT-Composite ................ 22

17 Entwurf des Prozesses mit Prozessschritten, Aktivitäten Pa-

rametern und Formularen . . . . . . . . . . . . . . . . . . . . 26

18 Ausführung eines Prozesses mit Formularen . . . . . . . . . . 28

19 Überblick über das Gesamtsystem . . . . . . . . . . . . . . . . 29

20 Traditionelle Entwicklung einer Oberfläche . . . . . . . . . . . 33

21 Entwicklung eines Formulars mit einem Assistenten . . . . . . 33

22 Formulare in unterschiedlichen Kontexten mit ähnlichem

Aussehen ............................. 37

23 Strukturierter Datentyp für eine Adresse . . . . . . . . . . . . 39

24 Daten interpretiert als Adressinformation . . . . . . . . . . . . 39

25 Liste als strukturierter Datentyp mit fester Länge . . . . . . . 41

26 Standardelemente grafischer Oberflächen . . . . . . . . . . . . 42

27 Beispielformular für elektronische Überweisungen [FID09] . . . 42

28 Traditionelles Überweisungsdokument . . . . . . . . . . . . . . 43

29 Kontextbezogene grafische Elemente [Mü08b]. . . . . . . . . . 44

30 Formular für Einkaufsliste mit automatischer Preisberechnung

[Ein09]............................... 45

31 Barrierefreie Tastatur [BWF09] . . . . . . . . . . . . . . . . . 47

32 Verwendung von Formularfeldern vorangegangener Formulare . 52

33 Entwicklungsumgebung für Formulare von Inubit . . . . . . . 61

34 Entwicklungsumgebung für Formulare von Adobe Lifecycle

Designer.............................. 64

vii

35 Grafische Elemente für Formulare in Adobe Lifecycle Designer 66

36 Mit Adobe Lifecycle Designer generiertes PDF-Dokument . . . 67

37 Entwicklungsumgebung für Formulare von Microsoft Infopath 68

38 Dialoge zum Erstellen von Regeln für Formularfelder in Micro-

softInfopath............................ 70

39 Architektur von JAXFront [JAX] . . . . . . . . . . . . . . . . 72

40 XUI-Editor von JAXFront . . . . . . . . . . . . . . . . . . . . 73

41 Oberfläche für Swing gerendert . . . . . . . . . . . . . . . . . 75

42 Editor für Formulare von WJP . . . . . . . . . . . . . . . . . 76

43 WJP Editor für Container .................... 77

44 Übersicht über externe Datenbankverbindungen in WJP Form 78

45 Dialog für die Behandlung von Ereignissen eines grafischen

WJP-Elements .......................... 79

46 Darstellung eines XForms-Dokuments in einem XForms-

fähigem Web-Browser [W3C09b](vereinfacht) . . . . . . . . . . 82

47 Architektur der neuen Komponente und Eingliederung in das

BPM-System ........................... 88

48 Erstellung eines Formularmodells . . . . . . . . . . . . . . . . 90

49 Ablauf einer Formularausführung . . . . . . . . . . . . . . . . 91

50 Beispiele für Composite ...................... 96

51 Formular bestehend aus mehreren Composite .......... 97

52 Composite Definition mit Eigenschaften, einem Layout und

Composite .............................104

53 Übersicht über das Datenmodell . . . . . . . . . . . . . . . . . 107

54 Editor für strukturierte Datentypen (links) und Aufzählungen

(rechts) ..............................108

55 Baumansicht der vorhandenen Datentypen . . . . . . . . . . . 109

56 JSEclipse: Editor für JavaScript-Code [Aja09] . . . . . . . . . 111

57 Modell eines Composite für die Darstellung einer Adresse . . . 116

58 SWT-Composite für die Darstellung eines Adress-Composite . 117

59 (Vereinfachter) Java-Code für die Erstellung des Adress-

Composite imSWT-Kontext...................118

60 HTML-Dokument für die Darstellung eines Adress Composite 119

61 (Vereinfachter) JavaScript-Code für die Erstellung des Adress-

Composite im HTML-Kontext . . . . . . . . . . . . . . . . . . 120

62 Composite mit beispielhafter Anwendungslogik . . . . . . . . . 121

63 Integration der Anwendungslogik in die Composite-Klassen für

denHTML-Kontext........................122

64 Integration der Anwendungslogik in die Composite-Klassen für

denSWT-Kontext ........................123

viii

B Quellcodeverzeichnis

1 Schnittstelle der ExecutableComponent ............. 15

2 JavaScript eingebettet in HTML [Mü08a] . . . . . . . . . . . . 16

3 Benutzerdefiniertes Steuerelement als SWT-Composite . . . . 23

4 Verwendung eines Composite ................... 24

5 XForms-Dokuments, eingebettet in einem HTML-Dokument

[W3C09b](vereinfacht) . . . . . . . . . . . . . . . . . . . . . . 80

6Datatype-Schnittstelle ......................126

7Value-Schnittstelle ........................127

8Script-Schnittstelle ........................128

9FormCompositeDefinition-Schnittstelle . . . . . . . . . . . . . 130

10 FormComposites-Schnittstelle . . . . . . . . . . . . . . . . . . 131

11 Reference-Schnittstelle ......................132

12 Form-Schnittstelle ........................133

C Tabellenverzeichnis

1 Übersicht über die verfügbaren Editionen des JAXFront Ren-

derers und der Lizenzkosten in Euro . . . . . . . . . . . . . . . 74

2 Zusammenfassung der Evaluierungsergebnisse . . . . . . . . . 86

3 Zuordnung der neuen Datentypen auf ADEPT2 Datentypen . 94

4 Mögliche Eigenschaften für Composite und deren möglichen

Datentypen ............................ 99

5 Mögliche Ereignisse von Composite ...............101

6 Elemente einer Adresse . . . . . . . . . . . . . . . . . . . . . . 103

7 Eigenschaften des Adress-Composite ...............116

xii

D Literaturverzeichnis

[Ado09a] Adobe:FormCalc, 2009. http://help.adobe.com/de_

DE/livecycle/8.2/acrobat_designer/wwhelp/wwhimpl/

common/html/wwhelp.htm?context=Adobe_LiveCycle_

Designer-Hilfe\&file=Overview.112.1.html Abruf:

02.06.2009.

[Ado09b] Adobe:Lifecycle Designer, 2009. http://www.adobe.com/de/

products/livecycle/designer/ Abruf: 23.05.2009.

[Ado09c] Adobe:Lifecycle Enterprise Suite, 2009. http://www.adobe.

com/de/products/livecycle/ Abruf: 23.05.2009.

[Ado09d] Adobe:Reader, 2009. http://www.adobe.com/de/products/

reader/ Abruf: 23.5.2009.

[Aja09] Ajaxian:JSEclipse, 2009. http://ajaxian.com/archives/

jseclipse-javascript-editor-with-code-completion

Abruf: 03.06.2009.

[Alb07] Alby, Tom:Web 2.0. Konzepte, Anwendungen, Technologien.

Hanser Verlag, 2007.

[App07] Apple:MAC OS X Leopard, Oktober 2007. http://www.apple.

com/de/macosx/techspecs/ Abruf: 27.05.2009.

[Ari09] Aristaflow:AristFlow BPM Suite, 2009. http://aristaflow.

com/ Abruf: 03.06.2009.

[BWF09] BWF virtuell inside:E-Learning für Blinde und Sehbehin-

derte, 2009. http://inside.bfwvirtuell.de/blind_und_pc

Abruf: 06.06.2009.

[Dad06] Dadam, Peter:ADEPT2 - Ein adaptives Prozess-Management-

System der nächsten Generation. Tagungsband Stuttgarter Soft-

waretechnik Forum, 2006.

[Dad09] Dadam, Peter:Von ADEPT zur AristaFlow BPM Suite.

Koellen-Verlag, 2009.

[Ecl09a] Eclipse:Standard Widget Toolkit, Mai 2009. http://www.

eclipse.org/swt/ Abruf: 08.05.2009.

[Ecl09b] Eclipse:Understanding Layouts in SWT, 2009.

http://www.eclipse.org/articles/article.php?file=

xiii

Article-Understanding-Layouts/index.html Abruf:

25.05.2009.

[Ein09] Einkaufsplaner Online, Mai 2009. http://www.

einkaufsplaner-online.de Abruf: 10.03.2009.

[FID09] Fiducia, 2009. http://www.fiducia.de/ Abruf: 01.06.2009.

[GNU91] GNU:General Public License, version 2, Juni 1991. http://www.

gnu.org/licenses/gpl-2.0.html Abruf: 16.05.2009.

[GTK09] Gimp Toolkit, Mai 2009. http://www.gtk.org/ Abruf:

09.05.2009.

[Int93] International Organization for Standardization:

ISO/IEC 2382 - Information technology – Vocabulary – Part 1:

Fundamental terms, 1993.

[Inu09a] Inubit BPM-Suite, 2009. http://www.inubit.com/index.php

Abruf: 23.05.2009.

[Inu09b] Inubit BPM-Suite: Modulhandbuch, 2009.

[ISO02] ISO (International Organization for Standardiza-

tion):ISO/IEC 16262 - ECMAScript language specification, Ju-

ni 2002.

[ISO09] International Organization for Standardization, 2009. http://

iso.org Abruf: 27.05.2009.

[JAX] JAXFront: Smart GUI Solutions.http://www.jaxfront.com

Abruf: 17.05.2009.

[Joh95] Johnson, Erich Gamma; Richard Helm; Ralph E.:De-

sign Patterns. Elements of Reusable Object-Oriented Software.

Addison-Wesley Longman, März 1995.

[Jur06] Jurisch, Martin:Konzeption eines Rahmenwerkes zur Erstel-

lung und Modifikation von Prozessvorlagen und -instanzen. Uni-

versität Ulm, März 2006.

[Mic09a] Microsoft:Microsoft Foundation Classes, Mai 2009. http://

msdn.microsoft.com/de-de/library/d06h2x6e(VS.80).aspx

Abruf: 09.05.2009.

[Mic09b] Microsoft:.NET-Framework, 2009. http://www.microsoft.

com/NET/ Abruf: 24.05.2009.

xiv

[Mic09c] Microsoft:SQL-Server, 2009. http://www.microsoft.com/

germany/sql/2008/default.mspx Abruf: 10.06.2009.

[Mic09d] Microsoft:Visual Basic, Mai 2009. http://www.microsoft.

com/germany/express/product/visualbasicexpress.aspx

Abruf: 19.05.2009.

[Mic09e] Microsoft:Visual Basic for Application, 2009. http:

//msdn.microsoft.com/de-de/isv/bb190538(en-us).aspx

Abruf: 24.05.2009.

[Mic09f] Microsoft:Windows Forms, Mai 2009. http:

//windowsclient.net/ Abruf: 09.05.2009.

[Mic09g] Microsoft:Windows SharePoint Services Overview,

2009. http://download.microsoft.com/download/a/e/6/

ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-WSSO%5D.

pdf Abruf: 02.06.2009.

[Moz09] Mozilla:Firefox, 2009. http://www.mozilla.com/en-US/

firefox/personal.html Abruf: 24.05.2009.

[Mü08a] Münz, Stefan:Einführung in JavaScript und DOM, September

2008. http://de.selfhtml.org/javascript/intro.htm Abruf:

07.05.2009.

[Mü08b] Münz, Stefan:HTML: Felder für Datei-Upload, Septem-

ber 2008. http://de.selfhtml.org/html/formulare/datei_

upload.htm Abruf: 11.05.2009.

[Ope09] Opengroup:Motif, Mai 2009. http://www.opengroup.org/

motif/ Abruf: 09.05.2009.

[Pal09] Palm:Palm OS, 2009. http://www.palm.com/de/de/ Abruf:

27.05.2009.

[Ree08] Reed, Doron Rosenberg; Aaron:Mozilla XForms Plugin

Version 0.8.6ff3, Oktober 2008. https://addons.mozilla.org/

de/firefox/addon/824 Abruf: 20.01.2009.

[Rei00] Reichert, Manfred:Dissertation: Dynamische Ablaufän-

derungen in Workflow-Management-Systemen. Universität Ulm,

2000.

[Rei06] Reichert, Manfred; Dadam, Peter:ADEPT-

flex—Supporting Dynamic Changes of Workflows Without

Losing Control. Kluwer Academic Publishers, März 2006.

[RFC05] RFC: Common Format and MIME Type for Comma-Separated

Values (CSV) Files, Oktober 2005. http://tools.ietf.org/

html/rfc4180 Abruf: 24.05.2009.

[Sun06] Sun Microsystem:Java Platform Enterprise Edition, Mai

2006. http://java.sun.com/javaee/technologies/javaee5.

jsp Abruf: 24.05.2009.

[Sun09a] Sun Microsystem:Abstract Window Toolkit, Mai 2009. http:

//java.sun.com/products/jdk/awt/ Abruf: 09.05.2009.

[Sun09b] Sun Microsystem:Swing, Mai 2009. http://java.sun.com/

javase/technologies/desktop/ Abruf: 09.05.2009.

[Sun09c] Sun Microsystem:The Java Database Connectivity (JDBC),

2009. http://java.sun.com/javase/technologies/database/

index.jsp Abruf: 03.06.2009.

[Tro09] Trolltech:QT, Mai 2009. http://www.qtsoftware.com/

Abruf: 09.05.2009.

[Ull09] Ullenboom, Christian:Java ist auch eine Insel. Galileo Com-

puting, 2009.

[Ulm09] Universität Ulm, 2009. http://www.uni-ulm.de Abruf:

23.05.2009.

[Unt03] Unterstein, Günter Matthiessen; Michael:Relationale

Datenbanken und SQL – Konzepte der Entwicklung und Anwen-

dung. Addison-Wesley, Mai 2003.

[W3C98] W3C:Cascading Style Sheets 2, Mai 1998. http://www.w3.org/

Style/CSS/ Abruf: 31.05.2009.

[W3C07] W3C:XForms 1.1, November 2007. http://www.w3.org/

MarkUp/Forms/ Abruf: 17.05.2009.

[W3C08] W3C:Extensible Markup Language (XML) 1.0 (Fourth

Edition), November 2008. http://www.w3.org/TR/2006/

REC-xml-20060816/#sec-origin-goals Abruf: 23.05.2009.

[W3C09a] W3C: The World Wide Web Consortium, 2009. http://www.w3.

org/ Abruf: 23.05.2009.

[W3C09b] W3C:XForms - Introductory Example No. 1, 2009.

http://ubiquity-xforms.googlecode.com/svn/trunk/

xvi

testsuite/W3C-XForms-1.1/Edition1/Chapt02/2.1.a.xhtml

Abruf: 07.06.2009.

[Wen06] Wenz, Christian:AJAX. schnell + kompakt. Entwickler.Press,

April 2006.

[Wik09a] Wikipedia:Liste von GUI-Bibliotheken, Mai 2009. http://

de.wikipedia.org/wiki/Liste_von_GUI-Bibliotheken Abruf:

08.05.2009.

[Wik09b] Wikipedia:What you see is what you get (WYSIWYG),

Mai 2009. http://de.wikipedia.org/wiki/WYSIWYG Abruf:

19.05.2009.

[WJP09] WJ&P Systemhaus AG, 2009. http://www.wjp.de/ Abruf:

23.05.2009.

[WX09] WXWidgets, Mai 2009. http://wxwidgets.org/ Abruf:

09.05.2009.

xvii

Ehrenwörtliche Erklärung

Hiermit versichere ich, Florian Micheler, dass ich die vorliegende Arbeit

selbstständig verfasst und keine anderen als die angegebenen Quellen und

Hilfsmittel benutzt habe.

Ulm, 9. Juni 2009

Ort, Datum Florian Micheler

Danksagung

An dieser Stelle möchte ich mich bei einigen Personen bedanken, die mich

während meiner Arbeit besonders unterstützt haben.

An erster Stelle danke ich meinen Eletern, Heinz und Karin Micheler. Ohne

euch wäre mein Studium nicht möglich gewesen. Euer Vertrauen und eure

Geduld haben mir immer Zuversicht gegeben.

Für die Betreung dieser Arbeit danke ich Ulrich Kreher. Du hast mich nicht

nur unterstützt, sondern durch Deine hohen Ansprüche auch stets motiviert.

Deine Vorschläge und Erfahrung waren es, die es mir ermöglichten die Arbeit

Schritt für Schritt zu verbessern.

Neben Ulrich möchte ich mich auch bei seinen Kollegen bei AristaFlow für die

hilfreichen Tipps bdedanken, die mir sehr geholfen haben. Zudem waren die

täglichen Tischkickerspiele mit euch immer eine wilkommene Abwechselung

und halfen oft dabei, wieder einen klaren Kopf zu bekommen.

Zuletzt danke ich noch besonders Bastian Glöckle, der sich sehr oft Zeit für

Korrekturen an der Arbeit genommen hat. Deine zahlreichen Anregungen

waren eine große Hilfe und Erleichterung für mich.