Pflichtenheft FlowWorkJ

Experte: Jean-Jacques Jaquier 

Betreuer: Rolf Jufer, Hoang-Van Chau 

Autoren: Hugo Graf, Marco Zbinden 

Version: 2.3 

Status: final 

Ausgabedatum: 11.06.2002 

Dokumentname: Pflichtenheft.doc 

Webseite: http://home.dtc.ch/flowworkj/ 

Pflichtenheft 

FlowWorkJ 

Diplomarbeit 

Framework für Internet-basierte Workflow-Lösungen

Pflichtenheft - FlowWorkJ Änderungskontrolle 

Änderungskontrolle 

Version Datum Ausführende Stelle Bemerkungen/Art der Änderung 

2.3 11.06.2002 Marco Zbinden Ergänzungen der Punkte 0 und 9.2.1. 

Endfassung 

2.2 09.06.2002 Marco Zbinden Versionen zusammenführen - Endfassung 

2.1 08.06.2002 Hugo Graf Neu Aktivitätszustand und Korrektur 

Prozesszustand 

2.0 06.06.2002 Marco Zbinden Endgültige Fassung 

1.2 03.06.2002 Marco Zbinden Korrigierte Fassung 

1.1 01.06.2002 Hugo Graf & 

Marco Zbinden 

Korrekturen einbringen gem. Sitzungsprotokoll 

vom 29. Mai 2002 

1.0 28.05.2002 Hugo Graf Entwurf für Pflichtenheft-Sitzung 

0.2a 19.05.2002 Marco Zbinden Hermes Ausrichtung ➜ wird fallengelassen 

0.2 19.05.2002 Hugo Graf 2. Entwurf 

0.1 17.05.2002 Hugo Graf 1. Entwurf 

©Pflichtenheft.doc 06.01.2003 – Version: 2.3 Seite 1

Pflichtenheft - FlowWorkJ Inhaltsverzeichnis 

Inhaltsverzeichnis 

1 Abkürzungen..............................................................................................................................4 

2 Zielbestimmung .........................................................................................................................5 

2.1 Themenvorschlag für eine Diplomarbeit ...................................................................................5 

2.2 Leistung für den Benutzer.........................................................................................................5 

2.3 Schwerpunkte im Anforderungskatalog ....................................................................................5 

2.3.1 Definition Workflow und Workflow-Engine .............................................................................5 

2.3.2 Workflow-Beispiel...................................................................................................................5 

2.3.3 Anmerkungen .........................................................................................................................6 

2.3.3.1 Befolgung von Standards ....................................................................................................6 

3 Produkteinsatz...........................................................................................................................7 

3.1 Anwendungsdiagramm .............................................................................................................7 

3.2 Software....................................................................................................................................7 

3.3 Hardware...................................................................................................................................8 

4 Begriffe der «Workflow-Welt» ..................................................................................................9 

4.1 Aktivitäten..................................................................................................................................9 

4.2 Applikationen.............................................................................................................................9 

4.3 Build Time .................................................................................................................................9 

4.4 Daten.........................................................................................................................................9 

4.5 Datenfluss .................................................................................................................................9 

4.6 Ressourcen...............................................................................................................................9 

4.7 Run Time.................................................................................................................................10 

4.8 Transitionen ............................................................................................................................10 

5 Standard ...................................................................................................................................11 

5.1 Das Referenzmodell der WfMC ..............................................................................................11 

5.1.1 Workflow Enactment Service ...............................................................................................11 

5.1.2 Process Definition (Schnittstelle 1).......................................................................................11 

5.1.3 Workflow Client Applications (Schnittstelle 2) ......................................................................12 

5.1.4 Invoked Applications (Schnittstelle 3) ..................................................................................12 

5.1.5 Other Workflow Enactment Service(s) (Schnittstelle 4) .......................................................12 

5.1.6 Administration & Monitoring Tools (Schnittstelle 5)..............................................................12 

6 Mögliche Formen von WFMS .................................................................................................13 

6.1 Ad-hoc Workflow.....................................................................................................................13 

6.2 Flexibler Workflow...................................................................................................................13 

6.3 Produktions-Workflow .............................................................................................................13 

7 Konstrukte des Workflow-Modells ........................................................................................14 

7.1 Kontrollknoten .........................................................................................................................14 

7.1.1 Beispiel eines Workflows......................................................................................................14 

7.1.2 Start ......................................................................................................................................14 

7.1.3 Split und Join-Knoten ...........................................................................................................15 

7.1.4 Wiederholte Ausführung (Schleife).......................................................................................15 

7.2 Organisationsmodell ...............................................................................................................16 

7.2.1 Rollen ...................................................................................................................................16 

7.2.2 Basis FlowWorkJ-Rollen ......................................................................................................16 

7.2.2.1 Administrator......................................................................................................................17 

7.2.2.2 Prozessersteller .................................................................................................................17 

7.2.2.3 Instanzbesiter.....................................................................................................................17 

7.2.2.4 Worker ...............................................................................................................................17 

7.3 Aktivitäten................................................................................................................................17 

7.3.1 Sub-Workflow .......................................................................................................................17 


Pflichtenheft - FlowWorkJ Inhaltsverzeichnis 

7.3.2 Automatisierte Aktivität.........................................................................................................17 

7.3.3 Manuelle Aktivität .................................................................................................................17 

7.4 Transitionen ............................................................................................................................18 

7.4.1 Transitionsbedingung ...........................................................................................................18 

7.4.1.1 Normale Transitionen.........................................................................................................18 

7.4.1.2 Synchronisations-Transitionen ..........................................................................................18 

8 Anwendungsfälle.....................................................................................................................19 

8.1 Personen und Rollen verwalten (A1) ......................................................................................19 

8.1.1 Zielsetzung ...........................................................................................................................19 

8.1.2 Akteure .................................................................................................................................19 

8.1.3 Vorbedingung .......................................................................................................................19 

8.1.4 Normaler Ablauf....................................................................................................................20 

8.2 Prozess definieren (A2) ..........................................................................................................20 

8.2.1 Zielsetzung ...........................................................................................................................20 

8.2.2 Akteure .................................................................................................................................20 

8.2.3 Vorbedingung .......................................................................................................................20 

8.2.4 Nachbedingung ....................................................................................................................20 


8.2.6 Ausnahme (b).......................................................................................................................21 

8.2.7 Alternativen...........................................................................................................................21 

8.3 Automatisierte Aktivitäten erstellen (A3).................................................................................21 

8.3.1 Zielsetzung ...........................................................................................................................21 

8.3.2 Akteure .................................................................................................................................21 

8.3.3 Vorbedingung .......................................................................................................................21 

8.3.4 Nachbedingung ....................................................................................................................21 


8.3.6 Ausnahme (b).......................................................................................................................22 

8.4 Manuelle Aktivität ausführen (A4)...........................................................................................22 

8.4.1 Zielsetzung ...........................................................................................................................22 

8.4.2 Akteure .................................................................................................................................22 

8.4.3 Vorbedingung .......................................................................................................................22 


8.4.5 Alternative (a) .......................................................................................................................22 

8.4.6 Alternative (c) .......................................................................................................................22 

8.4.7 Ausnahme (c) .......................................................................................................................22 

8.4.8 Implementierung...................................................................................................................22 

8.4.8.1 GUI.....................................................................................................................................22 

8.5 Instanz überwachen und steuern (A5)....................................................................................23 

8.5.1 Zielsetzung ...........................................................................................................................23 

8.5.2 Akteure .................................................................................................................................23 

8.5.3 Vorbedingung .......................................................................................................................23 


8.5.5 Implementierung...................................................................................................................23 

8.5.5.1 Prozesszustand .................................................................................................................23 

