Erweiterung der ViPER-Umgebung zur ... - It works!

Diplomarbeit
Erweiterung der ViPER-Umgebung zur
methodengestützten Entwicklung mit
MeDUSA
von
Marcel Hermanns
Vorgelegt der
Fakultät für Mathematik, Informatik und Naturwissenschaften der
Rheinisch-Westfälischen Technischen Hochschule Aachen
im September 2007
Angefertigt am
Lehr- und Forschungsgebiet Software-Konstruktion
Prof. Dr. rer. nat. Horst Lichter
Gutachter:
Prof. Dr. rer. nat. Horst Lichter
Prof. Dr.-Ing. Manfred Nagl
Betreuer:
Dipl.-Inform. Alexander Nyßen

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 21. September 2007
Marcel Hermanns

Inhaltsverzeichnis
1 Einleitung 1
1.1 Software-Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Softwarekonstruktion - Notationen, Werkzeuge und Methoden . . . . 2
1.3 Eingebettete Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 MeDUSA, UML, ViPER 7
2.1 MeDUSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 ViPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Prozessunterstützung in aktuellen Werkzeugen 33
3.1 Jaczone WayPointer . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Rational Systems Developer . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Vision 41
4.1 Methodenunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Prozessintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Kosten/Nutzen-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Methodenunterstützung 49
5.1 Allgemeine Unterstützung . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Unterstützung der Subsystem Identification . . . . . . . . . . . . . . . 63
6 Prozessintegration 75
6.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3 Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.4 Durchführung der Prozessintegration . . . . . . . . . . . . . . . . . . 95
7 Evaluierung 99
7.1 Prozessintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.2 ViPER PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.3 Methodenunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . 101
8 Zusammenfassung 107
i

1 Einleitung
Die Geburtsstunde des Software-Engineering fällt in das Jahr 1968, als der Informatiker
F. L. Bauer auf einer NATO-Konferenz in Garmisch-Partenkirchen eine provokante
Äußerung an sein Publikum richtete:
The whole trouble comes from the fact that there is so much tinkering with
software. It is not made in a clean fabrication process, which it should be.
What we need, is software engineering.
Der Grund seiner Provokatation war die Mitte der 60er Jahre herrschende Softwarekrise.
Seit der Erfindung der ersten elektrischen Rechenanlage Z3 durch Konrad Zuse
um 1941 hatte die Entwicklung der Hardware rasante Fortschritte gemacht [AFM00].
Aus den verschiedensten Gründen - sei es der nationale Sicherheit wegen oder um des
Profits willen - war versucht worden, die steigende und immer preiswerter werdende
Rechenleistung durch komplexere Programme auszunutzen. Es entstand ein Problem,
dass der niederländische Mathematiker und Informatiker Edsger Wybe Dijkstra in seiner
Dankesrede zum Turingpreis 1972 folgendermaßen formulierte:
[The major cause of the software crisis is] that the machines have become
several orders of magnitude more powerful! To put it quite bluntly: as long
as there were no machines, programming was no problem at all; when we
had a few weak computers, programming became a mild problem, and
now we have gigantic computers, programming has become an equally
gigantic problem. [Dij72]
Die Softwarekrise resultierte also aus dem Scheitern vieler Softwareprojekte. Die mit
der nun höheren Rechenleistung realisierbaren Programme besaßen eine Größe und
Komplexität, die mit den damalig genutzten Techniken nicht mehr handhabbar waren.
Der durch die Rede von Bauer geprägte Begriff des Software-Engineering beschreibt
das Arbeiten an Software nach Ingenieurdisziplinen [LL06], deren Anwendung dazu
führen sollte, Softwareherstellung bewusst und kontrolliert vorzunehmen, um damit
der Softwarekrise zu begegnen. Hieraus hat sich im Laufe der Zeit die stark von Normierungen
und Standards geprägte Form der Softwareentwicklung gebildet.
1.1 Software-Engineering
Im Software-Engineering haben sich vier verschiedene Teilbereiche gebildet (vgl. Abb.
1.1), in denen die einzelnen Disziplinen Anwendung finden. Die Erstellung der Software
wird in einem Projekt durchgeführt, das die Menschen, Tätigkeiten, Interaktionen
1

1 Einleitung
und Resultate verbindet. Mit dem Projektmanagement werden dazu Ziele verfolgt, die
zu einem erfolgreichen Abschluss des Projekts führen. „ [. . . ] »Erfolgreich« bedeutet,
dass das Projekt die definierten Resultate in der geforderten Qualität innerhalb der
vorgegebenen Zeit und mit den vorgesehenen Mittels erzielt [. . . ] “ [LL06].
Abbildung 1.1: Teilbereiche des Software-Engineerings (Vorlesungsskript, Lichter)
Die Qualitätssicherung beinhaltet organisatorische, konstruktive aber auch analytische
Maßnahmen, um die Zielerfüllung der Software in gewissem Maße zu gewährleisten.
Für die Verwaltung von verschiedenen Produktversionen beispielsweise, aber auch
für die Berücksichtigung von Änderungswünschen, ist das Konfigurationsmanagement
verantwortlich. Die eigentliche Softwarekonstruktion bzw. Systemherstellung bildet
nur einen Teil des Software-Engineerings und steht in ständiger Interaktion mit den
anderen Teilbereichen.
1.2 Softwarekonstruktion - Notationen, Werkzeuge und Methoden
Im konstruktiven Teil der Softwareentwicklung werden Programme heutzutage meist
in einer hohen Programmiersprache mit einem Werkzeug entlang einer definierten Methode
entwickelt. Oft werden die drei Bestandteile durch gemeinsame Konzepte verbunden
und bilden dann ein Systemdreieck wie in Abbildung 1.2 dargestellt.
2
Abbildung 1.2: Das Systemdreick

1.2 Softwarekonstruktion - Notationen, Werkzeuge und Methoden
Sprachen und Notationen Bei den ersten Rechenanlagen in den 40er Jahren
mussten Programme in Maschinencode erstellt werden. Mit der Vereinfachung durch
die Einführung von Assembler, war die Programmierung einem ständigen Prozess der
Abstraktion unterworfen. Ab den 50er Jahren kamen verschiedene zumeist prozedurale
Hochsprachen zum Einsatz, deren Quelltext mit verfügbaren Compilern in Maschinenbefehle
übersetzt werden konnte.
Die Einführung der Objektorientierung in den 90er Jahren und die damit verbundenen
Konzepte wie das der Vererbung oder das der Polymorphie sind die Grundlage der modernen
Softwareentwicklung. Programme werden so nicht mehr ausschließlich durch
die Implementierung von Funktionen und Prozeduren erstellt, die eine Eingabe in eine
Ausgabe nach einer Rechenvorschrift umwandeln. Die Objektorientierung erlaubt
das Modellieren von Objekten, die durch Nachrichten miteinander kommunizieren.
Gleichartige Objekte werden durch gemeinsame Klassen beschrieben, die untereinander
wiederum Hierarchien bilden können. Die Verwendung der Objektorientierung
verspricht eine bessere Wartbarkeit; allerdings muss ein schlechteres Laufzeitverhalten
der Programme in Kauf genommen werden. Bei der Entwicklung von Informationssystemen
überwiegen die Kosten der Softwareherstellung und -wartung die Kosten
der Hardware. Um eine bessere Wartbarkeit der Software zu gewährleisten und damit
deren Kosten zu senken, wird aus diesem Grund ein schlechteres Laufzeitverhalten
akzeptiert.
Mit der Einführung der Unified Modeling Language (UML) als Standard am 19. November
1997 wurde ein weiterer wichtiger Eckpfeiler der heutigen Softwareentwicklung
gesetzt. Auf der Basis der Objektorientierung erlaubt die UML das Beschreiben
von Softwaresystemen auf einer abstrakteren Ebene als der der gewählten Programmiersprache
und ermöglicht eine grafische Visualisierung durch verschieden Diagrammtypen.
Aktuelle Ansätze wie die modellgetriebene Softwareentwicklung nutzen
diese Notation, um aus dem Modellierten unmittelbar den Code einer (objektorientierten)
Hochsprache zu generieren.
Werkzeuge Die Werkzeuge der Softwareherstellung durchlebten ebenfalls eine stetige
Weiterentwicklung. Neben den Compilern waren in den Anfängen der Programmierung
wohl Texteditoren die fundamentalen Werkzeuge. Mit ihnen konnte der Quelltext
der jeweiligen Sprache erstellt werden. Weitergehende Editoren konnten durch
Syntax-Highlighting den Code in einer lesbareren Form präsentierten und während
des Editierens auf Syntax-Fehler aufmerksam machen. Andere Einzelwerkzeuge unterstützten
beispielsweise die als Debugging bezeichnete Fehlersuche.
Erst in den letzten Jahren entstanden Werkzeuge, die mehrere Anwendungen vereinen
und als integrierte Entwicklungsumgebungen (IDE) bezeichnet werden. Momentan
sehr populär ist die frei verfügbare Eclipse-IDE, die durch ihre große Anhängerschaft
immer mächtiger wird. Sie unterstützt in ihren diversen Ausprägungen beispielsweise
die Programmierung in verschiedenen Sprachen (z. B. C, C++, Java und neuerdings
auch PHP 5), das Debugging und die Versionskontrolle [Ecl].
3

1 Einleitung
Methoden und Prozesse Heutige Softwareentwicklungsprozesse beschreiben,
wie die Entwicklung von Software nach einem vordefinierten Prozess stattfinden soll.
Sie bilden also den von Bauer erwähnten „Fertigungsprozess“ (fabrication process).
Allgemeine Entwicklungsprozesse, wie beispielsweise der Rational Unified Process
(RUP) [Kru99], beinhalten Aufgaben, die den Handlungsbedarf in allen Teilbereichen
des Software-Engineerings (vgl. Abb. 1.1) berücksichtigen.
Methoden hingegen können zwar Teil eines Entwicklungsprozesses sein, beschränken
sich aber auf die reine Softwarekonstruktion. Bei der Erstellung von Software nehmen
die Entwickler verschiedene Rollen ein, um bei der Bearbeitung von Aufgaben verschiedene
Arbeitsergebnisses zu erstellen. Methoden definieren Regeln, mit denen ein
Entwickler in einer Rolle bei der Wahl seiner Aktionen unterstützt wird [LL06].
Werkzeuge stellten im Laufe der Zeit immer mehr Funktionalität bereit, um die Entwicklung
der Software zu unterstützen. Bis heute gibt es allerdings nur wenige, in
denen ein Entwicklungsprozess bzw. eine Methode integriert ist. Die Unterstützung
beinhaltet oft nur die Beschreibung des Prozesses. Weder wird der konkrete Ablauf
des Prozesses, noch eine spezielle Hilfe bei einzelnen Aufgaben einer Methode im
Werkzeug abgebildet.
1.3 Eingebettete Systeme
Einen spezieller Bereich der Softwareentwicklung stellen eingebettete Systeme dar.
Ein eingebettetes System ist eine Kombination aus Computerhardware und -software,
das zur Erfüllung einer bestimmten Aufgabe erstellt wurde und mechanische oder andere
Komponenten beinhalten kann [Bar99]. Heutzutage befinden sie sich in nahezu
jedem elektrischen Gerät, können aber auch Teil großer Prozessautomatisierungsanlagen
sein.
Sie werden oft tausend- oder millionenfach mit identischer Hard- und Software eingesetzt.
Da ist es naheliegend, dass im Vergleich zu klassischen Informationssystemen
die Kosten der Hardware eine wesentlich wichtigere Rolle spielen. Kann die Software
prinzipiell so konstruiert werden, dass sie mit weniger Hardwareressourcen auskommt,
können die Herstellungskosten damit immens verringert werden. Die Software muss
nur ein einziges mal erstellt werden, die Hardware hingegen für jedes System. Aus
diesem Grund wird versucht, die Hardwarekosten zu minimieren und die Software
mit möglichst effizientem Laufzeitverhalten zu realisieren. In der Praxis wird deshalb
auf die Objektorientierung verzichtet und es wird beispielsweise eine prozedurale Programmiersprache
wie C eingesetzt.
Im Gegensatz zum Bereich der Informationssysteme haben sich im Kontext eingebetteter
Systeme relativ wenige Entwicklungsprozesse bzw. Methoden etabliert. Bruce
Powel Douglass veröffentlichte 1999 ROPES [Dou99] - eine Methode, in der die Konzepte
der UML in der Entwicklung von eingebetteten Systemen Einzug finden sollten
[Dou99]. Knapp ein Jahr später erschien von Hassan Gomaa ein Buch zur COMET
Methode [Gom00], mit der ein ähnlicher Ansatz verfolgt wurde. Beide Autoren ent-
4

1.4 Aufgabenstellung
wickelten auf den jeweiligen Methoden aufbauend weitere Ansätze. Douglass veröffentlichte
Ende 2006 ein Buch, in dem er die Methode Harmony vorstellte, die durch
das Werkzeug Rhapsody unterstützt wird und und in der modellgetriebenen Softwareentwicklung
Anwendung findet [Dou06]. Ein anderes Konzept wird durch Gomaa
aufbauend auf der COMET Methode mit PLUS verfolgt. In seinem Werk, das er im
Juli 2006 veröffentlichte, beschreibt er die Produktlinienentwicklung im Kontext eingebetteter
Systeme.
1.4 Aufgabenstellung
In dieser speziellen Fachdomäne wird am Lehrstuhl für Software-Konstruktion der
RWTH Aachen seit einigen Jahren in Kooperation mit der Industrie eine weitere Methode
entwickelt, die durch ein prototypisches UML-Modellierungswerkzeug unterstützt
werden soll.
Der Bedarf einer neuen Methode entstand dadurch, dass die bestehenden Methoden
für die Entwicklung von speziellen eingebetteten Systemen in einem Unternehmen
keine ausreichende Unterstützung boten. Die COMET-Methode wurde mehrfach den
eigenen Bedürfnissen bei der Entwicklung angepasst und mit der Zeit unübersichtlich.
Aus diesem Grund wird in Kooperation mit dem Lehrstuhl die MeDUSA-Methode
entwickelt, die auf Ansätzen von COMET basiert und auf die besonderen Bedürfnisse
dieser speziellen Domäne eingeht. Im Vordergrund steht hier unter anderem die Use
Case- und modellgetriebene Entwicklung.
Neben der MeDUSA-Methode wurde das auf die Eclipse-IDE basierende Werkzeug
ViPER entwickelt. Diese integrierte Entwicklungsumgebung unterstützt die modellgetriebene
Entwicklung einbetteter Systeme.
Im Rahmen dieser Arbeit soll ViPER dahingehend erweitert werden, dass erste Grundsteine
für die methodengestützte Entwicklung mit MeDUSA gelegt werden. Dabei
müssen im Wesentlichen zwei wesentliche Fragestellungen betrachtet werden:
• Methodenunterstützung: Wodurch kann der Entwickler bei den Aufgaben einer
Methode möglichst optimal unterstützt werden?
• Prozessintegration: Wie kann der zeitliche Ablauf eines Entwicklungsprozesses
in einem Werkzeug abgebildet werden?
1.5 Aufbau der Arbeit
Entlang dieser Leitfragen orientiert und strukturiert sich die gesamte Arbeit. Im Folgenden
Kapitel werden zunächst MeDUSA, ViPER und die UML detailliert vorgestellt.
Die Beschreibung von MeDUSA beruht auf der Unified Method Architecture
(UMA), die unter anderem ein Begriffsmodell zur Definition von Prozessen beinhaltet.
5

1 Einleitung
Entlang dieses Modells ist die Beschreibung von MeDUSA getrennt in eine Darstellung
des Methodeninhalts sowie in eine Schilderung der zeitlichen Abfolge des Prozesses.
ViPER wird anschließend zusammen mit der Eclipse-IDE und verwendeten
Technologien vorgestellt.
Im Kapitel 3 werden aktuelle Werkzeuge der Softwareentwicklung hinsichtlich realisierter
Konzepte für die Methodenunterstützung und Prozessintegration untersucht.
Auf der Basis der in diesem Kapitel identifizierten Konzepte werden in Kapitel 4 mögliche
Hilfestellung für die methodengestützte Entwicklung mit MeDUSA diskutiert.
Kapitel 5 greift mögliche Konzepte einer möglichen Methodenunterstützung auf. Der
Schwerpunkt liegt auf der Entwicklung eines allgemeinen Frameworks, das für die
Unterstützung einer einzelnen Aufgabe eingesetzt werden kann und der prototypischen
Entwicklung für eine Hilfestellung einer speziellen Aufgabe.
Die in Kapitel 4 beschriebenen Aspekte einer möglichen Prozessintegration werden in
Kapitel 6 vertieft und sowohl eine konzeptionelle Lösung als auch deren technische
Umsetzung präsentiert. Unter anderem beinhaltet das Kapitel auch eine Beschreibung
des UMA-Metamodells das - wenn nicht anders kenntlich gemacht - im Rahmen dieser
Arbeit stets verwendet wird, insbesondere für die in Kapitel 2 vorgelegte Beschreibung
von MeDUSA.
Sowohl die Evaluierung der Prozessintegration als auch die der Methodenunterstützung
werden im Kapitel 7 vorgenommen, indem die erstellten Komponenten bzgl. verschiedener
Qualitätsmerkmale bewertet werden. Abgeschlossen wird diese Arbeit mit
Kapitel 8, wo neben einer Zusammenfassung ein Ausblick auf mögliche zukünftige
Arbeiten geliefert wird.
Viele Abbildungen dieser Arbeit sind Bildschirmfotos oder Diagramme einer definierten
grafischen Notation. Der Übersichtlichkeit halber und zur Erklärung wurden den
Abbildungen an einigen Stellen durch rote Markierung kenntlich gemachte Hinweise
hinzugefügt.
6

2 MeDUSA, UML, ViPER
Im Folgenden sollen zunächst die Methode MeDUSA mit dem zugehörigen Prozess
vorgestellt werden und darüber hinaus die relevanten Bestandteile der UML und das
Modellierungswerkzeug ViPER, das um eine Prozessunterstützung für MeDUSA erweitert
werden soll. Zusammen mit der UML als Architekturbeschreibungssprache
bilden sie, verbunden durch gemeinsame Konzepte, wie beispielsweise der Use Caseund
modellgetriebenen Entwicklung, das in Abbildung 2.1 dargestellte Systemdreieck.
Abbildung 2.1: Systemdreieck: MeDUSA [LN07], ViPER [ViP], UML [UML]
2.1 MeDUSA
MeDUSA ist eine Design-Methode für die Erstellung von Software-Anwendungen
eingebetteter Systeme [LN07]. Ihr Einsatzbereich ist beschränkt auf eine spezielle
Fachdomäne, die der so genannten Feldgeräte. Feldgeräte sind kleine eingebettete
Systeme, die in Prozessautomatisierungsanalgen integriert sind und beispielsweise zur
Messung einer Temperatur, eines Drucks oder einer Fließgeschwindigkeit eingesetzt
werden.
Für die Implementierung der Softwaresysteme werden in der Praxis aufgrund der starken
Hardwareeinschränkungen prozedurale Programmiersprachen wie C eingesetzt.
Um eine Abbildung auf eine solche Sprache zu ermöglichen, wird auf das Konzept der
Objektorientierung, inbesondere auf die Vererbung und der darauf aufbauenden Polymorphie,
verzichtet. Der durchgängig objektbasierte Ansatz der Entwicklung in der
Analyse und im Entwurf ist sich durch die niedrige Komplexität der Systeme und der
somit geringen Anzahl zu erstellender Objekte begründet.
7

2 MeDUSA, UML, ViPER
Die folgende Beschreibung von MeDUSA basiert auf der Unified Method Architecture
(UMA), einer Sprache zur Modellierung von Entwicklungsprozessen und Methoden.
Wesentliches Ziel 1 von UMA ist die Trennung von Methodeninhalt und Prozess. Der
Methodeninhalt enthält unter anderem die Aufgaben der Methode, die von den einzelnen
Rollen im Entwicklungsprozess zu bearbeiten sind, um verschiedene Arbeitsergebnisse
zu erstellen. Sowohl die Aufgaben und Rollen als auch die entstehenden
Arbeitsergebnisse werden innerhalb des Methodeninhaltes in Disziplinen gruppiert.
Der Prozess hingegen setzt die Methodeninhalte in zeitliche Abhängigkeiten und definiert
einen Ablauf. Der Abschnitt 6.1.1 beschäftigt sich ausgiebig mit dieser Thematik
und stellt die UMA-Terminologie vor.
2.1.1 Methodeninhalt
Bei der Beschreibung der MeDUSA-Disziplinen wird implizit eine zeitliche Abhängigkeit
vorgegeben, da manche Aufgaben Arbeitsergbnisse anderer Aufgaben referenzieren.
Beispielsweise werden im Context Modelling als Aufgabe der Analyse die im
Use Case Modelling identifizierten Akteure referenziert. Diese implizite Vorgabe des
Ablaufs soll jedoch nicht den Prozess festlegen, sondern lediglich zum Verständnis
dienen.
Requirements
In der objektorientierten Analyse (OOA) werden oft Use Cases eingesetzt, um die
funktionalen Anforderungen an das zu erstellende System aus einer externen Sicht heraus
darstellen zu können. Solche Analysemethoden dienen meist der Modellierung von
Informationssystemen. Nicht-funktionalen Anforderungen bzgl. Hardwareeinschränkungen
spielen eine eher untergeordnete Rolle. Bei eingebetteten Systemen treten diese
nicht-funktionale Anforderungen - also Restriktionen für die Erstellung einer Lösung
- aufgrund der Ressourcenknappheit und Nebenläufigkeit dagegen vermehrt auf.
Mit MeDUSA sollen neben den funktionalen zusätzlich zu den nicht-funktionalen Anforderungen
bereits bei dem Use Case Modelling berücksichtigt werden. Neben der
Erfassung von Use Cases und Akteuren in Diagrammen werden die Szenarien der einzelnen
Use Cases im Narrative Use Case Description Modelling erläutert.
Use Case Modelling Im Use Case Modelling werden die Use Cases des zu erstellenden
Systems und die an der Interaktion für jeden Use Case beteiligten Akteure
in einem UML Use Case-Diagramm erfasst und zueinander in Beziehung gesetzt
[JCJv92]. Ein primärer Akteur stößt die Interaktion für einen Use Case an, sekundäre
Akteure sind passiv beteiligt. Die Attribute primär und sekundär repräsentieren also
Rollen, so dass ein Akteur bezüglich eines Use Cases ein primärer Akteur und bezüglich
eines weiteren Use Cases ein sekundärer Akteur sein kann. Die Taxonomie der
Akteure wird in Abbildung 2.2 dargestellt.
8
1 UMA wird im Kapitel 6.1.1 detailliert vorgestellt

Abbildung 2.2: Taxonomie der Akteure in MeDUSA
2.1 MeDUSA
Neben externen Soft- und Hardwaresystemen, die als device bzw. protocol actor repräsentiert
werden, wird der Auslöser einer Interaktion (ein primärer Akteur) durch einen
trigger actor repräsentiert. In eingebetten Systemen gibt es keine menschlichen Akteure.
Jeder Use Case wird entweder periodisch (timer actor) oder aperiodisch (eventer
actor) von einer Quelle ausgelöst. Die Idee, die mit MeDUSA verfolgt wird, ist
die Trennung der Quelle von dem Ereignis. Während die Quelle durch einen passiven
interface actor repräsentiert wird, stellt ein aktiver trigger actor den Auslöser des
Ereignisses dar.
Sind externe Systeme in der Realität (aktive) primäre Akteure, werden sie also als ein
trigger und ein interface actor modelliert. Abbildung 2.3 zeigt die Modellierung eines
Sensors sowohl durch einen device actor als auch durch einen timer actor. Passive
Akteure, wie z. B. ein externes System zur Anzeige von Informationen (Output Display),
werden lediglich durch einen interface actor repräsentiert. Die Trennung von
der Quelle und dem Ereignis erlaubt die explizite Modellierung von zeitlichen Rahmenbedingungen.
Abbildung 2.3: Trennung von Quelle und Ereignis / Interner Akteur
Die Nebenläufigkeit von Use Cases ist ebenfalls aus einer externen Sicht auf das System
erkennbar (vgl. Abb. 2.3 ): Ein Feldgerät könnte beispielsweise durch einen Sensor
die Flussgeschwindigkeit in einem Rohr bestimmen und daraus verschiedene Wer-
9

2 MeDUSA, UML, ViPER
te wie die Durchflussmenge bestimmen, die dann auf ein externes System übertragen
werden, um dort eine Ausgabe zu erzeugen. Andererseits könnten zeitgleich Wartungsinformationen
des Feldgerätes generiert werden, die auf das gleiche externe System
übertragen werden müssen. Werden beide Szenarien als Use Cases modelliert, und die
für die Ausgabe relevante Kommunikation mit dem externen System durch einen weiteren
Use Case dargestellt, entsteht die Notwendigkeit einer Synchronisation. Es muss
entschieden werden, welche Informationen an das externe System als Nächstes übertragen
werden sollen. Anstatt die beiden nebenläufigen Use Cases jeweils mit dem die
Kommunikation beinhaltenden Use Case durch Assoziationen miteinander zu verbinden,
werden sie wie in Abbildung 2.3 indirekt über einen internen Akteur verknüpft.
Der interne Akteur ist bezüglich der Use Cases Determine Flow Rate und Generate
Maintenance Information sekundärer Akteur. Bezüglich des Use Cases Send Ouput
nimmt er die Rolle eines primären Akteurs ein, da er das mit dem Use Case assoziierte
Verhalten anstößt. Eine ausführliche Diskussion dieser Problematik findet sich in
[NL].
Use Case Description Modelling Für jeden identifizierten Use Case wird eine
textuelle Beschreibung erstellt, die neben den Vor- und Nachbedingungen das Szenario
des Use Cases als Abfolge einzelner Schritte beschreibt. Die Darstellungen des Standardablaufs
und der Alternativabläufe werden mit Hilfe des flow of event-Konzepts
realisiert. Mit diesem Ansatz werden Abläufe als Flüsse von einem Anfangs- zu einem
Endpunkt interpretiert. Ein Fluss kann Erweiterungspunkte enthalten, die bei Alternativabläufen
durch Alternativflüsse erweitert werden können. Bei Vererbungsbeziehungen
können Flüsse zwischen zwei Erweiterungspunkten spezifiziert oder bereits
vorhandene überschrieben werden. Das Konzept der flow of events wird in [WNHL]
vorgestellt.
Analysis
In der Analyse sollen die Gegenstände der Problemwelt erkannt, festgehalten und ihr
kollaboratives Verhalten für die Use Cases beschrieben werden. Das Verhalten von
Objekten, die an mehreren Kollaborationen beteiligt sind, wird jeweils in einem Diagramm
konsolidiert dargestellt. Zuletzt werden Task-Kandidaten ermittelt. Durch eine
erste Abschätzung der CPU-Ausnutzung soll die weitere Entwicklung eines Systems
ausgeschlossen werden, das bereits zu diesem Zeitpunkt als nicht realisierbar eingestuft
werden kann.
Die Analyseobjekte werden entsprechend der in Abbildung 2.4 dargestellten Taxonomie
typisiert. Alle Objekte werden unterteilt in trigger und interface Objekte - analog
zu den Akteuren der Use Cases, in entity Objekte zur Repräsentierung datenintensiver
Objekte, in application logic Objekte zur Kapselung von Algorithmen oder Geschäftslogik
sowie in control Objekte zur Steuerung des Kontrollflusses. Um bei der
Identifikation dieser Objekte systematisch vorgehen zu können, werden sie in verschiedenen
Aufgaben identifiziert. Die erste Aufgabe beschäftigt sich mit der Identifikation
der trigger und interface Objekte. Im anschließenden Information Modelling werden
10

2.1 MeDUSA
die entity Objekte identifiziert und während des Inter-Object Collaboration Modelling
die noch fehlenden und für die Interaktionen der einzelnen Use Cases notwendigen
application-logic und control Objekte modelliert.
Abbildung 2.4: Taxonomie der Analyseobjekte in MeDUSA
Context Modelling Während des Context Modelling sollen alle Soft- und Hardwareschnittstellen
des Systems und damit alle Quellen periodischer oder aperiodischer
Ereignisse durch den Systemanalyst im Context Diagram in Form eines UML Objektdiagramms
festgehalten werden. Die trigger Objekte spiegeln direkt die im Use Case
Modelling identifizierten (externen) trigger Akteure wieder.
Information Modelling Das Ziel des Information Modelling ist das Identifizieren
aller datenintensiven entity Objekte und deren Beziehungen untereinander. Bei der Erstellung
des als UML Objekt-Diagramm realisierten Information Diagram werden alle
in der Realität der Anwendungsdomäne vorhandenen und für das System relevanten
physikalischen Größen identifiziert.
Inter-Object Collaboration Modelling Für jeden einzelnen Use Case wird ausgehend
von dem auslösenden trigger Objekt die Kollaboration der bisher entdeckten
und benötigten Analyseobjekte wahlweise in Kommunikations- oder Sequenzdiagrammen
beschrieben, wobei control und application-logic Objekte identifiziert werden.
Sollte der Use Case keine Assoziation mit einem trigger-Objekt besitzen, weil er beispielsweise
nur als Erweiterung eines anderen Use Cases dient, wird stattdessen das
korrespondierende Analyseobjekt verwendet. Die Kollaboration des Standardablaufs
sollte als Kommunikationsdiagramm modelliert werden. Die Interaktionen für Alternativabläufe
werden zusätzlich als Sequenzdiagramme festgehalten.
Intra-Object Behavioural Modelling Während der Analyse werden vermutlich
einige Objekte identifiziert, die an mehr als einer Kollaboration beteiligt sind, zumindest
fallen einige control und application-logic Objekte darunter. Ziel des Intra-Object
Behavioural Modelling ist nun, das Verhalten dieser Objekte in einem Diagramm konsolidiert
darzustellen.
Das Verhalten von application-logic Objekten kann zustandsabhängig sein, so dass
eine Beschreibung durch Zustandsdiagramme erfolgen sollte. Ansonsten steht es dem
11

