Plug&Play-Aspekte und Integration zustandsbehafteter Daten in Prozess-Management-Systeme [original]

Plug&Play-Aspekte und Integration

zustandsbehafteter Daten in

Prozess-Management-Systeme

Diplomarbeit

Diplomand: Kevin G¨

oser

Fachbereich: Informatik

Fachrichtung: Medieninformatik

Betreuer: Prof. Dr. Peter Dadam, Hilmar Acker

Korrektoren: Prof. Dr. Peter Dadam, Dr. Manfred Reichert

Abgabedatum: 30. September 2005

Danksagung

An erster Stelle m¨

ochte ich meinen Betreuern Prof. Dr. Peter Dadam und Hilmar Acker

f¨

ur die enge und fruchtbare Zusammenarbeit danken. Sie haben sich stets viel Zeit f¨

mich genommen und waren auch zu langen Diskussionen bereit.

Hilmar Acker danke ich besonders daf¨

ur, dass er stets ein offenes Ohr f¨

ur meine Fragen

und Anliegen hatte.

Mein besonderer Dank geht an meine Freundin, Linh Thao Ly, deren Liebe und Un-

terst¨

utzung mir w¨

ahrend der gesamten Zeit R¨

uckhalt geboten haben.

Kevin G¨

oser

Ulm, den 30.09.2005

Inhaltsverzeichnis

1 Einleitung 1

1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Relevante Grundlagen 5

2.1 Workflow-Management-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 ADEPT....................................... 8

2.2.1 ¨

Uberblick ¨

uberADEPT .......................... 8

2.2.2 Kontroll- und Datenfluss . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.3 Ausf¨

uhrungszust¨

ande von Aktivit¨

aten .................. 11

2.2.4 Konzepte zur Unterst¨

utzung von Adaptivit¨

at .............. 11

2.2.5 Definitionen und Notationen . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Komponententechnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Plug & Play 15

3.1 Plug & Play und Softwarekomponenten . . . . . . . . . . . . . . . . . . . . . 16

3.2 Plug & Play mit Komponenten in Workflow-Management-Systemen . . . . . 17

3.3 Abh¨

angigkeiten zwischen Aktivit¨

aten....................... 19

3.4 Beispiele....................................... 24

3.5 Weitere Aspekte und Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 26

3.6 Integration versteckter Datenfl¨

usse ........................ 27

3.7 Semantische und funktionale Aspekte . . . . . . . . . . . . . . . . . . . . . . 29

3.8 Zusammenfassung und weitere Inhalte der Diplomarbeit . . . . . . . . . . . . 30

4 Zustandsbehaftete Daten 33

4.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Ein erster L¨

osungsansatz.............................. 34

4.3 Bewertung und weitere Anforderungen . . . . . . . . . . . . . . . . . . . . . . 37

5 Zustandsbeschreibungen mittels Zustandsautomaten 41

5.1 Definition des Zustandsgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Erweiterung der Parameter von Aktivit¨

aten................... 44

5.3 Beispiele zur Demonstration des Konzepts . . . . . . . . . . . . . . . . . . . . 47

5.4 Ans¨

atze zur Sicherstellung der Zustandsforderungen . . . . . . . . . . . . . . 48

5.4.1 Anforderungen an die Validierung der Zustandsforderungen . . . . . . 51

5.4.2 Algorithmus f¨

ur synchronisationsfreie Prozesse . . . . . . . . . . . . . 51

5.4.3 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.4 L¨

osungsans¨

atze f¨

ur Prozesse mit Synchronisation . . . . . . . . . . . . 59

5.5 Diskussion und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.5.1 Parallele Zustandswechsel . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.5.2 Verarbeitungswege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.5.3 Allgemeine Zustandsobjekte . . . . . . . . . . . . . . . . . . . . . . . . 64

5.5.4 Globale Zust¨

ande.............................. 65

5.5.5 Mehrere Zust¨

ande ............................. 65

5.5.6 Bezugspunkt f¨

ur Zust¨

ande......................... 67

5.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Ausblick 69

A Algorithmen 75

Kapitel 1

Einleitung

Bem¨

uhungen, Gesch¨

aftsprozesse und beteiligte Anwendungen durch Informationssysteme zu

unterst¨

utzen, stießen in den letzten Jahren auf reges Interesse [5]. Flexibilit¨

at und Adaptivit¨

der Prozess- und der Anwendungslogik sollen durch systemseitige Unterst¨

utzung verbessert

werden. In diesem Zusammenhang stechen besonders drei Schlagw¨

orter heraus: Workflow-

Management-Systeme (WfMS) und Web Services bzw. Service Oriented Architecture (SOA).

Workflow-Management-Systeme trennen die Prozess- von der Anwendungslogik und erlauben

so eine anwendungsunabh¨

angige Modellierung und Ausf¨

uhrung von Abl¨

aufen. Web Services

und SOA besch¨

aftigen sich hingegen mit der Aufsplittung von Anwendungssystemen und

Komponenten in einzelne Dienste, um deren Integration in die Betriebs-IT zu vereinfachen.

Beide Ans¨

atze haben ihre Vor- und Nachteile. Bei Web Services ist es durch Einsatz von

Beschreibungsmodellen m¨

oglich, Methoden von Komponenten mit entsprechendem Aufwand

als separate Dienste in die Anwendungslandschaft zu integrieren und miteinander zu verschal-

ten. Aufgrund der Spezifikation ihrer Schnittstellen k¨

onnen Dienste dynamisch durch andere

ersetzt werden. Die Modellierung von Gesch¨

aftsprozessen ist jedoch nicht, oder nur in ge-

ringem Maße, m¨

oglich. Workflow-Management-Systeme hingegen legen den Schwerpunkt auf

die Organisation und Ausf¨

uhrung von Abl¨

aufen. Letzendlich werden jedoch auch bei WfMS

bei der Ausf¨

uhrung der Gesch¨

aftsprozesse dahinterliegende Komponenten und Dienste an-

gesprochen. Die angestrebte Flexibilit¨

at und Adaptivit¨

at wurde bei WfMS bisher h¨

ochstens

bez¨

uglich der Abl¨

aufe umgesetzt, nicht jedoch bez¨

uglich der angesprochenen Komponenten

und Dienste. Auswahl und Komposition der Dienste sind daher auch in aktuellen Forschungs-

projekten noch zu statisch. An ein benutzerfreundliches Verschalten oder Auswechseln von

Diensten und Komponenten ist daher bis heute noch nicht zu denken.

Die Vereinigung beider Herangehensweisen ist deshalb f¨

ur die Zukunft von Informationssyste-

men im betrieblichen Umfeld von großer Bedeutung. Die Komponententechnologie, die sich

u.a. mit der Beschreibung von Komponenten besch¨

aftigt, kann wertvolle Impulse dazu ein-

bringen. Im Rahmen des AristaFlow-Projekts, das vom Land Baden-W¨

urttemberg gef¨

ordert

Abbildung 1.1: Zuweisen von Arbeitsschritten mittels Plug & Play

wird, sollen Konzepte f¨

ur Workflow-Management-Systeme der n¨

achsten Generation erarbei-

tet werden [1]. Der Schwerpunkt des Projekts ist die Vereinigung von Prozess- und Kompo-

nententechnologie f¨

ur eine zeitnahe Umsetzung von Gesch¨

aftsprozessen in WfMS. Zur Be-

schreibung des Ablaufs eines Gesch¨

aftsprozesses wird ein Prozessmodell verwendet. Die vom

Gesch¨

aftsprozess aufzurufenden Komponenten werden in einem sog. Aktivit¨

aten-Repository

verwaltet und dem Prozess zur Verf¨

ugung gestellt. Diese sollen, nach der Metapher von Plug

& Play, auf einfache Art und Weise mit dem Prozessmodell verbunden werden, um einen

ausf¨

uhrbaren Prozess zu erzeugen. Neben einer raschen Umsetzung von Gesch¨

aftsprozessen

soll jedoch auch die fehlerfreie Ausf¨

uhrung der Prozesse sichergestellt werden (siehe Abbil-

dung 1.1). Dazu muss die korrekte Verwendung der Komponenten anhand ihrer Spezifikation

sichergestellt werden.

Mit der Vision der Integration von Plug & Play in WfMS sind jedoch vielf¨

altige Herausforde-

rungen verbunden. Einige davon sollen in der vorliegenden Diplomarbeit vorgestellt werden.

1.1 Aufgabenstellung

Die vorliegende Arbeit hat sich zweierlei Aufgaben zum Ziel gemacht. Zum einen geht es

darum, grundlegende Probleme f¨

ur die Integration ”Plug & Play“-Konzepten in Workflow-

Management-Systemen zu er¨

ortern. Dabei sollen im Speziellen Abh¨

angigkeiten, die bei der

Umsetzung von ”Plug & Play“-Konzepten ber¨

ucksichtigt werden m¨

ussen, systematisch auf-

gezeigt werden.

Der zweite Teil der Arbeit besch¨

aftigt sich mit der Erarbeitung eines im Bereich von Plug &

Play einsetzbaren Konzeptes zur Integration von Zustandsinformationen in das Prozessmodell

des WfMS ADEPT. Damit sollen auf zustandsbehaftete Daten basierende Abh¨

angigkeiten bei

der Auswahl und Komposition von Aktivit¨

aten bzw. Komponenten sowie bei der Prozessana-

lyse ber¨

ucksichtigt werden k¨

onnen.

1.2 Aufbau der Arbeit

Die vorliegende Diplomarbeit ist wie folgt gegliedert. Kapitel 2 f¨

uhrt relevante Grundlagen f¨

das Verst¨

andnis der vorliegenden Arbeit ein. Dabei wird in Abschnitt 2.1 auf wichtige Begriffe

im Kontext von WfMS eingegangen. In Abschnitt 2.2 wird das ADEPT WfMS als Ausgangs-

basis f¨

ur die Konzepte der vorliegenden Arbeit vorgestellt. Abschnitt 2.3 f¨

uhrt Grundlagen

zu Komponententechnologie ein.

Kapitel 3 motiviert den Einsatz von Plug & Play-Konzepten im Kontext von WfMS und

er¨

ortert systematisch bestehende Probleme bei dessen Umsetzung.

Kapitel 4 geht genauer auf das Problem von zustandsbehafteten Daten ein. Es wird ein

erster Ansatz zur Integration von zustandsbehafteten Daten in ADEPT vorgestellt. Ein aus-

gereifterer L¨

osungsansatz wird in Kapitel 5 eingef¨

uhrt. Dieser erweitert ADEPT um die Ver-

wendung von Zustandsautomaten zur Beschreibung von m¨

oglichen Zustands¨

uberg¨

angen.

In Kapitel 6 schließt die vorliegende Arbeit mit einem Ausblick ab.

Kapitel 2

Relevante Grundlagen

Im Folgenden werden wichtige Grundlagen f¨

ur die vorliegende Diplomarbeit eingef¨

uhrt. Im

n¨

achsten Abschnitt wird ein ¨

Uberblick ¨

uber Workflow-Management (WfM) gegeben. In Ab-

schnitt 2.2 wird dabei das Workflow-Management-System ADEPT vorgestellt, welches die

Grundlage f¨

ur Konzepte dieser Arbeit darstellt. Des Weiteren wird ein ¨

Uberblick ¨

uber Kom-

pontenten gegeben.

2.1 Workflow-Management-Systeme

Workflow-Management-Systeme (WfMS) werden heutzutage vermehrt eingesetzt, um die

Ausf¨

uhrung von Gesch¨

aftsprozessen in Unternehmen zu unterst¨

utzen. Sie versprechen eine

zuverl¨

assigere und effizientere Prozessausf¨

uhrung.

Workflow-Management umfasst unterschiedliche Aufgabenbereiche und Schnittstellen, wie

Abbildung 2.1 verdeutlicht. Dazu geh¨

oren Schnittstellen und Werkzeuge, um Gesch¨

aftspro-

zesse zu modellieren und um diese auszuf¨

uhren. Bei der Ausf¨

uhrung von Gesch¨

aftsprozessen

m¨

ussen anfallende Arbeitsschritte an die jeweiligen Bearbeiter auf Workflow-Clients verteilt

werden. Des Weiteren muss der Aufruf von ben¨

otigten Anwendungen in den Arbeitsschritten

unterst¨

utzt werden. Ferner z¨

ahlen auch die ¨

Uberwachung der Abl¨

aufe sowie Schnittstellen zu

anderen WfMS zu weiteren Aspekten von Workflow-Management [9].

Gesch¨

aftsprozesse stellen unterschiedliche Anforderungen an die Modellierung. So m¨

ussen

in der Regel sequentielle, alternative, parallele und zyklische Abl¨

aufe m¨

oglich sein. F¨

ur die

Darstellung von Gesch¨

aftsprozessen wird im Allgemeinen ein Graph als Repr¨

asentation ge-

w¨

ahlt. Knoten im Graphen stellen dabei Arbeitsschritte dar. ¨

Uber ausgehende Kanten werden

die nachfolgenden Arbeitsschritte bestimmt.

Ein Arbeitsschritt in einem Prozess wird auch Aktivit¨

at genannt. Die Aktivit¨

at steht f¨

unterschiedliche Aktionen, wie z.B. einen manuellen Arbeitsschritt oder den Aufruf einer Me-

Abbildung 2.1: Workflow Reference Model [9]

thode in einer Softwarekomponente. Durch eine Zuordnung zwischen Aktivit¨

aten und Knoten

wird festgelegt, welche Arbeitsschritte durch den Gesch¨

aftsprozess ausgef¨

uhrt werden. Die Zu-

ordnung zwischen Aktivit¨

aten und Knoten im Graph erlaubt eine flexible Modellierung sowie

die Wiederverwendung von bereits bekannten Aktivit¨

aten in Form von Aktivit¨

atenvorlagen.

Prozess-Designer w¨

ahlen bereits vorgefertigte Aktivit¨

atenvorlagen aus einem Repository aus

und setzen diese direkt in einen Prozess ein.

Ergebnis der Modellierung eines Gesch¨

aftsprozesses ist eine Prozessvorlage. Um einen Pro-

zess zu starten, wird die Vorlage logisch kopiert. Als Ergebnis erh¨

alt man eine ausf¨

uhrbare

Prozessinstanz. Bei auf Graphen basierenden Systemen, wie z.B. ADEPT (s. Abschnitt 2.2),

wird der Zustand der Ausf¨

uhrung durch Markierungen an Knoten und Kanten dargestellt.

Damit eine Aktivit¨

at gestartet werden kann, muss ihr Knoten zun¨

achst ein entsprechendes

Signal durch die eingehenden Kanten erhalten. Ein Knoten mit einer fertig ausgef¨

uhrten Ak-

tivit¨

at gibt dieses Signal ¨

uber ausgehende Kanten weiter.

Durch bisher aufgezeigte Konzepte kann ein Prozess modelliert und ausgef¨

uhrt werden. In

der Praxis ist dieses Vorgehen f¨

ur viele Anwendungsdom¨

anden, wie z.B. klinische Prozesse,

jedoch zu statisch [4]. Abl¨

aufe m¨

ussen dynamisch angepasst werden k¨

onnen, um z.B. die

Behandlung von Ausnahmef¨

allen zu erm¨

oglichen. So muss es m¨

oglich sein, Adhoc-¨

Anderungen

an einer laufenden Instanz vorzunehmen, um z.B. einen weiteren Arbeitsschritt, wie eine

zus¨

atzliche Untersuchung f¨

ur einen Patienten, einzuf¨

ugen. ¨

Anderungen k¨

onnen auch durch

Optimierung der Gesch¨

aftsprozesse oder durch ge¨

anderte gesetzliche Rahmenbedingungen

motiviert sein. In diesen F¨

allen sind nicht nur einzelne Prozessinstanzen betroffen sondern

vielmehr die Prozessvorlage. Es ist offentsichtlich, dass die ¨

Anderungen an der Prozessvorlage

auch auf laufende Instanzen ¨

ubertragen werden sollten, wo dies m¨

oglich ist. Dieser Vorgang

wird auch als Schemaevolution bezeichnet. Durch Modellierung, Ausf¨

uhrung, erneute Analyse

und Optimierung der Prozesse, entsteht so ein Kreislauf, auch unter Business Process Lifecycle

(Lebenszyklus von Gesch¨

aftsprozessen) bekannt (s. Abb. 2.2).

Angesichts der bestehenden Anforderungen muss ein modernes WfMS sowohl Adhoc-¨

An-

derungen an Prozessinstanzen als auch ¨

Anderungen an der Prozessvorlage (Schemaevolution)

nicht nur in einer effizienten Art und Weise erm¨

oglichen, sondern auch f¨

ur die zuverl¨

assige

Ausf¨

uhrung der Prozesse garantieren. So d¨

urfen die angesprochenen ¨

Anderungen keine Fehler

in der Ausf¨

uhrung der Prozesse verursachen, z.B. durch fehlende Daten nach dem L¨

oschen

einer Aktivit¨

at. Aktuelle auf dem Markt verf¨

ugbare WfMS sind im Moment noch nicht in der

Lage, diese Flexibilit¨

at und Robustheit zu gew¨

ahren. In Forschungsprojekten wie ADEPT

k¨

onnen jedoch Ans¨

atze daf¨

ur gefunden werden.

Abbildung 2.2: Business Process Lifecycle

Neben den genannten ¨

Anderungen am Ablauf von Prozessen m¨

ussen moderne WfMS je-

doch auch ¨

Anderungen in der Auswahl der im Prozess verwendeten Aktivit¨

aten unterst¨

utzen.

Dies bedeutet in erster Linie, dass Aktivit¨

aten ausgetauscht werden k¨

onnen. Hinter diesen

Aktivit¨

aten stehen jedoch oft komplexe Anwendungssysteme, wie z.B. ein Warenwirtschafts-

system. Neue Anforderungen an diese Anwendungssysteme, welche z.B. durch Optimierungen

oder einer ge¨

anderten gesetzlichen Rahmenbedingung motiviert sein k¨

onnen, betreffen daher

u.U. auch ganze Softwarekomponenten. Bei Bedarf m¨

ussen diese auf den neuesten Stand

gebracht oder vollst¨

andig ausgetauscht werden k¨

onnen.

Ein WfMS soll die angesprochenen ¨

Anderungen unterst¨

utzen. Dabei muss es den For-

derungen nach einer effizienten und fehlerfreien Ausf¨

uhrung jedoch weiterhin gen¨

ugen. Die

Vorg¨

ange, um ¨

Anderungen durchzuf¨

uhren, m¨

ussen daher nicht nur performant ablaufen.

Bei den modifizierten Prozessen darf es auch weiterhin nicht zu einem Fehler w¨

ahrend der

Ausf¨

uhrung kommen.

2.2 ADEPT

Grundlage f¨

ur alle in dieser Arbeit vorgestellten Konzepte stellt das ADEPT WfMS und da-

hinter liegende Konzepte dar. Darum soll an dieser Stelle eine Einf¨

uhrung in die Notation

und Konzepte von ADEPT gegeben werden. Da eine detaillierte Behandlung von ADEPT

den Rahmen dieser Arbeit sprengen w¨

urde, wird sich der Abschnitt auf f¨

ur das Verst¨

andnis

der vorliegenden Arbeit grundlegende Aspekte beschr¨

anken. Der interessierte Leser wird f¨

weiterf¨

uhrende Informationen auf [12] bzw. f¨

ur Details zu konkreten Definitionen und Algo-

rithmen auf [11] verwiesen.

2.2.1 ¨

Uberblick ¨

uber ADEPT

Hinter ADEPT stehen Konzepte f¨

ur ein adaptives WfMS, die an der Universit¨

at Ulm in der

Abteilung Datenbanken und Informationssysteme entwickelt wurden. Bei der Entwicklung von

ADEPT wurden auf verschiedene Aspekte besonders großen Wert gelegt. Prozesse sollten

bereits zur Modellierungszeit hinsichtlich ihrer Ausf¨

uhrbarkeit analysierbar sein. Dennoch

sollten sie auch zur Laufzeit angepasst werden k¨

onnen. Weitere Aspekte, die bei ADEPT eine

große Rolle spielen, sind Performanz und Skalierbarkeit.

Abbildung 2.3: Knotenkonstrukte und Blockstruktur von Prozessen in ADEPT

Zur Modellierung von Prozessen verwendet ADEPT gerichtete Graphen, denen eine Block-

struktur zugrunde liegt. Den Knoten im Graphen sind Aktivit¨

aten des Prozesses zugeordnet.

Spezielle blockorientierte Knotenkonstrukte erlauben die Modellierung paralleler, alternativer

sowie zyklischer Abl¨

aufe.

Die Verwendung der Blockstruktur erlaubt somit auf einfache Weise die Modellierung von

Sub-Prozessen, da ein einzelner Knoten einen Sub-Prozess darstellen kann. Abbildung 2.3

zeigt die erw¨

ahnten Knotenkonstrukte und veranschaulicht die Blockstruktur von Prozessen

in ADEPT.

Da Aktivit¨

aten des Prozesses Knoten im Prozessmodell zugeordnet werden, ist es m¨

oglich,

Aktivit¨

aten auszutauschen, ohne Knoten des Prozessmodells entfernen und wieder einf¨

ugen

zu m¨

ussen. Die an Knoten hinterlegten Aktivit¨

aten wiederum k¨

onnen f¨

ur einen tats¨

achlichen

Dienst stehen, sei es die Methode einer Komponente, den Aufruf eines Programms oder einen

manuellen Arbeitsschritt. Die Aktivit¨

at dient dazu, interpretierbare Informationen ¨

uber den

dahinter stehenden Dienst erhalten zu k¨

onnen, wie z.B. Eingabe- und Ausgabeparameter.

Abbildung 2.4 veranschaulicht dieses Prinzip.

Abbildung 2.4: Zusammenhang zwischen Knoten, Aktivit¨

at und dahinterliegender Kompo-

nente

2.2.2 Kontroll- und Datenfluss

In ADEPT werden Kontroll- und Datenfluss explizit getrennt. Zun¨

achst wird im Folgen-

den auf den Kontrollfluss eingegangen. Im Anschluss daran wird der Datenfluss in ADEPT

behandelt.

Zum Kontrollfluss (kurz KF) geh¨

oren alle Konstrukte, welche die Abfolge der Aktivit¨

aten

bestimmen. Wie bereits erw¨

ahnt, handelt es sich bei ADEPT um einen blockbasierten Ansatz.

Bl¨

ocke werden durch ganze Prozesse sowie durch parallele, alternative und zyklische Abl¨

aufe

gebildet.

Als alternative Verzweigung erlaubt ADEPT XOR-Splits. Die Ausgangssemantik des XOR-

Split-Knotens wird auch als ONE OF ALL bezeichnet, da nur genau einer der ausgehenden

Kanten gefolgt wird. In Abbildung 2.5 stellt der Knoten dein XOR-Split und der Knoten g

den dazugeh¨

origen XOR-Join des Blocks der alternativen Verzweigung dar.

Ein paralleler Block wird durch einen AND-Split-Knoten eingeleitet, d.h. es wird allen

ausgehenden Kanten des AND-Splits gefolgt (ALL OF ALL Ausgangssemantik). In Abbil-

dung 2.5 stellt Knoten cein AND-Split dar, w¨

ahrend Knoten jden dazugeh¨

origen AND-Join

darstellt.

Zwischen Knoten in unterschiedlichen parallelen Zweigen besteht keine vorgegebene Aus-

f¨

uhrungsreihenfolge. In einigen Anwendungsszenarien ist jedoch eine Synchronisation paral-

leler Vorg¨

ange erforderlich. Diese Synchronisation kann allerdings unter Ber¨

ucksichtigung der

Blockstruktur nicht erfolgen. Kontrollkanten zwischen den Knoten von parallelen Zweigen

sind nicht zul¨

assig. Daher wurden in ADEPT sog. Synchronisationskanten eingef¨

uhrt. Diese

erlauben einen kontrollierten Bruch der Blockstruktur und erm¨

oglichen so eine Synchronisati-

on zwischen parallelen Ausf¨

uhrungszweigen. Knoten mit einer eingehenden Synchronisations-

kante k¨

onnen erst ausgef¨

uhrt werden, wenn der Knoten, von dem die Kante ausgeht, beendet

oder abgew¨

ahlt wurde. In Abbildung 2.5 wird Aktivit¨

at imit Aktivit¨

at funter Verwendung

einer Synchronisationskante (gestrichelter Pfeil) synchronisiert. Aktivit¨

at ikann daher erst

ausgef¨

uhrt werden, wenn Aktivit¨

at hund Aktivit¨

at fausgef¨

uhrt wurden oder wenn Aktivit¨

hausgef¨

uhrt wurde und Aktivit¨

at fnicht mehr ausf¨

uhrbar ist.

Abbildung 2.5: Alternative Verzweigung, parallele Verzweigung und Synchronisationskante

Ein spezieller Block kann durch einen einleitenden AND-Split und einen abschließenden

XOR-Join gebildet werden. Diese Kombination bildet eine parallele Verzweigung mit finaler

Auswahl. Dies bedeutet, dass zwar alle Zweige parallel gestartet werden, jedoch nur die Ergeb-

nisse (Daten) von einem Zweig ausgew¨

ahlt werden. Die Ergebnisse der abgew¨

ahlten Zweige

werden verworfen oder ignoriert.

Der Datenfluss (kurz DF) wird in ADEPT mit Datenkanten und Datenelementen explizit

modelliert. Eine Datenkante ist eine gerichtete Kante zwischen Knoten und Datenelement.

An einem Knoten eingehende Kanten bedeuten einen lesenden Zugriff, ausgehende Kanten

bedeuten einen schreibenden Zugriff. Der an einem Knoten hinterlegten Aktivit¨

at werden zur

Laufzeit die Werte der mit lesenden Kanten referenzierten Datenelemente als Eingabepara-

meter zur Verf¨

ugung gestellt. Analog werden die durch schreibende Kanten referenzierten

Datenelemente mit den Ausgabeparametern der Aktivit¨

at geschrieben. Abbildung 2.6 zeigt

einen Ausschnitt eines Prozesses mit Datenfluss.

Die explizite Modellierung des Datenflusses erm¨

oglicht Analysen auf Basis der Prozessvorlage.

Dadurch k¨

