Eine Simulationsumgebung für strukturierte ... - It works!

Diplomarbeit
Eine Simulationsumgebung für
strukturierte natürlichsprachliche
Anwendungsfallbeschreibungen
von
Mark Lehmacher
Vorgelegt der
Fakultät für Mathematik, Informatik und Naturwissenschaften der
Rheinisch-Westfälischen Technischen Hochschule Aachen
im März 2008
Angefertigt am
Lehr- und Forschungsgebiet Informatik 3
Prof. Dr. rer. nat. Horst Lichter
Gutachter:
Prof. Dr. rer. nat. Horst Lichter
Prof. Dr.-Ing. Manfred Nagl
Betreuer:
Dipl.-Inform. Veit Hoffmann

Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich
gemacht habe.
Aachen, den 25. März 2008
Mark Lehmacher

Inhaltsverzeichnis
1 Einleitung 1
1.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Theoretische Grundlagen 5
2.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 NarrativeModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Beispiel für eine textbasierte Anwendungsfallbeschreibung . . . . . . 23
3 Technische Grundlagen 27
3.1 Eclipse-Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 GEF und Draw2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . 42
3.4 ViPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4 Konzeptueller Lösungsansatz 55
4.1 Ausführungssicht auf eine NarrativeModel-Instanz . . . . . . . . . . 55
4.2 ExecutionModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 SimulationModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5 Technische Umsetzung 67
i

5.1 Berechnung des ExecutionModels . . . . . . . . . . . . . . . . . . . 67
5.2 FlowView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 ExecutionModelView . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.5 Integration der graphischen Einzelkomponenten . . . . . . . . . . . . 82
6 Evaluierung 85
6.1 Inhaltliche Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2 Softwaretechnische Evaluierung . . . . . . . . . . . . . . . . . . . . 88
7 Zusammenfassung und Ausblick 91
ii

Abbildungsverzeichnis
2.1 Grobe Struktur des NarrativeModels . . . . . . . . . . . . . . . . . . 10
2.2 Feine Struktur der Verhaltenselemente . . . . . . . . . . . . . . . . . 12
2.3 Typhierarchie der abstrakten Event-Metaklasse . . . . . . . . . . . 13
2.4 Typhierarchie der abstrakten Context-Metaklasse . . . . . . . . . . 14
2.5 Kontrollfluss bei Ausnahmeflüssen . . . . . . . . . . . . . . . . . . . 15
2.6 Inklusionskontext- und Inklusionskonzepte . . . . . . . . . . . . . . 17
2.7 Abstrakte Erweiterungskontext- und Erweiterungsankerkonzepte . . . 18
2.8 Verfeinerung der Erweiterungskontext- und Erweiterungsankerkonzepte 19
2.9 Generalisierung und Redefinierbarkeit im NarrativeModel . . . . . . 21
2.10 Use Case Modellierung eines Geldautomaten . . . . . . . . . . . . . 23
2.11 Textuelle Beschreibung der Geldautomatanwendungsfälle . . . . . . . 24
3.1 Architektur der Eclipse-Plattform . . . . . . . . . . . . . . . . . . . . 29
3.2 Screenshot der Eclipse-Workbench . . . . . . . . . . . . . . . . . . . 32
3.3 Integration von Java-Editor und die OutlineView . . . . . . . . . . . 33
3.4 Architektur der Workbench (vgl. [Eclc]) . . . . . . . . . . . . . . . . 33
3.5 Workbench Konzepte(vgl. [Eclc]) . . . . . . . . . . . . . . . . . . . 34
3.6 SelectionService, SelectionProvider und SelectionListener (vgl. [Eclb]) 36
3.7 Typhierarchie von ISelection (vgl. [Eclb]) . . . . . . . . . . . . 36
3.8 Grobe Sicht der GEF-Architektur (vgl. [Ecle]) . . . . . . . . . . . . . 37
iii

3.9 Grobe Sicht der Draw2D-Architektur (vgl. [Ecld]) . . . . . . . . . . . 38
3.10 MVC Architektur in GEF (vgl. [Ecle]) . . . . . . . . . . . . . . . . . 40
3.11 Erzeugung von EditParts mittels EditPartFactory (vgl. [Ecle]) . 41
3.12 Typhierarchie von Ecore im Überblick . . . . . . . . . . . . . . . . . 44
3.13 Vereinfachter Ausschnitt aus dem Ecore-Modell . . . . . . . . . . . . 45
3.14 Beispiel für Metamodellierung mittels Ecore . . . . . . . . . . . . . . 46
3.15 Auszug aus der EObject-Schnittstelle . . . . . . . . . . . . . . . . 46
3.16 Screenshot der NarrativeModel-Perspektive . . . . . . . . . . . . . . 52
4.1 Aktivitätsdiagramm zum Geldautomatenbeispiel . . . . . . . . . . . . 57
4.2 Grobe Struktur des ExecutionModels . . . . . . . . . . . . . . . . . . 58
4.3 Event repräsentiert von zwei EventExecutions . . . . . . . . . . . . . 59
4.4 Reduzierende Kontextwechsel . . . . . . . . . . . . . . . . . . . . . 59
4.5 Verfeinerung der ExecutionContextChange-Metaklasse . . . . 60
4.6 Eigenschaften der Transition-Metaklasse . . . . . . . . . . . . . 61
4.7 Semantische Variation durch Inklusion abstrakten Verhaltens . . . . . 62
4.8 Schleife modelliert mittels Erweiterung . . . . . . . . . . . . . . . . 64
4.9 Struktur des SimulationModels . . . . . . . . . . . . . . . . . . . . . 65
4.10 Funktionsweise der record-Operation einer Trace . . . . . . . . . . . 66
5.1 ExecutionModelBuilder- und EventExecutionSuccessor-
Strategy-Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Implementierung der supports-Methode in DirectSuccessorStrategy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3 Funktionsweise von Nachfolgerstrategien . . . . . . . . . . . . . . . 70
5.4 Screenshot der FlowView . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5 Screenshot der FlowView . . . . . . . . . . . . . . . . . . . . . . . . 72
5.6 Screenshot der ExecutionModelView . . . . . . . . . . . . . . . . . . 74
iv

5.7 Screenshot der ExecutionModelView . . . . . . . . . . . . . . . . . . 74
5.8 Das Geldautomatenbeispiel als Menge von Aktivitäten . . . . . . . . 76
5.9 Metaklassen zur Modellierung von Aktivitäten . . . . . . . . . . . . . 77
5.10 Screenshot einer Folge von Bildschirmmasken des TraceEditors . . . 80
5.11 Screenshot der Darstellung zweier Traces in der SimulationView . . . 81
5.12 ChoiceLogic-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . 82
5.13 Screenshot der Simulationsumgebung . . . . . . . . . . . . . . . . . 83
v

Kapitel 1
Einleitung
Vor mehr als 20 Jahren hat Ivar Jacobson das Objectory-Prozessmodell vorgestellt
[Jac87] und in diesem Zuge einen Ansatz zur Beschreibung von Systemverhalten in
Form von Use Cases eingeführt.
A use case is a prose description of a system’s behavior when interacting
with the outside world.
Mit diesem Satz beschreibt Alistair Cockburn in [Coc00] kurz und prägnant, was
einen Anwendungsfall (engl. Use Case) ausmacht. Use Cases haben so schnell wie
kein zweiter Ansatz zur Anforderungsspezifikation Einzug in die Welt des Software-
Engineerings gehalten. Waren die Use Cases von Jacobson ursprünglich eine informelle
„prose description“ eines Systems, hat das Konzept der Anwendungsfälle mittlerweile
eine gewisse Formalisierung erfahren und ist heute Bestandteil der UML (Unified
Modeling Language).
Die Modellierung von Systemverhalten mit Hilfe von Anwendungsfällen wird aus einer
Sicht heraus betrieben, in der die Interaktionen des zu beschreibenden Systems
mit sogenannten Akteuren im Mittelpunkt stehen. Akteure sind Entitäten, in der Regel
Personen oder Systeme, die sich außerhalb des Zielsystems befinden und durch ihre
Interaktion mit dem System ein bestimmtes Ziel verfolgen oder sonst irgendwie von
dieser Interaktion betroffen sind. Diese Betrachtungsweise resultiert in der Beschreibung
eines Systems als Menge von Interaktionen mit der Außenwelt. Für diesen Grad
der Modellierung spezifiziert die UML Elemente und Beziehungen zwischen diesen
Elementen. Für eine detaillierte Beschreibung des Verhaltens der verschiedenen Interaktionen
stellt die UML allerdings keinerlei Modellierungselemente zur Verfügung.
Somit lässt die UML offen, wie das Verhalten, das von einem Use Case repräsentiert
wird, unterhalb der Abstraktionsebene eines Anwendungsfalles verfeinert beschrieben
werden soll. Auf dieser Ebene spezifiziert die UML lediglich, dass jeder Anwendungsfall
eine Menge möglicher Verhaltenssequenzen beschreibt. Jede Verhaltenssequenz
setzt sich dabei zusammen aus einer Folge atomarer Verhaltensschritte. Aus diesem
1

Grund gibt es diverse Konzepte, um Use Case-Verhalten detailliert zu spezifizieren
und die allgemein gehaltenen Begriffe der UML zu verfeinern. Ein Ansatz ist am Lehr
und Forschungsgebiet der Informatik 3 an der RWTH Aachen im Rahmen einer Diplomarbeit
entstanden [Wal07].
In diesem Ansatz wurde eine strukturierte textbasierte Darstellungsform gewählt, um
das Verhalten von Anwendungsfällen in natürlicher Sprache zu beschreiben. Begründet
wurde die Entscheidung für diese Form damit, dass eine textbasierte Beschreibung
einem Anwender größtmöglichen Nutzen und Flexibilität bietet. Dieser Ansatz wurde
im NarrativeModel formalisiert. Das NarrativeModel ist ein Metamodell und stellt
Konzepte und Elemente zur Modellierung natürlichsprachlicher Beschreibungen von
Use Cases zur Verfügung. Damit liegt einer textuellen Anwendungsfallbeschreibung
ein Modell zugrunde, ebenso wie einem Use Case-Modell das UML-Metamodell zugrunde
liegt. Aus dem Einsatz eines Metamodells folgen all die Vorteile, die einem
strukturierten und formalen Ansatz innewohnen. Dazu gehört beispielsweise die automatische
Prüfung des Modells bezüglich bestimmter Gesichtspunkte wie Konsistenz
mit Hilfe von Randbedingungen, die im Metamodell formuliert sind. Obwohl
das NarrativeModel eine Struktur für die textuelle Beschreibung von Use Cases vorgibt,
schränkt es die Ausdrucksweise des Modellierers nicht zu stark ein, da es den
Einsatz natürlicher Sprache zur Beschreibung bestimmter Verhaltenselemente zulässt.
Dem hier gewählten Ansatz liegt eine flussorientierte Sicht auf das Verhalten eines Use
Cases zugrunde.
Laut UML kapselt ein Anwendungsfall Verhaltenssequenzen, die jeweils als Folge einzelner
Verhaltensatome zusammengesetzt sind. Die Verhaltenssequenzen werden im
NarrativeModel in Form von Flüssen beschrieben, die Verhaltensatome in Form von
Aktionen. Jede natürlichsprachliche Beschreibung beinhaltet ein oder mehrere Flüsse.
Jeder Fluss besteht aus einer Folge von Aktionen, die in natürlicher Sprache spezifiziert
werden. Zwischen Flüssen können, ebenso wie zwischen Anwendungsfällen,
Inklusions- und Erweiterungsbeziehungen definiert werden. Für diesen Zweck gibt es
neben den Aktionen ausgezeichnete Stellen in einem Fluss, an denen die Beziehungen
ansetzen. Dieses Vorgehen orientiert sich an den vorhandenen UML-Mechanismen,
wie beispielsweise den Erweiterungspunkten in einem Use Case, an denen Verhalten
eines anderen Anwendungsfalles mittels Erweiterung eingefügt werden kann.
Auf Grundlage der Ergebnisse von [Wal07] soll in dieser Arbeit ein Werkzeug entwickelt
werden, um die Ausführung von Anwendungsfällen, bzw. ihrer textuellen Beschreibungen,
zu simulieren. In der Folge wird dieses Werkzeug als Simulationsumgebung
bezeichnet. Die Simulation eines Use Cases bedeutet anschaulich, dass einzelne
Szenarien „durchgespielt“ werden. Ein Szenario ist eine individuelle Use Case Instanz,
also ein spezieller Pfad (eine spezielle Verhaltenssequenz) durch einen Anwendungsfall.
In dem Fall, dass ein Use Case eine Menge von Verhaltensalternativen beinhaltet,
ist ein Szenario genau eine mögliche Verhaltensausprägung vom Start des Anwendungsfalles,
der durch eine Aktion eines Akteurs ausgelöst wird, bis hin zu seinem
Ende.
2

1.1 Zielsetzung
Die simulierte Ausführung von Anwendungsfällen soll der Validierung der in Use Cases
und textuellen Beschreibungen festgehaltenen Anforderungen dienen und nachgelagerte
Analysetätigkeiten unterstützen. Zur Validierung der Anforderungen gehören
Prüfungen auf Vollständigkeit und Korrektheit. Die Simulation soll Anhaltspunkte für
diese Prüfungen liefern. Beispielsweise kann im Verlauf der Simulation festgestellt
werden, dass gewisse Alternativabläufe in der Verhaltensbeschreibung eines Anwendungsfalles
fehlen. Die simulierte Ausführung kann außerdem Schwachpunkte in der
Anforderungsbeschreibung des Zielsystems aufzeigen. Dies können beispielsweise inkorrekt
formulierte Sachverhalte oder nur ungenügend beschriebene Aktionen sein.
Stößt ein Entwickler zu einem Entwicklungsteam hinzu, kann er die Ausführung der
existierenden Anwendungsfälle simulieren, um sich mit den Abläufen und Anforderungen
des Zielsystems vertraut zu machen und ein generelles Systemverständnis zu
entwickeln.
Mittels bestimmter Artefakte, die im Zuge der Simulationsdurchführung entstehen,
können idealerweise Erkenntnisse über die Qualität der aufgenommenen Anforderungen
gewonnen werden und im Rahmen des Projektmanagements weiterverarbeitet
werden. Als Artefakt ist hier beispielsweise eine Modellinstanz denkbar, die eine
ausführungsorientierte Sicht auf die zugrundeliegende Anwendungsfallbeschreibung
bietet und auf deren Grundlage die Simulation durchgeführt wird. Über den Einsatz
geeigneter Metriken, die dieses Modell bezüglich spezieller Gesichtspunkte und Eigenschaften
bewerten, sind Rückschlüsse auf die Qualität der Anforderungen möglich.
Eine Textdarstellung der im Laufe der Simulation durchgespielten Szenarien kann
möglicherweise als Ausgangspunkt für die Klärung offener Fragen und Probleme im
Rahmen eines Kundengesprächs dienen.
Im Bereich eingebetteter Systeme ist der Einsatz der Simulation für frühe Machbarkeitsstudien
denkbar. Das Problem in diesem Bereich ist häufig, dass nur begrenzte
Hardwareressourcen für die Realisierung des Zielsystems zur Verfügung stehen. Um
frühzeitig die Umsetzbarkeit der Anforderungen bezüglich der vorhandenen Ressourcen
zu evaluieren, ließen sich einzelne Schritte der Simulationsausführung mit geschätzten
Zusatzinformationen, den Ressourcenverbrauch betreffend, annotieren. Die
Simulation selbst gibt dann Aufschluss darüber, ob die Planung auch tatsächlich umsetzbar
ist.
Unabhängig von diesen fachlichen Zielsetzungen soll die Simulationsumgebung außerdem
gewissen anderen Anforderungen genügen. Zu diesen gehört, dass dem Benutzer
eine anschauliche graphische Visualisierung des möglichen Simulationsablaufs
zur Verfügung gestellt wird. Diese Darstellung dient idealerweise gleichsam zur Veranschaulichung
der zugrundeliegenden textuellen Beschreibung. Außerdem soll die
Simulationsumgebung in die ebenfalls am Lehrstuhl entstandene Eclipse Rich Client
Plattform integriert werden. Daraus folgt, dass sich die Umsetzung der Simulationsumgebung
an den Eclipse UI-Paradigmen zur Entwicklung graphischer Benutzeroberflächen
orientiert.
3

1.2 Aufbau der Arbeit
Die Arbeit ist wie folgt gegliedert: Zunächst werden in Kapitel 2 die theoretischen
Grundlagen für das weitere Verständnis gelegt. Dazu gehören eine kurze Abhandlung
über die hier relevanten Spracheinheiten der UML und eine ausführliche Beschreibung
des Metamodells für strukturierte natürlichsprachliche Beschreibungen von Anwendungsfällen.
Das Kapitel wird abgeschlossen mit einem Beispiel, welches die Anforderungsmodellierung
eines Geldautomaten mittels des vorgestellten Metamodells
illustriert.
Das dritte Kapitel beschäftigt sich mit den technischen Grundlagen, auf deren Basis die
technische Realisierung dieser Arbeit stattgefunden hat. Zuerst werden hierzu die Architektur
der Eclipse-Plattform thematisiert und danach die für diese Arbeit relevanten
Eclipse-Technologien eingeführt. Den Abschluss des Kapitels bilden die Vorstellung
der ViPER-IDE und ihrer Komponenten.
In Kapitel 4 wird der konzeptuelle Lösungsansatz, der der Realisierung der Simulationsumgebung
zugrunde liegt, vorgestellt. Dafür wird zunächst die Modellbildung
eines eigenen Metamodells zur Kapselung von Ausführungskonzepten motiviert und
dieses Metamodell anschließend ausführlich erklärt.
Das fünfte Kapitel erläutert die technische Realisierung der Simulationsumgebung.
Die Simulationsumgebung besteht aus einer Menge graphischer Komponenten, die in
diesem Kapitel der Reihe nach vorgestellt werden. Am Ende des Kapitels wird die Integration
der Einzelkomponenten, die in ihrer Summe die Simulationsumgebung ausmachen,
beschrieben.
Inhalt des sechsten Kapitels ist die Evaluierung der erarbeiteten Lösung. Dabei wird
die Qualität der Simulationsumgebung mit Blick auf die oben formulierten Zielsetzungen
untersucht.
Das siebte Kapitel bildet den Abschluss dieser Arbeit und fasst die Ergebnisse zusammen.
Darüber hinaus wird ein Ausblick auf mögliche zukünftige Arbeiten geboten.
4

Kapitel 2
Theoretische Grundlagen
Dieses Kapitel legt den theoretischen Grundstein für das Verständnis der konzeptuellen
Realisierung der Simulationsumgebung. Zunächst erfolgt ein kurzer Überblick über
die UML und ihr Metamodell. Im Anschluss wird das Metamodell für textbasierte Anwendungsfallbeschreibungen
ausführlich vorgestellt. Abgeschlossen wird das Kapitel
mit einem Beispiel, welches die Modellierung natürlichsprachlicher Beschreibungen
am Beispiel eines Geldautomaten illustriert.
2.1 UML
Die UML (Unified Modeling Language) ist eine von der OMG (Object Management
Group) standardisierte Beschreibungssprache [UML, OMG]. Zu ihren Anwendungsbereichen
gehört die Beschreibung von Strukturen, Verhalten und Architekturen, sowie
von Geschäftsprozessen und Datenbanken. Die UML findet hauptsächlich Anwendung
im Gebiet des Software-Engineerings. Dort wird sie eingesetzt, um statische Strukturen
und dynamische Abläufe eines Softwaresystems deskriptiv oder auch präskriptiv
festzuhalten [LL06].
Der UML zugrunde liegt ein Metamodell, welches Begriffe und Beziehungen zwischen
diesen Begriffen festlegt. Mittels dieser Elemente werden Systemmodelle spezifiziert.
Darüber hinaus definiert die UML graphische Notationen für ihre verschiedenen
Metamodellelemente.
Da die UML in ihrem Umfang seit Version 1.0 stark gewachsen ist, besteht die UML2
-Spezifikation aus drei Teilspezifikationen. Diese Dreiteilung reduziert Komplexität
und erleichtert den Umgang mit der Spezifikation während der Entwicklung. Für den
Anwender ist die Spezifikation durch ihre Zerlegung besser lesbar und einfacher verständlich.
Die drei Spezifikationen, die in ihrer Gesamtheit die UML2-Spezifikation
ausmachen, werden im Folgenden kurz vorgestellt. Darüber hinaus ist außerdem ein
Standard zum Informationsaustausch von Diagramminformationen definiert.
5

• UML Infrastructure ([Obj07a]): Die Infrastructure legt, wie ihr Name bereits
andeutet, das Fundament für die UML2. Sie beinhaltet einen wiederverwendbaren
Kernel, der als Basis für die Entwicklung weiterer Metamodelle dient. Er
umfasst Sprachkonstrukte in Form grundlegender Metamodellelemente. Zu diesen
gehören beispielsweise die Elemente Paket, Klasse, Multiplizität und Assoziation.
Mittels dieser Elemente können spezielle Konstrukte in den jeweiligen
Metamodellen formuliert werden. Ein derartiges Metamodell, welches auf den
Konzepten des Kernels aufsetzt, ist die Superstructure.
• UML Superstructure ([Obj07b]): Die Superstructure ist der zweite Teil der
UML2-Spezifikation und beinhaltet Sprachelemente, die auf denen der Infrastructure
aufbauen. Während die Infrastructure hauptsächlich als Basis für die
Entwicklung auf ihr aufsetzender Metamodelle dient, stellt die Superstructure
einem Anwender Konzepte zur Verfügung, die dieser zur Modellierung einsetzt.
Intern ist die Superstructure modular aufgebaut. Sie ist unterteilt in sogenannte
Spracheinheiten, die die Superstructure nach Struktur und Verhalten aufteilen.
Die Spracheinheit Activities umfasst beispielsweise Elemente für die Modellierung
von Systemverhalten, das sich am besten mit Hilfe des Formalismus von
Daten- und Kontrollflüssen darstellen lässt. Weitere Spracheinheiten sind Interactions,
State Machines oder Use Cases, die zur Verhaltensmodellierung eingesetzt
werden. Die Spracheinheiten Classes und Composite Structures dienen der
Modellierung von Strukturen.
• Object Constraint Language ([Obj03a]): Die OCL ist eine formale Sprache, die
der Spezifikation von Randbedingungen in einem Metamodell dient. Dazu gehören
etwa Spezifikation von Invarianten in Klassendiagrammen, von Bedingungen
in Sequenzdiagrammen oder die Formulierung von Vor- und Nachbedingungen
für Methoden. Außerdem können mittels OCL Suchanfragen (Queries)
über ein Modell gestellt werden. Die Auswertung der formulierten Ausdrücke
ist frei von Seiteneffekten und kann den Zustand eines Modells nicht ändern.
Diese Eigenschaft entspricht generell der Semantik einer Spezifikationssprache.
• Diagram Interchange [DI06]: Die Superstructure legt mittels ihrer Spracheinheiten
Diagrammtypen fest, die in der Praxis zur Modellierung von Systemen eingesetzt
werden. Dazu gehören einerseits Metamodellelemente und andererseits
die graphische Repräsentation dieser Elemente. Damit unterschiedliche Modellierungswerkzeuge
untereinander Diagramme austauschen und weiterverarbeiten
können, schreibt das Diagram Interchange eine standardisierte Serialisierung
von Diagrammen vor. Sie legt fest, wie Diagramminformationen persistent abgelegt
werden.
2.1.1 Spracheinheiten
Im Rahmen dieser Arbeit sind einige Spracheinheiten der UML-Superstructure von
besonderem Interesse. Dazu gehören Klassendiagramme, die im Zuge der Metamodellierung
der theoretischen Grundlagen dieser Arbeit eingesetzt wurden, ebenso wie
6

die Spracheinheit der Use Cases, die den Ausgangspunkt für den Ansatz der natürlichsprachlichen
Anwendungsfallbeschreibungen legt. Im Laufe der Simulation dieser textuellen
Beschreibungen werden Aktivitätsdiagramme eingesetzt, weil diese sich sehr
gut zur Visualisierung von Verhaltensabläufen, Auswahlmöglichkeiten und Verzweigungen
eignen.
Classes
Die Spracheinheit Classes ist die gebräuchlichste und bekannteste Spracheinheit der
UML. Sie umfasst den eigentlichen Kern der Modellierungssprache und definiert den
Klassenbegriff und die verschiedenen Beziehungen zwischen Klassen. Dabei setzt sie
auf dem abstrakten Classifier-Begriff der Infrastructure auf und konkretisiert diesen.
Ein Classifier ist eine abstrakte Metaklasse, die eine Klassifikation mehrerer Instanzen
bezüglich bestimmter Eigenschaften darstellt. Ein Classifier beschreibt also eine Menge
von Instanzen bezüglich ihrer Gemeinsamkeiten. Klassen und Schnittstellen sind
konkrete derartige Classifier und werden in der Superstructure als Teil der Spracheinheit
Classes definiert. Des Weiteren stellt die Superstructure spezielle Beziehungen
zwischen den verschiedenen Konzepten der Spracheinheit zur Modellierung zur Verfügung.
Dazu gehören beispielsweise Aggregations- und Kompositionsbeziehungen.
Elemente dieser Spracheinheit werden üblicherweise in Klassendiagrammen, Objektdiagrammen
und Paketdiagrammen dargestellt.
Use Cases
Die Elemente der Spracheinheit Use Cases dienen der Modellierung von Anforderungen
an ein System. Die wichtigsten Elemente hierbei sind Anwendungsfälle. Jeder
Anwendungsfall beschreibt eine Anforderung an das zu modellierende System. Die
Use Case Modellierung basiert auf einer Vorgehensweise, die die Interaktion externer
Entitäten mit dem System in den Mittelpunkt rückt und daraus Anforderungen ableitet.
Ein Use Case kapselt Verhalten im Sinne einer Black Box, welches im Rahmen einer
Interaktion ein Resultat für ein oder mehrere externe Entitäten generiert. Diese externen
Entitäten, die das Systemverhalten anstoßen und von seinen Resultaten abhängig
sind, nennt man Akteure. Üblicherweise wird ein Anwendungsfall aus Sicht eines Akteurs
beschrieben. Akteure spezifizieren, wer (im Sinne einer Person) oder was (im
Sinne eines anderen Systems) im Rahmen der Ausführung des aktuellen Use Cases
mit dem modellierten System interagiert. Kommt ein Anwendungsfall im System zur
Ausführung, muss er ein beobachtbares Resultat, das für einen oder mehrere Akteure
von Bedeutung ist, generieren. Sowohl Anwendungsfälle als auch Akteure sind spezielle
Classifier. Außer diesen Entitäten stellt die Superstructure in dieser Spracheinheit
Beziehungen zwischen Anwendungsfällen und Akteuren zur Verfügung. Dies umfasst
Generalisierungsbeziehungen zwischen je zwei Akteuren oder Anwendungsfällen,
eine binäre Assoziationsbeziehung zwischen je einem Use Case und Akteur, sowie
Inklusions- und Erweiterungsbeziehungen zwischen Anwendungsfällen. Letztere
7

dienen der Wiederverwendung des Verhaltens, das in einem Use Case gekapselt ist 1 .
Graphisch werden Anwendungsfälle in Anwendungsfalldiagrammen dargestellt.
Activities
Das zentrale Element der Spracheinheit Activities ist das Element Aktivität selbst. Eine
Aktivität dient der Modellierung des dynamischen Verhaltensablaufs eines Systems.
Sie beschreibt das Verhalten des Systems in Form einer Sequenz elementarer Aktionen.
Aktionen sind Teil einer eigenen Spracheinheit (Actions) und stellen die elementaren
Bausteine für die Modellierung eines Verhaltensablaufs in der UML dar. Aktionen
können Eingabewerte entgegennehmen und Ausgabewerte erzeugen. Aktionen sind in
einer Aktivität über Kanten gekoppelt, die den Kontrollflussverlauf von einer Aktion
zur anderen symbolisieren. In diesem Sinne hat eine Aktivität die Struktur eines Graphen
mit Knoten und Kanten. Außer den Aktionen gibt es noch weitere Arten von
Knoten. Beispielsweise gibt es sogenannte Kontrollknoten, an denen der Kontrollfluss
in der Aktivität kontrolliert bzw. gesteuert werden kann. An einem Entscheidungsknoten
(DecisionNode) verzweigt sich der Kontrollfluss, an einem MergeNode laufen
verschiedene Kontrollflüsse zusammen. Den Knoten entsprechend gibt es verschiedene
Arten von Kanten, die ja nach Typ verschiedene Knotenarten miteinander verbinden
können. Komplexere Aktivitäten können verschachtelt und mit Kontrollstrukturen
modularisiert werden. Graphisch dargestellt werden Aktivitäten in einem Aktivitätsdiagramm.
Auf die für diese Arbeit relevanten Elemente dieser Spracheinheit wird in
Abschnitt 5.3 noch ausführlicher eingegangen.
Profile
Die UML Infrastructure [Obj07a] stellt einen generischen Erweiterungsmechanismus
durch sogenannte Profile zur Verfügung. Profile werden im Zuge der Implementierung
eines Teils dieser Arbeit verwendet (vgl. Abschnitt 5.3).
Ein Profil beinhaltet eine Menge von Stereotypen, die zusammen ein bestimmtes Modellierungsproblem
beschreiben und somit die Modellierung in einer spezifischen Domäne
ermöglichen. Im Allgemeinen erweitern Stereotypen das Vokabular der UML
um neue Elemente, die von existierenden Elementen abgeleitet werden und diese um
domänenspezifische Eigenschaften erweitern. Sie werden benutzt, um Bausteine der
UML zu klassifizieren bzw. speziell auszuzeichnen, und um neue Bausteine für eine
bestimmte Domäne zu gewinnen. Anschaulich gesprochen dient ein Stereotyp der
Spezialisierung einer Elementinstanz zur Laufzeit.
Der Profilmechanismus ist leichtgewichtig in dem Sinne, dass das UML-Metamodell
unverändert bleibt. Stereotypen können auf Elemente, Attribute, Methoden, Assoziationen
und Assoziationsenden angewendet werden.
1 Genaugenommen werden Verhaltensbeschreibungen wiederverwendet.
8

