Effiziente Realisierung von Prozess-Schemaevolution in Hochleistungs-Prozess-Management-Systemen [original]

Universit¨

at Ulm

Fakult¨

at f¨

ur Informatik

Abteilung Datenbanken und Informationssysteme

Effiziente Realisierung von

Prozess–Schemaevolution

in Hochleistungs–Prozess–Management–Systemen

Diplomarbeit

vorgelegt von

Markus Lauer

17. Dezember 2004

1. Gutachter: Prof. Dr. Peter Dadam

2. Gutachter: Dr. Manfred Reichert

Zusammenfassung

Immer mehr Unternehmen setzen zur Verwaltung und ¨

Uberwachung ihrer betrieblichen Prozes-

se sogenannte Prozess-Management-Systeme (PMS) ein. Eine der wichtigsten Voraussetzungen

f¨

ur einen sinnvollen Einsatz ist es, dass PMS die Eigenschaft der Adaptivit¨

at besitzen: Sie

m¨

ussen ¨

Anderungen der hinterlegten Prozessvorlagen und der sich in Ausf¨

uhrung befindlichen

Prozesse zur Laufzeit zulassen, damit die Unternehmen in der Lage sind, flexibel und schnell

auf neue Anforderungen zu reagieren. Dies stellt jedoch hohe Anspr¨

uche an ein PMS: Effizien-

te Algorithmen m¨

ussen daf¨

ur sorgen, dass die ¨

Anderungen nicht zu inkonsistenten Zust¨

anden

von Prozessvorlagen und -instanzen f¨

uhren. Modifikationen der Prozessvorlagen m¨

ussen, wo vom

Ausf¨

uhrungsfortschritt her m¨

oglich, auf die darauf basierenden Prozessinstanzen propagiert wer-

den. Bei Instanzen, die sich aufgrund von Ad-hoc-¨

Anderungen in ihrem Ablauf gegen¨

uber der

Vorlage unterscheiden, m¨

ussen zus¨

atzlich ohne großes Eingreifen seitens der Benutzer Probleme

erkannt und beseitigt werden, die sich bei der Migration auf die neue Version aus ¨

uberlappenden

oder widerspr¨

uchlichen Instanz- und Vorlagen¨

anderungen ergeben. Dabei d¨

urfen die anderen,

parallel ablaufenden Funktionen des Systems nicht beeintr¨

achtigt werden, selbst wenn in realen

Anwendungen tausende von Instanzen migriert werden m¨

ussen. Hinzu kommt, dass dem System

f¨

ur diese Aufgaben nur eingeschr¨

ankt Ressourcen, wie z. B. Speicher, zur Verf¨

ugung stehen.

Alle diese Anforderungen verlangen nach einer flexiblen und ressourcensparenenden Architek-

tur sowie nach einer effizienten Implementierung. Die auf dem Markt erh¨

altlichen Produkte

bieten entweder gar keine oder nur eingeschr¨

ankte ¨

Anderungsm¨

oglichkeiten zur Laufzeit oder

erf¨

ullen die angesprochenen Anforderungen nur unzureichend. Wir entwickeln in unserem Pro-

jekt AristaFlow ein Prozess-Management-System, welches ¨

Anderungen zur Laufzeit vollst¨

andig

unterst¨

utzt.

Die Diplomarbeit stellt daf¨

ur einen Ansatz zur internen Repr¨

asentation von Prozessvorlagen und

-instanzen vor, der volle Adaptivit¨

at bereitstellt und den Anforderungen an einen Praxiseinsatz

gen¨

ugt. Darauf aufbauend werden zwei Optimierungsans¨

atze diskutiert, die das Ziel haben, den

Migrationsprozess im Ganzen zu beschleunigen. Bei einem Prozess-Management-System werden

viele Aktionen gleichzeitig ausgef¨

uhrt. Ohne Kontrolle bzw. Synchronisation durch das System

kann es dabei zu Problemen aufgrund von konkurrierenden Aktionen kommen. Diese Arbeit

analysiert die Probleme, die bei der vorgestellten Architektur zwischen der Schemaevolution,

der Ad-hoc-Modifikation, der Migration und dem Weiterschalten von Instanzen auftreten k¨

onnen

und zeigt L¨

osungsm¨

oglichkeiten auf.

Vorwort

Meine Diplomarbeit durfte ich ¨

uber ein sehr interessantes, aber auch sehr weitgreifendes Thema

verfassen.

An dieser Stelle m¨

ochte ich mich bei Herrn Prof. Dr. Peter Dadam bedanken, dass ich mich in

seiner Abteilung in dieses Metier einarbeiten durfte und so eine solide sachliche Grundlage f¨

diese Arbeit bekam.

Ganz besonders danke ich meinen Betreuern Frau Stefanie Rinderle und Herrn Dr. Manfred

Reichert, die mir immer mit Rat und Tat beiseite standen, stets ein offenes Ohr f¨

ur meine

Fragen hatten und mir mit ihren Anregungen immer wieder neue Impulse gaben.

Besonderer Dank gilt auch meinen Eltern, meiner Schwester und besonders meinen Studienkolle-

gen, die mich immer – mehr oder weniger freiwillig – unterst¨

utzten, indem sie Korrektur gelesen,

mein st¨

andiges Klagen erduldet oder mir Mut zugesprochen haben. Besonders nett fand ich von

meinen Studienkollegen, dass sie aus Solidarit¨

at den Sommer ¨

uber mit mir in der Universit¨

saßen und arbeiteten, anstatt die Tage im Urlaub am See oder am Meer zu verbringen.

Namentlich erw¨

ahnen m¨

ochte ich noch Ulrich Kreher, der mir viel geholfen hat, gerade die

anstrengende, nervenaufreibende Schlussphase gut zu ¨

uberstehen, auch wenn seine konstruktive

Kritik mir so manchen Schock versetzt hat und einen riesen Berg Arbeit vor meinem geistigen

Auge entstehen ließ. Auch meinen Kollegen Elmar Schoch m¨

ochte ich hier nicht vergessen.

All denen, die mich so super unterst¨

utzt haben und welchen ich mit meinem d¨

unnen Nerven-

kost¨

um zu schaffen machte, m¨

ochte ich f¨

ur ihre Nachsicht und Geduld einen Anteil an dieser

Arbeit zusprechen.

Ulm, den 17. Dezember 2004

Inhaltsverzeichnis

Vorwort i

Inhaltsverzeichnis ii

1 Einf¨

uhrung 1

1.1 Aufgaben von Prozess-Management-Systemen . . . . . . . . . . . . . . . . . . . . 2

1.2 Adaptivit¨

at ....................................... 4

1.3 Adaptivit¨

atundkommerziellePMS.......................... 8

1.4 Problemstellung und Fokus der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Konzepte des adaptiven Prozess-Managements 11

2.1 Schemaevolution .................................... 11

2.1.1 KorrekteSchemata............................... 12

2.1.2 Ablauf einer Schemaevolution . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Instanzen und Schemaevolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Migration ........................................ 16

2.3.1 Migration unverzerrter Instanzen . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Migration verzerrter Instanzen . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.3 Vertr¨

agliche und unvertr¨

agliche Instanzen . . . . . . . . . . . . . . . . . . 21

2.3.4 Markierungsanpassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.5 Ablauf der Migration einer Instanz . . . . . . . . . . . . . . . . . . . . . . 26

2.4 Dynamische ¨

Anderungen................................ 27

INHALTSVERZEICHNIS iii

2.5 Zusammenfassung ................................... 29

3 Realisierung von Prozessvorlagen und -instanzen 30

3.1 NaiverArchitekturansatz ............................... 30

3.2 Architekturansatz ................................... 31

3.3 Schemaevolution und Migration unverzerrter Instanzen . . . . . . . . . . . . . . . 32

3.4 Repr¨

asentationsvariante f¨

ur verzerrte Instanzen . . . . . . . . . . . . . . . . . . . 33

3.5 DieDelta-Schicht.................................... 35

3.6 Migration verzerrter Instanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6.1 Migration bei disjunkten ¨

Anderungsoperationen . . . . . . . . . . . . . . 40

3.6.2 Migration bei ¨

aquivalenten ¨

Anderungsoperationen . . . . . . . . . . . . . 42

3.6.3 Migration bei subsumptions-¨

aquivalenten ¨

Anderungsoperationen . . . . . 42

3.6.4 Migration bei partiell ¨

aquivalenten ¨

Anderungensoperationen . . . . . . . . 43

3.7 Delta-Schicht und andere Prozess-Modelle . . . . . . . . . . . . . . . . . . . . . . 43

3.8 Proof-Of-Concept-Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.9 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Optimierungsans¨

atze 48

4.1 Instanz-Gruppierung nach Laufzeitzustand . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Meilenstein-Ansatz................................... 54

4.3 Zusammenfassung und Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Nebenl¨

aufigkeit 58

5.1 Vorlagen¨

anderung ↔Vorlagen¨

anderung ....................... 59

5.2 Vorlagen¨

anderung ↔Weiterschalten ......................... 66

5.3 Vorlagen¨

anderung ↔Dynamische ¨

Anderungen ................... 70

5.4 Dynamische ¨

Anderungen ↔Weiterschalten ..................... 73

5.5 Dynamische ¨

Anderungen ↔Dynamische ¨

Anderungen ............... 75

5.6 Migration ↔Weiterschalten.............................. 76

5.7 Migration ↔Vorlagen¨

anderung............................ 80

iv INHALTSVERZEICHNIS

5.8 Migration ↔Dynamische ¨

Anderungen........................ 83

5.9 Zusammenfassung ................................... 88

6 Zusammenfassung 89

Literaturverzeichnis 93

Abbildungsverzeichnis 96

Anhang 99

A Berechnung der Anzahl m¨

oglicher Instanzzust¨

ande 99

A.1 Berechnung bei Prozessen mit nur sequentiell angeordneten Aktivit¨

aten . . . . . 99

A.2 Berechnung bei Prozessen mit zwei parallelen Ausf¨

uhrungsstr¨

angen . . . . . . . . 100

A.3 Berechnung bei dem Prozess aus Abbildung 4.3 . . . . . . . . . . . . . . . . . . . 101

B Proof-Of-Concept-Prototype 102

Kapitel 1

Einf¨

uhrung

”Wer rastet, der rostet!“ lautet ein weit verbreitetes Sprichwort. Mit diesem Sprichwort l¨

asst

sich sehr gut die Situation der Unternehmen in der heutigen globalen Gesch¨

aftswelt beschrei-

ben. Wer es sich heute erlaubt, sich auf dem bisher erreichten Niveau bez¨

uglich angebotener

Produkte bzw. Dienstleistungen, Qualit¨

at und Kosten auszuruhen, wird sehr schnell ¨

uberrollt

werden von der Masse an Konkurrenten. Um im globalen Wettbewerb bestehen zu k¨

onnen, ist es

unbedingt notwendig, sich st¨

andig und schnell auf einen sich ver¨

andernden Markt einzustellen,

flexibel auf neue Anforderungen zu reagieren, sowie die Entwicklungs- und Produktionszeiten zu

verk¨

urzen. Gleichzeitig m¨

ussen die Gesamtkosten minimiert und die Qualit¨

at der Arbeit maxi-

miert werden. Die Qualit¨

at der Arbeit umfasst dabei nicht nur die G¨

ute der Produkte bzw. der

Dienstleistungen, sondern auch, dass die Erf¨

ullung des Kundenwunsches in der geforderten Zeit

erfolgt.

Ein wichtiger Schritt, um die Kosten zu minimieren und die Qualit¨

at zu maximieren, ist es,

die Gesch¨

aftsprozesse des Betriebes als Ganzes zu erfassen, auf Schwachstellen, Engp¨

asse sowie

unn¨

otige Arbeitsschritte zu analysieren, den Prozess auf diese Erkenntnisse hin zu optimie-

ren und dann die Einhaltung der Arbeitsabfolgen und der vorgegebenen Zeiten zu ¨

uberwachen

(vgl. [RD02, S. 1-4]).

Stand heute ist, dass in den Unternehmen zwar die einzelnen Prozessschritte f¨

ur sich betrachtet

h¨

ochst effizient ausgef¨

uhrt werden, der Prozess als Ganzes aber nicht an das Optimum heran-

kommt. Erh¨

ohte Produktionszeiten sind die Folge. Der Grund f¨

ur die fehlende Optimierung auf

Prozessebene ist in der Arbeitsteilung zu suchen. Ein Mensch versucht von Natur aus, m¨

oglichst

wenig Energie f¨

ur seine Arbeit aufzubringen, und optimiert deshalb seinen Arbeitsablauf be-

wusst oder unbewusst. Da eine Person aufgrund der (notwendigen) Arbeitsteilung nicht mehr

f¨

ur den gesamten (Herstellungs-)prozess (z. B. eines Autos) sondern nur f¨

ur einzelne Teilschritte

(z. B. Innenverkleidung anbringen) verantwortlich ist, werden auch nur die einzelnen Teilschritte

f¨

ur sich betrachtet im Ablauf optimiert. Das Zusammenspiel der einzelnen Teilprozesse bleibt

von der Optimierung aber unber¨

uhrt (vgl. [RD02, S. 1-2 ff.]).

2KAPITEL 1. EINF ¨

UHRUNG

Der Gesamtprozess jedoch l¨

asst sich z. B. dahingehend verbessern, dass einzelne Teilschritte,

wo m¨

oglich, statt bisher sequentiell parallel ausgef¨

uhrt werden [RD02, S. 4-5]. Damit kann die

Produktionszeit erheblich verk¨

urzt werden. Oder es lassen sich zwei getrennt ausgef¨

uhrte Ar-

beitsschritte zusammenfassen [RD02, S. 4-5]. Damit l¨

asst sich Zeit und Geld f¨

ur Transport von

einem Arbeitsplatz zu einem anderen einsparen. Der freigewordene Arbeitsplatz kann dann an-

derweitig genutzt werden. Identifizierte Engp¨

asse k¨

onnen durch die Einf¨

uhrung von zus¨

atzlichen

parallelen Arbeitsschritten beseitigt werden.

Um ¨

uberhaupt Ansatzpunkte f¨

ur Optimierungen finden zu k¨

onnen, muss ein ¨

Uberblick ¨

uber

die teilweise sehr großen und komplexen Arbeitsabl¨

aufe eines Betriebes geschaffen werden. Pro-

zessmodellierungstools, wie z. B. ARIS Toolset1, k¨

onnen dabei helfen. Diese Tools erlauben es,

Ablaufstrukturen graphisch zu modellieren und darauf basierend Simulationen durchzuf¨

uhren

[RD02, S. 3-119 ff., S. 4-6]. Durch diese Simulationen k¨

onnen z. B. Engp¨

asse erkannt werden, oder

es kann damit ¨

uberpr¨

uft werden, ob ¨

Anderungen am Ablauf die gew¨

unschte Wirkung erzielen.

Doch was n¨

utzt der beste Arbeitsplan, wenn er in der Praxis nicht eingehalten wird, sei es, dass

Arbeitsschritte durch den menschlichen Faktor vergessen werden (z. B. eine wichtige Unterschrift

besorgen), oder dass die angesetzte Zeit nicht eingehalten wird, da z. B. Akten nicht aufgefun-

den werden? Unn¨

otige Arbeit, ¨

Uberschreitung von Fristen oder sogar Abbr¨

uche von ganzen

Vorg¨

angen drohen. Zum Beispiel darf ein Arzt nicht operieren, wenn er keine Einverst¨

andnis-

erkl¨

arung des Patienten vorweisen kann. Die entstandenen zus¨

atzlichen Kosten k¨

onnen immens

sein, besonders wenn der Betrieb auf Nicht-Erf¨

ullung eines Vertrages verklagt wird. Hier kommen

nun Prozess-Management-Systeme (PMS) ins Spiel.

1.1 Aufgaben von Prozess-Management-Systemen

PMS sind komplexe Softwaresysteme, die ein Unternehmen bei der Prozessabwicklung in Bezug

auf Einhaltung der Arbeitspl¨

ane unterst¨

utzen sollen (vgl. [RD02, S. 1-37 ff.]): In den Systemen

werden die optimierten Arbeitspl¨

ane als Prozessvorlagen hinterlegt. Anhand der Arbeitspl¨

ane

und anhand der Informationen, wie weit ein Prozess fortgeschritten ist, bestimmen sie die als

n¨

achstes auszuf¨

uhrenden Arbeitsschritte und stellen den daf¨

ur in Frage kommenden Mitarbei-

tern entsprechende Arbeitsvermerke in deren pers¨

onliche Arbeitsliste. Zus¨

atzlich stellen sie dem

Bearbeiter, der die Aufgabe ¨

ubernimmt, alle zur Bearbeitung notwendigen Daten zur Verf¨

ugung.

Dadurch k¨

onnen z. B. Verz¨

ogerungen aufgrund nicht gefundener Akten vermieden werden. Dazu

m¨

ussen alle f¨

ur einen Prozessablauf relevanten Daten im System hinterlegt werden. Gleichzeitig

uberwachen die Systeme, dass s¨

amtliche Aktivit¨

aten in der vorgegebenen Zeitspanne in Angriff

genommen und auch in der eingeplanten Zeit abgeschlossen werden. Drohen Zeit¨

uberschreitun-

gen, so werden die verantwortlichen Personen darauf aufmerksam gemacht.

PMS unterst¨

utzen aber nicht nur Aktivit¨

aten, die von Menschenhand ausgef¨

uhrt werden m¨

ussen,

sondern auch Schritte, die ganz automatisch von einem System erledigt werden k¨

onnen. Zum Bei-

1http://www.ids-scheer.de/

1.1. AUFGABEN VON PROZESS-MANAGEMENT-SYSTEMEN 3

spiel k¨

onnte ein PMS automatisch ein Buchungsprogramm veranlassen, den Betrag einer f¨

alligen

Rechnung auf das Konto des Gl¨

aubigers zu ¨

uberweisen. Die Vorgehensweise des PMS bei auto-

matischen Agenten ist ¨

ahnlich der bei menschlichen. Beim Starten der Aktivit¨

at ”Rechnungs-

betrag ¨

uberweisen“ im Gesch¨

aftsprozess ”Rechnung bezahlen“ ruft das PMS die entsprechende

Software auf und ¨

ubergibt die ben¨

otigten Daten, wie z. B. die Kontonummer und Bankleitzahl

des Empf¨

angers und den Rechnungsbetrag. Die Buchungssoftware f¨

uhrt die Transaktion aus

und meldet durch einen entsprechenden R¨

uckgabewert die erfolgreiche ¨

Uberweisung. Das PMS

nimmt diesen Wert entgegen und speichert ihn, um z. B. in einem sp¨

ateren Schritt eine Bu-

chungsbest¨

atigung ausdrucken zu k¨

onnen. Danach bestimmt es die n¨

achsten abzuarbeitenden

Aufgaben.

Die F¨

ahigkeit, auch automatische Agenten zu unterst¨

utzen, macht die PMS interessant f¨

ur den

Einsatz in einer dienstbasierten Architektur (englisch: Service Oriented Architecture (SOA)).

Die Idee hinter einer dienstbasierten Architektur ist, mehrere unabh¨

angige (Software-)dienste

(Services), die jeder f¨

ur sich eine bestimmte Aufgabe erf¨

ullen, zusammenzuschalten und zu einer

neuen Anwendung mit eigener Funktionalit¨

at zu kombinieren, wie in Abbildung 1.1 illustriert

[RD02, S. 6-15 ff.]. F¨

ur die Steuerung der Abfolge der Service-Aufrufe (Service Flow) k¨

onnen

A11 A12

A21 A22

ServiceProvider2

ServiceProvider1

ServiceProvider3

Service

ServiceOperation

A1 A2 A3 A4

ServiceFlow1

ServiceProvider4

Anwendung1

Anwendung2

ServiceFlow2

Abbildung 1.1: Service Flows und Services (in Anlehnung an [RD02, Abb. 6-13])

4KAPITEL 1. EINF ¨

UHRUNG

PMS eingesetzt werden. Das PMS bestimmt anhand der z. B. mit BPEL4WS2beschriebenen

Prozessvorlagen die als n¨

achstes auszuf¨

uhrenden Services, ruft diese gem¨

aß den vorgegebenen

Protokollen auf, ¨

ubergibt die ben¨

otigten Parameter und nimmt nach erfolgter Abarbeitung die

Ergebnisse entgegen, um sie den folgenden Diensten als Eingabe bereitzustellen. Der SOA kommt

in der Software-Entwicklung eine stark zunehmende Bedeutung zu, da dieser Ansatz immense

Kosteneinsparungen verspricht: Die Wiederverwendung bereits bestehender und im Einsatz er-

probter Dienste verk¨

urzt die Entwicklungs- und Programmierzeit – das Rad muss nicht mehr neu

erfunden werden – und erspart aufw¨

andige und teure Funktionstests von Eigenentwicklungen.

Von der Beliebtheit des neuen Ansatzes zeugt der große Erfolg des bekanntesten Vertreters der

SOA, die Web-Services. Und es zeigt, dass der Prozessgedanke – das nacheinander Abarbeiten

von Arbeitsschritten bzw. Diensten – wieder im Vordergrund steht.

1.2 Adaptivit¨

In einem Unternehmen m¨

ussen viele verschiedene Gesch¨

aftsprozesse unterst¨

utzt werden. F¨

jeden unterst¨

utzten Typ wird in der Prozessvorlage das entsprechende Prozessschema im PMS

hinterlegt. Das Prozessschema gibt den prinzipiellen Ablauf des Gesch¨

aftsprozesses wieder.

ProzessvorlageS

A2 A3 A4

A1 A2 A3

AufSbasierendeInstanzen

A1 A2 A3 A4

P P

uInstanz Aktivität Status

Arbeitsliste

I1 A1

I2 A3

Aktivität Kontrollflusskante Inaktiv Aktiviert uIn Ausführung

Beendet

SI1

SI2

Abbildung 1.2: Das Schema S und darauf basierende Instanzen

Das in Abbildung 1.2 aufgef¨

uhrte Schema Sbestimmt z. B., dass die Aktivit¨

aten A1, A2, A3

und A4 in dieser Reihenfolge sequentiell nacheinander ausgef¨

uhrt werden m¨

ussen. Basierend

auf der Prozessvorlage k¨

onnen Instanzen erzeugt und gestartet werden. Eine Prozessinstanz ist

eine konkrete Auspr¨

agung eines Prozesstyps. Jedem Prozesslauf ist eine Instanz zugeordnet. Die

2Business Process Execution Language for Web Services (http://www.ibm.com/developerworks/library/ws-

bpel/)

1.2. ADAPTIVIT ¨

AT 5

Instanz gibt den Bearbeitungszustand der einzelnen Aktivit¨

aten wieder. In vielen Umgebun-

gen, wie z. B. in einer Klinik, k¨

onnen viele tausend Instanzen eines Prozesstyps zur gleichen

Zeit aktiv sein, wobei sich jede in einem anderen Zustand befinden kann. Die Instanzen I1 und

I2 aus Abbildung 1.2 basieren auf S, d. h. deren Laufzeitschemata SI1bzw. SI2stimmen mit

dem Schema Sder Vorlage ¨

uberein. Die beiden Instanzen sind unterschiedlich weit fortgeschrit-

ten: Bei I1 befindet sich die erste Aktivit¨

at A1 in Ausf¨

uhrung. Damit steht I1 am Anfang der

Prozessausf¨

uhrung. Bei I2 wurden dagegen bereits die Aktivit¨

aten A1 und A2 vollst¨

andig und

erfolgreich abgearbeitet. Laut SI2steht damit die Aktivit¨

at A3 zur Ausf¨

uhrung an. Sie befindet

sich im Zustand ”AKTIVIERT“. Der zugeordnete Bearbeiter3hat einen entsprechenden Eintrag

in seine Arbeitsliste gestellt bekommen.

Allerdings ist ein Gesch¨

aftsprozess nicht auf ewig in seinem einmal aufgestellten Ablauf fest-

gelegt. Der Ablauf kann sich ¨

andern. Gr¨

unde daf¨

ur gibt es viele [CCPP98, Aa01, AJ00]: Im

Laufe des allt¨

aglichen Betriebes k¨

onnen neue Optimierungsm¨

oglichkeiten im Arbeitsablauf er-

kannt werden. Diese zuk¨

unftig zu ber¨

ucksichtigen bedeutet, den Gesch¨

aftsprozess anzupassen.

Auch werden h¨

aufig Fehler oder Unvollst¨

andigkeiten in der Prozessmodellierung erst im lau-

fenden Betrieb festgestellt. Die Folge ist, dass Prozesskorrekturen durchgef¨

uhrt werden m¨

ussen.

Betriebliche Umstrukturierungen, wie das Auslagern von Produktionsabschnitten an externe

Firmen (Outsourcing) oder an andere Produktionsstandorte, erfordern eine Umgestaltung des

entsprechenden Gesch¨

aftsprozesses. Der Einsatz neuer Maschinen setzt im Allgemeinen ebenfalls

Prozessanpassungen voraus. Ebenso verh¨

alt es sich bei der Weiterentwicklung oder der ¨

Uber-

arbeitung von Produkten (z. B. nach einer R¨

uckrufaktion). Die Einf¨

uhrung neuer Gesetze oder

Gesetzes¨

anderungen k¨

onnen die Anpassung eines Gesch¨

aftsprozesses erforderlich machen, damit

die neuen Vorschriften ber¨

ucksichtigt werden k¨

onnen. In einer SOA-Umgebung macht das Ein-

beziehen weiterer Services oder der Austausch einzelner Dienste eine Modifikation des Prozesses

notwendig.

Damit auch das PMS nach dem neuen Ablauf handeln kann, ist die F¨

ahigkeit eines PMS, das

Prozessschema im Rahmen einer Schemaevolution modifizieren zu k¨

onnen, ein Muss [CCPP98,

AM00]. Alle neu gestarteten Prozessinstanzen werden dann nach der neuen Version ablaufen. Die

spannende Frage ist, was mit den Instanzen geschieht, die noch auf der alten Version basieren.

F¨

ur kurz laufende Prozesse ist es eventuell m¨

oglich, die bereits gestarteten Prozesse auf dem

alten Schema zu Ende laufen zu lassen. Im Falle einer Schema¨

anderung aus Gr¨

unden einer

Prozesskorrektur, oder allgemein f¨

ur lang laufende Prozesse, wie z. B. Leasing-Vertr¨

age, ist es

unumg¨

anglich, dass die Schemaanpassungen auch auf den bereits aktiven Instanzen nachgezogen

werden. Das Anpassen des Laufzeitschemas einer Instanz an die neue Version ihrer Vorlage wird

Migration genannt [KG99, SO99]. Allerdings kann nicht jede aktive Instanz migriert werden.

Voraussetzung daf¨

ur ist, dass eine Instanz nicht zu weit in ihrer Ausf¨

uhrung fortgeschritten ist.

Sie muss vertr¨

aglich (engl.: compliant) mit den ¨

Anderungen sein (vgl. [RRD02]). Unvertr¨

agliche

Instanzen zu migrieren kann zu Konflikten im weiteren Prozessverlauf f¨

uhren, wie z. B. nicht

3Die Bearbeiterzuordnung und weitere in der Prozessvorlage hinterlegte Vorgaben, wie z. B. die Zeitabh¨

angig-

keiten, wurden in der Abbildung nicht explizit dargestellt, da sie f¨

ur diese Diplomarbeit im weiteren nicht relevant

sind.

6KAPITEL 1. EINF ¨

UHRUNG

korrekt versorgte Daten oder von der (neuen) Vorlage abweichende Ausf¨

uhrungsreihenfolgen der

Arbeitsschritte.

ProzessvorlageS

A1 A2 A3

AufSbasierendeInstanzen

A1 A2 A3 A4

P P

Aktivität Kontrollflusskante Inaktiv Aktiviert uIn Ausführung

Beendet

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A2 A23A1 A12 A3

P P

Migration

S’I1

imRahmenderMigrationeingefügte Aktivität

Abbildung 1.3: Schemaevolution von Snach S0mit anschließender Migration der Instanzen

Die Instanz I1 aus Abbildung 1.3 kann auf die im Rahmen der Schemaevolution aus dem Schema

Sneu hervorgegangene Schemaversion S0migriert werden, indem die Schema¨

anderung ∆S–

logisch gesehen – ebenfalls auf das Laufzeitschema SI1der Instanz I1 angewendet wird. Die

neue Version S0

I1des Laufzeitschemas der Instanz I1 stimmt daraufhin mit der neuen Version

S0der Vorlage ¨

uberein. Wird dieselbe ¨

Anderung jedoch auf das Laufzeitschema SI2von I2

angewendet, so kommt es zu einem Zustandskonflikt. Die Aktivit¨

at A2 ist dann bereits beendet

worden, obwohl die Vorg¨

angeraktivit¨

at A12 noch nicht einmal gestartet worden ist. I2 ist somit

mit der ¨

Anderung ∆Snicht vertr¨

aglich und darf nicht migriert werden.

Abbildung 1.4 demonstriert eine weitere, von einem PMS unbedingt zu unterst¨

utzende ¨

Ande-

rungsart: Das Laufzeitschema SI1der Instanz I1 wird individuell und dynamisch zur Laufzeit

gegen¨

uber der Vorlage Sabge¨

andert, indem die Aktivit¨

at A34 zwischen A3 und A4 eingef¨

ugt

wird. Der Prozessablauf dieser Instanz weicht somit von dem durch die Prozessvorlage vorgegebe-

nen Ablauf ab: Die Instanz ist mit dem Bias ∆SI1={insertActivity(A34, A3, A4)}gegen¨

uber

ihrer Vorlage Sverzerrt. Der Bias beschreibt die Menge der instanz-spezifischen ¨

Anderungs-

operationen, die auf das Laufzeitschema der Instanz angewendet worden sind [RRD03b]. Das

resultierende Laufzeitschema SI1∗stimmt nicht mehr mit der Vorlage S¨

uberein, die Instanz

basiert aber weiterhin darauf. Die anderen Instanzen gleichen Typs – wie z. B. Instanz I2 aus

Abbildung 1.4 – sind davon nicht betroffen.

1.2. ADAPTIVIT ¨

AT 7

ProzessvorlageS

A2 A3 A4

A1 A2 A3

AufSbasierendeInstanzen

A1 A2 A3 A4

P P

Aktivität Kontrollflusskante Inaktiv Aktiviert uIn Ausführung

Beendet

A1 A2 A3 A34 A4

S ->S *=S +I1 I1 I1 DSI1

S *I1

DS ={insertActivity(A34, A3, A4)}I1

gegenüberderVorlagezusätzlicheingefügte Aktivität

DynamischeÄnderung/

Adhoc-ModifikationvonI1

Abbildung 1.4: Dynamische ¨

Anderung/Ad-hoc-Modifikation einer Instanz

Mit dynamischen ¨

Anderungen einer Instanz, auch Ad-hoc-Modifikationen genannt, k¨

onnen in-

dividuelle Prozessanpassungen durchgef¨

uhrt werden [RD98]. Individuelle Prozessanpassungen

sind u. a. notwendig, wenn vorliegende Umst¨

ande oder die gegebene Situation es nicht erlau-

ben, wie geplant, d. h. nach Vorlage, vorzugehen. Zum Beispiel muss in einem Krankenhaus oft

von dem generell festgelegten Untersuchungs- oder Operationsablauf abgewichen werden, weil

weitere Leiden des Patienten die normale Vorgehensweise nicht zulassen. Die zus¨

atzlichen Maß-

nahmen sind von Patient zu Patient unterschiedlich, d. h. f¨

ur jeden Patienten muss der Prozess

individuell angepasst werden. Dies erfolgt durch die dynamischen ¨

Anderungen der den Patienten

zugeordneten Prozessinstanzen.

In der Produktion kann der Ausfall einer Maschine eine Ad-hoc-Modifikation nach sich ziehen,

wenn nicht schon f¨

ur diesen Notfall in der Prozessvorlage ein Notplan hinterlegt ist. Oft k¨

onnen

nicht f¨

ur alle Ausnahmesituationen oder auftretende Ereignisse in der Prozessvorlage entspre-

chende Reaktionsschritte4vorgesehen werden, weil entweder zu viele Ausnahmen bzw. Ereignisse

zu ber¨

ucksichtigen w¨

aren oder weil einfach nicht alle in der Praxis auftretbaren Konflikte und

Ereignisse vorhersagbar sind [RD98, Aa01].

Ein adaptives PMS muss also beide Arten von ¨

Anderungen – Ad-hoc-¨

Anderungen einer Instanz

und Prozesstyp-¨

Anderung – zulassen, um wirklich praxistauglich zu sein. Dar¨

uber hinaus muss

4Arbeitsschritte, um der Ausnahmesituation zu begegnen oder um auf eingetretene Ereignisse zu reagieren

8KAPITEL 1. EINF ¨

UHRUNG

das PMS auch das Zusammenspiel beider ¨

Anderungsarten unterst¨

utzen, d. h. es muss m¨

oglich

sein, die Prozesstyp¨

anderungen auch auf bereits ad hoc modifizierte Instanzen zu propagieren.

Beg¨

unstigt wird die Adaptivit¨

at bei den Prozess-Management-Systemen dadurch, dass die re-

levanten Prozesse nicht implizit im Anwendungscode versteckt sind, wie es bei properit¨

aren

Applikationen der Fall ist, sondern explizit mit einer Beschreibungssprache, meist auf Graphen

basierend, im System hinterlegt werden [RD02, S. 1-51f., S. 1-60]. So sind nicht nur die Aus-

wirkungungen einer ¨

Anderung besser zu erfassen, es muss bei einer Prozess¨

anderung auch nicht

der Programmcode des Systems umgeschrieben werden, was umfassende Tests nach sich ziehen

w¨

urde. Stattdessen muss lediglich die Repr¨

asentation des Prozesses angepasst werden. Gehorcht

die Repr¨

asentionsform bestimmten Design- und Korrektheitsregeln, so kann damit schon be-

stimmt werden – und das automatisch vom System –, ob die ¨

Anderungen ¨

uberhaupt erlaubt

sind.

Doch obwohl die Prozess-Management-Systeme diesen Vorteil gegen¨

uber den properit¨

aren An-

wendungen aufweisen und damit Adaptivi¨

at beg¨

unstigen, wird bei den kommerziell erh¨

altlichen

Systemen die Adaptivit¨

at nur rudiment¨

ar unterst¨

utzt (vgl. z. B. [AM00], [RD02, S. 7-2]).

1.3 Adaptivit¨

at und kommerzielle PMS

Die meisten kommerziellen Prozess-Management-Systeme unterst¨

utzen das Ab¨

andern einer Pro-

zessvorlage als eine Form der Adaptivit¨

at. Die Prozessvorlagen k¨

onnen abge¨

andert werden,

zuk¨

unftige Prozessinstanzen halten sich an die neuen Ablaufvorgaben. Viele dieser PMS, wie

z. B. MQSeries Workflow [Re00], lassen aber die bereits aktiven Instanzen bei einer Schema¨

ande-

rung unber¨

ucksichtigt, d. h. f¨

uhren sie weiterhin nach dem Prozessschema der alten Vorlage aus.

Prozesskorrekturen, Optimierungen oder anderweitige wichtige Anpassungen werden bei diesen

Instanzen nicht ber¨

ucksichtigt.

Andere PMS bieten dagegen an, die bereits aktiven Prozesse zur¨

uckzusetzen, um sie erneut, aber

diesmal nach der neuen Version der Vorlage auszuf¨

uhren. In vielen F¨

allen ist jedoch das Zur¨

uck-

setzten ¨

uberhaupt nicht m¨

oglich – eingesetzte Programme bieten z. B. keine Undo-Funktionen

bzw. Kompensationsfunktionen – oder es ist nicht praktikabel.

Wieder andere PMS-Vertreter ¨

ubernehmen zwar die ¨

Anderungen auf die aktiven Instanzen,

f¨

uhren aber keine Konsistenzpr¨

ufungen durch, wie z. B. Staffware [Re00]. Sie lassen auch ¨

Ande-

rungen zu, die mit dem bereits erreichten Ausf¨

uhrungsstand nicht vertr¨

aglich sind, wie z. B.

das Einf¨

ugen von Aktivit¨

aten in bereits ausgef¨

uhrte Prozessabschnitte. Probleme im weiteren

Verlauf bis hin zu Programmabst¨

urzen k¨

onnen die Folge sein.

Bei der Unterst¨

utzung der dynamischen ¨

Anderung einzelner Instanzen liegt auf dem Markt eine

ahnliche Situation vor wie bei der Schemaevolution. Die Prozess-Management-Systeme lassen

entweder Modifikationen ¨

uberhaupt nicht zu oder aber auch solche, die zu strukturellen und/oder

zustandsbedingten Konflikten bei den resultierenden Laufzeitschemata der Instanzen f¨

uhren

[Re00]. Die Migration von gegen¨

uber der Vorlage verzerrten Instanzen ist zur Zeit weder in

1.4. PROBLEMSTELLUNG UND FOKUS DER ARBEIT 9

kommerziellen Produkten realisiert, noch existieren bisher theoretische Ans¨

atze, die dieses Ziel

verfolgen.

Die Abteilung Datenbanken- und Informationssysteme der Universit¨

at Ulm erarbeitet im Rah-

men eines DFG-Forschungsprojekts und des Verbundprojekts ”AristaFlow“ zusammen mit ande-

ren Universit¨

aten und mit Partnern aus der Industrie die Konzepte eines voll adaptiven Prozess-

Management-Systems.

Dabei lauten die zentralen Fragestellungen: Wie ist das konzeptionelle Vorgehen bei einer Sche-

maevolution, Migration und einer dynamischen ¨

Anderung einer Instanz? Welche Korrektheits-

kriterien sind dabei einzuhaltenden? Wie sehen die Algorithmen aus, welche die Einhaltung der

Kriterien ¨

uberpr¨

ufen? Die Fragestellungen werden in diversen Ver¨

offentlichungen der Abteilung

ausf¨

uhrlich behandelt. Kapitel 2 geht auf die zugrundeliegenden Problemstellungen n¨

aher ein.

Die erarbeiteten Konzepte werden in dem Forschungssystem ADEPT 2 umgesetzt5.

1.4 Problemstellung und Fokus der Arbeit

Bei der Realisierung komplexer, parallel verarbeitender Systeme, wie Prozess-Management-

Systeme und Datenbanken, treten neben den konzeptionellen Fragen auch wichtige Fragen

bez¨

uglich einer praxistauglichen Implementierung auf: Wie k¨

onnen die theoretischen Konzep-

te effizient in die Praxis umgesetzt werden? Wie kann mit den knappen Ressourcen heutiger

Rechner, wie z. B. dem Arbeitsspeicher, umgegangen werden? Welche Probleme bringt die Pa-

rallelverarbeitung mit sich? Wie k¨

onnen diese verhindert werden?

Ziel dieser Diplomarbeit ist es, diese Fragen f¨

ur die Umsetzung der Adaptivit¨

at in Prozess-

Management-Systemen zu beantworten, um eine effiziente Realisierung der Prozess-Schemaevo-

lution in Hochleistungs-Prozess-Management-Systemen zu erreichen. Die Arbeit wird verschie-

dene L¨

osungsans¨

atze herleiten und auf die Praxistauglichkeit hin diskutieren. Insbesondere wird

darauf eingegangen,

•wie Prozessvorlagen und -instanzen ressourcensparend intern repr¨

asentiert werden k¨

onnen

•wie die Schemaevolution, Migration und die dynamische ¨

Anderung einer Instanz physisch

realisiert werden

•wie bei der gegebenen Architektur die Migration effizient durchgef¨

uhrt werden kann

•in welchem Umfang Maßnahmen zur Steuerung von konkurrierenden Zugriffen auf die

Datenstrukturen zu treffen sind

•wie diese Maßnahmen konkret aussehen

5ADEPT: Application Development Based on Encapsulated Pre-Modeled Process Templates

10 KAPITEL 1. EINF ¨

UHRUNG

Auch wenn die Preise f¨

ur Arbeitsspeicher in den letzten Jahren dramatisch gesunken sind, weist

diese Speichergattung trotzdem noch verh¨

altnism¨

aßig hohe Anschaffungskosten auf. Deshalb ist

er auch noch in der heutigen Zeit eine verh¨

altnism¨

aßig knappe Ressource, mit der sparsam um-

gegangen werden muss. In realen Anwendungsszenarien ist eine Anzahl an aktiven Instanzen

im Tausenderbereich keine Seltenheit. Bei dieser Gr¨

oßenordnung ist es deshalb unumg¨

anglich,

dass die Datenstrukturen f¨

ur die Repr¨

asentation der Vorlagen und Instanzen m¨

oglichst geringen

Speicherbedarf aufweisen, um die Restriktionen bez¨

uglich des Speicherbedarfs zu erf¨

ullen. Die

große Zahl an Instanzen setzt auch eine effiziente Umsetzung der Migrationsstrategie voraus,

damit die parallel ablaufenden Funktionen des Prozess-Management-Systems, wie das Zeitma-

nagement, die Benutzeranmeldung und -abmeldung, das Weiterschalten von Instanzen, etc.,

w¨

ahrend eines Migrationslaufes nicht beeintr¨

achtigt werden. An einem Prozess-Management-

System sind viele Benutzer gleichzeitig aktiv und es finden viele Aktionen parallel statt. So kann

es auch vorkommen, dass mehrere Benutzer versuchen, dasselbe Schema oder die gleiche Instanz

parallel abzu¨

andern. Oder ein Benutzer will eine Instanz ab¨

andern, die momentan in Begriff

ist zu migrieren. Zu untersuchen ist, ob und inwieweit diese konkurrierenden Zugriffe Probleme

verursachen und wie in sinnvoller Weise Maßnahmen dagegen getroffen werden k¨

onnen.

Der Aufbau der Diplomarbeit richtet sich nach den oben angesprochenen Fragen, die f¨

ur eine

Implementierung beantwortet werden m¨

ussen. Kapitel 3 leitet einen Ansatz zur Repr¨

asentation

von Prozessvorlagen und -instanzen her, der die Forderung an geringen Speicherbedarf erf¨

ullt

und bei dem die Schemaevolution, die Migration und eine dynamische ¨

Anderung einer Instanz

auf effiziente Weise umgesetzt wird. Im darauf folgenden Kapitel 4 werden zwei Implementie-

rungsvarianten vorgestellt und auf Tauglichkeit diskutiert, die das Ziel haben, die Migration zu

beschleunigen. Kapitel 5 besch¨

aftigt sich mit der Fragestellung der konkurrierenden Zugriffe.

Zuvor wird jedoch in Kapitel 2 vertiefend auf die Theorie hinter der Schemaevolution, der

Migration und den dynamischen ¨

Anderungen einer Instanz eingegangen, um die Grundlagen f¨

die folgenden Kapitel zu legen.

Kapitel 6 reflektiert die gewonnenen Erkenntnisse und beleuchtet diese im Licht der an die

Diplomarbeit gestellten Ziele.

Kapitel 2

Konzepte des adaptiven

Prozess-Managements

Dieses Kapitel gibt eine kurze Einf¨

uhrung in die Konzepte des adaptiven Prozess-Managements.

Es wird vertiefend auf die Schemaevolution, auf die Migration und auf die dynamischen ¨

Ande-

rungen einer Instanz eingegangen und aufgezeigt, welche Konflikte dabei auftreten k¨

onnen und

welche sich aus dem Zusammenspiel dieser Mechanismen ergeben k¨

onnen. Darauf aufbauend

wird hergeleitet, welche Tests notwendig sind, um eine korrekte Schemaevolution, Migration

und Instanz¨

anderung zu garantieren und wie schließlich ein konsistenter Ablauf einer Schemae-

volution, einer Migration und einer dynamischen ¨

Anderung einer Instanz aussehen kann.

2.1 Schemaevolution

Bei der Schemaevolution [CCPP98, KG99] wird, wie in Kapitel 1 schon angesprochen, das typ-

beschreibende Prozessschema Sinnerhalb einer ¨

Anderungstransaktion durch Anwendung von

kontrollfluss-¨

andernden, datenfluss-¨

andernden und/oder attribut-¨

andernden Operationen modi-

fiziert und dadurch in eine neue Version S0=S+∆S¨

uberf¨

uhrt. ∆Srepr¨

asentiert die Abweichung

von S0gegen¨

uber S, d. h. ∆Sbeschreibt die Wirkung der ¨

Anderungsoperationen auf das Schema

Die Kapselung der ¨

Anderungsoperationen in einer Transaktion garantiert, dass bei einem Com-

mit durch den Benutzer – und nur dann – das durch diese Operationen entstandene neue Schema

vollst¨

andig und dauerhaft ins Prozess-Management-System ¨

ubernommen wird.

Jedoch ¨

uberf¨

uhren nicht jede beliebige Modifikationen ein korrektes Prozessschema in ein neues,

ebenfalls korrektes Schema.

12 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

2.1.1 Korrekte Schemata

Ein korrektes Schema liegt genau dann vor, wenn keine Korrektheitskriterien des zugrundeliegen-

den Prozess-Modells f¨

ur Schemata verletzt werden. In ADEPT gelten als Korrektheitskriterien

die in [Re00, Kapitel 3 ff.] aufgestellten Strukturierungsregeln f¨

ur den Kontroll- und Datenfluss.

Zwei Regeln, die erf¨

ullt sein m¨

ussen, sollen exemplarisch herausgegriffen werden:

1. Der dem Schema zugrundeliegende Prozessgraph muss zyklenfrei bez¨

uglich Kontroll- und

Sync-Kanten sein ([Re00, Strukturierungsregel KF −4∗]).

2. F¨

ur jede Aktivit¨

at, die obligat lesend auf ein Datenelement zugreift, muss auf jedem m¨

ogli-

chen Ausf¨

uhrungspfad eine Vorg¨

angeraktivit¨

at existieren, die das entsprechende Datenele-

ment obligat schreibt ([Re00, Strukturierungsregel DF-1]).

Inkorrekte Schemata d¨

urfen nicht in das Prozess-Management-System ¨

ubernommen werden, da

es bei ihnen zu Problemen bei der Ausf¨

uhrung kommen kann: Ein Verstoß gegen die geforder-

te Zyklenfreiheit des Kontrollflusses f¨

uhrt bei der Prozessausf¨

uhrung zu Verklemmungen (engl.:

Deadlocks) und verhindert somit die korrekte Beendigung des Prozesses1. Ist die zweite genannte

Regel nicht erf¨

ullt, so kann in dem Datenelement zum Zeitpunkt des Lesens ein undefinierter

Wert stehen. Die korrekte Ausf¨

uhrung eines mit der Leseraktivit¨

at assoziierten Programms kann

dann aufgrund des undefinierten Wertes nicht garantiert werden. Falsche Ergebnisse oder Pro-

grammabst¨

urze k¨

onnen die Folge sein.

Unter anderem kann ein unkontrolliertes Einf¨

ugen von Sync-Kanten im Rahmen einer Schema-

evolution zu inkorrekten Versionen von Prozessvorlagen f¨

uhren, wie anhand dem Beispiel aus

Abbildung 2.1 exemplarisch gezeigt werden kann:

ProzessvorlageS

A11 A12

A21 A22

A2 A1

A11 A12

A21 A22

SSchemaevolution

DS={insertSync(A12, A21)}

S’

Zyklus O

Parallelverzweigung

ZusammenführungAktivität

Kontrollflusskante Sync-Kante

S->S’=S+DS

Abbildung 2.1: Zyklus im Prozessgraph aufgrund unkontrollierten Einf¨

ugens einer Sync-Kante

Die neue Version S0geht durch das Einf¨

ugen der Sync-Kante A12→A21 aus der vorigen Ver-

sion Shervor. Aufgrund der neuen Sync-Kante enth¨

alt die Prozessvorlage nun den Zyklus

1Ein Prozess gilt als korrekt beendet, wenn ein definierter Endzustand eingenommen wurde.

2.1. SCHEMAEVOLUTION 13

A11→A12→A21→A22→A11. Damit verst¨

oßt das Schema S0gegen die oben genannte Regel,

dass der dem Schema zugrunde liegende Prozessgraph keine Zyklen bez¨

uglich Kontroll- und

Sync-Kanten aufweisen darf. S0stellt somit kein korrektes Schema dar. Probleme bei der Pro-

zessausf¨

uhrung sind die Folge. Der Zyklus f¨

uhrt bei der Ausf¨

uhrung einer darauf basierenden

A11 A12

A21 A22

A11 A12

A21 A22

Deadlock

Parallelverzweigung

ZusammenführungAktivität

Kontrollflusskante Sync-Kante

inaktiv uin Ausführung

beendet

AufS’ basierendeInstanz

ProzessvorlageS’

A11 A12

A21 A22

S’

Beendenvon A1

Abbildung 2.2: Deadlock bei der Prozessausf¨

uhrung aufgrund eines Zyklus im Prozessgraph

Prozessinstanz zu einem Deadlock: Bei der auf S0basierenden Instanz aus Abbildung 2.2 kann

A11 nach erfolgter Abarbeitung der Aktivit¨

at A1 nicht aktiviert werden, da sie aufgrund der

Sync-Kante A22→A11 auf die erfolgreiche Ausf¨

uhrung von A22 wartet. A22 kann aber erst

nach A21 ausgef¨

uhrt werden. Somit wartet A11 auf die erfolgte Ausf¨

uhrung von A21. A21 kann

jedoch nicht aktiviert werden, da sie selbst aufgrund der anderen Sync-Kante A12→A21 auf die

erfolgreiche Beendigung der Aktivit¨

at A12 wartet. Da aber A12 erst nach A11 gestartet werden

kann, muss A21 transitiv auf A11 warten. A11 und A21 warten also gegenseitig aufeinander.

Damit liegt ein Deadlock vor und der Prozess kommt an dieser Stelle zum Erliegen. Der Prozess

kann somit nicht korrekt beendet werden.

Das PMS muss im Rahmen der Commit-Behandlung einer ¨

Anderungstransaktion in einem Kor-

rektheitstest sicherstellen, dass die Modifikationen nicht zu einem inkorrekten Schema f¨

uhren.

In [Re00] werden effiziente Verfahren vorgestellt, mit denen die Einhaltung der oben genannten

Regeln gepr¨

uft werden k¨

onnen. Scheitert der Test, so muss die ¨

Anderungstransaktion mit einem

entsprechenden Hinweis zur¨

uckgewiesen werden. Der Benutzer muss die M¨

oglichkeit haben, Kor-

rekturen durchzuf¨

uhren. Alternativ kann stets vor einer Anwendung einer ¨

Anderungsoperation

getestet werden, ob es durch die ¨

Anderung nicht zu einem inkorrekten Schema kommt, um die

14 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

Anderungsoperation bei Bedarf sogleich zur¨

uckzuweisen. Der Unterschied zwischen den beiden

Methoden ist, dass bei der ersten Methode erst nach der Anwendung aller Operationen einer

Anderungstransaktion ein korrektes Schema vorliegen muss, w¨

ahrend bei der zweiten nach jeder

einzelnen Operation die Bedingungen an das bis dahin entstandene Schema erf¨

ullt sein m¨

ussen.

2.1.2 Ablauf einer Schemaevolution

Wird der Korrektheitstest im Rahmen der Commit-Behandlung durchgef¨

uhrt, so ergibt sich

f¨

ur die Schemaevolution ein Ablauf, der sich mit dem Zustandsdiagramm aus Abbildung 2.3

beschreiben l¨

asst: Mit dem ¨

Offnen einer ¨

Anderungstransaktion durch den Benutzer tritt ein

Schemaevolution

Schemaaktiv Änderungsphase

Benutzeröffnet

Änderungstransaktion

SchemawirdvomBenutzer

abgeändert

[Änderungunvollständig]

Transaktionabgebrochen

Entry/VerwerfeÄnderungen

Benutzer-

Abbruch

Benutzer-Commit

[Änderungvollständig]

Korrektheitstestphase

Entry/PrüfeaufKorrektheit

Entry/ÄnderungeninsPMSübernehmen

Transaktioncommited

System-Commit

Zurückweisungder

gemachtenÄnderungen

neueSchemaversionaktivalteSchemaversionaktiv

Abbildung 2.3: Zustandsdiagramm f¨

ur eine Schemaevolution

aktives Schema in die ¨

Anderungsphase ein. In dieser Phase f¨

uhrt der Benutzer die gew¨

unschten

Anderungen durch. Bei einem Benutzerabbruch werden s¨

amtliche Modifikationen des Schemas

r¨

uckg¨

angig gemacht. F¨

uhrt der Benutzer ein Commit der Anpassungen durch, so tritt die neue

Version des Schemas in die Phase ein, in der das Schema auf Verst¨

oße gegen die dem Prozess-

Modell zugrunde gelegten Korrektheitskriterien getestet wird. Treten Fehler auf, so wird der

Benutzer aufgefordert, Korrekturen am vorliegenden Schema vorzunehmen. Konnte der Test

ohne Beanstandungen beendet werden, so commited auch das System die Transaktion, was die

dauerhafte ¨

Ubernahme ins Prozess-Management-System zur Folge hat.

Konnte die neue Version S0des Schemas erfolgreich ins Prozess-Management-System ¨

ubernom-

men werden, so laufen alle neu gestarteten Instanzen des entsprechenden Typs fortan danach

2.2. INSTANZEN UND SCHEMAEVOLUTION 15

ab2. Interessant ist die Frage, wie mit den Instanzen umgegangen werden soll, die noch auf

Grundlage der alten Version Sgestartet wurden.

2.2 Instanzen und Schemaevolution

Eine M¨

oglichkeit, mit Instanzen bei einer Schemaevolution umzugehen, die noch auf der Grund-

lage der alten Version gestartet worden sind, ist es, die schon aktiven Instanzen von der Schema-

Anderung unber¨

ucksichtigt zu lassen [SO99]. F¨

ur besonders kurzlebige Prozesse mag diese Vor-

gehensweise noch akzeptabel sein, aber bei langlebigen Instanzen k¨

onnen dadurch Probleme

entstehen. Ein Beispiel: Der Zulassungsprozess von neu entwickelten Medikamenten geht ¨

uber

Jahre und muss sich streng an die vom Gesetzgeber vorgeschriebenen Regeln halten. Bedient

sich nun das PMS nur der beschriebenen Methode, so k¨

onnten neu auferlegte Bestimmungen

nicht mehr auf die bereits laufenden Zulassungsverfahren angewendet werden und der Pharma-

Konzern w¨

urde sich strafbar machen. Bei wenigen betroffenen Instanzen besteht die M¨

oglichkeit,

durch Ad-hoc-Modifikationen die Instanzen per Hand auf die neuen Gegebenheiten anzupassen,

aber bei tausenden betroffener Instanzen ist dies unrealistisch. Außerdem ist die manuelle An-

passung von mehreren Instanzen fehleranf¨

allig. Eine weitere M¨

oglichkeit, mit bereits laufenden

Instanzen nach einer Schema¨

anderung umzugehen, ist es, diese abzubrechen und bez¨

uglich des

neuen Schemas erneut auszuf¨

uhren [SO99]. Aber das Zulassungsverfahren abzubrechen und dann

alle Untersuchungen erneut durchzuf¨

uhren ist nicht praktikabel.

Um die Effekte der beiden bis jetzt vorgestellten Verfahren abzumildern, wird ein komplexer

Prozess oft in mehrere, kurzlebige Abschnitte aufgesplittet, die durch separate “Mini-Schemata”

beschrieben werden. Die erste vorgestellte Methode kann dann aufgrund der Kurzlebigkeit eines

Abschnittes eher auf den Abschnitt angewendet werden, als auf den ganzheitlichen Prozess.

Bei Anwendung der zweiten Methode wird nicht der ganze Prozess zur¨

uckgesetzt, sondern nur

der jeweilige Abschnitt. Abgesehen davon, dass mehrere Prozessfragmente schwer zu handhaben

sind und sie nicht die nat¨

urliche, zusammenh¨

angende Sicht auf den Prozess bieten, sind auch

Anderungen, die gleichzeitig mehrere Abschnitte betreffen, unm¨

oglich, da jeder Abschnitt seine

eigene Prozessvorlage besitzt.

Die f¨

ur die Praxis interessanteste Vorgehensweise, mit den bereits laufenden Instanzen bei einer

Schema¨

anderung umzugehen, ist die Migration.

2Eventuell kann noch ein Zeitpunkt angegeben werden, ab dem die neue Version G¨

ultigkeit besitzt. Erst die

nach diesem Zeitpunkt gestarteten Instanzen werden dann nach der neuen Version der Vorlage ablaufen. Die

anderen, zuvor gestarteten Instanzen werden noch bis zu diesem Zeitpunkt nach der alten Version ablaufen.

16 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

2.3 Migration

Bei der Migration wird, wie in Kapitel 1 schon beschrieben, im Anschluss an die Schemaevolution

versucht, die Laufzeitschemata der Instanzen, die noch auf der alten Version Sder ge¨

anderten

Vorlage gestartet wurden, an die neue Version S0anzupassen [SO99, KG99].

Bei der Vorgehensweise muss zwischen unverzerrten und verzerrten Instanzen unterschieden

werden.

2.3.1 Migration unverzerrter Instanzen

Das Laufzeitschema einer unverzerrten Instanz I stimmt mit dem Schema Sder Vorlage ¨

uberein

(formal: SI≡trace S)3. Deshalb wird eine unverzerrte Instanz auf die neue Version S0angepasst,

indem die Schema¨

anderungen ∆S– logisch gesehen – auf dem Laufzeitschema SIvon I nachge-

zogen werden. Nach der Migration stimmt dann das Laufzeitschema S0

Idieser Instanz I mit der

neuen Version S0der Vorlage ¨

uberein: S0

I=SI+ ∆S≡trace S+ ∆S=S0. Die Instanz ist damit

wiederum unverzerrt gegen¨

uber ihrer Vorlage.

ProzessvorlageS

A2 A3

A2 A23A1 A12 A3

AufSbasierendeInstanz

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

Si1 S’ = + SI1 DSi1

Migration

gegenüberderVorlagezusätzlicheingefügte Aktivität

imRahmenderMigrationeingefügte Aktivität

trace

S S’

trace

Abbildung 2.4: Beispielmigration einer unverzerrten Instanz

Die Instanz I1 aus Abbildung 2.4 ist z. B. gegen¨

uber dem Schema Sder Prozessvorlage nicht

verzerrt (es wurden keine zus¨

atzlichen Aktivit¨

aten eingef¨

ugt; ∆SI1=∅). Um die Instanz an die

neue Version S0des Schemas, die aus Sdurch das Einf¨

ugen der Aktivit¨

at A12 zwischen A1 und

A2 und der Aktivit¨

at A23 zwischen A2 und A3 hervorging (∆S={insertActivity(A12, A1, A2),

insertActivity(A23, A2, A3)}), anzupassen, muss die ganze Schema¨

anderung ∆Sauf I1 nachge-

zogen werden.

3Sind zwei Schemata ausf¨

uhrungs¨

aquivalent (formal: ≡trace), so k¨

onnen alle Ausf¨

uhrungshistorien, die auf dem

einen Schema erzeugbar sind, auch auf dem anderen erzeugt werden und umgekehrt.

2.3. MIGRATION 17

2.3.2 Migration verzerrter Instanzen

Verzerrte Instanzen sind in ihrem Laufzeitschema SI∗gegen¨

uber ihrer Vorlage Sabge¨

andert,

d. h. SI∗=SI+ ∆SI≡trace S+ ∆SI. Die Schema¨

anderungen ∆Sk¨

onnen sich dann mit

den Instanz¨

anderungen ∆SI¨

uberlappen (formal: ∆S∩∆SI6=∅), d. h. die Schema¨

anderungen

∆Sbewirken auf das Laufzeitschema einer unverzerrten Instanz desselben Prozesstyps (teil-

weise) dieselben Effekte, wie die Instanz¨

anderungen ∆SIauf das urspr¨

ungliche Laufzeitschema

SI≡trace Sder Instanz I gehabt haben. Bei verzerrten Instanzen h¨

angt deshalb die Vorgehens-

weise zur Anpassung an die neue Version von den Beziehungen ab, in denen die Auswirkungen

der Instanz¨

anderungen und der Schema¨

anderungen stehen.

ProzessvorlageS

A2 A3

A2 A23A1 A12 A3

AufSbasierendeInstanzen

A1 A2 A23 A3

A2 A23A1 A12 A3

A2 A23A1 A12 A3 A2 A23A1 A12 A3

A4 A4

Schemaevolution

I2*

I3*

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

DS ={insertActivity(A23, A2, A3)}I2

DS ={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}I3

S*I3

DS\ DS ={insertActivity(A12, A1, A2)}I2

S*I2 S*’ =S* +( S )I2 I2 I2DDS\

S*’ =I3 S*I3

A2 A23A1 A12 A3

A34 A4

A2 A23A1 A12 A3

A34 A4

I4*

DS ={insertActivity(A12, A1, A2),

insertActivity(A34, A3, A4)}

I4 insertActivity(A23, A2, A3),

S*I4 S*’ =I4 S*I4

DS \ ={insertActivity(A34, A3, A4)}I4 DS

A2 A3A1 A12 A34 A2 A23A1 A12 A3

A4 A34 A4

I5*

DS ={insertActivity(A12, A1, A2),insertActivity(A34, A3, A4)}I5

S*I5

DS\ DS ={insertActivity(A23, A2, A3)}I5

S*’ = +( )I5 S* S\ SI5 I5D D

DS \ ={insertActivity(A34, A3, A4)}I5 DS

A1 A2 A3 A34 A4

A2 A23A1 A12 A3

A34 A4

I6*

DS ={insertActivity(A34, A3, A4)}I6

S*I6

DS ={insertActivity(A34, A3, A4)}I6

S*’ = +I6 S* SI6 D

Migration

trace

S+ SDI2

S+ SDI3

trace

S+ SDI4

trace

S+ SDI5

trace

S+ SDI6

trace

S’

trace

S’

trace

S’ +( S \ S)D DI4

trace

S’ + ( S \ S)D DI5

trace

S’ + SDI6

trace

DSI2 SpD

DSI3 DS

DSI4 SfD

D DS SI6=I

DSI5DS

()

Abbildung 2.5: Beispielmigration verzerrter Instanzen mit unterschiedlichem ¨

Uberlappungsgrad

Sind die Auswirkungen ∆SIder Instanz¨

anderungen, mit denen die Instanz I gegen¨

uber Sab-

ge¨

andert wurde, und die Auswirkungen ∆Sder Schema¨

anderungen ¨

aquivalent, d. h. ∆SI≡∆S,

so ist das Laufzeitschema SI∗der verzerrten Instanz I nach [RRD03a] ausf¨

uhrungs¨

aquivalent

(englisch: trace equivalent/execution equivalent) zu dem Schema S0der neuen Vorlagenversion:

Auf SI∗k¨

onnen dieselben Ablaufhistorien erzeugt werden wie auf S0und umgekehrt [RRD03a].

Damit ist das Einspielen der ¨

Anderungsoperationen auf SI∗, die Snach S0ge¨

andert haben,

nicht mehr notwendig, um die Instanz auf die neue Vorlage anzupassen. Die Instanz I ist bereits

18 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

mit der neuen Vorlage konform. Mehr noch: I ist auch nicht mehr verzerrt gegen¨

uber der neuen

Vorlage: SI∗0=SI∗=S0

I≡trace S0.

Bei der Instanz I3 aus Abbildung 2.5 ist die zu der Schema¨

anderung ∆S¨

aquivalente Ad-hoc-

Modifikation ∆SI3={insertActivity(A12, A1, A2), insertActivity(A23, A2, A3)}vorgenom-

men worden. Bei der Migration muss somit keine Anpassung von SI3an S0erfolgen. Gegen¨

uber

S0ist dann I3 auch nicht mehr verzerrt.

In diesem Beispiel wurde implizit angenommen, dass z. B. die auf Instanzebene eingef¨

ugte Ak-

tivit¨

at A12 die gleiche ist, wie die auf Typebene eingef¨

ugte. In der Praxis k¨

onnen jedoch zwei

Aktivit¨

aten, die den gleichen Namen bekommen haben, f¨

ur unterschiedliche Aktionen stehen.

Oder anders herum, es k¨

onnen zwei dem Namen nach unterschiedliche Aktivit¨

aten dennoch

dieselben Funktionen erf¨

ullen. Um den Test auf ¨

Aquivalenz korrekt durchf¨

uhren zu k¨

onnen, ist

es aber von entscheidender Bedeutung, dies ber¨

ucksichtigen zu k¨

onnen. F¨

ur die Praxis m¨

ussen

deshalb Kriterien gefunden werden, mit denen man Aktivit¨

aten auf Gleichheit vergleichen kann.

Daran muss noch geforscht werden. Aufgrund der Komplexit¨

at dieses Problems wird in die-

ser Diplomarbeit darauf nicht weiter eingegangen und stets zwei im Namen ¨

ubereinstimmende

Aktivit¨

aten als gleich betrachtet.

Neben der ¨

Aquivalenz gibt es weitere Beziehungen, in denen ∆SIund ∆Szueinander stehen

k¨

onnen. Je nach ¨

Uberlappungsgrad muss eine bestimmte Migrationsstrategie angewendet werden

[Ri04].

Sind die ¨

Anderungen disjunkt, d. h. ∆SI∩∆S=∅, so bewirken die beiden ¨

Anderungsarten

ganz unterschiedliche Effekte auf unterschiedliche Bereiche des Laufzeitschemas der Instanz. In

diesem Fall muss ganz ∆Sanalog den unverzerrten Instanzen f¨

ur die Anpassung eingespielt

werden. Instanz I6 aus Abbildung 2.5 zeigt diesen Sachverhalt.

Ist ∆SIsubsumptions-¨

aquivalent zu ∆S, d. h. ∆SI≺∆S, so schließen die Schema¨

anderungen

die Instanz¨

anderungen komplett ein, aber nehmen noch zus¨

atzliche Modifikationen vor. Logisch

gesehen m¨

ussen dann die zus¨

atzlichen Modifikationen ∆S\∆SIbei der Migration noch auf

der verzerrten Instanz nachgeholt werden4. Nach der Migration stimmt das Laufzeitschema der

Instanz mit der neuen Version des Schemas der Vorlage ¨

uberein. Die Instanz ist nicht mehr

verzerrt gegen¨

uber S0:SI∗0=S0

I≡trace S0.

Bei Instanz I2 aus Abbildung 2.5 wurde das Einf¨

ugen von Aktivit¨

at A23 bereits durch die

Ad-hoc-Modifikation vorweggenommen. F¨

ur die Migration muss dann nur noch A12 zwischen

A1 und A2 eingef¨

ugt werden. Da auf Instanzebene keine weiteren ¨

Anderungen vorgenommen

wurden, gilt: ∆SI2≺∆S.

Gilt umgekehrt ∆SIÂ∆S, so sind die Instanz¨

anderungen umfassender als die Schema¨

anderun-

gen. F¨

ur das Laufzeitschema SI∗der verzerrten Instanz gilt: SI∗=SI+ ∆SI≡trace S+ ∆SI=

4∆S\∆SIbeschreibt alle Auswirkungen der Schema¨

anderung ∆S, die nicht auch durch die Instanz¨

anderungen

∆SIbewirkt werden.

2.3. MIGRATION 19

S+(∆S∪(∆SI\∆S)) = S0+(∆SI\∆S)5. Damit ist die Instanz bis auf die zus¨

atzlichen Modifi-

kationen ∆SI\∆Skonform zur neuen Version. F¨

ur die Migration sind somit auf logischer Ebene

keine weiteren Aktionen notwendig und es gilt f¨

ur das Laufzeitschema SI∗0nach der Migration:

SI∗0=SI∗ ≡trace S0+ (∆SI\∆S).

Im Rahmen der Ad-hoc-Modifikation wurde bei Instanz I4 aus Abbildung 2.5 neben A34 auch

die beiden Aktivit¨

aten A12 und A23 eingef¨

ugt und zwar an die gleichen Stellen, wie im Rahmen

der Schemaevolution auf der Prozessvorlage. Die Schema¨

anderungen sind somit subsumptions-

aquivalent zu den Instanz¨

anderungen. Damit ist I4 bereits konform zu der neuen Schemaversion

S0, f¨

ur die Migration ist keine weitere Aktion notwendig. Allerdings ist I4 auch gegen¨

uber S0

wegen der zus¨

atzlichen Aktivit¨

at A34 verzerrt.

Haben die beiden ¨

Anderungsarten ∆SIund ∆Steilweise dieselben Effekte auf das Ursprungs-

schema gemeinsam, bewirken dar¨

uberhinaus aber auch noch weitere, dazu und zueinander dis-

junkte Modifikationen, so gelten sie als partiell ¨

aquivalent. Die Instanz wird dann migriert, indem

logisch die ¨

Anderungen ∆S\∆SIauf der Instanz nachgezogen werden. Nach der Migration ist

die Instanz mit dem Bias (∆SI\∆S) gegen¨

uber der neuen Vorlage verzerrt.

Die Schema¨

anderung ∆Sund die Instanz¨

anderung ∆SI5der Instanz I5 aus Abbildung 2.5 be-

wirken beide das Einf¨

ugen der Aktivit¨

at A12 zwischen A1 und A2, weisen aber beide noch die

zus¨

atzlichen Einf¨

uge-Modifikationen von A23 bzw. A34 auf. Damit sind die beiden ¨

Anderungs-

arten partiell ¨

aquivalent zueinander. F¨

ur die Migration von I5 auf das neue Schema S0muss

dann nur noch die fehlende Aktivit¨

at A23 eingef¨

ugt werden. Die bei der Ad-hoc-Modifikation

gegen¨

uber der Schema¨

anderung zus¨

atzlich eingef¨

ugte Aktivit¨

at A34 ist daf¨

ur verantwortlich,

dass I5 auch nach der Migration verzerrt bleibt.

Das ist aber nur ein kleiner Aspekt der partiellen ¨

Aquivalenz von Instanz- und Schema¨

anderun-

gen, wie im folgenden deutlich wird.

Zum Beispiel kann auf Schemaebene eine andere Aktivit¨

at an die gleiche Stelle des Prozessgra-

phen eingef¨

ugt werden wie auf der Instanzebene. Da in diesem Fall zwar verschiedene Aktivit¨

aten

eingef¨

ugt werden, dabei aber jeweils die gleiche Stelle des Prozessgraphen betroffen ist, werden

die entsprechenden Instanz- und Schema¨

anderungen auch als partiell ¨

aquivalent betrachtet. Die

Migration der entsprechenden Instanz ist dann aber nicht mehr so einfach, wie bei dem obigen

Fall der partiellen ¨

Aquivalenz geschildert, da Fragen aufkommen, die sich nur mithilfe der Benut-

zer oder durch f¨

ur solche F¨

alle im System hinterlegte Regeln beantworten lassen (vgl. Abbildung

2.6): Sollen im resultierenden Laufzeitschema die beiden Aktivit¨

aten sequentiell hintereinander

oder parallel angeordnet werden? Wenn sequentiell, welche soll dann zuerst zur Ausf¨

uhrung kom-

men? Oder soll keine oder nur eine der beiden Aktivit¨

aten an dieser Stelle ausgef¨

uhrt werden?

Wenn nur eine ausgef¨

uhrt werden soll, dann stellt sich die Frage: Welche?

Ahnliche Fragen ergeben sich, wenn auf Schemaebene dieselben Aktivit¨

aten an anderen Stellen

eingef¨

ugt werden als auf Instanzebene. Weitere F¨

alle, die Fragen aufwerfen, liegen vor, wenn

5∆S1∪∆S2 beschreibt die Auswirkungen der ¨

Anderungen ∆S1 kombiniert mit den Auswirkungen der ¨

Ande-

rungen ∆S2.

20 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

ProzessvorlageS

A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 AXY A3 A4

Migration

A2 A23A1 A12 A3

A2 AXYA1 A12 A3

A23

A1 A12 A3

AXY

A2A1 A12 A3

S *I

DS ={insertActivity(AXY, A2, A3)}I

S *’I

DS ’ ={deleteActivity(A23),insertActivity(AXY, A2, A3)}I

S *’I

DS ’ ={insertActivityParallel(AXY, A23)}I

DS ’ ={deleteActivity(A23)}I

gegenüberderVorlagezusätzlicheingefügte Aktivität

imRahmenderMigrationeingefügte Aktivität

AufSbasierendeInstanz

A2 A23A1 A12 AXY

A3 A4

DS ’ ={insertActivity(AXY, A23, A3)}I

A2 A23

A1 A12 AXY

A3 A4

DS ’ ={insertActivity(AXY, A2, A23)}I

trace

S+ SDI

S’+ S ’DI

trace

S’

trace

S *’IS’+ S ’DI

trace

S *’IS’+ S ’DI

trace

S *’IS’+ S ’DI

trace

S *’IS’+ S ’DI

trace

Abbildung 2.6: Konflikte bei der Migration bei partiell ¨

aquivalenten ¨

Anderungsarten

auf einer Ebene Aktivit¨

aten gel¨

oscht werden, auf der jeweils anderen Ebene aber dieselben

Aktivit¨

aten verschoben oder anderweitig modifiziert werden. Wiederum m¨

ussen diese Konflikte

erkannt und mithilfe des Benutzers oder mit im System hinterlegten Regeln aufgel¨

ost werden.

Ferner ist zu ¨

uberpr¨

ufen, ob das aus der Migration resultierende Schema SI∗0einer verzerrten

Instanz nicht gegen die in Abschnitt 2.1 angesprochenen Korrektheitskriterien f¨

ur Kontroll- und

Datenfl¨

usse verst¨

oßt. Die Kombination von Instanz- und Schema¨

anderungen k¨

onnen zu struk-

turellen Konflikten f¨

uhren, obwohl die Instanz- und die Schema¨

anderungen f¨

ur sich genommen

gegen keine Regeln verstoßen haben (vgl. [RRD03b]).

Zum Beispiel kann es in Zusammenhang mit Sync-Kanten zu Problemen kommen. Bei dem in

Abbildung 2.7 dargestellten Beispiel wurde das Laufzeitschema SIder Instanz I durch die Ad-

hoc-Modifikation ∆SI={insertSync(A22, A11)}in die neue, korrekte Version SI∗¨

uberf¨

uhrt.

Auch die neue Version S0der Prozessvorlage, die aus Sdurch das Einf¨

ugen der Sync-Kante

zwischen A12 und A21 hervorging, d. h. ∆S={insertSync(A12, A21)}, gen¨

ugt den Korrekt-

heitsanforderungen. Wird jedoch nach der Migrationsregel f¨

ur disjunkte ¨

Anderungen die Sche-

ma¨

anderung ∆Sauf das dynamisch abge¨

anderte, korrekte Laufzeitschema SI∗f¨

ur die Migration

von I angewendet, so weist das resultierende Schema SI∗0einen Verstoß gegen die Korrektheits-

2.3. MIGRATION 21

ProzessvorlageS

A11 A12

A21 A22

A2 A1

A11 A12

A21 A22

A11 A12

A21 A22

A11 A12

A21 A22

A2 A1

A11 A12

A21 A22

SSchemaevolution

Migration

Adhoc-Modifikation

S insertSync(A22, A11)}D ={

A11 A12

A21 A22

Migration

AufSbasierendeInstanzI

DS={insertSync(A12, A21)}

S’

I* I*’

I’

Zyklus

S->S’=S+DS

Abbildung 2.7: Inkorrekte Laufzeitschemata nach Migration verzerrter Instanzen

kriterien auf: Die Sync-Kanten bilden zusammen mit dem Kontrollfluss einen Zyklus. Dieser

Zyklus f¨

uhrt bei der Prozessausf¨

uhrung zu einem Deadlock (vgl. Kapitel 2.1). Ein entsprechen-

der Test muss verhindern, dass I auf die neue Version S0des Schemas migriert. [Ri04] beschreibt

einen effizienten Test, der anhand der alten Schemaversion, der ¨

Anderungshistorie der Ad-hoc-

Modifikation und der ¨

Anderungshistorie der Schemaevolution die Konflikte erkennen kann, ohne

das Schema SI∗0explizit herstellen zu m¨

ussen.

2.3.3 Vertr¨

agliche und unvertr¨

agliche Instanzen

Die Migration sowohl einer unverzerrten als auch einer verzerrten Instanz ist nur zul¨

assig, wenn

die Instanz mit dem neuen Schema vertr¨

aglich (engl.: compliant) ist [RRD03b, RRD04]. [RRD04]

stellt f¨

ur die verschiedenen Prozess-Modelle Korrektheitskriterien auf, welche die Vertr¨

aglichkeit

der Instanz garantieren. Bei Prozess-Modellen mit Ausf¨

uhrungshistorien lautet das Korrekt-

heitskriterium: Eine Instanz ist mit dem neuen Schema vertr¨

aglich, wenn sich ihre bisherige

Ausf¨

uhrungshistorie (basierend auf dem alten Schema) auch auf dem neuen Schema reproduzie-

22 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

ren l¨

asst [RRD04, Korrektheitskriterium 6]. Die Ausf¨

uhrungshistorie f¨

uhrt u. a. dar¨

uber Buch,

ob und wann eine jede Aktivit¨

at gestartet und wieder beendet wurde und welche Datenelemente

sie mit welchen Werten beschrieben haben bzw. welche Werte sie aus den Datenelementen gele-

sen haben [RRD02]. Sie gibt die ganze Vergangenheit der Instanz wieder. Daraus l¨

asst sich der

komplette Prozessablauf rekonstruieren. Wenn die Instanz auf der neuen Version der Vorlage

basieren soll, dann muss diese Version auch den bisherigen Verlauf der Prozessinstanz erkl¨

aren

k¨

onnen (vgl. [CCPP98]), d. h. es muss in dem neuen Schema ein Ausf¨

uhrungspfad existieren,

der dieselbe Historie erzeugen kann. Existiert ein solcher Pfad nicht, so kann das neue Schema

nicht als Vorlage f¨

ur die Instanz dienen und die Migration der Instanz darauf darf nicht erfolgen:

Die Instanz ist unvertr¨

aglich mit dem neuen Schema (vgl. [RRD02]).

ProzessvorlageS

A1 A2 A3

AufSbasierendeInstanzen

A1 A2 A3 A4

P P

Aktivität Kontrollflusskante

Inaktiv Aktiviert uIn Ausführung

Beendet

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A2 A23A1 A12 A3

P P

Migration

imRahmenderMigrationeingefügte Aktivität

AusführungshistorieH vonI1:

Start(A1,t3,...).

AusführungshistorieH vonI2:

Start(A1,t1,...);End(A1,t2,....);

Start(A2,t4,...);End(A2,t5).

Ausführungshistorie H von I1:

Start(A1, t3,...).

A2 A23A1 A12 A3

P P

AusführungshistorieH vonI2:

Start(A1,t1,...);End(A1,t2,....);

Start(A2,t4,...);End(A2,t5).

AusführungshistorieH vonI3:

Start(A1,t6,...);End(A1,t7,....);

Start(A12,t8,...);End(A12,t9);

Start(A2,t10,...);End(A2,t11).

Start-undEndeintrag

von A12fehlt!

Abbildung 2.8: Ausf¨

uhrungshistorien und Migration

Bei der Instanz I1 aus Abbildung 2.8 wurde vor der Migration nur die Startaktivit¨

at A1 des

Prozesses gestartet. Ihre Ausf¨

uhrungshistorie HI1enth¨

alt deshalb nur den Starteintrag f¨

ur die-

se Aktivit¨

at. A1 ist auch in der neuen Version S0der Prozessvorlage noch die Startaktivit¨

at.

Somit ist bei einer Instanz, die von Anfang an nach S0abl¨

auft, A1 die erste Aktivit¨

at, die zur

Ausf¨

uhrung kommen kann. Folglich ist der erste Historieneintrag der Starteintrag von A1, wie

die Historie HI3der direkt auf S0gestarteten Instanz I3 zeigt. Die Historie HI1von I1 h¨

atte

somit auch zustande kommen k¨

onnen, wenn die Instanz von Anfang nach dem neuen Schema

2.3. MIGRATION 23

S0abgelaufen w¨

are. Deshalb ist Instanz I1 vertr¨

aglich mit S0und die abgebildete Migration

SI1→S0

I1war zul¨

assig.

Die Instanz I2 aus Abbildung 2.8 ist dagegen mit S0unvertr¨

aglich: In der Ausf¨

uhrungshistorie

HI2von I2 folgt nach dem Start- und Endeintrag von A1 sofort der Starteintrag von A2, da

nach der alten Version Sder Vorlage A2 direkt nach dem Ende der Aktivit¨

at A1 ausgef¨

uhrt

werden kann. Diese Historie kann allerdings auf S0nicht erzeugt werden, da dabei nach A1 erst

einmal A12 ausgef¨

uhrt werden muss, bevor A2 gestartet werden kann. Dementsprechend muss

in der Historie einer Instanz, die auf S0gestartet wurde, zwischen dem Endeintrag von A1 und

dem Starteintrag von A2 definitiv noch der Start- und Endeintrag von A12 stehen (vgl. Historie

HI3von I3). Die Historie von I2 enth¨

alt diese Eintr¨

age nicht. I2 ist somit nicht vertr¨

aglich und

darf nicht migriert werden.

Wird die Migration einer unvertr¨

aglichen Instanz trotzdem durchgef¨

uhrt, so ist nicht nur die

Vergangenheit der Instanz nicht mehr erkl¨

arbar, sondern es kann auch zu Inkonsistenzen im

Prozessstatus kommen, wie in Abbildung 2.8 anhand der unvertr¨

aglichen Instanz I2 gezeigt:

Nach der Migration liegt die Inkonsistenz vor, dass A2 ausgef¨

uhrt wurde, obwohl A12 noch nicht

abgearbeitet wurde. Dies widerspricht der Regel, dass eine Aktivit¨

at erst gestartet werden kann,

wenn alle Vorg¨

angeraktivit¨

aten, die nicht in einem abgew¨

ahlten XOR-Pfad liegen, erfolgreich

beendet wurden.

Das Prozess-Management-System muss anhand eines Vertr¨

aglichkeitstests die zu migrierenden

Instanzen auf Vertr¨

aglichkeit pr¨

ufen und im Falle der Unvertr¨

aglichkeit die Instanz von der Mi-

gration ausschließen. Der Test muss auf effiziente Weise die Vertr¨

aglichkeit bzw. Unvertr¨

aglich-

keit feststellen, da in realen Anwendungsszenarien oft tausende von Instanzen gleichzeitig zur

Migration anstehen k¨

onnen.

Das oben angegebene Korrektheitskriterium selbst liefert einen ersten Ansatz f¨

ur einen Ver-

tr¨

aglichkeitstest: Die Historie muss auf dem neuen Schema reproduzierbar sein. Ein m¨

oglicher

Vertr¨

aglichkeitstest ist es also, die Ausf¨

uhrungshistorie auf dem neuen Schema Schritt f¨

ur Schritt

nachzuspielen (vgl. [RRD02]). Der Versuch, die Historie der unvertr¨

aglichen Instanz I2 auf dem

neuen Laufzeitschema S0

I2nachzuspielen, scheitert daran, dass nach dem Endeintrag von A1

schon der Starteintrag von A2 steht, nach der neuen Vorlage S0aber nach A1 nur A12 gestartet

werden kann und nicht A2. Damit wurde I2 mit der neuen Version S0der Vorlage als nicht

vertr¨

aglich erkannt.

Da das Nachspielen der kompletten Historie f¨

ur alle zur Migration anstehenden Instanzen u. U.

sehr aufw¨

andig sein kann, besonders wenn die Instanzen mehrere hundert Schleifendurchg¨

ange

durchlaufen haben, ist diese Art der Vertr¨

aglichkeitspr¨

ufung aus Performance-Gr¨

unden in der

Praxis eher ungeeignet. Ein weiterer Nachteil ist, dass f¨

ur das Nachspielen der Ausf¨

uhrungshisto-

rie das neue Schema erzeugt werden muss, bevor ¨

uberhaupt feststeht, ob die Instanz vertr¨

aglich

ist. Hinzu kommt, dass Ausf¨

uhrungshistorien aufgrund ihrer Gr¨

oße meistens im Hintergrund-

speicher gehalten werden. Der gegen¨

uber einem Hauptspeicherzugriff langsamere Zugriff auf den

Hintergrundspeicher wirkt sich zus¨

atzlich negativ auf die Performance aus.

24 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

[RRD02] zeigt, dass die Vertr¨

aglichkeit einer Instanz mit der neuen Version der Vorlage von

ihrem Zustand vor der Migration abh¨

angt. F¨

ur jede einzelne ¨

Anderungsoperation werden einige

wenige, schnell ¨

uberpr¨

ufbare Bedingungen an den Zustand angegeben, welche die Anwendbarkeit

der Operation auf das Laufzeitschema der Instanz garantieren, so dass die bereits entstandene

Ausf¨

uhrungshistorie reproduzierbar bleibt und keine Inkonsistenzen im Zustand der Instanz auf-

treten. F¨

ur das Einf¨

ugen einer Aktivit¨

at sequentiell zwischen zwei andere lautet die Bedingung,

dass die Aktivit¨

at, vor die eingef¨

ugt wird, noch nicht gestartet worden sein darf. Somit f¨

uhrt

das Einf¨

ugen einer Aktivit¨

at Y sequentiell zwischen zwei anderen Aktivit¨

aten X und Z nicht zu

Inkonsistenzen, solange Z noch nicht gestartet wurde. Die Instanz ist mit der neuen Version der

Vorlage vertr¨

aglich, wenn f¨

ur alle Operationen der ¨

Anderungstransaktion die entsprechenden

Bedingungen erf¨

ullt sind.

Der Vertr¨

aglichkeitstest l¨

auft dann derart ab, dass f¨

ur jede anzuwendende ¨

Anderungsoperation

die zu untersuchenden Aktivit¨

aten bestimmt und daraufhin deren Zust¨

ande auf Einhaltung der

Bedingungen untersucht werden. Erf¨

ullt nur eine einzige Aktivit¨

at nicht die gestellte Anforde-

rung an ihren Zustand, so klassifiziert der Test die Instanz als unvertr¨

aglich.

Der Aufwand zur ¨

Uberpr¨

ufung der Bedingungen ist deutlich geringer als die ganze Ausf¨

uhrungs-

historie nachzuspielen. Außerdem erfordert der Test auf Vertr¨

aglichkeit nicht mehr den Zugriff

auf die komplette Ausf¨

uhrungshistorie, sondern nur auf einen sehr geringen Teil daraus: Ben¨

otigt

werden die Informationen, die den aktuellen Zustand betreffen. Um den Zugriff auf die Historie

zu vermeiden, werden diese Informationen zus¨

atzlich und schnell zugreifbar in Form von Zu-

standsmarkierungen von Aktivit¨

aten in der Instanz hinterlegt. Der geringe Umfang dieser Da-

ten erm¨

oglicht es, sie im Hauptspeicher zu halten. Damit entf¨

allt der Zugriff auf den erheblich

langsameren Hintergrundspeicher6. Ein weiterer Vorteil ist, dass nicht das neue Laufzeitschema

hergestellt werden muss, bevor die Instanz als vertr¨

aglich erkannt wurde.

2.3.4 Markierungsanpassung

Auch wenn die migrierten Instanzen vom Zustand her vertr¨

aglich mit den ¨

Anderungen sind,

m¨

ussen im Allgemeinen an ihnen im Anschluss an die Migration noch Zustandsanpassungen

vorgenommen werden, wie Abbildung 2.9 zeigt:

Bei der Instanz I ist nach der Anwendung von ∆Sdie Aktivit¨

at A2 noch als aktiviert markiert,

obwohl die Vorg¨

angeraktivit¨

at, die neue Aktivit¨

at A12, noch nicht abgearbeitet wurde. Sie muss

wieder in den inaktiven Zustand zur¨

uckversetzt werden, d. h. die entsprechenden Arbeitsauftr¨

age

m¨

ussen aus den Arbeitslisten der infrage kommenden Bearbeiter herausgenommen werden, da-

mit sie nicht vor A12 ausgef¨

uhrt werden kann. Bei A12 liegt der umgekehrte Fall vor: Sie befindet

sich f¨

alschlicherweise noch im inaktiven Zustand, obwohl ihre direkte Vorg¨

angeraktivit¨

at A1 be-

reits beendet wurde und sie nach der Vorgabe des Kontrollflusses nun eigentlich zur Ausf¨

uhrung

anstehen m¨

usste. Es ist damit erforderlich, ihren Zustand von “INAKTIV” in “AKTIVIERT” zu

6Ausnahme: Die Instanz wurde im Rahmen der regul¨

aren Speicherverwaltung auf den Hintergrundspeicher

ausgelagert und muss zur Verarbeitung wieder in den Hauptspeicher geladen werden.

2.3. MIGRATION 25

ProzessvorlageS

A1 A2 A3

AufSbasierendeInstanz

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A2 A23A1 A12 A3

Propagationvon DSaufSI

Aktivität Kontrollflusskante

inaktiv aktiviert

beendet

imRahmenderMigrationeingefügte Aktivität

P P

A2 A23A1 A12 A3

Markierungsanpassung

Instanz Aktivität Status

Arbeitsliste

IA2

Instanz Aktivität Status

Arbeitsliste

IA2

Instanz Aktivität Status

Arbeitsliste

IA12

Prop.von

SaufSDI

Markierungs-

anpassung

Abbildung 2.9: Die Laufzeitzust¨

ande und Arbeitslisteneintr¨

age von I vor der Migration, nach

Anwendung von ∆Saber bei noch nicht erfolgter Markierungsanpassung und nach erfolgter

Anpassung.

andern. Die relevanten Bearbeiter bekommen damit einen entsprechenden Arbeitsauftrag in ihre

Arbeitsliste gestellt. Diese Anpassungen haben keinen Einfluss auf die bestehende Ausf¨

uhrungs-

historie, da inaktive bzw. aktivierte Aktivit¨

aten noch keine Historieneintr¨

age geschrieben haben.

Deshalb sind sie zul¨

assig.

Welche Aktivit¨

aten u. U. in ihrem Zustand angepasst werden m¨

ussen, h¨

angt wiederum von den

durchgef¨

uhrten ¨

Anderungen ab, d. h. die Menge der anzupassenden Aktivit¨

aten kann anhand der

aufgerufenenen ¨

Anderungsoperationen bestimmt werden. [RRD02] f¨

uhrt die entsprechenden Re-

geln auf. Wird z. B. die Aktivit¨

at Y zwischen X und Z eingef¨

ugt, so muss die Nachfolgeaktivit¨

Z von Y auf ”INAKTIV“ zur¨

uckgesetzt werden, wenn sie sich bereits in dem Zustand ”AKTI-

VIERT“ befand. Liegt der Status ”INAKTIV“ oder ”ABGEW¨

AHLT“ vor, so sind keine Anpas-

sungen vorzunehmen7. Eine Aktivit¨

at bekommt den Status ”ABGEW¨

AHLT“, wenn sie in einem

abgew¨

ahlten Pfad einer XOR-Verzweigung liegt. Zus¨

atzlich muss die eingef¨

ugte Aktivit¨

at Y noch

aktiviert werden, wenn die Voraussetzungen daf¨

ur gegeben sind, bzw. als ”ABGEW¨

AHLT“ mar-

kiert werden, wenn sie in einen abgew¨

ahlten Pfad einer XOR-Verzweigung eingef¨

ugt wurde. Ein

effizienter Algorithmus f¨

ur die Markierungsanpassung wird ebenso in [RRD02] beschrieben.

7Einen anderen Zustand als ”AKTIVIERT“, ”INAKTIV“ oder auch ”ABGEW¨

AHLT“ kann Z direkt nach der

Migration nicht innehaben, da die Instanz sonst nicht vertr¨

aglich mit dieser Operation gewesen w¨

are und es somit

nicht zu einer Migration dieser Instanz gekommen w¨

are (vgl. Abschnitt 2.3.3).

26 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

2.3.5 Ablauf der Migration einer Instanz

Zusammengefasst kann damit der Migrationsprozess in sechs Phasen eingeteilt werden, wie das

Zustandsdiagramm aus Abbildung 2.10 zeigt. In der ersten Phase, der Vertr¨

aglichkeitspr¨

ufung,

MigrationeinerInstanz

Instanzsteht

zurMigrationan

1.Phase:Verträglichkeitsprüfung

Entry/Verträglichkeitsprüfungdurchführen

Wenn(Instanz

unverträglich)

2.Phase:Klasseneinteilung

Wenn(Instanzverträglich)

3.Phase:Migrationsvorbereitung

Entry/NeuenVerzerrungsgradbestimmen

4.Phase:Migrationsvorgang

5.Phase:Instanzanpassung

Entry/Datenstrukturenanpassen

6.Phase:Markierungsanpassung

Wenn

(Instanzunverzerrt)

Entry/Überlappungsgradbestimmen

Wenn(Instanzverzerrt)

Entry/Markierungsanpassungdurchführen

Entry/Migrationdurchführen

Instanznicht

migriert

Instanz

migriert

Wenn(Migrationführt

zuinkorrektemSchema)

Wenn(MigrationführtzukorrektemSchema)

Abbildung 2.10: Das Zustandsdiagramm zur Migration.

wird eine zur Migration anstehende Instanz auf Vertr¨

aglichkeit mit den ¨

Anderungen gepr¨

uft. Im

Falle der Unvertr¨

aglichkeit wird die Instanz von der Migration ausgeschlossen. In der zweiten

Phase wird sie einer der beiden Klassen ”Verzerrte Instanz“ und ”Unverzerrte Instanz“ zuge-

ordnet. Bei einer verzerrten Instanz wird zus¨

atzlich der ¨

Uberlappungsgrad der Instanz¨

anderung

mit der Schema¨

anderung bestimmt. Durch die Klasseneinteilung wird deren Migrationsstrategie

festgelegt. In der darauf folgenden Phase werden die zus¨

atzlich f¨

ur die Migration einer verzerrten

Instanz ben¨

otigten Informationen berechnet, wie z. B. der neue Bias, mit dem die Instanz nach

der Migration gegen¨

uber der neuen Vorlage verzerrt sein wird. Unverzerrte Instanzen k¨

onnen

diese Phase ¨

uberspringen, da keine weiteren Informationen ben¨

otigt werden. Zus¨

atzlich wird in

dieser Phase untersucht, ob das resultierende Schema Verst¨

oße gegen die Korrektheitskriterien

des zugrunde gelegten Prozess-Modells aufweisen wird. Im Falle eines Verstoßes wird die Instanz

an dieser Stelle von der Migration zur¨

uckgewiesen. Stehen alle f¨

ur die Migration ben¨

otigten In-

formationen zur Verf¨

ugung, so tritt die Instanz in die vierte Phase der Migration ein, in der

2.4. DYNAMISCHE ¨

ANDERUNGEN 27

die bisher unverzerrten und verzerrten Instanzen gem¨

aß der in Phase 2 festgelegten Migrations-

strategie an die neue Schemaversion angepasst werden. Wenn im Rahmen der Migration neue

Aktivit¨

aten dazu kamen, so m¨

ussen die Datenstrukturen angepasst werden, welche die Lauf-

zeitinformationen, wie z. B. den momentanen Ausf¨

uhrungsstand, speichern, um entsprechende

Eintr¨

age f¨

ur diese Aktivit¨

aten aufnehmen zu k¨

onnen. Daf¨

ur ist die f¨

unfte Phase, die Instanzan-

passung, gedacht. Andere ¨

Anderungsoperationen fordern andere Anpassungen. Der Migrations-

prozess endet mit der Phase der Markierungsanpassung, in der die Zust¨

ande von bestimmten

Aktivit¨

aten der Instanz, wie in Abschnitt 2.3.4 beschrieben, angepasst werden.

2.4 Dynamische ¨

Anderungen

Vertr¨

aglichkeitspr¨

ufung, Instanzanpassung und Markierungsanpassung spielen auch bei dyna-

mischen ¨

Anderungen von Instanzen zur Laufzeit eine Rolle.

Wie schon angedeutet wird durch eine dynamische ¨

Anderung das Laufzeitschema SIeiner In-

stanz I gegen¨

uber der Vorlage Sdurch ¨

Anderungsoperationen ∆SImehr oder weniger stark

abge¨

andert. F¨

ur das resultierende Laufzeitschema SI∗der nun gegen¨

uber der Vorlage verzerrten

Instanz I gilt: SI∗=SI+ ∆SI≡trace S+ ∆SI.

Anmerkung: Eine Instanz kann auch innerhalb mehrerer ¨

Anderungstransaktionen abge¨

andert

worden sein. Nach der i-ten Transaktion gilt dann f¨

ur das neue Laufzeitschema SI∗, wenn da-

zwischen keine Migration stattgefunden hat:

SI∗=SI∗i=SI∗i−1+ ∆SIi=SI+i

j=1

∆SIj≡trace S+i

j=1

∆SIj.

Nach einer Instanz¨

anderung muss bei der Instanz nicht nur wieder statische Korrektheit vorlie-

gen, sondern auch die dynamische (vgl. [Re00]). Statische Korrektheit liegt vor, wenn wie im Falle

der Schemaevolution das resultierende Laufzeitschema der Instanz gegen keine Korrektheitskrite-

rien des Prozess-Modells in Bezug auf den Aufbau eines Schemas verst¨

oßt. Zum Beispiel darf das

Laufzeitschema in ADEPT keine Zyklen bez¨

uglich Kontrollfluss- und Sync-Kanten aufweisen.

Dynamische Korrektheit liegt vor, wenn keine Inkonsistenzen im Zustand der Instanz existieren.

Somit d¨

urfen die Instanz¨

anderungen zu keinen Zustandsinkonsistenzen f¨

uhren, die nicht durch

die von der Migration her bekannte Markierungsanpassung aufgel¨

ost werden d¨

urfen. In ADEPT

darf z. B. keine Aktivit¨

at sequentiell vor eine bereits ausgef¨

uhrte Aktivit¨

at eingef¨

ugt werden,

da sonst gegen die Regel verstoßen wird, dass eine Aktivit¨

at erst gestartet werden darf, wenn

die Vorg¨

anger-Aktivit¨

aten bereits beendet wurden. ¨

Anderungen f¨

uhren nicht zu nicht durch die

Markierungsanpassung bereinigbaren Zustandsinkonsistenzen, wenn sie vertr¨

aglich mit dem ak-

tuellen Zustand der Instanz sind. Deshalb muss vor der Anwendung einer ¨

Anderungsoperation

deren Vertr¨

aglichkeit ¨

uberpr¨

uft werden. Im Falle einer Unvertr¨

aglichkeit muss die Operation

zur¨

uckgewiesen werden.

Wie bei der Migration muss nach einer ¨

Anderung der Instanz die Datenstruktur, welche die

Zust¨

ande aller Aktivit¨

aten speichert, nach der Modifikation an das ge¨

anderte Schema angepasst

28 KAPITEL 2. KONZEPTE DES ADAPTIVEN PROZESS-MANAGEMENTS

werden, um z. B. den Zustand einer neu eingef¨

ugten Aktivit¨

at aufnehmen zu k¨

onnen. Dies

geschieht im Rahmen der aus der Migration bekannten Instanzanpassung.

Ebenso kann eine Instanz¨

anderung die Markierungsanpassung notwendig machen. Wird z. B.

eine Aktivit¨

at Y sequentiell direkt vor die aktivierte Aktivit¨

at Z eingef¨

ugt, dann muss Z wieder

deaktiviert werden, um deren Ausf¨

uhrung vor Y zu verhindern. Y muss stattdessen aktiviert

werden, sofern nichts anderes dagegen spricht, wie z. B. dass Y aufgrund einer Sync-Kante auf

das Ende einer anderen Aktivit¨

at warten muss.

Um dem Benutzer immer eine korrekte Sicht auf die Instanz bieten zu k¨

onnen, wird der Ablauf

vorgeschlagen, der sich mit dem Zustandsdiagramm aus Abbildung 2.11 darstellen l¨

asst:

DynamischeÄnderungeinerInstanz

Instanzaktiv

Änderungsphase

Benutzer öffnet

Änderungstransaktion

Transaktionabgebrochen

Entry/Änderungenverwerfen

Benutzer-

Abbruch

Benutzer-Commit

[Änderungvollständig]

Entry/ÄnderungeninsPMSübernehmen

Transaktioncommited

GeänderteInstanzaktiv

UnveränderteInstanzaktiv

Operationsauswahl

Verträglichkeitsprüfung

Operationsanwendung

Instanzanpassung

Markierungsanpassung

Entry/Verträglichkeitsprüfungdurchführen

Korrektheitsprüfung

Schemawirdvom

Benutzerabgeändert

[Änderungunvollständig]

Wenn

(Schemainkorrekt)

Wenn

(Instanzverträglich)

Wenn

(Schemakorrekt)

Änderung

vollständig

Wenn(Instanz

unverträglich)

Entry/Korrektheitsprüfungdurchführen

Entry/ausgewählteOperationausführen

Operation

ausgewählt

Entry/Instanzanpassungdurchführen

Entry/Markierungsanpassungdurchführen

Abbildung 2.11: Das Zustandsdiagramm zur dynamischen ¨

Anderung einer Instanz.

Um eine ¨

Anderung durchzuf¨

uhren, wird mit dem Beginn der ¨

Anderungstransaktion die zu

andernde Instanz auf den Client-Rechner kopiert. Die Instanz tritt damit in die ¨

Anderungsphase

ein. Der Benutzer kann dann mit einem entsprechenden Tool die ¨

Anderungen am Laufzeitsche-

ma vornehmen. Bevor jedoch eine gew¨

unschte Operation auf das Laufzeitschema angewendet

wird, wird ¨

uberpr¨

uft, ob die Operation vom aktuellen Laufzeitzustand her ¨

uberhaupt erlaubt

werden darf. Daf¨

ur kommen die gleichen Regeln wie bei der Vertr¨

aglichkeitspr¨

ufung bei der

2.5. ZUSAMMENFASSUNG 29

Migration zur Anwendung (vgl. Abschnitt 2.3.3). F¨

allt der Test negativ aus, so wird dem Be-

nutzer diese Operation verweigert. Die Verweigerung f¨

uhrt systemseitig nicht automatisch zum

Abbruch der ¨

Anderungstransaktion. Der Benutzer kann innerhalb des gleichen Transaktions-

kontextes weitere Modifikationen durchf¨

uhren. F¨

allt der Test positiv aus, so wird die Operation

auf das Laufzeitschema angewendet, vorausgesetzt, das resultierende Schema widerspricht nicht

den Korrektheitskriterien des zugrunde gelegten Prozess-Modells. Danach werden sofort – wenn

n¨

otig – die Datenstrukturen, welche die aktuellen Zust¨

ande speichern, analog zur Phase 5 bei

der Migration angepasst und die Markierungszust¨

ande analog zur Phase 6 bei der Migration ak-

tualisiert. Erst danach kann der Benutzer weitere ¨

Anderungsoperationen durchf¨

uhren. Bei einem

Commit der ¨

Anderungstransaktion werden die ¨

Anderungen auf den PMS-Server ¨

ubernommen.

F¨

ur einen Abbruch der Transaktion wird die Kopie einfach verworfen.

Auf die Probleme, die auftreten k¨

onnen, wenn zeitgleich zur Ad-hoc-Modifikation die Instanz

weitergeschaltet wird, und wie diese Probleme verhindert werden k¨

onnen, wird in Kapitel 5.4

n¨

aher eingegangen.

Eine andere m¨

ogliche Vorgehensweise f¨

ur das Ab¨

andern einer Instanz ist, den Benutzer zu-

erst s¨

amtliche Modifikationen auf dem Laufzeitschema der Instanz ohne Pr¨

ufungen durchf¨

uhren

zu lassen und erst sp¨

ater im Rahmen der Commit-Behandlung die notwendige Vertr¨

aglich-

keitspr¨

ufung, Instanzanpassung und Markierungsanpassung vorzunehmen. Im Falle der Unver-

tr¨

aglichkeit muss der Benutzer dann aber seine Modifikationen ¨

uberarbeiten, was aufw¨

andig sein

kann.

2.5 Zusammenfassung

Dieses Kapitel zeigt, dass ¨

Anderungen des Schemas nicht einfach auf die Instanzen ¨

ubernommen

werden d¨

urfen, da es im Falle von unvertr¨

aglichen Instanzen oder bei entsprechender Kombi-

nation von Instanz- und Schema¨

anderungen zu Inkonsistenzen im Zustand oder zu Verst¨

oßen

gegen die Korrektheitskriterien des zugrunde liegenden Prozess-Modells kommen kann. Deshalb

m¨

ussen vor der Migration der Instanzen Tests sicherstellen, dass es dazu nicht kommt. Weiter

zeigt dieses Kapitel, dass die Art und Weise, wie Instanzen an die neue Vorlage anzupassen sind,

davon abh¨

angt, ob eine unverzerrte Instanz oder eine verzerrte Instanz vorliegt und im Falle

einer verzerrten Instanz, inwieweit sich die Instanz- und Schema¨

anderungen ¨

uberlappen.

Wie die Schemaevolution, die dynamische ¨

Anderung einer Instanz und die Phase 4 des Mi-

grationsprosses physisch realisiert werden, h¨

angt davon ab, wie Prozessvorlagen und -instanzen

im Speicher repr¨

asentiert sind. Das n¨

achste Kapitel leitet eine Repr¨

asentationsform her und

beschreibt darauf aufbauend die physische Realisierung der in diesem Kapitel beschriebenen

Mechanismen der Adaptivit¨

at.

Kapitel 3

Realisierung von Prozessvorlagen

und -instanzen

In diesem Kapitel wird Schritt f¨

ur Schritt eine Architektur erarbeitet, mit der sowohl Ad-hoc-

Modifikationen von Instanzen als auch ¨

Anderungen von Prozessvorlagen durchgef¨

uhrt werden

k¨

onnen. Zudem unterst¨

utzt dieser Ansatz die Migration von unverzerrten sowie von verzerrten

Instanzen auf ein modifiziertes Prozessschema, ohne dabei das System stark zu belasten oder

einen hohen Ressourcenbedarf aufzuweisen. Die Realisierungsentscheidungen werden u. a. durch

Gegen¨

uberstellung mit anderen Realisierungsvarianten begr¨

undet.

3.1 Naiver Architekturansatz

Der naive Ansatz, Instanzen zu repr¨

asentieren, zeigt Abbildung 3.1. Er besteht darin, f¨

ur je-

de Instanz ein Objekt anzulegen und darin sowohl die Laufzeitinformationen, wie z. B. den

Ausf¨

uhrungszustand der Instanz, als auch die Prozessbeschreibungen, wie den Kontroll- und

Datenfluss, zu speichern.

Die Anpassung unverzerrter Instanzen an eine neue Version der zugrunde liegenden Prozessvorla-

ge erfolgt, indem die ¨

Anderungsoperationen, welche die Vorlage von der alten in die neue Version

uberf¨

uhrt haben, auf die in den entsprechenden Instanz-Objekten hinterlegten Schemata erneut

angewendet werden. Bei verzerrten Instanzen muss eine dem ¨

Uberlappungsgrad von Schema-

und Instanz¨

anderung entsprechend angepasste Operationenmenge angewendet werden. Bei ver-

zerrten Instanzen, wie z. B. bei der Instanz I3 aus Abbildung 3.1, weicht das im Instanz-Objekt

hinterlegte Schema von der Vorlage ab.

Der große Nachteil bei diesem Ansatz ist, dass dabei die Prozessbeschreibung unn¨

otig oft redun-

dant gespeichert wird: Jede (unverzerrte) Instanz desselben Prozesstyps l¨

auft nach dem gleichen

Schema ab. Deshalb sind in jedem der entsprechenden Instanz-Objekte dieselben Schemain-

3.2. ARCHITEKTURANSATZ 31

A1 A2 A3

InstanzI1

DatenelementD1:W1

A1 A2 A3

InstanzI2

DatenelementD1:W2

inaktiv uin Ausführung

beendet

aktiviert

A1 A2 A23

InstanzI3

DatenelementD1:W3

A3 A1 A2 A3

InstanzI4

DatenelementD1:W4

Aktivität Konrollflusskante Datenflusskante

Redundanzen

DatenelementD1:W4 DatenelementmitDatenwert

Abbildung 3.1: Naiver Ansatz, Instanzen zu repr¨

asentieren

formationen – die Prozessbeschreibung – enthalten. Es l¨

asst sich erheblich Speicher einsparen,

wenn die redundanten Informationen aus den jeweiligen Instanz-Objekten herausgenommen und

stattdessen einmal in einem speziellen, dem Prozesstyp zugeordneten Objekt hinterlegt werden.

Jede Instanz des entsprechenden Prozesstyps greift dann auf dieses Objekt zu, um an die Infor-

mationen ¨

uber das Prozessschema zu kommen. Der im Folgenden vorgestellte Architekturansatz

beschreitet diesen Weg.

3.2 Architekturansatz

Ein in der Literatur (z. B. [We01]) vorgeschlagener Implementierungsansatz f¨

ur Prozessvorlagen

und Instanzen wird in Abbildung 3.2 illustriert. Bei diesem Ansatz wird die Prozessbeschreibung

in einem Objekt, der Prozessvorlage, gekapselt, das den Prozesstyp repr¨

asentiert. Die Instanz-

Objekte, welche Prozessinstanzen repr¨

asentieren, enthalten selber nur Laufzeitinformationen, wie

den Ausf¨

uhrungsstatus von Aktivit¨

aten und logisch, nicht unbedingt physisch, den Inhalt der

Datenelemente. Die Prozesstypzugeh¨

origkeit wird durch eine Referenz auf das entsprechende

32 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

InstanzI2

A1: A2:

A3:

DatenelementD1:W2

A1 A2 A3

VorlageS1

DatenelementD1

InstanzI1

A1: A2:

A3:

DatenelementD1:W1

A1 A2 A3

DatenelementD1:W1

A1 A2 A3

DatenelementD1:W2

inaktiv uin Ausführung

beendet

aktiviert

Aktivität Referenz

Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

Abbildung 3.2: Die Repr¨

asentation von Instanzen eines Prozesstyps

Prozessvorlagen-Objekt ausgedr¨

uckt. Alle Instanzen eines Prozesstyps referenzieren dasselbe

Vorlagen-Objekt. Dieser Ansatz soll als Ausgangsbasis dienen.

Gegen¨

uber der Variante, f¨

ur jede Instanz die jeweilige Prozessbeschreibung redundant zu spei-

chern (siehe Abschnitt 3.1), resultiert ein erheblich geringerer Speicherplatzbedarf bei großer

Anzahl von Instanzen. Ein weiterer Vorteil ist, dass sich damit auch signifikant Rechenzeit ein-

sparen l¨

asst, da strukturver¨

andernde Operationen bei einer Schemaevolution nur einmal auf die

Prozessvorlage angewendet werden m¨

ussen, bei der anderen Variante dagegen auf jede einzelne

Prozessinstanz.

3.3 Schemaevolution und Migration unverzerrter Instanzen

Bei dieser Implementierung darf allerdings die Schema¨

anderung nicht direkt auf dem Vorlagen-

Objekt ausgef¨

uhrt werden, welches die aktuelle Version repr¨

asentiert. Die Propagation der Sche-

ma¨

anderungen auf Instanzen w¨

urde zwar damit in einem Vorgang erfolgen, aber dann k¨

onnen

auch Instanzen f¨

alschlicherweise migriert werden, die f¨

ur diese ¨

Anderungen zu weit fortgeschrit-

ten sind. In Abbildung 3.3 laufen Instanz I1 und Instanz I2 auf derselben Vorlage S1, wobei I1

weiter fortgeschritten ist als I2. Da sich A2 bei I1 bereits in Ausf¨

uhrung befindet, ist I1 unver-

tr¨

aglich mit der neuen Version des Schemas S1, bei der vor A2 die Aktivit¨

at A12 eingef¨

ugt wird.

Wird nun die ¨

Anderung direkt auf S1 ausgef¨

uhrt, so migriert zwar I2 ordnungsgem¨

aß, aber I1

3.4. REPR ¨

ASENTATIONSVARIANTE F ¨

UR VERZERRTE INSTANZEN 33

inaktiv uin Ausführung

beendet

aktiviert

A1 A2 A3

VorlageS1

DatenelementD1

Aktivität Referenz

Datenflusskante DatenelementD1 Datenelement

InstanzI1

A1: u

DatenelementD1:W1

Konrollflusskante

A2:

A3:

InstanzI2

A1:

DatenelementD1:W2

A2:

A3:

A12 A2 A3

VorlageS1’

DatenelementD1

InstanzI1

A1: u

DatenelementD1:W1

A2:

A3:

InstanzI2

A1:

DatenelementD1:W2

A2:

A3:A12: A12:

VorlageS1

direkt

abändern

VorderMigration NachderMigration

A12 A2 A3

DatenelementD1:W1

A12 A2 A3

DatenelementD1:W2

Abbildung 3.3: Migration durch direkte Ab¨

anderung der Vorlage

folgt verbotenerweise ebenfalls dem neuen Schema, da sie weiterhin das gleiche Vorlagen-Objekt

referenziert wie I2. Eine Inkonsistenz ist die Folge: A2 von Instanz I1 wurde gestartet, bevor die

Vorg¨

angeraktivit¨

at A12 ausgef¨

uhrt worden ist.

Die Koexistenz von Instanzen, die auf verschiedenen Versionen der Prozessvorlage laufen, kann

sichergestellt werden, indem eine Kopie des Prozessvorlagen-Objekts angelegt wird, daran die

Modifikationen ausgef¨

uhrt werden und dann alle migrierbaren Instanzen auf dieses Objekt um-

geh¨

angt werden. In diesem Fall besteht der Vorgang des Migrierens aus dem ”Umbiegen“ der

Schemareferenz auf die neue Version.

3.4 Repr¨

asentationsvariante f¨

ur verzerrte Instanzen

Wie lassen sich mit obigen Implementierungsvorschlag instanzbezogene Ad-hoc-Modifikationen

abbilden? Eine M¨

oglichkeit ist es, eine Kopie des entsprechenden Prozessvorlagen-Objekts an-

zufertigen, die ¨

Anderungen darauf anzuwenden und dann die Instanz auf dieses Schema umzu-

biegen (siehe Abbildung 3.4).

34 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

A1 A2 A3

VorlageS1

DatenelementD1

InstanzI1 InstanzI2 InstanzI3

A2 A23 A3

VorlageS1*

DatenelementD1

Adhoc-Modifikation

vonInstanzI3

Aktivität Referenz

Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

A1 A2 A3

VorlageS1

DatenelementD1

DS ={insertActivity(A23, A2, A3)}I3

S *I

trace

S1+ S =S1*DI3

Abbildung 3.4: Fehlende Typ-Zugeh¨

origkeit nach einer dynamischen ¨

Anderung

Von Nachteil ist, dass damit die urspr¨

ungliche Prozesstypzugeh¨

origkeit verloren geht: Die ver-

zerrte Instanz I3 referenziert nicht mehr das urspr¨

ungliche Vorlagen-Objekt S1, obwohl sie noch

von dem durch dieses Objekt beschriebenen Prozesstyp abstammt. Ohne zus¨

atzliche Vorkeh-

rungen wird die Instanz I3 bei einer sp¨

ateren Schemaevolution nicht mehr ber¨

ucksichtigt. Hinzu

kommt, dass dieser Ansatz zu der anfangs in Abschnitt 3.1 erw¨

ahnten L¨

osung, bei der in jeder

Instanz der gesamte Prozessablauf hinterlegt ist, degeneriert, wenn mehr und mehr Instanzen

abge¨

andert werden.

Ber¨

ucksichtigt man aber, dass bei Instanz¨

anderungen im Allgemeinen nur ein kleiner Teil des

urspr¨

unglichen Prozessschemas angepasst wird, so l¨

asst sich eine alternative Strategie zur Re-

pr¨

asentation von verzerrten Instanzen anwenden: Man speichert bei jeder modifizierten Instanz

nur die Abweichungen vom urspr¨

unglichen Schema. Diese k¨

onnen auf zweierlei Arten repr¨

asen-

tiert werden, entweder durch die ¨

Anderungsoperationen selbst oder durch eine Delta-Schicht,

die im folgenden Abschnitt 3.5 beschrieben wird.

Abweichungen durch die ¨

Anderungsoperationen selbst zu repr¨

asentieren, kann aufgrund der

kompakten Darstellungsm¨

oglichkeit einer ¨

Anderungsoperation erheblich Speicher gegen¨

uber der

zweiten Methode einsparen. Es muss aber zur Beantwortung einer jeden Schemaanfrage, wie

z. B. ”Gib mir die Nachfolgeraktivit¨

at von X“ erst tempor¨

ar das neue Schema durch Anwen-

dung der ¨

Anderungsoperationen auf eine Kopie der Vorlage hergestellt werden, was erhebliche

Performance-Einbußen bedeutet.

3.5. DIE DELTA-SCHICHT 35

Deshalb ist es besser, das ge¨

anderte Schema sofort zugriffsbereit zu haben, wie es bei der Delta-

Schicht-Methode der Fall ist.

3.5 Die Delta-Schicht

Abbildung 3.5 verdeutlicht das Konzept der Delta-Schicht. Die Delta-Schicht wird durch ein

InstanzI2

A1:

DatenelementD1:W2

A2:

A3:

A1 A2 A3

VorlageS1

DatenelementD1

inaktiv uin Ausführung

beendet

aktiviert

Aktivität

Referenz

Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

InstanzI1

A1: u

DatenelementD1:W1

A2:

A3:

A1:

A2* A23 A3*

Delta-Schicht

DatenelementD1:W3

A2:

A3: A23:

InstanzI3

A1 A2 A3

DatenelementD1:W1

A1 A2 A23

DatenelementD1:W3

A1 A2 A3

DatenelementD1:W2

referenzierte Aktivität

Abbildung 3.5: Das Konzept der Delta-Schicht

Objekt repr¨

asentiert, das die gleichen Schnittstellen wie das Prozessvorlagen-Objekt besitzt und

daher nach außen hin die gleichen Operationen anbietet. Der Unterschied zu dem originalen

Vorlagen-Objekt besteht darin, dass es nicht den gesamten Prozessgraphen widergibt, sondern

nur die Ausschnitte, die durch instanzbezogene Modifikationen ge¨

andert wurden. Daher der

Name Delta-Schicht.

Zusammen mit dem Prozessvorlagen-Objekt, das den Prozesstyp der Instanz bestimmt, repr¨

asen-

tiert das Delta-Schicht-Objekt das gegen¨

uber der Prozessvorlage abge¨

anderte Laufzeitschema

der modifizierten Instanz. Das Instanz-Objekt, das die ge¨

anderte Instanz repr¨

asentiert, referen-

ziert dann nicht mehr, wie in Abbildung 3.5 anhand von Instanz I3 gezeigt, das entsprechende

36 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

Vorlagen-Objekt, sondern das Delta-Schicht-Objekt. Erst das Delta-Schicht-Objekt setzt auf

dem originalen Vorlagen-Objekt auf und bewahrt auf diesem Weg u. a. die Typzugeh¨

origkeit

der Instanz I3 zum Prozesstyp S1. Die unver¨

anderten Instanzen, wie z. B die Instanzen I1 und

I2, referenzieren das originale Prozessvorlagen-Objekt weiterhin direkt. Bei modifizierten In-

stanzen werden deshalb Anfragen, wie z. B. “Gib mir alle direkten Nachfolgeaktivit¨

aten von

Aktivit¨

at Z!”, zuerst an die Zwischenschicht gerichtet, bei unver¨

anderten dagegen direkt an das

Prozessvorlagen-Objekt.

Aus Gesichtspunkten der Speicherverwaltung w¨

are es sinnvoll, alle Instanz-Objekte verzerr-

ter Instanzen, die in ihrem Laufzeitschema ausf¨

uhrungs¨

aquivalent sind, dasselbe Delta-Schicht-

Objekt referenzieren zu lassen, anstatt f¨

ur jedes ein extra Delta-Schicht-Objekt anzulegen. Es

w¨

urde allerdings einen erheblichen Aufwand kosten, bei jeder Ad-hoc-Modifikation einer Instanz

genau das Delta-Schicht-Objekt aus den eventuell hundert bestehenden herauszusuchen – sofern

uberhaupt schon vorhanden –, das exakt dieselben Auswirkungen auf das zugrunde gelegte Pro-

zessschema verursacht, wie mit der Ad-hoc-Modifikation beabsichtigt ist. Aus diesem Grund ist

f¨

ur die Praxis die Variante vorzuziehen, bei der jeweils ein Delta-Schicht-Objekt genau einer

Instanz zugeordnet ist.

Da sich nach außen hin ein Delta-Schicht-Objekt nicht von einem Vorlagen-Objekt unterschei-

det, kann ein Delta-Schicht-Objekt statt einem Vorlagen-Objekt auch wieder ein Delta-Schicht-

Objekt referenzieren, d. h. mehrere Delta-Schicht-Objekte k¨

onnen ¨

ubereinander gestapelt wer-

den. Es muss nur sichergestellt sein, dass stets die unterste Delta-Schicht das typ-bestimmende

Vorlagen-Objekt referenziert. Alle Delta-Schicht-Objekte zusammen bilden dann das gegen¨

uber

der Vorlage abge¨

anderte Laufzeitschema. Zum Beispiel k¨

onnen tempor¨

are ¨

Anderungen1, die nur

einige Schleifendurchl¨

aufe lang G¨

ultigkeit haben, in einer gesonderten Schicht gespeichert wer-

den. Tempor¨

are ¨

Anderungen r¨

uckg¨

angig zu machen besteht dann nur aus dem Verwerfen des

entsprechenden Delta-Schicht-Objekts2.

In diesem Zusammenhang kommt die Frage auf, warum bei der Schemaevolution die ¨

Anderun-

gen von einer Version auf die n¨

achste nicht durch Delta-Schicht-Objekte repr¨

asentiert werden,

anstatt bei jedem Versionswechsel das Objekt der alten Vorlagenversion komplett zu kopieren

und darauf die ¨

Anderungen durchzuf¨

uhren (siehe Abschnitt 3.3). Der Grund hierf¨

ur ist, dass

bei der Verwendung von Delta-Schicht-Objekten meistens der Zugriff sowohl auf ein oder meh-

rere Delta-Schicht-Objekte als auch auf das originale Vorlagen-Objekt notwendig ist, um an die

aktuell geltenden Schemainformationen zu kommen, wie im Folgenden beschrieben wird. Bei

Vorlagen, die u. U. von hunderten Instanzen referenziert werden und auf die bei jedem Weiter-

schalten von Aktivit¨

aten zugegriffen werden muss, bedeutet der Mehrfachzugriff eine zu große

Performance-Einbuße.

Wie die Delta-Schicht selbst realisiert werden kann, h¨

angt von der Repr¨

asentation der Knoten

und Kanten des Prozessgraphen ab. In unserer Implementierung (siehe Abschnitt 3.8) existieren

1Siehe dazu [We97]

2Es muss dabei nur sichergestellt werden, dass es nicht zu Inkonsistenzen kommt, wenn sich andere Modifika-

tionen auf diese tempor¨

aren ¨

Anderungen bezogen haben.

3.5. DIE DELTA-SCHICHT 37

keine Kanten-Objekte. Wir speichern zu jeder Aktivit¨

at die ID der Vorg¨

anger- und Nachfolger-

aktivit¨

aten und stellen dadurch implizit den Kontrollfluss her. Vor einer dynamischen ¨

Anderung

werden alle Aktivit¨

aten-Objekte automatisch in die Delta-Schicht kopiert, die von der ¨

Anderung

betroffen sind. Die ¨

Anderungen werden dann auf den Kopien durchgef¨

uhrt.

InstanzI3

A1 A2 A3

VorlageS1

DatenelementD1

A1 A2 A3

VorlageS1

DatenelementD1

Delta-Schicht

InstanzI3

A1 A2 A3

VorlageS1

DatenelementD1

Delta-Schicht

InstanzI3

A1 A2* A3*

A1 A2 A3

VorlageS1

DatenelementD1

Delta-Schicht

InstanzI3

A1 A2* A3*

A23

A1 A2 A23

DatenelementD1:W3

A1 A2 A3

DatenelementD1:W3

a) b)

c) d)

inaktiv uin Ausführung

beendet

aktiviert

Aktivität

Referenz

Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

referenzierte Aktivität

Abbildung 3.6: Serielles Einf¨

ugen einer Aktivit¨

at infolge einer Ad-hoc-Modifikation

Um z. B. die Aktivit¨

at A23 sequentiell zwischen die beiden Nachbaraktivit¨

aten A2 und A3 in die

Instanz I3 aus Abbildung 3.6 a einzuf¨

ugen, werden zuerst die Aktivit¨

aten-Objekte A2 und A3

komplett, inklusive der ID, kopiert (Abbildung 3.6 c) und als A2*3und A3* in das leere, zuvor

zwischen das Instanz- und Vorlagen-Objekt geh¨

angte Delta-Schicht-Objekt (Abbildung 3.6 b)

eingef¨

ugt. A2 und A3 m¨

ussen kopiert werden, da sich ihre Nachfolger- bzw. Vorg¨

angermengen

andern. Danach wird das Aktivit¨

aten-Objekt A23 in der Delta-Schicht angelegt. Schließlich wird

die Aktivit¨

at A23 sequentiell zwischen A2* und A3* eingereiht, indem die Vorg¨

anger-Nachfolger-

Beziehungen gesetzt werden (Abbildung 3.6 d): Die ID von A23 wird anstelle der von A3 in die

Liste der Nachfolger von A2* und anstelle der ID von A2 in die Liste der Vorg¨

anger von A3*

aufgenommen. A23 speichert analog dazu die ID von A2* in seiner Vorg¨

angerliste und die ID

von A3* in seiner Nachfolgerliste. In einer Implementierung mit Kanten-Objekten m¨

ussen f¨

3Der Stern soll nur zum besseren Verst¨

andnis beitragen.

38 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

die Einf¨

uge-Operation nicht A2 und A3 in die Delta-Schicht kopiert werden. Es werden nur A23

und die Kantenobjekte f¨

ur die Verbindung A2→A234und A23→A3 angelegt. Zus¨

atzlich muss

A2→A3 als gel¨

oscht markiert werden.

Soll eine Aktivit¨

at gel¨

oscht werden, so muss bei beiden Ans¨

atzen die entsprechende Aktivit¨

at in

der Delta-Schicht durch eine Null-Aktivit¨

at ersetzt werden oder anderweitig als gel¨

oscht mar-

kiert werden. Null-Aktivit¨

aten sind Aktivit¨

aten, denen keine Funktionen zugeordnet sind und

die nach der Aktivierung sofort beendet werden [Re00]. Weiter m¨

ussen die Vorg¨

anger- und Nach-

folgerbeziehungen entsprechend angepasst werden. Bei der Verwendung der Kantenobjekte muss

in der Delta-Schicht durch Aufnahme der neuen Kanten und durch L¨

oschen der alten Kanten der

neue Kontrollfluss hergestellt werden. In der anderen Variante m¨

ussen dazu die Vorg¨

anger und

die Nachfolger des gel¨

oschten Knotens in die Schicht kopiert und deren Liste mit den Nachfolgern

bzw. Vorg¨

angern entsprechend abge¨

andert werden.

Zur Beantwortung der Anfrage “Gib mir alle direkten Nachfolge-Aktivit¨

aten von Aktivit¨

at Z!”

sieht die Delta-Schicht bei der Implementierung ohne Kanten-Objekte zuerst nach, ob sie ein

Aktivit¨

aten-Objekt mit der entsprechenden ID gespeichert hat. Wenn ja, so gibt sie dessen

Nachfolgerliste zur¨

uck. Ansonsten leitet sie die Anfrage an das referenzierte Prozessvorlagen-

Objekt oder im Falle von gestapelten Delta-Schichten an das referenzierte Delta-Schicht-Objekt

weiter.

Bei einer Implementierung mit Kanten-Objekten holt sich die Delta-Schicht erst einmal die

Menge A aller Kanten-Objekte von dem von ihm ge¨

anderten Schema, in denen die Aktivit¨

at Z

als Quelle verzeichnet ist. Dann entfernt sie aus A alle von ihr als gel¨

oscht markierten Kanten und

vereinigt sie mit der Menge der durch die Ad-hoc-Modifikationen neu hinzugekommenen Kanten

mit Z als Quelle. Die nun vorliegende Menge B enth¨

alt alle von Z ausgehenden Kanten, aus denen

die Nachfolger gewonnen werden k¨

onnen. Referenziert das Delta-Schicht-Objekt anstatt eines

Vorlagen-Objekts wiederum ein Delta-Schicht-Objekt, dann ist f¨

ur die Bestimmung der Menge

A rekursiv dasselbe Verfahren auf dem referenzierten Delta-Schicht-Objekt auszuf¨

uhren.

Abbildung 3.7 gibt ein Beispiel: Um die Nachfolger-Aktivit¨

at von A1 der zweimalig ad hoc

modifizierten Prozessinstanz I1 zu bestimmen, wird eine entsprechende Anfrage an das Delta-

Schicht-Objekt II gestellt.

Das Delta-Schicht-Objekt muss zur Beantwortung der Anfrage die Menge B3der von A1 aus-

gehenden Kanten in dem vorliegenden Laufzeitschema bestimmen. Dazu muss es die Menge A3

der Kanten mit A1 als Quelle von dem von ihm ge¨

anderten Schema holen, das durch das Delta-

Schicht-Objekt I und durch das Vorlagen-Objekt repr¨

asentiert wird, und dann daraus die von

ihm gel¨

oschten Kanten entfernen, sowie die hinzugef¨

ugten hinzuf¨

ugen. Aus Sicht des Delta-

Schicht-Objekts I ist die Menge A3die Menge B2der ausgehenden Kanten von A1 in dem

durch die Delta-Schicht I und dem Vorlagen-Objekt repr¨

asentierten Schema. Deshalb ergeht

vom Delta-Schicht-Objekt II eine entsprechende Anfrage an das Delta-Schicht-Objekt I. Es be-

antwortet diese mit der Menge B2={(A1→A21),(A1→AY )}. Nach dem Entfernen

der gel¨

oschten Kante A1→AY und dem Hinzuf¨

ugen der neuen Kante A1→AX liegt mit

4in Tupel-Schreibweise: (A2, A23)

3.5. DIE DELTA-SCHICHT 39

Delta-SchichtI

InstanzI1

VorlageS1

(A1 AY) (AY A11)

(A1 A11)

Delta-SchichtII

(A1 AX) (AX AY)

(A1 AY)

B ={(A11A11),(A1

B =(A \{2 2 (A1 A11) })U{(A1 AY)}

A =B ={(A13 2

B =(A \{3 3 (A1 AY)})U{ (A1 AX) }

B ={3(A1

=>Nachfolgervon A2sind: A21und AX

Antwort: A21und AX

“Gibmiralledirekten

Nachfolge-Aktivitäten

von Aktivität A1!”

Gibmirdie

MengeB

allerKanten

mit A1als

Quelle!

Gibmirdie

MengeB

allerKanten

mit A1als

Quelle!

1A =B ={(A12 1

A11 A12

A21 A22

AX AY

A21 A22

A21)}

A11),(A1 A21)}

A21),(A1 AY)}

A21),(A1 AX)}

A11 A12

Abbildung 3.7: Nachfolgerbestimmung bei Implementierung mit Kantenobjekten

B3={(A1→A21),(A1→AX)}die Menge der von A1 ausgehenden Kanten im abgebildeten

Prozess I1 vor, aus der die Nachfolgeraktivit¨

aten A21 und AX von A1 ermittelt werden k¨

onnen.

F¨

ur die Bestimmung der Menge B2muss das Delta-Schicht-Objekt I analog vorgehen: Zuerst

bestimmt es die Menge A2=B1der ausgehenden Kanten von A1 in dem von dieser Delta-

Schicht abge¨

anderten Schema durch eine entsprechende Anfrage an das Vorlagen-Objekt. Das

Vorlagen-Objekt liefert daf¨

ur die Menge B1={(A1→A11),(A1→A21)}. Dann entfernt

es daraus die gel¨

oschte Kante A1→A11 und f¨

ugt die Kante A1→AY hinzu. Damit liegt

die Menge B2={(A1→A21),(A1→AY )}vor, die sie an das Delta-Schicht-Objekt II als

Antwort auf dessen Anfrage zur¨

uckgibt.

Die Variante mit Kanten-Objekten hat damit den Nachteil, dass stets der Zugriff auf alle Delta-

Schicht-Objekte und dem zugrunde liegenden Prozess-Vorlagen-Objekt notwendig ist, um die

ein- oder ausgehenden Kanten einer Aktivit¨

at zu bestimmen. Bei der Variante ohne Kantenob-

jekte entfallen die zus¨

atzlichen Zugriffe, wenn die entsprechende Aktivit¨

at bereits in der obersten

Delta-Schicht vorhanden ist. Dieser Unterschied f¨

allt besonders stark ins Gewicht, wenn mehrere

Delta-Schichten ¨

ubereinander gestapelt werden.

40 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

3.6 Migration verzerrter Instanzen

Wie sich eine verzerrte Instanz auf die neue Version S0der zugrunde liegenden Prozessdefinition

migrieren l¨

asst, ist abh¨

angig von dem ¨

Uberlappungsgrad der Schema¨

anderungen ∆Sund den

Instanz¨

anderungen ∆SI(vgl. Abschnitt 2.3.2).

3.6.1 Migration bei disjunkten ¨

Anderungsoperationen

Sind die Schema- und die Instanz¨

anderungen disjunkt, d. h. ∆S∩∆SI=∅, so w¨

are ein Ansatz

f¨

ur die Migration, die Referenz auf das Prozessvorlagen-Objekt in der Delta-Schicht auf die

neue Version ”umzubiegen“. Dies kann aber bei der Implementierungsvariante ohne Kanten-

Objekte zu Problemen f¨

uhren (vgl. Abbildung 3.8): A1, A2 und A3 seien drei sequentiell in Folge

geschaltete Aktivit¨

aten. Das Einf¨

ugen eines Knotens A23 zwischen A2 und A3 auf Instanzebene

f¨

uhrt dazu, das eine Kopie A2* von A2 in der Delta-Schicht angelegt wird und darin die ID

von A23 anstelle der ID von A3 in die Nachfolger-Liste aufgenommen wird. Durch das Einf¨

ugen

der Aktivit¨

at A12 zwischen A1 und A2 auf Schemaebene wird die ID von A1 durch die ID von

A12 in der Vorg¨

angerliste von A2 ersetzt. Die Anfrage “Gib mir die direkten Vorg¨

anger von

A2” liefert jedoch weiterhin A1 als Vorg¨

anger, da die Delta-Schicht die Vorg¨

angerliste von A2*

zur¨

uckgibt, die aber durch die Schemaevolution nicht angepasst wurde und deshalb immer noch

die ID von A1 enth¨

alt.

A2* A23 A3*

Delta-Schicht

InstanzI3

A1 A2 A3

VorlageS1

DatenelementD1

A1 A12 A2

VorlageS1’

DatenelementD1

Migration

Aktivität Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

referenzierte Aktivität

Referenz

Abbildung 3.8: Inkorrekte Migration verzerrter Instanzen bei Realisierung ohne Kantenobjekte

Eine L¨

osung dieses Problems besteht darin, auf das Prozessvorlagen-Objekt, das die neue Version

des Schemas repr¨

asentiert, ein leeres Delta-Schicht-Objekt aufzusetzen. Darauf werden dann die

gleichen dynamischen ¨

Anderungen angewendet und vom entsprechenden Instanz-Objekt refe-

3.6. MIGRATION VERZERRTER INSTANZEN 41

renziert. Da bei dieser Vorgehensweise das Einf¨

ugen von A12 vor dem Einf¨

ugen von A23 erfolgt,

weist A2 schon vor dem Kopieren in die Delta-Schicht A12 als seinen Vorg¨

anger aus. Nach dem

Kopieren gilt daher das Gleiche f¨

ur die Kopie A2* von A2. Die Anfrage wird somit korrekt beant-

wortet. Die Abfolge der auf Instanz- und Typebene vorgenommenen ¨

Anderungen zu vertauschen

war zul¨

assig, da vorausgesetzt wurde, dass sich die ¨

Anderungen nicht ¨

uberlappen5.

Bei der Implementierung mit Kantenobjekten tritt das Problem des “vergessenen” Vorg¨

angers

nicht auf (siehe Abbildung 3.9): Die Delta-Schicht enth¨

alt hier durch das dynamische Einf¨

ugen

von A23 – abgesehen von dem Aktivit¨

aten-Objekt f¨

ur A23 – nur die neuen Kanten A2→A23

und A23→A3. A2→A3 wird dagegen als aufgehoben markiert. Auf Schemaebene werden beim

Delta-Schicht

InstanzI3

A1 A2 A3

VorlageS1

DatenelementD1

A1 A12 A2

VorlageS1’

DatenelementD1

Migration

Aktivität Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

referenzierte Aktivität

(A2 A23) (A23 A3)

(A2 A3)

A23

A1 A12 A2

DatenelementD1:W3

A23 A3

ta

inaktiv uin Ausführung

beendet

aktiviert Referenz

Abbildung 3.9: Problemlose Migration verzerrter Instanzen bei Realisierung mit Kantenobjekten

Einf¨

ugen von A12 die Kante A1→A2 komplett entfernt und daf¨

ur A1→A12 und A12→A2 ein-

gef¨

ugt. Zu Bearbeitung der obigen Anfrage holt sich die Delta-Schicht erst alle Kanten mit A2

als Ziel von der Prozessvorlage. Das Vorlagen-Objekt gibt in diesem Beispiel nur A12→A2 an

die Delta-Schicht zur¨

uck. Da die Kante in der Delta-Schicht nicht als gel¨

oscht markiert ist und

dort keine weiteren Kanten mit A2 als Ziel vermerkt sind, liefert die Delta-Schicht schließlich

A12 als die Vorg¨

angeraktivit¨

at von A2.

Uberlappen sich jedoch Schema- und Instanz¨

anderungen, so m¨

ussen andere Migrationsstrategien

angewendet werden [Ri04]. Diese werden im folgenden beschrieben.

5Disjunkte ¨

Anderungen sind kommutativ (vgl. [Ri04])

42 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

3.6.2 Migration bei ¨

aquivalenten ¨

Anderungsoperationen

Wie in Kapitel 2.3.2 angedeutet, d¨

urfen bei einer gegebenen Ausf¨

uhrungs¨

aquivalenz von modifi-

ziertem Instanzschema und neuer Schemaversion – auf logischer Ebene – die Schema¨

anderungen

nicht auf das Laufzeitschema der verzerrten Instanz angewendet werden, da die dynamische

Anderung der Instanz die Schema¨

anderungen bereits vorweggenommen hat. ¨

Ubertragen auf die

vorgestellte Architektur w¨

urde das bedeuten, dass keine ¨

Anderungen an der internen Repr¨

asen-

tation dieser Instanz vorzunehmen sind.

Dann w¨

urde die Instanz aber auch nach der Migration noch indirekt ¨

uber das Delta-Schicht-

Objekt das Vorlagen-Objekt der alten Version Sreferenzieren, anstatt das der neuen Version

S0. Die Instanz bes¨

aße demnach (faktisch) den falschen Typ S.

Aufgrund der Ausf¨

uhrungs¨

aquivalenz der gegen¨

uber der alten Version der Schemavorlage ver-

zerrten Instanz und der neuen Schemaversion kann die Instanz als unverzerrt gegen¨

uber der

neuen Version betrachtet werden. F¨

ur das Laufzeitschema der Instanz gilt n¨

amlich: S0

I=SI+

∆SI≡trace S+ ∆S=S0. Die richtige Migrationsstrategie f¨

ur ausf¨

uhrungs¨

aquivalente verzerrte

Instanzen ist es deshalb, das Delta-Schicht-Objekt zu verwerfen und direkt das Vorlagen-Objekt,

das die neue Version repr¨

asentiert, zu referenzieren. Damit wird zum einen ausgedr¨

uckt, dass

die Instanz nun von dem neuen Typ S0ist, und zweitens, dass die Instanz gegen¨

uber dem neuen

Typ nicht mehr verzerrt ist.

3.6.3 Migration bei subsumptions-¨

aquivalenten ¨

Anderungsoperationen

Ist die Instanz-¨

Anderung ∆SIsubsumptions-¨

aquivalent zu den Typ-¨

Anderungen ∆S, d. h.

∆SI≺∆S, so kann die gleiche Strategie angewendet werden, wie im Falle der ¨

Aquivalenz.

Mit dem Umh¨

angen auf die neue Version S0werden n¨

amlich implizit die in ∆SIgegen¨

uber ∆S

fehlenden ¨

Anderungen ∆S\∆SInachgeholt. Die Instanz ist gegen¨

uber der neuen Version S0

wiederum unverzerrt.

Gilt jedoch ∆SIÂ∆S, so wird auch das urspr¨

ungliche Delta-Schicht-Objekt der Instanz ver-

worfen und das neue Vorlagen-Objekt referenziert. Da aber ∆SImehr ¨

Anderungen am Laufzeit-

schema der Instanz vornimmt als die Schema¨

anderungen ∆S, ist die Instanz nach der Migration

noch gegen¨

uber der neuen Schemaversion S0verzerrt und zwar mit dem Bias ∆S0

I= (∆SI\∆S):

SI∗0=SI+∆S+(∆SI\∆S)≡trace S+∆S+(∆SI\∆S) = S0+(∆SI\∆S) = S0+∆S0

I. Deshalb

muss noch zwischen Instanz-Objekt und dem Vorlagen-Objekt der neuen Version S0ein leeres

Delta-Schicht-Objekt eingef¨

ugt und darauf die ¨

Anderungen ∆S0

I= (∆SI\∆S) angewendet

werden. (∆SI\∆S) muss dynamisch w¨

ahrend der dritten Phase des Migrationsprozesses (siehe

2.3.5) aus den beiden ¨

Anderungshistorien berechnet werden. [Ri04] stellt effiziente Algorithmen

daf¨

ur vor.

3.7. DELTA-SCHICHT UND ANDERE PROZESS-MODELLE 43

3.6.4 Migration bei partiell ¨

aquivalenten ¨

Anderungensoperationen

Bei partiell ¨

aquivalenten ¨

Anderungsoperationen ist die Instanz nach der Migration ebenfalls

gegen¨

uber der neuen Version S0verzerrt. Das neue Delta-Schicht-Objekt muss die Abweichung

∆S0

Ider migrierten Instanz gegen¨

uber der neuen Version der Vorlage S’ repr¨

asentieren, so dass

gilt: SI∗0=S0+ ∆S0

Wie in der Theorie zur Migration von verzerrten Instanzen in Abschnitt 2.3.2 angedeutet, kann

die Abweichung ∆S0

Ioft nur mithilfe der Benutzer oder anhand von im System hinterlegten

Regeln bestimmt werden.

Dynamische Datenfluss-¨

Anderungen einer Instanz werden auf gleiche Art und Weise verwal-

tet: Die Delta-Schicht speichert die ¨

Anderungen gegen¨

uber dem in dem Prozessvorlagen-Objekt

vorgegebenen Datenfluss. Zugriffe auf Elemente des Datenflusses erfolgen dann, wie f¨

ur Kon-

trollflusselemente skizziert. Die Migration l¨

auft gleich ab.

3.7 Delta-Schicht und andere Prozess-Modelle

Der Delta-Schicht-Ansatz zur Repr¨

asentation der Abweichung eines Instanzschemas gegen¨

uber

der Vorlage und der vorgestellte Migrationsablauf k¨

onnen prinzipiell uneingeschr¨

ankt auf andere

Prozess-Modelle ¨

ubertragen werden.

Wenn aber wie in ADEPT nur Instanzen migriert werden d¨

urfen, bei denen die ¨

Anderungen

mit dem bisherigen Prozessablauf vereinbar sind, m¨

ussen Informationen sowohl ¨

uber den mo-

mentanen Ausf¨

uhrungsstand als auch ¨

uber den bisherigen Verlauf vorliegen. Damit ist die ¨

Uber-

tragung nur auf Prozess-Modelle sinnvoll, die entsprechende Informationen z. B. in Form einer

Ausf¨

uhrungshistorie bereitstellen (siehe z. B. [RRD04]).

Abbildung 3.10 gibt ein Beispiel, wie eine Abweichung des Instanzschemas gegen¨

uber des Vor-

lagenschemas bei Ein-Marken-Petri-Netzen (siehe [RD02, S. 3-14 ff.]) mithilfe der Delta-Schicht

repr¨

asentiert werden kann: Bei der Instanz I1 ist gegen¨

uber der Vorlage S die Transition T3

alternativ zwischen Stelle S1 und S2 eingef¨

ugt worden, indem der zu ¨

andernde Teilgraph, hier

begrenzt durch S1 und S2, in die Delta-Schicht kopiert und darin die neue Transition T3 ein-

gef¨

ugt wurde. Die Frage, welche Transitionen schalten k¨

onnen, wenn die Stelle S1 besetzt ist,

wird dann von der Delta-Schicht mit T1 und alternativ T3 beantwortet. Dieselbe Frage beant-

wortet das Vorlagen-Objekt f¨

ur Instanz I2 nur mit T1.

3.8 Proof-Of-Concept-Prototype

F¨

ur die Konzeptvalidierung haben wir im Rahmen eines Praktikums (siehe [BGL03]) und dieser

Diplomarbeit einen Prototypen eines einfachen adaptiven Prozess-Management-Systems, den

Demonstrator, entwickelt. Er erm¨

oglicht es, Prozessvorlagen anzulegen und darauf basierende

44 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

VorlageS

InstanzI2

S1: S2:

S3:

S1:

Delta-Schicht

S3:

InstanzI1

S1 S2 S3

T1 T2

S1 S2

T1 T2

S2: S2

ta

T1 T2

ta

SfreieStelle belegteStelle

Transition

referenzierte

Transition

Kante Objektreferenz

Abbildung 3.10: Die Delta-Schicht bei Petri-Netzen

Instanzen zu starten. Die Instanzen k¨

onnen dann zur Laufzeit dynamisch gegen¨

uber ihrer Vor-

lage abge¨

andert werden. Bei der an eine Schemaevolution anschließenden Migration der auf dem

abge¨

anderten Schema basierenden Instanzen werden auch die verzerrten Instanzen ber¨

ucksich-

tigt. Sie werden abh¨

angig vom ¨

Uberlappungsgrad der Instanz- und Schema¨

anderungen an die

neue Version des Schemas angepasst. Vor einer Migration einer Instanz ¨

uberpr¨

uft der Demon-

strator, ob die Instanz ¨

uberhaupt vertr¨

aglich mit der Schema¨

anderungen ist. Liegt eine verzerrte

Instanz vor, pr¨

uft er zus¨

atzlich, ob es durch die Anpassung an die neue Vorlagenversion nicht

zu inkorrekten Kontroll- und Datenfl¨

ussen kommt. Im Falle von Unvertr¨

aglichkeit oder von

strukturellen Problemen weist er die Instanz von der Migration zur¨

uck.

Anhang B demonstriert anhand einiger Screenshots die F¨

ahigkeiten des Demonstrators.

Wir haben in der Proof-Of-Concept-Implementierung die Instanzen entsprechend der Abbildung

3.5 intern abgebildet und den Migrationsvorgang, wie f¨

ur Implementierungen ohne Kanten-

objekte beschrieben, realisiert. Abbildung 3.11 zeigt den entsprechenden Ausschnitt aus dem

Klassendiagramm des Prototypen.

Instanzen werden im Prototyp durch ein Instance-Objekt repr¨

asentiert. Es enth¨

alt keine Sche-

mainformationen, sondern nur Informationen ¨

uber den Laufzeitzustand der Instanz und indirekt

die Datenwerte. Das Laufzeitschema der Instanz wird im unverzerrten Fall durch das referenzier-

3.8. PROOF-OF-CONCEPT-PROTOTYPE 45

Template

<<Interface>>

TemplateVersion

ModifiedTemplate

Instance

{XOR}

* 1

-templateVersion

-originalTemplateVersion

{XOR}

ModifiedDataContext

1 1

DataContextImplementation

1 1

*{XOR}

-originalDataContext

-dataContext

<<Interface>>

DataContext

DataContextInstance

1 1

{XOR}

1-dataContext

-dataContext

-dataContextInstance

+getDirectPred_byCtrl(ID)

Abbildung 3.11: Repr¨

asentation der Prozessinstanzen und -vorlagen beim Demonstrator

te Template-Objekt repr¨

asentiert, im verzerrten Fall durch die Kombination Template-Objekt

und ModifiedTemplate-Objekte.

Das Template-Objekt korrespondiert mit dem Vorlagen-Objekt aus diesem Kapitel und be-

stimmt sowohl den Prozesstyp einer Instanz als auch das Schema, nachdem die Instanzen

dieses Prozesstyps im Allgemeinen ablaufen. Wie in der Theorie geschildert, referenzieren al-

le Instanzen desselben Prozesstyps – direkt oder indirekt – dasselbe Template-Objekt. Ein

ModifiedTemplate entspricht der Delta-Schicht. Es speichert die ge¨

anderten Abschnitte des

Prozessgraphen. Wie in diesem Kapitel gefordert, weist das ModifiedTemplate-Objekt die glei-

che Schnittstelle auf wie das Vorlagen-Objekt Template: Beide implementieren das Interface

TemplateVersion. Dadurch wird der Zugriff auf diese beiden Objekte transparent.

Jedes ModifiedTemplate referenziert entweder das typ-bestimmende Template-Objekt oder

wiederum ein ModifiedTemplate-Objekt im Falle ¨

ubereinander gestapelter Delta-Schichten6.

Kann die Delta-Schicht die an sie gerichtete Frage, wie z. B. ”Gib mir alle direkten Vorg¨

angerakti-

vit¨

aten der Aktivit¨

at mit der ID inID“, nicht beantworten, delegiert sie die Frage an das referen-

zierte, die Rolle ”originalTemplateVersion“ innehabende Template- oder ModifiedTemplate-

Objekt weiter, wie das Code-Beispiel 3.1 demonstriert:

Code 3.1 (Methode getDirectPred byCtrl(Integer inID) von ModifiedTemplate)

public ActivityList getDirectPred_byCtrl(Integer inID){

6Das Stapeln mehrerer Delta-Schichten wird momentan im Prototyp noch nicht verwendet. Die Architektur

ist daf¨

ur aber ausgelegt.

46 KAPITEL 3. REALISIERUNG VON PROZESSVORLAGEN UND -INSTANZEN

//Are there any information about the activity with ID inID

//in the delta-layer?

Activity currActivity = (Activity) activityID2ActivityMap.get(inID);

if (currActivity!=null){

//There are information about the activity with ID inID

//in the delta-layer.

//So answer the question with this information.

return currActivity.getCtrlPred(); //answer the question

}

else{

//There are no information about activity with ID inID

//in the delta-layer, so delegate the question

//to the original template, that is modified by this delta-layer.

return originalTemplateVersion.getDirectPred_byCtrl(inID);

}

Das Code-Beispiel gibt – aus ¨

Ubersichtsgr¨

unden in etwas vereinfachter Form – die Methode

getDirectPred byCtrl(Integer inID) von ModifiedTemplate wieder, die als Antwort eine

Liste mit den IDs aller Aktivit¨

aten zur¨

uckliefert, welche im Kontrollfluss direkte Vorg¨

anger der

Aktivit¨

at mit der ID inID sind.

Zuerst wird mit dem Aufruf activityID2ActivityMap.get(inID) ¨

uberpr¨

uft, ob die betroffe-

ne Aktivit¨

at im Rahmen einer Ad-hoc-Modifikation f¨

ur eine Anpassung in die Delta-Schicht

kopiert wurde. Ist dies der Fall, so ist der R¨

uckgabewert eine Referenz auf das zur Aktivit¨

mit der ID inID geh¨

orige Aktivit¨

aten-Objekt. Mit dem Aufruf der Methode getCtrlPred()

des entsprechenden Activity-Objekts bekommt man dann die aktuell g¨

ultige Liste mit den

IDs der Vorg¨

angeraktivit¨

aten. Wurde die Aktivit¨

at im Rahmen der Ad-hoc-Modifikation jedoch

nicht ge¨

andert, so liefert der Methodenaufruf activityID2ActivityMap.get(inID) eine null-

Referenz zur¨

uck. In diesem Fall kann nur das durch diese Delta-Schicht abge¨

anderte Schema die

Antwort geben. Somit wird die Anfrage delegiert.

Der Datenfluss wird analog zum Kontrollfluss gehandhabt. Das zum Template-Objekt geh¨

oren-

de DataContextImplemention-Objekt dient als Vorlage f¨

ur den Datenfluss einer Instanz des

durch das Template-Objekt festgelegten Prozesstyps. Der Datenfluss gibt vor, welche Daten

von welchen Aktivit¨

aten geschrieben und von welchen Aktivit¨

aten wieder gelesen werden. Das

ModifiedDataContext-Objekt repr¨

asentiert analog zum ModifiedTemplate f¨

ur eine Instanz die

im Rahmen einer dynamischen ¨

Anderung entstandenen Abweichungen des Datenflusses von der

3.9. ZUSAMMENFASSUNG UND AUSBLICK 47

Vorlage. Bei einer verzerrten Instanz erfolgen Zugriffe auf den Datenfluss dann zuerst ¨

uber das

ModifiedDataContext-Objekt. Analog zum ModifiedTemplate delegiert es Anfragen zur Be-

antwortung, wenn die Anfragen Teile des Datenflusses betreffen, die nicht ge¨

andert wurden.

Das zum Instance-Objekt geh¨

orende DataContextInstance-Objekt schließlich speichert die

instanzspezifischen, von Aktivit¨

aten geschriebenen Datenwerte.

3.9 Zusammenfassung und Ausblick

Mit dem skizzierten Ansatz liegt eine ¨

ubersichtliche interne Repr¨

asentation von Prozessvorla-

gen und Instanzen vor, mit der sich die Migration von unver¨

anderten und sogar dynamisch

abge¨

anderten Instanzen einfach realisieren l¨

asst. Der Migrationsvorgang ist schnell und effizient,

da er bei diesem Ansatz meistens nur aus dem Umh¨

angen von Referenzen besteht. Außerdem

ist der Speicherbedarf gegen¨

uber anderen Ans¨

atzen stark reduziert, da auf Wiederverwendung

gesetzt wird – dasselbe Prozess-Vorlagen-Objekt wird z. B. von mehreren Instanzen referenziert

— und da die Delta-Schicht nur abge¨

anderte Abschnitte des Prozessgraphen speichert. Auf-

grund dieser Eigenschaften ist dieser Architekturansatz bestens geeignet f¨

ur einen Einsatz in

Hochleistungs-Prozess-Management-Systemen.

Um weitere Anforderungen zu erf¨

ullen, die ein Einsatz in Produktivsystemen mit sich bringt,

muss die Architektur noch erweitert werden. Es muss unter anderem ein darauf abgestimmtes

Sperren-System entwickelt werden, um den nebenl¨

aufigen Zugriff sowohl auf Prozessvorlagen als

auch auf Instanzen zu koordinieren bzw. zu synchronisieren.

Auch muss untersucht werden, wie eine Migration durchgef¨

uhrt wird, wenn eine Instanz partitio-

niert auf mehreren Servern oder sogar in mehreren Prozess-Management-Systemen abl¨

auft. Die-

se Situation kann auftreten, wenn zwei parallel angeordnete Prozessabschnitte an verschiedenen

Firmenstandorten ausgef¨

uhrt werden und es z. B. aufgrund einer schlechten Netzwerkanbindung

untereinander unm¨

oglich ist, den Prozess von einem PMS alleine kontrollieren zu lassen. Wie

sich eine Ad-hoc-Modifikation effizient unter diesen Bedingungen durchf¨

uhren l¨

asst, wird z. B.

in [BRD01] behandelt.

Weiterhin bleibt zu untersuchen, ob durch kleine ¨

Anderungen oder Erweiterungen der Archi-

tektur in Bezug auf Instanzen der Migrationsprozess im Gesamten optimiert werden kann. Das

n¨

achste Kapitel geht dieser Frage nach.

Kapitel 4

Optimierungsans¨

atze

Bei dem in Kapitel 2.3.5 vorgestellten Migrationsablauf durchl¨

auft jede einzelne Instanz alle

f¨

unf bzw. sechs Phasen, je nachdem ob die Instanz unverzerrt oder verzerrt gegen¨

uber der

Prozessvorlage ist. Der Migrationsprozess kann aber noch optimiert werden. Dieses Kapitel stellt

dazu zwei m¨

ogliche Ans¨

atze vor:

1. Instanz-Gruppierung nach Laufzeitzustand (Abschnitt 4.1)

2. Meilenstein-Ansatz (Abschnitt 4.2)

Beide Ans¨

atze versuchen, f¨

ur Instanzen Teile des Migrationsablaufs einzusparen und damit Re-

chenzeit zu gewinnen.

4.1 Instanz-Gruppierung nach Laufzeitzustand

Existieren in der Menge der zu migrierenden Instanzen einige Instanzen, die sich weder im

Laufzeitschema noch im Ausf¨

uhrungszustand unterscheiden, so muss die Vertr¨

aglichkeitspr¨

ufung

nur f¨

ur eine dieser Instanzen ausgef¨

uhrt werden. Das Ergebnis kann dann uneingeschr¨

ankt auf die

anderen Instanzen ¨

ubertragen werden. Liefert der Test, dass die ¨

uberpr¨

ufte Instanz vertr¨

aglich

ist, so sind auch alle anderen bez¨

uglich Laufzeitschema und Ausf¨

uhrungszustand ¨

aquivalenten

Instanzen vertr¨

aglich. Gleiches gilt bei Unvertr¨

aglichkeit. Es k¨

onnen somit unter Umst¨

anden

etliche Vertr¨

aglichkeitspr¨

ufungen eingespart werden:

Gegeben sei ein Prozess Ssequ, bei dem n=50 Aktivit¨

aten sequentiell hintereinander angeordnet

sind. Nimmt man an, dass nur die Zust¨

ande “INAKTIV”, “AKTIVIERT”, “IN AUSF¨

UHRUNG”

und “BEENDET” existieren, so kommt es bei diesem Prozess h¨

ochstens zu #(Ssequ,50) = 101

verschiedenen Laufzeitzust¨

anden1. Liegen ausschließlich unverzerrte Instanzen vor, so m¨

ussen

1Zur Berechnung von #(Ssequ,50) siehe Anhang A

4.1. INSTANZ-GRUPPIERUNG NACH LAUFZEITZUSTAND 49

bei Anwendung des Gruppierungsansatzes nur maximal 101 Vertr¨

aglichkeitspr¨

ufungen bei einer

Migration durchgef¨

uhrt werden, egal wie viele Instanzen dieses Prozesstyps existieren. Befinden

sich momentan z. B. 10100 Instanzen des Prozesses in Ausf¨

uhrung, so reduziert sich der Aufwand

f¨

ur die Vertr¨

aglichkeitspr¨

ufung um den Faktor 100 gegen¨

uber der Variante, bei der alle Instanzen

einzeln auf Vertr¨

aglichkeit gepr¨

uft werden.

Die Aussage, dass die Vertr¨

aglichkeitspr¨

ufung nur f¨

ur eine Instanz der Gruppe durchgef¨

uhrt

werden muss und dass sich dann das Ergebnis auf die anderen Instanzen der Gruppe ¨

ubertra-

gen l¨

asst, gilt nicht generell, wenn eine oder mehrere Sync-Kanten im Rahmen der Migration

einzuf¨

ugen sind. Dann kann eine Gruppe n¨

amlich aus unvertr¨

aglichen und vertr¨

aglichen Instan-

zen bestehen, da die Vertr¨

aglichkeit einer Sync-Kanten-Einf¨

uge-Operation nicht immer nur vom

Zustand abh¨

angt, sondern in manchen F¨

allen auch davon, wann die Quell- und Zielaktivit¨

aten

der neuen Sync-Kanten gestartet bzw. beendet wurden: Eine Sync-Kanten-Einf¨

uge-Operation

kann auf eine Instanz angewendet werden, wenn die Zielaktivit¨

at entweder noch nicht gestartet

wurde, die Quellaktivit¨

at in einem abgew¨

ahlten Zweig eines XOR-Blocks liegt und damit den

Zustand ”ABGEW¨

AHLT“ besitzt, oder wenn der Startzeitpunkt der Zielaktivit¨

at sp¨

ater liegt

als der Endzeitpunkt der Quellaktivit¨

at [RRD02].

Wird z. B. nur die Sync-Kante X→Yeingef¨

ugt, dann m¨

ussen alle Instanzen gesondert auf

Vertr¨

aglichkeit gepr¨

uft werden, die einen der Zust¨

ande aufweisen, bei denen die Quellaktivit¨

at X

bereits beendet ist und die Zielaktivit¨

at Y sich entweder in Ausf¨

uhrung befindet oder ebenfalls

bereits beendet ist. Die Instanzen, bei denen X nach dem Ende von Y gestartet wurde, sind

vertr¨

aglich und k¨

onnen migriert werden, alle anderen sind unvertr¨

aglich und m¨

ussen von der

Migration ausgeschlossen werden. Die Informationen ¨

uber die Start- und Endzeitpunkte von

Aktivit¨

aten sind in der Ausf¨

uhrungshistorie hinterlegt.

Ahnlich verh¨

alt es sich, wenn Datenelementen gel¨

oscht werden. F¨

ur die Vertr¨

aglichkeitspr¨

ufung

muss u. U. ein Zugriff auf die Datenhistorie einer Instanz erfolgen [RRD02].

Aber nicht nur durch die Reduzierung der aufw¨

andigen Vertr¨

aglichkeitspr¨

ufungen lassen sich

theoretisch Optimierungen erzielen, sondern auch durch das gemeinsame ¨

Andern der Markie-

rungszust¨

ande f¨

ur diese Instanzen: Unterscheiden sich die Instanzen weder im Laufzeitschema

noch im Ausf¨

uhrungszustand, so muss nur einmal die Menge der Aktivit¨

aten bestimmt werden,

deren Zust¨

ande angepasst werden m¨

ussen. Bei den anderen Instanzen k¨

onnen diese Informatio-

nen wieder verwendet werden, es m¨

ussen nur die bereits ermittelten Anpassungen durchgef¨

uhrt

werden. Durch entsprechende Implementierungen ist es sogar m¨

oglich, f¨

ur alle Instanzen die

Markierungen zugleich anzupassen (siehe unten).

Um diese Optimierungsstrategien anwenden zu k¨

onnen, muss die in Kapitel 3 vorgestellte Archi-

tektur erweitert werden. Sie muss dahingehend modifiziert werden, dass Instanzen nach ihrem

Laufzeitzustand gruppiert werden k¨

onnen. Um der Forderung nach gleichem Laufzeitschema

nachzukommen, beschr¨

anken wir die Betrachtungen auf unverzerrte Instanzen und behandeln

verzerrte Instanzen wie bisher geschildert. Die Forderung nach gleichen Laufzeitschemata ist bei

allen gegen¨

uber der Vorlage unverzerrten Instanzen erf¨

ullt, da deren Laufzeitschemata ¨

aquivalent

zu der Vorlage sind.

50 KAPITEL 4. OPTIMIERUNGSANS ¨

ATZE

Da alle Instanzen einer Gruppe denselben Laufzeitzustand aufweisen, ist es vom Gesichtspunkt

des Speicherbedarfs her sinnvoll, die Informationen ¨

uber den Zustand der einzelnen Aktivit¨

aten

nicht in jeder Instanz redundant abzuspeichern, sondern nur einmal pro Gruppe innerhalb ei-

nes Zustandobjektes. Eine Instanz befindet sich dann in einem bestimmten Zustand, wenn sie

das entsprechende Zustandsobjekt referenziert. Alle Instanzen, die das gleiche Zustandsobjekt

referenzieren, bilden zusammen eine Gruppe. Abbildung 4.1 demonstriert diesen Sachverhalt.

InstanzI6

DatenelementD1:W6

InstanzI5

DatenelementD1:W5

InstanzI4

DatenelementD1:W4

InstanzI2

DatenelementD1:W2

VorlageS1

inaktiv uin Ausführung

beendet

aktiviert

Aktivität

Referenz

Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

InstanzI1

DatenelementD1:W1

A1:

Delta-Schicht

A2:

A3: A23:

Zustandsobjekt102

referenzierte Aktivität

DatenelementD1:W3

InstanzI3

A1: A2:

A3:

Zustandsobjekt3

A1: A2:

A3:

Zustandsobjekt4

bidirektionaleReferenz

A1 A2 A3

DatenelementD1

A2* A23 A3*

Zustandsgruppe3 Zustandsgruppe4

Abbildung 4.1: Architektur mit Zustandsgruppen vor der Migration

Aus Gr¨

unden der Wiederverwendung ist es sinnvoll, f¨

ur die Repr¨

asentation einer dynamisch

ge¨

anderten Instanz statt des aus Kapitel 3 bekannten Instanz-Objekts, das zus¨

atzlich den Zu-

stand speichert, die hier vorgeschlagene Kombination aus Instanz-Objekt und Zustandsobjekt

zu verwenden. Das Zustandsobjekt besitzt dann aber nur die Referenz auf das entsprechende

Instanz-Objekt.

Das Zustandsobjekt erm¨

oglicht es auch, dass alle referenzierten Instanzen bei Vertr¨

aglichkeit auf

einmal auf das neue Schema umgeh¨

angt werden k¨

onnen: Wie Abbildung 4.1 zeigt, referenzie-

ren nicht die Instanz-Objekte das zugrundeliegende Vorlagen-Objekt, sondern nur die jeweiligen

Zustandsobjekte. In der vierten Phase des Migrationsprozesses m¨

ussen dann nur die Zustand-

sobjekte auf das neue Vorlagen-Objekt umgeh¨

angt werden, die einen mit der Schema¨

anderung

vertr¨

aglichen Zustand repr¨

asentieren. Damit werden alle Instanzen der Gruppe gleichzeitig von

4.1. INSTANZ-GRUPPIERUNG NACH LAUFZEITZUSTAND 51

der Version S1 auf die neue Version S10der Vorlage migriert. Gleiches gilt f¨

ur die Instanzanpas-

sung und die Markierungsanpassung: Mit dem Anpassen des entsprechenden Zustandsobjekts

werden – logisch gesehen – alle Instanzen dieser Gruppe auf einmal angepasst.

Abbildung 4.2 zeigt die Repr¨

asentation der Instanzen direkt nach Abschluss des Migrationspro-

zesses.

InstanzI6

DatenelementD1:W6

InstanzI5

DatenelementD1:W5

InstanzI4

DatenelementD1:W4

InstanzI2

DatenelementD1:W2

A1 A2 A3

VorlageS1

DatenelementD1

inaktiv uin Ausführung

beendet

aktiviert

Aktivität

Referenz

Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

InstanzI1

DatenelementD1:W1

A1:

A2* A23 A3*

Delta-Schicht

A12

A2:

A3: A23:

Zustandsobjekt102

referenzierte Aktivität

DatenelementD1:W3

InstanzI3

A1: A2:

A3:

Zustandsobjekt3

A1: A2:

A3:

Zustandsobjekt4

bidirektionaleReferenz

A1 A12 A2

VorlageS1’

DatenelementD1

A12:

Abbildung 4.2: Architektur mit Zustandsgruppen nach einer Migration

Bei dem oben genannten Beispiel mit einem sequentiellen Prozessgraph m¨

ussen dann z. B. nach

dem Einf¨

ugen einer neuen Aktivit¨

at nicht nur maximal 101 Vertr¨

aglichkeitspr¨

ufungen statt

10100 durchgef¨

uhrt werden, sondern auch nur h¨

ochstens 101 Referenzen statt maximal 10100

umgeh¨

angt werden und nur maximal 101 Zust¨

ande angepasst werden. Ebenso reduziert sich der

Speicherverbrauch f¨

ur die Zustandsdaten um das 100-fache, da nicht mehr in allen 10100 Instanz-

Objekten der Zustand einzeln gespeichert wird sondern nur in maximal 101 Zustandsobjekten.

Gerade in Prozessen mit parallelen Ausf¨

uhrungspfaden kommt es aber schnell zur einer Zu-

standsexplosion. Das linke Diagramm aus Abbildung 4.3 verdeutlicht dies. Es tr¨

agt die Anzahl

#(S, 1, x, y, 1) der m¨

oglichen Zust¨

ande bei einem Prozess S mit zwei parallel angeordneten

Pfaden gegen¨

uber der Anzahl x und y der Aktivit¨

aten in den beiden Pfaden ab2.

2Zur Berechnung von #(S, 1, x, y, 1) siehe Anhang A

52 KAPITEL 4. OPTIMIERUNGSANS ¨

ATZE

#(1,x,y,1)

#(S,1,1,1,1)=13

#(S,1,2,2,1)=29

#(S,1,10,11,1)=487

#(S,1,11,10,1)=487

#(S,1,11,11,1)=533

#(S,1,16,19,1)=1291

Anzahl#(S)möglicher

ZuständebeiProzessS:

#(S)=#(S,1,x,y,1)

#(S,1,x,y,1)=#(I)+#(II)*#(III)-1+#(IV)-1

#(S,1,x,y,1)=3+(2x+1)(2y+1)-1+3-1

#(S,1,x,y,1)=4xy+2(x+y)+5

A11 A1x

A21 A2y

IIII

Mehrals500

möglicheZustände

Wenigerals500

möglicheZustände

Mehrals500

möglicheZustände

Wenigerals500

möglicheZustände

Trennebene

Abbildung 4.3: Anzahl #(S, 1, x, y, 1) m¨

oglicher Zust¨

ande bei einem Prozess mit zwei parallel

angeordneten Pfaden in Abh¨

angigkeit von der Anzahl x und y der Aktivit¨

aten in den Pfaden

Die Folge ist, dass bei Prozessen mit parallelen Ausf¨

uhrungspfaden schon bei geringer Akti-

vit¨

atenanzahl die Zahl der m¨

oglichen Zust¨

ande die Zahl der durchschnittlich vorhanden Prozess-

instanzen ¨

ubertreffen kann und damit mehr Zustandsobjekte existieren k¨

onnen als Instanzen,

wenn f¨

ur jeden m¨

oglichen Zustand ein Zustandsobjekt angelegt wird. Das rechte Diagramm aus

Abbbildung 4.3 demonstriert dies. Es gibt f¨

ur jede Kombination (x,y) an, ob damit S mehr (helle

Fl¨

ache) oder weniger (dunkle Fl¨

ache) als 500 Zust¨

ande aufweist und deshalb die angenommene

Zahl der durchschnittlich vorhandenen Instanzen von 500 ¨

uberschreitet oder nicht.

Bei Prozessen der Form S ergeben sich schon mit 11 Aktivit¨

aten pro parallelem Pfad mehr als 500

m¨

ogliche Zust¨

ande: #(S, 1,11,11,1) = 533. Gibt es, wie angenommen, 500 Instanzen von diesem

Prozess, so sind mindestens 33 Zustandsobjekte ohne zugeordnete Instanzen und damit unn¨

otig

angelegt, wenn f¨

ur alle 533 m¨

oglichen Zust¨

ande ein Zustandsobjekt angelegt wurde. Diese Zahl

erh¨

oht sich rapide mit der Zahl der Aktivit¨

aten: Beinhaltet z. B. der Pfad, der als Bereich II

ausgewiesen ist, jetzt 16 seriell angeordnete Aktivit¨

aten und der parallel dazu angeordnete Pfad

19, so berechnet sich die Anzahl #(S, 1,16,19,1)3der m¨

oglichen Zust¨

ande zu 1291. Damit hat

3zu den Parametern: relevantes Schema S, eine Aktivit¨

at in Bereich I, 16 in II, 19 in III und eine in IV

4.1. INSTANZ-GRUPPIERUNG NACH LAUFZEITZUSTAND 53

sich die Zahl der unn¨

otig angelegten Zustandsobjekte auf 791 erh¨

oht, obwohl S nun gerade mal

13 Aktivit¨

aten mehr aufweist.

Um nicht unn¨

otig viel Speicherplatz zu verschwenden, sollten deshalb zu einem Zeitpunkt nur

Zustandsobjekte existieren, denen auch Instanzen zugeordnet sind.

Beim Weiterschalten der Instanz muss dann f¨

ur einige Zust¨

ande erst das entsprechende Zu-

standsobjekt generiert werden. Cachen von Zustandsobjekten, die besonders h¨

aufig angenom-

mene Zust¨

ande repr¨

asentieren, kann den Aufwand daf¨

ur verringern.

Ein Weiterschalten der Instanz erfordert stets mehrere Schritte: Zuerst muss die Instanz aus

der entsprechenden Gruppe entfernt werden. Danach muss das nun relevante Zustandsobjekt

gefunden und referenziert werden. F¨

ur das schnelle Auffinden des neu zu referenzierenden Zu-

standsobjektes bietet sich eine Map an. In einer Map wird zu einem Schl¨

ussel der zugeh¨

orige

Wert gespeichert. Als Schl¨

ussel dient eine Codierung f¨

ur den Zustand. ¨

Uber diese Codierung

kann man dann mithilfe der Map auf das entsprechende Zustandsobjekt zugreifen. Beim Weiter-

schalten der Instanz wird somit zuerst die Codierung des neuen Zustandes berechnet, dann wird

damit das neue Zustandsobjekt herausgesucht. Sollte das Zustandsobjekt nicht existent sein,

so muss es zu diesem Zeitpunkt erzeugt werden. Schließlich wird die Instanz auf das neue Zu-

standsobjekt umgeh¨

angt. Die Codierung des neuen Zustandes sollte einfach aus der Codierung

des alten Zustandes berechnet werden k¨

onnen. Ein Codierung muss nicht unbedingt eindeutig zu

einem Zustand geh¨

oren, d. h. die Abbildung Codierung – Zustand muss nicht bijektiv sein. Bei

einer nicht bijektiven Abbildung k¨

onnen dann auf eine Codierung mehrere Zustandsobjekte fal-

len. Beim Weiterschalten muss dann noch zus¨

atzlich das richtige Zustandsobjekt herausgesucht

werden.

Wird die Aktivit¨

at A2 der Instanz I4 aus Abbildung 4.4 gestartet, so wird zuerst die bidirek-

tionale Referenz vom Zustandsobjekt 3, das den alten Zustand repr¨

asentiert, auf das Instanz-

Objekt I4 aufgel¨

ost. Dann wird die Codierung f¨

ur den neuen Zustand, bei dem A2 als “IN

AUSF¨

UHRUNG” markiert ist, berechnet. In diesem Fall lautet diese Zustandscodierung 4. Da-

mit wird nun schnell ¨

uber die Map auf das richtige Zustandsobjekt zugegriffen, um dort eine

wiederum bidirektionale Referenz auf das Instanz-Objekt I4 zu setzen. I4 befindet sich damit in

dem neuen Zustand, der durch das Zustandobjekt 4 repr¨

asentiert wird.

Zusammenfassend kann man sagen, dass das Umschalten relativ aufw¨

andig ist. Treffen zu einem

Zeitpunkt sehr viele Instanzweiterschaltungen aufeinander, so wirkt sich das negativ auf die

Performance aus.

Hinzu kommt, dass das parallele Umschalten von (vielen) Instanzen zu parallelen Schreib- und

Lesezugriffen auf die vorgestelle Architektur f¨

uhrt (z. B. Austragen von mehreren der bijektiven

Instanzreferenzen aus demselben Zustandsobjekt). Zur Vermeidung von Inkonsistenzen m¨

ussen

Sperren ein isoliertes Schreiben garantieren. Das Warten auf die Freigabe von Sperren kostet

wiederum wertvolle Performance.

54 KAPITEL 4. OPTIMIERUNGSANS ¨

ATZE

A1 A2 A3

VorlageS1

DatenelementD1

InstanzI6

DatenelementD1:W6

InstanzI5

DatenelementD1:W5

InstanzI4

DatenelementD1:W4

InstanzI2

DatenelementD1:W2 InstanzI1

DatenelementD1:W1

A1: A2:

A3:

Zustandsobjekt3

A1: A2:

A3:

Zustandsobjekt4

Umhängen

beim

Weiterschalten

Map

Schlüssel Wert

Xgelöscht

inaktiv uin Ausführung

beendet

aktiviert

Aktivität

Referenz

Datenflusskante DatenelementD1 Datenelement

Konrollflusskante

bidirektionaleReferenz

Abbildung 4.4: Weiterschalten einer Instanz bei einer Architektur mit Zustandsgruppen

4.2 Meilenstein-Ansatz

Ein alternativer Ansatz, Vertr¨

aglichkeitspr¨

ufungen einzusparen, ist der Meilenstein-Ansatz. Da-

bei wird der ganze Prozessgraph in mehrere Abschnitte eingeteilt, wie z. B. in Abbildung 4.5

gezeigt. Gemerkt wird dann, in welchen Abschnitt eine Instanz bereits vorger¨

uckt ist. Dazu

wird f¨

ur jeden Abschnitt eine Liste der Instanzen gespeichert, die den entsprechenden Abschnitt

erreicht, aber noch nicht ¨

uberschritten haben. Beim ¨

Uberschreiten einer Abschnittsgrenze, dem

Meilenstein, wird die Instanz in die Liste des neuen Abschnittes umgeh¨

angt. ¨

Uberschritten ist ein

Meilenstein, sobald eine Aktivit¨

at aus dem von diesem und dem n¨

achsten Meilenstein begrenzten

Prozessabschnitt ausgef¨

uhrt wird.

Vertr¨

aglichkeitspr¨

ufungen k¨

onnen deshalb eingespart werden, da alle Instanzen, die noch nicht in

den ersten von einer ¨

Anderung betroffenen Bereich vorger¨

uckt sind, automatisch als vertr¨

aglich

angenommen werden k¨

onnen. Wurden alle Meilensteine an Stellen im Graph gesetzt, an denen

jeweils nur ein Ausf¨

uhrungspfad und nicht mehrere, parallel oder alternativ angeordnete Pfa-

de existieren, so kann weiterhin gesagt werden, dass alle Instanzen, die den ersten von einer

Anderung betroffenen Abschnitt ¨

uberschritten haben, nicht mehr migrierbar sind, da sie zu weit

4.2. MEILENSTEIN-ANSATZ 55

A111

A121

AufSbasierendeInstanzen

ProzessvorlageS

A611 A612

A621 A622

A7A3 A4 A5

A613

A111

A121

A2 A6

A611 A612

A621 A622

A7A3 A4 A5

A613

M1 M2 M4

A111

A121

A2 A6

A611 A612

A621 A622

A7A3 A4 A5

A613

A111

A121

A2 A6

A611 A612

A621 A622

A7A3 A4 A5

A613

inaktiv

uin Ausführung

beendet

aktiviert

P P P P P

A111

A121

A2 A6

A611 A612

A621 A622

A7A3 A4 A5

A613

P P

Aktivität

Parallel-

verzweigung

Zusammen-

führung

Kontrollflusskante

Sync-Kante

Meilenstein

ZuordnungderInstanzen

zudenMeilensteinen

(M34)

M34

Abbildung 4.5: Architektur mit Meilensteinen

fortgeschritten sind. Es m¨

ussen dann nur noch die Instanzen innerhalb des besagten Abschnittes

auf Vertr¨

aglichkeit gepr¨

uft werden.

Wird z. B. in den Graph Saus Abbildung 4.5 zwischen die Aktivit¨

aten A3 und A4 eine weitere

Aktivit¨

at eingef¨

ugt, so sind alle von M1 referenzierten Instanzen, wie z. B. I1, vertr¨

aglich, alle

ab inklusive M3 referenzierten dagegen unvertr¨

aglich, wie z. B. die Instanz I4. Alle Instanzen,

die M2 aber nicht M3 ¨

uberschritten haben, m¨

ussen einzeln auf Vertr¨

aglichkeit gepr¨

uft werden:

Instanzen, bei denen A4 maximal aktiviert ist, sind vertr¨

aglich, Instanzen bei denen sich A4

bereits in Ausf¨

uhrung befindet oder bei denen A4 schon beendet wurde, sind nicht vertr¨

aglich.

Somit ist die Instanz I2 vertr¨

aglich und I3 unvertr¨

aglich, obwohl beide demselben Meilenstein

M2 zugeordnet sind.

Ohne die Bedingung an die Position der Meilensteine m¨

ussen alle Instanzen, die nicht von vorne

herein als vertr¨

aglich eingestuft werden konnten, der Vertr¨

aglichkeitspr¨

ufung unterzogen werden,

auch wenn sie bereits den ersten abge¨

anderten Prozessabschnitt ¨

uberschritten haben:

Wenn in dem Graph Saus Abbildung 4.5 noch zus¨

atzlich der gestrichelt eingezeichnete Meilen-

stein M34 ber¨

ucksichtigt wird, dann ist die Instanz I4 diesem Meilenstein anstatt dem Meilen-

56 KAPITEL 4. OPTIMIERUNGSANS ¨

ATZE

stein M3 zugeordnet, weil sich bei ihr die Aktivit¨

at A622 bereits in der Ausf¨

uhrung befindet und

die Instanz damit den Bereich zwischen M34 und M4 betreten hat. Wird nun in den dargestell-

ten Prozessgraphen Seine Aktivit¨

at zwischen die Aktivit¨

aten A611 und A612 eingef¨

ugt, so ist

I4 trotzdem noch vom Zustand her mit der ¨

Anderung vertr¨

aglich, obwohl sie bereits den auf den

ge¨

anderten Bereich folgenden Abschnitt des Prozessgraphen erreicht hat. Die Ausf¨

uhrung in dem

Pfad, in dem diese ¨

Anderung ausschließlich stattfindet, ist noch nicht zu weit fortgeschritten,

um die Instanz unvertr¨

aglich mit der ¨

Anderung zu machen. Deshalb gilt ohne die Bedingung

an die Position der Meilensteine nicht, dass alle Instanzen nach dem ersten ge¨

anderten Bereich

nicht mehr vertr¨

aglich sind. Aufgrund dessen m¨

ussen dabei auch die weiter fortgeschrittenen

Instanzen noch auf Vertr¨

aglichkeit gepr¨

uft werden.

Beim Hinzuf¨

ugen von Sync-Kanten m¨

ussen jedoch auch bei der Version mit der Einschr¨

ankung

bez¨

uglich der Positionierung der Meilensteine noch die Instanzen auf Vertr¨

aglichkeit ¨

uberpr¨

uft

werden, die bereits den ersten abge¨

anderten Abschnitt ¨

uberschritten haben. Ist z. B. die neue

Sync-Kante die einzigste Modifikation in diesem Abschnitt, dann kann auch eine Instanz, die

diesen Bereich bereits ¨

uberschritten hat, noch vertr¨

aglich sein, da eine Sync-Kante auch noch

zwischen zwei Aktivit¨

aten X und Y eingef¨

ugt werden kann, wenn sowohl X als auch Y schon

beendet wurden. X muss nur vor dem Start von Y beendet worden sein.

Werden innerhalb einer ¨

Anderungstransaktion Datenelemente gel¨

oscht, so m¨

ussen hierbei bei

beiden Alternativen des Meilenstein-Ansatzes s¨

amtliche Instanzen einzeln auf Vertr¨

aglichkeit

uberpr¨

uft werden, da f¨

ur eine Entscheidung ¨

uber die Vertr¨

aglichkeit nicht nur der Zustand der

Instanz ausschlaggebend ist, sondern auch, ob ¨

uberhaupt auf das Datenelement lesend oder

schreibend zugegriffen wurde (vgl. [RRD02]). Entsprechende Informationen m¨

ussen aus den

Datenhistorien der Instanzen gewonnen werden.

Der Vorteil gegen¨

uber der in Abschnitt 4.1 genannten Methode der Zustandsgruppierung zur

Einsparung von Vertr¨

aglichkeitspr¨

ufungen ist es, dass nicht bei jedem Weiterschalten von In-

stanzen aufw¨

andige Datenstrukturanpassungen notwendig sind, sondern nur, wenn Meilensteine

uberschritten werden.

Trotzdem ist auch in dem Fall, dass kein Meilenstein ¨

uberschritten wurde, das Weiterschalten

gegen¨

uber einem Weiterschalten in einer Umgebung verz¨

ogert, bei der keine der hier vorge-

stellten Optimierungsans¨

atze f¨

ur den Migrationsprozess zur Anwendung kommt, da bei jedem

Weiterschalten ¨

uberpr¨

uft werden muss, ob ein Meilenstein ¨

uberschritten wurde.

Von Nachteil ist, dass es bei diesem Ansatz nicht mehr m¨

oglich ist, erstens mehrere Instanzen auf

einmal auf eine neue Version der Prozessvorlage umzuh¨

angen, zweitens die Instanzanpassung f¨

mehrere Instanzen auf einmal vorzunehmen und drittens die nach einer Migration erforderlichen

Markierungsanpassungen auf einmal f¨

ur mehrere Instanzen durchzuf¨

uhren.

4.3. ZUSAMMENFASSUNG UND ALTERNATIVEN 57

4.3 Zusammenfassung und Alternativen

Vergleicht man die beiden Varianten miteinander, dann kann gesagt werden, dass das Weiter-

schalten einer Instanz bei der Meilenstein-Methode gegen¨

uber der zuvor vorgestellen Optimie-

rungsvariante mit der Gruppierung der Instanzen nach dem Laufzeitzustand beschleunigt ist.

Daf¨

ur m¨

ussen allerdings bei der Meilenstein-Methode auch Geschwindigkeitseinbußen bei der

Migration gegen¨

uber der anderen Variante in Kauf genommen werden.

Generell muss abgew¨

agt werden, ob eine beschleunigte Migration ein verz¨

ogertes Weiterschal-

ten von Instanzen ¨

uberhaupt rechtfertigt und ob damit die Optimierungsstrategien ¨

uberhaupt

angewendet werden sollen. Das Weiterschalten von Instanzen z¨

ahlt zu den am h¨

aufigsten auf-

zutretenden Ereignissen bei Prozess-Management-Systemen. In großen PMS-Systemen m¨

ussen

eventuell zu einem Zeitpunkt tausende von Aktivit¨

aten weitergeschaltet werden. Es geh¨

ort des-

halb besonders effizient implementiert. Die Migration von Instanzen kommt verglichen dazu

relativ selten vor.

Eine sinnvolle Alternative ist es, die Architektur aus Kapitel 3 beizubehalten und die Migration

auf konventionelle Weise durchzuf¨

uhren, aber die Migration von Instanzen, auf die momentan

nicht zugegriffen wird, in Tagesbereiche, z. B. Nacht, zu verlegen, in denen verh¨

altnism¨

aßig

wenig anderweitige Zugriffe auf das Prozess-Management-System stattfinden. Instanzen, bei

denen ein Zustandwechsel anliegt, m¨

ussen im Falle der Vertr¨

aglichkeit allerdings sofort auf das

neue Schema angepasst werden, damit sie gleich nach den neuen Vorgaben ablaufen k¨

onnen.

Eine verz¨

ogerte Migration (engl.: lazy migration) ist auch aus Sicht der Speicherverwaltung sinn-

voll. F¨

ur die Migration muss die Instanz im Hauptspeicher vorliegen. Wurde auf eine Instanz

schon lange nicht mehr zugegriffen, so ist die Wahrscheinlichkeit hoch, dass sie im Rahmen der

Speicherverwaltung auf den Hintergrundspeicher ausgelagert wurde. In diesem Fall muss sie f¨

die Migration zuerst wieder in den Hauptspeicher geladen werden. Daf¨

ur muss aber erst Platz

geschaffen werden. Wird daf¨

ur eine Instanz aus dem Arbeitsspeicher verdr¨

angt, auf die h¨

aufig

zugegeriffen wird, ist die Wahrscheinlichkeit groß, dass sie sofort wieder eingelagert werden muss.

Die zuvor eingelagerte Instanz dagegen wird h¨

ochstwahrscheinlich gleich wieder zur¨

uckgeschrie-

ben, wenn sie in der n¨

achsten Zeit nicht wieder angefasst wird. Die h¨

aufigen Zugriffe auf die

Platte kosten Zeit. Ein Ziel ist es deshalb, unn¨

otige Plattenzugriffe zu vermeiden. Dies kann

erreicht werden, indem eine ausgelagerte Instanz solange von der Migration zur¨

uckgestellt wird,

bis sie z. B. wegen Weiterschalten sowieso eingelagert werden muss.

Kapitel 5

Nebenl¨

aufigkeit

Prozess-Management-Systeme z¨

ahlen zu den Mehrbenutzer-Systemen. Es k¨

onnen u. U. mehrere

hundert Benutzer gleichzeitig angemeldet sein und das PMS in Anspruch nehmen. Die Aktionen,

die sie ausf¨

uhren, k¨

onnen sich ohne weitere Kontrollen durch das System beeinflussen oder sogar

st¨

oren. In einem adaptiven PMS k¨

onnen z. B. mehrere Benutzer versuchen, dieselbe Prozessvor-

lage zur gleichen Zeit anzupassen oder diesselbe Instanz dynamisch abzu¨

andern. H¨

aufiger wird

der Fall auftreten, dass Benutzer Instanzen weiterschalten, die von anderen Benutzern gerade

modifiziert werden oder die auf Vorlagen basieren, die angepasst werden m¨

ussen. Welche Pro-

bleme dabei entstehen und wie sie verhindert werden k¨

onnen, soll in diesem Kapitel untersucht

werden. Konkurrierende Zugriffe einfach zu verbieten, kann u. U. zu restriktiv sein.

Aber nicht nur Benutzeraktionen untereinander, sondern auch Benutzer- und Systemaktionen

k¨

onnen sich beeinflussen. Eine f¨

ur diese Arbeit relevante Systemfunktion ist die Migration, die

mit Ausnahme des Benutzereingriffs bei Konflikten automatisch abl¨

auft. Das Weiterschalten

oder die Modifikationen von in Migration befindlichen Instanzen oder das erneute Ab¨

andern

einer Vorlage, auf die noch immer Instanzen aus einer vorherigen Schemaevolution zu migrieren

sind, sind in diesem Zusammenhang zu untersuchen.

Zusammengefasst m¨

ussen folgende Aktionen in ihren Wechselwirkungen untersucht werden:

1. Vorlagen¨

anderung ↔Vorlagen¨

anderung

2. Vorlagen¨

anderung ↔Weiterschalten

3. Vorlagen¨

anderung ↔Dynamische ¨

Anderungen

4. Dynamische ¨

Anderungen ↔Weiterschalten

5. Dynamische ¨

Anderungen ↔Dynamische ¨

Anderungen

6. Migration ↔Weiterschalten

5.1. VORLAGEN ¨

ANDERUNG ↔VORLAGEN ¨

ANDERUNG 59

7. Migration ↔Vorlagen¨

anderung

8. Migration ↔Dynamische ¨

Anderungen

5.1 Vorlagen¨

anderung ↔Vorlagen¨

anderung

Eine Situation, bei der es zu Konflikten aufgrund von konkurrierenden Zugriffen kommen kann,

liegt vor, wenn zwei oder mehrere Benutzer versuchen, gleichzeitig dieselbe Vorlage zu ¨

andern.

Die Konflikte, die auftreten k¨

onnen, entsprechen den in Kapitel 2.3.2 beschriebenen auftret-

baren Konflikten zwischen Instanz- und Vorlagen¨

anderungen: Die Benutzer k¨

onnen sich wider-

sprechende Modifikationen an der Vorlage vornehmen, sie k¨

onnen versuchen, an dieselbe Stelle

unterschiedliche Aktivit¨

aten einzuf¨

ugen oder sie k¨

onnen ¨

Anderungen durchf¨

uhren, die f¨

ur sich

genommen zwar zu einem wiederum korrekten Schema f¨

uhren, zusammen aber ein inkorrektes

Schema ergeben, wie es z. B. in Zusammenhang mit dem Einf¨

ugen von Sync-Kanten vorkommen

kann.

Ziel ist es deshalb, dass Konflikte aufgrund von ¨

uberlappenden ¨

Anderungen vermieden oder

aufgel¨

ost werden.

Dieses Ziel kann durch unterschiedliche Verfahren erreicht werden. M¨

ogliche Verfahren sind:

•Exklusivzugriff

•Best¨

atigung einer ¨

Anderung durch den Server

•Sperren

•Optimistisches Verfahren

Diese werden im Folgenden erl¨

autert.

Exklusivzugriff

Die intuitivste und einfachste L¨

osungsstrategie zum Erreichen des Ziels ist es, das gleichzeitige

Ab¨

andern ein und derselben Vorlage durch mehrere Benutzer v¨

ollig zu unterbinden, d. h. dem

Benutzer, der zuerst die ¨

Anderung der Vorlage beim Server beantragt, Exklusivzugriff in Bezug

auf ¨

Anderungen zu gew¨

ahren. Der Ablauf der Vorlagen¨

anderung entspricht dem in Kapitel 2.1.2

uber das Konzept der Schemaevolution beschriebenen Ablauf.

Der Vorteil eines Exklusivzugriffes liegt darin, dass keine zus¨

atzlichen Datenstrukturen oder

aufw¨

andige Verfahren notwendig sind, um Konflikte zu verhindern oder aufzul¨

osen, da auf-

grund des Exklusivzugriffes keine diesbez¨

uglichen Konflikte auftreten k¨

onnen. Weiter besteht

f¨

ur den Benutzer die M¨

oglichkeit, die ¨

Anderungen offline vorzunehmen, wenn er bei Beginn der

60 KAPITEL 5. NEBENL ¨

AUFIGKEIT

Anderungstransaktion die Kopie der Vorlage auf seinen Rechner ¨

uberspielt bekommt. Er kann

diese dann ohne st¨

andigen Kontakt zum Server entsprechend seiner W¨

unsche anpassen. Bei

Commit wird die angepasste Kopie dann zur¨

uck an den Server geschickt und als neue Version

der Prozessvorlage ins PMS ¨

ubernommen. Oder es werden nur die angewendeten Operationen

dem Server mitgeteilt, die der Server dann auf seiner Kopie des Vorlagen-Objekts anwendet.

Dieses Vorlagen-Objekt repr¨

asentiert schließlich die neue Version der Prozessvorlage. Bis nach

Abschluss der Commit-Prozedur bleibt es den anderen Benutzer versagt, dieselbe Vorlage zu

andern.

Dieses Verfahren kann aber zu restriktiv sein, besonders in der Entwicklungszeit, wenn mehrere

Personen an der Gestaltung des Gesch¨

aftsprozesses beteiligt sind und h¨

aufig eventuell lang an-

dauernde Erweiterungen des bestehenden Schemas vornehmen m¨

ussen. Die Arbeit zur¨

uckzustel-

len bis der Kollege seine Modellierungen abgeschlossen hat, ist im Allgemeinen nicht tragf¨

ahig.

Werden keine weiteren Vorsichtsmaßnahmen getroffen, wie z. B. ein Zeitlimit f¨

ur den Exklusiv-

zugriff, dann kann es zu unn¨

otigen Blockaden aufgrund nicht freigegebener Vorlagen kommen,

z. B. wenn der Benutzer zwar mit den ¨

Anderungen fertig ist, aber mit dem Einspielen noch

wartet, oder die ¨

Anderungen verwirft, ohne das System davon zu benachrichtigen, oder wenn

aufgrund von Kommunikationsproblemen das Zur¨

uckspielen auf den Server nicht erfolgen kann.

Die im folgenden genannten Verfahren zur Verhinderung oder Vermeidung von Konflikten er-

m¨

oglichen das gleichzeitige – aber eventuell eingeschr¨

ankte – Ab¨

andern eines Schemas durch

mehrere Benutzer, sorgen aber daf¨

ur, dass das oben genannte Ziel trotzdem erf¨

ullt wird.

Best¨

atigung einer ¨

Anderung durch den Server

Eine M¨

oglichkeit, paralleles Ab¨

andern einer Vorlage zu gew¨

ahren, ohne aber Konflikte aufkom-

men zu lassen, besteht darin, den Server ¨

uber die Anwendung einer jeden ¨

Anderungsoperation

entscheiden zu lassen. Dabei schickt jeder Benutzer seine ¨

Anderungsw¨

unsche an den Server. Die-

ser nimmt sie in der Reihenfolge entgegen, wie sie bei ihm eintreffen, und untersucht f¨

ur jeden

einzelnen Wunsch, ob er erf¨

ullt werden kann, d. h. ob er nicht mit den ¨

Anderungsw¨

unschen an-

derer kollidiert. Kann dem Wunsch entsprochen werden, so f¨

uhrt er die entsprechende Operation

auf der Kopie der Vorlage aus. Zus¨

atzlich schickt er an alle f¨

ur die Anpassung der betroffenen

Vorlage registrierten Clients eine Best¨

atigung ¨

uber die Anwendung dieser Operation. Auf diese

Weise erf¨

ahrt der Client, der die entsprechende ¨

Anderungsoperation durchf¨

uhren wollte, dass

sie angenommen wurde. Alle anderen Clients werden dadurch st¨

andig ¨

uber die bereits erfolgten

Anderungen der anderen auf dem Laufenden gehalten und k¨

onnen entsprechend ihre Darstellung

aktualisieren. Kann die Operation aufgrund von Konflikten nicht angewendet werden, so muss

nur der Absender davon unterrichtet werden. Er kann dann den Benutzer mit einem entspre-

chenden Hinweis informieren, welche Operation abgelehnt wurde und warum.

Client 1 aus Abbildung 5.1 m¨

ochte in den dargestellten Prozessgraph die Sync-Kante A12 →A21

einf¨

ugen. Dazu stellt er eine entsprechende Anfrage an den Server. Dieser ¨

uberpr¨

uft, ob das

Einf¨

ugen der Sync-Kante in das Schema Konflikte verursachen w¨

urde. Da dies nicht der Fall ist,

5.1. VORLAGEN ¨

ANDERUNG ↔VORLAGEN ¨

ANDERUNG 61

A11 A12

A21 A22

Server

A11 A12

A21 A22

Server

Anfrage:

insertSync(A12, A21)

Client2

A11 A12

A21 A22

Client2

A11 A12

A21 A22

Client1

A11 A12

A21 A22

Client1

A11 A12

A21 A22

A11 A12

A21 A22

Server

Client1

A11 A12

A21 A22

Client2

A11 A12

A21 A22

Antwort:

insertSync(A12, A21)

Antwort:

insertSync(A12, A21)

Anfrage:

insertSync(A22, A11)

A11 A12

A21 A22

Server

Client1

A11 A12

A21 A22

Client2

A11 A12

A21 A22

Antwort:

insertSync(A22, A11)

Abgelehnt

Anpassung

Zeit t0 t1 t2 t3

Abbildung 5.1: Prinzip der Best¨

atigung einer Vorlagen¨

anderung durch den Server

gibt er an alle Clients, welche am ¨

Andern des Schemas beteiligt sind, eine Best¨

atigungsmeldung

heraus, nachdem er selbst die ¨

Anderung auf seiner Kopie der Vorlage durchgef¨

uhrt hat. Die

Clients passen daraufhin ihre Darstellung entsprechend an. Bevor Client 2 jedoch von der neuen

Sync-Kante erf¨

ahrt, beantragt er die Einf¨

ugung der Sync-Kante A22 →A11. Diese Operation

wird jedoch vom Server abgelehnt, da diese Sync-Kante zusammen mit der zuvor eingef¨

ugten

zu einem Zyklus im Prozessgraphen f¨

uhren w¨

urde.

Ein Vorteil dieses Verfahrens ist neben der M¨

oglichkeit, dass mehrere Benutzer das Schema pa-

rallel ab¨

andern k¨

onnen, dass alle Benutzer auch sofort – sofern keine Best¨

atigung verloren geht –

uber die gemachten ¨

Anderungen der anderen informiert werden. Dieses Verfahren ist auch sehr

gut f¨

ur eine Umgebung geeignet, in denen die Notwendigkeit f¨

ur ”Thin Clients“ besteht: Der

Server ¨

ubernimmt die vollst¨

andige Pr¨

ufung auf Korrektheit des Schemas und auf das Fehlen

von Konflikten aufgrund von ¨

uberlappenden ¨

Anderungen. Der Client muss somit diese Funk-

tionalit¨

at nicht bereitstellen, sondern konzentriert sich ausschließlich auf die Visualisierung des

Prozessgraphen.

Dass der Server s¨

amtliche ¨

Uberpr¨

ufungen durchf¨

uhren muss, kann aber zu Zeiten hoher Last,

oder wenn viele Vorlagen gleichzeitig abge¨

andert werden, zu starken Leistungseinbußen des Sys-

62 KAPITEL 5. NEBENL ¨

AUFIGKEIT

tems f¨

uhren. Ein weiterer Nachteil ist, dass das Versenden von ¨

Anderungsanforderungen und

Anderungsbest¨

atigungen einen erheblichen Kommunikationsaufwand verursacht. In stark bean-

spruchten Netzen oder ¨

uber mehre Teilnetze hinweg kann es dann zu erheblichen Verz¨

ogerungen

kommen. Auch muss der PMS-Server st¨

andig erreichbar sein, um eine Vorlage ab¨

andern zu

k¨

onnen. Es ist bei diesem Verfahren somit nicht m¨

oglich, offline zu arbeiten. Weitere Proble-

me treten auf, wenn Best¨

atigungsmeldungen verloren gehen. Die Clients k¨

onnen dann nicht die

entsprechenden Operationen auf ihrem Schema nachziehen. Es kann dann im folgenden zu Feh-

lern kommen, wenn Best¨

atigungen ¨

uber ¨

Anderungsoperationen eintreffen, die auf der fehlenden

Modifikation beruhen. Auch die Ankunft der Best¨

atigungen in falscher Reihenfolge aufgrund

von unterschiedlich zur¨

uckgelegten Routen der Nachrichten im Netzwerk f¨

uhrt zu diesem Feh-

ler. Der gr¨

oßte Nachteil aber ist, dass das R¨

uckg¨

angigmachen einer schon best¨

atigten ¨

Anderung

sehr aufw¨

andig sein kann, n¨

amlich dann, wenn andere Benutzer bereits anderweitige, darauf

basierende Modifikation ausgef¨

uhrt haben. Somit ist es schwer, ¨

Anderungstransaktionen zu rea-

lisieren, die abgebrochen werden k¨

onnen.

Eine Frage bleibt noch zu kl¨

aren, die in Zusammenhang mit diesem Verfahren auftritt: Wann ist

der Zeitpunkt gekommen, an dem eine neue Version der Vorlage zu existieren beginnt? Der einzig

sinnvolle Zeitpunkt ist dann, wenn alle beteiligten Benutzer ihre Modifikationen abgeschlossen

haben. Dabei besteht allerdings die Gefahr, dass sich die Versionierung lange Zeit hinausz¨

ogert,

erstens wenn immer wieder neue Benutzer die Vorlage anzupassen beabsichtigen und damit den

Abschluss verhindern und zweitens wenn die Modifikationen eines oder mehrerer Benutzer lange

Zeit in Anspruch nehmen. Dem ersten Fall kann begegnet werden, indem die Zahl der Personen

beschr¨

ankt wird, welche die Vorlage ab¨

andern k¨

onnen, ohne dass eine neue Version der Vorlage

zustande kommt. ¨

Uberschreitet die Zahl der ¨

anderungswilligen Personen die festgelegte Zahl, so

m¨

ussen diese warten, bis alle bereits zugelassenen Benutzer ihre Modifikationen abgeschlossen

haben und damit eine neue Version des Schemas angelegt werden konnte.

Sperrverfahren

Beim Sperrverfahren werden Prozessabschnitte, die abge¨

andert werden, gegen den Zugriff durch

andere gesperrt. Es kann dadurch nicht nur Konflikten vorgebeugt werden, es wird damit auch

verhindert, dass Modifikationen eines Benutzers auf Modifikationen eines anderen aufbauen. Das

Verfahren zielt darauf ab, die Schema¨

anderungen durch die verschiedenen Benutzer disjunkt

zu halten. Dadurch ist es besonders einfach, einzelne oder alle ¨

Anderungen eines Benutzers

wieder r¨

uckg¨

angig zu machen. Dieses Verfahren unterst¨

utzt damit ¨

Anderungstransaktionen. Die

entsprechend gesetzten Sperren m¨

ussen beim R¨

uckg¨

angigmachen aufgehoben werden.

Die Benutzer ¨

andern das Schema auf einer lokal liegenden Kopie der Vorlage ab. Bei einem

Commit werden die entsprechenden ¨

Anderungen wie in Kapitel 2.1.2 dargelegt ins PMS ¨

uber-

nommen und als neue Version der Vorlage dort hinterlegt. Welcher Benutzer zuerst commited

spielt keine Rolle, da die ¨

Anderungen der verschiedenen Benutzer durch dieses Verfahren dis-

junkt gehalten werden und disjunkte ¨

Anderungen nach [Ri04] kommutativ sind. Wird die neue

Version der Vorlage erneut abge¨

andert, noch bevor alle parallel dazu gemachten ¨

Anderungen

5.1. VORLAGEN ¨

ANDERUNG ↔VORLAGEN ¨

ANDERUNG 63

eingebracht wurden, so m¨

ussen die bereits existierenden Sperren auch dabei noch ber¨

ucksichtigt

werden. Dies ist notwendig, damit auch die restlichen ¨

Anderungen noch problemlos eingespielt

werden k¨

onnen, ohne dass es zu ¨

Uberlappungen mit den neuen Modifikationen kommt.

Vor jeder Anwendung einer Operation muss ¨

ahnlich dem vorigen Verfahren ¨

uberpr¨

uft werden,

ob die ¨

Anderungen erfolgen d¨

urfen, indem Exklusivsperren auf den Bereich angefordert werden,

der von der anzuwendenden Operation betroffen ist. K¨

onnen die Sperren nicht gew¨

ahrt werden,

da die Bereiche oder Teile davon bereits Exklusivsperren durch andere Benutzer aufweisen, dann

darf die Operation nicht angewendet werden. F¨

ur jeden Typ von ¨

Anderungsoperation kann ein

entsprechender Sperrbereich definiert werden. Das Beispiel aus Abbildung 5.2 demonstriert das

Prinzip des Sperrverfahrens:

Server

Client2

Client1

Zeit t0 t1 t2 t3

A1 A2

A0 A1 A2

Server

A0 A1

Client2

A0 A1 A12 A2

A12 A2

Server

A0 A1 A12 A2

Server

A1 A2

Client2 Client2

Client1 Client1 Client1

insertActivity(A12, A1, A2)

Commit:

insertActivity(A0,-, A1);

insertActivity(A12, A1, A2).

insertActivity(A3, A2,-)

A1 A2 A3

S S S’ S’’

Commit:

insertActivity(A3, A2,-).

insertActivity(A0,-, A1)

Sperre:

(A1;A2)

nichtmöglich

Sperre:

(A1;A2)

(A2;-)

Sperre:

(A2;-)

A1 A2

A0 A1 A2

A1 A2

Sperre:

(A1;A2)

A1 A2

Abbildung 5.2: Prinzip des Sperrverfahrens

In dem Beispiel ¨

andern Client 1 und Client 2 beide parallel das Schema S ab. Client 2 hat zuerst

die Aktivit¨

at A0 eingef¨

ugt. Dazu hatte er die Sperre (-;A1) beantragt, die auch gew¨

ahrt werden

konnte. Um dann noch die Aktivit¨

at A12 zwischen A1 und A2 einf¨

ugen zu k¨

onnen, beantragt

Client 2 zus¨

atzlich zum Zeitpunkt t0 die Sperre auf den Bereich (A1, A2), damit kein anderer

Benutzer an dieser Stelle eine andere Aktivit¨

at einf¨

ugen oder A1 bzw. A2 verschieben kann.

Zeitgleich beantragt Client 1 die Sperre auf (A2; -), um hinter A2 die Aktivit¨

at A3 einf¨

ugen

64 KAPITEL 5. NEBENL ¨

AUFIGKEIT

zu k¨

onnen. Beide Sperren k¨

onnen gesetzt werden. Somit k¨

onnen beide Clients ihre gew¨

unschten

Anderungen durchf¨

uhren. Client 1 will danach zus¨

atzlich noch zwischen A1 und A2 eine Akti-

vit¨

at einf¨

ugen. Die dazu notwendige Sperre (A1; A2) bekommt er aber nicht, da diese bereits von

Client 2 gehalten wird. Somit kann er diese ¨

Anderungsoperation auf dem Schema nicht vorneh-

men. Die Sperren von Client 2 werden auch nach dessem Commit seiner ¨

Anderungstransaktion

aufrechterhalten, damit Client 1, der seine Modifikationen noch nicht abgeschlossen hat, nicht

im Nachhinein noch ¨

Anderungen an den von Client 2 bereits modifizierten Prozessabschnit-

ten vornehmen kann, das zu Konflikten beim Einspielen der ¨

Anderungen von Client 1 auf den

Server f¨

uhren k¨

onnte. Da die Sperren f¨

ur disjunkte und konfliktfreie Modifikationen zwischen

mehreren Benutzern sorgt, k¨

onnen die ¨

Anderungsoperationen von Client 1 bei Abschluss seiner

Anderungstransaktion ohne weitere Pr¨

ufungen auf den Server eingespielt werden. Nach dem

Commit von Client 1 werden s¨

amtliche Sperren wieder freigegeben, da keine weiteren Clients

mehr existieren, die dieses Schema bearbeiten.

Die Sperren m¨

ussen in einer Sperrtabelle verwaltet werden, die auf einem zentralen Server liegt.

Jeder ¨

anderungswillige Client muss darauf Zugriff haben. Die Granularit¨

at der Sperrbereiche

bestimmt die Gr¨

oße der Tabelle und die H¨

aufigkeit des Zugriffs darauf. Da sich oft die ¨

Ande-

rungen in einem Bereich kleiner Ausdehnung konzentrieren, ist es denkbar, pr¨

aventiv einen

gr¨

oßeren Ausschnitt zu sperren, als es die bereits ausgef¨

uhrten ¨

Anderungsoperationen eigentlich

erfordern. Die Sperrtabelle muss dann nicht aktualisiert werden, wenn eine weitere Modifikation

des Schemas in einen der bereits gesperrten Bereiche f¨

allt.

Der Aufwand f¨

ur die Verwaltung einer Sperrtabelle zu diesem Zweck h¨

alt sich allerdings in Gren-

zen, da im Allgemeinen relativ wenig Benutzer gleichzeitig ein und dieselbe Vorlage ab¨

andern

und relativ wenig ¨

Anderungsoperationen ausgef¨

uhrt werden, verglichen mit der H¨

aufigkeit, mit

der Aktivit¨

aten weitergeschalten werden.

Von Nachteil bei diesem Verfahren ist, dass der Server mit der Sperrtabelle st¨

andig erreichbar

sein muss. Damit ist dieses Verfahren auch nicht f¨

ur die Offline-Arbeit geeignet.

Optimistisches Verfahren

Beim optimistischen Verfahren modifiziert jeder Benutzer seine eigene Kopie der Vorlage wie

beabsichtigt. Er braucht dabei erst einmal keine R¨

ucksicht auf die ¨

Anderungen der anderen

Benutzer zu nehmen. Beim Commit wird entweder die ganze Kopie zur¨

uck an den Server gesendet

oder es werden ihm nur die angewendeten ¨

Anderungsoperationen mitgeteilt. Ist die momentan

aktuelle Version der Vorlage genau die, auf dem der Benutzer seine ¨

Anderungen aufgebaut hat,

so wird sein Schema, sofern korrekt, als neue Version der Vorlage ins PMS ¨

ubernommen. Hat

ein anderer Benutzer jedoch bereits seine Modifikationen eingespielt, d. h. die aktuell relevante

Version stimmt nicht mit der ¨

uberein, auf dem die jetzt einzuspielenden Modifikationen beruhen,

dann muss der Server den ¨

Uberlappungsgrad (vgl. Kapitel 2.3.2) der beiden Vorlagen¨

anderungen

bestimmen und darauf basierend analog zur Migration von gegen¨

uber der Vorlage verzerrten

Instanzen das resultierende Schema erzeugen, welches daraufhin als neue Vorlagenversion ins

5.1. VORLAGEN ¨

ANDERUNG ↔VORLAGEN ¨

ANDERUNG 65

PMS ¨

ubernommen wird. Zuvor muss der Server aber ¨

uberpr¨

ufen, ob das Einspielen der neu

hinzugekommenen ¨

Anderungen auf das momentan relevante Schema nicht zu einem inkorrekten

Schema f¨

uhrt. Im Falle von Konflikten unterrichtet er den entsprechenden Benutzer und gibt

ihm die M¨

oglichkeit, sie zu beheben. F¨

ur den Test auf Konflikte und bei der Bestimmung des

Uberlappungsgrades der ¨

Anderungen k¨

onnen dieselben Algorithmen angewendet werden wie bei

der Migration von verzerrten Instanzen.

Server

Client2

Client1

Zeit t0 t1 t2 t3

A1 A2

A0 A1 A2

Server

A0 A1

Client2

A0 A1 A12 A2

A12 A2

Server

A0 A1 A12 A2

Server

A1 A2

Client2 Client2

Client1 Client1 Client1

insertActivity(A12, A1, A2)

Commit:

insertActivity(A0,-, A1);

insertActivity(A12, A1, A2).

insertActivity(A12, A1, A2) insertActivity(A3, A2,-)

A1 A2 A1 A12 A2 A1 A12 A2 A3

S S S’ S’’

Commit:

insertActivity(A3, A2,-).

insertActivity(A12, A1, A2);

insertActivity(A0,-, A1)

Abbildung 5.3: Prinzip des optimistischen Verfahrens

In dem Beispiel aus Abbildung 5.3 ¨

andern Client 1 und Client 2 parallel und unabh¨

angig von-

einander das Schema S ab. Client 2 commited als erster. Da die Version des auf dem Server

vorliegenden Schemas noch mit der Version des Schemas ¨

ubereinstimmt, auf dem Client 2 sei-

ne Modifikationen begonnen hat, k¨

onnen seine ¨

Anderungen einfach auf den Server eingespielt

werden. Zum Commit-Zeitpunkt von Client 1 sieht der Fall anders aus: Die aktuelle Version

S’ des Schemas auf dem Server stimmt nicht mehr mit der Version S ¨

uberein, die Client 1 be-

gonnen hat abzu¨

andern. Aus diesem Grund muss nun der ¨

Uberlappungsgrad der von Client 1

durchgef¨

uhrten ¨

Anderungen mit den ¨

Anderungen bestimmt werden, die das auf dem Server vor-

liegende Schema von der Version S in die Version S’ ¨

uberf¨

uhrt haben, d. h. in diesem Fall mit

den ¨

Anderungen von Client 2. Da beide Clients die Aktivit¨

at A12 eingef¨

ugt haben, ansonsten

aber keine gemeinsame Aktivit¨

aten dem urspr¨

unglichen Schema hinzugef¨

ugt haben, liegt der

66 KAPITEL 5. NEBENL ¨

AUFIGKEIT

einfache Fall der partiellen ¨

Aquivalenz vor. Um die ¨

Anderungen von Client 1 in dem serverseitig

vorliegenden Schema zu ber¨

ucksichtigen, ist es deshalb nur n¨

otig, die neue Aktivit¨

at A3 dort

einzubringen.

Der Vorteil dieses Verfahrens ist, dass jeder Benutzer erst einmal nicht in seiner Modellierungs-

freiheit eingeschr¨

ankt ist. Er kann s¨

amtliche Modifikationen vornehmen, die er geplant hat und

wie er sie geplant hat. Erst im Falle von Konflikten muss er sich dar¨

uber Gedanken machen,

wie er diese umgehen kann. Dabei kann er sinnvoller als bei den anderen Verfahren vom Ser-

ver unterst¨

utzt werden, weil der Server bereits die Ziele des Modellierers in Form des fertigen

Schemas kennt. Dadurch, dass kein st¨

andiger Kontakt zum Server erforderlich ist, ist das Offline-

Modellieren m¨

oglich. Da die Benutzer unabh¨

angig voneinander auf getrennten Vorlagenkopien

ihre Modifikationen vornehmen, k¨

onnen einzelne ¨

Anderungen auch wieder r¨

uckg¨

angig gemacht

werden, ohne dass es zu Konflikten aufgrund von darauf basierenden ¨

Anderungsoperationen

anderer Benutzer kommt. Das Abbrechen einer ganzen ¨

Anderungstransaktion kann auch leicht

realisiert werden, indem einfach die abge¨

anderte Vorlagenkopie verworfen wird. Ein weiterer

Vorteil ist, dass keine zentrale Datenstruktur, wie z. B. eine Sperrtabelle, notwendig ist, die zum

Nadel¨

ohr werden kann.

Der Nachteil ist, dass das Einspielen der ¨

Anderungen verglichen mit den anderen, bis jetzt

vorgestellten Verfahren ein relativ aufw¨

andiger Vorgang ist, da die Algorithmen zur Bestimmung

des ¨

Uberlappungsgrades auf Mengenvergleichen (vgl. [Ri04]) beruhen.

Welches der vorgestellten Verfahren zu bevorzugen ist, kann nicht pauschal gesagt werden, son-

dern h¨

angt von den gegebenen Umst¨

anden ab: Sind konkurrierende ¨

Anderungen der Vorlage

so gut wie ausgeschlossen oder nicht notwendig, dann ist das Verfahren des Exklusivzugriffs zu

bevorzugen, da es weder großen Verwaltungsaufwand f¨

ur das System verursacht, noch komplexe

Algorithmen notwendig sind, um die konkurrierende ¨

Anderungen zusammenzubringen, wie es

beim optimistischen Verfahren der Fall ist. Da in Unternehmen in der Regel die Zust¨

andigkeiten

f¨

ur logisch in sich abgeschlossene Prozessabschnitte klar verteilt sind, ist die Wahrscheinlichkeit

sehr gering, dass zwei Personen denselben Abschnitt ab¨

andern. Dann bietet sich das Sperrver-

fahren oder das optimistische Verfahren an.

5.2 Vorlagen¨

anderung ↔Weiterschalten

In Zusammenhang mit einer Vorlagen¨

anderung muss auch untersucht werden, ob und inwie-

weit es zu Konflikten kommen kann, wenn Instanzen, die auf dieser Vorlage basieren, zeitgleich

weiterschalten.

Da die Vorlagen¨

anderungen auf einer oder mehreren Kopien der momentan g¨

ultigen Vorlagenver-

sion durchgef¨

uhrt werden, kommt es prim¨

ar zu keinen Problemen, wenn eine auf dieser Vorlage

basierende Instanz zeitgleich weitergeschaltet wird: Das diese Instanz repr¨

asentierende Instanz-

Objekt bzw. – im Falle einer verzerrten Instanz – das zugeh¨

orige unterste Delta-Schicht-Objekt

5.2. VORLAGEN ¨

ANDERUNG ↔WEITERSCHALTEN 67

referenziert vorerst weiterhin das originale Vorlagen-Objekt. Die Bestimmung der als n¨

achstes

zu aktivierenden Aktivit¨

aten erfolgt deshalb weiterhin problemlos nach der bisherigen Version.

Allerdings kann das Weiterschalten die Instanz in einen Zustand bringen, der dann nicht mehr

mit den ¨

Anderungen des Schemas vertr¨

aglich ist, wie Abbildung 5.4 zeigt.

ProzessvorlageS

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 A3

AufSbasierendeInstanzen

Aktivität Kontrollflusskante Inaktiv Aktiviert uIn Ausführung

Beendet

A1 A2 A3 A4

Weiterschaltenvon A2

InstanzistverträglichmitderSchemaänderung SD

InstanzistunverträglichmitderSchemaänderung SD

Abbildung 5.4: Unvertr¨

aglichkeit einer Instanz aufgrund einer Aktivit¨

aten-Weiterschaltung

Hierbei kann das Sperren von Instanzen gegen das Weiterschalten schon w¨

ahrend der ¨

Anderungs-

phase verhindern, dass Instanzen in Zust¨

ande gelangen, in denen sie nicht mehr vertr¨

aglich mit

den ¨

Anderungen sind.

Zwei Sperrans¨

atze sind denkbar. Ein Ansatz ist, die Instanz komplett gegen das Weiterschalten

zu sperren. Ein anderer Ansatz ist, nur die Aktivit¨

aten gegen das Weiterschalten zu sperren,

die sp¨

ater von der Vertr¨

aglichkeitspr¨

ufung auf ihren Status hin untersucht werden. Wie in Ka-

pitel 2.3.3 ¨

uber vertr¨

agliche und unvertr¨

agliche Instanzen angedeutet, h¨

angt es von den durch-

gef¨

uhrten Modifikationen ab, welche Aktivit¨

aten untersucht werden m¨

ussen. Die zu sperrenden

Aktivit¨

aten lassen sich somit anhand der angewendeten ¨

Anderungsoperationen bestimmen.

Der zweite Ansatz hat gegen¨

uber dem ersten Ansatz den Vorteil, dass nur Aktivit¨

aten gegen

das Ausf¨

uhren gesperrt werden, die auch wirklich von der Vertr¨

aglichkeitspr¨

ufung betroffen sind.

Das Weiterschalten der anderen Aktivit¨

aten wird dabei nicht behindert.

Da aber erst nach der Anwendung einer ¨

Anderungsoperation bekannt ist, welche Aktivit¨

aten

davon betroffen sind, kann dieser Ansatz nur verhindern, dass die Instanz in einen unvertr¨

agli-

chen Zustand gebracht wird, indem die bereits bestimmten Aktivit¨

aten ausgef¨

uhrt werden. Die

Instanz kann aber immer noch durch das Weiterschalten der anderen Aktivit¨

aten einen unver-

tr¨

aglichen Zustand einnehmen, n¨

amlich dann, wenn im Laufe der Transaktion eine Operation

68 KAPITEL 5. NEBENL ¨

AUFIGKEIT

angewendet wird, bei deren Pr¨

ufung auf Anwendbarkeit im Vertr¨

aglichkeitstest des Migrations-

prozesses die ¨

Uberpr¨

ufung des Status einer dieser Aktivit¨

aten notwendig ist.

Die Abbildungen 5.5 und 5.6 verdeutlichen dies:

ProzessvorlageS

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 A3

AufSbasierendeInstanz

Aktivität

Kontrollflusskante

Inaktiv Aktiviert

uIn Ausführung

Beendet

Instanzist mitdenbisher

ausgeführtenSchemaänderungen

verträglich

A2A1 A12 A3

insertActivity(A12, A1, A2) insertActivity(A23, A2, A3)

A1 A2 A3 A4

Versuch, A2weiterzuschalten

Instanzist mitden

Schemaänderungen

verträglich

A1 A2 A3 A4

Instanzist mitdenbisher

ausgeführtenSchemaänderungen

verträglich

Zeit t0 t1 t2

migrierbar

SperregegenWeiterschalten

Abbildung 5.5: Vermeidung von Unvertr¨

aglichkeit durch Sperren gegen Weiterschalten

Bei Abbildung 5.5 vereitelt die nach der Schema¨

anderung insertActivity(A12, A1, A2) auf A2

gesetzte Sperre den zum Zeitpunkt t1 stattfindenden Versuch, A2 zu starten, und verhindert

damit, dass die Instanz I unvertr¨

aglich mit den Schema¨

anderungen ∆Swird.

Wird aber, wie in Abbildung 5.6 gehandhabt, anstatt A12 zuerst die Aktivit¨

at A23 eingef¨

ugt,

dann existiert zum Zeitpunkt t1 die Sperre auf A2 noch nicht und der Versuch gelingt, A2

zu diesem Zeitpunkt zu starten. Dies hat zur Folge, dass I mit dem Einf¨

ugen von A12 in das

Vorlagenschema zum Zeitpunkt t2 trotz des Einsatzes von Sperren unvertr¨

aglich mit den Sche-

ma¨

anderungen ∆Swird und im Folgenden nicht migriert werden kann. Die Sperre A12 existiert

bei t1 noch nicht, da das System zu diesem Zeitpunkt noch nicht wissen kann, dass zu einer

sp¨

ateren Zeit noch die Aktivit¨

at A12 in das Schema eingef¨

ugt werden soll.

Die Instanz komplett gegen das Weiterschalten zu sperren, blockiert zwar alle Aktivit¨

aten, aber

es kann dabei nur der bereits zu Beginn der Schema¨

anderung eingenommene Zustand der Instanz

5.2. VORLAGEN ¨

ANDERUNG ↔WEITERSCHALTEN 69

ProzessvorlageS

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

SS->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 A3

AufSbasierendeInstanz

A1 A2 A3 A4

Instanzist mitdenbisher

ausgeführtenSchemaänderungen

verträglich

insertActivity(A12, A1, A2)insertActivity(A23, A2, A3)

A2 A23A1 A3

Instanzist mitdenbisher

ausgeführtenSchemaänderungen

verträglich

Versuch, A2weiterzuschalten

A1 A2 A3 A4

Instanzist mit

denSchemaänderungen S

unverträglich

Aktivität

Kontrollflusskante

Inaktiv Aktiviert

uIn Ausführung

Beendet

Zeit t0 t1 t2

nichtmigrierbar

SperregegenWeiterschalten

A1 A2 A3 A4

Abbildung 5.6: Unvertr¨

aglichkeit trotz Sperren gegen Weiterschalten

verantwortlich f¨

ur die Unvertr¨

aglichkeit mit den Schema¨

anderungen sein. Nachtr¨

aglich in einen

solchen Zustand zu laufen ist dabei unm¨

oglich.

Der Einsatz von Sperren schon w¨

ahrend der Vorlagen¨

anderung weist allerdings erhebliche Nach-

teile auf:

Das Sperren kann die Instanz unn¨

otigerweise oder unn¨

otig lange blockieren, erstens wenn die

Vorlagen¨

anderung abgebrochen wird, zweitens wenn die Instanz aufgrund ihres bereits erlangten

Zustandes schon unvertr¨

aglich ist oder es im Laufe der ¨

Anderungstransaktion wird, und drittens

wenn die Instanz noch vor dem Abschluss der Schemaevolution beendet werden k¨

onnte.

Werden nur einzelne Aktivit¨

aten gegen das Weiterschalten gesperrt, so ist eine Sperrtabelle

notwendig, die entsprechende Informationen bereith¨

alt. Da sehr viele Instanzen eines Typs exis-

tieren k¨

onnen und jedes Weiterschalten ein Zugriff auf die Tabelle erforderlich macht, kann die

Datenstruktur zu einem Engpass werden. Verz¨

ogerungen bei den Prozessausf¨

uhrungen sind die

Folge.

Zus¨

atzlich von Nachteil ist, dass dabei das Offline-¨

Andern der Vorlage nicht mehr m¨

oglich ist,

auch wenn das eingesetzte Verfahren zur Verhinderung von konkurrierenden Vorlagen¨

anderungen

70 KAPITEL 5. NEBENL ¨

AUFIGKEIT

(vgl. Abschnitt 5.1) dies zulassen w¨

urde, da nach jeder Anwendung einer ¨

Anderungsoperation

die entsprechenden Sperren auf dem Server gesetzt werden m¨

ussen. Dazu ist der st¨

andige Zugriff

aller an der Schema¨

anderung beteiligten Clients auf den Server notwendig.

Einfach die entsprechenden Arbeitsauftr¨

age aus den Arbeitslisten der infrage kommenden Bear-

beiter herauszunehmen reicht im Allgemeinen zur Verhinderung einer Weiterschaltung nicht aus,

besonders nicht, wenn die Clients selbst f¨

ur die Aktualisierung ihrer Arbeitslisten verantwortlich

sind: Einige der Clients k¨

onnen das L¨

oschen der Eintr¨

age aufgrund zu langer Aktualisierungsin-

tervalle zu sp¨

at oder gar nicht mitbekommen. Deshalb muss der Server trotzdem noch bei einer

Auftragsannahme gesondert ¨

uberpr¨

ufen, ob die jeweilige Aktivit¨

at gestartet werden darf.

Zusammenfassend kann gesagt werden, dass Sperren auf der einen Seite verhindern k¨

onnen, dass

eine mit den Schema¨

anderungen vertr¨

agliche Instanz noch unvertr¨

aglich wird, auf der anderen

Seite aber auch Instanzen lange blockieren k¨

onnen. Die Vor- und Nachteile eines Einsatzes soll-

ten deshalb gut gegeneinander abgew¨

agt werden. Die Gr¨

unde f¨

ur die Schema¨

anderungen k¨

onnen

u. U. die Entscheidung beeinflussen. Sind Optimierungen der Anlass der ¨

Anderungen, so ist im

Allgemeinen das Sperren nicht notwendig. Beseitigen die Schema¨

anderungen allerdings Fehler

im Prozessablauf, so ist das Sperren der Instanzen im Allgemeinen unumg¨

anglich. Auch die

Ausf¨

uhrungsbrisanz muss in die ¨

Uberlegungen mit einbezogen werden. Bei Leasing-Vertr¨

agen

zum Beispiel, bei denen es bei dem Ausf¨

uhrungszeitpunkt der einzelnen Schritte nicht auf das

Heute oder auf das Morgen ankommt, kann dem Sperren eher zugestimmt werden, als bei Pro-

zessen, bei denen strenge Zeitanforderungen vorliegen.

5.3 Vorlagen¨

anderung ↔Dynamische ¨

Anderungen

Weitere, auf Wechselwirkung hin zu untersuchende konkurrierende Aktionen sind die Vorla-

gen¨

anderung und das dynamische ¨

Andern einer Instanz, die auf dem entsprechenden Schema

basieren.

Von der Architektur her gibt es dabei keine Probleme: Das Delta-Schicht-Objekt, in dem die

Anderungen der Instanz gegen¨

uber der Vorlage gespeichert werden, setzt direkt oder transitiv

uber andere Delta-Schichten auf dem originalen Vorlagen-Objekt auf, das die bisher g¨

ultige

Version des Schemas repr¨

asentiert. Die Schema¨

anderungen werden dagegen auf einer Kopie

dieses Vorlagen-Objekts ausgef¨

uhrt, wie in Kapitel 3.3 beschrieben. Damit kommt es auf dieser

Ebene zu keinen Wechselwirkungen zwischen den ¨

Anderungsarten.

Bei der Migration der dynamisch ge¨

anderten Instanz auf das neue Schema kann es aber zu

Konflikten aufgrund partiell ¨

aquivalenten Instanz- und Vorlagen¨

anderungen kommen, wie in

Kapitel 2.3.2 ¨

uber die Migration verzerrter Instanzen geschildert wurde.

Zum Beispiel kann an dieselbe Stelle auf Typebene eine andere Aktivit¨

at als auf Instanzebene

eingef¨

ugt werden. Im Rahmen der Migration der Instanz ergeben sich dann mehrere denkbare

Varianten, wie sich die Instanz auf die neue Version der Vorlage anpassen ließe, wie Abbil-

5.3. VORLAGEN ¨

ANDERUNG ↔DYNAMISCHE ¨

ANDERUNGEN 71

dung 5.7 zeigt. Welche Variante die richtige ist, muss mithilfe des Benutzers oder speziell daf¨

hinterlegten Regeln beantwortet werden.

A1 A2 AXY A3 A4

S *I

DS ={insertActivity(AXY, A2, A3)}I

gegenüberderVorlagezusätzlicheingefügte Aktivität

imRahmenderMigrationeingefügte Aktivität

AufSbasierendeInstanz

ProzessvorlageS

A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 A3 A4

dynamischeÄnderung:

insertActivity(AXY, A2, A3)

Migration

A2 A23A1 A12 A3

A2 AXYA1 A12 A3

A23

A1 A12 A3

AXY

A2A1 A12 A3

S *’I

DS ’ ={deleteActivity(A23),insertActivity(AXY, A2, A3)}I

S *’I

DS ’ ={insertActivityParallel(AXY, A23)}I

DS ’ ={deleteActivity(A23)}I

A2 A23A1 A12 AXY

A3 A4

DS ’ ={insertActivity(AXY, A23, A3)}I

A2 A23

A1 A12 AXY

A3 A4

DS ’ ={insertActivity(AXY, A2, A23)}I

S’+ S ’DI

trace

S’

trace

S *’IS’+ S ’DI

trace

S *’IS’+ S ’DI

trace

S *’IS’+ S ’DI

trace

S *’IS’+ S ’DI

trace

S+ SDI

trace

Abbildung 5.7: Konflikte aufgrund ¨

uberlappender Instanz- und Schema¨

anderungen

Ziel dieses Abschnitts ist zu kl¨

aren, ob es sinnvoll ist, dynamische ¨

Anderungen einer Instanz zu

untersagen, w¨

ahrend das zugrunde liegende Schema abge¨

andert wird, und ob es andere M¨

oglich-

keiten gibt.

Instanzen w¨

ahrend der Schemaevolution gegen das dynamische ¨

Andern zu sperren verhindert,

dass es bei der Migration dieser Instanzen zu Problemen aufgrund von ¨

uberlappenden oder kon-

kurrierenden ¨

Anderungen kommt, vorausgesetzt die Instanzen sind nicht schon bereits gegen¨

uber

der momentan g¨

ultigen Schemaversion verzerrt. Benutzereingriffe w¨

ahrend der Migration k¨

onnen

dadurch reduziert werden.

Die Instanz ganz gegen das dynamische Ab¨

andern zu sperren, muss aber nicht unbedingt sinnvoll

sein: Wie in Abschnitt ”Adaptivit¨

at“ der Einf¨

uhrung (Abschnitt 1.2) erkl¨

art, werden dynami-

sche ¨

Anderungen u. a. angewendet, um Ausnahmesituationen zu begegnen. Wird die Instanz

in so einer Situation gegen das ¨

Andern gesperrt, dann kann eventuell nicht rechtzeitig auf die

Ausnahme reagiert werden. Unter Umst¨

anden kann daraus mehr Schaden als Nutzen entstehen.

72 KAPITEL 5. NEBENL ¨

AUFIGKEIT

Eine praktikable L¨

osung ist es, einfach die Benutzer von der anstehenden Schema¨

anderung in

Kenntnis zu setzen und ihnen die Entscheidung zu ¨

uberlassen, ob sie die Instanzen trotzdem

modifizieren wollen.

Wird zur Kontrolle von konkurrierenden Vorlagen¨

anderungen das in Abschnitt 5.1 beschriebene

Sperrverfahren eingesetzt, das die Schema¨

anderungen der verschiedenen Benutzer disjunkt h¨

alt,

dann kann durch die Ber¨

ucksichtigung der dabei angefallenen Sperrinformationen die Wahr-

scheinlichkeit von Konflikten reduziert werden, ohne die Instanz ganz gegen dynamische ¨

Ande-

rungen w¨

ahrend der Schema¨

anderung zu sperren.

Die Sperren zu ber¨

ucksichtigen kann die ¨

Uberlappung der Instanz¨

anderungen mit den Schema-

anderungen reduzieren, da auf Instanzebene keine Modifikationen durchgef¨

uhrt werden k¨

onnen,

die Bereiche betreffen, die bereits auf Schemaebene ge¨

andert wurden. Damit wird auch das Ri-

siko reduziert, dass sp¨

ater bei der Migration Konflikte auftreten. Ganz verhindert werden kann

dies nur, wenn anders herum auch die Instanz-Modifikationen zu Sperren bei der Schema¨

ande-

rung f¨

uhren. Allerdings w¨

urde das die Vorlagen¨

anderung einschr¨

anken und sollte daher nicht

angewendet werden.

Abbildung 5.8 zeigt, wie durch ein R¨

uckgreifen auf die w¨

ahrend der Vorlagen¨

anderung gesetzten

Sperren die in Abbildung 5.7 gezeigte Situation vermieden werden kann.

A1 A2 AXY A3 A4

gegenüberderVorlagezusätzlicheingefügte Aktivität

imRahmenderMigrationeingefügte Aktivität

AufSbasierendeInstanz

ProzessvorlageS

A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 A3 A4

dynamischeÄnderung:

insertActivity(AXY, A2, A3)

A1 A2 A3 A4

Änderungnichterlaubt!

Änderungenverwerfen

A2 A23A1 A12 A3

eindeutigeMigration

Änderungfälltin

gesperrtenBereich

Aktivität Kontrollflusskante

Inaktiv Aktiviert

uIn Ausführung

Beendet

Sperre

Abbildung 5.8: Reduzierung des ¨

Uberlappungsgrades von Instanz- und Schema¨

anderungen

Infolge der Einf¨

ugung der Aktivit¨

at A12 zwischen die Aktivit¨

aten A1 und A2 auf Typebene

ist der Bereich zwischen A1 und A2 gesperrt worden, damit andere Benutzer, welche dieselbe

Vorlage ab¨

andern, diesen Bereich nicht auch modifizieren und damit u. U. Konflikte hervorrufen

5.4. DYNAMISCHE ¨

ANDERUNGEN ↔WEITERSCHALTEN 73

k¨

onnen. Diese Sperre verhindert dann aber auch, dass auf Instanzebene an gleicher Stelle die

Aktivit¨

at AXY eingef¨

ugt werden kann und dass es somit bei der Migration dieser Instanz zu dem

in Abbildung 5.7 illustrierten Problem kommt, sich zwischen mehreren denkbaren Anpassungen

der Instanz an die Vorlage entscheiden zu m¨

ussen.

5.4 Dynamische ¨

Anderungen ↔Weiterschalten

Das parallele Weiterschalten und dynamische Ab¨

andern von Instanzen ist ein weiterer Fall von

konkurrierenden Zugriffen, bei dem untersucht werden muss, ob sich daraus Probleme ergeben

k¨

onnen.

Um eine Instanz abzu¨

andern, wird das Instanz-Objekt, das typbestimmende Vorlagen-Objekt

und die eventuell bereits vorhandenen Delta-Schicht-Objekte auf den Clientrechner kopiert. Die

Anderungen werden dann entweder auf einem der kopierten Delta-Schicht-Objekte ausgef¨

uhrt

oder es wird ein neues angelegt. Beim Commit wird das entsprechende Delta-Schicht-Objekt an

den Server zur¨

uckgeschickt und in die Originalinstanz integriert. Da die Modifikationen zun¨

achst

auf Kopien durchgef¨

uhrt werden, kann das Weiterschalten der Instanz ungest¨

ort und ohne Pro-

bleme gem¨

aß dem durch das bisherige Laufzeitschema vorgeschriebene Vorgehen erfolgen.

Allerdings kann es in Bezug auf die Vertr¨

aglichkeit der ¨

Anderungsoperationen mit der Instanz

zu Problemen kommen: Vor der Ausf¨

uhrung einer jeden Operation muss deren Vertr¨

aglich-

keit mit dem eingenommenen Laufzeitzustand der Instanz ¨

uberpr¨

uft werden. Nur wenn die f¨

die entsprechende Operation relevanten Aktivit¨

aten die richtigen, f¨

ur die Vertr¨

aglichkeit der

Operation vorausgesetzten Zust¨

ande aufweisen, darf die Modifikation durchgef¨

uhrt werden. Da

aber die Modifikationen zun¨

achst auf Instanzkopien ausgef¨

uhrt werden, kann zwischen der Ver-

tr¨

aglichkeitspr¨

ufung und dem endg¨

ultigen Einspielen der ¨

Anderungen auf die Originalinstanz

im Rahmen der Commit-Behandlung eine l¨

angere Zeit vergehen. Ohne besondere Vorkehrungen

ist es dann m¨

oglich, dass in dieser Zeitspanne die bereits ¨

uberpr¨

uften Aktivit¨

aten im Nachhin-

ein in Zust¨

ande geschaltet werden, welche die Anwendung der Operationen beim Commit nicht

mehr erlauben d¨

urften. Werden die Operationen aber trotzdem, ohne eine erneute, abschließende

Vertr¨

aglichkeitspr¨

ufung ¨

ubernommen, dann kann es zu Inkonsistenzen im Zustand der Instanz

kommen, wie das Beispiel aus Abbildung 5.9 zeigt.

F¨

ur die Ad-hoc-Modifikation der Instanz I wird diese auf den Client kopiert. Um in die Instanz

die Aktivit¨

at A12 zwischen A1 und A2 einf¨

ugen zu k¨

onnen, darf A2 sich h¨

ochstens im Zu-

stand ”AKTIVIERT“ befinden. Die auf dem Client stattfindende Vertr¨

aglichkeitspr¨

ufung zum

Zeitpunkt t1 f¨

ur die Operation insertActivity(A12, A1, A2) ergibt, dass I vertr¨

aglich mit der

gew¨

unschten Operation ist, da die Bedingung an den Zustand von A2 erf¨

ullt ist: A2 ist nur

aktiviert. Auf den positiven Ausgang der Vertr¨

aglichkeitspr¨

ufung hin wird die Aktivit¨

at bei

t2 auf die Instanzkopie eingef¨

ugt. Bevor aber das Einspielen dieser Operation auf den Server

vorgenommen wird, wird die Aktivit¨

at A2 dort gestartet und I damit in einen mit der Einf¨

uge-

Operation unvertr¨

aglichen Zustand gebracht. Erfolgt das Einspielen dann ungepr¨

uft, kommt

74 KAPITEL 5. NEBENL ¨

AUFIGKEIT

A1 A2 A3

serverseitig

clientseitig

A1 A2 A3

A1 A12 A2 A3

Verträglichkeitsprüfungfür

insertActivity(A12, A1, A2)

durchführen

KopiederInstanz

fürdynamischeÄnderung

aufdenClientübertragen

Weiterschaltenvon A2

A1 A2 A3

Instanzänderung

insertActivity(A12, A1, A2)

durchführen

A1 A12 A2 A3

Instanzänderung

insertActivity(A12, A1, A2)

aufServerungeprüfteinspielen

Zeit t0 t1 t2 t3

gegenüberderVorlagezusätzlicheingefügte Aktivität

KopievonInstanzI

InstanzI

Aktivität Kontrollflusskante

Inaktiv Aktiviert uIn Ausführung

Beendet

Sperre

Abbildung 5.9: Konflikt bei konkurrierender Instanz¨

anderung und Aktivit¨

aten-Weiterschaltung

es zu der Zustandsinkonsistenz, dass A2 gestartet wurde, bevor ihre Vorg¨

angeraktivit¨

at A12

ausgef¨

uhrt wurde.

Es muss somit verhindert werden, dass es aufgrund eines zu den dynamischen ¨

Anderungen pa-

rallel erfolgten Weiterschaltens einer Instanz zu Inkonsistenzen beim Einspielen der ¨

Anderungen

kommt.

Zwei Ans¨

atze k¨

onnen zu diesem Ziel f¨

uhren: Zum einen kann, wie in der Problembeschreibung be-

reits angedeutet, eine erneute Vertr¨

aglichkeitspr¨

ufung im Rahmen der Commit-Behandlung f¨

eine korrekte Instanz¨

anderung sorgen. Dies bringt aber den Nachteil mit sich, dass entweder der

Benutzer bei einem Scheitern der Vertr¨

aglichkeitspr¨

ufung seine Instanzanpassungen ¨

uberarbei-

ten muss oder dass einige Aktivit¨

aten wieder zur¨

uckgesetzt werden m¨

ussen. Das Zur¨

ucksetzten

ist aber im Allgemeinen aufw¨

andig und nicht immer m¨

oglich.

Ein anderer Weg besteht darin zu verhindern, dass sich der Zustand einer bereits ¨

uberpr¨

uften

Aktivit¨

at bis nach dem endg¨

ultigen Einspielen der Operationen noch einmal ¨

andert. Dies kann

analog wie bei dem Fall ”Vorlagen¨

anderung ↔Weiterschalten“ (siehe Abschnitt 5.2) erreicht

werden, indem die Instanz w¨

ahrend der Ad-hoc-Modifikation komplett gegen ein Weiterschalten

5.5. DYNAMISCHE ¨

ANDERUNGEN ↔DYNAMISCHE ¨

ANDERUNGEN 75

gesperrt wird oder indem (nur) die bereits ¨

uberpr¨

uften Aktivit¨

aten der Instanz dagegen gesperrt

werden.

Die Nachteile der beiden Varianten sind dieselben, wie in Abschnitt 5.2 diskutiert: Die Instanz

komplett zu sperren blockiert auch Aktivit¨

aten, die nicht von den Vertr¨

aglichkeitspr¨

ufungen

angefasst werden. Nur die Aktivit¨

aten an der Ausf¨

uhrung zu hindern, die f¨

ur die bisher an-

gewendeten ¨

Anderungsoperationen relevant sind, bringt den Nachteil mit sich, dass mit jedem

Weiterschalten einer nicht gesperrten Aktivit¨

at die Menge an prinzipiell noch vornehmbaren

Modifikationen des Laufzeitschemas reduziert wird, d. h. jedes Weiterschalten verringert die

Chance, dass der Benutzer seine gew¨

unschten ¨

Anderungen durchbringen kann.

Manche Aktivit¨

aten nicht gegen das Weiterschalten zu sperren hat auch den Nachteil, dass die

Instanzkopien auf den Clientrechnern und die jeweiligen Originale vom Zustand her st¨

andig

synchron gehalten werden m¨

ussen, d. h. jede Kopie muss ¨

uber einen erfolgten Zustandswechsel

zuverl¨

assig informiert werden.

Alle drei Konzepte – das erneute Pr¨

ufen beim Einspielen, die Komplettsperre und das Sperren

der relevanten Aktivit¨

aten – f¨

uhren zu dem Ziel, dass es zu keinen Inkonsistenzen beim Einspielen

der ¨

Anderungen kommt. Allerdings weisen alle drei Nachteile auf. Wiederum muss man abw¨

agen,

welches Verfahren angewendet werden soll. Da dynamische ¨

Anderungen von Instanzen eher von

geringem Umfang sind und damit im Allgemeinen relativ schnell erfolgen, bietet sich die L¨

osung

mit der Komplettsperre an. Sie erfordert wenig Verwaltungsaufwand f¨

ur das System.

5.5 Dynamische ¨

Anderungen ↔Dynamische ¨

Anderungen

Wie auch mehrere Benutzer parallel die gleiche Vorlage anpassen wollen k¨

onnen, so k¨

onnen auch

mehrere Benutzer zeitgleich versuchen, ein und dieselbe Instanz dynamisch abzu¨

andern.

Daraus k¨

onnen dieselbe Probleme entstehen, wie im Fall ”Vorlagen¨

anderung ↔Vorlagen¨

ande-

rung“ beschrieben (siehe Abschnitt 5.1): Zum Beispiel k¨

onnen unterschiedliche Aktivit¨

aten an

derselben Stelle eingef¨

ugt werden oder das aus den verschiedenen ¨

Anderungstransaktionen re-

sultierende Schema kann gegen die Korrektheitskriterien des zugrunde gelegten Prozess-Modells

verstoßen.

Analog zum Fall ”Vorlagen¨

anderung ↔Vorlagen¨

anderung“ besteht das zu erreichende Ziel darin,

dass Konflikte aufgrund von ¨

uberlappenden ¨

Anderungen vermieden oder aufgel¨

ost werden.

Da die gleichen Probleme wie im Fall ”Vorlagen¨

anderung ↔Vorlagen¨

anderung“ auftreten,

k¨

onnen auch dieselben Verfahren zur Vermeidung bzw. Aufl¨

osung von Konflikten aufgrund von

uberlappenden ¨

Anderungen herangezogen werden:

•Exklusivzugriff

•Best¨

atigung einer ¨

Anderung durch den Server

76 KAPITEL 5. NEBENL ¨

AUFIGKEIT

•Sperren

•Optimistisches Verfahren

Diese Verfahren wurden bereits in Abschnitt 5.1 detailliert beschrieben.

5.6 Migration ↔Weiterschalten

Bisher wurde die Problematik von konkurrierenden Benutzeraktionen untersucht. Aber es kann

auch zu Konflikten oder anderweitigen Wechselwirkungen zwischen Benutzeraktionen und der

Migration kommen, die zu den Systemfunktionen z¨

ahlt.

Unter anderem muss die Wechselwirkung ”Migration ↔Weiterschalten“ n¨

aher betrachtet wer-

den.

Das Weiterschalten einer Instanz kann mit einer Migration konkurrieren, wenn genau die Instanz

weitergeschaltet wird, die gerade im Begriff ist, von der alten Vorlagenversion Sauf die neue

S0zu migrieren. Das Weiterschalten der Instanz kann ohne weitere Absicherungen durch das

System mehrere Konflikte verursachen.

Zu untersuchen ist, welche Konflikte aus dem Zusammenspiel zwischen der Migration und dem

zeitgleichen Weiterschalten einer Instanz entstehen k¨

onnen und wie sie zu vermeiden sind.

Um eine Instanz auf die neue Version S0der Vorlage migrieren zu k¨

onnen, muss sie vertr¨

aglich

mit den Vorlagen¨

anderungen sein. Daf¨

ur d¨

urfen die f¨

ur die Vertr¨

aglichkeit relevanten Aktivit¨

aten

nur bestimmte Zust¨

ande einnehmen. In der Phase der Vertr¨

aglichkeitspr¨

ufung des Migrations-

prozesses wird die Einhaltung dieser Bedingungen ¨

uberpr¨

uft. Wird die Einhaltung best¨

atigt,

dann kann die Instanz mit der Migration fortfahren, d. h. sie ist vertr¨

aglich. Ansonsten ist die

Instanz unvertr¨

aglich und wird von der Migration ausgeschlossen.

Im Allgemeinen sind mehrere Aktivit¨

aten zu ¨

uberpr¨

ufen. Wird eine dieser Aktivit¨

aten in dieser

Phase weitergeschaltet, noch bevor sie zur ¨

Uberpr¨

ufung an der Reihe war, so kann dies dazu

f¨

uhren, dass sie in einen Zustand gelangt, mit dem nicht mehr die Bedingung an deren Zustand

f¨

ur eine Vertr¨

aglichkeit erf¨

ullt ist. Der Test wird dann sp¨

atestens bei dieser Aktivit¨

at die Instanz

korrekt f¨

ur unvertr¨

aglich erkl¨

aren und sie damit von der Migration ausschließen, auch wenn die

Instanz zu Beginn der Phase der Vertr¨

aglichkeitspr¨

ufung vom Zustand her vertr¨

aglich mit den

Anderungen war.

Folgenreicher aber ist der Fall, dass die Aktivit¨

at noch nach ihrer positiven ¨

Uberpr¨

ufung, aber

noch vor dem Ende dieser Phase weitergeschaltet wird. Gelangt die Aktivit¨

at dabei in einen

Zustand, der den Bedingungen widerspricht, so kann das, wie Abbildung 5.10 zeigt, dazu f¨

uhren,

dass der Test die Instanz am Schluss f¨

alschlicherweise f¨

ur vertr¨

aglich erkl¨

art, obwohl die Instanz

eigentlich aufgrund des neuen Zustandes dieser Aktivit¨

at unvertr¨

aglich ist.

5.6. MIGRATION ↔WEITERSCHALTEN 77

ProzessvorlageS

A1 A2 A3

A2 A23A1 A12 A3

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 A3

Weiterschalten

von A2

Zeit t0 t1 t2 t3

A1 A2 A3

P P P

Verträglichkeitsprüfung

fürinsertActivity(A12, A1, A2):

A2darfmaximalaktiviertsein

Verträglichkeitsprüfung

fürinsertActivity(A23, A2, A3):

A3darfmaximalaktiviertsein

IIverträglich

mit DS

Iunverträglich

mit DS

VerträglichkeitsprüfungvonI

zuüberprüfende Aktivität

Inaktiv Aktiviert uIn Ausführung

Beendet

bereitsüberprüfte Aktivität

AufSbasierendeInstanz

? ? ?

verträglich

ErgebnisVerträglichkeitsprüfungfürI:

Iwirdvonder

Verträglichkeits-

prüfungalsverträglich

mit eingestuft,obwohlI

unverträglichist

Abbildung 5.10: Inkorrekte Vertr¨

aglichkeitspr¨

ufung aufgrund einer Zustandsweiterschaltung

Wird die Instanz daraufhin in der vierten Phase auf das neue, S0repr¨

asentierende Vorlagen-

Objekt umgeh¨

angt, dann werden – logisch gesehen – ¨

Anderungen des Laufzeitschemas der In-

stanz durchgef¨

uhrt, die aufgrund des Zustandes der Instanz nicht erfolgen d¨

urften. Zustandsin-

konsistenzen und Fehler bei der Prozessausf¨

uhrung drohen im folgenden.

Derselbe Umstand ergibt sich, wenn einer der ¨

uberpr¨

uften Aktivit¨

aten im Zeitraum zwischen

dem korrekten Ende der Vertr¨

aglichkeitspr¨

ufung und dem Umh¨

angen der Instanz auf das neue

Vorlagen-Objekt durch das Weiterschalten in einen verbotenen Zustand gelangt.

Deshalb muss mit dem Start der Vertr¨

aglichkeitspr¨

ufung sichergestellt werden, dass keine der

relevanten Aktivit¨

aten ihren Zustand mehr ¨

andern kann, bis entweder der Test die Instanz

aufgrund ihrer Unvertr¨

aglichkeit von der Migration ausgeschlossen hat oder bis die Instanz im

Falle der Vertr¨

aglichkeit vollst¨

andig die vierte Phase des Migrationsprozesses durchlaufen hat

und das entsprechende Instanz-Objekt korrekt auf das neue Vorlagen-Objekt umgeh¨

angt wurde.

Eine M¨

oglichkeit, dies sicherzustellen und damit Konflikte zu vermeiden, ist, die f¨

ur die Ver-

tr¨

aglichkeitspr¨

ufung relevanten Aktivit¨

aten einer Instanz zu Beginn des Tests bis zum Abschluss

78 KAPITEL 5. NEBENL ¨

AUFIGKEIT

der vierten Phase des Migrationsprozessen gegen das Weiterschalten zu sperren, wie Abbildung

5.11 zeigt:

ProzessvorlageS

A1 A2 A3

A2 A23A1 A12 A3

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

A1 A2 A3

Zeit t0 t1 t2 t3

A1 A2 A3

PP P P

Verträglichkeitsprüfung

fürinsertActivity(A12, A1, A2):

A2darfmaximalaktiviertsein

Verträglichkeitsprüfung

fürinsertActivity(A23, A2, A3):

A3darfmaximalaktiviertsein

IIverträglich

mit DS

VerträglichkeitsprüfungvonI

zuüberprüfende Aktivität

Inaktiv Aktiviert uIn Ausführung

Beendet

bereitsüberprüfte Aktivität

AufSbasierendeInstanz

? ? ?

verträglich

ErgebnisVerträglichkeitsprüfungfürI:

SperregegeneinWeiterschalten

Iverträglich

mit DS

A1 A2 A3

Iunverträglich

mit DS

Sperreverhindert

Weiterschalten

von A2

Abbildung 5.11: Verhinderung inkorrekter Vertr¨

aglichkeitspr¨

ufungen durch Sperren

Das Sperren der f¨

ur die Vertr¨

aglichkeitspr¨

ufung relevanten Aktivit¨

aten gegen das Weiterschal-

ten verhindert bei der Instanz I aus Abbildung 5.11, dass die Aktivit¨

at A2, die zur Zeit t1

ihrer ¨

Uberpr¨

ufung einen f¨

ur die Vertr¨

aglichkeit zul¨

assigen Zustand inne hat, nach ihrer ¨

Uber-

pr¨

ufung aber noch vor dem Ende der Vertr¨

aglichkeitspr¨

ufung in einen f¨

ur die Vertr¨

aglichkeit

der Instanz unzul¨

assigen Zustand geschalten werden kann und dass damit das Ergebnis der

Vertr¨

aglichkeitspr¨

ufung verf¨

alscht wird, wie in Abbildung 5.10 demonstriert worden ist.

Der Vorteil dieser Methode gegen¨

uber einer Komplettsperre der Instanz ist, dass die nicht rele-

vanten Aktivit¨

aten ausgef¨

uhrt werden k¨

onnen und somit nicht unn¨

otig behindert werden. Der

Nachteil ist, dass das Sperren einzelner Aktivit¨

aten einen h¨

oheren Verwaltungsaufwand verur-

sacht als eine Komplettsperre.

Wie in der Untersuchung des Falls ”Vorlagen¨

anderung ↔Weiterschalten“ in Abschnitt 5.2 dis-

kutiert, kann es sinnvoll sein, das Weiterschalten der relevanten Aktivit¨

aten schon w¨

ahrend

der Vorlagen¨

anderung selbst zu unterbinden und nicht erst nach dem Beginn der Vertr¨

aglich-

keitspr¨

ufung. Greifen dann aber noch viele andere Instanzen des gleichen Prozesstyps auf diese

5.6. MIGRATION ↔WEITERSCHALTEN 79

Sperrtabelle zu, um pr¨

aventiv ein Weiterschalten bis zu deren Migration zu unterbinden, dann

kann diese Datenstruktur zum Flaschenhals werden.

Das Sperren der f¨

ur die Vertr¨

aglichkeitspr¨

ufung relevanten Aktivit¨

aten gegen ein Weiterschalten

stellt nicht nur sicher, dass eine als vertr¨

aglich eingestufte Instanz auch bis zum Umh¨

angen

auf die neue Vorlage vertr¨

aglich bleibt. Es verhindert auch, dass die Instanz in dem Zeitraum

zwischen dem positiven Ausgang der Vertr¨

aglichkeitspr¨

ufung und dem Umh¨

angen auf die neue

Vorlage S0nach der alten Version Sabl¨

auft anstatt nach der neuen Version S0und damit

Anderungen ausl¨

asst, die das Laufzeitschema der Instanz erst nach dem Umh¨

angen auf die neue

Vorlage aufweisen wird.

Aber auch nach dem Umh¨

angen des diese Instanz repr¨

asentierenden Instanz-Objekts auf das

neue Vorlagen-Objekt k¨

onnen Konflikte aufgrund eines Weiterschaltens der Instanz vor dem

Abschluss ihrer Migration auftreten.

Wird eine Aktivit¨

at beendet, so werden gem¨

aß Vorgabe des Schemas die als n¨

achstes aus-

zuf¨

uhrenden Aktivit¨

aten bestimmt, deren Status auf ”AKTIVIERT“ gesetzt und dann ent-

sprechende Arbeitsauftr¨

age in die Arbeitslisten der infrage kommenden Bearbeiter gestellt. Um

aber den Status einer Aktivit¨

at auf ”AKTIVIERT“ setzen zu k¨

onnen, muss f¨

ur diese Aktivit¨

in der Datenstruktur, welche die Laufzeitzust¨

ande der verschiedenen Aktivit¨

aten einer Instanz

speichert, ein entsprechender Eintrag vorhanden sein. Dieser Eintrag wird f¨

ur Aktivit¨

aten, die

im Rahmen der Schemaevolution eingef¨

ugt worden sind, in der f¨

unften Phase des Migrations-

prozesses, der Phase der Instanzanpassung, angelegt.

Findet dieser Zustandswechsel nach der vierten Phase des Migrationsprozesses – die Instanz

l¨

auft damit bereits nach dem neuen Schema ab – aber noch vor Ende der Instanzanpassung

statt und z¨

ahlt die Aktivit¨

at zu den neu hinzugef¨

ugten, dann besteht die M¨

oglichkeit, dass f¨

diese Aktivit¨

at noch kein Eintrag in dieser Datenstruktur angelegt wurde. Der Versuch, diese

Aktivit¨

at zu aktivieren, kann dann u. U. zu einem undefinierten Verhalten des Systems f¨

uhren.

Eine ¨

ahnliche Situation liegt vor, wenn die neue Aktivit¨

at in einem XOR-Zweig liegt und dieser

abgew¨

ahlt wird. Existiert f¨

ur die entsprechende Aktivit¨

at noch kein Eintrag in der angesproche-

nen Datenstruktur, dann kann der Status der Aktivit¨

at auch nicht auf ”ABGEW¨

AHLT“ gesetzt

werden. Auch in diesem Fall droht u. U. ein undefiniertes Verhalten des Systems.

Somit muss verhindert werden, dass sich der Status neu hinzugef¨

ugter Aktivit¨

aten vor dem Ende

der 5. Phase des Migrationsprozesses ¨

andern kann. Wiederum k¨

onnen dazu Sperren eingesetzt

werden.

Zu weiteren Konflikten kann es kommen, wenn aktivierte Aktivit¨

aten, die im Rahmen der Mar-

kierungsanpassung wieder deaktiviert werden m¨

ussen, zuvor gestartet werden. Wird z. B. vor die

aktivierte Aktivit¨

at Z die Aktivit¨

at Y eingef¨

ugt, dann muss, wie in Kapitel 2.3.4 erkl¨

art, Z im

Rahmen der Markierungsanpassung in den inaktiven Zustand zur¨

uckversetzt werden und daf¨

Y aktiviert werden. Wird jedoch Z vor dem Zur¨

ucksetzen gestartet, dann wird Z ausgef¨

uhrt,

obwohl dazu nach dem neuen Schema zuvor Y beendet worden sein h¨

atte m¨

ussen. Es kommt zu

einer Zustands- bzw. Ausf¨

uhrungsinkonsistenz.

80 KAPITEL 5. NEBENL ¨

AUFIGKEIT

Die Ausf¨

uhrung der Aktivit¨

at Z r¨

uckg¨

angig zu machen, kann das Problem l¨

osen. Viele Akti-

vit¨

aten k¨

onnen aber in der Praxis nicht mehr so einfach r¨

uckg¨

angig gemacht werden. Deshalb

scheidet diese L¨

osung oft aus. Die f¨

ur die Markierungsanpassung relevanten Aktivit¨

aten gegen

das Weiterschalten zu sperren bietet Abhilfe. Die Menge der zu sperrenden Aktivit¨

aten kann

wiederum anhand der ausgef¨

uhrten ¨

Anderungsoperationen ermittelt werden.

Probleme zwischen einem Weiterschalten und der zweiten und dritten Phase des Migrationspro-

zesses treten nicht auf, da die Klasseneinteilung und die Migrationsvorbereitung ausschließlich

mit den statischen Schemainformationen der alten und neuen Vorlage arbeiten und den dyna-

mischen Aspekt einer Instanz außer Acht lassen.

Eine Instanz weiterzuschalten und gleichzeitig zu migrieren funktioniert somit nur eingeschr¨

ankt:

Einige Aktivit¨

aten m¨

ussen gegen das Weiterschalten gesperrt werden, um eine korrekte Migra-

tion zu garantieren.

Wenn aber die Dauer der Migration einer Instanz kurz oder ungef¨

ahr gleich lang verglichen

mit der durchschnittlichen Zeit ist, die zwischen zwei Zustands¨

anderungen derselben Instanz

aufgrund von Weiterschalten vergeht, dann ist eine sinnvolle Alternative, die Instanz w¨

ahrend

der gesamten Migration komplett gegen das Weiterschalten zu sperren, anstatt nur einige Akti-

vit¨

aten.

F¨

ur die Entscheidung ¨

uber das Verfahren muss aber auch die Verwaltung der Arbeitslisten

ber¨

ucksichtigt werden: Ist es effizienter, nur gezielt einige Arbeitsauftr¨

age aus den Listen zu ent-

fernen und sp¨

ater auch nur wieder einzelne Eintr¨

age dort hineinzustellen, oder ist es effizienter,

alle Eintr¨

age zu einer Instanz zu Beginn der Migration herauszunehmen und am Schluss wieder

alle zu einer Instanz geh¨

origen Eintr¨

age auf einmal einzustellen?

5.7 Migration ↔Vorlagen¨

anderung

Die Migration kann nicht nur mit dem Weiterschalten einer Instanz konkurrieren, sondern auch

mit einer Vorlagen¨

anderung.

Dieser Fall liegt vor, wenn eine Vorlage S0=S+ ∆Sim Rahmen einer Schemaevolution durch

die Modifikationen ∆S0zu S00 =S0+∆S0abge¨

andert wird, gleichzeitig aber noch Instanzen von

der Vorg¨

angerversion Sauf diese Version S0migrieren.

Diesbez¨

uglich ist zu kl¨

aren, ob es dabei zu Problemen kommt und was beachtet werden muss.

Daf¨

ur m¨

ussen die verschiedenen Phasen der Migration getrennt auf Wechselwirkungen mit den

Vorlagen¨

anderungen untersucht werden.

5.7. MIGRATION ↔VORLAGEN ¨

ANDERUNG 81

Vertr¨

aglichkeitspr¨

ufung ↔Vorlagen¨

anderung

F¨

ur die Vertr¨

aglichkeitspr¨

ufung einer Instanz werden die aktuellen Ausf¨

uhrungszust¨

ande be-

stimmter, von den angewendeten Operationen abh¨

angiger Aktivit¨

aten ben¨

otigt und eventuell

Informationen aus der Ausf¨

uhrungshistorie (wenn Sync-Kanten eingef¨

ugt werden) sowie aus der

Datenhistorie (wenn z. B. Datenelemente gel¨

oscht werden) (vgl. [RRD02]). Da die Vorlagen¨

ande-

rung weder den aktuellen Ausf¨

uhrungszustand einer Instanz noch deren Ausf¨

uhrungs- oder Da-

tenhistorie beeinflusst, kommt es zu keinen Wechselwirkungen zwischen der Vorlagen¨

anderung

S0nach S00 und der Vertr¨

aglichkeitspr¨

ufung der Instanz bez¨

uglich S0.

Zur Bestimmung der Menge der f¨

ur die Vertr¨

aglichkeitspr¨

ufung zu untersuchenden Aktivit¨

aten

werden Schemainformationen der Version Sben¨

otigt, nach der die Instanz bisher abgelaufen ist.

Da durch die Schema¨

anderung ∆S0nur die Version S0der Vorlage abge¨

andert wird, auf welche

die Instanz zu migrieren ist, kommt es auch hierbei zu keinen Problemen.

Somit sind f¨

ur diese Phase der Migration keine weiteren Maßnahmen notwendig.

Klasseneinteilung ↔Vorlagen¨

anderung

Um die ¨

Uberlappung der Instanz¨

anderungen einer zu migrierenden, verzerrten Instanz mit den

Schema¨

anderungen ∆S0zu bestimmen, werden u. a. die Schemainformationen der Version S0

ben¨

otigt (vgl. [Ri04]). Da aber die Modifikationen ∆S0auf einer Kopie des Vorlagen-Objekts, das

die Version S0repr¨

asentiert, ausgef¨

uhrt werden, die Schemainformationen aber auf dem origina-

len Vorlagen-Objekt abgegriffen werden, besteht auch in dieser Phase der Migration keine Gefahr

der Wechselwirkung mit den parallel dazu vorgenommenen Schema¨

anderungen. Wiederum sind

keine weiteren Maßnahmen zu treffen.

Migrationsvorbereitung ↔Vorlagen¨

anderung

In der Phase der Migrationsvorbereitung wird bei einer mit dem Bias ∆SIgegen¨

uber Sver-

zerrten Instanz u. a. ¨

uberpr¨

uft, ob deren Migration auf die neue Vorlagenversion S0zu einem

inkorrekten Laufzeitschema SI∗0der Instanz f¨

uhren wird, z. B. weil die auf Instanz- und die auf

Typebene eingef¨

ugten Sync-Kanten nach der Migration zu einem Zyklus im Kontrollfluss f¨

uhren.

Daf¨

ur werden neben den auf Instanz- und Typebene angewandten ¨

Anderungsoperationen ∆SI

und ∆Sdie Schemainformationen der urspr¨

unglichen Vorlagenversion Sben¨

otigt (vgl. [Ri04]).

Da mit der jetzigen Schemaevolution S0→S00 keine dieser Informationen ge¨

andert werden,

kommt es in dieser Beziehung auch in dieser Phase nicht zu Problemen zwischen der parallel

ablaufenden Migration und den Vorlagen¨

anderungen.

Zus¨

atzlich wird in dieser Phase auch der neue Bias ∆S0

Iberechnet, mit dem die bisher mit

dem Bias ∆SIgegen¨

uber Sverzerrte Instanz nach der Migration gegen¨

uber S0verzerrt sein

wird, so dass f¨

ur ihr neues Laufzeitschema SI∗0gilt: SI∗0≡trace S0+ ∆S0

I. Zur Berechnung

von ∆S0

Iwerden neben den auf Instanz- und Typebene vorgenommenen ¨

Anderungen ∆SIund

82 KAPITEL 5. NEBENL ¨

AUFIGKEIT

∆Sdas Laufzeitschema SI∗ ≡trace S+ ∆SIder Instanz vor der Migration und die beiden

Vorlagenversionen Sund S0ben¨

otigt (vgl. [Ri04]). Die Schemaevolution S0→S00 beeinflusst

weder die gemachten ¨

Anderungen ∆SIund ∆Snoch das Laufzeitschema SI∗der Instanz vor

der Migration noch die urspr¨

ungliche Version Sder Prozessvorlage. Aber auch die Vorlage S0

bleibt im System vollst¨

andig erhalten, da die im Rahmen der Vorlagen¨

anderung vorgenommenen

Schemaanpassungen ∆S0auf einer Kopie des Vorlagen-Objekts, das S0repr¨

asentiert, ausgef¨

uhrt

werden und nicht auf dem Original selbst.

Damit st¨

oren bzw. beeinflussen die Vorlagen¨

anderungen auch nicht diese Phase der Migration.

Migrationsvorgang ↔Vorlagen¨

anderung

In dieser Phase des Migrationsprozesses wird eine vertr¨

agliche Instanz auf das Vorlagen-Objekt,

das die neue Vorlagenversion S0repr¨

asentiert, umgeh¨

angt und – wenn n¨

otig – die Delta-Schicht

eingef¨

ugt, die f¨

ur den in der vorangegangenen Migrationsphase berechneten, neuen Bias ∆S0

sorgt. Wie bereits in den Untersuchungen zur vorigen Phase ausgef¨

uhrt, bleibt das Vorlagen-

Objekt unangetastet von den erneuten Vorlagen¨

anderungen ∆S0, da diese auf einer Kopie dieses

Objekts ausgef¨

uhrt werden. Somit kommt es auch hier zu keinen Problemen aufgrund der pa-

rallelen Vorg¨

ange.

Instanzanpassung ↔Vorlagen¨

anderung

Auch die Instanzanpassung wird nicht durch die Vorlagen¨

anderung beeinflusst. Bei der Instanz-

anpassung werden z. B. die Datenstrukturen, welche sich die Zust¨

ande der einzelnen Aktivit¨

aten

merken, um Eintr¨

age f¨

ur die durch die Migration neu hinzugekommenen Aktivit¨

aten erweitert

oder um die f¨

ur gel¨

oschte Aktivit¨

aten reduziert. Die Menge der eingef¨

ugten und gel¨

oschten

Aktivit¨

aten kann allein aus den Betrachtungen der Instanz- und Schema¨

anderungen ∆SIund

∆Sgewonnen werden. Und die neue Vorlagen¨

anderung hat keine Auswirkungen darauf.

Markierungsanpassung ↔Vorlagen¨

anderung

Ausschließlich in der letzten Phase des Migrationsprozesses, der Markierungsanpassung, kann es

zu Wechselwirkungen zwischen der Migration und der Vorlagen¨

anderung kommen.

Bei der Markierungsanpassung werden bestimmte, von den angewandten ¨

Anderungsoperationen

abh¨

angige, bereits aktivierte Aktivit¨

aten in den inaktiven Zustand zur¨

uckgesetzt, andere dage-

gen in den ”AKTIVIERT“-Modus versetzt, der signalisiert, dass diese bereit zur Ausf¨

uhrung

sind. Die Folge ist, dass die infrage kommenden Bearbeiter entsprechende Eintr¨

age in ihre Ar-

beitslisten gestellt bekommen.

Um eine korrekte Markierungsanpassung durchf¨

uhren zu k¨

onnen, werden neben dem aktuel-

len Status der Instanz die Informationen ¨

uber die auf Instanz- und Typebene vorgenommenen

5.8. MIGRATION ↔DYNAMISCHE ¨

ANDERUNGEN 83

Anderungen ∆SIund ∆Sben¨

otigt, sowie die Schemainformationen alter und neuer Version S

bzw. S0. Da die Schema¨

anderungen ∆S0auf einer Kopie von S0ausgef¨

uhrt werden und die an-

deren Informationen auch nicht von der neuen Schemaevolution beeinflusst werden, kommt es

zu keinen Problemen.

Allerdings wurde in Kapitel 5.2 ausgef¨

uhrt, dass das Weiterschalten eine Instanz in einen unver-

tr¨

aglichen Zustand mit den parallel dazu durchgef¨

uhrten ¨

Anderungen ihrer Vorlage bringen kann

und dass dies durch Sperren der ganzen Instanz oder der unmittelbar betroffenen Aktivit¨

aten

ganz oder zumindest teilweise verhindert werden kann.

Werden nun w¨

ahrend der Vorlagen¨

anderung S0nach S00 die auf S0basierenden Instanzen oder

wenigstens die von den ¨

Anderungen ∆S0betroffenen Aktivit¨

aten gegen ein Weiterschalten ge-

sperrt, dann muss dies bei der Markierungsanpassung einer Instanz beachtet werden, die von

der Version Sauf S0migriert. Es muss verhindert werden, dass Arbeitsauftr¨

age zu den neu

aktivierten Aktivit¨

aten in die Arbeitslisten der zugeordneten Bearbeiter gestellt werden, wenn

die entsprechenden Aktivit¨

aten als gesperrt markiert worden sind.

Zusammengefasst kann gesagt werden, dass nichts gegen die Migration einer Instanz auf eine

Version der Vorlage spricht, die zeitgleich erneut abge¨

andert wird. Einzig und allein die Sper-

ren, die gesetzt werden, um eine Unvertr¨

aglichkeit aufgrund von Weiterschalten zu verhindern,

m¨

ussen bei der Markierungsanpassung beachtet werden.

5.8 Migration ↔Dynamische ¨

Anderungen

Komplizierter ist die Situation zwischen den konkurrierenden Aktionen Migration und dynami-

sche ¨

Anderung der zu migrierenden Instanz.

In dieser Situation wird versucht, eine eventuell schon verzerrte Instanz I, die gerade im Begriff

ist, von der Vorlagenversion Snach S0zu migrieren, dynamisch (erneut) in ihrem Laufzeitsche-

ma zu ¨

andern. Da sowohl die Migration als auch die dynamische ¨

Anderung Modifikationen an

dem Laufzeitschema der Instanz und an dem diese Instanz repr¨

asentierenden Instanz-Objekt

vornehmen und zus¨

atzlich beide den Zustand der Instanz anpassen, sind Konflikte zu erwarten.

Dieser Abschnitt kl¨

art, wann Konflikte auftreten und was getan werden muss, um diese zu

verhindern.

In der ersten Phase der Migration, der Vertr¨

aglichkeitspr¨

ufung, kommt es zu keinen Konflikten,

wenn die Instanz parallel dazu abge¨

andert wird: Keine Instanz¨

anderung f¨

uhrt dazu, dass eine

bisher noch nicht ausgef¨

uhrte Aktivit¨

at in den Zustand ”IN AUSF¨

UHRUNG“ gelangt. Da f¨

die Unvertr¨

aglichkeit einer Instanz mit den Schema¨

anderungen aber ausschließlich Aktivit¨

aten

verantwortlich sind, die sich mindestens im Zustand ”IN AUSF¨

UHRUNG“ befinden, kann sich

der Vertr¨

aglichkeitsstatus einer Instanz durch deren Ad-hoc-Modifikation nicht ¨

andern.

Auch kommt es zu keinen Konflikten, wenn im Rahmen der Vertr¨

aglichkeitspr¨

ufung der Zu-

stand einer Aktivit¨

at ¨

uberpr¨

uft werden muss, die im Rahmen der Instanz¨

anderung zuvor her-

84 KAPITEL 5. NEBENL ¨

AUFIGKEIT

ausgel¨

oscht worden ist. Der Zustand dieser Aktivit¨

at kann automatisch als vertr¨

aglich ange-

nommen werden, denn diese Aktivit¨

at konnte vor dem L¨

oschen maximal aktiviert gewesen sein.

Ansonsten h¨

atte sie nicht im Rahmen der Ad-hoc-Modifikation gel¨

oscht werden k¨

onnen.

Erst bei der Klasseneinteilung, der zweiten Phase des Migrationsprozesses, k¨

onnen Probleme

auftreten.

In dieser Phase des Migrationsprozesses wird bestimmt, inwieweit sich die dynamischen ¨

Ande-

rungen der zu migrierenden Instanz mit den Schema¨

aenderungen ¨

uberlappen. F¨

ur die Bestim-

mung des ¨

Uberlappungsgrades muss ein stabiles Laufzeitschema der Instanz vorliegen, ansonsten

kommt es zu einem inkorrekten Ergebnis, wie im folgenden veranschaulicht wird.

F¨

ur die Bestimmung ist neben vielen weiteren Informationen das Ergebnis eines Vergleichs zwi-

schen der Menge der auf Instanzebene eingef¨

ugten Aktivit¨

aten und der Menge der auf Typebene

eingef¨

ugten Aktivit¨

aten relevant [Ri04]1. Die Aktivit¨

aten, die im Rahmen einer zu der Migra-

tion parallel erfolgenden Instanz¨

anderung eingef¨

ugt werden, m¨

ussen bei diesem Vergleich mit

einbezogen werden. Wird aber eine Aktivit¨

at erst eingef¨

ugt, nachdem dieser Vergleich bereits er-

folgt ist, dann spiegelt das Ergebnis des Vergleichs nicht mehr die nun gegebene Situation wider

und die ¨

Uberlappungsbestimmung erfolgt auf Basis veralteter Informationen. Im Allgemeinen

wird dann ein ¨

Uberlappungsgrad ermittelt, der von dem aktuell zwischen Instanz¨

anderung und

Schema¨

anderung vorherrschenden ¨

Uberlappungsgrad abweicht.

Um also ein korrektes Ergebnis liefern zu k¨

onnen, muss w¨

ahrend der Phase der Klasseneinteilung

ein stabiles Laufzeitschema der zu migrierenden Instanz vorliegen. Somit darf sich die Instanz

in dieser Phase nicht ¨

andern.

Der bestimmte ¨

Uberlappungsgrad legt fest, wie die Instanz in der vierten Phase an die neue

Version ihrer Vorlage angepasst werden muss. Deshalb d¨

urfen bis zu der erfolgten Anpassung

keine ¨

Anderungen an der Instanz durchgef¨

uhrt werden, die den ¨

Uberlappungsgrad ¨

andern und

damit das Ergebnis der Klasseneinteilung ad absurdum f¨

uhren.

Die Migration einer Instanz auf Basis inkorrekt gewordener Informationen bez¨

uglich des ¨

Uber-

lappungsgrades f¨

uhren zu Inkonsistenzen bzw. ”verlorenen“ ¨

Anderungen, wie Abbildung 5.12

zeigt.

Die abgebildete Instanz I ist zum Zeitpunkt der Klasseneinteilung gegen¨

uber ihrer Vorlage S

mit dem Bias ∆SI={insertActivity(A23, A2, A3)}verzerrt und weist damit ihr gegen¨

uber

die zus¨

atzliche Aktivit¨

at A23 auf. Im Rahmen der Schemaevolution, welche die Vorlage Sin

die neue Version S0¨

uberf¨

uhrt, wird diese Aktivit¨

at allerdings auch auf Typebene hinzugef¨

ugt.

Da auf Instanzebene keine weiteren ¨

Anderungen vorgenommen worden sind, auf Typebene aber

zus¨

atzlich noch die Aktivit¨

at A12 eingef¨

ugt worden ist, wird im Rahmen der Klasseneinteilung

f¨

ur den ¨

Uberlappungsgrad zwischen der Instanz¨

anderung ∆SIund den Schema¨

anderungen ∆S

bestimmt: ∆SIist subsumptions-¨

aquivalent zu den Schema¨

anderungen ∆S. Die richtige Migra-

tionsstrategie zur Anpassung der Instanz an die neue Vorlage lautet hierf¨

ur, wie in Kapitel 3.6

1In [Ri04] ist detailliert beschrieben, wie der ¨

Uberlappungsgrad bestimmt wird und welche Informationen dazu

notwendig sind.

5.8. MIGRATION ↔DYNAMISCHE ¨

ANDERUNGEN 85

InstanzI

A1 A2 A3 A4

A1 A2* A23 A4A3*

A2 A23A1 A12 A3

InstanzI

ProzessvorlageS

A1 A2 A3

A2 A23A1 A12 A3

A4 A4

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={insertActivity(A12, A1, A2),insertActivity(A23, A2, A3)}

DS ={insertActivity(A23, A2, A3)}I

InstanzI

A1 A2 A3 A4

A1 A2* A23 A4A3*

A23 A3** A34 A4*

DS ={insertActivity(A23, A2, A3),insertActivity(A34, A3, A4)}I

Überlappungsgrad: SIistsubsumptionsäquivalentzu SD D

MigrationgemäßStategie

fürsubsumptions-äquivalente

Instanzänderungen

A2 A23A1 A12 A3

InstanzI

A2 A23A1 A12 A3

InstanzI

A23 A3* A34 A4*

Überlappungsgrad: S istpartielläquivalentzu SD DI

MigrationgemäßStategie

fürsubsumptions-äquivalente

Instanzänderungen

MigrationgemäßStategie

fürpartielläquivalente

Instanzänderungen

zusätzliche

Adhoc-Modifikation:

insertActivity(A34, A3, A4)

Abbildung 5.12: Inkorrekte Migration aufgrund falscher Informationen ¨

uber ¨

Uberlappungsgrad

beschrieben: Das diese Instanz repr¨

asentierende Instanz-Objekt ist einfach direkt auf das neue

Vorlagen-Objekt umzuh¨

angen, die existierenden Delta-Schichten sind zu verwerfen. Mit dem

Umh¨

angen auf das neue Vorlagen-Objekt wird – logisch gesehen – die zus¨

atzliche Modifikation

insertActivity(A12, A1, A2) auf Instanzebene nachgezogen.

Wird nun aber auf Instanzebene noch zus¨

atzlich die Aktivit¨

at A34 eingef¨

ugt, dann sind die In-

stanz¨

anderungen nicht mehr subsumptions-¨

aquivalent zu den Schema¨

anderungen sondern par-

tiell ¨

aquivalent, d. h. der ¨

Uberlappungsgrad hat sich ge¨

andert. Wie zuvor muss die Instanz

nach der Migration das neue Vorlagen-Objekt (indirekt) referenzieren. Zwischen dem Instanz-

Objekt und dem Vorlagen-Objekt muss aber im Falle einer korrekten, dem neuen ¨

Uberlappungs-

grad gem¨

aßen Migration noch eine Delta-Schicht liegen, welche die resultierende Verzerrung

∆SI\∆S={insertActivity(A34, A3, A4)}der Instanz gegen¨

uber der neuen Schemaversion S0

repr¨

asentiert.

Erfolgt die zweite Instanz¨

anderung insertActivity(A34, A3, A4) aber erst nach der Bestim-

mung des ¨

Uberlappungsgrades, dann wird der ¨

Uberlappungsgrad nicht erneut bestimmt, die

Instanz¨

anderungen werden f¨

alschlicherweise weiterhin als subsumptions-¨

aquivalent zu den Sche-

ma¨

anderungen betrachtet und die Migration folgt einer falschen Strategie. Die Folge ist, dass

86 KAPITEL 5. NEBENL ¨

AUFIGKEIT

die die Verzerrung ∆SI\∆S={insertActivity(A34, A3, A4)}repr¨

asentierende Delta-Schicht

nicht aufgebaut wird, da die Migrationsstrategie auf der Tatsache beruht, dass Instanzen, bei

denen die Instanz¨

anderungen subsumptions-¨

aquivalent zu den Schema¨

anderungen sind, stets ge-

gen¨

uber der neuen Vorlage unverzerrt sind und deshalb die Bildung einer Delta-Schicht nicht

notwendig ist.

Somit muss verhindert werden, dass bis zum Abschluss der vierten Phase Ad-hoc-¨

Anderungen

der Instanz vorgenommen werden k¨

onnen.

Wird die Instanz sofort nach dem Umh¨

angen auf das neue Vorlagen-Objekt am Ende der vierten

Phase des Migrationsprozesses zur ¨

Anderung freigegeben, dann ist folgender Konflikt denkbar:

InstanzI

A1 A2 A3

ProzessvorlageS

A1 A2 A3

A1 A3

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={deleteActivity(A2)}

A1:

A3:

A2:

S’

InstanzI

A1:

A3:

A2:

A1 A3

S’

InstanzI

A1:

A3:

A2:

A1 A3

A1* A2 A3*

S’

InstanzI

A1:

A3:

A1 A3

A1* A2 A3*

Umhängenaufdas

neueVorlagen-Objekt

infolgederMigration

Instanzänderung

DS ={insertActivity(A2, A1, A3)}I

Zeit t0 t1 t2

Instanzanpassung

infolgederMigration

Zustandseintrag

für A2fehlt!

Abbildung 5.13: Scheinbarer Konflikt bei parallel erfolgender Instanzanpassung und -¨

anderung

Das L¨

oschen der Aktivit¨

at A2 aus der in Abbildung 5.13 gezeigten Instanz I hat zur Folge,

dass alle Eintr¨

age im Rahmen der Instanzanpassung bez¨

uglich A2 aus dem Instanz-Objekt

herausgel¨

oscht werden. Wird aber noch vor dem L¨

oschen der Eintr¨

age dieselbe Aktivit¨

at durch

eine Instanz¨

anderung wieder eingef¨

ugt, dann f¨

uhrt das anschließende L¨

oschen der Eintr¨

age im

Rahmen der Instanzanpassung augenscheinlich zu folgender Inkonsistenz: Die Aktivit¨

at A2 ist

im Schema der Instanz I existent, sie wird aber in der Datenstruktur, welche die Zust¨

ande

5.8. MIGRATION ↔DYNAMISCHE ¨

ANDERUNGEN 87

speichert, nicht mehr gef¨

uhrt. In diesem Fall k¨

onnte der Zugriff auf die Zustandsinformationen

dieser Aktivit¨

at zu einem undefinierten Verhalten des Systems f¨

uhren.

InstanzI

A1 A2 A3

ProzessvorlageS

A1 A2 A3

A1 A3

Schemaevolution

S S'

S->S’=S+DS

imRahmenderSchemaevolutioneingefügte Aktivität

DS={deleteActivity(A2)}

A1:

A3:

A2:

S’

InstanzI

A1:

A3:

A2:

A1 A3

S’

InstanzI

A1:

A3:

A2:

A1 A3

A1* A2_ A3*

S’

InstanzI

A1:

A3:

A1 A3

A1* A2_ A3*

Umhängenaufdas

neueVorlagen-Objekt

infolgederMigration

Instanzänderung

DS ={insertActivity(A2, A1, A3)}I

Zeit t0 t1 t2

Instanzanpassung

infolgederMigration

A2_: A2_:

Abbildung 5.14: Konfliktlose parallel erfolgende Instanzanpassung und -¨

anderung

In der Praxis wird dieses Problem allerdings nicht auftreten, wie Abbildung 5.14 zeigt. Auch

wenn die gel¨

oschte und die eingef¨

ugte Aktivit¨

at als dieselben betrachtet werden, so unterschei-

den sie sich im System dennoch durch unterschiedliche IDs. In Abbildung 5.14 wird dies durch

den zus¨

atzlichen Unterstrich bei der im Rahmen der Ad-hoc-Modifikation eingef¨

ugten Aktivit¨

A2 verdeutlicht. ¨

Uber die ID wird im Allgemeinen in der Instanz der Zugriff auf die Zustands-

informationen einer Aktivit¨

at erfolgen. Deshalb wird mit dem erneuten Einf¨

ugen der Aktivit¨

A2 parallel zu dem bereits existierenden ein weiterer Eintrag in der Datenstruktur angelegt, auf

den mit der neuen ID der Aktivit¨

at zugegriffen werden kann. Im Rahmen der Instanzanpassung

wird dann der alte Eintrag gel¨

oscht, der neue bleibt dagegen unangetastet: Es tritt kein Konflikt

auf.

Auch in der Phase der Markierungsanpassung kommt es zu keinen Problemen durch parallel

erfolgende Instanz¨

anderungen.

88 KAPITEL 5. NEBENL ¨

AUFIGKEIT

5.9 Zusammenfassung

Dieses Kapitel zeigt, dass bei der Schemaevolution, Migration und bei Instanz¨

anderungen Kon-

flikte aufgrund von konkurrierenden Aktionen auftreten k¨

onnen. Damit ein korrekter Ablauf

dieser adaptiven Vorg¨

ange gew¨

ahrleistet ist, m¨

ussen konfliktverursachende konkurrierende Ak-

tionen synchronisiert werden.

Viele dieser Konflikte lassen sich z. B. durch den Einsatz von Sperren vermeiden, ohne den

parallelen Ablauf der konfliktverursachenden Aktionen v¨

ollig zu unterbinden. Es hat sich aber

gezeigt, dass es aus pragmatischen Gr¨

unden auch sinnvoll sein kann, die Nebenl¨

aufigkeit dieser

Aktionen ganz zu verhindern. Beide Strategien weisen Vor- und Nachteile auf. Welche Strategie

gew¨

ahlt wird, muss von Fall zu Fall abh¨

angig vom Einsatzszenario abgewogen werden.

Damit bei dem Einsatz von Sperren die Sperrverwaltung nicht zum Flaschenhals wird, wenn viele

Zugriffe darauf gleichzeitig erfolgen, muss eine von der Performance her effiziente Implementie-

rung der Sperren gefunden werden. Die im Umfeld von Datenbanken gewonnenen Erkenntnisse

uber die Sperrverwaltung k¨

onnen hierf¨

ur hilfreich sein.

Kapitel 6

Zusammenfassung

Ziel dieser Diplomarbeit ist es, Konzepte f¨

ur die effiziente Realisierung der Prozess-Schemaevolu-

tion mit anschließender Instanz-Migration in einem Hochleistungs-Prozess-Management-System

vorzustellen.

Voraussetzung f¨

ur eine effiziente Realisierung der Prozess-Schemaevolution mit anschließender

Instanz-Migration ist, dass eine geeignete interne Repr¨

asentationsform f¨

ur Prozessvorlagen und

-instanzen vorliegt, die sowohl die Schemaevolution mit der anschließenden Migration der auf

der ge¨

anderten Vorlage basierenden Instanzen, als auch das dynamische ¨

Andern einer Instanz

gegen¨

uber ihrer Vorlage auf effiziente Art und Weise erm¨

oglicht, gleichzeitig aber auch einen

geringen Speicherbedarf aufweist.

Mit der in Kapitel 3 vorgestellten Architektur wurde eine interne Repr¨

asentationsform f¨

Prozessvorlagen und -instanzen gefunden, die dieses Ziel erf¨

ullt und f¨

ur den Einsatz in einem

Hochleistungs-Prozess-Management-System geeignet ist: Die Architektur ist in der Lage, sowohl

unverzerrte als auch verzerrte Instanzen speichersparend darzustellen und garantiert eine effizi-

ente Schemaevolution mit anschließender Migration der auf der ge¨

anderten Vorlage basierenden

Instanzen.

Der entscheidende Grundgedanke bei deren Entwicklung bestand darin, alle Instanzen dessel-

ben Prozesstyps dasselbe Vorlagen-Objekt referenzieren zu lassen und das zu diesem Prozesstyp

geh¨

orige Ablaufschema alleine in diesem Vorlagen-Objekt zu halten, anstatt in jedem Instanz-

Objekt repliziert. Damit kann nicht nur der Speicherbedarf gering gehalten werden, es erm¨

oglicht

auch eine effiziente Migration der vertr¨

aglichen, unverzerrten Instanzen nach einer Schemaevolu-

tion. Die Instanzen m¨

ussen dazu nur von dem Vorlagen-Objekt, das die alte Version der Vorlage

repr¨

asentiert, auf das durch die Schemaevolution neu hervorgegangene Vorlagen-Objekt um-

geh¨

angt werden. Mit dem Umh¨

angen werden – logisch gesehen – die Schema¨

anderungen auf den

Laufzeitschemata der Instanzen nachgezogen. Nicht physisch irgendwelche Schemata f¨

ur eine

Anpassung der zu migrierenden Instanzen auf die neue Vorlagenversion ¨

andern zu m¨

ussen, wie

es bei der Variante der Fall ist, bei der bei jeder Instanz das zu ihr geh¨

orige Schema explizit

90 KAPITEL 6. ZUSAMMENFASSUNG

gespeichert wird, bewirkt einen enorm positiven Effekt auf die Effizienz von Migrationen, denn

das physische ¨

Andern eines Schemas ist gegen¨

uber einer einfachen Referenz-Anpassung eine

vergleichsweise aufw¨

andige und teure Operation.

F¨

ur die Repr¨

asentation einer ad hoc ge¨

anderten Instanz wurde die Delta-Schicht eingef¨

uhrt.

Das Delta-Schicht-Objekt repr¨

asentiert die durch die Ad-hoc-Modifikation entstandene Abwei-

chung der Instanz von ihrer Vorlage. Das Delta-Schicht-Objekt wird zwischen das zu der Instanz

geh¨

orige Instanz-Objekt und das Vorlagen-Objekt geh¨

angt oder auf ein weiteres Delta-Schicht-

Objekt gestapelt. Das typ-bestimmende Vorlagen-Objekt und die Delta-Schicht-Objekte bilden

zusammen das (ge¨

anderte) Laufzeitschema der Instanz. Eine Alternative wurde diskutiert: Das

gegen¨

uber der Vorlage abge¨

anderte Laufzeitschema kann auch durch eine Kopie des entsprechen-

den Vorlagen-Objekts repr¨

asentiert werden, auf dem die Instanz¨

anderungen eingespielt worden

sind. Der Nachteil dieses Ansatzes ist, dass durch jedes Kopieren nicht nur die anzupassenden

Prozessabschnitte vervielf¨

altigt werden, sondern auch die unge¨

anderten. Die Folge ist, dass da-

mit die unge¨

anderten Prozessabschnitte u. U. mehrfach redundant im System hinterlegt werden.

Der Delta-Schicht-Ansatz vervielf¨

altigt dagegen nur die Prozessabschnitte, die dann angepasst

werden und vermeidet so Redundanzen. Gegen¨

uber der anderen Variante kann dadurch erheblich

Speicher eingespart werden.

Die Migration von verzerrten Instanzen erfolgt genauso effizient wie bei unverzerrten: Die Instanz

wird auf das neue Vorlagen-Objekt umgeh¨

angt. Davon abweichend muss nur noch bei Instanzen,

die auch noch nach der Migration gegen¨

uber ihrer Vorlage verzerrt sind, zwischen das Instanz-

Objekt und das neue Vorlagen-Objekt ein Delta-Schicht-Objekt eingef¨

ugt werden, das den neuen

Bias repr¨

asentiert.

Basierend auf dieser Architektur wurden zwei Optimierungsans¨

atze diskutiert, die das Ziel hat-

ten, die Migration zu beschleunigen.

Der Grundgedanke hinter den Optimierungsans¨

atzen ist, bei einigen Instanzen Schritte des Mi-

grationsprozesses einzusparen.

Beim ersten Optimierungsansatz werden unverzerrte Instanzen nach ihrem Laufzeitzustand

gruppiert, d. h. alle Instanzen, die denselben Zustand aufwiesen, geh¨

oren einer Gruppe an. Im

Rahmen der Migration muss der Vertr¨

aglichkeitstest dann nur f¨

ur eine Instanz dieser Gruppe

durchgef¨

uhrt werden, das Ergebnis kann dann auf alle Instanzen derselben Gruppe ¨

ubertragen

werden. Es konnte gezeigt werden, dass sich bei der vorgestellten Implementierungsvariante so-

gar die Zahl der bei der Migration anfallenden Umh¨

ang-Vorg¨

ange von Instanzen auf das neue

Vorlagen-Objekt reduzieren l¨

asst: Referenzieren alle Instanzen einer Gruppe das zugrunde lie-

gende Vorlagen-Objekt statt direkt nur indirekt ¨

uber das gemeinsame Zustandsobjekt, dann

muss bei der Migration nur das Zustandsobjekt auf das neue Vorlagen-Objekt umgeh¨

angt wer-

den und alle das Zustandsobjekt referenzierenden Instanzen sind implizit mit umgeh¨

angt und

damit auf die neue Version der Vorlage migriert. Dass der Zustand nur einmal pro Gruppe

in dem Zustandsobjekt gemerkt wird und nicht explizit in allen Instanzen, hat nebenbei noch

den Vorteil, dass auch die im Rahmen der Migration im Allgemeinen anfallende Instanz- und

Markierungsanpassung nur einmal pro Gruppe und nicht f¨

ur jede Instanz einzeln vorgenom-

men werden muss. Allerdings hat sich gezeigt, dass damit zwar die Migration der Instanzen

beschleunigt werden kann, dass dies aber erheblich zu Lasten der Effizienz des Weiterschaltens

von Instanzen geht, da bei jedem Weiterschalten die entsprechende Instanz auf ein neues, den

neuen Zustand repr¨

asentierendes Zustandsobjekt umgeh¨

angt werden muss. Dabei kommt es zu

besonders großen Verz¨

ogerungen, wenn zu dieser Zeit das Zustandsobjekt noch nicht existiert

und deshalb erst noch erstellt werden muss.

Der zweite Optimierungsansatz, die Meilenstein-Ansatz, unterteilt den Prozessgraphen in meh-

rere Abschnitte. Zu jedem Abschnitt wird gemerkt, welche Instanzen diesen Bereich bereits

betreten, aber noch nicht ¨

uberschritten haben. Alle unverzerrten Instanzen, die noch nicht den

ersten Abschnitt einer ¨

Anderung betreten haben, k¨

onnen dann automatisch als vertr¨

aglich mit

den ¨

Anderungen betrachtet werden, ohne explizit eines Vertr¨

aglichkeitstests unterzogen zu wer-

den1. Sind die Meilensteine ausschließlich an den Stellen des Prozessgraphen gesetzt, bei denen

genau ein Ausf¨

uhrungspfad vorliegt und nicht mehrere, parallel oder alternativ angeordnete,

dann k¨

onnen alle Instanzen, die den ersten Bereich einer ¨

Anderung bereits ¨

uberschritten haben,

ohne eine Vertr¨

aglichkeitspr¨

ufung als unvertr¨

aglich von der Migration ausgeschlossen werden,

sofern keine Sync-Kanten im Rahmen der ¨

Anderungstransaktion eingef¨

ugt worden sind. Dadurch

k¨

onnen auch bei diesem Verfahren f¨

ur einige Instanzen Schritte des Migrationsprozesses einge-

spart werden, womit der gesamte Migrationsvorgang nach einer Schemaevolution beschleunigt

werden kann. Allerdings geschieht dies nicht in dem Maße, wie es bei entsprechender Imple-

mentierung bei dem Verfahren der Fall ist, bei dem die Instanzen nach dem Zustand gruppiert

werden: Die Meilenstein-Methode bietet nicht die M¨

oglichkeit, mehrere Instanzen gleichzeitig

auf das neue Vorlagen-Objekt umzuh¨

angen, oder gleichzeitig die Instanz- bzw. die Markierungs-

anpassung durchzuf¨

uhren. Gegen¨

uber der Methode mit den Zustandsgruppierungen weist dieses

Verfahren jedoch einen erheblich geringeren negativen Effekt auf die Funktion des Weiterschal-

tens von Instanzen auf: Instanzen m¨

ussen beim Weiterschalten nur umgeh¨

angt werden, wenn

dabei ein Meilenstein ¨

uberschritten wird. Trotzdem ist ein jedes Weiterschalten stets etwas

verz¨

ogert, da jedesmal ¨

uberpr¨

uft werden muss, ob nicht ein Meilenstein ¨

uberschritten wird.

Die Verz¨

ogerungen beim Weiterschalten f¨

uhrten zu der berechtigten Frage, ob der Einsatz die-

ser Verfahren ¨

uberhaupt sinnvoll ist, da das Weiterschalten von Instanzen zu den am h¨

aufigsten

aufzutretenden Ereignissen bei Prozess-Management-Systemen z¨

ahlt und damit besonders effi-

zient implementiert geh¨

ort. Die Migration von Instanzen kommt verglichen dazu relativ selten

vor. Als Alternative wurde vorgeschlagen, die Migration in Zeiten geringer Last des Systems zu

verlegen, um damit die anderen Funktionen des Systems so wenig wie m¨

oglich zu st¨

oren.

Bei der Realisierung der Adaptivit¨

at in Hochleistungs-Prozess-Management-Systemen m¨

ussen

auch die Probleme ber¨

ucksichtigt werden, die durch die in einer Mehrbenutzerumgebung zwangs-

weise auftretenden konkurrierenden Aktionen entstehen, um eine korrekte und reibungslose Sche-

maevolution, Migration und Ad-hoc-Modifikation von Instanzen zu garantieren.

Kapitel 5 besch¨

aftigte sich mit diesen Problemen, die bei dem Einsatz der in Kapitel 3 entwi-

ckelten Architektur auftreten k¨

onnen, und erarbeitete Konzepte, wie sie sich vermeiden oder

1Ausnahme: Datenelemente wurden im Rahmen der ¨

Anderungstransaktion gel¨

oscht.

92 KAPITEL 6. ZUSAMMENFASSUNG

beheben lassen. Dazu wurde untersucht, inwieweit sich die drei Mechanismen der Adaptivit¨

und zus¨

atzlich das Weiterschalten bei der gegebenen Architektur gegenseitig und untereinander

beeinflussen. Nachdem die Probleme – sofern vorhanden – identifiziert wurden, wurden L¨

osungs-

vorschl¨

age erarbeitet, um diese von vornherein zu vermeiden oder im Nachhinein aufzul¨

osen.

Zusammenfassend kann gesagt werden, dass mit der Architektur aus Kapitel 3 unter Ber¨

ucksich-

tigung der in Kapitel 5 herausgearbeiteten Erkenntnisse eine f¨

ur den Einsatz in Hochleistungs-

Prozess-Management-Systemen geeignete Realisierungsvariante gefunden wurde, die eine effi-

ziente und auch in einer Mehrbenutzerumgebung korrekt ablaufende Prozess-Schemaevolution

erm¨

oglicht.

Literaturverzeichnis

[Aa01] Van der Aalst, W. M. P.: Exterminating the Dynamic Change Bug : A Concrete

Approach to support Workflow Change. Information Systems Frontiers 3(3), 2001,

Seite 297-317

[ADK99] van der Aalst, W.; Desel, J.; Kaschek, R. (Eds.): Proc. Software Architecture for

Business Process Management (SABPM ’99), Workshop at the CAiSE ’99, Heidel-

berg, Bericht 390, Juni 1999

[AJ00] Van der Aalst, W.M.P.; Jablonski, S.: Dealing with Workflow Change: Identification

of Issues and Solutions. Int’l Journal of Computer Systems, Science, and Engineering,

Vol. 15, No. 5, 2000, Seite 267-276

[AM00] Agostini, A.; de Michelis, G.: Improving Flexibility of Workflow Management Sys-

tems. Proc. of the Int’l Conf. on Business Process Managemant (BPM ’00), LNCS

1806, Springer, 2000, Seite 218-234

[BGL03] Bausch, T; Gromer, S.; Lauer, M.: Dokumentation zum Praktikum Implementie-

rungsaspekte von Workflow-Management-Systemen. Praktikumsbericht, Abt. DBIS,

Universit¨

at Ulm, 2003

[BRD01] Bauer, T.; Reichert, M.; Dadam, P.: Adaptives und verteiltes Workflow-

Management. In: [HLP01], Seite 47-66

[CCPP98] Casati, F.; Ceri, S.; Pernici, B.; Pozzi, G.: Workflow Evolution. Data and Knowledge

Engineering, Vol. 24, No. 3, Januar 1998, Seite 211-238

[DR04] Dadam, P.; Reichert, M. (Hrsg.) Informatik 2004 - Informatik verbindet - Band 2:

Beitr¨

age der 34. Jahrestagung der Gesellschaft f¨

ur Informatik e. V. (GI). Proceedings

34. Jahrestagung der GI, 20.-24. September 2004, Ulm, Gesellschaft f¨

ur Informatik,

2004

[HLP01] Heuer, A.; Leymann, F.; Priebe, D. (Hrsg.): Proc. Datenbanksysteme in B¨

uro, Tech-

nik und Wissenschaft, Oldenburg, M¨

arz 2001. Springer Verlag, 2001

94 LITERATURVERZEICHNIS

[KG99] Kradolfer, M.; Geppert, A.: Dynamic Workflow Schema Evolution Based on Work-

flow Type Versioning and Workflow Migration. Proc. Int’l Conf. on Cooperative

Information Systems, CoopIS ’99, Edinburgh, Schottland, September 1999, Seite

104-114

[LRR04] Lauer, M.; Rinderle, S.; Reichert, M.: Repr¨

asentation von Schema- und Instanzob-

jekten in adaptiven Prozess-Management-Systemen. In: [DR04], Seite 555-560

[LR00] Leymann, F.; Roller, D.: Production Workflow: Concepts and Techniques. Prentice

Hall PTR, 2000

[RD98] Reichert, M.; Dadam, P.: ADEPTflex - Supporting Dynamic Changes of Workflows

Without Losing Control. Journal of Intelligent Information Systems, Kluwer Acade-

mic Publ., Vol. 10, No. 2, March/April 1998, Seite 93-129

[RD02] Reichert, M.; Dadam, P.: Workflow-Management-Systeme: Grundlagen, Einsatz und

Implementierung. Skript zur Vorlesung, Universit¨

at Ulm, Abt. DBIS, WS 2002/2003

[Re00] Reichert, M.: Dynamische Ablauf¨

anderungen in Workflow-Management-Systemen.

Dissertation, Universit¨

at Ulm, Fakult¨

at f¨

ur Informatik, Mai 2000

[Ri04] Rinderle, S.: Schema Evolution in Process Management Systems. Dissertation, Uni-

versit¨

at Ulm, Fakult¨

at f¨

ur Informatik, 2004

[RRD02] Rinderle, S.; Reichert, M.; Dadam, P.: Effiziente Vertr¨

aglichkeitspr¨

ufung und au-

tomatische Migration von Workflow-Instanzen bei der Evolution von Workflow-

Schemata. Informatik - Forschung und Entwicklung, Band 17, 2002, Seite 177-197

(auch: Ulmer Forschungsberichte, Nr. 2002-01, April 2002)

[RRD03a] Rinderle, S.; Reichert, M.; Dadam, P.: On Dealing With Semantically Conflicting

Business Process Changes. Ulmer Informatik-Berichte, Nr. 2003-04, Juni 2003

[RRD03b] Reichert, M.; Rinderle, S.; Dadam, P.: On the Common Support of Workflow Type

and Instance Changes Under Correctness Constraints. Proc. Int’l Conf. on Coope-

rative Information Systems, CoopIS ’03, Catania, Sizilien, Italien, November 2003

[RRD04] Rinderle, S.; Reichert, M.; Dadam, P.: Correctness Criteria for Dynamic Changes in

Workflow Systems - A Survey. Data and Knowledge Engineering, 2004

[SO99] Sadiq, S.W.; Orlowska, M.E.: Architectural Considerations for Systems Supporting

Dynamic Workflow Modification. In: [ADK99], Seite 118-134

[We97] Weilbach, P.: Implementierungsaspekte zur Verwaltung und Synchronisation dy-

namischer ¨

Anderungen in prozeßorientierten Workflow-Management-Systemen. Di-

plomarbeit, Universit¨

at Ulm, Abt. DBIS, 1997

LITERATURVERZEICHNIS 95

[We01] Weske, M.: Formal Foundation and Conceptual Design of Dynamic Adaptations in

a Workflow Management System. Proc. 34th Hawaii Int’l Conf. on System Sciences,

2001

Abbildungsverzeichnis

1.1 Service Flows und Services (in Anlehnung an [RD02, Abb. 6-13]) . . . . . . . . . 3

1.2 Das Schema S und darauf basierende Instanzen . . . . . . . . . . . . . . . . . . . 4

1.3 Schemaevolution von Snach S0mit anschließender Migration der Instanzen . . . 6

1.4 Dynamische ¨

Anderung/Ad-hoc-Modifikation einer Instanz . . . . . . . . . . . . . 7

2.1 Zyklus im Prozessgraph aufgrund unkontrollierten Einf¨

ugens einer Sync-Kante . 12

2.2 Deadlock bei der Prozessausf¨

uhrung aufgrund eines Zyklus im Prozessgraph . . . 13

2.3 Zustandsdiagramm f¨

ur eine Schemaevolution . . . . . . . . . . . . . . . . . . . . 14

2.4 Beispielmigration einer unverzerrten Instanz . . . . . . . . . . . . . . . . . . . . . 16

2.5 Beispielmigration verzerrter Instanzen mit unterschiedlichem ¨

Uberlappungsgrad . 17

2.6 Konflikte bei der Migration bei partiell ¨

aquivalenten ¨

Anderungsarten . . . . . . . 20

2.7 Inkorrekte Laufzeitschemata nach Migration verzerrter Instanzen . . . . . . . . . 21

2.8 Ausf¨

uhrungshistorien und Migration . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.9 Die Laufzeitzust¨

ande und Arbeitslisteneintr¨

age von I vor der Migration, nach

Anwendung von ∆Saber bei noch nicht erfolgter Markierungsanpassung und

nacherfolgterAnpassung................................ 25

2.10 Das Zustandsdiagramm zur Migration. . . . . . . . . . . . . . . . . . . . . . . . . 26

2.11 Das Zustandsdiagramm zur dynamischen ¨

Anderung einer Instanz. . . . . . . . . 28

3.1 Naiver Ansatz, Instanzen zu repr¨

asentieren ..................... 31

3.2 Die Repr¨

asentation von Instanzen eines Prozesstyps . . . . . . . . . . . . . . . . 32

3.3 Migration durch direkte Ab¨

anderung der Vorlage . . . . . . . . . . . . . . . . . . 33

ABBILDUNGSVERZEICHNIS 97

3.4 Fehlende Typ-Zugeh¨

origkeit nach einer dynamischen ¨

Anderung . . . . . . . . . . 34

3.5 Das Konzept der Delta-Schicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6 Serielles Einf¨

ugen einer Aktivit¨

at infolge einer Ad-hoc-Modifikation . . . . . . . . 37

3.7 Nachfolgerbestimmung bei Implementierung mit Kantenobjekten . . . . . . . . . 39

3.8 Inkorrekte Migration verzerrter Instanzen bei Realisierung ohne Kantenobjekte . 40

3.9 Problemlose Migration verzerrter Instanzen bei Realisierung mit Kantenobjekten 41

3.10 Die Delta-Schicht bei Petri-Netzen . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.11 Repr¨

asentation der Prozessinstanzen und -vorlagen beim Demonstrator . . . . . 45

4.1 Architektur mit Zustandsgruppen vor der Migration . . . . . . . . . . . . . . . . 50

4.2 Architektur mit Zustandsgruppen nach einer Migration . . . . . . . . . . . . . . 51

4.3 Anzahl #(S, 1, x, y, 1) m¨

oglicher Zust¨

ande bei einem Prozess mit zwei parallel

angeordneten Pfaden in Abh¨

angigkeit von der Anzahl x und y der Aktivit¨

aten in

denPfaden ....................................... 52

4.4 Weiterschalten einer Instanz bei einer Architektur mit Zustandsgruppen . . . . . 54

4.5 Architektur mit Meilensteinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1 Prinzip der Best¨

atigung einer Vorlagen¨

anderung durch den Server . . . . . . . . 61

5.2 Prinzip des Sperrverfahrens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3 Prinzip des optimistischen Verfahrens . . . . . . . . . . . . . . . . . . . . . . . . 65

5.4 Unvertr¨

aglichkeit einer Instanz aufgrund einer Aktivit¨

aten-Weiterschaltung . . . 67

5.5 Vermeidung von Unvertr¨

aglichkeit durch Sperren gegen Weiterschalten . . . . . . 68

5.6 Unvertr¨

aglichkeit trotz Sperren gegen Weiterschalten . . . . . . . . . . . . . . . . 69

5.7 Konflikte aufgrund ¨

uberlappender Instanz- und Schema¨

anderungen . . . . . . . . 71

5.8 Reduzierung des ¨

Uberlappungsgrades von Instanz- und Schema¨

anderungen . . . 72

5.9 Konflikt bei konkurrierender Instanz¨

anderung und Aktivit¨

aten-Weiterschaltung . 74

5.10 Inkorrekte Vertr¨

aglichkeitspr¨

ufung aufgrund einer Zustandsweiterschaltung . . . 77

5.11 Verhinderung inkorrekter Vertr¨

aglichkeitspr¨

ufungen durch Sperren . . . . . . . . 78

5.12 Inkorrekte Migration aufgrund falscher Informationen ¨

uber ¨

Uberlappungsgrad . . 85

5.13 Scheinbarer Konflikt bei parallel erfolgender Instanzanpassung und -¨

anderung . . 86

98 ABBILDUNGSVERZEICHNIS

5.14 Konfliktlose parallel erfolgende Instanzanpassung und -¨

anderung . . . . . . . . . 87

B.1 Die Instanzen I1 - I3 vor deren Migrationsversuch . . . . . . . . . . . . . . . . . . 103

B.2 Die Instanzen I1 - I3 nach deren Migrationsversuch . . . . . . . . . . . . . . . . . 104

B.3 Die Instanzen I4 - I6 vor deren Migrationsversuch . . . . . . . . . . . . . . . . . . 105

B.4 Die Instanzen I4 - I6 nach deren Migrationsversuch . . . . . . . . . . . . . . . . . 107

B.5 Die Instanzen I7 und I8 vor deren Migrationsversuch . . . . . . . . . . . . . . . . 108

B.6 Die Instanzen I7 und I8 nach deren Migrationsversuch . . . . . . . . . . . . . . . 109

Anhang A

Berechnung der Anzahl m¨

oglicher

Instanzzust¨

ande

In diesem Anhang soll die in Abbildung 4.3 aufgestellte Formel

#(S, 1, x, y, 1) = 3 + (2x+ 1)(2y+ 1) −1+3−1 (A.1)

zur Berechnung der Anzahl #(S, 1, x, y, 1) m¨

oglicher Zust¨

ande des ebenfalls abgebildeten Pro-

zesses S hergeleitet werden.

F¨

ur diese Betrachtung sollen die Aktivit¨

aten jeweils nur die Zust¨

ande “INAKTIV”, “AKTI-

VIERT”, “IN AUSF¨

UHRUNG” und “BEENDET” annehmen k¨

onnen, d. h. Zust¨

ande, wie z. B.

“AUSGESETZT”, sollen hier nicht ber¨

ucksichtigt werden. Weiter wird angenommen, dass sich

die erste abzuarbeitende Aktivit¨

at bei Prozessstart sofort in dem Zustand “AKTIVIERT” be-

findet und nicht erst in dem Zustand “INAKTIV”.

Ausgangspunkt f¨

ur die Herleitung der angegebenen Formel ist die Formel zur Berechnung der

Anzahl m¨

oglicher Zust¨

ande bei einem sequentiellen Graphen.

A.1 Berechnung bei Prozessen mit nur sequentiell angeordneten

Aktivit¨

aten

Bei einem Prozess Ssequ mit n sequentiell angeordneten Aktivit¨

aten bel¨

auft sich die Anzahl

#(Ssequ, n) an m¨

oglichen Zust¨

anden auf:

#(Ssequ, n) = 2n+ 1 (A.2)

Dies soll mithilfe der Induktion bewiesen werden. Zuerst wird die Formel f¨

ur einen Prozess Ssequ

mit genau einer Aktivit¨

at, d. h. n= 1, ¨

uberpr¨

uft (Induktionsanfang): Die eine Aktivit¨

at kann

100 ANHANG A. BERECHNUNG DER ANZAHL M ¨

OGLICHER INSTANZZUST ¨

ANDE

nacheinander die Zust¨

ande “AKTIVIERT”, “IN AUSF¨

UHRUNG” und “BEENDET” anneh-

men. Somit k¨

onnen Instanzen existieren, die sich maximal in drei unterschiedlichen Zust¨

anden

befinden k¨

onnen. Die Anzahl an m¨

oglichen Instanzzust¨

anden bei einem Prozess mit nur einer

Aktivit¨

at bel¨

auft sich damit auf 3. Die Formel liefert f¨

ur eine Aktivit¨

at ebenfalls 3. Damit ist

die Indunktionsvoraussetzung erf¨

ullt und die Formel kann f¨

ur genau nAktivit¨

aten als korrekt

angenommen werden. Bevor durch den Induktionsschritt gezeigt werden kann, dass die Formel

auch f¨

ur n+ 1 Aktivit¨

aten korrekt ist und damit generell gilt, muss das Ergebnis noch auf eine

andere Weise interpretiert werden: Da bei einem Prozess mit nnur sequentiell angeordneten

Aktivit¨

aten alle Aktivit¨

aten in gegebener Reihenfolge abgearbeitet werden m¨

ussen, bedeutet

das Ergebnis auch, dass der Prozess 2n+ 1 verschiedene Zust¨

ande eingenommen haben muss,

bis alle nAktivit¨

aten abgearbeitet wurden und der Prozess als beendet gilt.

Als Induktionsschritt wird nun im folgenden statt von einem Prozess mit nsequentiell hinterein-

ander geschalteten Aktivit¨

aten von einem mit n+1 ausgegangen. Die (n+1). Aktivit¨

at kann erst

aktiviert werden, wenn alle nVorg¨

anger beendet worden sind. Dazu werden laut Induktionsvor-

aussetzung 2n+1 verschiedene Prozesszust¨

ande eingenommen. Bis dann der Prozess vollst¨

andig

abgearbeit ist, m¨

ussen zwei weitere Prozesszust¨

ande durchlaufen werden, einmal der, bei dem

sich die (n+ 1). Aktivit¨

at noch in Ausf¨

uhrung befindet und einmal der, bei dem alle n+ 1

Aktivit¨

aten abgearbeitet wurden. Damit bel¨

auft sich der Zahl an m¨

oglichen Instanzzust¨

anden

#(Ssequ, n + 1) auf: #(Ssequ, n + 1) = #(Ssequ, n) + 2 = (2n+ 1) + 2 = 2(n+ 1) + 1. Somit

stimmt die Formel auch f¨

ur Prozesse mit n+1 sequentiell in Reihe geschalteten Aktivit¨

aten und

ist damit generell f¨

ur alle Prozesse mit nur sequentiell abzuarbeitenden Arbeitsschritten g¨

ultig,

was zu beweisen war.

A.2 Berechnung bei Prozessen mit zwei parallelen Ausf¨

uhrungs-

str¨

angen

Der Prozessgraph eines Prozesses Spar mit zwei parallelen Ausf¨

uhrungsstr¨

angen kann, wie ex-

emplarisch in Abbildung 4.3 gezeigt, in vier Bereiche eingeteilt werden: in den Vorbereich (Be-

reich I), den Bereich des ersten Pfades (Bereich II), den Bereich des parallel dazu angeordneten

zweiten Pfades (Bereich III) und in den Nachbereich (Bereich IV). Da Bereich II und Bereich

III parallel zueinander angeordnet sind, muss bei der Berechnung der Anzahl #(Spar) an m¨

ogli-

chen Zust¨

anden von Spar darauf geachtet werden, dass jeder m¨

ogliche Zustand des Bereichs II

mit jedem m¨

oglichen Zustand des Bereichs III kombinierbar ist. Somit berechnet sich die An-

zahl #(II +III) an m¨

oglichen Zust¨

anden f¨

ur den Bereich II und III zusammen genommen zu

#(II+III) = #(II)·#(III). F¨

ur den durch Bereich I, II und III definierten Prozess gibt sich die

Anzahl #(I+II +III) an m¨

oglichen Zust¨

anden zu: #(I+II +III) = #(I)+#(II +III)−1 =

#(I) + #(II)·#(III)−1. Die Verringerung um 1 ist notwendig, da sonst der Prozesszustand

doppelt gez¨

ahlt wird, bei dem alle Aktivit¨

aten aus Bereich I beendet, die Aktivit¨

aten A11 und

A21 aktiviert und alle weiteren Aktivit¨

aten aus den Bereichen II und III inaktiv sind. Die Anzahl

#(Spar) an m¨

oglichen Zust¨

anden f¨

ur den gesamten Prozess S berechnet sich dann schließlich zu:

A.3. BERECHNUNG BEI DEM PROZESS AUS ABBILDUNG 4.3 101

#(Spar) = #(I+II +III +IV ) = #(I+II +III) + #(IV )−1. Die erneute Subtraktion

einer Eins verhindert, dass der Zustand doppelt ber¨

ucksichtigt wird, bei dem alle Aktivit¨

aten

aus den Bereichen I - III beendet sind und nur die erste Aktivit¨

at aus dem Bereich IV – der

Join – aktiviert ist. Mit #(I+II +III) aufgel¨

ost lautet schließlich die Formel zur Berech-

nung der Anzahl #(Spar) an m¨

oglichen Zust¨

anden f¨

ur einen Prozess Spar mit zwei parallelen

Ausf¨

uhrungsstr¨

angen:

#(Spar) = (#(I) + #(II)·#(III)−1) + #(IV )−1 (A.3)

Besteht bei einem Prozess Spar sequ Bereich I aus w, Bereich II aus x, Bereich III aus y und

Bereich IV aus z sequentiell angeordneten Aktivit¨

aten, so kann deren jeweilige Anzahl #(I),

#(II), #(III) bzw. #(IV ) an m¨

oglichen Zust¨

anden mithilfe der Formel A.2 berechnet werden.

Eingesetzt in die Formel A.3 ergibt sich dann f¨

ur die Gesamtanzahl #(Spar sequ, w, x, y, z) an

m¨

oglichen Zust¨

anden des Prozesses Spar sequ:

#(Spar sequ, w, x, y, z) = ((2w+ 1) + (2x+ 1)(2y+ 1) −1) + (2z+ 1) −1 (A.4)

A.3 Berechnung bei dem Prozess aus Abbildung 4.3

In der Abbildung 4.3 liegt ebenfalls ein Prozess vor, bei dem s¨

amtliche Bereiche f¨

ur sich betrach-

tet sequentielle Prozessgraphen sind. Die Besonderheit liegt darin, dass der Vorbereich und der

Nachbereich jeweils nur aus einer Aktivit¨

at besteht und damit w und z in der Formel A.4 auf

1 gesetzt werden m¨

ussen. Deshalb berechnet sich die Anzahl #(S) an m¨

oglichen Zust¨

anden f¨

diesen Prozess S zu

#(S) = #(S, 1, x, y, 1)

= ((2 ·1+1)+(2x+ 1)(2y+ 1) −1) + (2 ·1 + 1) −1

= (3 + (2x+ 1)(2y+ 1) −1) + 3 −1 (A.5)

und entspricht damit der in der Abbildung genannten Formel A.1.

q .e. d.

Anhang B

Proof-Of-Concept-Prototype

Wie in Kapitel 3.8 angesprochen, haben wir f¨

ur die Validierung der aufgestellten Konzepte im

Rahmen eines Praktikums und dieser Diplomarbeit den Demonstrator als einen Prototypen eines

einfachen adaptiven Prozess-Management-Systems entwickelt, mit dem die Schemaevolution,

die dynamische ¨

Anderung einer Instanz und die Migration von sowohl unverzerrten als auch

verzerrten Instanzen demonstriert werden kann.

Im folgenden wird anhand von Beispielen dessen Leistungsspektrum aufgezeigt.

Im Rahmen einer Schemaevolution wird die in Abbildung B.1 gezeigte Prozessvorlage Sder

Version V1 durch das Einf¨

ugen der neuen Aktivit¨

at A3 hinter A2 und durch das Einf¨

ugen einer

Sync-Kante zwischen die parallel angeordneten Aktivit¨

aten A12 und A21 in die in Abbildung

B.2 gezeigte Version V2¨

uberf¨

uhrt.

Die Screenshots aus den Abbildungen B.1 bis B.6 dokumentieren den Versuch des Systems, die

auf der Vorlage Sder Version V1 basierenden, zum Teil verzerrten Instanzen I1 - I8 auf die neue

Version V2 der Vorlage zu migrieren.

Abbildung B.1 zeigt neben der alten Version V1 der Prozessvorlage Sdie Instanzen I1-I3 vor

deren Migrationsversuch mit ihren Ausf¨

uhrungshistorien.

Die Laufzeitschemata dieser drei Instanzen stimmen exakt mit dem Schema der Vorlage ¨

uberein.

Sie sind somit gegen¨

uber ihrer Vorlage nicht verzerrt. Wie im Kapitel 2.3.1 ¨

uber die Migration

von unverzerrten Instanzen ausgef¨

uhrt, werden unverzerrte Instanzen im Rahmen der Migration

an die neue Version der Vorlage angepasst, indem die Schema¨

anderungen – logisch gesehen – auf

den Laufzeitschemata der Instanzen nachgezogen werden. Abbildung B.2 zeigt die Resultate.

I1 wurde korrekt in dieser Weise an die neue Vorlage S, V 2 angepasst: Ihr neues Laufzeitschema

stimmt mit der neuen Version des Schemas ihrer Vorlage ¨

uberein. Zus¨

atzlich wurde korrekterwei-

se mit der Migration in der Phase der Markierungsanpassung die Aktivit¨

at A21 von dem Status

”AKTIVIERT“ in den Status ”INAKTIV“ zur¨

uckversetzt: Die neue Sync-Kante A12 →A21

schreibt vor, dass vor der Ausf¨

uhrung von A21 erst die Aktivit¨

at A12 erfolgreich beendet worden

102

103

Abbildung B.1: Die Instanzen I1 - I3 vor deren Migrationsversuch

sein muss. Da aber A12 bei I1 noch nicht einmal aktiviert worden ist, darf A21 bei dieser Instanz

nicht gestartet werden k¨

onnen. Somit war es notwendig, sie wieder zu deaktivieren und damit

die entsprechenden Arbeitsauftr¨

age aus den Arbeitslisten der infrage kommenden Bearbeiter zu

entfernen.

Auch die Instanz I2 wurde korrekt auf die neue Version V2 ihrer Vorlage Smigriert. Die Instanz-

Uberschrift ”I2 running on Template “S, V2”“ best¨

atigt, dass die Instanz von nun an gem¨

aß

den Vorgaben der neuen Vorlage ablaufen wird.

Warum aber l¨

auft die Instanz I3 immer noch nach der alten Version V1 der Vorlage Sab und

wurde nicht auf die neue Version V2 migriert, obwohl sie zu Beginn denselben Zustand wie die

Instanz I2 aufwies? Der in Abbildung B.2 abgebildete Migrationsreport gibt einen Hinweis: I3

ist f¨

ur die durchzuf¨

uhrenden Modifikationen zu weit fortgeschritten. I3 ist somit unvertr¨

aglich

mit den Schema¨

anderungen. Der Grund hierf¨

ur ist bei der Einf¨

uge-Operation der Sync-Kante

zu suchen: Eine Sync-Kante kann in das Laufzeitschema einer Instanz nur eingef¨

ugt werden,

104 ANHANG B. PROOF-OF-CONCEPT-PROTOTYPE

Abbildung B.2: Die Instanzen I1 - I3 nach deren Migrationsversuch

wenn die Quellaktivit¨

at entweder in einem abgew¨

ahlten Zweig eines XOR-Blocks liegt oder

wenn die Zielaktivit¨

at entweder h¨

ochstens aktiviert wurde oder erst nach dem Ende der Quel-

laktivit¨

at gestartet wurde [RRD02]. Der Demonstrator hat anhand der Ausf¨

uhrungshistorie von

I3 richtig erkannt, dass bei dieser Instanz die Aktivit¨

at A21 vor dem Ende der Aktivit¨

at A12

zur Ausf¨

uhrung gelangte und dass I3 damit im Gegensatz zu I2, bei der A21 erst nach dem

Ende von A12 gestartet wurde, gegen die genannte Bedingung f¨

ur die Vertr¨

aglichkeit mit der

Sync-Kanten-Einf¨

uge-Operation verst¨

oßt und nicht migriert werden darf.

Die im folgenden betrachteten Instanzen I4 - I8 basieren wie schon die Instanzen I1 - I3 auf der

Vorlagenversion S, V 1, sind aber alle, im Gegensatz zu diesen, gegen¨

uber ihrer Vorlage verzerrt.

Abbildung B.3 zeigt die Instanzen I4, I5 und I6 vor ihrer Migration auf die neue Schemaversion

S, V 2 zusammen mit ihren ¨

Anderungshistorien. Die Historien dokumentieren, in welcher Weise

die Instanzen gegen¨

uber ihrer Vorlage abge¨

andert wurden.

105

Abbildung B.3: Die Instanzen I4 - I6 vor deren Migrationsversuch

I4 weist zus¨

atzlich die Sync-Kante A12 →A21 zwischen den Aktivit¨

aten A12 und A21 auf.

I5 weicht von ihrer Vorlage S, V 1 nicht nur durch die Sync-Kante A12 →A21 ab, sondern

auch durch die zus¨

atzlich eingef¨

ugte Aktivit¨

at A3. An I6 wurden dieselben Ad-hoc-¨

Anderungen

vorgenommen wie an der Instanz I5, aber dar¨

uber hinaus wurde auch noch die Aktivit¨

at A0 vor

A1 eingef¨

ugt.

Die Erg¨

anzung ”(adhoc modified)“ in den jeweiligen Instanz-¨

Uberschriften belegen, dass es sich

um verzerrte Instanzen handelt.

Betrachtet man die ¨

Anderungshistorien der Instanzen und vergleicht sie mit der ebenfalls abge-

bildeten Historie der Vorlagen-¨

Anderung S, V 1→S, V 2, dann erkennt man, dass sich bei diesen

Instanzen die beiden ¨

Anderungsarten ¨

uberlappen.

Sowohl bei der Ad-hoc-Modifikation der Instanz I4 als auch bei der Schemaevolution wurde

eine Sync-Kante zwischen die Aktivit¨

aten A12 und A21 eingef¨

ugt. Da an I4 keine weiteren

Modifikationen vorgenommen, an der Vorlage aber weiter noch die Aktivit¨

at A3 eingef¨

ugt wurde,

106 ANHANG B. PROOF-OF-CONCEPT-PROTOTYPE

ist die Instanz¨

anderung von I4 subsumptions-¨

aquivalent zu den Schema¨

anderungen. Um die

Instanz I4 auf die neue Vorlage S, V 2 zu migrieren, muss gem¨

aß der Theorie zu der Migration

von verzerrten Instanzen auf logischer Ebene dann nur noch die Aktivit¨

at A3 an dieselbe Stelle

im Laufzeitschema der Instanz eingef¨

ugt werden, anstatt s¨

amtliche Schema¨

anderungen auf der

Instanz nachzuvollziehen.

I5 wurde laut ihrer ¨

Anderungshistorie in exakt derselben Weise wie die alte Schemaversion

S, V 1 abge¨

andert, d. h. bei dieser Instanz gilt, dass die Instanz¨

anderungen ¨

aquivalent zu den

Schema¨

anderungen sind. Dies kann auch daran erkannt werden, dass die Instanz in ihrem Lauf-

zeitschema schon vor der Migration mit dem Schema der neuen Vorlagenversion S, V 2¨

uberein-

stimmt. Auf logische Ebene muss somit die Instanz I5 im Rahmen der Migration nicht mehr an

die neue Version ihrer Vorlage angepasst werden, sie ist es bereits.

Wie durch einen Vergleich der ¨

Anderungshistorien von der Instanz I6 und der Vorlage leicht zu

erkennen ist, wurden auf Instanzebene dieselben ¨

Anderungen wie auf Typebene vorgenommen,

aber zus¨

atzlich noch die Aktivit¨

at A0 eingef¨

ugt. Damit sind die Instanz¨

anderungen von I6 auf-

grund der zus¨

atzlichen Einf¨

uge-Operation der Aktivit¨

at A0 umfassender als die Schema¨

anderun-

gen, die Schema¨

anderungen sind subsumptions-¨

aquivalent zu den Instanz¨

anderungen. ¨

Ahnlich

wie bei der Instanz I5 m¨

ussen keine zus¨

atzliche ¨

Anderungen an der Instanz I6 vorgenommen

werden, um sie an die neue Vorlage anzupassen. Sie ist bereits angepasst. Im Gegensatz zu I5

ist I6 auch noch nach der Migration verzerrt, da sie der neuen Vorlagenversion gegen¨

uber die

zus¨

atzliche Aktivit¨

at A0 aufweist.

Die Aufgabe des Systems ist nun, den ¨

Uberlappungsgrad der Instanz¨

anderungen einer jeden

verzerrten Instanz mit den Typ¨

anderungen korrekt zu bestimmen und dann die Instanz geeignet

auf die neue Vorlage anzupassen. Abbildung B.4 zeigt das Ergebnis.

Wie der abgebildete Migrationsreport zeigt, wurden die Instanz¨

anderungen von I4 korrekt als

subsumptions-¨

aquivalent und die von I5 korrekt als ¨

aquivalent zu den Schema¨

anderungen er-

kannt. Auch bei der Instanz I6 hat das System den richtigen ¨

Uberlappungsgrad bestimmt.

Ebenso konnten die auf diese Informationen angewiesenen Migrationen erfolgreich von dem Sys-

tem durchgef¨

uhrt werden: Das Laufzeitschema der Instanz I4 weist nach deren Migration die bis-

her fehlende Aktivit¨

at A3 auf und stimmt damit mit der neuen Version V2 des Vorlagenschemas

S¨

uberein. Sie l¨

auft von nun an gem¨

aß dem neuen Schema S, V 2 ab, wie die Instanz-¨

Uberschrift

”I4 running on Template “S, V2”“ best¨

atigt. Das Fehlen der Erg¨

anzung ”(adhoc modified)“

l¨

asst erkennen, dass das System die Instanz I4 auch als nicht mehr verzerrt gegen¨

uber der neuen

Version der Vorlage betrachtet und l¨

asst darauf schließen, dass die Instanz von jetzt an auch

intern wieder wie eine jede unverzerrte Instanz ohne eine Delta-Schicht repr¨

asentiert wird.

Die neue ¨

Uberschrift zur Instanz I5 zeugt einerseits davon, dass auch sie nicht mehr auf der

Version V1 der Vorlage Sberuht, sondern jetzt, wie beabsichtigt, auf der neuen Version V2,

und andererseits, dass auch sie analog zu I4 nicht mehr verzerrt gegen¨

uber der neuen Vorlagen-

Version ist.

107

Abbildung B.4: Die Instanzen I4 - I6 nach deren Migrationsversuch

Ebenfalls an der ¨

Uberschrift ist zu erkennen, dass auch Instanz I6 erwartungsgem¨

aß auf der neu-

en Version V2 der Vorlage l¨

auft. Das System erkannte richtig, dass diese auch nach der Migration

noch verzerrt ist und hat korrekt den neuen Bias berechnet, wie die neue ”¨

Anderungshistorie“1

der Instanz zeigt: Auf Instanzebene ist zwischen der Startaktivit¨

at des Prozesses und der Akti-

vit¨

at A1 die Aktivit¨

at A0 eingef¨

ugt. Im Gegensatz zu dem Zeitpunkt vor der Migration enth¨

alt

diese ”Historie“ folgerichtig nicht mehr die Eintr¨

age f¨

ur die Sync-Kante und die Aktivit¨

at A3,

da diese Elemente nun von der neuen Vorlage vorgeschrieben werden und somit nicht mehr zur

Verzerrung der Instanz beitragen.

Der Demonstrator f¨

uhrt aber auch die Migration von verzerrten Instanzen korrekt durch, bei

denen die Ad-hoc-Modifikationen disjunkt zu den Schema¨

anderungen sind.

1Der Begriff ”Historie“ im eigentlichen Sinne ist hier nicht korrekt, da diese ”Historie“ nicht wirklich die vom

Benutzer durchgef¨

uhrten ¨

Anderungen dokumentiert, sondern nur den Bias in Form einer Historie beschreibt.

108 ANHANG B. PROOF-OF-CONCEPT-PROTOTYPE

Abbildung B.5 zeigt u. a. mit I7 ein Beispiel einer Instanz mit einer zu den Schema¨

anderungen

disjunkten Modifikation.

Abbildung B.5: Die Instanzen I7 und I8 vor deren Migrationsversuch

Der Theorie nach werden Instanzen mit zu den Schema¨

anderungen disjunkten Modifikationen an

die neue Version der Vorlage angepasst, indem - auf logischer Ebene - die Schema¨

anderungen wie

im Falle von unverzerrten Instanzen einfach auf den Laufzeitschemata der Instanzen nachgezogen

werden. Das neue Laufzeitschema weist danach sowohl die auf Instanz- als auch die auf Typebene

gemachten ¨

Anderungen gegen¨

uber der alten Version des Schemas auf.

Wie Abbildung B.6 gezeigt, hat der Demonstrator dasselbe Ergebnis mit der in Kapitel 3.6

beschriebenen Methode zur Migration von Instanzen bei disjunkten ¨

Anderungsoperationen er-

reicht: Das Laufzeitschema der Instanz I7 weist nun sowohl die auf Schemaebene eingef¨

ugte

Sync-Kante A12 →A21, als auch die ebenfalls auf Schemaebene eingef¨

ugte Aktivit¨

at A3 und

die auf Instanzebene eingef¨

ugte Aktivit¨

at A0 auf. Die Instanz-¨

Uberschrift teilt korrekt mit, dass

I7 von nun an auf der neuen Version V2 der Vorlage Sbasiert und dass sie weiterhin verzerrt

gegen¨

uber ihrer Vorlage ist.

109

Vorraussetzung f¨

ur die korrekte Migration war, dass der Demonstrator auch die Disjunktheit

der ¨

Anderungsarten erkennt. Der Migrationsreport aus der Abbildung B.6 best¨

atigt dies.

Abbildung B.6: Die Instanzen I7 und I8 nach deren Migrationsversuch

Mit dem Scheitern der Migration von Instanz I8 kann demonstriert werden, dass der Demonstra-

tor auch in der Lage ist, die Migration von Instanzen zu verhindern, die zwar vom Zustand her

vertr¨

aglich mit den durchzuf¨

uhrenden ¨

Anderungen sind, aber bei denen die Anpassungen an die

neue Vorlage zu inkorrekten Laufzeitschemata f¨

uhren w¨

urden. Wie die Bemerkung in dem Mi-

grationsreport zu dieser Instanz erahnen l¨

asst, h¨

atten die aus den Instanz¨

anderungen bzw. Sche-

ma¨

anderungen stammenden Sync-Kanten bei I8 den Zyklus A11 →A12 →A21 →A22 →A11

im Kontrollfluss verursacht. Dieser Zyklus w¨

are dann f¨

ur einen Deadlock w¨

ahrend der weiteren

Prozessausf¨

uhrung von I8 verantwortlich gewesen. Deshalb wurde I8 korrekterweise von der

Migration ausgeschlossen.

Anhand dieser Beispiele wurde klar gezeigt, dass der Demonstrator die wichtigsten Anforderun-

gen eines der Theorie nach voll adaptiven Prozess-Management-Systems erf¨

ullt: Er unterst¨

utzt

sowohl das ¨

Andern von Prozessvorlagen als auch das dynamische ¨

Andern einzelner Instanzen

110 ANHANG B. PROOF-OF-CONCEPT-PROTOTYPE

zur Laufzeit. Wie in der Einf¨

uhrung zu dieser Diplomarbeit gefordert, versucht er nach Vorla-

gen¨

anderung die auf der alten Version der Prozessvorlage basierenden Instanzen auf die neue

Version anzupassen, wobei er auch die bereits durchgef¨

uhrten Modifikationen der zu migrieren-

den Instanzen ber¨

ucksichtigt. Zus¨

atzlich sorgt er durch entsprechende Korrektheits- und Ver-

tr¨

aglichkeitstests daf¨

ur, dass die Anpassungen nicht zu Inkonsistenzen f¨

uhren und dass dadurch

die korrekte Prozessausf¨

uhrung zu jeder Zeit gew¨

ahrleistet ist.

Erkl¨

arung

Markus, Lauer, Matrikel-Nr.: 427963

Ich erkl¨

are, dass ich die Diplomarbeit selbst¨

andig verfasst und keine anderen als die angegebenen

Quellen und Hilfsmittel verwendet habe.

Ulm, den 17. Dezember 2004

111