2 MeDUSA, UML, ViPER
Systemanalysten frei, das Verhalten von Objekten in verschiedenen Kollaborationen
durch Sequenz- und Aktivitätsdiagramme zu beschreiben.
Task Modelling Bereits im Use Case Modelling wird versucht, das Auftreten von
Nebenläufigkeit zu identifzieren und die dazugehörige Interaktionen im Inter-Object
Collaboration Modelling zu beschreiben. Aus den trigger Objekten und anderen an
der Kollaboration zur Durchführung eines Use Cases beteiligten Objekten sind Task-
Kandidaten identifizierbar, die unter Berücksichtigung der Nebenläufigkeit für eine
Durchführbarkeitsanalyse herangezogen werden können. Die Identifzierung der Task-
Kandidaten wird im späteren Architekturentwurf aufgegriffen, um die tatsächlichen
Tasks zu definieren.
Ein potentiell auf dem Zielsystem zur Laufzeit tatsächlich existierender Thread wird
als Task-Kandidat repräsentiert und bezieht sich auf eine Use Case-bezogene Interaktion
der Analyseobjekte. Der Systemanalyst kann mit Hilfe vordefinierter Angaben
durch Berechnungsverfahren analysieren, ob der modellierte Ansatz überhaupt realisierbar
ist. Dazu können feste Zeitintervallen der timer Objekte und Schätzungen für
das Zeitverhalten von eventer Objekten herangezogen werden.
Dazu müssen die Zeitintervalle des in timer Objekten gekapselten periodischen Verhaltens
herangezogen, bzw. worst case-Schätzungen für das Auftreten der mit eventer
Objekten beschriebenen aperiodischen Ereignisse zur Berechnung der Frequenz
vorgenommen werden, um damit eine Schätzung der CPU-Ausnutzung vornehmen
zu können. Für jeden Task-Kandidaten werden die Ergebnisse im Initial Task Report
festgehalten. Eine Schedulability-Analyse wird auf der Basis der berechneten CPU-
Ausnutzungen anhand eines geeigneten Verfahrens ([LN07], [Gom00]) durchgeführt.
Die Ergebnisse werden im Initial Schedulability Report festgehalten. Bei dieser Analyse
kann das Rapid Prototyping eingesetzt werden, um die Ausführungsdauer schlecht
schätzbarer, komplexer Algorithmen zu messen.
Architectural Design
Ziel des Architectural Design ist die Modellierung einer Lösung, die mit dem Analysemodell
konsistent ist. Dazu werden durch das Partitionieren der Analyseobjekte
Subsysteme erstellt und Struktur- bzw. Verhaltensbeziehungen zwischen den gebildeten
Subsystemen modelliert. Die identifizierten Task-Kandidaten des Task Modelling
werden hierzu aufgegriffen und es wird eine detailliertere Schedulability-Analyse
durchgeführt, um feststellen zu können, ob die entworfene Architektur zu einer Lösung
führen kann.
Subsystem Identification Die Aufteilung der Objekte des Analysemodells in
Subsysteme beeinflusst stark die Leistung des Systems bzw. entscheidet, ob das modellierte
System überhaupt eine Lösung darstellt. Sollte die Partitionierung der Objekte
12

2.1 MeDUSA
einen starken Kommunikationsoverhead verursachen, kann es unter Umständen vorkommen,
dass das für die Ausführung eines einzelnen periodischen Tasks benötigte
Zeitintervall länger ist als die Periode seines Auftretens. Somit wird der Task nicht
beendet werden, bevor er erneut auszuführen ist. Als Folge dessen kann das bisher
modellierte System zu keiner Lösung führen. Um eine gewisse Qualität der Aufteilung
gewährleisten zu können, sind deshalb für die Durchführung Prinzipien und Metriken
vorgesehen, an denen sich der Systemarchitekt orientieren, bzw. mit deren Hilfe er das
Modell bewerten kann.
Während der Partitionierung wird für jedes Subsystem ein Initial Structural Subsystem
Design Diagram erstellt. Diese Arbeitsergebnisse enthalten neben den Analyseobjekten
und ihren Beziehungen die für die Kommunikation mit der Außenwelt notwendigen
Interaktionspunkte, um den Informationsfluss zu externen Systemen oder zu
Objekten anderer Subsysteme berücksichtigen zu können. Für jeden Interaktionspunkt
eines solchen UML Composite Structure-Diagramms wird festgelegt, ob ein Dienst
angeboten oder gefordert wird. Die Signaturen der zugehörigen Schnittstellen werden
in einem weiteren Arbeitsergebnis - dem Initial Subsystem Interface Design Diagram
- entworfen, das als UML Klassendiagramm realisiert wird. Die Methodensignaturen
der Schnittstellen werden zunächst ohne Parameter und Rückgabewerte modelliert.
Structural System Architecture Modelling Während der Subsystem Identification
wurden die Analyseobjekte in Subsysteme partitioniert und es sind Schnittstellen
zu anderen Subsystemen als Interaktionspunkte modelliert worden. Um die erstellten
Subsysteme und ihre Schnittstellen im Systemkontext zu betrachten bzw. zu validieren,
ob die angebotenen den geforderten Schnittstellen entsprechen, wird ein UML
Komponentendiagramm erstellt, in dem die Schnittstellen der Subsysteme miteinander
verbunden werden. Die Signaturen der Schnittstellen werden im Initial Subsystem
Interface Design Diagram um Parameter und Rückgabetypen erweitert.
Behavioural System Architecture Modelling Nachdem die Subsysteme und
deren struktureller Zusammenhang mittels Schnittstellen entworfen worden sind, werden
die in der Inter-Object Collaboration Modelling modellierten Interaktionen der
einzelnen Use Cases unter Berücksichtigung der neu hinzugekommenen interface Objekte
erneut beschrieben. Es sind also die Diagramme derjenigen Interaktionen zu aktualisieren,
deren beteiligte Objekte auf mehr als ein Subsystem verteilt wurden. Das
Arbeitsergebnis wird im Behavioural System Architecture Diagram als Sequenzdiagramm
festgehalten.
Task Design Consolidation Die im Initial Task Report festgehaltenen Task-Kandidaten
werden in dieser Aufgabe herangezogen, um Optimierungspotential zu identifizieren.
Beispielsweise können die in einem Subsystem enthaltenen timer Objekte,
deren Perioden einen größten gemeinsamen Teiler (>1) besitzen, zu einem einzigen
Objekt verschmolzen werden. Des Weiteren könnten eventer Objekte, deren Ereignisse
in keinem Fall zeitgleich auftreten können, durch ein einziges Objekt ersetzt wer-
13

2 MeDUSA, UML, ViPER
den. Durch dieses Verschmelzen solcher trigger Objekte kann die Anzahl der Tasks
verringert werden. Das Ergebnis wird im Consolidated Task Report festgehalten. Die
Schedulability-Analyse wird erneut durchgeführt und liefert den Consolidated Schedulability
Report.
Detailed Design
Das „Innenleben“ jedes Subsystems wird individuell und unabhängig von anderen
Subsystemen entworfen. Eine Konsolidierung, wie sie für aktive Objekte in der Task
Design Consolidation durchgeführt wurde, kann auf Subsystemebene in der Subsystem
Design Consolidation ähnlich für die passiven Objekte durchgeführt werden. Im
Class Design Modelling werden schließlich die Objekte auf Klassen abgebildet.
Subsystem Design Consolidation Auf der Basis des Initial Structural Subsystem
Design Diagrams kann eine Konsolidierung der passiven Objekte erfolgen, indem
einige verschmolzen, andere entfernt und manche auf mehrere Objekte abgebildet
werden. Die Veränderungen werden in den bereits erstellten Arbeitsergebnissen
zur Beschreibung der Struktur bzw. des Verhaltens aktualisiert.
Class Design Modelling Bei der Abbildung der Objekte auf Klassen muss der
objektbasierte Ansatz von MeDUSA berücksichtigt werden und somit auf die Vererbung
verzichtet werden. In vielen Fällen tritt domänenspezifische Funktionalität sich
häufig wiederholend auf, so dass Bibliotheken erstellt bzw. verwendet werden können.
2.1.2 Prozess
Der Prozess setzt laut der Unfied Method Architecture (UMA) Methodeninhalte in zeitliche
Abhängigkeiten. Entsprechend der beschriebenen Disziplinen beinhaltet der Prozess
vier analog benannte Phasen und vier Iterationen. Jede Phase enthält, wie der Abbildung
2.5 entnommen werden kann, die gleichnamige Iteration und die Iterationen
der vorangegangenen Phasen, die optional wiederholt durchgeführt werden können.
Diese Strukturierung des Prozesses soll einerseits durch die Phasen und den zugehörigen
Meilensteinen den Prozessfortschritt anzeigen, aber andererseits auch eine möglicherweise
auftretende Rücksprungdynamik auffangen. Die Diagramme der Phasen
machen durch Entscheidungspunkte deutlich, dass ein Rücksprung in die vorangestellten
Iterationen möglich ist. Des weiteren existiert für jede Iteration ein Aktivitätsdiagramm,
das festlegt, in welcher Reihenfolge die einzelnen Aufgaben bearbeitet werden
können und welche evtl. gleichzeitig bearbeitbar sind.
14

2.2 UML
Abbildung 2.5: Aufteilung des Prozesses in vier Phasen mit den jeweiligen Iterationen
2.2 UML
Die Unified Modeling Language (UML) ist eine von der Object Management Group
(OMG) standardisierte Beschreibungssprache [UML]. Das Einsatzgebiet der UML ist
die Beschreibung von Strukturen, Verhalten und Architekturen, aber auch von Geschäftsprozessen
und Datenbanken [UML]. Im Software-Engineering wird sie eingesetzt,
um statische Strukturen und dynamische Abläufe eines Softwaresystems deskriptiv
oder auch präskriptiv festzuhalten [LL06].
2.2.1 Strukturierung der UML
Die UML beinhaltet ein Metamodell, das ab der Version 2.0 aufgrund seiner Komplexität
durch zwei Spezifikationen definiert wird. Neben dem Metamodell legen die
Spezifikationen die Notation der grafischen Repräsentierung des Modellinhaltes der
Diagramme fest. Zusätzlich wird mit der UML eine formale Spezifikationssprache
(OCL) und ein Standard zum Informationsaustausch von Diagramminformationen definiert:
• UML Infrastructure [Inf07]: Die Infrastructure enthält den Kernel der Superstructure.
Der Kernel umfasst die grundlegenden Metamodell-Elemente der
UML, von denen jedes andere Element direkt oder indirekt abhängig ist. Die
Elemente des Kernel bilden also die Grundlage der UML. Darin enthalten sind
beispielsweise die Elemente Paket, Klasse, Multiplizität und Assoziation.
• UML Superstructure [Obj07]: Der zweite Teil der UML Spezifikation beinhaltet
diverse Konstrukte auf der Basis der UML Infrastructure, die bei der Modellierung
eingesetzt werden. Sie sind entsprechend ihrer Konzepte in Spracheinheiten
aufgeteilt, die nach Struktur und Verhalten gruppiert sind. Als Spracheinheit
werden beispielsweise Interaktionen, Zustandsautomaten oder Use Cases
für die Modellierung von Verhalten bzw. Klassen und Composite Structures
15

2 MeDUSA, UML, ViPER
für die Modellierung von Strukturen bereitgestellt. Neben der Beschreibung des
Metamodells werden aber auch die grafischen Notationen der Diagramme jeder
Spracheinheit definiert.
• Object Constraint Language [OCL06]: Die Object Constraint Language (OCL)
ist eine formale Sprache, die bei der Metamodellierung eingesetzt wird, um Bedingungen
an ein Modell oder Suchanfragen (Queries) über einem Modell zu
formulieren. Da die OCL eine Spezifikationssprache ist, kann sie nicht dazu
verwendet werden, das Modell selbst zu verändern. Das heißt die Auswertung
der formulierten Ausdrücke ist frei von Seiteneffekten: Ausdrücke können eine
Bedingung an den Zustand des Modells stellen, ihn aber nicht verändern.
• Diagram Interchange [DI006]: Die UML Superstructure definiert Spracheinheiten
für verschiedene Anwendungsfälle und legt somit einerseits das Metamodell
und andererseits die grafischen Notationen der Diagramme fest. Für den
Austausch von Diagrammen zwischen unterschiedlichen Modellierungswerkzeugen
und zur standardisierten Serialisierung, wurde für die UML 2 eine weitere
Spezifikation entwickelt. Das Diagram Interchange legt fest, wie Diagramminformationen
persistent abgelegt werden.
Nach dieser groben Übersicht der UML wird nun kurz ein Konzept zur Erweiterung
von Metamodellen und die für MeDUSA relevanten Spracheinheiten der UML Superstructure
detaillierter vorgestellt und durch Beispieldiagramme illustriert. Die mit roter
Markierung kenntlich gemachten Hinweise sind zur Erklärung hinzugefügt worden
und nicht Teil der eigentlichen Inhalte.
2.2.2 Profile
Für die leichtgewichtige 2 Anpassung der UML für verschiedene Einsatzzwecke stellt
die UML Infrastructure einen Erweiterungsmechanismus durch sogenannte Profile zur
Verfügung. Ein Profil beinhaltet Stereotypen, mit denen Modellelemente versehen werden
können. Mit diesen speziellen Metaklassen können UML-Metamodellelemente
implizit erweitert werden. Es entstehd dabei ein Dialekt der UML.
2.2.3 Spracheinheiten
Bei der Entwicklung mit MeDUSA werden verschiedene Diagramme und somit auch
Sprachpakete eingesetzt. Neben den Use Case-Diagrammen und den textuellen Beschreibungen
der Standard- und Alternativabläufe im Requirements (vgl. Abschnitt
2.1.1), gehen aus den Aufgaben der Analyse Objekt- und Interaktionsdiagramme als
Arbeitsergebnisse hervor. Nach der Partitionierung der Analyse Objekte im Architectural
Design werden für die Modellierung der Subsysteme zusätzlich Composite Structure-Diagramme
verwendet.
16
2 d. h. das UML Metamodell bleibt unverändert

Classes
2.2 UML
Das grundlegende Modellierungskonzept der UML sind Classifier und ihre Beziehungen
im Sinne der Objektorientierung. Sie werden in der UML Infrastructure definiert
und in der UML Superstructure wiederverwendet [Obj07]. Ein Classifier ist eine abstrakte
Metaklasse, die eine Klassifikation mehrerer Instanzen darstellt. Ein Classifier
beschreibt also eine Menge von Instanzen bzgl. ihrer Gemeinsamkeiten. Klassen
(Classes), Interfaces aber auch Datentypen sind Beispiele für Classifier und werden
in der UML Superstructure definiert. Ein Attribut eines Classifiers wird als Property
bezeichnet. Da Beziehungen wie Aggregation, Komposition und Assoziation sowie
die Modellierung von Attributen und Methoden allgemein bekannt sind, wird auf eine
minutiöse Beschreibung verzichtet 3 .
Abbildung 2.6: Auszug eines Objektdiagramms aus dem Information Modelling
Neben dem Konzept der Classifier werden Metamodell-Elemente zur Darstellung von
Instanzen des modellierten Systems eingeführt. Eine InstanceSpecification kann eine
Instanz zu einem bestimmten Zeitpunkt oder auch nur einen für den betrachteten Sachverhalt
maßgeblichen Teil repräsentieren. Wie Klassen Attribute besitzen und mit Assoziationen
in Beziehung gesetzt werden können, besteht die Möglichkeit, Werte von
Instanzen durch Slots und Beziehungen durch Links zu modellieren. Eine InstanceSpecification
kann gleichzeitig eine Instanz mehrerer Classifier sein, indem beispielsweise
Mehrfachvererbung eingesetzt wird oder verschiedene Interfaces implementiert werden.
Abbildung 2.6 zeigt die grafische Notation dieser Elemente. Hinter dem Namen
einer InstanceSpecification wird, durch einen Doppelpunkt getrennt, die Namensliste
der Classifier angegeben.
Interactions
Interaktionen beschreiben das Zusammenspiel von verschiedenen Objekten, um ein
spezielles Verhalten des Systems zu gewährleisten. Dabei wird der für die Sicht auf
das System relevante Teil des Innenlebens betrachtet. Instanzen werden durch Lifelines
repräsentiert, die durch Messages miteinander kommunizieren. Jede Lifeline kann
3 für eine genauerer Behandlung dieser Thematik kann [Inf07] herangezogen werden
17

2 MeDUSA, UML, ViPER
lediglich Bestandteil einer einzigen Interaction sein und repräsentiert in den meisten
Fällen eine Property. Die Art und Weise wie Messages an die sendenden bzw.
empfangenden Lifelines gekoppelt werden, ist von dem Typ des Diagramms abhängig.
Wie im dargestellten Kommunikationsdiagramm (Abbildung 2.7) zu sehen, können
sich Messages auf einen Connector zwischen Lifelines beziehen. Die Spracheinheit
Interactions enthält unter andere die Diagrammtypen Sequenzdiagramm und Kommunikationsdiagramm.
Components
Abbildung 2.7: Auszug eines Kommunikationsdiagramms
Mit der Spracheinheit Components können modulare Einheiten mit wohl-definierten
Schnittstellen modelliert werden. Dabei wird in vielen Fällen eine black box-Sicht auf
die Komponenten geworfen, so dass die Implementierung des Inhalts außer Acht gelassen
wird. Durch die Komponenten können beispielsweise Subsysteme innerhalb eines
Systems repräsentiert werden. Eine Komponente ist eine Property eines Structured-
Classifiers. Sie kann eine Schnittstelle aus zweierlei Sichten referenzieren:
1. required: Eine Schnittstelle wird referenziert, mit der eine Komponente festlegt,
welche Funktionalität sie von ihrer Umgebung erwartet.
2. provided: Angebotene Funktionalität kann von einer Komponente für eine wohldefinierte
Schnittstelle bereitgestellt werden.
Wie Abbildung 2.8 verdeutlicht, werden in einem Gesamtkontext (z. B. in einem System)
zusammenpassende Paare von required/provided Schnittstellen der Komponenten
durch die sogenannte ball and socket Notation mit assembly-Konnektoren verbunden.
Die Schnittstellen einer Komponente können mittels Ports organisiert werden, indem
beliebig viele required und provided Interfaces von einem Port aggregiert werden.
18

Composite Structures
Abbildung 2.8: Auszug eines Komponentendiagramms
2.2 UML
Die Spracheinheit Composite Structures dient der Modellierung von Element-Kompositionen.
Ein StructuredClassifier beinhaltet eine interne Struktur, bestehend aus Property-Elementen,
die über Konnektoren miteinander verbunden sind. Diese Elemente
werden Parts genannt. Für die Kommunikation mit der Außenwelt kann ein EncapsulatedClassifier
zusätzlich Ports besitzen, die - ähnlich wie beim Sprachpaket Components
beschrieben - Interfaces aggregieren können. Abbildung 2.9 zeigt ein Composite
Structure Diagramm, das ein mit MeDUSA modelliertes Subsystem als EncapsulatedClassifier
enthält. Die interne Struktur beinhaltet Parts zur Repräsentierung der
dem Subsystem zugeteilten Analyseobjekte.
Abbildung 2.9: Subsystem modelliert im Composite Structure Diagramm
19

2 MeDUSA, UML, ViPER
2.3 ViPER
ViPER ist ein Prototyp einer integrierten Entwicklungsumgebung, mit der die modellgetriebene
Entwicklung auf der Basis von UML unterstützt wird. Mit ViPER (Visual
Modeling Platform for Embedded System Architectures) soll insbesondere die Modellierung
bei der Entwicklung von eingebetteten Systemen bis zum Entwurf unterstützt
werden. Gerade im Zuge dieser Diplomarbeit sind die ersten Grundsteine für die
methodengestützte Entwicklung mit MeDUSA zu legen. ViPER ist als Eclipse Rich-
Client-Platform (RCP) realisiert und verwendet bzw. beinhaltet eine ganze Reihe anderer
Werkzeuge, Frameworks und Technologien. Zunächst werden die grundlegende
Architektur und wichtige Bestandteile von Eclipse erläutert und im Anschluß die von
ViPER genutzen Frameworks beziehungsweise ViPER selbst vorgestellt.
2.3.1 Eclipse SDK
ViPER beinhaltet unter anderem den gesamten Eclipse Software Development Kit
(Eclipse SDK). Grundlage jeder auf Eclipse aufbauenden integrierten Entwicklungsumgebung
ist die Eclipse Platform, die im Folgenden erläutert wird. Im Anschluss
werden die für die spätere Betrachtung relevanten Bestandteile des Eclipse-SDKs vorgestellt.
Eclipse Platform
Die Eclipse Platform ist ein Framework für die Erstellung von integrierten Entwicklungsumgebungen
(IDE) auf der Basis der Programmiersprache Java [Jav]. Für die
Entwicklung einer konkreten IDE kann dieses Framework um Plug-Ins erweitert werden.
Jedes Plug-In besitzt ein sogenanntes Manifest, indem die folgenden Eigenschaften
definiert sind [BSM + 03]:
20
• Required: Jede Abhängigkeit zu anderen Plug-Ins muss explizit in einer required-Liste
angegeben werden. Ein Plug-In ist von einem anderen abhängig, wenn
es Bestandteile desselben verwendet oder erweitert. Zirkularitäten von Abhängigkeiten
sind nicht erlaubt.
• Exports: Java Quelltextdateien werden im Allgemeinen durch Pakete (Packages)
hierarchisch angeordnet. Diejenigen Pakete eines Plug-Ins, die anderen
Plug-Ins zur Verfügung stehen sollen, werden in einer export-Liste definiert.
Ausschließlich die hier aufgelisteten (Java) Pakete können von anderen genutzt
werden.
• Extension Points: Jedes Framework benötigt so genannte hotspots - Stellen an
denen es durch anwendungsspezifischen Code erweitert werden kann. Da das
Framework im Besitz des Kontrollflusses ist, muss die Bekanntmachung des erweiternden
Codes und somit auch die Bekanntmachung der hotspots auf einer

2.3 ViPER
abstrakteren Ebene als die der verwendeten Programmiersprache erfolgen. Für
die Bekanntmachung einer Erweiterung wäre ansonsten der Kontrollfluss notwendig.
In Eclipse werden deshalb sowohl hotspots als auch deren Erweiterungen
im Manifest definiert und als Extension Points bzw. Extensions bezeichnet.
• Extensions: Während Extension Points aufzeigen, welche Stellen eines Frameworks
erweiterbar sind, werden die Erweiterungen selbst durch Extensions gebildet.
Jeder Extension Point legt mittels einer XML Schema Definition (XSD)
fest, welche Informationen die Extension bereitstellen soll. Dies könnte z. B.
der vollständige Namen einer Klasse sein, die ein bestimmtes Interface implementiert,
um spezielle erweiternde Funktionalität zu bieten.
Durch Features können des Weiteren beliebig viele Plug-Ins gruppieren werden, die
gemeinsam eine Funktionalität des Werkzeuges realisieren. Ein solches Feature zeichnet
sich dadurch aus, dass es die kleinste separat installierbare Einheit einer Eclipsebasierten
Entwicklungsumgebung darstellt. Es kann zum einen nur aus Plug-Ins bestehen,
im Sinne einer Werkzeugkomposition allerdings auch weitere Features beinhalten.
Architektur
Auf der Basis der Eclipse Plattform und der damit verbundenen Plug-In Architektur
bildet der Eclipse SDK die „Standard“ IDE. Neben der Platform Runtime, die für die
Auflösung der Plug-In Abhängigkeiten verantwortlich ist, beinhaltet die Eclipse Plattform
zusätzlich grafische Komponenten. Wie aus Abbildung 2.10 hervorgeht, ist in
jedem Fall das Standard Widget Toolkit (SWT) und JFace darin enthalten. SWT ist eine
native Bibliothek zur Erstellung von grafischen Elementen (z. B. Kontroll-, Bild-,
Textelemente) und JFace eine darauf aufbauende weiterführende Bibliothek für komplexere
Komponenten (z. B. Dialoge).
Neben der Eclipse Benutzer-Assistenz, die in der Übersicht als Help dargestellt wird,
definiert die Workbench UI verschiedene Konzepte zur Oberflächengestaltung einer
Eclipse-basierten Entwicklungsumgebung. Durch Perspektiven wird die Oberfläche
der Entwicklungsumgebung kontextabhängige angepasst. Menüstrukturen sind beispielsweise
nur dann sichtbar, wenn sie einen Teil der betrachteten Perspektive sind.
Die Workbench ist aufgeteilt in verschiedene Views. Diese Fenster sind in die Gesamtoberfläche
integriert, und können beliebig nebeneinander und mittels Kartenreiter
übereinander angeordnet werden.
Plug-Ins, Features und auch andere Einheiten werden während der Entwicklung im
Werkzeug als Projekte repräsentiert. Jedem Projekt können mehrere Natures zugeordnet
werden, die als Markierungen interpretiert werden können, um dem Werkzeug
anzuzeigen, welche Typen das Projekt besitzt. Das können, neben den genannten Plug-
Ins und Features, Natures für Java oder eine andere Programmiersprache sein. Die von
dem Projekt beinhalteten Dateien werden als Ressourcen bezeichnet. Alle Projekte und
die dazugehörigen Ressourcen werden in einem speziellen Bereich, dem Workspace,
21

2 MeDUSA, UML, ViPER
Abbildung 2.10: Architektur des Eclipse-SDK (Quelle: [DFK + 04])
verwaltet und gespeichert. Dadurch wird unter anderem sichergestellt, dass zu jedem
Zeitpunkt höchstens durch eine Entwicklungsumgebungen die in einem Workspace
befindlichen Projekte und Ressourcen bearbeitet werden.
Die weiteren in Abbildung 2.10 dargestellten Bestandteile des Eclipse-SDK werden
hier nicht aufgeführt. Stattdessen werden die Benutzer-Assistenz und JFace näher betrachtet.
JFace
JFace eine auf SWT aufbauende Bibliothek für komplexere grafische Komponenten
[SHNM05]. Ein Schwerpunkt liegt auf der Betrachtung von strukturierten Daten nach
dem Model-View-Controller (MVC) 4 Architekturmuster. Es wird nicht nur der Inhalt
(das Model) von der Ansicht (der View) getrennt, sondern zusätzlich auch die Repräsentierung
eines Elements von der Struktur. Für ein anzuzeigendes Element muss
ein LabelProvider realisiert werden, der Text und ein Bild für die Anzeige definiert.
Ein ContentProvider beinhaltet Schnittstellen, mit dem hinsichtlich der baumartigen
Struktur die untergeordneten Elemente abgefragt werden können oder das übergeordnete
Element zu bestimmen ist.
Der zweite Schwerpunkt von JFace wird durch verschiedenste Dialoge gebildet. Besonders
interessant sind Wizards, mit denen komplexe Aufgaben in kleinere, sequentielle
Aufgaben zerlegt werden können, die dann in einer bestimmten Reihenfolge aus-
22
4 Architekturmuster nach dem Prinzip der Trennung von Interaktion und Funktion, [LL06]

2.3 ViPER
geführt werden müssen [EHLK04]. Dazu wird dieser Dialog als Modalfenster 5 realisiert
und beinhaltet mehrere Seiten, zwischen denen der Benutzer wechseln kann.
Üblicherweise werden auf den Wizard-Seiten Einstellungen vorgenommen, um eine
definierte Aktion durchführen zu können. Nach den Eclipse User Interface Guidelines
[EHLK04] besitzt ein Wizard vier Schaltflächen:
1. Next: Anzeigen der nächsten Seite
2. Previous: Anzeigen der vorherigen Seite
3. Cancel: Abbruch des Dialogs
4. Finish: Beenden des Dialogs und evtl. Ausführung der mit dem Wizard verbundenen
Aktion
In Eclipse gibt es eine ganze Reihe verschiedener Wizards. Als Standardbeispiel wird
in der Dokumentation des Öfteren ein Projektwizard herangezogen. Auf den einzelnen
Seiten kann der Benutzer Einstellungen treffen und mit dem Aktivieren der Schaltfläche
Finish wird die eigentliche Aktion durchgeführt - die Erstellung eines neuen
Projekts.
Benutzer-Assistenz
Auf Eclipse basierende Rich-Client Plattformen besitzen eine integrierte Benutzer-
Assistenz, die neben dem statischen Hilfesystem und einer kontextabhängigen dynamischen
Hilfe durch sogenannte CheatSheets gebildet wird. Jedes dieser Konzepte kann
in einem Plug-In durch Extensions zu definierten Extension-Points erweitert werden.
Abbildung 2.11 zeigt den Aufbau des Hilfesystems. Auf der linken Seite befindet sich
eine baumartige Struktur zur Navigation, deren Knoten mit Inhalten verknüpft sind,
die auf der rechten Seite angezeigt werden. Für den statischen Inhalt werden u. a.
Suchfunktionen, das Anlegen von „Lesezeichen“ und das Ausdrucken der betrachteten
Seite angeboten. Der Inhalt des Hilfesystems (vgl. Abb. 2.11, rechter Teil) wird durch
HTML-Dateien definiert. Die Navigation wird durch sogenannte table-of-contents Dateien
auf der Basis von XML erstellt.
CheatSheets dienen der Durchführen von Abläufen und werden oft für „Tutorials“
eingesetzt, um den Benutzer durch ihn unbekannte Vorgänge zum Erreichen eines bestimmten
Ziels zu führen. Der Benutzer muss die dafür festgelegten, meist sequentiell
angeordneten Schritte abarbeiten, kann referenzierte Seiten des Hilfesystems öffnen
und abgelegte Aktionen ausführen. Das gezeigte CheatSheet im Inhaltsbereich der in
Abbildung 2.11 dargestellten Hilfeseite zeigt die dafür notwendigen Kontrollelemente.
Durch das Betätigen eines Fragezeichen-Symbols wird die damit verknüpfte Hilfeseite
geöffnet. Die Aktivierung des Abspielknopfs mit dem Text „Click to perform“ führt
eine Aktion aus (in dem Beispiel würde ein Wizard gestartet werden).
5 Ein Fenster das die restliche Anwendung solange blockiert, bis es selbst wieder geschlossen wird
23

2 MeDUSA, UML, ViPER
Abbildung 2.11: Bildschirmfoto: Beispiel des Eclipse-Hilfesystem
Die Anzahl der modellierbaren Hierarchiestufen von CheatSheets ist sehr begrenzt. Eine
nach oben beliebig erweiterbare Struktur kann dagegen durch den Einsatz von CompositeCheatSheets
erreicht werden, indem die Möglichkeit besteht, Elemente rekursiv
zu verschachtelt. Der durch die Rekursion aufgespannte Baum enthält als Blätter Referenzen
auf CheatSheets. Sowohl Composite-CheatSheets, als auch CheatSheets, sind
durch eine Grammatik definiert und werden in XML-Dateien abgelegt.
2.3.2 Eclipse Modeling Framework (EMF)
Das Eclipse Modeling Framework dient der Metamodellierung und der Handhabung
und Serialisierung von Metamodell Instanzen. Auf der technischen Seite beinhaltet das
unter anderem eine Java Code-Generierung, um mit den Modellen programmatisch
umgehen zu können:
24

2.3 ViPER
• EMF.Core stellt Mechanismen für die Metamodellierung bereit und definiert
dafür ein eigenes (Meta-)Metamodell namens Ecore
• EMF.Codegen ermöglicht die Generierung von Code ausgehend vom erstellten
Metamodell
• EMF.Edit dient der Handhabung von Instanzen eines Metamodells und stellt
Funktionalität für das Editieren und die graphischen Repräsentierung bereit
Ecore - das EMF-Metamodell
EMF definiert für die Metamodellierung ein eigenes, sehr schmales Metamodell namens
Ecore, das identisch zu einem kleinen Teil des vorgestellten UML-Kernels (vgl.
Abschnitt 2.2.1) ist. EMF ermöglicht eine Vereinheitlichung von XSD, Java und der
UML, indem ein damit definiertes Metamodell in ein Ecore-Modell umgewandelt werden
kann. Es ist also möglich, ein eigenes Metamodell mit Hilfe der UML zu definieren
- beispielsweise unter Verwendung eines Klassendiagramms - und dieses in ein
Ecore-Modell zu transformieren.
Der Kern des Ecore-Metamodells wird durch den in Abbildung 2.12 dargestellte strukturelle
Zusammenhang zwischen EClass, EReference und EAttribute gebildet. Elemente
eines zu erstellenden Metamodells werden als EClasses modelliert. Instanzen
eines Elementes können wiederum andere Instanzen beinhalten oder verwenden. Dieses
Referenzieren von anderen Elemente wird im Metamodell durch die Verwendung
von EReference-Elementen modelliert. Der Parameter containment gibt an, ob es sich
um eine Komposition oder Assoziation/Aggregration handelt. Attribute in Form von
primitiven Datentypen werden mit Hilfe des Ecore Elements EAttribute definiert. Ecore
stellt weitere Metamodell-Elemente zur Verfügung, die an dieser Stelle allerdings
nicht vorgestellt werden. Genauere und weiterführende Informationen finden sich in
[BSM + 03].
Abbildung 2.12: Auszug aus dem Ecore - Metamodell (Quelle: [BSM + 03])
Code-Generierung
Das primäre Ziel von EMF ist die Handhabung von Metamodellen bzw. deren Instanzen
was auf technischer Seite durch die Programmiersprache Java realisiert wird. Auf
25

