18.01.2014 Aufrufe

Metamodellbasierte und hierarchieorientierte ... - RosDok

Metamodellbasierte und hierarchieorientierte ... - RosDok

Metamodellbasierte und hierarchieorientierte ... - RosDok

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

42 Deklarative UML metamodellbasierte Workflowmodellierung<br />

einer Gruppe Parallel gehören im gleichen Ausführungszustand sein müssen.<br />

Die Entscheidungsmodellierung ist ein wichtiger Teil von Geschäftsprozess- bzw. Workflowmodellierungssprachen<br />

(s. Abschnitt 2.5.2). So spielt sie auch für DMWM eine wichtige Rolle. Es wird zwischen expliziten<br />

<strong>und</strong> impliziten Entscheidungen unterschieden. Die implizite Entscheidungsmodellierung wird mit dem Deferred<br />

Choice Pattern in Abschnitt 3.2.4.4 näher erläutert. Für die explizite Entscheidungsmodellierung sind<br />

spezielle Aktivitäten, die Unterklassen von Decision im Metamodell von Abbildung 3.2 sind, vorgesehen.<br />

Die Kriterien zur Auswahl des korrekten Prozesspfades werden über die Guards angegeben.<br />

Die damit direkt oder über Gruppen indirekt verb<strong>und</strong>enen Aktivitäten können erst dann starten, wenn der<br />

Pfad ausgewählt wurde.<br />

Die OCL-Invarianten drücken zunächst nur die deklarative operationale Semantik aus. Das Überspringen<br />

der zur Runtime nicht ausgewählten Prozesspfade erfordert eine imperative Spezifikation, welche dann in<br />

Abschnitt 4.2.2 näher vorgestellt wird.<br />

✞<br />

☎<br />

1 context Parallel inv allInTheSameState:<br />

2 self.activity−>forAll(a | self.activity−>any(true).state=a.state)<br />

3<br />

4 context Guard inv onlySelectedActivitiesOrGroupsCanRun:<br />

5 if (self.option.oclIsTypeOf(Activity)) then<br />

6 self.option.oclAsType(Activity).state=#running implies self.selected<br />

7 else −− option is a group<br />

8 self.option.oclAsType(Group).activity−>exists(state=#running) implies self.selected<br />

9 endif<br />

✝<br />

✆<br />

Listing 3.6: Die OCL Invarianten zur Definition der Parallel-Beziehung <strong>und</strong> explizten<br />

Entscheidungsmodellierung<br />

3.2.4 Workflow Patterns<br />

Um die Mächtigkeit der hier eingeführten Workflow-Modellierungssprache zu demonstrieren wird in<br />

diesem Abschnitt eine Workflow Pattern Analyse gemacht. Dieses Mittel ist weit verbreitet <strong>und</strong> allgemein<br />

akzeptiert, um Modellierunggssprachen für Geschäftsprozesse bzw. Workflow Management Systeme zu<br />

analysieren. So wurden u.a. EPKs [MNN05], UML-Aktivitätsdiagramme [RAHW06], BPMN [WAD + 06],<br />

BPEL [WADH03] <strong>und</strong> das π-Kalkül [PW05] betrachtet.<br />

Die in diesem Abschnitt erfolgende Workflow Pattern Analyse ist nach Kenntnisstand des Autors die erste<br />

für einen deklarativen Workflow-Modelliengsansatz.<br />

Im Folgenden werden nicht alle OCL-Invarianten zur Definition der operationalen Semantik vorgestellt. Nur<br />

exemplarisch werden einige erklärt. Es wird lediglich die grobe Semantik umgangssprachlich erläutert. Die<br />

OCL-Spezifikationen genauso wie die Beschreibungen geben keine Garantie auf Vollständigkeit. Anhand<br />

von Modellausführungen zur Runtime wurde das Metamodell jedoch ausgiebig getestet (s. Kapitel 4).<br />

Sollten bei weiteren Ausführungen Unvollständigkeiten im Metamodell auftauchen, können diese anhand<br />

von Erweiterungen leicht behoben werden.<br />

3.2.4.1 Basic Control Flow Patterns<br />

Zu den in diesem Abschnitt vorgestellten Basic Control Flow Patterns zählen die gr<strong>und</strong>legenden Modellierungselemente,<br />

die von allen Workflowmodellierungssprachen unterstützt werden. In Abbildung 3.4 sind die

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!