Diskussion von Alternativen und Entwurfsentscheidungen

... ...

ist Teilkonfigurationstyp

WFS 1

WFS 2

C

Abbildung 7.13: Mögliche Zyklen bei Kontrollflussabhängigkeiten in beide Richtungen Aufgrund der dargestellten Probleme sollen ausschließlich Kontrollflussbeziehungen in Rich-tung der „ist Teilkonfigurationstyp“-Beziehung im Abhängigkeitsmodell erlaubt sein. Da kei-ne praktisch relevanten Beispiele bekannt sind, in dekei-nen Kontrollflussabhängigkeiten in beide Richtungen benötigt werden, stellt dies keine signifikante Einschränkung dar.

Durch diese Konsistenzbedingung ist es nicht möglich, mit sequenziellen Kontrollflussab-hängigkeiten Verklemmungssituationen zwischen Workflows zu verursachen. Anstelle eines formalen Beweises soll diese Aussage durch folgende Betrachtungen begründet werden:

Um eine Verklemmung zu erreichen, muss sich im Graph ein Zyklus ausbilden. Bei einem Zyklus handelt es sich um eine geschlossene Pfeilfolge, d.h. eine zirkuläre Aneinanderrei-hung von Pfeilen. Durch die Einschränkung, dass Pfeile zwischen Workflow-Schemata nur in eine Richtung verlaufen dürfen, kann niemals ein Zyklus geschlossen werden.

7.1.2 Diskussion von Alternativen und Entwurfsentscheidungen

Im Laufe der Arbeit sind Alternativen zu dem im vorangegangenen Abschnitt vorgestellten Konzept entstanden, die jedoch wieder verworfen wurden. Diese sollen nun kurz diskutiert werden.

7.1.2.1 Direkte Spezifikation von Abhängigkeiten

Eine Alternative zum vorgeschlagenen Abhängigkeitsmodell besteht darin, Abhängigkeiten nicht über den Umweg der Bindung eines Workflow-Schemas an einen bestimmten Konfigu-rationstyp zu beschreiben, sondern diese direkt zwischen den Workflow-Schemata festzule-gen. Beispielsweise in der Art: „die Aktivität B einer Instanz des Workflow-Schemas 1 soll vor Aktivität A einer Instanz des Workflow-Schemas 2 ausgeführt werden, wenn die Instanzen entsprechenden, in hierarchischen Abhängigkeiten stehenden Konfigurationen zugeordnet sind.“

B

C

A D E

B

D

A E

C WFS 1

WFS 2

Abbildung 7.14: Direkte Spezifikation von Kontrollflussabhängigkeiten

86 Lösungskonzepte Vorteil dieser Alternative ist eine kompaktere Spezifikation, da nicht für jeden Konfigurati-onstyp die Abhängigkeiten einzeln angegeben werden müssen. Allerdings hätte dieses Vor-gehen zur Folge, dass Kontrollflussabhängigkeiten, die vom Typ der Konfiguration abhängen, nicht ausgedrückt werden können und für solche Fälle (unnötigerweise) dasselbe Workflow-Schemata repliziert werden müsste. Auch die Verwendung eines Workflow-Schemas wäre eingeschränkt, da durch die Richtung der Abhängigkeiten implizit festgelegt wäre, für welche Hierarchieebenen (relativ gesehen) die Workflow-Schemata verwendet werden dürfen. Insge-samt würde dies dazu führen, dass die Abhängigkeiten im Workflow-Geflecht für den Model-lierer weniger durchschaubar und damit schlechter wartbar sind: Zur Laufzeit existieren die Kontrollflussabhängigkeiten zwischen Freigabeworkflows hierarchisch abhängiger Konfigu-rationen. Durch die Modellierung des Interworkflow-Kontrollflusses in Abhängigkeit von der hierarchischen Struktur wird dies sehr viel anschaulicher, als wenn diese Abhängigkeiten ohne Bezug zur Hierarchie der Konfigurationen geschehen würde. Aus diesen Gründen wur-de die Entscheidung zu Gunsten wur-des Abhängigkeitsmowur-dell in Abschnitt 7.1.1.3 getroffen.

7.1.2.2 Modellierung durch Reifegrade