2 MeDUSA, UML, ViPER
der Basis des erstellten Ecore-Modells kann deshalb eine Code-Generierung angestoßen
werden, bei der das Entwurfsprinzip der Trennung von Schnittstelle und Implementierung
6 verfolgt wird. Für jedes Element des erstellten Metamodells wird sowohl
ein Interface als auch eine Klasse und die modellierten Methoden, Attribute, Referenzen
und entsprechende Zugriffsmethoden generiert. Zusätzlich wird der folgende Code
generiert:
• Factory: Elemente des Metamodells werden nicht direkt, sondern unter Verwendung
einer Factory ,instanziert.
• Notifier und Adapter: Um auf Veränderungen eines Modellelementes aufmerksam
machen zu können, wird das Observer-Muster eingesetzt. Bei dem beobachteten
Objekt (Rolle Notifier) können sich andere Objekte (Rolle Observer)
registrieren, die bei Änderungen benachrichtigt werden. Das Entwurfsmuster
wird an dieser Stelle mit dem das Objekt-Adapter-Muster kombiniert. Die sich
registrierenden Observer nehmen gleichzeitig die Rolle Adapter bzgl. des beobachtenden
Objektes ein. Diese Kombination erlaubt es dem beobachtenden
Adapter, die Funktionalität eines beobachteten Objektes Notifier für einen bestimmten
Kontext zu erweitern und dabei gleichzeitig auf Änderungen des Objektes
geeignet reagieren zu können. Jede für ein Metamodell-Element generierte
Klasse implementiert die Rolle Notifier. Ein Beispiel für einen beobachtenden
Adapter ist der ItemProvider.
• ItemProvider: In Eclipse gibt es verschiedene Mechanismen Modellinformationen
anzuzeigen. Mittels TreeViewern können, wie in Abschnitt 2.3.1 beschrieben,
baumartige Strukturen dargestellt werden, während PropertyViewer dem
Anzeigen von Details eines ausgewählten Objektes dienen. EMF generiert für jede
Klasse (also für jedes Element des erstellten Metamodells) sogenannte Item-
Provider, die als Adapter die Instanzen dahingehend um Funktionalität erweitern,
dass sie in den verschiedenen Ansichten angezeigt werden können. Sie implementieren
also gleichzeitig den Label- und ContentProvider. Wie beschrieben
fungieren sie durch die Registrierung als Adapter ebenfalls als Observer, so
dass Modelländerungen auch unmittelbar in den Ansichten berücksichtigt werden.
• Präsentation: Als Hilfestellung für die Erstellung von Modellen wird automatisch
ein Wizard generiert und zur Betrachtung und Bearbeitung eines Modells
wird ein Editor inklusive eines TreeViewers erstellt.
Reflective API
Durch die Code-Generierung werden modellierte Methoden, Attribute und Referenzen
unmittelbar auf Java-Code abgebildet. Um einen allgemeinen Zugriff auf die Attribute
und Referenzen von Instanzen eines beliebigen Metamodells zu ermöglichen, exis-
26
6 Für die auch im Folgenden genannten Entwurfsprinzipien und -muster kann [LL06] herangezogen
werden

2.3 ViPER
tiert neben der generierten API eine weitere, vom erstellten Metamodell unabhängige,
sogenannte reflective API, die durch das Ecore Metamodell bereitgestellt wird. Dazu
definiert EMF generische Methoden, mit denen ein Attribut oder eine Referenz unter
Verwendung einer eindeutigen ID, aber ohne Kenntnis der eigentlichen Zugriffsmethode,
verändert bzw. hinzugefügt oder entfernt werden kann.
Command-Framework
Des Weiteren gibt es ein Framework zur Handhabung von Modelländerungen. Das
Command-Framework sieht vor, jede Änderungen des Modells in einem Command zu
kapseln, der dann auf einem Stack (dem Command-Stack) ausgeführt wird. Realisiert
ein Command undo- bzw. redo-Operationen, so sind die Modelländerungen mit Hilfe
des Command-Stacks widerrufbar bzw. erneut durchführbar. Für den Einsatz mit
EMF sind vordefinierte Commands implementiert, die das Erstellen von Objekten und
das Ändern von Attributen und Referenzen erlauben. Zusätzlich existieren Compound-
Commands, die als Komposition beliebiger anderer Commands eingesetzt werden können,
um damit mehrere Commands als atomare Einheit zusammenzufassen. EMF realisiert
darauf aufbauend Commands zum Kopieren von Objekten.
Commands können erst durch die Metamodell-unabhängige reflective API und der generischen
Handhabung von beliebigen Objekten realisiert werden. Sie können durch
Angabe des betroffenen Objektes, der ID des Attributes oder der zu benutzenden Referenz
und dem neuen Wert bzw. des hinzuzufügenden oder zu entfernenden Objektes
erstellt und ausgeführt werden.
Objekt-Serialisierung
Modellinstanzen eines mit EMF definierten Metamodells werden in Resourcen abgelegt,
deren Inhalt persistent in Dateien gespeichert werden kann. Für die Serialisierung
wird das XML Metamodel Interchange (XMI) Format verwendet [XMI05]. Dadurch,
dass nicht alle Objekte eines Modells in einer einzigen Ressource abgelegt werden
müssen, können Objekte eines anderen Modells referenziert werden.
2.3.3 openArchitectureWare (oAW)
ViPER ist eine integrierte Entwicklungsumgebung zur Unterstützung der modellgetriebenen
Softwareentwicklung. Vorraussetzung für die Realisierung dieser Unterstützung
ist die Generierung von Code aus einem UML-Modell. ViPER nutzt dafür das
openArchitectureWare (oAW) Framework, mit dem Modell-zu-Modell Transformationen
und Modell-zu-Code Generierung programmatisch durchgeführt werden können.
oAW beinhaltet drei Komponenten für die Transformation, Generierung und Validierung,
die jeweils eigene funktionale Sprachen verwenden.
27

2 MeDUSA, UML, ViPER
Jede dieser Sprachen berücksichtigt Vererbung und Polymorphie. Es können sowohl
die allgemein definierten Methoden eines Modells auf den generierten Klassen aufgerufen
werden, als auch statische Java-Methoden als Extensions. Zusätzlich zu den drei
genannten Komponenten gibt es eine Workflow-Komponente zur konkreten Durchführung
einer Transformation, Generierung oder Validierung.
Xtend Modell-zu-Modell Transformationen können mit der Sprache XTend realisiert
werden. Die für die Transformation definierten Funktionen werden als Extensions bezeichnet.
Eine Extension erhält üblicherweise ein oder mehrere Objekte des abzubildenen
Modells und erstellt ein entsprechendes Objekt des Zielmodells. Dafür greift oAW
auf das mittels ECore beschriebene Metamodell durch Nutzung der reflective API (vgl.
2.3.2) zu, um die Werte der abzubildenen Objekte lesen bzw. die Werte des Zielobjekts
setzen zu können. Zusätzlich stellt XTend eine API mit Hilfsfunktionen bereit.
XPand Für die Modell-zu-Code Generierung stellt oAW eine weitere Sprache zur
Verfügung, mit der sogenannte Templates definiert werden können. Die mit XPand
definierten Dateiinhalte bestehen aus dem zu generierenden Code bzw. aus aufzulösenden
Funktionsaufrufen.
Check Bevor ein Modell transformiert bzw. daraus Code generiert wird, sollte es
auf Validität überprüft werden, um die Erstellung eines korrekten Ergebnisses gewährleisten
zu können. Für die Validierung stellt das oAW Framework eine weitere, regelbasierte
Sprache zur Verfügung, die der Object Constraint Language (OCL) 7 ähnelt.
Bedingungen, die an ein Modell gestellt werden, sind von Anwendungsfall zu Anwendungsfall
unterschiedlich und können deshalb nicht mit Hilfe der OCL im Modell
verankert werden. Mit Hilfe der check-Komponente kann nun eine anwendungsspezifische
Validitätsprüfung realisiert werden.
Workflow Die Workflow-Komponente dient dazu, die entsprechende Transformation
bzw. Generierung durchzuführen. Es müssen die verwendeten Metamodelle spezifiziert
werden sowie das abzubildende Ausgangsmodell und optional ein Postprocessor
angegeben werden. Eine mögliche Realisierung eines Postprocessors bestünde darin,
den generierten Code zu formatieren. Die check-Komponente kann eingesetzt werden,
um das Ausgangsmodell vor der Durchführung zu validieren.
2.3.4 Architektur
Auf der Basis der Eclipse Plug-In Architektur gliedert sich die ViPER IDE im Wesentlichen
in die ViPER Platform und in ViPER UML2, wie in Übersicht 2.13 dargestellt.
28
7 OCL ist eine prädikatenlogische Sprache zur Formulierung von Bedingungen, die an Instanzen eines
Modells gestellt werden. Für nähere Informationen siehe [OCL06]

2.3 ViPER
Die ViPER Platform ist - bestehend aus drei Features - das Fundament von ViPER und
dabei völlig unabhängig von der UML. ViPER Core bietet zusätzliche Funktionalität
für die Verwendung des Eclipe Modeling Framework (EMF). Das ViPER Modeling
Transformation Framework (MTF) dient der allgemeinen Unterstützung von Modelltransformationen
und Code-Generierung und nutzt das Werkzeug openArchitecture-
Ware (oAW).
Abbildung 2.13: Architektur von ViPER
Für die Erstellung von Diagrammeditoren stellt die Plattform das ViPER Visual Modeling
Framework (VMF) zur Verfügung, das auf dem Graphical Editing Framework
(GEF) aufbaut. Parallel zur ViPER Platform sind in ViPER UML drei Features realisiert,
die jeweils die der Plattform erweitern. ViPER Codegen realisiert die Code-
Generierung auf der Basis von UML-Modellen.
Im Kontext dieser Diplomarbeit sind lediglich die Features ViPER Core und ViPER
MTF von Relevanz, die nun detaillierter beschrieben werden.
2.3.5 ViPER Core
Durch ViPER Core wird EMF in die ViPER Plattform integriert und zusätzliche Funktionalität
bereitgestellt. Zum einen werden Commands zur Erstellung, zum Löschen
und zum Umbenennen von Ressourcen zur Verfügung gestellt und zum anderen enthält
ViPER Core Operationen zur Handhabung der Modell-Ressourcen. Zusätzlich beinhaltet
dieses Feature unter Verwendung von SWT und JFace einige Dialoge und Wizards
zur Erstellung von Ressourcen und Modellinstanzen.
29

2 MeDUSA, UML, ViPER
2.3.6 ViPER MTF
Mit ViPER MTF wird das Ziel verfolgt, den Einsatz von oAW zu vereinfachen, indem
die Handhabung der Transformation, wie in Abbildung 2.14 dargestellt, durch eine
TransformationUnit gekapselt wird 8 .
Abbildung 2.14: TransformationUnit in ViPER MTF
Die TransformationUnit beinhaltet alle Bestandteile, die für die Transformation notwendig
sind:
30
• IModelReader: das serialisierte Modell muss aus einer Datei gelesen werden,
bevor es transformiert werden kann. Sollte das dazugehörige Metamodell mittels
EMF konstruiert worden sein, kann der Standard XMIModelReader verwendet
werden.
• CheckComponent: für die Validierung von Instanzmodellen eines Metamodells
werden mit der Sprache check Regeln definiert, die ausgehend von den Wurzelelementen
kaskadiert angewendet werden. Der Aufruf der ersten Regel für das
Wurzelelement wird in der CheckComponent definiert.
• TransformationComponent: analog zur stufenförmigen Anwendung von Regeln
in der check-Komponente werden bei der Transformation die mittels XTend bestimmten
Extensions ausgewertet. Die TransformationComponent kapselt die
initiale Extension. Für die Transformation können zusätzliche Parameter angegeben
werden.
• PostProcessor: ein Postprocessor kann für die Formatierung von Code verwendet
werden. Modellinstanzen werden mit dem XMI-Format und somit einer spe-
8 Die entsprechende Klasse GenerationUnit zur Kapselung der Generierung ist analog aufgebaut

2.3 ViPER
ziellen Form von XML abgelegt, so dass ein XMLBeautifier genutzt werden
kann. Wesentlich wichtiger als bei der Serialisierung von Modellinstanzen ist
die Verwendung eines Postprocessors bei der Generierung von Quelltext, der
Entwicklern als Basis für die weitere Entwicklung dient. In diesem Fall muss
die Lesbarkeit des Quelltextes gewährleistet sein.
Des Weiteren stellt ViPER MTF Dialoge zur Durchführung einer Transformation bzw.
Generierung bereit, denen die zu verwendenden TransformationUnits bzw. GenerationUnits
übergeben werden.
31

2 MeDUSA, UML, ViPER
32

3 Prozessunterstützung in aktuellen Werkzeugen
Nachdem im letzten Kapitel MeDUSA, ViPER und die relevanten Teil der UML vorgestellt
wurden, sollen in diesem Kapitel aktuelle Werkzeuge der Softwaremodellierung
hinsichtlich der in der Einleitung beschriebenen Leitfragen untersucht werden:
• Methodenunterstützung: Wodurch kann der Entwickler bei den Aktivitäten einer
Methode möglichst optimal unterstützt werden?
• Prozessintegration: Wie kann der zeitliche Ablauf eines Entwicklungsprozesses
in einem Werkzeug abgebildet werden?
Eine Betrachtung der Werkzeuge WayPointer und Rational System Developer anhand
dieser Leitfragen soll erste Kenntnisse darüber liefern, wie Prozess- und Methodenunterstützungen
realisiert werden können. Die gewonnenen Erkenntnisse werden unter
Berücksichtigung der ViPER IDE am Ende dieses Kapitels evaluiert, um als Grundlage
einer im nächsten Kapitel beschriebenen Vision zu dienen.
3.1 Jaczone WayPointer
Die Firma Jaczone stellt mit ihrer kommerziellen Entwicklungsumgebung WayPointer
[APF] ein agentenbasiertes Werkzeug zur UML-Modellierung bereit, das den Rational
Unified Process (RUP) ([Kru99]) unterstützt. Wie Abbildung 3.1 zeigt, werden diese
drei Bestandteile verbunden durch das gemeinsame Konzept der Use Case-getriebenen
Entwicklung. WayPointer bildet die Grundlage einer Werkzeuglandschaft, mit der die
Entwicklung unterstützt wird.
Abbildung 3.1: Systemdreieck - RUP [Kru99], WayPointer [APF], UML [UML]
33

3 Prozessunterstützung in aktuellen Werkzeugen
Werkzeugintegration Während der Softwareentwicklung kommen üblicherweise
verschiedene Werkzeuge zum Einsatz. Auf der einen Seite muss die Möglichkeit bestehen,
eine Architektur zu modellieren, Code zu generieren und programmieren zu
können. Auf der anderen Seite müssen aber auch textuelle Dokumente wie Testfälle,
Dokumentationen und Use Case Beschreibungen verfasst werden. Somit werden
bei der Entwicklung im Allgemeinen mindestens zwei Werkzeuge eingesetzt: ein Modellierungswerkzeug
und ein Textverarbeitungsprogramm. Der verwendete Softwareentwicklungsprozess
wird oft nur implizit „gelebt“, da er nicht durch die jeweiligen
Werkzeuge unterstützt wird.
Abbildung 3.2: Werkzeugintegration in WayPointer [Jac06]
Mit WayPointer wird nun das Ziel verfolgt, die unterschiedlichen Werkzeuge zusammenzufassen
und den Software-Prozess (z. B. den RUP) stärker zu berücksichtigen.
Wie Abbildung 3.2 darstellt, bildet WayPointer die Grundlage einer Werkzeuglandschaft.
Für das Erstellen von textuellen Dokumenten muss ein spezielles Textverarbeitungssystem
integriert werden. Für die UML-Modellierung kann ein Werkzeug aus
einer fest vorgegeben Liste ausgewählt werden. WayPointer bewirkt eine Synchronisation
mit dem Modellierungswerkzeug, so dass Änderungen eines Modells im Modellierungswerkzeug
unmittelbar durch WayPointer berücksichtigt werden und ebenso
umgekehrt.
WayPointer soll nun hinsichtlich der Methodenunterstützung betrachtet werden. Der
zentrale Begriff ist dabei der des aktive Prozesses.
Aktiver Prozess Als aktiver Prozess wird abstrakt das Verhalten von WayPointer
bei der konkreten Durchführung des integrierten Entwicklungsprozesses bezeichnet.
Bei der Benutzung des Werkzeuges passen sich die Oberfläche und das Verhalten der
durch den Benutzer gewählten Rolle, z. B. durch die Auswahl der zur Verfügung stehenden
Aktivitäten, dynamisch an.
Die standardmäßige Integration des RUP deckt allerdings nicht alle Disziplinen ab. Es
werden lediglich die Diziplinen Requirements und Analysis & Design unterstützt. Die
einzelnen Aktivitäten 1 werden nicht identisch repräsentiert. Beispielsweise werden die
34
1 nach der UMA-Terminologie Aufgabe, im Kontext des RUPs weiterhin Aktivität

3.1 Jaczone WayPointer
Aktivitäten „Find Actors and Use Cases“ und „Structure the Use Case Model“ des
RUP in WayPoiner zusammengefasst zu der Aktivität „Develop the Use Case Model“.
Das Abbilden mehrerer RUP Aktivitäten auf eine Einzige in WayPointer wird dadurch
begründet, dass die im RUP modellierten Aktivitäten im aktiven Prozess gleichzeitig
bearbeitet werden (müssen). Die Aktivitäten und die Unterstützung bei der Erstellung
von Arbeitsergebnissen werden durch Agenten realisiert, die der Interaktion mit dem
Entwickler dienen.
Abbildung 3.3: Regelverstoß und Vorschlag zur Beseitigung [Jac06]
Agenten Die wichtigsten Ausprägungen des aktiven Prozesses sind sogenannte intelligente
Agenten, Regeln und Vorschläge. Agenten besitzen Wissen und sind fähig,
dieses durch ein proaktives Verhalten geeignet einzusetzen, um den Entwickler bei der
Durchführung einer Aktivität interaktiv unterstützen zu können. Es gibt drei Arten von
Agenten [Jac06]:
• Aktivität: Jede Aktivität des aktiven Prozesses wird durch einen Agenten repräsentiert.
• Wizard: Durch Wizards werden komplexe Aktivitäten mit einer sequentiellen
Bearbeitung unterstützt.
35

3 Prozessunterstützung in aktuellen Werkzeugen
• Artefakt-Agent: Artefakt-Agenten sollen dem Entwickler bei den unterschiedlichen
Modellierungsaufgaben helfen und bieten durch definierte Regeln die
Möglichkeit der Konsistenz-, Vollständigkeits- und Korrektheitsprüfung des gerade
bearbeiteten Modells. Durch Korrekturvorschläge ist es möglich, diesen
Regelverstoß aufzuheben.
Die Interaktion mit Agenten wird über den in Abbildung 3.3 dargestellten WayPointer
Highlighter realisiert. Aktivitäten und Schritte werden in einer Baumansicht grafisch
repräsentiert und für Regelverstöße werden Korrekturvorschläge angezeigt.
Abbildung 3.3 zeigt ein Beispiel für die Use Case-Modellierung. Die Aktivität „Develop
the Use-Case Model“ beinhaltet unter anderem den Schritt „Find actors“. Im
Artefakt-Agenten des use case models ist eine Regel definiert, die besagt, dass das
Use Case Modell mindestens einen Akteur besitzen muss. Der Hinweis auf den Regelverstoß
mit zugehörigem Korrekturvorschlag wird ebenfalls dargestellt.
Prozessintegration Eine Unterstützung bei der konkreten Durchführung eines
Prozesses, d.h. eine Integration des Ablaufs ist in WayPointer nicht vorzufinden. In
einer Werbeschrift der Firma Jaczone heißt es zwar:
The WayPointer Active Process Framework enables you to turn your static
process description into Active Process applications [APF]
Doch die suggerierte Abbildung des statischen Prozesses auf eine dynamische Begleitung
durch den Ablauf des Prozesses existiert nicht. Während das vorgestellte Konzept
der Agenten und Regeln dynamisch auf Interaktionen des Benutzers und Änderungen
des Modells eingeht, wird der Ablauf des Prozesses „nur“ statisch durch eine Repräsentierung
des Arbeitsstrukturbaums, wie Abbildung 3.4 zeigt, vor Augen geführt. Der
Benutzer kann stets selbst entscheiden, ob und in welcher Reihenfolge er die Aktivitäten
bearbeitet.
Wie die Abbildung außerdem zeigt, kann für jede Aktivität eine (spezifische) Hilfe
aufgerufen werden. Diese gibt unter Verwendung der RUP Konfiguration Auskunft
darüber, wie die jeweilige Aktivität bearbeitet bzw. erledigt werden kann.
Konfiguration und Erweiterbarkeit Die Einstellungen der Agenten und die Definition
der Regeln auf Basis vordefinierter, beschränkter Auswahlmöglichkeiten werden
direkt in WayPointer vorgenommen, um damit den Prozess projektspezifisch anzupassen.
Durch die Aktivität „Definiere Regeln“ können sie unmittelbar in WayPointer
aktiviert werden. Dazu ist das zu beobachtende Modellelement (z. B. das „Use Case“)
aus einer Auswahlliste zu selektieren, welche Eigenschaft Gegenstand der Betrachtung
sein soll (z. B. „Mindestanzahl der Akteure“), sowie die entsprechenden Parameter
(die Anzahl als numerischer Wert). Nach der Regeldefinition können aus einer festgelegten
Liste Vorschläge gewählt werden, die dem Benutzer bei dem entsprechenden
Regelverstoß angezeigt werden, wie in Abbildung 3.3 dargestellt.
36

Abbildung 3.4: „Arbeitsstrukturbaum“ in WayPointer
3.1 Jaczone WayPointer
Die Definition gänzlich neuer Agenten (inklusive Aktivität und Schritte), Regeln und
Korrekturvorschläge ist durch die Verwendung eines Development Kit, bzw. dem darin
enthaltenen Agent Builder realisierbar. Komplexe, nicht vordefinierte Modellprüfungen
können durch eine Implementierung auf Quelltextebene realisiert werden.
Zusammenfassung Mit dem Konzept des aktiven Prozesses passt sich die Entwicklungsumgebung
der vom Entwickler gewählten Rolle an, um die damit verbundenen
Aktivität anzubieten und durch Agenten zu unterstützen. Auf Regelverletzungen
wird der Entwickler durch Artefakt-Agenten lediglich hingewiesen, optionale Korrekturvorschläge
für deren Beseitigung werden ihm angeboten. Der Entwicklungsprozess
(standardmäßig der Rational Unified Process (RUP)) wird durch Menüpunkte abgebildet;
eine Integration des Prozessablaufs ist nicht vorzufinden.
Projektspezifische Anpassungen der Regeleinstellungen und -aktivierung bzw. der Auswahl
der Korrekturvorschläge ist direkt in WayPointer möglich und Teil des aktiven
Prozesses. Die Integration gänzlich neuer Aktivitäten und die Entwicklung neuer
Agenten wird durch den Development Kit unterstützt. WayPointer ist also zugleich
Entwicklungsumgebung im Sinne einer Werkzeugkomposition als auch ein erweiterbares
Framework.
37

3 Prozessunterstützung in aktuellen Werkzeugen
3.2 Rational Systems Developer
Auf der Eclipse Plattform aufbauend bietet der Rational Systems Developer 2 als kommerzielles
Werkzeug eine „ [. . . ] integrierte Entwurfs- und Entwicklungsunterstützung
für die modellgetriebene Entwicklung mit UML“ [RSD]. Das Werkzeug liefert unter
anderem, ebenfalls unter Verwendung einer Rational Unified Process-Konfiguration,
eine integrierte Prozessbeschreibung. Die statische Beschreibung kann im Process
Browser betrachtet und kontextabhängig durch den Process Advisor referenziert werden.
Abbildung 3.5: Kontextabhängige Referenz auf statische Prozessbeschreibung
Das Navigieren durch die Prozessbeschreibung wird durch den Prozess Browser ermöglicht
(vgl. Abbildung 3.5, rechte Seite). Für dessen Nutzung können die mittels
EPF-Composer (vgl. Abschnitt 6.1.1) oder mit dem darauf aufbauenden kommerziellen
Pendant, dem IBM Rational Methode Composer veröffentlichten HTML-Seiten in
den RSA integriert werden. Die Beschreibung des RUP ist standardmäßig im Produkt
enthalten. Die Ansicht wird in einem neuen Fenster geöffnet und kann ähnlich wie in
einem Browser betrachtet und zur Laufzeit erweitert bzw. verändert werden.
Der Prozess Advisor (Abbildung 3.5, linke Seite) bietet kontextabhängig Referenzen
zur Prozessschreibung anhand der vom Benutzer aktuell durchgeführten Aktion (z. B.
Use Case-Modellierung) an. Das Verwenden einer solchen Referenz öffnet die dazugehörige
Seite der statischen Beschreibung im Prozess Browser. Der Prozess Advisor
bewirkt also implizit eine kontextabhängige Suche der durch den Process Browser bereitgestellten
Themen.
Darüber hinaus bietet der Rational Systems Developer keine Unterstützung für den
Softwareentwicklungsprozess.
38
2 ebenso der darauf aufbauende Rational Software Architect (RSA)

3.3 Evaluierung
3.3 Evaluierung
Die beiden beschriebenen Werkzeuge bieten eine Werkzeugunterstützung für die Softwareentwicklung
nach dem Rational Unified Process. Die statische und dynamische
Hilfe beim Rational System Developer kann als Nachschlagewerk in Form einer Prozessbeschreibung
verstanden werden. Sie unterstützt den Entwickler also nur indirekt
und vereinfacht beispielsweise das Erlernen des Prozesses, indem Informationen und
Hilfestellungen nicht in einem externen Dokument eingeholt werden müssen, sondern
direkt verfügbar sind.
Die interaktive Entwicklung mit dem WayPointer bei der Modellierung in einem externen
Werkzeug bietet weitergehende Unterstützung. Zum einen passt sich die Umgebung
der gewählten Rolle an, zum anderen bietet das Agentenkonzept ein sehr leicht
konfigurierbares und prinzipiell erweiterbares Framework. Folgend werden die einzelnen
Konzepte bewertet:
• Statische und kontextabhängige Prozessbeschreibung: Sowohl eine statische als
auch eine kontextabhängige Hilfe durch eine Prozess- bzw. Methodenbeschreibung
ist wohl in jedem Fall eine geeignete Unterstützung. Die statische Prozessbeschreibung
kann als Referenzwerk eingesetzt werden, wohingegen kontextabhängige
Referenzen eine dynamische Hilfestellung bieten.
• Rollen-basierte Anpassung der Oberfläche: Ein Anpassung der Oberfläche der
Entwicklungsumgebung an die gewählte Rolle hilft dem Entwickler, seine Ziele
zu identifizieren. Die Anpassung ist allerdings nur dann sinnvoll, wenn für jede
Aktivität die gleiche Oberfläche verwendet wird und es viele verschiedene
Rollen im Prozess gibt.
• Validierungen und Korrekturvorschläge: Die Validierung des Modells, als auch
das Bereitstellen von Korrekturvorschlägen dient zum einen der Qualitätssicherung,
zum anderen aber auch dem Abnehmen einfacher Arbeiten.
• Konfigurierbares Agentensystem: Die Konfiguration der Agenten zur Unterstützung
der einzelnen Aktivitäten ist nur dann von Belangen, wenn der integrierte
Prozess projektspezifisch angepasst werden muss.
• Übersicht der Aktivitäten: Das Starten der Aktivitäten aus dem Menü heraus ist
für erfahrene Entwickler eine sehr einfache und schnelle Möglichkeit die Modellierung
zu betreiben. Eine zusätzliche Möglichkeit einer konkreten Durchführung
des Prozessablaufs wäre eine zusätzliche Erleichterung.
Die Unterstützung beider Werkzeuge ist von sehr allgemeiner Natur. Der zugrunde liegende
Entwicklungsprozess RUP ist nicht für eine spezielle Domäne entwickelt worden,
sondern ganz im Gegenteil - er soll ein breites Spektrum von Softwareentwicklungsprojekten
abdecken [Kru99]. Es ist also naheliegend, dass auch die unterstützenden
Werkzeuge ähnlich allgemein bleiben. Andere UML-Modellierungswerkzeuge
bieten in den meisten Fällen fast gar keine Unterstützung für einen Entwicklungspro-
39

3 Prozessunterstützung in aktuellen Werkzeugen
zess oder eine Methode an. Mit dem WayPointer ist es zwar möglich, einige Anpassungen
für ein Projekt vorzunehmen, allerdings beziehen sich dies Anpassungen nur
auf die Prüfungen des erstellten Modells beziehungsweise auf die Korrekturvorschläge
bei Verstößen.
Wie im anschließenden Kapitel diskutiert, kann für MeDUSA und ViPER aufgrund der
sehr speziellen Anwendungsdomäne eine wesentlich konkretere Unterstützung realisiert
werden, als es bei den beiden betrachteten Werkzeugen der Fall ist.
40

4 Vision
Im letzten Kapitel wurden während der Untersuchung von zwei aktuellen, kommerziellen
Modellierungswerkzeugen allgemeine Möglichkeiten zur Unterstützung der
Softwareentwicklung vorgestellt und im Anschluß diskutiert. Teilweise darauf aufbauend
soll nun in Form einer Vision die für eine Unterstützung von MeDUSA denkbaren
Konzepte herausgearbeitet werden. Drei Bereiche sind hier thematisch voneinander
abzugrenzen:
• Der Begriff Methodenunterstützung umfasst im Wesentlichen alle Hilfestellungen
für die Bearbeitung von Aufgaben. Die für diesen Bereich identifizierten
Konzepte können für alle Aufgaben Anwendung finden oder sich auch auf eine
aufgabenspezifischen Unterstützung beziehen. Zusätzlich ist die technische
Umsetzung der MeDUSA Objekttaxonomie erforderlich.
• Unter der Prozessintegration wird die Unterstützung verstanden, die sich auf
den MeDUSA-Prozess bezieht. Neben der Realisierung einer konkreten Durchführung
des Prozesses, wird durch Prozessintegration auch Prozessbeschreibung
eingeschlossen.
• Die Infrastruktur beinhaltet sowohl die Bereitstellung von allgemeinen Einstellungen
als auch die Verwaltung und Erstellung von MeDUSA-Projekten.
Sowohl für die Methodenunterstützung als auch für die Prozessintegration werden im
Folgenden lediglich grundlegende Ideen einer möglichen Hilfestellung aufgeführt. Eine
detaillierte Beschreibung der Konzepte und der technischen Realisierung wird in
den Kapiteln 6 bzw. 5 geliefert. Der Realisierung der Infrastruktur ist rein technischer
Natur und wird daher ausschließlich in diesem Kapitel durch eine Identifizierung der
durchzuführenden Arbeiten behandelt.
4.1 Methodenunterstützung
In der Konzeption der Methodenunterstützung sind verschiedene Ansätze von Bedeutung.
Zum einen könnten sicherlich die in der Evaluierung des letzten Kapitels genannte
Validierungen mit entsprechenden Korrekturvorschlägen eine geeignete Hilfestellung
bieten. Eine zusätzliche Bewertung durch Metriken könnte Aufschluss über
die Qualität der erstellten UML-Modellen geben. Durch die Anwendung von Metriken
während der Partitionierung der Analyseobjekte in der ersten Aufgabe des Architectural
Design (vgl. Abschnitt 2.1.1) könnte die Architektur entscheidend beeinflusst werden.
Bei einer gleichzeitigen Betrachtung der Use Case-Modellierung und des Context
Modelling kann eine Redundanz bezüglich der identifizierten Elemente erkannt wer-
41