8.5.5.2 Aktivitätszustand................................................................................................................24 

9 Abnahmekriterien ....................................................................................................................25 

9.1 Funktionale Anforderungen.....................................................................................................25 

9.2 Qualitätszielbestimmungen.....................................................................................................26 

9.2.1 Definition der Qualitätszielbestimmungskriterien .................................................................26 

9.3 Abgrenzung.............................................................................................................................26 

10 Glossar .....................................................................................................................................28 

11 Abbildungsverzeichnis ...........................................................................................................31 


Pflichtenheft - FlowWorkJ Kapitel: 1 Abkürzungen 

1 Abkürzungen 

DBMS Data Base Management System 

DTD Dokumenttyp-Definition 

GUI Grafical User Interface 

JMS Java Messaging Service 

OMG Object Management Group, Arbeitsgruppe für Konzepte zur Verwaltung von Objekten 

SOAP Simple Object Access Protocol 

UML Unified Modeling Language 

WfMC Workflow Management Coalition 

WFMS Workflow Management Systems 

XML eXtensible Markup Language 

XPDL XML Processing Description Language 


Pflichtenheft - FlowWorkJ Kapitel: 2 Zielbestimmung 

2 Zielbestimmung 

2.1 Themenvorschlag für eine Diplomarbeit 

Titel: Framework für Internet-basierte Workflow-Lösungen 

Bearbeiter: Hugo Graf & Marco Zbinden 

Betreuer: Rolf Jufer & Hoang-Van Chau 

Experte: Jean-Jacques Jaquier 

Umfeld: Bis vor kurzem war für die Ausführung von Workflows häufig ein «proprietärer» Client notwendig 

(einen solchen werden Sie im Rahmen des weiteren I&O Unterrichts noch kennen lernen). 

Erst in jüngerer Zeit ist es möglich, solche Workflows auch mit Hilfe von Web-Browsern auszuführen. 

Aufgabenstellung & Zielsetzung: 

1. Entwicklung eines Frameworks, welches als Basis für die Realisierung von (einfachen) Intranetbasierten 

Workflows dienen soll. 

2. Im Sinne eines «Proof-of-Concept» soll auf der Grundlage dieses Frameworks eine einfache 

Workflow-Lösung «Auftragsabwicklung bei ProLux (siehe Fallbeispiel im I&O-Unterricht)» realisiert 

werden, welche später für Unterrichtszwecke benutzt werden kann. 

Lerninhalte: Wirtschaftsinformatik, E-Business, Workflow-Management 

Hardware & Software: Java Servlets, JSP, Java Beans, J2EE, SQL-DB, XML 

Aufgabensteller: Rolf Jufer 

Bemerkungen: 

Die Aufgabe kann jederzeit nach Absprache mit den Betreuern erweitert oder eingeschränkt werden. 

2.2 Leistung für den Benutzer 

Der Benutzer erhält mit FlowWorkJ die Möglichkeit Geschäftprozesse als Workflow abzubilden. An 

den Instanzen dieser Prozesse kann er entsprechend seiner Rolle aktiv teilnehmen, zudem kann er 

die einzelnen Prozesse beobachten und steuernd eingreifen. 

2.3 Schwerpunkte im Anforderungskatalog 

2.3.1 Definition Workflow und Workflow-Engine 

Zurzeit ist wohl die Java 2 Enterprise Edition die momentan erfolgreichste Komponentenarchitektur für 

verteilte Transaktionen. Daher bietet es sich an, die Workflow Engine für diese Umgebung zu konzipieren. 

1. Modellierung von Geschäftsprozessen mittels XML 

2. Eine Ablaufumgebung für die modellierten Prozesse 

3. Eine Administrationsumgebung und Monitoringwerkzeug für das gesamte Workflow System 

2.3.2 Workflow-Beispiel 

Folgende Applikationsintegrationen werden implementiert und mit dem Workflow-Beispiel überprüfbar 

gemacht. 

• Web Service mit SOAP 


Pflichtenheft - FlowWorkJ Kapitel: 2 Zielbestimmung 

• Java Server Pages 

• Session Bean 

Die oben genannten Applikationstypen können Ein- und Ausgabedaten haben. 

2.3.3 Anmerkungen 

Der in der Aufgabenstellung formulierte Auftrag präsentiert sich sehr offen und lässt uns sehr viel 

Spielraum. Wir haben uns daher einige zusätzliche Überlegungen gemacht. 

2.3.3.1 Befolgung von Standards 

Da die Implementierung des Prozessdefinitions-Werkzeuges nicht zu den Anforderungen gehört, stellt 

sich uns die Frage, ob wir die Standards der WfMC umsetzen wollen, wobei damit vorwiegend die 

XML Process Definition Language gemeint ist. Dies hätte den Vorteil, dass eine weitere Diplomarbeit 

die grafische Prozessdefinition zum Inhalt haben könnte und sich diese auf eine Standardschnittstelle 

abstützen könnte. Anderseits betrachten wir zu diesem Zeitpunkt die manuelle Erstellung einer Prozessdefinition 

durch den Benutzer im XML-Format gemäss den XPDL-Schema als eher zeitaufwändig 

und schwierig. 

©Pflichtenheft.doc 06.01.2003 – Version: 2.3 

Seite 6

Pflichtenheft - FlowWorkJ Kapitel: 3 Produkteinsatz 

3 Produkteinsatz 

3.1 Anwendungsdiagramm 

In der Abbildung 1 sind nur die Komponenten aufgeführt, welche für die Ausführung von FlowWorkJ 

notwendig sind, das heisst die Komponenten von externen Applikationen und Datenbanken sind nicht 

aufgeführt. 

Worker-PC 

Internet Browser 

J2EE Applikation-PC 

Notification Daemon 

J2EE-Appliaktion Server 

Web Container 

EJB Container 

Abbildung 1: Einsatzdiagramm von FlowWorkJ 

3.2 Software 

DTD oder Schema für 

Prozessdefinition 

XML-Prozessdefinition 

Dieses Werkzeug 

gehöhrt nicht zum 

Lieferumfang von 


FlowWorkJ-DBMS 

Prozessersteller-PC 

Autoren-XML/DTD/Schema- 

Werkzeug 

FlowWorkJ-Deployment 

Werkzeug 

Java Applikation 

Instanzbesitzer/Administrator-PC 


Administrations / 

Monitoring-Werkzeug 

Benutzte Java-Frameworks werden hier nicht aufgeführt. Es werden nur Open Source-Produkte verwendet. 

Als Betriebsystem wird sicherlich Windows NT/2000 unterstützt. 

FlowWorkJ DBMS Eine frei verfügbare Datenbank wie zum Beispiel MySQL, Interbase usw. 

Java JDK 1.3.x 

Internet Browser Internet Explorer 5.0 

Notification Daemon Dieser Daemon wird benutzt, um zum Beispiel die Worker bei Terminüberschreitungen 

mittels E-Mail zu informieren. Dabei werden die Soll- und Ist- 

Termine periodisch verglichen. 

Web Container Tomcat 4.X 

EJB Container JBoss – Der EJB Container muss den EJB 2.0 Standard bezüglich JMS und 

Message Driven Beans implementiert haben. Falls parallele, automatische 


Pflichtenheft - FlowWorkJ Kapitel: 3 Produkteinsatz 

3.3 Hardware 

Aktivitäten durchgeführt werden, muss eine Parallelität in EBJ Container 

stattfinden können. Diese lässt sich mit JMS und Message Driven Beans 

realisieren. 

An die Hardware werden keine speziellen Anforderungen gestellt. 


Seite 8

Pflichtenheft - FlowWorkJ Kapitel: 4 Begriffe der «Workflow-Welt» 

