Analyse von UML Aktivitäten mit DMM - Universität Paderborn

„Neue Ansätze der Softwarequalitätssicherung“
Analyse von UML Aktivitäten mit DMM
Matthias Multhaup
E-Mail: emperor@upb.de
Universität Paderborn,
Fakultät für Elektrotechnik, Informatik und Mathematik,
Institut für Informatik, Warburger Str. 100, 33098 Paderborn
Zusammenfassung Die Semantik von visuellen Modellierungssprachen
wird oft nur informell und dadurch meist unpräzise definiert. Eine präzise
Definition der Semantik ist jedoch erforderlich, wenn Modelle automatisiert
auf die Einhaltung semantischer Qualitätskriterien überprüft
werden sollen. Dynamic Meta Modeling (DMM) ist eine Technik zur formalen
Spezifikation von Modellsemantiken. Diese Arbeit stellt vor, wie
DMM zur Spezifikation einer formalen Semantik für Workflowdiagramme
(UML Aktivitätendiagramme) eingesetzt werden kann. Anschließend
werden die Workflowdiagramme mit dem Modelchecker GROOVE automatisiert
auf das Qualitätskriterium der Soundness untersucht.
1 Einleitung
In Unternehmen der heutigen Arbeitswelt setzen sich Geschäftsprozesse meist
aus zahlreichen Teilaufgaben zusammen. Diese Teilaufgaben werden oft parallel
und von unterschiedlichen Personen bearbeitet. Manche Teilaufgaben können
erst bearbeitet werden, wenn andere bereits fertig gestellt sind. Ebenso kann es
vorkommen, dass bestimmte Teilaufgaben überhaupt nicht erledigt werden, weil
sie zum Beispiel nur zur Erfüllung spezieller Kundenwünsche erforderlich sind. Je
mehr Teilaufgaben, Abhängigkeiten und Spezialfälle ein Geschäftsprozess beinhaltet,
desto komplexer wird er und desto schwieriger lässt er sich beschreiben.
Da effiziente Geschäftsprozesse für den Erfolg eines Unternehmens von entscheidender
Bedeutung sind, empfiehlt es sich, diese Prozesse im Vorfeld genau zu
planen, und sie vor ihrer tatsächlichen Ausführung gründlichen Simulationen
und Tests zu unterziehen. Die Planung bzw. der Entwurf von Geschäftsprozessen
kann mit sogenannten Workflowmodellen vorgenommen werden. In Abschnitt 2
dieser Seminararbeit wird ein Konzept zur visuellen Modellierung von Workflows
vorgestellt, dass auf UML Aktivitätendiagrammen basiert. Mit Hilfe der
vorgestellten Modellierungstechnik wird dann ein Workflowmodell erstellt, das
im weiteren Verlauf der Seminararbeit auf seine Qualität hin untersucht wird.

Die Modellierung von Workflows ist eine anspruchsvolle Aufgabe, die stark von
den Fähigkeiten und der Aufmerksamkeit des Modellierers abhängt. Nicht jedes
Workflowmodell drückt tatsächlich die gewünschten Sachverhalte aus. Oft
werden wichtige Teilaufgaben vergessen, Abläufe nicht korrekt abgebildet oder
Dinge in das Modell mit einbezogen, die für den Ablauf irrelevant sind. Viele
Qualitätsansprüche an ein Workflowmodell sind stark vom konkreten Einsatzbereich
abhängig und daher sehr speziell. Andererseits existieren jedoch auch
Eigenschaften die unabhängig vom Einsatzbereich für jedes qualitativ hochwertige
Workflowmodell gelten sollten. So sollte zum Beispiel jeder Workflow frei
von Deadlocks sein, so das er in jedem Fall bis zum Ende ausgeführt werden
kann. van der Aalst [3] hat solche allgemeinen Eigenschaften für Workflowmodelle
erarbeitet und im Qualitätskriterium der Soundness zusammengefasst.
Abschnitt 3 dieser Arbeit, stellt die genauen Anforderungen der Soundness an
ein Workflowmodell vor. Auf Grundlage der Arbeit von Soltenborn [1] wird
dann erläutert, wie sich dieses, ursprünglich für Petri Netze formulierte, Kriterium
konkret auf UML Aktivitätendiagramme anwenden lässt.
Ob ein Workflowmodell tatsächlich sound ist, lässt sich von einem Menschen
für komplexe Modelle kaum feststellen. Daher empfiehlt es sich, Workflowmodelle
automatisiert auf das Kriterium der Soundness zu überprüfen. Damit ein
visuelles Modell jedoch automatisiert überprüft werden kann, muss es zunächst
in Daten transformiert werden, die von Computern verarbeitet werden können.
Um diese Transformation für die Syntax des Modells vorzunehmen stellen UML
Aktivitätendiagramme ein Metamodell bereit. Das Metamodell kann in einer beliebigen
objektorientierten Programmiersprache implementiert werden und die
Workflowmodelle lassen sich dann in Objektinstanzen dieser Implementierung
umsetzen. So transformierte Modelle können auf syntaktische Korrektheit überprüft
werden. Soundness ist jedoch kein syntaktisches sondern ein semantisches
Qualitätskriterium. Da die Semantik von UML Aktivitätendiagrammen von der
Object Management Group (OMG) nur in textueller Form spezifiziert wurde,
ist sie nicht von einen Computer verarbeitbar.
Damit eine automatische Analyse auf Soundness durchgeführt werden kann, bedarf
es einer Möglichkeit die Semantik der UML Aktivitätendiagramme formal
zu spezifizieren. Dabei soll die Semantik einerseits präzise, andererseits aber weiterhin
für den Menschen verständlich sein. Das von Hausmann [4] entwickelte
Dynamic Meta Modeling (DMM) bietet diese Möglichkeit für alle visuellen
Modellierungssprachen, deren Syntax bereits durch ein Metamodell beschrieben
ist. DMM erweitert das syntaktische Metamodell um zusätzliche Klassen,
die für die Beschreibung der statischen Semantik notwendig sind. Jeder Nutzer
der das syntaktische Metamodell versteht, sollte somit in der Lage sein, auch
das semantische Metamodell zu verstehen. Alle Aspekte der dynamischen Semantik
werden in DMM durch Graphtransformationsregeln spezifiziert. Diese
Regeln beschreiben, wie sich die Instanzen des semantischen Metamodells über
die Zeit verändern können. Da Graphtransformationsregeln auf dem Konzept

