Repr¨
asentation von Schema- und Instanzobjekten in
adaptiven Prozess–Management–Systemen
Markus Lauer, Stefanie Rinderle, Manfred Reichert
Abteilung Datenbanken und Informationssysteme, Universit¨
at Ulm
{ml4, rinderle, reichert}@informatik.uni-ulm.de
1 Einf¨
uhrung
Immer mehr Unternehmen setzen zur Steuerung, Verwaltung und ¨
Uberwachung ihrer be-
trieblichen Abl¨
aufe ein Prozess–Management–System (PMS) ein. Eine wichtige Voraus-
setzung f¨
ur den sinnvollen Einsatz eines PMS ist, dass es die Eigenschaft der Adaptivit¨
at
besitzt [RRD04a, SMO00]: Es muss ¨
Anderungen der hinterlegten Prozessvorlagen – wir
sprechen hierbei von Schemaevolution – und der sich in Ausf¨
uhrung befindlichen Prozesse
zur Laufzeit zulassen, damit die Unternehmen in der Lage sind, flexibel und schnell auf
neue Anforderungen zu reagieren. Prozessoptimierungen, ¨
Anderungen der innerbetriebli-
chen Organisation, wie z. B. Auslagern der Produktion ins Ausland, oder neue gesetzliche
Bestimmungen machen Modifikationen der Prozessvorlage notwendig. ¨
Anderungen von
Instanzen sind notwendig, um unvorhersehbaren Situationen (z. B. Ausfall von Maschi-
nen) begegnen oder um sp¨
ate Kundenw¨
unsche noch ber¨
ucksichtigen zu k¨
onnen.
Adaptivit¨
at stellt jedoch hohe Anspr¨
uche an das PMS: Effiziente Algorithmen m¨
ussen
daf¨
ur sorgen, dass die ¨
Anderungen nicht zu inkonsistenten Zust¨
anden von Prozessvorlagen
und-instanzenf¨
uhren.ModifikationenderProzessvorlagen m¨
ussen,wovomAusf¨
uhrungs-
zustand her m¨
oglich, auch auf die darauf basierenden Prozessinstanzen propagiert werden
k¨
onnen. Bei verzerrten Instanzen — das sind Instanzen, die sich aufgrund von Adhoc–
¨
Anderungen in ihrer Ablaufsstruktur gegen¨
uber der Original–Vorlage unterscheiden —
m¨
ussen zus¨
atzlich Probleme, die sich bei der Migration auf die neue Version aus ¨
uberlap-
penden Vorlagen- und Instanz¨
anderungen ergeben, erkannt und gehandhabt werden. Dabei
d¨
urfen die anderen, parallel ablaufenden Funktionen des PMS nicht beeintr¨
achtigt wer-
den, selbst wenn in realen Anwendungen tausende von Instanzen migriert werden m¨
ussen.
Hinzu kommt, dass dem PMS f¨
ur diese Aufgaben nur eingeschr¨
ankt Ressourcen, wie z. B.
Speicher, zur Verf¨
ugung stehen. Alle diese Anforderungen verlangen nach einer flexiblen
und ressourcensparenden Architektur sowie nach einer effizienten Implementierung.
Die auf dem Markt erh¨
altlichen Produkte bieten entweder gar keine oder nur eingeschr¨
ank-
te ¨
Anderungsm¨
oglichkeiten zur Laufzeit oder erf¨
ullen die angesprochenen Anforderungen
nur unzureichend. Wir entwickeln in unserem Projekt ADEPT ein PMS der n¨
achsten Ge-
neration, welches ¨
Anderungen zur Laufzeit vollst¨
andig unterst¨
utzt. Die formalen Grundla-
gen hierf¨
ur haben wir in fr¨
uheren Ver¨
offentlichungen beschrieben [RRD03, RRD04b]. In
diesem Beitrag stellen wir einen ersten Architekturansatz vor, der ¨
Anderungen von Instan-
zen und Prozessvorlagen erm¨
oglicht, wie z. B. das Einf¨
ugen und L¨
oschen von Aktivit¨
aten,
Proc. Workshop Geschäftsprozessorientierte Architekturen (Informatik '04), LNI P-51,
Germany, September 2004, S. 555-560
Sync-Kanten und Datenelementen, der die Migration effizient unterst¨
utzt und der einen ge-
r
ingen Speicherbedarf aufweist. Er wurde von uns in einem neuen Prototyp implementier
t,
d
er auf dem Workshop ebenfalls demonstriert werden soll.
2
Schema- und Instanzobjekte in adaptiven PMS
E
in in der Literatur (vgl. [We01]) vorgeschlagener Implementierungsansatz von Prozes
s-
v
orlagen und -instanzen wird in Abb. 1 illustriert. Dabei wird die Prozessbeschreibun
g
A1 A3A2
AAktivität
Kontrollkante
Datenflusskante
Status: erledigt
Status: inaktiv
Status: aktiviert
A1 A3A2
Vorlage S1
Datenelement 1
A1 A3A2
W1
Instanz I3
A1:
Datenelement 1:
A2:
A3:
W1
A23:
Instanz I2
A1:
Datenelement 1:
A2:
A3:
W1
A23:
Instanz I1
A1:
Datenelement 1:
A2:
A3:
W1
Abbildung 1: Die Repr¨
asentation von Instanzen eines Prozess-Typs
(
u. a. Kontroll- und Datenfluss) in einem Objekt, der Prozessvorlage, gekapselt, das de
n
P
rozesstyp repr¨
asentiert. Die Instanz–Objekte, welche Prozessinstanzen repr¨
asentieren
,
e
nthalten selbst nur Laufzeitinformationen, wie den Ausf¨
uhrungsstatus von Aktivit¨
ate
n
u
nd logisch, nicht unbedingt physisch, den Inhalt der Datenelemente. Die Typzugeh¨
orig
-
k
eit wird durch eine Referenz auf das entsprechende Prozessvorlagen–Objekt ausgedr¨
uck
t.
A
lle Instanzen eines Prozesstyps referenzieren das gleiche Vorlagen–Objekt. Dieser An
-
s
atz soll als Ausgangsbasis dienen. Gegen¨
uber der Variante, f¨
ur jede Instanz die jeweilig
e
P
rozessbeschreibung redundant zu speichern, resultiert ein erheblich geringerer Speiche
r-
p
latzbedarf bei großer Instanzzahl. Ein weiterer Vorteil ist, dass sich damit auch signifikan
t
R
echenzeit einsparen l¨
asst, da strukturver¨
andernde Operationen bei einer Schemaevolut
i-
o
n nur einmal auf die Prozessvorlage angewendet werden m¨
ussen, bei der anderen Varian
te
d
agegen auf jede einzelne Prozessinstanz.
B
ei dieser Implementierung darf allerdings die Schema¨
anderung nicht direkt auf dem
V
orlagen–Objekt ausgef¨
uhrt werden, welches die aktuelle Version repr¨
asentiert. Die Pro
-
p
agation der Schema¨
anderungen auf Instanzen w¨
urde zwar damit in einem Vorgang erfo
l-
g
en, aber dann k¨
onnten auch Instanzen f¨
alschlicherweise migriert werden, die f¨
ur dies
e
¨
A
nderungen zu weit fortgeschritten sind. In Abb. 2 laufen Instanzen I1 und I2 auf de
r-
s
elben Vorlage S1, wobei I1 weiter fortgeschritten ist als I2. Da die Aktivit¨
at A2 bei I
1
s
chon ausgef¨
uhrt worden ist, ist I1 unvertr¨
aglich mit der neuen Version von S1, bei de
r
v
or A2 die Aktivit¨
at A12 eingef¨
ugt wird. Wird nun die ¨
Anderung direkt auf S1 ausgef¨
uhr
t,
s
o migriert zwar I2 ordnungsgem¨
aß, aber Instanz I1 folgt verbotenerweise ebenfalls dem
n
euen Schema, da sie weiterhin S1 referenziert. Eine Inkonsistenz ist die Folge: A2 von I
1
w
urde abgearbeitet, bevor die Vorg¨
angeraktivit¨
at A12 ausgef¨
uhrt worden ist.
D
ie Koexistenz von Instanzen neuer und alter Form kann sichergestellt werden, indem ein
e
K
opie des Vorlagen–Objekts angelegt wird, daran die Modifikationen ausgef¨
uhrt werde
n
u
nd dann alle migrierbaren Instanzen auf dieses Objekt umgeh¨
angt werden. In diesem Fa
ll
Vorlage S1
direkt
abändern
A1 A3A2
Vorlage S1 Datenelement 1
Instanz I1
A1:
Datenelement 1:
A2:
A3:
W1
A1 A2A12
W1
A3
Instanz I2
A1:
Datenelement 1:
A2:
A3:
W2
Instanz I1
A1:
Datenelement 1:
A2:
A3:
W1
A12:
A1 A2A12
Vorlage S1‘ Datenelement 1
A3
A1 A2A12
W2
A3
Instanz I2
A1:
Datenelement 1:
A2:
A3:
W2
A12:
Vor der Migration Nach der Migration
Abbildung 2: Unerlaubte Migration der Instanz I1 bei der direkten Ab¨
anderung der Vorlage S1
besteht der Migrationsvorgang aus dem “Umbiegen” der Referenz auf die neue Version.
2.1 Repr¨
asentationsvariante f¨
ur verzerrte Instanzen
Wie lassen sich mit obigen Implementierungsvorschlag instanzbezogene Adhoc–Mod
i-
fikationen abbilden? Eine M¨
oglichkeit ist es, eine Kopie des entsprechenden Vorlagen
–
Objekts anzufertigen, die ¨
Anderungen darauf anzuwenden und dann die Instanz auf diese
s
Schema umzubiegen. Von Nachteil ist, dass damit die urspr¨
ungliche Prozesstyp–Zugeh¨
o
-
rigkeit verloren geht: Die verzerrte Instanz referenziert nicht mehr das urspr¨
ungliche Vo
r-
lagen-Objekt S1, obwohl sie noch von dem durch dieses Objekt beschriebenen Prozessty
p
abstammt. Ohne zus¨
atzliche Vorkehrungen wird die Instanz bei einer sp¨
ateren Schemaevo
-
lution nicht mehr ber¨
ucksichtigt. Hinzu kommt, dass dieser Ansatz zu der anfangs erw¨
ahn
-
ten L¨
osung, bei der in jeder Instanz der gesamte Prozessablauf hinterlegt ist, degenerier
t,
wenn mehr und mehr Instanzen individuell abge¨
andert werden. Ber¨
ucksichtigt man abe
r,
dass bei Instanz¨
anderungen i. A. nur ein kleiner Teil des urspr¨
unglichen Prozessschema
s
angepasst wird, so l¨
asst sich eine alternative Strategie zur Repr¨
asentation verzerrter Instan
-
zen anwenden: Man speichert bei jeder modifizierten Instanz nur die Abweichungen vom
urspr¨
unglichen Schema. Diese k¨
onnen auf zweierlei Arten repr¨
asentiert werden, entwede
r
durch die ¨
Anderungsoperationen selbst oder durch eine Delta–Schicht. Aus Platzgr¨
unde
n
wenden wir uns gleich dem aus unserer Sicht besseren Konzept zu: der Delta-Schicht.
Abb. 3 verdeutlicht das Konzept der Delta–Schicht. Sie wird durch ein Objekt repr¨
asen
-
tiert, das die gleichen Schnittstellen wie das Prozessvorlagen–Objekt besitzt und dahe
r
nach außen hin die gleichen Operationen anbietet. Der Unterschied zum eigentliche
n
Vorlagen–Objekt besteht darin, dass es nicht den gesamten Prozess–Graphen wiedergib
t,
sondern nur die Ausschnitte, die durch instanzbezogene Modifikationen ge¨
andert wurden
.
Zusammen mit dem Original–Vorlagen–Objekt, das den Prozesstyp der Instanz bestimm
t,
repr¨
asentiert das Delta–Schicht–Objekt das gegen¨
uber der Prozessvorlage abge¨
ander
te
Laufzeitschema der modifizierten Instanz. Das Instanz–Objekt, das die ge¨
anderte Instan
z
repr¨
asentiert, referenziert dann nicht mehr, wie in Abb. 3 anhand von I1 gezeigt, das en
t-
sprechende Vorlagen–Objekt, sondern das Delta–Schicht–Objekt. Erst das Delta–Schicht
–
Objekt setzt auf dem Original–Vorlagen–Objekt auf und bewahrt auf diesem Weg u. a. d
ie
A1 A3A2
Vorlage S1
Datenelement 1
A
AAktivität
Verweis auf Aktivität
Kontrollkante Datenflusskante
Status: erledigt
Status: aktiviert
Status: inaktiv
A1 A23A2
W1
A3
Instanz I1
A1:
Datenelement 1:
A2:
A3:
W1
A23: Instanz I2
A1:
Datenelement 1:
A2:
A3:
W2
A2*A1 A23 A3*
Delta-Schicht A1 A2
W2
A3
Abbildung 3: Das Konzept der Delta-Schicht
Typzugeh¨
origkeit von I1 zum Prozesstyp S1. Die unver¨
anderten Instanzen (z. B. Instan
z
I2) referenzieren das originale Prozessvorlagen–Objekt weiterhin direkt. Bei modifizierte
n
Instanzen werden deshalb Anfragen, wie ”Gib mir alle direkten Nachfolgeaktivit¨
aten vo
n
Aktivit¨
at Z!“, zuerst an die Zwischenschicht gerichtet, bei unver¨
anderten dagegen dire
kt
an das originale Vorlagen–Objekt.
Wie die Delta–Schicht realisiert werden kann, h¨
angt von der Repr¨
asentation der Kno
-
ten und Kanten des Prozess–Graphen ab. In unserer Implementierung existieren kein
e
Kanten–Objekte. Wir speichern zu jeder Aktivit¨
at die IDs der Vorg¨
anger- und Nachfo
l-
geraktivit¨
aten und stellen dadurch implizit den Kontrollfluss her. Vor einer dynamische
n
¨
Anderung werden alle Aktivit¨
aten–Objekte automatisch in die Delta–Schicht kopiert, d
ie
von der ¨
Anderung betroffen sind. Diese wird dann auf den Kopien durchgef¨
uhrt. Um z. B
.
die Aktivit¨
at A23 sequentiell zwischen die Nachbaraktivit¨
aten A2 und A3 einzuf¨
uge
n,
werden zuerst die Aktivit¨
aten–Objekte A2 und A3 komplett, inklusive der ID, kopiert un
d
als A2* und A3* in die Delta–Schicht eingef¨
ugt1. A2 und A3 m¨
ussen kopiert werden, d
a
sich ihre Nachfolger- bzw. Vorg¨
angermengen ¨
andern. Danach wird das Aktivit¨
aten–Obje
kt
A23 in der Delta–Schicht angelegt. Schließlich wird A23 sequentiell zwischen A2* un
d
A3* eingereiht, indem die Vorg¨
anger- und Nachfolgerlisten von A2*, A3* und A23 en
t-
sprechend angepasst werden. In einer Implementierung mit Kanten–Objekten m¨
ussen f
¨
u
r
die Einf¨
uge–Operation nicht A2 und A3 in die Delta–Schicht kopiert werden. Es werde
n
nur A23 und die Kantenobjekte f¨
ur die Verbindungen A2→A23 und A23→A3 angeleg
t.
Zus¨
atzlich muss A2→A3 noch als gel¨
oscht markiert werden.
Zur Beantwortung der obigen Anfrage ”Gib mir alle direkten Nachfolgeaktivit¨
aten vo
n
Aktivit¨
at Z!“ sieht die Delta–Schicht bei der Implementierung ohne Kanten–Objekte zu
-
erst nach, ob sie ein Aktivit¨
aten–Objekt mit entsprechender ID gespeichert hat. Wenn ja, s
o
gibt sie dessen Nachfolgerliste zur¨
uck. Ansonsten leitet sie die Anfrage an das referenzie
r-
te Prozessvorlagen–Objekt weiter. Im Falle der Implementierung mit Kanten–Objekte
n
holt sich die Delta–Schicht erst einmal alle Kanten–Objekte von der Prozessvorlage,
in
denen die Aktivit¨
at Z als Quelle verzeichnet ist. Dann entfernt sie aus dieser Menge al
le
als gel¨
oscht markierten Kanten und vereinigt sie mit der Menge der durch die Adhoc
–
Modifikationen neu hinzugekommenen Kanten mit Z als Quelle. Die Menge enth¨
alt nu
n
1Der Stern soll nur zum besseren Verst¨
andnis beitragen.
2.2 Migration verzerrter Instanzen
W
ie l¨
asst sich nun eine verzerrte Instanz auf eine neue Version der zugrunde liegende
n
V
orlage migrieren, wenn sich die Schema- und Instanz-¨
Anderungen nicht ¨
uberlappen
?
E
in Ansatz ist es, die Referenz auf das Vorlagen–Objekt in der Delta–Schicht auf die neu
e
V
ersion “umzubiegen”. Dies kann aber bei der Implementierungsvariante ohne Kanten
–
O
bjekte zu Problemen f¨
uhren: A1, A2 und A3 seien drei sequentielle Aktivit¨
aten. Da
s
E
inf¨
ugen eines Knoten A23 zwischen A2 und A3 auf Instanz–Ebene f¨
uhrt dazu, das ein
e
K
opie A2* von A2 in der Delta-Schicht angelegt und darin die ID von A23 anstelle d
er
I
D von A3 in die Nachfolgerliste aufgenommen wird. Durch Einf¨
ugen der Aktivit¨
at A1
2
z
wischen A1 und A2 auf Schema–Ebene wird die ID von A1 durch die ID von A12
in
d
er Vorg¨
angerliste von A2 ersetzt. Die Anfrage ”Gib mir die direkten Vorg¨
anger von A2
“
l
iefert jedoch weiterhin A1 als Vorg¨
anger, da die Delta–Schicht die Vorg¨
angerliste vo
n
A
2* zur¨
uckgibt, die aber durch die Schemaevolution nicht angepasst wurde und desha
lb
i
mmer noch die ID von A1 enth¨
alt (vgl. Abb. 4).
A1 A3A2
Vorlage S1 Datenelement 1
A2*A1 A23 A3*
Delta-Schicht
Instanz I1
X
A1 A2A12
Datenelement 1
A3
Schemaevolution
S1 -> S1‘
Xgelöscht
Kontrollkante
Datenflusskante
A
A
Aktivität
Verweis auf Aktivität
XX
Vorlage S1‘
Abbildung 4: Migration von verzerrten Instanzen bei Implementierungen ohne Kantenobjekte
E
ine L¨
osung dieses Problems besteht darin, auf das Vorlagen–Objekt, das die neue Versio
n
d
es Schemas repr¨
asentiert, ein leeres Delta–Schicht–Objekt aufzusetzen, darauf dann d
ie
g
leichen dynamischen ¨
Anderungen anzuwenden und es schließlich von dem entsprechen
-
d
en Instanz–Objekt zu referenzieren. Da bei dieser Vorgehensweise das Einf¨
ugen von A1
2
v
or dem Einf¨
ugen von A23 erfolgt, weist A2 schon vor dem Kopieren in die Delta–Schic
ht
A
12 als seinen Vorg¨
anger aus. Nach dem Kopieren gilt daher das Gleiche f¨
ur die Kop
ie
A
2* von A2. Die Anfrage wird somit korrekt beantwortet. Die Abfolge der auf Instan
z-
u
nd Typebene vorgenommenen ¨
Anderungen zu vertauschen war zul¨
assig, da vorausgeset
zt
w
urde, dass sich die ¨
Anderungen nicht ¨
uberlappen.
B
ei der Implementierung mit Kantenobjekten tritt das Problem des “vergessenen” Vo
r-
g
¨
angers nicht auf: Die Delta–Schicht enth¨
alt hier durch das dynamische Einf¨
ugen vo
n
A
23 — abgesehen vom Aktivit¨
aten–Objekt f¨
ur A23 — nur die neuen Kanten A2→A2
3
u
nd A23→A3. A2→A3 wird dagegen als aufgehoben markiert. Auf Schema–Ebene we
r-
d
en beim Einf¨
ugen von A12 die Kante A1→A2 komplett entfernt und daf¨
ur A1→A12 un
d
A
12→A2 eingef¨
ugt. Zur Bearbeitung der obigen Anfrage holt sich die Delta–Schicht er
st
a
lle Kanten mit A2 als Ziel von der Prozessvorlage. Das Vorlagen–Objekt gibt in diese
m
B
eispiel nur A12→A2 an die Delta–Schicht zur¨
uck. Da die Kante in der Delta–Schic
ht
nicht als gel¨
oscht markiert ist und dort keine weiteren Kanten mit A2 als Ziel vermerkt
sind, liefert die Delta–Schicht schließlich A12 als Vorg¨
angeraktivit¨
at von A2. Die Variant
e
mit den Kanten–Objekten hat jedoch den Nachteil, dass immer ein Zugriff auf das zugrun
-
deliegende Vorlagen–Objekt notwendig ist, um die ein- oder ausgehenden Kanten eine
r
Aktivit¨
at zu bestimmen. Bei der anderen Variante entf¨
allt dieser Zugriff auf das Vorlagen
–
Objekt, wenn die entsprechende Aktivit¨
at bereits in der Delta–Schicht vorhanden ist.
3 Zusammenfassung und Ausblicke
Mit dem skizzierten Ansatz liegt eine ¨
ubersichtliche interne Repr¨
asentation von Prozess
-
vorlagen und Instanzen vor, mit der sich die Migration von unver¨
anderten und sogar dy
-
namisch abge¨
anderten Instanzen einfach realisieren l¨
asst. Der Migrationsvorgang ist auc
h
schnell und effizient, da er bei diesem Ansatz meistens nur aus dem Umh¨
angen von Re
-
ferenzen besteht. Außerdem konnte der Speicherbedarf gegen¨
uber anderen Ans¨
atzen star
k
reduziert werden, da auf Wiederverwendung gesetzt wurde — dasselbe Prozessvorlagen
–
Objekt wird z. B. von mehren Instanzen referenziert — und da die Delta-Schicht nu
r
abge¨
anderte Abschnitte des Prozessgraphen speichert. Diese Eigenschaften sprechen f¨
u
r
einen Einsatz in der Praxis. Der Delta-Schicht-Ansatz zur Repr¨
asentation der Abwe
i-
chung eines Instanzschemas gegen¨
uber der Vorlage und der vorgestellte Migrationsablau
f
k¨
onnen prinzipiell uneingeschr¨
ankt auf andere Workflow-Modelle ¨
ubertragen werden. D
a
aber nur Instanzen migriert werden d¨
urfen, bei denen die ¨
Anderungen mit dem bisher
i-
gen Prozessablauf vereinbar sind, m¨
ussen Informationen sowohl ¨
uber den momentane
n
Ausf¨
uhrungsstand als auch ¨
uber den bisherigen Verlauf vorliegen. Damit ist die ¨
Ubertra
-
gung nur auf Workflow-Modelle sinnvoll, die entsprechende Informationen bereitstelle
n
(siehe z. B. [RRD04a]). Der pr¨
asentierte Ansatz muss jedoch noch erweitert werden, um
weitere Anforderungen, die ein Einsatz in Produktivsystemen mit sich bringt, zu erf¨
ullen
.
Es m¨
ussen u. a. darauf abgestimmte Sperrverfahren entwickelt werden, um den nebenl¨
aufi
-
gen Zugriff sowohl auf Prozessvorlagen als auch auf Instanzen zu koordinieren. Beispiels
-
weise muss abgefangen werden, dass ein Benutzer eine Instanz zu modifizieren beginn
t,
die gerade im Begriff ist zu migrieren. Auch muss untersucht werden, wie eine Migratio
n
durchgef¨
uhrt wird, wenn eine Instanz partitioniert von mehreren Prozess–Engines aus
-
gef¨
uhrt wird. Außerdem haben wir bisher bei der Migration von verzerrten Instanzen di
e
Einschr¨
ankung gemacht, dass sich die Schema- und die Instanz¨
anderungen nicht ¨
uberlap
-
pen d¨
urfen. An diesen und weiteren Aspekten arbeiten wir derzeit sehr intensiv.
Literatur
[RRD03] Reichert, M.; Rinderle, S.; Dadam, P.: On the Common Support of Workflow Type an
d
Instance Changes Under Correctness Constraints. Proc. CoopIS ’03, Catania, 2003
[RRD04a] Rinderle, S.; Reichert, M.; Dadam, P.: Correctness Criteria for Dynamic Changes i
n
Workflow Systems - A Survey. Data and Knowledge Engineering, 50(1):9-34(2004)
[RRD04b] Rinderle, S.; Reichert, M.; Dadam, P.: Flexible Support of Team Processes by Adaptiv
e
Workflow Systems. Distributed and Parallel Databases, 16(1):91-116(2004)
[SMO00] Sadiq, S.; Marjanovic, O.; Orlowska, M.E.: Managing Change and Time in Dynami
c
Workflow Processes. IJCIS, 9(1&2):1-25(2000)
[We01] Weske, M.: Formal Foundation and Conceptual Design of Dynamic Adaptations in
a
Workflow Management System. Proc. 34th Hawaii Int’l Conf. on System Sciences, 200
1