4 Vision
den. Die in Use Case-Diagrammen identifizierten Akteure werden erneut als Schnittstellen
des Systems in der Analyse modelliert. An dieser oder auch an anderen Stellen
wäre es also möglich, den aus der Redundanz hervorgehenden Aufwand zu verringern.
In dem betrachteten Fall könnten beispielweise die Schnittstellen automatisch
durch ein Werkzeug erstellt werden.
Bei der Strukturierung möglicher Unterstützungen, können auf der einen Seite allgemeine
Konzepte herausgearbeitet werden, die unabhängig von dem Inhalt einer Aufgabe
sind, und auf der anderen Seite aufgabenspezifische Hilfestellungen.
4.1.1 Allgemeine Konzepte
Angelehnt an das Agenten-Konzept von WayPointer, könnte für die Entwicklung mit
MeDUSA die Bearbeitung einer Aufgabe jeweils durch einen Wizard unterstützt werden.
Eine Menüstruktur, welche die Disziplinen und Aufgaben widerspiegelt, könnte
das Starten eines solchen Wizards ermöglichen. Weiterhin wären folgende, allgemeine
Hilfestellungen geeignet, die im Abschnitt 5 aufgegriffen werden:
1. Validierung: Unabhängig von dem Gegenstand der Aufgabe, sollte jedes verwendete
Modell zunächst validiert werden.
2. Korrekturvorschläge: Bei der Verletzung einer Validierungsregel (Constraint)
könnten Korrekturmöglichkeiten vorgeschlagen werden, die zu einer Aufhebung
des Verstoßes führen.
3. Sicherstellung der Nachverfolgbarkeit und Durchgängigkeit: Bei der Entwicklung
mit MeDUSA werden in den einzelnen Disziplinen verschiedene Elemente
modelliert, die allerdings eine implizite Beziehung untereinander aufweisen.
Beispielsweise werden alle Analyseobjekte im Entwurf aufgegriffen und entsprechend
in die Architektur integriert. Im Detailed Design werden für alle modellierten
Objekte Klassen erstellt. Solche Beziehungen treten vermehrt zwischen
den unterschiedlichen Abstraktionsniveaus der Arbeitsergebnisse unterschiedlicher
Disziplinen auf. Um eine dahingehende Durchgängigkeit der Arbeitsergbnisse
sicherstellen zu können ist es notwendig die impliziten Abhängigkeiten
durch ein Werkzeug explizit festzuhalten. Dadurch kann eine Nachverfolgbarkeit
sichergestellt werden, mit der Widersprüche zwischen den Arbeitsergebnisse
unterschiedlicher Disziplinen aufgedeckt werden können (beispielsweise,
dass ein Analyseobjekt nicht im Entwurf berücksichtigt wurde).
4.1.2 Aufgabenspezifische Hilfestellungen
In vielen Aufgaben kann dem Benutzer fehlerproduzierende Arbeit abgenommen und
damit die Qualität des Modells zusätzlich verbessert werden. Besonders für die folgenden
Aufgaben, kann eine sinnvolle spezielle Unterstützung realisiert werden.
42

Context Modelling
4.1 Methodenunterstützung
Die interface und trigger Objekte spiegeln direkt die primären bzw. sekundären Akteure
der Use Cases wider, so dass sie unmittlebar aus den Informationen der Use
Case-Diagrammen erstellt werden könnten. Durch den Entwickler wäre lediglich die
Kommunikationsrichtung der interface Objekten zu spezifizieren.
Task Modelling
Im Task Modelling werden Task-Kandidaten ermittelt und es wird in einer ersten
Schätzung analysiert, ob die Modellierung der Problemwelt mit den Einschränkungen
durch die Hardware in Einklang zu bringen ist. Das Verhalten des Systems im Kontext
eines Use Cases wird entweder durch ein trigger Objekt angestoßen oder durch einen
referenzierenden Use Case. Dem Entwickler könnte also für die Aufstellung der Task-
Kandidaten eine Auflistung entsprechender Objekte geliefert werden. Die Schätzung
anhand eines Verfahrens könnte ebenfalls durch die Unterstützung eines aufgabenspezifischen
Wizards übernommen werden, der die Berechnung durch die möglichen
Verfahren anbietet.
System Identification
Nach der Analyse werden die identifizierten und für die Interaktionen notwendigen
Objekte durch die Bildung von Subsystemen partitioniert. Ohne eine spezielle Unterstützung
müsste ein Entwickler für jedes Subsystem (mindestens) ein Diagramm
erstellen und dabei die entsprechenden Analyseobjekte im Entwurf berücksichtigen.
Die dadurch modellierten Objekte müssten wiederum derart in Beziehung zu einander
gesetzt werden, wie es bereits für die Analyseobjekte durchgeführt wurde. Eine solche
Verfahrensweise wäre sehr aufwändig und vorallem sehr fehlerträchtig. Das Übersehen
eines einzigen Analyseobjekts bei der Partitionierung könnte schwerwiegende
Auswirkungen auf das spätere System haben.
Neben dieser technischen Aufteilung der Analyseobjekte muss ein Entwickler sich um
eine effektive Aufteilung bemühen, so dass eine effiziente Kommunikation der Objekte
unterschiedlicher Subsysteme im späteren System gewährleistet ist. Das Erstellen
einer Architektur, die nicht den einschränkenden Anforderungen an das Softwaresystem
genügt, würde zu einer Veränderung entsprechender UML-Diagramme führen und
ebenso die ports und interfaces der jeweiligen Subsysteme beeinflussen.
Eine geeignete Hilfestellung für diese Aufgabe könnte eine Unterstützung der Partitionierung
vereinfachen, indem anstelle von UML-Diagrammen Ansichten auf das
Analyse- und Architekturmodell angeboten werden, so dass eine Abbildung der Objekte
auf die Subsysteme durch entsprechende Interaktionen vorgenommen werden
können (z. B. durch drag&drop). Dabei könnte zusätzlich überprüft werden, ob alle
Analyseobjekte und entsprechende Nachrichten zwischen Objekten verschiedener
43

4 Vision
Subsysteme im Entwurf aufgegriffen wurden. Die Architektur könnte während der
Partitionierung bereits durch die Anwendung von Metriken evaluiert werden. Durch
eine direkte Anwendung der Metriken sind vermutlich sehr viel weniger Iterationen
notwendig, denn sollte die Anwendung einer Metrik auf ein starkes Defizit des Modells
hinweisen, könnte die Modellierung abgebrochen oder die letzten Schritte widerrufen
werden. Der Entwickler könnte einen anderen Ansatz wählen. Ohne eine solche
Entwicklung würde das Defizit des Modells vermutlich erst sehr viel später erkannt
werden.
Structural System Architecture Modelling
Die in der Subsystem Identification modellierten Subsysteme werden im Kontext des
Systems betrachtet und ihre Interaktionspunkte werden miteinander verbunden. Die
modellierten interface Objekte werden durch ihre Signaturen verfeinert. Es müssen
also wiederholt die Interaktionspunkte erstellt und die der verschiedenen Subsysteme
entsprechend miteinander verbunden werden.
Auch bei diesem Vorgang könnten einige der Informationen aus den bisherigen Modellen
gezogen werden. Interaktionspunkte dienen der Übermittlung von Nachrichten
zwischen Objekten verschiedener Subsysteme. Da die Nachrichten bereits bekannt
sind, kann entschieden werden, inwiefern Subsystem-Schnittstellen miteinander zu
verknüpfen sind.
Behavioural System Architecture Modelling
Interaktionsdiagramme der Analyse, deren Objekte sich in mehr als einem Subsystem
befinden, müssen für den Entwurf im Behavioral System Architecture Modelling erneut
unter Berücksichtigung der Interaktionspunkte und den damit verbundenen interface
Objekten modelliert werden.
Für jedes Interaktionsdiagramm kann im Sinne einer aufgabenspezifischen Unterstützung
entschieden werden, ob die damit modellierten Objekte auf mehr als ein Subsystem
verteilt sind. Im Prinzip sollte es möglich sein, die Diagramme bzw. das zugrunde
liegende Modell zu erstellen bzw. anzupassen, indem das Analysemodell, die modellierten
Interaktionspunkte und interface-Objekte inklusive ihrer Signaturen herangezogen
werden. Zumindest könnte das zu erweiternde Diagramm der Analyse zunächst
kopiert werden, um dem Entwickler durch die Herstellung dieses initialen Zustands,
Arbeit abzunehmen.
Class Design Modelling
In der letzten Aufgabe des Detailed Designs wird die Abbildung der Objekte auf
Klassen vorgenommen. Durch eine geeignete Unterstützung könnte dem Benutzer bei
44

4.2 Prozessintegration
dieser Abbildung eine Hilfestellung angeboten werden, indem die Klassen unter berücksichtigung
der akkumulierten Signaturen der Objekte erstellt werden. Sollte ein
Objekt nicht durch eine entsprechenden Klasse berücksichtigt worden sein, sollte der
Entwickler darauf hingewiesen werden.
4.2 Prozessintegration
Im Kapitel 3 wurden zwei Modellierungswerkzeuge bezüglich der Methodenunterstützung
und Prozessintegration untersucht. Es wurde festgehalten, dass weder der Way-
Pointer noch der Rational Systems Developer eine konkrete Durchführung des Prozesses
im Sinne eines Ablaufs unter Berücksichtigung der zeitlichen Abhängigkeiten
unterstützen. Der Entwickler ist für die Reihenfolge der Aufgabenbearbeitung verantwortlich
und kann sich an einer Prozessbeschreibung und Menüstrukturen bei seinem
Vorgehen orientieren. Eine derartige Menüstruktur, wie sie durch WayPointer (vgl. Abschnitt
3.1) bereitgestellt wird, reflektiert streng genommen nur die Disziplinen und
Aufgaben. Diese Hilfestellung fällt also in die Kategorie Methodenunterstützung.
Für die Unterstützung von MeDUSA hinsichtlich der Prozessintegration würde neben
einer Prozessbeschreibung, wie sie im Rational Systems Developer realisiert wurde
(vgl. Abschnitt 3.2), eine Ablaufmodellierung durch die im Abschnitt 2.3.1 vorgestellten
CheatSheets eine geeignete Hilfestellung leisten. Ein CheatSheet könnte die
zeitlichen Abhängigkeiten widerspiegeln und für die jeweiligen Aufgaben die aufgabenspezifischen
Methodenunterstützung anbieten. Mit der Hilfe-Schaltfläche eines
CheatSheets könnte die Prozessbeschreibung kontextabhängig referenziert werden. Eine
Prozessbeschreibung könnte durch erstellte HTML-Dateien in das Eclipse Hilfesystem
(vgl. Abschnitt 2.3.1) eingebunden und so in ViPER integriert werden.
4.3 Infrastruktur
Im Abschnitt 2.3 wurde das UML-Modellierungswerkzeug ViPER mit dem zugrunde
liegenden Eclipse-SDK vorgestellt, das um eine Prozessunterstützung für MeDUSA
erweitert werden soll. Um eine Prozessintegration und insbesondere eine Methodenunterstützung
realisieren zu können, sind einige infrastrukturelle Maßnahmen durchzuführen.
MeDUSA-Projekt
Die Erstellung eines Softwaresystems beinhaltet das Erstellen von Modellressourcen
und die Code-Generierung. Um die entstehenden Ressourcen geeignet ablegen zu können,
sollte es möglich sein, MeDUSA-Projekte anlegen zu können. Dafür ist die Erstellung
einer speziellen Nature (vgl. S. 21) erforderlich, um die im Workspace befindlichen
MeDUSA-Projekte identifizieren zu können. Das Anlegen eines Projekts
45

4 Vision
wird in Eclipse unabhängig von der Nature über einen Projektwizard realisiert. Ein
spezieller Wizard für die Erstellung von MeDUSA-Projekten könnte neben der Markierung
des neuen Projekts durch die Nature unmittelbar Modellressourcen erstellen
und gegebenfalls initialisieren.
Einstellungen
In einer Eclipse-basierten Entwicklungsumgebung gibt es zwei Ebenen zur allgemeinen
Speicherung von Einstellungen. Unter Preferences versteht man projektunabhängige
Konfigurationen, die zur Anpassung des Werkzeugs aber auch als Standardwerte
für projektspezifische Einstellungen eingesetzt werden. Die projektspezifischen Einstellungen
(Properties oder Settings) werden im Projekt selbst abgelegt und sind haben
im allgemeinen keine Auswirkungen auf andere Projekte. Sie sind im Gegensatz
zu den Preferences unabhängig von der Entwicklungsumgebung. Wird das Projekt in
verschiedenen Umgebungen bearbeitet, sind die projektspezifischen Einstellung verfügbar.
Die Standardnamen der UML-Modelle und -ressourcen können als Preferences definiert
werden, die dann bei der Projekterstellung herangezogen werden. Für MeDUSA-
Projekte sollen einige Einstellungen projektspezifisch anpassbar sein, z. B. das für die
Prozessdurchführung zu verwendende CheatSheet.
4.4 Kosten/Nutzen-Analyse
Die Realisierung aller genannten Hilfestellung ist im Rahmen dieser Arbeit nicht möglich.
Aus diesem Grund muss durch Anwendung einer Kosten/Nutzen-Analyse entschieden
werden, welche Unterstützungen umgesetzt werden sollen. Sowohl die Prozessintegration
als auch die Infrastruktur werden bei dieser Betrachtung außen vor
gelassen, da beide Realisierung als obligatorisch angesehen werden.
Der größte Nutzen wird wohl aus einer Realisierung der allgemeinen Konzepte gezogen.
Das Aufstellen einer Lösung für die allgemeine Unterstützung einer beliebigen
Aufgabe hat Vorteile für jede spezifischen Hilfestellung. Neben einer Berücksichtigung
von Validierungen und Korrekturvorschlägen, kann die Handhabung der Modellressourcen
durch ein Framework geeignet abgedeckt werden. Zusätzlich würde
ein gemeinsames Konzept zur Sicherstellung der Durchgängigkeit einen hohen Nutzen
bringen, indem die Möglichkeit bestünde, Widersprüche zwischen den Arbeitsergebnissen
unterschiedlicher Disziplinen erkennen zu können. Die Realisierung eines
Frameworks, das die angesprochenen Konzepte vereint, ist trotz eines hohen Implementierungsaufwand
gerechtfertigt, da die Umsetzung jeder speziellen Hilfestellungen
sowohl konzeptionell als auch technisch vereinfacht wird.
Die aufgabenspezifischen Unterstützungen besitzen unterschiedliche Komplexitäten.
Die Partitionierung der Analyseobjekte in der Subsystem Identification hat sehr star-
46

4.4 Kosten/Nutzen-Analyse
ken Einfluss auf die spätere Leistung des zu erstellenden Softwaresystems. Zum einen
kann eine Unterstützung dieser Aufgabe die Effizienz der Entwicklung verbessern, indem
eine Partitionierung der Analyseobjekte durch eine Hilfestellung vereinfacht wird.
Zum anderen kann die Sicherstellung der Durchgängigkeit die Qualität der Modelle
positiv beeinflussen. Durch die zusätzliche Anwendung von Metriken, kann ein Entwickler
frühzeitig erkennen, ob das entwickelte Modell Defizite aufweist. Auch wenn
der Implementierungsaufwand zur Unterstützung dieser Aufgabe vermutlich den der
anderen übersteigt, ist er in Anbetracht des großen Nutzens für den Entwickler in Kauf
zu nehmen.
Aus diesem Grund wird im Rahmen dieser Arbeit der Schwerpunkt sowohl auf die
Umsetzung der Prozessintegration und Infrastruktur als auch auf die Erstellung eines
allgemeinen Frameworks und die prototypische Unterstützung der Subsystem Identification
gelegt.
47

4 Vision
48

5 Methodenunterstützung
Die Methodenunterstützung soll dem Entwickler Hilfestellung bei der Ausübung der
Tätigkeiten zur Bearbeitung einer Aufgabe leisten. Dazu gehört insbesondere eine Unterstützung
für die Fertigstellung der mit den Aufgaben verbundenen Arbeitsergebnisse.
In der im Kapitel 4 vorgestellten Vision wurden auf der einen Seite einige allgemeine
Arten der Unterstützung herausgearbeitet, die für jede Aufgabe Anwendung finden
sollen, und auf der anderen Seite mögliche aufgabenspezifische Hilfestellungen.
Eine Realisierung aller identifizierten Unterstützungsmöglichkeiten ist im Rahmen
dieser Arbeit nicht möglich. Deshalb wird im Folgenden der Schwerpunkt auf allgemeine,
aufgabenunabhängige Konzepte und die prototypische Erstellung eines Wizards
zur Unterstützung der Subsystem Identification gelegt. Für die Erläuterungen ist
die vorgezogene Beschreibung von zwei grundlegenden Entwurfsentscheidungen erforderlich:
• Disziplinspezifische Modelle: Der Methodeninhalt von MeDUSA wurde im Kapitel
2 durch die Beschreibung der vier Disziplinen und den jeweiligen Aufgaben
vorgenommen. Es wird nun festgelegt, dass für die einzelnen Disziplinen
unterschiedliche UML-Modelle verwendet werden. Lediglich in den Aufgaben
des Architectural Designs und des Detailed Designs wird ein identisches UML-
Modell eingesetzt. Die Arbeitsergebnisse, die aus den Aufgaben der verschiedenen
Disziplinen hervorgehen, haben keine gemeinsamen Inhalte. Die Verwendung
mehrerer Modelle bewirkt somit keine (zusätzliche) Redundanz. Ein gemeinsames
Modell beispielsweise in der Analyse und im Entwurf würde einige
Probleme hervorrufen, da ohne weitere Hilfsmittel die in den Aufgaben der jeweiligen
Disziplinen modellierten Inhalte (Objekte, Nachrichten) nicht voneinander
unterschieden werden könnten.
• Einsatz von Profilen: MeDUSA stellt für die identifizierten bzw. modellierten
Objekte der unterschiedlichen Disziplinen Objekttaxonomien bereit, mit denen
sie bezüglich ihrer Eigenschaften „typisiert“ werden können. Jedes Objekt wird
damit genau einer Kategorie zugeordnet. Unter technischen Gesichtspunkten
kann die Objekttaxonomie nicht sinnvoll durch eine Klassenhierarchie realisiert
werden, so dass der Einsatz von UML-Profilen für die technische Umsetzung
gewählt wird.
5.1 Allgemeine Unterstützung
Für eine allgemeine Hilfestellung bei der Bearbeitung von Aufgaben, sind im Kapitel
4 einige Arten einer möglichen Unterstützung vorgestellt worden. Zum einen ist es
49

5 Methodenunterstützung
notwendig, die UML-Modelle vor der Bearbeitung zu validieren, zum anderen können
dem Entwickler bei einigen Regelverstößen Korrekturvorschläge angeboten werden.
Um zusätzlich die Durchgängigkeit der Modellinhalten sicherstellen zu können, ist
die Speicherung von Abbildungsinformationen notwendig. Dadurch kann mittels einer
Validierung beispielsweise überprüft werden, ob alle in der Analyse identifizierten
Objekte im Entwurf berücksichtigt wurden.
Im Folgenden wird ein einfaches Modell definiert, mit dem die Bearbeitung einer Aufgabe
beschrieben werden kann. Dieses Modell wird im Abschnitt 5.1.3 durch die Integration
von Validierungen und Korrekturvorschlägen auch hinsichtlich der Durchgängigkeit
erweitert und dient als Grundlage für die technische Realisierung eines allgemeinen,
aufgabenunabhängigen Frameworks.
5.1.1 Aufgabenmodell
Jede Aufgabe einer Methode wird von einer Rolle bearbeitet. Mit einigen Arbeitsergebnisse
als Grundlage, werden während der Bearbeitung neue Arbeitsergebnisse
erstellt oder vorhandene verändert 1 . Bei der Entwicklung mit MeDUSA sind die Arbeitsergebnisse
in den meisten Fällen UML-Diagramme, die eine Sicht auf das Modell
der jeweiligen Disziplin bilden. Das Erstellen oder Verändern eines Arbeitsergebnisses
hat also Veränderungen des jeweiligen Modells zur Folge. Aus diesem Grund werden
im Folgenden nur UML-Modelle betrachtet:
• Eingabemodelle sind UML-Modelle, die als Grundlage bei der Bearbeitung einer
Aufgabe verwendet werden
• Analog sind Ausgabemodelle diejenigen Modelle, die bei der Bearbeitung einer
Aufgabe verändert oder erstellt werden und somit als Ergebnis hervorgehen
Durch das iterative Vorgehen, sind alle Ausgabemodelle einer Aufgabe (nach eventuellen
Änderungen außerhalb des Aufgabenkontextes) gleichzeitig auch Eingabemodelle
für den nächsten Iterationsschritt. Bei der Bearbeitung der Subsystem Identification
beispielsweise, wird im ersten Iterationsschritt das Analysemodell herangezogen
und das Initial Structural Subsystem Design Diagram modelliert (vgl. Abschnitt 2),
das eine Sicht auf das Architekturmodell liefert. In allen folgenden Iterationsschritten,
wird das Architectural Design-Modell allerdings auch als Eingabemodell verwendet,
um vorherige Veränderungen des Analysemodells im Entwurf anzupassen, ohne das
gesamte Architekturmodell neu erstellen zu müssen. Verallgemeinert lässt sich also
festhalten, dass jedes Ausgabemodell auch immer ein Eingabemodell ist. Im Sonderfall
des ersten Iterationsschritts kann das Architekturmodell als ein Modell ohne Inhalt
betrachtet werden.
Jede Aufgabe kann nun, wie in Abbildung 5.1 dargestellt, als eine abgeschlossene
Einheit im Kontext eines iterativen Vorgehens betrachtet werden und die Bearbeitung
durch ein einfaches Modell repräsentiert werden. Alle in einer Aufgabe durchgeführ-
50
1 Siehe dazu SPEM, UMA im Abschnitt 6.1)

Abbildung 5.1: Das Aufgabenmodell
5.1 Allgemeine Unterstützung
ten Modelländerungen werden aus einer black-box Sicht heraus als eine Funktion definiert,
durch deren Anwendung Eingabemodelle auf Ausgabemodelle abbildet werden.
Da die Modelländerungen teilweise durch das Werkzeug und teilweise durch den
Entwickler bestimmt sind, ist die Funktionsvorschrift nicht eindeutig bestimmt. Die
Signatur einer solchen Funktion zur Beschreibung von Modelländerungen bei der Bearbeitung
einer Aufgabe k im Iterationsschritt i wird wie folgt definiert:
g i k : M n UML → M n UML
(5.1)
Dabei ist MUML die Menge aller UML-konformen Modelle. Die Funktion bildet n
Eingabemodelle auf n Ausgabemodelle ab. Die Eingabemodelle und Ausgabemodelle
sind identische Modelle zu unterschiedlichen Zeitpunkten. Ihre Inhalte unterschei-
den sich gerade durch die bei der Bearbeitung durchgeführten Modelländerungen, die
durch die Funktion f i k beschrieben werden.
5.1.2 Durchgängigkeit
Bei der modellgetriebenen Entwicklung, besteht vorallem bei einem iterative Vorgehen
die Gefahr, dass sich die Modellinhalte der verschiedenen Disziplinen widersprechen
und einige Teile unvollständig sind. Um eine Durchgängigkeit der disziplinspezifischen
Modelle sicherstellen zu können, ist es deshalb notwendig, zusätzliche Information
für die Nachverfolgbarkeit von Abbildungen festzuhalten.
Zwischen den Elemente der disziplinspezifischen UML-Modelle existieren implizite
Abhängigkeiten. Beispielsweise muss jedes Analyseobjekt muss im Entwurf aufgegriffen
werden (vgl. Abb 5.2). Ein Widerspruch des Analyse- und Architekturmodells
kann die Entwicklung eines defizitären Systems bewirken. Das Auftreten eines solchen
Widerspruchs kann zwei Ursachen haben: Entweder ist das Analyseobjekt zum aktuellen
Zeitpunkt überflüssig und wurde nicht entfernt, oder es wurde bei der Modellierung
des Entwurfs übersehen. Der zweite Grund kann unter Umständen die Entwicklung
eines System bewirken, dass keine korrekte Lösung bezüglich der Anforderungen darstellt.
51

5 Methodenunterstützung
Abbildung 5.2: Implizite Abhängigkeiten zwischen UML-Modellen
Der Zusammenhang zwischen diesen beiden aufeinanderfolgenden Modellen, lässt
sich auch an anderen Stellen wiederfinden. Alle in der Disziplin Requirements identifizierten
trigger-Akteure sollten ebenfalls in der Analyse als trigger-Objekte vorzufinden
sein. Die im Entwurf modellierten Objekte der einzelnen Subsysteme sollten im
Detailed Design durch erstellte Klassen widergespiegelt werden.
Bei einer geeigneten Methodenunterstützung ist also, insbesondere unter Berücksichtigung
der iterativen Entwicklung, eine Nachverfolgbarkeit der durchgeführten Abbildungen
notwendig, um die Durchgängigkeit der UML-Modelle gewährleisten zu können.
Der Entwickler soll dabei unterstützt werden, eine Modellierung vorzunehmen,
deren Ergbnisse sich als möglichst widerspruchsfreie und vollständige gestalten.
Lösungsansätze
Die UML stellt grundsätzlich kein Konzept für die Modellierung von Abbildungsinformationen
bereit. Die Nachverfolgbarkeit kann nur durch eine Erweiterung der Profile
oder durch ein grundsätzlich neues Metamodell realisiert werden, indem Abbildungsinformationen
in einem externen Modell abzulegen sind.
Die Erweiterung der UML-Profile zur Informationsspeicherung bewirkt allerdings eine
starke Kopplung zwischen den Modellen, aufgrund der festgehaltenen Referenzen
untereinander. Die Abbildungsinformationen werden lediglich dazu verwendet, Zusammenhänge
zwischen den Elementen unterschiedlicher Modelle zu erkennen. Aus
diesem Grund ist es sinnvoll, sie in einem externen Modell abzulegen, damit jedes
UML-Modell für sich eine abgeschlossene Einheit bildet.
Eine ähnliches Ziel wird im ATLAS Transformation Language (ATL) Projekt verfolgt
[ATL]. Dieses Projekt beinhaltet (wie oAW) Frameworks und Sprachen zur Modelltransformation
und Code-Generierung. Bei einer Transformation besteht die Möglichkeit,
auf Basis eines speziellen Weaving-Metamodells, Informationen darüber festzuhalten,
wie die Elemente des Quellmodells auf Elemente des Zielmodells abgebildet
worden sind [AMW]. Prinzipiell ist das genau die Art von Informationen, die für die
Nachverfolgbarkeit relevant ist. Dieses Metamodell unterliegt allerdings starken Ein-
52

5.1 Allgemeine Unterstützung
schränkungen, so dass es für den betrachteten Kontext keine ausreichende Flexibilität
aufweist. Beispielsweise ist es nicht möglich, Abbildungen zu gruppieren oder Elemente
beliebiger Modelle zu verbinden.
Aus diesem Grund wird eine neues Metamodell vorgestellt, das es ermöglichen soll,
Informationen zur Gewährleistung der Nachverfolgbarkeit von Abbildungen festhalten
zu können.
Traceability-Modell
Mit einem neuen Metamodell sollen die bislang impliziten Abhängigkeiten zwischen
disziplinspezifischen Modellen nun explizit festgehalten werden. Der Zusammenhang
zwischen den Modellen besteht darin, dass Elemente eines Modells auf Elemente eines
anderen Modells abgebildet werden, wie in Abbildung 5.2 beispielhaft dargestellt.
Eine solche Abbildung ist also durch eine Menge von Quellobjekten und durch eine
Menge von Zielobjekten bestimmt und wird im Folgenden als Mapping bezeichnet.
Abbildung 5.3: Beispiel für Abbildungsinformationen
In der Abbildung 5.3 sind beispielhaft einige Mappings skizziert. Betrachtet wird der
Zusammenhang zwischen Elementen des Requirements-Modells, des Analysemodells
und des Entwurfs. Ein Analyseobjekt wird durch potentiell mehrere Elemente repräsentiert
(z. B. durch Lifeline3a und InstanceSpec3b). Dessen Repräsentanten werden
dementsprechend auf ein einziges Property-Element eines Subsystems abgebildet. Mit
dem angedeutete Step werden alle Mappings zusammengefasst, die für die Partitionierung
eingesetzt werden. Eine Trace ist eine Folge von Mappings. Ausgehend von
einem Akteur des Requirements-Modells werden Analyseobjekte und zuletzt Objekte
im Entwurf explizit miteinander in Beziehung gesetzt. Ausgehend vom trigger actor
könnten die Elemente des Entwurfs bestimmt werden, die diesen Akteur (bzw. die
53

5 Methodenunterstützung
Schnittstelle) widerspiegeln, vorausgesetzt das Traceability-Modell wurde bei der gesamten
Methodenunterstützung geeignet verwendet.
Alle Klassen eines mit EMF realisierten Metamodells sind Spezialisierungen der Klasse
EObject (vgl. Abschnitt 2.3.2). Um das Metamodell in einem anderen Kontext (jenseits
der UML) wiederverwenden zu können, wird deshalb verallgemeinert eine Abbildung
von EObjects auf EObjects betrachtet. Somit können Abbildungen zwischen
den Elementen beliebiger Metamodelle berücksichtigt werden, insofern die Metamodelle
durch Verwendung des Eclipse Modeling Framework (EMF) in das Werkzeug
integriert sind.
Abbildung 5.4: Das Traceability Modell
Die wesentlichen Elemente des Traceability-Metamodells sind in Abbildung 5.4 dargestellt.
Ein Mapping kann, wie im Beispiel motiviert, unter verschiedenen Gesichtspunkten
betrachtet werden:
• Step: Ein Step dient der Zusammenfassung von gleichartigen Mappings. Bei
der Partitionierung von Analyseobjekte wird für jedes Analyseobjekt genau ein
Mapping eingesetzt. Die Mappings aller Analyseobjekte können zu einem Step
gruppiert werden.
• Trace: Für die Durchgängigkeit der Abbildungen von Elementen bezüglich mehrerer
Modelle, kann eine Sequenz von Mappings als Trace modelliert werden.
Die Abbildungen weniger Objekte werden schrittweise über verschiedene Modelle
hinweg berücksichtigt. Durch den Einsatz von OCL-Bedingungen wird sichergestellt,
dass die Quell- und Zielobjekte der geordneten Folge von Abbildungen
übereinstimmen.
• Eine Traceability beinhaltet alle Mappings, Traces und Steps und soll die Nachverfolgbarkeit
bei der Entwicklung eines Softwaresystems sicherstellen.
Damit auch die Möglichkeit besteht, gespeicherte Abbildungsinformationen aus dem
Traceability-Modell zuordnen zu können und zu extrahieren, müsssen den einzelnen
Steps, Traces und Mappings je nach Verwendung verschiedene Attribute zugeteilt werden.
Das Element PropertyOwningElement ist eine Generalisierung aller vier genann-
54