4 Begriffe der «Workflow-Welt» 

4.1 Aktivitäten 

Aktivitäten sind die atomaren Arbeitseinheiten innerhalb eines Prozesses. Für jede Aktivität wird eine 

verantwortliche Ressource festgelegt. Eine Aktivität kann sein: 

• eine «manuell» ausgeführte Tätigkeit 

• ein ausgeführtes Programm 

• ein (Unter-) Prozess 

• eine Schleife 

4.2 Applikationen 

Applikationen werden in Aktivitäten aufgerufen, wobei eine Applikation von mehreren Aktivitäten aufgerufen 

werden kann. Die Eingangs- und Ausgangsparameter der Applikation müssen aus den Daten 

des Prozesses bestimmt werden. 

4.3 Build Time 

In der Buildtime-Umgebung des Workflow System wird die automatisierte Abarbeitung der Arbeitsabläufe 

vorbereitet. Ein zentraler Aspekt ist dabei die Transformation eines realen Arbeitsablaufs in eine 

computerbasierte Darstellung, die Workflow-Definition genannt wird. 

Eine Workflow-Definition enthält eine formale, vom Computer abarbeitbare Darstellung der Beschreibung 

einer Anzahl von einzelnen Aktivitäten mit den zugehörigen automatischen und/oder manuellen 

Operationen, sowie Regeln, die den Ablauf der Abarbeitung der einzelnen Aktivitäten steuern. 

4.4 Daten 

Unter Daten verstehen wir die durch die Aktivitäten eines Prozesses bearbeiteten Geschäftsdaten 

sowie Steuerdaten des Prozesses. Sie können vom primitiven Typ (Integer, String) sein oder vom Typ 

einer Referenz auf komplexere Daten. 

4.5 Datenfluss 

Für die Ausführung einzelner Aktivitäten werden meist Eingabedaten benötigt, die diese verarbeiten 

und daraus resultierende Ausgabedaten bereitstellen. Diese Ausgabedaten können wiederum als 

Eingabedaten einer späteren Aktivität dienen, welche jedoch nicht unbedingt die im Kontrollfluss direkt 

folgende Aktivität sein muss. Dieser Zusammenhang von Ausgabe- und Eingabedaten verschiedener 

Aktivitäten wird als Datenfluss bezeichnet und grafisch durch eine zweite Art von Kanten dargestellt, 

Datenflusskanten genannt. Der Datenfluss zwischen Aktivitäten wird als interner Datenfluss bezeichnet. 

Ausserdem können am Datenfluss externe Datenquellen wie zum Beispiel Datenbanken beteiligt 

sein, die Ausgangsdaten für Aktivitäten bereitstellen bzw. in denen Endergebnisse zur späteren Verwendung 

abgelegt werden. Dieser Datenfluss wird entsprechend externer Datenfluss genannt. 

4.6 Ressourcen 

Diese führen Aktivitäten aus und können sein: 

• Worker 

• Geräte 


Pflichtenheft - FlowWorkJ Kapitel: 4 Begriffe der «Workflow-Welt» 

• Gruppen von Ressourcen 

Diese Workflowbegriffe sind bei der WfMC standardisiert und damit nicht proprietär. Verwendet man 

diese Begriffe für die Beschreibung von Geschäftsprozessen, können leicht Schätzmodelle für Entwicklungsprojekte 

entwickelt werden. Ausserdem können Aktivitäten als Einstiegspunkt für 

Komponenten dienen, so dass die Aktivität ein Arbeitsschritt einer Komponente sein kann. Dabei 

können eben auch die verwendeten Applikationen integriert und so transparent für den Benutzer 

aufgerufen werden. 

4.7 Run Time 

Die Funktionalität der Run Time bildet die Verbindung zwischen der modellierten Workflow-Definition 

und dem real ausgeführten Arbeitsablauf. Die Workflow Engine führt die Workflow-Definitionen aus, 

indem sie Instanzen von diesen erzeugt, den Inhalt der Workflow-Definitionen interpretiert und entsprechend 

der Beschreibung der Aktivitäten bestimmte Aktionen durchführt. Die Workflow-Engine ist 

damit die zentrale Komponente der Runtime-Umgebung. Die einzelnen Aktivitäten in einem Workflow 

sind meist mit Benutzer-Interaktionen verbunden, oft in Zusammenhang mit der Verwendung einer 

bestimmten Applikation, zum Beispiel zum Ausfüllen eines Formulars. Eine solche Applikation kann 

vom Workflow-System gestartet und gesteuert werden. 

4.8 Transitionen 

Transitionen beschreiben Übergänge zwischen den Aktivitäten. Jede Transition trägt eine Bedingung 

für die Daten des Prozesses. Ist die Bedingung – von der die Transition ausgeht – nach Ausführung 

der Aktivität erfüllt, so wird die Transition durchlaufen. 


Seite 10

Pflichtenheft - FlowWorkJ Kapitel: 5 Standard 

5 Standard 

Es ist wichtig, das Referenzmodell der WfMC zu verstehen, da sich einige Anforderungen nach diesem 

Modell richten. 

5.1 Das Referenzmodell der WfMC 

Die WfMC ist ein Industriestandardisierungsgremium – vergleichbar mit der OMG – mit dem Unterschied, 

dass der Fokus rein auf Standards für Workflow-Managementsystem gerichtet ist. 

Abbildung 2: Referenzmodell der WfMC 

5.1.1 Workflow Enactment Service 

• Ist die Softwarekomponente, welche die Laufzeitunterstützung für die Ausführung zur Verfügung 

stellt 

• Generiert aus den Prozessdefinition Instanzen und arbeitet diese ab (Kreation, Aktivierung, Anhalten, 

Beenden usw.) 

• Ist ein Interface, um Benutzer-Interaktionen zu unterstützen 

• Ermöglicht Austausch-relevanter Daten zwischen Benutzer und Anwendung 

5.1.2 Process Definition (Schnittstelle 1) 

Eine Vielzahl von Werkzeugen kann zu Hilfe genommen werden, um Geschäftsvorgänge zu analysieren, 

zu modellieren und zu beschreiben. Das WfMC-Referenzmodell schreibt nicht vor, wie diese 

Werkzeuge zu arbeiten haben. Stattdessen beinhaltet es eine Import/Export-Schnittstelle für die Definitionen 

von Geschäftsvorgängen. Das gemeinsame Austauschformat bietet folgende Arten von Informationen 

an: 


Pflichtenheft - FlowWorkJ Kapitel: 5 Standard 

• Bedingungen für das Starten und Beenden von Prozessen 

• Identifizierung von Aktivitäten innerhalb eines Prozesses, einschliesslich dazugehöriger Applikationen 

und vorgangsrelevanter Daten 

• Identifizierung von Datentypen und Zugriffspfaden 

• Definition von Übergangsbedingungen und Flussregeln 

• Informationen zu Entscheidungen über Ressourcen-Belegungen 

5.1.3 Workflow Client Applications (Schnittstelle 2) 

• Zusammenarbeit mit den Anwendern 

• Aktivierung spezieller Applikationen 

• Liste aller Arbeitsschritte und der zugehörigen Benutzer 

5.1.4 Invoked Applications (Schnittstelle 3) 

Interaktionsunabhängige Applikationen stellen spezielle Programme dar, die von WFMS direkt aktiviert 

werden können, um eine Aktion auszulösen. Im Gegensatz zur Anwendung von Klientenbenutzerapplikationen 

werden diese Aktionen ohne Benutzereingaben durchgeführt. 

5.1.5 Other Workflow Enactment Service(s) (Schnittstelle 4) 

Ein Hauptanliegen der WFMC ist es, Standards zu definieren, die es Workflow Enactment Services 