2.2 NarrativeModel
2.2.1 Motivation und Ziel
Das NarrativeModel ist ein Metamodell für textbasierte Anwendungsfallbeschreibungen.
Es dient der Modellierung der internen Struktur eines Use Cases und der Beschreibung
seines Verhaltens in natürlicher Sprache. Die UML definiert einen Standard,
der Konzepte und Elemente vorgibt, um eine System mittels einer Menge von
Anwendungsfällen und ihrer Beziehungen untereinander zu modellieren. Die UML-
Spezifikation macht allerdings keine Aussage über die Form der detaillierten Beschreibungen
des Verhaltens einzelner Use Cases. Hierfür gibt es diverse Ansätze und Notationen,
aus denen sich allerdings kein Standard herausgebildet hat.
Als ein solcher Ansatz zur detaillierten Beschreibung von Anwendungsfällen ist das
NarrativeModel-Metamodell im Rahmen einer früheren Diplomarbeit am Lehr- und
Forschungsgebiet Informatik 3 an der RWTH Aachen entstanden [Wal07]. Der Modellbildung
zugrunde lag die informelle Notation für die natürlichsprachliche Beschreibung
von Anwendungsfällen, die Bittner und Spence in ihrem Buch vorgestellt haben
[BS02]. Seitdem hat das NarrativeModel allerdings einige Veränderungen erfahren und
wird deswegen an dieser Stelle noch einmal ausführlich vorgestellt.
Dem NarrativeModel-Ansatz liegt eine flussorientierte Sicht auf die Ausführung von
Anwendungsfällen zugrunde. Jeder Anwendungsfall beschreibt ein oder mehrere Szenarien,
die durch seine konkreten Verhaltensausprägungen zustande kommen. Die Ausführung
eines Use Cases resultiert im Hinblick auf das durchgeführte Verhalten in
einem konkreten Szenario. Ziel des NarrativeModel-Ansatzes ist die strukturierte Beschreibung
aller möglicher Verhaltensausprägungen in natürlicher Sprache. Praktisch
geschieht dies, indem man die interne Use Case-Struktur mit den Elementen, die das
NarrativeModel zur Verfügung stellt, modelliert und dabei an bestimmten Stellen die
natürliche Sprache zur Beschreibung von Verhalten einsetzt.
Eine Instanz eines Use Case-Modells besteht aus einer Menge von Instanzen von Metaklassen
des UML-Metamodells. Im NarrativeModel gibt es Metaklassen, welche bestimmte
UML-Metaklassen der Use Case-Spracheinheit referenzieren. Das dient der
Sicherstellung der Konsistenz zwischen beiden Modellen. Auf diese Weise wird gewährleistet,
dass es zu bestimmten Elementen des Use Case-Modells eine detaillierte
Beschreibung dieser Elemente im NarrativeModel gibt. In diesen Fällen gibt es gerichtete
1:1 Beziehungen vom NarrativeModel in das UML-Modell. Derartig repräsentierte
Metaklassen sind beispielsweise UseCase, ExtensionPoint, Include und
Actor. Bei der Konzipierung des NarrativeModels wurden unterschiedliche Ansätze
der Integration mit dem zu beschreibenden Use Case-Modell erwogen [Wal07].
Letzen Endes wurde der Ansatz gewählt, das NarrativeModel als Erweiterung des Use
Case-Modells zu modellieren und bestimmte Elemente des Use Case-Modells aus dem
NarrativeModel heraus zu referenzieren.
Der Verhaltensbeschreibung eines Anwendungsfalles zugrunde liegt in aller Regel die
9

Vorstellung, dass jeder Anwendungsfall einen Standardablauf und mögliche Alternativabläufe
besitzt. Der Standardablauf stellt den Normalfall des Use Cases in Form einer
Verhaltenssequenz, die wiederum aus einzelnen Verhaltenssegmenten besteht, dar.
Dieser Standardablauf ist also ein Szenario, welches Teil aller Verhaltensausprägungen
des Anwendungsfalles ist. Die Verhaltenssegmente beschreiben atomares Verhalten in
natürlicher Sprache (in diesem Fall spricht man von Verhaltensatomen) oder dienen
dem bedingten oder unbedingten Einfügen anderer Verhaltenssequenzen an wohl definierten
Stellen des Verhaltensablaufs. Verhalten welches bedingt, also an eine Bedingung
gekoppelt, zur Ausführung kommt, heißt Alternativverhalten. Das bedingte und
unbedingte Einfügen von Verhalten wird in der UML-Notation durch Erweiterungen
und Inklusionen modelliert. Standardablauf in Kombination mit Alternativen spannen
den Zustandsraum für Szenarien auf.
Die Begriffe der Verhaltenssequenzen und Verhaltenssegmente stammen aus der Spezifikation
der UML. Im Vorgriff auf die folgenden Ausführungen sei an dieser Stelle
bereits erwähnt, dass die Verhaltenssequenzen von Anwendungsfällen im Narrative-
Model durch Flüsse dargestellt werden und die Verhaltenssegmente durch Ereignisse.
2.2.2 Das Metamodell
Abbildung 2.1: Grobe Struktur des NarrativeModels
Abbildung 2.1 gibt einen Überblick über die Metaklassen des NarrativeModels, die
dessen grobe Struktur ausmachen. Insbesondere dienen diese Metaklassen der Spiegelung
der Kompositionshierarchie eines Use Case-Modells in einem NarrativeModel.
Ein UML-Model ist üblicherweise als Kompositionshierarchie strukturiert, in der jedes
Element Teil eines anderen Elements ist. Das Wurzelelement, welches in der Regel
ein Model-Element ist, bildet hierbei die Ausnahme und ist nicht Kind eines anderen
Elements. Dieses Wurzelelement ist in einem NarrativeModel eine Instanz der Meta-
10

klasse NarrativeModel. Diese NarrativeModel-Instanz referenziert das durch sie
beschriebene Use Case-Modell.
In der UML gibt es außerdem noch andere Elemente, die der hierarchischen Komposition
dienen. Im Rahmen der Modellierung eines Use Case-Modells werden die
UML-Konzepte Package und Component eingesetzt, um logisch zusammenhängende
Elemente zu gruppieren. Um die mittels Verschachtelung dieser Elemente gebildete
Kompositionsstruktur nachzubilden, besitzt das NarrativeModel das Konzept des
NarrativeContainers. NarrativeContainer-Instanzen lassen sich beliebig
ineinander schachteln. Als Wurzel einer NarrativeContainer-Hierarchie dient eine
Instanz der NarrativeModel-Metaklasse.
Als weitere Kinder eines NarrativeContainers kommen neben anderen NarrativeContainern
noch Instanzen der Metaklassen NarrativeActor und NarrativeDescription
in Frage. NarrativeDescription und NarrativeActor dienen
der natürlichsprachlichen Beschreibung von UseCase-Instanzen einerseits und
Actor-Instanzen andererseits. Die UML-Elemente werden jeweils durch eine Verfeinerung
der umlNamespace-Assoziation von den sie repräsentierenden NarrativeModel-
Elementen referenziert.
An dieser Stelle sieht man, dass Konsistenz zwischen Use Case-Modell und NarrativeModel-Modell
sichergestellt werden muss. Zu jeder UseCase-Instanz muss es
tatsächlich auch eine NarrativeDescription-Instanz geben. Außerdem müssen
noch andere als die bisher vorgestellten Elemente eines Use Case-Modells in einem
NarrativeModel-Modell abgebildet werden. Beispielsweise müssen sich externe Erweiterungspunkte,
sowie Erweiterungs- und Inklusionsbeziehungen in der Narrative-
Model-Instanz durch entsprechende Elemente repräsentiert wiederfinden.
2.2.3 Flüsse
Die Semantik der UML für Use Cases besagt, dass jeder Use Case eine Menge von
Verhaltenssequenzen beinhaltet. Sie macht darüber hinaus aber keine Aussage über
deren Struktur [Obj07b]. Der Begriff des Verhaltenssequenz muss also im Rahmen
einer detaillierten Anwendungsfallbeschreibung konkretisiert werden.
Hierfür gibt es im NarrativeModel das Konzept der Flüsse (Metaklasse Flow). Ein
Fluss beschreibt eine solche Verhaltenssequenz als eine Folge einzelner Ereignisse.
Die Ereignisse entsprechen dabei den Verhaltenssegmenten der UML und werden
durch die Metaklasse Event dargestellt. Ereignisse werden ausführlich in Abschnitt
2.2.4 behandelt.
Eine textbasierte Beschreibung beinhaltet ein oder mehrere Flüsse, die untereinander
in Beziehung stehen können und somit die interne Struktur eines Use Cases ausmachen.
Als mögliche Beziehungen gibt es hier analog zu den Beziehungen zwischen
Use Cases die Inklusions- und Erweiterungsbeziehung sowie die Generalisierungsbeziehung.
Darüber hinaus gibt es noch das Konzept der Ausnahmeflüsse. Ein Ausnah-
11

mefluss kapselt Verhalten zur Ausnahmebehandlung, welches jederzeit als Reaktion
auf eine Ausnahmesituation in einem anderen Fluss zur Ausführung kommen kann.
Abbildung 2.2: Feine Struktur der Verhaltenselemente
Abbildung 2.2 illustriert den Zusammenhang zwischen NarrativeDescriptions nochmals
in graphischer Form. Es gibt zwei verschiedene Assoziationen zwischen NarrativeDescription
und Flow. Über die Kompositionsbeziehung besitzt jede
NarrativeDescription eine Menge von Flüssen, nämlich diejenigen, die auch tatsächlich
in der jeweiligen NarrativeDescription definiert oder redefiniert werden. Die gerichtete
Beziehung von NarrativeDescription zu Flow ist eine Aggregation
über die Vererbungshierarchie der jeweiligen NarrativeDescription und beinhaltet neben
den lokal definierten Flüssen auch diejenigen, die von einer generelleren NarrativeDescription
geerbt wurden, ohne lokal redefiniert zu werden (für eine detaillierte
Beschreibung der Generalisierungsbeziehung vgl. Abschnitt 2.2.6).
2.2.4 Ereignisse in Flüssen
Flüsse sind Verhaltenssequenzen und bestehen aus einer Folge von Verhaltenssegmenten.
Im Sinne der Ausführung ereignen sich diese Verhaltenssegmente an einem Stück.
Ein Verhaltenssegment findet seine Entsprechung im NarrativeModel in Form eines
Ereignisses (abstrakte Metaklasse Event). Ein Fluss besteht aus einer diskreten Sequenz
von Ereignissen.
Auch dieser Zusammenhang ist in Abbildung 2.2 zu sehen. Analog zu den Beziehungen
zwischen NarrativeDescription und Flow wird auch zwischen Flow und
Event einerseits unterschieden nach innerhalb des konkreten Flusses definierten Ereignissen
und geerbten Verhaltensbausteinen andererseits.
Die Metaklasse Event ist abstrakt. Das NarrativeModel kennt verschiedene Arten
von Spezialisierungen des Ereignis-Begriffs. Zum einen gibt es Ereignisse, die aus
Sicht des Flusses, deren Teil sie sind, atomares Verhalten darstellen. Ein derartiges
Ereignis heißt Aktion (Metaklasse Action) und wird vom Modellierer in natürlicher
Sprache beschrieben. Die Beschreibung an sich hat aus Sicht des Metamodells keine
Semantik.
Außerdem gibt es Ereignisarten, die der Definition potentieller Kontrollflussverlagerungen
(abstrakte Metaklasse ControlEvent) im Fluss dienen. Das sind ausgezeichnete
Positionen im Fluss, an denen Verhalten anderer Flüsse bedingt (Erweiterung)
oder unbedingt (Inklusion) zur Ausführung kommt. Aus Sicht des Ereignisses
ändert sich an dieser Stelle möglicherweise der aktuelle Kontext (das Kontextkonzept
12

wird im folgenden Abschnitt 2.2.5 ausführlich vorgestellt). Das passiert genau dann,
wenn der Kontrollfluss den bisher aktuellen Fluss (möglicherweise nur vorübergehend)
verlässt und sich in einen anderen Fluss verlagert.
Abbildung 2.3: Typhierarchie der abstrakten Event-Metaklasse
Abbildung 2.3 gibt einen Überblick über die verschiedenen Ereignisarten. Man erkennt
die Verfeinerung des abstrakten Event-Konzepts zu dem abstrakten ControlEvent-
Begriff einerseits und der konkreten Metaklasse Action andererseits. Control-
Event wird dabei noch weiter unterteilt in Inclusion und ExtensionAnchor,
bei denen wiederum noch unterschieden wird zwischen internen und externen Ereignissen
dieser Art. Der genaue Verwendungszweck dieser Typen wird erläutert im Abschnitt
2.2.6, der sich mit der Darstellung von Inklusions- und Erweiterungsbeziehungen
im Modell beschäftigt.
2.2.5 Flüsse und Kontexte
Jeder Fluss hat einen oder mehrere Kontexte (Metaklasse Context), die bestimmen,
auf welche Arten und Weisen ein Fluss verwendet werden kann. Beispielsweise besitzt
ein Fluss, der nur dazu geeignet ist, über eine Erweiterungsbeziehung zusätzliches
Verhalten für andere Flüsse zur Verfügung zu stellen und demnach nicht für sich alleine
genommen ausführbares Verhalten darstellt, einen dementsprechenden Kontext. Stellt
ein Fluss einen Standardablauf dar, hat er ebenfalls einen bestimmten Kontext, der
aussagt, dass der Fluss über einen Akteur angestoßen werden kann.
Abbildung 2.4 stellt die Typhierarchie der Context-Metaklasse vor. Es gibt zwei
Spezialisierungen, die für einen Fluss mit derartigen Kontexten zur Folge haben, dass
er über Inklusion oder Erweiterung aus einem anderen Fluss heraus zur Ausführung
13

Abbildung 2.4: Typhierarchie der abstrakten Context-Metaklasse
kommen kann (Metaklassen ExtensionContext und InclusionContext).
Diese beiden Kontextkonzepte werden im Rahmen der Beschreibungen der Inklusionsund
Erweiterungsbeziehungen in späteren Abschnitten näher ausgeführt. Darüber hinaus
gibt es noch zwei andere Spezialisierungen des Kontextbegriffs.
Dies ist zum einen der Interaktionskontext (Metaklasse InteractionContext).
Ein Fluss, an dem ein derartiger Kontext definiert ist, kann als Einstieg in einen Anwendungsfall
benutzt werden. Die Ausführung eines solchen Flusses wird durch einen
Akteur ausgelöst, d.h. der Akteur interagiert mit dem System. Der Interaktionskontext
koppelt ein oder mehrere Akteure an einen Fluss. Dabei hat genau ein Akteur
die ausgezeichnete Rolle als primärer Akteur inne. Nur primäre Akteure können einen
Anwendungsfall anstoßen. Außerdem können im Interaktionskontext Vor- und Nachbedingungen
natürlichsprachlich formuliert werden, die vor bzw. nach Ausführung des
Flusses gelten müssen. Auch Invarianten, die während der kompletten Ausführung erfüllt
sein müssen, können dort in natürlicher Sprache festgehalten werden. Der Inhalt
der Vor- und Nachbedingungen und der Invariante hat allerdings keine Semantik für
das NarrativeModell an sich.
Zum anderen gibt es Ausnahmekontexte (Metaklasse ExceptionContext). Ein
Fluss, der einen derartigen Kontext besitzt, ist ein Ausnahmefluss. Im Allgemeinen
kann ein Fluss zwar mehrere Kontexte besitzen, aber üblicherweise verfügt er, wenn
er der Behandlung von Ausnahmen dient, nur über einen Kontext (den Ausnahmekontext).
In diesem Fall ist es dann anschaulicher, von einem Ausnahmefluss zu sprechen.
Ein Ausnahmefluss definiert Verhalten, welches zur Ausführung kommt als Reaktion
auf eine aufgetretene Ausnahme in einem anderen Fluss. Die Kopplung an den anderen
Fluss geschieht über den Kontext. Hier wird auch eine natürlichsprachliche Bedingung
(entryCondition) formuliert, die angibt, in welchem Fall der Ausnahmefluss
im überwachten Fluss zur Ausnahmebehandlung aktiv wird. Anders als Erweiterungen
oder Inklusionen, die an wohl definierten Stellen eines Flusses stattfinden, bedeutet die
Kopplung eines Flusses an einen Ausnahmefluss, dass die Ausnahmebedingung zu jeder
Zeit der Ausführung eintreten kann und damit das Verhalten des Ausnahmeflusses
zum Einsatz kommt.
14

Ausnahmeflüsse haben semantische Besonderheiten in zweifacher Art: Die erste Besonderheit
besteht darin, dass der Kontrollfluss abhängig vom Zustand nach Ausführung
des Ausnahmeflusses an verschiedenen Stellen fortfahren kann. Er kann im Ursprungfluss
hinter demjenigen Ereignis, an dem die Ausnahme eingetreten war, fortgesetzt
werden. Ebenso kann auch zum Ende des Ursprungflusses gesprungen werden
oder sogar zum Ende des gesamten Anwendungsfalles. Während der Ausführung
wird abhängig vom Zustand am Ende des Ausnahmeflusses eine dieser drei Rücksprungsmöglichkeiten
gewählt. Für jede dieser drei Möglichkeiten kann man je eine
Bedingung im Kontext spezifizieren, unter der diese stattfindet (continueCondition,
bypassCondition und abortCondition). Die zweite semantische Besonderheit ist durch
den Gültigkeitsbereich des Ausnahmeflusses gegeben. Ein Ausnahmefluss kann auch
jederzeit in Flüssen zum Effekt kommen, die erst über Inklusion oder Erweiterung
desjenigen Flusses, an den der Ausnahmefluss gekoppelt ist, zur Ausführung kamen.
Abbildung 2.5: Kontrollfluss bei Ausnahmeflüssen
Abbildung 2.5 illustriert beispielhaft die Kontrollflussmöglichkeiten für Ausnahmeflüsse.
Ausgangspunkt ist, dass sich der Kontrollfluss nach der Aktion A vom Hauptfluss
zum Ausnahmefluss verlagert. Dies setzt voraus, dass die Ausnahmebedingung
während der Ausführung von A erfüllt wurde. Daraufhin wird im Ausnahmefluss dessen
gesamtes Verhalten in Form dreier Aktionen ausgeführt. Beim Verlassen des Ausnahmeflusses
kann der Kontrollfluss auf drei verschiedene Arten weiterlaufen:
1. die Ausführung des Hauptflusses wird mit dem Ereignis hinter der Aktion A,
welche die Ausnahmebehandlung ausgelöst hat, fortgesetzt,
2. die Ausführung des Hauptflusses wird beendet,
3. die Ausführung des kompletten Anwendungsfalles wird beendet.
15

Ausnahmekontexte, Erweiterungs- und Inklusionskontexte koppeln je zwei Flüsse über
die durch den Kontext bestimmte Beziehung. Bei Ausnahmekontexten ist dies unmittelbar
der Fall, bei Erweiterungs- und Inklusionskontexten, wie im Folgeabschnitt beschrieben,
nur mittelbar.
2.2.6 Beziehungen zwischen Flüssen
In der UML gibt es zwei Arten von Beziehungen zwischen Use Cases, welche eine
Aussage über die Verhaltensbeziehungen zwischen den Use Cases machen, nämlich
Erweiterungs- und Inklusionsbeziehungen. Diese Beziehungen werden im Narrative-
Model verfeinert und auf die Flussebene übertragen. Die Generalisierungsbeziehung
zwischen Use Cases überträgt sich ganz analog auf die dazugehörigen NarrativeDescriptions.
Welche Folgen das für die Elemente der NarrativeDescriptions hat, wird in
Abschnitt 2.2.6 erläutert.
Es ist klar, dass sich Inklusions- und Erweiterungsbeziehungen zwischen Use Cases
wiederfinden müssen als Beziehungen zwischen Flüssen. Inkludiert ein Use Case U1
einen Use Case U2, muss es auch mindestens einen Fluss in U1 geben, der einen
Fluss aus U2 inkludiert. Nur wenn es mindestens eine Inklusionsbeziehung zwischen
Flüssen der beiden Anwendungsfälle gibt, ist auch die Inklusionsbeziehung auf Ebene
der Use Cases „befriedigt“. Diese fordert, dass das Verhalten von U2 an einer Stelle in
U1 zur Ausführung kommen muss.
Im Folgenden werden die drei Beziehungsarten im Detail beschrieben. Insbesondere
wird geklärt, inwiefern verschiedene Elemente des Metamodells zusammenwirken,
um die jeweiligen Beziehungstypen im Modell zu realisieren.
Inklusionen
Eine Inklusion bewirkt die unbedingte Ausführung des gesamten Verhaltens eines
Flusses aus einem anderen Fluss heraus. Hierbei spricht man von einem inkludierenden
Fluss auf der einen Seite und von einem inkludierten Fluss auf der anderen. Das
Verhalten des inkludierten Flusses wird an der Stelle der Inklusion im inkludierenden
Fluss ausgeführt. Die genaue Stelle in einem Fluss, an der dies stattfindet, wird in
Form einer Event-Spezialisierung, der Inklusion (Metaklasse Inclusion), modelliert.
Die Inklusion ist ein spezieller Kontextwechsel: eine Inklusion induziert in jedem
Fall einen Wechsel des aktuellen Kontexts (der aktuelle Fluss wird verlassen und ein
anderer betreten).
Auf der Gegenseite muss der inkludierte Fluss über einen Inklusionskontext (Metaklasse
InclusionContext) verfügen. Besitzt er einen solchen Kontext, heißt das,
dass man diesen Fluss aus einem anderen Fluss heraus einmal oder mehrmals inkludieren
kann. Möchte man denselben Fluss aus einem anderen Fluss heraus inkludieren,
bedarf es eines weiteren Inklusionskontexts. Ein Kontext stellt also immer eine Verbindung
zwischen zwei Flüssen dar. Je nachdem, ob ein Fluss intern oder extern inkludiert
16

wird, kann zwischen internen und externen Inklusionskontexten unterschieden werden
(Metaklassen InternalInclusionContext und ExternalInclusion-
Context). Analog dazu gibt es ebenfalls Spezialisierungen für Inklusionen (Metaklassen
InternalInclusion und ExternalInclusion).
Abbildung 2.6: Inklusionskontext- und Inklusionskonzepte
Abbildung 2.6 illustriert den Zusammenhang der verschiedenen Elemente, über die eine
Inklusionsbeziehung zustande kommt. Die abstrakten Konzepte Context und ControlEvent
werden verfeinert zu den abstrakten Begriffen InclusionContext und Inclusion,
um dann schließlich für externe und interne Inklusionsbeziehungen konkretisiert
zu werden. Zu beachten ist hier, dass jede Inklusion mit genau einem Kontext verbunden
ist. Dies spiegelt zum einen die Richtung der Inklusionsbeziehung von inkludierender
Verhaltenssequenz zu inkludiertem Verhalten wider und zum anderen den Fakt,
dass diese Beziehung „verbindlich“ in dem Sinne ist, dass sie unbedingt stattfindet.
Aus Sicht des Kontextes kann dieser mit ein oder mehreren Inklusionen verbunden
sein, solange diese alle als Teil desselben Flusses definiert sind.
Erweiterungen
Besteht eine Erweiterungsbeziehung zwischen zwei Use Cases, hat dies zur Folge,
dass es auch mindestens zwischen zwei Flüssen der jeweiligen Use Cases eine derartige
Verbindung gibt. In dem Fall spricht man von einem erweiterten Fluss, in den
Verhalten eingefügt werden kann und einem erweiternden Fluss, dessen Verhalten eingefügt
wird.
In der Verhaltenssequenz des erweiterten Flusses muss es demnach ein oder mehrere
Positionen geben, an denen dies der Fall sein kann. Solch ein Punkt wird innerhalb des
Flusses repräsentiert durch ein spezielles Ereignis (genauer: einen speziellen Con-
17

trolEvent), einen sogenannten Erweiterungsanker (Metaklasse ExtensionAnchor).
An dieser Stelle kann dann unter einer bestimmten Bedingung während der
Ausführung des Flusses das Verhalten eines anderen Flusses eingefügt werden.
Dafür muss der erweiternde Fluss allerdings als Voraussetzung einen Erweiterungskontext
(Metaklasse ExtensionContext) besitzen. Hat ein Fluss einen derartigen
Erweiterungskontext, dient er als mögliches Alternativverhalten für einen anderen
Fluss. Während der Ausführung wird das Verhalten dann je nach Gültigkeit einer bestimmten
Bedingung, die im Erweiterungskontext in natürlicher Sprache formuliert ist,
im erweiterten Fluss eingefügt. Beachtenswert hierbei ist, dass der erweiternde Fluss,
der den Erweiterungskontext besitzt, damit auch die Bedingung angibt, unter der er
in einem anderen Fluss zur Ausführung kommt. Dies entspricht der Semantik der Erweiterungsbeziehung
in der UML, die mittels Extend-Metaklasse modelliert wird.
Die Erweiterungsbeziehung ist eine gerichtete Beziehung von erweiterndem Use Case
zum erweiterten Use Case. Der erweiternde Anwendungsfall spezifiziert unter welcher
Bedingung er zum Tragen kommt. Der erweiterte Use Case bietet nur Stellen an, an
denen er erweitert werden kann.
Abbildung 2.7: Abstrakte Erweiterungskontext- und Erweiterungsankerkonzepte
Abbildung 2.7 veranschaulicht diesen Zusammenhang. Ein Erweiterungsfluss muss
einen Erweiterungskontext besitzen. Der erweiterte Fluss muss ein spezielles Ereignis
in Form eines Erweiterungsankers definieren, an dem das Verhalten des erweiternden
Flusses zur Ausführung kommen kann. Er kann mehrere derartige Anker an verschiedenen
Stellen in seinem Verhaltensablauf definieren, an die dann mögliche Kontexte
„angedockt“ werden. Diese Kardinalität spiegelt die Richtung der Erweiterungsbeziehung
wider (von erweiterndem Fluss zu erweitertem Fluss): Erweiterungsanker werden
lokal in einem Fluss definiert, ohne Wissen, ob an den Stellen tatsächlich bedingtes
Verhalten zum Einsatz kommt. Daher muss ein Anker auch nicht zwangsläufig mit einem
Kontext verbunden sein. Andersherum muss ein Erweiterungskontext mit ein oder
mehreren Ankern verbunden werden, die dann allerdings alle Teil desselben Flusses
sein müssen. Die Konzepte in Abbildung 2.7 sind alle abstrakt. Sie werden im Folgenden
bezüglich des Aspekts verfeinert, ob eine Erweiterungsbeziehung zwischen zwei
Flüssen einer NarrativeDescription oder verschiedener NarrativeDescriptions besteht.
18

Man unterscheidet zwischen internen Erweiterungskontexten (Metaklasse InternalExtensionContext),
die Flüsse einer NarrativeDescription koppeln und Externen
(Metaklasse ExternalExtensionContext), über die zwei Flüsse verschiedener
NarrativeDescriptions in eine Erweiterungsbeziehung gesetzt werden. Ein
externer Erweiterungskontext hat dabei einen Verweis auf die Extend-Instanz des
UML-Modells, die er repräsentiert. Man kann nur dort externe Erweiterungsbeziehungen
zwischen Flüssen von Use Cases modellieren, wo auch eine Erweiterungsbeziehung
zwischen den entsprechenden Use Cases besteht. Analog zu den internen und externen
Kontexten wird bei den Ankern, an denen die Erweiterungsbeziehung ansetzt,
ebenfalls unterschieden zwischen internen und externen Erweiterungsankern (Metaklassen
InternalExtensionAnchor, ExternalExtensionAnchor). Auch
hier hat der externe Erweiterungsanker eine Referenz auf die entsprechende ExtensionPoint-Instanz
des UML-Modells.
Abbildung 2.8: Verfeinerung der Erweiterungskontext- und Erweiterungsankerkonzepte
Abbildung 2.8 beschreibt die Spezialisierungen der aus Abbildung 2.7 bekannten Konzepte.
Man sieht wie die Erweiterungsbeziehung zu internen und externen Kontexten
und Ankern verfeinert wird.
Darüber hinaus unterscheidet sich die Semantik der internen Erweiterungsbeziehung
zwischen zwei Flüssen einer NarrativeDescription von derjenigen der externen Erweiterungsbeziehung.
Die Semantik der externen Beziehung ist vorgegeben durch die
Semantik des Extends in der UML. Diese besagt, dass bestimmte Teile des Verhaltens
des erweiternden Use Cases an ein oder mehreren Stelle im erweiterten Use Case
zur Ausführung kommen können (abhängig davon, ob die Bedingung erfüllt ist oder
nicht). Kommt das Alternativverhalten des erweiternden Flusses im erweiterten Fluss
zur Ausführung, wird der Kontrollfluss im erweiterten Fluss nach Ausführung des Alternativverhaltens
hinter der Stelle, an der die Erweiterung ursprünglich stattgefunden
hat, fortgesetzt. Es ist nicht möglich nach der Ausführung des erweiternden Flusses
19