5.1 Allgemeine Unterstützung
ten Elemente. Jedem PropertyOwningElement können beliebig viele Properties zugewiesen
werden (vgl. Abb. 5.5), wobei jede Property ein key-value Paar beinhaltet.
Damit besteht zum Beispiel für eine Section die Möglichkeit, zu einem Schlüssel
sectionId den Wert ANALYSIS_OBJECT_PARTITIONING abzulegen.
Abbildung 5.5: Zusätzliche Informationen
Nachdem nun mit einem Metamodell die Möglichkeit besteht, Widersprüche zwischen
disziplinspezifischen UML-Modell zu erkennen, wird im nächsten Abschnitt das Aufgabenmodell
erweitert, um Validierung und Korrekturvorschläge auch hinsichtlich der
Durchgängigkeit zu berücksichtigen.
5.1.3 Validierungen und Korrekturvorschläge
Immer dann, wenn Modelle für eine Bearbeitung verwendet werden, sollten sie zunächst
auf eventuelle Vorbedingungen überprüft werden. Ein UML-Modell kann auf
unterschiedlichen Arten Fehler aufweisen, die bezüglich ihrer Ursachen durch die folgenden
Begriffe gruppiert werden:
1. Integritätsverletzungen: Eine Integritätsverletzung kann durch ein einzelnes oder
mehrere UML-Modelle hervorgerufen werden. Fehler bei der Serialisierung, Referenzen
auf nicht erreichbare Elemente anderer Modelle oder auch Verletzungen
gegen UML-Constraints könnten die Ursachen dafür sein.
2. Inkonsistenzen: Inkonsistenzen sind Verletzungen MeDUSA-spezifischer Vorbedingungen
und obligatorischer Konventionen (z. B. die Kategorisierung jedes
modellierten Objekts hinsichtlich der Objekttaxonomie).
3. Unstimmigkeiten treten auf, wenn die Durchgängigkeit mehrerer Modelle nicht
gewährleistet ist, und bilden daher den Grund für Widersprüche zwischen disziplinspezifischen
Modellen. Unstimmigkeiten können auf der Basis des beschriebenen
Traceability-Modells erkannt werden.
Die Vermeidung und das Beheben von Integritätsverletzungen wird durch das Eclipse
Modeling Framework (EMF) gewährleistet. Inkonsistenzen und Unstimmigkeiten müs-
55

5 Methodenunterstützung
sen durch die Methodenunterstützung vermieden, beziehungsweise erkannt und in Interaktion
mit dem Entwickler behoben werden. Aus diesem Grund werden die UML-
Modelle vor jeder Bearbeitung einer Validierung unterzogen, um aufgabenspezifische
Vor- und Nachbedingungen zu überprüfen. Wie in Abbildung 5.6 dargestellt, wird dazu
das beschriebene Aufgabenmodell erweitert.
Vor- und Nachbedingungen
Abbildung 5.6: Das erweiterte Aufgabenmodell
Im Kontext einer Aufgabe werden an die Eingabemodelle Vorbedingungen und an die
Ausgabemodelle Nachbedingungen gestellt. Welche Bedingungen das konkret sind, ist
abhängig von der jeweiligen Aufgabe. Allgemein kann aber festgestellt werden, dass
Unstimmigkeiten nicht durch Vorbedingungen an die Eingabemodelle ausgeschlossen
werden sollten, denn die Bearbeitung einer Aufgabe beinhaltet gerade die Behebung
von Unstimmigkeiten (z. B. das Partitionieren neuer Analyseobjekte). Die Nachbedingungen
der Ausgabemodelle sollten hingegen Unstimmigkeiten ausschließen oder
zumindest auf deren Existenz hinweisen.
Die für eine Aufgabe k spezifischen Vorbedingungen prek und Nachbedingungen
postk eines n-Tupels von UML-Modellen kann durch Anwendung der Funktionen
cpre und cpost überprüft werden:
cpre : M n UML → B (5.2)
cpost : M n UML → B (5.3)
Die Funktion gi k aus Abschnitt 5.1.1 wird zur Berücksichtigung der Vor- und Nachbedingungen
angepasst. Alle während einer werkzeugunterstützten Aufgabe k durchgeführten
Aktionen über den n Eingabemodellen im Iterationsschritt i werden durch die
neue Funktion f i k beschrieben:
56
f i k : M n UML, pre → M n UML, post
(5.4)

5.1 Allgemeine Unterstützung
Der Ursprung von f i k ist dadurch definiert, dass für jedes m ∈ M n UML, pre
den zwei Eigenschaften gelten müssen:
1. m ∈ M n UML
2. cpre(m) = true
die folgen-
Entsprechend muss für jedes Element des Bildbereiches f i k (m) ∈ M n UML, post , gelten,
dass:
1. f i k (m) ∈ M n UML
2. cpost(f i k (m)) = true
Jedes ausgehende Modell einer Aufgabe wird im nächsten potentiellen Iterationsschritt
ein Eingabemodell der gleichen Aufgabe sein. Deshalb wird festgelegt, dass die an
die Eingabemodelle gestellten Bedingungen ebenfalls durch die Ausgabemodelle erfüllt
werden müssen. Das heißt, die Nachbedingungen bezüglich der Ausgabemodelle
beinhalten mindestens die Vorbedingungen an die entsprechenden Eingabemodelle.
Damit ist sichergestellt, dass die Modelländerungen einer Aufgabe nicht den eigenen
Vorbedingungen widersprechen. Somit wird von jeder Funktion f i k gefordert, dass:
und somit
Korrekturvorschläge
Auch wenn bei der Anwendung von f i k
f i k (m) ∈ M n UML, pre
M n UML, post ⊆ M n UML, pre
(5.5)
(5.6)
im Iterationsschritt i eine Menge von Modellen
hervorgeht, die die Nachbedingungen und somit auch die Vorbedingungen erfüllen, ist
nicht automatisch gewährleistet, dass im nächsten Iterationsschritt i + 1 die Vorbedingungen
der Eingabemodelle erfüllt sind. Bei der Bearbeitung anderer Aufgaben,
werden vermutlich ebenfalls einige der Modelle verändert. Die Vor- oder Nachbedingungen
anderer Aufgaben werden nicht berücksichtigt.
Wenn die Modelle jeweils nicht alle Vor- oder Nachbedingungen erfüllen, können die
Inkonsistenzen durch festgelegte Korrekturvorschläge behoben werden. Für eine Vorbedingung
prej kann eine Korrektur durch ein Funktion rpostj definiert werden:
Für jedes m ∈ M n UML,pre
1. m ∈ M n UML
2. cprei (m) = true, ∀1 ≤ i ≤ k
rpostj : M n UML,pre → M n UML,pre
gilt dann, dass es eine Vorbedingung k gibt, so dass:
3. cprek (m) = false und deshalb m /∈ M n UML,pre
(5.7)
57

5 Methodenunterstützung
Analog können Korrekturvorschläge für die Nachbedingungen festgelegt werden.
Konfiguration
Das Aufgabenmodell verlangt für die Unterstützung einer Aufgabe also eine ganze
Reihe von Parametern. Neben den UML-Modelle m, die von ihnen zu erfüllenden
l Vorbedingungen und den jeweiligen Korrekturen {rprej }1≤j≤l, gehören dazu
die während der Bearbeitung durchgeführten Modelländerungen repräsentiert durch
f i k , die durch cpost zu prüfenden p Vorbedingungen, die zugehörigen Korrekturen
{rpostj }1≤j≤p und schließlich das Traceability-Modell T zur Erkennung von Unstimmigkeiten.
Eine Konfiguration des Modells für eine Aufgabe ist wie folgt definiert:
K = (m, cpre, {rprej }1≤j≤l, f i k , cpost, {rpostj }1≤j≤p, T ) (5.8)
Auf der Basis einer solchen Konfiguration und den entsprechenden Parametern wird
das Aufgabenmodell in der technischen Umsetzung berücksichtigt.
5.1.4 Technische Umsetzung
Die Realisierung der vorgestellten konzeptionellen Lösung wird hauptsächlich durch
ein Iterative Task Framework geprägt. Die Unterstützung einer Aufgabe kann durch die
Realisierung eines TaskWizards geleistet werden, wie beispielsweise in Abschnitt 5.2.4
für die Unterstützung der Subsystem Identification beschrieben wird. Das Iterative Task
Framework überwacht den Lebenszyklus eines solchen aufgabenspezifischen TaskWizards
und berücksichtigt die vom Aufgabemodell definierten Eigenschaften (z. B. die
Prüfung von Vor- und Nachbedingungen).
Bearbeitungssequenz
Das zentrale Konzept bei der technischen Umsetzung des Aufgabenmodells ist die
Bearbeitungssequenz, durch die eine feste Reihenfolge bei der Bearbeitung einer Aufgabe
festgelegt wird. Es bedient sich der Paramatere einer aufgabenspezifischen Konfiguration
K:
58
1. Einlesen der Eingabemodelle m
2. Prüfung der Vorbedingungen (Integritätsverletzungen und Inkonsistenzen) durch
cpre und Anbieten eventueller Korrekturvorschläge
3. Modelländerungen während der aufgabenspezfischen Bearbeitung (f i k )
4. Prüfung der Nachbedingungen (Vorbedingungen, Unstimmigkeiten) durch cpost
und Anbieten eventueller Korrekturvorschläge
5. Speicherung der Ausgabemodelle bei erfolgreicher Beendigung

5.1 Allgemeine Unterstützung
Die Bearbeitung anhand dieser festen Reihenfolge kann allerdings nur dann zu einem
gültigen Ergebnis führen, wenn der Kontrollfluss während der Bearbeitung einer
Aufgabe sichergestellt werden kann. Es ist zu gewährleisten, dass keine Modelländerungen
während der Bearbeitung einer Aufgabe im Hintergrund vorgenommen werden
(z. B. durch den Entwickler). Ein Modell zu validieren, bevor es bearbeitet wird, hat
erst dann einen Nutzen, wenn während der Bearbeitung auch ausgeschlossen werden
kann, dass das Modell anderweitig verändert wird.
Nicht zuletzt aus diesem Grund, sollte jede aufgabenspezifische Methodenunterstützung
durch einen Wizard realisiert werden. Zum einen eignet er sich durch sein Anwendungsfeld
(vgl. Abschnitt 2.3.1) für die sequentielle Bearbeitung und zum anderen
kann der Kontrollfluss sehr einfach sichergestellt werden. Nach dem Starten können
keine Aktionen außerhalb dieses Wizards im Werkzeug durchgeführt werden, bis die
Bearbeitung beendet oder abgebrochen wurde.
Auf der einen Seite garantiert die Sicherstellung des Kontrollflusses durch einen Wizard
zwar die Einhaltung der Bearbeitungssequenz und die Gültigkeit einer durchgeführten
Validierung, aber auf der anderen Seite muss auf allgemeine Funktionalität
verzichtet werden, die durch das Werkzeug bereitgestellt wird. Das beinhaltet insbesondere
die Widerrufbarkeit von (Modell-)Änderungen.
Zunächst wird der allgemeine Aufbau eines TaskWizards beschrieben und anschließend
die Architektur des Iterative Task Frameworks und die Berücksichtigung von
Validierungen und der Widerrufbarkeit von Modelländerungen.
Aufbau eines TaskWizards
In einem TaskWizard kann die Bearbeitungssequenz unmittelbar durch die Reihenfolge
der Wizard-Seiten abgedeckt werden. Wie in Abbildung 5.7 am Beispiel der Subsystem
Identification demonstriert wird, besteht ein TaskWizard aus (mindestens) vier Seiten,
die folgend beschrieben werden:
1. ShowTaskDescriptionAndSelectModelWizardPage: Die erste Seite dient der Auswahl
des MeDUSA Projekts. Mit der Bereitstellung eines Projektwizards durch
die Infrastruktur (vgl. Abschnitt 4.3) kann ein MeDUSA-Projekt mit den zugehörigen
UML-Modellen erstellen. Die erste Seite eines TaskWizards bietet die
vorhandenen MeDUSA-Projekte zur Auswahl an. Sollten die Modellressourcen
seit der Erstellung durch den Projektwizard nicht umbenannt worden sein, werden
automatisch die entsprechenden Dateien durch Berücksichtigung der Standardeinstellungen
selektiert.
2. ValidationPage: Die zweite Seite dient der Überprüfung von Vorbedingungen.
Sollte eine Verletzung aufgetreten sein, kann, falls vorhanden, der entsprechende
Korrekturvorschlag angeboten werden. Dieser Aspekt wird im Abschnitt 5.1.4
vertieft.
59

5 Methodenunterstützung
60
Abbildung 5.7: Seiten eines TaskWizards
3. TaskInteractionPage: Die dritte Seite ist abhängig von der zu bearbeitenden Aufgabe.
In Abbildung 5.7 wird eine Unterstützung für die Subsystem Identification
angeboten. Die genauere Erläuterung dieser aufgabenspezifischen Funktionalität
wird im Abschnitt 5.2.4 vorgenommen.
4. ValidationPage: Die letzte Seite dient der Überprüfung der Nachbedingungen.
Sind keine Inkonsistenzen oder Unstimmtigkeiten aufgetreten, kann die Bearbeitung
im Anschluß durch Speicherung aller Modelländerungen beendet werden.

Architektur
5.1 Allgemeine Unterstützung
Bei der Betrachtung der Bearbeitungssequenz und insbesondere der Konfiguration des
Aufgabenmodells geht hervor, dass die Erstellung eines TaskWizards nur zu einem
geringen Teil von der eigentlichen Aufgabe abhängig ist. Die aufgabenunabhängigen
Bearbeitungssequenz wird im Iterative Task Frameworks durch einen TaskController
gewährleistet, der den gesamten Lebenszyklus eines TaskWizards überwacht. Alle
identifizierten Parameter einer Konfiguration K des Aufgabenmodells werden in einer
Instanz der Klasse TaskConfiguration gekapselt. Diese beinhaltet also alle UML-
Modelle, das Traceability-Modell, alle Vor- und Nachbedingungen und die dazugehörigen
Korrekturvorschläge einer Aufgabe. Zusätzlich kann eine Beschreibung der
Aufgabe angegeben werden, die auf der ersten Seite des TaskWizards angezeigt wird
(vgl. 5.7). Bis auf die Erstellung der aufgabenspezifischen Seiten ist der TaskController
dafür verantwortlich, alle aufgabenunabhängigen Wizard-Seiten in der Reihenfolge
entsprechend der Bearbeitungssequenz zu erstellen.
Für die Unterstützung einer konkreten Aufgabe ist also lediglich die Realisierung eines
speziellen TaskWizards erforderlich, mit dem die TaskConfiguration spezifiziert wird
und aufgabenabhängige Wizard-Seiten hinzugefügt werden.
Abbildung 5.8: Architektur des Iterative Task Framework
Die genau Architektur des Iterative Task Frameworks wird in Abbildung 5.8 dargestellt.
Für die Kapselung verschiedener Funktionalitäten verwendet der Controller unterschiedliche
Hilfsklassen:
1. ModelHandler: Der ModelHandler ist verantwortlich für das Laden und Speichern
von Modellressourcen. Die Funktionalität wird immer durch den TaskController
angestoßen.
61

5 Methodenunterstützung
2. UMLHelper: Jegliche Logik, die sich auf die Struktur des UML-Metamodells
bezieht (z. B. das Berechnen aller Lifelines der Interaktionen eines Modells),
wird durch die Klasse UMLHandler bereitgestellt.
3. TraceabilityHelper: Analog wird die Logik für die Handhabung des Traceability-Metamodells
in einer eigenen Klasse gekapselt.
4. TaskLogic: Für die Kapselung der Funktionalität für die Unterstützung einer
konkreten Aufgabe wird ein TaskPerformingHelper vordefiniert. Spezialisierungen
dieser Klasse besitzen über den TaskController Zugriff auf die jeweiligen
notwendigen Hilfsklassen. Aufgabenspezifische TaskLogicPages verwenden die
TaskLogic als Funktionskomponente.
5. ValidationHelper: Die Validierung zur Prüfung der Vor- und Nachbedingungen
wird vom ValidationHelper durchgeführt. Validierungen sind auf der Basis des
EMF Validation Frameworks realisiert und werden im folgenden Abschnitt erläutert.
Validierung und Korrekturvorschläge
Die Vor- und Nachbedingungen werden durch Conditions als Teil der TaskConfiguration
beschrieben (vgl. Abb. 5.8). Jede Condition kann mehrere Constraints beinhalten,
die auf der Basis des EMF Validation-Frameworks implementiert werden. Durch eine
Erweiterung dieses Frameworks, ist es bei der Verletzung eines Constraints außerdem
möglich, dem Entwickler die betroffenen Elemente anzeigen zu lassen und eventuelle
Korrekturvorschläge anzubieten.
62
Abbildung 5.9: Beispiel einer Validierung mit Korrekturvorschlag

5.2 Unterstützung der Subsystem Identification
Das Anzeigen einer ValidationPage wie in Abbildung 5.9 bewirkt unmittelbar die
Auswertung der definierten Constraints nach einer festgelegten Reihenfolge, wie es
im Aufgabenmodell durch die Funktion cpre definiert wurde. Dazu verwendet der
TaskController einen ValidationHelper, der die programmatische Schnittstelle zum
EMF Validation Framework bildet, um die Vor- oder Nachbedingungen zu überprüfen.
Sollte ein Constraint nicht erfüllt sein, wird die Validierung abgebrochen und,
falls verfügbar, ein Korrekturvorschlag angeboten. Abbildung 5.9 zeigt eine solche
Validierungsseite.
Widerrufbarkeit von Modelländerungen
Um dem Entwickler einen zusätzlichen Komfort bieten zu können, wird ihm die Möglichkeit
geboten, alle angestoßenen Änderungen des aktuellen Schritts der Bearbeitungsequenz
einer Aufgabe zu widerrufen aber auch zu wiederholen. Jede TaskWizardPage
kann in ihrer Oberfläche die entsprechende Funktionalität anbieten, durch
eine ValidationPage wird sie generell angeboten.
Modelländerungen werden technisch durch die Verwendung des EMF Command Frameworks
realisiert, indem sie in Commands gekapselt werden. Für das Verschmelzen
von mehreren Commands zu einem Einzigen stellt das Framework CompoundCommands
bereit. Dieser Zusammenhang wurde bereits in Abschnitt 2.3.2 beschrieben.
Damit jede für den Entwickler scheinbar atomare Aktion (Modelländerung) in einem
Schritt widerrufen werden kann, ist eine konsequente Kombination der entsprechenden
Commands zu einem einzigen CompoundCommand zwingend erforderlich. Sollten
mehrere Elemente bei der Durchführung einer Korrektur betroffen sein, darf der
mit jeder Änderung verbundene Command nicht einzeln ausgeführt werden. Möchte
der Entwickler nach der Durchführung einer Korrektur den vorherigen Zustand wiederherstellen,
so müsste er mehrere Änderungen widerrufen, obwohl er lediglich eine
einzige Aktion durchgeführt hat.
Nachdem nun ein allgemeines Framework beschrieben wurde, mit die Unterstützung
einzelner Aufgaben nach einem vordefinierten Schema realisiert werden kann, wird im
nächsten Abschnitt die prototypische Unterstützung der Subsystem Identification unter
Verwendung des Iterative Task Frameworks vorgestellt. Der Fokus dieser aufgabenspezifischen
Unterstützung liegt eher darauf, die Eignung des beschriebenen Frameworks
vorzuweisen, ohne dabei einen Anspruch auf die Vollständigkeit des prototypischen
TaskWizards zu erheben.
5.2 Unterstützung der Subsystem Identification
Im Abschnitt 2 wurde die Subsystem Identification als eine Aufgabe des Architectural
Designs vorgestellt, in der die Analyseobjekte durch Subsysteme zu partitionieren
sind. Neben der Beschreibung dieser Partitionierung wird in diesem Abschnitt erläutert,
welche Vor- und Nachbedingungen definiert werden müssen und wie die Model-
63

5 Methodenunterstützung
lierung durch eine Bewertung mittels Metriken unterstützt werden kann. Zuletzt wird
die technische Umsetzung durch die Verwendung des Iterative Task Frameworks erläutert.
5.2.1 Partitionierung der Analyseobjekte
Nachdem in der Analyse versucht wurde, alle Objekte der realen Anwendungswelt zu
identifizieren, wird in der ersten Aufgabe des Architectural Design ein Entwurf modelliert,
der entscheidend die Leistung des zu erstellenden Softwaresystems beeinflusst.
Bislang wurde allerdings nicht erläutert, auf welche Art und Weise Objekte mit der
UML realisiert werden können. Es entsteht eine Problematik durch den instanzgetriebenen
Ansatz von MeDUSA, da dieser durch die UML nicht unmittelbar abgedeckt
werden kann. Neben der Partitionierung selbst wird daher diese Problemstellung und
mögliche Lösungsalternative im folgenden Abschnitt diskutiert. Anschließend wird
der Aufbau eines Architekturmodells beschrieben, und es wird erläutert, wie die Analyseobjekte
und die modellierten Nachrichten auf entsprechende Elemente des Architekturmodells
abgebildet werden können.
Repräsentierung der Analyseobjekte
Mit der MeDUSA-Methode wird ein objektbasierter Ansatz verfolgt (vgl. Abschnitt
2), so dass in den Aufgaben aller Disziplinen Objekte modelliert werden, die mit Stereotypen
entsprechend der Objekttaxonomie versehen werden. Erst am Ende des Detailed
Design ist eine Erstellung von Klassen für die modellierten Objekte vorgesehen.
Im Gegensatz zu diesem instanzgetriebenen Ansatz definiert die UML das Konzept der
Abbildung 5.10: Diskrepanz zwischen MeDUSA und der UML
Classifier als ihr grundlegendes Modellierungskonzept (vgl. Abschnitt 2.2). Instanzen
von Classifiern werden in den unterschiedlichen Spracheinheiten nicht durchgängig repräsentiert.
Interaktionen können miteinander kommunizierende Lifelines beinhalten,
um somit das Verhalten von Instanzen zu einem bestimmten Zeitpunkt zu beschreiben.
64

5.2 Unterstützung der Subsystem Identification
Mit der Spracheinheit Classes können Objektdiagramme erstellt werden, in denen die
Objekte durch InstanceSpecification-Elemente repräsentiert werden. Unter Repräsentanten
eines Analyseobjekts werden im Folgenden alle Instanzen von UML-Elementen
verstanden, die in einem erstellten Modell Analyseobjekte repräsentieren.
Es gibt in der UML kein gemeinsames Konzept der einzelnen Sprachpakete, mit dem
beispielsweise definiert werden kann, dass eine Lifeline und eine InstanceSpecifications
als Repräsentanten des gleichen Objekts zu interpretieren sind. Diese Diskrepanz
der instanzgetriebenen Methode und der Classifier-getriebenen Beschreibungssprache
wird in Abbildung 5.10 verdeutlicht.
Der Zusammenhang zwischen der statischen Sicht auf identifizierte Objekte und der
dynamischen Sicht auf das Verhalten identischer Objekte ist bei der Entwicklung mit
MeDUSA ein sehr grundlegender Aspekt. Ohne eine konkrete Methodenunterstützung
bliebe es dem Entwickler selbst überlassen, auf welche Art und Weise er zusammengehörende
Elemente berücksichtigt, beispielsweise durch Namenskonventionen, zusätzlicher
Dokumentation oder schlicht seinem Erinnerungsvermögen. Noch schwerwiegender
wird die Problematik durch den Einsatz der modellgetriebenen Entwicklung.
Wie kann der Code eines Objekts bzw. einer Klasse generiert werden, wenn nicht klar
festgelegt werden kann, durch welche Elemente ein Objekt beschrieben wurde?
Im Sinne einer geeigneten Unterstützung, auch hinsichtlich des modellgetriebenen Ansatzes,
muss also eine Lösung gefunden werden, mit der die Diskrepanz zwischen der
UML und MeDUSA (s. Abb. 5.10) bezüglich dieser Problematik ausgeglichen werden
kann.
Lösungsansätze Da die allgemeine und einheitliche Repräsentierung von Analyseobjekten
nicht durch die Verwendung der UML gewährleistet werden kann, müssen
die unterschiedlichen Repräsentanten auf ein im Modell semantisch nicht explizit modellierbares
Objekt abgebildet werden. Dafür sind folgende Ansätze denkbar:
• Namenskonventionen: Durch eine bestimmte Namenskonvention der Repräsentanten
kann die Zusammengehörigkeit ausgedrückt werden. Diese Möglichkeit
entspricht allerdings weder den Modellierungskonzepten der UML, noch
ist es für den Entwickler intuitiv und würde eine starke Einschränkung bei der
Modellierung erzwingen. Schreibfehler könnten zudem unkontrollierbare Auswirkungen
haben.
• Einsatz von Classifiern: Eine bessere Lösung für den betrachteten Kontext bietet
der Einsatz von Classifiern, indem jedes Analyseobjekt durch genau einen
Classifier im Modell repräsentiert wird. Sowohl InstanceSpecifications als auch
Lifelines könnten dann (über Umwege) mit einem Classifier verbunden werden.
Ein Analyseobjekt könnte als eine Singleton-Instanz eines solchen Classifiers
verstanden werden. Auch wenn dieses Konzept mit den Standardmitteln der
UML realisierbar ist, wird der Entwickler auch hier zu einer Modellierungsart
gezwungen, deren Ursache nur durch eine technische Notwendigkeit begründet
wird. Die Repräsentanten aus den unterschiedlichen Diagrammtypen der
65

5 Methodenunterstützung
Sprachpakete, müssten sehr speziell zu einem gemeinsames Konzept gezwungen
werden. Zusätzlich wäre es wohl sehr irreführend in den Augen eines Entwickler,
wenn er eine objektbasierte Modellierung betreiben würde und im Modell
Classifier-Elemente vorfände.
• Verwendung von Stereotypen: Völlig unabhängig von dem Typ des Repräsentanten,
können Abbildungsinformationen in den Stereotypen der jeweiligen
Modellelemente abgelegt werden. Element und Abbildungsinformation befänden
sich damit im gleichen Modell. Mit diesem Konzept können also beliebige
Elemente durch Metainformationen miteinander verbunden werden, indem die
für die Objekttaxonomie verwendeten Profile und Stereotypen hinsichtlich einer
Möglichkeit erweitert werden, diese Information ablegen zu können. Diese
Realisierung könnte beliebige Sprachpakete berücksichtigen werden.
Damit jedes UML-Modell eine in sich abgeschlossene Einheit bildet, sollten alle Modellierungsinformationen
in dem Modell selbst vorliegen, so dass die Erweiterung der
UML-Profile als Lösungs gewählt wird. Die Analyseobjekte werden implizit durch
einen eindeutigen Identifier dargestellt. Die Repräsentanten eines Objekts besitzen
durch die UML-Profile für die MeDUSA Objekttaxonomie genau einen angewendeten
Stereotypen. Der Identifier des repräsentierten Analyseobjekts kann in einem zusätzlichen
Attribut aller Stereotypen festgehalten werden.
Nach oder während der Erstellung der einzelnen Arbeitsergebnisse in der Analyse
müssen die modellierten Repräsentanten den so implizit identifizierten Objekten zugeordnet
werden, indem der Identifier des Objekts dem (angewendeten Stereotyps des)
Repräsentanten zugewiesen wird.
Aufbau des Architekturmodells
Entsprechend dem MeDUSA Methodeninhalt (vgl. Abschnitt 2.1.1) wird bei der Entwicklung
des Architectural Design Models für jedes Subsystem ein Komponentendiagramm
erstellt. Eine Betrachtung der Subsysteme im Systemkontext wird erst im darauf
folgenden Structural System Architecture Modelling vorgenommen. In der zweiten
Aufgabe des Architectural Design werden u. a. die provided bzw. required-Interfaces
der einzelnen Subsysteme miteinander in Beziehung gesetzt werden.
Die Methodenunterstützung für die Subsystem Identification erstellt neben den Komponenten
für die Subsysteme bereits auch die System-Komponente. Die durch den Entwickler
modellierten Subsysteme werden durch Properties, die die jeweiligen Subsysteminstanzen
darstellen, im Gesamtsystem repräsentiert. Die Schnittstellen der Subsystemkomponenten
werden dabei außer Acht gelassen, um eine klare Trennung zur
Unterstützung der darauffolgenden Aufgabe zu bilden.
Der Zusammenhang zwischen System und Subsystemen wird in Abbildung 5.11 aufgeführt.
Die Subsystemkomponenten beinhalten bereits einige Objekte, mit denen die
„partitionierten“ Analyseobjekte widergespiegelt werden.
66

5.2 Unterstützung der Subsystem Identification
Abbildung 5.11: Subsystem als Komponente und Property der System-Komponente
Abbilden der Analyseobjekte
Die Partitionierung der Analyseobjekte ist eine sehr bildhafte Bezeichnung. Genau genommen,
werden die Objekte nicht in Subsystemen gruppiert, sondern für sie werden
neue Elemente im Architekturmodell erstellt.
Mit Hilfe der Methodenunterstützung muss der Entwickler Subsysteme erstellen und
entfernen können und die Analyseobjekte auf die einzelnen Subsysteme abbilden. Das
neue Element (eine Property, vgl. Abb. 5.11) wird durch den Einsatz eines Traceability-Modells
mit den Repräsentanten des Analyseobjekts verbunden. Die so entstehenden
Mappings werden zu einem Step zusammengefasst, wie es beispielhaft bereits in
der Abbildung 5.3 im Abschnitt 5.1.2 dargestellt wurde.
Gruppierung von Nachrichten
Neben der Partitionierung der Analyseobjekte, müssen die Nachrichten zwischen den
Repräsentanten im Entwurf berücksichtigt werden. Kommunizieren die Repräsentanten
von Objekten miteinander, die auf das gleiche Subsystems abgebildet wurden, erfordert
das kein besonderes Augenmerk. Befinden sich miteinander kommunizierende
Objekte allerdings in unterschiedlichen Subsystemen, müssen die Nachrichten über
Ports und Interfaces (vgl. Abschnitt 2.2) realisiert werden. Die Unterscheidung beider
Fälle kann durch eine geeignete Werkzeugunterstützung vorgenommen werden.
Die Erstellung der Ports als auch die Zuteilungen der Interface-Elemente zu den Ports
wird durch den Entwickler durchgeführt.
67