onnen Datenzugriffe bereits vor der Ausf¨

uhrung sichergestellt werden. Das Lesen

eines Datenelements, welches noch keine Daten enth¨

alt, wird so bereits zur Modellierungs-

zeit ausgeschlossen. In Abbildung 2.6 liest die Aktivit¨

at von Knoten adas Datenelement d1.

Abbildung 2.6: Ein Knoten mit lesender und schreibender Datenkante

Anhand des Kontrollflusses und der explizit modellierten Datenzugriffe, kann festgestellt wer-

den, ob eine weitere Aktivit¨

at das Datenelement vor dem lesenden Zugriff schreibt. Ist dies

der Fall, gilt der Eingabeparameter als versorgt und die Ausf¨

uhrung des Prozesses ist daher

m¨

oglich.

2.2.3 Ausf¨

uhrungszust¨

ande von Aktivit¨

aten

Zur Laufzeit einer Prozessinstanz befinden sich Aktivit¨

aten in unterschiedlichen Zust¨

anden.

Der Zustand der Ausf¨

uhrung wird durch Markierungen an Knoten und Kanten dargestellt. In

Abbildung 2.7 sind die wichtigsten Zust¨

ande in ADEPT veranschaulicht. Zun¨

achst befindet

sich eine Aktivit¨

at im Zustand NOT ACTIVATED. Im Zustand ACTIVATED befindet sich

eine Aktivit¨

at, wenn sie ausgef¨

uhrt werden kann. Der Zustand STARTED gibt an, dass sich

eine Aktivit¨

at in der Bearbeitung befindet. In den Zustand COMPLETED wird eine Aktivit¨

uberf¨

uhrt, wenn ihre Ausf¨

uhrung erfolgreich verlief. F¨

ur eine vollst¨

andige ¨

Ubersicht ¨

uber alle

m¨

oglichen Zust¨

ande wird auf die Arbeit von Reichert in [11, S. 90] verwiesen.

Abbildung 2.7: Darstellung der Zust¨

ande von Aktivit¨

aten

2.2.4 Konzepte zur Unterst¨

utzung von Adaptivit¨

Anpassungen an Prozessen werden in ADEPT auf drei Ebenen realisiert. ADEPT erm¨

oglicht

es Prozessvorlagen zu ¨

andern. Des Weiteren k¨

onnen diese ¨

Anderungen auch auf laufende

Instanzen der ge¨

anderten Vorlage ¨

ubertragen werden (Schemaevolution). Die dritte Ebene

sind ¨

Anderungen an einzelnen laufenden Instanzen (Adhoc-¨

Anderungen).

Als Grundlage dienen generische ¨

Anderungsoperationen, welche auf Prozesse und Instanzen

angewendet werden k¨

onnen. Diese Operationen lassen sich unter wohl definierten Vorausset-

zungen anwenden und liefern ausschließlich korrekte Graphen als Ergebnis.

Im Falle einer Schemaevolution wird so f¨

ur jede Instanz individuell und effizient festgestellt,

ob eine Migration der Instanz auf die modifizierte Prozessvorlage m¨

oglich ist. Ist dies der Fall,

kann die Instanz mit Hilfe der ¨

Anderungsoperationen automatisch an die ge¨

anderte Vorlage

angepasst werden. An dieser Stelle soll nicht n¨

aher auf das Thema eingegangen werden. Ein

einf¨

uhrender ¨

Uberblick ¨

uber das Thema findet sich in [15], n¨

aheres zu Adaptivit¨

at und proto-

typischer Implementierung in ADEPT findet sich in [13]. F¨

ur Details wird auf [16] verwiesen.

2.2.5 Definitionen und Notationen

Definitionen, die in dieser Diplomarbeit vorgestellt werden, erweitern oft Definitionen von

Reichert aus [11]. Da eine Ausf¨

uhrung der vollst¨

andigen Definition den Rahmen der Arbeit

sprengen w¨

urde, wird der Leser an gegebener Stelle auf die Arbeit von Reichert verwiesen.

Neue Definitionen in dieser Diplomarbeit lehnen sich in vereinfachter Form an die Notation

von Reichert an. Die Zugeh¨

origkeit zu einem Element wird durch die hochgestellte Abk¨

urzung

des Elements gekennzeichnet. So hat z.B. das Feld T ype eines Parameters Pdie Bezeichnung

T ypeP.

2.3 Komponententechnologie

Komponenten sind Anwendungen, welche sich als Teil in ein gr¨

oßeres System einf¨

ugen. Ins-

besondere in Betrieben kommen dadurch oft unterschiedlichste Anwendungen zum Einsatz.

Die Vorteile liegen dabei auf der Hand: Die Verwendung bereits vorgefertigter Komponenten

verspricht g¨

unstiger zu sein als die Entwicklung von eigenen Anwendungen.

Damit Komponenten und ihre Methoden verwendet werden k¨

onnen, m¨

ussen diese genau

beschrieben werden. Die Spezifikation einer Komponente kann als Vertrag angesehen werden,

an welchen sich die Komponente h¨

alt und worauf sich der Anwender verlassen kann. Ent-

wickler k¨

onnen dadurch die Funktionen unterschiedlicher Komponenten verstehen und durch

eigenen Code zusammenarbeiten lassen. Durch Komposition der Einzelteile entsteht eine neue

Anwendung, wobei der Code der Entwickler die Zusammenarbeit der Komponenten sicherge-

stellt [2].

F¨

ur die Spezifikation von Komponenten wurden unterschiedliche Beschreibungsmodelle ent-

wickelt. Dazu geh¨

oren z.B. die Interface Description Language (IDL) von CORBA [7] und

Enterprise JavaBeans [10]. Ziel dieser Beschreibungsmodelle ist eine Spezifikation, welche die

Verwendung der Komponente erm¨

oglicht, ohne ihre interne Funktionsweise kennen zu m¨

ussen.

Parallel zu den Bem¨

uhungen, die Zusammenarbeit und Verwendung von Komponenten zu

vereinfachen, haben sich die Beschreibungsmodelle auch zur allgemeinen Entwicklung von

Programmen etabliert. Durch eine m¨

oglichst genaue Spezifikation des zu erstellenden Pro-

gramms sollen m¨

ogliche Probleme bereits auf Ebene der Architektur gel¨

ost bzw. verhindert

werden. Das heute wohl wichtigste Modell f¨

ur die Softwareentwicklung ist die Unified Mode-

ling Language (UML) der Object Management Group (OMG), welche inzwischen in Version

2.0 verabschiedet wurde [8].

An dieser Stelle werden unterschiedliche Zielsetzungen bei der Spezifikation sichtbar. Auf

der einen Seite sollen Komponenten mit ihren Methoden m¨

oglichst pr¨

azise spezifiziert wer-

den, um ihre Verwendung ohne Kenntnis ¨

uber deren internen Aufbau zu erm¨

oglichen. Auf

der anderen Seite soll ein Programm, dieses als Komponente betrachtet, in seiner internen

Funktionsweise pr¨

azise beschrieben werden, um eine m¨

oglichst fehlerfreie Entwicklung zu ga-

rantieren. Im Zusammenhang mit UML werden diese zwei Sichten auch als Black Box und

White Box bezeichnet.

Es gibt unterschiedliche Wege eine Komponente zu spezifizieren. Grundlegend sind hierbei

die Fragen, welche Methoden zur Verf¨

ugung stehen und wie sie aufgerufen werden k¨

onnen.

Letzteres schließt die Signatur der Methoden mit ein, also Informationen ¨

uber Parameter

und Datentypen. Ein einfaches Beispiel f¨

ur eine Spezifikation sind Application Programming

Interface (API) Dokumentationen.

Kapitel 3

Plug & Play

Ein wichtiger Schritt bei der Umsetzung von Gesch¨

aftsprozessen in WfMS ist die Zuordnung

bzw. Auswahl der Arbeitsschritte, welche an den Knoten des Prozessmodells ausgef¨

uhrt wer-

den sollen. Da in ADEPT zwischen den Knoten im Prozessmodell und Aktivit¨

aten unterschie-

den wird, m¨

ussen Aktivit¨

aten an den Knoten hinterlegt werden. Daf¨

ur m¨

ussen Aktivit¨

aten

neu erstellt oder bestehende Aktiv¨

aten wiederverwendet werden. Dieser Vorgang soll sich f¨

den Benutzer m¨

oglichst einfach gestalten. Aktivit¨

aten sollen sich nach dem Prinzip des Plug

& Plays einfach an einen Knoten ”einstecken“ lassen. In Abbildung 3.1 werden u.a. Methoden

einer Lagerverwaltung aus einem Aktivit¨

aten-Repository (ein Pool von bereits bestehenden

Aktivit¨

aten bzw. Komponenten) als Aktivit¨

aten an Knoten hinterlegt.

Unter Plug & Play versteht man das dynamische und fehlerfreie Zusammenspiel unter-

schiedlicher Komponenten. Im Kontext von Betriebsanwendungen bilden unterschiedliche

Systeme die verwendeten Komponenten. Dazu geh¨

oren z.B. Systeme zur Warenwirtschaft,

zur Lagerverwaltung oder Buchhaltung. Das Zusammenspiel dieser Komponenten wird heute

Abbildung 3.1: Aktivit¨

aten werden mittels Plug & Play an Knoten hinterlegt

oft durch statische Programmierung erreicht. Unter dem Hintergrund von Arbeitsabl¨

aufen,

welche aus unterschiedlichen Gr¨

unden dynamisch ge¨

andert werden m¨

ussen, ist diese feste

Verschaltung jedoch hinderlich. Ebenso problematisch ist dies, wenn Komponenten ge¨

andert

oder ausgewechselt werden sollen. Abhilfe versprechen hier adaptive WfMS wie ADEPT, wel-

che nicht nur ¨

Anderungen an den Abl¨

aufen sondern auch den dynamischen Austausch der

Komponenten erlauben. Mittels Plug & Play soll dies einfach und und vor allem auch feh-

lerfrei m¨

oglich sein. Denn trotz der erlaubten Dynamik m¨

ussen diese Systeme zuverl¨

assig

arbeiten [2].

In den n¨

achsten beiden Abschnitten wird auf die Bedeutung von Plug & Play bei Soft-

warekomponenten und in WfMS n¨

aher eingegangen. Abschnitt 3.3 wird sich n¨

aher mit Zu-

sammenh¨

angen und Abh¨

angigkeiten zwischen Komponenten besch¨

aftigen, welche das Zusam-

menspiel der Aktivit¨

aten beeintr¨

achtigen k¨

onnten. Nachdem in Abschnitt 3.5 weitere Aspekte

und Anforderungen erl¨

autert werden, werden in Abschnitt 3.7 semantische und funktionale

Aspekte voneinander abgegrenzt. Das Kapitel schließt in Abschnitt 3.8 mit einer Zusammen-

fassung und einem Ausblick auf weitere Inhalte der Diplomarbeit.

3.1 Plug & Play und Softwarekomponenten

Um zwischen Softwarekomponenten Plug & Play zu erm¨

oglichen, ist eine API Dokumentation

nicht ausreichend. Hier wird eine durch Maschinen verarbeitbare Komponentenbeschreibung

ben¨

otigt sowie ein System, welches die Kommunikation zwischen den Komponenten verein-

heitlicht (sog. Middleware). Zur Spezifikation der Komponenten gibt es unterschiedliche Mo-

delle und Sprachen. Erw¨

ahnenswert sind aus diesem Bereich die Interface Definition Language

(IDL) aus CORBA, die Web Service Description Language (WSDL) aus dem Bereich der Web

Services, die Beschreibung von Enterprise Java Beans (EJB) sowie die IDL von Microsofts

DCOM.

Mit diesen Modellen k¨

onnen zumindest Komponenten, Typen, Methoden und Parameter

beschrieben werden. Dabei werden Methoden der Komponenten zumeist sehr isoliert betrach-

tet. Die Methoden werden meistens als zustandslos angesehen und h¨

angen ausschließlich von

den ¨

ubergebenen Daten ab. In vielen F¨

allen reicht diese Betrachtungsweise jedoch nicht aus:

Da es sich bei Komponenten um komplexe Anwendungssysteme handelt, kann die Ausf¨

uhrung

der Methoden vom Zustand der Komponente oder von zus¨

atzlichen internen Daten abh¨

angig

sein. Dadurch k¨

onnen Methoden nur unter bestimmten Voraussetzungen aufrufbar sein, also

z.B. Aufrufreihenfolgen voraussetzen. Einige der genannten Beschreibungsmodelle bieten un-

teschiedliche Mittel an, um solchen Abh¨

angigkeiten zu begegnen. Speziell f¨

ur Web Services

kann z.B. die Web Services Conversation Language (WSCL), eine Erweiterung zur WSDL,

eingesetzt werden. Diese bietet u.a. eine M¨

oglichkeit zur Modellierung von Aufrufabfolgen

an [14].

Uber entsprechende Beschreibungen erhofft man sich m¨

oglichst reibungslose Komposition

und Austausch von Komponenten. Middleware bietet hierf¨

ur eine gemeinsame Platform und

die notwendigen Kommunikationswege. Hierbei muss jedoch beachtet werden, dass die Spe-

zifikation der Komponenten mit unterschiedlichen Beschreibungsmodellen erfolgt sein kann.

In der Forschung werden daher weiterf¨

uhrende Spezifikationen entwickelt, welche zus¨

atzliche

Abh¨

angigkeiten beschreiben k¨

onnen und vorhandene Beschreibungsmodelle vereinheitlichen.

In [17] werden weitere Informationen zum Thema Komponenten und Middleware gegeben

und ein Meta-Beschreibungsmodell f¨

ur Komponenten vorgeschlagen. Ein umfassendes Modell

zur Spezifikation von Komponenten wird in [3] vorgestellt, ein ¨

Uberblick ¨

uber den Ansatz ist

in [6] zu finden.

3.2 Plug & Play mit Komponenten in Workflow-Management-

Systemen

Werden Arbeitsabl¨

aufe durch ein WfMS unterst¨

utzt, m¨

ussen Komponenten und Methoden

ausgew¨

ahlt und mit Hilfe des Prozessmodells miteinander verschaltet werden. Durch ”Plug

& Play“-Techniken soll das Auffinden und Verschalten der Komponenten f¨

ur den Benutzer

vereinfacht werden. Dabei ist es wichtig, dass die Komposition fehlerfrei funktioniert und

daf¨

ur notwendige Pr¨

ufungen f¨

ur den Benutzer transparent vonstatten gehen.

Die Abl¨

aufe werden i.A. von Prozess-Designern erstellt. Normale Benutzer des Systems

k¨

onnen die Abl¨

aufe jedoch, z.B. durch Adhoc-¨

Anderungen, beeinflussen. In beiden F¨

allen

m¨

ussen die Anwender die gew¨

unschten Aktivit¨

aten in einem Repository auffinden, um diese

dann in den Prozess einzusetzen. Daraufhin muss ¨

uberpr¨

uft werden, ob die Aktivit¨

aten in der

vom Benutzer vorgeschlagenen Komposition ausgef¨

uhrt werden k¨

onnen, oder ob z.B. noch

Daten zur Ausf¨

uhrung fehlen. Diese ¨

Uberpr¨

ufung ist notwendig, da die Komposition nicht

durch Entwickler geschieht, die sich in APIs, formelle und informelle Spezifikationen einle-

sen k¨

onnen. Insbesondere Benutzer des WfMS haben keinen ¨

Uberblick ¨

uber Zusammenh¨

ange

zwischen den Aktivit¨

aten oder gar ¨

uber Details ihrer internen Funktionsweise. W¨

ahrend der

Prozess-Modellierung und bei Adhoc-¨

Anderungen zur Laufzeit, muss eine ¨

Uberpr¨

ufung, ob ei-

ne Aktivit¨

at zu den gegebenen Bedingungen ausf¨

uhrbar ist, m¨

oglich sein. Die daf¨

ur ben¨

otigten

Informationen m¨

ussen f¨

ur das WfMS aus einer Beschreibung der Komponenten bzw. der ein-

zelnen Aktivit¨

aten ableitbar sein.

An dieser Stelle muss jedoch zwischen zwei unterschiedlichen Aspekten im Einsatz der

Komponentenbeschreibungen in WfMS unterschieden werden. Auf der einen Seite m¨

ussen

die Benutzer in der Auswahl der Aktivit¨

aten unterst¨

utzt werden. Daf¨

ur muss das WfMS

dem Benutzer verf¨

ugbare Informationen zur Verf¨

ugung stellen, jedoch gleichzeitig auch die

Beschreibungen selbst auswerten, um sinnvolle Vorschl¨

age bzgl. der Aktivit¨

atenauswahl ma-

chen zu k¨

onnen. Auf der anderen Seite ist es notwendig, dass das WfMS die Komposition

der Aktivit¨

aten auf Fehler ¨

uberpr¨

uft. Diese ¨

Uberpr¨

ufung muss erfolgen, wenn der Prozess

durch Komposition von Aktivit¨

aten erstellt wird oder ¨

Anderungen (z.B. Adhoc-¨

Anderungen)

erf¨

ahrt.

F¨

ur Softwarekomponenten existieren unterschiedliche formale Beschreibungsmodelle. F¨

den Einsatz der Komponenten in einem WfMS muss das System diese Beschreibung aus-

werten k¨

onnen. Eine minimale Voraussetzung ist hier die Interpretation von Schnittstellen-

Beschreibungen. W¨

ahrend es bei der Entwicklung von Software m¨

oglich ist, sich auf ein Be-

schreibungsmodell festzulegen, muss ein WfMS die Beschreibung unterschiedlichster Kompo-

nenten interpretieren k¨

onnen. Daf¨

ur gibt es grunds¨

atzlich zwei M¨

oglichkeiten: Komponenten

m¨

ussen f¨

ur den Einsatz erneut f¨

ur das WfMS beschrieben werden. Die Alternative ist die

Formulierung einer abstrakten Schnittstelle f¨

ur Anfragen an unterschiedliche Beschreibungs-

modelle. In beiden F¨

allen wird ein abstraktes Beschreibungsmodell ben¨

otigt, auf dem das

WfMS arbeiten kann. Im Vergleich zur Softwareentwicklung, stellen WfMS jedoch weitere

Anforderungen an das Beschreibungsmodell.

Ein Beschreibungsmodell zur Softwareentwicklung sollte eine umfangreiche und detaillierte

Modellierung erm¨

oglichen, vor allem auch ¨

uber die internen Zusammenh¨

ange der Komponente

(White Box). Diese Informationen dienen der Erstellung der Komponente selbst. Sie werden

in bestimmten Situationen zur Analyse eingesetzt, i.A. jedoch von den Entwicklern verwendet.

Je nachdem, ob es um das Auffinden von Aktivit¨

aten oder die formale Analyse der Kompo-

sition geht, sind die Anforderungen an ein Beschreibungsmodell f¨

ur ein WfMS unterschiedlich.

Von Seiten des Aktivit¨

aten-Repositorys, welches die Benutzer bei der Auswahl der Aktivit¨

aten

unterst¨

utzt, besteht die Anforderung von informellen Beschreibungen. Neben informellen soll-

ten jedoch auch formale Beschreibungen vorhanden sein. Diese k¨

onnen vom WfMS interpre-

tiert werden, um sinnvolle Vorschl¨

age f¨

ur den Benutzer zu generieren. Dies ist bei Adhoc-

Anderungen f¨

ur normale Benutzer hilfreich, jedoch ebenso eine Unterst¨

utzung f¨

ur Prozess-

Designer. Letztere m¨

ussen jedoch auch tiefere Einblicke in die Funktion der Komponente

haben. F¨

ur sie k¨

onnen z.B. API Dokumentationen aus der Softwareentwicklung durchaus

hilfreich sein. W¨

ahrend der Modellierungszeit ist Performanz zweitrangig, daher sind hier

auch umfangreiche Beschreibungen einsetzbar.

Geht es um die Analyse der Komposition, so muss das Beschreibungsmodell eine formale

Spezifikation erm¨

oglichen. Die Informationen werden dabei haupts¨

achlich vom WfMS selbst

verwendet. Dies bedeutet, dass hier das Augenmerk auf eine performante und automatische

Verarbeitung gelegt werden muss. Die Spezifikation sollte daher nur die notwendigsten In-

formationen zur Verwendung der Komponente bereitstellen (Black Box). Zudem m¨

ussen die

erforderlichen Informationen w¨

ahrend der Analyse effizient abrufbar sein. Dies spielt insbe-

sondere bei Schemaevolution eine Rolle, wenn ¨

Anderungen vieler Instanzen eines Prozesses

eine effiziente ¨

Uberpr¨

ufung unumg¨

anglich machen. Eine zeitaufw¨

andige Anfrage an die Ak-

Abbildung 3.2: Zusammenh¨

ange im WfMS bez¨

uglich Aktivit¨

atenbeschreibungen

tivit¨

at bzw. das Aktivit¨

aten-Repository darf hier nicht notwendig sein. Vielmehr m¨

ussen die

entsprechenden Informationen in das Prozessmodell des WfMS integriert sein. F¨

ur das Be-

reitstellen der formalen Beschreibungen, sollten Prozess-Designer detaillierte Informationen

uber Komponenten und ihre Methoden im Aktivit¨

aten-Repository verwalten. Abbildung 3.2

fasst die Zusammenh¨

ange zwischen WfMS, Aktivit¨

aten-Repository und den Aufgaben der

Benutzer zusammen.

Im Folgenden Abschnitt wird ein ¨

Uberblick dar¨

uber gegeben, welche Aspekte von einem

Beschreibungsmodell f¨

ur Komponenten in einem WfMS abgedeckt bzw. ber¨

ucksichtigt werden

m¨

ussen. Da es Kern darum geht, wovon die Ausf¨

uhrbarkeit einer Aktivit¨

at abh¨

angig sein kann,

wird hier allgemein von ”Abh¨

angigkeiten“ gesprochen.

3.3 Abh¨

angigkeiten zwischen Aktivit¨

aten

Zur fehlerfreien Ausf¨

uhrung einer Aktivit¨

at m¨

ussen alle notwendigen Randbedingungen gege-

ben sein. Dies bedeutet in erster Linie, dass die Funktionalit¨

at jeder Aktivit¨

at, zu jedem ihrer

m¨

oglichen Ausf¨

uhrungszeitpunkte im Prozess, gew¨

ahrleistet sein muss. So muss z.B. sicher-

gestellt werden, dass die von ihr ben¨

otigten Daten zur Verf¨

ugung stehen. Die Abh¨

angigkeit

einer Aktivit¨

at von Daten ist jedoch nur einer von vielen Aspekten, die die Ausf¨

uhrbarkeit

von Aktivit¨

aten beeinflussen und daher bei der Umsetzung von Plug & Play ber¨

ucksichtigt

werden m¨

ussen.

In Gesch¨

aftsprozessen sind unz¨

ahlige Abh¨

angigkeiten zwischen Aktivit¨

aten denkbar, ins-

besondere wenn rein semantische Abh¨

angigkeiten hinzugenommen werden. Um dieses weite

Feld etwas ¨

ubersichtlicher zu gestalten und gleichzeitig einen systematischen ¨

Uberblick ¨

uber

verschiedene Abh¨

angigkeiten zu bieten, wird in diesem Abschnitt eine Klassifikation vorge-

schlagen. Das Augenmerk soll hier haupts¨

achlich auf funktionale Abh¨

angigkeiten gerichtet

sein, also auf Abh¨

angigkeiten, welche die Ausf¨

uhrbarkeit der Aktivit¨

at direkt betreffen.

Eine Aktivit¨

at kann f¨

ur ihre Ausf¨

uhrung verschiedene Voraussetzungen an ihre Umgebung

stellen. Diese lassen sich grob in Abh¨

angigkeiten von Daten, Ressourcen, anderen Arbeits-

schritten, Zeit, Zugriffsrechte sowie semantische Abh¨

angigkeiten einteilen. Im Weiteren wer-

den diese Abh¨

angigkeitsbeziehungen n¨

aher beschrieben und feiner unterteilt.

1. Abh¨

angigkeit von Daten

Eine grundlegende Abh¨

angigkeit stellt die Versorgung von Parametern dar. Dar¨

uber

hinaus k¨

onnen jedoch weitere Abh¨

angigkeiten bez¨

uglich Daten bestehen. Dabei muss es

sich nicht notwendigerweise um konkrete, im Sinne von durch das WfMS verwaltbare

Daten handeln. So k¨

onnte es sich bei Daten z.B. ebenso gut um ein Papierdokument

handeln, welches in einem manuellen Arbeitsschritt erzeugt wurde. Auch andere f¨

das WfMS unsichtbare Datenfl¨

usse (versteckte Datenfl¨

usse), wie sie auch unter Kompo-

nentenkompositionen vorkommen k¨

onnen, k¨

onnen die Ausf¨

uhrbarkeit von Aktivit¨

aten

bestimmen. Ebenso zu ber¨

ucksichtigen sind Daten, die lediglich in Form von Referenzen

vom WfMS im Datenfluss weitergereicht werden.

(a) Existenz der Daten

Beispiel: Die Aktivit¨

at ”E-Mail-Versand“ braucht die Daten ”E-Mail-Adresse“ und

”Nachricht“.

Die Aktivit¨

at h¨

angt also davon ab, dass bestimmte Daten verf¨

ugbar sind. Ob die-

se als durch das WfMS kontrollierbare Parameter ¨

ubergeben werden, ist hierbei

irrelevant.

(b) Typ der Daten

Beispiel: Das Datum ”E-Mail-Adresse“ der Aktivit¨

at ”E-Mail-Versand“ muss eine

E-Mail-Adresse sein.

Die Aktivit¨

at h¨

angt davon ab, dass Daten einem bestimmten Typ entsprechen.

Beispiel: F¨

ur die Aktivit¨

at ”Sicherer E-Mail-Versand“ m¨

ussen sich die Daten ”Nach-

richt“ im Zustand ”verschl¨

usselt“ befinden.

Die Aktivit¨

at h¨

angt davon ab, dass die Daten einer bestimmten Verarbeitung un-

terzogen wurden. Dies wird i.A. durch die Verarbeitung durch andere Aktivit¨

aten

erreicht.

(d) Ort der Daten

Beispiel: Die Aktivit¨

