Metamodellbasierte und hierarchieorientierte ... - RosDok

2.5 Geschäftsprozessmodellierung 27
keine korrekten Aktivitätsdiagramme widerspiegeln. Hier könnte die Formulierung der Bedingung mit OCL
helfen. Werden diese Bedingungen bei der Entwicklung des UML-Modellierungstools, das die Implementierung
des Metamodells bedeutet, berücksichtigt, würden diese Modellierungsfehler auffallen. Ein solcher
formalerer Weg, OCL zu verwenden, wird bei dem metamodellbasierten Workflowmodellierungsansatzes
vorgeschlagen, der in dieser Arbeit vorgestellten wird.
Für EPKs wurde zur Entwicklung des bflow-Modellierungswerkzeugs ein Metamodell entwickelt [GLKK08].
In Abbildung 2.5(a) ist zu sehen, dass ausschließlich die EPK-Modellierungselemente Ereignis, Funktion,
Konntektor und Kanten definiert sind. Kanten verbinden die restlichen Modellierungselemente mit den
beiden Assoziationen, die zur Klasse Node führen. Kanten sind im Metamodell wiederum durch die Klasse
Edge ausgedrückt. Wichtige Regeln für EPKs werden über die OCL ähnliche Constraintsprache Check
spezifiziert. Diese geben EPK-Regeln an, die in Abschnitt 2.5.2.1 schon eingeführt wurden. Z.B. müssen
EPKs mit Ereignissen beginnen und enden. Außerdem ist zu prüfen, dass vor einem Entscheidungskonnektor
eine Funktion und kein Ereignis steht.
Für eine weitergehende Integration der anderen ARIS-Sichten in der EPK kann man die eEPK benutzen,
so wie in Abbildung 2.2(d) verdeutlicht. Eine abstrakte eEPK wird daraufhin in [Sch02, S.46] angegeben,
die die Zusammenhänge der einzelnen Modelle visualisiert und eine Instanz des Metamodells darstellt.
Die Steuerungssicht im ARIS-Ansatz wird anhand eines Metamodells in [Sch02, S.45] vorgestellt, das als
eine Art Metamodell für die eEPK angesehen werden kann. Für eine Auslagerung der eEPK Modellierungselemente
können auch Funktionszuordnungsdiagramme verwenden werden, in denen Funktionen z.B.
mit Ein- und Ausgabedaten verknüpft werden. In [Sch01, S.105,118] werden dafür die Verbindungen der
Funktionssicht zu anderen Sichten auf Metamodellebene angegeben.
Ein Metamodell ist auch in der BPMN-Spezifikation hinterlegt. In Abbildung 2.5(c) ist ein Ausschnitt
aus diesem zu sehen, in der die Klasse FlowElement genauer betrachtet wird [BPM11, S.87]. In der
BPMN Spezifikation wurde auf sowohl umgangssprachliche als auch OCL-basierte Constraintzuweisungen
verzichtet. Die Metamodelle für BPMN bieten daher mehr Interpretationsspielraum als die Metamodelle der
UML.
Vergleicht man die Metamodelle von Aktivitätsdiagrammen (s. Abbildung 2.5(b) und BPMN (s. Abbildung
2.5(c)) ist zunächst auffällig, dass die Diagramme sich sehr ähneln. Die Integration der Kanten im
Metamodell und die Verknüpfung mit den restlichen Modellelementen durch die zwei Assoziationen ist
gleich gelöst worden. BPMN hat hier offenbar den Teil für sein Metamodell übernommen. Jedoch ist die
Datenspezifikation mit der Metaklasse DataObject bei BPMN ausgelagert worden.
Für ARIS wurde ein Metamodell in [Sch01] angegeben. Dort werden die Modellierungselemente der
einzelnen Diagramme definiert. Bei der Funktionssicht (s. Abbildung 2.2(a)) wird eine hierarchische
Zielmodellierung und hierarchische Funktionsmodellierung verfolgt. Es werden dafür zu den jeweiligen
Klassen im Metamodell reflexive Assoziationen modelliert (s. Abbildung 2.6). Zudem wird die Verbindung
zwischen Funktion und Ziel über eine Assoziation zwischen beiden Klassen angegeben [Sch01, S.38].
Außerdem hat Scheer die Anordnung und Ablaufreihenfolge bereits in der Funktionssicht über eine reflexive
Assoziation Anordnung im Metamodell ausgedrückt.
Zu den in Abbildung 2.6 genutzten Assoziationsklassen ist zu sagen, dass sie zur Bezeichnung der Assoziationen
genutzt wurden. Eine direkte Benennung der Assoziation wäre in UML-Klassendiagrammen
stattdessen ebenfalls möglich gewesen.
Ähnlichkeiten weist das Metamodell zur ARIS Funktionssicht von Abbildung 2.6 mit dem des Metamodells
für Aufgabenmodelle, das später in dieser Arbeit behandelt wird, auf. Beide Metamodelle beinhalten eine
Hierarchisierung, Zielmodellierung und Angabe der Ablaufreihenfolgen von Funktionen bzw. Aufgaben.