Pflichtenheft - home.dtc.chhome.dtc.ch/flowworkj/doku/Pflichtenheft_v2.3.pdf · Pflichtenheft -...

Pflichtenheft FlowWorkJ

Diplomarbeit

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

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/

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

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. Sitzungsproto-koll 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.5 Normaler Ablauf....................................................................................................................21 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.5 Normaler Ablauf....................................................................................................................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.4 Normaler Ablauf....................................................................................................................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.4 Normaler Ablauf....................................................................................................................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 not-wendig (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) Intranet-basierten 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 konzi-pieren.

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

Seite 6

• 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 Pro-zessdefinition 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

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.

FlowWorkJ-DBMS

Worker-PC

Internet Browser

Prozessersteller-PC

Autoren-XML/DTD/Schema-Werkzeug

XML-Prozessdefinition

DTD oder Schema fürProzessdefinition

FlowWorkJ-DeploymentWerkzeug

J2EE Applikation-PC

Notification Daemon

J2EE-Appliaktion Server

EJB Container

Web Container

Instanzbesitzer/Administrator-PC

FlowWorkJAdministrations /Monitoring-Werkzeug

Java ApplikationDieses Werkzeuggehöhrt nicht zumLieferumfang vonFlowWorkJ

Abbildung 1: Einsatzdiagramm von FlowWorkJ

3.2 Software

Benutzte Java-Frameworks werden hier nicht aufgeführt. Es werden nur Open Source-Produkte ver-wendet. 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über-schreitungen 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

Seite 8

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.

3.3 Hardware

An die Hardware werden keine speziellen Anforderungen gestellt.


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 auf-gerufen 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 Arbeitsab-lä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 Beschrei-bung 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 bezeich-net. 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 Ver-wendung 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»

Seite 10

• 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 Ent-wicklungsprojekte 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 ent-sprechend 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.


Pflichtenheft - FlowWorkJ Kapitel: 5 Standard

5 Standard

Es ist wichtig, das Referenzmodell der WfMC zu verstehen, da sich einige Anforderungen nach die-sem Modell richten.

5.1 Das Referenzmodell der WfMC

Die WfMC ist ein Industriestandardisierungsgremium – vergleichbar mit der OMG – mit dem Unter-schied, 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, Anhal-ten, 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 analysie-ren, 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 Defi-nitionen von Geschäftsvorgängen. Das gemeinsame Austauschformat bietet folgende Arten von In-formationen an:


Pflichtenheft - FlowWorkJ Kapitel: 5 Standard

Seite 12

• Bedingungen für das Starten und Beenden von Prozessen

• Identifizierung von Aktivitäten innerhalb eines Prozesses, einschliesslich dazugehöriger Applika-tionen 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 Klientenbenutzerap-plikationen 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. Verschie-dene 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 gemein-samem 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


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 Mitteilun-gen 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 Aus-druckskraft. Die Prozess-Modelle können nur als Ganzes verändert werden. Einzelne laufende Pro-zesse 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 Ab-nahmekriterien 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än-dig, da einige Konstrukte in diesem Diagrammtyp fehlen.

Auftragsbearbeitung Kundenbetreung Buchhaltung

Bestellungbearbeiten

Express-Lieferung

NormaleLieferung

{Or-Join}{Or-Split} aufdenTransitionen

{And-Split}

Bestellungentgegen-nehmen

Rechnungausstellen

Bestellungabschliessen

{And-Join} Zahlungverbuchen

Startknoten

[sonst][Eilbestellung]

Abbildung 3: Beispielprozess mit Join- und Splitknoten

7.1.2 Start

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 einlau-fenden 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 kei-ne der anderen Transitionen aktiviert wird. Damit ist sichergestellt, dass mindestens eine ausge-hende 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 einge-henden 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 wei-ter 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 Transiti-onen 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.

A B Aktivität 4Aktivität 1

[Bedingung]

Loop-Start Loop-Ende