at ”Bestellung SAP“ muss ihre Daten vom SAP-Backend be-

ziehen k¨

onnen.

Beispiel: Die durch den Parameter ”Rechnungs-Nr.“ referenzierten Daten m¨

ussen

sich auf die DB2 Datenbank ”Archivierte Rechnungen“ beziehen.

Die vom WfMS gelieferten Daten sind lediglich eine Referenz auf die tats¨

achlichen

Daten: Die Aktivit¨

at kann Einschr¨

ankungen auf den Ort der Daten haben. Sie muss

sich darauf verlassen k¨

onnen, dass sich die Referenz auf ein bestimmtes Backend

bezieht. Als Backend sind hier u.a. Datenbanken, unterschiedliche Informationssy-

steme und Dateisysteme denkbar.

(e) Abh¨

angigkeiten unter den ben¨

otigten Daten

Beispiel: Der Parameter ”Lieferadresse“ muss sich auf die Bestellung ”Bestell-ID“

beziehen.

Es bestehen Abh¨

angigkeiten unter den Daten, die von einer Aktivit¨

at ben¨

otigt

werden. Dies tritt z.B. auf, wenn mehrere Daten ¨

ubergeben werden, welche Teil

einer Relationen aus einer Datenbank sind. Falls im Kontext eines Prozesses un-

terschiedliche Kombinationen von Datenelementen die Parameter erf¨

ullen w¨

urden,

muss sichergestellt werden, dass die Daten den richtigen Bezug haben.

(f) Abh¨

angigkeiten unter Parametern

Beispiel: Vergleichbar mit Shell-Kommandos: Ein optionaler Parameter macht einen

weiteren Parameter obligat.

Eine Aktivit¨

at hat unterschiedliche Ausf¨

uhrungsm¨

oglichkeiten. Die Auswahl, wel-

che Ausf¨

uhrungsart wahrgenommen wird, erfolgt durch das Setzen entsprechender

Parameter. Je nach Ausf¨

uhrungsart werden unterschiedliche Parameter optional

oder obligat sein. Eine Aktivit¨

at mit solchen Abh¨

angigkeiten l¨

asst sich in mehrere

Aktivit¨

aten aufteilen. Dieser L¨

osungsansatz kann jedoch bei komplexen Parameter-

Konstrukten schnell un¨

ubersichtlich werden.

2. Abh¨

angigkeit von Ressourcen

Die Verwaltung von Ressourcen ist ein sehr weites Gebiet und umfasst Bereiche, wie die

Verwaltung von G¨

utern und Maschinen. Im Allgemeinen sind Ressourcen an einen Ort

gebunden, k¨

onnen jedoch verschiedenste relevante Eigenschaften besitzen. Diese Eigen-

schaften k¨

onnen Bedingungen zur Ausf¨

uhrung einer Aktivit¨

at sein. Dadurch sind f¨

alle Ressourcen komplexe Abh¨

angigkeiten m¨

oglich, vergleichbar mit Bearbeiterzuord-

nungsregeln. Hier sind sehr viele Abh¨

angigkeiten denkbar. In dieser Diplomarbeit soll

jedoch nicht weiter darauf eingegangen werden.

(a) G¨

uter

Beispiel: Die Waren aus der Artikelliste m¨

ussen zum Versand bereit sein.

Die Aktivit¨

at h¨

angt also davon ab, dass bestimmte G¨

uter an einem bestimmten

Ort vorhanden sind (z.B. Lager) und versendet werden k¨

onnen.

(b) Ger¨

ate/Werkzeuge/Maschinen

Beispiel: Die Aktivit¨

at ”Serienbrief drucken“ ben¨

otigt einen ”Laser-Drucker“

Die Aktivit¨

at verwendet bestimmte Objekte. Diese m¨

ussen daher verf¨

ugbar sein.

Beispiel: ”Ein Mitarbeiter der Verwaltung mit Prozess¨

anderungsrechten“

Die Aktivit¨

at ist davon abh¨

angig, dass Bearbeiter mit entsprechenden Qualifika-

tionen auch vor Ort sind.

(d) Ressourcen-Eigenschaften

Jede Ressource kann unterschiedliche Eigenschaften haben, welche von Aktivit¨

aten

gefordert werden k¨

onnen. So kann z.B. ein Drucker Farbe oder nur Schwarz drucken,

einen bestimmten Seitendurchsatz haben und unterschiedliche Papierformate und

-st¨

arken bedrucken. ¨

Ahnlich wie zustandsbehaftete Daten k¨

onnen auch Ressour-

cen Zust¨

ande besitzen. Ein Drucker hat u.a. die Zust¨

ande ”Aus“, ”Bereit“ und

”Fehler“.

3. Abh¨

angigkeiten von Vorg¨

angen

Allgemeine Vorg¨

ange k¨

onnen ebenfalls Abh¨

angigkeiten bewirken, die von den bisher

genannten Abh¨

angigkeiten nicht abgedeckt werden.

(a) Abh¨

angigkeit von anderen Vorg¨

angen: Vorher/Nachher-Beziehungen

Beispiel: Vor ”Rechnung versenden“ muss ”Rechnung drucken“ erfolgen.

Die Aktivit¨

at ist davon abh¨

angig, dass andere Vorg¨

ange/Aktivit¨

aten auch aus-

gef¨

uhrt werden. Dabei handelt es sich nicht um eine Abh¨

angigkeit durch einen

Datenfluss oder durch Ressourcen.

(b) Abh¨

angigkeit von anderen Vorg¨

angen: Ergebnis

Beispiel: Die Aktivit¨

at ”Kredit erteilen“ setzt das Ergebnis ”Antrag genehmigt“ der

Aktivit¨

at ”Kreditantragspr¨

ufung“ voraus.

Die Ausf¨

uhrbarkeit einer Aktivit¨

at kann auch von Ergebnissen anderer Aktivit¨

aten

abh¨

angen. So kann eine Aktivit¨

at fordern, dass eine weitere Aktivit¨

at mit einem

bestimmten Status beendet wurde.

angigkeit durch interne Vorg¨

ange: Ausf¨

uhrungsh¨

aufigkeit

Beispiel: ”Mahnung versenden“ darf h¨

ochstens 3 mal ausgef¨

uhrt werden.

Die Aktivit¨

at darf aus internen Gr¨

unden nicht mehrmals ausgef¨

uhrt werden. Dies

kann sich z.B. aus einem internen Zustand ergeben. Im Beispiel ist ein solcher

interner Zustand dadurch gegeben, dass h¨

ochstens drei Male gemahnt wird.

4. Zeitliche Abh¨

angigkeiten

Zeitliche Abh¨

angigkeiten k¨

onnen grundlegend in zwei Klassen unterteilt werden: Ab-

h¨

angigkeiten, welche im Zusammenhang mit anderen Abh¨

angigkeiten oder Aktivit¨

aten

auftreten, und aktivit¨

ateninterne Abh¨

angigkeiten. Insbesondere durch Schleifen und pe-

riodische Zeitangaben k¨

onnen sehr komplexe Abh¨

angigkeiten entstehen. Beispielhaft

sollen im Folgenden zwei typische Abh¨

angigkeiten erl¨

autert werden.

(a) Min/Max-Abst¨

ande

Beispiel: Die Daten des Parameters ”Blutbild“ d¨

urfen nicht ¨

alter als ein Tag sein.

Beispiel: Die Ressource ”Drucker“ muss f¨

ur mindestens drei Stunden verf¨

ugbar

sein.

Beispiel: Der Vorgang ”Mahnung versenden“ darf fr¨

uhestens drei Wochen nach

”Rechnung versenden“ ausgef¨

uhrt werden.

Die aufgef¨

uhrten Beispiele zeigen zeitliche Minimal- und Maximalabst¨

ande in Kom-

bination mit unterschiedlichen anderen Abh¨

angigkeiten.

(b) Aktivit¨

ateninterne zeitliche Abh¨

angigkeiten

Beispiel: ”L¨

ocher bohren“ darf max. drei Stunden durchgehend laufen (sonst l¨

auft

der Bohrer heiß).

Beispiel: ”Datenversand an das DATEV RZ“ ist nur zwischen 6 und 8 Uhr m¨

oglich.

Die Ausf¨

uhrung von Aktivit¨

aten kann zeitliche Einschr¨

ankungen haben. M¨

oglich

sind z.B. Laufzeiten, konkrete Termine und Wiederholungs- sowie Ruhezeiten.

5. Abh¨

angigkeiten durch Rechte

Auch Rechte stellen ein sehr weitreichendes Gebiet dar. Hier sollen zun¨

achst nur einige

wenige Anforderungen angesprochen werden, welche f¨

ur die Ausf¨

uhrung funktionalen

Charakter haben. Das allgemeine ”Recht zur Ausf¨

uhrung“ bzw. die Bearbeiterzuord-

nung geh¨

ort hier nicht dazu, da diese nicht unbedingt die Funktionalit¨

at einer Aktivit¨

beeintr¨

achtigen. Eine grundlegende funktionale Voraussetzung ist jedoch z.B., dass der

Bearbeiter die Rechte haben muss, um ben¨

otigte Daten zu lesen bzw. zu ¨

andern.

(a) Rechte zum Lesen/¨

Andern von Daten

Wenn eine Aktivit¨

at Daten ben¨

otigt oder schreibt, muss der Bearbeiter die ent-

sprechenden Rechte besitzen.

(b) Entscheidungsgewalt

Falls eine Aktivit¨

at bei einer alternativen Verzweigung ¨

uber den weiteren Verlauf

entscheidet, muss der Bearbeiter auch die entsprechenden Rechte f¨

ur die Entschei-

dung besitzen. Gleiches gilt auch bei vormodellierten Sprung- und Fehlerkanten.

Beispiele f¨

ur Entscheidungsbefugnis sind einfach zu finden, so z.B. in einem Kran-

kenhaus im Prozess zur Behandlung eines Patienten. Dieser Aspekt ist insofern

funktional, da die Aktivit¨

at selbst vielleicht von jedem Bearbeiter ausgef¨

uhrt wer-

den k¨

onnte, es jedoch bestimmte Qualifikationen f¨

ur eine korrekte Entscheidung

bedarf.

6. Semantische Abh¨

angigkeiten

Als semantische Abh¨

angigkeiten werden hier Abh¨

angigkeiten bezeichnet, welche f¨

ur die

Funktion einzelner Aktivit¨

aten keine Rolle spielen. Ein Beispiel hierf¨

ur ist die Unver-

tr¨

aglichkeit zwischen unterschiedlichen Medikamenten.

Unter den vorgestellten Abh¨

angigkeitsklassen sind unterschiedliche Kombinationen m¨

oglich.

So kann es f¨

ur die Ausf¨

uhrung einer Aktivit¨

at z.B. erforderlich sein, dass ihre Eingabedaten

einem bestimmten Typ entsprechen und sich dar¨

uber hinaus noch in einem bestimmten Zu-

stand befinden. Ein weiteres Beispiel sind Anforderungen an die Ausf¨

uhrungsh¨

aufigkeit, die

sich auf eine andere Aktivit¨

at beziehen: Die Aktivit¨

at, um Geld ¨

uber eine Rechnung gericht-

lich einzufordern, h¨

angt davon ab, dass zuvor die Aktivit¨

at, um Mahnungen zu verschicken,

drei Male aufgerufen wurde.

Die Relevanz der in diesem Abschnitt vorgestellten Abh¨

angigkeiten muss an realen Pro-

zessen ¨

uberpr¨

uft werden. Da die Integration der Abh¨

angigkeiten auch einen Mehraufwand

in der Modellierung und Analyse von Prozessen bedeutet, scheint eine Beschr¨

ankung auf

die im realen Fall ben¨

otigten Abh¨

angigkeiten sinnvoll. Die vorgestellte Klassifikation erhebt

keinen Anspruch auf Vollst¨

andigkeit. Dennoch bietet sie eine Grundlage, um Probleme oder

Teilprobleme einzuordnen.

3.4 Beispiele

Nachdem im vorhergehenden Abschnitt Abh¨

angigkeiten vorgestellt wurden, werden einige

von ihnen im Folgenden an Beispielprozessen veranschaulicht.

Vorlauf Der Prozess beschreibt den Teil eines Buchhaltungsvorgangs in der Bearbeitung

eines Vorlaufs.

Abbildung 3.3: Bearbeitung eines Vorlaufs in einem Buchhaltungsvorgang

Wie in Abbildung 3.3 angedeutet, verwendet die Aktivit¨

at ”Kontoausz¨

uge verarbeiten“ Da-

ten, die von der Aktivit¨

at ”Kontoausz¨

uge einlesen“ bereitgestellt werden. Der Datenfluss wird

jedoch nicht durch das WfMS verwaltet sondern erfolgt intern. Des Weiteren werden die Daten

(hier die Kontoausz¨

uge) durch die verarbeitende Aktivit¨

at gel¨

oscht. Wenn die Kontoausz¨

uge

also ein weiteres Mal verarbeitet werden sollen, m¨

ussen sie zuerst erneut eingelesen werden.

Eine besondere Bedeutung hat die Aktivit¨

at ”Vorlauf festschreiben“. Nach ihrer Ausf¨

uhrung

k¨

onnen und d¨

urfen die Daten eines Vorlaufs nicht mehr ge¨

andert werden. Dies ist Vorausset-

zung, um den Vorlauf an DATEV ¨

ubertragen zu k¨

onnen. Dies bedeutet, dass keine Aktivit¨

mehr eingef¨

ugt werden darf, welche die Daten ¨

andert. Auf der anderen Seite muss das WfMS

es weiter erlauben, die Daten zu lesen, z.B. durch eine Aktivit¨

at, welche den Vorlauf aus-

druckt.

Eine zeitliche Abh¨

angigkeit ist in der Aktivit¨

at zur ¨

Ubertragung an DATEV zu finden. Die

Ubertragung darf ausschließlich zu bestimmten Tageszeiten stattfinden.

Angebot Bei diesem Prozess (Abbildung 3.4) handelt es sich um einen Ausschnitt aus

einem Ablauf f¨

ur ein Angebot aus dem B2B-Bereich. Auf Anfrage des Kunden wird ein An-

gebot erstellt, von h¨

oherer organisatorischer Instanz kontrolliert und schließlich dem Kunden

ubermittelt. Dies wiederholt sich, bis der Kunde das Angebot akzeptiert und keine weiteren

Anderungsw¨

unsche hat. Daraufhin wird abgewartet, ob der Kunde aufgrund des Angebots

eine Bestellung in Auftrag gibt.

In diesem Beispiel sind semantische Abh¨

angigkeiten zu erkennen. So sollte es nicht m¨

oglich

sein, einem Kunden ein Angebot zuzusenden, welches noch keiner Durchsicht unterzogen wur-

de. Aus funktionaler Sicht ist diese Aktivit¨

at nicht notwendig, dennoch ist es ein f¨

ur die Firma

wichtiger Vorgang.

Abbildung 3.4: Erstellen eines Angebots

3.5 Weitere Aspekte und Anforderungen

Neben den vorgestellten Abh¨

angigkeiten k¨

onnen weitere Forderungen von Seiten der Ak-

tivit¨

aten bestehen. So kann z.B. die Ausf¨

uhrung einer Aktivit¨

at einer bestimmten Version

vorausgesetzt werden. Ebenso k¨

onnen ”weiche“ Abh¨

angigkeiten bestehen, d.h. der Benutzer

kann im konkreten Fall entscheiden, ob die Abh¨

angigkeit f¨

ur die Ausf¨

uhrung relevant ist.

Bedingte Abh¨

angigkeiten Abh¨

angigkeiten k¨

onnen unter Voraussetzung einer anderen

Abh¨

angigkeit bestehen. Beispiel: Falls ”Ware nachbestellt“ ausgef¨

uhrt wurde, muss vor ”Be-

stellte Artikel versenden“ auch ”Wareneingang best¨

atigen“ ausgef¨

uhrt worden sein. Um Ab-

h¨

angigkeiten dieser Art zu ber¨

ucksichtigen, ist ein Konzept mit gemeinsamen Schnittstellen

zur Repr¨

asentation notwendig. Auf dieser Basis ließen sich zusammengesetzte Abh¨

angigkeiten

durch entsprechende Regeln definieren. Auf die Definition und Interpretation solcher Regeln

soll in dieser Diplomarbeit jedoch nicht weiter eingegangen werden, da die entsprechenden

Grundlagen noch geschaffen werden m¨

ussen.

Erkl¨

arungen von Seiten des Systems Die Abh¨

angigkeiten und v.a. auch die Begr¨

undung,

warum sie im konkreten Fall verletzt werden, m¨

ussen f¨

ur den Benutzer von Seiten des Sy-

stems verst¨

andlich gemacht werden. Je komplexer die Abh¨

angigkeiten gestaltet werden, desto

besser m¨

ussen sie auch erkl¨

art werden. Das spielt auch f¨

ur den Prozess-Designer beim Model-

lieren komplexer Prozesse eine Rolle. Besonders wichtig sind Erkl¨

arungen jedoch bei Adhoc-

Anderungen, welche von normalen Benutzern durchgef¨

uhrt werden. Zus¨

atzlich zur Erkl¨

arung

sollten bei Verletzung von Abh¨

angigkeiten auch L¨

osungsm¨

oglichkeiten vorgeschlagen werden.

Kontrolle ¨

uber die Einhaltung von Abh¨

angigkeiten Manche Abh¨

angigkeiten lassen

sich zur Laufzeit nicht durch das WfMS kontrollieren. Im Gegensatz dazu l¨

asst sich z.B.

das Schreiben eines vom WfMS verwalteten Datums ¨

uberpr¨

ufen, so dass im Fehlerfall die

Ausf¨

uhrung ausgesetzt werden kann. Dies ist jedoch nicht bei allen Abh¨

angigkeiten m¨

oglich.

Die Abh¨

angigkeiten k¨

onnen beschrieben werden. Anhand der Beschreibung k¨

onnen korrek-

te Prozesse modelliert werden. Das WfMS muss sich jedoch darauf verlassen, dass sich die

Aktivit¨

aten entsprechend ihrer Beschreibung verhalten. Wird die Aktivit¨

at ”Nachricht ver-

schl¨

usseln“ ohne Fehlermeldung beendet, muss das WfMS davon ausgehen, dass die Ver-

schl¨

usselung erfolgreich ausgef¨

uhrt wurde. Bei sicherheitskritischen Vorg¨

angen sollten jedoch

zus¨

atzliche Pr¨

ufroutinen den tats¨

achlichen Status der Abh¨

angigkeiten ¨

uberpr¨

ufen k¨

onnen.

3.6 Integration versteckter Datenfl¨

usse

Wie in Abschnitt 3.3 geschildert, k¨

onnen Aktivit¨

aten bestimmte Daten zur Ausf¨

uhrung vor-

aussetzen. In diesem Abschnitt werden versteckte Datenfl¨

usse, also Datenfl¨

usse, die nicht

durch das WfMS verwaltet werden, etwas n¨

aher betrachtet. Das Problem der versteckten

Datenfl¨

usse wird auch in [2] beschrieben. In [2] schlagen Acker et al. zudem eine L¨

osung

mittels virtueller Datenfl¨

usse vor. In diesem Abschnitt wird der Einsatz des vorgeschlage-

nen L¨

osungsansatzes in ADEPT untersucht. Der Abschnitt zeigt, wie die Beschreibung einer

Abh¨

angigkeit, durch minimale Anpassungen des Prozessmodells, in ein bestehendes WfMS

integriert werden kann.

Wie das Beispiel des Vorlauf-Prozesses (s. Abschnitt 3.4) der Steuerberatung zeigt, k¨

onnen

eine Reihe von Daten unter Aktivit¨

aten und Komponenten außerhalb des WfMS ausgetauscht

werden. Im konkreten Beispiel liest z.B. die Aktivit¨

at ”Kontoausz¨

uge abrufen“ Kontoausz¨

uge

in eine Datenbank ein. Die Aktivit¨

at ”Kontoausz¨

uge verarbeiten“ liest diese Daten wieder aus.

Der Datenfluss erfolgt absolut transparent f¨

ur das WfMS. Falls ein Benutzer die Aktivit¨

”Kontoausz¨

uge abrufen“ z.B. bei einer Adhoc-¨

Anderung l¨

oschen m¨

ochte, w¨

urde das WfMS

dies zulassen. Das WfMS ist nicht in der Lage, die Verletzung der Abh¨

angigkeit zu entdecken

und Vorschl¨

age zur Aufl¨

osung des Konflikts zu machen. Es ist leicht auszumalen, dass solche

verletzten Abh¨

angigkeiten kritische Fehler w¨

ahrend der Prozessausf¨

uhrung zur Folge haben

k¨

onnen.

Soll das WfMS mit versteckten Datenfl¨

ussen umgehen k¨

onnen, m¨

ussen Abh¨

angigkeiten, wel-

che durch versteckte Datenfl¨

usse entstehen, ebenso wie konkrete Datenfl¨

usse, auf Ebene der

Aktivit¨

aten modelliert werden.

Versteckte Datenfl¨

usse haben die gleichen Eigenschaften wie normale Datenfl¨

usse: Die Da-

ten werden von Aktivit¨

aten gelesen und geschrieben. Sie haben einen Datentyp und k¨

onnten

uber einen Bezeichner identifiziert werden. Um das Problem der versteckten Datenfl¨

usse zu

l¨

osen, liegt f¨

ur ADEPT daher eine L¨

osung auf Basis des vorhandenen Datenflussmodells na-

he. Wie in Abschnitt 2.2 geschildert, umfasst das Beschreibungsmodell der Aktivit¨

aten von

ADEPT eine vollst¨

andige L¨

osung f¨

ur normale Datenfl¨

usse. Das Modell wird daher um vir-

tuelle Datenelemente und virtuelle Parameter erweitert, wodurch ein sogenannter virtueller

Datenfluss modelliert werden kann. Konzepte und Eigenschaften, wie obligat vs. optional oder

die Nachforderbarkeit von Parametern, lassen sich ohne weiteres auf die virtuellen Konstruk-

te ¨

ubertragen. Dadurch lassen sie sich in vorhandenen Algorithmen genauso wie die nicht

virtuellen Konstrukte behandeln. Implementierungstechnisch bietet es sich an, die betrof-

fenen Konzepte um ein Attribut zu erweitern, welches ¨

uber die Virtualit¨

at Aufschluss gibt.

Von dem Attribut unabh¨

angige Algorithmen k¨

onnen so ohne ¨

Anderung ¨

ubernommen werden.

Zur Integration von virtuellen Datenfl¨

ussen wird die Definition eines Eingabe- bzw. Aus-

gabeparameters Pnach [11] um folgendes Attribut erweitert:

IsV irtualP={TRUE oder FALSE }

Mit der Definition von Datenelementen wird analog verfahren. Abbildung 3.5 zeigt einen

Ausschnitt aus dem Beispielprozess der Steuerberatung (vgl. 3.4), in dem die Daten¨

ubergabe

der Kontoausz¨

uge ¨

uber einen virtuellen Datenfluss modelliert wird. F¨

ur die Darstellung von

virtuellen Datenelementen wird eine grau hinterlegte Variante vorgeschlagen.

Abbildung 3.5: Modellierung eines versteckten Datenflusses mit einem virtuellen Datenele-

ment

Mit Hilfe der virtuellen Datenelemente kann das WfMS ¨

uber versteckte Datenfl¨

usse in

Kenntnis gesetzt werden. Die Korrektheit des Datenflusses kann mit vorhandenen Algorith-

men sichergestellt werden. Zudem ist es aufgrund der Parameterbeschreibungen auch m¨

oglich,

dem Benutzer erkl¨

arende R¨

uckmeldungen zu Fehlern im Datenfluss zu geben.

Ein wichtiger Aspekt bleibt jedoch anzumerken: Im Unterschied zum normalen Datenfluss

entzieht sich der versteckte Datenfluss immer noch der Kontrolle des WfMS. Dies bedeutet,

dass sich das WfMS darauf verlassen muss, dass die Aktivit¨

aten die modellierten schreiben-

den Zugriffe t¨

atigt. Es kann nicht ¨

uberpr¨

uft werden, ob die Daten auch tats¨

achlich vorhanden

sind.

Neben der Modellierung von versteckten Datenfl¨

ussen k¨

onnen virtuelle Datenfl¨

usse auch

f¨

ur die Modellierung anderer Abh¨

angigkeiten eingesetzt werden. Damit ließen sich auf Ak-

tivit¨

atenebene auch explizite Forderungen ¨

uber vorher ausgef¨

uhrte Aktivit¨

aten stellen. Es

k¨

onnte ein spezieller Ausgabeparameter eingef¨

uhrt werden, der f¨

ur jede Aktivit¨

at einen schrei-

benden Zugriff auf ein virtuelles Datenelement beschreibt. Der Typ des virtuellen Datenele-

ments w¨

are dann genau der eindeutige Bezeichner der Aktivit¨

at. Damit w¨

are es m¨

oglich zu

modellieren, dass eine Aktivit¨

at die Ausf¨

uhrung einer anderen Aktivit¨

at erfordert. Dazu ist

lediglich ein obligater virtueller Eingabeparameter mit dem Typ der erforderlichen Aktivit¨

notwendig. Im Unterschied zu einer expliziten Modellierung eines solchen Zusammenhangs,

z.B. als kleiner Sub-Prozess, lassen sich auf diese Weise lose Abfolgen auf Ebene der Akti-

vit¨

aten modellieren. Die Ausf¨

uhrungsreihenfolge wird in diesem Fall durch den Datenfluss

bestimmt, wodurch nur die Reihenfolge der beteiligten Aktivit¨

aten festgelegt wird.

Da es sich in diesem Fall noch nicht einmal um einen versteckten Datenfluss handelt, ist

dies als eine rein semantische Erweiterung des Modells zu sehen. Dennoch k¨

onnen die da-

durch modellierten Abh¨

angigkeiten auch funktionalen Charakter haben. So k¨

onnte z.B. eine

Aktivit¨

at ”Paket versenden“ davon abh¨

angig sein, dass die Aktivit¨

at ”Paket zuschn¨

uren“ vor-

her ausgef¨

uhrt wurde. Abbildung 3.6 veranschaulicht die Aktivit¨