unterschiedlicher Hersteller ermöglichen sollen, untereinander Arbeitsteile weiterzugeben. Verschiedene 

Workflow Enactment Services unterscheiden sich unter anderem in ihrem Detaillierungsgrad 

bezüglich der Geschäftsvorgänge. Während das eine Produkt nur Aufgaben oder Daten weiterleitet, 

ist ein anderes auf genau geregelte Produktionsabläufe ausgelegt. Um zu vermeiden, dass sich 

WFMS-Produktanbieter zwischen Interoperabilitätstandards oder einem hohen Detaillierungsgrad 

entscheiden müssen, werden mehrere Ausbaustufen für den Standard entwickelt. Interoperabilität 

kann auf verschieden Levels realisiert werden: Von einfacher Aufgabenweiterleitung bis hin zu WFMS 

mit vollständigem Austausch von Vorgangsbeschreibungen, vorgangsrelevanten Daten und gemeinsamem 

Look and Feel. 

5.1.6 Administration & Monitoring Tools (Schnittstelle 5) 

• Werkzeug für das Monitoring: Zustand/Auslastung der laufenden Instanzen 

• Protokollierung zur nachträglichen Fehlererkennung und Auswertung 

• Tools zur Benutzerverwaltung 

• Tuning-Tools: Anpassung technischer Parameter 


Seite 12

Pflichtenheft - FlowWorkJ Kapitel: 6 Mögliche Formen von WFMS 

6 Mögliche Formen von WFMS 

6.1 Ad-hoc Workflow 

Ad-hoc Workflow ist durch blosse Verwendung von E-Mail-Systemen gegeben. Es werden Mitteilungen 

verschickt. Weitere Abarbeitungsregeln können nicht abgeleitet werden. 

6.2 Flexibler Workflow 

Unter Flexiblem Workflow versteht man das Erstellen einer Prozessdefinition vor der Ausführung, aber 

mit der Möglichkeit, die Prozesse und ihre Modelle während der Ausführung zu modifizieren. 

6.3 Produktions-Workflow 

Produktions-Workflow beinhaltet das Erstellen von vordefinierten Prozessen mit relativ strenger Ausdruckskraft. 

Die Prozess-Modelle können nur als Ganzes verändert werden. Einzelne laufende Prozesse 

sind nicht modifizierbar. Diese Definition entspricht dem klassischen Workflow-Konzept. 


Pflichtenheft - FlowWorkJ Kapitel: 7 Konstrukte des Workflow-Modells 

7 Konstrukte des Workflow-Modells 

Im Folgenden wird ein Workflow-Modell beschrieben. Aufgrund dieses Modells wird ein Teil der Abnahmekriterien 

erstellt. 

7.1 Kontrollknoten 

Mittels Kontrollknoten kann der Ablauf des Kontrollflusses gesteuert werden. 

7.1.1 Beispiel eines Workflows 

Der folgende Prozess ist ein Aktivitäts-Diagramm der UML Notation; natürlich ist dieser nicht vollständig, 

da einige Konstrukte in diesem Diagrammtyp fehlen. 

[Eilbestellung] 

Express- 

Lieferung 

Auftragsbearbeitung Kundenbetreung Buchhaltung 

Bestellung 

bearbeiten 

{Or-Split} auf 

den 

Transitionen 

{And-Split} 

[sonst] 

Normale 

Lieferung 

{Or-Join} 

Abbildung 3: Beispielprozess mit Join- und Splitknoten 

7.1.2 Start 

Bestellung 

entgegennehmen 

Rechnung 

ausstellen 

{And-Join} 

Bestellung 

abschliessen 

Startknoten 

Zahlung 

verbuchen 

Jede Workflow-Definition enthält genau einen Startknoten. Ein Endknoten muss nicht explizit definiert 

werden. Der Start einer Workflow-Instanz kann ausgelöst werden: 

• Durch ein externes Ereignis, wie zum Beispiel durch eine einkommende E-Mail 

• Manuell durch den Worker oder Instanzbesitzer 

• Zeitgesteuert 



7.1.3 Split und Join-Knoten 

Split-Knoten ermöglichen die Verzweigung des Kontrollflusses in mehrere parallel ablaufende Pfade. 

Ausserdem kann durch die Angabe von Bedingungen an den ausgehenden Transitionen des Split- 

Knotens festgelegt werden, unter welchen Bedingungen der folgende Pfad abgearbeitet werden soll. 

Jeder Split-Knoten hat als Gegenstück genau einen Join-Knoten. Dieser vereinigt die parallel einlaufenden 

Kontrollpfade zu einem ausgehenden Kontrollpfad. 

Es können zwei Arten von Split-Knoten verwendet werden: 

• And-Split: Die ausgehenden Transitionen haben keine Bedingungen, es werden also immer alle 

ausgehenden Kontrollpfade abgearbeitet. 

• Or-Split: Die ausgehenden Transitionen haben (bis auf eine) Bedingungen, sie werden jeweils 

genau dann aktiviert, wenn die Bedingung erfüllt ist. Genau eine der ausgehenden Transitionen 

hat keine Bedingung, dies ist die sogenannte Default-Transition. Sie wird dann aktiviert, wenn keine 

der anderen Transitionen aktiviert wird. Damit ist sichergestellt, dass mindestens eine ausgehende 

Transition des Or-Splits aktiviert wird, es können aber auch mehrere aktiviert werden. 

Für Join-Knoten stehen drei verschiedene Typen zur Verfügung: 

• And-Join: Die ausgehende Transition des Join-Knotens wird aktiviert, wenn alle eingehenden 

Transitionen aktiviert sind. Wenn der zugehörige Split ein Or-Split ist, dann werden nur die eingehenden 

Transitionen berücksichtigt, deren Kontrollpfade tatsächlich abgearbeitet werden. 

• Or-Join: Die ausgehende Transition des Join-Knotens wird aktiviert, wenn eine der eingehenden 

Transitionen aktiviert wird. Die Kontrollpfade aller anderen eingehenden Transitionen werden weiter 

abgearbeitet. 

• XOr-Join: Die ausgehende Transition des Join-Knotens wird aktiviert, wenn eine der eingehenden 

Transitionen aktiviert wird. Die Abarbeitung der Kontrollpfade aller anderen eingehenden Transitionen 

wird abgebrochen. 

7.1.4 Wiederholte Ausführung (Schleife) 

Mittels Loop-Start- und Loop-Ende-Knoten kann die wiederholte Ausführung bestimmter Abschnitte 

des Kontrollflusses festgelegt werden. 

Aktivität 1 

Loop-Start 

Abbildung 4: Wiederholte Ausführung 

[Bedingung] 

A B Aktivität 4 

Loop-Ende 

Vom Loop-End-Knoten führt eine Transition zurück zum Loop-Start-Knoten, diese wird als Loop- 

Transition bezeichnet. Die Loop-Transition besitzt immer eine wertebasierte Bedingung. Solange diese 

Bedingung wahr ist, wird die Schleife erneut abgearbeitet. Erst wenn diese Bedingung falsch ist, 

wird die ausgehende Transition des Loop End-Knotens aktiviert und damit der folgende Kontrollfluss 

abgearbeitet. 



7.2 Organisationsmodell 

Das Organisationsmodell beruht auf Personen und Rollen. Jedem Aktivitätsknoten wird während der 

Modellierungsphase eine Rolle zugewiesen, die für ihre Ausführung verantwortlich ist. Mit dem Administratorenwerkzeug 

erfolgt die konkrete Zuordnung von Person zu Rolle. 

7.2.1 Rollen 

Jede Person hat eine bestimme Beziehung zu einer Rolle, eine Person kann jedoch auch mehrere 

Rollen haben. 