von Zuständen und Zustandsänderungen basieren, stellen sie einen angemessenen
Formalismus für die Beschreibung von dynamischem Verhalten dar, ohne
die semantische Lücke zwischen formeller und informeller Beschreibung zu groß
werden zu lassen. Im Abschnitt 4 dieser Seminararbeit wird DMM genauer vorgestellt
und dann anhand einer von Hausmann durchgeführten Fallstudie gezeigt,
wie sich die Semantik von UML Aktivitätendiagrammen formal mittels DMM
spezifizieren lässt. Auf Grundlage dieser formalen Semantik kann anschließend
eine automatische Überprüfung auf Soundness durchgeführt werden.
In Abschnitt 5 wird erläutert, wie Soltenborn [1] eine solche Überprüfung
mit Hilfe des Modelcheckers GROOVE durchgeführt hat. Abschließend fasst
Abschnitt 6 die vorgestellten Konzepte und Verfahren kurz zusammen und gibt
einen Ausblick auf weitere Herausforderungen im Bereich der Qualitätssicherung.
2 Workflowmodellierung
Workflows beschreiben Arbeitsabläufe für Arbeitsaufträge. Ein Arbeitsauftrag
kann aus mehreren Teilaufgaben bestehen. Die Reihenfolge, in der die verschiedenen
Teilaufgaben abgearbeitet werden müssen, wird durch einen Arbeitsprozess
festgelegt. Diese grundlegende Struktur von Workflows wird am besten an einem
konkreten Beispiel deutlich. Man stelle sich den stark vereinfachten Ablauf eines
Spielertransfers zwischen zwei Fußballmannschaften vor. Zunächst treffen
sich die Manager der beiden Vereine um eine Ablösesumme für den Spieler auszuhandeln.
Währenddessen wird der Spieler zum Probetraining eingeladen, um
seine Fitness zu testen. Wenn sich die Manager über eine Ablösesumme geeinigt
haben, kann der Spieler einen Vertrag bei seinem neuen Verein unterschreiben,
wird hingegen keine Einigung über die Ablösesumme erzielt, müssen die Transferbemühungen
abgebrochen werden.
Soltenborn beschreibt in [1], wie sich UML Aktivitätendiagramme für die
Modellierung von Workflows nutzen lassen. Ein Aktivitätendiagramm enthält jeweils
den Arbeitsprozess für einen Arbeitsauftrag. Der Beginn des Arbeitsprozesses
wird durch eine InitialNode und das Ende durch eine ActivityFinalNode
gekennzeichnet. Alle Teilaufgaben werden in Form von Actions modelliert, die
durch ActivityEdges miteinander verbunden und in eine Reihenfolge gebracht
werden. ForkNode und JoinNode markieren parallele Bearbeitungsmöglichkeiten
innerhalb des Arbeitsprozesses. Die Modellierung von Bearbeitungsbedingungen
und alternativen Bearbeitungswegen geschieht mit Hilfe der DecisionNode und
der MergeNode.
Das Workflowbeispiel „Spielertransfer“ lässt sich mit Hilfe der genannten Techniken
wie in Abbildung 1 modellieren. Eine InitialNode markiert den Startpunkt
des Prozesses. Auf die InitialNode folgt eine ForkNode, die den Bearbeitungsprozess
aufteilt und dadurch die parallele Bearbeitung der Actions

Verhandlung
Probetraining
Spielertransfer
[ok]
[zu teuer]
Transferabbruch
Vertragsabschluss
Abbildung 1. Workflow „Spielertransfer“ als UML Aktivitätendiagramm
„Verhandlung“ und „Probetraining“ ermöglicht. Auf die Action „Verhandlung“
folgt eine DecisionNode an der das Verhandlungsergebnis abgefragt wird. Auf
eine gescheiterte Verhandlung folgt die Action „Transferabbruch“. Verläuft die
Verhandlung hingegen erfolgreich, dann wird der Prozess über eine MergeNode
zur Action „Vertragsabschluss“ weitergeleitet. Zum Schluss wird die parallele
Bearbeitung durch eine JoinNode wieder zusammengeführt und der Prozess endet
an einer ActivityFinalNode.
Das Beispiel vermittelt einen Eindruck davon wie UML Aktivitätendiagramme
aufgebaut werden, und welche Funktion den einzelnen UML Elementen dabei
zukommt. Dieser Eindruck ist jedoch unpräzise. Es ist nicht klar, welche Elemente
mit welchen kombiniert werden können und es bestehen mehrere Interpretationsmöglichkeiten
für die tatsächliche Bedeutung dieser Kombinationen.
Die Regeln, die die Kombinationsmöglichkeiten der einzelnen Elemente präzise
festlegen, bezeichnet man als die abstrakte Syntax der Diagramme. Die OMG
hat die abstrakte Syntax von UML Aktivitätendiagrammen in [7] als Metamodell
spezifiziert. Dieses Metamodell besteht aus Klassendiagrammen, welche die
Beziehungen der einzelnen UML Elemente zueinander formal beschreiben.
Der Workflow „Spielertransfer“ lässt sich auf dieser Grundlage als Objektdiagramm
darstellen, welches das Metamodell instanziiert. Abbildung 2 zeigt einen
Ausschnitt des Objektdiagramms. Alle UML Elemente sind Objektinstanzen ihrer
jeweiligen Metamodellklassen und die Verbindungen der Elemente untereinander
sind durch Assoziationen zwischen den Objektinstanzen ausgedrückt. Das
Objektdiagramm kann somit als ungerichteter Graph angesehen werden, wobei
die Objektinstanzen die Knoten und die Assoziationen die Kanten des Graphen
darstellen. Durch die Formalisierung der abstrakten Syntax als Metamodell ist
präzise festgelegt, welche Elemente mit welchen anderen Elementen kombiniert
werden können, bzw. welche Objektinstanzen mit welchen und wie vielen anderen
Objektinstanzen assoziiert sein dürfen. Dadurch wird es möglich, die UML
Aktivitätendiagramme automatisiert zu verarbeiten. Ein Programm, wie zum
Beispiel ein grafischer Editor zu Erstellung von UML Diagrammen, müsste das