atenbeschreibungen und das

dazugeh¨

orige Prozessfragment.

Abbildung 3.6: Modellierung einer semantischen Abh¨

angigkeit durch einen virtuellen Daten-

fluss

Da es nicht m¨

oglich ist, den Datenfluss ¨

uber virtuelle Datenelemente durch das WfMS

zu kontrollieren, kann es zur Ausf¨

uhrungszeit zu Ausnahmesituationen kommen. Sobald ei-

ner Aktivit¨

at, z.B. durch einen Fehler in einer Komponente, Daten nicht zur Verf¨

ugung

stehen, ist die weitere korrekte Ausf¨

uhrung des Prozesses nicht mehr sichergestellt. Nicht

zuletzt bei gesch¨

afts- oder sicherheitskritischen Prozessen kann dies fatale Auswirkungen ha-

ben. Eine Erweiterung des Modells ist daher empfehlenswert. So k¨

onnten benutzerdefinierte

Pr¨

ufroutinen zugelassen werden, welche die f¨

ur das WfMS sonst transparenten Datenfl¨

usse

und Parameter¨

ubergaben sicherstellen. Zeigt die Pr¨

ufroutine einen Fehler an, kann das WfMS

die Ausf¨

uhrung des Prozesses an dieser Stelle aussetzen und den Prozessverantwortlichen in-

formieren.

3.7 Semantische und funktionale Aspekte

Die zu l¨

osenden und zu modellierenden Abh¨

angigkeiten umspannen ein sehr breit gef¨

achertes

Gebiet. Schon allein durch funkionale Aspekte wird ein großer Problemraum aufgespannt. Da

eine fehlerfreie Ausf¨

uhrung eine hohe Priorit¨

at hat, ist zun¨

achst eine Konzentration auf die

Funktionalit¨

at der Aktivit¨

aten angebracht.

Ob es sich bei einer Abh¨

angigkeit um einen funktionalen oder semantischen Aspekt handelt,

l¨

asst sich in vielen F¨

allen erst bei einer konkreten Implementierung sagen. Dadurch ergibt sich

eine sehr große Grauzone von Abh¨

angigkeiten, welche je nach Implementierung einen seman-

tischen oder funktionalen Charakter besitzen. Im Allgemeinen l¨

asst sich sagen, dass je mehr

sich eine Abh¨

angigkeit von syntaktischen Beschreibungen entfernt, desto unwahrscheinlicher

ist es, dass diese Abh¨

angigkeit funktionaler Natur ist.

Semantisch h¨

oherstehende Abh¨

angigkeiten ergeben sich z.B. durch notwendiges Hinter-

grundwissen. So k¨

onnten zwei Aktivit¨

aten zur Verabreichung von Medikamenten aus funktio-

naler Sicht einwandfrei hintereinander ausgef¨

uhrt werden. Bei entsprechenden Unvertr¨

aglich-

keiten zwischen den Medikamenten kann dies dennoch ein schwerwiegendes Problem darstel-

len. Die Last, das entsprechende Hintergrundwissen bereitszustellen und zu gebrauchen, liegt

bis heute in den meisten F¨

allen bei den Benutzern. Eine Unterst¨

utzung durch das WfMS ist

jedoch w¨

unschenswert, da, vor allem bei umfangreichen Prozessen, die wenigsten Benutzer

einen ¨

Uberblick ¨

uber den gesamten Prozess haben. Insbesondere da Prozesse durch Adhoc-

Anderungen auch von dem erwarteten Verlauf abweichen k¨

onnen.

Weitere Beispiele f¨

ur semantische Abh¨

angigkeiten lassen sich im Bereich allgemeiner Ge-

sch¨

aftsregeln (Business Rules) finden. Eine Aktivit¨

at um Mahnungen zu verschicken kann,

rein funktional betrachtet, eine beliebige Anzahl an Mahnungen erstellen. Dass nach genau

drei Mahnungen weitere Schritte eingeleitet werden sollen, kann rechtlich oder auch firmen-

politisch bedingt sein.

Die M¨

oglichkeiten, um funktionale und semantische Abh¨

angigkeiten zu integrieren, k¨

onnen

sich ¨

uberschneiden. Eine abstrakte semantische Beschreibung kann durchaus zur Modellierung

einer funktionalen Abh¨

angigkeit verwendet werden. Es muss daher unterschieden werden, ob

die Abh¨

angigkeit oder das Mittel zur Modellierung der Abh¨

angigkeit einen funktionalen bzw.

semantischen Charakter haben.

Ein typisches Beispiel f¨

ur eine Abh¨

angigkeit, welche in einer Grauzone zwischen Seman-

tik und Funktionalit¨

at liegt, findet sich auch im Beispiel des Vorlauf-Prozesses (s. 3.4). Ein

Vorlauf muss am Ende eines Prozesses entweder gel¨

oscht oder an DATEV ¨

ubertragen worden

sein. Durch entsprechende Adhoc-¨

Anderungen ließe sich eine Prozessinstanz beenden, ohne

dass dieses Kriterium erf¨

ullt ist. Das WfMS w¨

urde dies auch zulassen, da diese semantische

Information nicht bekannt ist. Dennoch kann dies in anderen Prozessinstanzen, z.B. bei der

Abrechnung, auch zu funktionalen Problemen f¨

uhren.

3.8 Zusammenfassung und weitere Inhalte der Diplomarbeit

Im bisherigen Teil der vorliegenden Diplomarbeit wurden Ziele der Anwendung von “Plug &

Play”-Konzepten in WfMS erl¨

autert. Dar¨

uber hinaus wurden Probleme bei der Umsetzung

dieser Konzepte er¨

ortert. Insbesondere wurden m¨

ogliche Abh¨

angigkeiten, die Aktivit¨

aten bzw.

Komponenten betreffen, identifiziert und klassifiziert.

Im Weiteren Verlauf dieser Arbeit soll eine der identifizierten Abh¨

angigkeiten n¨

aher un-

tersucht werden. Es sollen Konzepte erarbeitet werden, die eine Integration von zustands-

behafteten Daten in WfMS erlauben. Eine L¨

osung in dieser Richtung kann Grundlage f¨

die Integration weiterer Abh¨

angigkeiten sein, da es auf Zust¨

ande basierende Abh¨

angigkeiten

bzgl. Daten, Ressourcen und Komponenten gibt. Zustandsbehaftete Daten sind ein guter

Startpunkt, da auf Konzepte zur Datenflussmodellierung zur¨

uckgegriffen werden kann.

Die erarbeiteten Konzepte werden auf das WfMS ADEPT aufbauen. Durch die klare Struk-

turierung, die Unterscheidung zwischen Knoten und ihnen zugeordneten Aktivit¨

aten sowie

der expliziten Modellierung des Datenflusses bietet ADEPT eine hervorragende Grundlage.

Kapitel 4

Zustandsbehaftete Daten

Wie bereits in Kapitel 3 er¨

ortert, kann die Funktionalit¨

at einer Aktivit¨

at davon abh¨

angig

sein, dass ben¨

otigte Daten einer bestimmten Verarbeitung unterlaufen sind und sich dadurch

in einem bestimmten Zustand befinden. Dies zeigt sich auch in einem einfachen Beispiel,

wie dem Vorlauf-Prozess der Buchhaltung (s. Abschnitt 3.4). Bevor ein solcher Vorlauf an

DATEV ¨

ubermittelt werden kann, muss er festgeschrieben werden (”Vorlauf festschreiben“).

Das Festschreiben bedeutet, dass die Daten von keiner Aktivit¨

at mehr ge¨

andert werden d¨

urfen.

Dadurch ergeben sich zwei Datenzust¨

ande: ”festgeschrieben“ und ”nicht festgeschrieben“.

Solche Abh¨

angigkeiten m¨

ogen dem Prozess-Designer wohl bewusst sein, jedoch steht diese

Information dem WfMS nicht zur Verf¨

ugung. Dies hat zur Folge, dass das WfMS auch die

Ausf¨

uhrung eines Prozesses zul¨

asst, welcher, aufgrund einer verletzten Abh¨

angigkeit, keine

Aussicht auf eine korrekte Beendigung hat.

Das oben genannte Beispiel stellt sicherlich keinen Einzelfall dar. Vielmehr ist es nicht

schwer auszumalen, dass zustandsbehaftete Daten in vielen Prozessen eine Rolle spielen. Um

in vielen realen Anwendungszenarien eingesetzt werden zu k¨

onnen, ist es daher notwendig,

dass WfMS mit zustandsbehafteten Daten umgehen k¨

onnen. Im Folgenden wird in 4.1 auf

die daraus resultierenden Anforderungen eingegangen. Ein erster L¨

osungsansatz wird in 4.2

vorgestellt.

4.1 Anforderungen

Aus dem Beispiel mit dem Vorlauf ergeben sich zwei grundlegende Anforderungen zur Um-

setzung in einem WfMS. Zum einen muss es f¨

ur Aktivit¨

aten m¨

oglich sein, einen Zustand von

Daten zu fordern. Das bedeutet, die Ausf¨

uhrung darf nur dann erfolgen, wenn sich die Daten

im geforderten Zustand befinden. Des Weiteren m¨

ussen Aktivit¨

aten den Zustand von Daten

andern k¨

onnen. Um den Anforderungen zu entsprechen, ergeben sich weitere Anforderungen

von Seiten des WfMS. So muss es f¨

ur das WfMS m¨

oglich sein, den momentanen Zustand der

Daten zu ermitteln. Von den Aktivit¨

aten muss es zudem den neuen Datenzustand erfahren

und diesen f¨

ur die Daten setzen k¨

onnen.

Dies w¨

urde soweit gen¨

ugen, um zur Laufzeit festzustellen, ob eine Aktivit¨

at ausf¨

uhrbar

ist oder nicht. Da es w¨

ahrend der Ausf¨

uhrung eines Prozesses jedoch m¨

oglichst zu keinen

Uberraschungen kommen soll, muss es schon zur Modellierungszeit m¨

oglich sein, genaue Aus-

sagen zur Ausf¨

uhrbarkeit der Aktivit¨

aten zu treffen. Dies bedeutet, dass die Aktivit¨

aten vor-

geben m¨

ussen, unter welchen Datenzust¨

anden sie ausf¨

uhrbar sind und welche Datenzust¨

ande

sie bewirken.

4.2 Ein erster L¨

osungsansatz

Ausgehend von den beschriebenen Anforderungen l¨

asst sich ein einfacher Ansatz zur Integra-

tion von Datenzust¨

anden formulieren. Dazu wird zun¨

achst die Definition des Datenelements

erweitert. Es werden zwei neue Attribute ben¨

otigt: Eines, welches w¨

ahrend der Ausf¨

uhrung

den momentanen Zustand speichert, und ein weiteres, welches alle m¨

oglichen Zust¨

ande des

Datenelements enth¨

alt. Das Speichern aller existierenden Zust¨

ande ist nicht unbedingt not-

wendig. Dies ist jedoch hilfreich zur Erhaltung der Konsistenz und um das ¨

Uberblicken der

vorhandenen Zust¨

ande zu erleichtern.

Parameter und Datenkanten m¨

ussen um eine Zustandsforderung und eine optionale Zu-

stands¨

anderung erweitert werden. Da f¨

ur Parameter und Datenkanten gleiches gilt, wird an

dieser Stelle davon abstrahiert. Beschreibungen werden sich im Folgenden auf Parameter be-

ziehen, m¨

ussen jedoch ebenso auf Datenkanten angewandt werden. Die Datenkanten spielen

nur in der graphischen Darstellung eine weitere Rolle. Sie werden mit Zustandsforderung und

Zielzustand annotiert. Ein Zustand besteht ausschließlich aus einem eindeutigen Bezeichner.

Das Fordern und Setzen eines Zustands kann mit dem Lesen und Schreiben eines Datenele-

ments verglichen werden. Fordert eine Aktivit¨

at einen Zustand, so m¨

ochte sie exakt diesen

Wert vom Zustandsattribut des Datenelements lesen. Setzt eine Aktivit¨

at einen neuen Zu-

stand, so schreibt sie diesen Wert in das Attribut. Dadurch ist eine Erweiterung vorhandener

Algorithmen zur Sicherstellung der Korrektheit des Datenflusses mit wenig Aufwand verbun-

den.

Erweiterung des Datenelements (DataElement,DE):

CurrentStateDE ={UNDEFINED oder State }

StatesDE ={{ State }}

Erweiterung des Parameters P(bzw. Datenkanten):

StateP={UNDEFINED oder State }

Handelt es sich bei dem Parameter um einen Eingabeparameter, so ist StatePeine Zustands-

forderung. Im Falle eines Ausgabeparameters wird dieser Zustand gesetzt. Ist der Wert von

StatePUNDEFINED, bedeutet dies, dass die Aktivit¨

at vom Zustand der Daten unabh¨

angig

ist bzw. diesen nicht ¨

andert.

Abbildung 4.1 stellt eine abstrakte Darstellung der Beschreibung einer Aktivit¨

at dar. Zu der

Beschreibung von Eingabe (E) und Ausgabe (A) kommt der Bezeichner des Zustands hinzu.

Abbildung 4.1: Die Erg¨

anzung der Beschreibung einer Aktivit¨

at um Zustandsinformationen

Abbildung 4.2 zeigt anhand eines allgemeinen Beispiels, wie der Graph mit Zustandsforde-

rungen dargestellt wird. In diesem Fall wird von Knoten aein Zustand Z1im Datenelement

d1erzeugt. Knoten bfordert diesen Zustand.

Abbildung 4.2: Setzen und Fordern von Zust¨

anden

Der Ansatz bringt eine Einschr¨

ankung der Modellierung des Datenflusses mit sich: Am

abschließenden Knoten eines Blocks darf nur ein Zustand m¨

oglich sein. Dies bedeutet, dass

der letzte Zustand innerhalb eines alternativen Verzweigungsblocks immer der gleiche sein

muss. Notwendig ist dies, da ansonsten zur Modellierungszeit nicht sicher festzustellen ist,

welcher Zustand nach dem Block gesetzt ist. Eine darauffolgende Aktivit¨

at kann jedoch einen

einzelnen Zustand voraussetzen. In Anlehnung an die Datenfluss-Strukturierungsregeln DF-1

bis DF-3 aus [11] wird im Folgenden eine erg¨

anzende Regel DF-4* definiert.

Definition 4.1 (DF-4*). Wird in einer Oder-Verzweigung der Zustand eines Datenele-

ments dge¨

andert, muss am Ende des Blocks in allen Zweigen der gleiche Zustand gesetzt

sein.

F¨

ur parallele Verzweigungen sind keine weiteren Einschr¨

ankungen notwendig, da parallele

Schreibzugriffe durch DF-2 (s. [11, S. 122]) verhindert werden. Erlaubt hingegen sind paralle-

le Schreibzugriffe, deren Reihenfolge durch Synchronisationskanten festgelegt ist. Durch diese

Festlegung ist auch sichergestellt, dass am Ende eines parallelen Blocks immer der gleiche

Zustand gesetzt ist, auch wenn nicht jeder schreibende Zugriff den Zustand ¨

andert.

Auch im Falle von Schleifen muss der Datenfluss eingeschr¨

ankt werden. Hier gilt, dass am En-

de der Schleife der gleiche Zustand gelten muss wie zu Anfang. So kann sichergestellt werden,

dass der Zustand f¨

ur jede Schleifenausf¨

uhrung passend ist.

Definition 4.2 (DF-5*). Wird innerhalb eines Schleifenblocks der Zustand eines Daten-

elements dge¨

andert, muss am Ende eines Durchlaufs der Zustand des Datenelements wieder

gleich dem Zustand sein, der am Anfang des Blocks gegolten hat.

Die Versorgung eines Parameters mit Zustandsforderung muss algorithmisch sichergestellt

werden. Die Erweiterung des Algorithmus von Reichert in [11] ist minimal. Zum Wert der

Versorgung (Supplied, Counter) muss zus¨

atzlich noch der Wert des geschriebenen Zustands

weitergereicht werden. Da durch DF-4* am Ende eines Blocks immer nur ein einzelner Zustand

m¨

oglich ist, wird an dieser Stelle das Attribut h¨

ochstens mit dem gleichen Wert ¨

uberschrieben.

Auch muss der Algorithmus weiterhin nicht explizit mit Schleifen umgehen. Da durch DF-5*

zu Beginn und am Ende einer jeden Schleifenausf¨

uhrung der gleiche Zustand vorliegt, gen¨

ugt

ein einfaches Folgen des Kontrollflusses ohne Wiederholung, um den Zustand zu ermitteln.

Bei dem hier aufgef¨

uhrten Algorithmusteil handelt es sich um eine Erweiterung des Algorith-

mus 5-1 aus [11, S. 126]. Erg¨

anzungen sind fett gesetzt. Dieser Teil des Algorithmus besch¨

aftigt

sich mit Prozessen ohne Synchronisationskanten und dient hier dazu, zu zeigen, wie gering

die notwendigen ¨

Anderungen sind. Auch der vollst¨

andige Algorithmus erf¨

ahrt im Prinzip die

gleichen Anpassungen.

W riterExists(CF S, DF S, nread, d, state)

1. Bestimme die Menge c pred ∗(nread) aller Vorg¨

anger des Knotens nread (bzgl. Kon-

trollkanten des Typs CONTROL E) Initialisiere f¨

ur alle Knoten n∈Ndas Attribut

Supplied(n) mit F alse und den Z¨

ahler Counter(n) mit 0 und das Attribut State(n)

mit UNDEFINED.

2. Initialisiere die Menge der aktuell zu betrachtenden Knoten mit der leeren Menge:

NodeList =∅. F¨

ur jeden obligaten Schreibzugriff auf das Datenelement ddurch einen

Knoten n∈P red (bzw. einen vor-/nachgeschalteten Hilfsdienst von n) f¨

uhre die fol-

gende Anweisung aus: Inkrementiere f¨

ur jeden direkten Nachfolgerknoten n∗von n

(bzgl. Kanten des Typs CONTROL E), der innerhalb der Menge P red ∪ {nread}liegt,

den Z¨

ahler Counter(n∗) um 1, falls StatePvon nnicht UNDEFINED ist.Set-

ze State(n∗)auf StatePdes Ausgabeparameters von nund f¨

uge den Knoten n∗

der Menge NodeList hinzu. (NodeList enth¨

alt im Anschluß nur Knoten, f¨

ur die gilt:

dwird in mindestens einem der in diesen Knoten einm¨

undenden Ausf¨

uhrungszweige

sicher versorgt).

3. Falls NodeList =∅gilt, gehe zu Schritt 5. Andernfalls: Initialisiere die Menge der in der

n¨

achsten Iteration zu betrachtenden Knoten mit der leeren Menge (NewNodeList :=

∅). ¨

Uberpr¨

ufe f¨

ur jeden Knoten der Menge NodeList, ob bei seiner Aktivierung das

Datenelement dsicher versorgt ist: F¨

ur einen Knoten n∈NodeList trifft dies ge-

nau dann zu, wenn er entweder eine der beiden Eingangssemantiken ONE Of ONE

bzw. ALL Of ALL aufweist [vgl. (1)] oder wenn er die Eingangssemantik ONE Of ALL

besitzt und sein Z¨

ahler Counter(n) gleich der Anzahl der in neinm¨

undenden Kon-

trollkanten bzw. Teilzweige ist [vgl. (2)]. Ist eine dieser beiden Bedingungen erf¨

ullt, so

setze das Attribut Supplied(n) auf den Wert T rue und f¨

uhre f¨

ur jeden direkten Nach-

folger n∗von nwiederum die folgende Anweisung aus: Falls n∗ ∈ P red ∪nread und

Supplied(n∗) = F alse gilt, so erh¨

ohe den Z¨

ahler Counter(n∗) um 1, setze State(n∗)

auf StatePdes Ausgabeparameters von nund f¨

uge den Knoten n∗der Menge

NewNodeList (→duplikatfrei) hinzu.

4. Falls NewNodeList =∅oder Supplied(nread) = T rue gilt, so gehe zu Schritt 5. An-

dernfalls setze NodeList := NewNodeList und wiederhole Schritt 3 (d.h. propagiere

die Markierungen weiter entlang des Kontrollflusses).

5. Die Datenversorgung des obligaten Lesezugriffs von nread auf dist genau dann si-

cher gestellt, wenn f¨

ur die Markierung dieses Knotens Supplied(nread) = T rue gilt

(→Algorithmus liefert R¨

uckgabewert W riterExists(CF S, DF S, nread, d) = T rue).

Falls StatePvon nread ungleich UNDEFINED ist, muss zust¨

azlich State(nread)

gleich StatePvon nread sein. Andernfalls kann der Lesezugriff nicht in jedem Fall von

Vorg¨

angerknoten (bzgl. normaler Kontrollkanten) versorgt werden (→R¨

uckgabewert

W riterExists(CF S, DF S, nread, d) = F alse)

Durch das Festlegen der Zust¨

ande auf der Ebene von Aktivit¨

aten- und Prozessvorlagen

kann der momentane Zustand zu einem bestimmten Ausf¨

uhrungsschritt immer festgestellt

werden. Dies erm¨

oglicht nicht nur eine Pr¨

ufung zur Modellierungszeit, sondern ebenso auch

bei der Migration von laufenden Instanzen sowie Adhoc-¨

Anderungen durch den Benutzer.

4.3 Bewertung und weitere Anforderungen

Der vorgestellte Ansatz ist f¨

ur eine ¨

uberschaubare Menge von Zust¨

anden mit wenigen betei-

ligten Aktivit¨

aten gut einsetzbar. Abbildung 4.3 zeigt einen Ausschnitt des Vorlauf-Prozesses,

modelliert mit Zustandsforderungen und -¨

anderungen. Die Aktivit¨

at ”Vorlauf festschreiben“

fordert den Zustand ”r/w“ und ¨

andert diesen auf ”r/o“. Es handelt sich hierbei um zwei

Datenkanten; ”i:“ und ”o:“ stehen hier f¨

ur Eingabe bzw. Ausgabe.

Die Einsetzbarkeit des vorgestellten Ansatzes ist begrenzt. Probleme bereitet unter ande-

rem, dass es nicht m¨

oglich ist, die ¨

Uberg¨

ange zwischen Zust¨

anden einzugrenzen. So w¨

are z.B.

eine Aktivit¨

at einsetzbar, welche den Zustand der Daten auf ”r/w“ setzt, obwohl dies aus dem

Abbildung 4.3: Vorlaufprozess mit Zustandsattribut

Zustand ”r/o“ heraus nicht zul¨

assig w¨

are. Daher auch die Einschr¨

ankung auf wenige Zust¨

ande

und Aktivit¨

aten. Der Modellierer muss die Zusammenh¨

ange zwischen den Zust¨

anden selbst

im Auge behalten. Dazu geh¨

ort nicht nur, dass bestimmte Zust¨

ande nicht mehr erreicht wer-

den d¨

urfen. Bei mehreren Zust¨

anden ist auch eine Reihenfolge im Erreichen der Zust¨

ande

von Bedeutung. Dies kann schnell un¨

ubersichtlich werden und sollte daher durch das WfMS

unterst¨

utzt werden.

Eine weitere Schw¨

ache ist die Begrenzung der Parameterbeschreibungen auf einzelne Zust¨

ande.

So ist es z.B. denkbar, dass eine Aktivit¨

at zur Pr¨

ufung eines Kreditantrags, je nach Ausgang

der Beurteilung, ein Datum ”Antrag“ in einen anderen Zustand versetzt. Eine daraufhin fol-

gende Aktivit¨

at wiederum muss die M¨

oglichkeit haben, auf eine Auswahl dieser m¨

oglichen

Zust¨

ande reagieren zu k¨

onnen. Diese Beschr¨

ankung macht auch die Strukurierungsregeln zur

Verhinderung mehrfacher Zust¨

ande am Ende eines Blocks notwendig. Jedoch sind gerade an

dieser Stelle unterschiedliche Zust¨

ande typisch, dienen doch z.B. Oder-Verzweigungen auch

der Auswahl unterschiedlicher Verarbeitungswege der Daten.

Abbildung 4.4: Vorlaufprozess mit Zust¨

anden in einem virtuellen Datenelement

Eine Alternative zur Erweiterung des Datenelements soll der Vollst¨

andigkeit halber erw¨

ahnt

werden. Anstelle eines neuen Attributs mit dem Zustand w¨

are es auch denkbar, den bisher

nicht verwendeten Wert eines virtuellen Datenelements zu verwenden. Diese Idee wurde jedoch

schnell verworfen, da sie Probleme birgt. Falls Daten und Zustand in zwei unterschiedlichen

Datenelementen gespeichert w¨

urden, m¨

ussten diese einander Zugeordnet werden. So lange es

nur ein Datenelement vom gleichen Typ gibt, ist dies kein Problem. Sobald jedoch, z.B. durch

eine Adhoc-¨

Anderung, ein weiteres Datenelement eingef¨

ugt wird, muss diese Zuordnung bei

weiteren ¨

Anderungen u.U. von Hand geschehen. Ein weiterer Nachteil ist, dass beinahe doppelt

so viele Datenkanten ben¨

otigt werden, was die graphische Darstellung schnell un¨

ubersichtlich

werden l¨

asst. Abbildung 4.4 verdeutlicht die Situation.

Der Ansatz zur Formulierung virtueller Datenfl¨

usse bietet in der vorliegenden Form keine

M¨

oglichkeit, bereits gesetzte Zust¨

ande zur¨

uckzusetzen. In einer Erweiterung k¨

onnte dies ¨

uber

ein spezielles Schl¨

usselwort in StatePbei einem schreibenden Parameter geschehen. Inwiefern

diese M¨

oglichkeit sinnvoll ist, m¨

ussen jedoch zun¨

achst konkrete Anwendungsf¨

alle zeigen.

Kapitel 5

Zustandsbeschreibungen mittels

Zustandsautomaten

Nachdem in Kapitel 4 ein erster L¨

osungsansatz eingef¨

uhrt und bewertet wurde, wird im Fol-

genden ein weiterer Ansatz vorgestellt. Dieser nimmt Probleme in Angriff, mit denen der

einfache L¨

osungsansatz nicht umgehen kann. Die Zustandsdefinition, die im vorangehenden