Abbildung 4: Wiederholte Ausführung

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 die-se 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 Admi-nistratorenwerkzeug 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.

FlowWorkJ

Instanz überwachen undsteuern

Manuelle Aktivitätausführen

Prozess definieren

Personen und Rollenverwalten

Automatisierte Aktivitäterstellen

Prozessersteller

Worker

Adminstrator

Instanzbesitzer

<<extend>>

Abbildung 5: Rollen in FlowWorkJ



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 Prozessdefi-nition 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 Teil-nehmern an einem Workflow-Prozess. Diese Rolle charakterisiert die Person, die während der Erledi-gung 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 ab-gearbeitet 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ätsdefinitio-nen 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 wiederhol-ter Ausführung zulässig.

7.4.1.2 Synchronisations-Transitionen

Synchronisations-Transitionen legen fest, dass parallel liegende Knoten in einer bestimmten Reihen-folge 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.

Split

A

Join

B

DC

Synchronisations Transition

Abbildung 6: Transitionen


Pflichtenheft - FlowWorkJ Kapitel: 8 Anwendungsfälle

8 Anwendungsfälle

Da sowohl dem Auftraggeber wie auch dem Auftragnehmer die Grundprinzipien von Anwendungsfäl-len bekannt sind, verzichten wir hier auf eine Prosabeschreibung von Szenarien. Anwendungsfälle sind Abstraktionen von Szenarien, das heisst ähnliche Szenarien werden zusammengefasst und de-ren 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.

Produktion Marketing

Anlagen Fertigung 1

Person3

Fertigung 2

Person5

Person1Person2

Person4

Person6

Unternehmensleitung

Abbildung 7: Personen und Rollen

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

• 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 an-gemeldet.



Seite 20

8.1.4 Normaler Ablauf

Dieser Anwendungsfall wird während der Analysephase verfeinert.

8.2 Prozess definieren (A2)

8.2.1 Zielsetzung

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

1..*hat

1 hat

0..* hat

0..1hat

0..1 hat

1..* besteht aus

Applikation

Prozessdefinition

Aktivitaet

Workflow relevante Daten

Transitions Bedinung

Rolle

Dynamische Daten, wie z.B.Personen-/Rollenzuordnung, Einund Ausgabedaten von Applikat

Abbildung 8: Elementares Metamodell

Dabei besteht die XML-Prozessdefinition wie in Abbildung 8: Elementares Metamodell dargestellt aus Aktivitäten, Rollen, usw.

8.2.2 Akteure

Prozessersteller

8.2.3 Vorbedingung

• 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.




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)

8.3.1 Zielsetzung

FlowWorkJ hat Schnittstellen zu verschiedenen Technologien, welche die Integration von computerun-terstü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

Prozessersteller

8.3.3 Vorbedingung

• Der Prozessersteller kennt die Grundlagen von Session Bean, Java Server Pages und Web Ser-vices 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 Applika-tionsserver 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)

8.4.1 Zielsetzung

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

8.4.2 Akteure

Worker

8.4.3 Vorbedingung

• Der Worker hat sich mittels des Anmeldedialogs angemeldet.

• Der Worker hat eines oder mehrere Arbeitselemente in der Arbeitsliste bzw. Prozesse in der Pro-zessliste.


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.



Anzeige Prozess- und Arbeitsliste

Arbeitsfläche

FlowWorkJ

Abbildung 9: Frameaufteilung des Webclient

8.5 Instanz überwachen und steuern (A5)

8.5.1 Zielsetzung

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

8.5.3 Vorbedingung

• 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:



Seite 24

beendet

abgeschlossen

abgebrochen

erzeugt

läuft

nicht ausgeführt

suspendiert

nicht gestartet

Abbildung 10: Prozesszustände

• 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 Pro-grammfehler 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:

suspendiert

aktiv abgeschlosseninaktiv

Abbildung 11: Aktivitätszustände

• 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.


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 M1/W2 Mögliche Formen von WFMS

Unterstützt den Produktions-Workflow M