vorliegende Metamodell implementieren und könnte auf dieser Grundlage dann
die syntaktische Korrektheit einzelner Diagramme überprüfen.
+source
:ForkNode
+source
+outgoing
+outgoing
:Edge +target Verhandlung:
+incoming
Action
:Edge
+target
+incoming
Probetraining:
Action
+source
+source
+outgoing
+outgoing
:Edge
+source
+incoming
:DecisionNode
+source
+target
:Edge
+outgoing
+incoming
:Edge +target :MergeNode
+incoming
Abbildung 2. Ausschnitt des Workflows „Spielertransfer“ als Objektdiagramm
Syntaktische Korrektheit garantiert jedoch noch nicht, dass ein Diagramm auch
tatsächlich das aussagt, was man beabsichtigt. Bezogen auf das Diagramm „Spielertransfer“,
ist zum Beispiel nicht klar was passiert, wenn der Spieler sein Probetraining
beendet hat, die Verhandlungen jedoch noch nicht abgeschlossen sind.
Es könnte sein, das der Spieler zunächst auf das Ende der Verhandlungen wartet,
andererseits könnte es aber auch sein, dass er sofort den Vertrag unterschreibt.
Um beurteilen zu können welchen Weg der Prozess in diesem Fall tatsächlich
nehmen wird, muss das dynamische Verhalten von UML Aktivitätendiagrammen
betrachtet werden. Dieses Verhalten wird durch Tokenfluss modelliert. Der
Tokenfluss ist ein semantisches Konzept und wird daher nicht im syntaktischen
Metamodell der OMG beschrieben. Stattdessen hat die OMG textuelle Beschreibungen
für das Verhalten von UML Aktivitätendiagrammen verfasst. Zum groben
Verständnis des Verhaltens sollte diese textuelle Beschreibung jedoch zunächst
ausreichen. Eine Methode zu formalen Definition des dynamischen Verhaltens
wird später in Abschnitt 4 vorgestellt.
Um Tokenfluss zu verstehen, muss man sich ein UML Aktivitätendiagramm als
etwas Ausführbares und über die Zeit Veränderliches vorstellen. Zu Beginn der
Ausführung eines Aktivitätendiagramms wird an der InitialNode ein Token
erzeugt. Dieses Token wird nach und nach über die gerichteten ActivityEdges,
sowie die DecisionNodes und MergeNodes geroutet. An einer ForkNode werden
eingehende Tokens vervielfältigt, so dass ein Token für jeden Ausgang bereitgestellt
werden kann. An einer JoinNode werden hingegen alle eingehenden
Tokens zu einem einzelnen Token zusammengefasst. Eine JoinNode wird immer
nur dann aktiv, wenn an allen Eingängen Tokens vorhanden sind.

Das Token selbst ist eine Art Kontrolleinheit, die sich nur an Actions und an der
ActivityFinalNode aufhalten darf. Sobald ein Token an einer Action ankommt,
kann die jeweilige Action ausgeführt werden. Erst wenn die Ausführung abgeschlossen
ist wird das Token am Ausgang der Action wieder bereitgestellt. Das
Tokenrouting folgt dem von Bock [6] beschriebenen Prinzip des Traverse-To-
Completion. Das bedeutet, dass ein Token erst dann vom Ausgang einer Action
über einen Pfad geschickt wird, wenn er offen ist und somit komplett bis zur
nächsten Action bzw. ActivityFinalNode durchlaufen werden kann. Dadurch
ist sichergestellt das sich keine Tokens zwischen den Actions befinden, also beispielsweise
an einer JoinNode stecken bleiben können.
3 Qualitätskriterium für Workflows: Soundness
Bei der Erstellung von Workflowdiagrammen können leicht Modellierungsfehler
geschehen. In [3] hat van der Aalst gängige Fehler identifiziert, die bei
der Erstellung von Workflowdiagrammen in jedem Fall vermieden werden sollten.
Überflüssige Aufgaben sind all die, die bei der Ausführung des Workflows
niemals bearbeitet werden. Diese Aufgaben machen das Diagramm nur unnötig
komplex und können weggelassen werden. Deadlocks entstehen, wenn Aufgaben
kreisförmige Abhängigkeiten untereinander aufweisen. Wenn zum Beispiel Aufgabe
A erst dann ausgeführt werden kann, wenn Aufgabe B bereits erledigt ist,
Aufgabe B im Gegenzug aber auf den Abschluss von Aufgabe A wartet, dann
werden die Aufgaben nie abgeschlossen und der Workflow nicht bis zum Ende
ausgeführt. Für einen Workflow muss außerdem eindeutig definiert werden,
wann er gestartet und wann er beendet wird, das bedeutet, er sollte genau einen
Startzustand und einen Endzustand aufweisen. Des weiteren muss sichergestellt
werden, dass sich beim Erreichen des Endzustandes keine weiteren Aufgaben in
Ausführung befinden. Ein Workflow der diese Eigenschaften aufweist, erfüllt das
Kriterium der Soundness bzw. kann als sound bezeichnet werden.
In [1] hat Soltenborn das Kriterium der Soundness speziell auf UML Aktivitätendiagramme
übertragen. Ein UML Aktivitätendiagramm ist sound, wenn
folgende Bedingungen erfüllt sind:
1. Das Diagramm muss genau eine InitialNode und eine ActivityFinalNode
enthalten.
2. Für jede Action im Diagramm muss zumindest eine Möglichkeit bestehen,
ausgeführt zu werden.
3. Wenn ein Token die ActivityFinalNode erreicht, dürfen sich keine weiteren
Tokens mehr im Aktivitätendiagramm befinden.
4. Irgendwann muss ein Token die ActivityFinalNode erreichen.
Für unser Beispiel „Spielertransfer“ lässt sich leicht erkennen, dass Bedingung 1
erfüllt ist. Um die anderen Bedingungen zu überprüfen muss man sich überlegen
welche möglichen Ausführungsszenarien für das Diagramm in Frage kommen. Da