5 Methodenunterstützung
5.2.2 Validierung und Korrekturvorschläge
Für die Methodenunterstützung der Subsystem Identification muss vor der Bearbeitung
sichergestellt werden, dass jeder potentielle Repräsentant auch tatsächlich einem Analyseobjekt
zugeordnet ist. Jeder Repräsentant muss genau einen angewendeten Stereotypen
des MeDUSA-Analyseprofils besitzen, der einen gültigen Identifier beinhaltet.
Für die Korrektur einer auftretenden Inkonsistenz könnte dem Entwickler die Möglichkeit
gegeben werden, unspezifizierte Repräsentanten zu identifizieren und die Zuordnung
anzupassen. Es sind folgende Vorbedingungen durch das Analysemodell zu
erfüllen, die unter einander Abhängigkeiten besitzen und deshalb wie im Aufgabenmodell
spezifiziert eine Ordnung besitzen:
1. Jeder Repräsentant muss genau einen angewendeten Stereotypen besitzen
2. Die angewendeten Stereotypen aller Repräsentanten eines Analyseobjekts müssen
von der gleichen Art sein
3. Für jeden Repräsentanten muss ein gültiger Identifier spezifiziert worden sein,
durch den das Analyseobjekt implizit definiert wird
Analog muss das Architectural Design Model vor der Fertigstellung der Bearbeitung
die Nachbedingungen erfüllen, dass keine Unstimmigkeiten vorhanden sind. Mit Hilfe
des Traceability-Modells kann die Durchgängikeit des Analysemodells und des Entwurfs
sichergestellt werden. Es ist zu prüfen, ob jedes Analyseobjekt durch eine Property
berücksichtigt wurde und diese Property den gleichen Stereotypen besitzt.
5.2.3 Bewertung durch Metriken
Alle vom Entwickler durchgeführten Modelländerungen können durch Metriken bewertet
werden, damit diesem bei der Modellierung ein Indiz für die relative Qualitätsänderung
während der Bearbeitung der aktuellen Aufgabe gegeben werden kann. Die
Erstellung der Subsysteme und die Verteilung der Interfaces auf Ports eines Subsystems
bestimmen die grobe Architektur und haben starken Einfluss auf die Leistung des
zu erstellenden Softwaresystems.
Auswahl der Metriken Eine Bewertung der Subsystem Partitionierung und der
Aufteilung der Interfaces kann auf zwei Ebenen stattfinden:
68
• Bewertung des Subsystems: Unabhängig vom Systemkontext kann jedes Subsystem
einzeln bewertet werden
• Bewertung des Systems: Zusätzlich kann das Gesamtsystem abhängig von der
Partitionierung der Subsysteme bewertet werden

5.2 Unterstützung der Subsystem Identification
Die Anwendung von Metriken für ein einzelnes Subsystems hat nur eine begrenzte
Aussagekraft. Selbst wenn die Bewertung sehr schlecht ausfällt, kann im Systemkontext
eine ausreichende Lösung vorzufinden sein. Andererseits kann aber auch eine
defizitäre Modellierung vorliegen, obwohl sich keine Bewertung eines Subsystem als
negativ hervorhebt. Der kombinierte Einsatz von Metriken beider Ebenen bietet eine
sinnvolle Hilfestellung.
Werkzeuge und Metamodelle Es gibt zwei gründsätzlich verschiedene Ansätze
für die Integration von Metriken in Eclipse-basierte Entwicklungumgebungen:
• Die meisten existierenden Werkzeuge berechnen Metriken auf der Basis des
Quelltextes eines Softwaresystems oder Teilen davon. Beispielhaft kann hier das
Eclipse Plugin Metrics [Sau] aufgeführt werden.
• Eine völlig andere Herangehensweise wird durch das ATLAS Transformation
Language (ATL) Projekt in Zusammenarbeit mit der Université de Nantes vorangetrieben.
Durch eine Modell-zu-Modell Transformation wird für ein vorliegendes
UML-Modell die Instanz eines Metrik-Metamodells berechnet. Auf der
Basis dieses Metrikmodells wird eine Modell-zu-Code Generierungen durchgeführt,
um verschiedene Diagramme und Übersichten zu erstellen, mit denen die
zu den Metriken gehörenden Maßzahlen visualisiert werden [VBBJ06].
Leider kann keines der beiden Ergebnisse eingesetzt werden. Ein Werkzeug, das seine
Berechnungen durch Evaluierung des Quelltextes durchführt, ist im Rahmen der modellgetriebenen
Entwicklung für die Bewertung eines UML-Modells nicht anwendbar.
Der zweite Ansatz eignet sich zwar konzeptionell, kann aber aufgrund technischer Hindernisse
nicht eingesetzt werden. Die Abbildung auf ein Metrikmodell kann nur dann
erfolgen, wenn das zu transformierenden UML-Modelle keine angewendeten Profile
besitzt. Zusätzlich ist die Transformation bzw. Generierung ein langwieriger Prozess,
der nicht ständig während der Modellierung durch den Entwickler ausgeführt werden
kann.
Visualisierung Das Anwenden von Metriken ist die Berechnung Maßzahlen, die
zusammen mit einer Interpretion ein Indiz für die Qualität des Modells liefern. Das
Anzeigen der einzelnen Maßzahlen ist nicht sehr aussagekräftig, da aufgrund der Unübersichtlichkeit
Änderungen nur sehr schwer wahrgenommen und interpretiert werden
können. Es sollte somit eine geeignete grafische Visualisierung eingesetzt werden.
Eine übersichtliche Darstellung der Maßzahlen ist z. B durch Kiviat-Charts möglich
(vgl. Abb. 5.12). In einem Diagramm können mehrere Metriken gleichzeitig berücksichtigt
werden, indem auf einer geordneten Skala vom Nullpunkt ausgehend die berechneten
Maßzahlen eingetragen, und die Werte benachbarter Metriken miteinander
verbunden werden. Bei einer ausreichend großen Menge von Metriken entspricht eine
Änderung der aufgespannten Fläche annäherungsweise einer Änderung der Gesamtbewertung.
69

5 Methodenunterstützung
Abbildung 5.12: Beispiel eines Kiviat-Charts (Quelle: [Sof])
Nachdem nun die Inhalte der Methodenunterstützung für die Subsystem Identification
erläutert wurden, wird im nächsten Abschnitt die technische Realisierung vorgestellt.
5.2.4 Technische Umsetzung
Die technische Umsetzung der beschriebenen Unterstützung der Subsystem Identification
beruht auf der Verwendung des Iterative Task Frameworks und der Definition einer
TaskConfiguration. Neben der Nutzung des Frameworks wird die zusätzliche, aufgabenspezifische
Seite für die spezielle Unterstützung der Analyseobjekt-Partitionierung
beschrieben. Die Umsetzung von Metriken zur Bewertung des Systems bzw. der Subsysteme
konnte aus zeitlichen Gründen nicht fertiggestellt werden.
Nutzung des Iterative Task Frameworks
Die Unterstützung einer Aufgabe wird durch die Erstellung eines speziellen TaskWizards
realisiert. Sowohl die Seite zur Auswahl eines MeDUSA-Projekts, als auch die
für die Validierung der UML-Modelle notwendigen Seiten werden durch das Framework
automatisiert erstellt. Durch den SubsystemIdentificationWizard ist also lediglich
eine TaskConfiguration zu definieren und die zusätzliche aufgabenspezifische Seite bereitzustellen.
Abbildung 5.13 zeigt die Verwendung des Framework für die Unterstützung
der Subsystem Identification, wobei die neuen Klassen farblich hervorgehoben
sind.
70

5.2 Unterstützung der Subsystem Identification
Abbildung 5.13: Verwendung des Iterative Task Frameworks
Die aufgabenspezifische Konfiguration enthält neben dem Traceability-Modell sowohl
das Analyse- und Architekturmodell als auch die Vor- und Nachbedingungen und
eventuelle Korrekturvorschläge, die im Abschnitt 5.2.2 beschrieben wurden. Die für
die Erstellung der Konfiguration nötige Logik ist aus dem TaskWizard extrahiert worden
und im SubsystemIdentificationController implementiert. Die AnalysisObjectPartitioningLogic
beinhaltet die Anwendungslogik für die Partitionierung und interagiert
dafür mit dem UMLHandler und dem TraceabilityHandler, die durch das Framework
zur Verfügung gestellt werden (vgl. Abschnitt 5.1.4).
Aufbau der aufgabenspezifischen Seite
Für die Bearbeitung der Subsystem Identification wird eine Hauptansicht auf das System
mit den Subsystemen geboten und verschiedene Ansichten auf ein ausgewähltes
Subsystem, wie in Abbildung 5.14 dargestellt. Es gibt eine Detailansicht für die Partitionierung
der Analyseobjekte, indem Parts im Subsystem erstellt werden, eine Ansicht
für das Verteilen von Interfaces auf Ports, um damit die Nachrichten zwischen
Repräsentanten zu berücksichtigen, und eine Ansicht für die Bewertung durch Metriken.
System-Ansicht In der Hauptansicht können Subsysteme erstellt, umbenannt und
gelöscht werden. Das Selektieren eines Subsystems aktualisiert den Inhalt der Subsystemansichten.
Jede Detailansicht wird durch einen Kartenreiter realisiert und implementiert
eine abstrakte Schnittstelle, über welche die aktuelle Subsystemauswahl
71

5 Methodenunterstützung
in der oberen Systemansicht zu den Subsystemansichten propagiert wird. Durch diese
Nachricht kann jede Detailansicht ihren Inhalt gemäß dem gewählten Subsystem
anpassen.
Abbildung 5.14: Aufgabenspezifische Seite zur Partitionierung der Analyseobjekte
Parts-Ansicht In der Parts-Ansicht werden die zu partitionierenden Analyseobjekte
auf der linken Seite durch eine Baumstruktur angezeigt. Die bereits auf Subsysteme
verteilten Objekte werden in dem Ordner Assigend zusammengefasst und die noch zu
verteilenden entsprechend im Ordner Remaining. Jedes Analyseobjekt wird durch die
Angabe seines Identifier dargestellt. Die Repräsentanten eines Analyseobjekts werden
als untergeordnete Knoten in die Ansicht eingefügt. Durch einen einfachen drag&drop
Mechansimus können Analyseobjekte aus der Gruppe Remaining einem selektierten
Subsystem durch das „Ziehen“ der Elemente auf die rechte Seite zugeordnet werden.
Die Parts der Subsysteme werden auf der rechten Seite als untergeordnete Knoten des
betrachteten Subsystems angezeigt. Auch diese Elemente können umbenannt, gelöscht
oder einem anderen Subsystem zugewiesen werden. Letzteres ist ebenfalls durch einen
drag&drop Mechanismus realisiert. Parts eines Subsystems können auf der rechten
Seite ausgewählt und anderen Subsystemen über die Systemansicht zugeteilt werden.
72

5.2 Unterstützung der Subsystem Identification
Abbildung 5.15: Abbilden der Nachrichten auf Interfaces und Ports
Ports-Ansicht Neben der Abbildung der Analyseobjekte auf Parts der Subsystemen,
müssen, wie in Abschnitt 5.2.1 erläutert, die Nachrichten zwischen Objekten
verschiedener Subsysteme durch Interfaces im Entwurf widergespiegelt werden. Abbildung
5.15 zeigt den Inhalt der entsprechenden Detailansicht. Ähnlich wie bei Analyseobjekten
und Parts werden für Nachrichten Interfaces erstellt, wenn diese einem
modellierten Port zugewiesen werden. Die Entscheidung, ob es sich bei dem neuen
Interface-Element um ein required oder provided Interface handelt, kann unmittelbar
durch das Werkzeug getroffen werden, da die Richtung der Nachricht lediglich davon
abhängt, ob sich das sendende oder das empfangende Objekt im aktuellen Subsystem
befindet. Es werden nur diejenigen Nachrichten auf der linken Seite repräsentiert, deren
Empfänger oder Sender im aktuell betrachteten Subsystem liegen. Sollten beide
Objekte im gleichen Subsystem liegen, ist keine Abbildung auf Interfaces notwendig.
Nach der Definition eines festen Rahmens für mögliche Aufgabenunterstützungen und
der Beschreibung einer konkrete Unterstützung für die Subsystem Identification in diesem
Kapitel, wird im Anschluß die Umsetzung der Prozessintegration vorgestellt.
73

5 Methodenunterstützung
74

6 Prozessintegration
Die Kapitel 4 als Teil der Vision beschriebenen Aspekte einer möglichen Prozessintegration,
werden in diesem Kapitel aufgegriffen und analysiert, um im Anschluß sowohl
die konzeptionelle als auch die technische Lösung zu präsentieren. Die Prozessintegration
beinhaltet die folgenden zwei Punkten:
1. Prozessbeschreibung: Auf der Basis von HTML-Dateien kann ein Beschreibung
von MeDUSA in das Eclipse-Hilfesystem integriert werden. Für diese Erweiterung
ist neben der Erstellung der eigentlichen Inhalte die Bereitstellung einer
Navigationsstruktur erforderlich, mit der die Inhalte referenziert werden können
(vgl. Abbildung 6.1, rechte Seite).
2. Ablaufmodellierung: Eine Durchführung des MeDUSA-Prozesses soll durch die
Ausführung von CheatSheets ermöglicht werden (vgl. Abb. 6.1, linke Seite). Für
jede Aufgabe wird kontextabhängig eine Hilfe angeboten, mit der die entsprechenden
Inhalte der Prozessbeschreibung referenziert werden können.
6.1 Analyse
Abbildung 6.1: CheatSheets und Prozessbeschreibung
Die Erstellung der CheatSheets und der Prozessbeschreibung (in Form von HTML-
Dateien) wäre wohl sehr aufwändig, wenn die Realisierung beider Konzepte ohne weitere
Hilfsmittel durchgeführt werden müsste. Änderungen an der MeDUSA-Methode
wären in beiden Arbeitsergebnissen entsprechend zu aktualisieren, so dass eine schlechte
Wartbarkeit vorläge. Im folgenden Abschnitt wird daher untersucht, wie ein Modell
75

6 Prozessintegration
der Methode erstellt werden kann, um daraus sowohl die Prozessbeschreibung als auch
die CheatSheets generieren zu können (vgl. Abbildung 6.2).
Abbildung 6.2: Generieren der Prozessbeschreibung und des Ablaufmodells
Durch die automatisierte Erstellung unter der Verwendung eines speziellen Modells
wird die Änderbarkeit verbessert, denn durch das erneute Generieren der Arbeitsergebnisse
würden Modifikationen des Modells unmittelbar berücksichtigt werden. Zusätzlich
könnte ein Nutzen im Sinne der Wiederverwendung gezogen werden, da dieser
Vorgang auch für andere Prozessmodelle durchgeführbar wäre. Der beschriebene Ansatz
würde die Umsetzung eines Werkzeuges herbeiführen, das kein Bestandteil der
eigentlichen Prozessintegration darstellt, mit dem aber sehr wohl die Erstellung der
CheatSheets und Prozessbeschreibung automatisiert und werkzeuggestützt durchgeführt
werden kann.
6.1.1 Modellierung von Entwicklungsprozessen
Entwicklungsprozesse bestehen im Wesentlichen aus vier Elementen: in einer speziellen
Rolle bearbeitet ein Softwareentwickler Aufgaben, in denen er Arbeitsergebnisse
produziert (vgl. Abbildung 6.3). Die Bearbeitung der verschiedenen Aufgaben erfolgt
dabei nach einem bestimmten Ablauf (Workflow).
Abbildung 6.3: Kollaboration Rolle, Arbeitsergebnis und Aufgabe [SPE05]
Für die Modellierung von Prozessen gibt es unterschiedliche Notationen und Begriffsmodelle.
Prozesse, bzw. die darin enthaltenen zeitlichen Abläufe, werden oft durch
grafische Notationen modelliert. Für die Realisierung von geschäftlichen Prozessen
in der Betriebswirtschaftslehre wird die so genannte Business Process Management
76

6.1 Analyse
Notation (BPMN) verwendet. Prozesse können auf einem Application-Server anhand
des erstellten Modells ausgeführt werden. Dieser Ansatz ist allerdings nicht mit dem
Werkzeug ViPER vereinbar und somit für den betrachteten Kontext nicht von Relevanz.
In der Softwaretechnik werden für die Modellierung von Prozessen beispielsweise
Flußdiagramme oder UML-Aktivitätsdiagramme verwendet, wobei der Schwerpunkt
auf der Ablaufbeschreibung liegt.
Eine andere Herangehensweise bildet die Modellierung entlang des Software Process
Engineering Metamodels (SPEM). Im Vordergrund dieses Metamodells steht nicht die
Ablaufmodellierung, sondern vielmehr die Beschreibung eines gesamten Prozessmodells.
Die nächste Version dieser Spezifikation soll sich auf die Unified Method Architecture
(UMA) stützen. UMA stammt zu großen Teilen aus der Industrie und wurde
von einigen namhaften Firmen entwickelt.
Hinsichtlich der oben genannten Elemente der Prozessmodellierung wird zunächst die
Ausdrucksstärke von UML-Aktivitätsdiagramme untersucht und im Anschluss SPEM
und UMA vorgestellt.
UML (Aktivitätsgraphen)
Die UML wurde bereits im Abschnitt 2.2 als Beschreibungssprache vorgestellt. Sie
stellt diverse Sprachpakete und Diagrammtypen zur Verfügung, mit denen Softwaresysteme
sowohl aus einer statischen als auch aus einer dynamischen Sicht beschrieben
werden können. Aktivitätsdiagramme bilden eine grafische Notation der UML
für Aktivitätsgraphen, durch die dynamisches Verhalten geeignet dargestellt werden
kann[Obj07], um z. B. Algorithmen und Geschäftsprozesse zu modellieren [Bal01]:
An activity state represents the execution of statements in a procedure or
the performance of an activity in a workflow. [Rum99]
Aktivitätsdiagramme bestehen aus Aktionszuständen, Zustandsübergängen, Entscheidungspunkten
und Synchronisationsbalken. Ein Aktionszustand wird genau dann verlassen,
wenn die mit ihm verbundene Verarbeitung beendet ist [Rum99]. Mittels Entscheidungspunkten
an Zustandsübergängen kann eine Verzweigung des Kontrollflusses
(in Abhängigkeit von Bedingungen) spezifiziert werden. Nebenläufigkeit der Verarbeitungsschritte
kann durch den fork- und join-Synchronisationsbalken modelliert
werden, um eine Aufteilung bzw. Zusammenführung des Kontrollflusses abzubilden
[Bal01].
Aufgaben eines Entwicklungsprozesses könnten also durch Aktivitäten (Aktionszuständen)
repräsentiert werden. Für die Modellierung von Aufgaben, die von einer Rolle
gleichzeitig bearbeitet werden können, eignet sich die Verwendung von den genannten
forks und joins zur Modellierung der Nebenläufigkeit.
77

6 Prozessintegration
Es besteht die Möglichkeit, dass die „ [. . . ] Aktions-Zustände eines Aktivitätsdiagramms
[. . . ] in »Schwimmbahnen« (swim lanes) angeordnet werden, um die Verantwortung
für diese Aktionen Klassen oder organisatorischen Einheiten zuzuordnen.“
[Bal01] Durch swim lanes könnten also Rollen repräsentiert werden.
Damit bestünde die Möglichkeit, Rollen, Aufgaben und die damit verbundenen Abläufe
in einem Aktivitätsdiagramm zu erfassen. Neben ein paar technischen Problemen,
wie der Darstellung von Arbeitsergebnissen, birgt die Modellierung mit einer derartigen
grafischen Notation allerdings ein schwerwiegendes Problem, da keine klare Semantik
des Modellierten vorliegt. Beispielsweise ist nicht klar, was ein Aktionszustand
genau repräsentiert: eine Aufgabe, eine Aktivität oder eine Phase? Des weiteren können
lediglich die Bestandteile des Prozesses bzw. der Methode dargestellt werden, eine
Beschreibung der jeweiligen Elemente ist nicht möglich.
Es fehlt also ein semantischer Rahmen und eine Terminologie zur allgemeinen Beschreibung
von Prozessmodellen. Diese Sichtweise wird von den folgend beschriebenen
Metamodellen aufgegriffen.
SPEM 1.0
Heutzutage gibt es diverse Methoden und Prozesse zur Durchführung eines Softwareentwicklungsprojekts.
Die unterschiedlichen Metamodelle, aber auch die sich teilweise
widersprechenden Begrifflichkeiten, machen es fast unmöglich, eine Kombination
von Konzepten oder best practices verschiedener Methoden für ein einzelnes Projekt
zu nutzen. Die Object Management Group (OMG) versucht deshalb seit dem Jahr 2002
mit dem Software Process Engineering Metamodel (SPEM), dieser entstandenen Diskrepanz
zu begegnen [Gau06].
Ziel von SPEM ist die Einführung einer einheitlichen und allgemeingültigen Terminologie
und Semantik zur Beschreibung von Methoden und Entwicklungsprozessen.
Die Spezifikation [SPE05] macht sehr deutlich, dass das Metamodell vornehmlich der
Beschreibung eines Prozesses und nicht der Planung oder Durchführung eines Projekts
dienen soll. Das zentrale Konzept wird durch den in Abbildung 6.3 betrachteten
Zusammenhang von Rolle, Aufgabe und Arbeitsergebnissen gebildet.
Obwohl das SPEM Metamodell als UML 1.4 Profil verfügbar ist und damit potentiell
jedes UML 1.4-konforme Werkzeug zur Modellierung verwendet werden kann, wurde
in der Praxis kein damit modellierter Prozess veröffentlicht [Gau06]. Des Weiteren
erfolgte auch keine Realisierung eines Werkzeuges, mit dem explizit die Modellierung
von Prozessen unterstützt werden sollte. Im Jahr 2005 wurde die Spezifikation mit
kleinen Änderungen in der Version 1.1 veröffentlicht, die sich ebenfalls nicht in der
Praxis hat durchsetzen können [SPE07].
78

SPEM 2.0 / UMA
6.1 Analyse
Die OMG hat im November 2004 dazu aufgerufen, Vorschläge für SPEM 2.0 einzureichen
[SPE07]. Die Unified Method Architecture (UMA) bildet die Basis für die
Einreichung der Firmen Adaptive Ltd., Fujitsu & Fujitsu Consulting, Fundacion European
Software Institute, IBM Corporation und Softeam. Nach dem aktuellen Stand
wird sich die neue Spezifikation zu großen Teilen auf das UMA-Metamodell stützen
[Hau07], und im Oktober 2007 veröffentlicht werden [SPE07].
Im Folgenden werden die grundlegenden Konzepte und ein Teil der Terminologie vorgestellt.
Ein umfangreiche Übersicht der Terminologie mit jeweiligen Übersetzungen
und dem Vergleich zu Begriffen vorhandener Entwicklungsprozessmodelle wurde aus
[Gau06] übernommen und kann am Ende dieses Kapitels auf der Seite 97 betrachtet
werden.
Abbildung 6.4: Trennung von Methodeninhalt und Prozess (Quelle: [Hau07])
Trennung von Methodeninhalt und Prozess Das grundlegende Prinzip von
UMA ist die strikte Trennung des Methodeninhalts von dem Prozess, wie Abbildung
6.4 verdeutlichen soll. Während der Methodeninhalt die Aufgaben, Rollen und Arbeitsergebnisse
beinhaltet und Disziplinen für deren Gruppierung bereitstellt, definiert
der Prozess die zeitliche Abfolge der einzelnen Aufgaben unter Verwendung von Iterationen,
Phasen und Aktivitäten. Durch die Betrachtung des Methodeninhalts und des
Prozesses als unabhängige Dimensionen, werden die Elemente beider Kategorien nicht
nur strukturell von einander getrennt, sondern es besteht zusätzlich die Möglichkeit,
identische Methodeninhalte durch verschiedene Prozessen zu referenzieren. Dadurch
kann eine Wiederverwendung der Methodeninhalte und damit eine Verringerung von
Redundanzen gewährleistet werden.
Prozess Das wichtigste Element bei der Modellierung von Prozessen ist die Aktivität.
Eine Aktivität kann andere Aktivitäten beinhalten, aber auch Meilensteine definieren
oder beispielsweise Aufgaben und Rollen aus dem Methodeninhalt referenzieren.
UMA definiert darauf aufbauend verschiedene Typen von Aktivitäten [SPE07]:
79

6 Prozessintegration
• Phase: „Eine Phase repräsentiert eine Periode in einem Projekt, deren Ende
durch bedeutende Kontrollpunkte des Managements, einen Meilenstein oder einer
Menge fertigzustellender Ergebnisse definiert ist.“
• Iteration: „Eine Iteration gruppiert eine Menge von Aktivitäten, die mehrfach
wiederholt werden können. Sie repräsentiert also ein wichtiges strukturelles Element,
um Aktivitäten in einem iterativen Zyklus zu organisieren.“
• Prozess: „Ein Prozess ist eine spezielle Aktivität, die eine Struktur für eine spezielle
Art von Entwicklungprojekten oder Teilen von solchen beschreibt.“
Die Modellierung einer Aktivität und damit auch die eines Prozesses wird auf zwei
Stufen durchgeführt. Wie Abbildung 6.5 verdeutlicht wird der Prozess zunächst als
eine Hierarchie von Aktivitäten, Phasen und Iterationen durch einen Arbeitsstrukturbaum
repräsentiert. Die zeitlichen Abläufe der referenzierten Aufgaben und untergeordenten
Aktivitäten können des Weiteren durch Aktivitätsdiagramm beschrieben werden.
Wohlbemerkt wird das im Abschnitt 6.1.1 hervorgehobene Problem einer fehlenden
Semantik der Aktionszustände durch die Anwendung des UMA-Metamodells
behoben.
Abbildung 6.5: Arbeitsstrukturbaum und Aktivitätsdiagramm einer Aktivität
Wiederverwendbare Aktivitäten können durch Prozessmuster definiert werden, die in
dem Arbeitstrukturbaum eines Prozesses an verschiedenen Stellen durch die Angabe
des Aktivitätstypen (Aktivität, Phase, Iteration) eingesetzt werden können.
Das Referenzieren des Methodeninhalts in Prozesselementen wird durch den Einsatz
von Deskriptoren im Arbeitsstrukturbaum ermöglicht, die anstelle des eigentlichen
Elements eingesetzt werden. In Abbildung 6.5 werden beispielsweise Aufgaben indirekt
durch die Verwendung von Aufgabendeskriptoren eingefügt. Die Eigenschaften
referenzierter Elemente können durch Deskriptoren für eine spezielle Verwendung erweitert
oder verändert werden, wobei das ursprüngliche Element unverändert bleibt.
80

6.1 Analyse
Hilfestellungen Hilfestellungen dienen der Bereitstellung von zusätzlichem Material
für die Beschreibung anderer Elemente und sind deshalb sowohl Bestandteil des
Methodeninhalts als auch des Prozesses. Genau wie bei dem Aktivitäten-Element gibt
es für eine Hilfestellung verschieden Ausprägungen. Ein vordefinierter Typ einer Hilfestellung
ist der Werkzeugmentor, durch dessen Nutzung eine Bedienungsanleitung
für ein Werkzeug, das bei der Bearbeitung von Aufgaben verwendet wird, erstellt werden
kann. Es besteht dann die Möglichkeit, einen modellierten Werkzeugmentor durch
die entsprechenden Aufgabe zu referenzieren.
Methodenbibliothek und Konfiguration Der Methodeninhalt und die Prozesse
werden durch eine Methodenbibliothek zusammenfasst. Für die konkrete Verwendung
eines Prozessmodells in einem Projekt können durch eine Methodenkonfiguration
beliebige Elemente der Methodenbibliothek gewählt und projektspezifisch angepasst
werden. Auch bei dieser Referenzierung anderer Elemente bleiben die ursprünglichen
Elemente unverändert.
Zusammenfassung UMA stellt also eine Begriffshierarchie für die Modellierung
von Methoden und Entwicklungsprozessen zur Verfügung und erklärt wie Methodeninhalte
für verschiedene Prozessmodelle verwendet werden können. Die statische
Struktur des Prozesses wird durch Arbeitsstrukturbäume definiert; die zeitliche Abfolge
durch Aktivitätsdiagramme. Aus dem Methodeninhalt und dem Prozess kann
schließlich für ein konkretes Projekt eine Konfiguration erstellt werden.
Die Modellierung auf Basis des UMA Metamodells wird aktuell durch den EPF-
Composer unterstützt, der Teil des Eclipse Process Framework (EPF) ist.
Eclipse Process Framework (EPF)
Das Eclipse Process Framework (EPF) ist ein Eclipse-Technologieprojekt, das sich
der Entwicklung eines Modellierungswerkzeuges (dem EPF-Composer) auf der Basis
des UMA-Metamodells widmet und sich zusätzlich mit der (Re-)Modellierung vorhandener
Entwicklungsprozesse beschäftigt [EPF]. Zum aktuellen Zeitpunkt werden
Methodenbibliotheken für Scrum, XP und OpenUP 1 angeboten.
Der EPF-Composer nutzt das gesamte UMA-Metamodell und ermöglicht damit neben
dem Modellieren von Methodeninhalt und Prozessen innerhalb einer Methodenbibliothek
das Erstellen einer Methodenkonfiguration im Sinne des Tailoring. Das erstellte
Modell des Prozesses, bzw. die Methodenkonfiguration als projektspezifische Anpassung,
kann in das HTML-Format exportiert werden, so dass eine Betrachtung der generierten
Prozessbeschreibung durch einen geeigneten Browser ermöglicht wird. Beispielhaft
wird in Abbildung 6.6 die Beschreibung des OpenUP-Modells gezeigt. Die
Verwendung des EPF-Composer orientiert sich im Wesentlichen an dem beschriebe-
1 eine minimale, aber frei verfügbare Version des RUP
81

6 Prozessintegration
Abbildung 6.6: Exportierte HTML-Seiten des OpenUP (Quelle: [EPF])
nen Metamodell und wird nicht näher erläutert. Wichtig für die folgende Betrachtung
ist jedoch die Tatsache, dass für jedes Prozesselement eine eigene HTML-Ressource
generiert wird.
6.2 Konzept
Für die Realisierung der Prozessintegration hat die Verwendung des UMA-Modells
und des EPF-Composers insbesondere durch den HTML-Export einen hohen Nutzen.
Aus einer konzeptionellen Sicht muss entschieden werden, wie ein mit UMA modellierter
Prozess (z. B. MeDUSA) auf die Navigationsstruktur des Eclipse-Hilfesystems
und die CheatSheets abgebildet werden kann. Der aus der Navigationsstruktur referenzierte
Inhalt könnte durch die generierten HTML-Ressourcen geprägt werden. Beide
Abbildungen werden zunächst durch mathematische Funktionen definiert. Im Anschluss
wird vorgestellt, wie die Schnittstelle der Prozessintegration und Methodenunterstützung
realisiert werden kann, um später aus den CheatSheets die Gegenstände
der Methodenunterstützung - die TaskWizards - aufrufen zu können.
82

6.2.1 Abbildung auf die Navigationsstruktur
6.2 Konzept
Die Abbildung eines UMA-Modells auf die Navigationsstruktur des Eclipse-Hilfesystems
ist eine Funktion mit der folgenden Signatur:
fuma2help : MUMA → GT OC
(6.1)
Der Ursprung MUMA ist die Menge aller konform zum UMA-Metamodell definierten
Modelle. Die Menge aller Navigationsstrukturen des Eclipse-Hilfesystems ist der
Bildbereich und wird mit MT OC bezeichnet. Der Aufbau des UMA-Metamodells wurde
bereits im Abschnitt 6.1.1 erläutert, so dass an dieser Stelle lediglich der Aufbau
der Navigationsstruktur vorgestellt wird.
Abbildung 6.7: Beispiel einer Navigationsstruktur
Aufbau der Navigationstruktur
Die Navigationstruktur des Eclipse-Hilfesystems wird durch eine Sprache über einer
seitens Eclipse definierten Grammatik festgelegt. Die Struktur beinhaltet so genannte
toc-Elemente (table-of-contents), die ihrerseits topic-Elemente enthalten können.
Durch die topic-Elemente werden einerseits die darzustellenden HTML Inhalte referenziert.
Andererseits kann jedes topic-Elemente wiederum beliebig viele gleichartige
83