Konstrukte des Workflow-Modells

Wertebasierte Bedingungen auf Transitionen M

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

M

Optional wird der Instanzbesitzer bei Terminüberschreitungen mittels E-Mail informiert

M

Wiederholte Ausführung M

Es wird ein Framework bereitgestellt, welches das Herunter- und Hinaufladen einer Datei in die Datenbank unterstützt

M

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 Schulunter-richt benutzt werden

M

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

M

Für die Installation und den Betrieb des Produktes wird das Wissen der Entwickler dieses Produktes nicht benötigt, da ein vollständiges Be-triebshandbuch geliefert wird

M

1 Muss-Ziel 2 Wunsch-Ziel



Seite 26

9.2 Qualitätszielbestimmungen

Produktequalität sehr wichtig wichtig unwichtig Funktionalität

Angemessenheit

Richtigkeit

Interoperabilität

Ordnungsmässigkeit

X

X

X

X

Zuverlässigkeit

Reife

Fehlertoleranz

Wiederherstellbarkeit

X

X

X

Benutzbarkeit

Verständlichkeit

Erlernbarkeit

Bedienbarkeit

X

X

X

Effizienz

Zeitverhalten

Verbrauchsverhalten

X

X

Änderbarkeit

Analysierbarkeit

Erweiterbarkeit

Stabilität

X

X

X

Übertragbarkeit

Anpassbarkeit

Installierbarkeit

Konformität

Austauschbarkeit

X

X

X

X

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 Auftrag-nehmer 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.



Seite 27

• 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 Pro-grammen, 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.


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 bestimm-te 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 (relatio-nalen) 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 kon-sistenten Zustand der Daten. Ein Entity Bean kann seine Persistenz selbst kontrollieren (bean mana-ged 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 zusam-men ein wiederverwendbares und erweiterbares Gerüst für die Entwicklung von Software eines be-stimmten 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 Ap-plication 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 An-wender 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 inhaltser-zeugender Logik möglich wird. Der Seitenaufbau kann mit Hilfe von HTML- oder XML-Elementen rea-lisiert 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 «Script-lets» (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.



Seite 29

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 öffent-licht zugängig und kann von anderen Programmierern verwendet werden.

Session Beans: Ein Session Bean wird erzeugt, um dem aufrufenden Client eine bestimmte Funktio-nalität zur Verfügung zu stellen. Ein solches Bean existiert typischerweise nur für die Dauer einer ein-zelnen 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 Erweite-rung des Clients fungiert. Session Beans repräsentieren nicht notwendigerweise Daten aus der Da-tenbank. 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 Einzel-schritten 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 vorheri-gen 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 Zu-stand 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 Abwick-lung von komplexen Geschäftsprozessen über System- und Unternehmensgrenzen hinweg. IBM defi-niert Web Services wie folgt: «Web Services sind gekennzeichnet durch einen dreistufigen Web Servi-ce 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 verteil-te 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) übernom-mene Document Type Definition (DTD) als Format zur Beschreibung konkreter XML-Sprachen etab-liert. Mit der starken Verbreitung von XML in der Praxis machten sich zunehmend die Schwachpunkte der DTDs bemerkbar, insbesondere die dokumentenzentrierte Sichtweise der DTDs unter Vernach-lä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 semanti-scher Bedingungen noch die Festlegung von Wertebereichen zu. Als Nachfolger der DTDs markiert XML-Schema den entscheidenden Wendepunkt von der bisherigen dokumentenorientierten Sichtwei-se 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 30

Schema erfüllt die Anforderung, Daten in einem einheitlichen, dabei aber flexiblen und leicht modifi-zierbaren 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.


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 - home.dtc.chhome.dtc.ch/flowworkj/doku/Pflichtenheft_v2.3.pdf · Pflichtenheft -...

Documents

Transcript of Pflichtenheft - home.dtc.chhome.dtc.ch/flowworkj/doku/Pflichtenheft_v2.3.pdf · Pflichtenheft -...