der Workflow recht übersichtlich gehalten wurde, existieren nur zwei verschiedene
Ausführungsszenarien.
– Wenn sich die Manager über eine Ablösesumme einig werden können, dann
wird ein Token über die MergeNode zur Action „Vertragsabschluss“ geroutet.
Da eine MergeNode nur Tokens routet, jedoch nicht zusammenfasst, wandert
ebenfalls ein Token von der Action „Probetraining zu „Vertragsabschluss“.
Der Vertrag wird ein zweites Mal unterzeichnet. Beide Tokens bleiben an der
Action „Vertragsabschluss“ stecken, weil am anderen Eingang der JoinNode
kein Token zu Verfügung steht und somit keine Tokens zusammengefasst
werden können. Die Ausführung verstößt gegen Bedingung 4 der Soundness
Kriterien, da kein Token die ActivityFinalNode erreicht.
– Wenn sich die Manager nicht auf eine Ablösesumme einigen können, dann
wandert ein Token zur Action „Transferabbruch“. Das Token der Action
„Probetraining wandert hingegen weiter zur Action „Vertragsabschluss“. Dadurch
werden sowohl „Vertragsabschluss“ als auch „Transferabbruch“ ausgeführt.
Anschließend werden die beiden Tokens an der JoinNode zusammengefasst
und schließlich erreicht ein Token die ActivityFinalNode. Dieses
Ausführungsszenario verstößt gegen keines der Soundness Kriterien, es stellt
jedoch bezogen auf den Anwendungskontext „Spielertransfer“ eine nicht beabsichtigte
Ausführung dar, die allerdings durch das allgemeine Kriterium
der Soundness nicht als Fehler identifiziert werden kann.
Unser Beispiel ist nicht sound, da ein Ausführungsszenario existiert, das gegen
eine der Soundnessbedingungen verstößt. Für komplexe Diagramme lässt sich
eine manuelle Überprüfung auf Soundness, wie sie gerade vorgenommen wurde,
jedoch kaum realisieren, da die Anzahl der möglichen Ausführungsszenarien bei
komplexen Diagramm unüberschaubar groß wird. Daher ist es erstrebenswert
die Überprüfung von Soundness mit Hilfe von Computern vorzunehmen.
Bedingung 1 ist eine strukturelle Anforderung an das Diagramm. Die Bedingung
lässt sich mit syntaktischen Mitteln recht einfach überprüfen. Beispielsweise
könnte ein grafischer Editor, der das Metamodell der UML Aktivitätendiagramme
implementiert, und der zur Erstellung dieser Diagramme dient, direkt
überprüfen, wie viele Instanzen der InitialNode und der ActivityFinalNode
für das jeweilige Diagramm existieren.
Die Bedingungen 2-4 beziehen sich hingegen auf den Tokenfluss, also auf das
dynamische Verhalten innerhalb des Diagramms. Das Verhalten kann nur auf
semantischer Ebene definiert werden. Wie bereits erwähnt, hat die OMG für
UML Aktivitätendiagramme keine formale Semantik spezifiziert. Die Spezifikation
der UML Aktivitätendiagramme muss daher zunächst um eine formale
Semantik erweitert werden. Erst dann kann eine Überprüfung der Bedingungen
automatisiert durchgeführt werden. Eine Methode zur Spezifikation einer formalen
Semantik ist das von Hausmann entwickelte Dynamic Meta Modeling.

4 Dynamic Meta Modeling
Dynamic Meta Modeling (DMM) ist eine Technik zur formalen Definition von
Modellsemantiken, für visuelle Modellierungssprachen, deren Syntax durch ein
Metamodell definiert ist. Abbildung 3 gibt einen Überblick darüber, welche zusätzlichen
Definitionen DMM neben dem bereits vorhandenen Metamodell bereitstellt.
Zunächst erstellt DMM ein erweitertes semantisches Metamodell, das
mit Hilfe von Metarelationen auf das syntaktische Metamodell gemappt wird.
Dieses Verfahren nennt sich Denotational Meta Modeling. Da sich mit einem Metamodell
nur statische Konzepte ausdrücken lassen, legt DMM zusätzlich Graphtransformationsregeln
fest, die beschreiben, wie sich die Instanzen des semantischen
Metamodells über die Zeit verändern können. Graphtransformationsregeln
dienen damit der Definition der dynamischen Semantik. Aus der Anwendung der
Graphtransformationsregeln auf Instanzen des semantischen Metamodells entsteht
ein Transitionssystem. Dieses beschreibt nach und nach alle Zustände, die
die jeweilige Modellinstanz annehmen kann. Bezogen auf UML Aktivitätendiagramme
sind dies die möglichen Varianten des Tokenflusses durch das Diagramm.
4.2. Introduction to graph transformations 41
Syntax
Definition
Meta Model
Expression
Model elements
semantic
mapping
Semantics Definition
Static Semantics
Enhanced Meta Model
conforms to
Transition System
States
Dynamic Semantics
Graph Transformation
Rules
conforms to
Language
AbbildungFigure 3. Überblick 4.1: Overview über die Dynamic of the DMM Meta approach Modeling Technik [4]
Model (Instance)
this correlates to the requirements formulated above. Finally, we will see how
Die Grundlage für die Erstellung des semantischen Metamodells bildet zunächst
DMM can be applied to UML Activities.
das syntaktische Metamodell. Da die meisten syntaktischen Elemente auch eine
Semantik besitzen, können ihre Klassen aus dem syntaktischen Metamodell
übernommen und entsprechend modifiziert, bzw. erweitert werden, indem ihnen
Assoziationen 4.2 Introduction zu anderen Klassen tound graph neue Operationen transformations
hinzugefügt werden.
Für alle rein semantischen Konzepte, wie zum Beispiel den Tokenfluss bei UML
In this section we want to give a brief introduction to the idea of graph transformations.
[BH04] is a good introduction to graph transformations in general;
more information can be found in [Roz97, CMR + 97, EHK + 97, EEPPR04].
Graphs are a powerful formalism to describe complex structures and systems.
They are heavily used in the area of software engineering (for instance,
we have seen in definition 3.2 how an instance of a class diagram can be interpreted
as a graph).
Graph transformations are a formalism that allows to precisely specify
how graphs can evolve. This is exactly the usage of graph transformations

