Metamodellbasierte und hierarchieorientierte ... - RosDok

3.4 Organisationsmodellierung bei DMWM 57
dells von Abbildung 3.13(b) wird bei jedem Starten der Aktivität AdjustMedication ein MedicationDosage-Objekt
erstellt und die Rückreferenz zur erstellenden Aktivität im Attribut creationActivity hinterlegt.
Somit kann der Zustand der erzeugenden Aktivität abgefragt und anhand dessen überprüft werden, ob die
entsprechenden Einträge gemacht wurden.
Die Invariante DiseaseAndUrgencyEnteredAfterDelivery ist der Klasse PatientData zugeordnet und stellt
sicher, dass nach dem Transport des Patienten die Datenfelder disease und urgency eingetragen sein
müssen. In dem Attribut editingActivities werden alle Aktivitäten eingetragen, bei denen das Objekt über
DataflowObject oder DataEdit-Objekte angefragt und Attribute während der Ausführung editiert wurden.
Betrachtet man das Workflowmodell von Abbildung 3.13(b), so sind die beiden Transport-Aktivitäten
AmbulanceDelivery und HelicopterDelivery über eine DeferredChoice-Beziehung verbunden. Wird eine
von diesen Aktivitäten ausgeführt, so wird das verbundene PatientData-Objekt zum editieren freigegeben.
Nun ist in der Invariante zu prüfen, wenn eine Transportaktivität im Attribut editingActivities auftaucht und
diese beendet wurde, so müssen die angegebenen Attribute im PatientData-Objekt eingetragen sein.
Listing 3.10 zeigt, dass die Invarianten zur Spezifikation der Konsistenz zwischen Workflow- und Datenmodell
nicht ganz intuitiv zu lesen und verstehen sind. Im Gegensatz zum Erstellen des Workflowmodells
muss der Modellierer beim Erstellen des Datenmodells gleichzeitig textuelle OCL-Invarianten spezifizieren.
Hier können recht schnell Fehler passieren und eine Validation der Modelle ist daher notwendig. Genau für
solche Zwecke stellt die in Abschnitt 4.3 vorgestellte Validierungsfunktionalität eine Möglichkeit bereit,
die Spezifikation zu prüfen. Im Speziellen lassen sich bei DMWM die Korrektheitseigenschaften anhand
der Workflow-Ausführung zur Runtime mit dem USE-Workflowplugin validieren, was in Kapitel 4 näher
erläutert wird.
3.4 Organisationsmodellierung bei DMWM
Neben der Datenmodellierung ist die Organisationsmodellierung ein zweiter wichtiger Aspekt der Workflowbzw.
Geschäftsprozessmodellierung. Entsprechend spielt beim ARIS-Ansatz (s. in Abschnitt 2.5.2.1) das
Organisationsmodell eine wichtige Rolle. Dort wird ein hierarchischer Ansatz gewählt. Ein Beispiel ist
in der Abbildung 2.2(b) angegeben. Das Unternehmen repräsentiert die Wurzel und die Hierarchieebenen
darunter geben die Abteilungen an. Die Abteilungen können rekursiv aufgegliedert werden, bis in den
Blättern des Organisationsbaums, den Abteilungen Rollen zugeordnet werden.
Im Folgenden wird die metamodellbasierte Organisationsmodellierung in DMWM vorgestellt. Dafür wird in
Abschnitt 3.4.1 das Metamodell zur Organisationsmodellierung für DMWM eingeführt. Außerdem wird die
Verbindung vom Organisationsmodell zum Workflowmodell über das DMWM-Metamodell hergestellt. In
Abschnitt 3.4.2 wird dann das Metamodell angewendet, um ein Organisationsmodell an einem Beispiel zu
erstellen. Auch die Zuordnung von Organisationseinheiten bzw. Rollen zu Aktivitäten wird dort geschehen.
3.4.1 Metamodell für die Organisationsmodellierung
Für DMWM wird ähnlich zum ARIS-Ansatz eine hierarchische Organisationsmodellierung verfolgt. Ebenso
wie beim Metamodell für ARIS [Sch01] wurde also ein Organisationsmetamodell entwickelt, das eine solche
(hierarchische) Modellierung ermöglicht. In Abbildung 3.14 ist das DMWM-Metamodell zur Organisationsmodellierung
angegeben.
Neben dem ARIS-Metamodell für die Organisationsmodellierung [Sch01] wurden auch bei den objektorientierten
Analyse-Patterns [FCJ96] ähnliche Klassendiagramme für eine hierarchische Organisationsmodel-