Beispiel - Modellierungskonstrukte

Die Modellierungskonstrukte sind Bestandteile einer Prozessdefinition und beschreiben u.a. den Kontrollfluss. Es ist offensichtlich, dass unterschiedliche Modellierungskon-strukte unterschiedliche Prozessdefinitionen zur Folge haben. Die Unterschiede bei den Modellierungskonstrukten des Kontrollflusses, durch die es zu Problemen bei der Transformation kommen kann, werden im Folgenden am Vergleich der Systeme Staff-ware und MQSeries deutlich gemacht.

Für einen Vergleich der beiden Systeme anhand der Kontrollflusskonstrukte bieten sich die Workflow Patterns von W.M.P. van der Aalst [AHKB03] an, da diese sowohl von einer bestimmten Implementierung als auch von bestimmten Einsatzgebieten unabhän-gig sind. Laut Definition ist ein Pattern „die Abstraktion von etwas Konkretem, das sich in einem bestimmten Kontext wiederholt“ [AHKB03].

Sie stellen die Anforderungen an die Ausdrucksmächtigkeit von WfMSen ohne dabei bestimmte Beschreibungssprachen zu benutzen. Somit kann man mit ihrer Hilfe WfMSe objektiv miteinander vergleichen.

Insgesamt gibt es 20 Patterns, die sechs Gruppen zugeordnet sind. Einige davon sind grundlegende Kontrollkonstrukte, die für alle WfMSe essentiell sind, andere wiederum sind sehr speziell und werden nur ganz selten umgesetzt.

Eine genaue Beschreibung aller 20 Patterns findet sich im Anhang B.

4.4.1 Systemvergleich anhand von Workflow Patterns

In diesem Abschnitt werden Heterogenitäten bei den Modellierungskonstrukten am Bei-spiel der beiden Systeme Staffware und MQSeries Workflow aufgezeigt. Syntaktische Heterogenitäten, wie z.B. unterschiedliche Benennung, werden hier nicht betrachtet.

Der Vergleich der beiden Systeme wird anhand der vorgestellten Workflow Patterns vorgenommen.

Tabelle 4.1 zeigt welche Patterns von den beiden Systemen unterstützt werden. Ein „+“

bedeutet eine direkte Unterstützung durch das jeweilige System, „+/-“ bedeutet, dass das Pattern durch andere Konstrukte abgebildet werden kann. „-“ bedeutet keine Unter-stützung.

Tabelle 4.1 Unterstützung der Workflow Patterns durch Staffware und MQSeries [AHKB03]

Pattern 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

MQSeries Workflow + + + + + + + - - - + - + - - - - - -

-Staffware + + + + + +/- - - - + + - + - - +/- - - +

-Im Folgenden werden die Modellierungskonstrukte, die von beiden Systemen oder von einem der beiden unterstützt werden, betrachtet. Auf Patterns, die von keinem der Sys-teme unterstützt werden, wird nicht näher eingegangen, da es bei diesen zu keinen Hete-rogenitäten kommen kann.

Pattern 1 (Sequence): Wird von beiden Systemen direkt unterstützt.

Pattern 2 (Parallel Split): Wird von beiden Systemen, durch mehrere ausgehende Kan-ten einer Aktivität, unterstützt.

Pattern 3 (Synchronisation): Wird von MQSeries direkt unterstützt. In Staffware gibt es einen „Wait Step“, der auf die Beendigung aller eingehenden Kanten wartet.

Pattern 4 (Exclusive Choice): Wird von MQSeries, durch sich gegenseitig ausschlie-ßende Bedingungen auf den Transitionen, unterstützt. In Staffware gibt es einen „Con-dition Step“, in dem eine Bedingung zu true oder false evaluiert wird.

Pattern 5 (Simple Merge): Wird von MQSeries direkt unterstützt. Bei Staffware können die normalen Schritte mehrere eingehende Kanten haben.

Pattern 6 (Multi Choice): Wird von MQSeries, durch sich nicht ausschließende Bedin-gungen auf den Transitionen unterstützt. Keine direkte Unterstützung durch Staffware.

Kann aber durch Hintereinanderschalten mehrerer Bedingungen simuliert werden. Da-durch ergeben sich allerdings komplexe und unübersichtliche Strukturen.

Pattern 7 (Synchronising Merge): Wird von MQSeries direkt unterstützt. Keine Unter-stützung durch Staffware.

Pattern 10 (Arbitrary Cycles): Keine Unterstützung durch MQSeries. Wird von Staffwa-re mit einigen Beschränkungen unterstützt.