Aktivitätendiagrammen, werden neue Klassen erstellt. In Abbildung 4 ist ein
Ausschnitt des semantischen Metamodells für UML Aktivitätendiagramme dargestellt.
Die vier Klassen Token, Offer, BufferNode und ActivityExecution wurden
gegenüber dem syntaktischen Metamodell hinzugefügt.
Die Klasse Token modelliert die Kontrolleinheiten die durch das Diagramm bewegt
werden. Tokens werden von Actions benötigt um ausgeführt werden zu
können. Um Tokens zwischenzuspeichern, verfügen Actions über BufferNodes
an ihren Ein- und Ausgängen. Ein Token, das an einer BufferNode verfügbar ist,
wird durch die Offer Klasse ausgedrückt. Offer Objekte können mit der neuen
Methode „canCarry(o:Offer)“ über Edges transportiert werden. BufferNodes
können Offers mit der Methode „acceptOffer(o:Offer)“ akzeptieren. Wenn eine
Offer akzeptiert wird, wird das assoziierte Token in einem Schritt von der offerierenden
zur akzeptierenden BufferNode bewegt. Die Verwaltung der Tokens
und die Ausführung der Actions regelt die Klasse ActivityExecution. So
sorgt sie zum Beispiel dafür, dass beim Start der Ausführung ein Token an
der InitialNode des Diagramms erzeugt wird. Wenn keine Tokens mehr im
Diagramm vorhanden sind und keine Action mehr ausgeführt wird, endet die
ActivityExecution.
Activity
1
executes
0..*
0..*
ActivityNode
1
source
1
ActivityEdge
1
carries
Offer
0..1
0..*
target
1
0..*
1
0..*
belongs to
ActivityExecution
1
ControlNode DecisionNode
BufferNode
1
carries
Token
0..*
0..*
ObjectNode
Action
Abbildung 4. Ausschnitt Fig. 3. aus Enhanced dem semantischen UML Activity Metamodell meta model für UML Aktivitäten [2]
decisionNode.flow()
Insgesamt wurden dem semantischen Metamodell deutlich mehr Klassen, als die
:Offer
vier genannten, hinzugefügt. Die vier beschriebenen Klassen verdeutlichen jedoch
die wesentlichen Konzepte. Eine komplette Beschreibung des semantischen
carries
carries {new}
Metamodells für {destroyed} UML Aktivitätendiagramme findet sich im Anhang der Disser-
target
source
tation von Hausmann :ActivityEdge [4]. Dort decisionNode:DecisionNode
sind zudem alle Methoden:ActivityEdge aufgeführt, die den
Klassen hinzugefügt wurden. Da die Ausführung einer Methode dynamisches
Fig. 4. DMM rule decisionNode.flow()
transition system’s point of view, the result is a branch, representing all possible
executions of the Activity at that point. Figure 5 shows one possible application
of rule decisionnode.flow(). In this case, the offer is routed along the top edge of
the DecisionNode. The right part of that figure shows two consecutive states of
the Activity.
The resulting transition system represents the complete behavior of the Activity
under consideration. It will be the basis for analysis of the Activity, using

Verhalten impliziert, können die Folgen der Ausführung nicht im Metamodell
beschrieben werden. Stattdessen wird jede Methode durch eine Graphtransformationsregel
beschrieben, die darstellt wie sich Instanzen des Metamodells durch
die Methodenausführung verändern.
In Abschnitt 2 wurde beschrieben, dass die Instanz eines Metamodells als Graph
angesehen werden kann, dessen Knoten die einzelnen Objekte und dessen Kanten
die Assoziationen zwischen den Objekten sind. Eine Graphtransformationsregel
beschreibt, wie ein solcher Graph verändert werden kann. Jede Graphtransformationsregel
T besitzt, wie in Abbildung 5 eine linke Seite L und eine rechte
Seite R, wobei L und R selbst Graphen sind. Eine Transformationsregel T ist
auf einen Graphen G anwendbar, wenn es einen Morphismus zwischen L und
G gibt. Bei der Anwendung von T auf G werden alle Elemente aus G entfernt,
die in L aber nicht in R vorkommen. Anschließend werden dem Graphen G alle
Elemente hinzugefügt, die in R aber nicht in L vorkommen. So entsteht aus G
der neue Graph H.
42 Chapter 4. Dynamic Meta Modeling
L
A
v
C
m r
u
A B
v
C
G H
u
u
y
B
B
w
D
z
w
D
E
r
d r
R
A
x
C
u
A B
Figure 4.2: Example of a graph transformation. Since there is a matching mr from L to G, a new graph H = dr Abbildung 5. Konzept einer Graphtransformationsregel T [4]
(G) is derived.
Jede Graphtransformationsregel hat in DMM eine visuelle Repräsentation. In
Abbildung 6 ist die Regel fork.getOffer()* dargestellt. Die linke und die
are rechte added Seite to dieser G, andRegel elements werden being in der bothDMM in L Notation and R remain zusammengefasst. unchanged (the Al-
latter le Elemente is called diethe mitapplication einem destroyed contextmarkiert of the rule). sind, tauchen By applying nur ina Lrule auftound a
graph
alle Elemente
G, a new
die
graph
mit new
H is
markiert
derived
sind,
which
tauchen
differs
nur
to G
in
as
R auf.
described
Das durchgeabove.
Figure 4.2 illustrates this procedure. It is taken from [Hau05, p. 71].
In DMM, the mapping from L to G needs to be injective (if this would not
be the case, an element of G could satisfy two or more roles in one rule). This
is a restriction to graph transformations, but makes the development of proper
rules much easier.
DMM follows the Single Pushout approach. This is related to the way
dangling edges—edges which have lost one of their anchoring vertices through
the application of a rule—are treated. In the Single Pushout approach, these
edges are implicitly deleted; in other approaches, edges can only be deleted
x
C
m’ r
u
u
B
B
z
E

