Metamodellbasierte und hierarchieorientierte ... - RosDok

3.3 Datenintegration 51
beiden Beziehungen Parallel und InterleavedParallelRouting zugeordnet.
Es sind noch viele weitere Integritätsbedingungen zur Sicherstellung von Soundness-Eigenschaften denkbar.
Beispielsweise stellen Zyklen von Guard- und exceeded-Assoziationen ebenso ein Problem dar. Die Beispiele
von diesem Abschnitt sollen jedoch ausreichen, um exemplarisch zu zeigen, wie OCL-Invarianten im
Metamodell eingesetzt werden können, um konsistente Workflowmodelle zu garantieren.
3.3 Datenintegration
In diesem Abschnitt wird die Datenintegration in Workflow-Modellierungssprachen im allgemeinen und in
DMWM-Workflowmodellen im speziellen betrachtet. Die Spezifikation von Daten in Geschäftsprozessmodellen
ist äußerst wichtig und Bestandteil aller populärer Prozessmodellierungssprachen, wie BPMN, Aktivitätsdiagrammen
und eEPKs. Des Weiteren gibt es Datenflussdiagramme, die den Zusammenhang zwischen
Funktionen, Schnittstellen und Speichern über Datenflüsse spezifizieren [Bal09]. In Abschnitt 3.3.1 werden
diese näher betrachtet und gezeigt, wo Unterschiede und Probleme existieren. Daraufhin wird der Ansatz der
Datenmodellierung und die Metamodellerweiterung für die Datenintegration in DMWM-Workflomodelle in
Abschnitt 3.3.2 näher eingeführt. Im DMWM-Ansatz lassen sich außerdem Datenkonsistenzbedingungen
mit OCL in den Datenmodellen spezifizieren, welche in Abschnitt 3.3.3 thematisiert werden. Damit können
beispielsweise fehlende Dateneinträge zur Runtime identifiziert werden und der Nutzer darauf hingewiesen
werden. Außerdem wird dort ein Beispiel gegeben, an dem die Datenintegration gezeigt wird.
3.3.1 Konzepte und Probleme der Datenintegration in etablierten Modellierungssprachen
Die Datenintegration ist in eEPKs vom Kontrollflusskonzept entkoppelt. Ein Beispiel für diese Modelle ist
in Abbildung 3.11(a) angegeben. In eEPKs sind die Datenspezifikationen für jede Aktivität neu anzugeben.
Datenflüsse, in denen einzelne Objekte von einer Aktivität zur nächsten gegeben werden sind nicht
vorgesehen.
Auch bei der in der Softwaretechnik entwickelten Strukturierten Analyse mit Realtime-Erweiterung (SA/RT)
und den dort verwendeten Datenflussdiagrammen (DfDs) sind die Ablaufspezifikation (CSpecs) von Datenflüssen
entkoppelt [Bal09]. Damit ist das Vorhandensein der Daten nicht Vorbedingung zur Ausführung
der Funktion. Es kann z.B. auch passieren, dass während der Ausführung Daten ausgetauscht werden oder
Funktionen später ihre Ausführung wieder aufnehmen. In Abbildung 3.11(d) ist ein Datenflussdiagramm zu
sehen, das einen Austausch von Daten zwischen zwei Funktionen Function1 und Function2 vorgibt. Hier
wissen wir nicht in welcher Reihenfolge diese Funktionen abgearbeitet oder ob eine Funktion mehrfach
ausgeführt werden muss. Bei DfDs liegt der Fokus der Modellierung auf der Verbindung zwischen Daten,
Funktionen, Schnittstellen und Speichern.
Bei Aktivitätsdiagrammen, wofür in Abbildung 3.11(c) ein Beispiel angegeben ist, stellen Objektflüsse
gleichzeitig Kontrollflüsse dar. Die Objekte dienen als Eingabeparameter für die Aktivitäten und sind
Vorbedingungen zur Ausführung und Konsumierung der Objekte. Die Modellierung eines expliziten Kontrollflusses
ist nicht erforderlich, wenn schon ein Objektfluss vorhanden ist. Objektflussspezifikationen
können aber Probleme bei der Verknüpfungen zu Flussoperatoren hervorrufen. Beispielsweise kann es Typkonsistenzprobleme
geben, wenn diese mit einem join synchronisiert oder mit einem fork verzweigt werden.
Auch semantische Probleme können hier auftreten, die die Effekte auf das Objektmodell bei Ausführung der
Flussoperatoren betreffen. Hier stellt sich beispielsweise die Frage, was passiert, wenn zwei Token miteinan-