7.2.2 Basis FlowWorkJ-Rollen 

Zusätzlich definiert FlowWorkJ Basisrollen, welche die Zugriffsrechte zu den einzelnen FlowWorkJ- 

Modulen regelt. 

Adminstrator 

Worker 

Instanzbesitzer 

Prozessersteller 

Abbildung 5: Rollen in FlowWorkJ 

Manuelle Aktivität 

ausführen 


Personen und Rollen 

verwalten 

Prozess definieren 

 

Automatisierte Aktivität 

erstellen 

Instanz überwachen und 

steuern 



7.2.2.1 Administrator 

Die Rollen und Benutzer werden durch diese Rolle verwaltet. 

7.2.2.2 Prozessersteller 

Der Prozessersteller übersetzt das Geschäftsablaufmodell in einen Workflow-Modul-Prozess. Diese 

Rolle ist der «Besitzer» der Prozessdefinition. Nur der Besitzer hat die Berechtigung, die Prozessdefinition 

zu ändern oder zu löschen. Zusätzlich besorgt diese Rolle die Integration von Applikationen. 

7.2.2.3 Instanzbesiter 

Der Instanzbesitzer überwacht und steuert die Instanzen seiner Prozesse. Weiter kann er Prozesse 

erzeugen oder abbrechen. 

7.2.2.4 Worker 

Jeder Benutzer von FlowWorkJ ist zugleich Worker. Der Worker ist die allgemeinste Klasse von Teilnehmern 

an einem Workflow-Prozess. Diese Rolle charakterisiert die Person, die während der Erledigung 

täglicher Aufgaben mit dem WFMS arbeitet. 

7.3 Aktivitäten 

Wir unterscheiden zwischen komplexen und einfachen Aktivitätsdefinitionen. Ein Sub-Workflow ist 

eine komplexe Aktivität. 

7.3.1 Sub-Workflow 

Eine komplexe Aktivitätsdefinition beinhaltet eine komplette (Sub-)Workflow-Definition, die ausgeführt 

wird, wenn der zugehörige Aktivitätsknoten aktiviert wird. Nachdem ein Sub-Workflow vollständig abgearbeitet 

ist, wird auch der zur Aktivitätsdefinition gehörige Aktivitätsknoten als beendet angesehen. 

Ein Sub-Workflow-Definition kann ihrerseits wieder Aktivitätsknoten mit komplexen Aktivitätsdefinitionen 

enthalten, so dass eine mehrfache Verschachtelung möglich ist. 

7.3.2 Automatisierte Aktivität 

Applikationen werden jeweils einer einfachen Aktivitätsdefinition zugeordnet. Diese Applikationen 

werden zur Runtime dann durch die Workflow Engine über den Applikation Server gestartet und mit 

ihren Eingabe-Objekten versorgt. Die Workflow Engine nimmt dann auch die Ausgabeobjekte der 

Applikationen wieder entgegen. Nach erfolgreicher Beendigung der Applikation wird die Aktivität als 

abgeschlossen angesehen. 

7.3.3 Manuelle Aktivität 

Bei manuellen Aktivitäten wird der Benutzer darüber informiert, dass eine Aktivität auszuführen ist, es 

kann eine rein manuelle oder eine teilweise vom Computer unterstützte Aktivität sein. 



7.4 Transitionen 

7.4.1 Transitionsbedingung 

7.4.1.1 Normale Transitionen 

Transitionen legen fest, welche Knoten zu einem Kontrollpfad gehören. Ihnen können zwei Arten von 

Bedingungen zugeordnet werden: 

• Temporale Bedingungen: Beinhalten zeitliche Bedingungen, wie eine minimale Wartezeit oder 

maximale Wartezeit zwischen zwei Aktivitäten. 

• Wertebasierte Bedingungen: Beinhalten Bedingungen, die sich auf die Werte von Objekten aus 

dem Objektfluss beziehen. Diese Art von Bedingungen ist nur bei Or-Split-Knoten oder wiederholter 

Ausführung zulässig. 

7.4.1.2 Synchronisations-Transitionen 

Synchronisations-Transitionen legen fest, dass parallel liegende Knoten in einer bestimmten Reihenfolge 

abzuarbeiten sind. Dies ist in Abbildung 6 dargestellt. Synchronisations-Transitionen sind nur 

zwischen parallel liegenden Knoten zulässig, das heisst wenn die Reihenfolge der Abarbeitung der 

Knoten nicht durch normale Transitionen eindeutig definiert ist, wie dies in Split-Join-Regionen der Fall 

ist. Ausserdem darf weder der Quell- noch der Ziel-Knoten ein Start- oder End-Knoten sein und er darf 

nicht in einer Schleife liegen. 

Abbildung 6: Transitionen 

Split 

A 

C 

Synchronisations Transition 

©Pflichtenheft.doc 06.01.2003 – Version: 2.3 Seite 18 

B 

D 

Join

Pflichtenheft - FlowWorkJ Kapitel: 8 Anwendungsfälle 

8 Anwendungsfälle 

Da sowohl dem Auftraggeber wie auch dem Auftragnehmer die Grundprinzipien von Anwendungsfällen 

bekannt sind, verzichten wir hier auf eine Prosabeschreibung von Szenarien. Anwendungsfälle 

sind Abstraktionen von Szenarien, das heisst ähnliche Szenarien werden zusammengefasst und deren 

Gemeinsamkeiten ausgearbeitet. 

Im folgenden werden die Anwendungsfälle von Abbildung 5: Rollen in FlowWorkJ wiedergeben. 

8.1 Personen und Rollen verwalten (A1) 

8.1.1 Zielsetzung 

Personen und Rollen können erfasst, gelöscht und miteinander verknüpft werden. Zum Beispiel lässt 

sich eine wie in Abbildung 7: Personen und Rollen dargestellte Organisation in FlowWorkJ abbilden, 

wobei keine Relation zwischen den Rollen erfasst wird, das heisst in diesem Beispiel hat die Fertigung 

1 keine Relation zur Produktion. 

Person4 

Person1 

Abbildung 7: Personen und Rollen 

Produktion Marketing 

Anlagen Fertigung 1 

Person6 

Person3 

(UML-Kenner mögen uns entschuldigen für dieses Diagramm) 

Person5 

Unternehmensleitung 

Person2 

Fertigung 2 

• Die Rollen und Personen werden erfasst, dabei kann eine Person 0..n Rollen (maximale Anzahl 

Rollen) und eine Rolle 0..n Personen (maximale Anzahl Personen) haben. 

• Personen oder Rollen können gelöscht werden, falls dies die referenzielle Integrität erlaubt. 

8.1.2 Akteure 

Administrator 

8.1.3 Vorbedingung 

• Der Administrator hat sich erfolgreich am FlowWorkJ Administratoren/Monitoring Werkzeug angemeldet. 



8.1.4 Normaler Ablauf 

Dieser Anwendungsfall wird während der Analysephase verfeinert. 

8.2 Prozess definieren (A2) 


Der Prozesserstellter definiert den Geschäftsprozess mittels XML und führt das Deployment dieser 

XML-Prozessdefinition durch. 

Rolle 

0..1 

hat 

0..* hat 

Transitions Bedinung 

Abbildung 8: Elementares Metamodell 

1..* 

hat 

Prozessdefinition 

1..* besteht aus 

Aktivitaet 

1 hat 

0..1 hat 

Applikation 

Workflow relevante Daten 

Dynamische Daten, wie z.B. 

Personen-/Rollenzuordnung, Ein 

und Ausgabedaten von Applikat 

Dabei besteht die XML-Prozessdefinition wie in Abbildung 8: Elementares Metamodell dargestellt aus 

Aktivitäten, Rollen, usw. 