6 Prozessintegration
Elemente beinhalten, so dass eine Verschachtelung der topic Elemente von beliebiger
Tiefe bewirkt werden kann.
Abbildung 6.7 zeigt beispielhaft eine Navigationsstruktur mit zugehöriger Definition
auf der Basis der angesprochenen XML-Grammatik. Das toc-Element „MeDUSA Delivery
Process“ auf der linken Seite enthält ineinander verschachtelte topic-Elemente
zur Repräsentierung von Phasen und Iterationen. Die dargestellte HTML-Seite wird
von dem markierten topic-Element referenziert.
Abbildung 6.8: Abbildung des MeDUSA-Modells auf das Hilfesystem
Zuordnungsvorschrift
Die konzeptionelle Abbildung eines UMA-Modells auf die Navigationstruktur des Hilfesystems
ist im Wesentlichen eine identische Abbildung des Arbeitsstrukturbaums.
Für die ineinander verschachtelten Aktivitäten, ausgehend vom Prozess selbst als toc-
84

6.2 Konzept
Element, muss analog eine Hierarchie von Navigationsknoten (topic-Elemente) erstellt
werden, die jeweils die Inhalte der entsprechenden Aktivitäten bzw. Aufgaben in die
Navigationsstruktur einbinden. Abbildung 6.8 zeigt beispielhaft eine derartige Abbildung.
6.2.2 Abbildung auf CheatSheets
Die Repräsentierung eines Prozessmodells durch die Navigationsstruktur des Hilfesystems
gestaltet sich als sehr einfach, da bei beiden Metamodellen eine Verschachtelung
beliebiger Tiefe vorgenommen werden kann. Die Abbildung auf CheatSheets ist etwas
komplizierter und unterliegt einigen Einschränkungen. Die Signatur der zugehörigen
Funktion ist folgendermaßen definiert:
fuma2cs : MUMA → GCS
(6.2)
Der Ursprung MUMA ist wiederum die Menge aller Modelle, die konform zu dem
UMA-Metamodell sind. Der Bildbereich GCS ist die Menge aller CheatSheets und
Composite-CheatSheets, die entsprechend ihrer Grammatiken definiert sind. Zunächst
wird der Aufbau der (Composite-)Cheatsheets vorgestellt und anschließend die Zuordnungsvorschrift
von fuma2cs informal beschrieben.
Abbildung 6.9: Beispiel eines CheatSheets
85

6 Prozessintegration
Aufbau der (Composite-) CheatSheets
Composite-CheatSheets als auch die CheatSheets werden jeweils durch eine eigene
XML-Grammatik definiert. Der Aufbau eines Composite-CheatSheet ist im Wesentlichen
durch die Anwendung eines Composite-Entwurfsmuster ([LL06]) bestimmt. Es
beinhaltet entweder genau ein task- oder genau ein taskGroup-Element. Während die
mit den task-Elemente CheatSheets referenziert werden, können taskGroup-Elemente
beliebig viele andere task- oder taskGroup-Elemente beinhalten.
Analog zum Aufbau der Navigationsstruktur in Abbildung 6.7 wird in Abbildung
6.9 der Aufbau eines einfachen Composite-CheatSheets dargestellt (oben), mit dem
ein CheatSheet (unten) referenziert wird. Im oberen Teil ist die Verschachtelung der
taskGroup-Elemente ersichtlich.
Wenn für ein CheatSheet eingebettete Aktionen, wie ein Command zum Starten eines
Wizards, eingesetzt werden, beschränkt sich die Anzahl der modellierbaren Hierarchiestufen
dieses CheatSheets auf maximal zwei Stufen. Im unteren Teil der Abbildung
6.9 ist ein referenziertes CheatSheet mit dem zugehörigen Quelltext dargestellt. Ein
CheatSheet beinhaltet beliebig viele item-Elemente. Jedes item-Element kann höchstens
ein subItem-Element beinhalten. Somit wird aus konzeptioneller Sicht durch die
subItem-Elemente keine weitere Hierarchiestufe definiert, auch wenn es im Quelltext
als eigenes Element repräsentiert wird (vgl. Abb. 6.9). Die rot markierten Punkte gehören
nicht zu der eigentlichen Definition. Sie ersetzen in der Darstellung den Identifier
des durch den entsprechenden Commands zu startenden Wizards.
Abbildungsvorschrift
Da CheatSheets bei der Verwendung von eingebetteten Aktionen nur die Modellierung
einer zweistufigen Hierarchie erlauben, müssen bei der konzeptionellen Abbildung
zwangsläufig Composite-CheatSheets eingesetzt werden, so dass bei der Zuordnungsvorschrift
fuma2help nur wenig Spielraum bleibt.
Jede Aktivität, die Aufgaben referenziert, wird auf ein CheatSheet abgebildet, damit
für die referenzierten Aufgaben eine ausführbare Aktion angeboten werden kann.
Abbildung 6.10 zeigt, wie die Iteration des Architectural Design Modelling auf ein
CheatSheet abgebildet wird. Die vier referenzierten Aufgaben der Iteration werden innerhalb
des CheatSheets durch item-Elemente wiedergespiegelt und bieten das Starten
des zugehörigen TaskWizards an. Gleichzeitig wird diese Iteration aber auch auf ein
task-Element innerhalb des Composite-CheatSheets abgebildet, um das CheatSheet zu
referenzieren.
Die Aktivitäten der höheren Hierarchieebenen müssen folglich durch das Composite-
CheatSheet abgedeckt werden, das sich oben rechts im Bild befindet. Zunächst scheint
sich die Abbildung der UMA-Modelle auf die CheatSheets als relative einfach zu
gestalten. Allerdings gibt es sowohl durch das UMA-Metamodells bzw. den EPF-
Composer als auch von Seiten der CheatSheets einige Einschränkungen.
86

6.2 Konzept
Abbildung 6.10: Abbildung des MeDUSA-Modells auf (Composite-)CheatSheets
Einschränkungen bei der Abbildung
Die zeitlichen Abhängigkeiten der Aktivitäten und Aufgaben, die durch Aktivitätsdiagramme
spezifiert wurden, werden nicht im UMA-Modell abgelegt. Das hat zur Folge,
dass der Ablauf nur durch die statische Sicht im Arbeitsstrukturbaum nachempfunden
werden kann. Eine Abbildung der zeitlichen Abhängigkeiten der Aktivitätsdiagramme
kann für eine Abbildung nicht genutzt werden. Weitere Einschränkungen beziehen
sich auf die Ausdrucksstärke der CheatSheets.
Aufgrund der Beschaffenheit der CheatSheets ist die Abbildung eines Modells nur
dann durchführbar, wenn es keine Aktivitäten beinhaltet, die sowohl andere Aktivitäten
als auch referenzierte Aufgaben enthalten. Interpretiert man (Composite-)CheatSheets
als Bäume, so sind die Knoten von Composite-CheatSheets immer innere Knoten, und
die Knoten von CheatSheets immer Blätter. Würde eine Aktivität im UMA-Modell
sowohl eine Aufgabe als auch eine Aktivität enthalten, so wäre ein inneren Knoten neben
einem Blatt vorhanden, was aber weder durch CheatSheets noch durch Composite-
CheatSheets realisierbar ist. Wegen dieser Einschränkung durch die unterschiedlichen
Ausdrucksstärken des UMA-Metamodells und der CheatSheet-Grammatik muss die
Abbildung hinsichtlich der mit 6.2 definierten Signatur angepasst werden. Der Ursprung
M ′ UMA von fuma2cs wird derart eingeschränkt, dass er nur UMA-Modelle
beinhaltet, in der keine Aktivität sowohl andere Aktivitäten als auch Aufgaben referenziert:
fuma2cs : M ′ UMA → GCS
(6.3)
87

6 Prozessintegration
6.2.3 Schnittstelle zur Methodenunterstützung
Unter Berücksichtigung der im letzten Kapitel vorgestellte Methodenunterstützung
und als Grundlage für die Abbildungen der Prozessintegration muss im Modell des
Entwicklungsprozesses die Verwendung der TaskWizards zur Unterstützung der einzelnen
Aufgaben berücksichtigt werden. Die Unterstützung einer Aufgabe erfolgt durch
die Realisierung eines spezifischen TaskWizards. Um einen solchen Wizard für jede
Aufgabe aus den CheatSheets heraus starten zu können, wird den Aufgaben im UMA-
Modell ein Werkzeugmentor zugeordnet. Mit dem Werkzeugmentor kann der TaskWizards
durch die Angabe eines Identifiers spezifiziert werden. Zusätzlich besteht durch
den Werkzeugmentor die Möglichkeit, die Verwendung der aufgabenspezfischen Unterstützung
zu erläutern.
Die Angabe des Wizard-Identifier im Werkzeugmentor ermöglicht bei der Abbildung
des UMA-Modells auf die CheatSheets das Erstellen eines Command-Elements (vgl.
Abb. 6.9), mit dem der spezifierte Wizard zu einer Aufgabe gestartet werden kann.
6.3 Technische Umsetzung
Für die technische Umsetzung der Prozessintegration kann der EPF-Composer dahingehend
erweitert werden, dass er neben dem HTML-Export eines erstellten Prozessmodells
ebenfalls die Generierung einer Prozessbeschreibung und eines Ablaufmodells
in Form von CheatSheets anbietet. EPF definiert gerade für eine solche Erweiterung
einen speziellen Extension-Point.
Zunächst wird die Realisierung der CheatSheet-Erstellung und der Prozessbeschreibung
inklusive der Navigationsstruktur geschildert. Die eigentliche Erweiterung des
EPF-Composers unter Nutzung des Extension-Points zur Realisierung der beschriebenen
Abbildungen wird anschliessend vorgestellt.
6.3.1 Realisierung der CheatSheet Erstellung
Die Sprache der CheatSheets und Composite-CheatSheets wird jeweils durch eine
Grammtik in der Form einer XML Schema Definition (XSD) festgelegt. Die Umsetzung
der durch die Signatur 6.3 definierten konzeptionellen Abbildung von UMA-Modellen
muss also Wörter der mit dieser Grammatik definierten Sprache MCS erstellen.
Auf der technischen Ebene ist diese Abbildung als eine Modell-zu-Code Generierung
g ′ := fuma2cs zu betrachten. Aus einem Modell konform des UMA Metamodells muss
der Code eines CheatSheets entsprechend der zugehörigen XML-Grammatik generiert
werden. Diese Generierung kann durch zwei sinnvolle Strategien durchgeführt werden.
88

Transformationsstrategie
6.3 Technische Umsetzung
Mit der Anwendung einer einfachen Transformationsstrategie könnte eine direkte Generierung
des Ziel-Codes durch einen Lauf über das UML-Modell verfolgt werden.
Um aber die konzeptionelle Abbildung von der eigentlichen Code-Generierung und
damit die Semantik und Syntax zu trennen, kann eine komplexere Strategie durch
die Realisierung einer Funktionsvorschrift g ′ als Komposition einer Modell-zu-Modell
Transformation t und einer Modell-zu-Code Generierung g realisiert werden:
g ′ =: g ◦ t (6.4)
Die Trennung der Transformation von der Code-Generierung erfordert ein zusätzliches
CheatSheet-Metamodell, das im Wesentlichen die Grammatiken der (Composite-
) CheatSheets widerspiegelt. Sei MCS die Menge aller Instanzen dieses Metamodells,
dann ist die Signatur der Transformation t und Code-Generierung g wie folgt bestimmt:
t : M ′ UMA → MCS
(6.5)
g : MCS → GCS
(6.6)
Durch die klare Trennung der konzeptionellen Abbildung von der syntaktischen Code-
Erstellung ist mehr Implementierungsaufwand erforlich als bei einer direkten Generierung.
Zum einen muss die Abbildung zweistufig erfolgen, zum anderen ist damit die
Erstellung eines CheatSheet-Metamodells erforderlich. Auf der anderen Seite unterstützt
diese Strategie aber das Verständnis und verbessert die Qualität hinsichtlich der
Wartbarkeit.
Auf eine detaillierte Beschreibung der Grammatik als auch auf eine Erläuterung des
zugehörige Metamodells wird an dieser Stelle verzichtet, da die genaue Syntax der
CheatSheets für die weitere Betrachtung nicht relevant ist. Stattdessen wird im Folgenden
die Durchführung der zweistufigen Strategie durch den Einsatz des oAW Frameworks
(vgl. Abschnitt 2.3.3) geschildert.
Entwurf der Transformationsdurchführung
Auf der Basis der im letzten Abschnitt diskutierten Trennung der semantischen und
syntaktischen Abbildung wird nun die technische Umsetzung durch die Verwendung
von oAW beschrieben. Das Framework unterstützt die Modell-zu-Modell Transformation
durch die Sprache xTend und gleichermassen die Modell-zu-Code Generierung
durch die Sprache xPand. Abbildung 6.11 zeigt den gesamten Vorgang der Code-
Generierung.
Ausgehend vom UMA-Modell wird ein MCS-Modell durch die Anwendung von Extensions
der oAW-Sprache xTend erstellt. Aus diesem Modell wird dann der eigentliche
Code durch xPand-templates generiert. Bevor ein Modell für eine Bearbeitung
herangezogen wird, muss die Konsistenz des Modells sichergestellt sein. Während
EPF (bzw. EMF) die Integrität des Modells und die Konformität bezüglich des UMA-
Metamodells gewährleistet, bleibt durch Regeln zu prüfen, dass das UMA-Modell die
89

6 Prozessintegration
Abbildung 6.11: Ablauf der Transformation und CheatSheet-Generierung
in Abschnitt 6.2.2 beschriebene Bedingung erfüllt: Eine Aktivität darf nicht andere
Aktivitäten beinhalten und gleichzeitig Aufgaben referenzieren.
Das erstellte CheatSheet-Modell unterliegt keinen Einschränkungen. Aus Gründen der
Erweiterbarkeit wird aber eine mögliche Validierung im Entwurf berücksichtigt. An
dieser Stelle wird davon abgesehen, den Quelltext der einzelnen Extensions und Templates
vorzustellen.
6.3.2 Realisierung der Prozessbeschreibung
Der EPF-Composer bietet bereits die Möglichkeit, ein mit UMA erstelltes Prozessmodell
in das HTML-Format zu exportieren. Um nun die Prozessbeschreibung in das
Eclipse-Hilfesystem integrieren zu können, muss die in Abschnitt 6.2.1 beschriebene
Abbildung fuma2help eines UMA-Modells auf eine Navigationsstruktur realisiert
werden.
Da der Arbeitsstrukturbaum eines UMA-Modells ordnungserhaltend 2 auf die Knoten
der Navigationsstruktur abgebildet wird (vgl. Abbildung 6.8), ist keine Trennung der
semantischen von der syntaktischen Abbildung erforderlich. Der Navigationsstruktur
enthält lediglich gleichartige Knoten, so dass eine zweistufige Transformationsstrategie
nur einen unnötigen Aufwand darstellen würde. Dementsprechend wird eine einfache
Code-Generierung durchgeführt.
Das einzige Problem, das sich bei der technischen Realisierung stellt, ist die Bereitstellung
der URLs 3 , die für das Referenzieren des Inhaltes durch die Navigationsstruktur
benötigt werden.
2 die Hierarchieordnungen werden beibehalten
3 Uniform Resource Locator, Identifikation einer Ressource über ein Netzwerkprotokoll
90

Verfügbarkeit der Inhaltsreferenzen
6.3 Technische Umsetzung
Damit die URLs bei der Erstellung der Navigationsstruktur bekannt und verfügbar
sind, könnte eine Erweiterung des EPF-Composers dafür sorgen, dass während der
Generierung der HTML-Dateien die resultierenden URLs zwischengespeichert werden.
Die xPand-Sprache (und ebenso xTend) erlaubt das Einbinden von Java-Extensions
(vgl. Abschnitt 2.3.3). Somit können die zwischengespeicherten URLs in die Code-
Generierung durch den Zugriff auf statische Java-Methoden einbezogen werden. Gerade
durch dieses Vorgehen können in der CheatSheet-Transformation die den Aufgaben
entsprechenden Inhalte der Prozessbeschreibung referenziert werden, wie es eingangs
durch die Abbildung 6.1 dargestellt wurde.
Eine Übersicht des Generierungsvorgangs wird nicht explizit geliefert. Der Vorgang
ist eine Vereinfachung des in Abbildung 6.11 dargestellen, da keine Transformation
durchgeführt wird. Zudem ist eine Validierung des UMA-Modells nicht notwendig, da
für die Generierung der Navigationsstruktur keine Einschränkungen gelten.
Nachdem nun die beiden Vorgänge zur Erstellung der CheatSheets und der Prozessbeschreibung
erläutert wurden, wird im nächsten Abschnitt die Erweiterung des EPF-
Composers vorgestellt, in der die beschriebenen Transformationen und Generierungen
eingesetzt werden.
6.3.3 Architektur
In den letzten beiden Abschnitten wurde erklärt, wie das oAW Framework für die einzelnen
Abbildungen genutzt werden kann. Die technische Realisierung könnte ebenfalls
durch die Nutzung anderer Technologien durchgeführt werden. Allerdings hat die
Verwendung von oAW den Vorteil, dass dieses Framework bereits in ViPER eingesetzt
wird. Eine Benutzung ist dementsprechend erprobt und erfordert keinen zusätzlichen
Verwaltungsaufwand hinsichtlich des Einsatzes.
Integration von UMA in EPF
Wichtig für die technische Realisierung eines Werkzeuges, mit dem ein modellierter
Prozess auf CheatSheets bzw. auf eine Prozessbeschreibung abgebildet werden
kann, ist die Tatsache, das dass Prozessmodell in einem verwertbaren Format vorliegt.
Wie die Übersicht der Architektur in Abbildung 6.12 zeigt, ist das UMA-Metamodell
durch Nutzung des beschriebenen Eclipse Modeling Framework (EMF) 2.3.2 im EPF-
Composer integriert. Somit ist also sichergestellt, dass ein im EPF-Composer erstelltes
Prozessmodell für Modell-zu-Modell Transformationen oder Prozess-zu-Code Generierungen
unter Verwendung des oAW Frameworks herangezogen werden kann.
91

6 Prozessintegration
Abbildung 6.12: Architektur des EPF-Composer [EPF]
Werkzeugkomposition: EPF-Composer und ViPER-PF
Prinzipiell soll die Erstellung der Prozessbeschreibung und der CheatSheets selbst kein
Bestandteil von ViPER sein, da lediglich die entstehenden Arbeitsergebnisse für die
Unterstützung von MeDUSA von Relevanz sind. Da ViPER aber gerade mit dem Feature
ViPER MTF und dem verwendeten Framework oAW die Modelltransformation
auf der Basis von EMF unterstützt, ist es durchaus sinnvoll, die von ViPER bereitgestellten
Hilfsmittel für die Realisierung einzusetzen. Es wird ein neues Werkzeug
ViPER PF (Process Framework) erstellt, das neben dem EPF-Composer Bestandteile
von ViPER nutzt, um durch zusätzliche Funktionalität den HTML-Export des EPF-
Composers zu erweitern.
Die in Abbildung 6.13 dargestellte Architektur von ViPER beinhaltet ein optionales
Feature bootstrap, das nicht Teil der eigentlichen IDE ist, aber für das Arbeiten an
ViPER selbst genutzt werden kann. ViPER kann also mit diesem Feature in ViPER
selbst angepasst werden. Die Erweiterung von ViPER bootstrap schafft die Grundlage
für die Erstellung einer Prozessbeschreibung und CheatSheets, um sie beim eigentlichen
Arbeiten mit ViPER nutzen zu können.
Das Feature ViPER PF verwendet EPF und das seinerseits genutzte GMF Feature. Die
Generierung der Navigationsstruktur der Prozessbeschreibung wird in dem Plug-In
uma2cs realisiert, die Transformation und Code-Generierung der CheatSheets mit dem
dazugehörigen Metamodell stellt das Plug-In uma2help bereit. Der nächste Abschnitt
erläutert, wie beide Abbildungen mit dem Plug-In publishing durch Verwendung eines
EPF Extension-Points in den Vorgang des HTML-Exports eingebunden werden.
Erweiterung des HTML-Exports
Bei der Generierung von HTML zur Beschreibung eines Prozessmodells im EPF-
Composer wird der Benutzer mit Hilfe eines Wizards durch verschiedene Schritte ge-
92

6.3 Technische Umsetzung
Abbildung 6.13: Erweiterung von ViPER für die Prozessintegration
führt. Der Benutzer wählt diverse Einstellungen, z. B. die zu exportierende Methodenkonfiguration
(die projektspezifische Auswahl der Methodenbibliothek, vgl. Abschnitt
6.1.1) und den Zielordner der zu generierenden HTML-Dateien. Die so gewählten
Einstellungen werden bei erfolgreicher Beendigung des Wizards an einen PublishManager
übergeben, der die Generierung der Dateien auf der Basis dieser Einstellungen
durchführt.
EPF definiert einen Extension-Point, mit dem einerseits der Kontrollfluss bei der sequentiellen
Abarbeitung der einzelnen Wizard-Seiten durch einen WizardExtender übernommen
werden kann, mit dem andererseits aber auch zusätzliche Wizard-Seiten hinzugefügt
oder ersetzt werden können. Das publishing Plug-In verwendet beide Mechanismen
dieses Extension-Points. Mit Hilfe einer zusätzlichen Wizard-Seite können,
wie in Abbildung 6.14 dargestellt, relevante Einstellungen vorgenommen werden. Zum
einen ist der zu verwendene Prozess auszuwählen, der durch die generierten CheatSheets
ausgeführbar ist, zum anderen müssen die Zielordner der jeweiligen Arbeitsergebnisse
spezifiziert werden.
In Abbildung 6.15 sind sowohl die seitens EPF definierten Klassen (oben), als auch
die für das publishing Plug-In erstellten Klassen (unten) dargestellt. Der für den Export
zuständige PublishManager wird durch den PFPublishManager spezialisiert, um
93

6 Prozessintegration
Abbildung 6.14: Wizard-Seite für die Generierung:CheatSheets, Prozessbeschreibung
neben den HTML-Dateien die Prozessbeschreibung und die CheatSheets zu erstellen.
Dadurch, dass der WizardExtender im Besitz des Kontrollflusses ist, kann für den
Export anstelle des PublishManagers der PFPublishManager eingesetzt werden. Um
zusätzlich die Einstellungen zu kapseln, die auf der in Abbildung 6.14 dargestellten
Seite auswählbar sind, wird durch die Klasse PFPublishingOptions die seitens EPF
definierte Klasse PublishingHTMLOptions spezialisiert.
Abbildung 6.15: Erweiterung der HTML-Exports
Bei der Erstellung der Navigationsstruktur und der CheatSheets müssen die Inhaltsreferenzen
(URLs) der Prozessbeschreibung bekannt sein. Für die Erstellung der HTML-
Seiten nutzt der PublishManager einen HTMLBuilder. Um nun die URLs der einzelnen
HTML-Seiten zwischenspeichern zu können, wird durch den PFHTMLBuilder
diejenige Methode überschrieben, mit der das Generieren jeder einzelnen HTML-
Seite angestoßen wird. Wie bereits erwähnt, wird für jedes Prozesselement eine eigene
94

6.4 Durchführung der Prozessintegration
HTML-Seite exportiert. In der vom PFHTMLBuilder überschriebenen Methode ist
also lediglich die zurückgegebene URL zu dem exportierten Element in einem URL-
Cache abzulegen.
Bisher wurde immer angenommen, dass die vom EPF-Composer generierten HTML-
Dateien direkt als Prozessbeschreibung verwendet werden. Allerdings soll der Export-
Vorgang durch das publishing Plug-In lediglich erweitert werden, so dass die Generierung
der HTML-Seiten zweifach durchgeführt wird:
1. Export des Prozessmodells: Die von EPF vorgesehene Veröffentlichung wird
beibehalten.
2. Erstellen der Prozessbeschreibung: Die eingesetzte Funktionalität wird zusätzlich
für die Erstellung der Prozessbeschreibung genutzt. Die HTML-Dateien
werden also ein zweites Mal generiert, nun allerdings in einen anderen, vom
Benutzer gewählten, Zielpfad (vgl. Abb. 6.14).
Verwendung von ViPER MTF
Nach der Generierung der Prozessbeschreibung wird durch den PFPublishManager
die anschließende Erstellung der Navigationsstruktur und der CheatSheets angestoßen
und dabei die durch Funktionalität der uma2help und uma2cs Plug-Ins verwendet. Der
eigentliche Transformationsvorgang wurde bereits in den Abschnitten 6.3.2 und 6.3.1
beschrieben. Beide Abbildungen werden durch oAW realisiert, indem das ViPER MTF
Framework eingesetzt wird, dessen Nutzung bereits im Abschnitt 2.3.6 beschrieben
wurde.
Wohlbemerkt werden die Transformation des UMA-Modells in ein CheatSheet-Modell
und die anschliessende Code-Generierung durch den PFPublishManager hintereinander
ausgeführt. Beide Vorgänge können aber auch völlig unabhängig von einander
durchgeführt werden. Somit besteht die Möglichkeit, CheatSheets indirekt durch die
Verwendung des mit EMF definierten Metamodells zu generieren, ohne die nötigen
XML-Ressourcen anlegen zu müssen. Mit Eclipse 3.3 wurde diese Tatsache allerdings
überflüssig, da für die Erstellung von CheatSheets ein Editor entwickelt wurde, der
direkt auf den XML-Ressourcen arbeitet, allerdings deren Syntax verbirgt.
6.4 Durchführung der Prozessintegration
Die eigentliche Prozessintegration für MeDUSA in ViPER kann nun unter Zuhilfenahme
von ViPER PF vorgenommen werden. Dafür muss MeDUSA zunächst im EPF-
Composer anhand des UMA-Metamodells definiert werden.
Bereits die Beschreibung von MeDUSA im Kapitel 2 erfolgte unter Verwendung der
UMA-Terminologie. Der Methodeninhalt wurde vom Prozess separiert und die Aufgaben
der verschiedenen Disziplinen geschildert. Auch der Aufbau des Prozesses wurde
95

6 Prozessintegration
anhand der einzelnen Aktivitätsdiagramme vorgestellt. Dementsprechend kann sich
die Modellierung im EPF-Composer daran anlehnen.
Die analog zu den Disziplinen benannten Iterationen treten mehrfach auf, so dass für
deren Modellierung Prozessmuster (vgl. Abschnitt 6.1.1) verwendet werden können,
die an den entsprechenden Stellen der Phasen eingesetzt werden. Beispielsweise ist
die Iteration Requirements Modelling in jeder der vier Phase vorhanden, muss aber
mit Hilfe der Prozessmuster nur ein einziges Mal modelliert werden.
Nach der Modellierung können daraus die Prozessbeschreibung (inklusive der Navigationsstruktur)
und die CheatSheets generiert und im ViPER Plug-In Processes
abgelegt werden (vgl. Abb. 6.13). Für die Verwendung in ViPER müssen nur die in
Abschnitt 2.3.1 vorgestellten Extension-Points des Eclipse-Hilfesystems aufgegriffen
werden, um die Navigationsstruktur und die CheatSheets durch Extension in der Entwicklungsumgebung
(ViPER) zu registrieren.
Damit ist zunächst die Erläuterung der konzeptionellen und technischen Lösung für
die Prozessintegration abgeschlossen. Im nächsten Kapitel werden die Ergebnisse der
Prozessintegration und der Methodenunterstützung hinsichtlich verschiedener Qualitätsmerkmale
evaluiert. Im letzten Kapitel wird eine Zusammenfassung und Ausblick
geliefert.
96

6.4 Durchführung der Prozessintegration
UMA dt. Übersetzung RUP 2003 V-Modell XT
Methodeninhalt
Role Rolle Role Role
Work Product Arbeitsergebnis(-typ) Produkttype
- Artifact Artefakt Artifact Produkt
- Outcome Resultat
- Deliverable Liefergegenstand
- External Input Externe Zulieferung externes Produkt
Task Aufgabe Activity Teilaktivität
Step Schritt Step
Prozesselemente
Phase Phase Phase Projektabschnitt
Iteration Iteration Iteration
Activity Aktivität Workflow Detail Aktivität
Milestone Meilenstein Entscheindungspunkt
impacted Work beeinflusstes Work Product Produktabhängigkeit
Product Arbeitsergebnis Dependency
Capability Pattern Prozessmuster Vorgehensbaustein
Delivery Process Bereitstellungsprozess Lifecycle / Projektdurch-
Configuration führungsstrategie
Kategorisierung
Discipline Disziplin Discipline Aktivitätsgruppe
Domain Domäne (Artifact Set) Produktgruppe
Role Set Rollenmenge (Role Set)
Tool Werkzeug Tool
Process Family Vorgehensfamilie Projekttyp
Paketierung
Method Library Methodenbibliothek
Method Plug-In Methoden-Plugin Process Model Plug-In
Method Package Methodenpaket Process Component
Content Package Inhaltspaket
Process Component Prozesskomponente
Hilfestellung
Guideline Leitfaden Guideline
Concept Konzept Concept
Whitepaper Informationsschrift Whitepaper
Checklist Checkliste Checklist
Tool Mentor Werkzeugmentor Tool Mentor
Template Schablone Templates
Report Report Report
Estimate Schätzung
Example Beispiel Example
Roadmap Strategieplan Roadmap
Term Definition Glossareintrag Glossary
Practice Verfahrensweise
Tabelle 6.1: Übersicht und Vergleich der Terminologien [Gau06]
97

6 Prozessintegration
98

7 Evaluierung
Eine Evaluierung der technischen Umsetzung sollte durch die Prüfung von Qualitätsmerkmalen
erfolgen, damit die Zielerfüllung bezüglich konkreter Anforderungen bewertet
werden kann. Da im Rahmen dieser Arbeit keine festen Vorgaben an die Realisierung
gestellt wurden, wird eine Evaluierung unter Berücksichtigung der in Kapitel
4 herausgearbeiteten Anforderungen vorgenommen.
Abbildung 7.1: Qualitätenbaum nach Boehm, Brown und Lipow (Quelle: [LL06])
In den folgenden drei Abschnitten werden sowohl die Prozessintegration, das dafür
erstellte und genutzte Werkzeug ViPER PF, als auch die Methodenunterstützung, einer
Bewertung unterzogen werden, indem anwendbare Qualitätsmerkmale des in Abbildung
7.1 dargestellten (und auf Produktqualitäten reduzierten) Qualitätenbaums berücksichtigt
werden.
Bei der Bewertung der Warbarkeit wird die Portabilität nicht berücksichtigt. Sie ist
durch die Eclipse-IDE und ViPER bestimmt. Die technische Umsetzung der Prozessintegration
und Methodenunterstützung unterliegt keinen Einschränkungen hinsichtlich
dieses Qualitätsmerkmals, da im Wesentlichen vorhandene Technologien genutzt
wurden.
7.1 Prozessintegration
Die Prozessintegration wurde durch eine Ablaufmodellierung mittels CheatSheets und
durch eine Prozessbeschreibung realisiert.
99