strichene Offer Objekt markiert eine Negative Application Condition (NAC),
das bedeutet, dass die Regel nur dann anwendbar ist, wenn noch kein Offer
Objekt mit der ForkNode assoziiert ist. Das als Multiobjekt dargestellte Edge
Objekt in der oberen linken Ecke, visualisiert eine Universal Quantified Structure
(UQS), das heißt, die ForkNode darf mit beliebig vielen ausgehenden Edges
assoziiert sein. Der Asterik hinter dem Regelnamen bedeutet, dass es sich um
eine BigStep Regel handelt. BigStep Regeln können weitere Regeln (SmallStep
Regeln) aufrufen. Im Beispiel wird bei Ausführung der Regel eine weitere Regel
fork.spawnOffer(e) aufgerufen, was dazu führt, dass das Offer Objekt für die
ausgehenden Edges der ForkNode vervielfältigt wird. Die Anwendung der Regel
fork.getOffer()* auf den Graphen G bewirkt, dass die Kante zwischen den
Knoten „in“ und „o“ gelöscht wird und eine neue Kante zwischen den Knoten
„o“ und „fork“ erstellt wird. Anschließend wird die Regel fork.spawnOffer(e)
auf den Graphen angewendet.
4.4. Graphical representation of DMM rules 57
fork.getOffer()*
in:Edge
carries
{destroyed}
spawnOffer(e)
target
o:Offer
fork:
ForkNode
source
{new}
carries
P_canCarry(o)
carries
first
Figure 4.8: Rule fork.getOffer()∗
:Edge
e:Edge
4.4 Wenn Graphical auf einen Graphen representation G mehrere Regeln anwendbar ofsind, DMM dann wirdrules jede
As we mentioned in section 4.1, one major goal of DMM was to provide a
dynamic semantics which is easily understandable. For this, the formalism of
graph transformations has been chosen, which has the advantage that graph
transformation rules of course have a visual representation: The two graphs
comprising the left-hand and right-hand side of a rule.
Since DMM is targeted at language experts, and since knowledge of the
UML can be presumed by that target audience, Hausmann decided to provide
a graphical representation of the rules which is very similar to UML Communication
Diagrams3 dann erneut auf die Anwendbarkeit von DMM Regeln überprüft werden, so dass
sich nach und nach ein großes Transitionssystem aus Graphen und Regelanwendungen
aufbaut. Das Transitionssystem beinhaltet alle Zustände die ein ein
Diagramm während seiner Ausführung annehmen kann. Die automatische Generierung
solcher Transitionssysteme ist mit Tools wie GROOVE möglich, und
wird in Abschnitt 5 vorgestellt. Doch zunächst wird erläutert, wie sich Soundness
mit DMM formalisieren lässt.
.
Figure 4.8 shows an example of a DMM rule which contains all concepts
described in the last sections. Let us investigate this example in detail:
• The name of the rule can be found in the upper left corner of the rule.
The name of the example rule, fork.getOffer()∗, ends with an asterisk
:Offer
Abbildung 6. DMM Regel fork.getOffer()* [1]
Regel einzeln auf G angewendet. Wenn n Regeln auf G anwendbar sind, dann
entstehen aus G die Folgegraphen H1 bis Hn. Jeder dieser Folgegraphen muss

Um Soundness für UML Aktivitätendiagramme überprüfen zu können, werden
die folgenden DMM Regeln benötigt:
1. Die Regel finalnode.destroyToken1() ist anwendbar, wenn ein Token an
einer ActivityFinalNode ankommt und es das einzige Token im gesamten
Diagramm ist. Die Regel sorgt dafür, dass das ankommende Token vernichtet
und die Aktivität damit beendet wird.
2. Die Regel finalnode.destroyToken2() ist anwendbar, wenn finalnode.destroyToken1()
anwendbar ist, sich jedoch noch weitere Tokens im Diagramm
befinden. Die Regel sorgt dafür, das alle Tokens im Diagramm vernichtet
werden und die Aktivität damit beendet wird.
3. Für jede Action N im Diagramm, muss eine Regel N.start() erstellt werden,
die genau dann anwendbar ist, wenn die Action ausgeführt werden
kann.
Aus der Graphenrepräsentation G des UML Aktivitätendiagramms muss unter
Anwendung der DMM Regeln ein vollständiges Transitionssystem TS erstellt
werden. Dies Transitionssystem kann dann auf bestimmte Eigenschaften hin
überprüft werden.
In Abschnitt 3 wurde definiert, dass ein UML Aktivitätendiagramm nur dann
sound ist, wenn garantiert ist, das irgendwann ein Token die ActivityFinalNode
erreicht und sich in diesem Moment keine weiteren Tokens im Diagramm befinden.
Dies ist sichergestellt, wenn von jedem Zustand s des Transitionssystems TS
ein Zustand s’ erreichbar ist, auf den die Regel finalnode.destroyToken1() anwendbar
ist, oder s selbst durch Anwendung von finalnode.destroyToken1()
erreicht wurde. Zusätzlich darf auf keinen Zustand s des Transitionssystems TS
die Regel finalnode.destroyToken2() anwendbar sein.
Weiterhin ist ein UML Aktivitätendiagramm nur dann sound, wenn jede Action
im Diagramm zumindest einmal ausgeführt werden kann. Dies ist sichergestellt,
wenn für jede Regel N.start() zumindest ein Zustand s im Transitionssystem
TS existiert, auf den sie angewendet werden kann.
5 Automatisierte Überprüfung auf Soundness
In den vorherigen Abschnitten wurde beschrieben, dass ein UML Aktivitätendiagramm
als Objektdiagramm dargestellt werden kann, welches ein Metamodell
instanziiert. Dieses Objektdiagramm ist eine Repräsentation des UML Aktivitätendiagramms
als Graph. Wendet man auf den Graphen nun die mit DMM
erstellten Graphtransformationsregeln an, so entsteht ein Transitionssystem, dessen
Zustände die transformierten Graphen sind und dessen Transitionen die Anwendung
der verschiedenen Transformationsregeln darstellen.

