scieee Science in your language
[en] (orig)
Anwendungssp ezische Anforderungen an
Workow{Management{Systeme am Beispiel der Dom
ane
Concurrent Engineering
T. Beuter, P. Dadam
Universit
at Ulm
Zusammenfassung
Workow{Management{Systeme (WFMS) erob ern sich neue Anwendungsgebiete mit jeweils
sp ezischen Anforderungen an die Leistungsf
ahigkeit dieser Systeme. Neb en den Anfor-
derungsprolen an WFMS aus verschiedenen Anwendungsgebieten werden hier b esonders
die Anforderungen aus dem Bereich des Concurrent Engineering aufgezeigt. Die jeweiligen
anwendungssp ezischen Anforderungen f
uhren nichtnur zu einer groen Zahl unterschied-
lichm
achtiger Mo dellierungskomp onenten, sondern auchzu verschiedenen Alternativen f
ur
m
ogliche Laufzeitumgebungen der WFMS. Der Bericht zeigt die Probleme auf, die sich daraus
f
ur WFMS{Anwender und {Entwickler ergeb en, und leitet praxisrelevante Fragestellungen
ab, die aus wissenschaftlicher Sicht zu b earb eiten sind.
1 Einleitung
In vielen Gesch
aftsb ereichen wird ein komplexer Vorgang (Gesch
aftsproze, Ablauf ) nichtvon
einem Mitarb eiter allein, sondern in Zusammenarb eit mit Mitarb eitern der eigenen o der ande-
rer Abteilungen und Unternehmen durchgef
uhrt, die im Rahmen dieses Vorgangs Teilauftr
age
erf
ullen. Beispiele hierf
ur sind Reiseplanung und {abrechnung, Untersuchungszyklen in Kliniken
[36, 16], Kreditantr
age und {anpassungen, Versicherungsantragsb earb eitung o der Fertigungs-
prozeplanung und {steuerung [64]. Die Ko ordination dieser zum Teil komplexen und r
aumlich
weit verteilten Abl
aufe wird von klassischen Informationssystemen (datenbankbasierten Anwen-
dungen) nur sehr unzureichend unterst
utzt, da sie zur
statischen
Verwaltung von Informatio-
nen entwickelt wurden. Der
dynamische
Teil dieser Abl
aufe, wie das Zuteilen neuer Auftr
age,
der Austauschvon Informationen zwischen Mitarb eitern o der die Festlegung und
Ub erwachung
zeitlicher Beschr
ankungen, erfolgt deshalb h
aug informell zwischen den einzelnen b eteiligten
Personen und verursacht einen nicht unerheblichen Zusatzaufwand.
Will man mit konventionellen Programmiermetho den auch b eim dynamischen Teil der Abl
aufe
EDV{Unterst
utzung bieten, so f
uhrt dies zu sehr komplexen Anwendungsprogrammen: Der ge-
samte Informations{ und Kontrollu, einschlielich die in verteilten Anwendungen sehr aufwen-
dige Fehlerb ehandlung, mu explizit ausprogrammiert werden. Hinzu kommt, da diese
"
hart
verdrahteten\ Abl
aufe nur schwer zu validieren, zu warten sowie an organisatorische o der funk-
tionale
Anderungen anzupassen sind.
Diese Arb eit entstand im Rahmen eines von der Daimler-Benz-Forschung Ulm gef
orderten Forschungspro jekts.
1
Ulmer Informatik-Berichte, Nr. 96-04, Juni 1996
2 ANWENDUNGSBEISPIEL: CONCURRENT ENGINEERING
2
WFMS [23,30] bieten hier durchTrennung von Ablauogik (
dynamisch
) und eigentlichem An-
wendungsco de (
statisch
) einen vielversprechenden Ansatz. Durch
"
Herausziehen\ der Ablauo-
gik aus dem Anwendungsco de kann ein Ablauf schnell sp eziziert,
ub er Analyse b eziehungsweise
Animation validiert und gegeb enenfalls rasch an neue o der ver
anderte Anforderungen angepat
werden.
Ein WFMS
1
besteht aus einer
Buildtime{Komponente
zur Mo dellierung und Validierung von
Abl
aufen, sogenannten
Workows
, und einer
Runtime{Komponente
f
ur deren Ausf
uhrung (Lauf-
zeitumgebung). Die Runtime{Komp onente eines WFMS b esteht wiederum aus einer o der mehre-
ren
WF{Engines
,welche die eigentliche Ausf
uhrung der Workows
ub ernehmen. Die
Architektur
eines WFMS legt die Zahl und das Zusammenspiel der f
ur eine Workow{Ausf
uhrung b en
otigten
WF{Engines, ihre funktionale Aufgliederung in Komp onenten (Kontrollusteuerung, Organi-
sationsverwaltung) sowie ihre physikalische Verteilung auf Rechnerknoten fest.
Aufgrund ihres generischen Ansatzes k
onnen WFMS im Prinzip zur Mo dellierung und
Ausf
uhrung von Abl
aufen aus b eliebigen Anwendungsgebieten eingesetzt werden. Neb en
"
klas-
sischen\ Bereichen, wie zum Beispiel der B
uroautomatisierung [27, 63, 40] o der der Software{
Entwicklung [1, 46], werden in letzter Zeit WFMS auch in anderen Gebieten eingesetzt. Beispiele
hierf
ur sind medizinisch{organisatorische Abl
aufe [17,16,57,43] o der Concurrent{Engineering{
Anwendungen [48, 47, 2, 53,45, 56, 35].
Durch diese breitgef
acherten Einsatzgebiete entstehen jedo chzus
atzliche
anwendungsspezische
Anforderungen
an WFMS, die im Rahmen dieses Berichts skizziert werden sollen (Abschnitt 3).
Dab ei wird neb en Anforderungen aus anderen Anwendungsgebieten (Abschnitt 3.2) insb esondere
auf Anforderungen aus dem Bereich des Concurrent Engineering (Abschnitt 3.1) eingegangen.
Hierf
ur wird in Abschnitt 2 ein Beispiel b eschrieb en, das typischf
ur viele Abl
aufe des Concurrent
Engineering ist. Abschnitt 4 b eschreibt die Probleme, die sich aus den anwendungssp ezischen
Anforderungen f
ur Anwender und Entwickler von WFMS ergeb en. Im darauf folgenden Abschnitt
werden Herausforderungen an die Forschung formuliert, welche auf no ch oene Fragestellungen
hinweisen. Der Bericht endet mit
Ub erlegungen b ez
uglich einer WFMS{Architektur, welche die
zu Beginn aufgestellten Concurrent{Engineering{sp ezischen Anforderungen umsetzen kann.
2 Anwendungsb eispiel: Concurrent Engineering
Wie es der Begri
Concurrent Engineering
schon andeutet, werden komplexe Entwicklungspro-
zesse in der Regel
gemeinsam
von
mehreren
Personen durchgef
uhrt, deren zum Teil
gleichzeitig
stattndende Einzelt
atigkeiten geeignet ko ordiniert werden m
ussen. Ein p opul
ares Beispiel daf
ur
ist die Konstruktion und der Bau von Fahrzeugen. Auch die Dauer eines Entwicklungsprozesses
und die h
aug anzutreende r
aumliche Trennung der involvierten Personen sind Indizien daf
ur,
da sich der Einsatz von WFMS im Bereich des Concurrent Engineering lohnt.
Die prinzipiell e Eignung von WFMS soll anhand des im folgenden b eschrieb enen vereinfach-
ten Beispiels
"
Konstruktion und Fertigung von Leitungsb
undeln\[56, 35] gezeigt werden. Im
Abschnitt 3.1 werden dann einige Anforderungen an WFMS formuliert, welche sp ezischf
ur
Concurrent{Engineering{Anwendungen sind.
1
Im Bereich der WFMS existiert eine verwirrend hohe Zahl verschiedener Terminologien (siehe [67] f
ur eine
Gegen
ub erstellun g der Begrie). Die hier verwendeten Begrie orientieren sich am Referenzmo dell der
Work-
ow Management Coalition (WfMC)
, einem Standardisierun gsgremi um b estehend aus f
uhrenden Herstellern von
WFMS [68].
3 ANWENDUNGSSPEZIFISCHE ANFORDERUNGEN AN WFMS
3
Beim elektrischen Anlagenbau in Flugzeugen werden Einzellei tungen elektrischer Anlagen mit
gleichem o der
ahnlichem physikalischem Verlauf zu
Leitungsb
undeln
zusammengefat.
Das Zusammenspiel der b ei diesem Proze involvierten Einzelschritte l
at sich am b esten
ub er
einen
anlagenbezogenen
und einen
b
undelbezogenen
Ablauf b eschreib en, zwischen denen Daten-
abh
angigkeiten existieren (siehe Abbildung 1 a und 1 b)
2
.
Zuerst wird von (verschiedenen) Mitarb eitern der Organisationseinheit
Systemdenition
die
prinzipiell e Funktionsweise jeder im Flugzeug einzubauenden elektrischen Anlage durch jeweils
einen
Wirkschaltplan (principal diagram)
b eschrieb en (CAD{Zeichnung, Teilschritt
"
Wirkschalt-
plan erstel len\
). Da dieser Teilschritt f
ur jede Anlage einmal aufgerufen wird, werden mehre-
re Instanzen des anlagenb ezogenen Ablaufs gestartet. Der darauf folgende Teilschritt
"
Wiring
Diagram erstel len\
ben
otigt als Eingab eparameter VKE{Blo ckschaltbilder
3
, so da die ent-
sprechenden anlagenb ezogenen Abl
aufe solange blo ckiert sind, bis diese Schaltbilder vorliegen.
Diese Daten werden im b
undelb ezogenen Ablauf durch den Teilschritt
"
VKE{Blockschaltbild
erstel len\
erzeugt (Interworkow{Abh
angigkeit). Um sp
atere Mo dikationen an den VKE{
Blo ckschaltbildern durchnachtr
aglicheintreende Wirkschaltpl
ane m
oglichst auszuschlieen,
wird in der Regel eine gr
oere Zahl an Wirkschaltpl
anen angesammelt, b evor der Teilschritt
"
VKE{Blockschaltbild erstel len\
im b
undelb ezogenen Ablauf durch einen Mitarb eiter aus dem
Bereich
Konstruktion
b earb eitet wird.
NachFertigstellung der b en
otigten VKE{Blo ckschaltbilder werden im Teilschritt
"
Wiring Dia-
gram erstel len\
die Wirkschaltpl
ane eb enfalls im Bereich Konstruktion durch die in den Schalt-
bildern enthaltenen Informationen (Leitungsnummern, Zwischenstecker, ...) zu
Wiring Dia-
grams
erweitert.
Die automatischen Teilschritte
"
Ger
ateliste erstel len\
b eziehungsweise
"
Leitungsliste erstel len\
extrahieren aus den einzelnen Wiring Diagrams (CAD{Zeichnungen) eine Liste der b en
otigten
Ger
ate b eziehungsweise Leitungen, die wiederum im b
undelb ezogenen Ablauf zu b
undelsp ezi -
schen Listen zusammengefat werden (Organisationseinheit
Fertigungsunterlagen{Erstel lung
).
Die f
ur die b
undelsp ezi schen Leitungslisten b en
otigten L
angenangab en werden im Teilschritt
"
Leitungsb
undel Schemazeichnung erstel len (VKM)\
(Bereich Konstruktion) anhand genauer
Mo ckup
4
{Messungen festgelegt. Dieser Bearb eitungsschritt erfolgt meist parallel zur Erstellung
der Wiring Diagrams. Die VKM{Schemazeichnungen dienen auch als Vorlage f
ur die Konstruk-
tion des Verlegebretts, auf dem dann im
Fertigungsbereich
das Leitungsb
undel manuell erstellt
wird.
3 Anwendungssp ezische Anforderungen an WFMS
Dieser Abschnitt b eschreibt anwendungssp ezische Anforderungen aus dem Bereich des Con-
current Engineering (Abschnitt 3.1) sowie aus anderen Einsatzgebieten von WFMS (Abschnitt
3.2). Auerdem werden in Abschnitt 3.3 allgemeine Anforderungen an eine WFMS{Architektur
formuliert.
2
Auf die Bedeutung der unterschiedlichen Knotenformen in Abbildung 1 (4/6-eckig) wird sp
ater n
aher
eingegangen.
3
In einem VKE{Blo ckschaltbil d werden die Einzelleitu ngen verschiedener elektrischer Anlagen zu (vorl
augen)
Leitungsb
undel n zusammengefat.
4
Ein Mo ckup ist ein mastabsgetreues Mo dell des Flugzeug(abschni tt)s.
3 ANWENDUNGSSPEZIFISCHE ANFORDERUNGEN AN WFMS
4
Leit.
fertigen
Geometrie Längen
Bündel
längen
konstruieren
Leitungsbündel
Leitungsbündelzugehörigkeit
aufbereiten
Leitungsbündelzugehörigkeit
Geräteliste nach
Verlegebrett
Leitungsliste nach
3 of 3
aufbereiten
Wirkschaltplan
erstellen
of PDset
Wiring Diagram
erstellen
erstellen (VKM)
fork
fork
Interworkflow-Abängigkeiten
Interworkflow-Knoten
regulärer Knoten
join
fork
2 of 2
2 of 2
parallele Verzweigung
Vereinignung einer parallelen Verzweigunug
erstellen
Leitungsliste
2 of 2
3 of 3
join
Zeichnungsnummer
Spezifikation
Wirk-
Wirkschaltplan
SET OF VKEblockschaltbild
VKE
SET OF
WD
Leitungsliste
Leitungsliste
SET OF
SET OF
Leitungslst.
Gerätelst.
Schemazeichnung
schaltplan
Geräteliste
Geräteliste
PDset := SET OF Wirkschaltplan
PDset := SET OF Wirkschaltplan
Gerätelisten Leit.listen
of PDset
VKEs of PD
2 of 2
join
erstellen
Geräteliste
MockUpInfo
a) anlagenbezogener Ablauf b) bündelbezogener Ablauf
Konstruktion und Fertigung von Leitungsbündeln
events > 10
erstellen
VKE-Blockschaltbild
Abbildung 1:
Beschreibung der Abl
aufe zur Konstruktion und Entwicklung von Leitungsb
undel n
3 ANWENDUNGSSPEZIFISCHE ANFORDERUNGEN AN WFMS
5
3.1 Concurrent{Engineering{sp ezische Anforderungen
Das Beispiel aus Abschnitt 2 zeigt die folgenden anwendungssp ezischen Anforderungen, die
typischf
ur viele Abl
aufe im Bereich des Concurrent Engineering sind:
Wie aus den den bisher beschrieb enen Abl
aufen ersichtlich, erfolgt die Konstruktion
und Entwicklung eines Leitungsb
undels stark sequentiell. Beispielsweise b eginnt ein VKE{
Blo ckschaltbild{Designer meist erst dann mit der Konstruktion eines neuen Leitungsb
undels,
wenn alle Wirkschaltpl
ane erstellt worden sind. Damit verz
ogert er viele anlagenb ezogene
Abl
aufe, da diese die Blo ckschaltbilder als Eingab edaten f
ur Folgeschritte b en
otigen. Diese
Verz
ogerungen sind unn
otig, da ein Leitungsb
undel nie Leitungen aus allen Anlagen enth
alt.
Zur Reduzierung der Konstruktionskosten und {zeiten sollte ein Blo ckschaltbild{Designer des-
halb m
oglichst mit dem Eintreen der ersten Wirkschaltpl
ane mit der Erstellung von Blo ck-
schaltbildern b eginnen und diese f
ur wartende Folgeschritte freigeb en.
Damit b esteht jedo ch die Gefahr, da der Designer b eim Eintreen weiterer Wirkschaltpl
ane die
b ereits fertiggestellten Blo ckschaltbilder mo dizieren mu. Aus Konsistenzgr
unden m
ussen die
Resultate von Folgeschritten, welche die
"
alten\ Blo ckschaltbilder direkt o der indirekt als Einga-
b edaten verwendet hab en, r
uckg
angig gemachtwerden (kaskadierendes semantisches Rollback),
und die Schritte erneut mit den aktuellen Daten wiederholt werden. Dies verursacht insb eson-
dere b ei interaktiven Schritten Mehrarb eit. Erschwerend kommt hinzu, da die Bestimmung
der von Daten
anderungen b etroenen Teilschritte aufwendig und fehleranf
allig ist, da sie h
aug
manuell erfolgt. Die Konsistenthaltung stellt deshalb in der Praxis ein schwerwiegendes Problem
dar [35].
Durch den Einsatz eines WFMS kann trotz der skizzierten Probleme ein h
oherer Parallelit
ats-
grad erreichtwerden, wenn das WFMS die
"
Aufr
aumungsarb eiten\m
oglichst selbst
andig
ub er-
nimmt: Dazu mu das WFMS eine
explizite Datenumodel lierung
und
Protokol lierung die-
ser Daten
usse zur Laufzeit
anbieten, um dann alle von einer Datenmo dikation b etroen
Folgeschritte automatisch b estimmen zu k
onnen. Erm
oglicht das WFMS auch die
Model lie-
rung von Interworkow{Datenabh
angigkeiten
(siehe unten und Abbildung 1), so k
onnen auch
b etroene Folgeschritte anderer Abl
aufe erkanntwerden. Ein geeignetes
Versionierungskon-
zept
[33, 53, 42], das auchverschiedene Qualit
atsstufen [31,53] unterst
utzt, kombiniert mit
einem durchdieAnwendung sp ezizierten
Korrektheitsbegri
[21,18], erm
oglicht auerdem
eine (teil{) automatische R
ucksetzung der
"
veralteten\ Bearb eitungsschritte.
Interworkow{Datenabh
angigkeiten
lassen sich mittels
Interworkow{Abh
angigkeitsknoten
(Interworkow{Dependency{Knoten, ID-Knoten)
analog der untenstehenden Abbildung b e-
schreib en, die als graphische Variante von ECA{Regeln angesehen werden k
onnen.
Event
Condition
Entry
Activity
ID-Knoten wurden auch in Abbildung 1 zur Beschreibung der schon erw
ahnten
Datenabh
angigkeiten zwischen den
anlagenbezogenen
und den
b
undelbezogenen
Abl
aufen verwendet. Ein ID{Knoten b esteht aus drei Teilen: Die
Eingangsbe-
dingung (Entry Condition)
ist ein b o olescher Ausdruck
ub er die Eingab epara-
meter des ID{Knotens und wird b ei jedem eintreenden
Ereignis (Event)
neu
berechnet. Liefert sie
"
true\ , so wird der mit
Activity
b ezeichnete Teilschritt
aktivierbar. Dieser Teilschritt entscheidet dann
ub er die Fortsetzung dieses
Workows. Ein solcher Teilschritt mu sich dab ei nichtvon anderen im Work-
ow mo dellierten Aktivit
aten unterscheiden. Insb esondere kann er b eliebige
Eingab e{ und Ausgab eparameter b esitzen sowie ein interaktiver o der automatischer Teilschritt
sein. Es mu allerdings eine Abbildung seiner R
uckgab ewerte auf eine der Fortsetzungsaktionen
3 ANWENDUNGSSPEZIFISCHE ANFORDERUNGEN AN WFMS
6
m
oglich sein. Als Fortsetzungsaktionen sind denkbar:
continue:
Das neu eingetroene Ereignis erm
oglicht ein Fortsetzen dieses Workows.
reevaluate:
Das Ereignis reicht (no ch) nicht zum Fortsetzen dieses Workows aus.
regainControl:
Die Teilschritte, die b ei fr
uheren Fortsetzungen dieses Ablaufs b earb eitet
wurden, m
ussen zur
uckgesetzt werden, weil sie auf veralteten Daten b eruhen. Dies gilt
auchf
ur alle Teilschritte von \ interworkow{abh
angigen\ Abl
aufen.
Der Abschnitt 6 diskutiert verschiedene Architektur{Ans
atze, wie die hier aufgestellten
Concurrent{Engineering{sp ezischen Anforderungen umgesetzt werden k
onnen.
3.2 Anwendungssp ezische Anforderungen aus anderen Bereichen
Auch in vielen anderen Einsatzgebieten existiert eine Reihe von anwendungssp ezischen Anfor-
derungen, die sichsowohl auf die Mo dellierungseb ene als auch auf die WFMS{Architektur aus-
wirken. Im einzelnen werden skizziert: b en
otigte Strukturierungskonstrukte f
ur den Kontrollu,
Flexibilit
at in Ausnahmef
allen, Datenumo dellierung, Korrektheitsb edingungen sowie Zeitb e-
schr
ankungen. Manche dieser Anforderungen, wie zum Beispiel
Strukturierungskonstrukte f
ur
den Kontrol lu
oder
die Einhaltung von Korrektheitsbedingungen
sind in vielen Anwendungs-
b ereichen (Banken, Versicherungen, medizinisch{organisatorischer Bereich, Fertigung) zu nden.
Anforderungen wie
Flexibilit
at
(medizinisch{organisatorische Abl
aufe, Decision Supp ort) o der
Zeitbeschr
ankungen
(medizinisch{organisatorische Vorg
ange, Fertigungsprozesse) werden dage-
gen nur in einzelnen Bereichen gestellt.
Bei
schwach strukturierten
Prozessen erfolgt die Ko ordination und letztendlichauch die Sp ezi-
kation der Abl
aufe durchdieAnwender zur Laufzeit (Ad-ho c Workows [23]). Bei diesen
relativ
kurzdauernden
und nur
wenige Teilschritte
umfassenden Workows ist nur eine
kleine Gruppe
von Personen
b eteiligt. Ad-ho c Workows werden in der gleichen Form meist
nicht wiederholt
.
Der Datenaustauschzwischen den einzelnen Teilschritten erfolgt h
aug
ub er den Austauschvon
anwendungsspezisch strukturierten Dokumenten
. Durch die fehlende (Vor{) Mo dellierung von
Ad-ho c Workows und die b enutzergesteuerte Ablaufko ordination wird weder eine Ablaufmo del-
lierungskomp onente no ch eine systemseitige Steuerung des Kontroll{ und Datenusses b en
otigt.
Es gen
ugen
Komponenten zur Model lierung der Organisationsstruktur
sowie
benutzerfreund li-
che Mechanismen f
ur den Informationsaustausch
und
f
ur die dynamische Auswahl
der n
achsten
Bearb eiter, wie sie zum Beispiel von Groupware{Systemen [29] geb oten werden.
Stark strukturierte
,sichh
aug wiederholende Abl
aufe werden dagegen
vor
ihrer Ausf
uhrung
mo delliert. Abh
angig von der Komplexit
at der Strukturierung mu deshalb die Buildtime{
Komp onente des WFMS
verschiedene und zum Teil recht komplexe Kontrol lkonstrukte
(Paralle-
lit
at n{aus{m{Verzweigungen, Schleifen, Reihen, . . . [30,43]) anbieten. Die
automatische Koor-
dination und
Uberwachung
des vormo dellierten Workows zur Laufzeit ist b ei diesen Workow{
Typ en eine der Aufgab en des WFMS. Eine b enutzerinitiierte
Anderung des mo dellierten Ab-
laufs zur Laufzeit wird dagegen hier weniger gefordert b eziehungsweise teilweise sogar explizit
verb oten (Beispiel:
Ub erspringen/Auslassen des Gegenzeichnens einer weiteren Person b ei der
Kreditvergab e).
Dagegen ist b ei
medizinisch{organisatorischen Anwendungen
diese
Flexibilit
at zur Laufzeit
eine
existentielle Anforderung f
ur die Einsatzf
ahigkeit eines WFMS [36, 57, 43]. Das WFMS mu
es | in Ausnahmef
allen | erm
oglichen, Schritte auszulassen, zu vertauschen o der zu einem
fr
uheren Bearb eitungszustand im Ablauf zur
uckzukehren. Hierb ei kann man zwei Arten von
Ausnahmen unterscheiden:
vorhersehbare
, und damit vormo dellierbare, Ausnahmen sowie
nicht
3 ANWENDUNGSSPEZIFISCHE ANFORDERUNGEN AN WFMS
7
vorhersehbare
Ausnahmen. Die Mo dellierung der vorhersehbaren Ausnahmef
alle kann prinzipi-
ell zusammen mit der Mo dellierung des
"
Normalablaufs\sowie mit den gleichen Konstrukten
erfolgen. Um die Mo dellierungskomplexit
at zu reduzieren [30] und um auch zur Laufzeit zwi-
schen Ausnahme{ und Normalfall unterscheiden zu k
onnen [16], ist jedo ch eine
Model lierung
in mehreren Sichten
b eziehungsweise mittels
unterscheidbaren Konstrukten
sinnvoll. Bei b eiden
Arten von Ausnahmen ist es Aufgab e des Systems, auf das Fehlen von Eingab edaten geeig-
net zu reagieren und die Datenkonsistenz zu sichern [16]. In manchen Anwendungsgebieten, so
zum Beispiel b ei medizinisch{organisatorischen Abl
aufen, werden auerdem M
oglichkeiten zur
Beschreibung von
Interworkow{Abh
angigkeiten
gefordert [37].
Bei sehr
datenintensiven Anwendungen
(Bilder, Video{Sequenzen, CAD{Zeichnungen) o der
bei
weit verteilten
Abl
aufen (large workows [44]) sind zus
atzlich Konstrukte zur
expliziten
Datenumodel lierung
erforderlich, um nicht unn
otig Daten zwischen den einzelnen Bearb ei-
tungsschritten austauschen zu m
ussen (need{to{know Prinzip, [32, 52]).
Langdauernde
Abl
aufe mit hohen Konsistenzanspr
uchen b en
otigen
Konstrukte zur Beschrei-
bung von Korrektheitsbedingungen
[13,39] und eine entsprechende Laufzeitumgebung zur Rea-
lisierung der mo dellierten Konsistenzanforderungen (
transactional workows
)[18, 21]. Bei eng
gekopp elten o der integrierten Systemen erfolgt die Einhaltung der geforderten Korrektheitsb e-
dingungen in der Regel mit herk
ommlichen Metho den (Two{Phase{Commit, Persistent Queues,
TP{Monitore) [26]. Sollen auch autonome Teilschritte mit eventuell eigener p ersistenter Daten-
haltung eingebunden werden, so ist die Gew
ahrleistung von Konsistenzb edingungen mit erheb-
lichh
oherem Aufwand verbunden (Komp ensationsschritte, . . . ) [23, 39, 13].
Zeitbeschr
ankte
Abl
aufe b en
otigen Konstrukte, um
relative
(minimaler/maximaler zeitlicher Ab-
stand zwischen Teilschritten) und
absolute
(Start am . . . , Ende bis . . . )
Zeitgrenzen
mo dellieren
zu k
onnen.
3.3 Allgemeine Anforderungen an eine WFMS{Architektur
Die Eignung eines WFMS f
ur ein Anwendungsgebiet h
angt nichtnur von der Mo dellie-
rungsm
achtigkeit seiner Buildtime{Komp onente, sondern auchvon den Eigenschaften seiner
System{Architektur (Systemeigenschaften) ab:
Fehlertoleranz: Unternehmenskritische
Workows [23]ben
otigen eine Systemverf
ugbarkeit
von m
oglichst 100 %. Zentralistische WFMS{Architekturen [27,40,63, 20, 62] mit ih-
rem
"
single p oint of failure\ sind hierf
ur nur in Verbindung mit zus
atzlichen Manahmen
(Backup{Server [44]) geeignet. Dagegen stellen
Ad-hoc
Workows aufgrund ihrer relativ
kurzen Dauer sowie ihrer
Ub ersichtlichkeit (wenige Teilschritte und b eteiligte Personen)
in der Regel nicht so hohe Anforderungen an Verf
ugbarkeit und Konsistenz.
Skalierbarkeit:
Da die Zahl der gleichzeitig aktiven Workows im voraus nur sehr schwer
abzusch
atzen ist, sollte die Ko existenz mehrerer WF{Engines m
oglich sein, die jeweils
einen (disjunkten) Teil der Workows b earb eiten [44,5,6, 59, 55]. Insb esondere b ei weit
verteilten Workows [44,5]mu die Ausf
uhrungskontrolle von einer WF{Engine zu ei-
ner anderen weitergereichtwerden k
onnen, wenn die zweite Engine f
ur die als n
achstes
zu aktivierenden Teilschritte b esser geeignet ist (z. B. lokale Ausf
uhrung m
oglich). Diese
F
ahigkeit zur Migration der Ausf
uhrungskontrolle mu auchzwischen WF{Engines ver-
schiedener WFMS{Hersteller m
oglichsein(Interop erabilit
at [68]).
4 BER
UCKSICHTIGUNG ANWENDUNGSSPEZIFISCHER ANFORDERUNGEN
8
Antwortzeiten:
Bei Interaktionen mit dem WFMS zur Laufzeit werden in der Regel Ant-
wortzeiten von weniger als 1 Sekunde gefordert. Die Antwortzeiten werden dab ei wesentlich
vom Synchronisationsaufwand b estimmt
5
, der wiederum von zwei Asp ekten abh
angt:
{
Zahl der gleichzeitig aktionsb erechtigten Personen: Bei strikten Synchronisationsan-
forderungen mu jede Bewegung im Ablaufgraphen mit allen (vorher und nachher)
aktionsb erechtigten Personen abgestimmtwerden. Oftmals wird es jedo chgen
ugen,
(Zustands{)
Anderungen im Ablauf zeitverz
ogert, eventuell erst auf Anforderung, an
aktionsb erechtigte Personen weiterzuleiten. Diese Personen b esitzen dann nicht im-
mer die aktuellsten Informationen
ub er einen Proze.
{
Zahl der b eteiligten Workow{Engines: Erfolgt aus Fehlertoleranzgr
unden die Ablauf-
ko ordination von mehreren Workow{Engines gemeinsam, so b en
otigen sie zus
atzli-
che Synchronisationsmechanismen [11].
API{Funktionen:
Ub er die vom Laufzeitsystem angeb otene Schnittstelle kann ein An-
wender Einu auf die Durchf
uhrung von Workows nehmen (API{Funktionen). Diese
Schnittstelle mu mindestens das Starten von Abl
aufen b eziehungsweise von darin enthal-
tenen (interaktiven) Teilschritten umfassen. H
aug werden jedo chauchFunktionen zum
Stopp en, Unterbrechen und Zur
ucksetzen von Prozessen sowie verschiedene Anfrage{ und
Ub erwachungsop erationen (Status, History, Monitoring eines Workows) gefordert.
Kon-
trol lorientierte
WFMS [58], die das Aufrufen externer Teilschritte erm
oglichen, b en
otigen
zus
atzliche API{Funktionen zur Interaktion mit diesen externen Programmbausteinen [16].
Diese Systemeigenschaften bilden zusammen mit den geforderten Mo dellierungskonstrukten das
anwendungssp ezische
Anforderungsprol
.
4Ber
ucksichtigung anwendungssp ezischer Anforderungen
Aufgrund der ob en skizzierten unterschiedlichen Anforderungsprole ist bisher keines der auf
dem Markt b endlichen b eziehungsweise in der wissenschaftlichen Literatur vorgeschlagenen
WFMS in allen Anwendungsgebieten (gleich gut) geeignet. Die heutige Situation ist vielmehr
durch eine Vielzahl an die jeweiligen Anwendungsb ereiche angepaten WFMS mit unterschiedli-
chen
Funktionalit
aten
und
Systemeigenschaften
gekennzeichnet [60, 58]. Das Hinzukommen wei-
terer Anwendungsgebiete und damit zus
atzlicher Anforderungsprole wird diese Situation eher
no chversch
arfen, weshalb ein in allen Anwendungsb ereichen gleich gut geeignetes
"
General{
Purpose{WFMS\
auch in Zukunft mehr Wunschdenken als Realit
at bleib en wird. Die Unter-
schiede in den WFMS b eschr
anken sich dab ei nichtnur auf die Buildtime{Komp onente, sondern
f
uhren h
aug auchzu
unterschied lichen WFMS{Architekturen
mit jeweils sp ezischen Vor{ und
Nachteilen (z. B. bzgl. Skalierbarkeit, Fehlertoleranz). Anwender und Entwickler von WFMS
stehen deshalb vor den folgenden zwei Problemen:
1. Welche Laufzeitumgebung ist b ei
gegebenem
Anforderungsprol am b esten geeignet? Wie
b estimmt man diese
"
optimale\ WFMS{Architektur? Anhand welcher Kriterien kann man
verschiedene Laufzeitumgebungen (quantitativ) vergleichen?
Diese Fragen stellen sich WFMS{Entwickler, wenn sie die Architektur eines vorhandenen
WFMS restrukturieren b eziehungsweise ein neues WFMS entwerfen m
ochten.
5
Beisehrdatenintensiven Abl
aufen b eeinut auch die Bereitstellung der notwendigen Eingab edaten f
ur einen
Teilschritt das Antwortzeitverhalten (siehe Abschnitt 6.1).
5 HERAUSFORDERUNGEN AN DIE FORSCHUNG
9
F
ur WFMS{Anwender ist eine Antwort auf diese Frage interessant, wenn sie b ei der Fest-
legung des Anforderungsprols die Folgen f
ur die Workow{Ausf
uhrungen absch
atzen wol-
len: Welche Konsequenzen auf die Komplexit
at der Workow{Ausf
uhrung hat die Hinzu-
nahme eines weiteren Mo dellierungskonstrukts o der einer zus
atzlichen Systemeigenschaft?
Kann durch den Verzicht auf einen Teil der Anforderungen eine einfacher realisierbare
Laufzeit{Umgebung verwendet werden?
2. Welche Klasse von Workows (bzgl. Mo dellierungsm
achtigkeit, Skalierbarkeit, Konsistenz,
Antwortverhalten, . . . ) kann eine
gegebene
WFMS{Architektur (maximal) unterst
utzen?
F
ur Anwender stellt sichdieseFrage insb esonders dann, wenn ein schon im Einsatz b e-
ndliches WFMS weitere o der mo dizierte Abl
aufe unterst
utzen soll. Neb en der Frage, ob
sich die weiteren Abl
aufe geeignet mo dellieren lassen, mu insb esondere m
oglichst fr
uh ent-
schieden werden k
onnen, ob die gegeb ene WFMS{Architektur die zus
atzlichen Workows
zur Laufzeit b ew
altigen kann.
Ein WFMS{Anbieter stehtvor diesem Problem, wenn sein WFMS um zus
atzliche Mo del-
lierungskonstrukte o der Systemeigenschaften erweitert werden soll, um zum Beispiel f
ur
weitere Anwendungsgebiete eingesetzt zu werden [30]. Er mu dann m
oglichst fr
uh pr
ufen,
ob b eziehungsweise welche Mo dikationen an der WFMS{Architektur notwendig sind.
Vergleichende Ver
oentlichungen von WFMS b eschr
anken sich in der Regel auf eine Beurtei-
lung der jeweiligen Buildtime{Komp onenten [60, 58, 23]. Damit sind R
uckschl
usse auf die Lauf-
zeitumgebung, wie sie zur Beantwortung der obigen Fragen zwingend erforderlich sind, nicht
m
oglich. Deshalb ist b eispielswei se ein Anwender, hat er sichbez
uglich der gew
unschten Mo-
dellierungsm
achtigkeit festgelegt, auf aufwendige Vergleichstest angewiesen, um aus der Menge
"
gleich{m
achtiger\ WFMS dasjenige mit der geeignetesten Laufzeitsystem{Architektur heraus-
zunden. Der Aufwand resultiert im wesentlichen daraus, da
repr
asentative
Workows in meh-
reren WFMS vollst
andig mo delliert und unter realen Bedingungen ausgef
uhrt werden m
ussen.
Damit kann man sich in der Praxis immer nur auf den Vergleichweniger Systeme b eschr
anken.
5 Herausforderungen an die Forschung
Aus den ob en genannten Gr
unden sind deshalb Untersuchungen w
unschenswert, welche die
praxisrelevanten WF{Klassen durchFestlegung der Mo dellierungskonstrukte und Systemeigen-
schaften b eschreib en
und
f
ur diese die
"
optimale\ WFMS{Architektur b estimmen. Die Suche
nach der optimalen WFMS{Architektur reduziert sich damit auf die Bestimmung der geeig-
neten WF{Klasse, welche die geforderten Mo dellierungskonstrukte und Systemeigenschaften
umfat (Abbildung des geforderten Anforderungsprols auf das Anforderungsprol der WF{
Klasse). Auch der durchFrage 2 geforderte
"
R
uckweg\w
are dadurchm
oglich: Bei gegeb ener
WFMS{Architektur k
onnen alle WF{Klassen und damit die Menge der m
oglichen Konstrukte
und Systemeigenschaften b estimmtwerden, die f
ur diese Laufzeitumgebung geeignet sind.
Unseres Wissens existieren bisher jedo chnochkeine Arb eiten, welche die Abh
angigkeiten zwi-
schen Mo dellierungsm
achtigkeit und Systemeigenschaften auf der einen Seite sowie der dazu
m
oglichen WFMS{Architekturen auf der anderen Seite untersucht hab en.
Als Ergebnis einer wissenschaftlich fundierten Untersuchung dieser Abh
angigkeiten sind folgende
L
osungen denkbar:
5 HERAUSFORDERUNGEN AN DIE FORSCHUNG
10
Es existiert die General{Purp ose{WFMS{Architektur, die optimal f
ur alle WF{Klassen und
damit f
ur alle Anwendungsgebiete ist. Aufgrund der sich zum Teil widersprechenden Anforde-
rungsprolen ist dieses Ergebnis nichtzu erwarten.
Es ist wahrscheinlicher, da f
ur eine (hoentlich) gr
oere Zahl von WF{Klassen eine gemeinsame
WFMS{Architektur gefunden werden kann, die sehr viele Anwendungsgebiete ab deckt.Daein
Multi{Purp ose{WFMS nicht alle Anforderungsprole erf
ullen kann, werden aus einer solchen
Untersuchung mehrere Multi{Purp ose-WFMS resultieren, die jeweils f
ur andere Anwendungs-
b ereiche konzipiert sind. Multi{Purp ose{WFMS{Architekturen werden allerdings immer einen
mehr o der weniger guten Kompromi f
ur das jeweilige konkrete Einsatzgebiet darstellen.
Deshalb wird eine solche Untersuchung auch
"
Nischen{WFMS\ mit sp eziell f
ur das jeweilige An-
wendungsgebiet zugeschnittenen Architekturen hervorbringen.
6
Nischen{WFMS sind sinnvoll:
bei
"
einfachen\ Anwendungen
(z. B. einfach strukturierte Abl
aufe mit kurzen
Ausf
uhrungszeiten, vgl. Abschnitt 3.2), die nur wenige Mo dellierungsm
oglichkeiten und
nur geringe Systemunterst
utzung zur Laufzeit b en
otigen. Der Einsatz eines weit m
achti-
geren Multi{Purp ose{WFMS w
are hier viel zu aufwendig.
bei
sehr anwendungsspezischen und schwierig umsetzbaren Anforderungen
an ein WFMS.
Eine ho chsp ezialisierte und darauf abgestimmte WFMS{Architektur ist hier dann sogar
die einzige M
oglichkeit, die gestellten Anforderungen umzusetzen. WFMS{Architekturen,
die f
ur
large workows
(siehe Abschnitt 3.2) geeignet sein m
ussen, k
onnen b eispielswei se
eine solche Sp ezialisierun g erfordern.
Bei der Suche nach geeigneten WFMS{Architekturen f
ur die jeweiligen WF{Klassen ist ein
Vorgehen nach folgenden Schritten sinnvoll:
1.
Festlegung von praxisrelevanten WF{Klassen
Eine WF{Klasse b esteht aus einer
maximalen Menge
von Mo dellierungskonstrukten und
Systemeigenschaften. Maximalit
at b edeutet in diesem Zusammenhang, da durch die Hin-
zunahme eines weiteren Mo dellierungskonstrukts b eziehungsweise einer zus
atzlichen Sy-
stemeigenschaft eine grundlegende Ver
anderung der System{Architektur erforderlich wird.
Eine praxisorientierte Klasseneinteilun g wird dab ei die verschiedenen anwendungssp ezi-
schen Anforderungen b er
ucksichtigen.
2.
Erarbeitung verschiedener WFMS{Architektur{Alternativen f
ur die WF{Klassen
Die Beschreibung einer WFMS{Architektur mu neb en der physikalischen Verteilung der
WF{Engines und ihrer funktionaler Komp onenten im Netzwerk auch ihre Art der Zusam-
menarb eit (autonom, ko op erativ) sowohl im fehlerfreien Fall als auchw
ahrend Knoten{
und Netzausf
allen b einhalten. Zus
atzlichmu auch die Einbindung externer Anwendungen
(Klienten/Teilschrittprogramme) festgelegt werden, wob ei hier insb esondere b ez
uglich der
Konsistenzanforderungen der externen Anwendungen verschiedene Qualit
atsstufen vor-
stellbar sind. F
ur die WF{Klasse
"
Concurrent Engineering\ wird im folgenden Abschnitt
ub erlegt, wie sich die in Abschnitt 3.1 aufgestellten Anforderungen umsetzen lassen.
3.
Entwicklung eines Kriterienkatalogs zur systematischen und quantitativen Beurteilung ver-
schiedener Laufzeitumgebungen f
ur eine WF{Klasse
Der Kriterienkatalog mu mindestens die in Abschnitt 3.3 b eschrieb enen Systemeigen-
schaften umfassen. Quantitative Analysen sind unter anderem b ei den Kriterien
"
Fehler-
toleranz\[10] und
"
Antwortzeiten\ (z. B.
ub er Warteschlangenanalyse [54, 9, 61, 49, 8,12],
6
Diese Nischen{Systeme sind auch in anderen Bereichen der DV{Welt zu nden. Man denke hierb ei nur
an Echtzeitb etriebssysteme, die nur f
ur b esonders zeitkritische Anwendungen b en
otigt werden, an Single{User{
Betriebssysteme f
ur einfache Einzelplatzsy steme o der an Ho chleistungstransak tion ssysteme (z. B. Transaction
Pro cessing Facility (TPF) von IBM), die optimiert auf maximalen Transaktionsdurchs atz sind.
6 EINE CONCURRENT{ENGINEERING{GEEIGNETE WFMS{ARCHITEKTUR
11
zeitb ehaftete Petri{Netze [51,9,49, 34, 8,65] o der sto chastischer Graphen [9, 28]) m
oglich.
Eine
"
Antwortzeiten\ {Analyse kann dab ei f
ur jede vom Laufzeitsystem angeb otene API{
Funktion getrennt erfolgen. Hiermit lassen sich dann b eim Vergleichverschiedener WFMS{
Architekturen (siehe Punkt 4) die H
augkeiten der Funktionsaufrufe mit b er
ucksichtigen.
4.
Bestimmung der optimalen Laufzeitumgebungen mittels des Kriterienkatalogs
Da die optimale WFMS{Architektur immer einen Kompromi zwischen den verschiedenen
Anforderungen an eine Klasse darstellen wird, k
onnen je nach Priorisierung dieser Anfor-
derungen unterschiedliche optimale WFMS{Architekturen resultieren. Alternativ ist auch
denkbar, da eine
Anderung der Priorisierung zu weiteren WF{Klassen f
uhrt, wob ei dann
die Gefahr der
"
WF{Klassen{Explosion\ b esteht.
Zu b eachten ist hierb ei, da sich die M
achtigkeit einer WF{Klasse (Punkt 1) und die opti-
male Laufzeitumgebung (Punkt 4) gegenseitig b eeinussen. Deshalb stellt die Bestimmung der
Klassikationsgrenzen einen iterativen Proze dar. Auchkann es f
ur die Bildung von Multi{
Purp ose{WFMS sinnvoll sein, WF{Klassen mit
ahnlichen Architekturen zusammenzufassen,
um das Einsatzgebiet des WFMS zu vergr
oern.
6
Ub erlegungen zu einer Concurrent{Engineering{geeigneten
WFMS{Architektur
Dieser Abschnitt enth
alt
Ub erlegungen zu einer WFMS{Architektur, die den Concurrent{
Engineering{sp ezischen Anforderungen aus Abschnitt 3.1 gen
ugt. Dab ei werden aus den Anfor-
derungen resultierende Probleme zur Laufzeit skizziert und m
ogliche L
osungsans
atze b eschrie-
b en. Auerdem wird dieser Abschnitt aufzeigen, in welchen Bereichen no chweiterer Forschungs-
b edarf b esteht.
6.1 Zeitgerechte Bereitstellung der b en
otigten Eingab edaten
Eine b ei interaktiven Teilschritten zeitkritische Aufgab e eines WFMS ist die Bereitstellung der
notwendigen Eingab edaten f
ur die einzelnen Bearb eitungsschritte. Entscheidet sich ein Anwen-
der, einen ihm in seiner Worklist angeb otenen Teilschritt (in der Regel durch
"
Anklicken\ des
entsprechenden Items) durchzuf
uhren, so m
ussen diesem Teilschritt
innerhalb weniger Sekun-
den
die von ihm b en
otigten Daten zur Verf
ugung gestellt werden. Diese Daten{Bereitstellung ist
insb esondere b ei Concurrent{Engineering{Abl
aufen aus den folgenden Gr
unden problematisch:
1. Die b ereitzustellend en Datenmengen sind in der Regel gro.
2. Die Daten weisen unterschiedliche Formate auf.
3. Die Daten m
ussen teilweise
ub er groe Entfernungen transferiert werden, da b ei typi-
schen Concurrent{Engineering{Abl
aufen h
aug Mitarb eiter aus anderen, r
aumlichweit
verteilten Abteilungen, Niederlassungen o der ko op erierenden Firmen b eteiligt sind (large
workows [44]).
7
4. Die Eingab edaten eines Teilschritts m
ussen an verschiedenen Orten b ereitgestellt werden,
da der Schritt oftmals mehreren Mitgliedern (eines Teams) zeitgleich zur Durchf
uhrung
angeb oten wird.
7
Beispielswei se erfolgt die Airbus{Entwicklun g
ub er mehrere europ
aische L
ander verteilt.
6 EINE CONCURRENT{ENGINEERING{GEEIGNETE WFMS{ARCHITEKTUR
12
Unter Verwendung eines geeigneten Kommunikationsstandards zum Datenaustauschl
at sich
die Datenkonvertierungsproblematik (Punkt 2) weitgehend l
osen. F
ur den im Concurrent{
Engineering{Bereichben
otigten Austauschvon Pro duktdaten eignet sich hierb ei insb esondere
die von der ISO entwickelte Norm STEP (STandard for the Exchange of Pro duct mo del data)
[41], die b ei technischen Anwendungen eine immer gr
oere Verbreitung ndet.
F
ur die Sp eicherung der groen Datenmengen (Punkt 1) gibt es f
ur ein WFMS drei prinzipiel l e
M
oglichkeiten: b eim Erzeuger der Daten, b ei den p otentiellen Verbraucher{Teilschritten
8
o der
an einer unabh
angigen Zwischenstelle. Die Ber
ucksichtigung der Punkte 3 und 4 deckt jedo ch
b ei jedem dieser Ans
atze Schwachstellen auf:
Bei einer Sp eicherung auf dem Knoten des
Erzeuger{Teilschritts
b eziehungsweise an einer
Zwi-
schenstel le
lassen sich tolerierbare Zugriszeiten nur dann realisieren, wenn eine
schnel le
und
ausfal lsichere
Verbindung zwischen den Daten und den
entfernten
Verbraucher{Teilschritten
gew
ahrleistet werden kann. Diese Anforderung wird b ei den heutigen Netzinfrastrukturen in der
Regel nur im LAN{Bereich b eziehungsweise b ei einigen Ho chleistungs{MAN [14]erf
ullt. Bei
einer gr
oeren geographischen Verteilung der an einem Ablauf b eteiligten Personen (Punkt 3)
stoen diese Ans
atze an ihre Grenzen. Die Sp eicherung an einer zentralen Zwischenstelle birgt
zus
atzlich die Gefahr eines Flaschenhalses.
Zur Vermeidung dieser Verf
ugbarkeits{ und Zugriszeitenprobleme bietet sich b ei einer gr
oe-
ren
ortlichen Verteilung eine Sp eicherung der Daten auf allen Verbraucherknoten an (
Daten{
Prefetching
). Verbraucherknoten sind alle Knoten, auf denen Teilschritte, die diese Daten als Ein-
gab eparameter b en
otigen, p otentiell ausgef
uhrt werden k
onnen. Dadurchkann die Daten
ub er-
tragung erfolgen, b evor die entsprechenden Teilschritte ihren p otentiellen Bearb eitern angeb oten
und damit ausgef
uhrt werden k
onnen [52, 32]. Diese
Ub ertragung ist deshalb
nicht
zeitkritisch.
Problematisch b ei dieser L
osung ist jedo ch, da die Daten auf viele Knoten kopiert werden
m
ussen, da diese Rechner alle f
ur die Durchf
uhrung von Folgeschritten in Frage kommen. Dies
ist immer dann der Fall, wenn ein Folgeschritt mehreren Anwendern angeb oten wird (Punkt 4)
und/o der wenn es mehrere verschiedene Folgeschritte gibt (vergleiche Flexibilit
at in Abschnitt
3.2). Eine groe Zahl von p otentiellen Anwendern erh
oht somit die Zahl der zu versendenden
Datenkopien und reduziert damit die Praxistauglichkeit dieser L
osung. Die aktuelle Zahl der
geeigneten Anwender steht dab ei erst zur Laufzeit fest, da sie von der Anzahl der gerade im
WFMS angemeldeten Anwender f
ur die jeweilige Rolle abh
angt.
Um die skizzierten Nachteile der verschiedenen Ans
atze abzuschw
achen, m
ussen die bisherigen
Mo delle sicherlichnochverfeinert und mit mehr Anwendungssemantik versehen werden. Hierb ei
sind unter anderem folgende Verb esserungen auf ihre Eignung zu untersuchen:
1.
Daten{Clusterung:
Geographisch b enachbarte Bearb eiter teilen sich eine Datenkopie. Ein
Cluster b esteht aus allen Rechnerknoten, die
ub er ein schnelles und zuverl
assiges Netzwerk
(LAN/MAN) verbunden sind. Jeder Cluster erh
alt dann eine Datenkopie. Damit h
angt
die Zahl der zu versendenden Kopien von der Anzahl der Cluster und nichtvon der im
allgemeinen gr
oeren Zahl der p otentiellen Benutzer ab (Lokalit
atsprinzip). Dieser hybride
Ansatz erm
oglicht eine Datenverf
ugbarkeit und Zugriszeiten, die vergleichbar zur L
osung
der Datensp eicherung auf
al len
Verbraucherknoten sind, ohne den Nachteil dieser L
osung,
den hohen Kopieraufwand, im vollen Umfang zu
ub ernehmen. Durch eine entsprechende
Wahl der Clustergr
oe sind dab ei die Sp eicherung an einer Zwischenstelle (Cluster umfat
al le
Knoten) und die Sp eicherung auf allen Verbraucherknoten (jeder Verbraucherknoten
8
Mit Verbraucher{Teilschri tten werden Schritte b ezeichnet, die diese Daten als Eingab eparameter b en
otigen.
Ein Verbrauchen im eigentlichen Sinn ndet nat
urlich nicht statt.
6 EINE CONCURRENT{ENGINEERING{GEEIGNETE WFMS{ARCHITEKTUR
13
bildet einen eigenen Cluster) als Sp ezialf
alle enthalten.
2.
Reservierung von Teilschritt{Durchf
uhrungen:
Den p otentiellen Bearb eitern eines Teil-
schritts wird als weitere Op eration eine
Reservierungsfunktion
angeb oten. Durch das
Anstoen dieser Op eration verpichtet sich der Bearb eiter, die T
atigkeit zu
ub erneh-
men. Der Aufruf des Teilschritts zur Durchf
uhrung der entsprechenden T
atigkeit er-
folgt jedo ch erst zu einem sp
ateren Zeitpunkt. Damit kann auf ein b ei vielen p otenti-
ellen Bearb eitern kostspieliges Prefetching der Daten verzichtet werden, da in der Regel
|entsprechende Arb eitsorganisation der Benutzer vorausgesetzt | zwischen Reservie-
rung und Durchf
uhrung eines Teilschritts gen
ugend Zeit zur Daten
ub ertragung bleibt.
Auch kurze Verbindungsausf
alle k
onnen dadurch toleriert werden. Nach der Daten
ub er-
tragung kann dann der Mitarb eiter autark den Teilschritt durchf
uhren. Dieses Vorge-
hen eignet sich deshalb auchf
ur die Bearb eitung eines Teilschritts auf
mobilen Rech-
nern
, die nur zeitweise mit dem WFMS verbunden sind [3]. Eine Reservierung sollte
jedo ch zeitlich b egrenzt werden, um den Teilschritt nach Ablauf dieser Frist anderen
Bearb eitern erneut zur Durchf
uhrung anzubieten. Dadurch wird einer unn
otig langen
Verz
ogerung eines Workows vorgeb eugt, wenn der Mitarb eiter, der einen Teilschritt re-
serviert hat, daran gehindert wird, den Schritt fristgerecht durchzuf
uhren (z. B. wegen
Krankheit, Rechnerausfall). Andererseits sind hiermit Inkonsistenzen durch Mehrfachbe-
arb eitungen m
oglich, wenn aufgrund von Verbindungsunterbrechungen die Beendigungs-
meldung eines Teilschritts nicht an das WFMS
ub ermittelt werden kann.
Replikations-
verfahren
[11]k
onnen solche Inkonsistenzen erkennen und gegeb enenfalls automatisch
au
osen. Bei einer automatischen Inkonsistenzauf l
osung ist auch der Einsatz der Kon-
zepte aus dem Bereich
erweiterter Transaktionsmodel le
(z. B.: Komp ensation [21], accep-
table state set [38]) sinnvoll. Jedo chm
ussen alle diese Vorschl
age b ez
uglich ihrer Anwend-
barkeit f
ur den Concurrent{Engineering{Bereichuntersucht und entsprechend angepat
werden.
3.
Zeitverz
ogerte Versorgung mit Eingabeparametern:
Die Durchf
uhrung von Teilschritten im
Concurrent{Engineering{Bereich (z. B.
"
VKE{Blockschaltbild erstel len\
, siehe Abschnitt
2) ist h
aug eine l
angere T
atigkeit, die b eim Start nicht sofort alle Eingab edaten b en
otigt.
Entsprechende Schl
usselworte (
immediate, deferrable
) b ei der Deklaration der Einga-
b eparameter eines Teilschritts erm
oglichen eine Reduzierung der Eingab edaten, die b eim
Start des Teilschritts vom WFMS zur Verf
ugung gestellt werden m
ussen.
4.
Datenversionierung:
Ist es aus Anwendungssicht tolerierbar, da ein Teilschritt b eim Auf-
ruf mit einer veralteten Datenversion versorgt wird, so kann auch damit eine Reduzierung
des b en
otigten Datenvolumens erreichtwerden. Auch dieses anwendungssp ezische Wis-
sen kann
ub er geeignete Schl
usselattribute dem WFMS mitgeteilt werden. Hier stellt sich
die Frage, welche Klasse von Teilschritten welche H
ohe der dadurchm
oglichen Inkonsi-
stenzen toleriert. Welches Korrektheitskriterium eignet sich deshalb zur Beschreibung der
erlaubten Inkonsistenzen (z. B.:
{Serialisierbarkeit [50])?
Bei allen skizzierten Verb esserungsvorschl
agen mu untersuchtwerden, welche
"
Stel lschrauben\
(z. B.: Anzahl und Gr
oe der Cluster, Zeitraum einer Reservierung, H
ohe der erlaubten In-
konsistenzen) in der Praxis sinnvoll sind und welche durch Ablauf{Mo dellierer o der Bearb eiter
mo diziert werden d
urfen.
6 EINE CONCURRENT{ENGINEERING{GEEIGNETE WFMS{ARCHITEKTUR
14
6.2
Ub erwachung der Interworkow{Abh
angigkeiten
Interworkow{Abh
angigkeiten, wie sie in Abschnitt 3.1 b eschrieb en worden sind, ergeb en
sich erst zur Laufzeit. Eine systemseitige Unterst
utzung dieser Interworkow{Abh
angigkeiten
kann deshalb nur
ub er eine allen Workow{Instanzen b ekannte
Vermittlerstel le
, b eispielswei se
ub er einen allgemein zug
anglichen
aktiven Daten{Pool
(
shared data pool
, siehe auch Abbil-
dung 2) erfolgen. Im wesentlichen b esteht die Aufgab e der Vermittlerstelle darin, datenerzeugen-
de Workow{Instanzen und datenverbrauchende Workow{Instanzen
ub er ihre Interworkow{
Abh
angigkeiten zu informieren. Dazu m
ussen in der Vermittlerstelle jedo ch nicht die auszu-
tauschenden Datenob jekte selbst, sondern nur Informationen
ub er die auszutauschenden Ob-
jekte, sogenannte
Metadaten
, gesp eichert werden. Der eigentliche Datenaustauschkann dadurch
weiterhin ohne Zwischensp eicherung in der Vermittlerstelle direkt zwischen den involvierten
Workow{Instanzen erfolgen.
based on:
data flow,
time of exchange,
level of quality, and
version specification
Service
Provider
Service
Provider
Service
Requestor
Service
Requestor
shared
data pool
based on:
data flow,
time of exchange,
level of quality, and
version specification
control flow
data propagation
checkIn/Out,
version merge
compensation
Workflow
Runtime Info
rollback
data pool
workflow local
data pool
workflow local
shared data prop.
modify data
prop. info
data propagation
control flow
data propagation
checkIn/Out,
version merge
compensation
Workflow
Runtime Info
rollback
wait for
notify
Abbildung 2:
Ub erwachung der Interworkow{Abh
angigkeiten
Im einzelnen mu eine solche Vermittlerstelle die folgenden Op erationen anbieten:
Mit der Op eration
wait for
kann eine Workow{Instanz ihr Interesse an b estimmten Daten-
ob jekten anmelden. Treen die entsprechenden Metadaten b ei der Vermittlerstelle ein (Op era-
tion
shared data propagation
), so werden von ihr die darauf wartenden Workow{Instanzen
b enachrichtigt (Op eration
notify
) und die entsprechenden datenerzeugenden Workows b eauf-
tragt, diese Daten auch an die wartenden Instanzen weiterzuleiten (Op eration
modify data
propagation info
).
Der Vorteil dieses
publish{and{subscribe
{Prinzips [66, 24] liegt in der Entkopp elung von Da-
tenerzeuger und {verbraucher. Damit ist die Bestimmung, an welche Workow{Instanzen die
Daten weitergeleitet werden m
ussen, nicht Aufgab e des
"
Erzeuger{Workows\ , sondern erfolgt
durch die Vermittlerstelle.
Bei diesem zentralistischen L
osungsansatz mu sicherlichnochuntersuchtwerden, ob er sich auch
f
ur Interworkow{Abh
angigkeiten zwischen geographischweit verteilten Workow{Instanzen
eignet (vergleiche Kritikpunkte an zentralistischen L
osungen b ei weit verteilten Workows
in [4]). Im Gegensatz zu einer zentralen Verwaltung der Daten
usse
innerhalb
eines weit verteil-
ten Workows ist ein zentraler Ansatz b ei
Interworkow
{Datenabh
angigkeiten jedo ch aus drei
Gr
unden weniger kritisch:
6 EINE CONCURRENT{ENGINEERING{GEEIGNETE WFMS{ARCHITEKTUR
15
Die Zahl von Interworkow{Datenabh
angigkeiten ist geringer als die Datenabh
angigkeiten
von Teilschritten innerhalb eines Workows.
Ub er die Vermittlerstelle werden nur Informationen
uber
die auszutauschenden Daten
(Metadaten) und nicht die Daten selbst ausgetauscht. Die auszutauschende Datenmenge
ist dadurchweit geringer.
Der Datenaustauschkann erfolgen, b evor den Anwendern der aufgrund von Interworkow{
Abh
angigkeiten blo ckierte Schritt angeb oten wird (vergleiche Abschnitt 6.1).
6.3 Einbindung autonomer Teilschritt{Programme
Bei Workows im Concurrent{Engineering{Bereichwerden Teilschritte h
aug mit b ereits fr
uher
entwickelten Anwendungssystemen (z. B.: CAx{Systeme) verkn
upft. Diese Anwendungssysteme
werden meist als autonome Stand{alone{Applikationen entwickelt. Eine Integration dieser au-
tonomen Teilschritt{Programme in ein
ub ergeordnetes externes System, wie zum Beispiel ein
WFMS, ist deshalb meist nichtvorgesehen.
Dies erschwert die Realisierung der in Abschnitt 3.1 geforderten automatisch durchzuf
uhren-
den Aufr
aumungsarb eiten, weil aufgrund der fehlenden Integrationsm
oglichkeiten ein atoma-
res Zur
ucksetzen der vom WFMS verwalteten Daten
und
der (p ersistenten) Daten der ent-
sprechenden Teilschritt{Programme verhindert wird (keine
globale Transaktion
m
oglich, wel-
che
"
WFMS{Daten\ und
"
Teilschritt{Programm{Daten\ umfat) [7]. Das Zur
ucksetzen der
Teilschritt{Programm{Daten erfolgt deshalb
ublicherweise durch den Aufruf eines entspre-
chenden Komp ensationschritts
9
, der unabh
angig zu den WFMS{internen Aufr
aumungsarb ei-
ten erfolgt. Bei Auftreten von Kommunikations{ o der Knotenfehlern sind damit Inkonsistenzen
m
oglich. Beispielsweise k
onnen die WFMS{Daten schon auf einen fr
uheren Bearb eitungszu-
stand zur
uckgesetzt worden sein, der Aufruf des Komp ensationsschritts zum Zur
ucksetzen der
Teilschritt{Programm{Daten schlug dagegen fehl.
Um die daraus resultierenden Inkonsistenzen zu verhindern, mu es dem WFMS erm
oglicht
werden, den konkreten Bearb eitungszustands eines Teilschritts (komp ensiert, erfolgreich b een-
det, . . . ) b eim zugeordneten Anwendungssystem zu erfragen, wozu das entsprechende Schritt{
Programm jedo ch einen Teil seiner Autonomie aufgeb en mu. Ein alternativer Ansatz b estehtin
einer
idemponenten
Realisierung der Komp ensationsschritte, damit auch mehrmaliges Aufrufen
der Komp ensation keine weiteren Inkonsistenzen verursacht [6].
Wann sichwelche Alternative b esser eignet, h
angtimwesentlichen von den Eigenschaften des
jeweiligen Teilschrittprogramms ab. Diese Eigenschaften k
onnen stark unterschiedlich sein: Be-
reitschaft zum Two{Phase{Commit, Abfragem
oglichkeiten b estimmter interner Bearb eitungs-
zust
ande, M
oglichkeit zum Abbrechen eines Auftrags, usw. Sind diese dem WFMS b ekannt, so
k
onnen sie zur Konsistenzsicherung geeignet ausgen
utzt werden. Dazu m
ussen jedo ch Kriteri-
en erarb eitet werden, nach denen die verschiedenen Teilschrittprogramme entsprechend ihrer
Eigenschaften eingeteilt werden k
onnen.
9
Komp ensation ist auch aufgrund der langen Workow{Bearb eitun gsda uer notwendig [22 ], da diese eine Kon-
sistenzsicherung mittels (Zwei{Phasen{) Sp erren
ub er den gesamten Zeitraum aus Ezienzgr
unden unm
oglich
macht.
7 FAZIT
16
7 Fazit
WFMS erob ern sich neue Anwendungsgebiete mit jeweils sp ezischen Anforderungen an die
M
achtigkeit dieser Systeme. Neb en den Anforderungsprolen aus unterschiedlichen Anwen-
dungsgebieten wurden hier die sp ezischen Anforderungen aus dem Bereich des Concurrent
Engineering exemplarisch aufgezeigt und die daraus resultierenden Folgen f
ur eine geeigne-
te WFMS{Architektur b eschrieb en. Hierb ei wurde deutlich, da b ei der Realisierung einer
Concurrent{Engineering{geeigneten WFMS{Architektur no ch viele oene Probleme existieren,
die weiterer Forschung b ed
urfen.
Allgemein l
at sich sagen, da die Ber
ucksichtigung anwendungssp ezischer Anforderungen nicht
nur zu einer groen Zahl unterschiedlichm
achtiger Buildtime{Komp onenten f
uhrt, sondern auch
zu verschiedenen Alternativen f
ur m
ogliche Laufzeitumgebungen (Runtime{Komp onenten).
Bisher fehlen jedo ch fundierte Untersuchungen, wie die geeignete WFMS{Architektur f
ur
ein vom Anwendungsb ereichvorgegeb enes Anforderungsprol auszusehen hat b eziehungswei-
se anhand welcher Kriterien verschiedene alternative WFMS{Architekturen verglichen werden
k
onnen. Neb en einem Kriterienkatalog zur Beurteilung von WFMS{Architekturalternativen
m
ussen solche Untersuchungen eine Klassikation verschiedener Laufzeitumgebungen liefern.
Jeder WF{Klasse (Menge von Konstrukten und Systemeigenschaften) sollen dab ei eine o der
mehrere WFMS{Architekturen zugeordnet sein, die f
ur diese Klasse am b esten geeignet sind.
Der praktische Nutzen solcher Untersuchungen w
are vielf
altig: Ein WFMS{Anwender ist b ei der
Auswahl eines geeigneten WFMS nicht mehr auf aufwendige Vergleichstests angewiesen, sondern
kann mit Hilfe der Kriterien die unterschiedlichen WFMS{Architekturen vergleichen und so das
am b esten geeignete WFMS b estimmen. Durch Abbilden seiner Anforderungen auf eine geeignete
WF{Klasse ist er auerdem in der Lage, den Realisierungsaufwand und die Ausf
uhrungskom-
plexit
at des b en
otigten WFMS abzusch
atzen. Entwickler von WFMS k
onnen einerseits anhand
der Klassikation die optimale Architektur f
ur eine vorgegeb ene Menge von Anforderungspro-
len b estimmen und anderseits feststellen, um welche Konstrukte und Systemeigenschaften ihr
bisheriges WFMS erweitert werden kann, ohne die Laufzeitumgebung grundlegend ver
andern zu
m
ussen.
Danksagung
Diese Arb eit entstand im Rahmen eines Ko op erationspro jekts mit dem Daimler-Benz-
Forschungszentrum Ulm, Abteilung Pro duktionsinformatik (F3P). Wir m
ochten uns hiermit
insb esondere b eim Leiter dieser Abteilung, Herrn Dr. Haban, sowie b ei seinen Mitarb eitern
Herrn Ortiz Bernal und Herrn Feltes f
ur die gute und immer ko op erative Zusammenarb eit
b edanken. Bei der Entstehung dieses Berichts geb
uhrt Herrn Feltes unserer b esonderer Dank.
Seine Gespr
achsb ereitschaft und fachliche Komp etenz hat die Beschreibung der hier skizzierten
Abl
aufe und Probleme aus der Anwendungsdom
ane
"
Concurrent Engineering\ erm
oglicht.
Auchwollen wir uns an dieser Stelle b ei den Teilnehmern des im April 1995 stattgefunden
"
PEFF{Workshops
Concurrent Engineering
\ , insb esondere b ei Herrn Dr. Krammer und Herrn
Vilsmeier, Daimler{Benz Aerospace Ottobrunn, b edanken. Die dort stattgefundenen Vortr
age
und Gespr
ache hab en uns einen tieferen Einblick in die in der Praxis auftretenden Probleme der
Flugzeugentwicklung b ei der Daimler{Benz Aerospace gegeb en.
LITERATUR
17
Auerdem danken wir Herrn Heinlein und Herrn Reichert, Universit
at Ulm, f
ur ihre wertvollen
Hinweise und Ratschl
age b ei der Entstehung dieser Ausarb eitung.
Literatur
[1] R. Admomeit, W. Deiters, B. Holtkamp, F. Sch
ulke, and H. Web er. K/2r: A kernel for the
ESF software factory supp ort environment. In
Proc. 2nd Int'l Conf. on Systems Integration
,
pages 325{336, Morristown, New Jersey, 1992.
[2] D. Agrawal, J. L. Bruno, A. E. Abbadi, and V. Krishnaswamy. Managing concurrent
activities in collab orativeenvironments. In Co opIS [15], pages 99{110.
[3] G. Alonso, R. G
unth
or, M. Kamath, D. Agrawal, A. E. Abbadi, and C. Mohan. Exoti-
ca/FMDC: Handling disconnected clients in a workow management system. In Co opIS
[15], pages 99{110.
[4] G. Alonso, M. Kamath, D. Agrawal, A. E. Abbadi, R. G
unth
or, and C. Mohan. Failure
handling in large scale workow management systems. Research Rep ort RJ9913, IBM, Nov.
1994.
[5] G. Alonso, C. Mohan, R. G
unth
or, D. Agrawal, A. E. Abbadi, and M. Kamath. Exoti-
ca/FMQM: A p ersistent message-based architecture for distributed workow management.
In
Proc. IFIP WG8.1 Working Conference on Information Systems for DecentralizedOr-
ganizations
,Trondheim, Aug. 1995.
[6] D. Barbara, S. Mehrotra, and M. Rusinkiewicz . INCAS: Managing dynamic workows in
distributed environments. Technical rep ort, Matsushita Information Technology Labratory,
Princeton N. Y, May 1994.
[7] T. Bauer. Realisierung einer Kommunikationsinfrastruktur f
ur sichere, verteilte Anwen-
dungen. Master's thesis, Universit
at Ulm, Fakult
at f
ur Informatik, 1995.
[8] F. Bause and M. Sczittnicj. Design von Mo dellierungsto ols zur Leistungsb ewertung: HIT,
MACOM QPN{Tool.
it + ti, Informationstechnik und Technische Informatik
, 37(3):34{40,
June 1995.
[9] H. Beilner. Werkzeuge zur mo dellgest
utzten Leistungsb ewertung.
it + ti, Informations-
technik und Technische Informatik
, 37(3):5{9, June 1995.
[10] F. Belli, K. Echtle, and W. G
orke. Metho den und Mo delle zur Fehlertoleranz.
GI Informatik
Spektrum
, 19:68{81, 1986.
[11] T. Beuter and P. Dadam. Prinzipien der Replikationskontrolle in verteilten Systemen.
Ulmer Informatik Berichte 95{11, Universit
at Ulm, Nov. 1995.
[12] G. Bolch, M. Ro essler, and R. Zimmer. Leistungsb ewertung mit PEPSY{QNS and MOSES.
it + ti, Informationstechnik und Technische Informatik
, 37(3), June 1995.
[13] Y. Breitbart, A. Deacon, H.-J. Schek, A. Sheth, and G. Weikum. Merging application{
centric and data{centric approaches to supp ort transaction{oriented multi{system work-
ows.
ACM SIGMOD Record
, 22(3):23{30, Sept. 1993.
LITERATUR
18
[14] B. Butscher, L. Henckel, and T. Luckenbach. Die Kommunikationsplattform BERKOM f
ur
multimediale Anwendungen.
GI Informatik Spektrum
, 14:261{269, 1991.
[15]
Proc. 3rd Int. Conf. on Cooperative Information Systems
, Vienna, Austria, May 1995.
[16] P. Dadam, K. Kuhn, M. Reichert, T. Beuter, and M. Nathe. ADEPT: Ein integrierender
Ansatz zur Entwicklung exibler, zuverl
assiger ko op erierender Assistenzsysteme in klini-
schen Anwendungsumgebungen. In GI [25], pages 677{686.
[17] U. Dayal, M. Hsu, and R. Ladin. A transactional mo del for long{running activities. In
Proc.
17th Int'l Conf. on Very Large Data Bases (VLDB)
, pages 113{122, Barcelona, Spain, Sept.
1991. Morgan Kaufmann.
[18] Sp ecial issue on workow and extended transaction systems.
IEEE Data Engineering Bul le-
tin
, 16(2), June 1993.
[19]
Proceedings of the International Conference on Database and Expert Systems Applications
(DEXA)
,Valencia, Spain, 1992. Springer.
[20] J. Eder and W. Liebhart. The workowactivitymodelWAMO. In Co opIS [15], pages
87{98.
[21] A. K. Elmagarmid, editor.
Database Transaction Models for Advanced Applications
. Morgan
Kaufmann Publishers, 1992.
[22] H. Garcia-Molina, D. Gawlick, J. Klein, K. Kleissner, and K. Salem. Mo deling long{running
activities as nested sagas.
IEEE Data Engineering Bul letin
, 14(1), Mar. 1991.
[23] D. Georgakop oulos, M. F. Hornick, and A. Sheth. An overview of workow management:
From pro cess mo deling to workow automation infrastructure.
Distributed and Paral lel
Databases
, 3:119{153, 1995.
[24] R. Gerstner. Ereignisse als Basis einer workoworientierten Architektur von Anwendungs-
systemen. In
Proc. GI Fachtagung MobIS'95
,Bamb erg, Germany, Oct. 1995.
[25]
Proc. GI{Jahrestagung
,Z
urich, Sept. 1995. Springer.
[26] J. Gray and A. Reuter. Transaction pro cessing monitors: An overview. In
Transaction
Processing: Concepts and Techniques
,chapter 5, pages 239{290. Morgan Kaufmann, 1993.
[27] V. Gruhn. Entwicklung von Informationssystemen in der LION{Entwicklungsumgebung. In
G. Scheschonk and W. Reisig, editors,
Petri{Netze im Einsatz f
ur Entwurf und Entwicklung
von Informationssystemen
. Springer, 1993.
[28] F. Hartleb, P. Dauphin, R. Klar, A. Quick, and M. Siegle. Mo dellierung und Meun-
terst
utzung mit dem Werkzeug PEPP.
it + ti, Informationstechnik und Technische Infor-
matik
, 37(3):41{47, June 1995.
[29] H. Hartsto ck, M. Klepp el, R. Kossow, M. Tusche, and J. Wege.
Lotus Notes, Das Kompen-
dium, Einf
uhrung, Arbeitsbuch, Nachschlagewerk
. Markt & Technik Buch{ und Software
Verlag, 1995.
[30] S. Jablonski.
Workow{Management{Systeme, Model lierung und Architektur
. Thomson,
1995.
LITERATUR
19
[31] S. Jablonski, S. Barthel, T. Kirsche, T. R
odinger, H. Schuster, and H. Wedekind. Da-
tenbankunterst
utzung f
ur ko op erative Grupp enarb eit.
Informationstechnik und Technische
Informatik
, 35(1):34{44, 1993.
[32] S. Jablonski, T. Ruf, and H. Wedekind. Implementation of a distributed data management
system for technical applications{ a feasibility study.
Information Systems
, 15(2):247{256,
1990.
[33] R. D. Katz. Toward a unied framework for version mo deling in engineering databases.
ACM Computing Surveys
, 22(4):375{408, Dec. 1990.
[34] C. Kelling, R. German, A. Zimmermann, and G. Hommel. TimeNET | ein Werkzeug zur
Mo dellierung mit zeiterweiterten Petri{Netzen.
it + ti, Informationstechnik und Technische
Informatik
, 37(3):21{27, June 1995.
[35] Krammer, Altmeyer, and Holz. PEFF: Prozenetzwerk Entwicklung und Fertigung im
Flugzeugbau, Ergebnisb ericht Nr. 2, IST{Prozeerfassung und Schwachstellen. Technical
rep ort, Daimler{Benz Aerospace, Daimler{Benz Forschung und Technik, Pro duktionsinfor-
matik (F3P), Sept. 1993.
[36] K. Kuhn, M. Reichert, and P. Dadam. Unterst
utzung der klinischen Ko op eration durch
Workow-Management-Systeme: Anforderungen, Probleme, Persp ektiven. In H. J. Tram-
pisch and S. Lange, editors,
40. Jahrestagung der GMDS: Medizinische Forschung |
Arzt-
liches Handeln
, pages 437{441, M
unchen, 1995.
[37] K. Kuhn, M. Reichert, and P. Dadam. Using workow management systems in clinical
environments, a critical analysis. Submitted for publication, 1996.
[38] Y. Leu. Comp osing multidatabase applications using exible transactions.
IEEE Data
Engineering Bul letin
, 14(1), Mar. 1991.
[39] F. Leymann. Supp orting business transactions via partial backward recovery in workow
management systems. In
Proc. GI{Fachtagung Datenbanksysteme in B
uro, Technik und
Wissenschaft (BTW)
, Dresden, Germany, Mar. 1995. Springer, Informatik aktuell.
[40] F. Leymann and W. Altenhub er. Managing business pro cesses as an information resource.
IBM Syst. J.
, 33(2):326{348, 1994.
[41] H. L
uhrsen. ISO{Norm STEP/EXPRESS | Einsatz ob jektorientierter Technologie in der
Pro duktdatenverwaltung. In
Innovative Softwaretechnologien: Neue Wege mit objektorien-
tierten Methoden und Client/Server{Architekturen
, pages C614.01{C614.15. S. J
anichen,
1994.
[42] D. R. McCarthy and S. K. Sarin. Workow and transactions in InConcert. In DEB [18],
pages 53{56.
[43] J. Meyer. Anforderungen an zuk
unftige Workow{Management{Systeme: Flexibilisie -
rung, Ausnahmeb ehandlung und Dynamisierung | Er
orterung am Beispiel medizinisch{
organisatorischer Abl
aufe. Master's thesis, Universit
at Ulm, Fakult
at f
ur Informatik, 1996.
[44] C. Mohan, G. Alonso, R. G
unth
or, and M. Kamath. Exotica: a research p ersp ectiveon
workow management systems.
IEEE Data Engineering Bul letin
, 18(1):19{26, Mar. 1995.
LITERATUR
20
[45] J. Mylop oulos and R. Motschnig-Pirtrik. Partitioning information bases with contexts. In
Co opIS [15], pages 44{54.
[46] A. Ob erweis. INCOME/STAR: Metho dology and to ols for the development of distributed
information systems.
Information Systems
, 19(8):643{660, Dec. 1994.
[47] R. Ortiz and P. Dadam. The concurrency mo del: Activating an engineering database
through an integrated pro duct and pro cess data mo del. In
Proceedings of the Interna-
tional Conferenceon Database and Expert Systems Applications (DEXA)
, London, UK,
Sept. 1995. Springer.
[48] R. Ortiz and P. Dadam. Towards the b oundary of concurrency.In
Proc. of the Int. Confe-
rence on Concurrent Engineering
, McLain, Virginia, USA, Aug. 1995.
[49] R. Pooley.Performance Analysis To ols in Europ e.
it + ti, Informationstechnik und Tech-
nische Informatik
, 37(3):10{16, June 1995.
[50] C. Pu and A. Le. Replica control in distributed systems: An asynchonous approach.
ACM
SIGMOD Record
, 20(2):377{386, June 1991.
[51] C. V. Ramamo orthy and G. S. Ho. Performance evaluation of asynchronous concurrent
systems using p etri nets.
IEEE Trans. on Software Engineering
, SE-6(5):440{449, Sept.
1980.
[52] B. Reinwald and H. Wedekind. Automation of control and data ow in distributed appli-
cation systems. In DEXA [19], pages 475{481.
[53] N. Ritter, B. Mitschang, T. H
arder, and U. Nink. Unterst
utzung der Ablaufsteuerung in
Entwurfsumgebungen durchVersionierung und Kongurierung. In
Proc. STAK' 94, Soft-
waretechnik in Automatisierung und Kommunikation | Datenbanken unter Realzeit{ und
technischen Entwicklungsanforderungen
, pages 135{169, 1994.
[54] T. G. Rob ertazzi.
Computer Networks and Systems: Queueing Theory and Performance
Evaluation
. Springer, 1995.
[55] A. Schill and A. Malhotra. Language and distributed system supp ort for complex organi-
zational services. In P. de Jong, editor,
Conferenceon Organizational Computing Systems
,
pages 1{15, Atlanta, Georgia, Nov. 1991. ACM press.
[56] P.Schneider and M. Feltes. PEFF: Prozenetzwerk Entwicklung und Fertigung im Flug-
zeugbau, Zwischenb ericht zur Betrachtung der Prozekette
"
Konstruktion und Fertigung
eines Leitungsb
undels\. Technical rep ort, Daimler{Benz Forschung und Technik, Pro duk-
tionsinformatik (F3P), Nov. 1993.
[57] B. Schulthei. Prozereengineering in klinischen Anwendungsumgebungen, Beispiele, Vor-
gehensmo delle, Werkzeuge. Master's thesis, Universit
at Ulm, Fakult
at f
ur Informatik, 1996.
[58] W. Schulze and M. B
ohm. Klassikation von Vorgangsverwaltungssystemen. In Vossen and
Becker [64], chapter 16, pages 279{293.
[59] H. Schuster, S. Jablonski, T. Kirsche, and C. Bussler. Aclient/server architecture for
distributed workow management systems. In
Proceedings of the International Conference
on Paral lel and Distributed Information Systems
, Austin, Texas, Sept. 1994. extended
version.
LITERATUR
21
[60] K. Schwab. Ko ordinationsmo delle und Softwarearchitekturen als Basis f
ur die Auswahl und
Sp ezialisi erung von Workow{Management{Systemen. In Vossen and Becker [64], chap-
ter 17, pages 295{317.
[61] C. U. Smith. The Evolution of Performance Analysis To ols.
it + ti, Informationstechnik
und Technische Informatik
, 37(3):17{20, June 1995.
[62] WorkParty V2.0, Pro duktinformationen. Technical rep ort, Siemens Nixdorf Informations-
systeme AG, Oct. 1995.
[63] P.Vogel and R. Ere. Backtracking oce pro cedure. In DEXA [19], pages 506{511.
[64] G. Vossen and J. Becker, editors.
Gesch
aftsprozemodel lierung und Workow{Management
.
Thomson, 1996.
[65] H. Wabnig and G. Haring. PAPS|Werkzeuge zur Leistungsvorhersage von parallelen
Systemen.
it + ti, Informationstechnik und Technische Informatik
, 37(3):48{53, June 1995.
[66] H. W
achter, F. J. Fritz, A. Berthold, B. Drittler, H. Eckert, R. Gerstner, R. G
otzinger,
R. Krane, A. Schae, C. Schl
ogel, and R. Web er. Mo dellierung und Ausf
uhrung exibler
Gesch
aftsprozesse mit SAP Business Workow 3.0. In GI [25], pages 197{204.
[67] Glossary | workow management coalition sp ecication. Technical rep ort, Workow Ma-
nagement Coalition, Dec. 1994.
[68] The workow reference mo del. TC00-1003, Workow Management Coalition, Dec. 1994.