7 Evaluierung
Änderbarkeit Anstelle einer programmatischen Lösung wurde der Quelltext beider
Arbeitsergebnisse durch ein zusätzliches Werkzeug unter Verwendung des Eclipse
Process Frameworks (EPF) generiert. Dadurch ist eine sehr hohe Änderbarkeit gewährleistet.
Modifizierungen - auch im Sinne von Erweiterungen innerhalb der MeDU-
SA Methode werden durch erneutes Generieren automatisch in der Prozessbeschreibung
und den CheatSheets berücksichtigt.
Bedienbarkeit Beide Arbeitsergebnisse der Prozessintegration sind durch allgemeine
Technologien der Eclipse-Benutzerassistenz in das Werkzeug integriert. Damit
ist die Bedienbarkeit als sehr hoch einzustufen. Sowohl das Hilfesystem, als auch die
CheatSheets sind als Standardtechnologien der Eclipse-IDE ausführlich dokumentiert
und einfach zu bedienen. Durch die Verknüpfung der CheatSheets mit dem Hilfesystem
mittels einer kontextabhängige Referenz wird die Bedienbarkeit zusätzlich erhöht.
7.2 ViPER PF
Das Werkzeug ViPER PF ist weder ein Teil der Unterstützung für MeDUSA noch
ein direkter Bestandteil von ViPER. Es dient lediglich der Erweiterung von ViPER
für die Unterstützung eines Prozesses. Da dieses Nebenprodukt aber auch im Rahmen
dieser Arbeit realisiert wurde, werden dessen grundlegenden Eigenschaften evaluiert.
Die wesentliche Funktionalität ist die Transformation eines erstellten UMA-Modells
in ein CheatSheet-Modell und die anschließende Code-Generierung (vgl. Abschnitt
6.3.1).
Prüfbarkeit Durch die Definition von Regeln, Extensions und Templates für die
Abbildungslogik zur automatisierten Erstellung der CheatSheets wurde eine hohe Lokalität
diesbezüglich erreicht. Die mit Hilfe der oAW-Sprachen definierte Logik hat
keine Auswirkung auf andere Teile der Realisierung. Zusätzlich wird durch die Trennung
der semantischen Abbildung von der syntaktischen Code-Generierung eine hohe
Testbarkeit erzielt. Es besteht die Möglichkeit ein Prozessmodell auf der Basis von
UMA zu definiert und es für eine Transformation als Eingabe zu verwenden, wobei
das entstandene CheatSheet-Modell durch geeignete Testfälle überprüft werden kann.
Bei einer direkten Code-Generierung, wie bei der Abbildung der Navigationsstruktur,
müsste ein Vergleich auf Basis des erstellten XML-Quelltextes durchgeführt werden,
um die Abbildung systematisch testen zu können.
Änderbarkeit Durch die Trennung der Transformation von der Generierung und
das Kapseln der Abbildungslogik ist darüberhinaus eine hohe Änderbarkeit erzielt
worden. Änderungen in der semantischen Transformation haben keine Auswirkung
auf die syntaktische Code-Erstellung. Durch die Verwendung eines Postprocessors
nach der Code-Generierung durch ViPER MTF ist die Lesbarkeit des erstellten Codes
gewährleistet. Zusätzlich ist aber auch die Lesbarkeit des erstellenden Codes si-
100

7.3 Methodenunterstützung
chergestellt, da keine Formatierung für das Ergebnis berücksichtigt werden muss. Die
Verwendung der oAW Sprachen zur Kapselung der Logik bewirkt zudem eine hohe
Knappheit und Strukturiertheit. Die definierten Regeln zur Transformation und Generierung
sind in separaten Dateien abgelegt und besitzen keine Abhängigkeit zu anderen
Komponenten, abgesehen von der Nutzung des URLCaches (vgl. Abschnitt 6.3.3). Die
Simplizität ist hingegen als niedrig einzustufen, da die Syntax beider Sprachen nicht
intuitiv verständlich und zudem schlecht dokumentiert ist.
Zuverlässigkeit Die Zuverlässigkeit des Werkzeugs wird stark durch die Nutzung
des Eclipse Process Frameworks (EPF) und der verwendeten Schnittstelle des HTML-
Exports beeinflusst. Da sich in der Vergangenheit die Schnittstelle zu diesem Framework
des Öfteren geändert hat, muss davon ausgegangen werden, dass der erweiternde
Code auch in Zukunft bezüglich weiterer Änderungen seitens EPF, anzupassen ist.
Nützlichkeit Aufgrund der zweifachen Ausführung der HTML-Generierung (vgl.
Abschnitt 6.3.3) ist die Erstellung der HTML-Dateien und der Prozessbeschreibung
ein langwieriger Prozess. Das Kopieren der einmalig generierten Dateien für die Prozessbeschreibung
könnte die Effizienz verbessern. Da jedoch der Vorgang nicht allzu
oft angestoßen wird, ist dieser Aspekt von geringfügiger Bedeutung. Die Leistungsvollständigkeit
ist bei dem Generierungsvorgang nicht gewährleistet, da bei der ersten
Durchführung eine Integration der erstellten Arbeitsergebnisse durch Extensions im
Werkzeug vorgenommen werden muss.
Bedienbarkeit Die Generierung der CheatSheets und die Erstellung der Prozessbeschreibung
werden über die einfache Angabe der jeweiligen Zielordner durch einen
Benutzer gestartet. Die hohe Einfachheit wird dadurch eingeschränkt, dass die Arbeitsergebnisse
bei der ersten Erstellung durch die Verwendung von Extensions im
Werkzeug registriert werden müssen (vgl. Abschnitte 2.3.1, 6.4). Die automatische
Erstellung der Extensions konnte aus technischen Gründen nicht durch ViPER PF abgedeckt
werden.
7.3 Methodenunterstützung
Die bisherige Methodenunterstützung stellt ein Framework für aufgabenspezifische
Unterstützung bereit, das prototypisch für die Subsystem Identification eingesetzt worden
ist. Analog dazu wird die Evaluierung beider Teile getrennt voneinander durchgeführt.
101

7 Evaluierung
7.3.1 Iterative Task Framework
Mit dem Iterative Task Framework wird ein Framework bereitgestellt, dass die Bearbeitung
einer Aufgabe nach einer festen Bearbeitungssequenz (vgl. Abschnitt 5.1.4)
sicherstellt. Zudem beinhaltet es Hilfsklassen für aufgabenunabhängige Funktionalität,
die für die Unterstützung einer Aufgabe verwendet werden können.
Bei der Realisierung des Iterative Task Frameworks wurde sehr viel Wert auf die Trennung
von Zuständigkeiten 1 gelegt. Um den Lebenszyklus eines TaskWizards zu überwachen
und den Ablauf steuern zu können, verwendet der TaskController verschiedene
Hilfsklassen, denen unterschiedliche Aufgabenbereiche zugeordnet sind. Funktionalität
für die Speicherung von Modellressource wurde von der Anwendungslogik zur
Handhabung der UML-Modelle und des Traceability-Modells getrennt.
Prüfbarkeit Durch die gewählte Architektur des Iterative Task Frameworks, unter
Berücksichtung des Prinzips der Trennung von Zuständigkeiten, liegt eine relativ hohe
Testbarkeit vor. Die Funktionalität der einzelnen Hilfsklassen (vgl. Abschnitt 5.1.4)
kann unabhängig vom restlichen Framework relativ einfach durch Testfälle überprüft
werden. Die Testbarkeit des TaskControllers ist allerdings nur zu einem geringen Teil
gewährleistet.
Änderbarkeit Neben einer hohen Prüfbarkeit besitzt das erstellte Framework auch
eine gute Änderbarkeit. Wiederum durch die Separierung der verschiedenen Aufgabenbereiche
wurde auch eine hohe Strukturiertheit und Simplizität erreicht.
Portabilität Durch die Realisierung des Traceability-Metamodells (vgl. Abschnitt
5.1.2) besitzen die UML-Modelle eine gute Portabilität. Unabhängig von den Abbildungsinformationen
zur Sicherstellung der Nachverfolgbarkeit und damit der Durchgängigkeit,
bildet jedes UML-Modell eine abgeschlossene Einheit. Somit kann es für
sich allein stehend in einem anderen Kontext ohne Einschränkung bearbeitet werden.
Brauchbarkeit Bei der Bewertung des Frameworks sind die Qualitätsmerkmale
der Brauchbarkeit nicht unmittelbar auf die Nutzung durch einen Entwickler anwendbar,
da eine Schnittstelle erst durch die eigentliche Unterstützung zustande kommt.
Daher wird das Framework hinsichtlich der Brauchbarkeit für eine mögliche Hilfestellung
bewertet. Für die Verwendung des Frameworks ist neben der aufgabenspezifischen
Anwendungslogik die Erstellung einer TaskConfiguration notwendig. Prinzipiell
können damit sehr einfach und verständlich die Parameter zur Unterstützung der Aufgaben
(z. B. Vor-, Nachbedingungen, Modelle, vgl. Abschnitte 5.1.3, 5.1.4) festgelegt
werden. Für die eigentliche Implementierung von Constraints durch die Verwendung
des EMF Validation Frameworks ist allerdings zusätzliches Wissen erforderlich, da
1 separation of concerns, [LL06]
102

7.3 Methodenunterstützung
die Schnittstelle zum Validation Framework nicht sinnvoll verborgen werden kann.
Die Realisierung solcher Constraints auf der Basis von Java oder OCL ist allerdings
ausführlich in der dazugehörigen Dokumentation beschrieben.
Bedienbarkeit Die allgemeine Bedienbarkeit beschränkt sich auf den generellen
Aufbau eines TaskWizards. Durch die einheitliche Struktur und Oberfläche der aufgabenunabängigen
Seiten, wird eine hohe Verständlichkeit und Konsistenz erzielt. Ebenso
gewährleistet die einfache Handhabung von Validierungen und entsprechenden Korrekturvorschlägen
eine hohe Einfachheit, die allerdings bei der aufgabenspezifischen
Konfiguration durch die Formulierung von Vor- und Nachbedingungen, beeinflusst
wird. Die Verwendung des Traceability-Modells wird vor dem Entwickler gänzlich
verborgen und wirkt sich nicht nachteilig auf die Bedienbarkeit aus.
Alle Modelländerungen, die bei der Bearbeitung einer Aufgabe mit einem TaskWizard
durchgeführt werden, können durch den Entwickler widerrufen (undo) und wiederholt
(redo) werden. Dazu gehören sowohl die Änderungen durch Korrekturvorschläge
als auch Änderungen im aufgabenspezifischen Teil. Damit dieser Mechanismus auf
eine konsistente Art und Weise genutzt werden kann, muss die aufgabenspezifische
Unterstützung die in Commands (s. Abschnitt 2.3.2) gekapselten Modelländerungen
geeignet miteinander kombinieren. Bei der Verwendung des Frameworks sollte gewährleistet
sein, dass die für den Entwickler scheinbar atomaren Änderungen, dementsprechend
durch einen einzigen CompoundCommand gekapselt und geeignet benannt
werden (vgl. Abschnitt 5.1.4). Wird dieser Aspekt berücksichtigt, bietet der undo/redo-
Mechanismus ein sehr mächtiges Hilfsmittel, das die Bedienbarkeit enorm verbessert.
7.3.2 Unterstützung der Subsystem Identification
Die Umsetzung einer aufgabenspezifische Unterstützung der Subsystem Identification
beschränkt sich, neben der Nutzung des TaskControllers, im Wesentlichen auf die Realisierung
einer Wizard-Seite für die Partitionierung der Analyseobjekte. Abgesehen
von den grafischen Komponenten ist dazu Anwendungslogik erforderlich, die durch
die zugehörige AnalysisObjectPartitioningLogic bereitgestellt wird.
Prüfbarkeit Durch die Auslagerung der Anwendungslogik aus der Wizard-Seite in
den AnalysisObjectPartitioningLogic nach dem Prinzip der Trennung von Funktion
und Interaktion kann eine hohe Prüfbarkeit erzielt werden, indem die Hilfsklasse unabhängig
von der Wizard-Seite relativ einfach getestet werden kann. Da die Analysis-
ObjectPartitioningLogic nur Zugriff auf durch das Framework festgelegte Komponente
besitzt, ist auch die Lokalität aus einer programmatischen Sicht hoch einzustufen.
Die Lokalität der UML-Modelle ist aufgrund möglicher Änderungen in jeder Aufgabe
relativ gering, ist allerdings unvermeidbar. Die Wizard-Seite kann, wie grafische
Komponenten im Allgemeinen, nur sehr schlecht getestet werden.
103

7 Evaluierung
Änderbarkeit Typisch für grafische Komponenten ist eine hohe Kopplung zwischen
den einzelnen Bestandteilen. Durch die Aufteilung in eine System- und mehrere
Subsystemansichten (vgl. Abschnitt 5.2.4) wurde die Strukturiertheit bis zu einem gewissen
Maße verbessert. Mit Hilfe der Implementierung einer gemeinsamen abstrakten
Schnittstelle werden die Subsystemansichten über das aktuell betrachtete Subsystem
benachrichtigt und können die jeweiligen Inhalte anpassen. Die Realisierung durch eine
Art Observer-Muster (vgl. [LL06]) ermöglicht eine einfache Erweiterbarkeit und
eine hohe Simplizität.
Bedienbarkeit Mit der Methodenunterstützung wird das Ziel verfolgt, einen Entwickler
bei der Bearbeitung einer Aufgabe eine möglichst optimale Unterstützung zu
bieten.
Die grundlegende, konzeptionelle Entscheidung für die Unterstützung der Subsystem
Identification bezieht sich auf die Repräsentierung von Analyseobjekten. Konzept
wirkt sich sowohl auf eine mögliche Unterstützung für die Aufgaben der Analyse aus,
als auch auf die Validierung und die Korrekturvorschläge für die Subsystem Identification.
Die Art der Analyseobjekt-Repräsentierung kann dementsprechend nicht vor dem
Entwickler verborgen werden. Die Realisierung mit der Erweiterung von Stereotypen
zur Speicherung eines Identifiers ist vermutlich sehr leicht von einem Entwickler nachzuvollziehen.
Jedes Analyseobjekt wird durch einen Identifier berücksichtigt, der bei
den angewendeten Stereotypen der Repräsentanten festgehalten werden muss. Diese
Realisierung bietet somit eine hohe Einfachheit und Verständlichkeit.
Der zweite wesentliche Aspekt bei der prototypisch realisierten Unterstützung ist die
Oberfläche der aufgabenspezifischen Wizard-Seite. Da dem Entwickler durch diese
Seite sehr viel Funktionalität bereitgestellt wird (vgl. Abschnitt 5.2.4), ist eine intuitive
Oberflächengestaltung wichtig. Ganz allgemein wurden, wie auch bei dem Design
aller anderen Oberflächen, die Eclipse User Interface Guidelines [EHLK04] berücksichtigt.
Mit ihnen wird empfohlen verschiedene Eigenschaften, wie die zu verwendenen
Icons (z. B. zum Erstellen, Löschen oder auch Umbennen) oder auch das Verhalten
und das Layout von Wizards zu berücksichtigen. Ziel dabei ist es, dem „Benutzer“ ein
einheitliches und intuitives Look & Feel im gesamten Werkzeug präsentieren zu können.
Neben der Berücksichtigung dieser Richtlinien wurde bei der Strukturierung der Seite
darauf geachtet, dass die Bearbeitung immer von oben nach unten und von links nach
rechts durchgeführt wird. Diese Reihenfolge entspricht im europäischen Raum der Leserichtung
und begünstigt die Verständlichkeit. Die Auswahl eines Subsystems in der
Hauptansicht (vgl. Abb. 5.14, 5.15) im oberen Teil bewirkt ein Anpassung der Detailansichten
in der unteren Hälfte. Die Partitionierung der Analyseobjekte und die Zuteilung
der Interfaces durch Nachrichten ist in Form eines drag&drop-Mechanismus
realisiert, der eine Ausrichtung von links nach rechts besitzt.
Desweiteren wurden alle Modelländerungen geeignet durch Commands gekapselt, damit
der allgemeine undo/redo-Mechanismus der TaskWizard-Seite ein für den Ent-
104

7.3 Methodenunterstützung
wickler konsistentes Verhalten aufweist. Alle Modelländerungen, die vom Entwickler
durch eine einzige Aktion durchgeführt werden, bilden eine scheinbar atomare Einheit.
Löscht der Entwickler beispielsweise mehrere parts eines Subsystems, werden alle dafür
notwendigen Commands durch einen CompoundCommand zusammengefasst. Das
Widerrufen der letzten Änderung bewirkt also das Wiederherstellen aller gelöschten
Parts. Die daraus resultierende Steigerung der Konsistenz und Verständlichkeit konnte
zusätzlich durch eine geeignete Benennung dieser Commands erzielt werden.
Als besonders negativ für die Parts-Ansicht (vgl. Abschnitt 5.2.4) muss hervorgehoben
werden, dass die Gruppierung der Analyseobjekte bezüglich der bereits partitionierten
Objekte und der noch nicht zugewiesenen Objekte ab einer gewissen Komplexität sehr
unübersichtlich wird. In der baumartigen Struktur werden alle Analyseobjekte durch
Angabe ihres Identifiers dargestellt. Die Repräsentanten bilden Unterknoten des jeweiligen
Objekts. Sollten in einem Analysemodell sehr viele Objekte identifiziert worden
sein, ist es für den Entwickler wohl sehr schwierig, nachzuvollziehen, in welchem
Kontext die jeweiligen Objekte modelliert wurden. An dieser Stelle fehlt die Möglichkeit,
die in der Analyse erstellten UML-Diagramme zu betrachten oder sogar mit in
die Interaktion einbeziehen zu können, um dadurch einen hohen Wiedererkennungsgrad
zu erzielen, der durch die bisher realisierte baumartige Ansicht nicht gewährleistet
wird.
105

7 Evaluierung
106

8 Zusammenfassung
Im Rahmen dieser Arbeit sollte das Werkzeug ViPER für die modellgetriebene Entwicklung
um die Unterstützung der MeDUSA-Methode erweitert werden. Verbunden
durch gemeinsame Konzepte wie der Use Case- und modellgetriebenen-Entwicklung
bilden sie zusammen mit der UML ein Systemdreieck. Während mit ViPER eine prototypische
Entwicklungsumgebung für den UML-basierten Entwurf bereitgestellt wird,
ist MeDUSA ist eine Methode zur Entwicklung von kleinen eingebetten Systemen.
Um eine geeignete Unterstützung von MeDUSA in ViPER vornehmen zu können,
wurden bereits in der Einleitung zwei Leitfragen hervorgehoben, die die Richtung der
dann folgenden konzeptionellen und technischen Realisierung vorgaben:
• Methodenunterstützung: Wodurch kann der Entwickler bei den Aufgaben einer
Methode möglichst optimal unterstützt werden?
• Prozessintegration: Wie kann der zeitliche Ablauf eines Entwicklungsprozesses
in einem Werkzeug abgebildet werden?
Zunächst wurde im Kapitel 2 das Systemdreieck - MeDUSA, UML und ViPER - vorgestellt
und alle für diese Arbeit relevanten Teile wurden erläutert. Insbesondere wurden
wichtige Sprachpakete der UML und von ViPER genutzte Frameworks beschrieben.
Im dem sich anschließenden Kapitel 3 wurden aktuelle Werkzeuge für die modellgetriebene
Entwicklung bezüglich ihrer Unterstützung hinsichtlich der identifizierten
Leitfragen untersucht. Während mit dem Werkzeug WayPointer der Firma jaczone primär
die Validierung und Korrekturvorschläge von UML-Diagrammen unterstützt wird,
bietet der Rational System Developer eine umfangreiche integrierte Prozessbeschreibung.
Diese Prozessbeschreibung kann als statische Referenz aber auch als kontextabhängige
Hilfe verwendet werden.
Die in Kapitel 4 vorgestellte Vision griff die Erkenntnisse aus der Untersuchung der
beiden Werkzeuge auf, und es wurden verschiedene Ideen einer möglichen Unterstützung
herausgearbeitet. Für die Methodenunterstützung wurden einige allgemeine Anforderungen
hervorgehoben, die bei einer Hilfestellung für jede Aufgabe Verwendung
finden könnte. Des Weiteren wurden aufgabenspezifische Unterstützungen beschrieben.
Eine Realisierung aller identifizierten Aspekte konnte im Rahmen dieser Arbeit
nicht vorgenommen werden. Deshalb wurde der Schwerpunkt auf die Erstellung eines
Frameworks für die Methodenunterstützung eines Prototypen für die Unterstützung
der Subsystem Identification gelegt. Durch eine zusätzliche Prozessintegration sollte
die Möglichkeit bestehen, den MeDUSA-Prozess auf der Basis von CheatSheets
durchführen zu können, um damit die Unterstützung der einzelnen Aufgaben anzusto-
107

8 Zusammenfassung
ßen. Zusätzlich war eine Prozessbeschreibung in das Eclipse-Hilfesystem zu integrierenwerden.
Die Beschreibung der Methodenunterstützung im Kapitel 5 wurde unterteilt in einen
allgemeinen Teil und in einen speziellen Teil für die Unterstützung der Subsystem
Identification. Im allgemeinen Teil wurde ein einfaches konzeptionelles Modell entwickelt,
mit dem eine Aufgabe im Kontext eines iterativen Vorgehens beschrieben werden
kann. Neben den Änderungen der in einer Aufgabe verwendeten UML-Modelle
berücksichtigt dieses Aufgabenmodell zum einen Vor- und Nachbedingungen, die an
die Modelle vor beziehungsweise nach der Bearbeitung gestellt werden und unterbreitet
zum anderen eventuelle Korrekturvorschläge. Zusätzlich wurde ein Traceability-
Modell entwickelt, das aus der Notwendigkeit heraus erforderlich geworden war, Abbildungsinformationen
zwischen UML-Modellen für die Nachverfolgbarkeit in einem
externen Modell ablegen zu können. Durch diese Informationen kann die Durchgängigkeit
der disziplinspezifischen Modelle überprüft werden. Auf der Basis des Aufgabenmodells
wurde auf der technischen Seite das Iterative Task Framework realisiert,
mit dem die Bearbeitung einer Aufgabe in einer festgelegten Sequenz durchgeführt
wird. Die Unterstützung einer Aufgabe erfolgt durch die Implementierung eines
TaskWizards, wobei lediglich die für die Aufgabe spezifischen Teile realisiert werden
müssen. Sowohl die Ordnung der Seiten zur Einhaltung der Bearbeitungssequenz als
auch die Erstellung der allgemeinen Seiten wird durch das Framework sichergestellt.
Die Unterstützung der Subsystem Identification wurde durch die Nutzung dieses Frameworks
implemeniert. Die instanzgetriebene Entwicklung mit MeDUSA bildet ein
gegenläufiges Konzept zur Classifier-getriebenen Entwicklung mit der UML. Somit
musste eine Lösung gefunden werden, mit der Analyseobjekte in den UML-Modellen
abgebildet werden können. Durch die Erweiterung der für die Objekttaxonomie von
MeDUSA verwendeten Stereotypen kann jedem Repräsentanten eines Objekts im jeweiligen
Sprachpaket ein Identifier zugeordnet werden. Durch die Erstellung einer aufgabenspezifischen
Wizard-Seite wird nicht nur die Partitionierung der Analyseobjekte
durch Subsysteme im Architekturmodell sondern auch die Zuordnung von Nachrichten
auf Ports der Subsysteme unterstützt. Dazu wurde eine Oberfläche mit verschiedenen
Ansichten auf die jeweiligen Subsysteme realisiert.
Die zukünftige Entwicklung der in dieser Arbeit begonnenen Erweiterung für die Unterstützung
der MeDUSA-Methode kann bezüglich verschiedener Ansätze weiter getrieben
werden. Zum einen ist natürlich die Unterstützung aller bislang nicht betrachteten
Aufgaben denkbar, die unter Verwendung des Iterative Task Frameworks realisiert
werden können. Zum anderen gibt es aber auch bezüglich der Unterstützung für die
Subsystem Identification, deren Realisierung im Rahmen dieser Arbeit prototypisch
begonnen wurde, noch einige offene Punkte.
Für den Vorgang der Abbildung der Repräsentanten auf Analyseobjekte könnte eine
ähnliche Hilfestellung wie bei der Partitionierung der Analyseobjekte geleistet werden.
Neben der Nutzung während der Bearbeitung der Analyseaufgaben könnte diese
Funktionalität in der Unterstützung der Subsystem Identification eingesetzt werden,
um damit Korrekturvorschläge anbieten zu können.
108

Außerdem sollte, wie in der Evaluierung beschrieben, eine bessere Sicht auf die Analyseobjekte
geliefert werden, als durch eine einfache Unterteilung in partitionierte und
nicht partitionierte Objekte. Durch eine Einbettung der vorhandenen UML-Diagramme
in die Detailansichten könnte dem Enwickler der Kontext des von ihm Modellierten
besser dargestellt werden. Dadurch könnte er leichter nachvollziehen, um welches Objekt
es sich handelt, da der Name als einziger Hinweis ab einer gewissen Anzahl von
Objekten nicht sehr aussagekräftig ist.
Nichtzuletzt ist die Fertigstellung der Metrik-Ansicht ein sehr wichtiger Punkt, der im
Rahmen dieser Arbeit aus zeitlichen nicht zu Ende geführt werden konnte.
Für die Prozessintegration wurden dann im Kapitel 6 Möglichkeiten vorgestellt, mit
denen Methoden und allgemeine Entwicklungsprozesse modelliert werden können.
Mit dem EPF-Composer steht ein Werkzeug zur Verfügung, mit dem auf der Basis
der Unified Modeling Architecture sehr einfach ein Prozessmodell von MeDUSA erstellt
werden kann. Mit diesem Modell konnten dann die CheatSheets und die Prozessbeschreibung
automatisch generiert werden. Für die Generierung wurde der EPF-
Composer durch einige Bestandteile von ViPER erweitert, womit durch zusätzliche
Funktionalität ein neues Werkzeug entstand. Mit der Verwendung von ViPER PF können
nun beliebige Prozessmodelle in Eclipse-basierte Entwicklungsumgebungen integriert
werden. Die TaskWizards als Hilfemittel einer Methodenunterstützung können
aus den CheatSheet heraus gestartet werden.
Die Realisierung der Prozessintegration liefert einen wichtigen Beitrag für die Unterstützung
der Methode, da sowohl der Ablauf als auch die komplette Prozessbeschreibung
damit in ViPER integriert werden konnte. Durch die Methodenunterstützung
wurde ein klar definierter Rahmen festgelegt, auf dessen Basis die Hilfestellung
einer konkreten Aufgabe realisiert werden kann, wie es protypisch durch die Unterstützung
der Subsystem Identification gezeigt wurde.
109

8 Zusammenfassung
110

Literaturverzeichnis
[AFM00] ALEX, JÜRGEN, HERMANN FLESSNER und WILHELM MONS: Konrad
Zuse - Der Vater des Computers, 2000.
[AMW] ATLAS Model Weaver. http://wiki.eclipse.org/index.php/AMW.
[APF] WayPointer Active Process Framework. http://www.jaczone.com.
[ATL] ATLAS Transformation Language. http://www.eclipse.org/m2m/atl.
[Bal01] BALZERT, HELMUT: Lehrbuch der Softwaretechnik, 2. Auflage. Spektrum
Akademischer Verlag, 2001.
[Bar99] BARR, MICHAEL: Programming Embedded Systems in C and C++.
O’Reilly, 1999.
[BSM + 03] BUDINSKY, FRANK, DAVID STEINBERG, ED MERKS, RAYMOND EL-
LERSICK und TIMOTHY J. GROSE: Eclipse Modeling Framework: A Developer’s
Guide, 2003.
[DFK + 04] D´ANJOU, JIM, SCOTT FAIRBROTHER, DAN KEHN, JOHN KELLER-
MAN und PAT MCCARTHY: The Java Developer´s Guide to Eclipse, Second
Edition. Addison-Wesley, 2004.
[DI006] Diagram Interchange, 2006. http://www.omg.org/docs/formal/06-04-
04.pdf.
[Dij72] DIJKSTRA, EDSGER W.: The Humble Programmer, 1972.
http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF.
[Dou99] DOUGLASS, BRUCE POWEL: Doing Hard Time. ADDISON-WESLEY,
1999.
[Dou06] DOUGLASS, BRUCE POWEL: Real-Time UML Workshop for Embedded
Systems. Butterworth Heinemann, 2006.
[Ecl] Eclipse. http://www.eclipse.org.
[EHLK04] EDGAR, NICK, KEVIN HAALAND, JIN LI und PETER
KIMBERLEY: Eclipse User Interface Guidelines, 2004.
http://www.eclipse.org/articles/Article-UI-Guidelines/Index.html.
[EPF] http://www.eclipse.org/epf.
111

Literaturverzeichnis
[Gau06] GAU, THORSTEN: UMA und EPF: Einführung und Anwendung in der
Praxis. ObjektSpektrum, 06:43–46, 2006.
[Gom00] GOMAA, HASSAN: Designing Concurrent, Distributed, and Real-Time
Applications with UML. Addison-Wesley, 2000.
[Hau07] HAUMER, PETER: Eclipse Process Framework
Composer, Part 1: Key Concepts, 2007.
http://www.eclipse.org/epf/general/EPFComposerOverviewPart1.pdf.
[Inf07] Unified Modeling Language: Infrastructure, 2007.
http://www.omg.org/docs/formal/07-02-04.pdf.
[Jac06] JACZONE AB: User Guide, Waypointer 6.0, 2006. Im Lieferumfang der
Testversion vorhanden.
[Jav] Java. http://www.java.sun.com.
[JCJv92] JACOBSON, IVAR, MAGNUS CHRISTERSON, PATRIK JONSSON und
GUNNAR ÖVERGAARD: Object-Oriented Software Engineering - A Use
Case Driven Approach. Addison-Wesley, 1992.
[Kru99] KRUCHTEN, PHILIPPE: Rational Unified Process, An Introduction.
Addison-Wesley, 1999.
[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.
[NL] NYSSEN, ALEXANDER und HORST LICHTER: Weakness of Use Case
Modeling in te Context of Embedded Sofware Applications. Zu veröffentlichen.
[Obj07] OBJECT MANAGEMENT GROUP: Unified Modeling Language: Superstructure,
2007. http://www.omg.org/docs/formal/07-02-03.pdf.
[OCL06] Object Constraint Language, 2006. http://www.omg.org/docs/formal/06-
05-01.pdf.
[RSD] Rational Software Developer. http://www.ibm.com.
[Rum99] RUMBAUGH, JAMES, IVAR JACOBSON UND GRADY BOOCH: The Unified
Modeling Language Reference Manual. Addison-Wesley, 1999.
[Sau] SAUER, FRANK: Metrics. http://metrics.sourceforge.net/.
[SHNM05] SCARPINO, MATTHEW, STEPHEN HOLDER, STANFORD NG und LAU-
RENT MIHALKOVIC: SWT/JFace IN ACTION. Manning Publications Co.,
112

2005.
[Sof] SOFTWARE RESEARCH, INC. http://e-valid.com/.
Literaturverzeichnis
[SPE05] Software Process Metamodel Specification, 2005.
http://www.omg.org/docs/formal/05-01-06.pdf.
[SPE07] Software Process Metamodel Specification, 2007.
http://www.omg.org/docs/formal/03-03-07.pdf.
[UML] Unified Modeling Language. http://www.uml.org.
[VBBJ06] VEPA, ERIC, JEAN BEZIVIN, HUGO BRUNELIERE und FREDERIC JOU-
AULT: Measuring Model Repositories, 2006.
[ViP] ViPER Project Site. http://www.viper.sc.
[WNHL] WALTER, ANDREAS, ALEXANDER NYSSEN, VEIT HOFFMANN und
HORST LICHTER: Towards the integration of UML and text based use
case modeling. Noch nicht veröffentlicht.
[XMI05] Meta Object Facility (MOF) 2.0 XMI Mapping Specification, 2005.
http://www.omg.org/docs/formal/05-09-01.pdf.
113