Das Softwaretool GROOVE [8] ermöglicht es, aus einem Anfangsgraphen und
Graphtransformationsregeln automatisch ein Transitionssystem zu erzeugen. Es
stellt einen Editor bereit, der zur Erstellung des Anfangsgraphen und der Regeln
dient, einen Imager der die Graphen darstellen kann, einen Generator der
das Transitionssystem erstellen kann und einen Modelchecker der das Transitionssystem
auf Eigenschaften überprüfen kann, die in Computational Tree Logic
(CTL) formuliert sind. Um ein Transitionssystem auf Soundness zu überprüfen
müssen also zunächst alle Soundness Bedingungen aus Abschnitt 4 in CTL formuliert
werden.
Definition 1. Sei TS = (S,→,s0) ein Transitionssystem, in dem S alle Zustände
enthält, die von s0 erreichbar sind. Sei Comp(s0) die Menge aller Pfade, die
von Startzustand s0 aus berechnet werden können und sei p eine Aussage. Dann
gilt:
T S |= AF(p) :⇔ ∀s0s1 · · · ∈ Comp(s0)∃k ∈ N : p gilt für sk
T S |= AG(p) :⇔ ∀s0s1 · · · ∈ Comp(s0)∀k ∈ N : p gilt für sk
T S |= EF(p) :⇔ ∃s0s1 · · · ∈ Comp(s0)∃k ∈ N : p gilt für sk
AF(p) bedeutet also, dass auf allen Pfaden des Transitionssystems TS ein Zustand
existiert, auf den die Aussage p zutrifft. AG(p) bedeutet, dass auf allen
Pfaden für jeden Zustand die Aussage p zutrifft. Und EF(p) bedeutet, dass ein
Pfad im Transitionssystem einen Zustand enthält, auf den die Aussage p zutrifft.
Mit Hilfe der CTL Ausdrücke lässt sich Soundness wie folgt definieren:
Definition 2. Sei A ein UML Aktivitätendiagramm mit genau einer InitialNode
und einer ActivityFinalNode. Sei s0 der Zustand von A, bei dem sich genau ein
Token an der InitialNode befindet. Seien N1,...,Nk die Namen der Actions die
in A enthalten sind und sei TS = (S,→,s0) ein Transitionssystem. A ist genau
dann sound, wenn die folgenden CTL Formeln gelten:
1. TS |= AF(finalnode.destroyToken1())
2. TS |= AG(¬ (finalnode.destroyToken2()))
3. TS |= EF(N1.start()) ∧ · · · ∧ EF (Nk.start())
Bedingung 1 bedeutet, dass auf allen Pfaden des Transitionssystems die Regel
finalnode.destroyToken1() angewendet wird. Wenn die Bedingung gilt, ist
sichergestellt, dass irgendwann ein Token an der ActivityFinalNode ankommt.
Bedingung 2 bedeutet, dass auf keinem der Pfade im Transitionssystem die Regel
finalnode.destroyToken2() ausgeführt werden kann. In Verbindung mit
Bedingung 1 stellt dies sicher, dass sich in dem Moment wo ein Token an der
ActivityFinalNode ankommt, keine weiteren Tokens im Diagramm befinden.
Bedingung 3 bedeutet, dass für jede der Actions N1 bis Nk ein Pfad existiert,
auf dem sie ausgeführt werden können. Gilt die Bedingung, dann ist sichergestellt
dass das Diagramm keine überflüssigen Actions enthält.