den Kontrollfluss an einer anderen Stelle im erweiterten Fluss fortzusetzen.
Anders verhält es sich im Falle von internen Erweiterungsbeziehungen. Hier kann
man am Ende der Ausführung eines erweiternden Flusses abhängig von bestimmten
Bedingungen entscheiden, an welcher Stelle im erweiterten Fluss der Kontrollfluss
fortgesetzt werden soll. Konkret geschieht dies über (interne) Erweiterungsanker (Metaklasse
InternalExtensionAnchor), welche als Rücksprungsanker für einen
internen Erweiterungskontext dienen. Jeder Rücksprungsanker ist außerdem über den
Kontext assoziiert mit einer (in natürlicher Sprache formulierten) Rücksprungsbedingung.
Am Ende der Ausführung des erweiternden Flusses wird dann abhängig von der
erfüllten Bedingung zu einem dieser Anker zurückgesprungen. Verbunden wird ein
interner Erweiterungsanker in seiner Funktion als herkömmlicher Erweiterungspunkt
mit einem internen Erweiterungskontext über die branchingInternalExtension/internalBranchAnchor-Assoziation
zwischen den beiden Elementen. Analog dazu gibt es
eine mergingInternalExtension/internalMergeAnchor-Assoziation über die ein Anker
als Rücksprungspunkt mit einem Kontext verbunden wird.
Generalisierung
Als dritten Beziehungstypen zwischen Use Cases gibt es die Generalisierung. Anders
als Inklusions- und Erweiterungsbeziehungen dient die Generalisierung nicht der Modellierung
von Verhaltensbeziehungen zwischen Flüssen. Die Generalisierung im Sinne
der UML, beschreibt eine taxonomische Beziehung zwischen einem spezielleren
und einem generelleren Classifier.
Im UML-Metamodell ist die Generalisierung demnach nicht als reflexive Beziehung
zwischen Use Cases definiert, sondern bereits auf der Ebene der abstrakten Metaklasse
Classifier. Ein Classifier dient der Klassifizierung von Instanzen bezüglich ihrer
sie kennzeichnenden Eigenschaften. Classifier können in einer Generalisierungsbeziehung
zu anderen Classifiern stehen. Damit stehen Eigenschaften, die für Instanzen des
generelleren Classifiers spezifiziert wurden, auch denjenigen des spezielleren Classifiers
zur Verfügung. Sowohl Use Cases als auch Akteure sind Classifier.
Ein verwandtes UML-Konzept wird durch die abstrakte Metaklasse Redefinable-
Element beschrieben. Ein derartig redefinierbares Element ist ein Element, welches,
wenn es im Kontext eines Classifiers definiert wurde, von einem anderen Classifier, der
eine Spezialisierung des Kontextclassifiers darstellt, redefiniert werden kann. Classifier
selbst sind derartige redefinierbare Elemente, damit also insbesondere auch Akteure
und Use Cases.
Aus dem Vorhergegangenen folgt, dass ein Use Case A, der als Spezialisierung des
Use Case B modelliert wird, diesen Use Case B redefinieren kann. Auch die Extend-Metaklasse
über die die Erweiterungsbeziehung zwischen Use Cases realisiert
wird, ist eine RedefinableElement-Spezialisierung. Somit sieht die UML nicht
nur vor, dass Use Cases als Ganzes redefiniert werden, sondern durchaus auch einzelne
Elemente von Use Cases. Über die Redefinition des Verhaltens von Use Cases
20

macht die UML-Spezifikation selbst allerdings keinerlei Angaben. Damit bleibt offen,
auf welcher Granularität Verhalten redefiniert werden kann und was Redefinition
in diesem Kontext überhaupt bedeutet. Bei der Konzipierung des NarrativeModels
wurde die von Bittner und Spence ausgeführte Interpretation [BS02] für die Generalisierungsbeziehung
zwischen Anwendungsfällen adaptiert und auf die Elemente des
NarrativeModels angewendet.
Nach Bittner und Spence wird im Rahmen der Spezialisierungsbeziehung zwischen
Use Cases natürlich auch Verhalten verfeinert. Konkret kann das Verhalten des generellen
Use Cases im spezialisierenden Use Case zutage treten, in aller Regel geschieht
dies jedoch in modifizierter Form. Bezogen auf die textuellen Beschreibungen von Use
Cases vererben sich im Zuge der Spezialisierung die formulierten Verhaltenssequenzen
(also die Flüsse) der generellen NarrativeDescription an die speziellere NarrativeDescription.
Abbildung 2.9: Generalisierung und Redefinierbarkeit im NarrativeModel
Damit folgt, dass insbesondere alle diejenigen Elemente redefinierbar sein müssen,
die die interne Struktur einer natürlichsprachlichen Beschreibung ausmachen. Anders
als ihre referenzierten Entsprechungen im UML-Metamodell sind die Metaklassen
NarrativeActor und NarrativeDescription nicht redefinierbar. Erst
die NarrativeModel-Metaklassen, die eingesetzt werden zur Spezifikation der internen
Struktur einer NarrativeDescription, spezialisieren die RedefinableElement
Metaklasse. Die Elemente die das Verhalten einer NarrativeDescription ausmachen
sind Flow, Context und Event. Dies ist illustriert in Abbildung 2.9. In dieser
Abbildung sieht man, dass NarrativeDescription und NarrativeActor
keine RedefinableElements sind. Sie besitzen wohl aber eine specific/general-
Assoziation, über die eine NarrativeDescription mit ihren spezielleren bzw. generelleren
NarrativeDescriptions verbunden ist. Die Hierarchie der NarrativeDescriptions
gemäß dieser Assoziation entspricht genau der Generalisierungshierarchie zwischen
den dazugehörigen Use Cases.
21

Mittels dieser Mechanismen kann eine textuelle Beschreibung bezüglich ihrer verschiedenen
Eigenschaften spezialisiert und redefiniert werden. Besteht eine Spezialisierungsbeziehung
zwischen zwei textuellen Beschreibungen A und B (von A nach
B), erbt die NarrativeDescription A die Eigenschaften von B, d.h. insbesondere alle
in B definierten Flüsse, samt dazugehöriger Kontexte und Ereignisse. Auf Narrative-
Description-Strukturebene können im Rahmen der Spezialisierung neue Flüsse hinzugefügt
werden oder bestehende Flüsse redefiniert werden. Dabei können bestehende
Ereignisse redefiniert werden oder an beliebigen Stellen im Fluss neue Ereignisse hinzugefügt
werden. Flüsse können außerdem zusätzliche Kontexte erhalten und bestehende
Kontexte können redefiniert werden.
Ist ein Use Case abstrakt, dann ebenso die dazugehörige NarrativeDescription. Innerhalb
der NarrativeDescription können Flüsse als Ganzes abstrakt sein (d.h. sie definieren
keinerlei Ereignisse) oder ein Fluss besitzt eine Menge von konkreten und abstrakten
Ereignissen. Beinhaltet ein Fluss ein abstraktes Ereignis, ist der Fluss als solcher
notwendigerweise auch abstrakt. Dies setzt sich dann fort bis auf die Ebene der NarrativeDescription.
Umgekehrt gilt, dass ein konkreter Use Case keinerlei abstraktes
Verhalten besitzen kann. Konsistenz zwischen Use Case-Modell und NarrativeModel-
Modell wird hier, wie an vielen anderen Stellen, durch im Metamodell formulierte
Randbedingungen sichergestellt.
2.2.7 Randbedingungen im Metamodell
Viele Elemente des Metamodells sind mit Randbedingungen (constraints) versehen,
die mittels OCL (Object Constraint Language) [Obj03a] formuliert sind. Randbedingungen
sollen Qualität und Konsistenz einer Modellinstanz verbessern und sicherstellen.
Neben den Arten von Randbedingungen, die in der UML-Spezifikation beschrieben
sind [Obj07b] unterscheiden wir zwischen zwei weiteren Typen:
• Randbedingungen, die die strukturelle Konsistenz eines NarrativeModels mit
dem zu beschreibenden Use Case-Modell gewährleisten sollen und
• Randbedingungen, die Semantik für Elemente des NarrativeModels formulieren.
Die zweite Art Randbedingung ist insofern wichtiger, als dass eine derartige Bedingung
Semantik definiert und im Falle ihrer Verletzung die NarrativeModel-Instanz
inkorrekt ist. Konkret kann dies beispielsweise bedeuten, dass bestimmte Flüsse gar
nicht oder nur ungenügend spezifiziert wurden.
Mit Hilfe von Randbedingungen kann sichergestellt werden, dass eine Modellinstanz
ohne Verletzungen korrekt ist in dem Sinne, dass die Elemente des Use Case-Modells
Entsprechungen im NarrativeModel besitzen (Konsistenz). Weiterhin kann garantiert
22

werden, dass alle durch die NarrativeModel-Instanz beschriebenen Szenarien ein wohl
definiertes Startereignis haben, von dem aus ein endlicher Pfad, der aus einer diskreten
Folge von Ereignissen besteht, zum Ende des Anwendungsfalles existiert. Randbedingungen
können offensichtlich nicht sicherstellen, dass Anwendungsfälle vollständig
und korrekt im Sinne der modellierten Domäne beschrieben werden.
Als Beispiel für eine semantische Absicherung mittels Randbedingung dienen Inklusionen.
Weiter oben wurde für Inklusionskontexte beschrieben, dass jeder Fluss, der
einen solchen Kontext besitzt, aus einem anderen Fluss heraus ein- oder mehrmals
inkludiert werden kann. Über eine Randbedingung wird an dieser Stelle abgesichert,
dass nicht zwei verschiedene Flüsse den inkludierten Fluss über denselben Kontext
inkludieren.
Eine andere Randbedingung gewährleistet, dass der Rücksprung aus einem erweiternden
Fluss (mittels interner Erweiterung) nur zu einem Anker des ursprünglich erweiterten
Flusses erfolgen kann und nicht etwa zu einem anderen Fluss.
2.3 Beispiel für eine textbasierte Anwendungsfallbeschreibung
An dieser Stelle wird ein (für diesen Zweck vereinfachtes) Beispiel vorgestellt. Inhalt
ist die Modellierung eines Geldautomaten mit Hilfe eines Use Case-Diagramms und
darauf aufsetzender textueller Beschreibung.
Abbildung 2.10: Use Case Modellierung eines Geldautomaten
23

In Abbildung 2.10 ist das System Geldautomat modelliert. Der Akteur auf der linken
Seite ist der Kunde. Er ist der primäre Akteur und aus seiner Sicht wird die funktionale
Anforderung Geld abheben an den Geldautomaten formuliert. Aus diesem Grund ist
der Kunde mit dem entsprechenden Use Case assoziiert.
Da ein Kunde, der Geld ausgezahlt bekommen möchte, sich auch immer authentifizieren
muss, inkludiert Geld abheben den Anwendungsfall Authentifizieren. Verbunden
mit diesen beiden Use Cases ist der Akteur Banksystem. Während der Transaktion des
Geld abhebens und des Authentifizierungsvorgangs kommuniziert der Geldautomat
mit dem Banksystem. Der Anwendungsfall Quittung drucken steht als Erweiterung
mit Geld abheben in Beziehung. Wenn der Kunde es wünscht, bekommt er eine Quittung
der gerade getätigten Auszahlung gedruckt.
Use Case Geld abheben
Geld abheben Standard:
Kontexte:
wird ausgelöst vom Kunden
Ereignisse:
1. Der Kunde steckt seine Bankkarte in den
Automaten.
2. Inklusion: Use Case Authentifizieren
3. {hinter Authentifizierung}
4. Der Kunde gibt gewünschten Geldbetrag
ein.
5. Der Automat gibt die Bankkarte zurück.
6. Der Automat zahlt das Geld aus.
7. {hinter Geld Ausgabe}
Kunde bricht ab:
Kontexte:
Zu jeder Zeit in {Geld abheben Standard},
wenn Kunde abbricht
Ereignisse:
1. Der Automat gibt die Bankkarte zurück.
Kontrollfluss:
Anwendungsfall beenden, wenn: wahr
UC Authentifizieren
Authentifizieren Standard:
Kontexte:
inkludiert von Fluss {Geld abheben Standard}
in Use Case Geld abheben
Ereignisse:
1. {vor PIN Eingabe}
2. Der Kunde gibt seine PIN ein.
3. {hinter PIN Eingabe}
erneute PIN Eingabe:
Kontexte:
erweitert Fluss {Authentifizieren Standard}
an {hinter PIN Eingabe}, wenn PIN inkorrekt
Ereignisse:
1. Der Automat fordert den Kunden zur erneuten
PIN Eingabe auf.
Kontrollfluss:
zurück zu {vor PIN Eingabe}, wenn: wahr
UC Quittung drucken
Quittung drucken Standard:
Kontexte:
erweitert Fluss {Geld abheben Standard} an
{hinter Geld Ausgabe}, wenn Kunde Quittung
wünscht
Ereignisse:
1. Der Automat druckt eine Quittung.
Kontrollfluss:
zurück zu {hinter Geld Ausgabe}, wenn:
wahr
Abbildung 2.11: Textuelle Beschreibung der Geldautomatanwendungsfälle
Abbildung 2.11 repräsentiert eine NarrativeModel-Instanz in Form einer strukturierten
Darstellung in natürlicher Sprache, die angelehnt ist an die informelle Darstellung von
textuellen Anwendungsfallbeschreibungen von Bittner und Spence [BS02].
Hier findet man all diejenigen Elemente als Teil der Beschreibung wieder, die wie im
Vorgängerkapitel vorgestellt, die interne Struktur eines Use Cases ausmachen. Zum
Use Case Geld abheben gehört eine NarrativeDescription, für die zwei Flüsse definiert
24