Kapitel vorgestellt wurde, umfasste eine lose Menge von Zust¨

anden (StatesDE ). Sollen je-

doch Zusammenh¨

ange zwischen den Zust¨

anden dargestellt werden, bieten sich Digraphen

zur Modellierung an. Mittels Digraphen kann festgelegt werden, zwischen welchen Zust¨

anden

Uberg¨

ange stattfinden d¨

urfen (Abbildung 5.1). Ein Zustands¨

ubergang von ”festgeschrieben“

nach ”nicht festgeschrieben“ (s. 4) kann somit durch das WfMS als ung¨

ultig erkannt und

dadurch verhindert werden. Die neu eingef¨

uhrte Zustandsdefinition entspricht daher einem

einfachen Zustandsautomaten. Durch die Verkettung der Zust¨

ande kann ein Verarbeitungs-

weg f¨

ur Daten vorgeschrieben werden. Typischerweise haben Wege auch einen Beginn und ein

Ende. Auch in diesem Fall ist dies eine Anforderung an das Modell. So kann eine Forderung

f¨

ur den Vorlauf-Prozess lauten, dass die Daten am Ende des Prozesses entweder an DATEV

ubertragen wurden oder der Vorlauf gel¨

oscht wurde. Das Beispiel mag nach einer rein seman-

tischen Erweiterung aussehen, da es nicht direkt die Funktionalit¨

at von Aktivit¨

aten betrifft.

Dennoch ist es f¨

ur einen korrekten Gesamtablauf essentiell.

Abbildung 5.1: Von losen Zust¨

anden zu Zustandsautomaten

Eine weitere Anforderung ist, dass sich der Zustand auch durch lesenden Zugriff ¨

andern las-

sen muss. Wichtig ist dies vor allem, wenn nur eine Referenz der Daten verwaltet wird. Der

schreibende Zugriff ist dem WfMS in diesem Fall nicht bekannt. Ein weiterer Anwendungsfall

sind Zust¨

ande, welche tats¨

achlich durch lesenden Zugriff erreicht werden. Sie k¨

onnen sich z.B.

auf einen Druckvorgang beziehen, bei dem die Daten selbst nicht ge¨

andert werden, jedoch der

Zustand ”gedruckt“ erzeugt wird.

Die feste Verbindung zwischen Zustandsdefinition und Datenelement muss gel¨

ost werden.

Da Aktivit¨

aten im Allgemeinen in unterschiedlichen Prozessen verwendet werden, wird die

dazugeh¨

orige Zustandsdefinition in mehreren Prozessen ben¨

otigt. Daher bietet sich eine zen-

trale Verwaltung von Zustandsdefinitionen an, so dass sie aus mehreren Prozessen heraus

referenziert werden k¨

onnen. Ein Datenelement muss dann nur noch eine Referenz auf eine

solche Definition halten.

Des Weiteren muss es m¨

oglich sein, mehr als einen Zustand als Zustandsforderung und

Zielzustand angeben zu k¨

onnen. Mehrere Zustandsforderungen bedeuten, dass einer dieser

Zust¨

ande eintreten muss. Die Situation, dass an einer Position im Kontrollfluss unterschiedli-

che Zust¨

ande erreicht werden, tritt z.B. durch alternative Verzweigungen ein. Durch mehrfache

Zustandsforderungen ist es, anders als beim ersten L¨

osungsansatz, nicht mehr notwendig, dass

am Ende eines Blocks ein einzelner Zustand feststeht. Zudem kann dadurch eine Aktivit¨

at f¨

jeden geforderten Zustand einen anderen Folgezustand anzugeben. Aktivit¨

aten, wie z.B. eine

Auftragspr¨

ufung, k¨

onnen unterschiedliche Ausf¨

uhrungsergebnisse besitzen. Um dies auch in

den Zust¨

anden widerspiegeln zu k¨

onnen, ist es notwendig, dass f¨

ur je einen geforderten Zu-

stand, mehrere m¨

ogliche Folgezust¨

ande angegeben werden k¨

onnen. Hier muss erst zur Laufzeit

entschieden werden, welcher der angegebenen Zust¨

ande tats¨

achlich eintritt.

Eine Aktivit¨

at kann bzgl. eines Parameters also aktiviert werden, sobald die Daten im rich-

tigen Zustand sind. Die Aktivit¨

at entscheidet w¨

ahrend ihrer Ausf¨

uhrung, welcher konkrete

Folgezustand eintritt. Um eine Ausf¨

uhrbarkeitsanalyse zu erm¨

oglichen, muss die Menge der

m¨

oglichen Folgezust¨

ande jedoch schon zur Modellierungszeit feststehen.

Im Folgenden wird in Abschnitt 5.1 auf die erweiterte Zustandsdefinition und in Ab-

schnitt 5.2 auf die Parameterbeschreibung eingegangen. Nach einigen Beispielen wird das

dynamische Verhalten in 5.3 erl¨

autert. Im Anschluss werden in 5.4 Kriterien und Algorith-

men f¨

ur den Ansatz vorgestellt. Eine kritische Betrachtung des Ansatzes folgt in Abschnitt 5.5.

Mit einer Zusammenfassung in 5.6 schließt dieses Kapitel ab.

5.1 Definition des Zustandsgraphen

Die Zustandsdefinition beinhaltet alle Informationen bez¨

uglich der Zust¨

ande. Dazu geh¨

oren

unter anderem ein Bezeichner, eine Beschreibung und ein Zustandsgraph. Der Zustandsgraph

ist ein Digraph, dessen Knoten Zust¨

ande und dessen Kanten Zustands¨

uberg¨

ange (Transitio-

nen) darstellen. In Anlehnung an einen Verarbeitungsweg f¨

ur die Daten wird der Bezeichner

f¨

ur die Zustandsdefinition DataP rocessingT emplate (Abk¨

urzung sei DP T ) genannt.

Da eine Zustandsdefinition von mehreren Prozessen verwendet wird, sind ein Name und eine

Beschreibung angebracht. Diese unterst¨

utzen den Modellierer bei der Suche nach einer passen-

den Zustandsdefinition und erleichtern das Verstehen eines bereits vorhandenen Prozesses. Um

die Verwendung des DataP rocessingT emplate weiter zu erleichtern, kann die Zustandsdefi-

nition mit typischen benutzerdefinierten Datentypen und typischen Datenelementbezeichnern

versehen werden.

DataP rocessingT emplate ={NameDP T , DescriptionDP T , StatesDP T , T ransitionsDP T ,

StartStatesDP T , EndStatesDP T , UsageDP T }

StatesDP T Eine nicht leere Menge von Zust¨

anden (State ). Jeder

Zustand muss ¨

uber eine Transition mit mindestens ei-

nem weiteren Zustand verbunden sein.

T ransitionsDP T Eine nicht leere Menge von Zustands¨

uberg¨

angen

(T ransition) mit Zustandstupeln aus StatesDP T :

T ransitionsDP T ⊆ {StatesDP T ×StatesDP T }.

StartStatesDP T Eine nicht leere Teilmenge von StatesDP T , welche als

Startzust¨

ande dienen k¨

onnen.

EndStatesDP T Eine Teilmenge von StatesDP T , die Endzust¨

ande re-

pr¨

asentieren.

UsageDP T Eine Liste von typischen benutzerdefinierten Datentypen

und Datenelementbezeichnern, f¨

ur welche die Zustands-

definition verwendet wird.

State Ein Zustand (Abk. S) bestehend aus einem eindeutigen

Bezeichner und einer optionalen Beschreibung.

T ransition Ein Zustands¨

ubergang (Abk. T) , mit einem Bezeichner,

einer optionalen Beschreibung und einem Tupel unter-

schiedlicher Zust¨

ande: {RequiredStateT, GoalStateT}.

Jeder der Zust¨

ande in der Menge StatesDP T enth¨

alt einen Bezeichner und kann durch ei-

ne Beschreibung erg¨

anzt werden. Dies ist wichtig, um dem Benutzer informative Erkl¨

arungen

geben zu k¨

onnen, falls z.B. eine Forderung nach einem Zustand verletzt wird. Gleiches gilt f¨

die Beschreibung der Transitionen. Zus¨

atzlich muss f¨

ur eine Transition auch ein geforderter

Zustand und ein Zielzustand angegeben werden. Im Zustandsgraph wird dieses Tupel mit

einer gerichteten Kante dargestellt. Mit der Beschreibung der Transitionen k¨

onnen Alternati-

ven gefunden und dem Benutzer erkl¨

art werden, wie die Verarbeitung weiter gehen kann, um

z.B. einen Konflikt zu l¨

osen.

Durch die StartStatesDP T k¨

onnen m¨

ogliche Startzust¨

ande festgelegt werden. Die Start-

zust¨

ande sind beliebige Zust¨

ande aus StatesDP T , welche durch eine Aktivit¨

at initial gesetzt

werden k¨

onnen. Da jedes zustandsbehaftete Datum auch einen anf¨

anglichen Zustand haben

muss, ist die Angabe eines Startzustandes Pflicht.

Optional k¨

onnen Zust¨

ande auch als Endzust¨

ande gekennzeichnet werden. Diese befinden sich

dann in der Menge EndStatesDP T . Endzust¨

ande erlauben eine Kontrolle dar¨

uber, ob sich

die Verarbeitung der Daten am Ende eines Prozesses in einem f¨

ur sie vorgesehenen Zustand

befindet. Dies dient als Hilfe f¨

ur den Bearbeiter des Prozesses und darf nicht vom System

erzwungen werden. So k¨

onnen Benutzer dar¨

uber informiert werden, wenn der Zustand nicht

erreicht wird, aber dennoch die Entscheidungsgewalt ¨

uber die weitere Ausf¨

uhrung behalten.

Da der Endzustand unter Umst¨

anden keine Rolle spielt oder die Daten keinen finalen Zustand

besitzen, ist die Angabe von Endzust¨

anden optional.

Abbildung 5.2 zeigt eine Zustandsdefinition, wie sie f¨

ur einen Vorlauf aus dem Prozess der

Steuerberatung (s. Abschnitt 3.4) aussehen k¨

onnte. Im Unterschied zum einfachen Ansatz

kann hier ein Zustandswechsel von ”r/w“ nach ”r/o“ ausgeschlossen werden. Ein festgeschrie-

bener Vorlauf kann somit nicht mehr weiter ge¨

andert werden.

Abbildung 5.2: Zustandsdefinition f¨

ur den Vorlauf

5.2 Erweiterung der Parameter von Aktivit¨

aten

Die Beschreibung der Eingabe- und Ausgabeparameter von Aktivit¨

aten nach [11] muss um

Zustandsforderungen und Folgezust¨

ande erweitert werden, um die Datenzust¨

ande zu inte-

grieren. In ADEPT wird explizit zwischen Eingabe- und Ausgabeparametern unterschieden.

Wenn eine Aktivit¨

at ein Datenelement liest und schreibt, dr¨

uckt sich dies daher in zwei Pa-

rametern aus. Werden an beiden Parametern Zustandsforderungen erlaubt, m¨

ussten diese in

einer bestimmten Reihenfolge abgearbeitet werden. Dadurch w¨

aren auch Zustands¨

uberg¨

ange

w¨

ahrend der Ausf¨

uhrung m¨

oglich, wie Abbildung 5.3 veranschaulicht. Der Einfachheit hal-

ber wird deshalb festgelegt, dass nur einer dieser Parameter eine Erweiterung um eine Zu-

standsbeschreibung enthalten darf. Falls optionale und obligate Parameter vorliegen, ist die

Zustandsbeschreibung ¨

uber den obligaten Parameter zu finden.

Da unterschiedliche Zustandsdefinitionen f¨

ur die Daten existieren k¨

onnen, kann ein Parameter

Abbildung 5.3: Mehrere Parameter f¨

ur ein einzelnes Datenelement

auch mehrere Zustandsbeschreibungen besitzen. Es darf jedoch nur genau eine Zustandsbe-

schreibung f¨

ur eine Zustandsdefinition hinterlegt werden .

StateRequirementsP={{T emplateSR, StateListSR}}

T emplateSR Eine Referenz auf das DataP rocessingT emplate, auf

welches sich die Zustandsforderungen und Folgezust¨

ande

in der StateListSR beziehen.

StateListSR Eine Menge bestehend aus

{RequiredState, GoalStates}.RequiredState ist

eine Voraussetzung, um die Aktivit¨

at ausf¨

uhren zu

k¨

onnen. Als spezieller Zustand kann Any angegeben

werden, falls die Aktivit¨

at f¨

ur jeden Zustand des

Datenelements ausf¨

uhrbar ist.

GoalStates ist eine Menge von Zust¨

anden, welche durch

die Ausf¨

uhrung erreicht werden k¨

onnen, sofern der ge-

forderte Zustand galt.

Aktivit¨

aten k¨

onnen in der Zustandsbeschreibung der Parameter mehrere Zust¨

ande fordern.

Damit die Aktivit¨

at ausf¨

uhrbar ist, muss einer dieser geforderten Zust¨

ande eintreten. Als be-

sonderer Zustand kann das Schl¨

usselwort Any angegeben werden. In diesem Fall ist jedoch

die Angabe eines Folgezustands nicht erlaubt. Diese Option ist besonders n¨

utzlich, wenn ei-

ne Aktivit¨

at zwar immer aufrufbar ist, den Zustand der Daten jedoch nur in bestimmten

Situationen ¨

andert.

F¨

ur jeden geforderten Zustand k¨

onnen mehrere Folgezust¨

ande angegeben werden. Dies

bedeutet, dass f¨

ur den entsprechenden geforderten Zustand einer der GoalStates gesetzt wird.

Welcher dieser Zust¨

ande tats¨

achlich eintritt, entscheidet sich erst zur Laufzeit. Dadurch ist

es notwendig, dass die Aktivit¨

at das WfMS von dem gesetzten Zustand in Kenntnis setzt.

Als m¨

ogliche Folgezust¨

ande d¨

urfen nur direkte Folgezust¨

ande des geforderten Zustands

oder der geforderte Zustand selbst angegeben werden. Dadurch wird die Einhaltung des durch

den Zustandsgraphen beschriebenen Verarbeitungsweg sichergestellt. Die Angabe des gefor-

derten Zustands als Zielzustand macht das Setzen eines neuen Zustands optional. Im Falle

eines hierarchisch aufgebauten Prozesses muss es jedoch eine Ausnahme geben. Ist einem

Knoten keine Aktivit¨

at sondern ein Sub-Prozess hinterlegt, so sind in dessen Parameterbe-

schreibungen Zustandsspr¨

unge erlaubt. Voraussetzung hierf¨

ur ist, dass im Zustandsgraphen

mindestens ein Weg zwischen dem geforderten und dem Zielzustand existiert. Zudem muss

der Sub-Prozess die Einhaltung der Zustands¨

uberg¨

ange sicherstellen. Um solche transitiven

Zustands¨

uberg¨

ange in der graphischen Darstellung schnell erkennen zu k¨

onnen, werden sie

mit einem ∗versehen.

Anstelle einer Menge von Folgezust¨

anden k¨

onnte ebenso eine Menge von Transitionen an-

gegeben werden. Wie gezeigt, ist jedoch sp¨

atestens bei Sub-Prozessen ein Zustandssprung

unumg¨

anglich. Die Angabe von Transitionen w¨

are an dieser Stelle hinderlich. Des Weite-

ren haben Zust¨

ande den Vorteil, dass der Folgezustand direkt ersichtlich ist und nicht erst

aus dem Zustandsgraphen abgelesen werden muss. Dadurch kann die Konsistenz der Zu-

stands¨

uberg¨

ange in einer graphischen Darstellung schnell erkannt und nachvollzogen werden.

Von Datenkanten wird weiterhin abstrahiert. F¨

ur sie gelten jedoch auch die bisher ange-

sprochenen Erweiterungen der Parameter. Wie schon im ersten Ansatz, werden sie in der

graphischen Darstellung mit Zustandsforderung und Zielzust¨

anden annotiert. Dabei wird f¨

jede Forderung eine eigene Zeile verwendet. In jeder Zeile steht der RequiredState. Falls

GoalStates existieren, stehen diese hinter dem RequiredState und einem Doppelpunkt in

einer kommaseparierten Liste. Transitive Zustands¨

uberg¨

ange werden durch ein ∗gekenn-

zeichnet. Beispiel: ”RequiredState :State1, State2∗“.

Eine abstrakte Darstellung einer Aktivit¨

at mit einer Zustandsforderung nach dem erweiterten

Ansatz wird in Abbildung 5.4 gezeigt.

Abbildung 5.4: Aktivit¨

at mit erweiterter Zustandsbeschreibung

Die Parameterbeschreibung muss noch um den Ausgabeparameter f¨

ur den Folgezustand

erweitert werden. Dieser Wert spielt ausschließlich zur Ausf¨

uhrungszeit eine Rolle. Falls die

Aktivit¨

at den Zustand der Daten ¨

andert, gibt dieser spezielle Ausgabeparameter den neuen

Zustand zur¨

uck. Der Wert muss sp¨

atestens dann vorliegen, wenn die Aktivit¨

at in den Zustand

COMPLETED wechselt.

OutputStatePEnth¨

alt den neuen Folgezustand nach Ausf¨

uhrung der

Aktivit¨

at. Der Wert ist UNDEFINED, falls die Akti-

vit¨

at den Zustand der Daten nicht ¨

andert. Wird der

Zustand ge¨

andert, muss der neue Zustand aus der Men-

ge GoalStates aus der StateListSR sein, welche zum

entsprechenden und eingetretenen Eingangszustand

RequiredState geh¨

ort.

5.3 Beispiele zur Demonstration des Konzepts

Bevor auf konkrete Algorithmen zur ¨

Uberpr¨

ufung der Einhaltung von Zustandsforderungen

eingegangen wird, soll an dieser Stelle der Ansatz anhand von Beispielen erl¨

autert werden. Die

bereits vorgestellte Abh¨

angigkeit im Vorlauf-Prozess der Steuerberatung l¨

asst sich mit dem

neuen Zustandsmodell sauberer modellieren. Unter Verwendung der bereits in Abbildung 5.2

gezeigten Zustandsdefinition, l¨

asst sich Modellierung der Aktivit¨

aten an die ben¨

otigten Zust¨

an-

de anpassen. Soll an einer gegebenen Stelle im Prozess eine Aktivit¨

at eingef¨

ugt werden, so

kann das System die Zust¨

ande, welche zur Ausf¨

uhrung an dieser Stelle gelten, ermitteln. Ent-

sprechen diese Zust¨

ande nicht den geforderten Zust¨

anden der Aktivit¨

at, so wird das Einf¨

ugen

nicht erm¨

oglicht. Das WfMS kann also verhindern, dass unpassende Aktivit¨

aten, wie z.B. eine

Anderung an einem Vorlauf nach dem Festschreiben, eingef¨

ugt werden. Durch die Forderung

zur Einhaltung der Zustands¨

uberg¨

ange werden schon w¨

ahrend der Spezifikation einer Akti-

vit¨

at Fehler unterbunden. Das Erstellen einer Aktivit¨

at, welche den Zustand von ”r/o“ auf

”r/w“ zur¨

ucksetzt, ist daher nicht m¨

oglich.

Das vorgestellte Modell kann auch zur Modellierung semantischer Abh¨

angigkeiten verwen-

det werden. Als Beispiel dient hier der bereits beschriebene Angebot-Prozess (s. Abb. 3.4). Die

Verarbeitung eines ”Angebot“ erfordert, dass das Angebot nach der Erstellung einer Durch-

sicht unterzogen wird, bevor es zum Kunden geschickt werden kann. Dieser kann W¨

unsche

bzgl. des Angebots ¨

außern oder es akzeptieren. Falls das Angebot noch einmal ¨

uberarbeiet

wird, muss erneut eine Durchsicht erfolgen. Abbildung 5.5 zeigt eine zur Situation passende

Zustandsdefinition. ¨

Uber die Zustandsparameter k¨

onnen Aktivit¨

aten beschreiben, welchem

Verarbeitungsschritt sie entsprechen. Dadurch k¨

onnen passende Aktivit¨

aten ¨

uber Zustand

der Daten und ein Aktivit¨

aten-Repository, durch entsprechende Anfragen, gefunden werden.

Abbildung 5.6 zeigt den fertig modellierten Angebot-Prozess mit Zustandsinformationen. Es

ist nicht mehr m¨

oglich, dass ein Angebot an den Kunden versendet wird, ohne dass es vor-

her durchgesehen und best¨

atigt wurde. Allerdings zeigt sich in der Modellierung auch eine

Schw¨

ache des Konzepts. Aktivit¨

at 15 ¨

andert den Zustand des Datenelements in Abh¨

angigkeit

des Ausf¨

uhrungsergebnisses. Ebenso h¨

angt davon die Entscheidung ab, welchem alternativen

Abbildung 5.5: Zustandsdefinition zur Verarbeitung eines Angebots

Zweig gefolgt wird. Dieser Zusammenhang ist mit bisherigen Mitteln leider noch nicht mo-

dellierbar, weshalb die Aktivit¨

at an Knoten 16 auf beide Folgezust¨

ande von der Aktivit¨

an Knoten 15 eingehen muss, obwohl nur einer eintreten wird. Auf dieses Problem wird in

Abschnitt 5.5 nochmals n¨

aher eingegangen.

Abbildung 5.6: Verarbeitung eines Angebots mit Zustandsinformationen

Das Verhalten von Graph und Zustandsdefinition w¨

ahrend der Ausf¨

uhrung eines Prozesses

wird in Abbildung 5.7 dargestellt. Die schematische Darstellung zeigt, wie Zustandswechsel

der Aktivit¨

at (z.B. ”aktiviert“, ”gestartet“) und Zustandswechsel in der Zustandsdefinition zu-

sammenspielen. Eine konkrete Implemementierung m¨

usste diese Informationen jedoch nicht

w¨

ahrend der Ausf¨

uhrung verarbeiten. Es w¨

urde gen¨

ugen, die Zustandsinformationen aus-

schließlich w¨

ahrend der Modellierung und bei ¨

Anderungen von Instanzen zu verwenden. Durch

die Validierung der Prozessvorlage k¨

onnen w¨

ahrend der Laufzeit keine falschen Zust¨

ande ein-

treten. Welcher Zustand zu einem bestimmten Zeitpunkt nun tats¨

achlich eintritt, ist daher

f¨

ur die Ausf¨

uhrung zun¨

achst nicht relevant.

5.4 Ans¨

atze zur Sicherstellung der Zustandsforderungen

Bevor algorithmisch festgestellt werden kann, ob die Zustandsforderungen eingehalten wer-

den, muss zun¨

achst definiert werden, wann eine Aktivit¨

at ausf¨

uhrbar ist. Danach wird auf

grundlegende Anforderungen an die Validierung eingegangen. Im Anschluss daran wird ein

Abbildung 5.7: Ausf¨

uhrung einer Aktivit¨

at mit zustandsbehafteten Daten

Algorithmus f¨

ur synchronisationsfreie Prozesse vorgestellt. Im Weiteren wird analysiert, wel-

chen Einfluss Synchronisation auf die Validierung hat, um daraufhin m¨

ogliche L¨

osungsans¨

atze

zu diskutieren.

F¨

ur die Definition, wann ein Parameter mit einer Zustandsbeschreibung als versorgt gilt,

m¨

ussen unterschiedliche Kriterien festgelegt werden. Um die Definition zu vereinfachen, wer-

den zun¨

achst einige Pr¨

adikate bez¨

uglich eines Parameters Peingef¨

uhrt. Das DataProcessing-

Template, also die Zustandsdefinition, ist in einem konkreten Prozess festgelegt. Daher wird

an dieser Stelle von der Referenz T emplateSR abstrahiert. Es werden also immer ausschließ-

lich Zustandsbeschreibungen in Betracht gezogen, welche f¨

ur die gew¨

ahlte Zustandsdefinition

gelten.

InputStates(P) Alle Zust¨

ande aus RequiredState der StateListSR des

Parameters P.

OutputStates(P) Alle Zust¨

ande aus GoalStates der StateListSR des Pa-

rameters P.

Damit ein Parameter Pmit einer Zustandsbeschreibung als versorgt gilt, darf kein Zustand

eintreten, welcher nicht als RequiredState in der StateListSR von Pauftaucht. In einem

Prozess k¨

onnen zum Ausf¨

uhrungszeitpunkt der Aktivit¨

at immer h¨

ochstens die Zust¨

ande ein-

treten, die durch die Vorg¨

anger erzeugt werden k¨

onnen. Daher ist es m¨

oglich, dass nicht

alle Zust¨

ande RequiredState in einem Prozess erreicht werden. Eine Aktivit¨

at kann z.B.

nur einen bestimmten Zustand in ihren GoalStates haben. Daher k¨

onnen durch eine darauf

folgende Aktivit¨

at nur die GoalStates erreicht werden, welche diesen einzelnen Zustand als

RequiredState besitzen. Auf der anderen Seite, k¨

onnen bei einer fehlerhaften Modellierung

auch Zust¨

ande erreichbar sein, welche nicht in RequiredStates vorkommen. Um diese Feh-

ler durch eine Analyse erkennen bzw. ausschließen zu k¨

onnen, werden auch diese Zust¨

ande

in die Menge der erreichbaren Zust¨

ande aufgenommen. F¨

ur die in einem konkreten Prozess

tats¨

achlich erreichbaren Eingangs- und Ausgangszust¨

ande an einem Parameter Pwerden die

Pr¨

adikate ReachableInputStates(P) und ReachableOutputStates(P) definiert.

ReachableInputStates(P) Alle Zust¨

ande, welche bei Vorg¨

angerknoten in

ReachableOutputStates auftauchen k¨

onnen.

ReachableOutputStates(P) Alle Zust¨

ande, welche bei Vorg¨

angerknoten in

ReachableOutputStates auftauchen k¨

onnen.

Auf dieser Grundlage l¨

asst sich ein einfaches Kriterium formulieren, wann eine Prozessvorla-

ge, auch unter dem Gesichtspunkt von zustandsbehafteten Parametern, ausf¨

uhrbar ist.

V ersorgt(P)ReachableInputStates(P) ist eine Teilmenge von

InputStates(P) oder InputStates(P) enth¨

alt den

speziellen Zustand Any. Ein zustandsbehafteter Pa-