8.2.2 Akteure 



• Der Prozessersteller hat eine konkrete Vorstellung des Geschäftprozesses und kennt XML. 

• Die Organisation ist in der FlowWorkJ-DBMS definiert, damit die Personen-/Rollenzuordnung 

funktioniert. 

• Der Prozesshersteller ist als Prozessersteller in der FlowWorkJ-DBMS eingetragen. 

• Der Prozess hat eine eindeutige Kennung. 

8.2.4 Nachbedingung 

Das Deployment war erfolgreich und Instanzen von diesem Prozess können gebildet werden. 


Seite 20



a. Der Prozessersteller setzt den Geschäftprozess in eine XML-Prozessdefinition um. Dabei wird er 

durch DTD oder XML-Schema untertstützt. 

b. Der Prozessersteller führt das Deployment der XML-Prozessdefinition mittels dem FlowWorkJ- 

Deployment-Werkzeug in die FlowWorkJ-DBMS durch, dabei bestimmt er den Instanzbesitzer. 

8.2.6 Ausnahme (b) 

1) Beim Deployment treten semantische Fehler auf wie zum Beispiel: 

• Die Rollenzuordnung ist fehlgeschlagen. 

8.2.7 Alternativen 

1) Der Prozess wird in der FlowWorkJ-DBMS gelöscht bzw. als zu löschen markiert. 

8.3 Automatisierte Aktivitäten erstellen (A3) 


FlowWorkJ hat Schnittstellen zu verschiedenen Technologien, welche die Integration von computerunterstützten 

Aktivitäten erlauben, dabei kann mit Ein- und Ausgabedaten gearbeitet werden. 

Der Prozessersteller programmiert Session Beans, Java Server Pages und Web Services, dabei wird 

durch Open Source- und/oder FlowWorkJ Framework/s unterstützt. Diese automatisierten Aktivitäten 

werden in der XML-Prozessdefintion bekannt gemacht und auf den J2EE Application Server deployed. 

8.3.2 Akteure 



• Der Prozessersteller kennt die Grundlagen von Session Bean, Java Server Pages und Web Services 

mit SOAP. 

• Der Prozessersteller kennt das Deployment-Verfahren seines Applikationsservers. 

• Der Prozessersteller ist als Prozessersteller in der FlowWorkJ-DBMS eingetragen. 

8.3.4 Nachbedingung 

Das Deployment ist erfolgreich und Instanzen von diesem Prozess können gebildet werden. 


a. Der Prozessersteller programmiert die computerunterstützten Aktivitäten. 

b. Der Prozessersteller führt das Deployment der computerunterstützten Aktivitäten auf dem Applikationsserver 

durch. 

c. In der XML-Prozessdefinition werden die Schnittstellen definiert. 



8.3.6 Ausnahme (b) 

1) Das Deployment auf dem Applikationsserver ist fehlgeschlagen. 

8.4 Manuelle Aktivität ausführen (A4) 


Der Worker führt eine manuelle Aktivität durch. 

8.4.2 Akteure 

Worker 


• Der Worker hat sich mittels des Anmeldedialogs angemeldet. 

• Der Worker hat eines oder mehrere Arbeitselemente in der Arbeitsliste bzw. Prozesse in der Prozessliste. 


a. Der Worker wählt ein Arbeitselement aus der Arbeitsliste aus. 

b. Der Worker bestätigt die Annahme der Aktivität. 

c. Der Worker führt die Aktivität durch. 

d. Der Worker schliesst die manuelle Aktivität ab. 

e. Der Work Engine schaltet zur nächsten Aktivität. 

8.4.5 Alternative (a) 

1) Der Worker erzeugt eine neue Instanz aus der Prozessliste. 

2) Fortsetzung mit c. 

8.4.6 Alternative (c) 

1) Die Tätigkeit wird suspendiert. 

2) Sofortige oder spätere Fortsetzung mit a. 

8.4.7 Ausnahme (c) 

1) Die Ausführung der computerunterstützten Aktivität ergab einen Fehler. 

2) Der Prozess wird abgebrochen. 

8.4.8 Implementierung 

8.4.8.1 GUI 

In der Abbildung 9: Frameaufteilung des Webclient ist eine mögliche, grobe Bildschirmaufteilung des 

Webclient dargestellt. 




Abbildung 9: Frameaufteilung des Webclient 

Anzeige Prozess- und 

Arbeitsliste 

8.5 Instanz überwachen und steuern (A5) 


Arbeitsfläche 

Der Instanzbesitzer kann seine Instanzen überwachen und steuernd eingreifen, dazu gehören: 

• Eine Instanz eines Prozesses erzeugen, dabei muss er die erste Aktivität nicht durchführen. 

• Wahlweise pro Aktivität einer Instanz einen Termin setzen. 

• Eine Instanz im Zustand «erzeugt» löschen 

• Eine Instanz in den Zustand «abgebrochen» führen. 

• Den Arbeitsfortschritt und Prozesszustand beobachten. 

8.5.2 Akteure 

Instanzbesitzer 


• Der Instanzbesitzer hat sich mittels des Anmeldedialogs angemeldet. 


Dieser Anwendungsfall wird während der Analysephase verfeinert. 

8.5.5 Implementierung 

8.5.5.1 Prozesszustand 

Die folgende Prozesszustände können durch den Instanzbesitzer beobachtet werden: 



Abbildung 10: Prozesszustände 

erzeugt 

läuft 

nicht ausgeführt 

nicht gestartet 

suspendiert 

beendet 

abgeschlossen 

abgebrochen 

• erzeugt: Der Prozess wird durch den Instanzbesitzer oder Worker erzeugt. 

• nicht gestartet: Instanzbesitzer erzeugt eine Instanz. 

• läuft: Der Prozess hat keine Aktivität welche den Zustand suspendiert hat. 

• suspendiert: Ein oder mehrere Aktivitäten haben den Zustand suspendiert. 

• beendet: Der Prozess wird ordnungsgemäss abgeschlossen oder manuell bzw. durch einen Programmfehler 

abgebrochen. 

• abgeschlossen: Der Prozess wird ordnungsgemäss beendet. 

• abgebrochen: Der Prozess wird manuell oder durch einen Programmfehler abgebrochen. 

8.5.5.2 Aktivitätszustand 

Die folgende Aktivitätszustände können durch den Instanzbesitzer beobachtet werden: 

inaktiv 

Abbildung 11: Aktivitätszustände 

suspendiert 

aktiv abgeschlossen 

• inaktiv: Die Aktivität wurde erzeugt aber noch nicht aktiviert. 

• aktiv: Ein Arbeitselement wird durch den Worker oder einer Applikation dieser Aktivität bearbeitet. 

• suspendiert: Worker wählt ein Arbeitselement aus der Prozessliste, schliesst dies aber nicht ab 

und seine Session ist nicht mehr aktiv. 

• abgeschlossen: Der Worker oder die Applikation schliesst die Aktivität ordnungsgemäss ab. 


Seite 24

Pflichtenheft - FlowWorkJ Kapitel: 9 Abnahmekriterien 

9 Abnahmekriterien 

9.1 Funktionale Anforderungen 

Zu den in den Anwendungsfällen (A1-A5) beschriebenen Anforderungen bestehen zusätzlich folgende 

funktionale Anforderungen: 

Bereich Ziel M 1 /W 2 

Mögliche Formen 

von WFMS 

Konstrukte des 

Workflow-Modells 

Unterstützt den Produktions-Workflow 

Wertebasierte Bedingungen auf Transitionen 

Split und Join-Knoten werden vollständig implementiert M 

Optional wird die Rolle – bzw. der Worker – bei Terminüberschreitungen 

mittels E-Mail an seine Pflichten erinnert 