sind. Zum einen ist dies der Fluss Geld abheben Standard, der den Standardablauf des
Anwendungsfalles beschreibt und der durch einen Kunden ausgelöst wird (festgehalten
im Kontext des Flusses), indem dieser seine Karte in den Automaten einführt (die
erste Aktion im Fluss). Im NarrativeModel hat dieser Fluss insgesamt sieben Ereignisse:
• vier Aktionen (an den Positionen 1, 4, 5 und 6 im Fluss)
• eine externe Inklusion (an der Position 2)
• zwei Erweiterungsanker (ein Interner an Position 3, namens {hinter Authentifizierung}
und ein Externer an Position 7 {hinter Geld Ausgabe}
Der Erweiterungsanker {hinter Authentifizierung} wird im Rahmen dieses Beispiels
nicht benutzt. An dieser Stelle würde als Teil einer vollständigen Beschreibung internes
Alternativverhalten zum Zuge kommen. Beispielsweise ein Test, ob der Kunde
nach Inklusion des Anwendungsfalles Authentifizieren tatsächlich authentifiziert ist.
Im Beispiel ist das Verhalten des Flusses Authentifizieren Standard insofern sehr simpel
gehalten, als dass der Kunde nach Eingabe einer falschen PIN erneut aufgefordert
wird, sich zu authentifizieren. In der Realität würde der Automat nach einer bestimmten
Anzahl erfolgloser Eingabeversuche die Bankkarte des Kunden einziehen. In dem
Fall ist der Kunde nach Ausführung von Authentifizieren nicht authentifiziert und es
müsste vom Standardablauf abweichendes Alternativverhalten zur Aktion kommen.
Außerdem besitzt der Anwendungsfall Geld abheben noch einen anderen Fluss, nämlich
Kunde bricht ab. Dies ist ein Ausnahmefluss, dessen Verhalten jederzeit zur Ausführung
kommen kann, wenn der Kunde die aktuelle Transaktion abbricht. Hierbei ist
zu beachten, dass der Ausnahmefluss sich zwar auf den Fluss Geld abheben Standard
bezieht, aber auch wirksam wird während der Ausführung der Flüsse Authentifizieren
Standard und Quittung drucken aus Geld abheben Standard heraus. Am Ende der
Ausführung eines Ausnahmeflusses gibt es grundsätzlich drei verschiedene Möglichkeiten,
den Kontrollfluss fortzusetzen. Im konkreten Fall des Ausnahmeflusses Kunde
bricht ab folgt jedoch immer das Ende des Anwendungsfalles.
25

Kapitel 3
Technische Grundlagen
Im Zuge der technischen Realisierung der Simulationsumgebung wurden diverse Technologien
aus dem Umfeld von Eclipse eingesetzt. Diese werden ebenso wie die Eclipse-
Plattform selbst im Folgenden vorgestellt. Den Abschluss dieses Kapitels bildet eine
Beschreibung der ViPER-IDE.
3.1 Eclipse-Plattform
Eclipse ([Ecla]) wurde ursprünglich entwickelt von OTI (Object Technology International)
als Nachfolgeprodukt von VisualAge. Die Verantwortung für Eclipse ging
mit der OTI Übernahme durch IBM 1996 an IBM Kanada über. Anfang 2001 hat
IBM Eclipse der Open-Source-Gemeinde geschenkt. 2003 wurde der Open-Source-
Entwicklungsprozess für Eclipse in Form der Eclipse Foundation institutionalisiert.
Die Eclipse Foundation steuert die Entwicklung von Eclipse und ist dafür verantwortlich,
dass Eclipse spätestens seit der Version 3.0 mehr ist als eine bloße Java-
Entwicklungsumgebung. Seit dieser Version dient der strukturelle Kern von Eclipse
als Basis für beliebige Desktopanwendungen. Wo Eclipse in Version 2.1 primär eine
Java-Entwicklungsumgebung darstellte, fand mit Version 3.0 ein Paradigmenwechsel
statt. Eclipse wird nunmehr primär als Plattform wahrgenommen und die Java-
Entwicklungsumgebung als eine Ausprägung dieser Plattform. Technologische Voraussetzung
für dieses Umdenken war die Einführung einer OSGi-basierten [OSG]
Plattformlaufzeitumgebung, die den Grundstein legte für eine dynamische Plugin-
Architektur. Mit Version 3.1 ist Eclipse zu einer auch in der Praxis bewährten Rich
Client Plattform gereift. Beispielsweise hat die NASA auf Basis der Eclipse-Plattform
ein Produkt zur Steuerung des Mars-Rovers „Spirit“ entwickelt [Mae].
Eine Rich Client Plattform gibt dem Entwickler Technologien und Rahmenwerke für
die Entwicklung von Rich Clients an die Hand. Rich Clients bieten einem Benutzer für
eine bestimmte Domäne eine komfortable und qualitativ hochwertige graphische Oberfläche.
Die graphische Oberfläche eines Rich Client nutzt native Desktop-Metaphern
27

wie Drag-and-Drop, Zwischenablage, Navigation und Look-and-Feel [ML05]. Eine
Rich Client Plattform unterstützt und erleichtert die Entwicklung eines derartigen Rich
Clients, indem sie sowohl einen technologischen Rahmen als auch eine Architektur
vorgibt. Im Idealfall erleichtert sie außerdem die Integration verschiedener generell
unabhängiger, aber doch zusammenarbeitender Anwendungskomponenten.
In der Eclipse-Nomenklatur heißen einzelne Komponenten, die gemeinsam die Plattform
ausmachen, Plugins. Die Plattform kann jederzeit durch weitere Plugins erweitert
werden. Die Eclipse-Plattform stellt Mechanismen und Regeln bereit, um die nahtlose
Integration verschiedener Werkzeuge in Form von Plugins zu ermöglichen.
Ein Plugin ist die kleinste Einheit einer Funktionalität, die gesondert für die Eclipse-
Plattform entwickelt und eingesetzt werden kann [Obj03b]. Bis auf den funktionalen
Eclipse Kern, die Plattform-Runtime, ist der komplette Rest der Eclipse-Funktionalität
in Form von Plugins realisiert. Plugins werden in Java programmiert. Ein typisches
Plugin besteht aus einer Menge von Java-Klassen und diversen anderen Artefakten,
wie beispielsweise HTML- und Bilddateien sowie generell jeder beliebigen Art von
Datei. Notwendiger Bestandteil eines jeden Plugins ist das Plugin-Manifest. Dieses
Manifest spezifiziert deklarativ, inwiefern das aktuelle Plugin andere Plugins erweitert
(Extension) oder selbst Erweiterungspunkte (ExtensionPoint) anbietet, über die es
selbst von anderen Plugins erweitert werden kann.
Als Beispiel für diesen Mechanismus sei das Workbench-Plugin von Eclipse genannt.
Dieses definiert einen Erweiterungspunkt für Benutzereinstellungen (Preferences). Jedes
Plugin kann seine eigenen lokalen Benutzereinstellungen mittels Extension zu diesem
Erweiterungspunkt beisteuern. Ein Erweiterungspunkt kann Schnittstellen definieren,
die ein erweiterndes Plugin in Form von Java-Klassen Implementierungen bereitstellen
muss, um den Erweiterungspunkt anzusteuern.
Beim Start der Eclipse-Plattform legt die Plattform-Runtime alle verfügbaren Plugins
in der ExtensionRegistry ab. Hierfür werden die einzelnen Plugins noch nicht komplett
in den Speicher geladen, sondern nur ihr jeweiliges Manifest gelesen und die
daraus extrahierten Informationen in der ExtensionRegistry gespeichert. Dieses „lazyloading“
von Plugins garantiert schnelle Startzeiten für die Plattform und reduziert den
anfänglichen Speicherverbrauch. Solange ein Plugin nicht vollständig geladen ist, ist
sein Speicherverbrauch vernachlässigbar. Während der Laufzeit können der Ausführungsplattform
keine neuen Plugins hinzugefügt werden.
Ein Plugin wird aktiviert, wenn der Code des Plugins tatsächlich ausgeführt werden
soll. Erst zu diesem Zeitpunkt werden seine Java-Klasse instanziiert. Außerdem nutzt
das Plugin die ExtensionRegistry, um auf die Erweiterungen durch externe Plugins
zuzugreifen und diese einzubinden.
Die Plattform-Runtime definiert einen speziellen Erweiterungspunkt für Anwendungen,
die auf der Eclipse Rich Client Plattform basieren. Wenn eine Instanz der Plattform
ausgeführt wird, wird ihr der Name der Anwendung per Parameter übergeben.
Damit wird einzig das Plugin der Anwendung geladen und aktiviert.
28

Abbildung 3.1: Architektur der Eclipse-Plattform
Abbildung 3.1 stellt die grobe Struktur der Eclipse-Plattform Architektur dar. Alle
Komponenten bestehen aus ein oder mehreren Plugins. Die für diese Arbeit relevanten
Komponenten sind Workspace und Workbench. Workbench baut auf dem SWT/JFace-
Toolkit auf.
3.1.1 Workspaces
Die verschiedenen Werkzeuge, die als Plugin die Eclipse-Plattform erweitern, operieren
auf physischen Dateien im Workspace des Benutzers. Der Workspace ist ein
Eclipse-Konzept und wird technisch durch das gleichnamige Plugin als Teil der Eclipse-
Plattform realisiert. Der Workspace besteht aus einer Menge von top-level Projekten,
die jeweils im Dateisystem eine Entsprechung in Form eines benutzerdefinierten Verzeichnisses
haben. Jedes Projekt beinhaltet Dateien, die vom Benutzer mittels diverser
Operationen manipuliert werden können. Dies beinhaltet neben der Modifikation und
des Löschens vorhandener Dateien natürlich auch das Anlegen neuer Dateien. Auf alle
Dateien des Workspaces kann außerdem über die normalen Betriebssystemmechanismen
und Anwendungen zugegriffen werden. Allerdings legt die Eclipse-Plattform für
Werkzeuge, die in die Plattform integrierte sind, eine Abstraktionsschicht über diese
Ebene. Hier sind Projekte, Dateien und Verzeichnisse Ressourcen (IResource-
Instanzen), auf die per Platform-API zugegriffen werden kann. Derartige Workspace-
Ressourcen werden durch adaptierbare Objekte repräsentiert. Das sind Objekte, die das
29

IAdaptable-Interface implementieren und deren Verhalten über diesen Weg von
anderen Werkzeugen (in Form von Plugins) erweitert werden kann. Darüber hinaus
bietet die Plattform einen Mechanismus zum Verfolgen von Workspace-Änderungen.
Dies geschieht mit Hilfe von Notifikationen, mittels derer interessierte Werkzeuge über
Manipulationen an bestimmten Ressourcen in Form sogenannter Ressource-Deltas informiert
werden.
3.1.2 SWT/JFace
Die Bedienoberfläche der Eclipse-Plattform basiert auf einer Workbench, die ein Erscheinungsbild
vorgibt und dem Benutzer eine erweiterbare Oberfläche präsentiert.
API und Implementierung der Workbench basieren beiderseits auf zwei verschiedenen
Toolkits.
SWT (Standard Widget Toolkit) ([SWT]) ist eine low-level Graphikbibliothek, die Standardkomponenten
für die Entwicklung einer graphischen Benutzeroberfläche zur Verfügung
stellt. Das SWT Entwicklerteam bewertet SWT wie folgt:
SWT provides efficient, portable access to the UI facilities of the OSs on
which it is implemented.
Dies unterscheidet SWT auch grundsätzlich von anderen Java-basierten graphischen
Toolkits wie AWT und Swing. SWT ist ein „thin layer“ für existierende graphische
Komponenten des Zielsystems. Wo es geht, werden native Graphikressourcen eingesetzt.
Auf der Zielplattform nicht verfügbare Komponenten werden emuliert. SWT
erlaubt den Zugriff auf native Windowssysteme über eine konsistente und portable
Java-API. SWT Anwendungen sind portabel zwischen allen Plattformen, für die es
SWT Implementierungen gibt. Dank der Nutzung nativer Betriebssystemressourcen
sind SWT Anwendungen schneller als vergleichbare Swing/AWT-Anwendungen und
bilden zum anderen das Look-and-Feel der Zielplattform inklusive anderer spezifischer
Desktop-Metaphern wie Drag-and-Drop besser ab. SWT ist nicht abhängig von
der Eclipse Plattform-Runtime, sondern kann auch als Toolkit außerhalb der Eclipse-
Plattform benutzt werden.
SWT bietet eine Vielzahl graphischer Komponenten zur Erstellung einer graphischen
Oberfläche. Dazu gehören einzelne Bedienelemente (sogenannte Widgets) genauso wie
LayoutManager. Bedienelemente stehen in Form einfacher Knöpfe und Textfelder bis
hin zu Komponenten zur Unterstützung von Datumsauswahl und -eingabe zur Verfügung.
LayoutManager dienen der Positionierung von Bedienelementen in zusammengesetzten
Elementen (Composite). Dies erleichtert den hierarchischen Aufbau von
Oberflächen. Allerdings bietet SWT über die Widgets hinaus keinerlei übergreifende
Konzepte für die graphische Repräsentation von Modellen. Der Programmierer muss
im Zuge der Realisierung einer graphischen Oberfläche mittels SWT relativ viel manuelle
Arbeit verrichten. Dies hat damit zu tun, dass SWT nur eine dünne Schicht
über die Betriebssystemressourcen legt. Für die Kopplung und Interaktion zwischen
30

Widgets kann ein Ereignismodell genutzt werden, das Aktionen des Benutzers wie
beispielsweise Mausbewegungen oder Tastatureingaben in Ereignisse umsetzt, die programmatisch
verarbeitet werden können.
Das JFace-Toolkit bietet höherwertige Abstraktionen für häufig genutzte graphische
Konstrukte und Hilfsmittel. JFace ist in seiner API und Implementierung unabhängig
vom Windowssystem des Zielsystems. Es nutzt SWT, ohne diese Benutzung zu verstecken.
JFace beinhaltet die üblichen Bestandteile eines graphischen Toolkits in Form von
Komponenten für Bild- und Fontverwaltung, Dialoge, Präferenzen und vieles mehr.
Erwähnenswert ist außerdem ein Rahmenwerk für die Erstellung von Wizards. Wizards
dienen dazu, Benutzer in Form einer Sequenz modaler Dialoge durch eine komplexe
Aktivität zu führen. Zwei andere interessante JFace-Konzepte sind Aktionen (Actions)
und Viewer.
Der Aktionsmechanismus erlaubt es, Benutzeraktionen unabhängig von ihrem konkreten
Einsatzgebiet in der graphischen Oberfläche wiederverwendbar zu kapseln. Technisch
realisiert wird dies über die Implementierung der Schnittstelle IAction. Die
Aktionslogik kommt in der Methode run() zur Ausführung. Derartig durch eine Aktion
gekapseltes Verhalten kann aus den verschiedensten Stellen der Benutzeroberfläche
zum Einsatz kommen, z.B. aus Kontextmenüs oder Werkzeugleisten heraus. Jede Aktion
verfügt als Teil des IAction-Interfaces über Eigenschaften, die ihre graphische
Repräsentation betreffen. Dazu gehören Icons, Beschriftungen, ein Tooltip und andere
Darstellungsspezifika. Somit ist es einfach, eine Aktion auszutauschen oder zu modifizieren,
selbst wenn sie an diversen Stellen der Oberfläche zum Einsatz kommt.
Viewer sind modellbasierte Adapter für bestimmte Arten von SWT Widgets. Das heißt,
dass Viewer eine Abstraktion über SWT-Komponenten wie Listen, Tabellen und Bäume
bieten und im Sinne des MVC-Paradigmas genutzt werden können. Dazu gehören
die Darstellung eines Modellelements und die Navigation über seine möglichen
Kinder, sowie die Synchronisation der Viewer mit Modellen und Änderungen an
diesen Modellen. Um dies zu erreichen, werden Viewer mit Implementierungen von
IStructuredContentProvider und ILabelProvider parametrisiert. Der
Viewer delegiert Navigation und Darstellung des aktuell dargestellten Modellelements
an diese Provider. Der für den strukturierten Inhalt des Viewers verantwortliche ContentProvider
muss außerdem Änderungen des zugrundeliegenden Modells in Updates
am Viewer übersetzen. Der LabelProvider sorgt für die graphische Repräsentation eines
Modellelements mittels textueller Beschriftung und Icon. Darüber hinaus unterstützen
Viewer als Teil ihrer Darstellungsstrategie Sortierung und Filterung von Modellelementen
über Delegation an spezielle Implementierungen von ViewerSorter
und ViewerFilter.
31

3.1.3 Workbench
Anders als SWT und JFace, die auch außerhalb der Eclipse-Plattform wiederverwendbare
Toolkits sind, macht die Workbench die Benutzeroberfläche der Eclipse-Plattform
(Eclipse Platform UI) aus. Sie gibt Strukturen vor, in deren Rahmen Benutzer mit
Werkzeugen in Interaktion treten können. Wegen ihrer zentralen Rolle ist die Workbench
synonym mit der Benutzeroberfläche der Eclipse-Plattform als Ganzem. Sie
stellt das Fenster dar, das beim Starten der Plattform angezeigt wird (siehe Abbildung
3.2). Die Workbench-Implementierung nutzt die von SWT und JFace zur Verfügung
gestellte Infrastruktur graphischer Bedienelemente.
Abbildung 3.2: Screenshot der Eclipse-Workbench
Das Eclipse-Plattform UI-Paradigma basiert auf der Anordnung von Editoren und
Views (nicht zu verwechseln mit den bereits vorgestellten SWT-Viewern) in Perspektiven.
Aus Benutzersicht besteht das Fenster der Workbench aus verschiedenen Editoren
und Views. Eine bestimmte Anordnung von Editoren und Views zur Laufzeit auf dem
Bildschirm stellt eine Perspektive dar.
Editoren dienen dem Öffnen, Editieren und Speichern von Workspace-Ressourcen.
Editoren sind mit der Workbench integriert und können die übergreifenden Menüs der
Workbench um editorspezifische Aktionen (im Sinne einer JFace-Aktion) erweitern.
Ein generischer Texteditor zur textuellen Bearbeitung beliebiger Ressourcen ist Teil
der Basisplattform. Andere Plugins erweitern die Plattform um spezifischere Editoren.
Views stellen Informationen von Ressourcen dar, die gerade in der Workbench bearbeitet
werden. Eine View unterstützt üblicherweise einen Editor, indem sie Zusatzinformationen
über die gerade im Editor geöffnete Ressource anzeigt. Abbildung 3.3 zeigt
einen Java-Editor und die OutlineView, welche die Felder und Methoden der aktuell
im Editor geöffneten Klasse anzeigen. Im Kontext eines aktiven graphischen Editors
gibt die OutlineView einen Gesamtüberblick über das aktuell im Editor geöffnete Dia-
32

Abbildung 3.3: Integration von Java-Editor und die OutlineView
gramm. Eine View kann aber auch an die aktuelle Darstellung einer anderen View
gekoppelt sein und deren Inhalt bezüglich eines anderen Aspekts visualisieren. Die
Plattform umfasst eine Menge von Standard-Views. Spezifischere Views können auch
hier als Erweiterung der Plattform durch andere Plugins integriert werden.
Abbildung 3.4: Architektur der Workbench (vgl. [Eclc])
Die technische Realisierung der Workbench in Form einer Kompositionshierarchie
ist in Abbildung 3.4 zu sehen. Die Workbench beinhaltet ein oder mehrere WorkbenchWindows.
Zu jedem WorkbenchWindow wiederum gehört genau eine Workbench-
Page 1 . Das WorkbenchWindow stellt einen Rahmen für Inhalte, sowie Fensteroperationen
bereit (Minimieren, Maximieren, Schließen). Die WorkbenchPage ist verantwortlich
für den Inhalt des Fensters. Views und Editoren gehören zu einer Page und
sind dieser über ViewFactory- und EditorManager-Indirektionsmechanismen zugeord-
1 Seit Eclipse v2, vorher konnte ein WorkbenchWindow auch mehrere WorkbenchPages besitzen
33

net. Die ViewFactory verwaltet eine Menge von Views. Der EditorManager ist neben
der Verwaltung von Editoren außerdem verantwortlich für die Verwaltung deren
gemeinsamer Ressourcen. Beiden gemein ist, dass Referenzen verwaltet werden und
nicht die Editoren oder Views selbst. Die ViewFactory hält außerdem in Form eines
Referenz-Zählers fest, Bestandteil wie vieler Perspektiven eine View ist. Perspektiven
werden mittels Layout-Informationen definiert, die bestimmen, wie Views und Editoren
in der Perspektive angeordnet werden. Perspektiven referenzieren somit also Views
und Editoren von WorkbenchPages. Der Verwaltungsmechanismus mittels Referenzen
dient der Effizienzoptimierung, da er „lazy-loading“ von Views und Editoren ermöglicht.
Abbildung 3.5: Workbench Konzepte(vgl. [Eclc])
Abbildung 3.5 illustriert den oben geschilderten Zusammenhang. Man sieht die vorgestellten
Elemente in Form ihrer graphischen Darstellung. Die graphische Hierarchie
korrespondiert weitgehend mit der Kompositionshierarchie. Ausnahme hierbei ist die
Perspektive, die man in ihrer graphischen Funktion intuitiv als Container der Views
und Editoren interpretiert, die tatsächlich aber nur eine Layout-Abstraktion darstellt.
Die graphische Darstellung der Perspektive entspricht somit nicht ihrer Rolle in der
Kompositionshierarchie.
Plugins können die Workbench um eigene Editoren und Views erweitern. Dafür sind
die Schnittstellen IEditorPart bzw. IViewPart eingerichtet, deren Implementierung
dann über einen Erweiterungspunkt der Workbench in die Plattform eingebunden
wird. Editoren und Views dienen der Darstellung von Informationen, unterscheiden
sich jedoch in ihren Benutzungs-Paradigmen. Der Hauptunterschied zwischen
Editoren und Views besteht darin, dass ein Editor der Bearbeitung einer explizit
ihm zugewiesenen Workspace-Ressource dient. Dies geschieht im Rahmen eines
Öffnen-Bearbeiten-Speichern-Schließen-Kreislaufes. Das Speichern findet hierbei zu
Benutzer-definierten Zeitpunkten statt. Ein Editor muss also in der Lage sein, die Än-
34

derungen, die an seiner geöffneten Ressource durchgeführt wurden, auch zu persistieren.
Diese Anforderung an den Editor wird als Teil der IEditorPart-Schnittstelle
in Form einer zu realisierenden save()-Methode formuliert. Die IViewPart-Schnittstelle
definiert eine solche Methode nicht. Dies hängt damit zusammen, dass Änderungen
an einer Ressource, die über eine View erfolgen, direkt an die zugrundeliegende
Datenquelle weitergeleitet werden. Im Gegensatz zum Editor, bei dem der Speichervorgang
durch eine separate Aktion des Benutzers in der Benutzeroberfläche ausgelöst
wird, werden Änderungen in Views direkt persistiert.
Ein zentrales Workbench-Konzept sind Selektionen. Diese dienen der Koordination
von Views und Editoren untereinander. Views sollen Informationen zu bestimmten
Objekten anzeigen. Welches Objekt gerade in einer View dargestellt wird, hängt in aller
Regel von den Selektionen anderer Views oder Editoren des aktuellen Workbench-
Fensters ab. Die OutlineView z.B. (vgl. Abbildung 3.3) zeigt immer die Struktursicht
derjenigen Ressource, die gerade im aktuellen Editor geöffnet ist.
Anstatt Plugins im Rahmen der Implementierung bezüglich dieses Aspekts eng zu
koppeln, wird ein sogenannter SelectionService benutzt, um die Integration von Editoren
und Views aus verschiedenen Plugins zu realisieren. Dieser Service wird benachrichtigt,
wenn sich im aktuellen Fenster der Workbench eine Selektion ändert
und gibt diese Information dann weiter an registrierte IWorkbenchPart-Instanzen
(IEditorPart und IViewPart sind Spezialisierungen von IWorkbenchPart).
Technisch umgesetzt ist dies so, dass eine WorkbenchPage einen derartigen Selection-
Service darstellt (IWorkbenchPart ist Spezialisierung von ISelectionService).
Damit verfügt jedes WorkbenchWindow über genau einen SelectionService.
Der SelectionService verfolgt die Selektionen des aktuellen WorkbenchParts und propagiert
Selektionsänderungen an registrierte Listener. Derartige Selektionsereignisse
treten auf, wenn sich die Selektion des aktuellen WorkbenchParts verändert oder wenn
ein bisher inaktives, anderes WorkbenchPart aktiviert wird. Beide Möglichkeiten können
durch Benutzerinteraktionen oder programmatisch ausgelöst werden. Für eine
View, in der ein Objekt gerade selektiert ist, ist unerheblich, welche anderen Views
an ihrer Selektion interessiert sind. Somit kann man die Plattform um neue Views erweitern,
ohne bestehenden Code anpassen zu müssen. Existierende Views, die anderen
Views Selektionen zur Verfügung stellen, bleiben also unverändert wenn neue Views
deren Selektionen nutzen.
Abbildung 3.6 illustriert den SelectionService als zentrales Konzept, das Selektionsänderungen
von sogenannten SelectionProvidern an eine Menge von sogenannten SelectionListenern
propagiert. Ein Objekt, das die ISelectionProvider-Schnittstelle
realisiert, kann als Quelle von Selektionen dienen. Damit seine Selektionen auch tatsächlich
vom SelectionService an registrierte Listener propagiert werden, muss das
Objekt in seiner Funktion als SelectionProvider bei der aktuellen WorkbenchPage
(dem SelectionService) angemeldet werden. Analog registrieren sich ISelection-
Listener-Instanzen, um über Selektionsänderungen informiert zu werden.
Aus Benutzersicht stellt eine Selektion eine Menge markierter Elementen eines gra-
35

Abbildung 3.6: SelectionService, SelectionProvider und SelectionListener (vgl.
[Eclb])
Abbildung 3.7: Typhierarchie von ISelection (vgl. [Eclb])
phischen Bedienelements, wie einer Tabelle oder eines Baumes dar. Eine Selektion
kann natürlich auch ein markiertes Textfragment eines Editors sein. Diese graphischen
Elemente sind plattformintern alle als Java-Objekte repräsentiert. Die bereits angesprochene
MVC-Implementierung von JFace unterstützt das Übersetzen zwischen diesen
beiden Repräsentationen. Die meisten JFace-Widgets implementieren standardmäßig
die ISelectionProvider-Schnittstelle und können derart direkt am Selection-
Service registriert werden.
Intern ist eine Selektion eine Datenstruktur, die aus denjenigen Modellobjekten besteht,
die mit den aktuell graphisch markierten Elementen korrespondieren. Der SelectionService
leitet ein Selektionsereignis in Form einer ISelection-Instanz an die
Interessenten dieses Ereignisses weiter. Die Eclipse-Plattform verfeinert den Selektionsbegriff
in drei ISelection-Unterkonzepte. Zum einen in IStructuredSelection,
die eine strukturierte Menge von selektierten Objekten darstellt und zum
anderen in ITextSelection und IMarkSelection, die beide Textselektionen
kapseln (Abbildung 3.7).
36

Über die hier vorgestellten Workbench-Konzepte hinaus, gibt es noch eine Reihe anderer
Mechanismen, deren Beschreibung hier allerdings den Rahmen sprengen würde.
Für eine detaillierte Beschreibung der Eclipse-Plattform und insbesondere auch der
Workbench, sei hiermit an [CR06] verwiesen.
3.2 GEF und Draw2D
Das Graphical Editing Framework (GEF) ([GEF]) ist ein Rahmenwerk für die Entwicklung
graphischer Editoren und Views in Eclipse. Die Voraussetzung für den Einsatz
von GEF ist die Existenz eines Modells, das graphisch dargestellt und/oder editiert
werden soll. Dabei stellt GEF keinerlei spezielle Voraussetzung an das zu visualisierende
Modell.
Im Rahmen dieser Diplomarbeit sind zwei Eclipse-Views als Teile der Simulationsumgebung
mit Hilfe von GEF entstanden: Erstens zur Visualisierung der statischen
internen Struktur einer NarrativeDescription (Abschnitt 5.2) und zweitens zur graphischen
Darstellung einer ExecutionModel-Instanz (Abschnitt 5.3).
Grundsätzlich folgt GEF dem MVC-Paradigma. Gemäß diesem Ansatz werden View
und Modell über einen Controllermechanismus entkoppelt. Mit View ist hierbei die
graphische Darstellung des zugrundeliegenden Modells im Sinne des MVC-Entwurfsmusters
[GHJV95] gemeint 2 . Der Controller ist dafür verantwortlich, Benutzerinteraktionen
mit graphischen Elementen in Modelloperationen und -modifikationen zu übersetzen.
Abbildung 3.8: Grobe Sicht der GEF-Architektur (vgl. [Ecle])
2 Diese View kann beispielsweise mittels Eclipse-View Mechanismus realisiert werden.
37

Abbildung 3.8 illustriert die generelle Funktionsweise von GEF (dargestellt durch die
Ellipse in der Mitte der Abbildung). Das Rahmenwerk verbindet ein Modell mit einer
graphischen Darstellung dieses Modells. Außerdem bietet es Mechanismen zur Umwandlung
von Benutzereingaben, die das Rahmenwerk in Form von SWT-Ereignissen
empfängt, in Requests. Derartige Requests werden vom Controller bearbeitet und resultieren
in Operationen auf dem Modell, die in Commands gekapselt werden.
3.2.1 Draw2D
Teil des GEF-Rahmenwerks ist ein Darstellungsplugin namens Draw2D. Draw2D
stellt sogenannte Figures und LayoutManager zur Verfügung, die die graphische Ebene
einer GEF Applikation ausmachen. Draw2D kann unabhängig von GEF benutzt
werden, ist für sich alleine genommen aber kein MVC-Rahmenwerk. Es dient rein
der graphischen Darstellung. Im Rahmen von GEF wird Draw2D zur Darstellung der
View im Sinne des MVC-Ansatzes genutzt.
Draw2D ist ein leichtgewichtiges Toolkit zur Darstellung spezieller graphischer Komponenten,
sogenannter Figures. Eine Figure ist leichtgewichtig in dem Sinne, dass sie
ein reines Java-Objekt ist und keine Repräsentation in Form einer Betriebssystem-
Ressource besitzt. Figures können via Vater-Kind-Beziehung zusammengesetzt werden
und besitzen damit eine hierarchische Struktur. Jede Figure hat eine rechteckige
Begrenzung (bounds), in deren Rahmen sie und ihre geschachtelten Kinder gezeichnet
werden. LayoutManager können eingesetzt werden, um Kinder auf besondere Art und
Weise in ihrer Vater-Figure anzuordnen.
Abbildung 3.9: Grobe Sicht der Draw2D-Architektur (vgl. [Ecld])
Draw2D baut auf der Graphikfunktionalität von SWT auf. Dies geschieht allerdings
nicht direkt, sondern mittels einer Zwischenschicht, dem zu Draw2D gehörendem
38

LightweightSystem. In SWT werden Canvas-Instanzen als Zeichenflächen für beliebige
Graphiken genutzt. LightweightSystem erweitert Canvas und stellt eine
Abstraktionsschicht dar, in der nicht mehr Widgets als Bedienelemente eingesetzt
werden, sondern Figures als Bausteine der graphischen Darstellung dienen. Dabei ist
das LightweightSystem verantwortlich für die in ihm dargestellten Figures. Außerdem
leitet es SWT-Ereignisse (die es in seiner Eigenschaft als Canvas von SWT
empfängt) an den SWTEventDispatcher weiter, der diese in Ereignisse für bestimmte
Figures übersetzt. Spezielle Ereignisse, die das LightweightSystem auffordern, seinen
Inhalt zu zeichnen, werden an den UpdateManager weitergeleitet. Dieser koordiniert
die durch ihn ausgelösten Aktionen „Zeichnen“ und „Layouten“. Wenn sich bestimmte
Eigenschaften von Figures wie Größe oder Aussehen ändern, sorgt der UpdateManager
dafür, dass nur einmal die Aktion „Layouten“ ausgeführt wird und dann im Rahmen
der Aktion „Zeichnen“ nur die Region neugezeichnet wird, die von der Änderung
betroffen ist. Abbildung 3.9 illustriert, wie die verschiedenen Draw2D-Konzepte miteinander
verknüpft sind.
Auf Klassenebene sind Figures Realisierungen der IFigure-Schnittstelle oder Spezialisierungen
der Standard-Implementierung Figure. Das Draw2D-Rahmenwerk
besitzt eine umfangreiche Klassenbibliothek, zu deren Umfang folgende Elemente gehören:
• diverse geometrische Standard-Figures (Kreis, Ellipse, Rechteck, etc.),
• Behälter-Figures, die eine Menge von transparenten Schichten (Layer) beinhalten
können,
• Figures, die als Rahmen für andere dienen (Border),
• spezielle Figures, die Verbindungen zwischen zwei anderen Figures darstellen
(Connection),
• verschiedene Anker (ConnectionAnchor), mittels derer Verbindungen an
einer Figure festgemacht werden,
• verschiedenste LayoutManager (LayoutManager) und Routing-Algorithmen
für Connections (ConnectionRouter),
• viele weitere Helferklassen, die den Umgang mit Figures erleichtern.
Als Beispiel für eine Behälter-Figure sei hier die Klasse LayeredPane genannt,
die neben einer primären Schicht noch weitere Schichten enthält. Dazu gehört z.B.
der ConnectionLayer für die Darstellung von Verbindungen (in Form von Connections)
zwischen regulären Figuren der primären Schicht und der FeedbackLayer, in
dem Effekte bestimmter Benutzeraktionen dargestellt werden (z.B. Farbänderung bei
Selektion einer Figure).
39

EditParts
Im Rahmen der Darstellung eines Modells mittels GEF wird jedes graphisch darzustellende
Modellelement durch eine Instanz einer Unterklasse von Figure repräsentiert.
Benutzerinteraktionen mit der graphischen Modelldarstellung werden von GEF
in Modellmanipulationen übersetzt. Dies geschieht mittels Controller-Mechanismus.
Zu jedem graphisch visualisierten Modellelement gibt es einen Controller. In der GEF-
Nomenklatur ist der Controller ein EditPart. EditParts verbinden Modell und die graphische
Darstellung des Modells und sind ebenso verantwortlich für die Durchführung
von Modellmodifikationen. Dafür besitzen EditParts Helferobjekte, sogenannte Edit-
Policies, die einen Großteil der Operationen auf dem Modell vornehmen.
EditParts bilden eine hierarchische Struktur. Jedes EditPart hat eine Menge von Kindern.
Normalerweise korrespondiert dies mit einer Vater-Kind Beziehung im Modell.
Beispielsweise kann ein Modell aus einem Diagramm mit Knoten bestehen. In diesem
Falle gäbe es ein Diagramm-EditPart, das Kinder in Form von Knoten-EditParts
besitzt.
Abbildung 3.10: MVC Architektur in GEF (vgl. [Ecle])
Die Vater-Kind Beziehungen der EditParts übertragen sich in die Figure-Hierarchie.
Die Figure des Vater-EditParts beinhaltet die Figures der Kinder-EditParts. Die graphische
Darstellung des Vaters kann auch durch eine zusammengesetzte Figure erfolgen,
von der eine der Teil-Figures die ausgezeichnete Rolle des ContentPane innehat. Die
Figure jedes Kindes wird dann dieser ContentPane-Figure als Kind hinzugefügt. Resultat
hiervon ist, dass es drei mehr oder weniger parallele Hierarchien gibt. Abbildung
3.10 veranschaulicht diesen Sachverhalt graphisch.
Verbindungen (Connections) zwischen zwei Figures stellen hierbei die Ausnahme dar
und sind nicht Teil der Baumstruktur. Graphische Verbindungen zwischen Figures repräsentieren
üblicherweise Assoziationen zwischen Modellelementen. Assoziationen
sind in der Regel auch durch spezielle EditParts auf Seite der Controller repräsentiert,
konkret durch Spezialisierungen des ConnectionEditParts. Auf Seiten der graphischen
Darstellung werden Verbindungen in Form spezieller Figures als Connection-Instanzen
visualisiert. Die ConnectionEditParts werden von Quell- und Ziel-
EditParts an jedem Ende verwaltet. Diese EditParts sind die Controller der Modellelemente,
die graphisch miteinander verbunden werden.
40

Die gesamten Verantwortlichkeiten eines EditParts umfassen somit:
• die Kopplung eines Modellelements an eine graphische Darstellung und die Synchronisation
zwischen graphischer Darstellung und Modell,
• die Verwaltung seiner strukturellen Eigenschaften in Form von Kind-EditParts
und ConnectionEditParts,
• die Unterstützung von Modellmodifikationen.
Das Bindeglied zwischen SWT und GEF ist ein EditPartViewer. Der EditPartViewer
dient der graphischen Darstellung von EditParts. Es wird unterschieden zwischen
zwei Arten von EditPartViewern in GEF. Zum einen gibt es einen graphischer Viewer
zur Darstellung von Figures und zum anderen einen Viewer zur Visualisierung von
Bäumen ([GEF]). Im Zusammenhang dieser Arbeit ist nur der graphische EditPart-
Viewer von Interesse, der für die Darstellung von Figures genutzt wird. Jeder Edit-
PartViewer ist außerdem SelectionProvider. EditParts sind hierbei die Selektionseinheiten,
die anderen Viewern als Selektionen zur Verfügung gestellt werden. Der graphische
EditPartViewer kapselt ein Draw2D FigureCanvas und damit gleichzeitig
das Draw2D LightweightSystem. Der Viewer selbst wird von einem WorkbenchPart
(im Regelfall ein EditorPart oder ViewPart) genutzt. Auch für den graphischen Edit-
PartViewer gibt es mehrere Spezialisierungen. Beispielsweise gibt es Viewer mit oder
ohne Scrollbalken. Wurzelelement jedes EditPartViewers ist ein spezielles EditPart,
genannt RootEditPart. Dieses hat keine Entsprechung im Modell, sondern definiert
einen gemeinsamen Kontext für die EditParts, die als Controller für bestimmte Modellelemente
dienen. GEF bietet auch hier verschiedene Standardimplementierungen, die
z.B. eingebaute Zoom-Funktionalität zur Verfügung stellen.
Abbildung 3.11: Erzeugung von EditParts mittels EditPartFactory (vgl. [Ecle])
Der Inhalt von Viewer bzw. RootEditPart ist in der Regel ein Wurzelmodellelement,
das eine Kompositionshierarchie darstellt und den graphischen Viewer mit darzustel-
41

lenden Elementen versorgt. Die EditPartFactory des Viewers ist dafür verantwortlich,
ein Modellelement in ein passendes EditPart zu übersetzen, das dann als Inhalt des
RootEditParts gesetzt wird. Die dazugehörige Figure wird zur RootFigure des Root-
EditParts hinzugefügt. Das auf diese Weise gewonnene Kind-EditPart des RootEdit-
Parts erzeugt jetzt wiederum seine Kinder-EditParts, analog zu der hierarchischen
Struktur des Modells. Die Kinder-EditParts erzeugen ihrerseits weitere Kinder- und
ConnectionEditParts, bis das gesamte Modell in Form von Controllern und Figures
aufgespannt wurde. Die Erzeugung von EditParts wird hierbei immer an die EditPart-
Factory des Viewers delegiert. Abbildung 3.11 illustriert diesen Zusammenhang.
Bisher wurde nur über die reine Darstellung eines Modells mittels Figures gesprochen,
in der zudem jedem Modellelement ein Controller in Form eines EditParts zugeordnet
ist. GEF dient aber nicht nur der graphischen Darstellung von Modellen, sondern
ebenso deren Bearbeitung. Editieren ist üblicherweise die komplexeste Tätigkeit, für
die ein EditPart verantwortlich ist. Das EditPart muss nicht nur Modelländerungen
durchführen, sondern dem Benutzer auch graphische Rückmeldungen für seine Interaktionen
mit der View geben. Benutzerinteraktionen werden von GEF in Form von
Requests (Typ Request) gekapselt, die zur Bearbeitung an ein EditPart weitergereicht
werden. Als Resultat dieser Anfrage gibt das EditPart einen Command (Klasse
Command) zurück, der Modellmodifikationen kapselt. Liefert das EditPart einen leeren
oder unausführbaren Command zurück, bedeutet das, dass die Anfrage nicht vom
EditPart bearbeitet werden kann und die aktuelle Benutzerinteraktion nicht zulässig
ist.
EditParts bearbeiten derartige Anfragen nicht selber, sondern delegieren sie an sogenannte
EditPolicies, die Strategien (im Sinne des gleichnamigen Entwurfsmusters) zur
Behandlung von Anfragen sind. Jede EditPolicy ist verantwortlich für eine Editier-
Teilaufgabe oder eine Menge von zusammengehörenden Aufgaben. Auf diese Weise
ist gemeinsames Editier-Verhalten in verschiedenen EditPart-Implementierungen wiederverwendbar.
Über die Anforderung von Commands hinaus werden Requests auch
eingesetzt, um visuelle Rückmeldungen für bestimmte Benutzerinteraktionen von einem
EditPart zu erhalten oder auch die Durchführung beliebiger Aktionen durch ein
EditPart selbst anzustoßen.
Weitere zentrale GEF-Konzepte wie Tools und Palette werden an dieser Stelle nicht
vorgestellt, weil sie für den Rahmen dieser Arbeit nicht relevant sind. Einen guten
Überblick, der über die hier vorgestellten Inhalte hinausgeht, bietet [Ecle].
3.3 Eclipse Modeling Framework
Das Eclipse Modeling Framework ([EMF, BSM + 03]) ist ein Eclipse-basiertes Rahmenwerk,
das Funktionalitäten für die Metamodell-Modellierung und zur Codegenerierung
zur Verfügung stellt. Es unterstützt die Entwicklung von Werkzeugen und Anwendungen,
die auf einem strukturierten Datenmodell basieren. Aus einer Modellspezifikation
kann EMF eine Menge von Java-Klassen generieren, die das Modell darstel-
42

len. Ebenso kann EMF andere Artefakte, die die Arbeit mit dem Modell unterstützen
und vereinfachen, erzeugen. Beispielsweise wird für jedes Metamodell automatisch
ein eigener Editor generiert, über den Modellinstanzen erstellt und bearbeitet werden
können. Modelle können mittels Java-Annotationen, XML-Dokumenten oder mit Hilfe
von Modellierungswerkzeugen wie Rational Rose ([Rat]) spezifiziert werden.
Die beiden Metamodelle, die im Rahmen dieser Arbeit entstanden sind, wurden beide
mit Hilfe des Rational Software Architect ([Rat]) in Form eines UML-Klassendiagramms
spezifiziert. EMF wurde eingesetzt für die Generierung des Modell Java-
Codes.
Der Einsatz von EMF bringt viele Vorteile mit sich:
• Verwaltung bidirektionaler Assoziationen: EMF übernimmt die Verwaltung
bidirektionaler Assoziationen zwischen zwei Metamodellelementen. Das bedeutet,
dass bei der Modifikation eines Endes einer bidirektionalen Assoziation das
jeweils andere Ende automatisch entsprechend angepasst wird. Eine manuelle
Lösung, die dies generisch umsetzt, ist aufwändig zu realisieren und deshalb
fehleranfällig.
• Notifikationsmechanismus: Ein mittels EMF generiertes Modell besitzt einen
Notifikationsmechanismus, der auf feingranulare Änderungen an Elementen einer
Modellinstanz reagiert. Damit eignen sich EMF-Modelle ideal für den Einsatz
in einer MVC-Architektur [GHJV95], in der ein Controller üblicherweise
an Veränderungen seines Modellelements interessiert ist.
• Persistierung: EMF bringt Lösungen zur Persistierung von Modellinstanzen,
zum Beispiel in Form eines XML-Dokuments, mit. Dieser Mechanismus ist einfach
erweiterbar, so dass bei Bedarf eine eigene Realisierung zur Modellserialisierung
und -persistierung eingesetzt werden kann.
• Undo/Redo-Unterstützung: EMF bietet außerdem eine Transaktionskomponente,
über deren Nutzung das Modell u.a. Undo/Redo-Funktionalitäten erlangt.
• Validierung von Modellinstanzen: Mittels dem EMF-Validationsrahmenwerk
können Modellinstanzen bezüglich ihrer Integrität geprüft werden. Darunter fallen
modellintrinsische Beschränkungen wie Kardinalitäten, aber auch explizit
im Rahmen der Entwicklung des Metamodells formulierte semantische Einschränkungen
(constraints).
EMF besteht aus drei Kernbestandteilen, die jeweils in eigenen Eclipse-Plugins enthalten
sind: EMF-Core, EMF-Edit und EMF-Codegen.
3.3.1 EMF-Core
EMF-Core beinhaltet den konzeptionellen und technischen Kern von EMF. Die Kernkonzepte
werden in einem eigenen Metamodell namens Ecore festgehalten. Dieses
43

Modell dient der Repräsentation anderer Modelle in EMF. Ecore selbst ist ein EMF-
Modell und damit sein eigenes Metamodell. Metamodelle, die mittels Ecore-Mechanismen
repräsentiert werden, heißen in der EMF-Nomenklatur Core-Modelle. Dabei
ist die Frage zu stellen, warum EMF sein eigenes Modell zur Metamodellierung benutzt
und nicht das UML-Metamodell. Dies ist zu beantworten damit, dass Ecore einem
Modellierer nur eine kleine und vereinfachte Menge aller UML-Modellierungselemente
zur Verfügung stellt. Die UML bietet beispielsweise Elemente zur Modellierung
dynamischen Verhaltens, während Ecore nur Elemente zur Modellierung einer
statischen Struktur zur Verfügung stellt.
Ecore unterstützt eine Menge von „higher-level“ Konzepten, die über die Konzepte, die
in Java repräsentierte sind, hinausgehen. Dazu gehören bidirektionale Beziehungen,
Containment-Beziehungen und spezielle Datenstrukturen wie Enumerationen 3 . EMF
generiert effizienten und korrekten Java-Code für all diese Konstrukte und erspart dem
Entwickler damit Aufwand und Zeit.
Abbildung 3.12: Typhierarchie von Ecore im Überblick
Im Rahmen der Metamodellierung werden die Strukturausprägungen für eine Menge
von Modellinstanzen des Metamodells definiert und die Typen von Objekten, die Art
der Daten, die sie beinhalten können sowie die Beziehungen zwischen ihnen, spezifiziert.
Formal geschieht dies mittels der Konzepte, die Ecore dem Modellierer an die
Hand gibt. Die Klassenhierarchie von Ecore ist Inhalt der Abbildung 3.12.
3 Seit Java 5 sind Enumerationen auch Teil der Java Language Specification ([JLS]).
44

Abbildung 3.13: Vereinfachter Ausschnitt aus dem Ecore-Modell
An dieser Stelle sollen die Kernkonzepte dieser Klassenhierarchie vorgestellt werden.
Abbildung 3.13 illustriert in Form einer vereinfachten Darstellung (bestimmte Superklassen
wurden der Übersichtlichkeit halber ausgeblendet) die Beziehungen verschiedener
Ecore-Konzepte untereinander. Beispielsweise besitzen die Klassen EClass,
EAttribute und EReference im vollständigen Ecore-Modell den gemeinsamen
Supertypen ENamedElement, der das name-Attribut, das hier für jede Klasse separat
dargestellt wurde, definiert.
Die hier vorgestellten Elemente sind:
• EClass dient der Modellierung von Klassen im Metamodell. Klassen haben
einen Namen und eine Menge beliebiger Attribute und Referenzen. Zur Unterstützung
von Vererbung kann eine Klasse eine beliebige Anzahl anderer Klassen
als Superklassen angeben 4 .
• EAttribute modelliert Attribute einer Klasse. Jedes Attribut hat einen Namen
und einen Typ.
• EDataType stellt den Typen eines Attributes dar. Es repräsentiert Typen, die
zwar in Java definiert sind, nicht aber in EMF. Jeder Datentyp besitzt ebenfalls
einen Namen.
• EReference wird benutzt zur Modellierung von Assoziationsbeziehungen zwischen
Klassen. Jede Referenz stellt ein Ende einer Assoziationsbeziehung dar.
Ähnlich wie Attribute verfügen Referenzen über je einen Namen und einen Typen.
Allerdings muss der Typ dem der EClass am jeweiligen Assoziationsende
entsprechen. Wenn die Assoziation in beide Richtungen navigierbar ist, muss es
dementsprechend zwei dazu korrespondierende Referenzen geben.
Abbildung 3.14 illustriert die vorgestellten Ecore-Elemente anhand eines Ausschnitts
aus dem ExecutionModel-Metamodell, welches als Teil des konzeptuellen Lösungsansatzes
an späterer Stelle (vgl. Abschnitt 4.2) vorgestellt wird. Transition und
4 Im Rahmen der Metamodellierung kann Mehrfachvererbung verwendet werden.
45

Abbildung 3.14: Beispiel für Metamodellierung mittels Ecore
EventExecution sind EClass-Instanzen, die als Inhalt ihres name-Attributs jeweils
„Transition“ bzw. „EventExecution“ haben. Zwischen den beiden Elementen
Transition und EventExecution gibt es zwei graphisch repräsentierte Assoziationsbeziehungen,
die jeweils in beide Richtungen navigierbar sind. Jedes der
vier resultierenden Assoziationsenden wird durch eine EReference-Instanz repräsentiert,
deren Typ jeweils EventExecution bzw. Transition ist. Darüber hinaus
sieht man, dass Transition drei Attribute in Form von EAttribute-Instanzen
mit dem Java-Typ Boolean besitzt. Man könnte diese Attribute jeweils in Form einer
EReference mit Typ EBoolean (der eine Spezialisierung von EClass darstellt)
modellieren, aber im Rahmen dieses Beispiels wurde der Attribut-Ansatz gewählt, um
den Unterschied zwischen Attributen und Referenzen zu verdeutlichen. Attribute besitzen
einen Typen, der nicht in EMF repräsentiert wird, während der Typ einer Referenz
eine Spezialisierung von EClass ist (und damit insbesondere von EMF repräsentiert
wird). Standardmäßig besitzt Ecore eine Menge von EDataType-Instanzen
(und damit EClass-Spezialisierungen), die die gebräuchlichsten Java-Typen darstellen,
darunter auch der bereits erwähnte Typ EBoolean als Repräsentation des Java-
Typs Boolean.
public interface EObject extends Notifier {
EClass eClass();
Object eGet(EStructuralFeature feature);
void eSet(EstructuralFeature feature, Object newValue);
}
...
Abbildung 3.15: Auszug aus der EObject-Schnittstelle
Außer der in Ecore festgehaltenen konzeptionellen Basis beinhaltet EMF Core eine
Java-Implementierung von Ecore. Auf Java-Ebene existiert zu jeder der Typen in Abbildung
3.12 eine korrespondierende Schnittstelle und eine Implementierung derselben.
Es gibt zum Beispiel das EObject-Interface und die EObjectImpl-Klasse als
Realisierung dieser Schnittstelle. Diese Schnittstellen und Klassen bilden die Basis für
46

den im Rahmen der Codegenerierung entstehenden Code eigener Metamodelle. Wie
bereits oben dargestellt, ist jedes Element eines Metamodells ein spezielles EObject
(vgl. Abbildung 3.12). Dieser Sachverhalt spiegelt sich ebenso im resultierenden Modellcode
wider. Der EMF-Codegenerator generiert für jedes Metamodellelement eine
Schnittstelle und eine Implementierung in Form einer Klasse, die diese und ggf. weitere
Schnittstellen realisiert. Alle generierten Schnittstellen erweitern die EObject-
Schnittstelle. Da im Metamodell durchaus auch Mehrfachvererbung erlaubt ist, wird
diese auf Java-Ebene mittels Schnittstellen nachgebildet 5 .
Die EObject-Schnittstelle kapselt EMF-spezielle Methoden, die insbesondere während
der Laufzeit genutzt werden können, um Metadaten eines Modellelements zu ermitteln.
Abbildung 3.15 stellt einen Ausschnitt dieser Schnittstelle dar. Hiermit können
statische, strukturelle Informationen abgefragt werden. Beispielsweise die EClass
des Objekts (mittels eClass()-Methode). Auch dynamische Informationen, wie z.B.
der aktuelle Wert eines bestimmten Attributs des Objekts (mittels eGet()-Methode)
lassen sich ermitteln.
3.3.2 EMF Edit
EMF Edit stellt Funktionalität zur Darstellung und Bearbeitung von Modellinstanzen
EMF-basierter Metamodelle bereit. Diese Funktionalität ist spezifisch auf das jeweilige
Metamodell zugeschnitten und wird im Rahmen der Codegenerierung des Metamodells
als separate Komponente erzeugt. Idealerweise dienen die generierten EMF
Edit-Artefakte als Ausgangspunkt für die Entwicklung einer kompletten Anwendung
um das generierte Modell herum. Das bedeutet, dass der von EMF Edit generierte
Code zur Modelldarstellung und -bearbeitung nicht nur genutzt, sondern auch modifiziert
wird. Dabei muss EMF Edit bezüglich seines Design und seiner Werkzeuge zum
einen eine gute Integration mit der Umgebung (in unserem Fall der Eclipse-Plattform)
anstreben und zum anderen größtmögliche Flexibilität erreichen, um dem Entwickler
die Erweiterung und Modifikation zu erleichtern. Zu diesem Zweck generiert EMF
Edit für jedes Metamodell standardmäßig zwei Plugins. Das eine ist das Edit-Plugin,
das UI-unabhängigen Code beinhaltet und das andere das Editor-Plugin, in dem die
UI-abhängigen Komponenten enthalten sind.
Das UI-unabhängige Plugin beinhaltet von der graphischen Benutzeroberfläche unabhängige
Abstraktionen zur Darstellung und Bearbeitung des Modells. Beispielsweise
ermöglicht das ItemProvider-Konzept die Nutzung und Bearbeitung von Modellelementen
in einer speziellen Umgebung mit Hilfe eins Adaptionsmechanismus. In EMF
nehmen Adapter grundsätzlich zwei verschiedene Rollen ein. Sie sind gleichermaßen
Beobachter wie Adapter eines Modellelements im Sinne der jeweiligen Entwurfsmuster
(vgl. [GHJV95]). In ihrer Rolle als Adapter können sie Modellelemente um die
im Rahmen von Darstellung und Bearbeitung geforderten Eigenschaften erweitern.
Als Beobachter können sie Zustandsänderungen des Modellelements weiterleiten an
registrierte Listener.
5 Java unterstützt Mehrfachvererbung nur auf abstrakter Ebene zwischen Schnittstellen.
47

Das UI-abhängige Plugin verwendet das Workbench-Rahmenwerk der Eclipse-Plattform,
inklusive JFace und SWT, um eine Benutzeroberfläche zum Erstellen und Bearbeiten
von Modellinstanzen zu realisieren. Dazu gehören unter anderem ein Wizard
zur Erstellung eines neuen Modells und ein Editor zur Bearbeitung eines existierenden
Modells.
3.3.3 EMF Codegen
Der Hauptbestandteil des EMF Codegen Plugins ist der Codegenerator von EMF. Dieser
dient der Erzeugung von Java-Code aus Core-Modellen 6 . Dazu gehören wie vorher
beschrieben für jedes Modellelement eine Schnittstelle und eine Klasse, die diese
Schnittstelle realisiert. Die Implementierung ist in der Regel nicht vollständig, da dass
Modell Operationen und abgeleitete Eigenschaften beinhaltet, deren Semantik im Rahmen
der Modellierung nicht im Detail spezifiziert wird. In derartigen Fällen generiert
der Codegenerator leere Methodenrümpfe, die vom Entwickler manuell implementiert
werden können. Jede Methode ist mit einer Metainformation versehen 7 , die aussagt, ob
die Methode generiert wurde oder nicht. Wenn der Entwickler eine Methode manuell
realisiert, ändert er diese Metainformation dementsprechend. Somit ist für den Codegenerator
ersichtlich, dass der Methodenrumpf nicht automatisch generiert wurde. Er
berücksichtigt dies in weiteren Durchläufen, indem die nicht-generierten Fragmente
übernommen und nicht überschrieben werden. Dadurch ist es möglich, Modellierung
und Implementierung zeitgleich verzahnt durchzuführen.
Die meisten Informationen, die der Codegenerator für die Codeerzeugung benötigt,
sind im Core-Modell gespeichert. Darüber hinaus müssen dem Generator aber noch
andere Informationen mitgeteilt werden, beispielsweise in welche Plugins und Java-
Pakete der Code generiert werden soll. Diese Daten sind nicht Teil des Core-Modells,
können aber vom Benutzer in Form eines sogenannten Generatormodells spezifiziert
werden. Das Generatormodell ist ebenso wie Ecore selbst ein EMF-Modell. In der Tat
ist es so, dass das Generatormodell Zugriff auf alle Daten zur Codeerzeugung bietet,
darunter auch die des Core-Modells. Aus technischer Sicht ist das Generatormodell ein
Dekorator [GHJV95] des Core-Modells. Die Klassen des Generatormodells dekorieren
Ecore Klasse, beispielsweise dient GenClass der Dekoration von EClass. Dieser
Ansatz der Trennung zwischen Core-Modell und Generatormodell gewährleistet, dass
das Core-Modell keine spezifischen Codeerzeugungsinformationen beinhaltet. Nachteil
ist, dass die Konsistenz zwischen beiden Modelle verloren gehen kann. Hierfür
gibt es Mechanismen im Generatormodell, über die das Generatormodell automatisch
an Änderungen im Core-Modell angepasst wird.
Das Eclipse Modeling Framework bietet über die hier vorgestellten Kernplugins hinaus
noch diverse weitere Komponenten. Deren Beschreibung geht ebenso wie eine detailliertere
Beschreibung der oben vorgestellten Plugins über den Umfang dieser Arbeit
hinaus. Weitergehende Informationen sind nachzulesen in [BP06, BSM + 03].
6 Ein mittels Ecore-Mechanismen repräsentiertes Metamodell ist ein Core-Modell.
7 Dies geschieht in Form einer Annotation im Javadoc-Header der Methode.
48

3.4 ViPER
ViPER (Visual Tooling Platform for Model-Based Engineering) [ViP] ist eine Eclipsebasierte
Entwicklungsumgebung für den UML-basierten Entwurf kleiner eingebetteter
Systeme. Sie wird derzeit am Lehr- und Forschungsgebiet Informatik 3 der RWTH
Aachen als Forschungsprototyp entwickelt. Zu ihren Bestandteilen gehören UML-
Modelldiagrammeditoren, C-Code Generatoren, ein Toolkit zur natürlichsprachlichen
Beschreibung von Anwendungsfällen sowie die Unterstützung der MeDUSA-Methode,
die ebenfalls am Lehr- und Forschungsgebiet Informatik 3 entwickelt wird. Außer
der Eclipse-Plattform bilden die folgenden weiteren Eclipse Projekte die technische
Grundlage von ViPER:
• Eclipse C/C++ Development Environment (CDT)
• Eclipse Modeling Framework (EMF)
• Eclipse Modeling Framework Technologies (EMFT)
• Eclipse Model Development Tools (MDT)
• Eclipse Graphical Editing Framework (GEF)
• Eclipse Generative Modeling Technologies (GMT)
• Apache Commons Logging
Diese Bestandteile machen zusammen die ViPER-IDE aus:
• ViPER Platform
• ViPER UML2
• ViPER MeDUSA
• ViPER NaUTiluS
Sie werden im Folgenden kurz erläutert.
3.4.1 ViPER Platform
ViPER Platform bildet die Basis der ViPER-IDE. Sie stellt ein offenes Rahmenwerk
zur Implementierung von GEF-basierten graphischen Editoren für EMF-basierte Modelle
dar. Zum weiteren Funktionsumfang gehören Mechanismen für Modelltransformationen
(Modell-zu-Modell, Modell-zu-Code und Modell-zu-Text) und zur Validierung
von Modellen.
49

ViPER Platform ist weiter untergliedert in Bestandteile, die diese einzelnen Funktionalitäten
kapseln:
• ViPER Core
• ViPER MTF
• ViPER VMF
ViPER Core enthält Basiskomponenten für die Arbeit mit EMF-basierten Modellen.
Dies beinhaltet Konstrukte zur deklarativen Spezifikation von Modellmanipulationen,
sowie Konstrukte zur Unterstützung und Vereinfachung der Navigation auf EMF-basierten
Modellen. Außerdem gehören diverse ViPER-spezifische Basisklassen für graphische
Elemente wie Wizards oder Kontextmenüs (GUI-Bestandteile im Allgemeinen) zum
Kern von ViPER.
ViPER MTF (Model Transformation Framework) ist ein Rahmenwerk, das dem Entwickler
Basisinfrastruktur zur Transformation und Validierung von Modellen zur Verfügung
stellt. Unter die Modelltransformationen fallen sowohl Modell-zu-Modell Transformationen
als auch die Codegenerierung aus Modellen.
ViPER VMF (Visual Modeling Framework) kapselt Konstrukte und Erweiterungsmöglichkeiten,
die der Implementierung GEF-basierter Editoren für EMF-basierte Modelle
dienen. VMF ist vom konzeptionellen Umfang her die größte Einzelkomponente der
ViPER-IDE. Sie ist intern weiter unterteilt in die folgenden Bestandteile:
• ViPER VMF Core
• ViPER VMF GraphModel
• ViPER VMF MCD
• ViPER VMF UI
• ViPER VMF UI Extensible
Für diese Arbeit stellt ViPER VMF allerdings keinen Schwerpunkt dar. Aus diesem
Grund wird an dieser Stelle auf eine detaillierte Beschreibung der Einzelkomponenten
verzichtet. [Wal07, Do08] stellen die einzelnen VMF-Bestandteile in ihren Arbeiten
ausführlicher vor.
3.4.2 ViPER UML2
ViPER UML2 baut auf den Basiskomponenten von ViPER Platform auf und bietet eine
UML2-Entwicklungsumgebung mit graphischen Editoren für alle gängigen UML2-
Diagrammtypen.
50

Intern besteht es aus den folgenden drei großen Bestandteilen:
• ViPER UML2 Core stellt grundlegende Bausteine einer UML-Entwicklungsumgebung
zur Verfügung. Dazu gehören beispielsweise diverse UML-spezifische Klassen
sowie eine Reihe von Wizards, die der Erzeugung von UML-Modellen dienen.
• ViPER UML2 Codegen enthält die Implementierung eines Codegenerators auf
Basis von ViPER MTF. Dieser Generator dient der Erzeugung von C-Code aus
UML2-Modellen.
• ViPER UML2 VME (Visual Modeling Environment) stellt die Referenzimplementierung
einer graphischen Modellierungsumgebung auf Basis des ViPER
VMF Rahmenwerks dar. Im Rahmen dieser Referenzimplementierung sind bislang
zehn der insgesamt 13 UML2-Diagrammtypen entstanden.
3.4.3 ViPER MeDUSA
ViPER MeDUSA (Method for UML2-based Design of Embedded Software Applications)
ist eine Design-Methode für die Erstellung von Software-Anwendungen eingebetteter
Systeme [LN07]. Die MeDUSA Methode beruht auf Ansätzen der COMET-
Methode [Gom00] und stellt die Use Case- und modellgetriebene Entwicklung in den
Vordergrund. ViPER MeDUSA enthält prototypische Grundsteine für die methodengestützte
Entwicklung mit MeDUSA in Form eines Wizards für die Subsystem Identification.
Die Subsystem Identification ist eine Teilaktivität des MeDUSA-Prozesses. Die
Durchführung des Gesamtprozesses als Folge von Teilaktivitäten basiert technisch auf
CheatSheets. CheatSheets sind ein Eclipse-spezifisches Konzept, das der Durchführung
von Abläufen dient. Außerdem beinhaltet ViPER MeDUSA eine in das Eclipse-
Hilfesystem integrierte Prozessbeschreibung. [Her07, LN07] beschreiben den zu diesem
Zeitpunkt aktuellen Stand und Inhalt von ViPER MeDUSA im Detail.
3.4.4 ViPER NaUTiluS
ViPER NaUTiluS (Narrative Use Case Description Toolkit for Evaluation and Simulation)
umfasst in seiner Form als Toolkit für die natürlichsprachliche Beschreibung
von Anwendungsfällen mehrere Komponenten. Hierzu gehören bislang Funktionalitäten
zum Editieren natürlichsprachlicher Anwendungsfallbeschreibungen sowie zur
Simulation derselben. Die Simulationskomponente ist im Rahmen dieser Arbeit entstanden.
Der Grundstein für die Funktionalitäten zum Erstellen und Bearbeiten von
Anwendungsfallbeschreibungen wurde im Zuge von [Wal07] gelegt. Über die bereits
bestehenden Komponenten hinaus ist für die Zukunft außerdem die Unterstützung der
Evaluierung von Anwendungsfallbeschreibungen geplant.
ViPER NaUTiluS setzt sich grob zusammen aus den folgenden zwei Teilkomponenten:
51

• ViPER NaUTiluS Core
• ViPER NaUTiluS Simulation
NaUTiluS Core wiederum besteht intern aus einer Menge von Plugins, die verschiedene
Inhalte kapseln:
Abbildung 3.16: Screenshot der NarrativeModel-Perspektive
• sc.viper.nautilus.core.resources umfasst Metamodelle und
UML-Profile für die Verwendung mit Instanzen dieser Modelle. Konkret sind
das die Metamodelle von NarrativeModel, ExecutionModel und SimulationModel
8 . Sie werden referenziert von den Generatormodellen (siehe Abschnitt 3.3)
der jeweiligen Modellplugins.
• sc.viper.nautilus.core.executionmodel ist im Zuge dieser Arbeit
entstanden und beinhaltet den mittels EMF generierten Code des Execution-
Models sowie das Generatormodell, welches die EMF-Codegenerierung steuert.
Bestimmte Methoden der Implementierungsklassen wurden nachträglich manuell
implementiert. Außerdem beinhaltet dieses Plugin die Klassenbibliothek zur
Berechnung einer ExecutionModel-Instanz zu einer gegebenen NarrativeModel-
Instanz. Die Arbeitsweise und die technische Realisierung dieser Komponente
werden ausführlich thematisiert in Abschnitt 5.1.
8 ExecutionModel und SimulationModel werden als Teil des konzeptuellen Lösungsansatzes dieser
Arbeit in Kapitel 4 eingeführt.
52

• sc.viper.nautilus.core.narrativemodel kapselt Schnittstellen
und Implementierungsklassen des NarrativeModels. Der Großteil dieses Codes
wurde mit Hilfe von EMF aus der Spezifikation des NarrativeModels generiert.
• sc.viper.nautilus.core.ui.editors beinhaltet einen Editor zur Bearbeitung
von NarrativeModel-Instanzen. Dieser Editor hat seinen Ursprung in
der Arbeit von Andreas Walter [Wal07] und wurde seitdem am Lehrstuhl weiterentwickelt.
Der ehemals monolithische Editor, der die verschiedenen Facetten
der NarrativeModel-Editierung abgedeckt hat (Synchronisation mit Use Case-
Modell, Bearbeitung von NarrativeDescriptions, Bearbeitung von Flüssen), wurde
zerlegt in einen Editor zur Bearbeitung je einer NarrativeDescription und ihrer
Flüsse und eine Menge unterstützender Views. Diese Aufteilung folgt dem
Eclipse UI-Paradigma, wie es in Abschnitt 3.1.3 vorgestellt wurde. Der Screenshot
in Abbildung 3.16 illustriert diesen Sachverhalt anhand der Perspektive zur
Bearbeitung eines NarrativeModels. Oben links erkennt man die ModelView, die
eine modellzentrische Sicht auf den Eclipse Benutzerarbeitsplatz (Workspace)
bietet und es ermöglicht, die interne hierarchische Struktur eines Modells unterhalb
der Dateisystemebene zu navigieren. Die ModelView dient als SelectionProvider
und stellt anderen WorkbenchParts beliebige Modellelemente des
aktuell geöffneten Modells zur Verfügung. Unterhalb der ModelView sieht man
die FlowView und die OutlineView, die einen Überblick über die interne Struktur
einer NarrativeDescription bzw. des zugrundeliegenden Use Case-Modells
bieten. Zentral in der Mitte der Abbildung befindet sich der NarrativeDescriptionEditor,
der als SelectionListener diejenigen NarrativeDescriptions zur Bearbeitung
anzeigt, die ihm von der ModelView zur Verfügung gestellt werden.
Oberhalb des Editors ist die UseCaseNarrativeSyncView platziert, die darüber
informiert, welche Elemente des Use Case-Modells durch Elemente des NarrativeModels
repräsentiert werden. Unterhalb des Editors dargestellt ist die Eclipseeigene
PropertiesView, die die Eigenschaften eines jeden selektierten Elements
der Workbench anzeigt.
NaUTiluS Simulation umfasst zwei Plugins, die beide als Ergebnis dieser Arbeit entstanden
sind:
• sc.viper.nautilus.simulation.simulationmodel kapselt die
EMF-Implementierung des SimulationModels und das zugrundeliegende Generatormodell.
• sc.viper.nautilus.simulation.ui beinhaltet graphische Komponenten,
die der Darstellung und Bearbeitung des SimulationModels dienen. Dazu
gehören neben einem Editor, der der Aufzeichnung des Simulationsablaufs
dient, eine View zur graphischen Darstellung einer ExecutionModel-Instanz (vgl.
Abschnitt 5).
53

Kapitel 4
Konzeptueller Lösungsansatz
Zu Beginn dieses Kapitels wird eine Ausführungssicht auf eine NarrativeModel-Instanz
beschrieben. Diese motiviert die Bildung eines speziellen Metamodells, das im zweiten
Abschnitt dieses Kapitels erläutert wird. Im letzten Teil dieses Kapitels wird schließlich
ein weiteres Metamodell vorgestellt, welches simulationsspezifische Konzepte
kapselt.
4.1 Ausführungssicht auf eine NarrativeModel-Instanz
Im Zuge der simulierten Ausführung eines Anwendungsfalles löst man sich von der
gesamtheitlichen Sicht auf diesen Anwendungsfall und interessiert sich nur noch für
einzelne Szenarien. Jeder Anwendungsfall besteht aus einer Menge von Verhaltensausprägungen,
die in seiner zugehörigen NarrativeDescription als Flüsse und Beziehungen
zwischen Flüssen modelliert werden. Diese Verhaltensausprägungen kommen
dann während der Ausführung zustande durch die vielfältigen Pfade vom Anfang des
Anwendungsfalles zu seinem Ende. Ein Szenario ist demnach ein bestimmter solcher
Pfad und beschreibt eine komplette Benutzerinteraktion mit dem modellierten System
als Sequenz von Ereignissen (Events des NarrativeModels). Inklusionen und Erweiterungsanker
werden aufgelöst und durch Aktionssequenzen der durch sie ausgelösten
Verhaltensausführung dargestellt.
Wendet man diesen Ansatz nicht nur auf ein einzelnes Szenario sondern auf ein vollständige
NarrativeModel-Instanz an, erhält man eine ausführungsorientierte Sicht auf
diese.
Jede NarrativeModel-Instanz spannt bezogen auf diese Sicht einen Ausführungsgraphen
auf. Dessen Knoten werden dargestellt durch die atomaren Verhaltensatome (also
Aktionen) der Flüsse. Die Kanten zwischen Knoten bilden dann intuitiv die Übergänge
zwischen Aktionen. Diese Übergänge sind nicht explizit als Elemente des Narrative-
Models modelliert, sondern folgen aus der Semantik der Flüsse und ihrer Beziehungen
55

untereinander. Man betrachtet also nur Aktionen auf der feinsten Verhaltensebene. Use
Cases, NarrativeDescriptions und Flüsse haben im Ausführungsgraphen keine explizite
Darstellung, sondern werden in der Ausführung implizit durchlaufen, abhängig davon,
in welchem Fluss die aktuell ausgeführte Aktion definiert wurde. Ein Pfad durch
den Graphen von der ersten bis zur letzten Aktion eines Anwendungsfalles beschreibt
dann jeweils ein Szenario als Sequenz von Aktionen.
Die Kanten des Graphen geben an, welche anderen Aktionen von einer bestimmten
Aktion aus in einem Schritt erreichbar sind. Der einfachste Fall, in dem eine Aktion B
in einem Schritt erreichbar von A ist, liegt vor, wenn beide Aktionen in der Verhaltenssequenz
desselben Flusses hintereinander definiert sind. Eine andere Möglichkeit liegt
vor, wenn direkt hinter A eine Inklusion eines Flusses oder eine Erweiterung durch
einen Fluss stattfindet, dessen erste Aktion B ist. Das erste Ereignis eines Ausnahmeflusses
ist erreichbar von jeder Aktion der überwachten Flüsse aus.
Verzweigungsmöglichkeiten, also Knoten mit mehreren ausgehenden Kanten, in diesem
Graphen entstehen als Resultat von Ausnahmeflüssen und Erweiterungsbeziehungen
zwischen Flüssen. Während der Ausführung gibt es an den Erweiterungsankern
die Möglichkeit zu alternativem Verhalten zu verzweigen. Außerdem werden nach
Ausführung einer jeden Aktion die Bedingungen der anliegenden Ausnahmeflüsse
evaluiert. Abhängig von den Resultaten dieser Prüfung wird dann der entsprechende
Ausnahmefluss aktiv.
Eine Modellinstanz ohne Elemente, die Verzweigungmöglichkeiten induzieren, besitzt
keinerlei Verhaltensausprägungen, die über den Standardablauf hinausgehen. Der Anwendungsfall
beschreibt dann genau ein Szenario. Während der Ausführung gibt es
keinerlei Entscheidungspunkte, an denen sich Verhalten verzweigen kann.
Zur graphischen Darstellung eines solchen Graphen bieten sich Aktivitätsdiagramme
an. Laut UML-Spezifikation [Obj07b] dienen Aktivitäten zum einen der Modellierung
von Sequenzen von „lower-level“ Verhalten und zum anderen der Bedingungen zur
Steuerung dieses Verhaltens. Jede Aktivität besteht aus einer Menge von Aktionen,
die in ihrer Sequenz während der Ausführung das Verhalten der Aktivität darstellen.
Es liegt damit nahe, die oben beschriebene Sicht auf eine textuelle Anwendungsfallbeschreibung
durch ein Aktivitätsdiagramm darzustellen. Dabei stellt die Aktivität die
durch den auszuführenden Anwendungsfall beschriebene Benutzerinteraktion als Ganzes
dar. Die Aktionen der Aktivität entsprechen den einzelnen Verhaltensatomen der
Benutzerinteraktion. Diese wiederum werden repräsentiert durch Aktionen derjenigen
Flüsse, die im Rahmen der Ausführung des ursprünglichen Anwendungsfalles erreichbar
sind.
Abbildung 4.1 zeigt eine derartige Sicht auf die textuelle Beschreibung der Anwendungsfälle
des Geldautomatenbeispiels aus Abschnitt 2.3. Die Ausführung des Anwendungsfalles
Geld abheben ist hierbei die Gesamtaktivität. Diese besteht aus Aktionen
(Action in der UML), die den Aktionen (Action des NarrativeModels)
der verschiedenen Flüsse des NarrativeModels entsprechen. Use Case-Start und Use
Case-Ende sind hierbei durch die entsprechenden InitialState- und ActivityFinalState-
56

Abbildung 4.1: Aktivitätsdiagramm zum Geldautomatenbeispiel
Knoten des Aktivitätsdiagramms gesondert ausgezeichnet. Man beachte, dass man im
Rahmen der graphische Darstellung die inkludierten und erweiternden Verhaltenssequenzen
auch als strukturierte Aktionen darstellen kann (d.h. aus Sicht der Geld abheben-Aktivität
ist die Ausführung von Authentifizieren atomar). Zur Veranschaulichung
der Ausführungssicht ist die in Abbildung 4.1 gewählte Darstellung allerdings besser
geeignet.
4.2 ExecutionModel
Als Grundlage für die technische Umsetzung der Simulation, bietet es sich an, die
oben geschilderte Ausführungssicht auf eine NarrativeModel-Instanz in einem eigenen
Metamodell festzuhalten. Die Besonderheit der Ausführungssicht ist, dass die Strukturinformationen
des NarrativeModels aufgelöst werden und eine atomare Sicht auf
einzelne Ausführungsschritte in Form von Aktionen eingenommen wird. Die anderen
Ereignisarten wie Inklusionen und Erweiterungsanker werden aufgelöst zu Sequenzen
von Aktionen.
Die Ausführungssicht ist konzeptionell verschieden von der NarrativeModel-Sicht.
Ziel der Modellierung von textuellen Anforderungsbeschreibungen ist es, Verhalten
in den dafür vorgesehenen Strukturen zu beschreiben. Diesem Ansatz liegen bereits
gewisse Modellierungsprinzipien zugrunde, z.B. das Prinzip des Erzielens höchstmöglicher
Wiederverwendung von Verhalten. Die Ausführungssicht löst diese Abstraktio-
57

nen wieder auf und bricht sie hinunter auf Sequenzen von möglichen „lower-level“
Aktionen. Damit ist die Ausführungssicht konzeptionell anders als diejenige Sicht, die
während des Modellierens des NarrativeModels eingenommen wird.
Das ExecutionModel ist das Metamodell, welches der Repräsentation der Verhaltenssicht
auf das NarrativeModel dient. Zu jeder NarrativeModel-Instanz kann eine ExecutionModel-Instanz
generiert werden. Diese ist dann die Grundlage für die Simulation.
4.2.1 Zentrale Elemente
Das ExecutionModel hat zwei zentrale Konzepte, die sich aus der ausführungsorientierten
Darstellung eines NarrativeModels als Graph ergeben. Die Knoten des Graphen
stellen Verhaltensatome dar, die Kanten zwischen den Knoten die Übergänge von einem
Verhaltensatom zum anderen. Dieser Sachverhalt wird im ExecutionModel durch
die zwei Konzepte EventExecution und Transition abgebildet. EventExecutions
entsprechen den Knoten des Graphen und kapseln die simulierte Ausführung
von Events des NarrativeModels. Transitionen stellen die Kanten des Graphen dar und
modellieren damit die Übergänge zwischen je zwei EventExecutions.
Abbildung 4.2: Grobe Struktur des ExecutionModels
Inhalt der Abbildung 4.2 sind die beiden Metaklassen EventExecution und Transition.
Jede EventExecution referenziert genau ein Event des NarrativeModels.
Dabei kann ein Event selbst durchaus durch mehrere EventExecutions referenziert
werden. Man sieht außerdem, dass eine EventExecution immer eine oder mehrere
Vorgänger- und Nachfolger-Transitionen besitzt. Jede Transition wiederum hat genau
eine oder keine Vorgänger- und Nachfolger-EventExecution. Eine Transition besitzt
keinen Vorgänger bzw. Nachfolger, wenn sie in das Modell hinein- bzw. aus dem Modell
heraus führt (Use Case-Start, Use Case-Ende). Die Metaklasse Step stellt eine
Generalisierung von EventExecution und Transition dar und beschreibt, dass
sowohl EventExecutions als auch Transitionen einen Ausführungsschritt darstellen.
58

EventExecutions und ExecutionContexts
In Abbildung 4.2 sieht man außerdem die zu Transitionen und EventExecutions gehörenden
Konzepte ExecutionContextChange und ExecutionContext. Jede
EventExecution besitzt einen ExecutionContext, der den aktuellen Ausführungskontext
charakterisiert. Der Ausführungskontext beinhaltet eine Liste aller NarrativeDescriptions
und Flusskontexte (Context aus NarrativeModel), die bis zum Erreichen
des durch die aktuelle EventExecution dargestellten Ereignisses durchlaufen wurden.
Mehrere EventExecutions haben denselben ExecutionContext, wenn zum einen ihre
referenzierten Ereignisse als Teil der Verhaltenssequenz des selben Flusses definiert
wurden und zum anderen dieser Fluss während der Ausführung jeweils auf dem selben
Weg erreicht wurde (d.h., über die selbe Folge von Transitionen und EventExecutions).
Abbildung 4.3: Event repräsentiert
von zwei EventExecutions
Abbildung 4.4: Reduzierende
Kontextwechsel
Abbildung 4.3 zeigt die Situation, dass ein Fluss F2 aus einem Fluss F1 von zwei
verschiedenen Positionen aus inkludiert wird. In diesem Fall besitzt das dazugehörige
ExecutionModel zwei Entsprechungen in Form von EventExecutions für das Ereignis
A in Fluss F2. Es ist wichtig, zwischen Ereignissen, die auf verschiedenen Wegen erreichbar
sind, zu unterscheiden, weil die Rücksprungspunkte aus einem inkludierten
oder erweiternden Fluss zurück in den Ursprungsfluss abhängig sind von den Punkten,
aus denen das Zusatzverhalten ursprünglich zur Ausführung kam. Die beiden Event-
Executions, die A darstellen, haben jeweils auch verschiedene Ausführungskontexte.
Transitionen und ExecutionContextChanges
Transitionen koppeln zwei EventExecutions und können bezogen auf den Übergang
von einer zur anderen EventExecution einen Kontextwechsel (Metaklasse ExecutionContextChange)
induzieren. In diesem Fall sind beide über die Transition
gekoppelten EventExecutions mit unterschiedlichen ExecutionContexts assoziiert. Induziert
eine Transition keinen Kontextwechsel, ist sie eine diesbezüglich invariante
Transition. Ein Kontextwechsel kann expandierend sein, d.h., die Liste der Flusskontexte
vergrößert sich vom ExecutionContext der Vorgänger-EventExecution zu dem
59

der Nachfolger-EventExecution. Anders ausgedrückt, wird durch eine expandierende
Transition ein neuer Fluss betreten. Das Gegenteil ist die reduzierende Transition,
durch die ein Fluss verlassen wird und die die Ausführung zu dem ursprünglichen
Vorgängerfluss zurückkehren lässt. Eine Transition heißt also reduzierend, wenn sie
ein oder mehrere reduzierende Kontextwechsel induziert.
Die Abbildung 4.4 illustriert, in welchem Fall eine Transition mehrere reduzierende
Kontextwechsel zur Folge hat. Dargestellt ist die Situation, in der der Fluss F1 an der
Position I1 den Fluss F2 inkludiert. Dieser wiederum inkludiert von I2 aus den Fluss
F3. Der Fluss F3 führt nur die Aktion A aus. Der Nachfolger der A-EventExecution 1
ist in diesem Fall die B-EventExecution 2 innerhalb F1. Wäre die Inklusion I2 in F2
nicht an letzter Position in der Verhaltenssequenz, hätte die B-EventExecution einen
Nachfolger in F2. Die Transition, die den Übergang von B-EventExecution zu A-
EventExecution darstellt, induziert somit zwei reduzierende Kontextwechsel. Der Verlauf
des Kontrollflusses durch die Flüsse ist in der Abbildung mittels gestrichelter Linie
kenntlich gemacht.
Abbildung 4.5: Verfeinerung der ExecutionContextChange-Metaklasse
Die abstrakte ExecutionContextChange-Metaklasse wird bezüglich ihrer Eigenschaft,
die eine Ausführungskontextreduktion oder -expansion bewirkt, in ExecutionContextExpansion
oder ExecutionContextReduction spezialisiert
(siehe Abbildung 4.5).
ExecutionContextExpansion hat ein Attribut namens trigger, welches eine
Referenz auf ein Event-Element des NarrativeModels darstellt. Dies wird in Fällen
benötigt, in denen ein Fluss an verschiedenen Stellen denselben anderen Fluss inkludiert
oder von demselben anderen Fluss erweitert wird. In diesen Fällen sind all diese
Inklusionen oder Erweiterungsanker mit demselben Kontext (Context des NarrativeModels)
des inkludierten oder erweiternden Flusses verbunden. Daher hält man
den trigger als Zusatzinformation in Form desjenigen Ereignisses, das die expandierende
Transition ausgelöst hat, fest. Somit kann man unterscheiden, ob der inkludier-
1 die EventExecution, die die Ausführung von A darstellt
2 die EventExecution, die die Ausführung von B darstellt
60

te oder erweiternde Fluss auf verschiedenen Wegen erreicht wurde. Im Falle einer
Erweiterung ist der trigger also ein ExtensionAnchor, im Falle einer Inklusion
eine Inclusion. Auch bei expandierenden Transitionen, die in einen Ausnahmefluss
führen, greift dieser Mechanismus. Der trigger ist dann eine Action. Ohne die
trigger-Zusatzinformation wären beispielsweise die Inklusionen I1 und I2 in Abbildung
4.3 bezüglich ihrer induzierten Kontextwechsel nicht unterscheidbar, da beide
auf NarrativeModel-Ebene denselben Übergang vom Kontext des Flusses F1 in den
Kontext des Flusses F2 bewirken.
Analog zum trigger-Attribut in ExecutionContextExpansion besitzt ExecutionContextReduction
ein mergeEvent-Attribut. Dieses ist ebenfalls eine Referenz
auf eine Event-Instanz und wird benötigt, um eindeutig die Rücksprungsbedingung
zu bestimmten, unter der eine Transition stattfindet.
4.2.2 Transitionstypen
Abbildung 4.6: Eigenschaften der Transition-Metaklasse
Wie bereits beschrieben spricht man von einer kontextinvarianten Transition, wenn
sie den Übergang zwischen zwei EventExecutions desselben Ausführungskontexts bewirkt.
Damit findet aus Sicht der NarrativeModel-Struktur (mit den Strukturelementen
Model, NarrativeDescription, Flow, Event) insbesondere auch nur ein Übergang
zwischen zwei Ereignissen eines Flusses statt. Expandierende Transitionen können in
diesem Sinne aber auch Übergange zwischen Ereignissen verschiedener Flüsse oder
gar zwischen verschiedenen Flüssen in verschiedenen NarrativeDescriptions bewirken.
Transitionen, über die ein Anwendungsfall gestartet oder beendet wird, über-
61

schreiten sogar die Modellgrenze. Die Information, welche Art von Übergang durch
eine Transition induziert wird, steckt in der TransitionType-Enumeration (Abbildung
4.6). Jede Transition bewirkt einen Übergang einer der vier Arten (Event, Flow,
Description, Model). Klar ist, dass eine Model-Transition gleichzeitig eine Description-Transition
ist und die wiederum eine Flow-Transition. Übergänge aller Art sind
Event-Transitionen.
Außerdem wird bei Transitionen unterschieden danach, ob sie Modellvariationen oder
semantische Variationen darstellen. Im Falle der Modellvariationen wird zudem weiter
differenziert nach ihrer Art. Variationspunkte sind Stellen im ExecutionModel, an
denen sich der Kontrollfluss verzweigen kann. Jede EventExecution, die mehr als eine
nachfolgende Transition besitzt, induziert somit einen Variationspunkt. Diese Punkte
kommen zustande als Resultat von Erweiterungen und Ausnahmeflüssen, die vom
Standardablauf abweichende Verhaltensalternativen anbieten. Verzweigungsmöglichkeiten,
die über eben diese modellintrinsischen Beziehungen wie Erweiterung und
Ausnahmebehandlung zustande kommen, sind Modellvariationen. Im Gegensatz dazu
resultieren semantische Variationen nicht aus Elementen des NarrativeModels. Semantische
Variationen sind Gegenstand der Behandlung des folgenden Abschnitts.
Ob eine Transition eine Modellvariation oder eine semantische Variation darstellt,
kann über die isSemanticVariation-Eigenschaft von Transition ermittelt werden.
Im Falle der Modellvariation ist die Frage nach dem zugrundeliegenden NarrativeModel-Konzept
von Interesse. Hier bestehen die Möglichkeiten der Extension und der Exception,
die in ModelVariationType festgehalten werden (siehe Abbildung 4.6).
Invariante Transitionen stellen grundsätzlich Modellvariationen vom Typen None dar.
4.2.3 Semantische Variationen
Abbildung 4.7: Semantische Variation durch Inklusion abstrakten Verhaltens
62

An semantischen Variationspunkten stehen Verzweigungsmöglichkeiten zur Auswahl,
die nicht durch NarrativeModel-intrinsische Semantik (also Erweiterungen und Ausnahmen),
sondern durch andere Ursachen bedingt sind. Abbildung 4.7 illustriert dies
an einem Beispiel: der Akteur Actor1 ist primärer Akteur des abstrakten Use Cases
Entry. Entry definiert abstraktes Verhalten, das nicht ausgeführt werden kann. Allerdings
gibt es hier drei Spezialisierungen des Entry Use Cases, die allesamt konkret und
damit ausführbar sind: Use Case 1, Use Case 2 und Use Case 3. An dieser Stelle liegt
ein semantischer Variationspunkt vor. Das Modell ist ausführbar, da es ein oder mehrere
konkrete Spezialisierungen von Entry gibt. Tatsächlich kann aber nur eine der drei
gegebenen konkreten Use Cases zur Ausführung kommen. Die drei Start-Transitionen,
die in die verschiedenen Use Cases hineinführen, sind also Alternativen und jede für
sich eine mögliche semantische Variation. Die Situation, dass abstraktes Verhalten zur
Ausführung kommt, ist natürlich nicht auf dieses Szenario beschränkt. Auch Inklusionen
abstrakter Anwendungsfälle, Erweiterungen durch abstrakte Use Cases und abstrakte
Ausnahmeflüsse sind vorstellbar. Solange es mindestens eine Konkretisierung
eines abstrakten Anwendungsfalles gibt, stellt dies allerdings aus Sicht des Execution-
Models kein Problem dar.
Allerdings sind semantische Variationen insofern problematisch, als dass sie konzeptionell
kein Alternativverhalten im ursprünglichen Sinne darstellen. Die Wahl einer
Alternative ist nicht an bestimmte modellintrinsische Bedingungen gekoppelt, sondern
resultiert aus einer anderen Ebene der Modellierung. Fraglich ist zudem, zu welchem
Zeitpunkt die Auswahl einer konkreten Verhaltensalternative erfolgen soll.
Es spricht einiges dafür, semantische Variationspunkte bereits vor der Durchführung
der Simulation aufzulösen, indem man für jedes ursprünglich abstrakte Verhalten eine
konkrete Alternative „bindet“. In diesem Sinne eliminiert man jegliches abstraktes
Verhalten und erhält eine Instanz des Ausgangsmodells, die ausschließlich konkretes
Verhalten beschreibt. Folgt man diesem Ansatz, kann problemlos mit Abhängigkeiten
zwischen mehreren Variationspunkten umgegangen werden. Die Entscheidung für eine
Alternative an einem Variationspunkt bedingt möglicherweise die Auswahl einer
bestimmten Lösung an einem anderen Variationspunkt. Diese Semantik geht verloren,
wenn man die semantische Variation erst im Zuge der Simulationsausführung auflöst.
In diesem Kontext stellt sich eine weitere Frage. Wenn im Laufe der Simulationsausführung
ohne Auflösung der Variation im Vorfeld, ein semantischer Variationspunkt
mehrfach erreicht wird; darf der Benutzer eine andere, als die im ersten Durchlauf
gewählte Alternative, für die Fortsetzung der Simulation wählen?
Zu diesem Zeitpunkt sind die hier aufgeworfenen Fragen noch nicht befriedigend und
umfassend beantwortet. Vermutlich wird das ExecutionModel künftig noch um eine
Menge möglicher Bindings zu erweitern sein. Ein Binding ordnet dann jedem semantischen
Variationspunkt eine Transition aus der Menge der zu diesem Punkt gehörenden
Transitionen zu. Vor Ausführung der Simulation muss dann ein konkretes Binding gewählt
werden, auf dessen Grundlage die Simulation durchgeführt wird. Ein aktiviertes
Binding schränkt dann die Transitionsmöglichkeiten an einem semantischen Variationspunkt
im ExecutionModel auf eine konkrete Auswahl ein.
63

4.2.4 Endlichkeit der ExecutionModel-Berechnung
Abbildung 4.8: Schleife modelliert mittels Erweiterung
Beim Aufbau des ExecutionModels aus dem NarrativeModel entsteht immer ein endliches
Modell. Problematisch in dieser Hinsicht sind Schleifen. Diese werden allerdings
während der Berechnung des ExecutionModels aufgelöst. Abbildung 4.8 zeigt den
Fluss F1 und den diesen erweiternden Fluss F2. Erweitert wird F1 an der Position
EP2. Nach Ausführung von F2 setzt der Kontrollfluss in F1 an EP1 fort. Dieses derart
im NarrativeModel modellierte Verhalten resultiert im ExecutionModel in genau
fünf EventExecutions. Vier EventExecutions repräsentieren dabei die vier Ereignisse
in F1 und eine EventExecution die Aktion A in F2. Die kontextreduzierende Transition
hinter A-EventExecution führt zu derselben C-EventExecution, die auch von
B-EventExecution erreicht wird, wenn der alternative Ablauf über F2 an EP1 nicht
zur Ausführung kommt. Aus der statischen Darstellung von C-EventExecution im ExecutionModel
lässt sich nicht ablesen, ob dem Erreichen von C bereits mehrere Ausführungen
von F2 vorangegangen sind oder nicht. Während der Simulation selbst ist
diese Information jedoch vorhanden, vorausgesetzt man zeichnet die Schrittsequenz
auf, über die man C erreicht hat (in Form einer Folge von Transitionen und EventExecutions).
4.3 SimulationModel
Das SimulationModel kapselt die für die Simulation notwendigen Konzepte, die auf
denen des ExecutionModels aufbauen. Darunter fallen zum einen Mechanismen zum
Aufzeichnen von Simulationsabläufen und zum anderen Elemente, um den aktuellen
Zustand der Simulation zu speichern. In der Anfangsphase der Metamodellierung waren
einige der Elemente, die jetzt im SimulationModel zu finden sind, ebenfalls dem
ExecutionModel zugeordnet. Konzeptionell stellen sie aber nur eine Anwendung des
ExecutionModels dar und gehören semantisch nicht zu der im ExecutionModel ausgedrückten
Ausführungssicht. Folgerichtig sind diese Elemente jetzt Teil eines separaten
Metamodells, dem SimulationModel.
Abbildung 4.9 zeigt das gesamte SimulationModel. Das Wurzelement des Modells ist
64

Abbildung 4.9: Struktur des SimulationModels
die Metaklasse Simulation. Eine Simulation wird immer auf Grundlage eines ExecutionModels
durchgeführt, daher die executionModel-Referenz in Simulation. Zu
jeder Simulation gehören beliebig viele Trace-Elemente. Eines dieser Elemente kann
als aktuelle Trace der Simulation ausgezeichnet sein. Eine Trace dient dem Speichern
des Simulationsablaufs. Während dem Ablauf der Simulation wählt der Benutzer eine
Folge von Transitionen und EventExecutions aus dem ExecutionModel, über die er das
Modell durchläuft. Jeder solcher „Lauf“ wird in einer eigenen Trace festgehalten. Dies
geschieht in Form von TraceElement-Instanzen, die jeweils einen Step 3 des ExecutionModels
kapseln. Jede Trace kann grundsätzlich beliebig viele derartige Elemente
umfassen. Jeweils eines dieser Elemente ist das aktuelle Element der Trace. Eine Trace
kann durchaus mehrere Elemente beinhalten, die jeweils denselben ExecutionModel-
Step kapseln. Dies geschieht wenn der Benutzer während der Simulation Schleifen
durchläuft und eine bestimmte EventExecution mehrfach besucht. In der zugrundeliegenden
ExecutionModel-Instanz wird wie bereits erwähnt nicht unterschieden, ob ein
Element während der Ausführung zum ersten Mal erreicht wird oder im Zuge einer
Schleife bereits mehrmals besucht wurde. Die Trace kann aber sehr wohl Schleifen
beinhalten.
Neben den Metaklassen Simulation, Trace und TraceElement gibt es noch
die DemarcationPoint-Metaklasse. Diese dient dazu, einzelne Elemente der Trace
gesondert mit Namen auszuzeichnen. Auf diesem Wege kann der Benutzer im Laufe
der Simulation bestimmte Elemente kennzeichnen, um beispielsweise die Trace zu einem
späteren Zeitpunkt bis zu diesem Punkt „zurückzuspulen“.
3 Zur Erinnerung: EventExecution und Transition sind Step-Spezialisierungen.
65

4.3.1 Semantik der Trace-Operationen
Neben den bereits vorgestellten strukturellen Beziehungen der Trace zu den anderen
Elementen des Metamodells, verfügt sie außerdem noch über drei Operationen. Diese
dienen der Manipulation der Trace und haben im Einzelnen die folgende Semantik:
Abbildung 4.10: Funktionsweise der record-Operation einer Trace
• record(Step) dient dem Hinzufügen eines Elements zur Trace. Dabei wird der
gegebene Step in Form einer TraceElement-Instanz gekapselt und hinter
dem aktuellen Element der Trace hinzugefügt. Wenn das aktuelle Element der
Trace nicht gleichzeitig auch das letzte Element der Trace ist (als Resultat von
Navigationsoperationen auf der Trace), werden diejenigen Elemente die hinter
dem aktuellen Element stehen aus der Trace entfernt und an ihrer Stelle das
neue Element hinzugefügt. Das neue Element wird in jedem Fall das neue aktuelle
Element der Trace. Abbildung 4.10 illustriert den geschilderten Sachverhalt
für eine Trace mit vier Elementen, wobei Element 2 das aktuelle Element der
Trace ist. Element 5 wird der Trace mittels record-Operation hinzugefügt. Dadurch
werden die Elemente 3 und 4 aus der Trace entfernt und 5 ist das neue
aktuelle Element hinter dem bis dahin aktuellen Element 2.
• toPrevious und toNext versetzen das aktuelle Element auf das Element, welches
dem bis dato aktuellen Element in der Liste aller Elemente der Trace vorhergeht
bzw. nachfolgt. Gibt es ein derartiges Element nicht, haben die Operationen keinen
Effekt.
66

Kapitel 5
Technische Umsetzung
Eingeleitet wird dieses Kapitel durch eine Beschreibung der Arbeitsweise des Algorithmus
zur Berechnung einer ExecutionModel-Instanz. Darauf folgt die Darstellung
der technischen Umsetzung der Simulationsumgebung.
Die Simulationsumgebung setzt sich aus mehreren graphischen Komponenten zusammen.
Jede dieser Komponenten ist verantwortlich für einen Aspekt der Simulation.
Den Kern der Simulationsumgebung bildet ein Editor zur Aufzeichnung der Simulation
selbst. Dieser Editor arbeitet auf Basis einer Instanz des SimulationModels (vgl.
Abschnitt 4.3). Darüber hinaus gibt es Views zur Darstellung von simulationsspezifischen
Zusatzinformationen. Konkret gibt es die folgenden Komponenten:
• Die FlowView, die der Visualisierung der statischen Struktur einer NarrativeDescription
dient. Dies wird umgesetzt durch die graphische Darstellung der Flüsse
dieser NarrativeDescription, sowie der Beziehungen zwischen den Flüssen.
• Die ExecutionModelView realisiert die graphischen Darstellung einer ExecutionModel-Instanz.
Dies geschieht mittels navigierbarer Aktivitätsdiagramme.
• Der Simulator dient zur Aufzeichnung von Traces, bzw. allgemeiner zum Bearbeiten
einer Simulation-Instanz des SimulationModels.
Im Folgenden werden die verschiedenen Komponenten ausführlich vorgestellt und ihre
technische Realisierung beschrieben. Zum Schluss wird die Integration der Teile zu
einem funktionsfähigen Ganzen behandelt.
5.1 Berechnung des ExecutionModels
Wie in Abschnitt 4.2 beschrieben, stellt eine ExecutionModel-Instanz die Ausführungssicht
auf eine NarrativeModel-Instanz dar. Die Erzeugung einer ExecutionModel-
67

Instanz auf Grundlage einer existierenden NarrativeModel-Instanz ist Inhalt dieses Abschnitts.
Die hier im Folgenden vorgestellten Schnittstellen und Klassen sind Teil des
sc.viper.nautilus.core.executionmodel-Plugins.
public interface ExecutionModelBuilder {
ExecutionModel buildFrom(NarrativeModel narrativeModel);
}
public interface EventExecutionSuccessorStrategy {
List getNewSuccessors(EventExecution eventExecution);
boolean supports(EventExecution eventExecution);
}
Abbildung 5.1: ExecutionModelBuilder- und EventExecutionSuccessorStrategy-Schnittstellen
Die Aufgabe der Berechnung übernimmmt eine Realisierung der ExecutionModelBuilder-Schnittstelle
(Abbildung 5.1). Dabei erhält der Algorithmus als einzige
Eingabe ein NarrativeModel und gibt als einzige Ausgabe ein ExecutionModel zurück.
Der Kern der Referenzimplementierung der ExecutionModelBuilder-Schnittstelle
besteht aus verschiedenen Implementierungen einer weiteren Schnittstelle, der
EventExecutionSuccessorStrategy. Deren Signatur ist ebenfalls in Abbildung
5.1 zu sehen. Diese Schnittstelle definiert die Methode getNewSuccessors zur
Berechnung der Nachfolger einer gegebenen EventExecution. Diese Methode gibt als
Ergebnis die Menge der Nachfolger-EventExecutions zurück. Der Vorgänger wird mittels
Transitionen mit seinen Nachfolgern gekoppelt.
public boolean supports(EventExecution eventExecution) {
return eventExecution.getEvent() instanceof Action
|| eventExecution.getEvent() instanceof ExtensionAnchor;
}
Abbildung 5.2: Implementierung der supports-Methode in DirectSuccessor-
Strategy
Jede Implementierung der EventExecutionSuccessorStrategy-Schnittstelle
unterstützt die Nachfolgerberechnung für einen speziellen Typ EventExecution. Über
die supports-Methode wird ermittelt, ob eine Strategie für die Ermittlung der Nachfolger
einer gegebenen EventExecution zuständig ist. Die verschiedenen Strategien
differenzieren nach Art des durch die EventExecution referenzierten NarrativeModel-
Events. Für jede Event-Spezialisierung gibt es eine Strategie.
Beispielsweise berechnet die DirectSuccessorStrategy, die Nachfolger für
EventExecutions, die Actions oder ExtensionAnchors kapseln (siehe Implementierung
der supports-Methode in Abbildung 5.2). Diese Strategie berechnet den regulären
Nachfolger einer Aktion oder eines Erweiterungsankers. Das ist genau der Nachfolger,
der den Standardablauf ausmacht und in der Regel im selben Fluss wie der Vorgänger
liegt. Der reguläre Nachfolger einer EventExecution, die ein Ereignis an der
letzten Position eines Flusses kapselt, liegt, über eine reduzierende Transition erreich-
68

ar, im „Vorgängerfluss“. Auf die Erweiterungsanker bezogen, ist ein regulärer Nachfolger
derjenige Nachfolger, der erreicht wird, wenn keine Alternative wirksam wird.
Für die Berechnung von alternativen Nachfolgern 1 sind eigene Strategien verantwortlich,
nämlich InternalExtensionSuccessorStrategy bzw. External-
ExtensionSuccessorStrategy für interne bzw. externe Erweiterungsanker.
Im Falle einer EventExecution, die das letzte Ereignis eines Flusses darstellt, delegiert
DirectSuccessorStrategy die Nachfolgerberechnung an eine Helferstrategie,
namens DirectMergeSuccessorStrategy. Diese ist verantwortlich für die Bestimmung
eines Nachfolgers, der bezogen auf die Ausführungssequenz von Flüssen in
einem Fluss „vor“ dem aktuellen Fluss liegt. Damit ist ein Fluss gemeint, aus dem heraus
der aktuelle Fluss - direkt oder indirekt - über eine Sequenz verschiedener anderer
Flüsse zur Ausführung kam. Bildlich gesprochen wird der Stack des Ausführungskontextes
durch eine reduzierende Transition zwischen aktueller EventExecution und
Nachfolger abgebaut.
An dieser Stelle werden alle Nachfolgerstrategien noch einmal kurz vorgestellt:
• DirectSuccessorStrategy und DirectMergeSuccessorStrategy
dienen, wie oben bereits geschildert, der Berechnung eines regulären Nachfolgers
für eine gegebene Action- oder ExtensionAnchor-EventExecution. Es
gibt immer genau einen (oder keinen) regulären Nachfolger bezogen auf den
Standardablauf. Im Falle der DirectSuccessorStrategy wird der Vorgänger an
seinen einzigen Nachfolger immer über eine invariante Transition gekoppelt. Im
Falle der DirectMergeSuccessorStrategy geschieht diese Kopplung immer über
eine reduzierende Transition.
• ExternalInclusionSuccessorStrategy sowie InternalInclusionSuccessorStrategy
sind verantwortlich für die Nachfolgerberechnung
von ExternalInclusion- und InternalInclusion-EventExecutions. Sie berechnen
in diesem Sinne auch den Standardablauf, da eine Inklusion das Verhalten
eines anderen Flusses unbedingt zur Ausführung bringt. Auch hier gibt es zu einer
Inclusion-EventExecution jeweils nur einen Nachfolger, der vom Vorgänger
aus über eine expandierende Transition erreicht wird.
• Analog gibt es zur Ermittlung der Nachfolger von Erweiterungsankern die beiden
Klassen ExternalExtensionSuccessorStrategy und InternalExtensionSuccessorStrategy.
Diese bestimmen zu einer internen
oder externen ExtensionAnchor-EventExecution die im Rahmen von Alternativabläufen
erreichbaren Nachfolger. Dies können grundsätzlich beliebig viele
sein. Jeder gefundene Nachfolger wird mittels expandierender Transition an die
ExtensionAnchor-EventExecution gekoppelt.
• Die ExceptionSuccessorStrategy dient der Bestimmung von Nachfolgern
einer Action-EventExecution, die in Ausnahmeflüssen liegen. Das ist abhängig
vom aktuellen Ausführungskontext und kann für eine Action-EventExe-
1 Ein alternativer Nachfolger ist nicht Teil des Standardablaufs.
69

cution in beliebig vielen Nachfolgern resultieren. Diese sind dann alle mittels
expandierender Transition erreichbar.
• Die NullSuccessorStrategy erwartet als Eingabe-EventExecution eine
Null-Referenz (null in Java). Sie gibt dann diejenigen EventExecutions zurück,
über die in das Modell „eingestiegen“ werden kann. Das sind die Event-
Executions, die in einem konkreten Fluss, der über einen InteractionContext verfügt,
an erster Position stehen.
Der ExecutionModelBuilder baut das ExecutionModel ausgehend von der Ausgabe der
NullSuccessorStrategy inkrementell auf. Die Ausgabe-EventExecutions der NullSuccessorStrategy
werden der Reihe nach in die supports-Methoden der anderen Strategien
hineingegeben. Wenn eine Strategie einen bestimmten Typ EventExecution unterstützt,
wird ihre getNewSuccessors-Methode aufgerufen. Die neugewonnenen Nachfolger
werden dann auf dieselbe Weise weiter verarbeitet, bis irgendwann keine neuen
Nachfolger mehr gefunden werden. Zu diesem Zeitpunkt ist das ExecutionModel dann
komplett aufgebaut und kann anschließend mittels EMF-Mechanismen im Dateisystem
persistiert werden.
Abbildung 5.3: Funktionsweise von Nachfolgerstrategien
Abbildung 5.3 illustriert die Arbeitsweise der verschiedenen Strategien anhand eines
einfachen Beispiels. Die Quadrate symbolisieren EventExecutions, die Pfeile stellen
Transitionen zwischen EventExecutions dar. Die EventExecutions ohne Beschriftung
sind einfache Aktionen. EI ist eine externe Inklusion, EP1 ein externer Erweiterungsanker.
Jede Transition ist beschriftet mit derjenigen Nachfolgerstrategie, mittels der
die jeweilige Transition im ExecutionModel erzeugt wurde.
Interpretiert man das in Abbildung 5.3 dargestellte Beispiel als eine komplette ExecutionModel-Instanz,
stellt man fest, dass dieses Modell genau zwei Szenarien aufspannt.
Zum einen gibt es das Szenario, welches den Standardablauf darstellt und mittels der
Transitionsfolge {a, b, d, c, b, c} zustande kommt. Das andere Szenario beinhaltet
einen Alternativablauf und stellt sich als Transitionsfolge wie folgt dar: {a, b, d, c, b,
e, c, c}.
70

5.2 FlowView
Wichtiger Bestandteil einer benutzerfreundlichen Simulationsumgebung ist eine Visualisierungskomponente
für die statische Struktur eines NarrativeModels. Mittels dieser
kann sich ein Benutzer den Strukturzusammenhang des zugrundeliegenden Modell
vergegenwärtigen und sich somit einen Überblick über die modellierten Inhalte verschaffen.
Zu diesem Zweck wurde im Rahmen dieser Arbeit die sogenannte FlowView entwickelt.
Die FlowView stellt die interne Struktur einer NarrativeDescription graphisch
dar. Dazu werden die Flüsse der NarrativeDescription mit ihren Ereignissen visualisiert.
Die Inklusions- und Erweiterungsbeziehungen zwischen Flüssen einer NarrativeDescription
werden in Form von Kanten dargestellt.
Abbildung 5.4: Screenshot der FlowView
Abbildung 5.4 beinhaltet einen Screenshot der FlowView. Diese zeigt zwei Flüsse einer
NarrativeDescription, die über eine interne Erweiterungsbeziehung miteinander
verbunden sind. Die „IEA“-Quadrate stehen für interne Erweiterungsanker, die leeren
Quadrate stellen Aktionen dar. Wenn man den Mauszeiger über eines der Quadrate
eines Ereignisses eines Flusses bewegt, werden Detailinformationen zum Ereignis
eingeblendet. In der Abbildung ist dies für den zweiten Erweiterungsanker illustriert.
Der Fluss hat den Namen Authentifizieren Standard und der Anker heißt hinter PIN
Eingabe. Die Pfeile zwischen den Flüssen geben die tatsächliche Richtung des möglichen
Kontrollflusses an und nicht die Richtung der zugrundeliegenden Beziehung.
Die Erweiterungsbeziehung ist von erweiterndem zu erweitertem Use Case gerichtet,
der Kontrollfluss läuft genau entgegengesetzt. Im Falle des Beispiels kann der Kontrollfluss
also vom Erweiterungsanker hinter PIN Eingabe in den Fluss auf der rechten
Seite übergehen.
Inhalt des Screenshots in Abbildung 5.5 ist die Ausgabe der FlowView im Falle einer
komplexeren NarrativeDescription. Das Bild stellt die selbe Situation zweimal dar.
Links werden alle Kanten, die mögliche Kontrollflusswechsel zwischen Flüssen sym-
71

Abbildung 5.5: Screenshot der FlowView
bolisieren, angezeigt. Diese Darstellung kann für große Modelle ziemlich unübersichtlich
werden. Aus diesem Grund bietet die FlowView die Möglichkeit, verschiedene
Kantenarten bei Bedarf auszublenden. Auf der rechten Seite des Bildes ist die interne
Struktur der NarrativeDescription erneut visualisiert, diesmal ohne Rücksprungskanten.
Durch diese Maßnahme wird die Übersichtlichkeit deutlich erhöht. Generell lassen
sich auch die Aussprungskanten ausblenden. Der Benutzer der View kann somit immer
die Sichtweise auf den Kontrollfluss einnehmen, die ihn gerade interessiert.
5.2.1 Integration der FlowView in die Eclipse-Plattform
Die FlowView ist technisch realisiert als Eclipse-View, d.h. als Implementierung der
IViewPart-Schnittstelle.
Für die graphische Darstellung kommt das GEF Rahmenwerk (siehe Abschnitt 3.2)
zum Einsatz.
Die FlowView ist sowohl SelectionListener als auch SelectionProvider (vgl. Abschnitt
3.1.3). In ihrer Rolle als SelectionListener verarbeitet sie alle NarrativeDescriptions,
die ihr von anderen SelectionProvidern zur Verfügung gestellt werden. Selektiert ein
anderes WorkbenchPart eine NarrativeDescription, wird die FlowView hierüber informiert
und stellt die auf diese Art erhaltene NarrativeDescription graphisch dar.
72

In der graphischen Darstellung der FlowView kann mittels Mausklick ein Ereignis
eines Flusses selektiert werden. Diese Selektion wird anderen SelectionListenern zur
Verfügung gestellt.
5.2.2 Graphische Anordnung der Flüsse
Die Anordnung der Flüsse in der graphischen Darstellung resultiert aus einer Heuristik,
die anstrebt, Überschneidungen der Beziehungen zwischen Flüssen in Form sichüberkreuzender
Kanten möglichst zu vermeiden. Daraus resultiert, dass Flüsse mit Interaktionskontext
immer links dargestellt werden und sich inkludierte und erweiternde
Flüsse nach rechts hin auffächern.
5.3 ExecutionModelView
Die ExecutionModelView dient der graphischen Visualisierung einer ExecutionModel-
Instanz. Praktisch geschieht dies mittels einer Darstellung in Form navigierbarer Aktivitätsdiagramme.
Diese Darstellungsform reflektiert die Ausführungssicht, wie sie ein
ExecutionModel auf eine NarrativeModel-Instanz beschreibt. Anders als bei der Flow-
View stehten nicht mehr Strukturinformationen im Vordergrund, sondern Ablaufmöglichkeiten
des Verhaltens, das im Use Case-Modell und dem auf diesem basierenden
NarrativeModel enthalten ist.
In Abschnitt 4.1 wurde das Gesamtmodell des Geldautomaten (aus dem Beispiel in
Abschnitt 2.3) in Form eines Aktivitätsdiagramm dargestellt. Die ExecutionModel-
View stellt allerdings nicht das gesamte Ausführungsmodell dar, sondern jeweils einen
Ausschnitt in Form je einer Aktivität. Die Navigation zwischen verschiedenen Ausschnitten
des zugrundeliegenden Modells verschafft einen allumfassenden Überblick
über das Gesamtmodell. Die Idee der Darstellung eines kompletten Modells in einem
Diagramm wurde aus Gründen der Übersichtlichkeit für unpraktikabel befunden.
Die einzelnen Aktivitäten, die von der ExecutionModelView angezeigt werden, stellen
für je einen NarrativeModel-Fluss die in diesem Fluss möglichen Aktionsalternativen
dar. Die Aktionsknoten einer Aktivität kapseln EventExecutions und Transitionen des
ExecutionModels. Mittels derjenigen Aktionsknoten, die Transitionen symbolisieren,
kann zwischen der Darstellung verschiedener Aktivitäten navigiert werden, was weiter
unten noch erläutert wird. Genau genommen werden nicht die Aktionsmöglichkeiten
je eines Flusses anzeigt. Dies würde nämlich implizieren, dass die Strukturinformationen,
die aus dem NarrativeModel abgefragt werden können, für diese Darstellung
ausreichend sind. Stattdessen werden die Aktionsmöglichkeiten je eines Execution-
Contexts des ExecutionModels visualisiert. Jeder Fluss des NarrativeModels hat mindestens
einen ExecutionContext, der den Kontext seiner Ausführung beschreibt. Wenn
der Fluss in der Ausführung auf verschiedenen Pfaden erreichbar ist, sind auch mehrere
möglich. Anschaulicher ist allerdings die Sprechweise, nach der der Verhaltensablauf
eines Flusses dargestellt wird.
73

Erweiterungen, Inklusionen und Verzweigungen zu Ausnahmeflüssen werden jeweils
aus Sicht des lokalen Flusses atomar als je eine Aktion dargestellt. Derartige Aktionen,
die die Ausführung einer Verhaltenssequenz (bzw. eines anderen Flusses) kapseln,
sind graphisch durch ein Symbol, das wie ein umgedrehter Dreizack aussieht, kenntlich
gemacht. Durch Doppelklick des Benutzer auf eine solche Aktion stellt die View
deren gekapselte Verhaltenssequenz in Form einer eigenen Aktivität dar. Der Benutzer
bekommt auf diese Weise den Inhalt des aufgerufenen Flusses angezeigt. Über einen
Zurück-Knopf hat er die Möglichkeit, in den Ursprungsfluss zurückzukehren. Der Benutzer
kann so durch die Kontexte einer ExecutionModel-Instanz navigieren und sich
leicht einen Überblick über das Modell verschaffen.
Abbildung 5.6: Screenshot der ExecutionModelView
Abbildung 5.7: Screenshot der ExecutionModelView
Abbildung 5.6 zeigt die ExecutionModelView in Aktion. Die abgebildete Aktivität
illustriert die Aktionsmöglichkeiten des Flusses Standardfluss, der in der NarrativeDescription
von UseCase definiert ist. Der dargestellte Fluss besitzt nur einen Erweiterungsanker,
an dem Verhalten eingefügt werden kann. In diesem Fall kann konkret der
Fluss Erweiterungsfluss, der zur selben NarrativeDescription gehört, ausgeführt werden.
Bewegt der Benutzer den Mauszeiger über die Fragezeichen an den Kanten, wer-
74

den die Bedingungen eingeblendet, unter denen sich der Kontrollfluss entsprechend
verlagert. Der Standardablauf von Standardfluss ist durch die beiden unbeschrifteten
Kanten dargestellt, die vom Startknoten zum Endknoten der Aktivität führen. Im Falle
eines Doppelklicks auf die Aktion mit dem umgekehrten Dreizack werden die Ablaufmöglichkeiten
des Flusses Erweiterungsfluss als Inhalt einer neuen Aktivität visualisiert.
In der Menüleiste der View sind Knöpfe enthalten, mittels derer durch die Darstellung
navigiert werden kann. Auf dem Screenshot ist nur der Zurück-Knopf funktionsfähig,
der Vorwärts-Knopf ist ausgegraut. Der Vorwärts-Knopf ist nur dann aktiviert,
wenn vorher mindestens einmal der Zurück-Knopf betätigt wurde. Intuitiv entspricht
die Navigationsmechanik der eines Web-Browsers. Des Weiteren kann mittels der Lupen
in der Menüleiste die Darstellung vergrößert bzw. verkleinert werden. Mit Hilfe
des Layout-Knopfes ganz links kann zwischen der vertikalen und horizontalen Darstellung
einer Aktivität umgeschaltet werden. Je nach gewählter Darstellungsart werden
die Knoten, die den Standardablauf einer Aktivität ausmachen, von links nach rechts
(horizontal) bzw. von oben nach unten (vertikal) angeordnet. Alternativabläufe und
Ausnahmen werden als vom Standardablauf abweichende Verzweigungen rechts neben
oder unterhalb des Standardablaufs dargestellt. Abbildung 5.7 zeigt die bereits aus
der Vorgängerabbildung bekannte Aktivität, diesmal allerdings in horizontaler Darstellung.
Zur Verdeutlichung der Funktionsweise der ExecutionModelView im Falle eines komplexeren
Modells zeigt Abbildung 5.8 eine aufgefächerte Darstellung der relevanten
Aktivitäten des Geldautomatenbeispielmodells. Im Zuge der Visualisierung der
ExecutionModel-Instanz wird als erstes die links oben abgebildete Aktivität NarrativeModel:
Geldautomat dargestellt. Im Falle des Geldautomatensystems gibt es nur
eine Möglichkeit, eine Ausführung eines Anwendungsfalles auszulösen. Dementsprechend
gibt es hier nur einen Einstiegspunkt, der bei Doppelklick in die Darstellung
des Flusses Geld abheben Standard hineinführt. Diese Aktivität ist Inhalt der rechten
Spalte der Abbildung. In der linken Spalte sind außerdem noch die Aktivitäten Authentifizieren
Standard und Quittung drucken Standard zu sehen, die beide aus Geld
abheben Standard heraus erreichbar sind.
Der Darstellung einer ExecutionModel-Instanz in Form des navigierbaren Aktivitätdiagramms
liegen zwei hauptsächliche Motivationen zugrunde:
1. Intuitive Darstellung: Aktivitätsdiagramme gehören zu den bekanntesten Vertretern
der verschiedenen Diagrammtypen der UML. Sie sind den meisten Modellierern
vertraut. Selbst Benutzern, die noch keinerlei Kontakt mit Aktivitätsdiagrammen
hatten, erschließt sich ihre Semantik intuitiv.
2. Semantik von Aktivitäten und Aktionen: Die Semantik der eingesetzten Elemente
zur Darstellung von EventExecutions und Transitionen des Execution-
Models entspricht genau der Semantik der Elemente, die sie repräsentieren.
UML-Aktionen werden eingesetzt, um Action-EventExecutions 2 darzustellen.
2 Eine Action-EventExecution ist eine EventExecution die eine NarrativeModel Action kapselt.
75

Abbildung 5.8: Das Geldautomatenbeispiel als Menge von Aktivitäten
76

Eine andere Art von UML-Aktion wird benutzt, um die Ausführung einer kompletten
Verhaltenssequenz graphisch zu repräsentieren. Eine Aktivität selbst ist
nichts anderes als eine Verhaltenssequenz.
5.3.1 Integration der ExecutionModelView in die Eclipse-Plattform
Die ExecutionModelView ist technisch realisiert als Eclipse-View, d.h. als Implementierung
der IViewPart-Schnittstelle.
Für die graphische Darstellung kommt das GEF Rahmenwerk (siehe Abschnitt 3.2)
zum Einsatz.
Abbildung 5.9: Metaklassen zur Modellierung von Aktivitäten
Die Modellelemente der verschiedenen EditParts sind dabei nicht etwa Elemente des
ExecutionModels sondern Elemente des UML-Modells. Insbesondere sind dies Activity,
ActivityEdge und verschiedene Spezialisierungen von Activity-
Node.
Abbildung 5.9 bietet einen Überblick über die eingesetzten Modellelemente und ihre
Struktur. Das zentrale Element ist die Activity-Metaklasse. Activity ist eine
Spezialisierung von Behavior und dient damit der Darstellung von dynamischen
Verhaltenssequenzen. Eine Activity besitzt eine Menge von Knoten (Metaklasse ActivityNode)
und eine Menge von Kanten (Metaklasse ActivityEdge) zwischen
ihren Knoten (siehe auch Abschnitt 2.1.1). Zwei Verfeinerungen von Activity-
Node sind im Rahmen der Realisierung der ExecutionModelView besonders interessant:
• Action: Eine Aktion ist ein Knoten, der einen einzelnen Schritt der Verhaltens-
77

sequenz einer Aktivität darstellt. Es gibt atomare Schritte in Form von SendSignalAction-Instanzen
und solche Schritte, die wiederum eine andere Verhaltenssequenz
kapseln (Metaklasse CallBehaviorAction). Letztere werden
graphisch mit dem umgekehrten Dreizacksymbol dargestellt.
• ControlNode: Ein Kontrollknoten ist ein Knoten, der der Steuerung des Kontrollflusses
dient. Konkret gibt es DecisionNode-Instanzen an denen sich
Verhalten verzweigt (ein DecisionNode besitzt immer mehr als eine ausgehende
Kante) und MergeNode-Instanzen, an denen mehrere Kontrollflüsse zusammengeführt
werden (d.h. mehrere Kanten führen in eine MergeNode hinein). Jede
Aktivität muss über genau einen Startknoten in Form einer InitialNode-
Instanz verfügen. Zu den Knoten einer Activity können außerdem Instanzen von
ActivityFinalNode gehören. Die Ausführung einer Activity endet, wenn
der Kontrollfluss in einen derartigen Knoten hineinführt. Startknoten haben keine
eingehenden Kanten, Endknoten keine ausgehenden Kanten.
Der Visualisierung einer ExecutionModel-Instanz voraus geht notwendigerweise die
Transformation des ExecutionModels in eine Aktivität, bzw. in eine hierarchische
Struktur einer Menge von Aktivitäten. Die hierarchische Struktur kommt mittels Call-
BehaviorAction-Instanzen, die als Knoten zu einer Aktivität gehören, zustande.
Über ihre behavior-Assoziation referenziert eine CallBehaviorAction das Verhalten,
deren Ausführung sie kapselt. Im Falle der ExecutionModelView ist das gekapselte
Verhalten immer eine andere Aktivität, die der Ausführung je eines Flusses entspricht.
Im Rahmen der graphischen Darstellung einer ExecutionModel-Instanz wird jede Action-EventExecution
durch eine SendSignalAction repräsentiert. CallBehaviorActions
werden genutzt, um expandierende Transitionen zu visualisieren. EventExecutions,
die die Ausführung anderer NarrativeModel-Events als Actions kapseln, bieten keinen
Mehrwert für die graphische Darstellung. Verzweigendes Verhalten wird mittels
DecisionNodes visualisiert. Dass dieser Verzweigung im ExecutionModel ein Erweiterungsanker
zugrunde liegt, an dem alternatives Verhalten ansetzt, ist hierbei unerheblich.
Ebenso wenig werden reduzierende Transitionen explizit repräsentiert. Jede
Aktivität hat in der ExecutionModelView genau einen Endknoten, der alle möglichen
reduzierenden Transitionen darstellt.
Im Zuge der Transformation eines ExecutionModels in eine Aktivitätshierarchie werden
Stereotypen eingesetzt, um einer Aktivität denjenigen ExecutionContext zuzuordnen,
den sie repräsentiert. Analog ermöglicht ein anderer Stereotyp die Zuordnung von
Transitionen und EventExecutions auf Aktionen und von Transitionen auf Kanten. Damit
ist an den Elementen, die das Aktivitätsdiagramm ausmachen, hinterlegt, welche
Elemente des ExecutionModels sie repräsentieren. Der diesem Ansatz technisch zugrundeliegende
UML-Profilmechanismus wurde in Abschnitt 2.1.1 vorgestellt.
Diese auf derartige Weise an Aktivitäten, Knoten und Kanten hinterlegte Informationen
werden von dem Algorithmus, der für die graphische Anordnung der Knoten einer
Aktivität verantwortlich ist, genutzt, um zu ermitteln, welche Knoten den Standardablauf
darstellen.
78

Die ExecutionModelView ist SelectionProvider und SelectionListener (vgl. Abschnitt
3.1.3). Selektiert man eine Aktion, wird anderen WorkbenchParts das repräsentierte
ExecutionModel-Element zur Verfügung gestellt. Stellt hingegen ein anderes WorkbenchPart
ein ExecutionModel-Element zur Verfügung, welches zu diesem Zeitpunkt
in der aktuell dargestellten Aktivität durch eine Aktion oder eine Kante repräsentiert
wird, hebt die ExecutionModelView die Aktion oder die Kante farblich hervor.
5.4 Simulator
Das zentrale Element der Simulationsumgebung ist der Simulator. Dieser dient der
Aufzeichnung von neuen Traces und der Bearbeitung existierender Traces. Der Simulator
besteht aus zwei Komponenten, die gemeinsam seine Funktionalität ausmachen.
Die erste Komponente ist ein Editor, mittels dem ein Benutzer eine Trace aufzeichnet.
Die zweite Komponente ist eine View, die eine Simulation-Instanz (das Wurzelement
des SimulationModels, siehe Abschnitt 4.3) und ihre Traces visualisiert.
5.4.1 TraceEditor
Der Editor zum Aufzeichnen von Traces heißt TraceEditor. Im Editor steuert der Benutzer
die simulierte Ausführung einer ExecutionModel-Instanz. Dafür wählt er aus
einer Menge von Schritten (Steps des ExecutionModels, also Transitionen und Event-
Executions), die ihm der Editor zur Auswahl gibt, einen aus. Daraufhin wird der selektierte
Schritt als neuer aktueller Schritt in die Trace aufgenommen und eine neue
Bildschirmmaske mit den entsprechenden Nachfolgern des jetzt aktuellen Schrittes
aufgebaut. Aus dieser Menge wählt der Benutzer wiederum einen Schritt aus. Dies
geschieht solange, bis der Benutzer ein komplettes Szenario vom Anfang eines Use
Cases bis zu dessen Ende in Form einer Folge von Schritten in der Trace gespeichert
hat. Auf Modellebene wird jeder Schritt, der der Trace hinzugefügt wird, durch eine
eigene TraceElement-Instanz gekapselt.
Abbildung 5.10 zeigt eine Abfolge von Bildschirmmasken des TraceEditors für das
Geldautomatenbeispiel aus Abschnitt 2.3. Wird der Editor auf einer Modelldatei 3 , die
eine Simulation enthält, geöffnet, muss eine Trace angegeben werden, die in der Folge
bearbeitet werden soll. Hierfür kann eine bereits bestehende Trace gewählt werden,
oder es kann eine neue Trace angelegt werden. Startet man das Geldautomatenbeispiel
mit einer neuen Trace, wird die zweite abgebildete Bildschirmmaske angezeigt. Hier
hat der Benutzer ebenso wie in der dritten Maske nur einen Schritt zur Auswahl. Die
vierte Maske stellt eine Situation dar, an der sich Verhalten verzweigen kann. Die erste
Option stellt den Standardablauf dar. Im konkreten Fall kann der Benutzer mittels
Inklusion in den Verhaltensablauf des Flusses Authentifizieren Standard übergehen.
Alternativ geht der Kontrollfluss in den Ausnahmefluss Kunde bricht ab über. Die Bedingung
unter der dies stattfindet ist in eckigen Klammern angegeben.
3 Diese kann man mittels Wizard zu einer existierenden ExecutionModel-Instanz erstellen.
79

Abbildung 5.10: Screenshot einer Folge von Bildschirmmasken des TraceEditors
5.4.2 SimulationView
Der TraceEditor ermöglicht immer nur eine sehr lokale Bearbeitung einer Trace. An einem
Punkt kann man aus einer Menge möglicher Nachfolgeschritte einen Bestimmten
auswählen. Die SimulationView hingegen bietet eine umfassende Sicht auf die im aktiven
Editor bearbeitete Simulation. Sie stellt eine Simulation-Instanz graphisch in
Form eines Baumes, der eine Menge von Traces enthält, dar. Die Traces werden ebenfalls
hierarchisch visualisiert. Während eine Trace im SimulationModel eine Liste von
Elementen beinhaltet, ist es für ihre graphische Darstellung intuitiver, stattgefundene
Kontextwechsel durch Einrückungen hervorzuheben.
80

Abbildung 5.11: Screenshot der Darstellung zweier Traces in der SimulationView
Abbildung 5.11 illustriert diesen Sachverhalt am Geldautomatenbeispiel. Dargestellt
sind zwei vollständige Traces, von Anfang bis Ende des Anwendungsfalles. Die erste
Trace durchläuft den Standardablauf des Anwendungsfalles Geld abheben. Die hierarchische
Struktur der Elemente gibt an, an welchen Stellen der Simulation sich der
Kontrollfluss in einen neuen Ausführungskontext verlagert hat. Im Falle des Standardablaufs
war dies nur an zwei Stellen der Fall. Das erste Mal, wenn der Benutzer in
die Simulation des Flusses Geld abheben Standard einsteigt und das zweite Mal, wenn
Geld abheben Standard den Fluss Authentifizieren Standard inkludiert. Die zweite
Trace in Abbildung 5.11 stellt ein vom Standardablauf abweichendes Szenario dar.
Bei der PIN-Eingabeaufforderung gibt der Kunde zweimal eine falsche Nummer ein.
Erst im dritten Anlauf gelingt ihm die korrekte Eingabe seiner PIN.
5.4.3 Integration in die Eclipse-Plattform
Sowohl TraceEditor als auch SimulationView nutzen SWT für die Darstellung ihrer
graphischen Benutzeroberflächen. Beide Komponenten sind sowohl SelectionListener
als auch SelectionProvider. Die SimulationView zeigt immer die Simulation des aktuellen
TraceEditors an. Hierbei ist immer das letzte einer Trace hinzugefügte Element
im Baum selektiert. Wählt der Benutzer in der SimulationView ein Element der Trace
aus, springt der TraceEditor zu dieser Stelle der Simulation und zeigt die Auswahlmöglichkeiten,
die sich aus dem selektierten Element der SimulationView ergeben,
an. Die zu einem vergangenen Zeitpunkt getroffene Auswahl ist dabei standardmäßig
vorselektiert. Entscheidet sich der Benutzer jetzt für eine andere Auswahl, werden alle
Elemente, die auf das in der SimulationView Selektierte folgen, aus der Trace ent-
81

public interface ChoiceLogic {
}
List getStartChoices(ExecutionModel executionModel);
List getChoicesAfter(Step step);
Abbildung 5.12: ChoiceLogic-Schnittstelle
fernt und stattdessen das neue Element hinzugefügt. Hierdurch ist es möglich, bereits
existierende Traces nach Belieben zu verändern. Mittels der SimulationView kann der
Benutzer einfach zu der Position in der Trace springen, an der er Änderungen vornehmen
möchte.
Den Schritten, die der Benutzer im Rahmen der Simulation in einer Trace speichert,
liegen wie bereits erwähnt Transitionen und EventExecutions des ExecutionModels
zugrunde. Der TraceEditor gibt dem Benutzer nach jeder getroffenen Entscheidung
ein oder mehrere Folgeschritte zur Auswahl. Dabei zeigt der TraceEditor aber nur Elemente
an, die tatsächlich für die Simulation relevant sind. Beispielsweise wäre es für
den Benutzer sehr mühsam, wenn er jede invariante Transition 4 zwischen zwei Event-
Executions desselben Ausführungskontextes der aktuellen Trace durch eine eigene Benutzerinteraktion
hinzufügen müsste. Dass eine Transition zwischen zwei Aktionen eines
Flusses stattfindet, stellt für den Benutzer keinen Mehrwert an Informationen dar.
Invariante Transitionen sind lediglich Elemente, die aus der Modellbildung des ExecutionModels
resultieren. Aus diesem Grund stellt der TraceEditor dem Benutzer nur
bestimmte Schritte zur Auswahl zur Verfügung. Dazu gehören EventExecutions, die
eine Aktion kapseln und expandierende und reduzierende Transitionen. Realisiert wird
diese Filterung durch eine Implementierung der ChoiceLogic-Schnittstelle, die in
Abbildung 5.12 vorgestellt wird. Neben invarianten Transitionen werden standardmäßig
Auswahlen, die nur Rücksprungspunkte darstellen, übersprungen. Ein interner Erweiterungsanker,
der nur als Rücksprungsanker aus einem anderen Fluss heraus dient,
ist als Simulationsschritt nicht relevant.
5.5 Integration der graphischen Einzelkomponenten
In den vorangegangen Abschnitten dieses Kapitels wurden die verschiedenen Komponenten
der Simulationsumgebung vorgestellt. Die in diesem Rahmen beschriebenen
Views und der Editor sind jeweils verantwortlich für eine spezielle Facette, die
die Durchführung der Simulation betrifft. FlowView und ExecutionModelView dienen
der Visualisierung der zugrundeliegenden NarrativeModel- und ExecutionModel-
Instanzen. TraceEditor und SimulationView sind verantwortlich für die Durchführung
der Simulation selbst.
4.2.1).
4 Eine invariante Transition ist der Übergang zwischen zwei Events eines Flusses (vgl. Abschnitt
82

In diesem Abschnitt wird erläutert, wie die verschiedenen Komponenten im Rahmen
des Eclipse UI-Paradigmas (siehe Abschnitt 3.1.3) zusammenarbeiten, um eine benutzerfreundliche
Simulationsdurchführung zu ermöglichen.
Abbildung 5.13: Screenshot der Simulationsumgebung
Abbildung 5.13 zeigt eine Anordnung der verschiedenen Komponenten in der Eclipse-
Workbench. Zentrales Element ist der TraceEditor, der umrahmt wird von den verschiedenen
Views. Diese Anordnung folgt dem üblichen Eclipse UI-Paradigma, nach
dem ein Editor im Zentrum steht und von diversen unterstützenden Views flankiert
wird. Der TraceEditor stellt den Views in seiner Funktion als SelectionProvider verschiedene
Elemente zur Verfügung. Wenn, wie im Screenshot abgebildet, eine der vorgegebenen
Auswahlmöglichkeiten selektiert wird, setzt der TraceEditor eine mehrteilige
Selektion zusammen. Diese beinhaltet neben der aktuellen Simulation-Instanz
auch die durch die aktuelle Auswahl repräsentierte Step-Instanz des ExecutionModels
sowie eine Event-Instanz des NarrativeModels. Betätigt der Benutzer den „OK“-
Knopf des TraceEditors, um das selektierte Element der Trace hinzuzufügen, stellt der
TraceEditor den anderen WorkbenchParts die aktuelle Trace zur Verfügung. Daraufhin
können die Views zusätzliche Kontextinformationen anzeigen. Sowohl FlowView
als auch ExecutionModelView markieren dabei in ihren jeweiligen Darstellungen das
jeweils relevante Element, das mit der Auswahl des TraceEditors korrespondiert. Die
Eclipse-eigene PropertiesView nutzt den EMF-Adapter Mechanismus, um die Eigenschaften
der zuletzt zur Verfügung gestellten Selektion anzuzeigen. Rückkopplungen
der unterstützenden Views in den TraceEditor mittels ihrer Selektionen sind zu diesem
Zeitpunkt nur von der SimulationView aus möglich (siehe Abschnitt 5.4.3).
83

Mittels SelectionListener- und SelectionProvider-Mechanismen wird also eine Integration
der verschiedenen Simulationskomponenten angestrebt, um eine graphische
Benutzeroberfläche zu realisieren, die konform zu den bekannten Eclipse-Paradigmen
ist.
84

Kapitel 6
Evaluierung
Im Rahmen dieser Arbeit ist ein Werkzeug zur Ausführungssimulation natürlichsprachlicher
Anwendungsfallmodelle enstanden. Eine Evaluierung der Umgebung kann bezüglich
einer inhaltlichen Beurteilung erfolgen, die sich mit der Erfüllung der fachlichen
Anforderungen beschäftigt, oder kann der Frage nachgehen, inwiefern die Implementierung
dieser Arbeit softwaretechnischen Anforderungen genügt.
6.1 Inhaltliche Evaluierung
Mangels einer formalen Anforderungsspezifikation fällt eine systematische Evaluierung
schwer. Allerdings wurden im ersten Kapitel dieser Arbeit eine Reihe von Zielsetzungen
formuliert, die für eine Beurteilung herangezogen werden können.
Ein Ziel dieser Arbeit ist es, die Anforderungsanalyse mittels Simulationsumgebung
zu unterstützen. Leider ist es zu diesem Zeitpunkt nicht angemessen, eine umfassende
Beurteilung bezüglich dieses Gesichtspunkts vorzunehmen. Ob das Werkzeug die
erwünschte Leistung tatsächlich erbringt, müssen die Praxis und etwaige weitere Forschung
zeigen. Bereits jetzt ist allerdings abzusehen, dass durch Einsatz der Simulation
ein besseres Systemverständnis erlangt werden kann.
Eine weitere Zielsetzung bestand darin, im Laufe der Simulation Artefakte, die als
Grundlage zur qualitativen Evaluierung der modellierten Anwendungsfallbeschreibungen
genutzt werden können, zu gewinnen. In dieser Arbeit ist als wichtigstes Artefakt
die ExecutionModel-Instanz, die auf Basis einer NarrativeModel-Instanz berechnet
wird und dessen Ausführungssicht beschreibt, zu erwähnen. Zukünftige Untersuchungen
werden zeigen müssen, inwiefern es geeignete Metriken gibt, die auf Basis dieses
Modells zulässige Qualitätsaussagen oder Aussagen anderer Art treffen.
Als zweites Artefakt entsteht während der Durchführung der Simulation eine SimulationModel-Instanz,
die eine Menge von Traces beinhaltet. Die darin enthaltenen Informationen
können in Zukunft möglicherweise genutzt werden, um Hotspots zu identi-
85

fizieren. Hotspots sind Verhaltensbestandteile eines Anwendungsfalls, die übermäßig
häufig zur (simulierten) Ausführung kommen, beispielsweise als Resultat von Schleifen.
Auf diese Weise kann man bereits im Zuge der Spezifikation zentrale Verhaltensbestandteile
des Zielsystems identifizieren und diesen in den sich anschließenden
Phasen der Entwicklung entsprechend Beachtung schenken.
Der konzeptionelle Unterbau der simulierten Ausführung von Anwendungsfällen auf
Basis des ExecutionModels ist sicherlich fundiert. Ein offener Punkt betrifft die semantischen
Variationen im ExecutionModel. An semantischen Variationspunkten stehen
Verhaltensalternativen zur Auswahl, die nicht aus der Semantik von Elementen
des NarrativeModels resultieren und infolgedessen einer gesonderten Behandlung bedürfen.
Abschnitt 4.2.3 schildert die Problematik und zeigt einen möglichen Ansatz
zur Lösung auf.
Die restlichen Zielsetzungen betrafen die Benutzeroberfläche selbst. Bezüglich dieser
Anforderungen kann ein durchgehend positives Fazit gezogen werden. Erwünscht war
eine graphische Darstellung der Aktionsmöglichkeiten während der Simulation. Dies
wird von der ExecutionModelView in Form von navigierbaren Aktivitätsdiagrammen
realisiert. Außerdem gefordert war eine graphische Benutzeroberfläche, die sich an
den etablierten Eclipse Prinzipien in diesem Bereich orientiert. Der Aufbau der Benutzeroberfläche
der Simulationsumgebung folgt dem Eclipse UI-Paradigma, nach der
ein zentraler Editor durch eine Menge Views, die Zusatzinformationen zu dem aktuellen
Inhalt des Editors anzeigen, unterstützt wird. Dieser Ansatz ermöglicht dem
Benutzer eine flexible und individuelle Anordnung seiner Workbench. Abhängig von
den für ihn relevanten Informationen, kann der Benutzer die diversen Views in ihrer
Darstellungsgröße- und Platzierung variieren, oder bei Bedarf auch komplett entfernen.
Hierdurch wird eine benutzerfreundliche Benutzeroberfläche realisiert, die zudem
noch individuell auf die Bedürfnisse des Benutzers angepasst werden kann.
Die einzelnen Komponenten der Simulationsumgebung decken die von ihnen geforderte
Zielfunktionalität ab. Im Folgenden werden allerdings noch Ideen zur Verbesserung
der einzelnen Teile vorgestellt.
6.1.1 Verbesserungsmöglichkeiten FlowView
Derzeit ist die FlowView lediglich geeignet, dem Benutzer einen groben Überblick
über die interne Struktur einer einzelnen NarrativeDescription zu verschaffen. Für
die Zukunft ist angedacht, auch externe Beziehungen zwischen Flüssen verschiedener
NarrativeDescriptions in der FlowView darzustellen und navigierbar zu machen.
Demnach arbeitet die FlowView nicht mehr alleine auf Grundlage einer NarrativeDescription,
die sie in ihrer Funktion als SelectionListener zur Verfügung gestellt bekommt,
sondern kann selbst zwischen den verschiedenen NarrativeDescriptions eines
NarrativeModels navigieren.
Die graphische Darstellung von Ausnahmeflüssen ist derzeit ebenfalls noch nicht optimal.
Wünschenswert wäre es, Ausnahmeflüsse graphisch als solche zu kennzeichnen
86

und ihre Beziehungen zu den Bezugsflüssen zu visualisieren.
Darüber hinaus sollten wichtige Zusatzinformationen, wie der Name eines Flusses,
Teil der permanenten graphischen Darstellung sein und nicht erst auf Veranlassung
von Benutzerinteraktionen eingeblendet werden.
6.1.2 Verbesserungsmöglichkeiten ExecutionModelView
Der primäre Zweck der ExecutionModelView ist die Visualisierung der verschiedenen
Ablaufmöglichkeiten, die in einem ExecutionModel erfasst sind. Diese Anforderung
wird zu diesem Zeitpunkt bereits erfolgreich umgesetzt. Darüber hinaus ist es erstrebenswert,
dem Benutzer der View noch einen Mehrwert durch weitere Informationen
zu bieten. Interessant ist es in diesem Zusammenhang, eine Brücke zurück zu den zugrundeliegenden
NarrativeModel-Elementen zu schlagen.
Als weitere mögliche Entwicklungsrichtung kann die Integration mit anderen Komponenten
der ViPER-Plattform herangezogen werden. Vorstellbar ist beispielsweise eine
Funktionalität zum Export der Aktivitätshierarchie, die aus einer ExecutionModel-
Instanz gewonnen wurde, als UML-Modell. Damit können die Aktivitäten gesondert
im ViPER-Aktivitätsdiagrammeditor weiterbearbeitet werden.
6.1.3 Verbesserungsmöglichkeiten Simulator
Zu diesem Zeitpunkt ist die Visualisierung der Auswahlmöglichkeiten im TraceEditor
sehr rudimentär. Über die aktuell dargestellten Informationen hinaus sind weitere Kontextinformationen
für den Benutzer interessant, z.B. wie häufig der derzeitig aktuelle
Schritt bereits im Zuge der aktuellen Trace besucht wurde.
Die SimulationView könnte neben ihrer Rolle als SelectionProvider weitere Benutzerinteraktionen
ermöglichen. Beispielsweise könnten mittels Kontextmenü Aktionen
zur Verfügung gestellt werden mit deren Hilfe sich Traces löschen oder der Simulation
hinzufügen lassen.
Die SimulationView könnte möglicherweise ersetzt werden durch den Einsatz einer
Eclipse-eigenen View. Hier bietet sich die bereits in Abschnitt 3.1.3 vorgestellte OutlineView
an. Die OutlineView stellt eine Übersicht des Inhalts des jeweils aktuellen
Editors an. Sie verfügt über Mechanismen, die eine flexible Einbettung neuer Editoren
ermöglichen. Der jetzige Inhalt der SimulationView könnte damit als Teil der Outline-
View dargestellt werden.
87

6.2 Softwaretechnische Evaluierung
Im Zuge der technischen Umsetzung dieser Arbeit wurden diverse Rahmenwerke eingesetzt,
die einen konzeptionellen Rahmen vorgeben.
Aus der Realisierung der Arbeit innerhalb der Eclipse-Plattform folgt zwingend eine
Strukturierung der verschiedenen Komponenten in Form von Plugins. Gemäß dem
Seperation of Concerns Entwurfsprinzip sind ExecutionModel und SimulationModel
jeweils Inhalt separater Plugins. Die diversen Views und der Editor sind ebenfalls auf
verschiedene Plugins aufgeteilt.
Der Einsatz von GEF für die Realsierung der Views zieht die Verwendung einer MVC-
Architektur nach sich. Dieser Ansatz dient der Entkopplung des Modells von seiner
graphischen Darstellung und Benutzerinteraktionen mittels Controller-Mechanismus.
Durch die Nutzung von EMF zur Erzeugung des Modellcodes verfügt das Modell über
Funktionalitäten, die bei manueller Implementierung des Modells aufwändig und fehleranfällig
selbst zu realisieren wären. Dazu gehören u.a. ein Notifikationsmechanismus,
der über Änderungen am Modell informiert, sowie eine Undo/Redo-Funktionalität.
Wo die Architektur nicht durch ein Rahmenwerk bestimmt war, wurden Entwurfsmuster
eingesetzt, um eine höchstmögliche Qualität des Designs und der Realisierung zu
erzielen. Als Beispiel dient die Implementierung der ExecutionModel-Berechnung wie
in Abschnitt 5.1 beschrieben. Hier wurde das Strategiemuster eingesetzt, um die komplexe
Aufgabe der Modelltransformation in überschaubare Teilprobleme zu zerlegen
und austauschbare Algorithmen in Form von Strategien zu realisieren. Da dieser Algorithmus
einen zentralen Teil dieser Arbeit darstellt, wurde er außerdem ausführlich
getestet. Die Testfälle für diesen Algorithmus decken zu diesem Zeitpunkt 90 Prozent
seiner Anweisungen ab.
Die Darstellung der ExecutionModelView selbst geschieht auf Grundlage einer Hierarchie
von Aktivitäten. Hier wurden Profile eingesetzt, um die Darstellung der Aktivitäten
weitgehend von den diesen zugrundeliegenen Elementen des ExecutionModels zu
entkoppeln. Darstellungsaspekte, die von den Elementen des ExecutionModels selbst
abhängen, wurden als konkrete Implementierungen generischer Schnittstellen gekapselt.
Dank dieser Vorgehensweise ist eine gute Änderbarkeit der ExecutionModelView
gewährleistet.
Querschnittsaufgaben, die diverse Komponenten dieser Arbeit betreffen, wurden als
abstrakte Konzepte in den Kern der ViPER-Plattform aufgenommen:
• Abhängig von der Selektion des aktiven TraceEditors heben ExecutionModel-
View und FlowView in ihren jeweiligen graphischen Darstellungen ein dazu
passendes Element farblich hervor. Dieses „highlighting“ eines Elements ist
konzeptionell verschieden von der Selektion eines Elements. Selektion impliziert,
dass die Views ihrerseits das selektierte Element wiederum anderen Work-
88

enchParts zur Verfügung stellen. Dies ist allerdings in diesem Kontext unerwünscht.
Im Rahmen dieser Arbeit wurde das Highlighting-Konzept in Form
einer generischen Implementierung für Views, die mittels GEF realisiert werden,
wiederverwendbar gekapselt.
• Alle Views und der TraceEditor sind SelectionListener und/oder SelectionProvider.
Diese beiden Mechanismen wurden im Konzept der WorkbenchIntegration
zusammengeführt und ihre Nutzung mittels Helferklassen vereinfacht.
Die WorkbenchIntegration-Kapselung erlaubt außerdem die generische
Realisierung der „Link to Editor“-Funktionalität einer View. Dies ist ein Eclipse-
Konzept nach dem sich Views mittels Knopfdruck von Editoren entkoppeln lassen.
Das bedeutet, dass eine entkoppelte View nicht mehr auf die Selektionen
des Editors reagiert und auch umgekehrt dem Editor keinerlei Auswahlen mehr
zur Verfügung stellt.
• Generische Funktionalitäten für den Umgang mit EMF-Modellen aus einer View
oder einem Editor heraus wurden in abstrakten Superklassen abgelegt. Hierbei
gibt es jeweils eine Typhierarchie für Editoren und Views. Die Editor-Superklasse
kapselt beispielsweise eine generische Implementierung zum Speichern der
aktuell geöffneten EMF-Ressource.
Im Laufe der Entstehung der Realisierung wurden Refaktorisierungen durchgeführt,
die hauptsächlich auf die Verbesserung der Wartungsmöglichkeiten abzielten. Beispielsweise
wurde der ursprünglich relativ komplizierte Algorithmus zur Berechnung
der Aktivitätshierarchie zu einer ExecutionModel-Instanz komplett ersetzt durch einen
simpleren und damit besser verständlichen Algorithmus.
89

Kapitel 7
Zusammenfassung und Ausblick
Im Rahmen dieser Arbeit wurden Konzeption und Entwicklung eines Werkzeugs zur
simulierten Ausführung von Anwendungsfällen für die ViPER-IDE beschrieben. Dabei
wurde zunächst das theoretische Fundament in Form des UML-Metamodells und
des NarrativeModels vorgestellt. Das NarrativeModel ist ein Metamodell für strukturierte
natürlichsprachliche Anwendungsfallbeschreibungen.
In der Folge wurden die technischen Grundlagen für die Realisierung der Simulationsumgebung
erläutert. Hier stand die Beschreibung der Eclipse-Plattform und ihrer
zentralen Konzepte im Mittelpunkt. Des Weiteren wurden verschiedene Rahmenwerke
vorgestellt, die für die Realisierung dieser Arbeit von besonderem Interesse sind.
Abgeschlossen wurde dieses Kapitel mit einer Betrachtung der ViPER-IDE und ihrer
diversen Komponenten. Besonderes Augenmerk wurde hierbei auf die Beschreibung
von ViPER NaUTiluS gelegt. NaUTiluS ist die Komponente, die sich mit der natürlichsprachlichen
Beschreibung von Use Cases sowie deren Evaluierung und Simulation
befasst.
Danach wurde der konzeptuelle Lösungsansatz erläutert, in dessen Rahmen zwei Metamodelle
entstanden sind. Das ExecutionModel bildet konzeptionell die Ausführungssicht
auf das NarrativeModel. Es löst die im NarrativeModel vorhandenen Strukturinformationen
auf und nimmt eine atomare Sicht auf einzelne Ausführungsschritte ein.
Das ExecutionModel stellt die Grundlage für die Ausführung der Simulation dar. Als
weiteres Metamodell wurde das SimulationModel vorgestellt, das die Konzepte der
Simulation selbst kapselt.
Auf Basis der konzeptuellen Grundlagen wurde die technische Realisierung beschrieben.
Diese umfasst neben dem Algorithmus zur Berechnung einer ExecutionModel-
Instanz aus einer NarrativeModel-Instanz heraus außerdem die verschiedenen graphischen
Komponenten der Simulationsumgebung. Zu diesen Komponenten gehören die
FlowView zur Visualisierung der statischen Struktur einer NarrativeDescription und
die ExecutionModelView zur graphischen Darstellung und Veranschaulichung einer
ExecutionModel-Instanz in Form navigierbarer Aktivitätsdiagramme. Zur Durchführung
der Simulation selbst dient der Simulator, der sich wiederum zusammensetzt aus
91

dem TraceEditor und der SimulationView. Zuletzt wurden die Integration des Editors
und der einzelnen Views in die Eclipse-Workbench beschrieben. Hierbei wurde
der Mechanismus der SelectionProvider und SelectionListener eingesetzt, um aus den
Einzelkomponenten eine funktionsfähige Simulationsumgebung zusammenzusetzen.
Die darauf folgende Evaluierung unterzog die erzielten Resultate dieser Arbeit einer
Bewertung. Dabei wurde eine Beurteilung sowohl bezüglich der anfänglich formulierten
Anforderungen auf der einen Seite und der allgemein erstrebenswerten softwaretechnischen
Prinzipien und Qualitäten auf der anderen Seite vorgenommen.
Weitergehende Schritte, die auf den Resultaten dieser Arbeit basieren, können in mehrere
Richtungen unternommen werden. Forschungsbedarf besteht in dem Bereich der
Evaluierung von Use Cases und ihrer textuellen Beschreibungen. Für eine gegebene
NarrativeModel-Instanz könnte die dazugehörige ExecutionModel-Instanz als Basis
für den Einsatz von Metriken dienen. Für diesen Zweck müssen geeignete Metriken
konzipiert werden. Denkbar sind beispielsweise Metriken, die der Einschätzung der
Komplexität des modellierten Systems dienen. Frühzeitige Komplexitätsabschätzungen
können einen Anhaltspunkt für das Projektmanagement liefern, ob das Zielsystem
mit den zur Verfügung stehenden Ressourcen realisierbar ist. Grundlage für diese Metrik
könnte beispielsweise das Verhältnis zwischen der Anzahl der EventExecutions in
einem ExecutionModel zur Anzahl der Events im zugrundeliegenden NarrativeModel
sein. Je größer das Verhältnis, desto höher vermutlich die Komplexität des Systems 1 .
Auf der praktischen Seite wird eine Kombination der Simulationsumgebung mit der
bereits existierenden Perspektive zur Bearbeitung von NarrativeModel-Instanzen (vgl.
Abschnitt 3.4.4) angestrebt. Orientiert an der Java-Debug-Perspektive in Eclipse, soll
hierdurch eine Funktionalität entstehen, die es ermöglicht, Modellierung und Simulation
zu verzahnen und so das Modell zu „debuggen“. Voraussetzung für die Umsetzung
dieser Idee ist, dass die Berechnung einer ExecutionModel-Instanz aus einer gegebenen
NarrativeModel-Instanz inkrementell erfolgt. Damit ist gemeint, dass Änderungen
an der NarrativeModel-Instanz isoliert werden und ausschließlich die von den Änderungen
betroffenen Elemente der ExecutionModel-Instanz neuberechnet werden. Es
soll somit an dieser Stelle vermieden werden, eine komplett neue ExecutionModel-
Instanz zu generieren, wenn die repräsentierte NarrativeModel-Instanz modifiziert wird.
Der derzeitige Algorithmus zur Berechnung des ExecutionModels (siehe Abschnitt
5.1) unterstützt dies zu diesem Zeitpunkt nicht. Die für diesen Zweck notwendigen
Modifikationen sind nach einer ersten groben Abschätzung allerdings relativ überschaubar.
1 Ein Event wird durch mehrere EventExecutions repräsentiert, wenn dieser Event in der Ausführung
über verschiedene Wegen erreichbar ist.
92

Literaturverzeichnis
[BP06] BOLDT, NICK und MARCELO PATERNOSTRO: Introduction to the Eclipse
Modeling Framework. Online, 2006.
[BS02] BITTNER, KURT und IAN SPENCE: Use Case Modeling. Addison Wesley
Object Technology, 2002.
[BSM + 03] BUDINSKY, FRANK, DAVID STEINBERG, ED MERKS, RAYMOND EL-
LERSICK und TIMOTHY J. GROSE: Eclipse Modeling Framework: A Developer’s
Guide. Addison Wesley, 2003.
[Coc00] COCKBURN, ALISTAIR: Writing Effective Use Cases. Addison Wesley,
2000.
[CR06] CLAYBERG, ERIC und DAN RUBEL: Eclipse: Building Commercial-
Quality Plug-ins, 2nd Edition. Addison Wesley Professional, 2006.
[DI06] Diagram Interchange, http://www.omg.org/docs/formal/06-04-04.pdf, 2006.
[Do08] DO, HUY: Entwicklung eines Sequenzdiagramm-Editors für die ViPER
Plattform. Diplomarbeit, RWTH Aachen, 2008.
[Ecla] The Eclipse Project, http://www.eclipse.org.
[Eclb] Eclipse Workbench: Using the Selection Service,
http://www.eclipse.org/articles/Article-WorkbenchSelections/article.html.
[Eclc] Inside the Workbench: A guide to the workbench internals,
http://www.eclipse.org/articles/Article-UI-Workbench/workbench.html.
[Ecld] Draw2d Programmer’s Guide, http://help.eclipse.org/help33.
[Ecle] GEF Programmer’s Guide, http://help.eclipse.org/help33.
[EMF] Eclipse Modeling Framework Project, http//www.eclipse.org/emf.
[GEF] Graphical Editing Framework, http://www.eclipse.org/gef.
[GHJV95] GAMMA, ERICH, RICHARD HELM, RALPH JOHNSON und JOHN M.
VLISSIDES: Design Patterns: Elements of Reusable Object-Oriented Software.
Addison Wesley, 1995.
93

[Gom00] GOMAA, HASSAN: Designing Concurrent, Distributed, and Real-Time Applications
with UML. Addison Wesley, 2000.
[Her07] HERMANNS, MARCEL: Erweiterung der ViPER Umgebung zur methodengestützten
Entwicklung mit MeDUSA. Diplomarbeit, RWTH Aachen, 2007.
[Jac87] JACOBSON, IVAR: Object Oriented Development in an Industrial Environment.
In: OOPSLA, Seiten 183–191, 1987.
[JLS] The Java Language Specification, http://java.sun.com/docs/books/jls.
[LL06] LUDEWIG, JOCHEN und HORST LICHTER: Software Engineering - Grundlagen,
Menschen, Prozesse, Techniken. dpunkt.verlag, 2006.
[LN07] LICHTER, HORST und ALEXANDER NYSSEN: MeDUSA - Method for
UML2-based Design of Embedded Software Applications. 2007.
[Mae] Maestro Download Page, http://mars.telascience.org/softwaredownload.
[ML05] MCAFFER, JEFF und JEAN-MICHEL LEMIEUX: Eclipse Rich Client Platform:
Designing, Coding and Packaging Java Applications. Addison Wesley
Professional, 2005.
[Obj03a] OBJECT MANAGEMENT GROUP: UML2.0 OCL Specification,
http://www.omg.org/docs/ptc/03-10-14.pdf, 2003.
[Obj03b] OBJECT TECHNOLOGY INC.: Eclipse Platform Technical Overview.
http://www.eclipse.org/whitepapers/eclipse-overview.pdf, 2003.
[Obj07a] OBJECT MANAGEMENT GROUP: UML Infrastructure Specification,
http://www.omg.org/spec/UML/2.1.2, 2007.
[Obj07b] OBJECT MANAGEMENT GROUP: UML Superstructure Specification,
http://www.omg.org/spec/UML/2.1.2, 2007.
[OMG] Object Management Group, http://www.omg.org.
[OSG] OSGi Alliance, http://www.osgi.org.
[Rat] IBM Rational Rose, http://www.ibm.com/software/rational.
[SWT] The Standard Widget Toolkit, http://www.eclipse.org/swt.
[UML] Unified Modeling Language, http://www.uml.org.
[ViP] ViPER, http://www.viper.sc.
[Wal07] WALTER, ANDREAS: Ein Use Case-Modellierungswerkzeug für die ViPER-
Plattform. Diplomarbeit, RWTH Aachen, 2007.
94