rameter gilt genau dann als versorgt, wenn durch

Vorg¨

angerknoten ausschließlich Zust¨

ande erzeugt wer-

den, die auch gefordert wurden.

Abbildung 5.8 zeigt, wie sich die geforderten und erreichbaren Zust¨

ande zusammensetzen.

In diesem Beispiel beinhaltet einen Fehler in der Modellierung. Die erreichbaren Eingabe-

zust¨

ande sind keine Teilmenge der geforderten Zust¨

ande. Es ist dadurch m¨

oglich, dass bei

Knoten hZustand z2eintritt, f¨

ur den die hinterlegte Aktivit¨

at jedoch nicht ausf¨

uhrbar ist.

Abbildung 5.8: Geforderte und erreichbare Zust¨

ande in einer fehlerhaften Modellierung

5.4.1 Anforderungen an die Validierung der Zustandsforderungen

Die grundlegende Anforderung an die Validierung ist, dass die Parameter einer Aktivit¨

at zum

Ausf¨

uhrungszeitpunkt mit Daten in den richtigen Zust¨

anden versorgt sind. Um dies sicher-

zustellen, m¨

ussen diejenigen Zust¨

ande, die ¨

uber alle m¨

oglichen Ausf¨

uhrungswege zustande

kommen k¨

onnen, ermittelt werden.

Erschwert wird dies dadurch, dass die m¨

oglichen Zust¨

ande nicht alleine davon abh¨

angen,

welche Zust¨

ande in den GoalStates der zuvor ausgef¨

uhrten Aktivit¨

at stehen. Welche dieser

GoalStates erreicht werden, h¨

angt auch davon ab, welche Zust¨

ande vor dieser Aktivit¨

at gal-

ten (vgl. ReachableOutputStates). Wird dieser Gedankengang fortgesetzt, wird schnell klar,

dass die Aktivit¨

aten von Beginn an in ihrer tats¨

achlichen Ausf¨

uhrungsreihenfolge betrachtet

werden m¨

ussen. Teile dieser Reihenfolge sind jedoch nicht festgelegt. Bei Oder-Verzweigungen

wird alternativ genau einem von mehreren m¨

oglichen Zweigen gefolgt. Als Konsequenz sind

am Ende eines Oder-Blocks, alle Zust¨

ande m¨

oglich, welche am Ende einer jeden alternativen

Verzweigung gelten.

Im Hinblick auf diesen Hintergrund scheint die Ermitllung der Zust¨

ande aufw¨

andig zu sein.

Es bietet sich an, die gefundenen Werte f¨

ur die Zustandsmengen der ReachableInputStates

und ReachableOutputStates an bestimmten Knoten zu speichern. Dadurch ist bei Adhoc-

Anderungen schneller ersichtlich, ob eine Aktivit¨

at an einer bestimmten Stelle eingesetzt

werden kann. Zudem erleichtert die Information das algorithmische Vorgehen. Um die Werte

nicht an jedem Knoten halten zu m¨

ussen, bietet sich eine Auswahl bestimmter Knoten an.

Sinnvoll sind Knoten, welche Zustandsforderungen besitzen, und Knoten, welche einen Block

einleiten oder abschließen.

Ein weitere Anforderung an den Validierungsalgorithmus ist eine performante Ausf¨

uhrung.

So muss z.B. bei einer Schemaevolution ein effizientes Pr¨

ufen aller zu migrierenden Instanzen

m¨

oglich sein.

5.4.2 Algorithmus f¨

ur synchronisationsfreie Prozesse

Bei Verwendung von Synchronisationskanten verspricht dies jedoch komplizierter zu werden,

da diese die Blockstruktur von Prozessen in ADEPT aufbrechen. Daher wird im Folgen-

den zun¨

achst ein Algorithmus f¨

ur synchronisationsfreie Prozesse beschrieben, bevor n¨

aher

auf das Problem mit Synchronisationskanten eingegangen wird. Die Vorgehensweise ist an

den W riterExists Algorithmus (s. 4.2) angelehnt. Anders als beim W riterExists Algorith-

mus wird jedoch der gesamte Graph durchlaufen. Dies ist notwendig, da die Knoten in ihrer

tats¨

achlichen Ausf¨

uhrungsreihenfolge abgearbeitet werden m¨

ussen, diese jedoch nicht gegeben

ist. Im W riterExists Algorithmus wird der Status, ob ein Knoten versorgt ist, von Knoten

zu Knoten weiter gegeben. Um die Knoten-Semantik ber¨

ucksichtigen zu k¨

onnen, wird ein

Counter verwendet um die Anzahl der eingehenden und versorgten Kanten zu z¨

ahlen.

Die grunds¨

atzliche Idee wird hier ¨

ubernommen. Da jedoch auch die m¨

oglichen Eingangs-

zust¨

ande (ReachableInputStates) gefunden werden m¨

ussen, werden auch diese von Knoten

zu Knoten weiter propagiert. Der Counter wird verwendet, um die bereits abgearbeiteten

Kanten zu z¨

ahlen. Ein Knoten wird nur dann weiter bearbeitet, wenn der Verlauf ¨

uber alle

relevanten eingehenden Kontrollfluss-Kanten betrachtet wurde. Wie bereits im vorigen Ab-

schnitt erkl¨

art, ist dies notwendig, um die Menge der m¨

oglichen Zust¨

ande bestimmen zu

k¨

onnen. Damit das Verfahren nicht alle Knoten durchlaufen muss, werden Bl¨

ocke ohne Zu-

standsforderung ¨

ubersprungen.

Um zu bestimmen, welche Zweige und welche Bl¨

ocke relevant sind, wird die topologische Sor-

tierung des Graphen zunutze gemacht. Die topologische Sortierung von ADEPT-Graphen hat

folgende Eigenschaften: Liegen Knoten in einer Sequenz, so sind sie aufsteigend in Ausf¨

uhrungs-

reihenfolge nummeriert. Liegt ein Knoten bzwischen zwei Knoten aund ceiner Sequenz, so

muss die Knoten-ID von bzwischen den Knoten-IDs der umgebenden Knoten aund cliegen.

Ein Block wird ¨

ubersprungen, wenn kein Knoten mit Zustandsforderung zwischen Split- und

Join-Knoten liegt. Analog dazu werden Zweige ignoriert, wenn kein Knoten mit Zustands-

forderung zwischen dem ersten und letzten Knoten, einschließlich des ersten und des letzten

Knotens, im Zweig liegt.

Die von Knoten zu Knoten weiter propagierten Zust¨

ande werden an bestimmten Stellen in

den Knoten-Eigenschaften RIS und ROS gespeichert, wobei ersteres f¨

ur die erreichbaren Ein-

gangszust¨

ande und letzteres f¨

ur die erreichbaren Ausgangszust¨

ande steht. Knoten, an denen

die Information gespeichert wird, sind Block-Knoten und Knoten mit Zustandsforderungen.

1. Initialisierung von Variablen und Setzen von initialen Zust¨

anden. F¨

ur den Algorithmus

werden zus¨

atzliche Knoten-Attribute und weitere Variablen ben¨

otigt. F¨

ur jeden Kno-

ten nwerden die Attribute RIS(n) (m¨

ogliche Eingangs-Zust¨

ande), ROS(n) (m¨

ogliche

Ausgangszust¨

ande) und Counter(n) (abgearbeitete eingehende Kanten) jeweils mit 0

bzw. ∅initialisiert. Der Graph wird anhand eines Stacks durchlaufen. Zu bearbeitende

Knoten und ihre m¨

oglichen Eingangszust¨

ande werden auf den Stack gelegt. W¨

ahrend

der Initialisierung werden Zust¨

ande aus den Eingangsparametern des Prozesses auf den

Start-Knoten ¨

ubertragen und dieser auf den Stack gelegt. Beginnend bei Schritt 2 wird

dieser Stack abgearbeitet und gleichzeitig um Folgeknoten erweitert. Der Algorithmus

terminiert, wenn der Stack leer ist, also der gesamte Graph durchlaufen wurde, oder

wenn eine Verletzung von Zustandsforderungen gefunden wurde.

2. N¨

achsten Knoten (node) und m¨

ogliche Zust¨

ande (States0) vom Stack holen und be-

trachten.

3. Falls der Knoten Zustandsforderungen bzgl. des Datenelements besitzt:

(a) ¨

Uberpr¨

ufung von Zust¨

anden: Um die Einhaltung der Zustandsforderungen sicher-

zustellen, sind unterschiedliche F¨

alle zu beachten. Da der Knoten Zust¨

ande for-

dert, darf die Menge der m¨

oglichen Zust¨

ande nicht leer sein. Ist die Menge nicht-

leer, so muss sie entweder eine Teilmenge der geforderten Zust¨

ande sein, oder das

Schl¨

usselwort Any muss in der Menge der geforderten Zust¨

ande enthalten sein.

(b) Finden der m¨

oglichen Folgezust¨

ande: Die Folgezust¨

ande ergeben sich aus allen

Mengen der Zielzust¨

ande, deren geforderter Zustand in der Menge der m¨

oglichen

Zust¨

ande auftaucht. Hier muss die Menge RIS(node) verwendet werden, diese ist

gesetzt, da sie an Knoten mit Zustandsforderungen gespeichert wird. Die m¨

oglichen

Folgezust¨

ande werden in der Menge ROS(node) gespeichert. Enth¨

alt die Zustands-

forderung das spezielle Schl¨

usselwort Any, werden auch die nicht explizit geforder-

ten Zust¨

ande der Menge ROS(node) hinzugef¨

ugt. Die Menge der m¨

oglichen Folge-

zust¨

ande wird f¨

ur die weitere Verarbeitung zus¨

atzlich in SuccStates gespeichert.

4. Falls der Knoten keine Zustandsforderungen besitzt:

(a) Gegebenenfalls ¨

Ubertragung von RIS(node) auf ROS(node): Da die m¨

oglichen

Zust¨

ande nicht nur an Knoten mit Zustandsforderungen gespeichert werden, kann

auch in diesem Fall die Menge RIS(node) nicht-leer sein. Da der Knoten den

Zustand nicht ¨

andert, erh¨

alt die Menge ROS(node) die gleichen Zust¨

ande.

(b) Der Zustand wird nicht ge¨

andert. Die Menge der m¨

oglichen Zust¨

ande zur Weiter-

verarbeitung bleibt also gleich. SuccStates wird auf den Wert von States0 gesetzt.

5. Finden der Nachfolger: Es m¨

ussen relavante Nachfolger bez¨

uglich Kontrollfluss-Kanten

gefunden werden.

6. Aktueller Knoten ist der Anfangsknoten eines Blockes (z.B. OR-Split):

(a) Falls kein Knoten im Block eine Zustandsforderung besitzt, wird der zugeh¨

orige

Join-Knoten als relevanter Nachfolger verwendet. Dadurch wird der Block ¨

uber-

sprungen.

(b) Falls Knoten im Block Zustandsforderungen besitzen, werden alle Zweige betrach-

tet. Nachfolger des Block-Knotens, welche auf einem Zweig mit Zustandsforderun-

gen liegen, werden der Menge der relevanten Nachfolgern hinzugef¨

ugt.

7. Aktueller Knoten ist kein Block-Anfang-Knoten: Der (einzige) direkte Nachfolger wird

verwendet.

8. Der n¨

achste (relevante) Nachfolger sn wird betrachtet.

9. Anpassung der Folgezust¨

ande und Setzen von RIS(sn): Je nach Knotensemantik muss

die Menge SuccStates angepasst werden. Im gleichen Zug wird die Menge RIS(sn)

gesetzt, wo dies erw¨

unscht ist. Folgende Sonderf¨

alle f¨

ur sn sind zu beachten:

(a) AND-Join: Falls der Folgeknoten ein AND-Join ist und im Block Zustandsforde-

rungen existieren, wird RIS(sn) auf SuccStates gesetzt. Da der Prozess frei von

Sync-Kanten ist, wurde h¨

ochstens einem Zweig gefolgt.

(b) OR-Join (und Zustandsforderung im Block): Am Ende einer alternativen Verzwei-

gung sind alle Zust¨

ande m¨

oglich, die am Ende jeder einzelnen Verzweigung gelten.

Daher werden diese der Menge RIS(sn) und SuccStates hinzugef¨

ugt. Der Kno-

ten wird jedoch erst dann auf den Stack gelegt, wenn alle eingehenden Kanten

relevanter Zweige abgearbeitet wurden.

m¨

oglichen Zust¨

ande in RIS(sn) gespeichert. Zus¨

atzlich wird hier noch kontrolliert,

ob die Zust¨

ande am Ende der Schleife eine Teilmenge der Zust¨

ande zu Anfang der

Schleife sind.

(d) Knoten ¨

andert den Zustand: In diesem Fall muss nur RIS(sn) auf den Wert von

SuccStates gesetzt werden.

10. Knoten auf den Stack: Der Nachfolger sn wird genau dann auf den Stack gelegt, wenn

node der letzte noch nicht betrachtete relevante Vorg¨

anger ist. Ansonsten wird der

Z¨

ahler Counter(sn) um eins erh¨

oht. Da es ausschließlich bei Oder-Verzweigungen meh-

rere relevante eingehende Zweige gibt, muss der Z¨

ahler nur im Falle eines OR-Joins

ber¨

ucksichtigt und erh¨

oht werden.

11. Den n¨

achsten Nachfolger betrachten, zur¨

uck zu Schritt 8.

12. Den n¨

achsten Knoten im Stack betrachten, zur¨

uck zu Schritt 2.

Bei der textuellen Erl¨

auterung des Algorithmus wurden bewusst einige Details ausgelassen,

um nur den prinzipiellen Ablauf zu erl¨

autern. Im Anhang A wird ein ein vollst¨

andiger Al-

gorithmus als kommentierter Pseudo-Code vorgestellt. Der Algorithmus bietet ein effizien-

tes Verfahren zur ¨

Uberpr¨

ufung von Zust¨

anden in einem synchronisationsfreien Prozess. Der

Graph muss nur einmal durchlaufen werden, wobei s¨

amtliche irrelevante Bl¨

ocke und Teil-

zweige ¨

ubersprungen werden. W¨

ahrenddessen werden die geltenden Zust¨

ande zu bestimmten

Ausf¨

uhrungszeitpunkten zwischengespeichert, was eine effiziente Revalidierung zur Laufzeit

erlaubt.

5.4.3 Synchronisation

In diesem Abschnitt wird analysiert, welche Anforderungen an den Algorithmus f¨

ur den

Umgang mit synchronisierten Graphen bestehen. Synchronisationskanten sind ein bewusster

Bruch der Blockstruktur, der eine Festlegung der Ausf¨

uhrungsreihenfolge ansonsten paralleler

Abbildung 5.9: Synchronisation von

KF und DF

Abbildung 5.10: Vom DF un-

abh¨

angige Synchronisation

Aktivit¨

aten erlaubt. Damit kann die Ausf¨

uhrung von zwei parallelen Zweigen eines Blocks syn-

chronisiert werden. Teil eines Zweigs sind auch Aktivit¨

aten aus Bl¨

ocken, welche auf dem Zweig

liegen. Dadurch ist Synchronisation aus Bl¨

ocken heraus, sowie in Bl¨

ocke hinein, m¨

oglich, sofern

Start- und Zielknoten zu unterschiedlichen Zweigen eines gemeinsamen Und-Blocks geh¨

oren.

Hintergrund von Sync-Kanten ist die Kontrollflussmodellierung, um die Synchronisation von

paralleler Ausf¨

uhrung an bestimmten Stellen im Prozess zu erm¨

oglichen. Die Synchronisation

von Zugriffen auf Datenelementen findet daher nicht explizit statt, sondern ergibt sich impli-

zit aus dem Kontrollfluss.

Diese implizite Synchronisation bereitet Schwierigkeiten bei einer Erweiterung des im vorigen

Abschnitt beschriebenen Algorithmus. Da Zustandsforderungen in parallelen Zweigen durch

Sync-Kanten erm¨

oglicht werden, muss der Algorithmus auch diesen folgen und Zust¨

ande auch

dar¨

uber weiter propagieren. Die Entscheidung, ob und welche Zust¨

ande ¨

uber eine Sync-Kante

propagiert werden m¨

ussen, ist jedoch nicht trivial. Gr¨

unde hierf¨

ur werden anhand von ein

paar einfachen Beispielen aufgezeigt. Um die Graphiken ¨

ubersichtlich zu halten, wird auf die

Darstellung von Datenelementen verzichtet. Die Beispiel-Graphen beeinhalten ein einzelnes

Datenelement. Sofern ein Knoten eine Zustandsforderung und Zielzust¨

ande besitzt, werden

diese direkt am Knoten annotiert: {Eingabezustaende}:{Ausgabezustaende}.¨

Ubertragene

Zust¨

ande werden ggf. an den Kontrollfluss-Kanten angezeigt.

Ubertragung von Zust¨

anden ¨

uber eine Sync-Kante Abbildungen 5.9 und 5.10 zeigen

das grunds¨

atzliche Problem der Entscheidung, ob Zust¨

ande ¨

uber Sync-Kanten propagiert

werden m¨

ussen oder nicht. Alleine durch Betrachtung der synchronisierten Knoten l¨

asst sich

nicht bestimmen, welcher Zustand ¨

ubernommen werden muss. Ein naiver Ansatz w¨

are z.B. zu

untersuchen oder zu speichern, auf welchem Zweig sich die letzte Zustandsforderung befand.

Wie jedoch Abbildung 5.11 zeigt, gen¨

ugt dies nicht: Die Synchronisation des Datenflusses

kann auch transitiv ¨

uber mehrere Sync-Kanten und parallele Zweige geschehen.

Abbildung 5.11: Transitive Synchronisation des DF

Auswahl der bei Sync-Kanten zu ¨

ubertragenden Zust¨

ande Werden Zust¨

ande ¨

uber

Sync-Kanten ¨

ubertragen, muss untersucht werden, welche Zust¨

ande bei der Synchronisation

eine Rolle spielen. Dies ist mit Komplikationen verbunden, wenn die Synchronistion aus Oder-

Bl¨

ocken heraus geschieht. Sync-Kanten k¨

onnen in diesem Fall abgew¨

ahlt werden: Wird der

Zweig mit der Sync-Kante abgew¨

ahlt, wird die Sync-Kante als nicht mehr ausf¨

uhrbar mar-

kiert. Zur Ausf¨

uhrung des Zielknotens spielt die Sync-Kante von diesem Moment an keine

Rolle mehr. Dadurch sind implizit mehrere Knoten mit dem Zielknoten synchronisiert: Der

Ausgangsknoten der Sync-Kante und jeder Knoten, der ¨

uber die Ausf¨

uhrung des Ausgangs-

knotens entscheidet. Der Graph in Abbildung 5.12 zeigt eine solche Situation. Es nehmen

sowohl Knoten cals auch Knoten eEinfluss auf die Synchronisation. Im synchronisierten

Zweig sind im weiteren Verlauf beide Mengen der m¨

oglichen Ausgangszust¨

ande in Betracht

zu ziehen.

Abbildung 5.12: Synchronisation durch abw¨

ahlbare Sync-Kante

Eine Untersuchung des direkt umschließenden Oder-Blockes reicht jedoch nicht aus. Vielmehr

m¨

ussen alle verschachtelten Bl¨

ocke, bis zum synchronisierten Und-Block, untersucht werden.

Durch jede weitere Verschachtelung nimmt ein weiterer Knoten Einfluss auf die Synchroni-

sation. In Abbildung 5.13 wird diese Situation verdeutlicht. An der Synchronisation sind in

diesem Fall Knoten b,cund ebeteiligt. Dementsprechend m¨

ussen auch die m¨

oglichen Aus-

gangszust¨

ande ber¨

ucksichtigt werden.

Ließen sich in den bisher gezeigten Beispielen die beteiligten Knoten auf die Split-Knoten

zur¨

uckf¨

uhren, so gibt es dennoch einen weiteren zu ber¨

ucksichtigenden Fall: Sind alle Zweige

Abbildung 5.13: Synchronisation aus einem verschachtelten Oder-Block

des Oder-Blocks synchronisiert, spielt der Zustand beim Split-Knoten keine Rolle mehr. In

diesem Fall m¨

ussen die Zust¨

ande aus allen Knoten, von denen die Sync-Kanten ausgehen,

ubernommen werden.

Abbildung 5.14: Synchronisation aller alternativen Zweige

Falls alle alternativen Zweige synchronisiert werden, muss dies nicht an einem einzelnen Kno-

ten geschehen. Abbildung 5.15 zeigt, wie alle Zweige eines Oder-Blocks indirekt synchronisiert

werden. Die Beispiele lassen sich beliebig durch Kombinationen der F¨

alle entsprechend ver-

komplizieren. Die vorgestellen Graphen veranschaulichen jedoch alle m¨

oglichen grundlegenden

Situationen.

Abbildung 5.15: Indirekte Synchronisation aller alternativen Zweige

Behandlung von mehreren Sync-Kanten Gehen an einem Knoten mehrere Synchroni-

sationskanten ein, m¨

ussen diese weiter untersucht werden. Grunds¨

atzlich ist festzustellen, ob

die Kanten f¨

ur den Datenfluss relevant sind oder nicht. F¨

ur je zwei Kanten k¨

onnen folgende

F¨

alle unterschieden werden:

1. Die Reihenfolge, in welcher die Sync-Kanten bewertet werden, ist eindeutig festgelegt.

Dies kann durch transitive Synchronisation geschehen, oder die Ausgangsknoten der

Kanten liegen in einer Sequenz. Die Kante, die zuerst bewertet wird, kann daher ignoriert

werden.

2. Die Kanten kommen aus unterschiedlichen Zweigen und ihre Reihenfolge ist nicht ein-

deutig festgelegt. In diesem Fall kann es nur sein, dass ¨

uber eine Kante Zust¨

ande

ubertragen werden. Ansonsten w¨

aren die Zustandsforderungen nicht synchronisiert. Die

Entscheidung, von welcher Kante Zust¨

ande entgegengenommen werden, ist analog zu

der Frage, ob ¨

uber eine Kontrollfluss- oder ¨

uber eine Sync-Kante Zust¨

ande entgegenge-

nommen werden.

3. Die Kanten kommen aus unterschiedlichen Zweigen von einem Oder-Block oder sind eine

transitive Synchronisation aus diesen Zweigen. Die Zust¨

ande von allen Kanten m¨

ussen

ber¨

ucksichtigt werden. Falls nicht alle Zweige des Oder-Blocks synchronisiert wurden,

m¨

ussen zudem auch die Zust¨

ande der entsprechenden OR-Splits ber¨

ucksichtigt werden

(vgl. Abbildungen 5.12, 5.13 und 5.14).

Zusammenfassung Wie einfache Beispiele zeigen, ist die bisher verfolgte Heransgehens-

weise zur Validierung nicht auf einfache Weise auf synchronisierte Graphen anwendbar. Ein

weiteres Problem stellt das Speichern der Zust¨

ande an Block-Knoten dar. Durch den Bruch

der Blockstruktur ist dies nicht mehr ohne weiteres m¨

oglich. So m¨

ussen entweder falsche Wer-

te an bestimmten Knoten in Kauf genommen werden oder die Tatsache, dass diese nicht an

jedem Block mit Zustandsforderungen gespeichert werden. In Abbildung 5.12 ist es z.B. nicht

m¨

oglich einen korrekten Wert an Knoten fzu speichern. Durch Synchronisation und parallele

Ausf¨

uhrung sind die Zust¨

ande zu dessen Ausf¨

uhrungszeitpunkt nicht mehr eindeutig.

Auch wenn die Modellierung einiger der vorgestellten Graphen wenig sinnvoll erscheint, so

sind sie dennoch ADEPT konform und m¨

ussen bei der Analyse ber¨

ucksichtigt werden. Zu be-

denken ist auch, dass Graphen durch Adhoc-¨

Anderungen, Schemaevolution und semantisch

h¨

oherwertige ¨

Anderungsoperationen modifiziert werden k¨

onnen. Dadurch k¨

onnen in realen

F¨

allen auch weniger ansehnliche Graphen entstehen.

5.4.4 L¨

osungsans¨

atze f¨

ur Prozesse mit Synchronisation

Im Folgenden werden drei L¨

osungsans¨

atze umrissen, die eine Ausf¨

uhrbarkeitsanalyse unter

Ber¨

ucksichtigung von Synchronisationskanten erm¨

oglichen. Zun¨

achst wird ein Ansatz, der

auf Knoten-Beziehungen basiert, vorgestellt. Als zweites wird ein Ansatz, der mit Erreich-

barkeitsgraphen arbeitet, angedacht. Ein dritter L¨

osungsansatz basiert auf Techniken zur

Graph-Reduktion.

Ein Ansatz auf Grundlage von Knoten-Relationen Unter der Voraussetzung, dass

bestimmte Beziehungen unter den Knoten, die Zustandsforderungen besitzen, bekannt sind,

lassen sich die Zust¨

ande einfacher ¨

uberpr¨

ufen. Dazu m¨

ussen Fragen, wie z.B. ”Kommt ein

Knoten direkt vor einem anderen?“ oder ”Kommt ein Knoten optional direkt vor einem

anderen?“, beantwortet werden k¨

onnen. Die erforderlichen Knoten-Beziehungen m¨

ussen auch

Sync-Kanten ber¨

ucksichtigen. Tabelle 5.1 gibt eine ¨

Ubersicht ¨

uber ben¨

otigte Beziehungen.

Tabelle 5.1: Knotenbeziehungen

a < b a wird direkt vor bausgef¨

uhrt.

a <|b a wird direkt vor bausgef¨

uhrt, jedoch ist die

Ausf¨

uhrung von boptional.

a|< b a wird direkt vor bausgef¨

uhrt, jedoch ist die

Ausf¨

uhrung von aoptional.

a?bZwischen aund bexistiert eine der Beziehungen bzw. a

kommt vor b.

Sind die Beziehungen unter den Knoten mit Zustandsforderungen bekannt, kann wie folgt

vorgegangen werden:

1. Betrachte alle Tupel mit einem Knoten a, zu dem es kein Knoten bgibt, mit b?a.

2. Falls a<boder a <|bund nicht a|< b:bwird (optional) nach aausgef¨

