Metamodellbasierte und hierarchieorientierte ... - RosDok

3.3 Datenintegration 53
Bei UML-Aktivitätsdiagrammen können durch «selection» Klauseln, die an Objektfluss-Kanten annotiert
werden, Kriterien zur Objektauswahl spezifiziert werden (s. Abbildung 3.11(c)). Ist der Objektfluss mit
einem Datastore-Knoten verbunden repräsentiert diese Klausel eine Datenbankanfrage. Die Möglichkeit der
Anfragespezifikation ist bei den anderen Modellierungssprachen nicht vorgesehen. Bei DfDs sind Speicher
zwar integraler Bestandteil der Modellierungssprache, bei den ausgehenden Datenflüssen kann man anhand
der Data-Dictionary Spezifikation jedoch nur Datentypen annotieren. Im Fall von Abbildung 3.11(d) ist mit
{A} angegeben, dass eine Menge von Objekten des entsprechenden Typs angefragt wird. Eine Menge von
den entsprechenden Objekten wird bei BPMN mit ||| und bei Aktivitätsdiagrammen mit Set of in
den Objektknoten angegeben. Die Spezifikation von einer Menge von Daten ist bei EPKs nicht vorgesehen.
In Aktivitätsdiagrammen können außerdem ankommende Objekte mit AcceptEventActions modelliert werden,
um dann in den zugeordneten Objektknoten gesammelt zu werden. Zudem lassen sich die Objektflüsse
gewichten, so dass nur eine gewisse Anzahl von Objekten an diesen Kanten langlaufen darf. Diese Modellierungselemente
sind in Abbildung 3.11(c) angegeben und werden nur für Aktivitätsdiagramme bereitgestellt.
Den anderen hier betrachteten Sprachen fehlen solche Ausdrucksmöglichkeiten.
Nach [UML10, S.411] und [Sch01, S.118f] gibt es vier Aktionen, die Aktivitäten auf Daten auslösen können:
• read: Lesen eines/mehrerer Datenelemente
• create: Anlegen eines/mehrerer Datenelemente
• update: Ändern eines/mehrerer Datenelemente
• delete: Löschen eines/mehrerer Datenelemente
Die in Abbildung 3.11 angegebenen Diagramme zeigen, dass die drei ersten oben aufgeführten Aktionen
ausgedrückt werden können. Die im Folgenden aufgeführte Modellierungsweise ist bei allen angegebenen
Modellierungssprachen im Prinzip gleich. Es gibt im Wesentlichen drei Verbindungen von Datenelementen
zu Aktivitäten. Ein gerichteter Pfeil vom Datenobjekt zur Aktivität repräsentiert eine Leseaktion. Ein
Pfeil in die umgekehrte Richtung von der Aktivität zum Datenobjekt kann eine create bzw. write Aktion
ausdrücken. Update-Operationen können in zwei Weisen dargestellt werden. Zum einen zeigt das EPK-
Beispiel von Abbildung 3.11(a), dass ein Pfeil vom Datenobjekt zur Aktivität und zurück modelliert werden
kann. Zum anderen ist beim BPMN-Beispiel von Abbildung 3.11(b) eine ungerichtete Assoziation, die
das Datenelement D mit Aktivitäten verknüpft, zu sehen. Die letzte oben aufgeführte Aktion Löschen von
Datenelementen kann visuell in den Diagrammen jedoch nicht ausgedrückt werden.
Alle hier vorgestellten Datenintegrationen in die Workflowmodelle sind darstellbar, aber nicht ausführbar. Die
in [BF08a] und oben angesprochenen Probleme bei der Verknüpfung von Objektflüssen mit Flussoperatoren
auf das Objektmodell bleiben offen.
Eine eindeutigere Semantik der Objektintegration beinhaltet der DMWM-Ansatz, der in den folgenden
Abschnitten näher eingeführt wird. DMWM ist auch mit der Verbindung zu den Datenspezifikationen
ausführbar und die Effekte der im Metamodell definierten Elemente werden klar definiert.
3.3.2 Metamodell für Datenintegration
Zur Datenmodellierung werden UML-Klassendiagramme genutzt. Das Workflow-Metamodell liegt ebenfalls
als UML-Klassendiagramm vor. Für eine Integration von Workflow- und Datenmodellen kann man die UML-
Klassendiagramme vereinigen. Voraussetzung hierfür ist jedoch, dass es keine Namenskonflikte bei den
Klassenbezeichungen zwischen Datenmodell und Workflow-Metamodell gibt. Die Workflowmodellierung