Optional wird der Instanzbesitzer bei Terminüberschreitungen mittels E- 

Mail informiert 

Wiederholte Ausführung M 

Es wird ein Framework bereitgestellt, welches das Herunter- und 

Hinaufladen einer Datei in die Datenbank unterstützt 

Synchronisations-Transitionen W 

Befolgung von Standards bezüglich des XML-WfMC-Referenz-Modells W 

Sub-Workflow W 

Temporale Bedingungen auf Transitionen W 

Die Prozessdefinition erfolgt mit einem grafischen Werkzeug W 

Eine Instanz kann zeitgesteuert erzeugt werden W 

Workflow-Beispiel Das Beispiel der einfachen Auftragsabwicklung kann für den Schulunterricht 

benutzt werden 

Die Studenten können dabei Rollen einnehmen und aktiv teilnehmen M 

Die implementierten Schnittstellen werden alle genutzt M 

Dokumentation Falls kein grafisches Werkzeug für die Prozessmodellierung vorliegt, 

muss die XML-Prozessdefinition sehr ausführlich in englischer oder 

deutscher Sprache beschrieben sein 

1 Muss-Ziel 

2 Wunsch-Ziel 

Für die Installation und den Betrieb des Produktes wird das Wissen der 

Entwickler dieses Produktes nicht benötigt, da ein vollständiges Betriebshandbuch 

geliefert wird 

©Pflichtenheft.doc 06.01.2003 – Version: 2.3 Seite 25 

M 

M 

M 

M 

M 

M 

M 

M


9.2 Qualitätszielbestimmungen 

Produktequalität sehr wichtig wichtig unwichtig 

Funktionalität 

Angemessenheit 

Richtigkeit 

Interoperabilität 

Ordnungsmässigkeit 

Zuverlässigkeit 

Reife 

Fehlertoleranz 

Wiederherstellbarkeit 

Benutzbarkeit 

Verständlichkeit 

Erlernbarkeit 

Bedienbarkeit 

Effizienz 

Zeitverhalten 

Verbrauchsverhalten 

Änderbarkeit 

Analysierbarkeit 

Erweiterbarkeit 

Stabilität 

Übertragbarkeit 

Anpassbarkeit 

Installierbarkeit 

Konformität 

Austauschbarkeit 

9.2.1 Definition der Qualitätszielbestimmungskriterien 

sehr wichtig: Hier kann der Auftraggeber feststellen das sich der Auftragnehmer der Problematik 

bewusst war und eine optimierte Lösung anbietet. 

wichtig: Der Auftragnehmer ist sich der Problematik bewusst und betreibt einen Mehraufwand, wobei 

aufwändige Optimierungen nicht durchgeführt werden. Falls dieser Mehraufwand durch den Auftragnehmer 

im Endprodukt nicht sichtbar ist, kann dies der Auftragnehmer begründen. 

unwichtig: Es hat keine Bedeutung, daher wird schon gar nicht über eine Optimierung nachgedacht. 

9.3 Abgrenzung 

• Es gibt kein Simulationswerkzeug um den Workflow zu simulieren. 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Seite 26


• Die Qualität der Dokumentation bezüglich Application Server liegt nicht in unserer Kompetenz. 

• Other Workflow Enactment Service(s) (Schnittstelle 4) des WfMC-Referenzmodelles wird nicht 

implementiert. 

• Versionierung von Prozessen wird nicht unterstützt. 

• Eine Instanz kann nicht durch eine E-Mail erzeugt werden. Siehe auch Kapitel «Start». 

• Ein XML-Autoren-Werkzeug gehört nicht zum Lieferumfang. 

• Die Sprache der Applikation ist Deutsch, andere Sprachen werden nicht unterstützt. 

• Da es sich um eine Serverlösung mit J2EE handelt und nicht um eine lokale Ausführung von Programmen, 

kann es keine direkte Integration von Microsoft-Office Anwendungen in den Workflow- 

Engine geben. 

• Die Verwaltung der XML-Prozessdefinitions Dateien gehört nicht zum Umfang von FlowWorkJ. 


Seite 27

Pflichtenheft - FlowWorkJ Kapitel: 10 Glossar 

10 Glossar 

Deployment: Das Deployment kann als ein Einspielen einer oder mehreren Komponenten auf eine 

Zielumgebung angesehen werden. 

Dokumenttyp-Definition (DTD): In einer Dokumenttyp-Definition werden die Regeln festgelegt, die 

für Dokumente eines bestimmten Typs gelten sollen. Für den Verfasser von XML-Dokumenten macht 

sich die Verwendung von DTDs in erster Linie als Einschränkung bemerkbar. Es können nur bestimmte 

Elemente verwendet werden, und es müssen die Vorgaben für die Verschachtelung der Elemente 

und für die Attribut-Werte eingehalten werden. Eine Dokumenttyp-Definition kann in einer separaten 

Datei untergebracht werden; man spricht dann von einer externen DTD (oder auch von einer externen 

DTD-Untermenge). Die Definitionen können aber auch am Anfang von einem Dokument erscheinen. 

In diesem Fall spricht man von einer internen DTD (bzw. einer internen DTD-Untermenge). 

Entity Beans: Der wesentliche Unterschied zwischen Session und Entity Beans definiert sich über die 

Persistenz. Session Beans sind nicht persistent, das heisst sie haben kein echtes Gegenstück auf der 

Datenbank (bei Entity Beans könnte das Gegenstück zum Beispiel ein Datensatz in einer Tabelle 

sein). Ein «Entity Bean» repräsentiert folglich eine Objektsicht auf Geschäftsdaten, die in der (relationalen) 

Datenbank gespeichert sind. Das Bean bringt einen sogenannten «object wrapper» mit, der ein 

einfaches Zugreifen auf die Daten und deren kontrollierte Manipulation ermöglicht. Entity Beans sind 

in diesem Kontext transaktionsgeschützt, das heisst die Beans repräsentieren immer den letzten konsistenten 

Zustand der Daten. Ein Entity Bean kann seine Persistenz selbst kontrollieren (bean managed 

persistence) oder die Aufgabe an den Container delegieren (container managed persistence). Ein 

Entity Bean wird über einen Primärschlüssel identifiziert. Wenn der Container abstürzt, in dem das 

Bean läuft, überleben das Entity Bean, sein Primärschlüssel sowie jede Referenz darauf. 

Framework: Als Framework bezeichnet man eine Menge von verknüpften Klassen, welche zusammen 

ein wiederverwendbares und erweiterbares Gerüst für die Entwicklung von Software eines bestimmten 

Typs bilden. 

J2EE: Die Java 2 Enterprise Edition ist ein Sammlung verschiedenster Spezifikationen auf deren 

Grundlage Softwareprodukte, insbesondere Internetanwendungen, entwickelt werden können. Die 

J2EE-Spezifikation kennt die folgenden vier Typen von Komponenten, die von J2EE-kompatiblen Application 

Servern unterstützt werden müssen : 

Application Clients: Das sind typischerweise Programme mit grafischem User Interface, die auf dem 

Desktop Computer beim Anwender laufen. 

Applets: Dieses sind GUI-Komponenten, die von einem Web Server in den Web Browser beim Anwender 

geladen und dort ausgeführt werden. 

Servlets, JavaServer Pages (JSP), Filter und Web Eventlistener: Diese werden als Web- 

Komponenten bezeichnet und Serverseitig ausgeführt. 

Enterprise Java Beans: Sie repräsentieren typischerweise die Geschäftslogik einer Anwendung und 

werden ebenfalls serverseitig ausgeführt. 

Java Server Pages: Die JavaServer Pages-Technologie ermöglicht das Erstellen von dynamischen 