uhrt. Wird b

ausgef¨

uhrt, so ist jedoch aper Definition der Vorg¨

anger. RIS von berh¨

alt also ROS

von a.RIS(b):=ROS(a).

3. Falls a|< b:awird optional vor bausgef¨

uhrt. Die Zust¨

ande, die ¨

uber diese Beziehung

ubertragen werden, m¨

usen zu RIS von bhinzugef¨

ugt werden. RIS(b) := RIS(b)∪

ROS(a).

4. Entferne das Tupel aus der Menge und fahre mit dem n¨

achsten Tupel fort. Terminiere,

falls keine weiteren Tupel vorhanden sind.

Werden Knoten-Beziehungen bereitgestellt, so ist eine algorithmische ¨

Uberpr¨

ufung der Zust¨

an-

de mit minimalem Aufwand m¨

oglich. Die algorithmische Hauptarbeit liegt jedoch im Fin-

den der Knoten-Beziehungen. Die Frage nach der tats¨

achlichen Ausf¨

uhrungsreihenfolge einer

Knotenmenge wird jedoch auch f¨

ur andere Analysen von Bedeutung sein. Beispiele hierf¨

sind semantische Abh¨

angigkeiten zwischen Aktivit¨

aten, Ressourcenmanagement und weitere

komponenteninterne Abh¨

angigkeiten. Auch um Sichten auf eine Teilmenge von Knoten eines

Graph zu erstellen, kann diese Information interessant sein. Unter Umst¨

anden ist es daher

sinnvoll, Datenstrukturen zu erstellen, die eine effiziente Feststellung der Knoten-Beziehungen

erm¨

oglichen.

Ein Ansatz auf Grundlage von Erreichbarkeitsgraphen Eine weitere Vorgehenswei-

se zur Ber¨

ucksichtigung von Synchronisationskanten ist die Erstellung eines Erreichbarkeits-

graphen. In diesem Graphen werden alle m¨

oglichen Kombinationen von Aktivit¨

atenzust¨

anden

(STARTED,COMPLETED etc., siehe Abschnitt 2.2.3) dargestellt, die w¨

ahrend der Aus-

f¨

uhrung des Prozesses erreicht werden k¨

onnen. Damit lassen sich auch alle m¨

oglichen Aus-

f¨

uhrungsreihenfolgen herausfinden. Die Zustandswechsel der Aktivit¨

aten spielen dabei jedoch

keine Rolle. Dadurch reicht ein bedeutend kleinerer Erreichbarkeitsgraph aus, indem z.B. nur

der Aktivit¨

atenzustand STARTED ber¨

ucksichtigt wird. Durch die kombinatorische Vielfalt,

die durch die verschiedenen Ausf¨

uhrungsreihenfolgen bei parallelen Zweigen zu erwarten ist,

erscheint eine anschließende Analyse jedoch trotzdem als zu aufw¨

andig. Der Aufwand lie-

ße sich jedoch erheblich verkleinern, wenn Knoten und Bl¨

ocke aus dem Graphen entfernt

w¨

urden, welche zur Analyse der Zustandsforderungen keine Rolle spielen. Dieser Vorgang,

auch Graph-Reduktion genannt, k¨

onnte jedoch auch genutzt werden, um einen neuen und

einfach analysierbaren Graphen zu erzeugen.

Ein Ansatz unter Verwendung von Graph-Reduktion Aktivit¨

aten mit Zustandsfor-

derungen d¨

urfen nicht parallel ausgef¨

uhrt werden. Dadurch kann die Ausf¨

uhrungsreihenfolge

dieser Aktivit¨

aten in einem Graphen ohne Parallelit¨

at dargestellt werden. Graph-Reduktion

ist eine M¨

oglichkeit, um einen solchen Graphen zu erzeugen. Insbesondere unter Verwendung

der topologischen Sortierung k¨

onnen so ganze Bl¨

ocke und einzelne Knoten nach und nach

aus dem Original-Graphen entfernt werden. Dadurch w¨

urden z.B. Sync-Kanten, die f¨

ur eine

indirekte Synchronisation verantwortlich sind (siehe Abbildung 5.15), auf einen Knoten zu-

sammenfallen. Und-Bl¨

ocke k¨

onnten dadurch so lange vereinfacht werden, bis die tats¨

achliche

Ausf¨

uhrungsreihenfolge der betrachteten Knoten eindeutig ist. Daraufhin k¨

onnten die Block-

Knoten entfernt und die Sync-Kanten in normale Kontrollfluss-Kanten umgewandelt werden,

um den gew¨

unschten Graphen zu erhalten. Grundlage k¨

onnen bereits vorhandene Algorith-

men bieten. In [11, S. 111] wird z.B. eine einfache Graphreduktion vorgeschlagen, um die

Erreichbarkeitsanalyse f¨

ur ADEPT-Graphen zu optimieren.

5.5 Diskussion und Ausblick

Die in diesem Kapitel vorgestellte L¨

osung zur Integration von auf zustandsbehafteten Da-

ten basierende Abh¨

angigkeiten bietet dem Prozess- und Aktivit¨

aten-Designer ein m¨

achtiges

Werkzeug. Damit lassen sich zahlreiche Zusammenh¨

ange zwischen Aktivit¨

aten modellieren.

Durch eine zentrale Verwaltung der Zustandsgraphen ist auch eine Wiederverwendung bereits

modellierter Zusammenh¨

ange m¨

oglich. Die wichtigste Neuerung ist jedoch die Festlegung von

Zustandsabfolgen. Die Realisierung als Digraph entspricht einem einfachen Zustandsautoma-

ten, welcher als Eingabe nur den aktuellen Zustand und den direkten Folgezustand kennt.

Durch die M¨

oglichkeit der Aktivit¨

aten, auf unterschiedliche Zust¨

ande zu reagieren und un-

terschiedliche Folgezust¨

ande angeben zu k¨

onnen, sind auch sehr komplexe Zusammenh¨

ange

modellierbar. Da jedoch i.A. kleine Graphen f¨

ur die Datenzust¨

ande zu erwarten sind, ver-

spricht die Modellierung dennoch ¨

ubersichtlich zu bleiben. Auch semantische Abh¨

angigkeiten,

die sich in Form einer Zustandsdefinition ausgedr¨

uckt werden kann, k¨

onnen auf diesem Wege

ins WfMS integriert werden.

Vorteile einer Modellierung mit Zust¨

anden liegen auch in der Ausf¨

uhrung von Vorw¨

artsspr¨

un-

gen (z.B. wegen einer Notoperation) vor. So k¨

onnen nicht nur unversorgte Parameter erkannt

werden, sondern zudem auch die Ausf¨

uhrung von weiteren Aktivit¨

aten vorgeschlagen wer-

den, um den ben¨

otigten Datenzustand bei der Zielaktivit¨

at zu erreichen. Dadurch kann der

Ausf¨

uhrungserfolg von Aktivit¨

aten auch bei Vorw¨

artsspr¨

ungen sichergestellt werden.

Ein durch den vorgestellten Ansatz nicht l¨

osbares Problem verbleibt an Oder-Verzweigungen.

Da Aktivit¨

aten unterschiedliche Zust¨

ande fordern k¨

onnen, werden am Ende einer Verzweigung

mehrere m¨

ogliche Zust¨

ande erlaubt. Wie bereits gezeigt, ist dies notwendig, da Verzweigungen

typischerweise auch zur unterschiedlichen Verarbeitung von Daten verwendet werden. Die Ent-

scheidung, welcher Verarbeitungsweg eingeschlagen wird, kann jedoch auch vom Zustand der

Daten abh¨

angen und sich dadurch auch in diesem widerspiegeln. Daraus ergeben sich zwei An-

forderungen: Der Zustand der Daten muss im Entscheidungspr¨

adikat bei Oder-Verzweigungen

verwendet werden k¨

onnen. Dar¨

uber hinaus muss die Menge m¨

oglicher Zust¨

ande, je nach

Verzweigung, eingeschr¨

ankt werden k¨

onnen. Eine naive L¨

osung daf¨

ur w¨

are eine Zuordnung

zwischen Ausgabeparametern und den vom Knoten ausgehenden Verzweigungen. Ein allge-

meinerer Ansatz w¨

are jedoch sinnvoller. So k¨

onnte die Entscheidung, welchem Zweig gefolgt

wird, auch vom Wert des Statusparameters einer Aktivit¨

at abh¨

angig gemacht werden. Der

Statusparameter ist ein spezieller Ausgabeparameter, welcher weitere Informationen ¨

uber die

Beendigung der Aktivit¨

at gibt. Er ist Vergleichbar mit exit codes von Prozessen eines Be-

triebssystems [11, Abschnitt 3.2.2.3]. W¨

urde eine Zuordnung zwischen Statusparameter und

Verzweigung existieren, k¨

onnten auf deren Grundlage auch Zust¨

ande aus den GoalStates ein-

zelnen Zweigen fest zugeordnet werden. Da bisher jedoch noch keine M¨

oglichkeit existiert,

das Verzweigungsverhalten einer Aktivit¨

at zu formulieren, m¨

ussen entsprechende Vorausset-

zungen auf einer h¨

oheren Ebene in Aktivit¨

atenbeschreibungen und Prozessmodell geschaffen

werden.

Die Ausf¨

uhrung der Prozesse bleibt weiterhin effizient. Da alle Zustandsinformationen, die

zur Validierung ben¨

otigt werden, bereits in der Prozessvorlage enthalten sind, ist kein Zugriff

auf das Aktivit¨

aten-Repository notwendig. Tats¨

achlich k¨

onnten diese Zustandsinformationen

sogar ausschließlich zur Modellierung verwendet werden. Zur Ausf¨

uhrungszeit wird dann nur

die Information ¨

uber momentanen Zustand verarbeitet. Da der Prozess vor der Ausf¨

uhrung

validiert wurde, ist ein Weiterschalten und Verwalten aller Zust¨

ande nicht notwendig.

Dies gilt nat¨

urlich nur unter der Voraussetzung, dass alle beteiligten Aktivit¨

aten und Kom-

ponenten fehlerfrei arbeiten und korrekt modelliert wurden. Damit das WfMS gegen¨

uber

entsprechender Fehler robuster ist, sollte die Einhaltung der Zust¨

ande revalidierbar sein. Da-

zu muss auch bei laufenden Instanzen die Zustandsinformation verarbeitet und gespeichert

werden. Wenn der tats¨

achliche Zustand der Daten ¨

uberpr¨

uft wird, sollte eine Berechnung des

Soll-Zustandes aus Gr¨

unden der Performanz nicht notwendig sein. ¨

Ahnlich wie f¨

ur versteckte

Datenfl¨

usse vorgeschlagen (s. Abschnitt 3.6), ist in bestimmten F¨

allen eine ¨

Uberpr¨

ufung der

Daten auf den korrekten Zustand w¨

unschenswert.

Im Folgenden wird ein Ausblick auf weiterf¨

uhrende Aspekte gegeben, f¨

ur deren L¨

osung der

vorgestellte Ansatz als Grundlage dienen kann.

5.5.1 Parallele Zustandswechsel

Zustandswechsel k¨

onnen auch bei paralleler Ausf¨

uhrung mit Einschr¨

ankungen erlaubt werden.

In der in diesem Kapitel vorgestellten L¨

osung sind nur ¨

Anderungen in einem einzelnen paralle-

len Zweig erlaubt. Zudem m¨

ussen alle anderen Zweige, welche Zustandsforderungen enthalten

mit diesem Zweig synchronisiert sein. Diese Restriktion l¨

asst sich jedoch auflockern: Unter

dem Vorbehalt, dass die Ausf¨

uhrungsreihenfolge der beteiligten Aktivit¨

aten durch Synchro-

nisation festgelegt ist, k¨

onnen in allen parallelen Zweigen Zustandswechsel erlaubt werden.

Zus¨

atzlich k¨

onnen auch Zustandsforderungen unsynchronisiert zugelassen werden, sofern sie

alle m¨

oglichen, auch durch parallele Zweige verursachten, Zust¨

ande abdecken. In diesem Fall

muss jedoch ¨

uber weitere Mechanismen nachgedacht werden, um das Weiterschalten des Zu-

stands zu verhindern, wenn zu dem Zeitpunkt eine weitere Aktivit¨

at ausgef¨

uhrt wird, die den

Zustand gefordert hat.

Auch bez¨

uglich Zustandswechsel in einem parallel laufenden Sub-Prozess k¨

onnen die bis-

her gestellten Anforderungen gelockert werden. Zum Beispiel unter Betrachtung folgender

Situation: Eine Aktivit¨

at fordert einen Zustand, der w¨

ahrend der Ausf¨

uhrung eines parallel

laufenden Sub-Prozesses verursacht wird. Der geforderte Zustand sei dabei nicht der Endzu-

stand des Sub-Prozesses, sondern tritt w¨

ahrend dessen Ausf¨

uhrung auf. In diesem Fall muss

die Aktivit¨

at darauf warten, dass der geforderte Zustand durch den Sub-Prozess gesetzt wird.

Die Aktivit¨

at kann daher genau dann ausgef¨

uhrt werden, wenn eine Aktivit¨

at im Sub-Prozess

ausgef¨

uhrt wurde. Dies ist gleichbedeutend mit Synchronisation ¨

uber die Prozesshierarchie

hinweg.

Zu beachten sind dabei folgende Anforderungen. Der Sub-Prozess muss unbedingt einen der

geforderten Zust¨

ande im Laufe seiner Ausf¨

uhrung erreichen. Dies bedeutet f¨

ur den Sub-

Prozess, dass alle m¨

oglichen Wege zwischen geforderten Zust¨

anden und m¨

oglichen Zielzust¨

an-

den mindestens einen der geforderten Zust¨

ande der parallelen Aktivit¨

at enthalten. Der Sub-

Prozess muss eine Referenz auf das Datenelement erhalten, so dass Zustands¨

anderungen

auch f¨

ur die dar¨

uber liegende Instanz ersichtlich sind. Das WfMS muss bei Zustandswechseln

uberpr¨

ufen, ob ein geforderter Zustand der Aktivit¨

at erreicht wurde, und deren Ausf¨

uhrung

gegebenenfalls freigeben.

5.5.2 Verarbeitungswege

Der Zustandsgraph kann als ein Verarbeitungsweg f¨

ur Daten eines bestimmten Typ angese-

hen werden. So soll ein Datum einer bestimmten Verarbeitung unterlaufen, indem Aktivit¨

aten

das Datum lesen, ¨

andern und schreiben. Dabei ¨

andern die Daten bei jedem Schritt ihren Zu-

stand. Legt man den Verarbeitungsweg ¨

uber einen Zustandsgraphen fest, so erh¨

alt man eine

abstrakte Beschreibung davon, was mit den Daten passieren soll.

Zusammen mit der Information, welche Aktivit¨

aten den Zustand der Daten ¨

andern, l¨

asst sich

ein durch das WfMS und das Aktivit¨

aten-Repository gest¨

utzter Modellierungsprozess f¨

ur den

Kontrollfluss vorstellen. Dies ist ein Schritt in Richtung Datengetriebener WfMS: Die Model-

lierung orientiert sich an der Verarbeitung der Daten; der Kontrollfluss ergibt sich daraus.

So k¨

onnte die Modellierung eines Prozesses bei den Datenelementen beginnen. F¨

ur jedes Da-

tenelement kann danach ein Verarbeitungsweg ausgew¨

ahlt werden. Dabei k¨

onnte bereits eine

erste Eingrenzung geschehen, indem der Benutzer relevante Wege im Zustandsgraphen mar-

kiert. So k¨

onnte der Modellierer festlegen, welche Daten verarbeitet werden, auf welchem Weg

und mit welchem Ziel sie verarbeitet werden. Danach k¨

onnten Aktivit¨

aten zur Erreichung von

jedem Zustand angeboten werden. Denkbar w¨

are auch mit einer Aktivit¨

at f¨

ur den Zielzustand

zu beginnen und durch Aufl¨

osen von Abh¨

angigkeiten den Prozess iterativ zu vervollst¨

andigen.

Je mehr Aktivit¨

aten ausgew¨

ahlt wurden, desto mehr Abh¨

angigkeiten ergeben sich, wodurch

die Auswahl zunehmend eingeschr¨

ankt wird. Dadurch k¨

onnen die Abh¨

angigkeiten mit Hilfe

des Systems mehr und mehr semi-automatisch gel¨

ost werden k¨

onnen. So k¨

onnen durch jede

Abh¨

angigkeit, welche sich durch Daten, geforderte Zust¨

ande und dem festgelegten Verarbei-

tungsweg ergibt, Aktivit¨

aten zur L¨

osung vorgeschlagen werden.

Die Modellierung verspricht dadurch schneller und ¨

ubersichtlicher zu werden, da der Verar-

beitungsweg eines einzelnen Datums i.A. viel kleiner sein wird als ein vollst¨

andiger Prozess.

5.5.3 Allgemeine Zustandsobjekte

Der Bezugspunkt f¨

ur Zust¨

ande in den bisherigen ¨

Uberlegungen waren Daten. In WfMS sind

jedoch auch von Daten unabh¨

angige Objekte denkbar, die ebenso einen Zustand besitzen

k¨

onnen. Zum einen sind hier allerlei Ressourcen, wie z.B. Drucker, vorstellbar. Auf der ande-

ren Seite aber auch komponenteninterne Zust¨

ande, welche nicht an konkrete Daten gebunden

sind. Ein Drucker k¨

onnte zum Beispiel die Zust¨

ande ”Aus“, ”Bereit“ und ”Druck“ besitzen.

Eine Aktivit¨

at k¨

onnte den Druckerzustand ”Bereit“ einfordern.

Tats¨

achlich ließe sich das Konzept auch auf allgemeine Zustandsobjekte ¨

ubertragen. Es m¨

ussten

hierf¨

ur nur entsprechende neue Elemente in die Prozessmodellierung eingef¨

uhrt werden. Dazu

geh¨

oren neben den Zustandsobjekten selbst z.B. auch Zustandskanten und eigene Zustands-

parameter. Alternativ w¨

are jedoch auch denkbar, anstelle neuer Zustandsobjekte virtuelle

Datenelemente zu verwenden. Aufgrund der gleichen Verhaltensweise von virtuellen und kon-

kreten Datenelementen und -fl¨

ussen kann das Zustandsmodell f¨

ur beide Zwecke eingesetzt.

Eine wichtige ¨

Uberlegung zu diesem Punkt ist jedoch die Benutzerfreundlichkeit. So ist es

f¨

ur den Anwender nicht gerade einleuchtend, warum z.B. ein Drucker durch ein zustands-

behaftetes virtuelles Datenelement repr¨

asentiert werden soll. Eine explizite Modellierung als

allgemeines Objekt, welches einen Zustand besitzt, scheint daher sinnvoller. Auch in der gra-

phischen Repr¨

asentation eines Prozesses muss der Unterschied zwischen Datenelementen und

anderen Objekte, wie einem Drucker, einfach ersichtlich sein. Auf der anderen Seite wiederum

muss anhand der Darstellung der beiden Elemente ersichtlich sein, ob sie zustandsbehaftet

sind oder nicht.

Abbildung 5.16: Ein Drucker als allgemeines Zustandsobjekt

Abbildung 5.16 zeigt einen Vorschlag zur Darstellung allgemeiner Zustandsobjekte. Im Bei-

spiel wird ein Drucker durch ein wolkenf¨

ormiges Objekt dargestellt. Die Aktivit¨

at verlangt

vom Drucker den Zustand ”Bereit“. An dieser Stelle wird auch sichtbar, dass weitere Kon-

zepte ben¨

otigt werden: Der Drucker besitzt einen globalen Zustand, welcher nicht durch den

aktuellen Prozess verursacht wird. Im folgenden Abschnitt wird n¨

aher darauf eingegangen.

5.5.4 Globale Zust¨

ande

Das Beispiel mit dem Drucker als eine zustandsbehaftete Ressource bringt einen weiteren

Aspekt ins Spiel: Globalit¨

at bez¨

uglich unterschiedlicher Prozesse und Instanzen. Da ein Dru-

cker ein konkretes, einmalig existierendes Objekt ist, muss auch das ihn repr¨

asentierende

Zustandsobjekt dem entsprechen. Dies zieht eine Reihe von Konsequenzen mit sich.

Da das Zustandsobjekt global ist, muss es auch vom WfMS zentral verwaltet werden. Eine

Prozessinstanz wiederum kann nur eine Referenz auf das (einmalige) Objekt erhalten. Da nun

mehrere Instanzen parallel auf das Objekt zugreifen k¨

onnen, kann aus Sicht einer Instanz das

Objekt einen spontanen Zustandswechsel vollziehen. Die zu Beginn des Kapitels gestellte For-

derung nach der Information ¨

uber m¨

ogliche Zustands¨

uberg¨

ange zur Modellierungszeit kann

dadurch nicht mehr eingehalten werden.

Da nun nicht mehr davon ausgegangen werden kann, dass sich die Daten, bzw. bei allgemeinen

Zust¨

anden das Objekt, zum Ausf¨

uhrungszeitpunkt in einem geforderten Zustand befinden,

m¨

ussen neue Mechanismen eingef¨

uhrt werden. Dazu geh¨

ort z.B. auch, dass eine Instanz auf

das Eintreten eines bestimmten Zustands warten muss. Hier zeigt sich eine St¨

arke des Modells

mit einem Zustandsgraphen: Es ist zumindest feststellbar, ob der geforderte und erwartete

Zustand noch erreichbar ist oder nicht. So ist es im Ernstfall m¨

oglich, eine Warnung und

Aufforderung zum manuellen Eingriff an den Prozessverantwortlichen zu senden.

Um Race Conditions weitgehend verhindern zu k¨

onnen, m¨

ussen hier Synchronisationskonzep-

te eingesetzt werden. So ist es durchaus wahrscheinlich, dass mehrere Instanzen gleichzeitig

auf den Zustand ”Bereit“ eines Druckers warten. Schlussendlich darf dieser Zustand jedoch

nur von einer einzigen Instanz ge¨

andert werden.

Bei Zustandsforderungen muss dar¨

uber hinaus weiter unterschieden werden. Eine Aktivit¨

kann z.B. Daten in einem bestimmten Zustand ben¨

otigen. Sobald diese jedoch als Parameter

erhalten wurden, kann sich der Zustand der Daten ¨

andern. Bei allgemeinen Zustandsobjek-

ten kann ein geforderter Zustand auch bedeuten, dass der Zustand w¨

ahrend der gesamten

Ausf¨

uhrung erhalten bleiben muss und daher erst nach Beendigung der Aktivit¨

at wieder

ge¨

andert werden darf.

Insbesondere wenn es sich um globale Zust¨

ande handelt, muss zudem noch beachtet werden,

dass sich der Zustand auch ”von außen“ ¨

andern kann. Dies kann z.B. durch einen manuellen

Eingriff geschehen (einen Drucker ausschalten), jedoch auch vom konkreten Objekt selbst

ausgehen (Drucker geht in Zustand ”Papierstau“).

5.5.5 Mehrere Zust¨

ande

Im vorgestellten Zustandsmodell kann f¨

ur ein Datenelement eine Zustandsdefinition hinter-

legt werden. Dies bedeutet jedoch, dass alle Aktivit¨

aten und Komponenten mit den gleichen

Zust¨

anden arbeiten m¨

ussen. Realistisch sind jedoch auch Situationen, in denen eine Kom-

ponente bez¨

uglich eines Datums unterschiedliche Zust¨

ande besitzt. Ist dies bei mehreren be-

teiligten Komponenten innerhalb eines Prozesses der Fall, m¨

ussten daher unterschiedliche

Zust¨

ande parallel gelten. So k¨

onnten zum Beispiel in einem Bestellprozess mehrere Akti-

vit¨

aten der Komponenten Lagerverwaltung und Auftragsverwaltung beteiligt sein. Die Ak-

tivit¨

at ”Artikel auslagern“ der Lagerverwaltung k¨

onnte bez¨

uglich eines Datums ”Auftrag“

den Zustand ”Verf¨

ugbarkeit ¨

uberpr¨

uft“, welcher durch eine Aktivit¨

at der gleichen Kompo-

nente verursacht wird, verlangen. Gleichzeitig kann die Aktivit¨

at ”Lieferschein erstellen“ der

Auftragsverwaltung den Zustand ”Auftrag angenommen“ voraussetzen. Zust¨

ande dieser Kom-

ponenten k¨

onnen gleichzeitig gelten. Abbildung 5.17 zeigt die beschriebene Situation.

Abbildung 5.17: Mehrere Zust¨

ande?

Zur L¨

osung dieses Problems k¨

onnten die Zustandsgraphen zu Petri-Netzen aufgebl¨

aht wer-

den. Die Komplexit¨

at w¨

urde sich dadurch allerdings erheblich vergr¨

oßern. Das ganze Modell

w¨

urde h¨

ochst un¨

ubersichtlich werden.

F¨

ur voneinander unabh¨

angige Zust¨

ande k¨

onnte das Problem z.B. dadurch gel¨

ost werden, dass

mehrere Zustandsattribute mit voneinander unterschiedlichen Zustandsdefinitionen an einem

Datenelement erlaubt w¨

urden. Auch diese L¨

osung w¨

urde jedoch die Darstellung un¨

ubersicht-

licher werden lassen, da die an den Datenkanten annotierten Zustandsinformationen sich auf

unterschiedliche Zustandsdefinitionen beziehen.

Eine ¨

ahnliche L¨

osung k¨

onnte mit Hilfe der bereits angesprochenen allgemeinen Zustands-

objekte erreicht werden. Wie Abbildung 5.18 zeigt, k¨

onnte, anstelle eines Zustandsattributs

im Datenelement, letzteres mit einem Zustandsobjekt verbunden werden. Das Zustandsob-

jekt w¨

urde in diesem Fall den Zustand der Daten repr¨

asentieren. F¨

ur mehrere voneinander

unabh¨

angige Zustandsdefinitionen k¨

onnten so mehrere Zustandsobjekte mit einem Datenele-

ment verbunden werden. Dies w¨

urde die graphische Repr¨

asentation insofern auflockern, dass

Zustandsforderungen und -¨

anderungen durch Kanten zum jeweiligen Zustandsobjekt darge-

stellt w¨