Fig. 6. Tool chain
having graphs Abbildung as states 7 zeigt and die verschiedenen transitionsSchritte between die zur these automatisierten states. The Überprü- transitions are
fung von Workflows auf Soundness notwendig sind. Zunächst wird ein Work-
labeled with flowmodell the name benötigt. of the Dieses applied kann mit rule. einem UML Editor erstellt werden, der
The generated das Metamodell transition der UML Aktivitätendiagramme system representsimplementiert. the complete Per XMI semantics (XML of the
input model. Metadata It can Interchange) either Format be investigated kann das erstellte manually UML Aktivitätendiagramm by visualizing an it with the
den DMM Property Checker übergeben werden. Zusätzlich zum UML Modell
GROOVE simulator (e.g. to understand the precise semantics of a certain part
benötigt der DMM Property Checker die Semantik der UML Aktivitätendia-
of a model), gramme, or automatic die mit Hilfe verification des DMM Semantics techniques Editor erstellt can be werden used. kann und die
For the Soundness latter, Eigenschaften, the first step die mitisHilfe todes identify DMM Property the properties Editor erstellttowerden be modified,
können. Aus diesen Eingaben generiert der DMM Property Checker dann einen
and to formulate them with the help of the DMM property editor. The property
Startgraphen im GXL (Graph Exchange Language) Format und Graphtransfor-
checker then mationsregeln, generates dieavom setGROOVE of rules and Generator a start gelesen graph, werden from können. which Außerdem the GROOVE
generatorgeneriert will compute er aus den the properties transition CTL Ausdrücke, system. Next, die an den theGROOVE GROOVE Modelche- model checker
is utilizedcker toweitergeleitet verify whether werden. Der theGROOVE properties Generator hold erzeugt on the auscomputed dem Startgratransition
phen unter Anwendung der Transformationsregeln ein Transitionssystem. Dieses
system (for Transitionssystem the examplekann of figure vom GROOVE 1, the whole Modelchecker procedure auf dietook Einhaltung 13.7 der seconds). in The
result of the CTLverification formulierten properties processüberprüft can then werden. be used Wennby allethe properties modeler erfüllt tower improve her
model.
6 Conclusion
In this paper gewesen, we dass have dershown Modelchecker how to dasuse Diagramm dynamic als nicht metasound modeling einstuft. for Wenn 1) defining
a semantics die Action for a „Verhandlung“ modeling formalism positiv verläuft, based bleiben onzwei a given Tokensmeta an der model, Action
and 2)
carrying out an analysis on the resulting semantics. As application, we used
UML Activities which pose a particular challenge for semantics definitions due
to their traverse-to-completion behavior introduced in UML 2.0. For the analysis,
we have chosen a general quality criterion (soundness) for workflows which are
a typical modeling domain for UML Activities. As a result, we now have a tool
chain which allows for the automatic analysis of soundness for workflows (using
the GROOVE toolset for the generation of the transition system as well as for
model checking).
Abbildung 7. Überblick über die einzelnen Schritte der Workflowanalyse [2]
den, ist das Diagramm sound, wenn nicht muss das UML Aktivitätendiagramm
im UML Editor überarbeitet werden und kann dann erneut getestet werden.
Da mir der DMM Property Editor nicht zur Verfügung stand, konnte ich im
Rahmen dieser Seminararbeit leider keine automatisierte Überprüfung des Workflowbeispiels
„Spielertransfer“ aus Abbildung 1 durchführen. Es wäre zu erwarten

„Vertragsabschluss“ stecken, da an der darauffolgenden JoinNode keine Zusammenfassung
der Tokens erfolgen kann. Folglich wird die ActivityFinalNode
nicht erreicht, so das die Regel finalnode.destroyToken1() auf diesem Pfad
des Transitionssystems nicht angewendet werden kann.
6 Zusammenfassung & Ausblick
Im Rahmen dieser Seminararbeit, wurde die Workflowmodellierung mit UML
Aktivitätendiagrammen vorgestellt. Um die Qualität von Workflowdiagrammen
bewerten zu können, wurde in Abschnitt 3 das Kriterium der Soundness erläutert.
Da sich eine Überprüfung von Workflowdiagrammen auf Soundness bei
komplexen Diagrammen kaum manuell realisieren lässt, wurde gezeigt, wie diese
Überprüfung automatisiert vorgenommen werden kann. Grundvoraussetzung für
die automatische Analyse eines Diagramms ist das Vorhandensein einer formalen
Semantik. Das in Abschnitt 4 beschriebene Dynamic Meta Modeling konnte
erfolgreich zur Spezifikation einer formalen Semantik eingesetzt werden. Auf
Grundlage dieser Semantik lässt sich mit dem Modelchecker GROOVE eine automatische
Überprüfung der Soundness vornehmen.
Soundness ist nur eines von vielen erdenklichen Qualitätskriterien. Daher bietet
es sich für die Zukunft an, sowohl speziellere Qualitätskriterien für Workflows
als auch allgemeine Qualitätskriterien für UML Aktivitätendiagramme zu entwickeln.
Diese könnten dann ebenfalls mittels GROOVE überprüft werden. Für das
konkrete Beispiel „Spielertransfer“ könnten etwa Bedingungen spezifiziert werden,
die festlegen, dass die Actions „Transferabbruch“ und „Vertragsabschluss“
nie zusammen ausgeführt werden dürfen. Dies wäre dann ein speziell auf einen
Anwendungsfall zugeschnittenes Qualitätskriterium.
Dynamic Meta Modeling eignet sich nicht nur für die Spezifikation von Semantiken
für UML Diagramme. Es ist ein universelles Verfahren, dass auch für andere
visuelle Modellierungsprachen, deren Syntax in Form eines Metamodells spezifiziert
ist, verwendet werden kann. Da allein schon der Versuch eine Modellsemantik
zu formalisieren, Qualitätsmängel in der Sprachspezifikation aufdecken
kann, wäre es wünschenswert, wenn möglichst viele Entwickler von Modellierungsprachen
diesen Versuch unternehmen würden.

Literatur
[1] C. Soltenborn: Analysis of UML Workflow Diagrams with Dynamic Meta Modeling
Techniques, Master’s thesis, University of Paderborn (2006)
[2] G. Engels, C. Soltenborn and H. Wehrheim: Analysis of UML Activities Using
Dynamic Meta Modeling, Lecture Notes in Computer Science, vol. 4468, pp. 76-90,
Springer (2007)
[3] W. van der Aalst: Verification of Workflow Nets, Lecture Notes in Computer
Science, vol. 1248, pp. 407-426, Springer (1997)
[4] J. H. Hausmann: Dynamic Meta Modeling : A Semantics Description Technique
for Visual Modeling Languages, PhD thesis, University of Paderborn (2005)
[5] D. Harel and B. Rumpe: Modeling Languages: Syntax, Semantics and All That
Stuff, Part I: The Basic Stuff, Technical Report MCS00-16, Mathematics & Computer
Sience, Weizmann Institute of Science (2000)
[6] C. Bock: UML 2 Activity and Action Models Part 4: Object Nodes, Journal Of
Object Technology, vol.3 pp.27 - 41, (2004)
[7] Object Management Group: UML Specification V2.0,
http://www.omg.org/technology/documents/modeling_spec_catalog.htm,
(2005)
[8] GRaphs for Object-Oriented Verification (GROOVE): Webseite,
http://groove.cs.utwente.nl/groove-home/, aufgerufen im Juni 2009