Pattern 11 (Implicit Termination): Wird von beiden Systemen direkt unterstützt.

Pattern 13 (MI with a priori known design time knowledge): Wird von beiden Systemen durch eine Kombination von Splits und Joins unterstützt.

Pattern 16 (Deferred Choice): Keine Unterstützung durch MQSeries. Auch keine direkte Unterstützung durch Staffware, kann aber durch einen Parallel Split und den Abbruch der nicht-gewählten Aktivität simuliert werden.

Pattern 19 (Cancel Activity): Keine Unterstützung durch MQSeries. Direkte Unterstüt-zung durch Staffware.

Wie man beim Vergleich der Patterns sehen konnte, gibt es unterschiedliche Heteroge-nitäten zwischen den Systemen. Zum einen gibt es Konstrukte, die von einem System direkt unterstützt werden, vom anderen wiederum gar nicht (Patterns 7, 10, 19) oder nur indirekt durch Kombinationen anderer Konstrukte (Patterns 6, 16). Zum anderen gibt es

auch Patterns, die zwar von beiden Systemen direkt unterstützt werden, allerdings in unterschiedlicher Form (Patterns 3, 4, 5). Möglichkeiten zur einheitlichen Darstellung dieser heterogenen Konstrukte werden im folgenden Kapitel diskutiert.

4.4.2 Mapping der Modellierungskonstrukte

In Kapitel 2.2 wurde bereits über die grundlegenden Möglichkeiten des Mappings dis-kutiert. In diesem Kapitel wird nun konkret betrachtet, welche der Möglichkeiten für die identifizierten Heterogenitäten bei den Modellierungskonstrukten am besten ist. Die Betrachtung erfolgt zunächst anhand der drei Kategorien, die am Ende von Abschnitt 4.4.1 identifiziert wurden: unterschiedliche Umsetzung der Konstrukte, direkte Unter-stützung durch ein System vs. indirekte UnterUnter-stützung durch das andere und direkte Unterstützung durch ein System vs. keine Unterstützung durch das andere. Zum Schluss wird noch ein weiteres Problem aufgegriffen, das bei dem Systemvergleich nicht er-sichtlich wurde.

4.4.2.1 Unterschiedliche Umsetzung der Konstrukte

Werden Konstrukte durch alle Systeme unterstützt, allerdings in unterschiedlicher Form, so hat ein Mapping auf ein maximales oder minimales Konstruktmodell große Nachteile. Beim maximalen Modell müssen alle Konstrukte der verschiedenen Systeme bei der Visualisierung angezeigt werden. Dadurch wird eine Vielzahl von Konstrukten visualisiert, die eigentlich denselben Sachverhalt ausdrücken. Beim minimalen Modell können diese Konstrukte allerdings nicht visualisiert werden, da sie trotz gleicher Be-deutung unterschiedliche Umsetzungen haben. Das schränkt die Ausdrucksmächtigkeit der Visualisierung enorm ein.

Die optimale Variante für das Mapping in diesem Fall ist die Abbildung auf ein kanoni-sches Modell. So können die unterschiedlichen Konstrukte, die alle die gleiche Bedeu-tung haben, auf ein Konstrukt des kanonischen Modells abgebildet werden. So bleibt die Ausdrucksmächtigkeit erhalten und eine übersichtliche einheitliche Visualisierung wird ebenfalls gewährleistet.

4.4.2.2 Direkte vs. indirekte Unterstützung der Konstrukte

Werden Konstrukte durch manche Systeme direkt und durch andere nur indirekt unter-stützt, dann treten beim Mapping auf ein maximales oder minimales Modell genau die gleichen Probleme auf wie in Abschnitt 4.4.2.1.

Auch hier können die Probleme durch ein Mapping auf ein kanonisches Modell gelöst werden. Der Unterschied zu Abschnitt 4.4.2.1 ist allerdings, dass man hier nicht nur ein Konstrukt des Quellmodells auf das kanonische Modell abbilden muss. Hier hat meis-tens eine Kombination von Konstrukten des Quellmodells die gleiche Bedeutung wie

ein einziges Konstrukt des Zielmodells. Somit muss diese ganze Kombination auf ein einziges Konstrukt abgebildet werden.

4.4.2.3 Direkte vs. keine Unterstützung der Konstrukte

Werden Konstrukte durch manche Systeme direkt und durch andere gar nicht unter-stützt, dann macht vor allem ein Mapping auf ein minimales Modell keinen Sinn. Der Grund ist der gleiche, wie bei den zwei vorangegangenen Abschnitten.