urden.

Sind mehrere Zustandsdefinitionen f¨

ur ein Datenelement erlaubt, k¨

onnen Zusammenh¨

ange

zwischen Zust¨

anden auch indirekt modelliert werden. Die indirekte Modellierung w¨

urde so

aussehen, dass Aktivit¨

aten z.B. in Folge einer Forderung aus einer Zustandsdefinition, einen

Zustands¨

ubergang einer weiteren Definition verlangen k¨

onnte. Ein großer Nachteil ist jedoch,

Abbildung 5.18: Mehrere Zust¨

ande durch Zustandsobjekte

dass das WfMS den Zusammenhang nicht kennt und auch nicht kontrollieren kann. Er ergibt

sich nur indirekt aus den Zustandsforderungen und Zielzust¨

anden der Aktivit¨

aten.

5.5.6 Bezugspunkt f¨

ur Zust¨

ande

Die Zust¨

ande im vorgestellten Ansatz beziehen sich ausschließlich auf die Daten selbst. Ein

weiterer Aspekt sind jedoch Zust¨

ande, die innerhalb einer Komponente bestehen. Je nach Zu-

stand der Komponente sind unterschiedliche Methoden aufrufbar. In einem Bestellprozess ist

z.B. der Aufruf der Aktivit¨

at ”Verf¨

ugbarkeit pr¨

ufen“ erst nach der Aktivit¨

at ”Bestellung auf-

nehmen“ m¨

oglich. Dies l¨

asst sich als Zustand des dahinterliegenden Warenwirtschaftssystem

ausdr¨

ucken [2].

Der vorgestellte Ansatz k¨

onnte mit Hilfe der allgemeinen Zustandsobjekte erweitert wer-

den. Ein Zustandsobjekt repr¨

asentiert in diesem Fall die Komponente. Aktivit¨

aten dieser

Komponente k¨

onnten den Zustand der Komponente ¨

uber Zustandsparameter fordern und

andern. Hier k¨

onnten neue Darstellungen helfen, das Zustandsobjekt als Komponente zu er-

kennen. Abbildung 5.19 erweitert das Beispiel aus vorigem Abschnitt. Es stellt eine m¨

ogliche

Darstellung von Komponenten, welche bzgl. eines Datums Zust¨

ande besitzen, vor.

Abbildung 5.19: Komponenten-Zust¨

ande durch Zustandsobjekte

Auch hier muss unterschieden werden, ob der Zustand nur innerhalb eines Prozesses gilt

oder ob die Komponente einen globalen Zustand besitzt. Zus¨

atzlich kann der Zustand auch

noch an einen Datenkontext gebunden sein. So besitzt das Warenwirtschaftssystem bez¨

uglich

einer bestimmten Bestellung z.B. den Zustand ”Bestellung angenommen“. Dieser Zustand

w¨

urde global gelten. Das bedeutet, dass die Komponente sich, bez¨

uglich einer Bestellung, in

diesem Zustand befindet, unabh¨

angig davon, welche Prozessinstanz ihre Aktivit¨

aten aufruft.

Dadurch existieren Zust¨

ande, die sowohl an eine Komponente als auch an Daten gebunden

sind.

Der Bezug zur Komponente ist in diesem Fall wichtig f¨

ur die Funktionalit¨

at ihrer Akti-

vit¨

aten. W¨

urde der Zustand ¨

uber ein allgemeines Zustandsobjekt bzw. ein Datenelement rea-

lisiert, welches auch durch Aktivit¨

aten anderer Komponenten Zustands¨

anderungen erfahren

k¨

onnte, ist die Konsistenz zwischen der Komponente und dem Zustand ihres Zustandsobjekts

nicht mehr sichergestellt. Dies bedeutet, dass es m¨

oglich sein muss, ein Zustandsmodell zu

definieren, welches nur seinen Zustand nur durch die Aktivit¨

aten einer einzelnen Komponente

andern kann.

5.6 Zusammenfassung

Das vorgestellte Beschreibungsmodell erm¨

oglicht die Darstellung von komplexen Zusammen-

h¨

angen zwischen Aktivit¨

aten, die auf Zust¨

ande von Daten beruhen. Auch f¨

ur weiterf¨

uhrende

Konzepte, wie z.B. globale Zustandsobjekte, ist das Modell offen und erweiterbar. Inwiefern

die angesprochenen Aspekte im praktischen Einsatz eine Rolle spielen, muss jedoch zun¨

achst

durch weitere Anforderungsanalysen erarbeitet werden.

Kapitel 6

Ausblick

Das Thema Plug & Play in WfMS umfasst eine Vielzahl von Aspekten. In der vorliegenden

Arbeit wurden vor allem Aspekte betrachtet, die das Prozessmodell betreffen. Dazu geh¨

oren

haupts¨

achlich m¨

ogliche Abh¨

angigkeiten zwischen Aktivit¨

aten. Die Integration der Beschrei-

bungen von Abh¨

angigkeiten ist ein wichtiger Schritt, um Plug & Play anbieten zu k¨

onnen. Die

Information, ob eine Aktivit¨

at ¨

uberhaupt an einer bestimmten Stelle im Prozess ausgef¨

uhrt

werden kann, stellt eine notwendige Grundlage dar. Ausgehend von dieser Grundlage k¨

onnen

weiterf¨

uhrende ”Plug & Play“-Konzepte in WfMS eingef¨

uhrt werden. Viele weiterf¨

uhrende

Fragestellungen, z.B. die Gestaltung von benutzerfreundlichen Oberfl¨

achen in diesem Kon-

text, sind noch offen.

Ein Hauptziel der Integration von Plug & PlayKonzepten in WfMS ist, die Erstellung von

Prozessen zu unterst¨

utzen und zu beschleunigen. Um dies zu erm¨

oglichen, soll die Auswahl

und Komposition von Aktivit¨

aten und Komponenten systemseitig durch das Aktivit¨

aten-

Repository unterst¨

utzt werden. Dies soll ¨

uber einen durch Vorschl¨

age des WfMS gest¨

utzten,

interaktiven Prozess mit dem Benutzer erfolgen. Ebenso geh¨

ort dazu, dass das WfMS den

Benutzer ¨

uber fehlgeschlagene Abh¨

angigkeitspr¨

ufungen aufkl¨

art. Neben Erkl¨

arungen, die f¨

jeden Benutzer verst¨

andlich sind, sollten auch noch Vorschl¨

age zur L¨

osung des Problems an-

geboten werden. Ein wichtiges Mittel zur Modellierung und Erkl¨

arung von Zusammenh¨

angen

sind auch graphische Darstellungen. Sie sollten Prozesse und Abh¨

angigkeiten anschaulich

vermitteln k¨

onnen, ohne dass der Benutzer viel ¨

uber verwendete Notationen lernen muss.

Dadurch k¨

onnen die Modellierung von neuen Prozessen sowie ¨

Anderungen durch Benutzer

zeitnah und effizient umgesetzt werden.

Abgesehen von der Verwendung von Plug & Play innerhalb des WfMS, ist auch die Integra-

tion neuer Komponenten ein wichtiger Aspekt. Diese m¨

ussen dem WfMS zun¨

achst bekannt

gemacht werden. Das bedeutet, dass Dienste und Methoden als Aktivit¨

aten im Beschrei-

bungsmodell des WfMS spezifiziert werden m¨

ussen. Auch dieser Vorgang sollte vom WfMS in

”Plug & Play“-Manier unterst¨

utzt werden. Da bei den Komponenten jedoch heterogene Be-

schreibungmodelle (EJB, UML, WSDL, etc.) zu erwarten sind, m¨

ussen hier unterschiedliche

Schnittstellen angesprochen werden. Dieser ”Import“ neuer Komponenten ist kein zeitkriti-

scher Vorgang. Daher k¨

onnen auch aufw¨

andige Analysen verwendet werden, um dem Benutzer

m¨

oglichst viel Arbeit bei der Integration zu ersparen.

Abh¨

angigkeiten, welche auf zustandsbehafteten Daten basieren, wurden in der vorliegen-

den Arbeit ausf¨

uhrlich untersucht und erl¨

autert. Die vorgestellten Ans¨

atze bieten eine einfa-

che bzw. eine umfangreiche L¨

osung, um die Abh¨

angigkeiten in das Beschreibungsmodell von

ADEPT zu integrieren. Bei der Entwicklung der Ans¨

atze wurde eine effiziente Analyse der

Zust¨

ande im Prozess bedacht. Es wurden auch weitere zustandsbasierte Abh¨

angigkeiten, wie

z.B. durch Ressourcen, betrachtet. Der Ansatz mit Zustandsautomaten bietet hier eine gute

Grundlage f¨

ur weiterf¨

uhrende Konzepte.

Literaturverzeichnis

[1] Aristaflow Projekt. http://www.aristaflow.de. Abgerufen am 26. Sept. 2005.

[2] H. Acker, C. Atkinson, P. Dadam, S. Rinderle und M. Reichert. Aspekte der kompo-

nentenorientierten Entwicklung adaptiver prozessorientierter Unternehmenssoftware. In

Tagungsband 1, 2004.

[3] J¨

org Ackerman, Frank Brinkop, Stefan Conrad, Peter Fettke, Andreas Frick, Elke Gli-

stau, Holger Jaekel, Otto Kotlar, Peter Loos, Heike Mrech, Erich Ortner, Ulrich Raape,

Sven Overhage, Stephan Sahm, Andreas Schmietendorf, Thorsten Teschke und Klaus

Turowski. Vereinheitlichte Spezifikation von Fachkomponenten. Memorandum des GI-

Arbeitskreises 5.10.3 Komponentenorientierte betriebliche Anwendungssysteme, 2002.

[4] Peter Dadam, Manfred Reichert und Klaus Kuhn. Clinical Workflows - The Killer Ap-

plication for Process-oriented Information Systems? Seiten 36–59, 2000.

[5] Peter Dadam, Manfred Reichert, Stefanie Rinderle und Colin Atkinson. Auf dem Weg zu

prozessorientierten Informationssystemen der n¨

achsten Generation - Herausforderungen

und L¨

osungskonzepte. 2005.

[6] Peter Fettke und Peter Loos. Entwicklung eines Metamodells f¨

ur die ’Vereinheit-

lichte Spezifikation von Fachkomponenten’. Rundbrief der GI-Fachgruppe WI-MobIS,

10(2):121–130, 2003.

[7] Object Management Group. Common Object Request Broker Architecture (CORBA),

v3.0, Chapter 3. 2002. http://www.omg.org/cgi-bin/doc?formal/02-06-07.

[8] Object Management Group. UML 2.0 Superstructure Specification. 2004. Abgerufen

am 26. Sept. 2005.

[9] D. Hollingsworth. Workflow Management Coalition - The Workflow Reference Model.

Technical report, The Workflow Management Coalition, 1995.

[10] Sun Microsystems. EJB 2.1 Specification Final Release 2.1 FR. 2003. http://java.

sun.com/products/ejb/docs.html.

[11] Manfred Reichert. Dynamische Ablauf¨

anderungen in Workflow-Management-Systemen.

Dissertation, Universit¨

at Ulm, 2000.

[12] Manfred Reichert und Peter Dadam. ADEPTflex - Supporting Dynamic Changes

of Workflows Without Losing Control. Journal of Intelligent Information Systems,

10(2):93–129, 1998.

[13] Manfred Reichert, Stefanie Rinderle und Peter Dadam. ADEPT Workflow Management

System: Flexible Support For Enterprise-wide Business Processes (Tool Presentation).

Seiten 371–379.

[14] Manfred Reichert und Dietmar Stoll. Komposition, Choreograhpie und Orchestrierung

von Web Services - Ein ¨

Uberblick. EMISA Forum, 24(2):21–32, 2004.

[15] Stefanie Rinderle und Peter Dadam. Schemaevolution in Workflow-Management-

Systemen. Informatik-Spektrum, 26(1):17–19, 2003.

[16] Steffanie Rinderle. Schema Evolution in Process Management Systems. Dissertation,

Universit¨

at Ulm, 2004.

[17] Jochen R¨

utschlin, G¨

unter Sauter, J¨

urgen Sellentin, Klaudia Hergula und Bernhard Mit-

schang. Komponenten-Middleware - Der n¨

achste Schritt zur Interoperabilit¨

at von IT-

Systemen. 2001.

Abbildungsverzeichnis

1.1 Zuweisen von Arbeitsschritten mittels Plug & Play . . . . . . . . . . . . . . . 2

2.1 Workflow Reference Model [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Business Process Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Knotenkonstrukte und Blockstruktur von Prozessen in ADEPT . . . . . . . . 8

2.4 Zusammenhang zwischen Knoten, Aktivit¨

at und dahinterliegender Komponente 9

2.5 Alternative Verzweigung, parallele Verzweigung und Synchronisationskante . 10

2.6 Ein Knoten mit lesender und schreibender Datenkante . . . . . . . . . . . . . 11

2.7 Darstellung der Zust¨

ande von Aktivit¨

aten.................... 11

3.1 Aktivit¨

aten werden mittels Plug & Play an Knoten hinterlegt . . . . . . . . . 15

3.2 Zusammenh¨

ange im WfMS bez¨

uglich Aktivit¨

atenbeschreibungen . . . . . . . 19

3.3 Bearbeitung eines Vorlaufs in einem Buchhaltungsvorgang . . . . . . . . . . . 24

3.4 Erstellen eines Angebots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 Modellierung eines versteckten Datenflusses mit einem virtuellen Datenelement 28

3.6 Modellierung einer semantischen Abh¨

angigkeit durch einen virtuellen Datenfluss 29

4.1 Die Erg¨

anzung der Beschreibung einer Aktivit¨

at um Zustandsinformationen . 35

4.2 Setzen und Fordern von Zust¨

anden........................ 35

4.3 Vorlaufprozess mit Zustandsattribut . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 Vorlaufprozess mit Zust¨

anden in einem virtuellen Datenelement . . . . . . . . 38

5.1 Von losen Zust¨

anden zu Zustandsautomaten . . . . . . . . . . . . . . . . . . . 41

5.2 Zustandsdefinition f¨

ur den Vorlauf . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Mehrere Parameter f¨

ur ein einzelnes Datenelement . . . . . . . . . . . . . . . 45

5.4 Aktivit¨

at mit erweiterter Zustandsbeschreibung . . . . . . . . . . . . . . . . . 46

5.5 Zustandsdefinition zur Verarbeitung eines Angebots . . . . . . . . . . . . . . 48

5.6 Verarbeitung eines Angebots mit Zustandsinformationen . . . . . . . . . . . 48

5.7 Ausf¨

uhrung einer Aktivit¨

at mit zustandsbehafteten Daten . . . . . . . . . . . 49

5.8 Geforderte und erreichbare Zust¨

ande in einer fehlerhaften Modellierung . . . 50

5.9 Synchronisation von KF und DF . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.10 Vom DF unabh¨

angige Synchronisation . . . . . . . . . . . . . . . . . . . . . . 55

5.11 Transitive Synchronisation des DF . . . . . . . . . . . . . . . . . . . . . . . . 56

5.12 Synchronisation durch abw¨

ahlbare Sync-Kante . . . . . . . . . . . . . . . . . 56

5.13 Synchronisation aus einem verschachtelten Oder-Block . . . . . . . . . . . . . 57

5.14 Synchronisation aller alternativen Zweige . . . . . . . . . . . . . . . . . . . . 57

5.15 Indirekte Synchronisation aller alternativen Zweige . . . . . . . . . . . . . . . 57

5.16 Ein Drucker als allgemeines Zustandsobjekt . . . . . . . . . . . . . . . . . . . 64

5.17 Mehrere Zust¨

ande?................................. 66

5.18 Mehrere Zust¨

ande durch Zustandsobjekte . . . . . . . . . . . . . . . . . . . . 67

5.19 Komponenten-Zust¨

ande durch Zustandsobjekte . . . . . . . . . . . . . . . . . 67

Anhang A

Algorithmen

Listing A.1: CacheAndCheckStates

1CacheAndCheckStates (CFS , DFS , d)

3Speichern der Zust¨ande an Knoten welche Zustandsforderungen /- ¨anderungen

4bez¨uglich Datenelement d haben sowie an Block - Ende - Knoten .

6Zus¨atzliche Knotenattribute , Knoten n:

7RIS (n): ReachableInputStates ( duplikatfreie Menge v. Zust¨anden )

8ROS (n): ReachableOutputStates ( duplikatfreie Menge v. Zust¨anden )

9Counter (n): Anzahl bereits bearbeiteter eingehender Kontrollfluss -

10 Kanten . Wird f¨ur OR - Joins ben¨otigt , bei parallelen Splits

11 wird eh h¨ochstens ein zweig ber¨ucksichtigt .

12 Alle Attribute mit 0 bzw . ∅initialisiert .

14 Pr¨adikate / Funktionen :

15 IS(n): InputStates von n

16 correspondingBlockNode (n): Der Join - Knoten bzgl . eines Splits und

17 Umgekehrt

18 succ (n): Nachfolger von n bzgl . Kontrollfluss - Kanten

19 id(n) : ID des Knotens nach topologischer Sortierung .

20 branch (n): Die Verzweigung eines Knotens .

21 c_pred_branch (n , branch ) : Der Vorg¨angerknoten von n , welcher auf der

22 Verzweigung branch liegt . Diese Methode ist notwendig , um die

23 Knoten auf einer Sequenz in einem Zweig zu finden .

25 Einige wichtige Variablen

26 StateNodes :

27 Menge der Knoten welche von d Zust¨ande fordert / ¨andert ( gegeben ).

28 NodeStack :

29 Stack aus Tupeln ( node , States0 ) mit zu bearbeitender

30 Knoten und m¨oglicher Eingangs - Zust¨ande ( mit Methoden push und pop ).

31 node:

32 Momentan betrachteter Knoten

33 States0:

34 Menge der m¨oglichen Eingangs - Zust¨ande , des momentan betrachteten

35 Knotens.

36 SuccStates :

37 Menge der m¨oglichen Ausgangs - Zust¨ande , welche nach dem momentan

38 betrachteten Knoten erreichbar sind .

40 // Beginn : Prozess - Parameter auf den Startknoten ¨ubertragen , diesen

41 // auf den Knoten - Stack legen .

42 RIS ( startNode ) := Zust¨ande ¨uber Eingabeparameter des Prozesses bzw . ∅

43 push NodeStack ( startNode , RIS ( startNode ) , ∅)

45 // so lange iterieren , bis der Stack leer ist

46 while ( ( node , States0 ) := pop NodeStack ) {

47 // 1. Schritt : ¨

Uberpr¨ufen von Zust¨anden , Finden und setzen von

48 // Folgezust¨anden.

49 // Falls n den Zustand von d ¨andert , oder einen Zustand fordert :

50 if( node ∈StateNodes ){

51 // pr¨ufen ob die Zustandsforderung verletzt wird ,

52 // das Ergebnis ist OK , falls :

53 // - Die m¨oglichen Eingangs -Zust¨ande eine Teilmenge der geforderten

54 // Zust¨ande sind

55 // - oder der spezielle Zustand Any in den Forderungen enthalten ist

56 // - Da der Knoten Zust¨ande fordert , darf die Menge der m¨oglichen

57 // Eingangs - Zust¨ande nicht leer sein

58 if ( RIS ( node ) 6=∅&&

59 (RIS (node ) ⊆IS ( node ) || Any ∈IS ( node ))

60 ) {

61 // Zust¨ande OK

62 }

63 else {

64 // ung¨ultiger DF

65 }

67 // setzen der m¨oglichen Ausgangs - Zust¨ande

68 ROS ( node ) := alle GoalStates mit RequiredState in RIS (node )

70 // falls Any verwendet wird , auch feforderte Zust¨ande weiterreichen

71 if(Any ∈IS( node ))

72 ROS ( node ) := ROS (node) ∪( RIS (node ) \RequiredStates)

74 // die folgenden m¨oglichen Zust¨ande entsprechen den m¨oglichen

75 // Ausgangszust¨anden

76 SuccStates := ROS ( node )

77 }

78 else {

79 // Falls der Knoten keine Zustandsforderung besitzt , jedoch Zust¨ande

80 // in RIS gesetzt sind , diese auf ROS ¨ubertragen (z.B. bei Block -

81 // Anfang - Knoten ).

82 if(RIS( node ) 6=∅)

83 ROS ( node ) := RIS ( node )

85 // keine ¨

Anderung in der neuen Zustandsmenge

86 SuccStates := States0

87 }

89 // 2. Schritt : Finden von relevanten Nachfolgern und ¨

Uberspringen von

90 // irrelevanten Bl¨ocken .

91 // Initialisieren der Menge der relevanten Nachfolger .

92 RelevantSuccessors := ∅

94 // Block - Anfang - Knoten :

95 // - Falls kein Knoten mit Zustandsforderung innerhalb des Blocks ist ,

96 // den zugeh¨origen Join - Knoten als Nachfolger nehmen .

97 // - Sonst : Untersuchen welche Zweige weiter verfolgt werden m¨ussen .

98 if ( node AND - Split , OR - Split , Loop - Start ) {

99 // der zum Split geh¨orende Join - Knoten

100 joinNode := correspondingBlockNode ( node )

101

102 // ¨

Uberpr¨ufe ob ein Knoten mit Zustandsforderung zwischen Split -

103 // und Join - Knoten liegt ( unter Verwendung der topologischen

104 // Sortierung ):

105 if(∃n∈StateNodes with : id (node ) < id(n) < id ( joinNode )) {

106 // RIS setzen ( falls nicht schon geschehen )

107 if(n /∈StateNodes )

108 RIS ( node ) := States0

109

110 // Zweigen mit Zustandsforderung folgen . Es werden alle

111 // Nachfolger untersucht , im Falle eines OR - Splits k¨onnen

112 // Knoten ( bzw . Zweige ) relevant sein . Ansonsten wird

113 // in RelevantSuccessors genau ein Knoten sein .

114 AllSuccessors := c_succ ( node )

115 for ( sn ∈AllSuccessors ) {

116 // letzten Knoten der Verzweigung von sn finden

117 lastBranchNode := c_pred_branch (joinNode , branch (sn))

118

119 // falls ein Knoten mit Zustandsforderung auf dem Zweig

120 // liegt , dem Zweig folgen ( Aufnahme in RelevantSuccessors ).

121 if(∃n∈StateNodes with : id ( sn) <= id(n) <= id(

lastBranchNode))

122 RelevantSuccessors := RelevantSuccessors ∪sn

123 }

124

125 // Falls es sich um einen OR - Block handelt , und nicht

126 // alle Verzweigungen Zustandsforderungen enthalten ,

127 // m¨ussen die aktuellen Zust¨ande ebenfalls ¨ubertragen werden .

128 // Zust¨ande der relevanten Verzweigungen werden hinzugef¨ugt .

129 // Korrektur des Counters , da nicht allen Zweigen gefolgt wird .

130 if ( node OR - Split && # RelevantSuccessors < # AllSuccessors ) {

131 RIS ( joinNode ) := ROS ( node )

132 Counter ( joinNode ) := # RelevantSuccessors

133 }

134 }

135

136 // Es gibt keine Zustandsforderung im Block : N¨achster zu

137 // betrachtender Knoten ist der zugeh¨orige Join - Knoten

138 else

139 RelevantSuccessors := joinNode

140 }

141

142 // Kein Block - Anfang - Knoten : Genau ein Nachfolger in c_succ ( node ).

143 else {

144 RelevantSuccessors := c_succ ( node )

145 }

146

147 // 3. Schritt : Zust¨ande auf relevante Nachfolger ¨ubertragen , Nachfolger

148 // auf den Stack legen .

149 for ( sn ∈RelevantSuccessors ) {

150 // Falls sn ein Block -Ende - Knoten ist , feststellen ob es im Block

151 // eine Zustandsforderung gab . Ist dies der Fall , muss RIS gesetzt

152 // werden.

153 blockChange := false

154

155 if(sn OR -Join , AND -Join , Loop -End ) {

156 // ¨

Uberpr¨ufen ob Knoten mit Zustandsforderungen zwischen

157 // Split - und Join - Knoten liegen :

158 if(∃n∈StateNodes with : id ( correspondingBlockNode (sn )) < id(n)

< id(sn)) {

159 blockChange := true

160 }

161 }

162

163 // Falls in einem AND -Block eine ¨

Anderung war:

164 // RIS auf die Folgezust¨ande setzen .

165 if(sn AND - Join && blockChange ) {

166 RIS ( sn) := SuccStates

167 }

168

169 // OR - Join : Die m¨oglichen Zust¨ande der momentanen Verzweigung der

170 // m¨oglichen Eingangs - Zust¨anden des Knotens hinzuf¨ugen .

171 else if(sn OR - Join && blockChange ) {

172 RIS ( sn) := RIS (sn ) ∪SuccStates

173 SuccStates := RIS ( sn)

174 }

175

176 // Schleifen , Forderung : Am Ende des Loops m¨ussen die gleichen

177 // Zust¨ande wie zu Beginn m¨oglich sein .

178 else if(sn LOOP - End && blockChange ) {

179 RIS ( sn) := SuccStates

180 if(RIS(sn) 6⊆ RIS ( correspondingBlockNode (sn))) {

181 // Fehler im Datenfluss !

182 }

183 }

184

185 // Der Knoten besitzt eine Zustandsforderung , Momentane Zust¨ande

186 // in RIS (sn ) speichern .

187 else if(sn ∈StateNodes ) {

188 RIS ( sn) := SuccStates

189 }

190

191 // OR - Join : Beim Abarbeiten der letzten relevanten Oder - Verzweigung

192 // den Nachfolger auf den Knoten - Stack legen , ansonsten den Counter

193 // erh¨ohen .

194 // Andere Knoten : Nachfolger auf den Knoten - Stack legen .

195 if (node ! OR - Join || Counter ( sn) = # eing . KF - Kanten - 1)

196 push NodeStack (sn , SuccStates )

197 else

198 Counter ( sn) := Counter ( sn) + 1

199 }

200 }

Erkl¨

arung

Hiermit erkl¨

are ich, Kevin G¨

oser (Matrikel-Nr. 448692), dass ich diese Diplomarbeit

selbst¨

andig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel

verwendet habe.

Kevin G¨

oser

Ulm, den 30.09.2005