Variable Serverzuordnungen
und komplexe Bearbeiterzuordnungen im
Workflow-Management-System ADEPT
Thomas Bauer, Peter Dadam
Abteilung Datenbanken und Informationssysteme, Universit¨at Ulm
bauer, dadam
@informatik.uni-ulm.de
Zusammenfassung
Bei großen, unternehmensweiten Workflow- (WF) Anwendungen k¨onnen die Belastung der WF-
Server und das Kommunikationsaufkommen in den Teilnetzen zum Engpaß werden. In diesem Beitrag
wird gezeigt, wie eineverteilte WF-Steuerung dergestalt realisiert werden kann, daß die Belastung der
beteiligten Komponenten zur Ausf¨uhrungszeit minimiert wird. Dazu kann die WF-Steuerung einer In-
stanz von einem WF-Server auf einen anderen migrieren. Ausgehend von den Bearbeiterzuordnungen
wird zur Modellierungszeit f¨ur alle Aktivit¨aten jeweils der WF-Server ermittelt, durch dessen Wahl
die Kommunikationskosten minimiert werden. Da Bearbeiterzuordnungen von vorangegangenen Ak-
tivit¨aten abh¨angen k¨onnen, ist eine statische Serverzuordnung nicht immer angebracht. Deshalb wer-
den sog. logische Serverzuordnungsausdr¨ucke eingef¨uhrt, durch die eine dynamische Serverzuord-
nung ohne aufwendige Laufzeitanalysen m¨oglich wird.
1 Motivation und Einf¨uhrung
Workflow-Management-Systeme (WfMSe) stellen eine vielversprechende Technologie f¨ur die Reali-
sierung vorgangsorientierter, unternehmensweiter verteilter Anwendungssysteme dar. Sie sind in einer
Phase, die mit den fr¨uhen Tagen relationaler Datenbanksysteme (RDBS) verglichen werden kann. Die
eigentlichen Herausforderungen entstehen erst dann, wenn zu großen Systemen ¨ubergegangen wird.
RDBS-Technologie zog Anwendungsentwickler und Benutzer mit einer semantisch h¨oheren Query-
Sprache, mit einem gr¨oßeren Abstraktionsgrad, mit mehr Flexibilit¨at (dynamisches Schema) und mit
dem Potential zur Anfrageoptimierung an. Die Technologie mußte noch zeigen, daß ihre Funktiona-
lit¨at, ihre Systemanforderungen und im speziellen ihre Performanz ausreichend sind, um unterneh-
mensweite Anwendungssysteme zu entwickeln.
Die Herausforderungen f¨ur WF-Technologie sind ¨ahnlich: Es ist zu untersuchen, welche Funktio-
nalit¨at ben¨otigt wird, um ein breites Spektrum realer WFs unterst¨utzen zu k¨onnen. Außerdem muß
die ben¨otige Performanz erreicht werden. Dabei ist zu untersuchen, wie WF-basierte Informations-
und Anwendungssysteme entwickelt werden k¨onnen, die mehrere Organisationseinheiten (OEen, vgl.
Tabelle 1) umspannen und hunderte oder tausende von Benutzern bedienen (vgl. [KAGM96]). Im
ADEPT-Projekt
werden beide Aspekte betrachtet. In diesem Beitrag konzentrieren wir uns auf den
ADEPT steht f¨ur Application Development Based on Encapsulated Pre-Modeled Process Templates.
Performanzaspekt.
Besonders kritisch f¨ur die Performanz von großen, unternehmensweiten, WF-basierten Anwendungs-
systemen ist die viele Kommunikation, die zwischen dem WF-Server und seinen Klienten notwendig
ist. Oberhalb einer gewissen Schwelle ist der WF-Server alleine durch diese Kommunikation ¨uber-
lastet. Aus diesem Grund wurden in einigen Projekten L¨osungen entwickelt, bei denen sich mehrere
WF-Server diese Last teilen. Aber selbst wenn das Problem der Rechenleistung und Kommunikations-
bandbreite des WF-Servers gel¨ost ist, kann es noch zur ¨
Uberlastung des Kommunikationsnetzwerks
kommen. Da diesem Aspekt bisher wenig Aufmerksamkeit gewidmet wurde, haben wir dieses Pro-
blem n¨aher untersucht. Bei unserem Ansatz wird schon zur Modellierungszeit analysiert, mit welcher
Wahrscheinlichkeit eine Aktivit¨at zur Laufzeit in welchem Teilnetz ausgef¨uhrt werden wird. Eine
WF-Instanz wird nicht mehr nur von einem WF-Server kontrolliert, sondern die Kontrolle der Instanz
migriert von einem WF-Server zum anderen, wenn dies Kommunikation ¨uber Teilnetzgrenzen hinweg
verhindert bzw. reduziert (siehe Abb. 1).
! #"%$'&)(
*,+
$.-/&1032
465879
-/:<;=-:>(
?
-%$
+
&=-/0@(
"
A B
C
-
D
46587E9
-/:<;=-:GF
46587E9
-/:<;=-:IH
&=!:< J"
+
-/:
K
!&10:
++ D+LNM
K
!&10:
++ D+LNM
L
&
CPO
$RQS:"/0$.!&
Abbildung 1 Partitionierung eines WF-Graphen und verteilte WF-Ausf¨uhrung.
Erst Ergebnisse dieser Arbeit wurden in [BD97] ver¨offentlicht. Die konkreten Serverzuordnungen
wurden schon zur Modellierungszeit berechnet. Die Berechnung basiert auf den Wahrscheinlich-
keitsverteilungen (WVen) f¨ur die Aktivit¨atenausf¨uhrung in den einzelnen Teilnetzen (diese werden
wiederum von der Verteilung der Rollen der Benutzer abgeleitet, f¨ur Details siehe [BD97]). Die
(Abschnitts-) Server eines WFs werden also komplett vor dessen Start ermittelt. Deshalb nennen wir
diesen Ansatz ”statisch definierte Migration“, im folgenden kurz ”statische Migration“ genannt. Die
statische Migration f¨uhrt dann zu guten Ergebnissen, wenn Bearbeiterzuordnungen (
TVU1WYX[ZS\#]_^Xa`[b
)
der Art "
cd^=eEeEUgfihJXajak
","
cd^eEeUgfilm,eU!noU1p8XaW8mqksrthuZ%kUSvwe<]_b,nxfzy{|vX=]>XnYvwU
"oder "
T}U1WYX[Z}f
~
XNGTX=vbp8WYbbT}UWX[Zf
~
XN|dXaWbp
"verwendet werden, da in diesen F¨allen die Menge der
potentiellen Bearbeiter (als Voraussetzung f¨ur die Berechnung der Wahrscheinlichkeiten) bereits zur
Modellierungszeit ermittelt werden kann.
In der Praxis gibt es jedoch h¨aufig Bearbeiterzuordnungen, die von anderen Aktivit¨aten abh¨angen
(”abh¨angige Bearbeiterzuordnungen“). So kann z.B. festgelegt sein, daß derselbe Arzt, der einen Pati-
enten untersucht hat (Aktivit¨at
), auch den zugeh¨origen Arztbrief schreiben soll (Nachfolgeraktivit¨at
p8
), oder daß ein Patient von einer Pflegekraft derjenigen OE versorgt werden soll (Aktivit¨at
p
), auf
der er zuvor untersucht wurde (siehe Abb. 2). In diesem Fall steht erst nachdem Aktivit¨at
ausgef¨uhrt
wurde, die OE der Bearbeiter der weiteren Aktivit¨aten (
p
und
p8
) fest. Auch wenn in einer WF-Vorlage
abh¨angige Bearbeiterzuordnungen vorkommen, k¨onnen prinzipiell die besten statischen Serverzuord-
nungen berechnet werden, indem bedingte Wahrscheinlichkeiten verwendet werden. Wenn aber sta-
tische Serverzuordnungen verwendet werden, so kann kein Wissen genutzt werden, das erst bei der
Ausf¨uhrung des WFs entsteht. Genau dies sollte aber bei den Aktivit¨aten
p
und
p
geschehen. Wegen
der abh¨angigen Bearbeiterzuordnung steht bei diesen Aktivit¨aten schon vor ihrer Ausf¨uhrung fest,
Die Berechnung basiert auf der vereinfachenden Annahme, daß sich an den Gr¨oßenordnungen – und damit an den
WVen – bis zur Ausf¨uhrung von Instanzen dieses WF-Typs nichts wesentlich ¨andert.
2
Y8../1=11/==/ %¡s¢£¤¥1¢¦R§%¨G©ª/«1¢§¬¦'¥a§/
®°¯¬±1²w³a´ µ¶
·¸N¹¹R¯»º)¼²<½¿¾
À=ÁÂ8Ã/ÄÅRÆÇ1ÄÈ=ÆÉÊË¿ÉÌ1ÆÇ
ÍÎNÏRÏлÑJÒ¿ÓSÏRÐÔÐ/Õ¿Öw×ÓØ
Ù
ÙqÚÜÛÙqÚÝßÞ°à¬á1âwã=Ýßäå<å
Abbildung 2 Beispiele f¨ur Bearbeiterzuordnungen, die von anderen Aktivit¨aten abh¨angig sind.
aus welcher OE die Bearbeiter stammen werden. Durch den Einsatz von variablen Serverzuordnun-
gen (siehe auch [BD99a, BD99b]) ist es m¨oglich, stets den optimalen WF-Server f¨ur diese Aktivit¨aten
zu verwenden. Anstelle einer einfachen Serverzuordnung der Art "Aktivit¨at
wird vom Server
æ,ç
kontrolliert", werden logische Serverzuordnungsausdr¨ucke verwendet, z.B. "Aktivit¨at
p
wird vom
Server im Domain des Bearbeiters kontrolliert, der Aktivit¨at
ausgef¨uhrt hat". Es wird also Informa-
tion genutzt, die zur Modellierungszeit bzw. beim Starten des WFs noch nicht existiert hat. Statische
Serverzuordnungen sind weniger flexibel. Mit denen ist es lediglich m¨oglich, den WF-Server in einer
festen (m¨oglichst g¨unstigen) OE zu w¨ahlen. L¨auft der WF aber in einer anderen OE, so ist diese Festle-
gung ung¨unstig; bei Verwendung variabler Serverzuordnungen ist sie stets optimal. Die zur variablen
Serverzuordnung ben¨otigten Ausdr¨ucke werden zur Modellierungszeit systemunterst¨utzt ermittelt und
erlauben es, zur Laufzeit auf effiziente Weise den optimalen WF-Server zu bestimmen.
Im n¨achsten Abschnitt werden die Voraussetzungen f¨ur die Anwendbarkeit des Verfahrens gekl¨art.
Abschnitt 3 diskutiert die Problemstellung und m¨ogliche L¨osungsans¨atze. Abschnitt 4 beschreibt die
Algorithmen zum Ermitteln einer optimalen Verteilung. Die Auswirkungen von zusammengesetzten
Bearbeiterzuordnungen – bei denen mehrere Aktivit¨aten z.B. einer Verzweigung referenziert werden
– werden in Abschnitt 5 untersucht. Die Effizienz des Ansatzes wird in Abschnitt 6 mit Hilfe von
Simulationen gezeigt. In Abschnitt 7 werden verwandte Ans¨atze diskutiert. Der Artikel schließt mit
einer Zusammenfassung und einem Ausblick auf weitere Arbeiten.
2 Einbettung und Rahmenbedingungen
Der nachstehend vorgestellte Ansatz beschreibt, wie Lastverteilung mittels variabler Migration in
ADEPT
èé3êëìíéîEïëéðíñ
, der verteilten Variante des ADEPT-Systems, realsiert wird. In der weiteren Dis-
kussion wird lediglich von den folgenden Annahmen ausgegangen:
1. Das WfMS verf¨ugt ¨uber ein Organisationsmodell, in dem Personen sowohl mit OEen in der Auf-
bauorganisation als auch mit Rollen assoziiert werden k¨onnen.
2. Die Zuordnung von Bearbeitern zu einer zur Bearbeitung anstehenden Aktivit¨at erfolgt in
der Regel zur Laufzeit mittels eines Auswahlpr¨adikats, wie z.B. "
cd^eEeU f hJXajak r
ò
XnWbvwóNWYkív^bóUSvb{_USvkôfõcdW`Yv^=e^NnYvíU
". In diesen Bearbeiterzuordnungen k¨onnen auch andere
Aktivit¨aten referenziert werden (abh¨angige Bearbeiterzuordnungen). Ist dies nicht der Fall, so
wird angenommen, daß sich der tats¨achliche Bearbeiter einer Aktivit¨at unabh¨angig von anderen
Aktivit¨aten ergibt. Der Bearbeiter ergibt sich also zuf¨allig aus den potentiellen Bearbeitern einer
Aktivit¨at.
3. Das WfMS verwendet mehrere Teilnetze sowie mehrere WF-Server. Zur Vereinfachung der Dis-
kussion wird angenommen, daß jedes betrachtete Teilnetz ¨uber einen (und nur einen) eigenen
WF-Server verf¨ugt, und daß jeder dieser WF-Server im Prinzip f¨ur jeden WF-Typ und jede WF-
Partition zur Steuerung eingesetzt werden kann. Ein Benutzer des WfMSs (WF-Klient) hat i.d.R.
ein oder mehrere fest zugeordnete Teilnetze.
4. Jeder WF-Server kann alle beim WfMS angemeldeten WF-Klienten bedienen, nicht nur diejeni-
gen, die sich in seinem Teilnetz (Domain) befinden.
3
Name Bedeutung
ö÷¬øù!ú!ûúSùü¬ýYþ ÿ
Anteil der Bearbeiter im Domain (Teilnetz)
ÿ
an der Gesamtheit der Bear-
beiter von Aktivit¨at
, wenn Aktivit¨at
vom Server
kontrolliert wird
úü
8ù!ú
>ý
Bearbeiterzuordnung der Aktivit¨at
ÿ
|÷
Menge der Abh¨angigkeiten
zwischen den Bearbeitern der Aktivit¨aten
des betrachteten WFs
ÿ
"!
=úSûú!ùü
$#&%
ýþ
'( *)$
Wahrscheinlichkeit f¨ur eine Migration zum WF-Server
+'
(beim ¨
Ubergang
von der Aktivit¨at
,
zu
), wenn Aktivit¨at
,
vom WF-Server
*)
kontrolliert
wird
ÿ
ú
-
=ûúSùü ýþ
.
Wahrscheinlichkeit, daß Aktivit¨at
vom Server
kontrolliert wird, wobei
der Bearbeiter
dieser Aktivit¨at vorgegeben ist
/
,
ûú!ùü%ý[þ
02143
Wahrscheinlichkeit, daß Aktivit¨at
vom Server des Teilnetzes
kontrolliert
und von einem Bearbeiter in Teilnetz
3
ausgef¨uhrt wird
5
76
÷
8
Yøýaþ
0
Gesamtgewicht mit der der Bearbeiter
bei der Ausf¨uhrung von Aktivit¨at
gewichtet wird
9
ù
4
°þ
zum Split-Knoten
geh¨orender Join-Knoten
"!
úSûúSùü¬ý
% :
þ
021"3
Wahrscheinlichkeit, daß beim ¨
Ubergang von Aktivit¨at
nach
;
vom Teilnetz
zum Teilnetz
3
migriert werden muß
OE Organisationseinheit
ûú
<>=?@BACDE@BF
1þ
direkte Vorg¨anger von Aktivit¨at k, analog zu
o÷¬÷
$<>=?$@GAC2D@F
!þ
ûú
IH
<>=?@BACDE@BF
þ
(in)direkte Vorg¨anger von k, analog zu
8÷¬÷
7H
<J=?$@GA CDE@BF
þ
ûôù!ø
úü ý
Menge der potentiellen Bearbeiter der Aktivit¨at
ûôù!ø
ú
-K
où!ú
ý
Menge der f¨ur Aktivit¨at
potentiell m¨oglichen Serverzuordnungen
LMN
ö
;O;
ù
6.
þ
1
,
pr¨uft, ob die Aktivit¨at
,
in
ú
-K
où!ú
ý
referenziert werden darf
LMNP
ú
|÷
ö÷øý
Aktivit¨at, die die in
ú
7-Q
8ù!ú
>ý
referenziert wird
LM
;
-
Gøö»÷øý
Aktivit¨aten, die f¨ur eine Referenzierung in
ú
-K
8ù!ú
>ý
geeignet und rele-
vant sind
ú
-
ûúSùü¬ý[þ
Wahrscheinlichkeit, daß Aktivit¨at
vom Server
(in Teilnetz
) kontrolliert
wird
ú
-K
où!ú
>ý
Serverzuordnung der Aktivit¨at
WV Wahrscheinlichkeitsverteilung
;
Eø¬þ
R3
zum Join-Knoten
3
geh¨orender Split-Knoten
o÷¬÷
$<>=?@BACDE@BF
!þ
bezeichnet f¨ur die Aktivit¨at
und die Kantentypen
/
&!
7STVU
WXZYM[
S\L
YM]
/
1
_^[`X
/
1
]aYZY
û
/cb
die Menge der direkten Nachfol-
geraktivit¨aten von
bzgl. der in
/
d!
ES.T7
festgelegten Kantentypen:
W
Akt.
,
e
Kante
\f
þ
1
,
1
d!
ES.T7
mit
&!
7SThgi/
d!
7STdb
o÷¬÷
EH
<>=?@BACDE@BF
þ
bezeichnet die Menge der direkten oder indirekten Nachfolger:
W
Akt.
,
,
g
8÷%÷
<J=?$@GA CDE@BF
þ
kj
þ
e
Tml
,
g
8÷¬÷
<J=?$@GA CDE@BF
þ
T
n
Tmg
o÷¬÷
EH
<>=?$@GAC2D@F
þ
o
b
pcq 7
ú¿ýaþ<ÿ
r
Anzahl der potentiellen Bearbeiter von Aktivit¨at
im Domain
ÿ
, wenn die
Aktivit¨at vom Server
kontrolliert wird
s
1Et
,
1
vu
Abh¨angigkeit: Aktivit¨at
hat denselben Bearbeiter wie die Vorg¨angerakti-
vit¨at
,
s
1Et
,
1
Y
/Zu
Abh¨angigkeit: der Bearbeiter der Aktivit¨at
geh¨ort derselben OE an, wie der
Bearbeiter der Vorg¨angeraktivit¨at
,
Tabelle 1: ¨
Ubersicht ¨uber die verwendeten Abk¨urzungen.
4
5. Die potentiell m¨oglichen Bearbeiter f¨ur eine gegebene Aktivit¨at befinden sich nicht notwendiger-
weise immer im selben Teilnetz.
w
6. Die Anzahl der Personen, die eine bestimmte Aktivit¨at bearbeiten d¨urfen, ¨andert sich zwischen
der Modellierungsphase und der WF-Ausf¨uhrung nicht signifikant.
7. Die Topologie des Kommunikationsnetzwerks ¨andert sich ebenfalls nicht signifikant.
3 Problemstellung
Wie bereits oben erw¨ahnt, ist es das Ziel unseres Ansatzes, Serverzuordnungen zu erhalten, durch
welche die Kommunikationskosten minimiert werden. Dabei soll insbesondere der oben beschriebene
Fall abh¨angiger Bearbeiterzuordnungen ber¨ucksichtigt werden. F¨ur die Zuordnung von WF-Servern
zu Aktivit¨aten gibt es im Prinzip mehrere Vorgehensweisen: Die einfachste und am h¨aufigsten ver-
wendete Methode ist, jeder Aktivit¨at zur Modellierungszeit oder beim Start des WFs fest (statisch)
einen Server zuzuordnen. Wie oben beschrieben wurde, ist diese L¨osung f¨ur WFs mit abh¨angigen
Bearbeiterzuordnungen, welche in der Praxis h¨aufig anzutreffen sind, unbefriedigend. Die besten Ser-
verzuordnungen w¨urde man nat¨urlich erhalten, wenn jeweils nach Beendigung einer Aktivit¨at der WF-
Server f¨ur die Nachfolgeraktivit¨at aktuell bestimmt werden w¨urde. F¨ur diese Auswahl st¨unden dann
die kompletten und aktuellen Laufzeitdaten der WF-Instanz zur Verf¨ugung, so daß der tats¨achlich am
besten geeignete WF-Server bestimmt werden k¨onnte. Leider scheidet diese L¨osung im allgemeinen
aus Aufwandsgr¨unden aus. Das Durchf¨uhren der notwendigen Analysen w¨urden die WF-Server stark
belasten und damit die Performanz des WfMSs beeintr¨achtigen.
x
In ADEPT
èé3êëì/é.îEï1ëé.ðíñ
wird deshalb eine Strategie verfolgt, welche eine statische Vorberechnung (zur
Modellierungszeit) mit dynamischen Aspekten (Ber¨ucksichtigung von Laufzeitdaten) kombiniert und
so im wesentlichen die Vorteile der beiden Vorgehensweisen in sich vereint. Wie schon in Abschnitt 1
beschrieben wurde, werden anstelle einer festen Serverzuordnung bei der Analyse, wo erforderlich
bzw. sinnvoll, logische Serverzuordnungsausdr¨ucke (im folgenden kurz: Serverzuordnungen) erzeugt.
Diese referenzieren die Laufzeitdaten der WF-Instanz und erm¨oglichen so auf einfache (und effizien-
te) Weise eine Festlegung des konkreten WF-Servers zur Laufzeit.
Die Frage ist nun, wie man zu geeigneten variablen Serverzuordnungen f¨ur die Aktivit¨aten kommt.
Eine M¨oglichkeit w¨are, sie bei der Modellierung einfach vorgeben zu lassen (analog zu den Bear-
beiterzuordnungen). Das Problem hierbei ist, daß der WF-Modellierer, ohne weitere Unterst¨utzung
bzw. Information, die durch die Verteilung entstehende Last in den Teilnetzen in der Regel kaum wird
absch¨atzen k¨onnen. Es ist deshalb notwendig, daß er beim Ermitteln von geeigneten Serverzuord-
nungen seitens des WfMSs aktiv unterst¨utzt wird. Das heißt, die WfMS-Modellierungskomponente
muß f¨ur die in Betracht gezogenen Serverzuordnungen die Belastung jeder Systemkomponente (Ser-
ver, Teilnetz, Gateway) geeignet absch¨atzen, so daß m¨ogliche ¨
Uberlastungen entdeckt und vermieden
werden k¨onnen.
F¨ur diese Lastanalyse wird ein Kostenmodell ben¨otigt, das es erm¨oglicht, auszurechnen, f¨ur welche
Komponenten welche Kosten (als gewichtete Summe von ¨
Ubertragungsmenge, Verarbeitungsmenge
etc.) bei der jeweils betrachteten Serverzuordnung entstehen. Dieses Kostenmodell und die Bestim-
mung der Serverzuordnungen werden im n¨achsten Abschnitt beschrieben.
y
W¨are dies immer der Fall, dann w¨are keine variable Migration erforderlich. Alle Entscheidungen k¨onnten bereits zur
Modellierungszeit getroffen werden (statische Migration).
z
Zur Erinnerung: Wir betrachten ”Produktions-WfMSe“ mit potentiell sehr vielen gleichzeitig aktiven WF-Instanzen.
5
4 Ermitteln der Serverzuordnungen
Im folgenden wird der Zweck von abh¨angigen Bearbeiterzuordnungen ausf¨uhrlich erl¨autert und es
beschrieben, wie zur Modellierungszeit die optimale Verteilung der Aktivit¨aten einer WF-Vorlage auf
WF-Server berechnet werden kann. Insbesondere wird auf die Bestimmung der Kosten und der WVen
eingegangen.
4.1 Abh¨
angige Bearbeiterzuordnungen
In der Einleitung wurde schon ein Beispiel f¨ur die Verwendung von abh¨angigen Bearbeiterzuordnun-
gen beschrieben. In diesem Abschnitt wird nun genauer erl¨autert, warum abh¨angige Bearbeiterzu-
ordnungen ben¨otigt werden und welche Ausdr¨ucke daf¨ur in Frage kommen. Außerdem wird gezeigt,
wie – auch bei mehrstufigen abh¨angigen Bearbeiterzuordnungen – schon zur Modellierungszeit die
potentiellen Bearbeiter einer Aktivit¨at
p
berechnet werden k¨onnen.
4.1.1 Einsatz abh¨
angiger Bearbeiterzuordnungen
In vielen Anwendungen sind f¨ur bestimmte Aktivit¨aten zwar prinzipiell Mitarbeiter aus verschiedenen
OEen zust¨andig; f¨ur eine bestimmte WF-Instanz sind aber doch nur Mitarbeiter aus einer bestimmten
OE zust¨andig. So werden bei einem Kreditantrag Arbeitsschritte, wie die Kundenbefragung, zwar
von Angestellten aller Filialen ausgef¨uhrt; f¨ur einen konkreten Vorgang sind aber nur Angestellte
der Filiale zust¨andig, in der der Kunde den Antrag gerade stellt. Abb. 3 zeigt ein Beispiel aus dem
Krankenhausbereich: Ein Patient wird in die Ambulanz eingeliefert und danach von einer Pflegekraft
einer a priori unbekannten Station aufgenommen (Aktivit¨at 1). Ab diesem Zeitpunkt ist nur noch
Personal dieser Station f¨ur den Patienten zust¨andig (Aktivit¨at 2-4).
{P|$}0~(}
(}$o
K
$
4$QE
K
BE~Q
{P|$}0~(}
K
sQBE~R}
2&
2(0(&
a¡£¢
¤P¥"¡E¦¡$§d¨©E¥Oª «¬
¢
«¬>®0¯
¡E©$¨s°
®2±²s²
Ù
³a´µ¶µ·£¸º¹.»G¼½ ¾
·E¿»sÀQ·7Á½·»ÃOÄÅ
ÆÇ
¸
ÆÇ
Ã
¾
·E¿»"ÀQÃÈ2Å"Å
Ù
ÉaÊ˶ËÌ£ÍÏÎPÐ"ËÌ7ÑdÌ$ÒÓBÔEÐOÕ
Abbildung 3 Beispiel f¨ur einen WF mit abh¨angigen Bearbeiterzuordnungen.
Damit eine abh¨angige Bearbeiterzuordnung von Aktivit¨at
p
zur Ausf¨uhrungszeit ¨uberhaupt aufgel¨ost
werden kann, d¨urfen nur Aktivit¨aten referenziert werden, die vor
p
ausgef¨uhrt werden (Vorg¨angerakti-
vit¨aten). Aus Abb. 3 lassen sich die folgenden Typen von teilweise abh¨angigen Bearbeiterzuordnungen
ermitteln:
Ö
T}UWX[Z!\#]q^NXa`Yb
×
f
unabh¨angiger Ausdruck
z.B. "Rolle = Arzt"oder "
cd^=eEeUJf lm,eUSn8U1p8XaWomqk,rghuZk/Uve]>b,n}f y{GvX]_XnYvwU
"
Ö
T}UWX[Z!\#]q^NXa`Yb
×
f
"
T}UWX[Z
(Ø
_Ù
"
Aktivit¨at
p
soll vom selben Bearbeiter ausgef¨uhrt werden wie Aktivit¨at
Ö
T}UWX[Z!\#]q^NXa`Yb
×
f
"
ò
ÛÚ
f
ò
ÜÚ
Ø
ET}UWX[Z
(Ø
_ÙÙ
°rSS
"
Der Bearbeiter von Aktivit¨at
p
soll derselben OE angeh¨oren, wie der von Aktivit¨at
. Des weite-
ren soll er irgendwelche weiteren Kriterien erf¨ullen.
Manchmal werden auch Bearbeiterzuordnungen ben¨otigt, die von WF-Daten abh¨angig sind. Ein Bei-
spiel hierf¨ur ist eine Untersuchung, bei der die ausf¨uhrende OE von der Untersuchungsart abh¨angig
6
ist:
T}UWX[Z!\#]q^NXa`Yb
×
df
"
ØoÝ
JbkUSX[ó1]
JÞ
S{G]_b,n8ó1WX=k»f
R¨
ontgen:
ò
ÛÚ
f cdW8`[v^=eE^NnYvwU)rgcd^=eEeUf
àßâá
Jh
ÛÙ
°
ØoÝ
JbkUSX[ó1]
JÞ
S{G]_b,n8óNWYX=kf
Endoskopie:
ò
ÛÚ
f y{GvX]_XnYvwUrcd^=eEeUJf hJXajak
$Ù
". Allgemein haben solche
Bearbeiterzuordnungen die Form:
Ö
T}UWX[Z!\#]q^NXa`Yb
×
f
"
T}U`Yvb,nY]>b,n>
ã
[T}UWXaZS\#]_^Xa`[bI6T}U`Yvb,nY]_b,n
ã
YT}UWX[ZS\)]q^X=`Yb SS
"
Außer diesen Typen von Bearbeiterzuordnungen sind auch noch weitere denkbar, auf die im folgenden
aber nicht detailliert eingegangen wird. So kann z.B. die folgende Bearbeiterzuordnung verwendet
werden, um ein 4-Augen-Prinzip zu realisieren:
Ö
T}UWX[Z!\#]q^NXa`Yb
×
f
"
T}UWX[Z
åä
f TVU1WYX[Z
IØ
æÙ\ç
'r
ò
ÜÚ
f
ò
ÜÚ
Ø
ET}UWX[Z
(Ø
_ÙÙè
rSS
"
Die Bearbeiter der Aktivit¨aten
und
p
sollen nicht identisch sein und evtl. derselben OE an-
geh¨oren. Die Auswahl des Bearbeiters von Aktivit¨at
p
kann noch durch weitere Kriterien einge-
schr¨ankt werden.
Soll die Aktivit¨at
p
vom Vorgesetzten des Bearbeiters der Aktivit¨at
ausgef¨uhrt werden, so ergibt
sich die folgende Bearbeiterzuordnung:
Ö
T}UWX[Z!\#]q^NXa`Yb
×
f
"
é
^XNnoU1óUSk/jak/UX
Ø
ETVU1WYX[Z
IØ
æÙÙ
"
Je nach Anwendung sind auch noch weitere Typen von Bearbeiterzuordnungen denkbar.
4.1.2 Potentielle Bearbeiter einer Aktivit¨
at
Bei unabh¨angigen Bearbeiterzuordnungen (z.B.
T}UWX[Z!\#]q^NXa`Yb
×
f
"
cd^=eEeEU f hJX=j[k
") kann die Men-
ge der potentiellen Bearbeiter von Aktivit¨at
p
direkt aus der
T}UWXaZS\#]_^Xa`[b
×
ermittelt werden, indem
f¨ur alle Benutzer des WfMSs gepr¨uft wird, ob sie die entsprechende Bedingung
T}UWX[ZS\)]q^X=`Yb
×
erf¨ullen. Dies ist bei abh¨angigen Bearbeiterzuordnungen nicht direkt m¨oglich. So hat die Aktivit¨at 3
in Abb. 3 die
T}UWX[ZS\)]q^X=`Yb
w
f
"
TVU1WYX[Z
IØGêQÙ
", woraus nicht direkt auf die potentiellen Bearbeiter von
Aktivit¨at 3 geschlossen werden kann.
Da die Menge der potentiellen Bearbeiter einer Aktivit¨at h¨aufig relevant ist, soll ein Algorithmus
entwickelt werden, der es erm¨oglicht, diese Menge zu berechnen. Eine einfache M¨oglichkeit ist, f¨ur
alle Aktivit¨aten des WFs sukzessive (d.h. in einer Reihenfolge entsprechend dem Kontrollfluß) diese
Menge
l^k/T}UWXaZ
7×
zu berechnen (siehe Algorithmus 1). St¨oßt man dabei auf eine abh¨angige Be-
arbeiterzuordnung, so wird aus der Menge
l^k/TVU1WYX[Z
Eë
der Bearbeiter der referenzierten Aktivit¨at
die Menge der Bearbeiter der referenzierenden Aktivit¨at
p
berechnet. So erh¨alt man z.B. bei der
T}UWX[Z!\#]q^NXa`Yb
×
Jf
"
é
^NXn8UNóNUkíj[k/UX
+Ø
ET}U1WYX[Z
IØ
æÙÙ
"die Bearbeiter der Aktivit¨at
p
, indem man die Men-
ge der Bearbeiter
]
der Aktivit¨at
durchl¨auft und f¨ur jeden Benutzer
]
pr¨uft, ob er die Bearbeiter-
zuordnung erf¨ullt, unter der Annahme, daß
]
die Aktivit¨at
bearbeitet hat. Die WF-Vorlage wird in
partieller Ordnung durchlaufen und in Bearbeiterzuordnungen k¨onnen nur Vorg¨angeraktivit¨aten refe-
renziert werden. Deshalb ist dem Algorithmus zu dem Zeitpunkt, wenn
l^kíT}UWX[Z
7×
berechnet wird,
l^k/TVU1WYX[Z
Eë
schon bekannt.
Der große Vorteil von Algorithmus 1 ist, daß keine Fallunterscheidung f¨ur die verschiedenen Arten
von abh¨angigen Bearbeiterzuordnungen ben¨otigt wird. Deshalb bleibt der Algorithmus unver¨andert,
auch wenn weitere abh¨angige Bearbeiterzuordnungen ben¨otigt werden. Es muß lediglich m¨oglich
sein, zu pr¨ufen, ob sich ein Benutzer
]
als Bearbeiter von Aktivit¨at
p
qualifiziert, wenn der Bear-
beiter
]
der referenzierten Aktivit¨at
bekannt ist. Dies ist genau die Funktionalit¨at, die auch das
WfMS ben¨otigt, wenn vor der Ausf¨uhrung der Aktivit¨at
p
die m¨oglichen Bearbeiter ermittelt werden
m¨ussen. Der Algorithmus hat aber auch zwei Nachteile. Erstens m¨ussen in einem großen WfMS, mit
sehr vielen Benutzern, f¨ur jede Aktivit¨at große Mengen verwaltet werden. Zweitens m¨ussen diese
Mengen neu berechnet werden, wenn sich die Menge der Benutzer des WfMSs oder deren Rollen-
7
Algorithmus 1 (Berechnung von
ìîí*ïðòñ+ó£ô*õ÷ö
als Menge)
for each Aktivit¨at
g
Prozeßvorlage (in partieller Ordnung entsprechend Kontrollfluß) do
ûôù!ø
úü¬ý
f
W
b
;
case
úSü
E
où!ú
d
>ý
unabh¨angig:
for each Benutzer
do
if
erf¨ullt
º
úü
où!ú
>ý
then
ûôù!ø
úSü%ý
f
ûôù!ø
úü¬ý
ùø
W
b
;
case
úSü
E
où!ú
d
ý
referenziert Aktivit¨at
,
:
for each Benutzer
)
g
ûôù!ø
úSü
$#
do
for each Benutzer
'
do
if
'
erf¨ullt
úü
où!ú
d
ý
, falls
)
die Aktivit¨at
,
bearbeitet hat then
ûôù!ø
º
úü ý
f
ûôù!ø
úü ý
ø
W
'
b
;
oder OE-Zuordnung ¨andert. Deshalb haben wir den Algorithmus 2 entwickelt, der diese Nachteile
vermeidet. Er bietet damit eine elegante M¨oglichkeit, die Menge der potentiellen Bearbeiter einer Ak-
tivit¨at zu berechnen. Dazu wird f¨ur jede Aktivit¨at
p
ein Ausdruck
l^k/TVU1WYX[Z
7×
berechnet, der diese
Menge beschreibt. Dabei werden die im vorherigen Abschnitt aufgef¨uhrten Bearbeiterzuordnungen
ber¨ucksichtigt; f¨ur weitere evtl. ben¨otigte Typen von Bearbeiterzuordnungen kann er entsprechend
erweitert werden. Der Algorithmus ermittelt aus der Bearbeiterzuordnung der Aktivit¨at
p
und den
potentiellen Bearbeitern der referenzierten Aktivit¨at
(
l^kíT}U1WYX[Z
Eë
) die potentiellen Bearbeiter der
Aktivit¨at
p
(
l^Nk/T}UWX[Z
E×
).
Algorithmus 2 (Berechnung von
ìîí*ïðòñ+ó£ô*õ÷ö
als Ausdruck)
for each Aktivit¨at
g
Prozeßvorlage (in partieller Ordnung entsprechend Kontrollfluß) do
ûôù!ø
úü ý
f
ûôù!ø
º7
úü
/
ú
úk
Eøø
;
°þ
º7
úü
8ù!ú
ý
;
ûåüý$þiÿ
2ý2ýÿ
þiÿ
£ü
:
case
úSü
E
où!ú
d
unabh¨angig:
return
úSü
E
où!ú
d
;
case
úSü
E
où!ú
d
f
"
º
úüSþ
,
":
return
ûôù!ø
úSü
#
;
case
úSü
E
où!ú
d
f
"
Y
/ f
Y
/
þ
º
úüSþ
,
o_n
Pr¨
adikat":
return
Y
/ g
WY
/
þ ûôù!ø
º7
úü
#
b
n
Pr¨
adikat;
case
úSü
E
où!ú
d
f
"
º
4P!( P!
l
úSü
E
où!ú
d
":
ûôù!ø
úü
f
"";
for each
do
ûôù!ø
úSü
f
ûôù!ø
úü
j
ûôù!ø
º
úü
/
ú
7úk
Eøø
;
°þ
º
úü
où!ú
;
return
ûôù!ø
úSü
;
Mit Hilfe von
l^k/T}UWXaZ
7×
l¨aßt sich f¨ur jeden Benutzer
]
pr¨ufen, ob er sich als Bearbeiter von Akti-
vit¨at
p
qualifiziert.
ç
Dadurch kann auch bei Verwendung von abh¨angigen Bearbeiterzuordnungen die
Menge der f¨ur die Ausf¨uhrung von Aktivit¨at
p
in Frage kommenden Benutzer ermittelt werden. Wie
in Kapitel 3 beschrieben wurde, lassen sich damit – wie bei unabh¨angigen Bearbeiterzuordnungen
– die besten statischen Serverzuordnungen berechnen. Da in diese Berechnung nur die Gesamtmen-
ge der potentiellen Bearbeiter der Aktivit¨aten einfließt (und nicht die Menge der Bearbeiter, die sich
Wir schreiben dann im folgenden vereinfachend
!#"%$'&)(+*-,/.103254
, egal ob es sich bei
$'&6(*,/.103254
um eine mit Al-
gorithmus 1 berechnete Menge oder um einen mit Algorithmus 2 berechneten Ausdruck handelt. Im letzteren Fall w¨are
eigentlich die Schreibweise
!
erf¨ullt
$'&6(*,6.10)2/4
korrekt.
8
tats¨achlich f¨ur eine Aktivit¨ateninstanz qualifizieren), gehen die Abh¨angigkeiten zwischen den Akti-
vit¨aten verloren. Deshalb f¨uhrt diese Vorgehensweise zu einem unzul¨anglichen Ergebnis und wird
nicht weiter verfolgt. Allerdings wird
l^Nk/T}UWX[Z
E×
von mehreren in diesem Beitrag vorgestellten Al-
gorithmen ben¨otigt. In diesen Algorithmen werden alle potentiellen Bearbeiter einer Aktivit¨at durch-
laufen und dabei jeweils die Beziehung zu der referenzierten Aktivit¨at
ber¨ucksichtigt.
4.2 Kostenmodell
Ein Kostenmodell zur Berechnung der Kosten bzw. zur Bestimmung der Last f¨ur die unter
Performanz-Aspekten kritischen Komponenten des WfMSs (Server, Teilnetz, Gateway) muß zumin-
dest die folgenden Kosten ber¨ucksichtigen:
Ö
Kosten f¨ur den Parametertransfer beim Starten und Beenden von Aktivit¨atenprogrammen
Ö
Kosten f¨ur das Aktualisieren von Arbeitslisten
Ö
Migrationskosten
Ö
Kosten f¨ur die Kommunikation von Aktivit¨atenprogrammen mit externen Datenquellen
Zus¨atzlich zu den bereits im WF- und Organisationsmodell vorhandenen (relativ statischen) Infor-
mationen werden je Aktivit¨at die gesch¨atze Ausf¨uhrungsh¨aufigkeit und die im Mittel zu kommuni-
zierende Datenmenge ben¨otigt. F¨ur bereits freigegebene WF-Typen k¨onnen diese Daten durch die
Analyse von Audit Trails ausgef¨uhrter WF-Instanzen gewonnen werden. Andernfalls m¨ussen diese
Daten gesch¨atzt werden.
Bezeichne im folgenden
Ú
_ldXa^aZ
7× Ø
v
)798
Ù
die Wahrscheinlichkeit, daß Aktivit¨at
p
vom Server in Teil-
netz
v
kontrolliert und von einem Benutzer in Teilnetz
8
bearbeitet wird.
ß
vnX=lX=^aZ
7×
: ;
BØ
v
6798
Ù
sei die
Wahrscheinlichkeit, daß beim ¨
Ubergang von Aktivit¨at
p
nach
e
von Server
v
nach
8
migriert werden
muß.
<
Ý
uóUSX
d× Ø
=8>
v
Ù
sei die Anzahl der potentiellen Bearbeiter von Aktivit¨at
p
im Teilnetz
8
, wenn
diese Aktivit¨at vom Server im Teilnetz
v
kontrolliert wird. Diese Matrizen h¨angen von den gew¨ahlten
Serverzuordnungen ab. Wie sie bestimmt werden k¨onnen, wird sp¨ater gezeigt. F¨ur den Moment wol-
len wir sie als gegeben betrachten. Im folgenden werden Formeln entwickelt, die das anfallende bzw.
zu transportierende Datenvolumen f¨ur jede Aktion (Aktivit¨at ausf¨uhren, Migration, ...) beschreiben,
und zwar getrennt f¨ur jede Komponente des WfMSs. Diese Formeln werden anschließend in eine
Gesamtformel eingesetzt, mit der die in einer Komponente entstehende Last berechnet werden kann.
4.2.1 Aktivit¨
atenausf¨uhrung
Der Erwartungswert f¨ur das Datenvolumen (im folgenden kurz: Datenvolumen) bei der Aktivit¨aten-
ausf¨uhrung (Transport der Ein- und Ausgabeparameterdaten) berechnet sich wie folgt: Das Datenvo-
lumen, das an Server
v
f¨ur die Ausf¨uhrung von Aktivit¨at
p
entsteht, ergibt sich als Wahrscheinlichkeit,
daß Server
v
die Aktivit¨at
p
kontrolliert, multipliziert mit der zu transportierenden Datenmenge:
é
^e
+?
×
¿ë
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
Pf
DCFEHG
Ú
qldXa^=Z
7×PØ
v
6798
Ù
JILK
֯
vb
M
_WYXaWÜUSkUSX ó1vjYU
d×
ON
^N]_k
M
_WXaWYÜUk/UX óvwjYU
&×KÙ
Die Belastung f¨ur die Teilnetze ergibt sich folgendermaßen: Im Teilnetz
v
findet Kommunikation statt,
wenn entweder der Server in
v
liegt oder wenn ein Bearbeiter aus Teilnetz
v
gew¨ahlt wird. Trifft beides
zu, so wird die Kommunikation nur einmal gez¨ahlt (deshalb
8
ä
f v
):
é
^e
+?
×
¿ë
PRQ
:
é
Ø
p
Ù
f
CSE G
Ú
_ldXa^aZ
7×Ø
v
6798
Ù
TN
E
GU
V
é
Ú
qldXa^=Z
7×PØ
=87
v
Ù
I
K
OØ
vb
M
_WXaWYÜUk/UX óvwjYU
&×
N
^]>k
M
qWYXaWÜUSkUSX ó1vjYU
d×IÙ
9
Das anfallende Datenvolumen am Gateway von Teilnetz
v
nach
8
(
v
ºä
f
W8
) ergibt sich wie folgt:
é
^e
+?
×
¿ë
XZY
:
é
[:
G
Ø
p
Ù
Pf
Ú
_ldXa^aZ
7×Ø
v
6798
Ù
\K
Svb
M
_WXaWYÜUk/UX óvwjYU
&×
]N
Ú
qldXa^aZ
E×PØ
=87
v
2Ù
'K
^]>k
M
qWYXaWÜUSkUSX ó1vjYU
d×
4.2.2 Aktualisieren der Arbeitslisten
Die Berechnung der Datenvolumina f¨ur das Aktualisieren der Arbeitslisten ist etwas problematisch.
Dies liegt u.a. daran, daß f¨ur das Aktualisieren verschiedene Verfahren verwendet werden k¨onnen
(siehe [BD98]), aus denen unterschiedliche Kosten resultieren. Die Klienten k¨onnen ihre Arbeitsli-
sten bei den Servern erfragen (Polling) oder die Server propagieren eine ¨
Anderung automatisch an die
betroffenen Klienten. Eine Variante des zweiten Verfahrens ergibt sich, wenn Mindestzeitabst¨ande f¨ur
¨
Ubertragungen zum selben Klienten eingehalten werden und mehrere ¨
Anderungen zusammengefaßt
werden. Dadurch wird die Anzahl der ¨
Ubertragungen reduziert. Bei der Absch¨atzung der Datenvo-
lumina muß außerdem ber¨ucksichtigt werden, daß es relevant ist, ob bei jeder Aktualisierung die
gesamte Arbeitsliste oder nur neu hinzugekommene oder entfernte Eintr¨age ¨ubertragen werden.
Im folgenden wird das Verfahren analysiert, bei dem jede ¨
Anderung sofort an alle betroffenen Kli-
enten propagiert wird. F¨ur die anderen Verfahren sind ¨ahnliche Absch¨atzungen denkbar. Allerdings
h¨angen die Kosten dann nicht nur von der WF-Ausf¨uhrung ab, sondern z.B. auch davon, wie schnell
verschiedene ¨
Anderungen aufeinander folgen, so daß sie zusammengefaßt werden k¨onnen. Außerdem
ist dann relevant, wie schnell ein neuer Eintrag von einem Bearbeiter
]
ausgew¨ahlt wird, so daß der
Arbeitsschritt schon vor der n¨achsten Arbeitslistenaktualisierung eines anderen Bearbeiters
]
nicht
mehr verf¨ugbar ist. Dies f¨uhrt dazu, daß der Eintrag nie an diesen Bearbeiter
]
¨ubertragen wird.
Aufgrund dieser Aspekte sind solche Absch¨atzungen aufwendig und ungenau. Eine M¨oglichkeit dem
zu begegnen ist, die Kosten vom Modellierer manuell absch¨atzen oder ¨uberarbeiten zu lassen. Aller-
dings lohnt sich dieser Aufwand kaum, da Arbeitslisten-Eintr¨age relativ klein sind. Die durch ihren
Transfer entstehenden Datenvolumina sind im Vergleich zum Parametertransfer und den Migrationen
fast vernachl¨aßigbar. Deshalb ist die im folgenden beschriebene Berechnungsmethode v¨ollig ausrei-
chend. Wird ein anderes (optimiertes) Verfahren zum Aktualisieren der Arbeitslisten verwendet, so
wird durch die beschriebene Absch¨atzung eine obere Schranke f¨ur die entstehenden Datenvolumina
ermittelt. Dies gilt, weil das aufwendigste Verfahren analysiert wird, bei dem jede ¨
Anderung sofort
an alle betroffenen Clients propagiert wird. Um realistischere Ergebnisse zu erhalten, k¨onnen die be-
rechneten Werte noch mit einem vom Modellierer vorzugebenen Faktor
(
^L_
`_ba
) multipliziert
werden. Wenn die Kosten f¨ur Arbeitslisten-Aktualisierungen im Vergleich zu den anderen Kosten
besonders klein sind, kann es sogar Sinn machen, sie v¨ollig zu ignorieren (
f
c^
).
Der WF-Server
v
muß Arbeitslisten aktualisieren, wenn Aktivit¨at
p
durch ihn kontrolliert wird; un-
abh¨angig davon in welchem Teilnetz
8
der sp¨atere Bearbeiter angesiedelt ist. Um die Anzahl der
Benutzer, deren Arbeitslisten aktualisiert werden m¨ussen, zu erhalten, werden die potentiellen Bear-
beiter aller Teilnetze
zusammengez¨ahlt. Das Datenvolumen, das bei einem einzigen Einf¨ugen und
sp¨ateren L¨oschen eines Arbeitslisteneintrags f¨ur Aktivit¨at
p
¨ubertragen wird, ist
dbe
vbóUSX=k ó1vjYU
&×
und
dbe
`U1eUSkU óvwjYU
&×
. Dies kann die Gr¨oße eines Eintrags oder der gesamten Arbeitsliste sein, je
nachdem ob stets die gesamte Arbeitsliste oder nur die ¨
Anderungen ¨ubertragen werden. Das Daten-
volumen f¨ur den WF-Server ergibt sich damit als:
é
^e
+?Rf
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
Pf
EG
Ú
qldXa^aZ
E× Ø
v
6798
Ù
\K
E g
<
Ý
uóUSX
d× Ø
h>
v
Ù
iK
Ø
jdbe
vbóUSX=k ó1vjYU
&×
Nkdbe
`U1eUSkU óvjU
&×QÙ
Im Teilnetz
v
findet Kommunikation statt, wenn Server
v
Arbeitslisten aktualisiert oder wenn ein be-
liebiger anderer Server
e
die Arbeitsliste eines Bearbeiters aus Teilnetz
v
aktualisiert:
10
é
^e
?Rf
PRQ
:
é
Ø
p
Ù
f
CEG
Ú
_ldXa^aZ
7×Ø
v
6798
Ù
\KE g<
Ý
dóNUX
d×Ø
h>
v
Ù
lNbE
;
U
V
é
K3E G
Ú
qldXa^=Z
7× Ø
Ee
m798
Ù
'K<
Ý
dóNUX
d×PØ
v
n>
e
BÙ
I
K
+Ø
jdbe
vbóNUXk ó1vjYU
d×
Nkdbe
`8UeUSkU ó1vjYU
d×IÙ
Im Gateway von Teilnetz
v
nach
8
entsteht Datentransfer, wenn der Server in Teilnetz
v
die Arbeitsliste
eines Benutzers aus Teilnetz
8
aktualisiert. Auch hier ist nur die Wahrscheinlichkeit relevant, mit der
der Server
v
die Aktivit¨at kontrolliert, unabh¨angig davon in welchem Teilnetz
e
sie sp¨ater bearbeitet
wird:
é
^e
+?Rf
XZY
:
é
[:
G
Ø
p
Ù
Pf
E
;
Ú
qldXa^=Z
7× Ø
v
67
¬e
BÙ
'K<
Ý
dóNUX
d× Ø
h>
v
2Ù
iK
֯
jdbe
vbóNUX=k óvjU
&×
]Nkdbe
`8UeUSkU ó1vjYU
d×IÙ
4.2.3 Kommunikation mit externen Datenquellen
Aktivit¨atenprogramme, die auf dem Rechner des Klienten laufen, k¨onnen mit externen Datenquellen
(z.B. Datenbanken) kommunizieren. Um die daraus resultierenden Kosten ber¨ucksichtigen zu k¨onnen,
m¨ussen die durchschnittlichen Ein- und Ausgabedatenmengen
Ú
>k vb
× Ø
=8
Ù
und
Ú
_k ^]>k
2×Ø
=8
Ù
vorge-
geben (modelliert) werden, die Aktivit¨at
p
mit Datenquellen in Teilnetz
8
austauscht. Dem WF-Server
entsteht durch solche Kommunikationen kein Aufwand, da die Daten direkt zwischen Teilschrittpro-
gramm und Datenquelle fließen:
é
^e
+o
ë
ë
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
Pf
c^
Im Teilnetz
8
findet Kommunikation zu allen Datenquellen
e
statt, wenn der Klient im TN
8
liegt
(unabh¨angig vom Ort
v
des Servers). Außerdem wird das Teilnetz
8
belastet, wenn die Datenquelle
von Aktivit¨at
p
im Teilnetz
8
liegt und der Klient in irgendeinem anderen Teilnetz
e
:
é
^e
+o
ë
ë
PRQ
:
G
Ø
p
Ù
Pf
pE
é
Ú
qldXa^aZ
E×PØ
v
6798
Ù
'KqE
;
Ø
Ú
>k vb
×Ø
Ee
BÙ
rN
Ú
>k ^N]_k
× Ø
Ee
BÙÙ
NE
é
KE
;
U
V
G
Ú
_ldXa^aZ
7× Ø
v
)7
¬e
GÙ
'K
Ø
Ú
_k vb
×Ø
=8
Ù
lN
Ú
>k ^]_k
× Ø
=8
ÙÙ
Von Teilnetz
v
nach
8
fließen Eingabedaten, wenn sich die Datenquelle in
v
und der Klient in
8
befindet,
und Ausgabedaten, wenn der Klient in Teilnetz
v
und die Datenquelle in
8
ist:
é
^e
+o
ë
ë
XZY
:
é
[:
G
Ø
p
Ù
Pf
sE
;
Ú
qldXa^=Z
7× Ø
Ee
m798
Ù
'K
Ú
>k vb
×PØ
v
Ù
rNtE
;
Ú
_ldXa^aZ
7×Ø
Ee
J7
v
Ù
'K
Ú
>k ^]_k
×PØ
=8
Ù
Die Kosten, die durch Kommunikation der Anwendungsprogramme mit externen Datenquellen entste-
hen, sind unabh¨angig von der gew¨ahlten Serverzuordnung, da die Server in diesen Datentransfer nicht
involviert sind. Sie h¨angen aber von der Wahl der Teilnetze f¨ur die Benutzer und f¨ur die Datenquellen
ab, die mit Hilfe dieser Kostenabsch¨atzung optimiert werden kann. Auch wenn der Modellierer bei
dieser Festlegung meist nur wenig Entscheidungsfreiheit hat, m¨ussen die durch die gew¨ahlte Vertei-
lung entstehenden Kosten bei der Analyse ber¨ucksichtigt werden, um die im Netzwerk entstehende
Last absch¨atzen zu k¨onnen.
4.2.4 Migrationen
Von besonderem Interesse sind in dem betrachteten Kontext nat¨urlich die Migrationskosten beim
¨
Ubergang von Aktivit¨at
p
nach
e
. Hierbei m¨ussen sowohl ein- wie auch ausgehende Migrationen
ber¨ucksichtigt werden. Dabei ist zu beachten, daß keine Kommunikation stattfindet, wenn die Server
f¨ur Aktivit¨at
p
und
e
identisch sind (deshalb:
8
ä
f v
). Um die f¨ur Server
v
erwartete Datenmenge zu
berechnen, wird das bei dieser Migration zu transportierende Datenvolumen mit der Wahrscheinlich-
keit, daß diese Migration den Server
v
betrifft, multipliziert:
é
^e
u
é
wv
“
@A
ì
5B
A
ì
5:
é
Ø
p
R7
¬e
BÙ
Pf
xE
GU
V
é
C
ß
vnYXaldXa^aZ
7×
: ;
BØ
v
6798
Ù
iN
ß
vnYXaldXa^aZ
E×
: ;
BØ
=87
v
Ù
JIyK
S vnX=Wkív^b ó1vjYU
d×
z: ;
11
Das durch die Migration verursachte Datenvolumen in den betroffenen Teilnetzen ist genau so groß
wie bei den Servern:
é
^e
u
é
wv
“
PRQ
:
é
Ø
p
R7
¬e
BÙ
Pf
âé
^=e
u
é
wv
“
@A
ì
5B
A
ì
5:
é
Ø
p
R7
¬e
BÙ
.
Die Gateways m¨ussen hierbei die folgenden Datenmengen transportieren:
é
^e
u
é
wv
“
XZY
:
é
[:
G
Ø
p
R7
¬e
BÙ
Pf
ß
vnYXaldXa^aZ
E×
: ;
Ø
v
)798
Ù
'K
S vnYXaWYkív^b ó1vjYU
d×
: ;
4.2.5 Gesamtkosten
F¨ur jede Systemkomponente m¨ussen diese Datenmengen noch mit den Ausf¨uhrungsh¨aufigkeiten der
einzelnen Aktivit¨aten
{
^=`8UdX[U
1|
+Ø
p
Ù
bzw. der Kanten
Ú
`anoUdX[U
1|
+Ø
p
R7
¬e
BÙ
multipliziert und f¨ur alle Ak-
tivit¨aten aller WF-Typen (
d
á
}zM
qUNó
) aufaddiert werden, um die entsprechende Last dieser Kom-
ponente zu bestimmen. Die dabei berechneten Werte k¨onnen verwendet werden, um zu ¨uberpr¨ufen,
ob die entsprechende Komponente ¨uberlastet sein wird. F¨ur die Server ergibt sich die Last wie folgt
(
e
^=W8`
PRQ
:
é
und
e
»^W8`
XZY
:
é
[:
G
analog):
e
^=W8`
@A
ì
5B
A
ì
5:
éf
E
~q
Yy Pm A
ê
E
×
~Z
C
{
^=`U1dX[U
1|
+Ø
p
Ù
'K
é
^=e
+?
×
¿ë
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
N{
^=`U1dX[U
1|
+Ø
p
Ù
iK
(é
^=e
?Rf
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
N{
^=`U1dX[U
1|
+Ø
p
Ù
iK
(é
^=e
o
ë
ë
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
NE
;
~Z1
;
U
V
×
Ú
`an8U1dX[U
1|
+Ø
p
R7
¬e
BÙ
\K
é
^=e
u
é
v
%ì
@A
ì
5B
A
ì
5:
é
Ø
p
R7
¬e
BÙ
I
Verz¨ogerungen bei den verschiedenen Aktionen eines WfMSs werden von den Benutzern unterschied-
lich stark wahrgenommen. So bemerkt ein Benutzer nicht, wenn eine Migration lange dauert, da er
bei dieser Aktion nicht auf eine Antwort des Systems wartet. Anders verh¨alt es sich, wenn er ei-
ne Aktivit¨ateninstanz aus seiner Arbeitsliste ausgew¨ahlt hat und auf den Start des entsprechenden
Aktivit¨atenprogramms wartet. Da daf¨ur die Eingabeparameter vom WF-Server zu seinem Rechner
transportiert werden m¨ussen, wird hier eine langsame (weil weit entfernte) Verbindung zum WF-
Server als besonders unangenehm empfunden. Eine M¨oglichkeit diesen Sachverhalt zu ber¨ucksich-
tigen, ist, die vorherige Formel wie nachfolgend angegeben abzuwandeln und die Kosten f¨ur den
Transfer von Eingabedaten von Aktivit¨atenprogrammen mit einem Faktor
?
×
¿ë
ya
zu gewichten
(
?Rf
f
o
ë
ëf
u
é
wv
“ f
a
). Dadurch wird erreicht, daß z.B. Migrationskosten vergleichsweise
weniger ins Gewicht fallen, weshalb die WF-Server tendenziell n¨aher bei den Bearbeitern der Akti-
vit¨aten gew¨ahlt werden. Dadurch verringern sich diese bewußt wahrgenommenen Wartezeiten. Die
”Last“ f¨ur den WF-Server
v
(
e
^=W`Y
PRQ
:
é
und
e
^=W8`[
XZY
:
é
[:
G
analog) ergibt sich damit als:
e
^=W8`[
@A
ì
5B
A
ì
5:
é
f
E
~q
Yy Pm A
ê
E
×
~Z
C
?
×
¿ë
ZK1{
^=`UXaU
z|
+Ø
p
Ù
'K
é
^=e
?
×
¿ë
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
Nk
?f
K1{
^=`8UdX[U
1|
+Ø
p
Ù
\K
é
^=e
+?f
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
Nk
o
ë
ë
Kz{
^=`8UdX[U
1|
+Ø
p
Ù
iK
Ié
^=e
+o
ë
ë
@A
ì
5B
A
ì
5:
é
Ø
p
Ù
Nk
u
é
v
%ì
K E
;
~Z1
;
U
V
×
Ú
`an8U1dX[U
1|
+Ø
p
R7
¬e
BÙ
\K
é
^=e
u
é
v
%ì
@A
ì
5B
A
ì
5:
é
Ø
p
R7
¬e
BÙ
I
Durch die zus¨atzlichen Gewichte entsprechen
e
^=W8`[
@A
ì
5B
A
ì
5:
é
,
e
^=W`Y
PRQ
:
é
und
e
^=W`Y
XZY
:
é
[:
G
nicht der zu
erwartenden Belastung der Komponenten. Deshalb kann damit nicht ¨uberpr¨uft werden, ob sie ¨uber-
lastet sind. Stattdessen werden die Werte in eine zu minimierende Zielfunktion
eingesetzt, so daß
die Gewichte Einfluß darauf haben, wie stark die einzelnen Aktionen ber¨ucksichtigt werden. Diese
Zielfunktion wird berechnet, indem man die Last aller Komponenten mit komponentenspezifischen
Kostenfaktoren
@A
ì
5B
A
ì
5:
é
,
PRQ
:
é
und
XZY
:
é
[:
G
gewichtet und aufaddiert. Diese Gewichte geben an, wie
12
teuer es ist, ein Byte ¨uber den Server, das Teilnetz bzw. das Gateway zu transportieren. Der Model-
lierer kann damit beeinflussen, wie stark jede Komponente belastet werden soll. Durch einen großen
Wert wird erreicht, daß z.B. eine bestimmte WAN-Verbindung (Gateway) wenig verwendet wird. Die
zu minimierende Zielfunktion ergibt sich damit als:
f
E
é
@A
ì
5B
A
ì
5:
é
K1e
^=W8`[
@A
ì
5B
A
ì
5:
é
NE
é
PQ
:
é
Kze
»^W8`[
PQ
:
é
NE
é
E
GqU
V
é
XZY
:
é
[:
G
Kze
»^=W`Y
XZY
:
é
:
G
Die Wahl der Gewichte h¨angt davon ab, welches Ziel bei der Berechnung der Verteilung verfolgt wird.
Die Gesamtbelastung der WF-Server kann durch eine geeignete Verteilung nicht minimiert werden,
da jede Aktion von genau einem WF-Server erledigt werden muß. Die Gesamtlast ist umso kleiner, je
weniger Migrationen stattfinden. Das Ziel des vorgestellten Ansatzes ist es aber, das Kommunikations-
verhalten zu optimieren. So ist es naheliegend
_v
ã
@A
ì
JB
A
ì
5:
éf
p^
zu w¨ahlen. Angenommen, man will
ausschließlich die durchschnittliche Netzlast minimieren, weil die Teilnetze stark belastet sind und die
Gateways (z.B. in einem LAN) keinen Flaschenhals darstellen. Dann w¨ahlt man
_v
+ã
PRQ
:
éf
`a
und
_v
6798
ã
R
XZY
:
é
[:
G
f
^
. F¨ur einzelne besonders leistungsschwache Teilnetze kann auch
PQ
:
é
a
fest-
gelegt werden. Wenn hingegen bestimmte WAN-Verbindungen die Leistungsf¨ahigkeit des Systems
limitieren, so sollte f¨ur die zugeh¨origen Gateways
XZY
:
é
[:
G
a
gew¨ahlt werden.
Im folgenden Abschnitt wird beschrieben, welche Serverzuordnungsausdr¨ucke f¨ur die Aktivit¨aten
m¨oglich sind. In Abschnitt 4.4 wird gezeigt, wie die Serverzuordnungen so gew¨ahlt werden k¨onnen,
daß
minimal wird.
4.3 Potentielle Serverzuordnungen
Die Frage, welche Serverzuordnungen als
æsUSX
G\)]q^X=`Yb
×
in Frage kommen, l¨aßt sich in zwei Aspekte
aufteilen: welche Ausdr¨ucke sind generell m¨oglich und welche Aktivit¨aten werden von ihnen referen-
ziert. Diese beiden Gesichtspunkte werden in diesem Abschnitt diskutiert.
4.3.1 Serverzuordnungsausdr¨ucke
Bei der statischen Migration werden als Serverzuordnungsausdr¨ucke die Server-IDs von WF-Servern
verwendet. Im Fall variabler Serverzuordnungen sind, wie oben bereits erw¨ahnt, als Serverzuordnun-
gen auch Ausdr¨ucke erlaubt, die Laufzeitdaten der Instanz referenzieren. In den meisten praktisch
relevanten F¨allen wird man sich hierbei auf die Lokation des Servers oder des Bearbeiters einer an-
deren Aktivit¨at beschr¨anken. In Sonderf¨allen k¨onnen auch weitere WF-interne Daten (z.B. der Start-
zeitpunkt einer Aktivit¨at), beliebige mathematische Funktionen, logische Ausdr¨ucke oder die Einbe-
ziehung WfMS-externer Daten (z.B. Parameterdaten von Aktivit¨aten) Sinn machen. W¨ahrend Ser-
verzuordnungen der erstgenannten Art (s.u.: 1. - 4.) systemseitig vom WF-Modell abgeleitet werden
k¨onnen, m¨ussen die Zuordnungsausdr¨ucke f¨ur die Sonderf¨alle (5.) explizit vom Modellierer vorgege-
ben werden.
M¨ogliche Serverzuordnungen sind:
1.
æsUX
q
G\#]_^Xa`[b
×
df
"
æé
"
Der Aktivit¨at
p
wird der Server
æé
fest (statisch) zugeordnet.
2.
æsUX
q
G\#]_^Xa`[b
×
df
"
æsUSX
8UX
Ø
æÙ
"
Die Aktivit¨at
p
soll vom selben Server kontrolliert werden wie die Aktivit¨at
.
3.
æsUX
q
G\#]_^Xa`[b
×
df
"
~
^Wvb
.Ø
ET}UWXaZ
IØ
_ÙÙ
"
Der Aktivit¨at
p
wird der Server zugewiesen, der sich im Domain des Bearbeiters befindet, der die
13
Aktivit¨at
ausgef¨uhrt hat. Ist Aktivit¨at
p
derselbe Bearbeiter zugeordnet wie Aktivit¨at
, so ist
der Server von Aktivit¨at
p
durch diese Zuordnung stets optimal.
4.
æsUX
q
G\#]_^Xa`[b
×
df
"
m
Ø
æsUSX
8UX
Ø
æÙÙ
"oder
æsUSX
G\)]q^X=`Yb
×
f
"
m
Ø
~
^WYvb
.Ø
ETVU1WYX[Z
IØ
æÙÙÙ
"
Auf die Serverzuordnungen vom Typ 2 und 3 kann nocheine Funktion
m
angewandt werden. Dies
macht z.B. Sinn, wenn Aktivit¨at
p
zwar von Bearbeitern derselben OE wie Aktivit¨at
ausgef¨uhrt
wird, diese aber eine andere Rolle haben und in einem anderen Domain angesiedelt sind. Die
Funktion
m
muß dann von dem ersten Domain auf den zweiten abbilden. Ein weiteres Beispiel
f¨ur die Verwendung einer Funktion ist eine Aktivit¨at
p
, welcher der Chef des Bearbeiters von
Aktivit¨at
zugeordnet ist. Dieser kann einem anderen Domain angeh¨oren (z.B. wenn er einer
anderen Abteilung zugeordnet ist), so daß
m
den Domain des Mitarbeiters auf den des Chefs
abbildet.
Da die WVen der beiden Aktivit¨aten
und
p
berechnet werden k¨onnen (siehe Abschnitt 4.5),
kann eine optimale Funktion
m
automatisch erzeugt werden. Wie dies exakt funktioniert, wird im
Anhang A beschrieben.
5.
æsUX
q
G\#]_^Xa`[b
×
df
beliebiger vorgegebener Ausdruck, der nicht Typ 1 - 4 entspricht
Der Modellierer kann auch einen beliebigen Serverzuordnungsausdruck vorgeben. Da dieser vom
WfMS nicht analysiert werden kann, k¨onnen die WVen nicht automatisch berechnet werden.
Deshalb muß der Modellierer auch diese vorgeben, da sie von den Algorithmen aus Abschnitt 4.5
f¨ur ihre Analysen ben¨otigt werden.
Bei Verwendung variabler Serverzuordnungen kann in
æPUSX
o\#]_^Xa`[b
×
eine Aktivit¨at
referenziert
werden. Um diese beschrieben zu k¨onnen, wird die Funktion
cU1mUXaUb
Þ
SU`Yh
ÏÞ
¿k
eingef¨uhrt:
{
sei die Menge der Aktivit¨aten einer WF-Vorlage. Dann definiert die Funktion
cUNmUSX[USb
Þ
SU1`Yh
ÏÞ
k
f¨ur eine Aktivit¨at
p
die in deren Serverzuordnung referenzierte Aktivit¨at:
cUNmUSX[USb
Þ
SU1`Yh
ÏÞ
k
ã
\{
{z{
Ý
ee
mit
cU1mUX[USb
Þ
SU`h
ºÞ
¿k
2×
uf
`
{
Ý
e-e
, falls
æsUX
o\#]_^Xa`[b
×
vom Typ 1 oder 5
, falls
æsUX
o\#]_^Xa`[b
×
von der Bauart 2 - 4 (s.o.)
Zur Ausf¨uhrungszeit der WFs muß vor dem Start der Aktivit¨at
p
der Ausdruck
æsUSX
G\)]q^X=`Yb
×
aus-
gewertet werden. Damit dies immer m¨oglich ist, muß sichergestellt sein, daß die in
æsUSX
o\#]q^NXa`Yb
×
referenzierte Aktivit¨at
f cU1mUXaUb
Þ
SU`Yh
ÏÞ
¿k
×
garantiert vor der Aktivit¨at
p
ausgef¨uhrt wird. Das be-
deutet, daß die Aktivit¨at
immer vor der Aktivit¨at
p
ausgef¨uhrt werden muß. Außerdem muß, falls
die Aktivit¨at
p
tats¨achlich ausgef¨uhrt wird, auch die Aktivit¨at
wirklich ausgef¨uhrt worden sein, d.h.,
sie darf sich dann nicht in einem nicht gew¨ahlten Zweig einer OR-Verzweigung befinden. Nur dann
sind die ben¨otigen Laufzeitdaten (Bearbeiter, Server) verf¨ugbar. Wie diese Bedingungen sichergestellt
werden k¨onnen, wird im n¨achsten Abschnitt diskutiert.
4.3.2 F¨ur eine Referenzierung relevante Aktivit¨
aten
Nachdem gekl¨art wurde, welche Ausdr¨ucke als
æsUSX
o\#]q^NXa`Yb
×
in Frage kommen, wird in diesem Ab-
schnitt diskutiert, welche Aktivit¨aten
darin referenziert werden sollen. Dazu wird festgelegt, welche
Aktivit¨aten in einer Serverzuordnung ¨uberhaupt referenziert werden d¨urfen. Dann wird betrachtet, bei
welchen Aktivit¨aten es Sinn macht, sie zu referenzieren. Schließlich wird f¨ur Paare von Aktivit¨aten
untersucht, wie sich die Festlegung des Bearbeiters f¨ur eine Aktivit¨at auf die Menge der potentiellen
Bearbeiter der anderen Aktivit¨aten auswirkt.
4.3.2.1 F¨ur Referenzierung m¨
ogliche Aktivit¨
aten
14
Damit die Aktivit¨at
in
æsUX
o\#]_^Xa`[b
×
referenziert werden darf, muß sie garantiert vor Aktivit¨at
p
ausgef¨uhrt werden (vgl. Abschnitt 4.3.1). Dazu muß die Aktivit¨at
Üf cUNmUSX[USb
Þ
SU1`Yh
ÏÞ
k
2×
im Ablauf-
graphen vor
p
liegen und die Aktivit¨at
muß stets ausgef¨uhrt werden, falls
p
ausgef¨uhrt wird. Ein
Beispiel, in dem nur die zweite Bedingung verletzt ist, ist in Abb. 4 dargestellt. In diesem Fall darf in
æsUX
q
G\#]_^Xa`[b
×
die Aktivit¨at
_
nicht referenziert werden, obwohl
>
eine Vorg¨angeraktivit¨at von
p
ist
(
>
Z
lXaU1`
¡¢5£Z¤
Q¥PR¦
¤
f o
:
@§ Q
£
oT¨
Ø
p
Ù
)
©
. Solche F¨alle m¨ussen explizit ausgeschlossen werden.
ª
ª¬«
®¯¯°-±]²l³[´nµ
Ù
¶R·¹¸º¶R·'»½¼r¾6¿zÀmÁ»½ÂjÃÃ
ÄZÅÆÆ
¾-¸ÇÉÈ3Ê Ë
ÄZÅÆÆ
¾-¸ÊlÀ[Ì3Í
Ù
ÎRϹÐÑÎRÏiÒ½ÓrÔ6ÕzÖm×Ò ØjÙ[Ù
Abbildung 4 In
ú
-Q
où!ú
d
ý
darf die Aktivit¨at
,
¡Ú
nicht referenziert werden.
Um sicherzustellen, daß die Aktivit¨at
stets ausgef¨uhrt wird, falls die Aktivit¨at
p
ausgef¨uhrt wird, ist
zu pr¨ufen, ob sich
in einem Ast einer bedingten Verzweigung befindet, in dem sich
p
nicht befindet.
Wegen der Blockstrukturierung von ADEPT (vgl. [RD98]) ist dies gegeben, wenn sich zwischen
und
p
ein Verzweigungs-Endknoten und nicht der zugeh¨orige Verzweigungs-Anfangsknoten befindet.
Ist dies der Fall, so ist nicht erlaubt, daß die Aktivit¨at
in
æPUSX
o\#]_^Xa`[b
×
referenziert wird. Die in
Algorithmus 3 definierte Funktion
cUNm,hJeEeE^
qÛ
U1`
pr¨uft diese Bedingung f¨ur die Aktivit¨at
p
und die
referenzierte Aktivit¨at
. Außerdem wird ¨uberpr¨uft, ob die Aktivit¨at
im Ablaufgraphen vor
p
liegt.
Algorithmus 3 (Pr¨ufen, ob Referenzierung erlaubt:
Ü
ñ
¬Ý¥ÞÉßJß
2í
à
ñ
á\â/ãOäzå'æ
)
if
,
#ç
g
ûú
èméêë
A
¡ì
êí
<_%
îï
ë'é
<
Rð
þ
then return False;
for each
3
:
ñ
ò
þ
3
f
YM[
/
Y
N
ö
]r]
//
3
ist OR-Join-Knoten
n
3
g
ûú
èméêë
A
¡ì
êí
<
Rð
þ
mn
3
g
o÷¬÷
3èméêë
A
¡ì
êí
<
Rð
þ
,
do //
3
liegt zwischen
,
und
\f
;
Eø¬þ
R3
; //
ist zu
3
geh¨origer Splitknoten
if
ç
g
o÷¬÷
3èméêë
A
¡ì
êí
<
Rð
þ
,
then return False; // Splitknoten
liegt nicht zwischen
,
und
return True;
4.3.2.2 F¨ur Referenzierung relevante Aktivit¨
aten
Die Funktion
cUNm,hJeEeE^
qÛ
U`
pr¨uft, ob es m¨oglich ist, eine Aktivit¨at
ó
in
æ
¥ôSõö÷øqõùú
×
zu referenzie-
ren. Daraus folgt noch nicht, daß dies auch sinnvoll ist. Deshalb wird in diesem Abschnitt untersucht,
f¨ur welche Aktivit¨aten
ó
es interessant ist, sie in
æ
¥ôSõö÷øqõùú
×
zu referenzieren.
Die naheliegendste Idee ist, nur die Aktivit¨at
ó
zu ber¨ucksichtigen, die in
ûÑôzüõýSö÷øqõùú
×
referenziert
wird. Aber auch transitiv abh¨angige Aktivit¨aten k¨onnen relevant sein. In dem in Abb. 5a dargestellten
Beispiel hat der Bearbeiter der (von Aktivit¨at
þ
transitiv abh¨angigen) Aktivit¨at
}
dieselbe Rolle Arzt
wie der Bearbeiter von Aktivit¨at
þ
. Der Bearbeiter der direkt abh¨angigen Aktivit¨at
ó
hat die Rolle
MTA. Da mit der in Abb. 5c dargestellten Bearbeiterverteilung der Bearbeiter von Aktivit¨at
ó
immer
im Domain 1 angesiedelt sind, ist diese Information zur Festlegung der Serverlokation von Aktivit¨at
þ
wertlos. Der Bearbeiter von Aktivit¨at
}
(Rolle Arzt) befindet sich je nach OE im Domain 1 oder
2. Da f¨ur den Bearbeiter von Aktivit¨at
þ
dasselbe gilt, ist der Domain des Bearbeiters der transitiv
abh¨angigen Aktivit¨at
}
die optimale Lokation f¨ur den Server von Aktivit¨at
þ
.
ÿ
Zur Definition von
$'0n,
siehe Tabelle 1.
15
"!##$&%('*),+.-
Ù
/10324/106587*9:<;=>5 ?@A@
BDCEE
9&2(FHGJI
KKK L
MDNOOQP&R(SUT,VJW
Ù
X1Y3Z[X1Y]\8^*_`<ab>\ cd,d
egfh
iii
j k
lDmnnQo&prqHsJt
Ù
u1v3w4u1v6x8y*z{<|}>x ~ADQ
z&w(U|,J
DQ&(U,J
Ù
13[1]8*<> ,
g
¡¢ £*¤¥§¦¨ ©«ª
¬U®°¯¨²± ³J©µ´*¶.®·¸¹¦®»º¼¨ ¯®>¶.®½¼®,¾,¿Àµ¨²¶.©¼©]Á1©]¦³¼Ã¶Ä¨ÅÆ£*¤¥Ç¦¨ ©È¾ÉªÊ³J©.¶*ËÌ
£*¤¥Ç¦¨ ©ÍË
Á1ÂΪ
Á1«Ë
ª
ª
Ï
Ï
¢"®Ð¯ £D¤¥§¦¨ ©«ªÑ£*¤¥Ç¦¨ ©ÍË
Á1ÂΪ
Á1«Ë
ª
Ï
Ï
ª
Abbildung 5 WFs, bei denen die indirekt abh¨angige Aktivit¨at
Ò
f¨ur
ÓDÔ.ÕµÖ>קØÊÙµÕ¼ÚÛ¸Ü
relevant ist.
Doch nur die transitiven Abh¨angigkeiten zu ber¨ucksichtigen, reicht nicht aus, wie Abb. 5b zeigt. Mit
der Bearbeiterverteilung aus Abb. 5c befindet sich der Bearbeiter der einzigen von Aktivit¨at
þ
(tran-
sitiv) abh¨angigen Aktivit¨at
ó
immer im Domain 1 (wegen Rolle MTA). Der Bearbeiter der Aktivit¨at
Ý
hat aber wie der Bearbeiter von
þ
die Rolle Arzt und er stammt auch aus derselben OE. Da er des-
halb stets im gleichen Domain angesiedelt ist, ist dieser Domain der optimale Ort f¨ur den Server von
Aktivit¨at
þ
. Daraus folgt, daß alle Aktivit¨aten f¨ur eine Referenzierung relevant sind, die indirekt (vor-
oder r¨uckw¨arts) mit Aktivit¨at
þ
in Beziehung stehen. Alle anderen Aktivit¨aten sind nicht relevant, da
ihre Bearbeiter und deren OEen in keiner Beziehung zum Bearbeiter von Aktivit¨at
þ
stehen.
F¨ur die in Abschnitt 4.5.2 beschriebenen Analysen ist es notwendig, zu wissen, ob die Aktivit¨at
þ
und
die in
Þ
¥ôSõ
ß
ö÷øqõùú
*à
referenzierte Aktivit¨at
ó
denselben Bearbeiter haben, oder ob deren Bearbeiter
nur derselben OE angeh¨oren. Deshalb ermittelt der nachfolgend beschriebene Algorithmus 4 nicht nur
die f¨ur eine Referenzierung relevanten Aktivit¨aten, sondern er ermittelt f¨ur jede von ihnen auch, den
Typ
á
der Abh¨angigkeit (
áãâåä
zû
çæJèêéìë
). Dabei haben Eintr¨age im Ergebnis
í
%ô
î
Rô1úrù¡ôSú
*ï.ð
mô
ñ
folgende
Bedeutung:
ò
þ
1æ<ó
ó
Uæ
6û
õô,ö
Aktivit¨at
þ
hat denselben Bearbeiter wie Aktivit¨at
ó
ò
þ
1æ<ó
ó
UæJè÷éêô,ö
Aktivit¨at
þ
hat einen Bearbeiter aus derselben OE wie Aktivit¨at
ó
ò
þ
1æ<ó øúùüûýû§ô,ö
steht f¨ur eine unabh¨angige Bearbeiterzuordnung von Aktivit¨at
þ
Falls die Bearbeiter der Aktivit¨aten
þ
und
ó
in keiner Beziehung zueinander stehen, so befindet sich
sich kein entsprechender Term in
í
%ô
î
ôSúrù¡ô1ú
*ï.ð
mô
<ñ
.
Algorithmus 4 berechnet zuerst aus den Bearbeiterzuordnungen aller Aktivit¨aten initiale (nicht transi-
tive) Abh¨angigkeiten und sammelt diese in der Menge
í
ô
î
RôSúrùôSú
*ï.ð
mô
ñ
auf (Funktion
ð
jú
Dðþð
9ü
Êÿ
ùô
î
).
Anschließend wird versucht, aus jedem Paar von Abh¨angigkeiten
í
%ô
î
und
í
ô
î
eine neue
Abh¨angigkeit
í
%ô
î
zu generieren. Diese Aufgabe ¨ubernimmt die Funktion
ñ
1÷ý
µñÈþ¹ðþ
J÷
¸þ
/ô ùô
î
, welche
die in Abb. 5a und b dargestellten F¨alle indirekter Abh¨angigkeiten ber¨ucksichtigt. Wurde ein Paar von
Abh¨angigkeiten gefunden, das sich kombinieren l¨aßt, so muß noch der Typ
á
ñ
der neu erzeugten
Abh¨angigkeit ermittelt werden (Funktion
ï
Fø
¹ý
Jð
júlô
). Sind beide Abh¨angigkeiten vom Typ B (selber
Bearbeiter), so hat auch die neue Abh¨angigkeit den Typ B. Sind sie vom Typ B oder OE, so kann f¨ur
die neue Abh¨angigkeit nur dieselbe OE garantiert werden (Typ OE). Andernfalls kann nichts ausge-
sagt werden.
Der nun folgende Algorithmus 4 analysiert Zusammenh¨ange zwischen den Bearbeiterzuordnungen
der Aktivit¨aten, ist also von den Serverzuordnungen unabh¨angig. Er wird deshalb nicht in einer Schlei-
16
fe von Algorithmus 6 (s.u.) aufgerufen, sondern nur einmal (vor dem Berechnen der Serverzuordnun-
gen) ausgef¨uhrt.
Algorithmus 4 (Abh¨
angigkeiten zwischen den Bearbeitern der Aktivit¨
aten)
Ô
Ô.ÛÆÚÔ.Û
Ô
;
for each Aktivit¨at
Prozeßvorlage do
Ô
Ô.ÛÆÚÔJÛ
Ô
Ô
Ô.ÛÆÚÔJÛ
Ô
Û
"!#"$&%
ÚÔ
(')+*
;
do
-,.$
Û
0/
>ÔµÚ
1
False;
for each
Ô
(23
Ô
ÊÔJÛÆÚÔ.Û
Ô
do
for each
Ô
045
Ô
ÊÔJÛÆÚÔ.Û
Ô
do
Ô
.678
ÄØ
9:!#"!
Ø
.!
Ô ÚÔ
('
Ô
;2=<
Ô
>4=*
;
if
Ô
.6?A@CB3DDFE
Ô
.6G?
Ô
Ô.ÛÆÚÔ.Û
Ô
then
Ô
Ô.ÛÆÚÔ.Û
Ô
Ô
Ô.ÛÆÚÔ.Û
Ô
F
Ô
>6H
;
-,+$
Û
0/
>ÔµÚ
1
True;
while
-,.$
Û
0/
ÔµÚ
1
True;
IKJLIMKIN(O P;QRTSVUW
:
case
X
rÔ
$
Õ
9
J×ÇØ ÙµÕ¼Ú<Û¸Ü
Y
"
X
rÔ
$
Õ
9Z'\[>*
":
return
]) <:^ [;<X7_a`<:]b[;<:^ 0<XY_\`K
;
case
X
rÔ
$
Õ
9
J×ÇØ ÙµÕ¼Ú<Û¸Ü
Y
"
c3de'bX
¡Ô
f$
Õ
Z9'b[>*V*ECg-g:g
":
return
]) <:^ [;<c3dY_a`<:]\[(<:^ 0<c3dY_a`
;
case
X
rÔ
$
Õ
9
J×ÇØ ÙµÕ¼Ú<Û¸Ü
Y
unabh¨angig:
return
]) <:^ @CB3DhDi_a`
;
jkml&j
MIKM
k
MQ P;QRTSVnoQ=Rmp.qnoQRir>W
:
]b%V2<
2f`
Ô
;2
;
])%)4s<
4=`t
Ô
>4
;
if
2uv^ @CB3DhDi_xw
47y^ @CB3DD_
then return
@CB3DD
;
[
%z2:{
,
|72
] =
2
; [
%)4{
,
|u4
] =
4
; //
Ô
;2}v]b%V2<:^ %z2f{a<V|12_\`
,
Ô
043v]b%~4H<f^ %~4Z{a<|u4_\`
if
%V2:{.%)4
then // Fall 1: Fall aus Abb. 5a
| #A
Ù
9K
ÛÆÔ
&'#:|12<V|x4&*
;
return
]b%z2=<:^ %)4{a<V| #=_\`
;
else if
%V2:{.%)4Z{
then // Fall 2: Fall aus Abb. 5b
| #A
Ù
9K
ÛÆÔ
&'#:|12<V|x4&*
;
return
]b%z2=<:^ %)4s<V| #_\`
;
else return
@CB3DhD
;
.l
IKJTQ;S"W
:
if
0|0tG|Z| F
B
then return B;
else if
0| G|Z| F
B, OE
then return OE;
else return
@CB3DhD
;
Wenn sich in
ù¡ô
î
RôSúrùôSú
*ï.ð
mô
<ñ
ein Eintrag
ò
þ
1æ<ó
ó
Íæá(ô,ö
befindet, so ist
ó
f¨ur eine Referenzierung in
Þ
\ô1õ
ß
ö÷øqõùú
*à
”interessant“. Damit die Aktivit¨at
ó
in
Þ
\ôSõ
ß
ö÷Røqõùú
*à
referenziert werden darf, muß
sie außerdem garantiert vor Aktivit¨at
þ
ausgef¨uhrt werden (
ô
=t
¡ÿÿ
+ø
ôzù
(
þ
1æ
/ó
tx
True). Damit erge-
ben sich die in
Þ
\ô1õ
ß
ö÷øqõùú
*à
referenzierbaren und relevanten Aktivit¨aten
ô
Èÿ
ô
¼ß
üú
Dþ
K
üïJþà
wie folgt:
ô
Èÿ
ô
Èß
¡ü¡ú
Dþ
üï.þ¹à
ä
1ó
ò
þ
1æ<ó
ó
Uæá(ô,örâ í
ô
î
RôSúrùôSú
*ï.ð
mô
ñ
8
ô
=t
¡ÿÿ
+ø
ô1ù
þ
1æ
/ó
t
Äë
4.3.2.3 Bearbeiter von Aktivit¨
atenpaaren
Die Menge
í
ô
î
RôSúrùôSú
*ï.ð
mô
ñ
wurde bestimmt, um entscheiden zu k¨onnen, welche Aktivit¨aten in einer
Serverzuordnung referenziert werden sollen. Die Abh¨angigkeiten beschreiben aber eigentlich (transi-
tive) Beziehungen zwischen den Bearbeitern von zwei Aktivi¨aten. Deshalb k¨onnen sie auch verwendet
17
werden, um zu entscheiden, ob sich ein Benutzer noch f¨ur die Bearbeitung einer Aktivi¨at qualifiziert,
wenn die Bearbeiter anderer Aktivi¨aten vorgegeben sind. Da diese Funktionalit¨at von mehreren in
dieser Arbeit vorgestellten Algorithmen ben¨otigt wird, wird in diesem Abschnitt ein entsprechender
Algorithmus vorgestellt.
Die in der Menge
í
%ô
î
ôSúrù¡ô1ú
*ï.ð
mô
<ñ
enthaltenen Abh¨angigkeiten lassen erkennen, welches die potenti-
ellen Bearbeiter einer Aktivit¨at
þ
sind, wenn die Bearbeiter anderer Aktivit¨aten vorgegeben sind. Mit
dieser Information l¨aßt berechnen, ob ein Bearbeiter
÷
die Aktivit¨at
þ
bearbeiten darf, falls der Bear-
beiter
÷
(
einer anderen Aktivit¨at
ó
gegeben ist. Dazu pr¨uft Algorithmus 5 zuerst, ob der Bearbeiter
÷
– unabh¨angig vom Bearbeiter der Aktivit¨at
ó
– die Aktivit¨at
þ
bearbeiten darf, d.h. (vereinfacht), ob
er z.B. die richtige Rolle hat. Dies ist gegeben, falls
÷
â
ø
þ
Jû ô1ü¡õý
.à
gilt. Anschließend wird getestet,
ob die Bearbeiter
÷
(
und
÷
eine Abh¨angigkeit zwischen den Aktivit¨aten
ó
und
þ
verletzen. Existiert
zwischen den Aktivit¨aten
ó
und
þ
eine Abh¨angigkeit vom Typ
û
(selber Bearbeiter), so darf
÷
die
Aktivit¨at
þ
nur bearbeiten, falls er mit
÷
(
identisch ist; besteht eine Abh¨angigkeit vom Typ
èêé
, so
m¨ussen die Bearbeiter
÷
und
÷
(
derselben OE angeh¨oren. Gibt es keine Abh¨angigkeit zwischen den
Aktivit¨aten
ó
und
þ
, so darf der Bearbeiter
÷
die Aktivit¨at
þ
immer bearbeiten, da dann auch keine
Abh¨angigkeit verletzt sein kann. Daß
÷
die Aktivit¨at
þ
aufgrund seiner Rolle o.¨a. prinzipiell bearbeiten
darf, wurde ja schon am Anfang des Algorithmus gepr¨uft.
Algorithmus 5 (
s¡(¢;£¤¡t¥.¥+¦:§s¨K©ª«3¬=®¬=¯T¬7°
)
if
Ø
o?²±
Ù
!zX
rÔ
$
Õ
Z9
Ü
then return False;
if
]~0<:^ [;<XY_\`L
Ô
Ô.ÛÆÚÔ.Û
Ô
then
return
Ø
G
åØ
0{
;
else if
]~0<:^ [;<Kc3d3_a`
Ô
ÊÔ.ÛÆÚÔ.Û
Ô
then
return
c3de'
Ø
*h8c3de'
Ø
{*
;
else /*
]) <:^ @CB3DhDi_a`
Ô
Ô.ÛÆÚÔ.Û
Ô
*/
return True;
Der vorgestellte Algorithmus kann auch verwendet werden, wenn die Bearbeiter mehrerer Aktivi¨aten
vorgegeben sind. Sind die Bearbeiter
³( ´iµµµ³;
ñ
der Aktivit¨aten
¶
´
µµµ-¶
ñ
gegeben, so qualifiziert sich
der Bearbeiter
³
f¨ur die Aktivit¨at
·
, falls gilt:
üïJþ
K¸¹He¸
>ññ<ð
º
.ÿ
#»+~¶
´
æ
³ ´
¼æ
-·
1æ
³t}
á
1¹&³»¼µµµ7½
üï.þ
¸¹He¸
>ññ<ð
º
.ÿ
#»+~¶
ñ
æ
³
ñ
æ
-·
1æ
³tu
á
1¹&³»
4.4 Bestimmung der optimalen Serverzuordnungen
Zum Ermitteln der optimalen Verteilung k¨onnten im Prinzip f¨ur alle Aktivit¨aten und alle m¨ogli-
chen Serverzuordnungen die Kosten analysiert und die optimale Variante ausgew¨ahlt werden. Da
ein WF aber durchaus
¾²¿·
Êþ
CÀÁÂHÂ
Aktivit¨aten umfassen kann, die jeweils alle ihre Vorg¨anger in
der Serverzuordnung referenzieren k¨onnen, scheidet diese Vorgehensweise wegen ihrer Komplexit¨at
è
Ãz¾·
Êþ
ÄmÅ
à
fÆ
im allgemeinen aus. Wir schlagen deshalb den nachfolgend beschriebenen Algorith-
mus 6 vor, der ein polynomiales Laufzeitverhalten hat. Er basiert auf einem Greedy-Ansatz und liefert
f¨ur die praktisch relevanten F¨alle das optimale Ergebnis bzw. eines, das dicht an diesem Optimum
liegt.
Algorithmus 6 berechnet f¨ur jede Aktivit¨at die optimale Serverzuordnung und legt diese im Array
Þ
T»Z¹
ß
Ç1³(¸¹HÈsÉ
ab. In der Phase 1 wird zun¨achst eine zul¨assige Ausgangl¨osung bestimmt. Diese ber¨uck-
sichtigt noch keine Migrationskosten. F¨ur jede Aktivit¨at werden alle m¨oglichen Serverzuordnungen,
18
d.h. Ausdr¨ucke vom Typ 1 - 4 aus Abschnitt 4.3.1, ausprobiert (
ʸ
þÞ
T»Z¹
ß
Ç1³(¸¹HÈsÉ
*à
). In diesen Aus-
dr¨ucken werden alle relevanten Aktivit¨aten referenziert, d.h. Aktivit¨aten
¶
mit
¶
â
Ëe»
Èÿ
#»
¼ß
>Ì+É
Dþ
K
¡ï.þà
.
Aus den potentiell m¨oglichen Serverzuordnungen wird diejenige ausgew¨ahlt, die zu den minimalen
Kosten f¨ur die Ausf¨uhrung dieser Aktivit¨at f¨uhrt (
ï
Ì
ÿï
f³
Éÿ
"Ì
þ
K»
ï
¸
>ñ<þñ
>z
verwendet hierzu das Kostenmo-
dell aus Abschnitt 4.2).
Da die Aktivit¨aten isoliert betrachtet werden, ergeben sich i.d.R. auch nicht rentable Migrationen.
In Phase 2 wird ¨uberpr¨uft, welche dieser Migrationen sinnvoll sind. Dazu wird ausgerechnet, ob es
g¨unstiger ist, eine Gruppe
von Aktivit¨aten (die alle vom selben WF-Server kontrolliert werden)
mit einer direkten Vorg¨anger- oder Nachfolgergruppe zusammenzufassen, so daß die Migration da-
zwischen entf¨allt. Die Motivation daf¨ur ist, daß es sich nicht lohnt, wegen wenigen Aktivit¨aten die
gesamte Prozeßinstanz zu einem Server hin und zur¨uck zu migrieren. Der Algorithmus betrachtet
zuerst kleine zusammenh¨angende Teilgraphen
(Partitionen) von Aktivit¨aten, die alle vom selben
Server (vgl. Algorithmus 12 und 13) kontrolliert werden. Diese werden mit Nachbar-Teilgraphen
zusammengefaßt, wodurch immer gr¨oßere Gruppen von Aktivit¨aten gebildet werden, zwischen de-
nen keinen Migrationen stattfinden. Dies wird solange durchgef¨uhrt, bis keine unrentablen Migratio-
nen mehr vorhanden sind. Dieses Vorgehen reduziert die zu kommunizierende Datenmenge bei der
Ausf¨uhrung der WFs, da Gruppen von Aktivit¨aten genau dann zusammengefaßt werden, wenn dies
die Kommunikationskosten reduziert.
Algorithmus 6 (Berechnung der Serverzuordnung f¨ur einen WF-Typ)
Phase 1:
for each Aktivit¨at
Prozeßvorlage (in partieller Ordnung entsprechend Kontrollfluß) do
Í
Û
;Î
«Ù
Z-!iÏ
;
for each
|
&Ô
:!
ÓDÔ.ÕµÖ ×ÇØ ÙµÕ¼Ú<Û Ü
G±
Ù
!
Ó*ÔJÕµÖ ×ÇØ ÙµÕ¼Ú<Û Ü
do
Î
«Ù
Z:!A$&%b
Ø
0%b$!
Ô
Ù
Z:!V='
,ÓDÔ.ÕµÖ>קØÊÙµÕ¼ÚÛ
(Ð<s*
;
Ñ
/* Kosten nur f¨ur Aktivit¨at k berechnen */
if
Î
«Ù
Z:!LÒ
Í
Û
;Î
«Ù
Z:!
then
ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ¸Ü
7Ó|
ýÔ
:!
ÓDÔ.ÕµÖ>×§Ø ÙµÕµÚÛ¸Ü
;
Í
,Û
;Î
«Ù
Z:!iAÎ
«Ù
Z:!
;
Phase 2:
Í
Û
;Î
«Ù
Z:!$&%b
Ø
0%b$!
Ô
ÄÙ
Z-!V'
,ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ
Ð<$&%b%)*
; /* Kosten gesamter WF (mit Migrationskosten) */
for PartGr¨
oße = 1 to #Aktivit¨
aten(Prozeßvorlage) do
for each
±Ë.Ô ±eÔ
PartGr¨
oße
Eñ
ist max. Teilgraph mit
0%bÕf<%aÖ3²±Ë
Ó
$
[Ô¼ÓDÔ.Õ.ÖÔ.Õ
H'b%bÕ<%aÖ:*
do
cm+!z×u!hÓ@CB3DD
;
for each
$?²±Ë=ØL%±v
$e²±
«ÕµÔµÚ
è
Ù;Ú;ÛLÜ>Ý Ú;Þ ßà á&â;ÛLÙ ßià ÞsÚ;Ú(ã ßä
'b%~*(w
$e
ìÓ"Ø
>-
è
Ù;Ú;ÛLÜ>Ý Ú;Þ ßià áâ(ÛLÙ ßià ÞsÚ;Ú(ã ßä
'b%~*
do
for each
%±
do
|
ýÔ
-!
Ó*ÔJÕµÖ ×ÇØ ÙµÕ¼Ú
å
Ó*ÔJÕµÖ ×ÇØ ÙµÕ¼Ú<Û
;æ
;
for each
%?±
do
|
ýÔ
-!
Ó*ÔJÕµÖ ×ÇØ ÙµÕ¼Ú
å
Ó*ÔJÕµÖ ×ÇØ ÙµÕ¼Ú<Û
å
;
|
ýÔ
-!VÎ
«Ù
Z:!iÓ$&%)
Ø
>%)$!
Ô
Ù
Z:!V'\|
ýÔ
:!
ÓDÔ.ÕµÖ>×§Ø ÙµÕµÚÛ
Ð<$&%b%)*
;
if
|
ýÔ
:!VÎ
«Ù
Z:!hÒ
Í
,Û
;Î
«Ù
Z:!
then
cm+!z×}!i$
;
Í
,Û
;Î
«Ù
Z:!Ó|
ýÔ
:!VÎ
«Ù
Z:!
;
if
cm+!z×u!x?@B3DhD
then
for each
%±
do
ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ
å
ÓDÔ.ÕµÖ>×§Ø ÙµÕµÚÛ
Ú0çè\éê~è
;
19
4.5 Berechnung der Wahrscheinlichkeitsverteilungen
Nachdem erl¨autert wurde, welche Serverzuordnungen f¨ur eine Aktivit¨at in Frage kommen und wie
die durch sie entstehenden Kosten berechnet werden, bleibt die Frage, wie die WVen
é
e¶(e¹&¸Hº
.à
.
,ðÄæ
Vë.
,
ì
ð
#í+¹H¹H¸Hº
Jà
=î ïz
,ðæ
Vë>
und
¾
Hù ñ
»¹
à
.
í
Ó
8Þ
f¨ur eine zu untersuchende Verteilung berechnet werden
k¨onnen.
Da Serverzuordnungen von Laufzeitdaten der Instanz abh¨angen, kann dieselbe Aktivit¨at
·
bei ver-
schiedenen WF-Instanzen durch unterschiedliche Server kontrolliert werden. Die entsprechende
Wahrscheinlichkeit, daß Aktivit¨at
·
vom Server
Þ
kontrolliert wird, wird mit
ð7©0¢ñi£o¢(¡(§.ò(ªfð°
=
P(Aktivit¨at
·
wird vom Server
Þ
kontrolliert) bezeichnet. Da sich verschiedene Instanzen in unter-
schiedlichen OEen befinden k¨onnen (und dabei unterschiedliche Server verwenden k¨onnen), kann die
Bearbeiter-WV jeweils unterschiedlich sein. Der Anteil an den Bearbeitern von Aktivit¨at
·
aus dem
Domain
í
, f¨ur den Fall, daß der Server
Þ
die Aktivit¨at
·
kontrolliert, wird in
+¡(¢;£o¢;¡§ òªóõôöð°
= P(der Bearbeiter von Aktivit¨at
·
befindet sich im Domain
í
÷
der Server der Aktivit¨at
·
befin-
det sich im Domain S) festgehalten. Das Hauptproblem bei der Kostenanalyse besteht nun darin, f¨ur
gegebene Serverzuordnungen die WVen
Þ
T»¹
ß
.e¹&¸Hº
.à
.
Þ
}
und
üï.þ
¸¹H¹H¸Hº
.à
.
í
Ó
8Þ
zu berechnen. Sind
diese erst bekannt, so k¨onnen
é
ʶ(¹H¸Hº
.à
>
,ðæ
Vë>
und damit die Kosten f¨ur die Aktivit¨atenausf¨uhrung
berechnet werden.
üï.þ
¸¹H¹H¸Hº
Jà
>
í
ø
8Þ
}
muß dazu nur noch mit der Wahrscheinlichkeit gewichtet
werden, mit der Server
Þ
den Schritt
·
kontrolliert (
Þ
T»Z¹
ß
>¹H¸Hº
Jà
0
Þ
). Die Wahrscheinlichkeit, daß
der Server
Þ
verwendet wird und ein Bearbeiter im Domain
í
die Aktivit¨at
·
bearbeitet, betr¨agt
é
e¶¹H¸Hº
Jà
0
Þ]æí
o
Þ
T»Z¹
ß
.¹H¸Hº
.à
.
Þ
mùZ
üï.þ
¸¹H¹H¸Hº
.à
>
í
Ó
8Þ
.
F¨ur einzelne Aktivit¨aten k¨onnen
Þ
T»Z¹
ß
.¹H¸Hº
.à
.
Þ
und/oder
üï.þ
¸¹H¹H¸Hº
Jà
>
í
ø
8Þ
}
f¨ur bestimmte Server-
zuordnungen auch vom Modellierer vorgegeben werden, falls dieser ¨uber zus¨atzliches Wissen verf¨ugt.
Ein Beispiel hierf¨ur ist eine Aktivit¨at, die bevorzugt von einem bestimmten Bearbeiter erledigt wird
und bei der die anderen potentiellen Bearbeiter nur aushelfen, wenn dieser ¨uberlastet ist.
4.5.1 Berechnung der Server-Wahrscheinlichkeitsverteilung
ð7©0¢ñi£o¢(¡(§ òªfð°
Die Server-WV
Þ
T»Z¹
ß
>¹H¸Hº
Jà
0
Þ
f¨ur die Aktivit¨at
·
gibt an, mit welcher Wahrscheinlichkeit Server
Þ
der Server von Aktivit¨at
·
ist. Sie ergibt sich aus der Serverzuordnung
Þ
»¹
ß
0Ç1³(¸¹HÈsÉ
*à
und der
Server- bzw. Bearbeiter-WV der referenzierten Aktivit¨at
¶
. Diese WVen sind bei der Analyse von
Aktivit¨at
·
schon bekannt, da
¶
vor
·
ausgef¨uhrt wird und die Prozeßvorlage in partieller Ordnung
durchlaufen wird. Die Berechnung der Server-WV wird nun f¨ur die in Abschnitt 4.3.1 definierten
Serverzuordnungen beschrieben. Der Fall 5 wird dabei (und im weiteren) nicht ber¨ucksichtigt, da bei
dieser Serverzuordnung die WV vom Modellierer vorgegeben werden muß.
Þ
T»Z¹
ß
.¹H¸Hº
.à
>
Þ
kann mit
dem folgenden Algorithmus berechnet werden:
4.5.2 Berechnung der Bearbeiter-WV
C+¡(¢;£o¢(¡(§ òªóõôúð5°
Die Bearbeiter-WV
¡ï.þ
K¸¹&e¹&¸Hº
.à
.
í
Ó
8Þ
gibt an, mit welcher Wahrscheinlichkeit der Bearbeiter von
Aktivit¨at
·
aus dem Domain
í
stammt, wenn die Aktivit¨at vom Server
Þ
kontrolliert wird. Sie
ist vom konkret verwendeten Server
Þ
dieser Aktivit¨at abh¨angig. Als Beispiel stelle man sich ein
Krankenhaus mit 3 Abteilungen vor, die jeweils ¨uber einen eigenen Server verf¨ugen. F¨ur Patien-
ten der Abteilung 1 sind ausschließlich Pflegekr¨afte von Abteilung 1 (Domain 1) zust¨andig. Sinn-
vollerweise wird in diesem Fall auch Server 1 verwendet. Damit ergibt sich eine Bearbeiter-WV
20
Algorithmus 7 (Berechnung der Server-WV
ðY©0¢ñi£¤¢;¡(§ òªfð°
)
case
ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ¸Ü
7
"
Ó
": (1)
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
+'
AÓ
i*iAû
á&à áü ý
case
ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ Ü
"
ÓDÔ.ÕµÖÔ.Õ
H'\[0*
": (2)
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
'
AÓ
i*i
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9þ.'
AÓ
i*
case
ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ¸Ü
7
"
Ù
²$
,Û
i')X
rÔ
$
Õ
Z9'\[0*V*
": (3)
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
'\z*iA×}!
ÙµÕ
±
«Õ¼Ù
Z9þ>'\z*
mit
×u!
ÙµÕ
±
«ÕµÙ
Z9þ>'
*h8ÿ
á
×}!
ÙµÕ
±
«Õ¼Ù
Z9þ>'
Ó
i*
µÓDÔ.Õ.Ö
&±
«Õ¼Ù
Z9þ+'
,Ó
i*
case
ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ¸Ü
7
"
t'
AÓ*ÔJÕµÖÔ.Õ
&'b[>**
": (4a)
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
+'
AÓ
i*i
t'
AÓ*ÔJÕµÖ
&±
«Õ¼Ù
Z9 þ'
,Ó
i*V*
case
ÓDÔ.Õ.Ö ×§ØÊÙµÕ¼ÚÛ Ü
"
t'
Ù
G$
Û
i'bX
¡Ô
f$
Õ
Z9'b[>*V**
": (4b)
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
+'\z*i
t'b×}!
ÙµÕ
±
«Õ¼Ù
Z9 þ'\z**
mit
×u!
ÙµÕ
±
«ÕµÙ
Z9 þ'
*hAÿ
á
×u!
ÙµÕ
±
«Õ¼Ù
Z9 þ'
Ó
i*
.Ó*ÔJÕµÖ
&±
«Õ¼Ù
Z9 þ'
,Ó
i*
Erkl¨arungen:
(1) Da die Aktivit¨at
stets vom Server
Ó
kontrolliert wird, ist
ÓDÔ.ÕµÖ
&±
«ÕµÙ
Z9
ÄÜ
s'
AÓ
h*L 2
f¨ur
Ó
Ó
und sonst
.
(2) F¨ur Akt.
wird derselbe Server verwendet wie f¨ur
[
, weshalb die Server-WVen gleich sind.
(3) Der Server von Aktivit¨at
ist im Domain des Bearbeiter von Aktivit¨at
[
angesiedelt. Deshalb ergibt
sich die Server-WV von
aus der Bearbeiter-WV von
[
. Da dabei nicht relevant ist, welcher Server
Aktivit¨at
[
kontrolliert hat, wird eine vom Server unabh¨angige Bearbeiter-WV
×}!
ÙµÕ
±
«Õ¼Ù
Z9 þ'\z*
erzeugt,
indem die Bearbeiter-WVen der einzelnen Server gewichtet aufaddiert werden. Diese werden jeweils mit
der Wahrscheinlichkeit gewichtet, daß der betrachtete Server die Aktivit¨at
[
kontrolliert hat.
(4a) Die Berechnung von
Ó*ÔJÕµÖ
&±
«Õ¼Ù
Z9
Ü
H'
AÓ
h*
erfolgt wie im Fall 2, wobei auf das Ergebnis noch die Funktion
angewandt werden muß (wie dies exakt funktioniert, zeigt Algorithmus 11 in Abschnitt 4.5.4).
(4b) Wie Fall 3, dann auf das Ergebnis
anwenden.
üïJþ
K¸¹H¹H¸&º
.à
>
í
øöu K
æ
Â
æ
Â+
. Analog ergibt sich f¨ur Server 2 die WV
¡ï.þ
K¸=¹H¹H¸Hº
.à
>
í
Ó s "Â
æ
Z
æ
Â+
und
¡ï.þ
K¸¹&e¹&¸Hº
.à
.
í
Ó s} "Â
æ
Â
æ
Z
f¨ur Server 3.
Die Bearbeiter-WV
¡ï.þ
K¸=¹H¹H¸Hº
.à
.
í
Ó
8Þ
kann durch Algorithmus 8 bestimmt werden. Der Algorith-
mus durchl¨auft alle Bearbeiter der Aktivit¨at
·
und ermittelt jeweils den zugeh¨origen Domain
í
(aus dem Organisationsmodell). Außerdem bestimmt er den Server
Þ
, der die Aktivit¨at kontrol-
liert, falls dieser Bearbeiter sie ausf¨uhrt. Dann wird der Bearbeiter f¨ur den entsprechenden Server
Þ
und Domain
í
in der Bearbeiter-WV
¡ï.þ
K¸=¹H¹H¸Hº
.à
.
í
Ó
8Þ
ber¨ucksichtigt. Die Berechnung von
üïJþ
K¸¹H¹H¸&º
.à
>
í
ø
8Þ
erfolgt also entsprechend der Definition der Bearbeiter-WV (siehe Abschnitt 4.5).
Die Aktivit¨at
·
kann trotz desselben Bearbeiters durch unterschiedliche Server – jeweils mit einer ge-
wissen Wahrscheinlichkeit – kontrolliert werden. Diese Wahrscheinlichkeiten werden mit der Funk-
tion
í
»
îDÞ
T»¹
ß
#·
1æ
"
²»Ì+¹sº ³
"
berechnet und im Vektor
í
»
îDÞ
T»¹
ß
.e¹&¸Hº
.à
.
Þ
1 ³t
gespeichert. Der
Bearbeiter wird anteilig bei jedem dieser Server ber¨ucksichtigt.
Um die Kosten f¨ur Arbeitslisten-Updates absch¨atzen zu k¨onnen, muß
¾
Hù ñ
»¹
<à
>
í
ø
8Þ
}
– die Anzahl
der potentiellen Bearbeiter von Aktivit¨at
·
im Domain
í
, falls die Aktivit¨at vom Server
Þ
kontrolliert
wird – berechnet werden. Dies geschieht im Algorithmus 8, indem alle Bearbeiter gez¨ahlt werden,
die Aktivit¨at
·
bearbeiten d¨urfen, falls sie vom Server
Þ
kontrolliert wird (
¾
çù ñ
»¹
<à
0
8Þ
). Da sich diese
Bearbeiter entsprechend
¡ï.þ
K¸=¹H¹H¸Hº
.à
.
í
Ó
8Þ
auf die verschiedenen Domains verteilen, berechnet sich
¾
Hùêñ
=»Z¹
<à
.
í
Ó
8Þ
damit als:
¾
Hù ñ
»¹
<à
>
í
ø
8Þ
}õ¾
Hùêñ
=»Z¹
<à
>
8Þ
ÓùZ
¡ï.þ
K¸=¹H¹H¸Hº
.à
.
í
Ó
8Þ
Die Berechnung der Server-WV
í
»
îDÞ
T»¹
ß
.e¹&¸Hº
.à
0
Þ
7 ³t
f¨ur einen bestimmten Bearbeiter
³
geschieht
in ¨ahnlicher Weise, wie f¨ur die bearbeiterunabh¨angige WV
Þ
T»Z¹
ß
.¹H¸Hº
.à
.
Þ
in Abschnitt 4.5.1 be-
21
Algorithmus 8 (Berechnung der Bearbeiter-WV
s¡(¢;£o¢;¡§ òªó ôúð°
)
for each
Ø
²±
Ù
!zX
¡Ô
$
Õ
Z9
Ü
do
Ù
²$
Û
i'
Ø
*
;
Ô
ÊÓDÔ.ÕµÖ
&±
«ÕµÙ
Z9
ÄÜ
s'
AÓ
Ø
*i
Ô
ÓDÔ.Õ.Ö
0') <
"
X
rÔ
$
Õ
Z9T
Ø
"
*
;
for each
Ó
do
if
Ô
ÓDÔ.Õ.Ö
&±
«Õ¼Ù
Z9
Ü
H'
,Ó
Ø
*u?
then
×}!
ÙµÕ
±
«Õ¼Ù
Z9
Ü
.'
Ó
i*iA×}!
ÙµÕ
±
«Õ¼Ù
Z9
Ü
.'
Ó
i*
Ô
ÊÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
s'
AÓ
Ø
0*
;
B7
JÔ.Õ Ü
Ó
o
BY
.ÔJÕ Ü
Ó
2
;
normalisiere jede Zeile von
×}!
ÙµÕ
±
«Õ¼Ù
Z9
Ü
'
Ó
i*
so, daß
Ó
ÿ
²×}!
ÙµÕ
±
«Õ¼Ù
Z9
Ü
'
Ó
i*i 2
;
schrieben. Allerdings h¨angt
í
»
îDÞ
T»¹
ß
.e¹&¸Hº
.à
.
Þ
1 ³t
nicht nur von der Serverzuordnung der betrachte-
ten Aktivit¨at
·
ab, sondern auch von deren Bearbeiterzuordnung. Im folgenden werden einige Bei-
spiele beschrieben, eine vollst¨andige Diskussion aller F¨alle, die durch Kombination der m¨oglichen
Server- und Bearbeiterzuordnungen entstehen, findet sich im Abschnitt 4.5.4.
Ist die Serverzuordnung statisch (
Þ
»¹
ß
0Ç1³(¸¹HÈsÉ
*à
F
"
Þ
"), so ist die Berechnung trivial, da der
Server immer gleich ist:
í
»
î"Þ
T»¹
ß
>¹H¸&º
.à
>
Þ
7 ³t
î
.
Ist die Bearbeiterzuordnung unabh¨angig von anderen Aktivit¨aten (z.B. "
¸
ÿÿ
#»Ê 5¹
þ
"), so ist
die Server-WV unabh¨angig vom Bearbeiter
³
, weshalb die allgemeine Server-WV ¨ubernommen
werden kann:
í
»
î"Þ
T»Z¹
ß
.¹H¸Hº
.à
>
Þ
7 ³
à
.
In Abb. 6a wird Aktivit¨at
·
vom selben Arzt bearbeitet wie Aktivit¨at
¶
. Der Server wird im Do-
main des Bearbeiters von Aktivit¨at
¶
allokiert. Es soll
í
»
î"Þ
T»Z¹
ß
>¹H¸Hº
Jà
>
Þ
7 ³t
f¨ur
³
= Dr. Brink-
mann aus Domain 3 berechnet werden. Wegen
²»Ì+¹sºÇ1³(¸¹HÈsÉ
*à
C
"
»ZÌ.¹sº&~¶t
"hat Dr. Brink-
mann auch Aktivit¨at
¶
ausgef¨uhrt. Deshalb ist der Server von Aktivit¨at
·
im Domain von Dr.
Brinkmann angesiedelt. Da dies der Domain 3 ist, ergibt sich
í
»
î"Þ
»¹
ß
.¹H¸Hº
.à
.
Þ
7 ³ "Â
æ
Â
æ
Z
.
Wird, wie in Abb. 6b dargestellt, nicht derselbe Bearbeiter verwendet, sondern lediglich diesel-
be OE, so ist das Verfahren etwas komplizierter. Es soll
í
»
î"Þ
T»¹
ß
>¹H¸&º
.à
>
Þ
7 ³t
f¨ur Schwester
Hildegard aus der OE Abteilung 2 berechnet werden. Dazu m¨ussen alle Bearbeiter (derselben
OE Abteilung 2) mit der Rolle Arzt durchlaufen werden, weil dies genau die Bearbeiter sind,
die die Aktivit¨at
¶
ausgef¨uhrt haben k¨onnen, wenn Aktivit¨at
·
von Schwester Hildegard aus-
gef¨uhrt wird. F¨ur jeden dieser ¨
Arzte wird der Domain ermittelt, da er – falls dieser Arzt die
Aktivit¨at
¶
ausgef¨uhrt hat – die Lokation des Servers bestimmt. Dieser Domain wird dann in
í
»
î"Þ
T»Z¹
ß
.¹H¸Hº
.à
>
Þ
7 ³
ber¨ucksichtigt. Nach dem Durchlaufen aller potentieller Bearbeiter wird
í
»
î"Þ
T»Z¹
ß
.¹H¸Hº
.à
>
Þ
7 ³
noch so normalisiert, daß
ÿ
í
»
î"Þ
T»¹
ß
>¹H¸&º
.à
>
Þ
7 ³t
gilt.
! "
#%$'&)(+*,
! -
.0/213&54768,7#9$&)(+*8,
! -:-
;/<=<=$?>A@9(CBED
F=GH
I I I
J K
L%MNON=P?QSRETN=PVUWP
KEX+Y
T)Z
Ù
[\^]_[\a`7b%c'd)e+f` gVh:h
i0j2k
d5l7m8`7b9cd)e+f8` g h:h
njo=o
c?]Ap9eCqEr
Abbildung 6 Beispiele zur Berechnung der Server-WV
Ô
ÓDÔ.Õ.Ö
&±
«Õ¼Ù
Z9
Ü
H'
,Ó
Ø
*
.
22
4.5.3 Gewichtung der Bearbeiter
Es gibt Benutzer, die Teilzeit arbeiten, die nur einen Teil ihres Arbeitstags mit dem WfMS arbeiten
oder die in mehreren Domains jeweils einen Teil ihrer Arbeitszeit verbringen. Diese d¨urfen nicht wie
Benutzer behandelt werden, die ”full time“ im selben Domain arbeiten, da sie im Tagesdurchschnitt
bzw. pro Teilnetz weniger Last erzeugen. Ein solcher Sachverhalt l¨aßt sich z.B. dadurch modellieren,
daß jedem Benutzer des WfMSs Gewichte zugeordnet werden. Diese k¨onnen verwendet werden, um
bei der Berechnung der Bearbeiter-WV
¡ï.þ
K¸=¹H¹H¸Hº
.à
.
í
Ó
8Þ
die
í
»
îDÞ
T»¹
ß
.e¹&¸Hº
.à
.
Þ
1 ³t
der einzelnen
Bearbeiter gewichtet zu addieren.
Die Gewichte k¨onnen auch von der aktuell betrachteten Aktivit¨at
·
abh¨angen (
s
à
~³
). Die Gewichte
eines Bearbeiters werden zwar h¨aufig f¨ur alle Aktivit¨aten identisch sein (
t
(É
vuws
à
0~³t}
s
~³t
), es gibt
aber auch praktisch relevante F¨alle, in denen die Gewichte f¨ur einzelne Aktivit¨aten vom Standardwert
abweichen. So kann ein Benutzer ”Lieblingsaktivit¨aten“ haben oder Aktivit¨aten, die er nur in Aus-
nahmef¨allen ausf¨uhrt, wenn alle anderen potentiellen Bearbeiter gerade verhindert sind. Außerdem
kann es Aktivit¨aten geben, die ein Benutzer nur in bestimmten Zeitr¨aumen bearbeitet. So ist vielleicht
ein Schalter nur vormittags ge¨offnet, so daß die entsprechenden Aktivit¨aten nur vormittags bearbeitet
werden, w¨ahrend andere T¨atigkeiten ganzt¨agig ausgef¨uhrt werden. F¨ur diese Aktivit¨aten ist
s
à
>~³
gr¨oßer bzw. kleiner als
s
~³
.
F¨ur die Gewichte eines Bearbeiters ist sogar eine noch feinere Unterscheidung m¨oglich. F¨ur einen
Benutzer
³
k¨onnen zwei Arten von benutzerspezifischen Gewichten
s
êà
>~³
und
s
à
~³t
unterschieden
werden. Mit
s
à
0~³t
legt der Modellierer fest, welchen Anteil der Zeit der Benutzer die Aktivit¨
at
·
ausf¨
uhrt (so daß durch den Parametertransfer Last erzeugt wird). Mit
s
à
~³t
wird angegeben, wel-
chen Anteil der ¨ublichen Arbeitszeit er durchschnittlich am WfMS angemeldet ist (so daß seine Ar-
beitsliste aktualisiert werden muß). Ist die Aktivit¨at
·
eine ”Lieblingsaktivit¨at“ des Benutzers
³
, so
ist
s
à
0~³t
gr¨oßer als der Standardwert
s
~³
dieses Benutzers. Auch das Gewicht
s
à
~³t
, das den
Anteil an der Arbeitszeit beschreibt, in dem der Benutzer angemeldet ist, kann f¨ur verschiedene Akti-
vit¨aten unterschiedlich sein. Benutzer verwenden oft mehrere Arbeitslisten f¨ur unterschiedliche Grup-
pen von Aktivit¨aten. Wenn z.B. ein Benutzer f¨ur Aktivit¨aten am Schalter nur vormittags zust¨andig ist
und deshalb die entsprechende Arbeitsliste nur vormittags ge¨offnet hat, so wird f¨ur diese Aktivit¨aten
s
à
~³t
yxs
~³
gew¨ahlt. Im folgenden wird aber auf die Unterscheidung von
s
à
~³t
und
s
à
~³t
ver-
zichtet und das Gewicht eines Bearbeiters
³
als
s
à
>~³
bezeichnet. Falls die Unterscheidung jedoch
ben¨otigt wird, so h¨angt die Auswahl des bei einer Berechnung verwendeten Gewichtes davon ab, ob
die Kosten f¨ur die Aktivit¨atenausf¨uhrung (
s
êà
0~³
) oder f¨ur Arbeitslisten-Updates (
s
¿
à
~³
) berechnet
werden sollen.
Durch die Gewichte wird beschrieben, daß die verschiedenen Benutzer eine zu bearbeitende Akti-
vit¨at mit unterschiedlicher Wahrscheinlichkeit ausw¨ahlen. Wenn die Gewichte der Benutzer bei einer
Berechnung ber¨ucksichtigt werden, so kann zwischen den Benutzern Unabh¨angigkeit angenommen
werden, d.h., die Wahrscheinlichkeit, daß ein Benutzer
³
die Aktivit¨at
·
ausw¨ahlt, ist so groß, wie
sein Anteil an dem ”Gesamtgewicht f¨ur Aktivit¨at
·
“:
(Benutzer
³
bearbeitet die Aktivit¨at
·
) =
s
à
>~³
{z
ÿ
)|}~%
Æ
i
+'
s
à
~³
Außer diesen benutzerspezifischen Gewichten
s
à
~³t
, werden durch die variable Serverzuordnung
weitere OE-spezifische Gewichte
s
à
0
èêé
²
notwendig. Der Grund daf¨ur ist, daß nicht mehr ange-
nommen werden kann, daß alle potentiellen Bearbeiter gleich wahrscheinlich
´
V
f¨ur die Bearbeitung
Hinter dieser Annahme steckt die Unabh¨angigkeit der Bearbeiter voneinander.
23
einer Aktivit¨at sind. Um dies zu erl¨autern, nehmen wir an, daß f¨ur den in Abbildung 6b dargestell-
ten Ablauf die Verteilung von Bearbeitern auf OEen aus Tabelle 2 gelte.
1É
Dþ
»
¼ðÿ
»ZÌ.¹sº
.à
.
èêé
²Ó
ÿ
VWC
)
E
¡
¢
ö
£
ÿ
8V¤CV
¢
5£
beschreibt dabei den Anteil der Bearbeiter von Aktivit¨at
·
, die der Or-
ganisationseinheit
èêé
angeh¨oren (
e¸
þ
¥
»ZÌ.¹sº
.à
ist die Menge der potentiellen Bearbeiter von Aktivit¨at
·
, vgl. Abschnitt 4.1.1).
OE
§¦
3©0¦¨
¨
©
ª©
¢;§
W«
(¨
Arzte)
§¦
3©0¦¨
¨
©
ª©
¢;§ ò
(Pflegekr¨
afte)
Abteilung 1 0,2 (2 Bearbeiter mit
s
à
0~³t
) 0,4 (16 Bearbeiter mit
s
à
>~³
)
Abteilung 2 0,5 (5 Bearbeiter mit
s
à
0~³t
) 0,35 (14 Bearbeiter mit
s
à
0~³t
)
Abteilung 3 0,3 (3 Bearbeiter mit
s
à
0~³t
) 0,25 (10 Bearbeiter mit
s
à
0~³t
)
Tabelle 2: Beispiel f¨ur die Verteilung von Bearbeitern auf verschiedene OEen.
Obwohl 40% der Bearbeiter von Aktivit¨at
·
(Pflegekr¨afte) zur Abteilung 1 geh¨oren, kann nicht an-
genommen werden, daß 40% dieser Aktivit¨aten von Bearbeitern der Abteilung 1 ausgef¨uhrt werden.
Die OE wird n¨amlich schon bei der Ausf¨uhrung von Aktivit¨at
¶
festgelegt. Da die ¨
Arzte von Ab-
teilung 1, die Aktivit¨at
¶
ausf¨uhren, aber nur einen Anteil von 20% haben, wird Aktivit¨at
·
auch
nur mit einer Wahrscheinlichkeit von 20% in Abteilung 1 ausgef¨uhrt. Algorithmus 9 berechnet f¨ur
jede Aktivit¨at
·
, wie groß der Anteil der einzelnen OEen bei der Ausf¨uhrung dieser Aktivit¨at ist
(
5É
Dþ
K»
Èðÿ
"1³
"ñ
=
à
>
èêé
G
). Ist Aktivit¨at
·
abh¨angig von einer Aktivit¨at
¶
(
ò
·
1æ<ó
¶
Uæárô,ö â í
»
î
t»ÉiÈ.»ZÉ
*ï.ð
»
<ñ
mit
á â ä
)
HæJè÷éìë
), so bestimmt Aktivit¨at
¶
den Anteil der OEen bei der Ausf¨uhrung von Aktivit¨at
·
. Andernfalls (
ò
·
1æ<ó øúùüûýû§ô,öõâ í
»
î
t»ÉiÈ.»ZÉ
*ï.ð
»
<ñ
) entspricht der Anteil einer OE bei der Ausf¨uhrung
ihrem Anteil an den Bearbeitern. Aus den Werten f¨ur
1É
Dþ
»
¼ðÿ
»ZÌ.¹sº
.à
.
èêé
²
und
5É
Dþ
»
¼ðÿ
"5³
1ñ
à
.
èêé
²
berechnet Algorithmus 9 das OE-Gewicht
s
à
>
è÷é
G
, mit dem jeder Bearbeiter dieser OE zus¨atzlich
gewichtet wird. Durch die zus¨atzliche Gewichtung der Bearbeiter mit diesem OE-Gewicht entspricht
der Anteil der Gewichte der Bearbeiter einer OE ihrem Anteil an der Ausf¨uhrung der Aktivit¨at. Da-
mit erfolgt die Berechnung von
s
»Z
rðï
¬
Æþ¹à
~³
auf korrekte Art und Weise. Diese Aussage wird im
Anhang B.1 bewiesen. Ist Aktivit¨at
·
von keiner anderen Aktivit¨at abh¨angig, so ergibt sich das OE-
Gewicht als 1.
Im obigen Beispiel ist f¨ur die Abteilung 1
5É
Dþ
K»
Èðÿ
"1³
"ñ
=
à
0"º
Jþ
v 1É
Dþ
»
¼ðÿ
"5³
1ñ
5
0"¿º
Jþ
fË
5É
Dþ
K»
Èðÿ
²»Ì+¹sº
®
"º
Jþ
Y Â
æ
-
. Damit ergibt sich das OE-Gewicht als
s
êà
>"¿º
Jþ
f Â
æ
-
z
Â
æ
¯
A Â
æ
'°
.
Mit diesem Wert wird jede Pflegekraft der Abteilung 1 bei der Berechnung von
üï.þ
¸¹H¹H¸Hº
.à
.
í
Ó
8Þ
zus¨atzlich gewichtet, so daß sich f¨ur alle Bearbeiter aus Abteilung 1 ein Gesamtgewicht
s
»Z
rðï
¬
þà
~³t² Â
æ
'°
ergibt. Mit diesem Gesamtgewicht wird der Bearbeiter
³
bei der Berechnung
von
üï.þ
¸¹H¹H¸Hº
.à
>
í
Ó
8Þ
in Algorithmus 8 gewichtet:
4.5.4 Berechnung der Wahrscheinlichkeitsverteilung
ó8©
±
xð7©0¢ñi£o¢(¡(§.ò(ªfðGô Y°
Wie in Abschnitt 4.5.2 beschrieben, muß zur Berechnung der Bearbeiter-Wahrscheinlichkeitsver-
teilung
üï.þ
¸¹H¹H¸Hº
Jà
>
í
ø
8Þ
}
die Server-WV
í
»
î"Þ
»¹
ß
.¹H¸Hº
.à
>
Þ
1 ³t
berechnet werden. Dabei ist zu be-
achten, daß der Bearbeiter
³
von Aktivit¨at
·
vorgegeben ist.
í
»
î"Þ
T»¹
ß
>¹H¸&º
.à
0
Þ
7 ³t
gibt also f¨ur einen
bestimmten Bearbeiter
³
an, mit welcher Wahrscheinlichkeit die Aktivit¨at
·
vom Server
Þ
kontrolliert
wird. Dabei muß sowohl die Bearbeiter- wie auch die Serverzuordnung gegeben sein, da die Berech-
nung von beiden abh¨angt. Algorithmus 10 behandelt die bei der Berechnung von
í
»
î"Þ
»¹
ß
#·
1æ
®²
e¸=ÉiÈ0
24
Algorithmus 9 (Berechnung der OE-abh¨
angigen Gewichte)
/* Anteil der OEen an den Bearbeitern von Aktivit¨at
berechnen */
c3d ×
ýÛ
!
Ô
f"%)X
rÔ
$
Õ
Z9
Ü
&')c3d1*
³
;
for each
c3d
do
×
§Û
!
Ô
f#%bX
¡Ô
f$
Õ
Z9
Ü
&'~c3d1*h ÿ
´
ã
¶µ
Vè
¸·
æ
¹¥º»
¼
Ú;ß
9½
¾¸¿
Ú;ß
À
Ü
H'
Ø
*
Á
ÿ
´
ã
¶µ
zè
¸·
æ
¹º»
À
Ü
s'
Ø
*
;
/* Anteil der OEen an der Ausf¨uhrung von Aktivit¨at
berechnen */
for each
c3d
do
if
Ø&[F+])0<f^ [(<X7_a`L
Ô
Ô.ÛÆÚÔ.Û
Ô
w]~0<:^ [;<Kc3d3_a`
Ô
ÊÔ.ÛÆÚÔ.Û
Ô
then
×
§Û
!
Ô
f#%b×
ýØ
0
ÈÜ
')c3d5*h×
ýÛ
!
Ô
f"%)×
§Ø
þ')c3d1*
else
×
§Û
!
Ô
f#%b×
ýØ
0
Ü
')c3d5*h×
ýÛ
!
Ô
f"%)X
rÔ
$
Õ
Z9
Ü
')c3d1*
;
À
Ü
'~c3d1*hA×
§Û
!
Ô
f#%b×
§Ø
Ü
')c3d1*
%Á
×
§Û
!
Ô
f#%bX
rÔ
$
Õ
Z9
Ü
')c3d1*
;
/* Berechnung der Gesamtgewichte f¨ur die Bearbeiter */
for each
Ø
²±
Ù
!zX
¡Ô
$
Õ
Z9
Ü
do
c3dvAc3dÊ'
Ø
*
;
À
Ô
EÂ
#-,s!
Ü
s'
Ø
*i
À
Ü
H'~c3d1*
%
À
Ü
s'
Ø
*
;
Algorithmus 8: Berechnung
Ã
M
wÄwÅÆÄ
. l
Ç
Sn
ÉÈËÊ
uW
unter Ber¨ucksichtigung der Gewichte
...if
Ô
ÓDÔ.Õ.Ö
&±
«Õ¼Ù
Z9
Ü
'
,Ó
Ø
*u?
then
×}!
ÙµÕ
±
«Õ¼Ù
Z9
Ü
'
Ó
i*iA×}!
ÙµÕ
±
«Õ¼Ù
Z9
Ü
'
Ó
i*
Ô
ÊÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
'
AÓ
Ø
0*
%
À
Ô
EÂ
#-,s!
Ü
'
Ø
*
;
B7
JÔ.Õ Ü
Ó
o
BY
.ÔJÕ Ü
Ó
À
Ô
EÂ
#-,+!
Ü
'
Ø
*
;
...
auftretenden F¨alle.
²
e¸=ÉiÈ
beschreibt dabei die betrachtete Bearbeitermenge, also beim Aufruf den
Benutzer
³
(
»ZÌ.¹sºY ³
).
Wir erw¨ahnen zuerst noch einmal die einfachen F¨alle, die auch schon in Abschnitt 4.5.2 diskutiert
wurden. Ist die Serverzuordnung statisch (
Þ
T»¹
ß
Ç7³¸¹&È+É
*à
Ê
"
Þ
", Fall 1a - c in Algorithmus 10), so
ist der Server immer gleich und die Serververteilung ergibt sich als
í
»
î"Þ
T»¹
ß
>¹H¸&º
.à
>
Þ
7 ³tG
Ì
î
)
.
Ist die Bearbeiterzuordnung unabh¨angig von Aktivit¨at
¶
(Fall 1a, 2a und 3a), so wird f¨ur jeden Be-
arbeiter die allgemeine Server-WV
Þ
T»Z¹
ß
.¹H¸Hº
.à
>
Þ
¨ubernommen. Im Fall 1a gilt nach Algorithmus 7
Þ
T»Z¹
ß
>¹H¸Hº
Jà
>
Þ
¤
Í
î
)
, so daß kein Widerspruch zu den Aussagen vom Anfang dieses Absatzes
besteht. Die F¨alle 2a und 3a machen scheinbar keinen Sinn, da eine abh¨angige Serverzuordnung ver-
wendet wird, obwohl der Bearbeiter der Aktivit¨at
·
nicht von anderen Aktivit¨aten abh¨angt. Diese
F¨alle k¨onnen aber sehr wohl auftreten, n¨amlich wenn Aktivit¨aten zusammengefaßt werden um Migra-
tionen einzusparen (Phase 2 von Algorithmus 6), so daß Aktivit¨at
·
in eine Partition mit abh¨angigen
Serverzuordnungen aufgenommen wird.
Es bleiben noch die F¨alle, in denen
»ZÌ.¹sºÇ7³¸¹&È+É
*à
von Aktivit¨at
¶
abh¨angig ist (
ò
·
1æ<ó
¶
Uæárô,ö â
í
»
î
»ZÉiÈ.»É
*ï.ð
»
ñ
mit
á â ä
)
çæJèêé ë
) und in
Þ
T»Z¹
ß
Ç1³(¸¹HÈsÉ
*à
die Aktivit¨at
¶
referenziert wird. Lau-
tet
Þ
T»¹
ß
Ç7³¸¹&È+É
*à
"
Þ
T»¹
ß
>»Z¹~¶t
", so ergibt sich
í
»
î"Þ
T»Z¹
ß
.¹H¸Hº
.à
.
Þ
7 ³
durch Rekursion. Wir be-
trachten zuerst den Fall, daß Aktivit¨at
·
vom exakt selben Benutzer bearbeitet wird wie Aktivit¨at
¶
(Fall 2b). Da die Aktivit¨aten
·
und
¶
in diesem Fall denselben Bearbeiter und denselben Server
haben, hat jeder Bearbeiter bei den beiden Aktivit¨aten auch dieselbe Serververteilung. Das Ergeb-
nis ergibt sich also durch direkte Rekursion, wobei die Bedingung
²
¸ÉiÈ
– die die Bearbeitermenge
von Aktivit¨at
¶
beschreibt – unver¨andert ¨ubernommen wird. Wird Aktivit¨at
¶
lediglich von irgend-
einem Benutzer derselben OE bearbeitet wie Aktivit¨at
·
(Fall 2c), so wird das Ergebnis ebenfalls
25
durch Rekursion berechnet. Es ist aber nicht garantiert, daß die Aktivit¨aten
·
und
¶
vom exakt sel-
ben Bearbeiter ausgef¨uhrt werden (nur dieselbe OE ist sicher). Deshalb wird die Rekursion mit einer
ge¨anderten Bedingung
²
e¸ÉiÈs
aufgerufen, falls
²
¸ÉiÈ
einen Bearbeiter spezifiziert hat.
²
e¸=ÉiÈ+
darf
f¨ur Aktivit¨at
¶
nun nur noch die OE des Bearbeiters festlegen. Falls durch
²
¸ÉiÈ
nur die OE der
Bearbeiter vorgegeben ist, kann die Bedingung unver¨andert f¨ur die Rekursion verwendet werden.
Lautet
Þ
T»Z¹
ß
Ç1³(¸¹HÈsÉ
*à
"
í
C¸¤Ì
ð
zÉ}
»ZÌ.¹Hº&~¶
", so wird keine Rekursion ausgef¨uhrt; ggf. ist damit
das Rekursionsende erreicht. Stattdessen wird die Menge der potentiellen Bearbeiter von Aktivit¨at
¶
durchlaufen, da der Server von Aktivit¨at
·
im Domain des Bearbeiters von Aktivit¨at
¶
angesiedelt ist.
F¨ur jeden Benutzer, der prinzipiell Aktivit¨at
¶
bearbeiten darf und zus¨atzlich die Bearbeiterbedingung
²
¸ÉiÈ
erf¨ullt, wird der zugeh¨orige Domain ermittelt. Die Domains dieser Bearbeiter bestimmen den
Server von Aktivit¨at
·
, so daß das gewichtete Aufaddieren dieser Domains zur korrekten Server-WV
f¨ur Aktivit¨at
·
f¨uhrt (f¨ur die in
²
¸ÉiÈ
spezifizierten Benutzer). Schließlich wird das Ergebnis noch
normiert, so daß die Summe aller Werte 1 ergibt.
Algorithmus 10 (Berechnung von
ó©
±
xðY©0¢;ñª¯T¬
Î
¡
ϦAÐ
°
)
case
Ñ
Uq
8Ò7ÓÕÔ×Ö?ÖÙØÚ
Ñ
Uq
Ò7Û
Lq
®Ü×ØÝÚ
Ñ
Uq
ÒËÛ
Lq
®ÞàßáØÚ
â
n¤QRtQHJTPQHJ
IKQ
j
â
noQ=RtQHJTPQHJ
IQ
j
â
noQ=RtQHJTPQHJ
IQ
j
ÓDÔ.ÕµÖ>קØÊÙµÕ¼ÚÛ¸Ü
(1a) (1b) (1c)
"
Ê%ã
"
ÆÓ
¤
Ó
9ä
'
AÓ
h*hÓû
áà áü
Ó
Ó
9ä
e'
,Ó
i*iÓû
áà áü
Ó
Ó
9ä
Ê'
AÓ
i*iAû
á&à áü
ÓDÔ.ÕµÖ>קØÊÙµÕ¼ÚÛ¸Ü
(2a) (2b) case
ÙµÛÆÚ
"
X
rÔ
$
Õ
9T
Ø
":(2c)
"
Ê
TQ
Ĥå
Q
Ä
S
VÛ
hW
"
ÆÓ
¤
Ó
9ä
'
AÓ
h*
Ó
9ä
e'
,Ó
i*i
Ô
ÓDÔ.Õ.Ö
0'\[(<Î
«ÙµÛÆÚ
&*
Ù¼Ô
x8c3de'
Ø
*
;
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
'
AÓ
i* Î
«ÙµÛÆÚ
={0
"
c3dv
Ù¼Ô
";
case
ÙµÛÆÚ
"
c3dv
Ù¼Ô
":
Î
«ÙµÛÆÚ
={0AÎ
«ÙµÛÆÚ
;
Ó
9ä
Ê'
AÓ
i*i
Ô
ÊÓDÔ.ÕµÖ
0'\[;<KÎ
«ÙµÛÆÚ
={a*
ÓDÔ.ÕµÖ>קØÊÙµÕ¼ÚÛ¸Ü
(3a)
Ó
Ó
9ä
e'
,Ó
i*i
æ
;(3b)
"
n
>
N(IJ7S
ÆÓ
¤
Ó
9ä
'
AÓ
h*
for each
Ø
ò±
Ù
!zX
rÔ
$
Õ
Z9 þ
mit
Ø
erf¨ullt
Î
«ÙµÛÆÚ
do
Ü
QsN
Ä
>l
S
Û
hW:W
"
Ó
o
Ù
²$=
Û
i'
gØ
0*
;
ÓDÔ.ÕµÖ
±
«Õ¼Ù
Z9
Ü
+'
AÓ
i*
Ó
çä
e'
AÓ
h*i
úÓ
9ä
Ê'
AÓ
i*
À
Ô
EÂ
#-,+! þ'
Ø
*
;
normalisiere SV(S), so daß
ÿ
á
Ó
9ä
'
AÓ
h*iy2
return SV(S);
Wird eine Funktion
auf die Serverzuordnung angewandt, d.h.
Þ
T»Z¹
ß
0Ç1³(¸¹HÈsÉ
*à
Ã
"
T
Þ
T»¹
ß
>»Z¹~¶t
"
oder
Þ
»¹
ß
0Ç1³(¸¹HÈsÉ
*à
¿
"
T
í
¸=¤Ì
ð
zÉ}
»ZÌ.¹sº&~¶t
", so muß
auch noch auf das Ergebnis
Þ
Ùè
C
Þ
}
an-
gewandt werden. Um die Funktion
auf einen Vektor anzuwenden, initialisiert Algorithmus 11 einen
Ergebnisvektor
Þ
3è
Ê#
Þ
mit 0. F¨ur jeden Eintrag in
Þ
3è
C
Þ
wird der aus der Abbildung
resultierende
Server
Þ
T
Þ
berechnet. Der entsprechende Eintrag aus
Þ
3è
C
Þ
wird dann an der Stelle
Þ
im
Ergebnis
Þ
3è
e
ber¨ucksichtigt.
Algorithmus 11 (Anwenden einer Funktion
é
auf eine WV
ð
ëê
8ªfð°
)
Ó
Ó
9ä
1{)'
,Ó
i*i
;
for each S do
Ó
{>
t'
AÓ
i*
;
Ó
9ä
7{~'
AÓ
i{ú*i
Ó
9ä
Y{~'
AÓ
i{ú*
Ó
9ä
e'
AÓ
i*
;
Hat der Modellierer f¨ur eine Aktivit¨at
·
eine Serverzuordnung vorgegeben, die nicht analysiert wer-
26
den kann (Fall 5. in Abschnitt 4.3.1), so muß er auch
Þ
T»¹
ß
>¹H¸&º
.à
0
Þ
und
¡ï.þ
K¸=¹H¹H¸Hº
.à
>
í
Ó
8Þ
vor-
geben. Da
¡ï.þ
K¸¹&e¹&¸Hº
.à
.
í
Ó
8Þ
damit schon bekannt ist, wird Algorithmus 8 aus Abschnitt 4.5.2 und
damit Algorithmus 10 nicht verwendet. Allerdings kann es vorkommen, daß die benutzerabh¨angige
Serververteilung
í
»
îDÞ
T»¹
ß
.e¹&¸Hº
.à
.
Þ
1 ³t
einer Aktivit¨at mit einer derartigen Serverzuordnung bei ei-
ner Rekursion ben¨otigt wird (Fall 2b oder 2c). Als Ergebnis kann immer die allgemeine Server-WV
Þ
T»Z¹
ß
>¹H¸Hº
Jà
>
Þ
verwendet werden, die ebenfalls vom Modellierer vorgegeben werden muß. Hat der
Modellierer zus¨atzlich OE-spezifische Server-WVen angegeben, so wird aus
²
¸ÉiÈ
die betroffene OE
ermittelt, womit die zugeh¨orige Server-WV verwendet werden kann.
Mit den beschriebenen Mechanismen lassen sich weitere relevante Typen von Bearbeiterzuordnun-
gen (siehe 4.1.1) behandeln. F¨ur diese k¨onnen weitere Arten von Abh¨angigkeiten und weitere Be-
arbeiterbedingungen
²
e¸=ÉiÈ
definiert werden. Soll z.B. die Aktivit¨at
·
vom Vorgesetzten des Be-
arbeiters der Aktivit¨at
¶
erledigt werden, so l¨aßt sich dies durch eine Serverzuordnung der Form
"
T
í
¸=¤Ì
ð
zÉ}
»ZÌ.¹sº&~¶t
"effizient unterst¨utzen. Dabei stellt
die Abbildung vom Domain der An-
gestellten einer Abteilung zum Domain ihres Vorgesetzten dar.
Þ
3è
C
Þ
wird, wie im Fall 3b beschrie-
ben, durch das Durchlaufen aller Untergebenen des Chefs berechnet. Daf¨ur kann eine Bedingung
der Art "
è
e¸¹í>»
ñ
=»
Èþ
¥
>þ
»¹ ³
"verwendet werden. – Wird f¨ur Aktivit¨at
·
ein Bearbeiter aus dersel-
ben OE
è÷é
´
wie f¨ur Aktivit¨at
¶
verwendet, der aber von diesem verschieden sein muß (4-Augen-
Prinzip), so muß beim Durchlaufen aller Bearbeiter beim Rekursionsende (3b) der Bearbeiter von
Aktivit¨at
·
ausgelassen werden. Die Bedingung kann hier "
èêé
¼
è÷é
´
ì
»ZÌ.¹sº
îí
³
"lauten. Die
»ZÌ.¹sºÇ1³¸=¹HÈ+É
*à
A
"
ï¡
²»Ì+¹sº&~¶txA¸
ÿÿ
#»Tµµµ
"wird ebenso behandelt, wobei aber alle Bearbeiter
mit einer passenden Rolle ber¨ucksichtigt werden m¨ussen (außer dem von Aktivit¨at
·
), und nicht nur
die einer bestimmten OE.
²
¸ÉiÈ
lautet dann "
»ZÌ.¹sº
ðí
³
", die richtige Rolle der Bearbeiter
³
der
Aktivit¨at
¶
wird in Algorithmus 10 Fall 3b durch die Bedingung
³
â
¤Ê¸
þ
»ZÌ.¹sº
'
sichergestellt.
4.5.5 Wahrscheinlichkeitsverteilung f¨ur die Startaktivit¨
at einer WF-Instanz
In zahlreichen Anwendungsbereichen sollen dieselben ”Standard-WFs“ in verschiedenen OEen ver-
wendet werden. Diese WFs werden (fast) ausschließlich von Bearbeitern der jeweiligen OE aus-
gef¨uhrt. Es werden also dieselben WF-Templates in unterschiedlichen OEen verwendet, wobei die
WF-Instanzen vom jeweils lokalen WF-Server kontrolliert werden sollen. Um eine solche Verteilung
zu modellieren, k¨onnte man einen speziellen Serverzuordnungsausdruck einf¨uhren, der festlegt, daß
eine Aktivit¨at von dem Server kontrolliert wird, auf dem die entsprechende WF-Instanz gestartet wur-
de. Dieser zus¨atzliche Serverzuordnungsausdruck wird in ADEPT nicht ben¨otigt; es gen¨ugen die in
Abschnitt 4.3.1 beschriebenen Ausdr¨ucke. Der Grund daf¨ur ist, daß der erste Schritt jedes WFs ein
expliziter Startknoten
ñ<þ
ist, dem immer die leere Aktivit¨at zugeordnet ist. Als Bearbeiter dieses Start-
knotens wird der Benutzer, der diesen WF gestartet hat, vermerkt; als WF-Server der Server, auf dem
die Instanz gestartet wurde. Dies ist der Server im Domain dieses Benutzers. Diese beiden Daten
der Startaktivit¨at k¨onnen nun in den Server- und Bearbeiterzuordnungen der darauf folgenden Akti-
vit¨aten referenziert werden. Einen WF, der am Startserver verbleibt, erh¨alt man damit, indem f¨ur jede
Aktivit¨at
·
die Serverzuordnung
Þ
T»¹
ß
0Ç1³¸=¹HÈ+É
*à
"
Þ
T»Z¹
ß
>»¹
ñ<þ
"verwendet wird.
Um (automatisch) ermitteln zu k¨onnen, ob solche Serverzuordnungen g¨unstig sind, m¨ussen auch
f¨ur die Startaktivit¨at
ñ<þ
die Bearbeiter- und Server-WVen berechnet werden. Die Server-WV
Þ
T»Z¹
ß
>¹H¸Hº
Eñ
Æ
Þ
kann aus den Domains der Benutzer abgeleitet werden, die eine Instanz dieses WF-
Typs
á
starten d¨urfen. Welche dies sind, wird durch ein Pr¨adikat des WF-Typs beschrieben (analog zu
den Bearbeiterzuordnungen). Bei der Berechnung von
Þ
T»Z¹
ß
.¹H¸Hº
ñ
Æ
Þ
werden die Gewichte
sSò
u~³
ber¨ucksichtigt, die angeben, ob der Benutzer
³
einen WF dieses Typs
á
¨uberdurchschnittlich oft bzw.
27
selten startet (analog zu den Gewichten der Benutzer f¨ur die Ausf¨uhrung von Aktivit¨aten):
t
DÞ
au
Þ
»¹
ß
.¹H¸Hº
ñ
Æ
Þ
}
ÿ
8}
Æ
¸'
Æ\
++ó
ôWõ
¥ö?
ñ
W¢
ö
£÷
sSò
u~³
ÿ
8}
Æ
¸
KÆ\
++ó
sSò
x~³
mit
Þ]þ
Ì.¹
þ
K»Z¹
ò
ä
Z³
Benutzer
³
darf WFs vom Typ
á
starten
ë
F¨ur die Bearbeiter-WV gilt stets
üï.þ
¸¹H¹H¸Hº
ñ
Æ
í
Ó
8Þ
e
Ì
î
õ
, weil der Benutzer
³
WFs auf seinem
lokalen Server
Þ
startet. Deshalb geh¨oren der Server
Þ
und der Benutzer
³
immer demselben Do-
main
í
an. Die WVen
Þ
T»Z¹
ß
.¹H¸Hº
ñ
Æ
Þ
und
üïJþ
K¸¹H¹H¸&º
ñ
Æ
í
Ó
8Þ
k¨onnen nun bei der Berechnung von
Þ
T»Z¹
ß
>¹H¸Hº
Jà
>
Þ
und
¡ï.þ
K¸=¹H¹H¸Hº
.à
.
í
Ó
8Þ
nachfolgender Aktivit¨aten verwendet werden.
4.6 Migrationskosten
In Phase 1 von Algorithmus 6 werden nur die optimalen Serverzuordnungen der Aktivit¨aten betrach-
tet, ohne die Migrationskosten zu ber¨ucksichtigen. In Phase 2 werden auch diese Kosten mit einbezo-
gen. Um entscheiden zu k¨onnen, ob ¨uberhaupt Kosten anfallen, muß berechnet werden, ob zwischen
zwei aufeinanderfolgenden Aktivit¨aten (
·
und
ÿ
) eine Migration stattfindet. Falls dem so ist, muß die
Wahrscheinlichkeit
ì
ð
#í+¹H¹H¸Hº
.à
î ïz
,ðÄæ
Vë.
bestimmt werden, mit der die WF-Instanz vom Server
ð
zum
Server
ë
migriert wird.
4.6.1 Bestimmung identischer Serverzuordnungen
Dieser Abschnitt untersucht die Frage, welche Aktivit¨aten stets vom gleichen Server kontrolliert wer-
den (dazu m¨ussen die Serverzuordnungsausdr¨ucke nicht identisch sein). Die Gleichheit bezieht sich
dabei auf dieselbe WF-Instanz; die Server unterschiedlicher Instanzen k¨onnen verschieden sein. F¨ur
die Aktivit¨aten
ÿ
und
·
wird derselbe Server verwendet (
Þ
LÌ.»
Þ
T»Z¹
ß
0»¹
ÿ¹æ
-·C
á
1¹&³»
), wenn einer
der in Abb. 7 dargestellten F¨alle vorliegt. Bei a) wird in der Serverzuordnung von
·
explizit angege-
ben, daß derselbe Server wie f¨ur
ÿ
verwendet werden soll und bei b) ergibt sich dies durch denselben
Serverzuordnungsausdruck (z.B. "
í
¸=¤Ì
ð
zÉ}
»ZÌ.¹sº&"Ì0
"). Im Fall c) haben die Aktivit¨aten
Ì
und
º
denselben Bearbeiter. In dessen Domain befinden sich die Server von
ÿ
und
·
, die somit identisch sind.
Ein h¨aufiger Spezialfall von c) ist, daß die Aktivit¨aten
º
und
ÿ
zusammenfallen, so daß sich eine Kette
von Aktivit¨aten mit demselben Server und demselben Bearbeiter ergibt. In d) ist exemplarisch der Fall
dargestellt, daß in zwei Serverzuordnungen dieselbe Funktion
verwendet wird und innerhalb dieser
Funktion ¨aquivalent Ausdr¨ucke stehen. Da
Þ
T»Z¹
ß
0»¹"Ì
und
Þ
T»¹
ß
>»Z¹#º
denselben Server beschreiben,
werden – nach Anwendung von
auf diesen Server – auch die Aktivit¨aten
ÿ
und
·
vom selben Server
kontrolliert. Falls die inneren Ausdr¨ucke identisch sind, erf¨ullen die Serverzuordnungen zus¨atzlich die
Bedingung f¨ur den Fall b).
Soll gepr¨uft werden, ob die Aktivit¨aten
·
und
¶
vom selben Server kontrolliert werden, so muß man
analysieren, ob eine ”transitive Abh¨angigkeit“ der beiden Aktivit¨aten voneinander besteht. Algorith-
mus 12 ermittelt dazu die Menge der Aktivit¨aten, die vom selben Server kontrolliert werden wie Ak-
tivit¨at
·
(
Þ
T»¹
ß
0»¹
¡ð
» ·
). Diese Menge enth¨alt zuerst nur die Aktivit¨at
·
. Dann wird in einer Schleife
f¨ur jede Aktivit¨at
ÿ
gepr¨uft, ob sie nach den Regeln aus Abb. 7 (Funktion
í
ÿ
#»
¼ðï
¬
(»¹
Þ
T»¹
ß
0»¹
>í ð
V¹H»=·
Êþ
z
)
vom selben Server kontrolliert wird, wie eine Aktivit¨at
aus der Menge
Þ
T»¹
ß
>»Z¹
¡ð
» ·
. Falls dem
so ist, wird
ÿ
in diese Menge aufgenommen. Dies wird solange durchgef¨uhrt, bis sich die Menge nicht
28
øù ú úVú
û ü
ýþÿ
Eþÿ
û
!"#$%
&&& '
()
***
+ , --- . /// 0
132 4657 8:9#;<7=?>@ACBEDGFH IJCH KL@NMCB O
PRQTS?UVWYXEZ6[U \:]#X<]^^PRQTS?UVWYXEZ6[U \:]#X<U^^
___
` a bbb c ddd e
fgihj3klmj3kgonppfgihjk:lmjkg<qpNp
rTs
tu3vwmu3vx<yz
Abbildung 7 F¨alle in denen die Aktivit¨aten
und
%
vom selben Server kontrolliert werden.
mehr ¨andert oder die Aktivit¨at
¶
aufgenommen wurde. Im letzteren Fall werden die Aktivit¨aten
·
und
¶
vom selben Server kontrolliert.
Algorithmus 12 jedesmal auszuf¨uhren, wenn die Gleichheit von Serverzuordnungen getestet werden
soll, bedeutet einen sehr großen Aufwand. Eine effiziente Alternative stellt die einmalige Berechnung
von Serverklassen dar. F¨ur die Aktivit¨aten
·
und
¶
muß danach nur noch gepr¨uft werden, ob sie
derselben Klasse angeh¨oren:
{
Ì.»
{
»Z¹
|
>»¹~¶
~}
-·
:return
{
»Z¹
|
0»¹
#
åÿ
"Ì
=»
{
»¹
|
>»Z¹
#
ÿ
"Ì
»
T
Die Berechnung der Serverklasse
{
»Z¹
|
0»¹
#
åÿ
"Ì
=»
einer Aktivit¨at
·
erfolgt nach Phase 1 und vor
Phase 2 von Algorithmus 6, also direkt nachdem die optimale Serverzuordnung f¨ur
·
(isoliert be-
trachtet) ermittelt wurde. Algorithmus 13 testet, ob die Aktivit¨at
·
in eine der schon ermittelten Ser-
verklassen f¨allt. Dazu wird f¨ur alle Aktivit¨aten
ÿ
, deren Serverklasse schon feststeht, gepr¨uft, ob die
Aktivit¨aten
·
und
ÿ
vom selben Server kontrolliert werden (Funktion
í
ÿ
#»
:
(»¹
{
»Z¹
|
0»¹
#
z¹s»·
z
aus
Algorithmus 12). Falls dem so ist, wurde die Serverklasse von Aktivit¨at
·
gefunden und die Suche
kann beendet werden. Wurde keine Aktivit¨at
gefunden, die diese Bedingung erf¨ullt, so begr¨undet
Aktivit¨at
·
eine neue Serverklasse.
In Phase 2 von Algorithmus 6 k¨onnen sich Serverzuordnungen noch ¨andern, wenn Partitionen
in-
nerhalb derer alle Aktivit¨aten vom selben Server kontrolliert werden, zusammengefaßt werden. Dann
ergibt sich die neue Serverklasse der Aktivit¨aten mit ge¨anderter Serverzuordnung (Partition
) als
Serverklasse der Aktivit¨at
Ì
, deren Serverzuordnung ¨ubernommen wurde:
for each
m#m
å
m#m
æ
;
Eine erneute Berechnung der Serverklassen ist damit nicht notwendig.
4.6.2 Migrationswahrscheinlichkeiten
Die Wahrscheinlichkeiten f¨ur die Migrationen beim ¨
Ubergang von Aktivit¨at
¶
nach
·
k¨onnen in Form
einer Migrationsmatrix angegeben werden. Der Eintrag der
-ten Zeile und
ë
-ten Spalte gibt an, wie
groß die bedingte Wahrscheinlichkeit ist, daß zum Server
ë
migriert werden muß, wenn Aktivit¨at
¶
vom Server
kontrolliert wird. Es gilt also:
»
¡
ì
#í+¹
#¢
¹H¸Hº
î
¤£
{¦¥§E{
´
m¨?©
P(Server
{¦¥
kontrolliert Aktivit¨at
·
§
Server
{
´
kontrolliert Aktivit¨at
¶
)
Damit ergibt sich die Migrationswahrscheinlichkeit als:
29
Algorithmus 12 (Berechnung von
ª
A©
¬«®ª¯°
ñ
6°¬±²R³´µ³#ª¯°
ñ
·¶¹¸»º¼°
¶Ð¦
¾½¿
)
Â
?À Á ÃÂ ÁÄ
;
do
Å3Æ
ÇÈ#É
False;
for each Aktivit¨at
do
for each Aktivit¨at
ÊËÌ
Â
?À Á
do
if
È#À
Å3Æ
TÍÎÀÁÏÐÑÊÓÒ
then
Â
?À Á
Â
?À ÁÕÔ ÂÄ
;
Å3Æ
ÇÈ#É
True;
while
Å3Æ
ÇÈÉ ×Ö Ø~Ù¹ÚÜÛÌ
Â
?À Á
;
if
ÚÌÓ
Â
?À Á
then
return True
else
return False;
ÝÞß#àáâ¦ß
8Ä
Ê
ß
8Ĥå
ãß
8Ä
äåà
¥Ä
ßæçTèÞéæê
:
// die Serverzuordnungen der Aktivit¨aten
oder
Á
sind noch nicht festgelegt:
if
YëµØìÉ Çí ïîðRñ¬ñÓò #ë?ØìÉǼó ïîðRñ¬ñ
then return False;
// Fall aus Abb. 7a:
if
YëµØìÉ Çí
"
#ÐÁYÒ
"
òYëµØìÉ Ç¼ó
"
#ÐÒ
"then return True;
// Fall aus Abb. 7b:
if
YëµØìÉ Çí Yë?ØìÉǼó
then return True;
// Fall aus Abb. 7c:
if
YëµØìÉ Ç í
"
ÍôìÊõÀÇ6Ðö÷TøÐ#ÒÒ
"
Ò¼Ùõ6mYëµØìÉ Ç ó
"
ÍôìÊÀÇ6Ðö¾øTÐøÒ:Ò
"
Ù
ù
Ñmú øÑCöÕûýü·Íþ:ÿÇãÉÇ
Å
À
then return True;
// Fall aus Abb. 7d:
if
YëµØìÉ Ç í
"
ÐNYë?ØìÉÇ
3Ò
"
ÒãÙYë?ØìÉÇ ó
"
ÐN#ë?ØìÉÇ
3Ò
"
Ù
R
ÐNÒ
ÐÒ
then
#ë?ØìÉÇí
#ë?ØìÉÇ
;
#ë?ØìÉǼó
#ë?ØìÉÇ
;
return
Êõ#Ð
ÑÁ
ÑC#ë?ØìÉÇ
6Ô ÂYë?ØìÉÇí
ÑYë?ØìÉǼó
ÄÒ
;
return False;
#¢
£
{
}
{¦¥
¨?©
{
|¤¢
¤£
{
¨
¡
!
#¢
"
£
{¦¥Y§E{
¨
Im folgenden wird beschrieben, wie die Matrix
¡
#
¢
$
ermittelt wird.
Werden die Aktivit¨aten
%
und
&
stets vom selben Server kontrolliert (
{
('#)*
{
+
|
ã£C}
&
¨ ©
-,
.
), so
muß nie migriert werden, so daß sich
¡
#¢
£
{¥§E{
¨R©
0/21
3
ergibt. Andernfalls bietet die
Nutzung der Server-WV
{
+
|¤¢
£
{¦¥
¨
eine einfache M¨oglichkeit zur Approximation der Migra-
tionswahrscheinlichkeiten. Die Server-WV gibt an, mit welcher Wahrscheinlichkeit sich die Instanz
nach der Migration an Server
{¥
befindet. Die Migrationswahrscheinlichkeiten ergeben sich damit
als:
4
{
}
{¦¥
65
¡
#
¢
$"
¤£
{¥§E{
¨?©
{
+
|¢
m£
{¦¥
¨
Bei dieser Berechnung wird allerdings die Annahme vorausgesetzt, daß die Server der beiden Ak-
tivit¨aten unabh¨angig voneinander gew¨ahlt werden. Das ist jedoch nicht der Fall, wenn z.B. die
Server- und Bearbeiterzuordnungen der beiden Aktivit¨aten jeweils von derselben OE abh¨angen. Des-
halb wird zur Berechnung der Migrationswahrscheinlichkeiten von der Aktivit¨at
%
nach
&
der Al-
gorithmus 14 verwendet, wenn eine Abh¨angigkeit zwischen den Bearbeitern der Aktivit¨aten besteht
(
7&
}
8 %
¬}
:9;=<?>
¡
A@CB#A@
m
).
30
Algorithmus 13 (Berechnen der Serverklassen)
ÊÚ
ED
;
Aktivit¨aten
Á
:
ó ïîðRñ~ñ
;
for each Aktivit¨at
Á¹
Prozeßvorlage do
for each Aktivit¨at
mit
#í6Û
îðRñ~ñ
do
if
È#À
Å3Æ
TÍÎÀÁÏÐÁÑCÒ
then
# ó
í
;
exit loop;
if
m#m ó
îðÕñ¬ñ
then
ÊõÚ # ÊÚ¤#m
GFIH
;
ó
ÊÚ
;
Algorithmus 14 berechnet die tats¨achlichen Migrationswahrscheinlichkeiten, da er alle aufgrund von
J
A'
K:L?.MN
B@
erlaubten Kombinationen von Bearbeitern
.
und
.
¥
f¨ur die Aktivit¨aten
%
und
&
durchl¨auft, die Wahrscheinlichkeit ihres Auftretens berechnet und die bei diesem Paar auftretende
Migration in
¡
#¢
ber¨ucksichtigt. Die Wahrscheinlichkeit, daß Benutzer
.
die Aktivit¨at
%
bearbeitet, betr¨agt
OQPSR
1UT!VWYXZ\[]_^
OQPa`_bdc
WUe
PSR
1UT!VWf]
. Die bedingte Wahrscheinlichkeit, daß Benutzer
.
¥
unter dieser
Voraussetzung Aktivit¨at
&
bearbeitet, betr¨agt
OQP_R
1UT!VAWhg:Z\[i^
OQPj`Sbc
WUe
P_R
1UT!VAWhidZk[]_^
. Mit diesen Wahrscheinlichkeiten ge-
wichtet geht die Migration in
¡
!
#¢
ein. Ergibt die Berechnung von
¡
{
+
|¤¢
£
{¾§
.
¨
bzw.
¡
{
+
|¢
£
{¯§
.
¥
¨
f¨ur das betrachtete Bearbeiterpaar
.
und
.
¥
, daß mehrere Server be-
troffen sind, so werden die Bearbeiter anteilsm¨aßig bei jedem dieser Server ber¨ucksichtigt. Da-
durch ergibt sich der Faktor
¡
{
+
|¢
£
{
§
.
¨
l
¡
{
|¤¢
£
{¦¥Y§
.
¥
¨
. Durch die abschlie-
ßende Normalisierung wird
¡
#¢
noch in eine Form gebracht, bei der die Summe jeder
Zeile 1 ergibt. Damit stellt die Zeile
{
G
die bedingte Wahrscheinlichkeit dar, mit der zum Server
{¦¥
migriert werden muß, wenn Aktivit¨at
%
vom Server
{
kontrolliert wird. Zeilen der Form (0
...0) ergeben sich, wenn Server
{
die Aktivit¨at
%
nie kontrolliert und sind deshalb nicht relevant
(
{
+
|¢
£
{
¨÷©
nmpo
#
¢
$"
¤£N3}
Sq
¨ ©
{
+
|¢
£
{
¨
+
¡
#
¢
$"
¤£
{¥§E{
¨¾©
nm
).
Sie k¨onnen deshalb bei der Normalisierung mit beliebigen Werten belegt werden. Im Anhang B.2
wird bewiesen, daß im Algorithmus 14 alle F¨alle ber¨ucksichtigt werden und daß die Faktoren korrekt
gew¨ahlt sind.
Algorithmus 14 (Migrationswahrscheinlichkeiten (keine Unabh¨
angigkeit))
for each
Ñ
r
do
ÍôCÿ
ts
ÀNÈRìTø
duAv
óÐN
rNw
Ò
ID
;
x
ÊõÏÈ#
"y
À
ÅmÆ
Ï
{zI|N}~SYM!daf
x
2y
?À
Å3Æ
Ï
!u
ÐØÒ
;
for each
Ø
r
ÓÕìÏö¾Tø
u
do
ÍôCÿRìTø
u
ÐN
w
Ø
Ò ÍôCÿÐýÚ¼Ñ
"
ö¾Tø Ø
"
Ò
;
ö¾Tø
|A
 Ø
w
Å
ÏìTÕìTmÀøÐÚ¼Ñ:Ø
r
ÑCÁÑ:ØÒ Ö ØÄ
;
x
mÊõÏÈ
2y
?À
Å3Æ
Ï
ÐØ
r
3Ò
z|N}M!da=
x
2y
?À
Å3Æ
ÏóÐýØÒ
;
for each
Ø
Rö¾ø
|
do
ÍôCÿRìTø
du
Ð
w
Ø
mÒ ÍôCÿÐÁÑ
"
ö÷Tø Ø
t
"
Ò
;
for each
ÑC
do
ÍôCÿ
ts
ÀNÈRìTø
uv
óÐ
w
Ò ÍôCÿ
ts
ÀNÈRìTø
uv
óÐ
w
Ò
F
r" : |!
!SGU!rk"
rk"h |2
!SGU!rk"Y |!
ÍôCÿRìTø
u
Ð
w
Ø
Ò
ÍôCÿ6mRìTø
u
ÐN
rw
Ø
3Ò
;
normalisiere jede Zeile von
ÍôCÿ
ts
ÀNÈRìTø
uAv
óÐN
w
Ò
so, daß
zE
ÍôCÿ
ts
ÀNÈRìTø
uv
óÐ
w
Ò
H
;
31
Der mit dem soeben beschriebenen Algorithmus behandelte Fall ist in der Praxis sehr relevant, da
WFs h¨aufig f¨ur die Dauer mehrerer Aktivit¨aten innerhalb derselben OE verbleiben. Außerdem bilden
die Benutzer einer OE oft exakt einen Domain. Angenommen, in dem in Abb. 2 dargestellten Beispiel
werden die Serverzuordnungen
L?.
BK@C¡
©
"
¢
)£'#¤!@
£
J
A'
K
£
=%
¨¨
"und
rL¥.M
B@
¡2¦
©
"
¢
)£'#¤!@
£
J
A'
K
£
&
¨¨
"verwendet, so sind die Server der Aktivit¨aten
&
und
&t§
nicht unbedingt gleich
(siehe Abb. 7). Wird weiter angenommen, daß zwei Server jeweils mit der Wahrscheinlichkeit 0,5
verwendet werden, so ergibt sich durch die einfache Approximation vom
¡
¤
#
¢
$
¡
¡2¦
£
!
¥Y§
¨
durch
¢
¡2¦
£
!
¥
¨
eine Migrationswahrscheinlichkeit von 50%. In Wirklichkeit tritt aber keine
Migration auf. Algorithmus 14 ber¨ucksichtigt dies, da bei allen Kombinationen von Bearbeitern f¨ur
die Aktivit¨aten
&
und
&t§
jeweils derselbe Server (n¨amlich der in der OE dieser Bearbeiter) ermittelt
wird, womit sich
¡
¤
#¢
¡
¡2¦
£
!
¥§
¨ ©
¨/©K]
©Ni
ergibt. Befindet sich lediglich der Großteil
der Benutzer einer OE im selben Domain, so ergibt sich ann¨ahernd
¡
¤
#¢
¡
¡2¦
£
!
¥§
¨Ü©
/©K]
©Ni
. In beiden F¨allen wird erkannt, daß die Migrationskosten wesentlich niedriger sind, als wenn
Unabh¨angigkeit angenommen worden w¨are.
4.7 Einsparen von Migrationen
Mit den bisher gezeigten Verfahren lassen sich die Kosten f¨ur jede beliebige Verteilung berechnen.
Algorithmus 6 analysiert – f¨ur jede Aktivit¨at isoliert betrachtet – alle relevanten Serverzuordnungen.
Damit ist nach der Phase 1 die optimale Verteilung bekannt, allerdings ohne Ber¨ucksichtigung der
Migrationskosten. In der Phase 2 werden diese mit einbezogen, indem ¨uberpr¨uft wird, ob die Mi-
grationen rentabel sind. Dabei wird untersucht, ob es g¨unstiger ist, einige von ihnen wegzulassen,
indem man Partitionen zusammenfaßt (d.h. demselben Server zuordnet). Im statischen Fall ist dieses
Zusammenfassen sehr einfach m¨oglich, indem die Serverzuordnungen (IDs von WF-Servern) ent-
sprechend ersetzt werden. Bei variablen Serverzuordnungen ist dies wegen der Abh¨angigkeiten der
Serverzuordnungen voneinander nicht so einfach m¨oglich. In diesem Abschnitt wird untersucht, wel-
che Problemf¨alle auftreten k¨onnen und wie Partitionen trotzdem zusammengefaßt werden k¨onnen.
4.7.1 Zusammenfassen mit nachfolgenden Partitionen
Das Zusammenfassen mit einer auf die Partition P folgenden Aktivit¨at
)
ist nicht immer m¨oglich
(vgl. Abb. 8a). Es kann vorkommen, daß die zur Auswertung von
rL¥.M
B@
c
notwendigen Lauf-
zeitdaten, zum Zeitpunkt der Ausf¨uhrung der ersten Aktivit¨at
@
dieser Partition
¢
, noch nicht exi-
stieren. Dieser Fall tritt auf, wenn sich
L?.
BK@
c
auf den Server oder Bearbeiter einer Aktivit¨at
)
§
bezieht (
)
§
©
ǻ
N¬
@C®AB#¯°®
£
)
¨
) und
)
§
keine Vorg¨angeraktivit¨at von
@
ist. Beim Zusamen-
fassen entlang einer normalen Kontrollkante tritt dieser Fall auf, wenn
)
§>
¢
gilt (Abb. 8a). Soll
entlang einer Synchronisationskante zwischen Aktivit¨aten paralleler Zweige (Abb. 8b) bzw. entlang
einer Schleifenr¨ucksprungkante (Abb. 8c) zusammengefaßt werden, so kann es sich bei
)
auch um
eine Aktivit¨at in einem parallelen Zweig bzw. um eine Nachfolgeraktivit¨at von
¢
handeln. In all die-
sen F¨allen ist diese Art des Zusammenfassens nicht m¨oglich. Im Fall a und c kann die Migration
trotzdem weggelassen werden, indem man der Partition von Aktivit¨at
)
den Server von
¢
zuordnet,
also ”andersherum“ zusammenfaßt.
Das Problem, eine Partition
¢
vom selben Server kontrollieren zu lassen, wie die Aktivi¨at
)
, kann
in mehrere Teilprobleme zerlegt werden:
4
@
>
ï¢
soll die Aktivit¨at
@
vom selben Server kontrolliert
werden, wie die Aktivit¨at
)
. Der Algorithmus 15 versucht f¨ur die Aktivit¨at
@
eine Serverzuordnung
32
±
²d³ ´µ ¶G¶G¶ ·¸ ¹
ººººººº »ººººººº ¼
½ ¾
¿À
Á ÂGÂGÂ ÃÄ Ä
ÅÅÅÅÅÅÅ ÆÅÅÅÅÅÅÅ Ç
È É
ÊË Ê
ÌË
ÍÎ$ÏÑÐAÒ(ÓÔÕÍ
ÖGÖGÖ
×dØ Ù ÚGÚGÚ
ÛÛÛÛÛÛÛ ÜÛÛÛÛÛÛÛ Ý
Þ ß
àá âGâGâ ãä ã
åä ä
æç$è°éê+êGëìæ
Abbildung 8 Die Partition
soll vom Server der Aktivit¨at
bzw.
í
kontrolliert werden.
zu berechnen, so daß
@
vom selben Server kontrolliert wird, wie die Aktivi¨at
)
. Eine Aktivit¨at
@
dem Server einer Vorg¨angeraktivit¨at
)
zuzuordnen ist stets m¨oglich, indem die Serverzuordnung
rL?.
BK@î
©
"
£
)
¨
"verwendet wird. Schwieriger ist der Fall, wenn
)
keine Vorg¨ange-
raktivit¨at von
@
ist. Wird f¨ur Aktivit¨at
)
eine statische Serverzuordnung verwendet, so kann diese
f¨ur
@
¨ubernommen werden. Lautet
rL?.
BK@
c
©
"
£
fï
¨
", so muß
ï
eine Vorg¨angeraktivit¨at
von
)
sein. Deshalb besteht die Chance, daß
ï
auch eine Vorg¨angeraktivit¨at von
@
ist, womit die
Aktivit¨at
ï
in
rL?.
BK@ î
referenziert werden darf. Da bei Verwendung dieser Serverzuordnung
die Server von
)
und
ï
identisch sind, wird rekursiv versucht, die Aktivi¨at n dem Server von
ï
zuzu-
ordnen. Wird die Aktivi¨at
)
vom Server im Domain des Bearbeiters einer Aktivit¨at
ï
kontrolliert, so
ergibt sich
îEð
c
, wenn
L?.MN
B@î
©
"
ñ¢
)£'#¤!@
£
J
A'
K
£
fï
¨¨
"verwendet wird.
Dies ist aber nur m¨oglich, falls die Aktivit¨at
ï
in
L?.MN
B@î
referenziert werden darf. Andern-
falls ist das Zusammenfassen von
@
und
)
nicht m¨oglich. Enth¨alt
rL?.
BK@
c
eine Funktion
¬
,
so muß diese auch auf
òÑNr
L?.MN
B@
angewandt werden; ansonsten verl¨auft die Berechnung wie
bei den vorherigen beiden F¨allen. Wird f¨ur Aktivi¨at
)
ein vom Modellierer vorgegebener Serverzu-
ordnungsausdruck verwendet, der nicht Typ 1-5 aus Abschnitt 4.3.1 entspricht, so kann die Semantik
dieses Ausdrucks nicht verstanden werden, so daß das Zusammenfassen nicht m¨oglich ist. Der Aus-
druck kann nicht einfach f¨ur Aktivit¨at
@
¨ubernommen werden, da die Werte von darin verwendeten
Datenelementen bei der Ausf¨uhrung von Aktivit¨at
@
evtl. noch nicht feststehen.
4.7.2 Abh¨
angige Aktivit¨
aten
Beim Zusammenfassen von Aktivit¨aten werden die Serverzuordnungen der Aktivit¨aten
¡
ó>
¢
ge¨andert. Dies kann unerw¨unschte Auswirkungen auf eine Aktivit¨at
@
haben, die sp¨ater im Ablauf
folgt. Soll diese Aktivit¨at nicht vom Zusammenfassen betroffen sein (
@õô
>
¢
), so darf die Wahl des
Servers f¨ur diese Aktivit¨at nicht durch die ¨
Anderung beeinflußt werden. Bei den folgenden Serverzu-
ordnungen der Aktivit¨at
@
tritt ein Problem auf (es gilt jeweils
)
>
¢
):
1.
L?.
BK@ î
©
"
ã£
)
¨
"
2.
L?.
BK@î
©
"
¬
£
!
ã£
)
¨¨
"
Der Algorithmus 16 berechnet f¨ur die Aktivit¨at
@
eine Serverzuordnung
ò$
L?.
BK@
, so
daß, trotz ver¨anderter Serverzuordnungen der Aktivit¨aten
¡
ö>
¢
, der Server von Aktivit¨at
@
un-
ver¨andert bleibt. Im ersten oben beschriebenen Problemfall l¨aßt sich Unabh¨angigkeit von der ¨
Ande-
33
Algorithmus 15 (
÷
º
MøQù2ú+û
?ª÷¶Ü±
ü
³« ³Yª¯°
ý
·¶¹¸»º¼°
øQü
¾½¤³
þ
°
tÿ
ªÕ°
ý
·¶õ¸ º°
øQü
¿
ºº
ü
)
// Aktivit¨at
Ê
darf in
#ë?ØìÉÇ
referenziert werden
if
R
ì
:y
ÉÐýÇÑÊÓÒ
then
È#6mYëµØìÉ Ç
"
#ÐýÊÓÒ
";
return True;
// Aktivit¨at
Ê
darf in
#ë?ØìÉÇ
nicht referenziert werden
case
Yë?ØìÉÇ
"
":
È#6mYëµØìÉ Ç
"
";
return True;
case
Yë?ØìÉÇ
"
6mÐÒ
":
return
s
ÃìÉ À
!tí
Y¬ë¾ÐýÇÑ:ÑCYëµØìÉ Ç
Ñ
È#6mYëµØìÉ Ç¼Ò
;
case
Yë?ØìÉÇ
"
ÍþìÊõÀÇ6Ðö÷TøÐÒÒ
":
if
R
ì
:y
ÉÐýÇÑ:NÒ
then
È#6mYëµØìÉ Ç
"
ÍôìÊõÀÇ6Ðö÷TøÐÒ:Ò
";
return True;
else
return False;
case
Yë?ØìÉÇ
"
¦ÐN#ÐNÒÒ
":
ZusammenfassenM¨
oglich =
s
ÃìÉÀ
!tí
#~ë¯ÐÇÑ:Ñ#ë?ØìÉÇ
Ñ
mÈY#ë?ØìÉÇ
oÒ
;
if ZusammenfassenM¨
oglich then
È#6mYëµØìÉ Ç
"
¦Ð
ÈYYë?ØìÉÇ
Ò
";
return True;
else
return False;
case
Yë?ØìÉÇ
"
¦ÐÍôìÊÀÇ6Ðö¾øTÐÒ:ÒÒ
":
if
R
ì
:y
ÉÐýÇÑ:NÒ
then
È#6mYëµØìÉ Ç
"
¦ÐÍôìÊÀNÇ6Ðö¾TøÐNÒÒÒ
";
return True;
else
return False;
default case: // vom Modellierer vorgegebener Ausdruck
return False;
rung erreichen, indem
L?.
BK@
c
als
L?.
BK@î
verwendet wird. Dadurch wird Akti-
vit¨at
@
von dem Server kontrolliert, der f¨ur Aktivit¨at
%
und damit auch f¨ur
)
geplant war. Dazu
wird in Algorithmus 16
L?.
BK@ î
durch
rL¥.M
B@
c
ersetzt. Die Rekursion ist notwen-
dig, falls in der neuen
L?.MN
B@î
weiterhin eine Aktivit¨at
¡
>
¢
referenziert wird. Lautet
rL?.
BK@î
©
"
¬
£
!
ã£
)
¨¨
", so kann
L?.MN
B@
c
nicht direkt ¨ubernommen werden.
Wird auf
L?.
BK@
c
aber noch die Funktion
¬
angewandt, so bleibt der Server von Aktivit¨at
@
unver¨andert. Bei allen anderen Serverzuordnungen von Aktivit¨at
@
kann diese unver¨andert ¨uber-
nommen werden, da sich durch die ¨
Anderung der Serverzuordnungen f¨ur Partition
¢
nur der Server
der entsprechenden Aktivit¨aten ¨andert.
Alle anderen Daten bleiben unver¨andert und k¨onnen deshalb
weiterhin referenziert werden. Die Seiteneffekte auf Aktvit¨aten
@ ô
>
¢
lassen sich also stets beheben.
Deshalb gibt es keine F¨alle, in denen sie das Zusammenfassen von Partitionen verhindern.
]]
Wird in einer Serverzuordnung vom Typ 5 der Server einer Aktivit¨at
referenziert, so muß auch dieser Teil der
Serverzuordnung (wie beschrieben) ersetzt werden.
34
Algorithmus 16 (
+û
ü
"!
ý
#%$&'!
øQü
)(*
þ
!
tÿ
+,"!
ý
#-$&'!
øQü
.
/01
ü
)
case
24365678
?Øì
95
ÉÇ
;:
"
2436597<365
#ÐýÊÓÒ
":
if
Ê
>=?
then
2436597@8
?Øì
95
ÉÇ
:A2436597@8
?Øì
95
ÉÇ
; // in
2436597@8
?Øì
95
ÉÇ
wird
24365678
?Øì
95
ÉÇ
ge¨andert
B
ìÿ
í
2C8
¾ÐýÇÑ
D?
Ñ
D2436597@8
?Øì
95
ÉÇ
TÑ
5
È
24365678
?Øì
95
ÉǼÒ
;
else
5
È
@2E3F5978
µØì
95
É Ç
G:
"
2436567365
#ÐýÊÓÒ
";
case
24365678
?Øì
95
ÉÇ
:
"
¦Ð
H2E3F597365
ÐÊÒ:Ò
":
if
Ê
>=?
then
2436597@8
?Øì
95
ÉÇ
:
"
¦Ð
H2E3F5978
µØì
95
É Ç
Ò
"; // in
2436597@8
?Øì
95
ÉÇ
wird
24365678
?Øì
95
ÉÇ
ge¨andert
B
ìÿ
í
2C8
¾ÐýÇÑ
D?
Ñ
D2436597@8
?Øì
95
ÉÇ
Ñ
5
È
24365678
?Øì
95
ÉǼÒ
;
else
5
È
@2E3F5978
µØì
95
É Ç
G:
"
¦Ð
H2436597<365
#ÐýÊÓÒÒ
";
default case: // statische Serverzuordn., Bearbeiter referenziert, sonstiger vorgegebener Ausdruck
a
5
È
@2E3F5978
µØì
95
É Ç
G:I2436597@8
?Øì
95
ÉÇ
;
4.7.3 Verteilungsalgorithmus
Wie wir in den vorherigen Unterabschnitten gesehen haben, kann bei variablen Serverzuordnungen
in Phase 2 von Algorithmus 6 eine zu analysierende Verteilung (
,
KJKL
L?.MN
B@
CM
) nicht durch
das direkte ¨
Ubernehmen der Serverzuordnungen erzeugt werden. Stattdessen m¨ussen die Funktio-
nen
B¤_¬
/N
L
und
O
$
FP
N
L
verwendet werden. Damit ergibt sich die folgende ¨
Anderung f¨ur die
Phase 2 von Algorithmus 6:
4.8 Verhalten zur Ausf¨uhrungszeit der WFs
Die bisher beschriebenen Algorithmen laufen zur Modellierungszeit ab. Zur Ausf¨uhrungszeit der WFs
m¨ussen nur die Serverzuordnungen ausgewertet werden. Dies geschieht nach Beendigung jeder Akti-
vit¨at f¨ur alle direkten Folgeaktivit¨aten, indem die referenzierten Laufzeitdaten der WF-Instanz einge-
setzt werden. Wird dabei ein Server ermittelt, der vom aktuellen verschieden ist, so wird die Migration
der WF-Instanz angestoßen. Migration bedeutet, daß die von den Vorg¨angeraktivit¨aten erzeugte Sta-
tusinformation und die Variablenwerte zum neuen Server transportiert werden. Um die Datenmenge
klein zu halten werden nur die aktuell g¨ultigen Variablenwerte ¨ubertragen und auf deren Historie
verzichtet. Die zu transportierende Datenmenge kann noch reduziert werden (z.B. Daten nicht ¨uber
mehrere parallele Zweige zum selben Join-Knoten transportieren), auf diese Optimierungsm¨oglich-
keiten soll in dieser Arbeit aber nicht eingegangen werden.
Durch die Verwendung variabler Serverzuordnungen ergibt sich an Synchronisationspunkten (Akti-
vit¨aten an denen parallele Zweige zusammengef¨uhrt werden oder Synchronisationskanten eingehen)
eine Schwierigkeit. Da der WF-Server der Synchronisationsaktivit¨at von jeder beliebigen Vorg¨ange-
raktivit¨at abh¨angig sein kann, ist dieser Server evtl. nicht in allen parallelen Zweigen bekannt. In dem
in Abbildung 9 dargestellten Beispiel kann nach Beendigung von Aktivit¨at
®
mit den zur Verf¨ugung
stehenden Daten nicht berechnet werden, von welchen Server die Nachfolgeraktivit¨at
kontrolliert
wird. Dies h¨angt von Daten (Bearbeiter der Aktivit¨at
B
) des unteren Zweiges ab, die im oberen Zweig
nicht zur Verf¨ugung stehen, da sie auf einem anderen WF-Server liegen. Deshalb kann die Migration
von Aktivit¨at
®
nach
nicht ausgef¨uhrt werden.
35
Erg¨
anzte Version von Algorithmus 6
...
Phase 2:
s
ÀÇ
B
ì
RQ
mÏ
4:
Å
TSU
Å
Ø
UVS
Ï
W3
Å
ì
RQ
3Ï
XQ
Ð
Y24365678
?Øì
95
ÉÇ
TÑ
SUVU
Ò
; /* Kosten gesamter WF (mit Migrationskosten) */
for PartGr¨
oße = 1 to #Aktivit¨
aten(Prozeßvorlage) do
for each
?[Z
#w
?
$w
K:
PartGr¨
oße
Ù
\?
ist max. Teilgraph mit
U
Ñ
U
]=?[Z^2
S
Ê
3_2436567365
#Ð
U
Ñ
U
mÒ
do
`
ÿÏ
!
Å
Ï
C:
îðRñ~ñ
;
for each
S
Û
=?[Z^a
U
=b?cZ
S
=?]593
É
@dfe0g0h+i*jg0k l
v
m
h+e l
v
kg0g
~
l/n
Ð
U
Òò
S
=b2
¦Ø
Å3Å
dfe0g0h+i*jg0k l
v
<m
h+e l
v
kg0g
~
l/n
Ð
U
Ò
do
ZusammenfassenM¨
oglich
:
Ö
5
Ø
"3
;
for each
U
=b?
do
if not
s
ÃìÉÀ
!tí
@2o8
¯Ð
U
Ñ
S
Ñ
124365678
?Øì
95
ÉÇ
Ñ Ö
39Q
mÏ
X24365978
µØì
95
É ÇíýÒ
then
ZusammenfassenM¨
oglich
:qp
SU
Q63
;
if ZusammenfassenM¨
oglich then
for each
U
Û
=?
do
B
ìÿ
#í
2C8
¯Ð
U
Ñ
D?
Ñ
D2436597@8
?Øì
95
ÉÇ
Ñ Ö
3_Q
mÏ
X2436597@8
?Øì
95
ÉÇíýÒ
;
Ö
3_Q
3Ï
B
ì
RQ
mÏ
4:
Å
TSU
Å
Ø
UHS
Ï
W3
Å
ì
RQ
mÏ
XQ
Ð Ö
3_Q
mÏ
X2436597@8
?Øì
95
ÉÇ
Ñ
SUVU
Ò
;
if
Ö
3_Q
mÏ
B
ì
RQ
3Ï
#r
s
ÀÇ
B
ì
RQ
mÏ
then
`
ÿ¤Ï
!
Å
Ï
C:
S
;
s
ÀÇ
B
ì
RQ
mÏ
E:
Ö
3_Q
mÏ
B
ì
RQ
mÏ
;
if
`
ÿÏ
!
Å
Ï»Û
:
îðRñ¬ñ
then
for each
U
=b?
do
s
ÃìÉ À
!tí
2C8
¾Ð
U
Ñ
S
Ñ
D2436597@8
?Øì
95
ÉÇ
ÑÖ
3_Q
3Ï
X2E3F5978
µØì
95
É Ç íÒ
;
s t
uRv'w x
uRv'w y z {
|
}_~
}_~ o46 K D_H
o46 K DRY
DRY
DRV
Abbildung 9 Beispiel f¨ur einen WF, bei dem der Server der Join-Aktivit¨at
3
nicht in allen parallelen Zweigen
berechnet werden kann.
Welche M¨oglichkeiten gibt es nun, die ben¨otigte Information (Zielserver der Migration) den betrof-
fenen Quellservern zur Verf¨ugung zu stellen? Die ID des Zielservers direkt an alle betroffenen Quell-
server der Migration zu senden, ist leider nicht m¨oglich, da diese ihrerseits nicht immer allgemein
bekannt sind. So ist in Abb. 9 nach Beendigung von Aktivit¨at
B
im unteren Zweig nicht bekannt,
welcher Server die Aktivit¨at
®
im oberen Zweig kontrolliert. Die ben¨otigte Information kann nat¨urlich
verbreitet werden, indem bei Erreichen einer Join-Aktivit¨at der entsprechende Server per Broadcast
allen anderen Servern des WfMSs bekannt gemacht wird. Dies f¨uhrt in großen Systemen allerdings
zu sehr vielen unn¨otigen Nachrichten. Eine weitere M¨oglichkeit ist, einen bestimmten Server zur In-
formationsvermittlung zu verwenden. Dies verschlechtert aber die Verf¨ugbarkeit des WfMSs, weil es
blockiert ist, wenn diese zentrale Informationsvermittlung ausf¨allt. Da zu einem fest gew¨ahlten Punkt
kommuniziert wird, wird auch dann weit entfernte Kommunikation notwendig, wenn sich alle Ser-
ver und die Klienten eines WFs in einem r¨aumlich beschr¨ankten Gebiet befinden. Es ist vorteilhaft,
die Struktur des WFs auszunutzen, um die ben¨otigte Information zu verbreiten. Der folgende Ansatz
macht dies.
Algorithmus 17 beschreibt den Ablauf einer Migration zur Aktivit¨at
,
'
RL
a¯ ®
6L
. Kann der WF-
Server
dieser Aktivit¨at im aktuellen Zweig berechnet werden, so wird mit Hilfe der WF-Vorlage
36
die Menge
AB
"14E¡¢¤£'4¥ ¦
©
§
¡¨ ¦o©<ª
,
'
_L
j¯ ®
FLT«
der direkten Vorg¨angeraktivit¨aten des Mi-
grationsziels berechnet. Die Server dieser Aktivit¨aten m¨ussen das Migrationsziel kennen. Gibt es
in
AB
14E¡¢¤£'4¥ ¦
©
§
¡¨ ¦o©
ª
,
'
_L
j¯ ®
FLT«
eine Aktivit¨at
, die keine Nachfolgeraktivit¨at der in
rL?.
BK@
¢
b
¬
e
P
W
®
MTW
referenzierten Aktivit¨at
%
ist, so kann der Server von
den Migrationszielser-
ver
nicht berechnen. In diesem Fall wird ihm
wie folgt mitgeteilt:
wird an einen Dispatcher
gemeldet (
¯
L
_¤_¬
/N
¤
'
°L
a¤
@
±ªW«
), der ¨uber einen Zuordnungsausdruck (¨ahnlich wie die WF-Server)
f¨ur jede Synchronisationsaktivit¨at festgelegt ist. Bei diesem Dispatcher kann der WF-Server der Ak-
tivit¨at
den Migrationszielserver
erfragen. Damit der Zuordnungsausdruck des Dispatchers von
diesem Server ausgewertet werden kann, muß der Zuordnungsausdruck statisch sein oder es muß ei-
ne Aktivit¨at referenziert werden, die Vorg¨anger aller
>
²
$
B
14E¡³¢/£/4¥ ¦
©
°§
¡& ¦o© ª
,
'
_L
j¯°®
6LT«
ist. Wenn der Zielserver
einer Migration nicht berechnet werden kann, so wird dieser beim Dis-
patcher erfragt (
´
@ ¬
¤
'
L
_¤
@
±ªW«
). Verf¨ugt der Dispatcher noch nicht ¨uber die ben¨otigte Informa-
tion, so wird vor der Wiederholung der Anfrage eine gewisse Zeit gewartet. Um Kommunikationen
einzusparen, ist es auch m¨oglich, diese Anfragen Huckepack [Tan92] mit anderen Nachrichten zu
transportieren.
Algorithmus 17 (Migration zur Aktivit¨
at
µbo!
tÿ
E*¶_·¸¶
)
if (
¹º:q¹4365978»"¼95_½K¾
i
f¿
®À
=
) kann berechnet werden then
if
¹4365978»"¼95_½K¾
i
f¿
®À
=
referenziert Aktivit¨at
Á;Â
Ã
7=b?]5_39½dfe'g0h+ijg'k l
v
m
h+e l/n^Ä®Å
S
56Æ@36Ç
!
±ÈÉÇXÊ
:
7=\¹¤»"ÈTÈFdfe'g0h+ijg'k l
v
m
h#e l/nKÄ®Á*Ê
then
Ë
¼9ÇÌ
!tíKs
ÍÌHÆ5
S
Ç̼9¾EÄHÎK¾0QFÇWÎ<½°ÏfÅ
S
56Æ36Ç
!
±ÈTÇÉÏD¹EÊEÐ*ÑÓÒ;ÌWQ
:ÿ
S
ÇWÈÔ365
i
X¿
df
®À
=
;
else
Nachfragen:
¹:AÎ^¾
"¼
As
ÍÌYÆ<5
S
Ç̼9¾EÄVÎ^¾0QFÇWÎ^½ÏXÅ
S
56Æ@3FÇ
!
&ÈÉÇXÊCÐ*ÑÓÒ;ÌWQ
:ÿ
S
ÇWÈÔ365
i
X¿
df
®À
=
;
if
¹º:Õ»*¾0Ö¾¼
:y
³¾
then wait;goto Nachfragen;
s
ÍÌYÆ<5
S
ÇW3ÄVÎ^¾0QFÇ
S
¾È39ÊoÐÑ×¹+Ø
Das in Algorithmus 17 beschriebene Verfahren ist recht effizient, da nur wenige sehr kleine Nach-
richten ausgetauscht werden. Es kann aber noch optimiert werden. Um mehrfache Aufrufe von
´
@ ¬
¤
'
L
_¤
@
±ªW«
zu vermeiden, kann sich der Dispatcher noch nicht beantwortbare Anfragen mer-
ken und beantworten, sobald er die ben¨otigte Information besitzt.
Nach Beendigung einer Aktivit¨at findet der ¨
Ubergang zu den Nachfolgeraktivit¨aten asynchron statt.
Deshalb kann dies ¨uberlappend geschehen. Warum diese Asynchonit¨at notwendig ist, wird anhand
von Abb. 10 erl¨autert: Wird zuerst mit der Signalisierung der Synchronisationskante
Ù
begonnen,
so kann die Aktivit¨at
®
erst gestartet werden, wenn diese Aktion abgeschlossen ist. Dies ist nach
Algorithmus 17 erst m¨oglich, wenn der WF-Server von Aktivit¨at
feststeht. Da dies aber u.U. erst sehr
viel sp¨ater der Fall ist, wird die Ausf¨uhrung der Aktivit¨at
®
unzul¨assigerweise verz¨ogert. Durch den
asnchronen (¨uberlappenden) ¨
Ubergang von Aktivit¨at
nach
und von
nach
®
wird dies vermieden.
Ú Û
Ü Ý
Þ
ß à
á
âDãDäÉåHæDçéèXäÉê ëìYíê èXäTë®î
ïìHäDíð
ñ
Abbildung 10 Synchronisation mit einer Aktivit¨at aus eine exklusiven Verzweigung.
Steht der gew¨ahlte Zweig einer exklusiven Aufspaltung (z.B. bei Aktivit¨at
B
in Abb. 10) fest, so er-
gibt sich im ADEPT-Modell [RD98] f¨ur die Aktivit¨aten aller anderen Zweige der Zustand
J
&
¤
PP
AB
.
37
Wird z.B. der Zweig der Aktivit¨at
gew¨ahlt, so k¨onnen die Aktivit¨aten
und
¬
nicht mehr ausgef¨uhrt
werden, so daß sich der Zustand
J
&
¤
PP
B
ergibt. Wie im zentralen Fall werden dann alle von diesen
Aktivit¨aten ausgehenden Synchonisationskanten signalisiert (falls es z.B. in Abb. 10 eine Synchonisa-
tionskante von
¬
nach
®
g¨abe, so w¨urde diese nach Beendigung von Aktivit¨at
B
und der Entscheidung
f¨ur den unteren Zweig signalisiert). Dies wird von dem Server durchgef¨uhrt, der die Berechnung die-
ses Zustands durchf¨uhrt, also in diesem Beispiel vom Server der Aktivit¨at
B
. Es findet also keine
Migration zu dem f¨ur Aktivit¨at
¬
vorgesehenen Server statt, um die Synchronisationskante
¬
Ù
®
zu
signalisieren. Dadurch wird eine Migration vermieden, die (weil die Aktivit¨at
¬
¨uberhaupt nicht aus-
gef¨uhrt wird) unn¨otig ist. Außerdem gibt es F¨alle, in denen der Server der Aktivit¨at
¬
nicht bestimmbar
ist, so daß auch nicht zu ihm migriert werden kann. So ist
L?.
BK@
Cò%ó
"
ñ¢
)£'#¤!@
±ª
J
A'
K
ª
^«É«
"
zul¨assig, da
immer vor
¬
ausgef¨uhrt wird, falls
¬
ausgef¨uhrt wird. Diese Serverzuordnung kann im
vorliegenden Fall aber nicht ausgewertet werden, da die Aktivit¨at
nicht ausgef¨uhrt wird.
Wird in dem in Abb. 10 dargestellten Beispiel der untere Ausf¨uhrungszweig (Aktivit¨at
) gew¨ahlt,
so ergibt sich eine Schwierigkeit bei der Signalisierung der Synchronisationskante
ôÙ
. Da die
Aktivit¨at
nicht ausgef¨uhrt wird, gibt es auch keinen WF-Server, der ihre Ausf¨uhrung kontrolliert.
Das Problem ist nun, daß die Aktivit¨at
in der Schleife von Algorithmus 17 st¨andig versucht, diesen
Server vom
ñ
¤
fJ
P
'
°L
j®
_õ
P
zu erfragen. Damit dieser Vorgang terminiert, muß auch dann ein Server
an den Dispatcher gemeldet werden, wenn die Aktivit¨at nie ausgef¨uhrt wird, sondern den Zustand
J
&
¤
PP
B
erreicht
Xö
. F¨ur die ausgelassenen Aktivit¨aten kann z.B. der Server gemeldet werden, der die
Berechnung des Zustandes durchf¨uhrt; hier also der Server der Aktivit¨at
B
. Ist diese Information beim
ñ
¤
fJ
P
'
°L
j®
_õ
P
verf¨ugbar, so kann die Synchronisationskante
÷Ù
signalisiert werden, so daß die
Bearbeitung der Aktivit¨at
beendet werden kann.
Es bleibt noch zu kl¨aren, wie der Zuordnungsausdruck f¨ur den Dispatcher gew¨ahlt werden soll. Da
mit dem Dispatcher nur kleine Nachrichten ausgetauscht werden, ist es eine akzeptable M¨oglich-
keit, die vom Algorithmus 6 berechnete beste statische Serverzuordnung zu verwenden. Eine ein-
fache Alternative dazu stellt die Verwendung des Startservers der WF-Instanz dar. Um eine hohe
Lokalit¨at zwischen den Aktivit¨aten aus
AB
14E¡¢¤£'4¥ ¦
©
§
¡¨ ¦#© ª
,
'
_L
j¯ ®
FLT«
und dem Dispat-
cher zu erhalten, sollte aber der Server einer Aktivit¨at gew¨ahlt werden, die im WF-Ablauf nahe bei
,
'
_L
j¯°®
6L
liegt. Hierf¨ur bietet sich z.B. der letzte gemeinsame Vorg¨angeraktivit¨at der Aktivit¨aten
>
º
AB
14C¡¢/£/4¥ ¦
©
§
¡¨ ¦o© ª
,
'
_L
j¯ ®
FLT«
bzgl. des Kontrollflusses an.
5 Komplexe Bearbeiterzuordnungen
Wie wir gezeigt haben k¨onnen Bearbeiterzuordnungen von vorausgehenden Aktivit¨aten abh¨angig sein.
Es ist sogar m¨oglich, daß eine Bearbeiterzuordnung von mehreren Aktivit¨aten abh¨angt, z.B. wenn
Aktivit¨aten einer Verzweigung referenziert werden sollen. In Abschnitt 5.1 wird der Zweck solcher
Bearbeiterzuordnungen ausf¨uhrlich diskutiert. Wenn der Modellierer eine komplexe Bearbeiterzuord-
nung f¨ur eine Aktivit¨at
&
verwendet, gibt es zwei prinzipielle Vorgehensweisen beim Ermitteln einer
geeigneten Serverzuordnung f¨ur diese Aktivit¨at:
1. Die Bearbeiterzuordnung wird nicht als abh¨angige Bearbeiterzuordnung (im Sinne von Kapi-
tel 4.1.1) behandelt. Dann wird lediglich die daraus resultierende Bearbeitermenge
$
L
J
A'
¡
(siehe
Abschnitt 4.1.2) ermittelt, um einen geeigneten Server auszuw¨ahlen.
2. Aus der komplexen abh¨angigen Bearbeiterzuordnung wird eine optimale variable Serverzuordnung
]i
Dies muß zumindest dann erfolgen, wenn die Aktivit¨at mehr als eine eingehende Kante vom Typ
ø+ùúüûoý+ùþ ÿ
und
úø ÿ
hat.
38
abgeleitet.
Da im Fall 1 die Abh¨angigkeiten ignoriert werden, ergibt sich f¨ur die Aktivit¨at
&
eine statische Ser-
verzuordnung. Die Vorteile von variablen Serverzuordnungen k¨onnen damit nicht genutzt werden.
Deshalb haben wir uns f¨ur die Variante 2 entschieden. Damit variable Serverzuordnungen automa-
tisch berechnet werden k¨onnen, muß eine Methode entwickelt werden, die es erlaubt, die Kosten im
komplexen Fall zu berechnen. Um die bisher entwickelten Algorithmen weiter nutzen zu k¨onnen, wird
der Fall komplexer abh¨angiger Bearbeiterzuordnungen auf den in Kapitel 4 beschriebenen Fall nicht
zusammengesetzter Bearbeiterzuordnungen zur¨uckgef¨uhrt. Wie dies exakt funktioniert, wird in dem
nun folgenden Kapitel beschrieben.
5.1 Verwendung komplexer Bearbeiterzuordnungen
In Abbildung 11 sind die elementaren F¨alle komplexer Bearbeiterzuordnungen dargestellt. Die-
se k¨onnen zu noch komplexeren kombiniert werden. In den abgebildeten Beispielen wurden stets
Bearbeiterzuordnungen des Typs
ó
"
ª
¤«
"verwendet. Das im folgenden
Gesagte gilt aber auch f¨ur andere Arten von Bearbeiterzuordnungen (z.B.
ó
"
ò
ª
ª
4«
"
«
ï=ï
!
ó
#"""
).
$
%
& ' (
)*
&+
$,-$/.
Ú
01324657-8:9
;<>=@?BADCFEG3HI6JK-J/L
MON>PRQSTFUV3WX6YZ-[:\
]^
[
Y
W
_-`bacdFe!d3fgfghifkjml:nol_-prqtsua6v_@d3awthoe!xFyth3jgz{|z}_@~ra6v
_@3abhi{bho|xv _@aFf-h3j-@hv
6-/
Ú
36-/
o 3 ¡¢@b£¤¢¥36b¦/
o 3 ¡¢@
³ 2
§¨©3ª«6¬-®:¯
°
©i«²±i³«6´©i«¶µ ·©F¸r¹oºk»
¼½¿¾ À-Á¿ÂFÃbÄÅ6ÆÈÇÉËʤÌËÍ:ÎBÏÐBÏ/ÊÑ/ÒÓ Ô
ÕÖ× Ø
ÕÖ×RÙ ÕÖ×RÙ
ÕÖ× Ø
ÚÛ¶Û/ÜrÙ
Abbildung 11 Beispiele f¨ur Bearbeiterzuordnungen, die sich auf mehrere Aktivit¨aten beziehen.
In Abbildung 11a bezieht sich die Bearbeiterzuordnung auf die Aktivit¨aten einer Verzweigung. Ei-
ne zusammengesetzte Bearbeiterzuordnung ist in diesem Fall die einzige M¨oglichkeit, Aktivit¨aten
aus der Verzweigung zu referenzieren. Durch eine einfache Bearbeiterzuordnung kann maximal ein
Zweig referenziert werden. Da dieser aber nicht in allen F¨allen durchlaufen wird, w¨are die Bearbei-
terzuordnung manchmal undefiniert. Deshalb wird jeweils eine Aktivit¨at jedes Zweiges referenziert.
Nat¨urlich ist f¨ur manche der Zweige auch eine unabh¨angige Bearbeiterzuordnung (z.B. ¨uber eine
Rolle) zul¨assig und evtl. auch sinnvoll.
Im Fall einer Parallelit¨at (b) werden stets alle Zweige durchlaufen. Deshalb liefern alle referenzierten
Aktivit¨aten einen Bearbeiter. Die Menge der potentiellen Bearbeiter von Aktivit¨at
Ý
ist die Vereini-
gungsmenge der Bearbeiter dieser Aktivit¨aten. Dasselbe gilt f¨ur Sequenzen (Fall c), da auch hier alle
Aktivit¨aten ausgef¨uhrt werden.
In Abbildung 11d ist eine Schleife dargestellt. Die Bearbeiterzuordnung von Aktivit¨at
Ý
soll sich auf
den Bearbeiter einer (evtl. derselben) Aktivit¨at des vorherigen Schleifendurchlaufs beziehen. Dadurch
ergibt sich das Problem, daß die Bearbeiterzuordnung in der ersten Iteration undefiniert ist. Deshalb
muß dieser Fall in der Bearbeiterzuordnung gesondert behandelt werden, indem sich der Bearbeiter
z.B. aus einer vor der Schleife ausgef¨uhrten Aktivit¨at ergibt. Es k¨onnen nat¨urlich auch f¨ur weitere
39
Iterationen spezielle Bearbeiterzuordnungen festgelegt werden. Entscheidend bei Bearbeiterzuord-
nungen in Schleifen ist aber, daß f¨ur jede Iteration jeweils nur ein Teil der Bearbeiterzuordnung g¨ultig
ist (¨ahnlich wie bei einer Verzweigung).
Die einzelnen Teile der Bearbeiterzuordnungen in (a) - (d) sind OR-verkn¨upft (wenn auch manchmal
nur ein Teil gleichzeitig g¨ultig sein kann). Eine AND-Verkn¨upfung macht wenig Sinn, da es dann von
den konkret gew¨ahlten Bearbeitern bei der WF-Ausf¨uhrung abh¨angig ist, ob ¨uberhaupt noch ein Be-
arbeiter den Zuordnungsausdruck erf¨ullt. Dadurch kann es in Prozessen zu Inkonsistenzen kommen,
die zur Modellierungszeit nicht entdeckt werden k¨onnen.
5.2 Potentiell m¨
ogliche Serverzuordnungen
Auch bei komplexen Bearbeiterzuordnungen werden die in Abschnitt 4.3.1 beschriebenen Serverzu-
ordnungsausdr¨ucke verwendet. Allerdings k¨onnen diese zu noch komplexeren Ausdr¨ucken zusam-
mengesetzt werden. Wie diese im Detail aussehen, wird im n¨achsten Abschnitt beschrieben.
Das Ermitteln der f¨ur eine Referenzierung in einer Serverzuordnung relevanten Aktivit¨aten funktio-
niert prinzipiell wie im Abschnitt 4.3.2 f¨ur den nicht komplexen Fall beschrieben; Algorithmus 4 wird
weiterhin verwendet. Allerdings k¨onnen in
D²b
jetzt mehrere Aktivit¨aten
Þßßß3à
refe-
renziert werden. Deshalb muß die Funktion
áâá/ã¶Oä Ooå
so erweitert werden, daß auch komplexe Bear-
beiterzuordnungen ber¨ucksichtigt werden k¨onnen. F¨ur das in Abb. 11a dargestellte Beispiel ergibt sich
z.B. die Abh¨angigkeit
æ!ݲçè éëêíìïîñð/Dò
ß:óôöõ
èRç3ø÷/ùËò
ßmúô õ
è ûç3ø÷üâ÷ý
. Es m¨ussen also wie bisher alle
abh¨angigen Aktivit¨aten und der Typ der Abh¨angigkeit (selber Bearbeiter oder selbe OE) und zus¨atz-
lich das entsprechende Konstrukt (Verzweigung:
éëêíìïî
Þâþ
, Parallelit¨at oder Sequenz:
, Schleife:
î}øïÿ
) mit der zugeh¨origen Zusatzinformation (Zweig-Id, Iterationsnummer) ermittelt werden.
Auch die Funktion
²
ã6áâã6ão Få
muß erweitert werden. Es reicht nicht mehr aus, komplette
Abh¨angigkeiten zu ersetzen, sondern es m¨ussen auch Fragmente substituiert werden. Dabei werden
diese ggf. auch durch komplexe Abh¨angigkeiten ersetzt. Falls z.B. in dem in Abb. 11a dargestellten
Fall zus¨atzlich die Abh¨angigkeit
æ!çè çËëéï÷ý
existiert (wegen
), so l¨aßt sich zusam-
men mit der oben angegeben Abh¨angigkeit f¨ur Aktivit¨at
Ý æ!ݲçè éëê ìëî ð/ò
ß:ó ôõ
è çËëéï÷/ùËò
ßmú ôõ
è ûç3ø÷üâ÷ý
oå²ûËá¶
ableiten. Außerdem muß
²
ã6á/ã¶ãF Få
so erweitert werden, daß im Fall
von
é ê ìëî
und
î} ëÿ
gesamte Bl¨ocke ersetzt werden k¨onnen (z.B.
è éëê ìëî ð
ßßß
üâ÷
durch
èRݲçËëéï÷
).
Diese Bl¨ocke m¨ussen bis auf den Typ (B oder OE) in den beiden Abh¨angigkeiten identisch sein. Auch
dies soll an einem Beispiel erl¨autert werden: in Abb. 11a folge auf die Aktivit¨at
Ý
eine Aktivit¨at
Ý
mit
²
ó
"
ò
ß:óô õ
ëé ð¡ð!üFü
bää!
ó
ãBùËò
ßmúô õ
bð¡ûü
". Daraus folgt
æ!Ý
¡çè éëêíìïî ð/ò
ß:óô õ
èRçËïéë÷/ùËò
ßmúô õ
è ûç3 ÷üâ÷
. Mit dieser Abh¨angigkeit kann man schließen, daß
Ý
und
Ý
stets in derselben OE bearbeitet werden:
æ!Ý
çèRݲçËïéë÷
. Derselbe Bearbeiter ist nicht garantiert,
da der Bearbeiter von Aktivit¨at
Ý
– f¨ur den Fall daß Zweig 1 gew¨ahlt wird – nur aus derselben OE
wie der von
stammt. Eine analoge Schlußfolgerung gilt nicht f¨ur den Fall OR (Parallelit¨at, Sequenz),
da hier mehrere Teile der Bearbeiterzuordnung gleichzeitig g¨ultig sind. Deshalb kann der Bearbeiter
von Aktivit¨at
Ý
auf einem anderen Teil resultieren wie der von Aktivit¨at
Ý
, womit zwischen den Be-
arbeitern von
Ý
und
Ý
kein Zusammenhang mehr besteht. Dagegen ist im Fall LOOP eine solche
Ersetzung m¨oglich. Allerdings muß – wie immer bei Abh¨angigkeitsbeschreibungen von Schleifen –
darauf geachtet werden, daß sich die zu ersetzenden Teile der beiden Abh¨angigkeiten auf dieselbe
Iteration beziehen.
deutet an, daß die Teilausdr¨ucke durch ein exclusives Oder verbunden sind, d.h., daß genau einer der Zweige
"!$#
,
%! &
, ...gew¨ahlt wird.
40
5.3 Berechnung der Serverzuordnungen
Aus der Bearbeiterzuordnung einer Aktivit¨at wird beim Berechnen der Verteilung ihre Serverzuord-
nung abgeleitet. In diesem Abschnitt werden die Algorithmen beschrieben, die bei den elementa-
ren zusammengesetzten Bearbeiterzuordnungen (siehe Abbildung 11) verwendet werden, um die aus
einer Serverzuordnung resultierenden Kosten zu berechnen. Die Behandlung der nicht elementaren
(verschachtelten) F¨alle wird im n¨achsten Abschnitt diskutiert.
Eine Serverzuordnung muß eindeutig einen Server festlegen. In den nun folgenden Unterabschnitten
wird f¨ur jeden Typ von elementarer Bearbeiterzuordnung untersucht, welche Serverzuordnungen diese
Bedingung erf¨ullen und wie die zugeh¨origen Kosten berechnet werden k¨onnen. Durch eine komplexe
Bearbeiterzuordnung kann sich eine komplexe Serverzuordnung ergeben. Wie immer wird diese aber
nur dann verwendet, wenn die dadurch entstehenden Kosten minimal sind. So gibt es auch F¨alle, in
denen es g¨unstiger ist, z.B. eine vor der betrachteten Verzweigung liegende Aktivit¨at zu referenzieren
oder den Server statisch festzulegen.
5.3.1 Verzweigungen
Im Falle der in Abbildung 11a dargestellten Verzweigung wird entweder Zweig 1 oder Zweig 2 aus-
gef¨uhrt, da genau ein Zweig durchlaufen wird. Deshalb ist es m¨oglich eine Serverzuordnung der Art
"
ò
ß:óô õ
'
)(
Þ
ùËò
ßmúô õ
'
)(
D²b
*
"
zu verwenden. Da stets genau einer der F¨alle
eintritt, ist die Serverzuordnung immer definiert und eindeutig. In
'
+(
Þ
k¨onnen Aktivit¨aten
referenziert werden, die in Zweig 1 liegen (z.B. Aktivit¨at
);
'
)(
²
*
bezieht sich auf Zweig 2.
Welche Aktivit¨aten
f¨ur eine Referenzierung in
'
)(
,
in Frage kommen, ergibt sich aus den
Abh¨angigkeiten
æ!ݲçè éëê ìëî ð
ßßß
ò
ß
á
ôõ
è
ç
.-
D÷/ù
ßßß
üâ÷
. Die m¨oglichen
'
)(
,
sind, wie in Ab-
schnitt 4.3.1 beschrieben, statische Serverzuordnungen und Ausdr¨ucke, die eine abh¨angige Aktivit¨at
referenzieren. F¨ur jede betrachtete
'
)(
,
und den jeweils entsprechenden Teil der Bearbeiter-
zuordnung
,
werden die WVen
'
)(
Oÿïb
,
ð
'
ü
und
ûËãoÿïb
,
ð
/10
'
ü
und die daraus
resultierenden Datenvolumina
2
øä
,
ð!Ý ü
getrennt berechnet (wie f¨ur den nicht komplexen Fall in Ab-
schnitt 4.5 beschrieben). Aus den f¨ur den i-ten Zweig in Frage kommenden
'
)(
²
,
wird dieje-
nige ausgew¨ahlt, die zur minimalen Last
3
f¨uhrt. Dazu wird die Zielfunktion
3
, wie in Abschnitt 4.2
beschrieben, aus den
2
bä
,
ð!Ý ü
berechnet. Allerdings wird dabei nur der i-te Zweig (
D²b
,
und
'
)(
D²b
,
) ber¨ucksichtigt. Zur Berechnung des Gesamtergebnisses von Aktivit¨at
Ý
werden
jeweils die optimalen Teilergebnisse gewichtet aufaddiert. Die Gewichte
å
4,
entsprechen dabei den
Ausf¨uhrungswahrscheinlichkeiten der Zweige
Þ
65
á
.
'
+(
OÿïËOð
'
ü
%798
,
å
4,;:
'
)(
ÿï
,
ð
'
ü
ûËãoÿïbBOð
/10
'
ü
"798
,
å
<,<:
ûBãobÿëb
,
ð
/=0
'
ü
2
äFð!Ý ü
%7 8
,
å
4,;:>2
bä
,
ð!Ý ü
Es wurde also ein Vorgehen gew¨ahlt, bei dem f¨ur jeden Zweig
á
die optimale Serverzuordnung ge-
trennt berechnet wird und diese dann zu der Gesamt-Serverzuordnung zusammengesetzt werden. Die
?
Diese Wahrscheinlichkeiten geh¨oren zu den statistischen Daten, die entweder durch eine Analyse der Audit Trails des
WfMSs gewonnen werden oder vom Modellierer vorgegeben werden. Sie werden auch ben¨otigt, um die Ausf¨uhrungswahr-
scheinlichkeiten der Aktivit¨aten eines Zweiges zu berechnen, um so auf den Erwartungswert der durch ihre Ausf¨uhrung
entstehenden Last schließen zu k¨onnen.
41
Alternative w¨are, alle in den Abh¨angigkeiten f¨ur Aktivit¨at
Ýíæ!ݲçè éëêíìïîñð
ßßß
üâ÷
ermittelten Kombi-
nationen von Aktivit¨aten herzunehmen und die Kosten f¨ur alle daraus resultierenden Kombinatio-
nen von Serverzuordnungen zu berechnen. Die Serverzuordnung mit den niedrigsten Kosten w¨urde
dann ausgew¨ahlt. Diese Alternative verursacht durch die hohe Anzahl der zu untersuchenden Gesamt-
Serverzuordnungen (kombinatorische Vielfalt) einen großen Aufwand. Sie bringt keinen Vorteil, da
auch das gew¨ahlte Verfahren die optimale L¨osung ermittelt, da die einzelnen Zweige voneinander un-
abh¨angig sind. Dies ist der Fall, da sich die Gesamtkosten
2
äFð!Ý ü
durch Addition der Einzelkosten
2
ä
,
ð!Ý ü
ergeben und die Gewichtungsfaktoren
å
<,
fest sind.
5.3.2 Disjunktion von Teil-Bearbeiterzuordnungen
Tritt in einem Ablauf Parallelit¨at auf (Fall b), so werden alle Zweige durchlaufen. Die Bearbeiter-
zuordnung stellt die Disjunktion mehrerer Teilbeschreibungen dar. Die Serverzuordnung darf aber
keine Vereinigungsmenge mehrerer Server darstellen, da sie dann nicht mehr eindeutig w¨are. In der
Serverzuordnung darf also maximal eine Aktivit¨at referenziert werden. Dasselbe gilt, wenn in einer
Bearbeiterzuordnung die Aktivit¨aten einer Sequenz referenziert werden (Fall c). Dies l¨aßt sich zu
dem Fall verallgemeinern, daß eine Bearbeiterzuordnung aus mehreren durch Disjunktion verbunde-
nen Teilen besteht (egal, ob diese andere Aktivit¨aten referenzieren oder nicht). Ein Beispiel hierf¨ur
ist:
²
@7
"
ð/ïéöð¡bð
üFü
ö
bä¡ä¡
A7
ãFü
B
ð/ïé
C7EDGF
í
bä¡ä!
@7
ã3ü
"
Obwohl nur die in Abschnitt 4.3.1 beschriebenen Serverzuordnungen verwendet werden, ist die Be-
rechnung der Kosten komplizierter als in Kapitel 4. Da die Bearbeiterzuordnung zusammengesetzt ist,
l¨aßt sich der Fall bei der Berechnung von
oå
'
)(
ÿïBð
'
0
ü
nicht mehr geschlossenen behandeln
(vgl. Abschnitt 4.5.4). F¨ur jeden Teil der Bearbeiterzuordnung
,
werden deshalb die
WVen
'
)(
ÿï
,
ð
'
ü
und
ûËãoÿïb
,
ð
/10
'
ü
getrennt berechnet. Diese Teile werden dann gewichtet
addiert, wobei die Gewichte
å
4,
der Wahrscheinlichkeit entsprechen, daß der tats¨achliche Bearbeiter
der Aktivit¨at aus dem gerade betrachteten Teil der Bearbeiterzuordnung resultiert. Sind die WVen
berechnet, so werden sie verwendet, um die resultierenden Kosten (Datenvolumina) zu berechnen,
anhand derer die optimale Serverzuordnung ausgew¨ahlt wird.
'
+(
OÿïËOð
'
ü
%798
,
å
4,;:
'
)(
ÿï
,
ð
'
ü
ûËãoÿïbBOð
/10
'
ü
"798
,
å
<,<:
ûBãobÿëb
,
ð
/=0
'
ü
Es bleibt noch zu kl¨aren, wie die Gewichte
å
,
f¨ur die einzelnen Teile der Bearbeiterzuordnung er-
mittelt werden. Dabei soll
å
4,
der Wahrscheinlichkeit entsprechen, daß der tats¨achliche Bearbeiter von
Aktivit¨at
Ý
aus
,
resultiert. Diese Wahrscheinlichkeit entspricht dem Anteil der Bear-
beiter aus
, der sich aus
,
ergibt. Dabei wird angenommen, daß alle
Bearbeiter die Aktivit¨at
Ý
mit der gleichen Wahrscheinlichkeit ausf¨uhren, unabh¨angig davon, aus wel-
cher Teil-Bearbeiterzuordnung sie stammen. Trifft diese Annahme nicht zu, so kann der Modellierer
geeignete Gewichte
å
4,
manuell vorgeben oder die berechneten Werte ¨uberschreiben.
Algorithmus 18 berechnet die Gewichte
å
4,
f¨ur
²
H7
"
Þ
B
ßßß
B
²
à
". Zuerst werden alle Bearbeiter von Aktivit¨at
Ý
durchlaufen, wobei ihre Gewich-
te aufaddiert werden. Außerdem werden die Bearbeiter gez¨ahlt. Beides erfolgt getrennt nach OEen
und f¨ur jeden Teil von
. Ein Bearbeiter
, der aus
ð¤ü
Teilen von
D²b
stammt, wird jeweils nur mit einem Anteil von
ó
IJ
ð¤ü
ber¨ucksichtigt.
42
In einer 2. Phase berechnet der Algorithmus f¨ur jede
²
,
die durchschnittlich resultieren-
de Anzahl von Bearbeitern
K,
. Dabei muß nach dem Typ von
D²b
,
unterschieden werden:
1. Wird direkt der Bearbeiter von Aktivit¨at
referenziert, so geht aus diesem Teil der Bearbeiterzu-
ordnung maximal ein Bearbeiter hervor.
K,
wird berechnet, indem f¨ur jede OE das durchschnittliche
Gewicht ihrer Bearbeiter berechnet wird. Diese Gewichte werden aufaddiert. Dies erfolgt gewichtet
mit der Wahrscheinlichkeit
ãFá6ä
;+L
,
(siehe Abschnitt 5.5.1), daß die Aktivit¨at
Ý
in dieser OE
ausgef¨uhrt wird (wobei nur
,
ber¨ucksichtigt wird).
2. Hat
D²b
,
die Form "
ïéöð¡ bð
üFü
ßßß
", so qualifiziert sich nicht nur ein Bearbeiter
f¨ur Aktivit¨at
Ý
, sondern alle Bearbeiter der OE, die diese Bedingung erf¨ullen. Deshalb ist in diesem
Fall nicht deren durchschnittliches Gewicht, sondern deren Gesamtgewicht relevant. Das Gesamtge-
wicht aller OEen wird wie im Fall 1 gewichtet aufaddiert.
3. Ist
,
von anderen Aktivit¨aten unabh¨angig, dann qualifizieren sich stets alle Bearbeiter,
so daß
,
unabh¨angig von irgendwelchen OEen berechnet wird.
K,
stellt nun die ”Gr¨oße der Bearbeitermenge“, die durch
,
resultiert, dar. In der 3.
Phase berechnet Algorithmus 18 nun die Wahrscheinlichkeit
å
4,
, mit der ein potentieller Bearbeiter
von Aktivit¨at
Ý
sich wegen
,
oð!Ý ü
qualifiziert.
å
<,
ist gleich dem Anteil von
K,
an der
Summe aller
K,
.
Algorithmus 18 (
MN
bei einer Disjunktion von Bearbeiterzuordnungen)
Phase 1:
/* F¨ur jede OE, jeden Teil
O@PQSRUTWV%XZYR[S\^]_
: Gesamtgewicht und Anzahl Bearbeiter ermitteln */
`acbedffWf
\hg
berechne
iYj6OkPQ+RUT]_
wie
iYj6O@PJQ+RUT
_
,
wobei anstelle von
OkPQ+RUTWV%XYRl[S\
_
nur der Teil
O@PQSRUTWV%XZYR[S\ ]_
verwendet wird;
for each
X
do
mkn
XZo
b9p
p
p$qrAs
XutviYj6O@PJQ+RUT]_+w
p
p
p
;
xzy bxzy n
X{o
;
for
a
= 1 to
\
do
if
X|t}iYj6OkPQ+RUT ]_
then
~
PJQ+vj/)PJ
aW
j6]
nxzy
o
b~
PJQ+vj/)PJ
aW
j6]
nxzy
o<
~
_
n
X{o
mkn
XZo
;
m
\^+Q
O@PQSRUT]
nxzy
o
b
m
\^SQ
OkPQ+RUT]
nxzy
o<
d
mkn
X{o
;
Phase 2:
/* Gr¨oße der Bearbeitermenge
O
]
von
OkPQ+RlTVXZYRl[\^]
_
berechnen */
for
a
= 1 to
\
do
case
OkPQ+RlTVXZYRl[\^]_
b
"
O@PQSRUT
n
o
": (1)
O
]
b
8
4
~
PJQ+vj/)PJ
aW
j]
nxzy
o
m
\^SQ
O@PJQ+RUT]
nxzy
o
m
\{j6P
a/
m
X{Z]_
nxzy
o
;
case
OkPQ+RlTVXZYRl[\ ]_
b
"
xzy n
OkPQ+RUT
n
oo;
fWfWf
": (2)
O
]
b
8
4
~
PJQ+vj/)PJ
aW
j6]
nxzy
o
m
\{j6P
a/
m
X{Z]_
nxzy
o
;
case
OkPQ+RlTVXZYRl[\
]
n
o
unabh¨angig von
: (3)
O
]
b
8
4
~
PJQ+vj/)PJ
aW
j6]
nxzy
o
;
Phase 3:
/* Wahrscheinlichkeiten
]
aus Gr¨oße des entsprechenden
O
]
berechnen */
X}P
b
8
]
O
]
;
for
a
= 1 to
\
do
]
b
O
]
XvvP
;
43
5.3.3 Schleifen
Da die Bearbeiterzuordnung f¨ur jede Iteration einer Schleife verschieden sein kann, ergeben sich je-
weils unterschiedliche Bearbeiter-WVen und Kosten. Dies kann zu einer unterschiedlichen optimalen
Serverzuordnung f¨ur jede Iteration f¨uhren. Selbst wenn nur die erste Iteration in den Bearbeiterzuord-
nungen gesondert behandelt wird, kann dies die Bearbeiter-WVen unter Umst¨anden noch f¨ur einige
Iterationen beeinflussen. Der Grund daf¨ur ist, daß Bearbeiterzuordnungen von nachfolgenden Akti-
vit¨aten abh¨angen k¨onnen, und das auch noch mehrstufig. Das besondere Verhalten der ersten Iteration
wandert also bei jeder Iteration nur um eine Stufe nach vorne. Deshalb kann es einige Schleifen-
durchl¨aufe dauern, bis ein ”eingeschwungener“ Zustand erreicht ist. Es gibt sogar F¨alle, in denen nie
ein eingeschwungener Zustand erreicht wird. Ein Beispiel hierf¨ur sind zwei parallele Aktivit¨aten in
einer Schleife, zwischen denen bei jeder Iteration die Bearbeiter getauscht werden.
Werden Schleifen verschachtelt, so hat die Verwendung von iterations-abh¨angigen Serverzuordnun-
gen in der ¨außeren Schleife Auswirkungen auf die innere Schleife. Ob in dem in Abbildung 12 dar-
gestellten WF eine Migration zwischen den Aktivit¨aten
Þ
und
Þ
(ebenso zwischen
à
und
*
) statt-
findet, h¨angt auch vom Server von Aktivit¨at
Þ
ab. Damit sind f¨ur die Serverzuordnungen der inne-
ren Schleife auch die g¨ultigen Serverzuordnungen der ¨außeren Schleife relevant. Da in der inneren
Schleife die Server der ¨außeren referenziert werden k¨onnen (z.B.
'l¡
({¢>£;¤
¡)¥¦ §©¨
7
"
'U¡
(
l¡
ð
Þ
ü
"),
h¨angen auch WVen der inneren Schleife von den aktuell g¨ultigen Serverzuordnungen der ¨außeren
Schleife ab. Deshalb h¨angen die optimalen Serverzuordnungen der inneren Schleife davon ab, in wel-
cher Iteration sich die ¨außere Schleife befindet.
Þ
ª
F¨ur Aktivit¨aten in Schleifen ergeben sich Serverzu-
ordnungen der Form:
'U¡
({¢k£<¤
¡¥«¦¬
7
"
,
®°¯
±².²/³U´©µ^¶
ã
·F
¡
ð¡î
"¤)¤
Ëå
¶
¥
ü
¤
Ëå
¶
ã
.F
¡
±².²/³U´©µ¸
,/¹
õ
'l¡
({¢>£;¤
¡)¥¦
,
"
mit
¤
iå
º1»+7
ç
U¼A½
¾¿ ÀÀ.ÀÁ{ ÃÄ
Å.Å.Å
Å.ÅÅ
ÆUÇ
ÈÉÉ.ÊË ÌÍÍ.ÎÐÏ
Abbildung 12 Verschachtelte Schleifen.
Um f¨ur jede Iteration die jeweils optimale Serverzuordnung bestimmen zu k¨onnen, m¨ussen bei der
Analyse einige Schleifendurchl¨aufe durchgespielt werden. Dies wird prinzipiell solange fortgesetzt,
bis sich gegen¨uber der letzten Iteration nichts mehr ver¨andert hat. Um den Aufwand zu begrenzen
und da es F¨alle gibt, in denen kein ”eingeschwungener“ Zustand erreicht wird, wird die Analyse nach
¦
Iterationen abgebrochen. Dabei f¨uhrt ein großes
¦
zu einem genauen Ergebnis und einem hohen
Analyseaufwand. In Anhang B.3 wird gezeigt, daß der Anteil der nicht analysierten Iteratinen klei-
ner als
)Ñ4Ò
ist, wenn
¦
7ÔÓÕ:{Ö
¶
ã
(
Ö
¶
ã
: (durchschnittliche) Anzahl der Durchl¨aufe)
Þ
×
Iterationen
analysiert werden. Wird z.B.
¦
7ÙØu:{Ö
¶
ã
gew¨ahlt, so ist die Wahrscheinlichkeit, daß noch weite-
re Iterationen ausgef¨uhrt werden, kleiner als 2%. F¨ur diese Iterationen wird das Verhalten (und die
Serverzuordnung) der letzten analysierten Iteration angenommen. Auch ihre Kosten werden ber¨uck-
sichtigt, allerdings nicht mit dem exakten Wert, sondern mit den WVen der Iteration
¦
. Da dies eine
Ú
Prinzipiell w¨are dieselbe Form auch f¨ur Bearbeiterzuordnungen in verschachtelten Schleifen m¨oglich (z.B.
Û"Ü©ÝUÞWß à)áWÞâlãäåæ=çSèêéëìKÞè
ááí#©îæï#cðKéëìKÞè
áWáí«&Jîæï#©îòñ)ÛóÜÝUÞßèêô
îòõ.èêéëìKÞè
áWáí#©î æï#cðöéë/ìKÞè
áWáòí&JîÐ÷
&Jî·ñ+øùáúûúûÜýüÐÞþë·õèêéë/ìKÞè
áWáòí#©îÐ÷º&ùðKéë/ìKÞSè
áWáòí«&îù÷ÿ#î·ñ)Û"ÜÝÞWßJè
îç
). Da diese aber f¨ur den Modellierer schwer zu
verstehen sind und in der Praxis wohl nicht ben¨otigt werden, wird auf diese Variante nicht weiter eingegangen.
Die durchschnittliche Anzahl von Iterationen (
éë
) wird aus den Audit Trails ermittelt oder vom Modellierer vorgege-
ben. Diese Information ist auch notwendig, um die durch die Schleife verursachten Kosten absch¨atzen zu k¨onnen.
44
recht gut N¨aherung darstellt, ist der Fehler noch kleiner als
Ñ4Ò
.
Nach dem Durchspielen der Iterationen sind die optimalen Serverzuordnungen, die WVen und die
Kosten f¨ur jede einzelne Iteration bekannt. Diese m¨ussen nun noch zu einem Gesamtergebnis zusam-
mengesetzt werden. Wie eine zusammengesetzte Serverzuordnung aussieht, wurde schon erkl¨art. Die
WVen
'U¡
(
Oÿ
¡
¤
¬
ð
'
ü
und
ûBã
.¤
¡
ÿ
¡
¤
¬
ð
/=0
'
ü
werden f¨ur Aktivit¨aten ben¨otigt, die auf die Schleife
folgen und Aktivit¨at
Ý
referenzieren. Die Daten werden verwendet, um die Server- und Bearbeiter-
WVen dieser Aktivit¨aten zu berechnen. F¨ur diese Aktivit¨aten sind die Werte der letzten ausgef¨uhrten
Schleifeniteration relevant, da sich auch ihre Server- und Bearbeiterzuordnungen auf die letzte Itera-
tion beziehen. Die WVen werden mit Hilfe der folgenden statistischen ¨
Uberlegung zusammengesetzt.
Wenn durchschnittlich
Ö
¶
ã
Iterationen der Schleife durchlaufen werden, so betr¨agt die Wahrschein-
lichkeit zum Verlassen der Schleife bei jeder Iteration
º7
ó
I
Ö
¶
ã
, falls das Verlassen der Schleife
zuf¨allig erfolgt.
Þ
Die Wahrscheinlichkeit, daß die Schleife nach exakt
á
Iterationen verlassen wird,
betr¨agt damit
å
4,ý7
ð
ó
ü
,
Ñ
Þ
:
(die Schleife wurde
á
ó
mal nicht verlassen und wird dann verlas-
sen). Die Server- und Bearbeiter-WVen werden mit
å
,
gewichtet aufaddiert (der Wahrscheinlichkeit,
mit der die Schleife nach Iteration
á
verlassen wird, so daß es die letzte Iteration war). Nat¨urlich muß
auch der Anteil der nicht mehr analysierten Iterationen ber¨ucksichtigt werden. Dies geschieht durch
ein gr¨oßeres Gewicht f¨ur die letzte analysierte Iteration
¦
.
'U¡
(
Oÿ
¡
¤
¬
ð
'
ü
%7
à
Ñ
Þ
8
,
Þå
4,;:
'l¡
(
ÿ
¡
¤
,
¬
ð
'
ü
ð
ó
à
Ñ
Þ
8
,
Þå
4,
/ü
ù:
'l¡
(
ÿ
¡
¤
à
¬
ð
'
ü
ûËã
.¤
¡
ÿ
¡
¤
¬
ð
/10
'
ü
"7
à
Ñ
Þ
8
,
Þå
<,<:
ûËã
.¤
¡
ÿ
¡
¤
,
¬
ð
/10
'
ü
ð
ó
à
Ñ
Þ
8
,
Þå
4,
/ü
Ð:
ûBã
·¤
¡
ÿ
¡
¤
à
¬
ð
/10
'
ü
Bei Schleifen werden die Kosten (Datenvolumina) f¨ur die einzelnen Schleifendurchl¨aufe
2 ¤
bä
,
ð!Ý ü
ge-
trennt berechnet und anschließend aufaddiert. Es wird (wie bei Verzweigungen) f¨ur jede Iteration
á
einzeln die
'U¡
(Z¢k£<¤
¡¥«¦
,
ermittelt, die die Zielfunktion
3
minimiert. Erst dann wird das Gesamter-
gebnis f¨ur die jeweils optimalen
'l¡
(Z¢k£;¤
¡¥¦
,
berechnet. Beim Aufaddieren der Datenvolumina ist
nicht die Wahrscheinlichkeit
å
<,
f¨ur das Verlassen der Schleife nach Iteration
á
relevant, sondern die
Wahrscheinlichkeit, daß diese Iteration ¨uberhaupt ausgef¨uhrt wird. Diese Wahrscheinlichkeit betr¨agt
å
,
7
ð
ó
ü
,
Ñ
Þ
(die Iteration
á
wird ausgef¨uhrt, wenn die Schleife in den ersten
á
ó
Iterationen nicht
verlassen wurde). Diese Wahrscheinlichkeit wird als Gewicht beim Aufaddieren der Kosten verwen-
det:
2 ¤
äFð!Ý ü
%7
à
Ñ
Þ
8
,
Þ
å
4
,
:S2 ¤
bä
,
ð!Ý ü
ð
ó
à
Ñ
Þ
8
,
Þ
å
<
,
ü
ù:>2 ¤
ä
à
ð!Ý ü
5.4 Kombination der Konstrukte
Die Serverzuordnungen aus Abschnitt 5.3 resultieren aus den elementaren komplexen Bearbeiterzu-
ordnungen (vgl. Abbildung 11). Diese Bearbeiterzuordnungen k¨onnen zu noch komplexeren zusam-
mengesetzt werden, die sich prinzipiell auf beliebig viele Aktivit¨aten beziehen k¨onnen. Ein Beispiel
hierf¨ur w¨are f¨ur Abbildung 11a
Ó
¡
l¢>£;¤
¡)¥¦¬
7
"
ð
6¢
ò
ß:ó ôõ
Ó
¡
bð
üËù
¢
ò
ßmú ôõ
Ó
¡
ð¡ûüFü
B
Ó
¡
ð
¥
ü
". Dadurch k¨onnen sich Serverzuordnungen ergeben, die aus den soeben beschriebenen
zusammengesetzt sind. Aus komplexen Bearbeiterzuordnungen ergeben sich entsprechend komple-
xe Abh¨angigkeiten, in diesem Beispiel
æ!ݲçè
ð¡éëêíìïî ð
6¢
ò
ß:ó
ô
õ
è
ç
ø÷/ù
¢
ò
ßmú
ô
õ
è ûç
ø÷üËùè
¥
ç
ø÷üâ÷
.
Es gibt auch Anwendungen, in denen die Schleife nicht zuf¨allig nach irgendeiner Iteration verlassen wird. Ist das
Kriterium f¨ur das Schleifenende z.B. das Erreichen eines Z¨ahlerstandes, so werden stets exakt
éë
Iterationen durch-
laufen.
Ü©Þ
! "
ÞWáß
$#
Uè
î
und
ü
&%
òëáÞ
'"
ÞWáß
$#
Uè
(*)
î
ergeben sich dann aus ihrem Wert der
éë
-ten (und damit letzten)
Schleifeniteration.
45
Komplexe Abh¨angigkeiten k¨onnen sich aber auch ergeben, wenn bei der Modellierung nur elementa-
re zusammengesetzte Bearbeiterzuordnungen verwendet werden, n¨amlich dann, wenn Algorithmus 4
die aus ihnen resultierenden Abh¨angigkeiten zu komplexeren kombiniert. Im folgenden wird erl¨autert,
wie in diesen F¨allen die Serverzuordnung ermittelt und die resultierenden WVen und Kosten berechnet
werden k¨onnen.
Die Verschachtelung der Abh¨angigkeits-Klauseln orientiert sich an der Verschachtelung der Konstruk-
te (Verzweigung, Parallelit¨at, Schleifen) von ADEPT. Deshalb k¨onnen sie aus den elementaren F¨allen
(vgl. Abbildung 11) zusammengesetzt werden. Dadurch ergibt sich eine hierarchische Struktur, wie in
Abbildung 13 f¨ur das oben beschriebene Beispiel dargestellt. Auf der untersten Ebene k¨onnen, wie in
Abschnitt 5.3 beschrieben, alle relevanten Serverzuordnungen durchprobiert und jeweils die Kosten
analysiert werden. Darauf k¨onnen die in Abschnitt 5.3 beschriebenen Algorithmen rekursiv ange-
wandt werden. Dies ist m¨oglich, da ihre Eingabeparameter (
'%l¡
(
ÿ
¡
¤
¬
ð
'
ü
und
ûBã
·¤
¡
ÿ
¡
¤
¬
ð
/=0
'
ü
)
Teilmenge ihrer Ausgabeparameter sind. Dadurch ergibt sich f¨ur beliebig komplexe Bearbeiterzuord-
nungen eine Gesamt-Serverzuordnung mit den zugeh¨origen WVen und Kosten.
+-,/.10
2436517
8:9<;=>
?A@CBDE
FAGIHJK
LNMOPRQ SNTUV&W
Abbildung 13 Hierarchische Struktur von
X
ZY'[
x
]\
ny
^`_]a
n
V%
fd
cb
g
[
T
Y
O
dfe
V
f
ghb
g
[
Y
O
d
o
-e
[
[
Y
O
d
o
idj
.
Bei jeder Rekursion m¨ussen alle relevanten Serverzuordnungen f¨ur die darunterliegende Ebene durch-
probiert werden. Deshalb ergibt sich eine Komplexit¨at, die exponentiell zur Rekursionstiefe ist. Da die
Rekursionstiefe aber der Verschachtelungstiefe in den Abh¨angigkeits-Klauseln entspricht, ist mit sehr
kleinen Rekursionstiefen zu rechnen. Diese Verschachtelungstiefe entspricht der Verschachtelungstie-
fe bei der Bearbeiterzuordnung, wobei aber auch indirekte Abh¨angigkeiten ber¨ucksichtigt sind. Ein
Modellierer wird aber keine sehr komplizierten Bearbeiterzuordnungen verwenden, da diese in der
Praxis nicht ben¨otigt werden und sehr schwer zu durchschauen sind.
5.5 Ver¨
anderungen durch komplexe Bearbeiter- und Serverzuordnungen
Komplexe Bearbeiter- und Serverzuordnungen haben Einfluß auf in Kapitel 4 beschriebene Algo-
rithmen. So muß die Berechnung des OE-Gewichts angepaßt werden, wenn komplexe Bearbeiterzu-
ordnungen verwendet werden. Außerdem m¨ussen bei der Pr¨ufung, ob Aktivit¨aten vom selben Server
kontrolliert werden, auch komplexe Serverzuordnungen ber¨ucksichtigt werden.
5.5.1 Berechnung von OE-Gewichten bei komplexen Bearbeiterzuordnungen
In Abschnitt 4.5.3 wurde das OE-Gewicht
k
¬
ð
l
ïé ü
eingef¨uhrt, um ber¨ucksichtigen zu k¨onnen, daß
bei abh¨angigen Bearbeiterzuordnungen der Anteil der Bearbeiter aus einer OE von der referenzier-
ten Aktivit¨at abh¨angt. F¨ur die Berechnung des OE-Gewichts ben¨otigt man f¨ur jede OE den Anteil
ihrer Bearbeiter und ihren Anteil bei der Ausf¨uhrung von Aktivit¨at
Ý
. Der Anteil der Bearbeiter
@¦
ã
áâä
i
Ó
¡
¬
ð
l
ëé ü
berechnet sich als (vgl. Algorithmus 9):
@¦
ã
áâä
i
Ó
¡
¬
ð
l
ëé ü
%7 8
mnpo
²
<qrts
Ò
u
#
v*wxzy
mh{
wtx
k
¬
ð
£
ü
I
8
mno
²
<qrts
Ò
!u
#
k
¬
ð
£
¤ü
46
Bei der Berechnung von
@¦
ã
áâä
£cSL
¬
ð
l
ïé ü
muß unterschieden werden, ob die Bearbeiterzuordnung
von Aktivit¨at
Ý
eine andere Aktivit¨at
referenziert (
k¦
ã
áâä
£;+L
¬
ð
l
ëé ü
%7
@¦
ã
áâä
£;+L
p|
ð
l
ëé ü
) oder
nicht (
@¦
ã
áâä
£cSL
¬
ð
l
ïé ü
"7
k¦
ã
á6ä
f
Ó
¡
¬
ð
l
ëé ü
).
Bei Verwendung komplexer Bearbeiterzuordnungen k¨onnen mehrere Aktivit¨aten referenziert
werden. F¨ur jeden Teil
Ó
¡
l¢>£;¤
¡)¥¦
,
¬
von
Ó
¡
l¢>£;¤
¡)¥¦¬
wird
k¦
ã
áâä
i
Ó
¡
,
¬
ð
l
ëé ü
und
@¦
ã
áâä
£cSL
,
¬
ð
l
ïé ü
separat berechnet. Aus diesen Werten wird
@¦
ã
áâä
i
Ó
¡
¬
ð
l
ëé ü
und
@¦
ã
áâä
£cSL
¬
ð
l
ïé ü
berechnet, indem sie gewichtet addiert werden. Die Gewichte entsprechen da-
bei den Wahrscheinlichkeiten
å
4,
, daß
Ó
¡
l¢>£;¤
¡)¥¦
,
¬
daf¨ur verantwortlich ist, daß der Bearbeiter
£
die Aktivit¨at
Ý
bearbeiten darf. Wie die Wahrscheinlichkeiten
å
4,
berechnet werden, wurde bereits in
den Abschnitten 5.3.1 - 5.3.3 erl¨autert. Es gilt also:
}
ëé
õ
«@¦
ã
áâä
i
Ó
¡
¬
ð
l
ïé ü
"798
,
å
,:
@¦
ã
áâä
i
Ó
¡
,
¬
ð
l
ïé ü
}
ëé
õ
«@¦
ã
áâä
£cSL
¬
ð
l
ïé ü
%798
,
å
,:
@¦
ã
áâä
£;+L
,
¬
ð
l
ïé ü
Da damit die ben¨otigten Werte f¨ur die Gesamtbearbeiterzuordnung verf¨ugbar sind, kann
k
¬
ð
l
ïé ü
und
k
òáâû
c~
ã
¬
ð
£
¤ü
– wie in Algorithmus 9 beschrieben – berechnet werden.
5.5.2 Komplexe Serverzuordnungen bei der Berechnung von Serverklassen
In Abschnitt 5.2 wurde diskutiert, unter welchen Umst¨anden Aktivit¨aten bei komplexen Bearbeiter-
zuordnungen denselben Bearbeiter bzw. einen Bearbeiter aus derselben OE haben. Analog hat die
Verwendung von komplexen Serverzuordnungen Auswirkungen darauf, wann Aktivit¨aten von sel-
ben Server kontrolliert werden (Funktion
ä
áâû
c~
U¡'l¡
(
U¡
á
¡«
ÝOãð/ü
in Algorithmus 12). Aktivit¨aten
k¨onnen immer vom selben Server kontrolliert werden, obwohl dies mit den in Abschnitt 4.6.1 auf-
gef¨uhrten Regeln nicht erkannt wird, da diese keine komplexen Serverzuordnungen ber¨ucksichtigen.
In dem in Abb. 14a dargestellten Beispiel referenzieren die Aktivit¨aten
Ý
und
Ý
Aktivit¨aten einer
Verzweigung. Dabei beschreiben die Teilserverzuordnungen f¨ur Zweig
á
jeweils denselben Server.
Deshalb verwenden die beiden Aktivit¨aten jeweils denselben Server, egal welcher Zweig gew¨ahlt
wird. Allgemein kann man schließen:
Falls
'l¡
(Z¢k£;¤
¡¥¦¬
7
"
¢
ò
ß:óô õ
'l¡
({¢>£;¤
¡)¥¦
Þ
¬
ù
ßßß
¢
ò
ß
¦
>ô õ
'U¡
({¢k£<¤
¡¥«¦
à
¬
"
und
'l¡
({¢>£;¤
¡)¥¦¬
;7
"
¢
ò
ß:óô õ
'%l¡
(Z¢k£<¤
¡¥«¦
Þ
¬
ù
ßßß
¢
Dò
ß
¦
>ô õ
'U¡
({¢k£<¤
¡¥«¦
à
¬
"mit
}
á
ù7
ó¿ßßß
W¦
íõ
'U¡
({¢k£<¤
¡¥«¦
,
¬
referenziert denselben Server wie
'U¡
({¢k£<¤
¡¥«¦
,
¬
,
dann werden die Aktivit¨aten
Ý
und
Ý
vom selben Server kontrolliert.
C
/'!' p
/!' c
¡¢-£
¤¥§¦ ¨
¤¥§¦© ª/«
¬/®¯I°±'²p³´µ'³´-¶·¸
¹/º&» ¼¾½¿!ÀpÁÂÃ'ÁÂÄ ÅcÆ Ç
ÈÉÈ&È
ÈÉÈ&È
ÊhË
ÌCÍ
Î Ï Ð
Ñ/ÒÓÔ'ÕÖ!×ØÙÚ'ØÙÛ ÜpÝ Þ
ß/àáâãä!åæçè'æçé êcë ì
íïîpð
ñò§ó ô
ñò§óõ öÉö&ö
÷hø
ùúûýüIúû-þïÿ
ÿ
¾þ
túÿ û
þïÿ
ÿ
¾þ
úÿû
þ:ÿ
Abbildung 14 Aktivit¨aten mit gleichem Server bei Verwendung komplexer Serverzuordnungen.
Auch in dem in Abb. 14b dargestellten Beispiel referenziert Aktivit¨at
Ý
die Aktivit¨aten einer Ver-
47
zweigung. Da alle referenzierten Aktivit¨aten
Þßßß
à
vom selben Server kontrolliert werden und
Aktivit¨at
Ý
(in allen F¨allen) auch diesen Server verwendet, kann geschlossen werden, daß der Ser-
ver von Aktivit¨at
Ý
derselbe ist wie f¨ur die Aktivit¨aten
Þßßß
à
. Dabei m¨ussen die Teilserverzuord-
nungen von Aktivit¨at
Ý
nicht unbedingt
'U¡
(
l¡
ð
4,
âü
lauten, es sind auch andere F¨alle denkbar (z.B.
'U¡
({¢k£<¤
¡¥«¦¬
7
"
¢
Dò
ß:ó ôõ
h¤
Ó
á
¦
ð
i
Ó
¡
bð
/Ó
üFüËù
¢
ò
ßmú ôõ
'U¡
(
l¡
ð
*
ü
"). Allgemein gilt:
Falls
'l¡
(Z¢k£;¤
¡¥¦¬
7
"
¢
ò
ß:ó ôõ
'l¡
({¢>£;¤
¡)¥¦
Þ
¬
ù
ßßß
¢
ò
ß
¦
ôõ
'U¡
({¢k£<¤
¡¥«¦
à
¬
"mit
}
á
ù7
ó¿ßßß
W¦
íõ
aus
'%l¡
(Z¢k£<¤
¡¥«¦
,
¬
folgt
'
Ó
S'%l¡
(
U¡
ð!ݲç
<,
âü
dann werden die Aktivit¨aten
ݲç
Þ
ç
ßßß
à
alle vom selben Server kontrolliert.
F¨ur die Konstrukte Parallelit¨at und Sequenz wurde in Abschnitt 5.3.2 festgestellt, daß Serverzuord-
nungen der Art "
'l¡
(
U¡
ð
Þ
ü
B
'l¡
(
U¡
ð
*
ü
"nicht m¨oglich sind, da der Server einer Aktivit¨at ein-
deutig sein muß. Deshalb kann dieser Fall auch in dem hier diskutierten Zusammenhang nicht auf-
treten. Bei Schleifen ist die Iterationsnummer nur innerhalb der Schleife g¨ultig. Deshalb k¨onnen
auf eine Schleifen folgende Aktivit¨aten keine Serverzuordnungen der Art "
¶
ã
·F
¡
ð¡î
"¤)¤
Ëå
ó
ü
7
ó õ
'U¡
({¢k£<¤
¡¥«¦
¿Þ
ù
¶
ã
.F
¡
ð¡î
ó¤+¤
Ëå
ó
ü
¼
úuõ
'%l¡
(Z¢k£<¤
¡¥«¦
*
"verwenden. Innerhalb der Schleife analysiert
Algorithmus 13 die Teilserverzuordnungen
'%l¡
(Z¢k£<¤
¡¥«¦
,
, da die Iterationen bei der Analyse ”durch-
gespielt“ werden. Dadurch werden die Serverzuordnungen auf die nicht zusammengesetzten F¨alle aus
Abschnitt 4.3.1 zur¨uckgef¨uhrt, wobei zus¨atzlich auf die Iterationsnummern geachtet werden muß. Es
ergeben sich also f¨ur die Funktion
ä
áâû
c~
l¡'l¡
(
l¡
á
¡
ÝOãð/ü
aus Algorithmus 12 durch Parallelit¨at,
Sequenz und Schleifen keine neuen F¨alle.
6 Effizienz des ADEPT
!"#%$
-Ansatzes
Um den Nutzen von variablen Serverzuordnungen zu demonstrieren, wird das ADEPT
µ
,
'&
q
u
,
m
q
,
²
)(
-
Verteilungsmodell mit Hilfe einer Simulation mit anderen Verteilungsmodellen verglichen (siehe auch
[BD99a], f¨ur Details und weitere Simulationen siehe [BD99c]). Dazu wurde die Ausf¨uhrung des fol-
genden einfachen Klinik-WFs unter verschiedenen Verteilungsmodellen simuliert:
3 Aktivit¨aten in der Ambulanz
1 Aktivit¨at durch einen Stationsarzt (nimmt Patient auf Station 1-5 auf)
5 Aktivit¨aten durch einen Arzt dieser Station
1 Aktivit¨at im Labor
5 Aktivit¨aten durch einen Arzt der Station
Die Simulation soll einen Vergleich der Verteilungsmodelle erm¨oglichen und dient nicht dazu, etwaige
¨
Uberlastungen zu untersuchen. Deshalb wurde selbst f¨ur den zentralen Fall angenommen, daß der
WF-Server nicht ¨uberlastet ist. Aus den bei der Simulation entstandenen Daten wurde die von den
WF-Servern zu bew¨altigende Gesamtlast, die Last pro WF-Server, die Belastung pro Teilnetz und
die Last f¨ur die Gateways ermittelt. Abb. 15 zeigt das dabei erzielte Ergebnis. Die Werte wurden so
normiert, daß sich f¨ur die Last im zentralen Fall jeweils der Wert 100 ergibt.
6.1 Zentraler Server
Die Belastung f¨ur den einzigen WF-Server wird als Vergleichswert 100 verwendet. Dasselbe gilt f¨ur
die durchschnittliche Belastung der Teilnetze und der Gateways. Der zentrale WF-Server befindet sich
in einem bestimmten Teilnetz, das somit mit dessen gesamter Kommunikation belastet wird. Deshalb
stellt es einen potentiellen Flaschenhals dar. Das zeigt sich auch an der hohen Last 387,1 f¨ur dieses
48
*++-, + *++-, +
*+*, . *+*/, .
*++-, +
*10, 2
*103, 4 *103, 4
*++-, + *++-, +
..5, 4
6 7 , 8
*++-, +
.58 , +
03, 0
*++-, +
+
*++
9;:=<>?@/AB:=?CEDF'G3:?IH3:=? JK:=?I>L:/MA N<5OPO-:Q@=R">S:=?CEDQTQU>L@=>SMBQWV=X3:YG3:?IH3:=?U9N5Z;?'[;<-N <3O-:=<\H3@=?]M@=^3A:YG3:?IH3:=?'9/N5Z;?'[ <N<5O-:=<
_
:Q@=R">BAB@)QU>@/AA:=?CEDF]G5:?IH3:=?
`
@)QU>-a5?'ZbCEDF'G3:=?UH3:=?
`
@)QU>-a5?'ZPcd:/MA <3:>9
_
:Q@=R">BAB@)QU>[-:=?
_
@>S:=eK@=fQ
g
258 7,L*1h
Abbildung 15 Ergebnis der Simulation eines Klinik-WFs unter verschiedenen Verteilungsmodellen.
Teilnetz, wohingegen die anderen Teilnetze mit durchschnittlich 52,1 nur relativ schwach belastet
sind.
6.2 Verteilung von gesamten Workflows
Werden den WF-Servern gesamte WF-Typenzugeordnet, so ist die f¨ur die Server entstehende Gesamt-
last genauso groß wie im zentralen Fall, da ebenfalls keine Migrationen stattfinden. Allerdings verteilt
sich diese Last rechnerisch
i/j
auf die 7 zur Verf¨ugung stehenden WF-Server, so daß sich f¨ur die Last
pro WF-Server mit 14,3 der beste Wert aller Verteilungsmodelle ergibt. Die Belastung der Teilnetze
und der Gateways ist mit der des zentralen Falls identisch, da in beiden F¨allen der WF-Server der Sta-
tion 1 verwendet wurde. Allerdings entf¨allt der Flaschenhals im Teilnetz des zentralen WF-Servers,
da unterschiedliche WF-Typen von verschiedenen WF-Servern kontrolliert werden k¨onnen.
6.3 Statische Serverzuordnung
Wird der WF partitioniert, so werden auch Migrationen (hier: von der Ambulanz zu einer Station) not-
wendig. Deshalb entsteht bei diesem Verteilungsmodell eine etwas h¨ohere Last f¨ur die WF-Server, als
bei den bisher vorgestellten. Diese Last verteilt sich aber auf mehrere WF-Server. Durch die geeignete
Wahl des WF-Servers f¨ur die Partitionen wird die Belastung der Teilnetze und der Gateways reduziert.
Da bei dem betrachteten WF statische Serverzuordnungen wenig geeignet sind, f¨allt die Verbesserung
in dieser Simulation sehr klein aus.
6.4 Variable Serverzuordnung
Durch variable Serverzuordnungen ist es m¨oglich, die von einem Stationsarzt bearbeiteten Aktivit¨aten
durch den WF-Server der entsprechenden Station kontrollieren zu lassen. Dadurch kann die Belastung
der Teilnetze und der Gateways drastisch reduziert werden.
k]l
Da die Ausf¨uhrung von Instanzen nur eines einzigen WF-Typs simuliert wurde, entsteht die Last eigentlich nur an
einem WF-Server.
49
Wir haben in ADEPT das Ziel verfolgt, die Belastung des Kommunikationssystems zu reduzieren.
Dies ist, wie mit dieser Simulation gezeigt wurde, durch die Verwendung von variablen Serverzuord-
nungen gelungen. Wegen der dabei notwendigen Migrationen steigt die Gesamtlast der WF-Server
gegen¨uber dem zentralen Fall an, was durch die Verwendung zus¨atzlicher Server ausgeglichen wer-
den kann.
7 Diskussion
Dieser Abschnitt bietet einen ¨
Uberblick ¨uber Architekturkonzepte f¨ur skalierbare WfMSe und stellt
einige konkrete Ans¨atze vor. F¨ur eine detaillierte Diskussion m¨ochten wir auf [BD98, BD99c] ver-
weisen. Das eine Extrem f¨ur die Architektur eines WfMSs ist ein zentraler Server. Diesem sind alle
Aktivit¨aten zugeordnet. Da er deshalb die gesamte Systemlast bew¨altigen muß, stellt er einen po-
tentiellen Flaschenhals dar. Einige Forschungsprototypen, die sich nicht prim¨ar um Skalierbarkeit
k¨ummern (z.B. Panta Rhei [EG96], WASA [WHKS98]), und die meisten kommerziellen Systeme
fallen in diese Kategorie. Das andere Extrem sind voll verteilte Systeme, die ¨uberhaupt keine Server
verwenden. Die WFs migrieren zwischen den Benutzern, die sie bearbeiten. Auch hier sind keine
Serverzuordnungen notwendig. Beispiele sind Exotica/FMQM [AMG
m
95] und INCAS [BMR96].
Zwischen diesen beiden Extremen liegen Ans¨atze, bei denen mehrere WF-Server verwendet werden,
aber nicht jede Benutzermaschine gleichzeitig als Server fungiert. Da bei diesen Systemen eine Strate-
gie f¨ur die Zuordnung der Server zu den Aktivit¨aten notwendig ist, werden sie nach diesem Kriterium
klassifiziert. In [AKA
m
94] werden identische Replikate (Cluster) der WF-Engine verwendet. Eine
WF-Instanz wird komplett von einem zuf¨
allig ausgew¨
ahlten Cluster kontrolliert. Deshalb sind keine
Serverzuordnungen notwendig. In [SM96] werden die Systeme CodAlf und BPAFrame beschrieben,
die den WF-Server einer Aktivit¨at jeweils auf dem Rechner der Anwendung (z.B. beim DBMS) al-
lokieren. Stehen mehrere Anwendungsserver zur Verf¨ugung, so sorgt ein Trader f¨ur eine Verteilung
der Last. Ein ¨ahnlicher Ansatz wird von METEOR
n
[DKM
m
97, MSKW96, SK97] verfolgt. Gene-
relle Nachteile dieses Vorgehens sind, daß zwischen dem WF-Server und den Bearbeitern u.U. eine
weit entfernte Kommunikation notwendig wird. Außerdem ist nicht f¨ur jede Anwendung eine Ort
vorgegebenen (z.B. f¨ur einen Editor).
Die meisten Ans¨atze versuchen, wie ADEPT
o;p &/qUr pUs1t qpUu
(
, die Server nahe bei den Bearbeitern der
jeweiligen Aktivit¨at zu plazieren. Bei MENTOR [WWWK96a, WWWK96b, WWK
m
97, MWW
m
98]
werden State-/Activitycharts so partitioniert, daß sich die ¨
Aquivalenz der verteilten Ausf¨uhrung zum
zentralen Fall formal zeigen l¨aßt. Da alle Bearbeiter einer Aktivit¨at demselben ”Processing Entity“
angeh¨oren m¨ussen, bietet es sich an, diesen Server auszuw¨ahlen. Dieselbe Verteilungsstrategie wird
von WIDE [CGP
m
96, CGS97] verwendet, wobei – anstelle einer Migration – entfernte Objektzugriffe
mittels CORBA durchgef¨uhrt werden. In MOBILE [HS96, SNS99] werdendie verschiedenen Aspekte
eines WFs von verschiedenen Servern behandelt. Außerdem wird beim Start eines (Sub-)WFs zur
Laufzeit entschieden, von welchem WF-Server er kontrolliert werden soll.
ADEPT
o;p &/qUr pUs1t qpUu
(
bezieht in den Verteilungsalgorithmus die Kommunikationskosten mit ein und
ber¨ucksichtigt damit, daß das Kommunikationssystem zum Flaschenhals werden kann. Es ist unse-
res Wissens der einzige Ansatz, bei dem eine Lastanalyse durchf¨uhrt wird, um durch eine geeigne-
te Verteilung die Kommunikationskosten zu minimieren. Bei den anderen Systemen gibt es keine
variable Serverzuordnung, der Einfluß abh¨angiger Bearbeiterzuordnungen auf die Verteilung wird
nicht ber¨ucksichtigt. Es gibt aber Systeme, die bei der Serverzuordnung flexibel sind [SM96], um
50
eine Lastbalancierung zu erreichen oder den Ausfall von Komponenten zu kompensieren. Dies ist in
ADEPT
o;p &/qUr pUs1t qpUu
(
ebenfalls vorgesehen, ist aber nicht Thema dieses Beitrags.
8 Zusammenfassung und Ausblick
WfMSe mit expliziter Prozeß- und Datenmodellierung und der dynamischen Zuordnung von Bear-
beitern zu den auszuf¨uhrenden T¨atigkeiten sind eine vielversprechende Technologie f¨ur die Rea-
lisierung unternehmensweiter, vorgangsorientierter Anwendungssysteme. Die mit diesen Systemen
erreichbare Flexibilit¨at schl¨agt sich jedoch in einem relativ hohen Kommunikationsaufkommen zwi-
schen den Steuerungskomponenten (den WF-Servern) und den Anwendungskomponenten (den WF-
Klienten) nieder. In unternehmensweiten WfMS-basierten Anwendungssystemen, mit hunderten von
WF-Klienten und tausenden von aktiven WF-Instanzen spielt die daraus resultierende Belastung der
WF-Server, aber auch der zugrundeliegenden (Teil-)Netze eine wesentliche Rolle f¨ur das Antwort-
zeitverhalten und damit f¨ur die Einsetzbarkeit ¨uberhaupt.
Eine M¨oglichkeit, um die Netzbelastung zu reduzieren, ist, die Kommunikation zwischen WF-Servern
und ihren WF-Klienten jeweils m¨oglichst lokal innerhalb eines Teilnetzes zu halten, d.h., teilnetz¨uber-
greifende Kommunikation nach M¨oglichkeit zu vermeiden. Dies ist dadurch zu erreichen, daß eine
WF-Instanz nicht mehr komplett von dem initiierenden WF-Server gesteuert wird, sondern daß die
Steuerung w¨ahrend der Ausf¨uhrung ggf. auf andere WF-Server ”migriert“. In [BD97] haben wir eine
Modellierungskomponente und deren formale Grundlagen (vor allem die Bestimmung von Wahr-
scheinlichkeitsverteilungen und Kostenformeln) beschrieben, die bei der Modellierung von WFs die
Bestimmung geeigneter ”WF-Abschnitte“ erlaubt, die dann jeweils von einem anderen WF-Server
gesteuert werden. Hierbei wurden die ”Abschnittsserver“ zur Modellierungszeit ermittelt und festge-
legt. Dies f¨uhrt dann zu guten Ergebnissen, wenn die m¨oglichen Bearbeiter einer T¨atigkeit z.B. allein
durch ihre Rolle oder ihre Organisationseinheit beschrieben sind.
In diesem Beitrag haben wir untersucht, wie auch komplizierte Bearbeiterzuordnungen durch ein
WfMS ad¨aquat unterst¨utzt werden k¨onnen. Im Mittelpunkt standen hierbei sog. ”abh¨angige“ Bearbei-
terzuordnungen, bei denen die in Frage kommenden Bearbeiter oder die Organisationseinheiten einer
Aktivit¨at von vorangegangenen Aktivit¨at abh¨angen; ein praktisch sehr relevanter Fall. Wir haben ge-
zeigt, wie sich zum einen zur Modellierungszeit geeignete Absch¨atzungen durchf¨uhren lassen, und
wie zum anderen die WF-Steuerung so realisiert werden kann, daß zur Laufzeit bei Bedarf dynamisch
entschieden werden kann, welcher WF-Server f¨ur die Steuerung ausgew¨ahlt werden soll. Hierzu ha-
ben wir sog. Serverzuordnungsausdr¨ucke sowie entsprechende Modelle f¨ur die Wahrscheinlichkeits-
und Kostenabsch¨atzungen eingef¨uhrt. Die Korrektheit des Kostenmodells und der Verteilungsalgorith-
men wurde durch eine Implementierung und durch Messungen verifiziert [End98]. Außerdem wurde
durch Simulationen gezeigt, daß sich die Netzlast durch die hier beschriebenen Verfahren tats¨achlich
reduzieren l¨aßt.
Das Kostenmodell wird prim¨ar ben¨otigt, um eine geeignete Verteilung der Aktivit¨aten auf die WF-
Server (Serverzuordnungen) zu ermitteln. Es erlaubt aber auch Optimierungen in eine andere Rich-
tung. ¨
Anderungen an den Bearbeiterzuordnungen der Aktivit¨aten oder an der Verteilung der Bear-
beiter auf die Teilnetze haben Einfluß auf die Belastung der Teilnetze. Es gibt Szenarien, bei denen
in diesen Punkten Freiheitsgrade existieren (z.B. weil die Netzlast ein so großes Problem ist, daß
sogar ein Umbau des Kommunikationsnetzwerks in Erw¨agung gezogen wird oder weil dieses erst
noch aufgebaut werden muß). In solchen Szenarien kann das Kostenmodell verwendet werden, um
den durch eine m¨ogliche Ver¨anderung erzielten Gewinn abzusch¨atzen. Das Kostenmodell erm¨oglicht
51
also auch eine Optimierung des Organisationsmodells. ¨
Ahnlich wie bei der Optimierung des Ortes
f¨ur externe Datenquellen (vgl. Abschnitt 4.2.3) wird bei der Optimierung des Organisationsmodells
vom WfMS kein Vorschlag berechnet. Stattdessen erm¨oglicht das Kostenmodell, verschiedene Al-
ternativen zu vergleichen. F¨ur den Fall unabh¨angiger Bearbeiterzuordnungen haben wir in [BD97]
sogar einen Algorithmus vorgestellt, der eine optimale Verteilung der Benutzer auf die Teilnetze (auf-
grund der Rollenzuordnungen) ermittelt. Dieser kann auch bei abh¨angigen Bearbeiterzuordnungen
– f¨ur die einzelnen OEen getrennt – verwendet werden, indem die abh¨angige Bearbeiterzuordnung
durch
vxwy)z|{}~d5
ersetzt wird und nur Bearbeiter der betrachteten OE ber¨ucksichtigt werden. Mit
dem Algorithmus wird dann f¨ur die Benutzer einer bestimmten OE ermittelt, welche Bearbeiter dem-
selben Teilnetz zugeordnet werden sollen, weil sie ¨ahnliche Aktivit¨aten bearbeiten. Bearbeiter unter-
schiedlicher OEen geh¨oren i.d.R. sowieso verschiedenen Teilnetzenan, da die unterschiedlichen OEen
geographisch voneinander entfernt sind. Außerdem bearbeiten Benutzer unterschiedlicher OEen bei
Verwendung abh¨angiger Bearbeiterzuordnungen verschiedene WF-Instanzen. Da sie deshalb nicht
dieselben Aktivit¨ateninstanzen bearbeiten, sollten sie auch nicht demselben Teilnetz angeh¨oren.
Um ein komplettes Bild zu erhalten, m¨ussen auch transaktionale Aspekte und ihr Einfluß auf die
Kommunikationslast ber¨ucksichtigt werden. Dies war hier aus Platzmangel nicht m¨oglich. Aufgrund
unserer bisher durchgef¨uhrten Analysen sind wir aber sicher, daß unser Ansatz darunter nicht mehr
leidet (wenn ¨uberhaupt) als die meisten anderen verteilten Ans¨atze. Um tiefere Einblicke in die-
ses Thema zu gewinnen, haben wir begonnen, die in dieser Arbeit beschriebenen Konzepte in den
ADEPT-Prototypen zu integrieren.
Literatur
[AKA
m
94] G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. G¨unth¨or und C. Mohan: Fai-
lure Handling in Large Scale Workflow Management Systems. Technischer Bericht
RJ9913, IBM Almaden Research Center, November 1994.
[AMG
m
95] G. Alonso, C. Mohan, R. G¨unth¨or, D. Agrawal, A. El Abbadi und M. Kamath: Exoti-
ca/FMQM: A Persistent Message-Based Architecture for Distributed Workflow Mana-
gement. In: Proceedings of the IFIP Working Conference on Information Systems for
Decentralized Organisations, Trondheim, August 1995.
[BD97] T. Bauer und P. Dadam: A Distributed Execution Environment for Large-Scale Work-
flow Management Systems with Subnets and Server Migration. In: Proc. Second IFCIS
Conference on Cooperative Information Systems, S. 99–108, Kiawah Island, SC, Juni
1997.
[BD98] T. Bauer und P. Dadam: Architekturen f¨
ur skalierbare Workflow-Management-Systeme
– Klassifikation und Analyse. Ulmer Informatik-Berichte 98-02, Universit¨at Ulm, Fa-
kult¨at f¨ur Informatik, Januar 1998.
[BD99a] T. Bauer und P. Dadam: Efficient Distributed Control of Enterprise-Wide and
Cross-Enterprise Workflows. In: Proceedings Workshop Enterprise-wide and Cross-
enterprise Workflow Management: Concepts, Systems, Applications, 29. Jahrestagung
der GI (Informatik ’99), S. 25–32, Paderborn, Oktober 1999.
52
[BD99b] T. Bauer und P. Dadam: Efficient Distributed Workflow Management Based on Varia-
ble Server Assignments. Ulmer Informatik-Berichte 99-09, Universit¨at Ulm, Fakult¨at
f¨ur Informatik, November 1999. Erscheint in: Proc. 12th Conference on Advanced
Information Systems Engineering, Stockholm, Juni 2000.
[BD99c] T. Bauer und P. Dadam: Verteilungsmodelle f¨
ur Workflow-Management-Systeme –
Klassifikation und Simulation. Informatik Forschung und Entwicklung, 14(4):203–
217, Dezember 1999.
[BMR96] D. Barbar´a, S. Mehrotra und M. Rusinkiewicz: INCAs: Managing Dynamic Workflows
in Distributed Environments. Journal of Database Management, Special Issue on Mul-
tidatabases, 7(1):5–15, 1996.
[CGP
m
96] F. Casati, P. Grefen, B. Pernici, G. Pozzi und G. S´anchez: WIDE: Workflow Model and
Architecture. CTIT Technical Report 96-19, University of Twente, 1996.
[CGS97] S. Ceri, P. Grefen und G. S´anchez: WIDE – A Distributed Architecture for Workflow
Management. In: 7th International Workshop on Research Issues in Data Engineering,
Birmingham, April 1997.
[DKM
m
97] S. Das, K. Kochut, J. Miller, A. Sheth und D. Worah: ORBWork: A Reliable Dis-
tributed CORBA-based Workflow Enactment System for METEOR
n
. Technical Re-
port #UGA-CS-TR-97-001, Department of Computer Science, University of Georgia,
Februar 1997.
[EG96] J. Eder und H. Groiss: Ein Workflow-Managementsystem auf der Basis aktiver Daten-
banken. In: J. Becker, G. Vossen (Herausgeber): Gesch¨
aftsprozeßmodellierung und
Workflow-Management. International Thomson Publishing, 1996.
[End98] H. Enderlin: Realisierung einer verteilten Workflow-Ausf¨
uhrungskomponente auf Ba-
sis von IBM FlowMark. Diplomarbeit, Universit¨at Ulm, Fakult¨at f¨ur Informatik, 1998.
[HS96] P. Heinl und H. Schuster: Towards a Highly Scaleable Architecture for Workflow Ma-
nagement Systems. In: Proceedings of the 7th International Workshop on Database
and Expert Systems Applications, DEXA’96, S. 439–444, Zurich, September 1996.
[KAGM96] M. Kamath, G. Alonso, R. G¨unth¨or und C. Mohan: Providing High Availability in
Very Large Workflow Management Systems. In: Proceedings of the 5th International
Conference on Extending Database Technology, S. 427–442, Avignon, M¨arz 1996.
[MSKW96] J. A. Miller, A. P. Sheth, K. J. Kochut und X. Wang: CORBA-Based Run-Time Ar-
chitectures for Workflow Management Systems. Journal of Database Management,
Special Issue on Multidatabases, 7(1):16–27, 1996.
[MWW
m
98] P. Muth, D. Wodtke, J. Weißenfels, A. Kotz-Dittrich und G. Weikum: From Centrali-
zed Workflow Specification to Distributed Workflow Execution. Journal of Intelligent
Information Systems, Special Issue on Workflow Management Systems, 10(2):159–
184, M¨arz/April 1998.
[RD98] M. Reichert und P. Dadam: ADEPT
B
– Supporting Dynamic Changes of Workflows
Without Losing Control. Journal of Intelligent Information Systems, Special Issue on
Workflow Management Systems, 10(2):93–129, M¨arz/April 1998.
53
[SK97] A. Sheth und K. J. Kochut: Workflow Applications to Research Agenda: Scalable and
Dynamic Work Coordination and Collaboration Systems. In: Proceedings of the NATO
Advanced Study Institute on Workflow Management Systems and Interoperability, S.
12–21, Istanbul, August 1997.
[SM96] A. Schill und C. Mittasch: Workflow Management Systems on Top of OSF DCE and
OMG CORBA. Distributed Systems Engineering, 3(4):250–262, Dezember 1996.
[SNS99] H. Schuster, J. Neeb und R. Schamburger: A Configuration Management Approach
for Large Workflow Management Systems. In: Proceedings of the International Joint
Conference on Work Activities Coordination and Collaboration, San Francisco, Fe-
bruar 1999.
[Tan92] A.S. Tanenbaum: Computer-Netzwerke. Wolfram’s Fachverlag, 1992.
[WHKS98] M. Weske, J. H¨undling, D. Kuropka und H. Schuschel: Objektorientierter Entwurf
eines flexiblen Workflow-Management-Systems. Informatik Forschung und Entwick-
lung, 13(4):179–195, 1998.
[WWK
m
97] G. Weikum,D. Wodtke, A. Kotz-Dittrich,P. Muthund J.Weißenfels: Spezifikation, Ve-
rifikation und verteilte Ausf¨
uhrung von Workflows in MENTOR. Informatik Forschung
und Entwicklung, Themenheft Workflow-Management, 12(2):61–71, 1997.
[WWWK96a] J. Weißenfels, D. Wodtke, G. Weikum und A. Kotz-Dittrich: The Mentor Architecture
for Enterprise-wide Workflow Management. In: Proceedings of the NSF Workshop
on Workflow and Process Automation in Information Systems, S. 69–73, Athens, Mai
1996.
[WWWK96b] D. Wodtke, J. Weißenfels, G. Weikum und A. Kotz-Dittrich: The Mentor Project: Steps
Towards Enterprise-Wide Workflow Management. In: Proceedings of the 12th IEEE
International Conference on Data Engineering, S. 556–565, New Orleans, LA, M¨arz
1996.
Die meisten unserer Ver¨offentlichungen sind auf folgender Web-Seite verf¨ugbar:
http://www.informatik.uni-ulm.de/dbis/papers
A Berechnung der optimalen Abbildungsfunktion
In Abschnitt 4.3.1 wurden die m¨oglichen Serverzuordnungen beschrieben. In einer Server-
zuordnung ist es m¨oglich, den Server einer vorangegangenen Aktivit¨at (
{~Yw~dK
"
{~{~W
") oder den Domain des Bearbeiters einer solchen Aktivit¨at (
{~Yw~dK
"
w}1z|{}~dW;
") zu referenzieren. Des weiteren kann auf eine solche Serverzuordnung auch
noch eine Funktion
angewandt werden:
{~bw~K
"
{~{~W;
"bzw.
{~Yw~dK
"
1w}1z|{}~dW;;
". Eine optimale Funktion
kann automatisch ermittelt werden, muß also
nicht vom Modellierer vorgegeben werden. Wie dies funktioniert wird in diesem Abschnitt beschrie-
ben.
Soll f¨ur Aktivit¨at
¡
soll gepr¨uft werden, ob die Serverzuordnung
{~bw~K
"
{~%{~W;
"
zu einem guten Ergebnis f¨uhrt, so wird mit Algorithmus 19 eine optimale Funktion
berechnet.
54
Dazu werden alle Bearbeiter
i
von Aktivit¨at
durchlaufen, wobei jeweils die Serververteilung
¢{£{~vE~w ¤
i
ermittelt wird. Dann werden alle Bearbeiter
bn
von Aktivit¨at
¡
durchlaufen,
die der
z|{}~Yw~dK
zufolge m¨oglich sind, wenn der Benutzer
i
die Aktivit¨at
bearbeitet hat.
Der Domain
¥w}Kn
jedes Bearbeiters
Yn
wird ermittelt, da er (f¨ur diesen Bearbeiter) den opti-
malen Ort f¨ur den Server von Aktivit¨at
¡
darstellt. F¨ur jedes Paar von Bearbeitern
i
und
bn
wird
die Abbildung vom Server
von Aktivit¨at
zum optimalen Server von Aktivit¨at
¡
(
¥w} n
) in
H¨
aufigkeit vermerkt. Der Eintrag wird mit der Wahrscheinlichkeit
¦
§YpU¨© q'ª« t
k¬
¦
&/®qU¯ §YpU¨© q
k±°
¦
/§bpU¨© q]²« t³
¬
¦
& ®qU¯ /§bpU¨© q³«t
k¬
f¨ur das Auftreten dieses Paares (siehe Abschnitt 4.6.2) gewichtet. Da f¨ur Aktivit¨at
mehrere
Server
m¨oglich sind, wird der Eintrag zus¨atzlich mit
¢{£{~vE~w \¤
i
gewichtet. Wegen
´¶µ
{;£{~%vE~w \¤
i
¸·
, wird das Gewicht des jeweiligen Bearbeiterpaares durch diese Ge-
wichtung nicht beeintr¨achtigt. Nachdem alle m¨oglichen Paare von Bearbeitern durchlaufen wurden,
wird f¨ur jeden Server
i
von Aktivit¨at
der optimale Zielserver
Pn
f¨ur die Abbildungsfunktion
ausgew¨ahlt. Dies ist der mit dem gr¨oßten Eintrag H¨
aufigkeit
i¹
n
f¨ur diesen Server
i
. Wenn der-
selbe maximale Eintrag in H¨
aufigkeit f¨ur mehrere Server
n
auftritt, so kann von diesen ein beliebiger
ausgew¨ahlt werden, da sie alle gleich g¨unstig sind.
Algorithmus 19 (Ermitteln einer optimalen Abbildungsfunktion
º
)
»¼Y½5¾)¼¿
:H¨
aufigkeit
À
¼Á½¾)¼¿5ÂKÃÅÄ
;
ÆÈÇÉ5ÊËÍÌ1ÎÇ-ÏÐ1Ñ-ÒdÌ ½±Ã
´ÔÓÕÖÁ×/Ø'ÙbÚÛ Ü)Ý1Þ
ÆÈÇ5ÏÐ=ÑÒÌß
À]à
Â
;
for each
à
½á|âÈã ÌäÇ3Êåæ;ß
do
ç
Ç)è ¼Ç5å3é âåãæ ß
À
¼ê
à
½;Âëà ç
Ç)è ¼Ç5å3é
À'ì
¾
"
äÇ3Êåæ Ã
à
½
"
Â
;
äÇ3Êåæ
Óí
öî
à
êï Ñ;Ì ãåâÈã É3ÉÐæ;ðÇ
À'ì
¾
à
½¾)ñ¾
à
ÂKÃÔò å
à
Çó
;
ÆÈÇÉ-ÊËÍÌ1ÎÇ5ÏÐ=ÑÒÌ ¿
À]à
½ÂKÃ
´ÓÕÙbÚÛ Ü)ÝWô
í
ÆÈÇ5ÏÐ=ÑÒÌ/õ
À'à
Â
;
for each
à
¿á äÇ3Êåæ
Óí
do
çãËöÊÐ1÷ ¿Ã çãËÍÊÐ1÷
À'à
¿-Â
;
»¼
:H¨
aufigkeit
À
¼P¾ çãËöÊÐW÷ ¿5ÂKÃ
H¨
aufigkeit
À
¼¾ çãËÍÊÐ1÷ ¿-Â
ø
ÆÈÇ5ÏÐ=ÑÒÌß
À'à
½ Â
ÆÈÇÉ-ÊËÍÌ1ÎÇ5ÏÐ=ÑÒÌ ½ù
ÆÈÇ-ÏÐ1Ñ-ÒdÌ/õ
À]à
¿5Â
ÆÈÇÉ5ÊËúÌ1ÎÇ5ÏÐ=ÑÒdÌ ¿
À'à
½ Â
ù
ç
Ç)è ¼Ç5å3é âåãæß
À
¼ê
à
½Â
ÀWû
Â
for each
¼Á½
do
ü
À
¼Á½-ÂþýÃÿ¼¿
mit
»¼
¿
ý
H¨
aufigkeit
À
¼Á½¾)¼
¿
Â
H¨
aufigkeit
À
¼Á½¾)¼¿5Â
;
Um f¨ur Aktivit¨at
¡
die Eignung der Serverzuordnung
{~\bw~K
"
1w}1z|{}~dW;;
"
zu pr¨ufen, kann ein ¨ahnlicher Algorithmus verwendet werden. Allerdings ist dann nicht die Server-
WV von Aktivit¨at
relevant, sondern deren Bearbeiter-WV. Deshalb wird f¨ur jeden Bearbeiter
i
von Aktivit¨at
nicht
{;£{~%vE~w \¤
i
, sondern der
¥w}
i
w}W
i
ermittelt, weil
dieser in
{~bw~K
referenziert wird und damit den Server von Aktivit¨at
¡
determiniert. Die mit
markierte Zeile in Algorithmus 19 muß damit wie folgt lauten:
H¨
aufigkeit
À
çãËöÊÐ1÷
½¾çãËÍÊÐ1÷
¿ÂKÃ
H¨
aufigkeit
À/À
çãËÍÊÐ1÷
½¾çãËöÊÐ1÷
¿Â
ø
ÆÈÇ5ÏÐ=ÑÒÌß
À'à
½ Â
ÆÈÇÉ-ÊËÍÌ1ÎÇ5ÏÐ=ÑÒÌ
½ù
ÆÈÇ-ÏÐ1Ñ-ÒdÌ/õ
À]à
¿5Â
ÆÈÇÉ5ÊËúÌ1ÎÇ5ÏÐ=ÑÒdÌ
¿
À'à
½Â
B Beweise
Im folgenden werden einige der in dieser Arbeit gemachten Aussagen bewiesen.
55
B.1 Korrektheit von Algorithmus 9
Um die Korrektheit von Algorithmus 9 zeigen zu k¨onnen, ben¨otigen wir Lemma 1: Das Gesamtge-
wicht aller Bearbeiter einer Aktivit¨at
¡
wird durch die Multiplikation mit
Í
in Algorithmus 8
nicht ver¨andert. Es kommt nur zu Verschiebungen zwischen den OEen.
Lemma 1:
´
t
Pu q
r
²
E{
yW
´
t
Pu q
r
²
W
Beweis:
´
t
Pu q
r
²
E{
yW
´
´
t
Pu q
r
²
«t
¬
E{
y)WP
´
´
t
Pu q
r
²
«t
¬
!
ö
°
W
´
E%
Í
°
´
t
Pu q
r
²
«t
¬
W
´
"
Py;{
#
"
%$
!
ö
"
Py;{
#
1z|{}~d-%
!
ö
°
´
t
&
Pu q
r
²
«t
¬
'
%WP
´
"
Py;{
#
1z|{}~d
!
ö
"
Py;{
#
1z|{}~d5
!
ö
°
´
t
Pu q
r
²
«t
¬
W
mit
zö{}~dYw~dK
ist (indirekt) von Aktivit¨at
abh¨angig:
(
¡
¹
)
¹
*
+-,
mit
*/.
0
z
¹
!21
.
{;£b{K%{
5{
3$
und
zö{}~dYw~d
h¨angt von keiner weiteren Aktivit¨at ab:
(
¹
) 4658797:+-,
.
{;£b{K%{
5{
3$
d.h.:
;!=<
"
Py;{
#
"
%$
Í
"
Py;{
#
"
%$
Í
"
Py;{
#
Wz|{}~d
Í
´
"
Py{
#
1z|{}~
!
ö
´
t
Pu q
r
²
«t
¬
'
%WP
>
´
t
&
Pu q
r
²
E%WP
°
´
t
Pu q
r
²
«t
¬
'
E%WP
´
t
Pu q
r
²
W
°
´
"
Py;{
#
Wz|{}~d
!
Í
´
t
Pu q
r
²
W
°
´
?
´
t
Pu q
r
ª
«t
¬
W
@
´
t
Pu q
r
ª
WP
A
´
t
Pu q
r
²
W
°
·
´
t
Pu q
r
ª
W
°
´
´
t
Pu q
r
ª
«t
¬
'
W
´
t
Pu q
r
²
W
°
·
´
t
Pu q
r
=ª
W
°
´
t
Pu q
r
=ª
W
´
t
Pu q
r
²
W
Mit Hilfe von Lemma 1 ist es nun m¨oglich, Lemma 2 zu beweisen. Lemma 2 besagt, daß der An-
teil der Bearbeiter der Organisationseinheit
!
an Aktivit¨at
¡
(jeweils mit
E{
yW
gewichtet)
56
dem Anteil dieser OE an der Ausf¨uhrung dieser Aktivit¨at (
"
Py;{
#
"
%$
Í
) entspricht. Da alle
Bearbeiter einer OE mit demselben Faktor
!
ö
gewichtet werden, kann es innerhalb dieser Be-
arbeiter zu keinen ”Verzerrungen“ der Gewichte kommen. Damit ist gezeigt, daß die Berechnung von
E{
yW
in Algorithmus 9 auf korrekte Art und Weise erfolgt.
Lemma 2: Wenn Aktivit¨at
die OE der Bearbeiter von Aktivit¨at
¡
bestimmt, gilt
;
:
´
t
Pu q
r
²
«t
¬
E{
y)WP
@
´
t
Pu q
r
²
E{
yW
"
Py;{
#
"
%$
Í
Beweis:
;
gilt:
´
t
Pu q
r
²
«t
¬
E{
y)WP
@
´
t
Pu q
r
²
E{
yW
B
®®
DC
´
t
Pu q
r
²
«t
¬
'
E%
Í
°
E%WP
@
´
t
Pu q
r
²
W
´
t
&
Pu q
r
²
«t
¬
'
"
Py;{
#
"
%$
Í
"
Py;{
#
1z|{}~d5%
Í
°
W
@
´
t
Pu q
r
²
W
"
Py{
#
"
E$
!
ö
"
Py{
#
1z|{}~5%
!
Í
°
´
t
Pu q
r
²
«t
¬
E%WP
@
´
t
Pu q
r
²
W
"
Py;{
#
"
%$
Í
´
t
&
Pu q
r
²
«t
¬
'
E%WP
@
´
t
&
Pu q
r
²
E%WP
°
´
t
&
Pu q
r
²
«t
¬
'
E%WP
@
´
t
Pu q
r
²
W
"
Py;{
#
"
%$
Í
B.2 Korrektheit von Algorithmus 14
Lemma 3 zeigt, daß Algorithmus 14 in den for-Schleifen alle relevanten F¨alle ber¨ucksichtigt. Der
Grund daf¨ur ist, daß die Summe der Wahrscheinlichkeiten (f¨ur alle betrachteten Kombinationen der
Bearbeitern von Aktivit¨at
und
¡
) 1 ergibt, was der Wahrscheinlichkeit entspricht, daß die Aktivit¨aten
und
¡
von genau einem Benutzerpaar bearbeitet werden.
Lemma 3:
´
t
k
Pu q
r
ª
´
t³
r
GF
k
H
E{
y W
IC
5
E{
J$
} y
K
%{
y
LC
°
x{
M
y)Wbn
x{
J$
} y
K
%{
ynW
IC
5
N
= 1
Beweis:
´
t
k
Pu q
r
ª
´
t³
r
GF
k
H
x{
M
y W
C
5
E{
J$
} y
K
%{
y
OC
°
E{
yWYn
E{
J$
} y
K
%{
ynW
IC
5
N
´
t
k
Pu q
r
=ª
H
E{
y W
IC
5
E{
J$
} y
K
%{
y
C
°
´
t³
O
r
F
k
E{
y)Wbn
E{
3$
} y
K
%{
y nW
C
N
·
E{
3$
} y
K
%{
y
LC
°
P
t
k
Pu q
r
=ª
H
x{
M
y W
C
5
Q RS T
¦
VU
® qU¯ §YpU¨© q
k
°
·
E{
3$
} y
K
%{
ynW
C
5
°
P
t³
O
r
F
k
E{
yWYn
Q RS T
¦
VU
® qU¯ /§bpU¨© q³«t
k/¬
N
·
57
Außerdem gilt analog
´
t³
O
r
GF
k
¦
/§bpU¨© q]²3« t³
¬
¦
U
®qU¯ /§bpU¨© q
³
«t
k¬
·
, so daß die Gewichtung des Bearbeiters
C
von Aktivit¨at
nicht durch die Multiplikationen mit
¦
§bpI¨/© q²«t³
¬
¦
U
®qU¯ §bpI¨/© q³«t
k¬
beeintr¨achtigt wird.
Das Gesamtgewicht eines Bearbeiterpaares
C
und
Yn
wird durch die Multiplikation mit
dem Faktor
¢{£P{~vx~w
WC
¤
C
5
°
¢{£{~vE~w nd¤ Yn
nicht beeinflußt, weil wegen
´µ
k
{;£{~%vE~w
C
¤
C
"
´µ
³
¢{£P{~vx~w
n¤ nþ ·
gilt:
´µ
k
´µ
³
{;£{~%vE~w
WC
¤
IC
5
°
¢{£{~vE~w nd¤ Ynþ ·
.
B.3 Anteil der nicht analysierten Iterationen einer Schleife
Mit Hilfe von Lemma 4 ist es m¨oglich, abzusch¨atzen, wie groß der Anteil der nicht analysierten
Iterationen einer Schleife (und damit der Fehler) maximal ist, wenn
}
°
XZY
y
Iterationen analysiert
werden. Die Wahrscheinlichkeit, daß Iteration
ausgef¨uhrt wird, betr¨agt
£
p
·
\[^]
p
-_ C
°
]
mit
]
ö
·
J@
XZY
y
(vgl. Abschnitt 5.3.3). Der Anteil der nicht mehr analysierten Iterationen ist damit die Summe
der
£p
f¨ur
a`
. Es kann
XZY
y
cb
·
angenommen werden, da in ADEPT die Schleifenbedingung
am Ende der Schleife gepr¨uft wird (Repeat-Until), weshalb immer mindestens ein Schleifendurchlauf
ausgef¨uhrt wird.
Lemma 4:
d
´
p
e
m
C
£p
gf
{
_
mit
£p
?
·
\[
·
A
p
-_ C
°
·
f¨ur
hb
·
und
}
i`kj
Beweis:
d
´
p
e
m
C
£p ·
9[
e
´
p
C
£p ·
l[
e
´
p
C
?
·
m[
·
A
p
-_ C
°
·
·
l[
·
°
e
´
p
C
?
·
9[
·
A
p
-_ C
·
l[
·
°
e
_ C
´
p
En
?
·
9[
·
A
p
Co
·
p[
·
°
·
p[
?
·
p[
·
J@
%A
e
·
p[
·
p[
·
J@
P
·
p[
?
·
p[
?
·
p[
·
A
e
A
|
?
·
p[
·
A
e
f
{
_
,
weil 1)
qsrst
Ju
d
?
·
p[
·
A
e
{
_
und 2)
?
·
\[
·
A
e
monoton wachsend f¨ur
hb
·
:
1)
qsrt
Ju
d
?
·
p[
·
A
e
vqsrst
Ju
d
{
e
e wyx
«
C _C
>
¬
{
_
, weil
qrst
Ju
d
°
qsz
P·
p[
·
J@
Pþ
{qsrt
Ju
d
qsz
K·
p[
·
J@
P
·
J@
n
n
qsrst
Ju
d
?
qsz
P·
p[
·
J@
P
VA}|
?
·
J@
~A|
vqsrst
Ju
d
·
·
\[
·
J@
°
?
j
a)
qsrt
Ju
d
qsz
K·
p[
·
Q RS T
uC
Q RS T
u
n
·
¨[
·
Q RS T
u
n
= 0
b)
?
qsz
K·
p[
·
·
¨[
·
A©|
·
·
p[
·
J@
°
?
j