Eine Alternative zum gesamten Lösungskonzept ist die Modellierung der Abhängigkeiten über sog. „Reifegrade“. Diesem alternativen Ansatz liegt die Auffassung zu Grunde, dass der Reifegrad einer Konfiguration höher ist, je weiter der zugehörige Freigabeworkflow fortge-schritten ist. Dies gründet darauf, dass in den vorangegangenen Prüffortge-schritten keine Fehler gefunden wurden. Der Ansatz ist der, diese Reifegrade explizit zu repräsentieren und paralle-le Freigabeworkflows über die Reifegrade zu synchronisieren. Die Abhängigkeiten zwischen den Freigabeworkflows auf verschiedenen Ebenen werden hier nicht mehr direkt zwischen einzelnen Aktivitäten festgelegt.

Für die Modellierung existieren bei diesem Ansatz zwei Modelle: Im Reifegradmodell wird eine globale Ordnung von Reifegraden festgelegt. Im Modell werden in Workflow-Schemata Typen von Freigabeworkflows definiert. Die Reifegrade und Abhängigkeiten von Reifegraden anderer Workflows werden direkt in den Workflow-Schemata durch neue Model-lierungskonstrukte beschrieben. Mit dem Konstrukt des selbst erreichten Reifegrades wird im Kontrollfluss des Workflow-Schemas festgelegt, wann ein gewisser Reifegrad erreicht ist. Das Konstrukt des mindestens zu erreichenden Reifegrades definiert, welchen Reifegrad alle Teil-konfigurationen mindestens erreicht haben müssen, damit mit der Ausführung an dieser Stel-le fortgesetzt werden kann. Die Synchronisation der Workflows geschieht somit implizit über globale Reifegrade.

Abbildung 7.15 gibt ein einfaches Beispiel für diesen Ansatz. Im Reifegradmodell sind Reife-grade 1–3 definiert, wobei 3 die höchste Reife ausdrückt. Die Aktivität A darf erst ausgeführt werden, wenn alle Teilkonfigurationen mindestens den Reifegrad 1 besitzen. Nach Ausfüh-rung von Aktivität A besitzt die zugehörige Konfiguration ebenfalls den Reifegrad 1. Entspre-chendes gilt für Aktivität C und den Reifegrad 2. Anzumerken ist, dass die Freigabe-workflows der Teilkonfigurationen Instanzen beliebiger (auch desselben) Workflow-Schemas sein können.

7 Lösungskonzepte 87

B

A C D E

1 2 3

1 2

F

3

1 2

X Mindestens zu erreichender Reifegrad X X Erreichter Reifegrad X

Reifegradmodell

Workflow-Schema

Abbildung 7.15: Workflow-Schema mit Reifegraden

Der Vorteil dieses Ansatzes liegt darin, dass das Modell (zumindest optisch) übersichtlicher ist als im vorgeschlagenen Lösungskonzept. Allerdings stehen diesem Vorteil eine Reihe von Nachteilen gegenüber. Die implizite Beschreibung der Abhängigkeiten führt zu schwerer verständlichen Modellen. Damit ist die Gefahr einer fehlerhaften Modellierung gegeben. Die Beschreibung von Kontrollflussabhängigkeiten, die vom Typ der assoziierten Konfiguration abhängen, ist ebenfalls nicht möglich. Ein weiteres Problem betrifft die Semantik der Reife-grade: Es ist für alle Beteiligten vermutlich sehr schwer, zu einem gemeinsamen Verständnis der Reifegrade zu kommen. Dies ist jedoch Grundvoraussetzung für diesen Ansatz. Ein weite-rer Nachteil aus technischer Sicht ist die nötige Erweiterung der Workflow-Sprache, die sub-stanzielle Änderungen an der Workflow-Engine notwendig machen.

7.1.3 Zusammenfassung

Der hier vorgestellte Ansatz zur Beschreibung von Kontrollflussabhängigkeiten zwischen Freigabeworkflows ist ein erster grundlegender Schritt, um Freigabeprozesse durch Workflowtechnologie unterstützen zu können. Es handelt sich hierbei um einen expliziten Ansatz, mit dem Kontrollflussabhängigkeiten zwischen Workflows separat und unabhängig von einer konkreten Workflow-Sprache beschrieben werden können.

Das Konzept ist sehr spezifisch auf den Problembereich zugeschnitten. Insbesondere das Metamodell des Typmodells ist speziell für Konfigurationen ausgelegt. Ein nächster Schritt in Richtung eines generischeren Konzepts wäre, die Struktur, die dort gebildet wird, auf ein beliebiges Datenmodell zu verallgemeinern. Damit wäre der Anwendungsbereich nicht mehr auf Konfigurationen eingeschränkt, sondern könnte auf eine Reihe von Anwendungen ausge-dehnt werden, in denen es Kontrollflussabhängigkeiten zwischen Workflows gibt, die von einer hierarchischen Datenstruktur abhängig sind.

88 Lösungskonzepte