Einen Unterschied gibt es hier zum Mapping auf ein maximales Modell. In diesem Fall gibt es nicht so viele unterschiedliche Konstrukte mit gleicher Bedeutung wie in den vorherigen beiden Abschnitten, da bei einigen Systemen diese Konstrukte gar nicht un-terstützt werden. Somit fällt dieser Nachteil hier nicht so schwer ins Gewicht. Trotzdem könnten unnötig viele unterschiedliche Konstrukte desselben Sachverhaltes visualisiert werden, was das Verständnis des Prozesses erschwert. Ein Vorteil wäre allerdings das einfachere Mapping.

Beim Mapping auf ein kanonisches Modell hat man wieder den Vorteil, dass man genü-gend Konstrukte haben kann, um die Ausdruckmächtigkeit nicht einzuschränken, aller-dings auch nicht zu viele unterschiedliche, sondern nur die einheitlichen des kanoni-schen Modells. So hat man die Möglichkeit die Konstrukte abzubilden, die im Quell-modell vorhanden sind, wobei gleichzeitig die nicht vorhandenen Konstrukte die Aus-drucksmächtigkeit nicht beeinträchtigen.

4.4.2.4 Keine Unterstützung der Konstrukte durch das kanonische Modell Da bei dem vorangegangenen Systemvergleich die beiden Systeme anhand der Patterns von W.M.P. van der Aalst miteinander verglichen wurden, die zusammen ein kanoni-sches Modell ergeben, waren immer alle Konstrukte der Quellmodelle im Zielmodell vorhanden. Dadurch ist ein Problem nicht aufgefallen. Es kann auch Konstrukte geben, die im Quellmodell vorhanden sind, aber im Zielmodell, also im kanonischen Modell, nicht. Denn selbst van der Aalst erhebt keinen Anspruch auf Vollständigkeit seiner Pat-terns. Und wenn ein anderes kanonisches Modell benutzt wird, das weniger Aus-drucksmächtigkeit besitzt, dann ist dieses Problem durchaus relevant.

Die optimale Lösung für das Problem wäre ein erweiterbares kanonisches Modell, bei dem man bei Bedarf neue Konstrukte anlegen kann. So kann sowohl die Ausdrucks-mächtigkeit, als auch eine übersichtliche einheitliche Visualisierung erhalten bleiben.

Ist das kanonische Modell nicht erweiterbar, so muss man auf andere, weniger zufrieden stellende Lösungen zurückgreifen. Eine Möglichkeit wäre, das jeweilige Konstrukt, wenn möglich, in mehrere einfachere Konstrukte zu zerlegen, die aber zusammenge-nommen genau die gleiche Wirkung und Bedeutung haben. Dadurch würde man aller-dings das einheitliche Prozessbild unnötig überladen und unübersichtlich machen. Die

Bestrebungen der Systemhersteller, die Modellierung und Visualisierung durch kom-paktere Prozesse einfacher zu machen, wären umsonst.

Kann man das jeweilige Konstrukt durch einfachere Konstrukte nicht darstellen, so ist die eben erwähnte Lösung auch nicht möglich. Es bleibt dann nur noch die Möglichkeit, das jeweilige Konstrukt manuell nachzumodellieren oder im globalen Prozess mit ei-nem Platzhalter anzudeuten, dass an der Stelle ein Modellierungskonstrukt nicht visuali-siert werden konnte. Die zweite Lösung ist allerdings nicht akzeptabel. Deshalb soll an dieser Stelle die Wichtigkeit eines erweiterbaren kanonischen Modells nochmals betont werden.

4.5 Zusammenfassung

In diesem Kapitel wurden, ausgehend von einer einheitlichen Datenbasis, Probleme identifiziert, die bei der Transformation von Prozessfragmenten auf ein anderes Meta-modell auftreten können. Dabei wurden Modellkonflikte sowohl im Kontroll- und Da-tenfluss, als auch im Organisationsmodell identifiziert. Zudem kann es, unabhängig von den bereits in Kapitel 3 identifizierten Namenskonflikten, Synonyme und Homonyme speziell auch auf der Prozessebene geben. Werden nicht nur Klasse-3-Systeme abgebil-det, dann kommt zu den vorherigen Problemen hinzu, dass für die Transformation benö-tigte Daten fehlen, die zunächst beschafft werden müssen. Zum Schluss des Kapitels wurden, anhand von Modellierungskonstrukten, die Modellkonflikte im Kontrollfluss zweier bekannter WfMSe aufgezeigt.