Inhalten für Web Clients. Eine JSP-Seite ist ein textbasiertes Dokument, das die Behandlung eines 

Requests und die damit verbundene Antwort (Response) beschreibt. Der Vorteil bei der Verwendung 

von JSP-Seiten gegenüber Servlets liegt darin, dass eine Trennung von Darstellungs- und inhaltserzeugender 

Logik möglich wird. Der Seitenaufbau kann mit Hilfe von HTML- oder XML-Elementen realisiert 

werden. Der dynamische Inhalt wird mit Hilfe von JSP-Elementen, wie Zugriffe auf instanziierte 

JavaBeans (hier als serverseitige Komponenten zu verstehen) oder zum Beispiel sogenannte «Scriptlets» 

(Fragmente aus Java-Code), erzeugt. 

JMS: Das Java Messaging Service API unterstützt asynchrone Kommunikation in verschiedenen 

Messaging-Systemen, wie zum Beispiel verlässliches Queuing oder Publish and Subscribe Services. 



Open Source: Software, die sowohl als Quelltext als auch in ausführbarer Form inspiziert, verändert 

und auch verändert unter gleicher Lizenz weitergegeben werden darf. Der Quellcode ist meist öffentlicht 

zugängig und kann von anderen Programmierern verwendet werden. 

Session Beans: Ein Session Bean wird erzeugt, um dem aufrufenden Client eine bestimmte Funktionalität 

zur Verfügung zu stellen. Ein solches Bean existiert typischerweise nur für die Dauer einer einzelnen 

Client Server Session. Session Beans werden benutzt, um spezielle «Business Cases» zu 

implementieren, das heisst in ihnen liegt die eigentliche Geschäftslogik. Demzufolge kann ein Session 

Bean unter Umständen der verlängerte Arm des Clients sein, der auf dem Server als logische Erweiterung 

des Clients fungiert. Session Beans repräsentieren nicht notwendigerweise Daten aus der Datenbank. 

Allerdings können sie Routinen beinhalten, die einen Zugriff und die Manipulation der Daten 

erlauben oder auch einen «Workflow» darstellen, das heisst einen Vorgang, der aus mehreren Einzelschritten 

besteht. Das Bean kann dabei transaktionsorientiert sein, allerdings ist der Vorgang nicht 

wieder herstellbar, falls der Container während einer laufenden Transaktion abstürzt. Weiterhin wird 

zwischen «stateful» und «stateless» Session Beans differenziert. Ganz simpel ausgedrückt handelt es 

sich bei einem «stateless» Session Bean um eine Komponente, auf die ohne Kenntnisse des vorherigen 

oder zukünftigen Zustands zugegriffen wird, das heisst die Zugriffe erfolgen isoliert voneinander. 

Ein «stateful» Session Bean hingegen kann als Erweiterung der Client-Applikation aufgefasst werden, 

da es Aufgaben für einen Client durchführt und sich auch den Zustand des korrespondierenden 

Clients merkt. Dieser Typ von Enterprise Beans bildet Logik ab, die bei einer klassischen Client- 

Server-Architektur im Client liegen würde (und nun auf der Middle-Tier liegt!). Man nennt diesen Zustand 

auch «conversational state», da er eine kontinuierliche Konversation zwischen dem stateful 

Session Bean und dem Client repräsentiert. 

SOAP (Simple Object Access Protocol) ist für Web Services die zentrale Middleware-Technologie. 

Sie basiert auf offenen Standards wie XML und definiert einen Nachrichtenaustausch zwischen 2 

Partnern im Internet: 

Ein Dienstanbieter (Server), auch Web Service Provider genannt, stellt eine beliebige Online- 

Dienstleistung via SOAP zur Verfügung. Er akzeptiert Nachrichten über das Standard-Internet- 

Protokoll HTTP, die in XML formatiert sind. 

Ein Dienstnehmer (Client), kann den Service des Anbieters durch eine entsprechend formulierte 

SOAP Nachricht nutzen kann. 

Web Services sind lose verbundene, offene Schnittstellen, die auf Basis plattformunabhängiger 

Technologien angebunden werden können. Sie ermöglichen eine zeitnahe und dynamische Abwicklung 

von komplexen Geschäftsprozessen über System- und Unternehmensgrenzen hinweg. IBM definiert 

Web Services wie folgt: «Web Services sind gekennzeichnet durch einen dreistufigen Web Service 

Stack, der die offenen Standards SOAP (Simple Object Access Protocol), WSDL (Web Services 

Description Language) und UDDI (Universal Discovery, Description and Integration) beinhaltet.» Der 

Charme von Web Services liegt eben in dieser konsequenten und ausschliesslichen Verwendung von 

standardisierten und Web-tauglichen Technologien, die nicht nur Kommunikation sondern auch verteilte 

Transaktionen über Unternehmensgrenzen und Firewalls hinweg ermöglichen. 

XML-Schema ist ein neuer Ansatz zur Definition von Dokument-Typen und damit zur Spezifikation 

von XML-Sprachen. Mit der Erhebung der eXtensible Markup Language (XML) zum Industriestandard 

1998 hatte sich zunächst die von der Standardized Generalized Markup Language (SGML) übernommene 

Document Type Definition (DTD) als Format zur Beschreibung konkreter XML-Sprachen etabliert. 

Mit der starken Verbreitung von XML in der Praxis machten sich zunehmend die Schwachpunkte 

der DTDs bemerkbar, insbesondere die dokumentenzentrierte Sichtweise der DTDs unter Vernachlässigung 

von Datentypen erwiesen sich in Zeiten der Annäherung der Programmiersprachen an die 

Datenmodellierung als Problem. Auch lassen die DTDs weder die Beschreibung bestimmter semantischer 

Bedingungen noch die Festlegung von Wertebereichen zu. Als Nachfolger der DTDs markiert 

XML-Schema den entscheidenden Wendepunkt von der bisherigen dokumentenorientierten Sichtweise 

hin zu einer datenorientierten Sichtweise. Durch das Hinzufügen von Datentypen erhöht XML- 

Schema seine Ausdruckskraft und die Nutzbarkeit von XML für E-Commerce und Datenbanken. XML- 


Seite 29


Schema erfüllt die Anforderung, Daten in einem einheitlichen, dabei aber flexiblen und leicht modifizierbaren 

Format, welches sich zudem leicht auswerten (parsen) lässt, zu transportieren. XML- 

Schema stellt die DTD-Regeln zur Verfügung, nach denen ein XML-Dokument auf seine Gültigkeit hin 

überprüft wird (Validierung). Da jedes XML-Schema auch ein XML-Dokument ist, lässt es sich selbst 

auch durch ein Schema oder eine DTD beschreiben. 


Seite 30

Pflichtenheft - FlowWorkJ Kapitel: 11 Abbildungsverzeichnis 

11 Abbildungsverzeichnis 

Abbildung 1: Einsatzdiagramm von FlowWorkJ...................................................................................... 7 

Abbildung 2: Referenzmodell der WfMC............................................................................................... 11 

Abbildung 3: Beispielprozess mit Join- und Splitknoten ....................................................................... 14 

Abbildung 4: Wiederholte Ausführung................................................................................................... 15 

Abbildung 5: Rollen in FlowWorkJ......................................................................................................... 16 

Abbildung 6: Transitionen...................................................................................................................... 18 

Abbildung 7: Personen und Rollen........................................................................................................ 19 

Abbildung 8: Elementares Metamodell ................................................................................................. 20 

Abbildung 9: Frameaufteilung des Webclient........................................................................................ 23 

Abbildung 10: Prozesszustände............................................................................................................ 24 

Abbildung 11: Aktivitätszustände .......................................................................................................... 24

Pflichtenheft FlowWorkJ

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?