INSTITUT F¨UR INFORMATIK Automatisierte Modell-Co-Evolution ...

INSTITUT FÜR INFORMATIK
DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN
Diplomarbeit
Automatisierte
Modell-Co-Evolution
bei der modellgetriebenen
Entwicklung
von
Rich Internet Applications
Olena Ivanyushyna

INSTITUT FÜR INFORMATIK
DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN
Diplomarbeit
Automatisierte
Modell-Co-Evolution
bei der modellgetriebenen
Entwicklung
von
Rich Internet Applications
Olena Ivanyushyna
Aufgabensteller: Prof. Dr. Martin Wirsing
Betreuer: Dr. Nora Koch
Abgabetermin: 31. Mai 2012

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbständig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
München, den 30. März 2012
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Unterschrift der Kandidatin)

Abstract
Die Rich Internet Applications(RIAs) bilden eine neue Art der Webanwendungen, welche die
Grenzen der traditionellen Web Anwendungen sehr stark erweitern. Die Reichhaltigkeit der
graphischen Schnittstelle und die Anwenderfreundlichkeit sind aus dem heutigen Internet
nicht mehr weg zu denken. Die RIAs bieten eine Vielzahl von Vorteilen der herkömmlichen
Webanwendungen und der Desktop-Anwendungen, werden mit fortgeschrittenen Webtechnologien
umgesetzt und verfügen über eine Vielfalt von benutzerfreundlichen interaktiven
Möglichkeiten.
Mit der UML-based Web Engineering (UWE) Methodologie 1 kann man bereits RIAs modellieren.
Für die Modellierung wird ein UWE-Profil als leichtgewichtiger Erweiterungsmechanismus
des UML Metamodells eingesetzt. Am UWE-Profil wurden in den letzten Jahren
viele Änderungen vorgenommen. Neue Elemente, die RIA-spezifisch sind, wurden zum Profil
hinzugefügt; eine Einbettung der Design Patterns wurde erarbeitet; die Sicherheitsaspekte
wurden in das UWE-Profil integriert. Die Evolution des UWE-Profils brachte die Notwendigkeit
der Anpassung der bereits existierenden UWE-Modelle mit sich, um ihre Konformität
mit dem neuen, weiterentwickelten UWE-Profil herzustellen. Solche Anpassung wird Modell-
Co-Evolution genannt. Die Modelle stehen im Fokus der modellgetriebenen Entwicklung,
somit spielt die Modell-Co-Evolution eine gravierende Rolle. Auf diesem Gebiet der modellgetriebenen
Entwicklung wird aktuell sehr intensiv geforscht und nach Lösungsansätzen für
die Co-Evolution-Problematik gesucht.
Die vorliegende Arbeit stellt Vorschläge für die Umsetzung der Modell-Co-Evolution vor. Diese
Vorschläge garantieren die Herstellung der Konsistenz der existierenden UWE-Modelle. Es
wird aus der Metamodell-Evolution die benötigte Modell-Co-Evolution abgeleitet. Durch eine
Automatisierung dieses Prozesses ist die Eindeutigkeit der Modell-Co-Evolution-Strategie
gewährleistet. Über die Problematik des Automatisierungsgrades der Modell-Co-Evolution-
Anpassungsschritte für unterschiedliche Metamodelländerungstypen wird im Rahmen dieser
Arbeit ausführlich diskutiert.
Ein transformativer Ansatz zur automatisierten Modell-Co-Evolution der UWE-Modelle
wurde erarbeitet. Eine Erweiterung des Eclipse-basierten Modellierungswerkzeug Topcased
(Toolkit in OPen source for Critical Applications & SystEms Development) durch das Plugin
UWEclipse stellt eine Plattform für die Modellierung von RIAs bereit. Der in dieser Arbeit
umgesetzte transformative Ansatz wird später im Rahmen des UWEclipse integriert.
1 http://uwe.pst.ifi.lmu.de
vii

Inhaltsverzeichnis
1 Einleitung 1
1.1 Problemstellung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen und verwendeten Technologien 5
2.1 Rich Internet Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Model Driven Architecture (MDA) . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Ziele der MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Metamodell der Grundbegriffe der MDA . . . . . . . . . . . . . . . . . 7
2.2.3 Durch MDA spezifizierte Modelle . . . . . . . . . . . . . . . . . . . . . 9
2.3 Die Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Die Unified Modeling Language (UML). UML Profile . . . . . . . . . 10
2.3.2 Die Meta Modellierung und die Meta Object Facility (MOF) . . . . . 11
2.3.3 Die Object Constraint Language (OCL) . . . . . . . . . . . . . . . . . 12
2.4 Die Query View Transformations (QVT) . . . . . . . . . . . . . . . . . . . . . 13
2.5 Das Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . . . . . . . . 13
2.5.1 Metamodellierung mit Ecore Tools . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Die Eclipse UML2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Die UWE Methodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.1 UWE Metamodell und UWE Profil . . . . . . . . . . . . . . . . . . . . 15
2.6.2 Die Separation of Concerns . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6.3 MagicUWE - UWE Plug-in für MagicDraw . . . . . . . . . . . . . . . 15
3 Die Modellevolution und die Modell-Co-Evolution 17
3.1 Was bringt die Modell-Evolution mit sich . . . . . . . . . . . . . . . . . . . . 18
3.1.1 Die Relationstypen zwischen dem Metamodell und den Modellierungsartefakten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Die Klassifizierung der Metamodelländerungen . . . . . . . . . . . . . . . . . 20
3.2.1 Illustratives Beispiel für Metamodell-Evolution . . . . . . . . . . . . . 20
3.2.2 Die additiven Änderungen eines Metamodells . . . . . . . . . . . . . . 23
3.2.3 Die subtraktiven Änderungen eines Metamodells . . . . . . . . . . . . 24
3.2.4 Die Updates an einem Metamodell . . . . . . . . . . . . . . . . . . . . 25
3.2.5 Die Klassifizierung von Metamodelländerungen anhand der korrupten
bzw. der non-korrupten Effekte auf existierende Modelle . . . . . . . . 25
3.3 Die Transformation-Co-Evolution . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Modell-Co-Evolution der UWE-Präsentationsmodelle . . . . . . . . . . . . . . 27
viii

Inhaltsverzeichnis
3.4.1 Die Metamodelldifferenzen zwischen UWE-Metamodellversion 1.7 und
der Version 1.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz 33
4.1 Der fundamentale Aufbau von Transformationsskript in der relationalen QVT-
Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Die relationalen Transformationen. Eine Formale Darstellung der Konzepte . 36
4.2.1 Die Transformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Die Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Die Domänen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4 Die when- und where-Klauseln . . . . . . . . . . . . . . . . . . . . . . 41
4.2.5 Object Template Expressions und Inline-Objekterzeugung . . . . . . . 42
4.3 Transformationen zur automatisierten Modell-Co-Evolution basierend auf UWE-
Metamodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Signatur der Transformation . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2 Die Identifizierung der Relationen . . . . . . . . . . . . . . . . . . . . 45
4.3.3 Die Relation für das Paket . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.4 Die Relationen für die PresentationClass und deren Subklassen . . . . 49
4.3.5 Die Relationen für einfache UI-Elemente . . . . . . . . . . . . . . . . . 52
4.3.6 Die Relation mapForm . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.7 Die Relation mapAnchoredCol . . . . . . . . . . . . . . . . . . . . . . 55
4.3.8 Die Relation mapProperty . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Die Durchführung der Transformationen mit dem mediniQVT-Tool . . . . . . 57
4.5 Ein Beispiel für metamodellbasierte Modell-Co-Evolution . . . . . . . . . . . 59
4.5.1 Die Durchführung der Transformation an dem Adressbuch-Modell . . 59
4.5.2 Die Konfiguration einer Transformation in mediniQVT . . . . . . . . . 61
4.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5 Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE
Toolumgebung 63
5.1 Anpassung der metamodellbasierten Transformation für UWE-Modelle . . . . 63
5.1.1 Der Zugriff auf die angewendeten UWE-Stereotypen . . . . . . . . . . 64
5.1.2 Die neu angepasste Transformation . . . . . . . . . . . . . . . . . . . . 65
5.1.3 Die Relation für die PresentationClass . . . . . . . . . . . . . . . . . . 68
5.2 Wahl der Toolumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Die Anforderungsanalyse für die Integration des transformativen Ansatzes . . 73
5.3.1 Die funktionalen Anforderungen . . . . . . . . . . . . . . . . . . . . . 73
5.3.2 Die nicht-funktionalen Anforderungen . . . . . . . . . . . . . . . . . . 74
5.4 Die Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.1 Das UseCase ” Die Transformation für ein Modell durchführen“ . . . . 76
5.4.2 Das UseCase ” Die Modelldifferenzen anzeigen lassen“ . . . . . . . . . 77
5.4.3 Das UseCase ” Die Konformität eines Modells zu seinem Metamodell
prüfen“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5 Die zusammengesetzte Toolumgebung . . . . . . . . . . . . . . . . . . . . . . 78
5.5.1 Das mediniQVT-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.5.2 Das EMF-Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
ix

Inhaltsverzeichnis
5.6 Beispiel der Modell-Co-Evolution für UWE-Modelle mit angewendetem UWE-
Profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6 Die Zusammenfassung und der Ausblick 87
6.1 Die Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 Der Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A Darstellung der Metamodelle 91
A.1 Erstellung von Metamodellen in Ecore-Format . . . . . . . . . . . . . . . . . 92
A.2 Ein Generator-Modell aus Ecore-Modellen erstellen . . . . . . . . . . . . . . . 96
A.3 Erstellung der Metamodelle in Form von Eclipse-Plug-ins . . . . . . . . . . . 98
A.4 Das Deployment der Metamodell-Eclipse-Plug-ins . . . . . . . . . . . . . . . . 99
A.5 Modelle basierend auf Metamodellen erstellen . . . . . . . . . . . . . . . . . . 101
B Transformationsskript mapUWEversion 103
Abbildungsverzeichnis 112
Tabellenverzeichnis 113
Listings 115
Liste der Definitionen 117
Literaturverzeichnis 119
x

1. Einleitung
So vielfältig die Einsatzbereiche für Rich Internet Applications sind, so umfangreich sind
die Möglichkeiten, RIAs zu implementieren. Inzwischen gibt es bereits eine ganze Reihe von
Technologien, Frameworks und konkreter Techniken, die genutzt werden können, um RIAs zu
erstellen. Die rasante Entwicklung dieser Techniken bewirkt, dass immer neue User-Interface-
Elemente und Interaktionsmöglichkeiten für den Benutzer bei der Entwicklung der RIAs zur
Hilfe stehen.
Im Bereich der modelgetriebenen Webentwicklung dagegen entwickeln sich erst seit kurzem
faszinierende Forschungsgebiete und neue methodologische Ansätze zur modelgetriebenen
Entwicklung von Rich Internet Applications, die sich zu einem großen Teil noch in frühen
Entwicklungsphasen befinden. Hier werden derzeit aktiv die Modellierungstechniken und
Tools für die Modellierung von Rich Internet Applications erweitert und angepasst. Es werden
immer neue Erkenntnisse auf dem Fachgebiet der RIAs gemacht, so dass interessante
Forschungsteilgebiete entstehen, die sich z.B. auf die Adaptivität der RIAs oder auf die
neue Sicherheitsaspekte der RIAs beziehen oder die Integration der Anforderungsanalyse
in den Entwurf erlauben. Es entstehen RIA-spezifische ” design pattern“, welche die ” best
practices“ Lösungen für den Entwurf von RIAs wiedergeben und in die Metamodelle für die
Modellierung integriert werden können.
Die Erarbeitung solcher Modellierungstechniken soll mit der Entwicklung des Fachgebietes,
als auch mit dem technischen Fortschritt mithalten können. Diese Tatsache bewirkt, dass
für die Modellierung eingesetzte Metamodelle einem schnell voranschreitenden Evolutionsprozesses
unterliegen.
Die UML-based Web Engineering (UWE) Methodologie wird kontinuierlich weiterentwickelt.
Die grundlegende Idee von UWE ist das Fachgebiet der Entwicklung von RIAs mithilfe einer
Domain Specific Language (DSL) eindeutig zu beschreiben, um basierend auf dieser DSL
ein UML Profil zu definieren, das auf das Fachgebiet der RIAs zugeschnitten ist. Somit
wird mit Hilfe einer UML Erweiterung in Form dieses Profils die Modellierung von RIAs
mit der weitverbreitesten objektorientierten Modellierungssprache der Welt ermöglicht. Wie
das Fachgebiet ändert sich ebenfalls die UWE Methodologie. Es existiert eine Anzahl an
Versionen des UWE-Profils und des UWE-Metamodells, diese sind wie z.B. die Version 1.7
und die Version 1.8 auf der UWE-Seite 1 zu finden. Die Evolution des UWE-Profils erfordert
bei jeder Verabschiedung einer neuen Profilversion die Anpassung der existierenden UWE-
Modelle, da Inkonsistenzen wegen des Konformitätsverlustes der existierenden Modelle zu
dem neuen Profil entstehen.
1 http://uwe.pst.ifi.lmu.de/publicationsMetamodelAndProfile.html
1

1. Einleitung
1.1. Problemstellung der Arbeit
Im Bereich der modellgetriebenen Webentwicklung besteht eine immer größer werdende Not
an Techniken zur automatisierten Modell-Co-Evolution. Die Metamodell-Evolution stellt eine
Bedrohung dar für die Anwendbarkeit der modellgetriebenen Entwicklung in Fachgebieten,
die von Veränderungen stark geprägt sind. Zu solchen Fachgebieten zählen die RIAs. Das
Problem wird durch die Inkompatibilitäten zwischen Metamodellversionen verursacht. Dies
bewirkt, dass die Modelle, welche mit der älteren Metamodellversion konform gehen, wegen
der Nicht-Konformität zur neueren Version angepasst werden müssen. Eine Annäherung an
die Lösung dieses Problems ist die Modell-Co-Evolution von Modellen mit ihrem jeweiligen
Metamodell. Um die unterschiedlichen Deutungen des Begriffes der Modell-Co-Evolution zu
vermeiden, wird an dieser Stelle die Definition dafür eingeführt.
Definition 1. Modell-Co-Evolution
Unter Modell-Co-Evolution wird eine Anpassung der existierenden Modelle
verstanden, die wegen der Evolution des zugrundeliegenden Metamodells
durchgeführt werden muss. Die Anpassung bewirkt, dass diese Modelle mit
dem neuen geänderten Metamodell konform gehen.
Für die Metamodell-Evolution gibt es unterschiedliche Gründe: zum einen können neue
Design-Lösungen für besseres Verständnis der Metamodelle die Metamodelländerungen bewirken.
Zum anderen werden Metamodelle aufgrund der schnellen Entwicklung des Fachgebietes
geändert. Das Hinzufügen der Design Pattern oder der ” best practices“ Lösungen kann
der Metamodell-Evolution zugrunde liegen. Deswegen sollten die existierenden Modelle an
diese Änderungen angepasst werden ohne dass sie ihre Gültigkeit verlieren. Nach der Metamodelländerung
müssen alle Modelle die vor dieser Änderung erstellt wurden, mit angepasst
werden, damit sie zu dem neuen Metamodell konform sind.
Wie die Metamodell-Evolution wird die Modell-Co-Evolution üblicherweise manuell durchgeführt.
Dies ist eine sehr fehleranfällige Aufgabe, die zu einer Inkonsistenz zwischen dem
Metamodell und den dazugehörigen Modellen führen kann. Die Modellierer und Entwickler
müssen all die betroffenen Modelle sorgfältig untersuchen, um mühsam die zu Inkonsistenzen
führenden Elemente zu entdecken und später die Modell-Co-Evolution schrittweise manuell
durchzuführen. Dies ist an sich eine fehleranfällige und ohne Automatisierung ziemlich langweilige,
monotone und vor allem zeitaufwendige Aufgabe. Zusätzliche Schwierigkeit bereitet
die Tatsache, dass keine eindeutige Weise der Modellelementenanpassung verfügbar ist. Dies
liegt daran, dass die Modellgültigkeit durch verschiedene Migrationsstrategien wieder hergestellt
werden kann, d. h. verschiedene Anpassungen können aus der Metamodell-Evolution
abgeleitet werden. Dies wiederspricht aufgrund von Mehrdeutigkeit dem Grundprinzip der
formalen Modelle. Aufgrund dieser schwerwiegenden Problematik, die bei der Entwicklung
der Rich Internet Applications im Wege steht, muss eine Vorgehensweise für eine automatisierte
Modell-Co-Evolution entwickelt werden.
2

1.2. Lösungsansatz
1.2. Lösungsansatz
In erster Linie soll diese Arbeit einen Einblick in die aktuellen Forschungstrends des Gebiets
der Modell-Co-Evolution gewähren. Es soll eine Diskussion über alle möglichen Szenarien für
die Metamodelländerungen und deren Auswirkungen auf die existierenden Modelle erfolgen.
Aus entstandenen Szenarien sollen Erkenntnisse erarbeitet werden, welche die Anpassung
der Metamodellinstanzen vorschreiben, welche die Inkonsistenz des Modells in Bezug auf
das neue Metamodell beseitigt. Anhand der Auswirkung der Metamodelländerungen auf die
Modelle sollte bestimmt werden, ob eine Automatisierung der Modell-Co-Evolution stattfinden
kann.
Die UWE-Metamodelle in zwei ausgewählten unterschiedlichen Versionen sollen auf Differenzen
überprüft werden. Die erkannten Metamodelländerungen sollen zusammengefasst
werden. Für jede solche Änderung soll die Strategie zur Modell-Co-Evolution beschrieben
werden. Aus den gewonnenen Erkenntnissen soll ein transformativer Modell-Co-Evolution
Ansatz für UWE-Modelle praktisch umgesetzt werden.
Anschließend soll eine Anforderungsanalyse für die Integrationsmöglichkeiten in die Toolumgebung
der UWE-Methodologie durchgeführt werden. Zu guter Letzt soll ein Integrationsweg
ausgewählt und umgesetzt werden.
1.3. Gliederung
Im Kapitel 2 werden die Grundlagen und die verwendete Technologien erläutert. Innerhalb
dieses Kapitels wird auf die zentralen Begrifflichkeiten dieser Arbeit angegangen. Angefangen
mit der Definition der Rich Internet Applications, den grundlegenden Begriffen aus dem Bereich
der Modell Driven Architecture bis hin zu einem Überblick über die aktuellen Ansätze
zur modellgetriebenen Entwicklung von RIAs.
Im Kapitel 3 wird eine Einführung in den Bereich der Modell-Co-Evolution geboten. Es
wird anhand der aktuellen Forschung eine umfassende Diskussion über die Metamodell-
Evolution gegeben. Die Metamodelländerungen werden in ihrem vollen Umfang beschrieben
und zu jeder solchen Änderung eine umfangreiche Beschreibung der Co-Evolutions-Schritte
aufgezeichnet. Darüber hinaus wird eine Typologie der Änderungen in Bezug auf ihre Auswirkungen
auf existierende Metamodellinstanzen vorgestellt. Zwei verschiedenen Versionen
eines UWE-Metamodellausschnittes werden in Bezug auf die durch die UWE-Metamodell-
Evolution entstandenen Differenzen untersucht. Eine Strategie wird für eine automatisierte
Modell-Co-Evolution für die betrachtete Metamodellversionen vorgeschlagen und detailliert
beschrieben.
Im Kapitel 4 wird diese Strategie mithilfe der Modelltransformationen umgesetzt. Zuerst
werden die formalen Konzepte der für die Transformationen ausgewählten relationalen QVT-
Sprache beschrieben. Anschließend werden die konkreten Transformationen für die Durchführung
der Modell-Co-Evolution für UWE-Präsentationsmodell vorgestellt.
Nachdem die Machbarkeit der Transformationen in Kapitel 4 illustriert wurde, werden im
darauf anschließenden Kapitel 5 einige Überlegungen zu der Integration des transforma-
3

1. Einleitung
tiven Ansatzes in die UWE-Toolumgebung erläutert, angefangen bei der Diskussion über
die Integrationsmöglichkeiten des transformativen Ansatzes in die UWE-Methodologie, gefolgt
von einer Anwendungsfallanalyse, bis hin zu einem konkreten Integrationsvorschlag.
Der Vorschlag wird für die Integration in das Eclipse-basierte UWEclipse-Tool[22], das eine
Toolumgebung für die Modellierung der UWE-Modelle bereitstellt, detailliert beschrieben.
Infolgedessen wird eine Anpassung der in Kapitel 4 vorgestellten Modell-Co-Evolution-
Transformationen vorgenommen und der Einsatz des EMFCompare-Tools für die Modelldifferenzenrepräsentation
dargestellt.
Anschließend werden in dem Kapitel die erreichten Ergebnisse resümiert und ein Ausblick
für die Zukunft und die Verbesserungsmöglichkeiten des vorgestellten Modell-Co-Evolution-
Ansatzes gegeben.
4

2. Grundlagen und verwendeten Technologien
In den folgenden Unterkapiteln werden die Grundlagen der modellgetriebenen Entwicklung
von Rich Internet Applications vorgestellt und die für die vorliegende Arbeit relevante Begriffe
wie ” Rich Internet Application“ und einige weitere Begriffe aus dem Bereich der Model
Driven Architecture (MDA) definiert.
2.1. Rich Internet Applications
In den letzten Jahren hat der neue Begriff der Rich Internet Applications eine weite Verbreitung
gefunden. In unterschiedlichen Quellen wurden die RIAs lange mithilfe deren Eigenschaften
beschrieben. Eine umfassende Definition wurde in der Veröffentlichung ” Rich
Internet Application. State-of-the-Art“[13] vorgeschlagen. Diese Definition wird im Rahmen
dieser Arbeit als Grundbegriff für die RIAs eingeführt.
Definition 2. Rich Internet Applications
” Rich Internet Applications (RIAs) are web applications, which use data that
can be processed both by the server and the client. Furthermore, the data exchange
takes place in an asynchronous way so that the client stays responsive
while continuously recalculating or updating parts of the user interface. On
the client, RIAs provide a similar look-and-feel as desktop applications and
the word rich“ means particularly the difference to the earlier generation of
”
web applications. RIAs are basically characterized by a variety of interactive
operating controls, the possibility of on-/offline use of the application, and
the transparent usage of the client and server computing power and of the
network connection..“[13]
Zu den wichtigsten Eigenschaften von RIAs gehört die asynchrone Kommunikation, wobei
nicht nur ganze Internetseiten übertragen werden, sondern bestimmten Teile der Webseiten
aktualisiert werden. Eine kennzeichnende Eigenschaft der RIAs ist die Reichhaltigkeit und die
Benutzerfreundlichkeit der graphischen Oberfläche, die in nichts den Desktop-Anwendungen
nachsteht.
Die wachsende Verbreitung der RIAs bedingt die neuen Trends im Bereich der modellgetriebenen
Webentwicklung. Neue Techniken und Ansätze, die später zum Teil erläutert werden,
ermöglichen bereits die Modellierung der RIAs.
5

2. Grundlagen und verwendeten Technologien
2.2. Model Driven Architecture (MDA)
Model Driven Architecture (MDA) wurde von der OMG (Object Management Group) im
Jahr 2000 als neues Softwareentwicklungs-Paradigma vorgestellt. Die MDA spezifiziert die
Richtlinien für die Ausführung des modellgetriebenen Prozesses. Die OMG hat eine Reihe
von Standards veröffentlicht, welche die Umsetzung des modellgetriebenen Vorgehens vorantreiben
sollen. Zu diesen Standards gehören unter anderem die UML (Unified Modeling
Language), die MOF(Meta Object Facility), die OCL (Object Constraint Language), das
XMI (XML Metadata Interchange) und die QVT (Query Views Transformations). Über diese
wird in dem Kapitel 2.3 ein Überblick verschafft.
Die MDA verfolgt das Ziel, die Spezifikation von Software-Systemen unabhängig von ihrer
technischen Realisierung zu ermöglichen. Damit wird die Komplexität bestehender Entwicklungstechnologien
verborgen und eine weitgehend plattformunabhängige Modellierung
erzielt. Der Fokus wird somit auf die Fachlichkeit gelegt. Als Basismodellierungssprache wird
die UML eingesetzt. Die MDA definiert verschiedene Abstraktionsebenen auf denen Modelle
spezifiziert werden können. Genaue Erläuterungen zu diesem Thema sind im Kapitel 2.2.3
zu finden.
Der Grundgedanke der MDA besteht darin, den Fokus von der Implementierung auf die
Modellierung zu verlegen. Dabei soll die Überführung der Modelle von abstrakten zu plattformabhängigen
Modellen, automatisiert unter dem Einsatz von Modelltransformationen
verlaufen. Somit kann das MDA-Entwicklungsprozess aus mehreren Iterationen bestehen,
wobei bei jeder Iteration eine Modellierungsaktivität von Transformationen gefolgt wird.
Ein weiterer Grundgedanke befasst sich mit der Unterstützung von Domain Specific Languages
(DSL). Laut Gruhn, Pieper und Röttgers wird unter dem Begriff Domäne in diesem
Zusammenhang in dem Buch [10] ganz allgemein ein Wissensbereich bzw. ein Problemraum
verstanden. Somit stellt die DSL ein weiteres Konzept zur Vereinfachung komplexer Sachverhalte
dar. Als Beispiel für eine graphische DSL dient die Entity-Relationship Modell für
die Darstellung eines Datenbankschemas für die Domäne der Datenbankrepräsentation dar.
So legt die MDA die Richtlinien für die Erstellung eigener Modellierungssprachen fest, die
auf eine Domäne zugeschnitten sind.[10]
Im nächsten Kapitel werden die Ziele der MDA erläutert.
2.2.1. Ziele der MDA
Modellgetriebene Entwicklung verfolgt folgende Ziele:[10] [20]
6
• Die Effizienzsteigerung und die Reduzierung des Entwicklungsaufwands:
– Durch Abstraktion
– Durch Automatisierung der Vorgänge mithilfe Werkzeugunterstützung
– Durch Wiederverwendung (Patterns, DSL)
• Die Systemintegration und die Interoperabilität:

2.2. Model Driven Architecture (MDA)
– Durch die Trennung der Fachlichkeit und der Technologie wird die Identifizierung
der Schnittstellen vereinfacht und somit die Austauschbarkeit und die Wiederverwendbarkeit
der Komponenten und so die Modularität der Anwendungen
gewährleistet
• Qualitätsverbesserung:
– Durch den Einsatz der formalen Modelle und Transformationen
– Durch eine wohl definierte Architektur
– Durch die Trennung der Fachlichkeit von den technischen Details
– Durch die Konservierung der Fachlichkeit und des Expertenwissens in Modellen
• Portabilität:
– Durch eine einfache Migration auf neue Technologien unter Verwendung passenden
Transformationen aus dem PIM (Computational Independent Model) in das
PSM (Platform Independent Model), wobei die Fachlichkeit erhalten bleibt
• Domänen-Orientierung
– Durch die Spezifikationen einer DSL lassen sich Zusammenhalte schneller beschreiben
– Durch den hohen Grad der Formalisierung
– Durch das hohe Abstraktionsniveaus und eindeutige Semantik
– Durch die Wiederverwendung der erstellten domänenspezifischen Modellen
Im Weiteren werden die Begriffe der MDA eingeführt.
2.2.2. Metamodell der Grundbegriffe der MDA
In diesem Kapitel werden die Grunddefinitionen des MDAs dargestellt, die aus dem Buch von
Gruhn, Pieper und Röttgers[10] zitiert werden nach einem Abgleich mit den Definitionen auf
der OMG-Webpräsenz[17]. Die Metamodell der Grundbegriffe der MDA ist in der Abbildung
2.1 zu sehen:
Im Weiteren werden die Definitionen der OMG aufgelistet, wobei auf die Interpretation der
Definitionen laut [10] weitgehend verzichtet wird.
Definition 3. System
” Ein System ist ein aus Teilen zusammengesetztes und strukturiertes Ganzes.
Es hat eine Funktion, erfüllt einen Zweck und verfügt über eine Architektur.“[10]
Definition 4. Model
” Ein Modell beschreibt oder spezifiziert ein System zu einem bestimmten
7

2. Grundlagen und verwendeten Technologien
Abbildung 2.1.: Metamodell der Grunddefinitionen der MDA [10]
Zweck. Dazu erfasst es alle hierfür relevanten Aspekte, etwa Struktur, Verhalten,
Funktion und die Umwelt des Systems.“[10]
Definition 5. Metamodell
” Ein Metamodell ist die Menge von Elementen mit denen Modelle, die Instanzen
dieses Metamodells sind, erstellt werden können. Es enthält die Regeln,
die bei der Erstellung des Modells beachtet werden müssen (abstrakte
Syntax) sowie die Bedeutung der Elemente und Elementkonstellationen (Semantik).“[10]
Definition 6. Profile
” Ein Profil ist eine leichtgewichtige Erweiterung eines Metamodells. Dazu
stellt es neue Modellelemente zur Verfügung oder redefiniert bzw. erweitert die
Semantik oder Syntax bereits bestehender Elemente. Im Gegensatz zur Definition
völlig neuer Metamodelle (schwergewichtiger Ansatz) können sie die Bedingungen,
die an Elemente der Modelle gestellt werden, nur verschärfen.“[10]
8

2.2. Model Driven Architecture (MDA)
Definition 7. Domain
” Unter dem Begriff Domäne versteht man ein abgrenzbares, kohärentes Wissensgebiet.
In einem Metamodell (respektive in einem Profil) werden die Konzepte
einer Domäne in Bezug gesetzt und beschrieben. Zusammen mit ihrem
sprachdefinierenden Charakter bezeichnet man Metamodell und Profil daher
als Domänenspezifische Sprache (engl. Domain-Specific Language, DSL).“[10]
Definition 8. Application
” Eine Anwendung oder Applikation (engl. Application) ist ein zu erstellendes
Stück Software, welches die zu entwickelnde Funktionalität umfasst. Ein
System kann sich aus einer oder mehreren Anwendung(en) zusammensetzen,
die auf einer oder mehreren Plattform(en) ausgeführt werden.“[10]
Definition 9. Plattform
” Eine Plattform ist eine Ausführungsumgebung für eine Anwendung. Ihre
Funktionalität stellt sie durch zweckmäßige Schnittstellen bereit, auf die die
Anwendung ohne Kenntnis der eigentlichen Implementierung zugreifen kann.
Typische Beispiele für Plattformen sind im Bereich Betriebssysteme (Unix,
Windows), Programmiersprachen (C++, Java) und Middleware (CORBA,
Java EE, .NET) zu finden. Typisch für Plattformen ist auch, dass sie oft in
der Art eines Plattform-Stacks (dt. in etwa Plattform Stapel) aufeinander
aufsetzen. So bildet die Hardware eines Computers die unterliegende Plattform
für das Betriebssystem, das seinerseits wieder Plattform für die einzelnen
Anwendungen bietet usw.“[10]
Definition 10. Transformation
” Eine Transformation (oder genauer Modell-Transformation) ist der Prozess
der Umwandlung eines Modells in ein anderes Modell des gleichen Systems.
Die Spezifikation für eine solche Transformation ist in Abbildungsregeln
(engl. Mapping Rules) festgehalten, die in einer Abbildung (engl. Mapping)
gebündelt sind.“[10]
Im weiteren Verlauf dieser Arbeit werden die oben genannten Begriffe stets im Sinne dieser
Definitionen verwendet. Folgend werden die Abstraktionsebenen, auf denen sich Modelle der
MDA befinden können, beschrieben.
2.2.3. Durch MDA spezifizierte Modelle
Die MDA spezifiziert folgende Abstraktion für Modelle. Die Abstraktion beinhaltet drei Ebenen
in denen sich die Beschreibung des Models mit jeder weiteren Stufe mehr konkretisiert
und verfeinert wird.
9

2. Grundlagen und verwendeten Technologien
In der ersten Ebene des CIMs (Computation Independent Model) enthält das Modell die Beschreibung
der fachlichen Anforderungen mit Begriffen und Konzepten seiner Domäne(womöglich
unter dem Einsatz einer DSL). Wobei das Modell unabhängig von Plattform und Programmiersprache
ist.
Auf der nächsten Ebene namens PIM (Platform Independent Model) beschreiben die Modelle
die Fachlichkeit, also die Struktur und die Funktionalität der Anwendung. Diese Modelle
sind unabhängig von implementierungstechnischen Details.
Schließlich wird auf der dritten Abstraktionsebene das Modell mit allen technischen und
implementierungsrelevanten Details angereichert und enthält somit eine plattformspezifische
Umsetzung des PIMs. Hierbei ist zu erwähnen, dass die plattformunabhängigen Modelle die
Grundlage für den MDA-Ansatz darstellen. Im Rahmen des Entwicklungsprozesses werden
die in Modellen beschriebenen Gegebenheiten mithilfe von Transformationen aus einer Abstraktionsebene,
in die Modelle einer anderen Abstraktionsebene überführt. Die OMG hat
hierfür einen weiteren Standard namens ” Queries Views Transformations“ (QVT) veröffentlicht.
[10] [20] [23]
Im folgenden Kapitel werden die von der OMG veröffentlichten Standards näher betrachtet.
2.3. Die Modellierung
Das Ziel dieses Abschnitts ist, einen Einblick in die Modellierungsaspekte bei der modellgetriebenen
Entwicklung zu gewähren und die aktuellen Standards zur Spezifikation der
Modellen, die eine wichtige Rolle im Zusammenhang mit MDA spielen, zu erläutern. Nach
einer Beschreibung der Unified Modeling Language wird die Meta Object Facility der OMG
Group vorgestellt. Anschließend wird die Object Constraint Language beschrieben.
2.3.1. Die Unified Modeling Language (UML). UML Profile
Die Modellierungssprache UML(Unified Modeling Language) zum graphischen Entwurf von
Software hat seit ihrer Erscheinung im Jahr 1997 kontinuierlich an Bedeutung im Bereich
des Objektorientierten Engineerings gewonnen. Martin Fowler äußert sich in seinem Buch
” UML Konzentriert“[9] folgendermaßen dazu aus: UML hat die babylonische Sprachverwir-
”
rung der früheren Notationen aufgelöst“.
Die UML wird unter allen graphischen Notationen de facto eingesetzt, und stellt somit
eine Vereinigung der ” best practices“ und sogar ein Standard in der Softwareentwicklung
dar.[9] Es ist anzumerken, dass in diesem Zusammenhang unter Standard keine Normierung
und Standardisierung wie z.B. ISO gemeint sind. Der Standard ist als die Veröffentlichung
einer Spezifikation durch die Object Management Group (OMG) zu verstehen.
Außerdem repräsentiert die UML die Basismodellierungssprache des MDA. Auf der Web-
Präsenz der OMG findet man eine Sammlung von UML-Spezifikationen namens UML-Stack.
10

2.3. Die Modellierung
Daraus kann man fünf Hauptelemente der UML erkennen.[10] Die fundamentalen Sprachkonstrukte
des UML sind in der Infrastructure Library zusammengefasst, die ein Teil der
UML-Infrastructure bildet. Die UML-Infrastructure legt die Architekturgrundlage der UML-
Spezifikation dar und liefert außerdem ein Meta-Metamodell für die UML-Superstructure.[11]
Alle Metamodelle sind unter dem Einsatz vom MOF (Meta Object Facility) definiert, mehr
zu dem MOF im folgenden Kapitel.
Das UML-Metamodell enthält keine Informationen über die grafische Notation der UML,
sondern definiert nur die logischen, strukturellen Zusammenhänge der UML-Sprachelemente.
Zum Austausch der Metamodelle ist das XMI-Format (XML Metadata Interchange) bereitgestellt.
Die textuelle, auf der mathematischen Grundlage aufbauende Sprache OCL (Object
Constraint Language) erlaubt die Formulierung von Bedingungen und somit die Validierung
der UML-Modelle.
Einer der gewichtigsten Vorteile der UML liegt in ihrer Fähigkeit der Erweiterbarkeit. Die
Spezifikation der UML bietet im Grunde keine Möglichkeit alle fachlichen technischen Problemdomänen
adäquat abzubilden. Unter einer Domäne wird in diesem Zusammenhang ganz
generell ein Wissens- bzw. Fachgebiet verstanden. Um eine Modellierungssprache für besondere
Fachgebiete in Form einer DSL (Domain Specific Language) zu erweitern, müssen die
nötigen Erweiterungsmerkmale bestimmt werden, die durch die Modellierungssprache spezifizierbar
sein sollen.
Die Beschreibung neuer oder erweiterter Modellierungssprachen wird durch den Einsatz
von UML-Profilen ermöglicht. Das UML-Profil stellt eine Menge der identifizierten Erweiterungsmerkmale
dar, deren Beschaffenheit durch UML-Infrastructure exakt vorgegeben ist.
Für die Definition von einem UML-Profil sind folgende drei Konstrukte ausschlaggebend: die
Stereotypen, die Tagged Values und die Bedingungen (Constraints). Die Stereotypen legen
die Bedeutung eines Modellierungselements fest. Die Tagged Values spezialisieren bestimmte
Attribute eines Modellierungselements. Mithilfe der Constraints können spezielle Bedingungen
zur Begrenzung der Instanzen eines Metamodells definiert werden.[20]
Weiterer wichtiger Vorteil ist die Möglichkeit Metamodelle mithilfe von der UML zu entwickeln.
Solche Möglichkeit bietet die Meta Object Facility (MOF), die im weiteren betrachtet
wird.
2.3.2. Die Meta Modellierung und die Meta Object Facility (MOF)
Die OMG hat im Rahmen der Meta Object Facility (MOF)[18] eine Konzeption zur Beschreibung
der Metamodelle für andere Modellierungssprachen entworfen. Die Metamodelle
werden auf der Basis von den UML-Klassendiagrammen definiert. Die Modellierungssprachen,
die auf diesem Weg definiert worden sind, werden als formale Modellierungssprachen
oder auch als MOF-Sprachen im Rahmen dieser Arbeit bezeichnen.
Die MOF definiert eine Metamodellhierarchie mit vier Metalevels M0-M3, wobei dem Level
M3 die MOF selbst zugeordnet ist. Hier wird die MOF als das Urmodell bezeichnet. Alle
anderen Modelle basieren auf der MOF und sind somit den darunter liegenden Levels zuge-
11

2. Grundlagen und verwendeten Technologien
Metalevel Name Beispiel
M3 Urmodell MOF
M2 Metamodelle UML Superstructure, OCL
M1 Modelle Klassendiagramm
M0 Systeme Website
Tabelle 2.1.: Tabelle. Die Metalevels nach der MOF [10]
ordnet. Mithilfe der MOF-Konzepte werden die Metamodelle für die Modellierungssprachen
entworfen, die ihren Platz auf dem Metalevel M2 einnehmen. Als Beispiel hierfür werden
die OCL und die auf der MOF basierende UML-Superstructure, die alle Diagrammarten der
UML festlegt, angegeben. Die Instanzen der definierten Metamodelle und somit die Modelle
selbst werden dem Metalevel M1 zugeordnet. Letztendlich gehören die Anwendungen und die
reelle Tatsachen, die mithilfe der Modelle beschrieben werden, zum Metalevel M0. Über dem
M3 Level sind keine Levels mehr definiert worden. Die MOF ist selbstbeschreibend definiert.
Hiermit sind bei der MOF-Definition die Konstrukte verwendet worden, die die MOF selber
definiert.[10]
Die MOF 2 ist in zwei Bestandteile aufgeteilt: das Essential MOF Model (EMOF) und das
Complete MOF Model (CMOF). Die EMOF beinhaltet die Basisfunktionalität von der MOF
und somit eine Untermenge davon, die die Definition einfacher Metamodelle zur Verfügung
stellt. Die komplette CMOF enthält die Definition aller anderen Metamodelle des UML-
Stacks wie die UML-Superstructure, sowie die EMOF und somit die gesamte Funktionalität
der Meta Object Facility.[10]
Die Tool-Interoperabilität wird mit dem XMI Format (XML Metadata Interchange) ermöglicht.
Dieses Format kann als Mapping der MOF-Strukturen auf eXtensible Markup Language
(XML) aufgefasst werden. Das XMI wird oft bei den Transformationswerkzeugen als
Input- und Output-Format für Modelle gefordert.
Im nächten Kapitel wird ein weiterer Standard der OMG vorgestellt.
2.3.3. Die Object Constraint Language (OCL)
Die Object Constraint Language (OCL) ist eine formale Sprache, mit der die Bedingungen
in Form von Constraints für Modelle definiert werden können. Die OCL bietet als textuelle
Ergänzung zu graphischen Diagrammen eine Möglichkeit die Bedingungen mit den Modellelementen
zu verknüpfen. Hiermit kann z.B. der gültige Wertebereich für eine Variable oder
eine Invariante für eine Klasse, die zu jederzeit gelten soll, definiert werden. Darüber hinaus
kann unter Verwendung der OCL-Bedingungen das Vorhandensein bestimmter Modellelemente
geprüft werden oder eine Vorbedingung für die Ausführung einer Operation definiert
werden.
12

2.4. Die Query View Transformations (QVT)
Die OCL ist eine streng typisierte Sprache, was die Auswertung der OCL-Syntax zur Modellierungszeit
ermöglicht. Die mathematischen Konzepte der Mengenlehre und der Prädikatenlogik
liegen der OCL-Sprache zugrunde. Für die mathematischen Symbole wird eine
formal textuelle Notation verwendet. Hierbei hat die OCL einen deklarativen Charakter.
Dies bedeutet, dass unter Verwendung von der OCL die Bedingungen erfasst werden, die für
ein Modell erfüllt sein sollen und somit diese als gültig bewertet wird. Es kann jedoch mit
Hilfe von OCL-Bedingungen nicht festgelegt werden wie ein Modell den gültigen Zustand
erlangt.
Die Verwendung der OCL-Sprache erlaubt dem Modellierer eine hohe Präzision der Anwendungsbeschreibung
zu erreichen, wobei hoher Abstraktionsgrad bewahrt wird. Die Modellvalidierung
ist nahezu unvorstellbar ohne den Einsatz von so einer mächtigen Sprache
wie die OCL. Einige Transformationssprachen wie z.B. die relationale QVT-Sprache basieren
auf die OCL. Die von der OMG spezifizierte QVT (Query Views Transformations) wird im
nächsten Abschnitt vorgestellt.
2.4. Die Query View Transformations (QVT)
Die QVT ist ein von der OMG veröffentlichter Standard zur Durchführung von Modelltransformationen.
Die QVT umfasst drei unterschiedlichen Transformationssprachen. Die
imperative Sprache QVT Operational Mappings (QVT Operational) und die deklarativen
Sprachen QVT Relations und QVT Core.[23]
Transformationen können unidirektional oder bidirektional sein. Dabei sind die deskriptiven
Sprachen bidirektional und die imperative Sprache unidirektional. QVT unterscheidet
zwischen zwei Konzepten für die Transformationen: der Model-To-Model-Transformation
und der Model-To-Text Transformation. Mit einer Model-To-Text-Transformation kann eine
Code-Generierung erfolgen.
2.5. Das Eclipse Modeling Framework (EMF)
Das Eclipse Modeling Framework(EMF) ist ein Modellierungsframework, der die Erstellung
von eigenen Modellierungssprachen erlaubt. Das EMF ist als eine Sammlung der Eclipse-
Plug-ins konzipiert und benutzt ein eigenes Meta-Metamodell namens Ecore. In der Version
2.0 kann das Ecore als Implementierung von EMOF betrachtet werden. Die Ecore-repräsentierte
Metamodelle sind zum EMOF Format (siehe Kapitel 2.3.2) weitgehend äquivalent. Die
Abbildung des Ecore auf das XMI ist der Abbildung des EMOFs auf das XMI sehr ähnlich.
Der Unterschied bei Mappings auf das XMI ist zum Beispiel, dass die Namen der Bezeichner
in Ecore Format mit E beginnen. Für einen Bezeichner Class steht z.B. EClass usw.
Die Ecore-XMI Repräsentation lässt sich bei Bedarf unter Verwendung der EMF Werkzeuge
einfach in das EMOF-Format überführen.[10][20]
13

2. Grundlagen und verwendeten Technologien
2.5.1. Metamodellierung mit Ecore Tools
Die Erstellung von Metamodellen ermöglicht eine EMF Komponente, die Ecore Tools genannt
wird. Sie stellt die Ecore-Modell-Editoren, die Ecore-Diagramm-Editoren zur Modellierung
der Metamodelle sowie das EMF Generator Template zur Verfügung. Das EMF
Generator Template dient zur automatischen Generierung von Eclipse-Plug-ins, die die Editoren
für die Erstellung und die Bearbeitung der Instanzen dieser Metamodelle erlauben.
Wird das Ecore-Metamodell für eigene Modellierungssprachen definiert, so kann aus diesem
Ecore-Metamodell ein Generator-Modell für die Eclipse-Plug-ins generiert werden. Diese
Plug-ins stellen Editoren bereit, welche die Modellierung auf der eigenen Modellierungssprache
ermöglichen. Für die Ausführung von den Modell-Transformationen sollen oft die
Metamodelle mit angegeben werden. Im Rahmen dieser Arbeit wurden für die Transformation
benötigten Metamodelle in dem Ecore-Format definiert. Aus den Metamodellen wurden
die Eclipse-Plug-ins generiert, welche die Editoren für die Erstellung der Metamodellinstanzen
liefern. Die genaue Vorgehensweise dafür wird im Rahmen dieser Arbeit vorgestellt (siehe
Anhang A). Darüber hinaus soll angemerkt werden, dass die Definition der Metamodelle für
eigene Modellierungssprachen eine schwergewichtige UML-Erweiterung mit sich bringt. Eine
elegantere Alternative bietet der Einsatz eines UML-Profils.[23]
2.5.2. Die Eclipse UML2
Wie oben bereits erwähnt, verabschiedet OMG einen Standard dadurch, dass die Spezifikation
dieses Standards veröffentlicht wird. Die konkreten Implementierungen des UML2-
Metamodells werden von verschiedenen Open-Source- oder kommerziellen Tool-Herstellern
entwickelt. Hierbei wurden unterschiedliche UML-2 Metamodell-Implementierungen um kleinere
Tool-spezifische Inhalte erweitert. Somit unterscheiden sich diese Implementierungen
voneinander. Dies hat eine schlechte Interoperabilität zur Folge. Als weiterer Faktor für die
schlechte Interoperabilität zwischen verschiedenen Tools wäre eine ungenaue Spezifikation
des XMI in den frühen Versionen zu benennen. Im Rahmen des Eclipse-UML2-Projekts
wurde UML2-Metamodell unter Verwendung des Ecore-Formats spezifiziert und unter der
Eclipse Public License (EPL) veröffentlicht. Somit können alle Modellierungs- bzw. Transformationstools
innerhalb der Eclipse ein einheitliches Metamodell verwenden. Ein standardisierter
XMI-Export ist ebenfalls angeboten.[23][10]
2.6. Die UWE Methodologie
Die UML-based Web Engineering-Methodologie ist ein modellgetriebener Ansatz für die
Entwicklung von Rich Internet Applications. Das UWE setzt auf die Standards des Model
Driven Architecture und hat als Ziel ” Development Driven by Models“ durchzusetzen, wobei
an allen Entwicklungsphasen der Einsatz von Modelltransformationen zum maximalen Grad
der Automatisierung des Entwicklungsprozesses beitragen soll.[12]
14

2.6.1. UWE Metamodell und UWE Profil
2.6. Die UWE Methodologie
Das UWE-Metamodell ist als konservative Erweiterung des UML 2 Metamodells definiert.
Dies ermöglicht ein Mapping des UWE-Metamodells auf ein UML Profil. Die UWE-Methodologie
basiert auf einem UWE-Profil, der leichtgewichtigen UML Erweiterung, die eine Spezialisierung
für die Domäne der modernen Webentwicklung in Form einer domänenspezifischen
Sprache erstellt. Somit sind die UWE-Modelldiagramme als Modellierungssprache gut
verständlich. Das UWE nutzt XMI als Austauschformat und ist somit zu den Tools kompatibel,
die das XMI einsetzten.[14][12]
2.6.2. Die Separation of Concerns
UWE setzt auf die strikte Separation of Concerns. Die Webanwendung wird in den separaten
Modellen beschrieben. Im Laufe des UWE-Entwicklungsprozesses werden die Modelle
mithilfe Modelltransformationen ineinander überführt[14][12].
• Das Inhaltsmodell: In dem Inhaltsmodell werden die Inhalte der Webanwendung in
Form eines Klassendiagramms modelliert, die aus einer Anforderungsanalyse hervorgehen.
Das Ziel von dem Inhaltsmodell ist die visuelle Spezifikation der Domänenrelevanten
Informationen der Webanwendung.
• Das Navigationsmodell: Das Navigationsmodell spiegelt die Navigationsstruktur der
Webanwendung wider, wobei diese Struktur aus dem Inhaltsmodell und den Anforderungen
abgeleitet wird. Das Metamodell der Navigationsstruktur ist durch eine Anzahl
spezieller Stereotype erweitert. Navigationsklassen repräsentieren die Navigationsknoten
einer Webanwendung, die eine Business Logik enthalten sollen.
• Das Prozessmodell: Das Prozessmodell enthält die Spezifikation der Funktionalitäten
der Webanwendung, die basierend auf dem Inhaltsmodell und dem Navigationsmodell
veranschaulicht werden.
• Das Präsentationsmodell: Das Präsentationsmodell liefert eine abstrakte Sicht auf die
Struktur von Benutzeroberfläche einer RIA. Es basiert auf dem Navigationsmodell.
Der Vorteil von dem Präsentationsmodell ist, dass das Modell unabhängig von den
Darstellungstechniken ist, welche für die Webanwendungsimplementierung eingesetzt
werden können. Basiselemente der Repräsentationsmodelle sind Präsentationsklassen,
die direkt auf den Knoten aus dem Navigationsmodell basieren.
2.6.3. MagicUWE - UWE Plug-in für MagicDraw
MagicUWE 1 ist ein MagicDraw-basiertes Plug-in, das eine Entwicklungsumgebung im Rahmen
der UWE-Methodologie bereitstellt. Magic UWE unterstützt die Modellierung von den
unterschiedlichen UWE-Modellen. Das MagicDraw vereint in sich die Integration des UWE-
Profils und einer benutzerfreundlichen Schnittstelle. Das Tool verfügt über eine Toolbar, in
der für alle UWE-Diagramme passende Elemente (Klassen, Properties usw.) zur Verfügung
stehen, womit eine bequeme Modellierung erfolgen kann. Es sind Modell-Transformationen
1 http://uwe.pst.ifi.lmu.de/toolMagicUWEReferenceV1.3.html
15

2. Grundlagen und verwendeten Technologien
in das MagicUWE integriert, deren Ausführung die Erstellung der Modelle vereinfachen. Das
MagicUWE-Plug-in für das UML-basiertes Tool MagicDraw lässt sich leicht erweitern und
verfügt über Konfigurations- und Anpassungsmöglichkeiten.
Nachdem die grundlegenden Begriffe für die modellgetriebenen Entwicklung von RIAs erläutert
wurden, wird im Folgenden die Modell-Evolution und Modell-Co-Evolution vorgestellt.
16

3. Die Modellevolution und die
Modell-Co-Evolution
In diesem Kapitel werden die Grundlagen der Thematik der Co-Evolution vorgestellt. Die
unterschiedlichen Modellierungsartefakte sind auf verschiedenen Wegen von dem Metamodell
bzw. deren Änderungen abhängig. Dabei wird zwischen folgenden Hauptarten der Co-
Evolution unterschieden: der Modell-Co-Evolution und der Transformationen-Co-Evolution.
Diese erfolgen in Form einer Anpassung existierender Model- bzw. Transformationsinstanzen
gemäß einer neuen Metamodell-Version.
Im Rahmen dieser Arbeit wird der Schwerpunkt auf die Modell-Co-Evolution gelegt. In
diesem Zusammenhang werden im Folgenden die unterschiedlichen Arten der Metamodell-
Modifikationen entsprechend der Typologie der benötigten Anpassungen kategorisiert. Diese
Anpassung der Modelle enthält Schritte, welche für die Eliminierung der durch Modellevolution
bedingten Differenzen benötigt werden. Für jeden solchen Typ wird der Automatisierungsgrad
dieser Änderungen diskutiert, da nicht bei allen solchen Änderungstypen die
Co-Evolution vollautomatisiert ablaufen kann. In solchen Fällen ist menschliche Eingriff unvermeidbar.
Im Bereich der Co-Evolution der restlichen Software-Artefakte wird momentan geforscht.
Es existieren bereits Ansätze zur Transformationen-Co-Evolution[16]. Auf die Co-Evolution
der Artefakte, die nicht Modelle oder Transformationen sind, wird im Rahmen dieser Arbeit
nicht weiter eingegangen. Zu solchen Artefakten gehören beispielsweise die Modell-Editoren,
die auf dem entsprechenden Metamodell basieren, die Dokumentation des Systems sowie die
Anforderungen an das System. Eine Publikation berichtet über Erfolge in der Umsetzung
einer Methodik für Co-Evolution von GMF-Editor[21]. Dieser Bereich der Co-Evolution ist
sehr neu und die Arten der betroffenen Artefakte sind sehr umfangsreich, was eine vollständig
automatisierte Migration der Gesamtmenge aller Software-Artefakte vermutlich unmöglich
macht. Nach der Modell-Co-Evolution und der Transformation-Co-Evolution bleiben immer
einige Artefakte vorhanden, welche manuell angepasst werden müssen.
Ein Versuch einen Ansatz zu erarbeiten, der die voll-automatisierte Modell-Co-Evolution
mit der Unterstützung von Transformationen ermöglicht, wirft eine Reihe von Problemen
auf. Im Folgenden werden diese Probleme erläutert und die Möglichkeiten diskutiert, diese
Ideen in die Realität umzusetzen. Anschließend wird die UWE-Methodologie unter die Lupe
genommen und zwei Versionen der UWE-Metamodelle miteinander verglichen. Letztendlich
wird die Co-Evolution Strategie für diese UWE Versionen aufgezeigt.
17

3. Die Modellevolution und die Modell-Co-Evolution
3.1. Was bringt die Modell-Evolution mit sich
Die Abhängigkeiten zwischen dem Metamodell und den unterschiedlichen im Entwicklungsprozess
beteiligten Software-Artefakten im Laufe des Metamodelllebenszyklus können zu
einem beliebigen Zeitpunkt entstehen. Zum Beispiel ist eine Modelltransformation, die als
Ausgangsmodell Model M1 hat und als Resultat ein Modell M2 liefert, von Metamodellen
von M1 und M2 abhängig. Ein graphisches oder textuelles Tool erlaubt es ein Modell zu
beschreiben, wobei das Tool mit dem Metamodell in Abhängigkeit steht. [7] [8]
Tool/Artefakt Beschreibung Abhängigkeit
bei der
Entwicklung
Graphische sowie
textuelle Editoren
Modell-zu-Modell-
Transformationen
Modell-zu-Text-
Transformationen
Graphische oder textuelle
Editoren, die Bearbeitung
und Erstellung der
Modelle unterstützen
Transformationen, die
aus einem Ausgangsmodell
Zielmodelle
generieren
Transformationen, die als
Ziel Textuelle Artefakte,
wie z.B. den Code aus
dem Ausgangsmodell generieren
Abhängigkeit
bei der
Evolution
Technologie
Schwach Stark GMF, MagicDraw,
Enterprise Architect,
Topcased
etc.
Stark Mittel ATL, QVT Operational,
QVT Relations,
VIATRA2 etc.
Schwach Schwach UWE4JSF, Acceleo
etc.
Tabelle 3.1.: Tabelle. Die Abhängigkeit zwischen dem Metamodell und den Softwareartefakten.
[8]
In der Tabelle 3.1 werden verschiedene Typen der Abhängigkeiten zwischen dem Metamodell
und den unterschiedlichen Artefakten unterschieden, die im Laufe der Entwicklung entstehen
können. Die Metamodelländerungen haben einen Einfluss auf existierende Software-
Artefakte im Sinne der Co-Evolution-Problematik. Die Artefakte müssen angepasst werden,
damit sie im Sinne der aktuellen Version des Metamodells wohldefiniert bleiben.
Das Metamodell kann sich auf unterschiedlichen Wegen entwickeln: einige Änderungen können
rein additiv sein und keinen Einfluss auf existierende Artefakte haben, wobei keine oder
nur ganz kleine Co-Evolution-Anpassungen benötigt werden. Allerdings können in manchen
Fällen Metamodell-Modifikationen Inkompatibilität und Inkonsistenzen mit sich bringen,
welche nicht einfach und nicht immer automatisiert behoben werden können.
3.1.1. Die Relationstypen zwischen dem Metamodell und den
Modellierungsartefakten
Die benötigten Co-Evolution-Adaptationsschritte hängen von dem Typ der Relation zwischen
dem Metamodell und dem betroffenem Artefakt ab.
Alfonso Pierantonio und Co. unterscheiden in [8] zwischen folgenden Relationstypen:
18

3.1. Was bringt die Modell-Evolution mit sich
Abbildung 3.1.: Eine Übersicht der Beziehungen zwischen einem Metamodell und den Softwareartefakten
[8]
• conformsTo: diese Relation verbindet Modelle mit ihren Metamodell. Ein Model ist zu
einem Metamodell konform, wenn dieses Modell jedes Konzept spezifiziert, das in der
Modelldefinition vorkommt. Dabei werden die Konzepte des Metamodells entsprechend
der Regeln benutzt, die im Metamodell spezifiziert sind;
• domainConformsTo: ist eine Relation zwischen der Definition einer Transformation
und der Definitionen der Metamodelle, auf denen diese Transformation operiert.
Zum Beispiel könnte eine Konformitätseinschränkung festlegen, dass die Elemente einer
Transformationsregel einer Metaklasse aus dem Quellmetamodell entsprechen müssen
und dasselbe für Zielelemente und entsprechendes Zielmetamodell gelten soll;
• dependsOn: ist die schwächste und meistens komplexeste Relation von allen. Diese
Relation besteht zwischen dem Metamodell und der Modellierungsartefakte, die keine
direkten und wohlgeformten vordefinierten Abhängigkeiten zu Metamodell-Elementen
besitzen. Zum Beispiel im Falle der GMF (Graphical Modeling Framework) Modelle referenzieren
einige von ihnen nicht direkt auf die im Metamodell angegebenen Elemente,
wenn auch eine Form der Konsistenz aufrechterhalten werden muss; 1
Der Fokus dieser Arbeit liegt auf der Problematik der Modell-Co-Evolution, weil die Modelle
die zentrale Bedeutung in der MDA einnehmen. Einzelne Lösungsvorschläge für Probleme
in der Modell-Co-Evolution und Transformationen-Co-Evolution existieren bereits. Es
existieren sogar Vorschläge für die Co-Evolution der Modellierungsartefakte, die mit dem
Metamodell dependsOn-Abhängigkeit besitzen, wie z.B. für den graphische GMF-Editor.
Leider sind diese Lösungen zum größten Teil unreif bzw. in einem Prototypen-Stadium oder
1 www.eclipse.org/gmf
19

3. Die Modellevolution und die Modell-Co-Evolution
basieren auf verschiedenen Standards und deren unterschiedlichen Versionen.
Es existiert noch kein Tool, indem eine umfassende, einheitliche und universelle Lösung
für Co-Evolution-Strategien für alle Typen der Artefakte vertreten ist. Der Kern der Co-
Evolution liegt aber bei der Modell-Co-Evolution. Auf die Modelle-Co-Evolution wird im
weiterem detailliert eingegangen.
3.2. Die Klassifizierung der Metamodelländerungen
Die Metamodelle können als grundlegendes Konzept des MDA betrachtet werden, da sie eine
formale Definition für die wohlgeformten Modelle bereitstellen. In anderen Worten bilden
Metamodelle die Grundlage für die Sprachen, durch deren Verwendung die Gegebenheiten
der Realität in einem abstrakten Sinne beschrieben werden. Durch die Weiterentwicklung
der Metamodelle, die im Laufe deren Lebenszyklus unausweichlich sind, stößt man auf die
Notwendigkeit das Problem der Versionskonflikte zu lösen. Die existierenden Modelle gehen
mit der älteren Metamodell konform, aber nicht mit dem neuen Metamodell. Diese Konformitätsrelation
ist vom Typ conformsTo (3.1.1) und damit abgebrochen. Dabei geht die
Validität des Modells verloren. Dieses Problem entsteht durch Inkompatibilität zwischen
den Versionen des Metamodells und kann durch Anpassungsmechanismus der Modell-Co-
Evolution gelöst werden. Somit kann die conformsTo-Relation (3.1.1) zwischen dem neuen
Metamodell und entsprechenden angepassten Modellinstanzen aufrechterhalten bleiben. Die
Modelle können zu neuen Instanzen entsprechend der vorgenommenen Metamodelländerungen
auf die neue Version migriert werden.
Leider ist Modell-Co-Evolution nicht immer einfach: abhängig von der Art der Metamodell-
Änderungen können sich Schwierigkeiten ergeben. Es ergeben sich unterschiedliche Arten von
Metamodelländerungen im Bezug auf die Auswirkungen, die diese Änderungen an existierenden
Modellen verursachen. Einige der Änderungen können rein additiv und unabhängig
von anderen Modell-Elementen sein und somit keinen Anpassungsbedarf an existierenden
Modellen verursachen.
Einige Metamodelländerungen bedingen den Verlust von Konformität der existierenden Modelle
zu dem neuen geänderten Metamodell. Diese Konformität kann dennoch mit einfachen
voll automatisierten Anpassungen der Modelle wiederhergestellt werden; in manchen Fällen
verursachen Metamodelländerungen Inkompatibilität und Inkonsistenz der Modelle, die auf
vollständig automatisiertem Wege nicht beseitigt werden können. Hier ist der menschliche
Eingriff unvermeidbar. Einige dieser Änderungen, lassen sich teilautomatisiert durchführen.
Eine Untermenge der Metamodelländerungen lässt eine Automatisierung der Anpassung der
existierenden Modelle nicht zu. Hier muss der Modellierer die Modelle manuell ändern. Dies
wird im nächsten Abschnitt weiter ausgeführt.
3.2.1. Illustratives Beispiel für Metamodell-Evolution
Im Folgenden wird ein Beispiel von Model-Evolution vorgeführt. Es wird ein vereinfachtes
Metamodell für die Modellierung von Petri-Netze vorgestellt. [7] Das Ausgangsmetamodell
20

3.2. Die Klassifizierung der Metamodelländerungen
der Petri-Netze MM0 besteht aus Plätzen (Place) und Transitionen (Transition), wie es in
der Abbildung 3.2 zu sehen ist.
Abbildung 3.2.: Das Petri-Netze-Metamodell MM0 [7]
Die Plätze können Eingangs- und Ausgangs-Transitionen besitzen. Die Transitionen verbinden
einen Platz entsprechend mit Eingangs- und Ausgangsplätze (src- und dst Assoziationen).
Aus diesem ganz vereinfachten Metamodell wird im nächsten Schritt ein neues Metamodell
erstellt. Im Metamodell MM1 im Bild 3.3 soll jedes Netz mindestens einen Platz
und eine Transition besitzen. Außerdem werden gerichtete Kanten zwischen den Plätzen
und Transitionen explizit durch die Einführung von PTArc (Place-Transition Arc) und
TPArc(Transition-Place Arc) Metaklassen definiert. [7]
Abbildung 3.3.: Das Petri-Netze-Metamodell MM1 [7]
Diese Verfeinerung erlaubt es, weitere Eigenschaften zu den Beziehungen zwischen den
Plätzen und den Transitionen hinzuzufügen. Z.B. kann der Petri-Netze Formalismus jetzt
mittels dieser Verfeinerung durch die Annotation der gerichteten Kanten mit Gewicht erweitert
werden. Aufgrund der Tatsache, dass die beiden Klassen PTArc sowie TPArc gerichtete
Kanten repräsentieren, können diese durch Hinzunahme einer Superklasse generalisiert werden.
Wobei die neue Eigenschaft ” Gewicht“ in diese Metasuperklasse als Metaattribute vom
Typ Integer hinzugenommen werden kann. Siehe Bild 3.4. Diese Änderung wird im Metamodell
MM2 mit aufgenommen. Letztendlich wird die Metaklasse Net in PetriNet umbenannt.
[7]
Die Versionen MM1 und MM2 des Petri-Netze Metamodells, die davor vorgestellt wurden,
können zu Ungültigkeit der bestehenden Modellinstanzen nach der Migration auf eine
neuere Version führen. Anhand der Änderungstypen soll eine Analyse dieser Versionen in
Bezug auf die Auswirkung der Änderung auf die existierende Modelle erfolgen. Anschlie-
21

3. Die Modellevolution und die Modell-Co-Evolution
ßend werden Überlegungen über notwendigen Adaptationsschritte vorgenommen, die an den
existierenden Modellen durchgeführt werden sollen, um Konformität mit dem neuen Metamodell
wiederherzustellen. Die Änderungen eines Metamodells können anhand korrupten
oder non-korrupten Effekte auf die existierenden Modelle klassifiziert werden [7]:
• ” non-breaking changes“: Die Änderungen an einem Metamodell, die bewirken, dass
existierende Modelle mit der durch diese Änderungen entstandenen neuen Version des
Metamodells ohne jegliche Anpassungen konform gehen.
• ” breaking and resolvable changes“: Die Konformität der existierenden Modelle zu
dem geändertem Metamodell bleibt nicht erhalten und kann mithilfe vollautomatisierter
Co-Evolution wiederhergestellt werden.
Abbildung 3.4.: Das Petri-Netze-Metamodell MM2 [7]
• ” breaking and unresolvable changes“: Die Konformität der existierenden Modelle
der neuen Version des Metamodells bleibt nicht erhalten und kann nicht automatisiert
wiederhergestellt werden. Menschlicher Eingriff ist unerlässlich.
Das obere Beispiel zeigt, dass das Einfügen einer abstrakten Metaklasse Arc als Generalisierung
der Metaklassen PTArc und TPArc (ohne Hinzunahme des Attributes weight) zu der
Kategorie der ” non-breaking changes“ gehört. Nach einer solchen Änderung sind existierende
Modelle, die mit dem MM1 Metamodell konform gehen, auch zu dem MM2 Metamodell
konform. Die Co-Evolution-Aktivitäten sind an dieser Stelle nicht nötig.
Die Hinzunahme der neuen Metaklassen PTArc und TPArc zu dem Metamodell MM0 bewirkt,
dass die existierenden Modelle zu dem neuen MM1 Metamodell nicht mehr konform
bleiben. Die Platz- und Transition-Instanz können dann nicht mehr direkt miteinander verbunden
werden, da die PTArc- und TPArc- Elemente gemäß dem neuen Metamodell dafür
eingesetzt werden sollen. Die Modelle können automatisiert in die neue Metamodellversion
überführt werden, indem für jedes Platz-Transition Paar zwei zusätzliche PTArc- und
TPArc-Instanzen hinzugefügt werden. Diese Metamodelländerung teilt man somit in die
Kategorie ” breaking and resolvable changes“ ein.
Oft führen die Metamodelländerungen zu Inkonsistenzen in den Modellen, die ohne menschlichen
Eingriff nicht beseitigt werden können. Ein Beispiel dafür wäre die Hinzunahme eines
22

3.2. Die Klassifizierung der Metamodelländerungen
neuen Attributs in die Metaklasse Arc des MM2 Modells, das zuvor im MM1 Metamodell
nicht vorkam. Die Modelle, die mit dem MM1 Metamodell konform gehen, können nicht automatisiert
auf die MM2 Version überführt werden, ohne dass Konformität eingebüßt wird.
Nur ein Modellierer kann die fehlende Information, die in diesem Fall die Gewichtung des
Pfeils betrifft, in die existierenden Modelle einfügen. Dies ist ein Beispiel für die ” breaking
and unresolvable changes“. Eine Abhilfe könnte die Definition eines Default-Wertes für dieses
Attribut sein. Dadurch wäre die Co-Evolution automatisierbar und würde der Kategorie
der ” breaking and unresolvable changes“ angehören.
3.2.2. Die additiven Änderungen eines Metamodells
Alle Szenarien der Modell-Co-Evolution können entsprechend der Metamodellmodifikationen
behandelt werden. Bei diesen Metamodellmodifikationen wird zwischen der additiven (engl.
additive), subtraktiven (engl. subtraktive) und ändernden (engl. updative) Modifikation unterschieden.
Mit additiven Änderungen werden folgende Additionen zu dem Metamodell
gemeint[7][24]:
• Das Einfügen einer Metaklasse: Eine neue Metaklasse wird dem Metamodell hinzugefügt.
Dies hat keinerlei Auswirkung auf die restlichen Klassen des Modells, ebenso
wenn die neue Metaklasse abstrakt ist. Als Vorbedingung muss gelten, dass die neu
hinzukommende Metaklasse in dem Metamodell nicht bereits enthalten ist. Somit wird
die Unterscheidung der Klassen gewährleistet und das Vorhandensein von Duplikaten
ausgeschlossen. Das Einfügen neuer Metaklassen bringt das Thema Co-Evolution nur
dann auf, wenn die neue Metaklasse zwingend erforderlich (obligatorisch) ist. Nur der
Modellierer kann die neuen Instanzen dieser Metaklasse in die existierenden Modelle
einfügen.
• Das Einfügen einer Meta-Eigenschaft: Dies ist dem Einfügen einer Metaklasse
ähnlich. Im Falle einer nicht obligatorischen Eigenschaft ist keine Co-Evolution-
Aktivität notwendig. Die neue Eigenschaft kann mit der Berücksichtigung einer bestimmten
Kardinalität obligatorisch sein. In diesem Fall ist die Modell-Co-Evolution
nicht ohne menschliche Interaktion möglich. Besondere Aufmerksamkeit ist im Falle
der Vererbung gefragt. Die Konformität bleibt erhalten, wenn die neue Eigenschaft in
eine abstrakte Metaklasse, die keine nicht-abstrakte Subklassen besitzt, eingefügt wird.
Ist die Metaklasse nicht abstrakt, so sind sowohl die Metaklasse selbst als auch alle
ihre Subklassen betroffen. Das Eingreifen des Menschen ist dann wiederum unabdingbar,
um den Wert der eingefügten obligatorischen Metaeigenschaft in allen betroffenen
Modellelementen zu setzen. Legt man einen Default-Wert für die Eigenschaft fest, so
lässt sich die Co-Evolution automatisieren.
• Die Generalisierung einer Meta-Eigenschaft: Eine Meta-Eigenschaft ist generalisiert,
wenn ihr Typ oder ihre Kardinalität geschwächt wird. Zum Beispiel, wenn die
Kardinalität einer Metaklasse von 3..n auf 0..n geändert wird. Es ist in diesem Fall
keine Co-Evolution-Aktion an den betroffenen Klassen der existierenden Modelle erforderlich.
Die Instanzen dieser Metaklasse bleiben konform zu der neuen Version des
Metamodells.
• Das Verlagern einer Meta-Eigenschaft einer Metaklasse zu ihrer Superklas-
23

3. Die Modellevolution und die Modell-Co-Evolution
se (engl. pull metaproperty): Eine Meta-Eigenschaft wird aus einer Subklasse B
zu ihrer Superklasse A verschoben. Sie wird in der Metaklasse B gelöscht und zu der
Metaklasse A eingefügt. Ist diese Eigenschaft nicht obligatorisch, so muss keine Modell-
Co-Evolution-Aktion ausgeführt werden. Andernfalls müssen als Resultat Instanzen
der Metaklasse A und deren Subklassen modifiziert werden. Weil diese Klassen diese
Meta-Eigenschaft erben. Die Instanzen der Klasse B müssen nicht modifiziert werden,
da sie diese Eigenschaft bereits besitzen.
• Das Extrahieren einer Superklasse: Eine Anzahl von Eigenschaften, die für einer
bestimmten Menge von Klassen gemeinsam ist, wird in eine neue Superklasse in einer
Hierarchie extrahiert. Die gemeinsamen Eigenschaften werden in diese Superklasse
verschoben. Ist die Superklasse abstrakt, so ist keine Co-Evolution notwendig. Sonst
können die Änderungseffekte auf den Fall des Verlagerns einer Meta-Eigenschaft einer
Metaklasse zu ihrer Superklasse (engl. pull metaproperty) zurückgeführt werden.
3.2.3. Die subtraktiven Änderungen eines Metamodells
Die subtraktiven Änderungen beziehen sich auf das Löschen einiger Metamodellelemente
und unterteilen sich in folgende Typen[7][24]:
24
• Das Löschen einer Metaklasse: Eine Metaklasse wird aus einem Metamodell gelöscht,
um einem Sub-Metamodell Platz zu machen. In diesem Fall induziert eine solche Änderung
normalerweise das Löschen aller Instanzen dieser Metaklasse. Wenn diese Klasse
Subklassen hatte oder Referenzen zu den anderen Metaklassen besessen hat, sind die
dadurch verursachten Seiteneffekte auch an diesen referenzierten Instanzen zu berücksichtigen.
• Das Löschen einer Meta-Eigenschaft: Effekte sind analog zu denen, wie beim
Löschen einer Metaklasse.
• Die Verlegung einer Meta-Eigenschaft in eine Subklasse (push metaproperty):
Ein Umzug einer Eigenschaft von einer Superklasse A zu ihren Subklassen bedeutet,
dass diese Eigenschaft in der ursprünglichen Superklasse A gelöscht wird, um dann
in allen Subklassen von A übernommen zu werden. Ist die Superklasse A abstrakt, so ist
keine Modell-Co-Adaptation erforderlich. Andernfalls müssen alle Instanzen der Klasse
A entsprechend modifiziert werden. Ist die Eigenschaft obligatorisch, so muss ihr Wert
in allen betroffenen Klassen manuell gesetzt werden. Alternativ ermöglicht die Definition
eines Default-Values ähnlich wie bei dem Fall des Einfügens einer Meta-Eigenschaft
die Automatisierung für dieses Vorgehen.
• Das Abflachen der Hierarchie (engl. flatten hierarchy): Das Abflachen einer
Hierarchie bedeutet die Eliminierung einer Superklasse und Auslagerung aller Eigenschaften
in die Subklassen. Dieses Szenario ist im vorigem Fall der Verlegung einer
Meta-Eigenschaft in eine Subklasse (engl. push) abgedeckt.
• Die Einschränkung der Kardinalität oder des Typs einer Meta-Eigenschaft:
Eine Meta-Eigenschaft wird in diesem Zusammenhang durch die Einengung bzw. die
Verringerung deren Kardinalitätsbereichs oder deren Typbereichs eingeschränkt. Dies
ist ein komplexer Fall, wobei alle Instanzen eine manuelle Co-Adaption bedürfen. Wird

3.2. Die Klassifizierung der Metamodelländerungen
der obere Grenzwert einer Multiplizität verringert, so müssen bestimmte Werte bzw.
Klassen gelöscht werden. Wird der untere Grenzwert einer Multiplizität erhöht, so
müssen zu den betroffenen Elementen neue Werte hinzugefügt werden, was normalerweise
nur durch die manuelle Anpassung möglich ist. Die Wahl der zu löschenden
Elemente kann nicht ohne menschlichen Eingriff getroffen werden. Nach einer Einschränkung
eines Typbereichs in einem Attribut muss für jede betroffene Instanz eine
Typkonvertierung dieses Attributes erfolgen.
3.2.4. Die Updates an einem Metamodell
Letztendlich kann die neue Version eines Metamodells einige Updates deren Elemente enthalten.
Die damit hervorgerufenen Modifikationen können wie folgt gruppiert werden[7][24]:
• Das Metaelement umbenennen: Die Umbenennung ist ein einfacher Fall. Die
Änderung soll bei den existierenden Instanzen durchgeführt werden und kann somit
vollständig automatisiert erfolgen.
• Die Verlagerung einer Metaeigenschaft aus einer Metaklasse zu einer anderen
Metaklasse: Bestimmte Eigenschaften einer Metaklasse A wird gelöscht und
in eine andere Metaklasse B eingefügt.
• Das Extrahieren (engl. to extract) einer Metaklasse und das Löschen (engl.
to inline) einer Metaklasse: Das Extrahieren einer Metaklasse bedeutet, dass eine
neue Metaklasse definiert wird und alle relevanten Felder aus einer existierenden Metaklasse
in die neue verschoben werden. Eine Metaklasse zu löschen bedeutet, dass alle
ihre Eigenschaften in eine andere Klasse verschoben werden, dabei wird die ursprüngliche
Metaklasse gelöscht.
3.2.5. Die Klassifizierung von Metamodelländerungen anhand der korrupten
bzw. der non-korrupten Effekte auf existierende Modelle
Die Klassifizierung von Metamodelländerungen anhand der korrupten bzw. der non-korrupten
Effekte auf existierende Modelle ist in der Tabelle 3.2 zusammengefasst.
Auf den ersten Blick wird der Eindruck erweckt, dass diese Klassifizierung die Assoziationen
zwischen den Klassen nicht berücksichtigt. Dies ist aber nicht der Fall, weil die Assoziationen
als Eigenschaften der Metaklassen betrachtet werden können.
Alle möglichen oben beschriebene Szenarien für Metamodell-Evolution sind in der Tabelle
3.2 in folgende Kategorien unterteilt: ” non-breaking changes“, ” breaking and resolvable
changes“ und ” breaking and unresolvable changes“. Basierend auf dieser Kategorisierung leiten
sich die Strategien für die Modell-Co-Evolution von den existierenden Modellinstanzen
ab. Die ” non-breaking changes“ bedürfen keiner Modell-Co-Evolution. Die existierenden Modelle
müssen nicht angepasst werden. Die ” breaking and resolvable changes“ bedürfen eine
Modell-Co-Evolution, wobei diese automatisiert werden kann. Die einzige Kategorie, welche
die Automatisierung der Modell-Co-Evolution sehr schwierig zum Teil unmöglich macht,
ist die ” breaking and unresolvable changes“. Von allen Metamodelländerungen kann ” Die
25

3. Die Modellevolution und die Modell-Co-Evolution
Änderungstyp Änderungen
Non-breaking changes
Breaking and resolvable changes
Breaking and unresolvable changes
Die Generalisierung einer Metaeigenschaft
Das Einfügen einer nicht-obligatorischen Metaklasse
Das Einfügen einer nicht obligatorischen Metaeigenschaft
Das Extrahieren einer abstrakten Superklasse
Das Löschen einer Metaklasse
Das Löschen einer Metaeigenschaft
Der Umzug einer Metaeigenschaft in eine Subklasse (push metaproperty)
Das Flachmachen einer Hierarchie (flatten hierarchy)
Das Umbenennen von Metaelementen
Der Umzug einer Metaeigenschaft zu einer anderen Metaklasse
Das Extrahieren einer Metaklasse bzw. Inline einer Metaklasse
Das Einfügen einer obligatorischen Metaklasse
Das Einfügen einer obligatorischen Metaeigenschaft
Der Umzug einer Metaeigenschaft zu einer Superklasse (pull metaproperty)
Die Einschränkung der Kardinalität oder des Typs einer Metaeigenschaft
Das Extrahieren einer nicht abstrakten Superklasse
Tabelle 3.2.: Klassifizierung der Änderungen eines Metamodells im Überblick.[7][24]
Einschränkung der Kardinalität oder des Typs einer Metaeigenschaft“ in keiner Weise automatisiert
werden. Die restlichen Fälle lassen sich mit einer Abhilfe wie z.B. der Einführung
eines Default-Wertes automatisieren. Diese Strategien wurden bereits für jeden solchen Typ
dargestellt.[7][24]
3.3. Die Transformation-Co-Evolution
Die Änderungen an einem Metamodell können die Modelltransformationen beeinträchtigen.
Inkonsistenzen entstehen, wenn die Transformation nicht mehr der domainTo-Relation 3.1.1
genügt. Dies kann z.B. passieren, wenn ein Konzept aus dem Metamodell entfernt wird, das in
der Transformationsregel angesprochen wird. In Bezug auf Transformationen unterscheidet
man Metamodelländerungen in den drei folgenden Kategorien [8][16]:
26
• Vollautomatisiert: Änderungen an einem Metamodell, die Transformationen beeinträchtigen,
wobei die existierende Modelle dank dieser Transformationen vollautomatisiert
ohne Benutzer Interaktionen auf die neue Version migriert werden können.
• Partiell automatisiert: Modifikationen des Metamodells, die Transformationen so
Beinträchtigen, dass eine Migration notwendig ist, um die Validität der Transformationen
und somit die domainTo Relation (3.1.1) wiederherzustellen. Diese Migration kann

3.4. Modell-Co-Evolution der UWE-Präsentationsmodelle
automatisiert erfolgen mit der Ausnahme einiger feiner Anpassungen, die nur manuell
durchzuführen sind, um die Co-Evolution dieser Transformationen zu vervollständigen.
• Vollsemantisch: Die Änderungen am Metamodell, die existierende Transformationen
so beeinträchtigen, dass das Migration nur durch einen Menschen manuell definiert
werden kann.
3.4. Modell-Co-Evolution der UWE-Präsentationsmodelle
Im Laufe des Forschungsprozesses wurde die UWE-Methodologie, die im Kapitel bereits
vorgestellt wurde, kontinuierlich verbessert und an die neuen Anforderungen der RIAs angepasst.
Die UWE-Metamodell-Evolution verläuft gemäß diesen Anpassungen, sodass mehrere
Versionen des UWE-Metamodells sowie des UWE-Profils bereits existieren. Im Rahmen
dieser Arbeit wird der Modell-Co-Evolution-Ansatz zur Veranschaulichkeit am Beispiel eines
Ausschnittes des UWE-Metamodells, namens Präsentationsmodell, erarbeitet. In den
nächsten Abschnitten werden die UWE-Präsentationsmetamodell-Differenzen zwischen Versionen
1.7 und 1.8 vorgestellt. Anschließend werden die entdeckten Differenzen entsprechend
der Typologie aus dem Kapitel 3.2 zugeordnet. Darauf basierend wird die Umsetzung der
Modell-Co-Evolution für das UWE-Präsentationsmodell aufgezeichnet.
3.4.1. Die Metamodelldifferenzen zwischen UWE-Metamodellversion 1.7 und
der Version 1.8
Im Folgenden wird die Evolution des Präsentationsmodells des UWE-Metamodells betrachtet,
die im Kapitel 2.6.2 bereits vorgestellt wurde. Das Präsentationsmodell des UWE-
Metamodells definiert das Layout für die entsprechenden früher definierten Navigations- und
Prozess-Modelle. Es enthält die Kompositionsstrukturen aus Klassen, die User- Interface-
Elemente und die Container der grafischen Oberfläche in der Form einer Webseite repräsentieren.
Im Weiteren, nach einer ausführlichen Beschreibung aller Elemente der beiden Präsentationsmodellen,
werden die Unterschiede zwischen den Elementen herausgearbeitet.
Die Abbildung 3.5 stellt das UWE-Präsentations-Metamodell der Version 1.7 dar. An dieser
Stelle wird auf den Aufbau des Präsentationsmodells in der Version 1.7 näher eingegangen.
Die PresentationClass ist eine spezielle Klasse zur Darstellung einer Webseite oder deren
Teile und kann User-Interface-Elemente sowie Präsentationsklassen enthalten.
Die Klasse PresentationPage hat dieselbe Semantik wie die PresentationClass und wird
verwendet, um die oberste Ebene der Kompositionsstruktur einer Webseite zu kennzeichnen.
Somit darf die PresentationPage nicht in einem anderen Container enthalten sein. Die
PresentationGroup dient zur Darstellung von Bereichen einer Webseite, sobald diese komplex
sind. Genauer gesagt beinhalten solche Bereiche mehrere Präsentationselemente bzw.
Präsentationsklassen. Die PresentationProperty ist ein spezielles Attribut von der Klasse
PresentationClass und deren Subklassen PresentationPage und PresentationGroup. Mit diesem
Attribut werden die Präsentationselenente angegeben, die in PresentationClass bzw.
PresentationPage bzw. PresentationGroup beinhaltet werden. Die PresentationClass und
ihre Subklassen können aus den Subklassen der Klasse UIElement bestehen, die die User
27

3. Die Modellevolution und die Modell-Co-Evolution
Abbildung 3.5.: Das UWE-Präsentations-Metamodell. Version 1.7
Interface Elemente einer Webseite repräsentieren.
In der Abbildung 3.6 ist nicht zu übersehen, dass mehrere Änderungen an dem Metamodell
vorgenommen wurden. Folgende abstrakte Metaklassen sind zur Unterscheidung der User-
Interface-Elementen eingeführt worden: die ValuedElement, die InteractiveElement und die
OutputElement. Dabei wird zwischen den Outputelementen wie z.B. Text, Bild usw. und den
interaktiven Elementen differenziert. Die interaktiven Elemente unterteilen sich in Buttons,
Anchor Elemente und Input-Elemente, die solche User-Interface-Elemente wie Textinput und
Fileinput beinhalten. All die abstrakten Klassen bekamen eine Anzahl neuer Attribute, in
welchen die RIA-Eigenschaften beschrieben sind.
Darüber hinaus wurde die PresentationClass in die PresentationGroup umbenannt. Außerdem
werden folgende Elemente umbenannt: Page zu PresentationPage, Choice zu Selection
und Form zu InputForm.
Die Klasse AnchoredCollection wird nicht weiter unterstützt, stattdessen soll entweder ein
Anchor mit der Angabe der dazugehörigen Multiplizität oder eine IteratedPresentationGroup
eingesetzt werden.
Einige neue Klassen zur Unterstützung der RIA Eigenschaften wurden eingeführt, darunter:
Tab, MediaObject, Fileinput und CustomComponent. In der Tabelle 3.3 sind alle Änderungen
übersichtlich dargestellt. Dabei ist die Kategorie und der Typ jeder Änderung entsprechend
der Kategorisierung aus dem Kapitel 3.2 angegeben.
Zu jeder der Metamodell-Änderungen aus der Kategorie der ” breaking and resolvable changes“
wird im Folgenden je eine Transformation definiert, die eine automatisierte Überführung
der existierenden Modellen auf die neue Version ermöglichen. Bei den ” non-breaking changes“
28

3.4. Modell-Co-Evolution der UWE-Präsentationsmodelle
Abbildung 3.6.: UWE-Präsentations-Metamodell. Version 1.8
29

3. Die Modellevolution und die Modell-Co-Evolution
Änderungstyp Änderungen Metamodellelemente
Non-breaking changes
Breaking and resolvable changes
Das Einfügen einer nicht obligatorischen Metaklasse Tab, MediaObject, CustomComponent
Das Einfügen einer nicht obligatorischen Metaeigenschaft Attribute der Klassen: UIElement, PresentationGroup,
ValuedElement, OutputElement,
InputElement
Das Extrahieren einer abstrakten Superklasse ValuedElement, InputElement, OutputElement,
InteractiveElement
Das Löschen einer Metaklasse AnchoredCollection
Das Umbenennen eines Metaelements PresentationClass - PresentationGroup, Page
- PresentationPage, Form - InputForm, Choice
- Selection
Tabelle 3.3.: Überblick der Metamodell-Änderungen im Bezug auf Änderungstypen
muss keine Aktion ausgeführt werden, da diese Änderungen die Gültigkeit der existierenden
Modellen nicht verletzen.
Wie oben beschrieben kann für alle durch die Modell-Evolution betroffenen Elemente außer
AnchoredCollection eine eindeutige Strategie für die Anpassung der entsprechenden Modellelementen
angegeben werden. Im Falle der Klasse AnchoredCollection sind zwei Alternativen
möglich. Es ist zu entscheiden ob eine Automatisierung der Überführung der AnchoredCollection-Elemente
in die Modelle der neuen Version stattfinden soll, oder die Anpassung der
AnchoredCollections durch den Modellierer manuell erfolgen soll. Im Weiteren wird die Alternative
mit der Umsetzung durch die IteratedPresentationGroup in den Transformationen
übernommen. Die Wahl beruht auf der Tatsache, dass die Beschreibung zu dem Einsatz des
AnchoredCollections in ” UWE Metamodel and Profile User Guide and Reference“ in der
Version 1.7 [15] und der IteratedPresentationGroup in der Version 1.9 [6] dieselbe ist. Sie
lautet, dass diese Elemente für die Präsentation eines Menüs oder eines Indexes verwendet
werden können.
Somit ist im Falle der UWE-Präsentationsmodelle eine komplett automatisierte transformative
Model-Co-Evolution möglich, was dadurch bedingt ist, dass keine der Metamodell-
Änderungen den Änderungstyp ” breaking and unresolvable changes“ hat.
3.5. Zusammenfassung
Metamodelle wie auch alle Softwareartefakte ändern sich im Laufe der Zeit. Evolution der
Metamodelle betrifft unterschiedliche Modellierungsartefakte, die mit dem entsprechenden
Metamodell in einer Beziehung stehen, solche wie existierende Modelle, Modelltransformationen,
Modellierungstools, Dokumentation und Anforderungen. Die Modelle stellen die
Grundlage einer modellgetriebenen Entwicklung dar. Somit müssen die Modelle infolge einer
Metamodell-Evolution als Erstes angepasst werden. In dieser Arbeit liegt der Fokus auf der
Modell-Co-Evolution.
In diesem Kapitel wurde eine umfangreiche Beschreibung der Metamodelländerungen mit
einer Diskussion über die Auswirkungen dieser Änderungen auf die Metamodellinstanzen
vorgeführt. Anschließend wurde die Typologie zur Unterscheidung der möglichen Auswir-
30

3.5. Zusammenfassung
kungen der Änderungen auf die existierenden Modelle erläutert. Die ” breaking and resolvable
changes“ des Metamodells haben keine Auswirkungen auf die Metamodellinstanzen.
Die ” breaking and resolvable changes“ sind sehr interessant, da deren Auswirkungen auf
die existierende Modelle automatisiert mithilfe der Modelltransformationen beseitigt werden
können.
Sobald die Metamodell-Evolution eine der ” breaking and unresolvable changes“ mit sich
bringt, bei denen eine Abhilfe wie z.B. die Definition eines Default-Wertes nicht anwendbar
ist, kann die Modell-Co-Evolution von betroffenen Modellelementen ausschließlich manuell
erfolgen. Diese Tatsache stellt eine große und unlösbare Problematik dieses Bereiches dar.
Eine ultimative Lösung dieses Problems ist nicht in Sicht.
Zusätzlich ist die klare Trennung zwischen den Metamodell-Evolution-Kategorien leider nicht
möglich. In der Wirklichkeit zeigen die Erfahrungen, dass Metamodell-Evolution nicht immer
auf eine Sequenz der atomaren Co-Evolutionsschritte zurückgeführt werden kann.[7]
Grundsätzlich wird auf das Metamodell im Rahmen des Evolutionsprozesses zeitgleich eine
komplexe Kombination der Änderungen angewendet. Zudem gehören diese Änderungen
zu verschiedenen Typen und weisen Abhängigkeiten voneinander auf. Die Co-Evolution-
Strategie sollte in diesem Fall nicht nur auf der oben vorgestellten Klassifizierung beruhen,
sondern auch auf den Entscheidungen des Modellierers. Diese Entscheidungen basieren auf
seinem Wissen über das Fachgebiet und die Zusammenhänge im konkreten Modell.
Insgesamt soll der Co-Evolution-Prozess in möglichst großen Umfang automatisiert verlaufen.
Anschließend sollen für die einzelnen ” breaking and unresolvable changes“ durch den
Modellierer eine konkrete Strategie für die betroffenen Modellelemente spezifiziert werden,
was eine Eindeutigkeit der Modell-Co-Evolution erzielen soll. Die Eindeutigkeit der Modell-
Co-Evolution wird nur dann gewährleistet, wenn alle möglichen zulässigen Varianten der
Co-Evolution-Strategie berücksichtigt, dokumentiert und im Rahmen des Projekts für alle
zugänglich gemacht werden.
Modell-Co-Evolution soll im Rahmen der UWE-Methodologie ermöglicht werden. Eine ausführliche
Beschreibung der Metamodelldifferenzen eines UWE-Metamodellausschnitts in der
Versionen 1.7 und 1.8 wurde in diesem Kapitel vorgenommen. Es hat sich ergeben, dass die
Änderungen, die das UWE-Metamodell üblicherweise während dessen Weiterentwicklung
erfährt unter die Kategorien der ” unbreaking changes“ oder der ” breaking and resolvable
changes“ gehören. Somit ist eine vollautomatisierte Überführung der existierenden Modelle
möglich. Das UWE-Metamodell ist in Teilmodelle unterteilt. Jedes davon ist sehr übersichtlich
und besitzt konkret definierte Modellelemente. Somit ist die automatisierte Modell-Co-
Evolution für UWE-Modelle ein sich gut rentierender Ansatz, deren Einsatz viel Zeit sparen
kann und eine hohe Qualität der Modelle bei der Versionsmigration gewährleistet.
Im nächsten Kapitel wird ein transformativer Ansatz für die Modell-Co-Evolution eines
Ausschnittes des UWE-Metamodells vorgestellt.
31

3. Die Modellevolution und die Modell-Co-Evolution
32

4. Modell-Co-Evolution. Metamodellbasieter
transformativer Ansatz
In diesem Kapitel wird ein transformativer Ansatz beschrieben, der die automatisierte Modell-
Co-Evolution der UWE-Präsentationsmodelle realisiert. Für die Umsetzung der Transformationen
wird die relationale QVT-Sprache verwendet. Im vorangehenden Kapitel wurden die
Änderungen zwischen den Präsentationsmetamodellen der Version 1.7 und 1.8 erläutert und
gemäß der im Kapitel 3 vorgestellten Typologie in zwei Gruppen eingeteilt.
Zu der ersten Gruppe gehören die Änderungen, die keine Co-Evolution-Aktion an den existierenden
Modellen bedingen. Die zweite Gruppe beinhaltet die Änderungen des UWE-Präsentationsmetamodells,
die zur Notwendigkeit der Modell-Co-Evolution der existierenden Modelle
führen. Für jede Änderung an einem UWE-Metamodellelement aus der zweiten Gruppe
kann eine Relation in der relationalen QVT-Sprache definiert werden. Diese Relation generiert
anhand der für die Modell-Co-Evolution betroffenen Modellelemente der existierenden
Modelle die geänderten Modellelemente, die konform zu der neuen UWE-Metamodell-Version
sind. Nach einer Einführung in die relationale QVT-Sprache und ihre Konzepte werden all
diese Relationen im Rahmen einer QVT-Transformation definiert und detailliert beschrieben.
Die OMG veröffentlichte die Spezifikation der Query-View-Transformations (QVT), welche
in Form der QVT-Sprachen Definitionen die Grundlagen und Richtlinien für die Transformationen
vorgibt. Da die OMG keine Implementierungen des QVTs vorgibt, werden die
Implementierungen von verschiedenen Tool-Herstellern bereitgestellt. Zu diesem Zeitpunkt
gibt die Implementierung von mediniQVT am besten die Spezifikation der relationalen
QVT-Sprache(QVT-Relations) wieder. Im Rahmen dieser Arbeit wird daher die medini-
QVT Implementierung der relationalen Sprache für die Erfassung der Modell-Co-Evolution-
Transformationen verwendet.
4.1. Der fundamentale Aufbau von Transformationsskript in der
relationalen QVT-Sprache
Die QVT-Spezifikation der OMG eignet sich leider nicht gut als ein Lehrbuch für die relationale
QVT-Sprache. Siegfried Nolte hat ein sehr umfangreiches Buch über die relationale
QVT-Sprache veröffentlicht[19]. Das Buch beinhaltet die Beschreibung der generellen
Konzepte der relationalen QVT-Sprache, viele nützliche Beispiele und die Anleitungen zur
Ausführung der Transformationen mithilfe von dem mediniQVT-Tool. Der Autor hat sich
mit der relationalen Sprache auseinander gesetzt und sehr ausführliche und hilfreiche Definitionen
verfasst. Nach Nolte lässt sich die Query View Transformations so interpretieren:
33

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
• Query: ” Die Query ist die Beschreibung einer Anfrage bezogen auf ein Quellmodell,
um den Kandidaten für die Transformation zu ermitteln. Der Kandidat für die Transformation
ist entweder Quellmodell selbst oder ein spezieller Ausschnitt des Modells,
welcher durch die Abfrage, die Query, eingegrenzt wird.“[19]
• View: ” Die View ist die Beschreibung einer Sicht, wie das Ergebnis im Zielmodell
aussehen soll.“[19]
• Transformation ” Die Transformation ist der Prozess, das konkrete Quellmodell mit
den definierten Query zu ermitteln und in das Zielmodell zu überführen.“[19]
Mit einer Query wird aus einem Quellmodell stützend auf sein formales Metamodell eine
bestimmte Untermenge deren Elemente selektiert. Eine spezielle View legt ein Zielmodell
fest, welches in vollem Umfang aus den Quellmodellelementen hergeleitet wird. Unter dem
Einsatz einer Transformation wird aus den selektierten Quellmodellelementen die vorher
festgelegte View generiert. Dies bezeichnet Nolte in seinem Buch als das QVT-Prinzip. [19]
Im Rahmen der Transformation werden zwischen den Elementen des Quellmodells und den
Elementen des Zielmodells, die Bezug zueinander haben, Relationen definiert. Die Relationen
beschreiben in Form der Musterdefinitionen konkret das gültige Erscheinungsbild des
Zielmodells. Diese Vorgehensweise wird als ” Pattern Matching“ genannt.[19]
Die relationale QVT-Sprache operiert mit folgenden Sprachkonstrukten: transformation, top
relation, enforce und checkonly domain usw. In der Abbildung 4.1 ist der generelle Aufbau
von Transformationen der relationalen QVT-Sprache zu sehen. Hierbei handelt es sich um
einen generellen Überblick über die Sprachelemente und deren Beziehungen.[19]
34
• Eine QVT-Transformation (transformation) generiert aus Quellmodell ein Zielmodell,
wobei dem Quell- und dem Zielmodell je ein bestimmtes Metamodell zugrunde
liegt. Es können bei dem Input wie bei dem Output einer Transformation jeweils mehr
als ein Modell angegeben werden.
• Der Bezug einer konkreten Teilmenge des Quellmodells auf die Elemente des Zielmodells
wird in den Relationen dargestellt. Eine Transformation soll mindestens eine
Relation besitzen.
• Eine oder mehrere Domänen können in einer Relation enthalten sein. Die Definition
der Regeln für die Gültigkeit der Modellelemente wird mit Hilfe von sogenannten
Domänenmustern (domain patterns) vorgenommen, die in Form einer Domäne
(domain) einer Relation hinzugefügt werden.
• Jede Domäne außer primitiven Domänen beinhaltet so ein Domänenmuster. Die primitiven
Domänen werden dafür eingesetzt um die einfachen Datentypen, wie z.B. String
als Argumente übergeben zu können. Die restlichen Domänen können als getypte Variable
verstanden werden, die ein Metamodellelement in einer speziellen Form darstellt. In
der Domänenmuster-Definition (pattern definition) erfolgt die Selektion der Eigenschaften
des ausgewählten Metamodellelements, um von diesem Metamodellelement
ausgehend die Elemente in dem Zielmodell zu generieren.
• Die optionalen when- oder where-Klauseln können Bedingungen in Form der OCL-
Ausdrücke enthalten. Mit Hilfe dieser Bedingungen wird die Gültigkeitsprüfung der
Relation zusätzlich verschärft.

4.1. Der fundamentale Aufbau von Transformationsskript in der relationalen QVT-Sprache
Abbildung 4.1.: Der Aufbau einer Transformation in der relationalen QVT-Sprache [19]
• Darüber hinaus ist es möglich spezielle Hilfsfunktionen (queries), die mit OCL-Anweisungen
umgesetzt werden, zu definieren. Die Hilfsfunktionen werden außerhalb der Relationen
erstellt.
• Die Verwendung der Variablen ist ausschließlich in den Relationen zugelassen. Dabei
können es beliebige OCL-Variablen sein: primitive Datentypen (String, Boolean),
Sammlungstypen (Set(String)) oder Variablen von einem Objekttyp (Class, Set(Attribute)
etc.)
• Bedingungen, domain patterns und queries werden mithilfe der OCL-Ausdrücke
umgesetzt.
• Eine optionale Spezifikation von keys schließt die Generierung von Duplikaten im
Zielmodell aus.
35

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
Textuell ergibt sich folgender syntaktischer Aufbau einer Transformation:
1 transformation
2 (
3 [ , ]∗
4 )
5 /∗ d i e f o l g e n d e Angabe i s t o p t i o n a l ∗/
6 [ key { [ ,
7 ]∗ } ; ] ∗
8 −− mindestens e i n e Relation auf dem obersten Level muss es geben −−
9 [ [ top ] relation
10 {
11 [ : ; ] ∗
12 −− mindestens e i n e Domäne muss es geben −−
13 [ [ checkonly | enforce ]
14 domain :
15 {
16 [ , ]∗
17 } ; ]+
18 −− checkonly und e n f o r c e domains b e s i t z e n Patterns , −−
19 −− p r i m i t i v e domains n i c h t −−
20 [ p r i m i t i v e domain :
21 ; ] ∗
22 −− c o n d i t i o n s sind optional , a l l e r d i n g s unter −−
23 −− Umständen unverzichtbar , z .B. f ü r r e l a t i o n − −−
24 −− oder function −c a l l s −−
25 [ when { } ]
26 [ where { } ]
27 }]+
28 −− o p t i o n a l e H i l f s f u n k t i o n e n −−
29 [ query ( [ [ , ] ] ∗ )
30 {} ] ∗
31 }
Listing 4.1: Der Syntaktischer Aufbau eines Transformationsskriptes[19]
Für die Definition der Hilfsfunktionen, sowie der Regeln in den where- und den when-
Klauseln steht die komplette OCL-Sprache zur Verfügung.
Im nächsten Kapitel wird näher auf die formale Beschreibung der relationalen QVT-Sprache
eingegangen. Dabei wird für jedes oben beschriebenes Element der Sprache die Syntax angegeben.
In den darauf folgenden Kapiteln werden die Transformationen, welche die UWE-
Präsentationsmodell-Co-Evolution ermöglichen, detailliert beschrieben.
4.2. Die relationalen Transformationen. Eine Formale Darstellung
der Konzepte
Nach der Einführung in den Aufbau einer QVT-Transformation, soll nun die Erläuterung
der Hauptsprachmittel folgen, mit denen die Transformationen erarbeitet werden.
36

4.2. Die relationalen Transformationen. Eine Formale Darstellung der Konzepte
4.2.1. Die Transformationen
Eine Transformation (transformation) wird als eine Relation zwischen Modellen betrachtet,
die einen Namen besitzt und in Form einer Parameterliste Modelle deklariert. Jedes
Modell besitzt einen Namen und einen Typ. Der Typ wird durch das entsprechende Metamodell
bestimmt.[19]
Die Syntax:
1 transformation
2 ( [ , ] ∗ )
3 {
4 [ ] ∗
5 [ ] ∗
6 [ ] ∗
7 }
Listing 4.2: Der Syntaktischer Aufbau einer Transformation[19]
Die Definition der Relationen zwischen den Modellelementen legt die Grundlage für die
Überführung eines Modells in ein anderes fest. Die UWE-Präsentationsmodelle in der Version
1.7, im weiteren SimpleUWEold-Modelle genannt, bestehen aus Paketen4.3, die folgende
Elemente enthalten können: Pages, Presentation Classes, Presentation Groups, Text, Buttons
usw. Wobei Pages, PresentationClasses und Presentation Groups Properties besitzen.
Das Beispiel:
1 transformation mapUWEversion ( s r c : SimpleUWEold , t r g : SimpleUWEnew )
2 {
3 −−keys−−
4 top relation mapPackage {−− body −−}
5 top relation mapPage {−− body −−}
6 relation mapProperty {−− body −−}
7 top relation mapPresClass {−− body −−}
8 top relation mapPresGroup {−− body −−}
9 top relation mapText {−− body −−}
10 top relation mapAnchor {−− body −−}
11 top relation mapImage {−− body −−}
12 top relation mapButton {−− body −−}
13 top relation mapTextInput {−− body −−}
14 top relation mapAnchoredCol {−− body −−}
15 top relation mapForm {−− body −−}
16 −− q u e r i e s−−
17 }
Listing 4.3: Das Beispiel einer Transformation[19]
Innerhalb der Transformationen können außer Relationen zusätzliche Hilfsfunktionen und
Abfragen (queries) definiert werden, die aus einfachen oder komplexen OCL-Ausdrücken
bestehen. Die Hilfsfunktionen lassen sich bei Bedarf in Form externer Dateien auslagern, die
über eine Import-Anweisung eingebunden werden können.[19]
37

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
4.2.2. Die Relationen
Eine Relation (relation) ist das primäre Element einer Transformation. In Form von Domänenmustern
(domain patterns) werden in den Domänen einer Relation die Selektionsbedingungen
für einen Modellauschnitt angegeben, der der Transformation als Quellmodell unterzogen
wird. Der Mechanismus ist einer ebenfalls deskriptiven SQL-Abfrage auf einen relationalen
Datenbestand ähnlich. Nur die Modellelemente, die dem Domänenmuster genügen, werden
in die Transformation miteinbezogen. Innerhalb einer Relation können Variablen deklariert
und verwendet werden, die in allen Domänen dieser Relation als global gelten. Die Variablen
können vom Typ eines Elements aus den Metamodellen sein oder den beliebigen
OCL-Datentyp besitzen.[19]
Das Beispiel:
1 transformation mapUWEversion ( s r c : SimpleUWEold , t r g : SimpleUWEnew )
2 {
3 −− E r s t e l l t e i n P r e s e n t a t i o n Paket im Z i e l m o d e l l −−
4 −− mit dem Namen und dem Attribut kind aus Quellmodell −−
5 top relation mapPackage
6 {
7 packageName : String ;
8 packageKind : String ;
9 checkonly domain s r c srcPckg : SimpleUWEold : : Package
10 {
11 name = packageName ,
12 kind = packageKind
13 } ;
14 enforce domain t r g tgtPckg : SimpleUWEnew : : Package
15 {
16 name = packageName ,
17 kind = packageKind
18 } ;
19 −− when−p r e d i c a t e −−
20 −− where−p r e d i c a t e −−
21 }
Listing 4.4: Das Beispiel einer Relation
Das Präsentationspaket soll mithilfe der Relation aus dem Listing 4.4 kopiert werden. Zuerst
wird der Name und das Attribut kind des Pakets in den Variablen zwischengespeichert
und anschließend in der folgenden Domäne dem Namen und dem Attribut kind des zu
generierenden Pakets zugewiesen.
Die Arten von Relationen
Es wird zwischen zwei Arten von Relationen unterschieden[19]:
38
• top-level-Relation ist eine Relation, die unmittelbar bzw. implizit ausgeführt wird,
sobald bei der Transformation eines Modells das Modellelement gefunden wird, für
welches die Selektionsbedingungen aus einer Domäne der Relation erfüllt sind. Solche
Relationen werden mit dem Schlüsselwort top gekennzeichnet.

4.2. Die relationalen Transformationen. Eine Formale Darstellung der Konzepte
• non-top-level-Relation ist eine Relation, welche durch einen expliziten Aufruf aus
einer anderen Relation heraus, ausgeführt wird. Diese Relationen werden mit keinem
Schlüsselwort gekennzeichnet.
Es muss mindestens eine top-level-Relation im Rahmen einer Transformation geben. Ansonsten
wird eine solche Transformation keine Wirkung erzielen. In dem Listing 4.5 sind
alle Relationen außer der mapProperty-Relation als top-level-Relationen deklariert. Wird
bei der Abarbeitung eines Modells ein bestimmtes Element gelesen, so wird die entsprechende
top-level-Relation aufgerufen. Die mapProperty wird nur in dem Fall ausgeführt, wenn
die Relation mapProperty explizit innerhalb von z.B. mapPage aufgerufen wird. Dabei muss
beachtet werden, dass die top-level Relationen nur innerhalb der when-Klauseln aufgerufen
werden können. Non-top-level-Relationsaufrufe dürfen ausschließlich innerhalb der where-
Klauseln stehen.
Mit jeder Ausführung von der mapPage Relation, wie in der Zeile 5 im Listing 4.5 steht, wird
zuerst wegen des Aufrufs unter der when-Klausel die mapPackage Relation aufgerufen. Damit
wird sichergestellt, dass zu dem Paket in dem sich die Page befindet ein entsprechendes
Paket in dem Zielmodell bereits existiert.
Das Beispiel:
1 transformation mapUWEversion ( s r c : SimpleUWEold , t r g : SimpleUWEnew )
2 {
3 −−keys−−
4 top relation mapPackage {−− body −−}
5 top relation mapPage
6 {
7 −− body −−
8 when
9 {
10 mapPackage (−−arguments−−) ;
11 }
12 where
13 {
14 mapProperty (−−arguments−−) ;
15 }
16 }
17 relation mapProperty {−− body −−}
18 −− q u e r i e s−−
19 }
Listing 4.5: Das Beispiel einer Relation unter dem Einsatz der when- und where-Klauseln
In der where-Klausel in der Zeile 14 vom Listing 4.5 wird durch den Aufruf der Relation
mapProperty sichergestellt, dass bei jeder Erzeugung von Page-Elements im Zielmodell auch
die Erstellung von deren Attribute erzwungen wird.
4.2.3. Die Domänen
Nur die gültigen Relationen werden bei der Abarbeitung einer Transformation herangezogen.
Durch die Definition der domain pattern werden die Regeln für die Gültigkeit der
39

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
Relation definiert. Eine Domäne repräsentiert die Modellelemente eines Metamodells als getypte
Variable, die Root-Variable genannt wird. Der Domänenname und die Deklaration
der Root-Variablen bilden die Signatur einer Domäne. Anschließend wird das Domänenmuster
definiert. Mit dem Schlüsselwort checkonly wird gekennzeichnet, dass die Gültigkeit
der Domäne geprüft wird, dies ist bei den Quellmodellelementen der Fall. Das enforce
kennzeichnen die Domänen, deren Gültigkeit erzwungen wird. Erzwungen werden die
Zielmodellelemente.[19]
Die Syntax:
1 [ checkonly | enforce ] domain
2
3 {
4 [ , ] ∗
5 } ;
Listing 4.6: Die Syntax einer Domäne[19]
Mit wird ein Modellelement bei der Argumentenliste der Transformation deklariert.
Ein Domänenmuster enthält neben dem Definitionsteil einen prozeduralen Teil
(pattern expression), der wiederum aus einer oder mehreren durch Kommata getrennten
Zuweisungsoperationen(template expressions) besteht. Mithilfe Pattern Matching werden
bestimmte Modellelemente im Rahmen des prozeduralen Teils geprüft(checkonly) oder
erzwunden(enforce).[19]
Die Relation mapPackage aus dem Listing 4.7 definiert die Beziehung zwischen den Paketen
im Modell SimpleUWEold und den Paketen im dem Modell SimpleUWEnew. Die Root
Variable srcPckg repräsentiert die Menge aller Pakete in SimpleUWEold, die das definierte
Domänenmuster erfüllen. Die Variable trgPckg repräsentiert das zu generierende Paket im
Zielmodell.
1 top relation mapPackage
2 {
3 pckgName : String ;
4 checkonly domain s r c srcPckg : SimpleUWEold : : Package
5 {
6 name = pckgName
7 } ;
8 enforce domain t r g tgtPckg : SimpleUWEnew : : Package
9 {
10 name = pckgName
11 } ;
12 }
Listing 4.7: Das Beispiel eines prozeduralen Teil(pattern expression) einer Domäne
Der Typname der Root-Variablen wird hier in vollständig spezifizierter Form angegeben, welche
es erlaubt die Elemente der Metamodelle mit gleichen Namen eindeutig zu unterscheiden:
::
also in Fall der Root-Variable:
40

4.2. Die relationalen Transformationen. Eine Formale Darstellung der Konzepte
srcPckg : SimpleUWEold::Package
Es wird zwischen vorher deklarierten Variablen (variable template expressions) und
den object template expressions, welche die Modellelemente zum Gegenstand haben,
unterschieden.
Als Hilfsmittel zur Speicherung des Namens des Paket wird eine freie Variable pckgName
vom Typ String deklariert. In diesem Beispiel wird bei der Zuweisungsoperation eine variable
template expression verwendet. Als Beispiel einer Komponente der Root-Variable
vom Typ SimpleUWEold::Package dient name aus der Zeile 6 des Listings 4.7.
Die Komponenten der Root-Variable stehen stets auf der linken Seite der Zuweisungsoperation.
Auf der rechten Seite einer Zuweisungsoperation kann eine freie Variable, ein OCL-
Ausdruck oder ein konkreter Wert seinen Platz haben. Der Checkonly-Teil wird vor dem
Enforce-Teil ausgeführt, somit enthält die pckgName Variable bei jeden Ausführung der
Transformation den aktuellen Wert des Namens des Packages aus SimpleUWEold. Dabei
wird der Name des Pakets srcPckg wegen des checkonly-Status nicht verändert.
In der darauf folgenden Domäne wird der Wert der Variable pckgName dem Namen des
tgtPckg vom Typ SimpleUWEnew::Package zugewiesen. Bei jeder Ausführung dieser Relation
wird ein Package des Typs SimpleUWEnew mit denselben Namen wie das ursprüngliche
srcPckg Paket erzwungen.
Eine Relation kann sowohl über mehrere checkonly-Domänen als auch mehrere enforce-
Domänen verfügen. Bei der Ausführung einer Transformation wird zuerst die Gesamtmenge
der checkonly-Domänen abgearbeitet und gültige Modellelemente aus dem Quellmodell selektiert.
Ist ein Modellelement selektiert, so wird die Generierung dieses Elements stattfinden.
Dies wird check-before-enforce Semantik genannt und bildet ein wichtiges Konzept der
relationalen QVT-Sprache.[19]
4.2.4. Die when- und where-Klauseln
Bestimmte Vorbedingungen und Invarianten können durch die Eingabe spezieller Prädikaten
innerhalb der der when- und where-Klauseln geprüft oder hergestellt werden[19]:
• Mithilfe einer when-Klausel werden die Vorbedingungen festgelegt, die erfüllt sein
müssen, damit die Relation ausgeführt wird.
• Mithilfe einer where-Klausel werden die Invarianten definiert. Für alle Modellelemente
der Relation zu jedem Zeitpunkt während der Abarbeitung der Relation werden die
Invarianten geprüft. Bei jedem Zugriff auf eine der veränderbaren Variablen müssen
die Invarianten hergestellt werden.
Innerhalb der when- und where-Klauseln dürfen beliebige, durch Semikola getrennte OCL-
Ausdrücke stehen, wobei folgende Regeln beachtet werden müssen[19]:
• Die top-level-Relationen dürfen nur in when-Klauseln explizit aufgerufen werden.
41

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
• Die non-top-level-Relationen dürfen nur in where-Klauseln aufgerufen werden.
• Die Funktionen dürfen nur in where-Klauseln aufgerufen werden.
Das Beispiel einer where-Klausel:
1 top relation mapPackage
2 {
3 pckgName : String ;
4 checkonly domain s r c srcPckg : SimpleUWEold : : Package
5 {
6 name = pckgName
7 } ;
8 enforce domain t r g tgtPckg : SimpleUWEnew : : Package
9 {
10 name = pckgName
11 } ;
12 −− Hier e i n e Bedingung : der Name des Packages −−
13 −− s o l l P r e s e n t a t i o n heißen −−
14 where
15 {
16 name = ’Presentation’ ;
17 }
18 }
Listing 4.8: Beispiel einer where-Klausel
Beim Zugriff auf die freie Variable pckgName in de enforce domain in der Zeile 6 des
Listings 4.8, wird für pckgName mithilfe der where-Klausel ein definierter Zustand hergestellt,
nämlich pckgName enthält den Wert ’Presentation’. Damit wird sichergestellt, dass
ausschließlich Präsentations-Pakets zur Transformation herangezogen werden. Wird bei der
Ausführung der Transformation ein Paket mit einem anderen Namen gefunden, so wird diese
nicht für die Generierung eines Zielpakets selektiert.
4.2.5. Object Template Expressions und Inline-Objekterzeugung
Wie im Kapitel 4.2.3 erläutert, können Zuweisungsausdrücke eines Domänenmusters object
expressions sein, wenn es sich um Instanzen von Modellen oder von Modellelementen handelt,
oder variable expressions, wenn es sich um Variablen handelt. “Ein object template
expression ist ein Ausdruck innerhalb eines Domänenmusters, der sich auf ein Element des
assoziierten Modells bezieht.”[19]
Das Beispiel:
1 top relation mapText
2 {
3 textName : String ;
4 srcPackage : SimpleUWEold : : Package ;
5 trgPackage : SimpleUWEnew : : Package ;
6 checkonly domain s r c te : SimpleUWEold : : Text
7 {
8 namespace = srcPackage ,
9 name = textName
42

10 } ;
4.2. Die relationalen Transformationen. Eine Formale Darstellung der Konzepte
11 enforce domain t r g te2 : SimpleUWEnew : : Text
12 {
13 namespace = trgPackage ,
14 name = textName
15 } ;
16 }
Listing 4.9: Das Beispiel einer object template expression
Das Muster der Domäne domain src, dass sich auf ein Modell vom Typ SimpleUWEold
bezieht, ist insgesamt ein object template expression, der sich auf die Instanz text vom
Typ Text bezieht. Zwei Zuweisungen sind in dem Domänenmuster enthalten: einen Variablenausdruck
name = textName und einen Objektausdruck namespace = trgPackage. Das
Domänenmuster kann alternativ wie folgt definiert werden[19]:
1 top relation mapText
2 {
3 textName : String ;
4 checkonly domain s r c te : SimpleUWEold : : Text
5 {
6 namespace = srcPackage : SimpleUWEold : : Package {} ,
7 name = textName
8 } ;
9 enforce domain t r g te2 : SimpleUWEnew : : Text
10 {
11 namespace = trgPackage : SimpleUWEnew : : Package {} ,
12 name = textName
13 } ;
14 when
15 {
16 mapPackage ( srcPackage , trgPackage ) ;
17 }
18 }
Listing 4.10: Das Beispiel einer object template expression. Alternative
Hier wird das Paket srcPackage in der Zeile 6 implizit mithilfe einer inneren ein object template
expression deklariert und verwendet. Dabei ist dieser Objektzuweisungsausdruck mit
der vordeklarierten Objektvariablen nicht gleichzusetzen. Implizite Zuweisung durch ein object
template expression bedeutet folgendes[19]:
namespace = srcPackage : SimpleUWEold::Package
was folgendem OCL-Ausdruck entspricht:
namespace->includes(srcPackage)
Demgegenüber impliziert die Alternative mit einer vordefinierten Variablen:
namespace = srcPackage
43

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
Manchmal kommt es vor, dass Modellelemente im Zielmodell mithilfe object template
expression in der enforce-Domäne generiert werden sollen. Dieses Verfahren wird als Inline-Objekterzeugung
bezeichnet.
Das Beispiel:
1 top relation mapPage
2 {
3 pageName : String ;
4 propertyName : String ;
5 checkonly domain s r c srcPg : SimpleUWEold : : Page
6 {
7 namespace = srcPckg : SimpleUWEold : : Package {} ,
8 name = pageName ,
9 ownedAttribute = presProp : SimpleUWEold : : PresentationProperty
10 {
11 name=propertyName
12 }
13 } ;
14 enforce domain t r g trgPg : SimpleUWEnew : : PresentationPage
15 {
16 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
17 name = pageName ,
18 −− I n l i n e Pattern zur Erzeugung der PresentationProperty −−
19 −− unter Verwendung des Namen der Property aus dem SimpleUWEold−
Modell −−
20 ownedAttribute = presProp2 : SimpleUWEnew : : PresentationProperty
21 {
22 name = propertyName
23 }
24 } ;
25 when
26 {
27 mapPackage ( srcPckg , tgtPckg ) ;
28 }
29 }
Listing 4.11: Das Beispiel einer Inline-Objekterzeugung.
Hier betrachten wir die Relation mapPage. Es wird gewährleistet, dass zu jeder Page ein
PresentationPage in neuem Modell generiert wird, wobei dieses PresentationPage genau so
viele PresentationProperties mit denselben Namen wie die ursprüngliche Page besitzen soll.
Diese Properties werden mithilfe inline-Objekterzeugung erzwungen (siehe Zeilen 20-24 im
Listing 4.11).
Bis zur dieser Stelle wurden alle wichtigen formalen Konzepte der Relationalen QVT-Sprache
erläutert, die für die Definition der Transformation für UWE-Präsentationsmodelle benötigt
werden. In den nächsten Kapiteln werden die Relationen für die Überführung der Präsentationsmodellelemente
aus der Version 1.7 des UWE-Metamodells in die Version 1.8 des
UWE-Metamodells vorgestellt.
44

4.3. Transformationen zur automatisierten Modell-Co-Evolution basierend auf UWE-Metamodellen
4.3. Transformationen zur automatisierten Modell-Co-Evolution
basierend auf UWE-Metamodellen
Nachdem in den vorangehenden Kapiteln die ausgewählten Grundkonzepte der relationalen
QVT-Sprache vorgestellt wurden, kann an dieser Stelle die Transformation zu der automatisierten
Überführung der UWE-Präsentationsmodelle der Version 1.7 in die Präsentationsmodelle
der Version 1.8 definiert werden. Dabei wird der Fokus auf die UWE-spezifische
Details gelegt und die Konzepte der relationalen QVT-Sprache nicht weiter erläutert.
4.3.1. Signatur der Transformation
Die Transformation soll ein Präsentationsmodell, das in der Version 1.7 des UWE-Metamodells
erstellt wurde in ein Präsentationsmodell der Version 1.8 überführen. Die Metamodelle werden
hier entsprechend SimpleUWEold und SimpleUWEnew genannt. Die Transformation
in der relationalen QVT-Sprache heißt ” mapUWEversion“. Die UML-Modelle der SimpleU-
WEold (Abb. A.7) und SimpleUWEnew (Abb. A.8) sind im Anhang A angegeben.
1 transformation mapUWEversion ( s r c : SimpleUWEold , t r g : SimpleUWEnew )
2 {
3 −− r e l a t i o n s −−
4 }
Listing 4.12: Transformationssignatur.
Das Quellmodell wird durch src repräsentiert und das Zielmodell entsprechend mit trg. Dies
bedeutet, dass src und dessen Modellelemente das Gegenstand von checkonly-Domänen,
und trg und dessen Modellelemente das Gegenstand der enforce-Domänen sind.
4.3.2. Die Identifizierung der Relationen
Als nächstes werden die UWE-Präsentationsmetamodelle untersucht und deren nicht abstrakte
Klassen genau betrachtet. Einige Elemente des UWE-Metamodells haben sich in der
neuen Version nicht verändert, daher wird die Transformation zu einem Teil aus der Relationen
bestehen, welche die Modellelemente einfach kopieren und zum anderem Teil aus den
Relationen, die die Metamodelländerungen berücksichtigen.
Als erstes werden alle nicht abstrakten Elemente der SimpleUWEold-Metamodells zusammengefasst.
Für die Elemente, die nicht von der Metamodell-Evolution betroffen sind, soll
eine einfache Kopier-Aktion ausgeführt werden. Die restlichen Elemente sollen entsprechend
der Metamodelländerungen transformiert werden. Dabei ist zu erwähnen, dass in unserem
Fall es sich bei allen Metamodelländerungen um ” breaking and resolvable changes“ handelt,
wie in der Tabelle 3.3 im Kapitel 3.4.1 bereits beschrieben wurde.
In der Tabelle 4.1 sind alle Elemente erfasst, die bei einem UWE-Modell als Modellelemente
vorkommen können. Im Rahmen der Transformation sollen die Instanzen des SimpleUWEold-
Metamodells in die Instanzen des SimpleUWEnew-Metamodells überführt werden. Dabei er-
45

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
Nr. SimpleUWEold SimpleUWEnew Transformationsaktion Relation
1 Package Package Kopie mapPackage
2 Text Text Kopie mapText
3 Image Image Kopie mapImage
4 Button Button Kopie mapButton
5 Anchor Anchor Kopie mapAnchor
6 TextInput TextInput Kopie mapTextInput
7 PresentationProperty PresentationProperty Kopie mapProperty
8 Form InputForm Umbenennen. Die Attribute elements
sollen als PresentationProperties
der InputForm hinzugefügt
werden
mapForm
9 Choice Selection Umbenennen mapChoice
10 Page PresentationPage Umbenennen mapPage
11 PresentationClass PresentationGroup Umbenennen mapPresClass
12 PresentationGroup PresentationGroup Nicht mehr unterstützt, stattdessen
PresentationGroup
13 AnchoredCollection IteratedPresentationGroup Elemente werden mit Iterated-
PresentaitonGroup ersetzt, wobei
Anchors als PresentationProperties
zu dieser hinzugefügt werden
14 —— Attribute collapse
und dragdrop
Neue RIA-spezifische Attribute sind
zu der Klasse PresentationGroup
hinzugefügt worden. Die Page, InputForm
und IteratedPresentation-
Group erben diese Attribute
mapPresGroup
mapAnchoredCol
mapPage,
mapPresentationGroup,
mapForm, mapAnchoredCol
Tabelle 4.1.: Alle Klassen des SimpleUWEold-Metamodells mit den entsprechenden Transformationsaktionen
und den Relationen.
geben sich drei Arten der Elemente des SimpleUWEold-Präsentationsmetamodells in Bezug
auf ihre strukturelle Beschaffenheit und die Platzierung in der Metamodellhierarchie:
• UI-Elemente, die PresentationProperties besitzen können: PresentationClass und seine
Unterklassen PresentationGroup und Page.
• PresentationProperties enthalten eine Assoziation presentationElement auf das entsprechenden
UI-Element, das in der PresentationClass beinhaltet ist. Dieses UI-Element
kann wiederum ein PresentationClass oder deren Erbe sein oder ein einfaches UI-
Element, wie unten beschrieben.
• Die Erben der Klasse UIElement, die einfache UI-Elemente wie Text, Button, Anchor
usw. darstellen. Diese dürfen wiederum keine PresentationProperties besitzen.
Die Relationen einer Gruppe sind sehr ähnlich. Deswegen können im Weiteren repräsenta-
46

4.3. Transformationen zur automatisierten Modell-Co-Evolution basierend auf UWE-Metamodellen
Nr. SimpleUWEnew-Attribut Transformationsaktion Relationen
1 liveReport Neues RIA-spezifische Attribut vom
Typ Boolean ist zu der neuen abstrakten
Klasse ValuedElement hinzugefügt
worden. Die Text-, Image-
, Button-, Anchor-, TextInput- und
Selection-Elemente erben dieses Attribut
2 periodicRefresh Neues RIA-spezifische Attribut vom
Typ Boolean ist zu der neuen abstrakten
Klasse OutputElement hinzugefügt
worden. Die Text- und
Image-Elemente erben dieses Attribut
2 autoCompletion Neues RIA-spezifische Attribut vom
Typ Boolean ist zu der neuen abstrakten
Klasse InputElement hinzugefügt
worden. Die TextInputund
Selection-Elemente erben dieses
Attribut
2 liveValidation Neues RIA-spezifische Attribut vom
Typ Boolean ist zu der neuen abstrakten
Klasse InputElement hinzugefügt
worden. Die TextInputund
Selection-Elemente erben dieses
Attribut
Tabelle 4.2.: Attribute aus den Abstrakten Klassen.
mapText,
mapImage,
mapButton,
mapAnchor,
mapTextInput,
mapChoice
mapText, map-
Image
mapTextInput,
map-Choice
mapTextInput,
map-
AnchoredCol
tive Exemplare einer Gruppe vorgestellt werden. Alle Relationen sind im Anhang im vollen
Umfang B angegeben.
Die abstrakten Metaklassen können in dem Zielmodell mithilfe der Transformationen nicht
instanziert werden. In dem UWE-Präsentationsmetamodell in der Version 1.8 ist eine Anzahl
der abstrakten Klassen eingeführt worden. Die neuen abstrakten Klassen besitzen neue RIAspezifische
Attribute. Diese Attribute können in den jeweiligen Subklassen der abstrakten
Klasse in den dazugehörigen Relationen eingefügt werden. Die Attribute der Metaklassen
sind in der Tabelle 4.2 zusammengefasst, wobei die betroffenen nicht-abstrakten Subklassen
und die entsprechenden Relationen mit angegeben sind. Durch diese Lösung werden mithilfe
der Transformation die Modelle erstellt die zum neuen Metamodell im vollen Umfang
konform sind.
Alle Relationen außer mapProperty sollen top-level-Relationen sein, da jedes Element
des Modells transformiert werden soll (die Arten von Relationen wurden im Kapitel 4.2.2
betrachtet). Besitzen die Modellelemente PresentationProperties, so soll die non-top-level-
Relation mapProperty an der Stelle erzwungen werden, also nicht implizit, sondern explizit
durch Aufruf ausgeführt werden. Diese Aufrufe werden innerhalb der where-Klausel definiert
(siehe Kapitel 4.2.4).
1 transformation mapUWEversion ( s r c : SimpleUWEold , t r g : SimpleUWEnew )
2 {
47

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
3 top relation mapPackage {−− body −−}
4 top relation mapPage {−− body −−}
5 relation mapProperty {−− body −−}
6 top relation mapPresClass {−− body −−}
7 top relation mapPresGroup {−− body −−}
8 top relation mapText {−− body −−}
9 top relation mapAnchor {−− body −−}
10 top relation mapImage {−− body −−}
11 top relation mapButton {−− body −−}
12 top relation mapTextInput {−− body −−}
13 top relation mapAnchoredCol {−− body −−}
14 top relation mapForm {−− body −−}
15 }
Listing 4.13: Identifizierte Relationen
Als nächstes nehmen wir die Relation mapPackage genau unter die Lupe.
4.3.3. Die Relation für das Paket
In dem UWE-Präsentationsmodell ist eine klare hierarchische Struktur der Beziehungen
zwischen den Elementen festgelegt:
1 top relation mapPackage
2 {
3 pckgName : String ;
4 checkonly domain s r c srcPckg : SimpleUWEold : : Package
5 {
6 name = pckgName
7 } ;
8 enforce domain t r g tgtPckg : SimpleUWEnew : : Package
9 {
10 name = pckgName
11 } ;
12 −− Hier e i n e Bedingung : der Name des Packages −−
13 −− s o l l P r e s e n t a t i o n heißen −−
14 where
15 {
16 name = ’Presentation’ ;
17 }
18 }
Listing 4.14: Relation mapPackage
Auf dem obersten Level befindet sich das Präsentations-Package. Alle restlichen Präsentationselemente
befinden sich darin als packagedElements. Bei der Ausführung der Transformation
wird mit mapPackage angefangen. Danach werden die darauf folgenden Relationen
ausgeführt. Für das Präsentations-Paket wird im Zielmodell ein Präsentations-Paket mit
demselben Namen erzeugt.
48

4.3. Transformationen zur automatisierten Modell-Co-Evolution basierend auf UWE-Metamodellen
4.3.4. Die Relationen für die PresentationClass und deren Subklassen
Die Elemente vom Typ PresentationClass, Page und PresentationGroup wurden bei der
Metamodell-Evolution geändert. (Siehe Tabelle 4.1 in den Zeilen 10-13). Das Element PresentationClass
ist zu der PresentationGroup umbenannt worden. Das Element PresentationGroup
wird in der neuen Version nicht mehr unterstützt. Deswegen sollen die Elemente,
die als PresentationGroup in der alten Version definiert waren, durch die Elemente PresentationClass
umgesetzt werden, die in der neuen UWE-Präsentationsmetamodellversion
PresentationGroup heißen. Dies ist ein gutes Beispiel dafür, dass sehr tiefes Wissen über
die Beschaffenheit der Metamodelle unabdingbar ist. Hier sollen die Zusammenhänge genau
spezifiziert werden. Obwohl es so aussieht, als ob man die Elemente PresentationGroup in
die Elemente PresentationGroup der neuen Version überführt, hat sich die Semantik dieser
Elemente verändert. Das Element Page ist lediglich in das PresentationPage umbenannt
worden.
mapPage
Die Relationen für die Elemente PresentationGroup, Page und PresentationClass sind analog,
wobei bei dem Element PresentationClass als Oberklasse die Unterscheidung zwischen
dieser Klasse und deren Subklassen eingeführt werden soll. Die Auflösung dieser Vererbung
wird später im Kapitel 4.3.4 behandelt. Im folgenden Listing ist die komplette mapPage-
Relation dargestellt.
1 −− Relation mapPage mappt Page auf PresentationPage . −−
2 −− P r e s e n t a t i o n P r o p e r t i e s werden übernommen −−
3 top relation mapPage
4 {
5 pageName : String ;
6 checkonly domain s r c srcPg : SimpleUWEold : : Page
7 {
8 namespace = srcPckg : SimpleUWEold : : Package {} ,
9 name = pageName ,
10 −− Es wird geprüft , ob page Stereotyp −−
11 −− b e i dem Page angewendet i s t −−
12 kind = ’page’ ,
13 ownedAttribute = presProp : SimpleUWEold : : PresentationProperty {}
14 } ;
15 enforce domain t r g trgPg : SimpleUWEnew : : PresentationPage
16 {
17 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
18 name = pageName ,
19 kind = ’presentationPage’ ,
20 −− Neue RIAs−Attribute , von PresentationGroup geerbt −−
21 c o l l a p s e = f a l s e ,
22 dragdrop = f a l s e ,
23 ownedAttribute = presProp2 : SimpleUWEnew : : PresentationProperty {}
24 } ;
25 when
26 {
27 mapPackage ( srcPckg , tgtPckg ) ;
49

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
28 }
29 where
30 {
31 −− B e s i t z t e i n e Page e i n e P r e s e n t a t i o n Property , −−
32 −− so wird d i e R elation mapProperty a u f g e r u f e n −−
33 mapProperty ( presProp , presProp2 ) ;
34 }
35 }
Listing 4.15: Relation mapPage
Mithilfe folgenden Zuweisung ” namespace = srcPckg : SimpleUWEold::Package“ in der Zeile
7 des Listings 4.15 und ” namespace = trgPckg : SimpleUWEnew::Package“ in der Zeile 15
werden alle namespace selektiert, für die gilt, dass die Page in ihnen liegt. Bei diesen Zuweisungen
handelt es sich um object template expressions, die im Kapitel 4.2.5 erläutert
wurden. Laut unserem vereinfachten Metamodell existiert nur ein Package-Element: das
Präsentations-Paket. Soll das komplette UWE-Metamodell transformiert werden, so müssen
die unterschiedlichen Pakete des UWE-Metamodells auseinander gehalten werden.
Damit diese Relation im Falle, wenn für die Elemente srcPckg und trgPckg noch keine gültige
Werte vorliegen, funktioniert, muss eine Vorbedingung für die Pakete definiert werden. Dies
erfolgt innerhalb der when-Klausel. Somit wird bei jeder Ausführung der mapPage-Relation
die mapPackage-Relation aufgerufen, um für jedes PresentationPage-Element einen korrekten
Bezug zu entsprechendem Präsentations-Package herzustellen.
Ähnlich verhält es sich mit den Konstruktionen ” ownedAttribute = presProp : SimpleU-
WEold::PresentationProperty“ in der Zeile 9 des Listings 4.15 und ” ownedAttribute = presProp2
: SimpleUWEnew::PresentationProperty“ in der Zeile 17. Der Unterschied liegt darin,
dass die Elemente PresentationProperty erzwungen werden sollen, sobald ein Page aus
dem Quellmodell PresentationProperties besitzt. Dafür sorgt die Bedingung in der where-
Klausel, wo die Abarbeitung der non-top-level-Relation mapProperty durch den expliziten
Aufruf erfolgt. Dieses Verfahren entspricht dem Prinzip des rekursiven Abstiegs.
Das Attribut kind hält das Stereotyp des Modellelements fest. In der Zeile 10 des Listings
4.15 wird sichergestellt, dass kind den Wert page besitz. In der Zeile 17 des Listing 4.15
wird kind auf PresentationPage gesetzt. In dem neuen UWE-Metamodell sind in der Klasse
PresentationGroup neue Attribute für RIAs Features eingeführt: collapse und dragdrop vom
Typ boolean. Diese Attribute besitzen einen Default-Wert false, womit die Automatisierung
der Modell-Co-Evolution in diesem Fall ermöglicht wird.
Die Relation mapPresGroup für die Transformation der Elemente PresentationGroup ist
analog zu der Relation mapPage aufgebaut. Die einzige Abweichung besteht darin, dass in
der checkonly-Domäne die Quellmodellelemente vom Typ PresentationGroup stehen und
in der enforce-Domäne die Elemente des Zielmodells PresentationGroup stehen, die dem
ursprünglichen PresentationClass entsprechen. Interessanter wird es bei dem Presentation-
Class-Element des Quellmodells. Die Relation für die PresentationClass wird im nächsten
Abschnitt betrachtet.
50

4.3. Transformationen zur automatisierten Modell-Co-Evolution basierend auf UWE-Metamodellen
Die Unterscheidung zwischen den Unterklassen Page bzw. PresentationGroup und
deren Oberklasse PresentationClass
Wenn die Relation mapPresClass analog zu der mapPage-Relation und der mapPresGroup-
Relation definiert wird, so werden die Subklassen von der PresentationClass doppelt erzwungen.
Dies liegt daran, dass die Elemente Page und PresentationGroup die Erben des PresentationClass
sind. Bei der checkonly-Domäne der Relation mapPresentationClass werden die
beiden Subklassen als PresentationClasses erkannt und in der enforce-Domäne als PresentationGroups
mit allen Attributen und den PresentationProperties erneut erzwungen. Dieses
Problem kann dadurch behoben werden, dass in der when-Klausel außer der Vorbedingung
für die Pakete (siehe unter dem Kapitel 4.3.4) weitere Vorbedingungen definiert werden. Diese
Vorbedingungen stehen in den Zeilen 16 und 17 des Listings 4.16. Die Elemente vom Typ
PresentationClass sollen nur dann transformiert werden, wenn sie an keiner anderen Stelle
der Transformation als Argumente der mapPage bzw. der mapPresGroup Relation stehen.
Dies wird durch die Vorbedingungen ” not mapPage(pc, pg); “ und ” not mapPresGroup(pc,
pg); “ erreicht.
1 −− Relation mapPresClass mappt P r e s e n t a t i o n C l a s s auf P r e s e n t a t i o n −−
2 −− Group −−
3 top relation mapPresClass
4 {
5 className : String ;
6 checkonly domain s r c pc : SimpleUWEold : : P r e s e n t a t i o n C l a s s
7 {
8 namespace = srcPckg : SimpleUWEold : : Package {} ,
9 name = className ,
10 −− Es wird geprüft , ob p r e s e n t a t i o n C l a s s Stereotyp −−
11 −− b e i dem P r e s e n t a t i o n C l a s s angewendet i s t −−
12 kind = ’presentationClass’ ,
13 ownedAttribute = pp : SimpleUWEold : : PresentationProperty {}
14 } ;
15 enforce domain t r g pg : SimpleUWEnew : : PresentationGroup
16 {
17 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
18 name = className ,
19 −− Hier wird das Stereotyp presentationGroup −−
20 −− dem Z i e l e l e m e n t zugewiesen −−
21 kind = ’presentationGroup’ ,
22 −− neue RIA−A t t r i b u t s −−
23 c o l l a p s e = f a l s e ,
24 dragdrop = f a l s e ,
25 ownedAttribute = pp2 : SimpleUWEnew : : PresentationProperty {}
26 } ;
27 when
28 {
29 mapPackage ( srcPckg , tgtPckg ) ;
30 not mapPage ( pc , pg ) ;
31 not mapPresGroup ( pc , pg ) ;
32 }
33 where
51

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
34 {
35 −− B e s i t z t e i n P r e s e n t a t i o n Class e i n e P r e s e n t a t i o n Property , −−
36 −− so wird d i e R elation mapProperty a u f g e r u f e n −−
37 mapProperty ( pp , pp2 ) ;
38 }
39 }
Listing 4.16: Relation mapPresClass
Das ist die allgemeine Vorgehensweise in der relationalen QVT-Sprache, um die Subklassen
von deren Oberklassen zu unterscheiden. Im Folgenden betrachten wir die Relationen für die
einfachen UI-Elemente.
4.3.5. Die Relationen für einfache UI-Elemente
In der Tabelle 4.1 in den Zeilen 2-6 sind folgende Elemente zusammengefasst Text, Image,
Button, Anchor und TextInput. Die Elemente dieser Gruppe besitzen eine Gemeinsamkeit:
sie wurden bei der Metamodell-Evolution nicht verändert und sollen einfach kopiert werden.
mapText
Im nächsten Listing ist eine Relation zum Kopieren von dem Text-Element vorgestellt. Die
restlichen Elemente werden analog kopiert.
1 −− Die Relation mapText e r s t e l l t e i n e Kopie des Text−Elements −−
2 −− im Z i e l m o d e l l −−
3 top relation mapText
4 {
5 textName : String ;
6 checkonly domain s r c te : SimpleUWEold : : Text
7 {
8 namespace = srcPckg : SimpleUWEold : : Package {} ,
9 name = textName ,
10 −− Es wird geprüft , ob t e x t Stereotyp −−
11 −− b e i dem Text angewendet i s t −−
12 kind = ’text’
13 } ;
14 enforce domain t r g te2 : SimpleUWEnew : : Text
15 {
16 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
17 name = textName ,
18 −− Hier wird das Stereotyp t e x t −−
19 −− dem Z i e l e l e m e n t zugewiesen −−
20 kind = ’text’ ,
21 p e r i o d i c R e f r e s h = f a l s e ,
22 l i v e R e p o r t = f a l s e
23 } ;
24 when
25 {
26 mapPackage ( srcPckg , tgtPckg ) ;
52

4.3. Transformationen zur automatisierten Modell-Co-Evolution basierend auf UWE-Metamodellen
27 }
28 }
Listing 4.17: Relation mapText
Wie bei allen Elementen des Präsentationspakets wird mithilfe des object template expressions
für das namespace und der Vorbedingung in der when-Klausel sichergestellt, dass
für die Elemente srcPckg und trgPckg gültige Werte vorliegen. Nach der Abarbeitung der
mapText-Relation wird im Zielmodell ein text-Element mit dem Namen des Quelltextelements
erzwungen. Im Weiteren werden die Relationen der UI-Elemente betrachtet, die im
Rahmen der Modell-Co-Evolution angepasst werden müssen.
4.3.6. Die Relation mapForm
Das Element Form wurde im Laufe der Metamodell-Evolution umbenannt und soll in der
neuen Version des UWE-Präsentationsmodells InputForm heißen. Darüber hinaus hat sich
ebenso die Position des Elements in der Hierarchie der PresentationElements verändert. Im
neuen Metamodell gehört inputForm zu der Gruppe der Elemente, die PresentationProperties
besitzen dürfen. Das Element InputForm ist eine Subklasse der PresentationGroup neben
den Elementen PresentationPage und einem neuen Element IteratedPresentationGroup.
1 −− Relation mapForm mappt das Element Form −−
2 −− auf das Element InputForm des Z i e l m o d e l l s −−
3 −− und f ü g t a l l e elements des u r s p r ü n g l i c h e n −−
4 −− FormElements a l s P r e s e n t a t i o n P r o p e r t i e s hinzu −−
5 top relation mapForm
6 {
7 formName : String ;
8 formElemName : String ;
9 checkonly domain s r c form : SimpleUWEold : : Form
10 {
11 namespace = srcPckg : SimpleUWEold : : Package {} ,
12 name = formName ,
13 −− Es wird geprüft , ob form Stereotyp −−
14 −− b e i der Form angewendet i s t −−
15 kind = ’form’ ,
16 elements = e l s : SimpleUWEold : : UIElement
17 {
18 name = formElemName
19 }
20 } ;
21 enforce domain t r g iform : SimpleUWEnew : : inputForm
22 {
23 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
24 name = formName ,
25 −− Hier wird das Stereotyp inputForm −−
26 −− dem Z i e l e l e m e n t zugewiesen −−
27 kind = ’inputForm’ ,
28 −− Neue RIAs−Attribute , von PresentationGroup geerbt −−
29 c o l l a p s e = f a l s e ,
30 dragdrop = f a l s e ,
53

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
31 −−i n l i n e Erzeugung von FormElementen −−
32 ownedAttribute = presProp : SimpleUWEnew : : PresentationProperty
33 {
34 name = formElemName ,
35 presentationElement = pe : SimpleUWEnew : : PresentationElement {}
36 }
37 } ;
38 when
39 {
40 mapPackage ( srcPckg , tgtPckg ) ;
41 mapText ( e l s , pe ) or mapImage ( e l s , pe ) or mapAnchor ( e l s , pe ) or
mapTextInput ( e l s , pe ) or mapButton ( e l s , pe ) or mapChoice ( e l s ,
pe ) ;
42 }
43 }
Listing 4.18: Relation mapForm
Zum einem gehört die Umbenennung eines Elements zu ganz einfachen Co-Evolution Änderungen.
Zum anderen liegt hier eine Änderung des Metamodells vor, welche die semantischen
Änderungen an dem Metamodell mit sich bringt. Um die Co-Evolution dieser Elemente zu
verwirklichen, muss man über vertieftes Wissen über die Semantik und die Beschaffenheit
der Metamodelle verfügen.
In diesem Fall ist die Relation so definiert worden, dass die Elemente, die der Form als
Attribute elements zugeordnet waren, in die neue inputForm als PresentationProperties hinzugefügt
werden (siehe Zeilen 9-13 und 19-24 des Listings 4.18). In Form von elements dürfen
zu einer Form verschiedene UIElements hinzugefügt werden, solche wie Text, Image, Button,
Anchor und TextInput (siehe UWE-Metamodell 1.8 in der Abbildung 3.5 im Kapitel 3.4.1).
In der Relation mapForm wird ein Domänenmuster für elements ähnlich wie bei namespace
mit einer object template expression umgesetzt. Damit sichergestellt werden kann, dass
ein entsprechender gültiger nicht-abstrakter UI-Element existiert. Es wird mithilfe einer Vorbedingung
in der when-Klausel geprüft, ob so ein Element bereits erzwungen wurde. Wenn
das nicht der Fall ist, wird abhängig vom UI-Element eine entsprechende Relation aufgerufen
(siehe Zeile 28 in dem Listing 4.18). Es wird entweder mapText oder mapButton oder
mapTextInput usw. aufgerufen.
Als Argumente bekommen die Relationsaufrufe in der Zeile 28 die abstrakten Oberklassen
der Elemente vom Typ PresentationElement. Dies ist kein Problem, da eine Form als elements-Attribute
konkrete nicht-abstrakte UI-Elemente besitzt. Alle einfachen UI-Elemente
sollen bereits existieren, da alle Relationen außer mapProperty die top-level-Relationen
sind. Die Bedingung in der when-Klausel erzwingt diese Relationen, wenn sie noch nicht
ausgeführt worden sind und sorgt damit für die Korrektheit der Attribute und der Beziehungen
zwischen den Elementen. Die PresentationProperties in dem enforce domain-Teil
werden mit der inline object - Erzeugung erzwungen. Dieses Konstrukt wurde im Kapitel
4.2.5 näher erläutert.
54

4.3. Transformationen zur automatisierten Modell-Co-Evolution basierend auf UWE-Metamodellen
4.3.7. Die Relation mapAnchoredCol
Die Elemente der AnchoredCollection werden in dem neuen UWE-Präsentationsmodell nicht
mehr unterstützt. Wäre dies eine einfache Löschaktion, so müsste bei der Transformation für
diese Elemente keine Relation angegeben werden und somit würden keine Elemente im neuen
Modell erzwungen. In diesem Fall ist die Metamodelländerung, ähnlich wie bei der Form von
der Semantik des Metamodells abhängig. Die Elemente der AnchoredCollection werden nicht
mehr unterstützt. Stattdessen sollen neue Elemente der IteratedPresentationGroup verwendet
werden, wobei die Attribute anchors des AnchoredCollection als PresentationProperties
des IteratedPresentationGroup definiert werden sollen.
1 −− Relation mapAnchoredCol mappt Element AnchoredCollection −−
2 −− auf d i e Elemente IteratedPresentationGroup des Z i e l m o d e l l s −−
3 −− und f ü g t a l l e Anchors des u r s p r ü n g l i c h e n Elements a l s −−
4 −− P r e s e n t a t i o n P r o p e r t i e s hinzu −−
5 top relation mapAnchoredCol
6 {
7 acName : String ;
8 anchorName : String ;
9 checkonly domain s r c ac : SimpleUWEold : : AnchoredCollection
10 {
11 namespace = srcPckg : SimpleUWEold : : Package {} ,
12 name = acName ,
13 −− Es wird geprüft , ob a n c h o r e d C o l l e c t i o n Stereotyp −−
14 −− b e i dem AnchoredCollection angewendet i s t −−
15 kind = ’anchoredCollection’ ,
16 anchors = ancs : SimpleUWEold : : Anchor
17 {
18 name = anchorName
19 }
20 } ;
21 enforce domain t r g t i 2 : SimpleUWEnew : : IteratedPresentationGroup
22 {
23 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
24 name = acName ,
25 −− Hier wird das Stereotyp i t e r a t e d P r e s e n t a t i o n G r o u p −−
26 −− dem Z i e l e l e m e n t zugewiesen −−
27 kind = ’iteratedPresentationGroup’ ,
28 −− Neue RIAs−Attribute , von PresentationGroup geerbt −−
29 c o l l a p s e = f a l s e ,
30 dragdrop = f a l s e ,
31 −−i n l i n e Erzeugung von Anchors −−
32 ownedAttribute = presProp : SimpleUWEnew : : PresentationProperty
33 {
34 name = anchorName ,
35 presentationElement = pe : SimpleUWEnew : : PresentationElement {}
36 }
37 } ;
38 when
39 {
40 mapPackage ( srcPckg , tgtPckg ) ;
41 mapAnchor ( ancs , pe ) ;
55

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
42 }
43 }
Listing 4.19: Relation mapAnchoredCol
Im Listing 4.19 wird das Domänenmuster für Anchors genau wie bei der Form mit einer
object template expression umgesetzt. Somit kann sichergestellt werden, dass ein entsprechender
gültiger Anchor-Element existiert, wird mithilfe einer Vorbedingung in der when-
Klausel geprüft, ob so ein Element bereits erzwungen wurde. Mit enforce domain werden
PresentationProperties, die die Anchors beinhalten, mithilfe der inline object-Erzeugung
erzwungen (siehe Zeile 19 des Listings 4.19). Dabei wird das Attribute presentationElement
der PresentationProperty in der Zeile 22 als ein abstraktes PresentationElement deklariert
und in der Zeile 28 als Argument für den Aufruf des mapAnchor in der when-Klausel verwendet.
Bei der Abarbeitung dieser Relation handelt es sich dann ausschließlich um die
nicht-abstrakte Anchors, somit werden keine Fehler bei der Transformation entstehen.
4.3.8. Die Relation mapProperty
Zuletzt wird eine einzige non-top-level-Relation mapProperty betrachtet. Von Metamodell
her wurden bei der Metamodellevolution keine Änderungen an diesem Metamodellelement
vorgenommen. So wird nachstehend für PresentationProperty eine Kopier-Relation definiert:
1 relation mapProperty
2 {
3 propName : String ;
4 checkonly domain s r c pp : SimpleUWEold : : PresentationProperty
5 {
6 name = propName ,
7 presentationElement = pe : SimpleUWEold : : PresentationElement
8 {
9 }
10 } ;
11 enforce domain t r g pp2 : SimpleUWEnew : : PresentationProperty
12 {
13 name = propName ,
14 presentationElement = pe2 : SimpleUWEnew : : PresentationElement
15 {
16 }
17 } ;
18 when
19 {
20 −− Sobald e i n e PresentationProperty einen Presentation − −−
21 −− Element b e s i t z t , s o l l d i e entsprechende Relation a u f g e r u f e n −−
22 −− werden −−
23 mapText ( pe , pe2 ) or mapAnchor ( pe , pe2 ) or mapImage ( pe , pe2 ) or
mapButton ( pe , pe2 ) or mapTextInput ( pe , pe2 ) or mapAnchoredCol (
pe , pe2 ) or mapPresClass ( pe , pe2 ) or mapPresGroup ( pe , pe2 ) or
mapForm( pe , pe2 ) ;
24 }
25 }
56

4.4. Die Durchführung der Transformationen mit dem mediniQVT-Tool
Listing 4.20: Die Relation mapProperty
Im Listing 4.20 wird der Name der PresentationProperty unter dem Einsatz von der Variable
propName in die Ziel-Property übernommen. Außerdem wird die Assoziation presentation-
Element mit object template expression umgesetzt. Hierbei sind die Attribute presentationElement
in den Zeilen 7 und 14 des Listings 4.20 als abstrakte Elemente des Typs
PresentationElement deklariert. In der when-Klausel stehen Aufrufe der möglichen Relationen,
die mit der ODER-Verknüpfung verbunden sind. Dabei sind hier alle Relationen außer
der mapPage vorhanden. Die Page steht stets als Strukturelement eines Pakets und darf
daher nicht in der PresentationProperties eines PresentationClass oder deren Subklassen
vorkommen.
4.4. Die Durchführung der Transformationen mit dem
mediniQVT-Tool
In den vorausgehenden Kapiteln wurde die Transformation vorgestellt, welche die automatisierte
Modell-Co-Evolution der vereinfachten UWE-Präsentationsmodelle veranschaulicht.
Für die Durchführung dieser Transformation sollten einige Aktionen vorab erledigt werden.
Der ganze Prozess ist manuell vorbereitet und durchgeführt worden. Eine Transformation
Abbildung 4.2.: Die Durchführung der Transformation.[19]
überführt Modelle ineinander, die auf der Basis von spezifizierten Metamodellen definiert
sind. Dabei besteht die Transformation aus einer Anzahl von Relationen, die auf der Basis
57

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
von Metamodellen gültige Beziehungen zwischen den Elementen der Modelle beschreibt. Außer
einem Transformationsskript in der relationalen QVT-Sprache und einem Quellmodell
sollen das Quell-Metamodell, sowie das Ziel-Metamodell in speziellen formalen Formen mit
eingebunden werden. Das Zielmodell einer Transformation resultiert aus deren Ausführung.
Die Durchführung einer Transformation mit mediniQVT setzt voraus, dass die für die Transformation
benötigten Metamodelle sowie deren Instanzen mithilfe Eclipse Modeling Framework,
das im Kapitel 2.5 bereits beschrieben wurde, erstellt sind. Der Prozess der Erstellung
und Durchführung einer Transformation wird in der Abbildung 4.6 veranschaulicht.
Im Kapitel 3.4 wurden die beiden Versionen der Präsentations-Metamodell vorgestellt und
die Differenzen zwischen diesen Metamodellversionen in der Tabelle 3.3 zusammengefasst.
Für die Transformation werden Metamodelle nach dem Verständnis der MOF in Form von
UML2-Klassendiagrammen in Ecore-Format definiert, das im Kapitel 2.5.1 vorgestellt wurde.
Im Anhang A ist detailliert beschrieben wie diese Metamodelle in einer serialisierten Form
(Eclipse Ecore Format) erstellt werden. Wobei die Metamodelle im Eclipse Ecore Format
dem generellen EMOF-Format (Essential Meta Object Facility) weitgehend äquivalent sind.
Aus den Metamodellen in Ecore Format werden automatisch EMF-Modelle (siehe Eclipse
Modeling Framework im Kapitel 2.5) vom Typ ” genmodel“ erstellt, die als eine Basis für
die Generierung der Editor-Eclipse-Plug-ins dienen können. (Genaue Vorgehensweise hierzu
ist im Anhang A.2 erläutert) Die aus Generator-Modell generierte Eclipse-Plug-ins stellen
Editoren bereit, die es erlauben die formalen Modelle im Sinne der vordefinierten Metamodelle
zu erstellen. (Siehe Anhang A.3)
Die OMG hat für den Austausch von formalen Modellen das XML Metadata Interchange
(XMI)-Format definiert, um speziell formale Modelle in ihrer flachen, textuell repräsentierten
Struktur als Grundlage der Transformation bereitstellen zu können.
58

4.5. Ein Beispiel für metamodellbasierte Modell-Co-Evolution
4.5. Ein Beispiel für metamodellbasierte Modell-Co-Evolution
In diesem Abschnitt wird ein Beispiel vorgeführt, welches die metamodellbasierte Modell-
Co-Evolution für das Modell Adressbuch präsentiert. Da die Modelle in der Form in der sie
in die Transformation eingehen ziemlich unübersichtlich sind, wird nur ein Ausschnitt aus
den Modellen vorgeführt.
4.5.1. Die Durchführung der Transformation an dem Adressbuch-Modell
Das Präsentationsmodell des Adressbuches in der Version 1.7 wird als Quellmodell genommen.
In der Abbildung 4.3 ist das Modell zu sehen. Das Quellmodell wird in einem ge-
Abbildung 4.3.: Das Präsentationsmodell für das Adressbuch in der Version 1.7.
nerierten SimpleUWEold-Editor in der speziellen textuellen Form erstellt. Die Informationen
über das erstellte Modell sind in der AddressBook.simpleuweold Datei gespeichert. Das
Modell soll in dem XMI-Format in die Transformation eingehen. Deswegen soll die Datei
AddressBook.simpleuweold in die Datei AddressBook.xmi umbenannt werden. Somit kann
diese Datei in der Transformationskonfiguration angegeben werden.
Während der Ausführung der Transformation wird das Zielmodell für das Adressbuch generiert,
das zu dem SimpleUWEnew Metamodell konform ist. In der Abbildung 4.4 sind die
beiden Modelle nebeneinander abgebildet.
Das Präsentationsmodell des Adressbuches in der Version 1.7 ist in einem SimpleUWEold-
Editor angezeigt. Das Präsentationsmodell des Adressbuches in der Version 1.8 ist dagegen
in einem SimpleUWEnew-Editor angezeigt. Die Elemente sind in ihrer baumartigen Struktur
abgebildet. In der ” Properties“-Ansicht werden die Detailinformationen über ein ausgewähltes
Element angezeigt. In der Abbildung ist sowohl in der alten, als auch in der neuen
Version das Form-Element, namens ” SearchForm“ ausgewählt. In der alten Version besitzt
59

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
Abbildung 4.4.: Das AddressBook vor und nach der Ausführung der Transformation in der
textuellen Präsentation.
die Form folgende elements-Attribute: den TextInput namens ” SearchCriterion“ und den
Button namens ” Search“. Die Transformation hat diese Attribute in die gleichnamige PresentationProperties
überführt, jeweils vom Typ TextInput und Button. Diese sind in der
Abbildung grün gekennzeichnet.
Außerdem ist zu sehen, dass die Page-Elemente AddressBook“ und Message“ in die gleich-
” ”
namige PresentationPage-Elemente transformiert wurden. Das PresentationClass-Element
” Contact“ ist in ein entsprechendes PresentationGroup-Element mithilfe der Transformation
überführt worden.
60

4.5. Ein Beispiel für metamodellbasierte Modell-Co-Evolution
4.5.2. Die Konfiguration einer Transformation in mediniQVT
Vor der Ausführung der Transformation sollen die Metamodelle in der QVT-Umgebung deklariert
werden. Diese Einstellung erfolgt über das Menü ” Preferences“. Es kann ein beliebi-
Abbildung 4.5.: Die Deklaration der Metamodelle in der mediniQVT-Umgebung.
ges Instanz des SimpleUWEold-Metamodell mithilfe der Transformation auf die neue Version
des Metamodells migriert werden. Hier wird als Beispiel für das Quellmodell das AdressBuch-
Modell von der UWE-Webseite genommen. 1 Neben dem Transformationsskript sollen das
Abbildung 4.6.: Die Run-Konfiguration der Transformation.
Quell- und das Zielmodell angegeben werden. Als Richtung der Transformationsausführung
soll das Ziel, in dem Fall trg ausgewählt werden.
1 http://uwe.pst.ifi.lmu.de/exampleAddressBookWithContentUpdates.html
61

4. Modell-Co-Evolution. Metamodellbasieter transformativer Ansatz
4.6. Zusammenfassung
In diesem Kapitel wurde demonstriert, wie eine Transformation mithilfe der relationalen
QVT-Sprache für die Modell-Co-Evolution aussehen kann. Hierbei besteht eine solche Transformation
zum Teil aus Kopier-Relationen, welche die Elemente, die infolge der Metamodell-
Evolution nicht geändert wurden, kopieren. Zum anderen Teil besteht die Transformation
aus den Relationen, die Elemente, die sich infolge der Metamodell-Evolution geändert haben
auf entsprechende Elemente des neuen Metamodells abbilden. Es hat sich bei der Analyse der
Metamodelländerungen zwischen UWE-Präsentationsmetamodell in der Version 1.7 und in
der Version 1.8 ergeben, dass Modell-Co-Evolution vollkommen automatisiert erfolgen kann.
Dies ist möglich, weil alle Metamodell-Änderungen zu dem Typ ” unbreaking changes“ oder
zu dem Typ ” breaking and resolvable changes“ zugeordnet sind. Außer der vollkommen automatisierten
Co-Evolution kann man die zu transformierenden Modelle zusätzlich während
der Transformationsabarbeitung validieren lassen, indem man mithilfe OCL-Ausdrücken Invarianten
innerhalb der where-Klauseln und Vorbedingungen innerhalb der when-Klauseln
festlegt.
Man kann von den Änderungsarten ausgehend den größten Teil der Relationen über die
vordefinierten Transformationsmuster definieren. In manchen Fällen, wie es z.B. bei der Form
und AnchoredCollection vorher der Fall war, gibt es Abweichungen von dem Allgemeinfall.
Man kann nur mithilfe semantischen Wissens über entsprechende Metamodelle und deren
Änderungen mehr Einzelheiten und Informationen auf unterschiedlichen Wegen in die neue
Version übernehmen. Dies sind für jedes Metamodell eine spezifische Besonderheiten, die sich
nicht kategorisieren lassen. Im Großen und Ganzen ist aber die Typologie aus dem Kapitel 3
sehr hilfreich bei der Definition der Transformation, sodass man von Transformationsmustern
sprechen kann.
In diesem Kapitel wurde illustrativ vorgestellt, wie Modell-Co-Evolution für Metamodellbasierte
UWE-Modelle unter dem Einsatz der Transformationen durchgeführt werden kann.
Dadurch wurde zwar bewiesen, dass die Modell-Co-Evolution gemäß der Überlegungen aus
dem Kapitel 3 für UWE-Modelle funktioniert, aber es wurde damit keine anwendbare Lösung
für die Modell-Co-Evolution der UWE-Modelle angeboten. Bei der Modellierungsumgebung
für UWE-Modelle werden diese nicht als Instanzen derer Metamodelle definiert, sondern als
UML-Modelle unter einer Anwendung von UWE-Profil. Der in diesem Kapitel beschriebener
Ansatz zur Definition der Ecore-Metamodelle liefert eine schwergewichtige Erweiterung
des UML im Rahmen der UWE-Methodologie. Das UWE setzt auf die UML-Profile als eine
leichtgewichtige Erweiterung der UML. Die oben vorgeführten Transformationen sollen
für eine Integration in die Toolumgebung der UWE-Methodologie im nächsten Abschnitt
angepasst werden.
62

5. Integration des UWE-Profil-basierten
transformativen Ansatzes in die UWE
Toolumgebung
In diesem Kapitel wird eine Basis für die Integration des transformativen Ansatzes in eine
Toolumgebung für UWE-Methodologie vorgestellt. Zuerst wird die UWE-Profil-basierte
Transformation für die UWE-Modelle mit dem angewendeten UWE-Profil aus der metamodellbasierten
Transformation siehe Kapitel 4 abgeleitet. Anschließend wird eine Toolumgebung
für die Integration des UWE-Profil-basierten transformativen Ansatzes ausgewählt.
Nach einer Anforderungsanalyse an diese Integration wird diese Integration detailliert beschrieben.
5.1. Anpassung der metamodellbasierten Transformation für
UWE-Modelle
In Kapitel 4.3.2 vorgestellte Transformation für die UWE-Modell-Co-Evolution basiert auf
den Metamodelländerungen, welche durch die Metamodell-Evolution entstanden sind (siehe
Kapitel 4). Die Definition eigener UWE-Metamodelle mithilfe des Eclipse Modeling Frameworks,
die im Kapitel 4 vorgestellt wurde, liefert eine schwergewichtige Erweiterung der
UML. Das UWE-Profil dagegen ermöglicht eine leichtgewichtige Erweiterung der UML. Es
soll an dieser Stelle eine Strategie vorgeschlagen werden, die es erlaubt aus der metamodellbasierten
Transformation eine UWE-Profil-basierte Transformation abzuleiten. Die Grundlage
dafür liefern die Mappings, die bei der UWE-Metamodelldefinition zusätzlich definiert sind.
Jedem nicht-abstrakten Element des UWE-Metamodells wird ein Stereotyp im UWE-Profil
zugeordnet:
UWE-Metamodellklasse UWE-Stereotype
PresentationClass
PresentationGroup
Page
PresentationProperty
Text
TextInput
Anchor
AnchoredCollection
Button
Image
Form
63

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
Das UWE-Profil der Version 1.7 wird in der Abbildung 5.1 veranschaulicht. Somit lassen
sich neue Relationen für die UWE-Profil-basierte Transformation aus den entsprechenden
Relationen der metamodellbasierten Transformation (aus Kapitel 4.3) für jedes UWE-
Profilelement direkt ableiten.
Jedes UWE-Modell wird als UML2 Modell definiert, wobei das UWE-Profil auf dieses Modell
angewendet wird. Auf die Klassen des Modells werden bestimmte UWE-Stereotypen angewendet.
Die Attribute werden als TaggedValues aus dem UWE-Metamodell übernommen.
Abbildung 5.1.: Das UML-Profil in Version 1.7
Als Metamodell wird bei der UWE-Profilbasierten Transformation das Eclipse UML2 Metamodell
in Ecore-Format verwendet, dass im Kapitel 2.5.2 bereits beschrieben wurde. Diese
Umstellung auf das neue Metamodell bringt einige Anpassungen an der Transformation aus
Kapitel 4.3 mit sich, die im Weiteren erläutert werden.
5.1.1. Der Zugriff auf die angewendeten UWE-Stereotypen
Das Quellmodell für die Transformation ist in Form eines UML 2 Modells angegeben, wobei
einige UWE-Stereotypen auf die Klassen dieses Modells angewendet wurden. Im Fall des
Präsentationsmodells sind alle eingesetzten Klassen mit den UWE-Stereotypen markiert. Im
Rahmen der Transformation werden folgende Hilfsfunktionen definiert, die einen Zugriff auf
ein Stereotyp anhand seines Namens ermöglicht: die getStereotype und die getStereotypes.
Hier sind die Hilfsfunktionen bis auf ihren Rückgabenwerttyp identisch. Die zweite Funktion
64

5.1. Anpassung der metamodellbasierten Transformation für UWE-Modelle
liefert eine Menge der Stereotypen für einen bestimmten Stereotypnamen. Diese Hilfsfunktionen
können im Weiteren aus anderen Relationen unter den when-Klauseln aufgerufen
werden.
1 query g e t S t e r e o t y p e ( stName : String ) : Stereotype
2 {
3 Stereotype . a l l I n s t a n c e s ( )−>
4 s e l e c t ( x : uml : : Stereotype |
5 x . name = stName )−>
6 asSequence ( )−> f i r s t ( )
7 }
8
9 query g e t S t e r e o t y p e s ( stName : String ) : Sequence ( Stereotype )
10 {
11 Stereotype . a l l I n s t a n c e s ( )−>
12 s e l e c t ( x : uml : : Stereotype |
13 x . name = stName )−>
14 asSequence ( )
15 }
Listing 5.1: Die Hilfsfunktionen für das Zugriff auf ein angewendetes Stereotyp
Das UWE-Profil wird in der Transformationskonfiguration neben dem Quellmodell angegeben.
Somit ist während der Abarbeitung der Transformation der Zugriff auf all die verfügbaren
UWE-Stereotypen gewährleistet. Unter einer when-Klausel einer Relation, kann somit
abgefragt werden, ob ein Stereotyp mit vorgegebenen Namen auf eine Klasse angewendet
ist.
1 when
2 {
3 s t = g e t S t e r e o t y p e ( ’text’ ) ;
4 s r c C l s . i s S t e r e o t y p e A p p l i e d ( s t ) ;
5 }
Listing 5.2: Die Anwendung des Stereotyps text wird unter der when-Klausel geprüft
Zuerst wird in einer Variablen st vom Typ uml:Stereotype anhand des Stereotypnamens der
Wert für den Stereotyp mithilfe der oben beschriebenen Hilfsfunktion gespeichert.
Dann kann mit Hilfe der isStereotypeApplied-Funktion geprüft werden, ob dieses Stereotyp
auf der Quellklasse srcCls angewendet ist.
5.1.2. Die neu angepasste Transformation
Die neuen Relationen sind den Relationen aus Kapitel 4.3 sehr ähnlich. Das Schreiben von
einem QVT-Skript in der relationalen QVT-Sprache, das auf dem Eclipse UML2 Metamodell
aufbaut, soll gemäß diesem Metamodell angepasst werden. Dies betrifft die Struktur
der Transformation. Um UML-Klassen transformieren zu können, wird die Transformation
rekursiv aufgebaut.
65

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
Die top-level-Relation
Bei einem rekursiven Aufbau gibt es nur eine top level-Relation, alle anderen Relationen
werden in den where-Klauseln aufgerufen. Das Präsentationspaket ist in dem Präsentationsmodell
enthalten. Das Model-Relation ist die einzige top-level-Relation. Die Relation
Packages wird in der where-Klausel der Relation Model aufgerufen.
1 transformation e v o l u t i o n P r o f i l ( source : uml , t a r g e t : uml )
2 {
3 key Class {name , owner } ;
4 key Property {name , owner } ;
5
6 top relation Model
7 {
8 modelName : String ;
9 checkonly domain source s r c : uml : : Model
10 {
11 name = modelName
12 } ;
13 enforce domain t a r g e t dst : uml : : Model
14 {
15 name = modelName
16
17 } ;
18 where
19 {
20 Packages ( src , dst ) ;
21 }
22 }
23 relation Packages
24 {
25 packageName : String ;
26 checkonly domain source srcPkg : uml : : Package
27 {
28 packagedElement = srcP : uml : : Package { name = packageName }
29 } ;
30 enforce domain t a r g e t dstPkg : uml : : Package
31 {
32 packagedElement = dstP : uml : : Package { name = packageName }
33 } ;
34 where
35 {
36 Packages ( srcP , dstP ) ;
37 Datatypes ( srcP , dstP ) ;
38 pageClasses ( srcP , dstP ) ;
39 P r e s C l a s s C l a s s e s ( srcP , dstP ) ;
40 t e x t C l a s s e s ( srcP , dstP ) ;
41 anchorClasses ( srcP , dstP ) ;
42 −− d i e r e s t l i c h e n Aufrufe werden wegen der Ü b e r s i c h t l i c h k e i t
n i c h t angegeben −−
43 }
44 }
66

5.1. Anpassung der metamodellbasierten Transformation für UWE-Modelle
Listing 5.3: Die Relationen für das Modell und das Paket
Unter der Verwendung des Eclipse UML 2 kann ein Objektausdruck in Form namespace =
trgPackage nicht angegeben werden, da namespace keine Informationen über die Pakete, in
denen eine Klasse enthalten ist, bereitstellt. Dies wird mithilfe von einem key umgegangen.
Eine Angabe von key erlaubt bei der Generierung von Zielelementen die Duplikate zu unterbinden.
Die in den Zeilen 3 und 5 des Listings 5.3 definierte keys für die Klassen und die
Properties lösen das Problem mit dem fehlenden Bezug der Klassen auf deren Paket. Sobald
eine Klasse mit einem eindeutigen Namen erzeugt wird, wird bei jedem Versuch diese Klasse
erneut zu erzeugen diese bereits existierende Klasse genommen. Dies entspricht der Tatsache,
dass innerhalb eines Pakets keine Klassen mit denselben Namen existieren dürfen.
Die Relation für den Text
Im Weiteren wird eine Relation für Textelemente betrachtet. Diese Relation ist nahezu identisch
zu der Relation mapText aus dem Kapitel 4. Unter der when-Klausel wird geprüft,
ob die Klasse mit dem -Stereotyp markiert ist. Bei dieser Relation werden ausschließlich
solche Klassen berücksichtigt.
1 −− Relation b e t r a c h t e t nur Klassen mit dem Stereotyp t e x t −−
2 relation t e x t C l a s s e s
3 {
4 s t : uml : : Stereotype ;
5 className : String ;
6 checkonly domain source s r c : uml : : Package
7 {
8 packagedElement = s r c C l s : uml : : Class
9 {
10 name = className
11 }
12 } ;
13 enforce domain t a r g e t dst : uml : : Package
14 {
15 packagedElement = dstCls : uml : : Class
16 {
17 name = className
18 }
19 } ;
20 when
21 {
22 s t = g e t S t e r e o t y p e ( ’text’ ) ;
23 s r c C l s . i s S t e r e o t y p e A p p l i e d ( s t ) ;
24 }
25 where
26 {
27 −− Klasse Text erbt von OutputElement das A ttribute
p e r i o d i c R e f r e s h −−
28 p e r i o d i c R e f r e s h A t t r i b u t e ( dstCls ) ;
29 −− Erbt von der S u p e r k l a s s e ValuedElement das Attribute
l i v e R e p o r t −−
67

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
30 l i v e R e p o r t A t t r i b u t e ( dstCls ) ;
31 }
32 }
1
Listing 5.4: Die Relation für die Textelemente
In Version 1.7 des UWE-Profils besitzt das Stereotyp keine Attribute in Form
einer TaggedValue. In Version 1.8 sind zwei neue Attribute dazugekommen: das periodicRefresh
und das liveReport. Das Text-Element erbt im UWE-Metamodell diese Attribute von
den abstrakten Klassen OutputElement und ValuedElement. Die Erzeugung dieser Attribute
wird in einer speziellen Relation erzwungen.
Im nächsten Listing ist die Relation für das liveReport-Attribut vorgestellt:
2 relation l i v e R e p o r t A t t r i b u t e
3 {
4 enforce domain t a r g e t oc : uml : : Class
5 {
6 ownedAttribute = op : uml : : Property
7 {
8 name = ’liveReport’ ,
9 v i s i b i l i t y = uml : : V i s i b i l i t y K i n d : : private ,
10 type = getDataTypeBoolean ( )
11 }
12 } ;
13 }
Listing 5.5: Die Relation für die Erzeugung eines liveReport-Attributs
Diese Relation verfügt ausschließlich über die enforce-Domäne. In der Zielklasse wird das
Attribute liveReport erzwungen.
Wie im Kapitel 4.3.2 bereits beschrieben, gehört der Text zu den einfachen UIElements.
Somit sind die Relationen für die Transformation der restlichen Subklassen des Elements
UIElement, solchen wie das Image, der Button und das Anchor der Relation textClasses
sehr ähnlich und werden im Weiterem nicht näher behandelt.
5.1.3. Die Relation für die PresentationClass
Die Relation für die Klassen, die mit dem -Stereotyp markiert sind,
sieht folgendermaßen aus:
1 −− Relation b e t r a c h t e t nur Klassen mit dem Stereotyp
p r e s e n t a t i o n C l a s s −−
2 relation P r e s C l a s s e s
3 {
4 s t : uml : : Stereotype ;
5 className : String ;
6 checkonly domain source s r c : uml : : Package
7 {
68

5.1. Anpassung der metamodellbasierten Transformation für UWE-Modelle
8 packagedElement = s r c C l s : uml : : Class
9 {
10 name = className
11 }
12 } ;
13 enforce domain t a r g e t dst : uml : : Package
14 {
15 packagedElement = dstCls : uml : : Class
16 {
17 name = className
18 }
19 } ;
20 when
21 {
22 s t = g e t S t e r e o t y p e ( ’presentationClass’) ;
23 s r c C l s . i s S t e r e o t y p e A p p l i e d ( s t ) ;
24 }
25 where
26 {
27 −− Kopiere bestehende P r o p e r t i e s −−
28 A t t r i b u t e s ( srcCls , dstCls ) ;
29 −− A l l e PresentationGroup und deren Subklassen b e s i t z e n −−
30 −− im neuen Metamodell A ttribute c o l l a p s e und dragdrop −−
31 c o l l a p s e A t t r i b u t e ( dstCls ) ;
32 dragdropAttribute ( dstCls ) ;
33 }
34 }
Listing 5.6: Die Relation für die PresentationClass
Wird bei der Abarbeitung der Transformation eine Klasse mit dem Stereotyp gefunden, so wird eine Klasse mit denselben Namen im Zielmodell erzeugt. Die
Properties der PresentationClass werden in der Attributes-Relation erzwungen. Im UWE-
Metamodell wurden zwei neuen Attribute der Klasse PresentationGroup hinzugefügt: collapse
und dragdrop. Diese Attribute werden analog wie das Attribute liveReport von Text in
einer ausgelagerten Relation der Zielklasse hinzugefügt.
Die presentationClass gehört zu der Gruppe der Elementen, die PresentationProperties besitzen
dürfen, genau so wie die PresentationGroup und die Page. Aus diesem Grund werden
die Relationen für die PresentationGroup und die Page nicht näher erläutert. Die Klassen
werden nach dem angewendeten Stereotyp unterschieden, somit wird auch strikt zwischen
der PresentationClass und deren Subklassen unterschieden.
Im Weiteren wird die Relation Attributes für die Erzeugung der Properties einer PresentationClass
beschrieben.
Die Relation für die PresentationProperty
In der UML 2 wird zwischen einfachen und komplexen Attributen unterschieden. In der
Relation Attributes werden in der where-Klausel dafür weitere Relationen aufgerufen: pri-
69

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
mitiveAttribute und complexAttribute. In der Relation primitiveAttribute werden die einfachen
UML-Datatypen als Attribute behandelt. Zum Beispiel kann eine Klasse aus dem
Quellmodell einen Attribute von Typ boolean oder String besitzen.
1 relation A t t r i b u t e s
2 {
3 checkonly domain source i c : uml : : Class
4 {
5 ownedAttribute = ip : uml : : Property {}
6 } ;
7 enforce domain t a r g e t oc : uml : : Class
8 {
9 ownedAttribute = op : uml : : Property {}
10 } ;
11 where
12 {
13 p r i m i t i v e A t t r i b u t e ( ip , op ) ;
14 complexAttribute ( ip , op ) ;
15 }
16 }
17
18 relation p r i m i t i v e A t t r i b u t e
19 {
20 propName : String ;
21 propType : uml : : DataType ;
22 p r o p V i s i b i l i t y : uml : : V i s i b i l i t y K i n d ;
23 checkonly domain source scrPr : uml : : Property
24 {
25 name = propName ,
26 v i s i b i l i t y = p r o p V i s i b i l i t y ,
27 type = propType
28 } ;
29 enforce domain t a r g e t trgPr : uml : : Property
30 {
31 name = propName ,
32 v i s i b i l i t y = p r o p V i s i b i l i t y ,
33 type = propType
34 } ;
35 when
36 {
37 not propType . oclIsTypeOf ( uml : : Class ) ;
38 }
39 }
40
41 relation complexAttribute
42 {
43 propName : String ;
44 className : String ;
45 p r o p V i s i b i l i t y : uml : : V i s i b i l i t y K i n d ;
46 checkonly domain source scrPr : uml : : Property
47 {
48 name = propName ,
49 v i s i b i l i t y = p r o p V i s i b i l i t y ,
70

50 type = c l s : uml : : Class
51 {
52 name = className
53 }
54 } ;
55 enforce domain t a r g e t trgPr : uml : : Property
56 {
57 name = propName ,
58 v i s i b i l i t y = p r o p V i s i b i l i t y ,
59 type = c l s 2 : uml : : Class
60 {
61 name = className
62 }
63 } ;
64 when
65 {
66 s t = g e t S t e r e o t y p e ( ’presentationProperty’) ;
67 scrPr . i s S t e r e o t y p e A p p l i e d ( s t ) ;
68 }
69 }
Listing 5.7: Die Relation für die PresentationProperties
5.2. Wahl der Toolumgebung
Die Relation primitiveAttribute erzwingt ein Attribut mit seinem Namen, der Sichtbarkeit
und dem Typ. Unter der when-Klausel wird folgende Bedingung aufgestellt:
not propType.oclIsTypeOf(uml::Class);
Diese sorgt dafür, dass in der Relation nur die Attribute mit einem einfachen Datentyp
berücksichtigt werden.
Die Relation complexAttribute ermöglicht die Erzeugung von PresentationProperties. Deren
Typ uml:Class ist. Der Name, die Sichtbarkeit und der Klassentyp der Property werden
im Zielmodell übernommen. Unter der when-Klausel wird zusätzlich geprüft, dass -Stereotyp auf die Quellproperty angewendet ist.
Inzwischen wurden alle drei Typen der Elementen des UWE-Präsentationsmodell betrachtet:
die einfachen UIElements, die Elemente, welche Properties besitzen dürfen und die Properties
selbst.
Wie aus den vorgestellten Relationsskripten entnommen werden kann, erfolgt keine Anwendung
der Stereotypen aus dem Profilversion 1.8 auf die Klassen des Zielmodells. Dieses
Problem sowie die Lösungsvorschläge für das Problem werden im Kapitel 5.5 näher angegangen.
5.2. Wahl der Toolumgebung
Die Transformation in der relationalen QVT-Sprache aus Kapitel 4.3 ist für die Modelle mit
angewendetem UWE-Profil angepasst worden und mit dem QVT-Werkzeug mediniQVT der
Version 1.7.0 erarbeitet und getestet worden, siehe Kapitel 5.1.2. Das Tool mediniQVT ist
71

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
ein Open Source Produkt, das die von der OMG veröffentlichte Spezifikation der relationalen
QVT-Sprache zur Zeit am vollständigsten abbildet[19] Das mediniQVT ist als Plug-in für
die Eclipse-Entwicklungsplattform implementiert.
Das Tool MagicDraw 1 verfügt über keine Implementierungen für die Modelltransformationen
in der relationalen QVT-Sprache. Die Transformationen können ausschließlich hart kodiert
in Java eingebettet werden. Dadurch gehen alle Vorteile der formalen Transformationen und
die Möglichkeit zur Validierung der Modelle während der Ausführung der Transformationen
verloren. Dies widerspricht den Grundideen des MDA. Hinzu kommt, dass es allgemein nicht
einfach ist, mit dem schlecht dokumentierten OpenAPI für MagicDraw zu operieren, wie Petar
Blagoev in seiner Arbeit [3] berichtete. Ebenso erläuterte Marianne Busch in [5], dass die
Verwendung des OpenAPIs nicht einfach ist. Aufgrund der Tatsache, dass der Quellcode von
MagicDraw nicht zur Verfügung steht, schließt dies die Verbesserung sowie die Erweiterung
der OpenAPI Funktionen aus. Diese Tatsache erschwert ebenfalls die Verwendung von bestimmten
APIs, wie z.B. MDT OCL Eclipse Bibliotheken 2 . Es ist nicht möglich herauszufinden
welche Version von MDT OCL Bibliotheken innerhalb der MagicDraw-Implementierung
verwendet wird. Dadurch ist die Implementierung wegen Versionskonflikt zwischen OCL-
Bibliotheken unmöglich. In einer Implementierung einer MagicUWE-Erweiterung für die
Validierung der UWE-Modelle wurde dafür ein interner Server implementiert, in den die
OCL-Constraints-Bearbeitung ausgelagert werden musste, um der Bibliothekinkompatibilität
auszuweichen. Zu guter Letzt fehlt es dem OpenAPI an der Flexibilität, was besonders
bei GUI-Entwicklung zur Last fällt.
Würde es keine anderen Möglichkeiten für die Integration des Transformationsansatzes in
die UWE-Methodologie geben, so müsste man sich mit der einzigen Integrationsmöglichkeit
zufriedengeben: die Transformationen hart codiert in Java für das Tool MagicUWE zu implementieren.
Letztens wurde ein zu MagicDraw alternatives Tool implementiert, mit dem UWE-Modelle
erstellt werden können. Dieses Tool soll an dieser Stelle in Betracht gezogen werden. Das
UWEclipse ist im Rahmen der Diplomarbeit ” Erweiterung eines Open Source-Werkzeugs
für die UML-basierte Modellierung von Webanwendungen“ von Dariya Sharonova entstanden.
Das UWEclipse ist die Nachbildung bzw. die Migration der MagicUWE-Funktionalität
in ein Open Source-Werkzeug vergleichbar mit MagicDraw Modellierungsmöglichkeiten[22].
Die im Rahmen der oben genannten Diplomarbeit entwickelte Software-Lösung für die Unterstützung
der UWE-Methodologie (UWEclipse) ist in den TOPCASED UML Editor integriert.
TOPCASED ist ein grafisches UML-Modellierungswerkzeug (Eclipse-basierte RCP),
das in Version 5.0.0 erweitert wurde. UWEclipse ist in Form eines Eclipse-Plug-ins entwickelt
worden. Auf diese Weise kann es problemlos in jede mit TOPCASED ausgestattete Eclipse-
Distribution integriert werden und auf der Funktionalität von TOPCASED aufbauen.[22]
In der Eclipse-Umgebung im Gegensatz zu MagicDraw steht eine Anzahl der QVT-Implementierungen
zur Verfügung. Unter anderem das Tool, namens mediniQVT 3 für die Durch-
1 http://uwe.pst.ifi.lmu.de/toolMagicUWE.html
2 http://www.eclipse.org/modeling/mdt/?project=ocl
3 http://projects.ikv.de/qvt
72

5.3. Die Anforderungsanalyse für die Integration des transformativen Ansatzes
führung der Transformationen in der relationalen QVT-Sprache, das im Kapitel 4.3 ausführlich
besprochen worden war. Sobald eine Transformation in der relationalen QVT-Sprache
für einen gegebenen Versionsübergang zur automatisierten Modell-Co-Evolution von existierenden
UWE-Modellen vorliegt, können beliebige Modelle dem Co-Evolution-Prozess
unterzogen werden. Das Tool TOPCASED mit mediniQVT und einer Kombination aus
ausgewählten Eclipse-Plug-ins erweitert, die im Weiteren beschrieben werden, soll dem Modellierer
eine Basis für die Durchführung der Modell-Co-Evolution schaffen.
Im nächsten Kapitel wird eine Anforderungsanalyse für die Integration des transformativen
Ansatzes in eine Eclipse-basierte Modellierungsumgebung beschrieben. Nachfolgend werden
ausgewählte Eclipse-basierte Tools näher vorgestellt, welche den Modell-Co-Evolutionsprozess
unterstützen sollen. Die Resultate und Probleme bei der Durchführung der Modell-Co-
Evolution für UWE-Modelle werden anschließend vorgestellt und Alternativen zur Lösung
der Probleme aufgezeigt.
5.3. Die Anforderungsanalyse für die Integration des
transformativen Ansatzes
Zuerst werden die funktionalen Anforderungen für die Durchführung des Modell-Co-Evolution-
Prozesses unter die Lupe genommen. Anschließend werden einige nicht-funktionale Anforderungen
gestellt und bestimmte Aspekte wie z.B. deren Bedienbarkeit diskutiert.
5.3.1. Die funktionalen Anforderungen
Dem Modellierer soll die automatisierte Modell-Co-Evolution im Rahmen einer Modellierungsumgebung
ermöglicht werden. Es wird vorausgesetzt, dass das neue und das alte UWE-
Profile vorliegen, ebenso wie das entsprechende Transformationsskript. Im Folgenden werden
die Anwendungsfälle für die Durchführung der Modell-Co-Evolution beschrieben.
Die Grundidee besteht darin, dass die Toolumgebung dem Modellierer zusätzliche Funktionalität
zur automatisierten Modell-Co-Evolution anbietet. Es soll möglich sein, dass für
ein beliebiges Modell, das unter Anwendung der alten Version des UWE-Profils erstellt wurde,
ein neues Modell generiert wird, das weitgehend all die Informationen des alten Modells
beinhaltet. Das neue generierte Modell geht mit der neuen Version des UWE-Metamodells
konform.
Die Anpassungen, die im Laufe der Modell-Co-Evolution vorgenommen wurden, sollen im
generierten Modell nach Bedarf gekennzeichnet werden, damit der Modellierer genau weiß,
auf welchem Weg das Modell transformiert wurde. Das heißt, dass die Elemente des Modells,
die aufgrund der Metamodell-Evolution geändert worden sind, hervorgehoben werden
sollen. Sollten im alten Metamodell Elemente vorhanden sein, deren Änderungstyp wegen
Metamodell-Evolution zu der Kategorie ” breaking and unresolvable changes“ zählen, so ist
eine automatisierte Transformation der Instanzen solcher Elemente nicht möglich. Diese Anpassungen
sind ohne menschliches Eingreifen nicht möglich. Sie werden bei der Transforma-
73

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
tion übersprungen. Diese Elemente sollten im ursprünglichen Modell nach Wunsch angezeigt
werden können. Dem Modellierer soll außerdem die Dokumentation für die Strategie der Anpassung
dieser Elemente zur Verfügung gestellt werden. Wie in der Zusammenfassung des
Kapitels 3 bereits beschrieben, kann die Eindeutigkeit des Modell-Co-Evolutionsprozesses
nur durch die genaue Spezifikation aller Anpassungsmöglichkeiten gewährleistet werden.
Insbesondere soll genau spezifiziert werden wie die Anpassungen der Modellelementen erfolgen
sollen, die durch ” breaking and unresolvable changes“ bedingt sind. Die Strategie für
die manuellen Anpassungsschritte solcher Elementen soll bei der Erarbeitung der Modell-
Co-Evolution aus der Metamodell-Evolution abgeleitet, dokumentiert und in Form einer
Spezifikation dem Modellierer zur Verfügung gestellt werden.
Die Instanzen der Metamodellelemente deren Änderungstyp wegen Metamodell-Evolution
zu der Kategorie ” breaking and resolvable changes“ zählen, werden mithilfe der Transformation
in die neuen geänderte Modellelemente überführt. Im Zielmodell soll die Hervorhebung
dieser Elemente möglich sein, um die Änderungen während der Transformation zu veranschaulichen.
Die Hervorhebung der Elemente soll sich in Abhängigkeit von der Metamodellmodifikation
an diesem Element unterscheiden. Entweder wurde das Element geändert oder
neu hinzugefügt. Gelöschte Elemente sind nicht mehr vorhanden und sollten im Quellmodell
hervorgehoben werden.
Im Weiteren werden unterschiedliche Möglichkeiten zur Hervorhebung dieser Elemente im
Bezug auf die Bedienbarkeit diskutiert.
5.3.2. Die nicht-funktionalen Anforderungen
Bei den nicht-funktionalen Anforderungen steht die Bedienbarkeit bzw. die Benutzerfreundlichkeit
im Vordergrund. Die genauen Beschreibungen für jedes konkretes Modellelement
für seine Modell-Co-Evolution sollen dem Modellierer zugänglich sein. Die Beschreibungen
der Co-Evolutionsstrategie könnten in Form von Zusatzinformationen zu jedem Element
im Modell hinzugefügt und mit angezeigt werden. Sind die Modelle komplex, an denen Co-
Evolution stattfinden soll, und wird bei jedem Element im Diagramm eine Zusatzinformation
diesbezüglich angezeigt, so werden die neu angepassten Modelle bald unübersichtlich und mit
Zusatzinformationen überladen. Dies sollte vermieden werden.
Es soll dem Modellierer auf jeden Fall ermöglicht werden die Anzahl und die Form der anzuzeigenden
Informationen zu konfigurieren. Außerdem soll die Kalkulation des neuen Modells,
also die tatsächliche Transformation, effizient verlaufen. Die Korrektheit der Ausführung des
Co-Evolution-Prozesses ist auch eine der wichtigsten Anforderungen. Im Folgenden sind die
nicht-funktionalen Anforderungen zusammengefasst:
74
• Die Bedienbarkeit
• Die Benutzerfreundlichkeit
• Die Konfigurierbarkeit
• Die Korrektheit
• Die Performanz

5.3. Die Anforderungsanalyse für die Integration des transformativen Ansatzes
Die Korrektheit ist dadurch gewährleistet, dass bei der Definition der Transformationen
vollständige Informationen über die Metamodelländerungen vorliegen. Die Transformation
selbst enthält die Vorbedingungen und Invarianten in der OCL-Sprache, die während der
Ausführung der Transformation geprüft werden. Somit wird stets ein korrektes Modell als
Ergebnis der Transformation geliefert. Die restlichen nicht-funktionalen Anforderungen werden
genauer angegangen.
Es ist notwendig, nach jeder Transformation deren Ergebnisse auch entsprechend zu visualisieren.
Da das UWE selbst eine Methodologie für die grafische Modellierung ist, hängt
die Benutzer-Akzeptanz sicherlich maßgeblich von der grafischen Darstellung der Modelldifferenzen
und Änderungen des Modells ab. Wünschenswert wäre natürlich eine Markierung
des geprüften Modells selbst, um so die Modelldifferenzen direkt im Modellierungswerkzeug
visualisieren und auch entsprechend bearbeiten zu können.
In den Kapiteln 3.2.2 bis 3.2.4 wurde zwischen additiven Änderungen, subtraktiven Änderungen
und Updates an einem Metamodell unterschieden. Dementsprechend werden diese
Aktionen an den existierenden Modellen während der Modell-Co-Evolution nachvollzogen.
Nach der Ausführung der Modell-Co-Evolution wird erwartet, dass die Unterschiede zwischen
dem Ursprungs- und dem Zielmodell hervorgehoben werden. Im Zielmodell soll die Hervorhebung
der Elemente möglich sein, um zu visualisieren welche Änderungen sie während der
Transformation erfahren haben. Die Hervorhebung der Elemente soll sich in Abhängigkeit
von der Metamodellmodifikation, die dieses Element betrifft, unterscheiden. Entweder wurde
das Element geändert oder neu hinzugefügt, die gelöschten Elemente sind nicht mehr vorhanden.
Die Umrandung der Elemente mit unterschiedlichen Farben würde diese kennzeichnen,
ohne das Modell mit Informationen zu überladen. Zum Beispiel könnten neu hinzugefügte
Elemente mit Grün umrandet sein und die geänderten Elemente mit Gelb.
Sind im alten Metamodell Elemente vorhanden, deren Änderungstyp wegen Metamodell-
Evolution zu der Kategorie ” breaking and unresolvable changes“ gehört, so ist eine automatisierte
Transformation solcher Elemente nicht möglich, somit werden diese bei der Transformation
übersprungen. Diese Elemente sollten im ursprünglichen Modell nach Wunsch
angezeigt werden können, z.B. mit einer roten Umrandung. Damit der Entwickler anhand
dieser Elemente entscheiden kann, ob und in welcher Form diese im neuen Modell übernommen
werden sollen. So kann vermieden werden, dass für das Modell relevante Informationen
aus Versehen verloren gehen. Sind in beiden Modellen farbige Umrandungen an den entsprechenden
Elementen vorhanden, so kann man die Unterschiede zwischen diesen auf einen
Blick sehen. Es sollte möglich sein die farbige Darstellung oder die Darstellung bestimmter
Änderungsgruppen auszublenden. Somit könnte man die Anzeige nach dem eigenen Bedarf
konfigurieren.
75

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
5.4. Die Anwendungsfälle
Für ein UWE-Modell, das in einer früheren UWE-Profil-Version entwickelt worden ist, soll
eine Transformation zur Modell-Co-Evolution gestartet werden können. Somit soll dieses
Modell in ein neues Modell automatisiert überführt werden, das mit der aktuellen Version
des UWE-Profils konform geht. Da die Überführung mithilfe einer Transformation atomar
abgearbeitet wird, ergeben sich folgende wenige Anwendungsfälle:
Abbildung 5.2.: Die Anwendungsfälle für den UWE-Co-Evolutionsprozess
In den nächsten Abschnitten folgt eine detaillierte Beschreibung der Anwendungsfälle.
5.4.1. Das UseCase ” Die Transformation für ein Modell durchführen“
Die Kurzbeschreibung
In der Entwicklungsumgebung soll in einer Run-Konfiguration der Speicherort des Quellund
des Ziel-Modells angegeben werden. Das Transformationsskript soll ebenfalls angegeben
werden, sowie die Richtung der Transformationsausführung.
Die Vorbedingung
Das Transformationsskript für den ausgewählten Versionsübergang liegt vor. Das Quell-
Modell ist konform zu dem entsprechenden Metamodell.
76

Die Nachbedingung
5.4. Die Anwendungsfälle
Das Zielmodell wird generiert, das zu dem neuen UWE-Metamodell konform ist.
5.4.2. Das UseCase ” Die Modelldifferenzen anzeigen lassen“
Die Kurzbeschreibung
Nachdem das Zielmodell unter Einsatz einer Transformation generiert wurde, soll die Berechnung
der Modelldifferenzen, sowie die farbige Darstellung dieser Differenzen ermöglicht
werden. An der ersten Stelle soll eine Berechnung der Modelldifferenzen für Modelle, die
in einer textuellen baumartigen Form repräsentiert sind, möglich sein. Eine graphische Repräsentation
der Modelldifferenzen soll ebenfalls möglich sein.
Die Vorbedingung
Das Quell-Modell und das generierte UWE-Modell liegen vor. Beide Modelle sind zu ihren
Metamodellen konform.
Die Nachbedingung
Die Modelldifferenzen sind aufgelistet. Diese Differenzen sind in der Baumstruktur der Modelle
bzw. der grafischen Repräsentation der Modelle entsprechend farblich hervorgehoben.
5.4.3. Das UseCase ” Die Konformität eines Modells zu seinem Metamodell
prüfen“
Die Kurzbeschreibung
Es soll dem Modellierer ermöglicht werden, die Konformität der Modelle prüfen zu lassen.
Anders ausgedrückt die Modelle zu validieren.
Die Vorbedingung
Die Beschränkungen (Constraints in der OCL-Sprache) für die Modellvalidierung liegen vor.
Die Nachbedingung
Das Ergebnis der Validierung wird angezeigt.
77

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
5.5. Die zusammengesetzte Toolumgebung
Das mediniQVT Tool basiert auf der Eclipse Plattform, genau wie das TOPCASED-Tool,
das in unserem Fall für die Definition der UWE-Modelle verwendet wurde.
Das Eclipse-Plug-in mediniQVT in der Version 1.7.0 lässt sich problemlos in das Tool TOP-
CASED in der Version 4.3.0 mit einbinden. Somit kann man ohne export/import Aktionen
zwischen den Tools, die Modelle den Transformationen unterziehen. Unsere erste Anforderung
war, dass der Modellierer mit wenigen Klicks die Transformation zur Modell-Co-
Evolution starten kann. Diese Anforderung ist bei der oben genannten Tool-Konstellation
bereits erfüllt. Für den Start der Modell-Co-Evolution Transformation soll lediglich eine
mediniQVT-Konfiguration für diese angegeben werden. Das zu transformierende Modell wird
als Input-Modell bei der Konfiguration angegeben. Es wird davon ausgegangen, dass für die
Konfiguration benötigte Metamodelle und das Transformationsskript bereits vorliegen. Mehr
wird nicht gebraucht. Die Transformation kann somit gestartet werden.
Der Anforderung für die farbige Darstellung der Modelldifferenzen zwischen dem Ursprungsund
dem Zielmodell wird nachgekommen, indem man das Eclipse-basierte EMF-Compare-
Tool einsetzt. Das EMF-Compare-Tool in der Version 1.2.2, berücksichtigt beim Vergleich
die Elemente und die Strukturen der Modelle. Die Ergebnisse des Vergleichs werden mithilfe
von Bäumen dargestellt, in denen geänderte, hinzugefügte oder gelöschte Modellelemente
visualisiert werden. Durch die Integration in das Eclipse kann das EMF-Compare-Tool beim
Vergleich unterschiedlicher Versionen eines Modells verwendet werden, wobei der Vergleich
grafisch dargestellter Modelle ab der Version 1.3 unterstützt werden soll. Auf der Herstellerseite
ist die neue Version für Ende Juni 2012 angekündigt. 4
Die letzte wichtige Anforderung betrifft die Validierung der Modelle innerhalb der TOP-
CASED-Umgebung. Im TOPCASED ist neben der Prüfung, ob Modelle zu der UML2 Spezifikation
konform sind, eine Definition der eigenen OCL-Regeln ermöglicht. Hierfür kann
ein im Rahmen des TOPCASED angebotenes OCL-Tooling verwendet werden. Es können
spezielle Bedingungen in Form der OCL-Constraints definiert werden, welche die Konformität
eines UWE-Modells zu seinem Metamodell prüfen. Somit ist die dritte Anforderung
ebenfalls erfüllt.
5.5.1. Das mediniQVT-Tool
Das mediniQVT der ikv++ technologies AG ein Eclipse-basiertes Tool zur Modelltransformation
mit der relationalen QVT-Sprache. Das mediniQVT kann sowohl als Eclipse-Plugin
in eine bestehende Eclipse-basierte Toolumgebung integriert werden, als auch schlanke
und vollständige Eclipse Rich Client Platform genutzt werden. Das mediniQVT ist ein freies
Produkt, das die von OMG spezifizierte relationale QVT-Sprache sehr konsequent unterstützt.[19]
Alle in dieser Arbeit vorgestellte Transformationen sind mit dem OpenSource-Werkzeug me-
4 http://wiki.eclipse.org/EMF_Compare
78

5.5. Die zusammengesetzte Toolumgebung
diniQVT getestet worden. Vor der Ausführung der Transformation sollen die Metamodelle
in der QVT-Umgebung deklariert werden. Diese Einstellung erfolgt über das Menü ” Preferences“.
Den UWE-Modellen liegt die Eclipse UML 2 zugrunde. So soll diese in der QVT-
Umgebung als ” http://www.eclipse.org/uml2/3.0.0/UML“ mit angegeben werden. In der
Transformationskonfiguration soll neben dem Transformationsskript, dem Quell- und dem
Zielmodell das UWE-Profil mit angegeben werden. (Siehe Abb. 5.3) Als Richtung der Transformationsausführung
soll das Ziel gewählt werden. Somit kann auf die Stereotypen in den
Abbildung 5.3.: Die Konfiguration der Transformation in der mediniQVT-Umgebung.
Relationen von Transformation zugegriffen werden.
Innerhalb der zusammengesetzten Tool-Umgebung können sich die Quell- und die Zielmodelle
sogar in den Unterschiedlichen Projekten befinden. Es muss keine export/import
Aktion durchgeführt werden.
Das mediniQVT-Problem bei der Anwendung von Stereotypen im Zielmodell
Unter Einsatz des mediniQVT-Werkzeugs lassen sich momentan die Stereotypen auf die
Zielklassen nicht anwenden. Dies liegt daran, dass die Methoden unter einer where- oder
einer when-Klauseln ausschließlich boolean-Werte als Rückgabewerte liefern dürfen. Die
Anwendung eines Stereotyps liefert einen void-Wert als Rückgabewert. Die Anwendung des
Stereotyps kann nur innerhalb der where- und when-Klauseln erfolgen. Somit liefert die
oben angepasste Transformation ein UML-Klassenmodell, auf dem kein UWE-Profil angewendet
ist.
79

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
In den Foren der mediniQVT-Webseite steht, dass an einer Implementierungslösung gearbeitet
wird, welche die Methoden mit void-Rückgabewerten zulassen würde. 5
Ein anderer Lösungsansatz dieses Problems ist die Angabe eines UML-Profils unter den
Metamodellen in der QVT-Umgebung. Hierfür soll das UML-Profil als statisches Profil in
Eclipse UML2 definiert werden. Als Resultat können Profilelemente in einer Domäne direkt
erzwungen und angewendet werden.
1 enforce domain t e x t S t e r e o t y p e : u w e p r o f i l e : : Text{
2 b a s e c l a s s = someClass
3 }
Listing 5.8: Das Erzwingen eines UML-Profil-Elements in einer Relationsdomäne.
Eine Recherche ergab, dass die Anwendung eines Profils auf das Zielmodell einer Transformation
problemlos unter Einsatz der operationalen QVT-Sprache funktioniert. Ausführliche
Beispiele von Sigfried Nolte sind in dem Tutorium: ” Modellgetriebene Anwendungsentwicklung
Jahrestagung der Gesellschaft für Informatik 2010“ vorgestellt worden. 6 Die dritte
Lösung für das oben geschilderte Problem würde die Definition der Transformation in der
operationalen QVT-Sprache liefern.
5.5.2. Das EMF-Compare
Das EMF-Compare ist ein Teil des EMF, das einen metamodellunabhängigen Modellvergleich
ermöglicht. Dies wird unter der Verwendung eines generischen Vergleichsalgorithmus
erreicht, das von Cédric Brun and Alfonso Pierantonio entwickelt ist[4].
Als Ergebnis eines Vergleichs zweier Modelle erzeugt das EMF Compare ein Übereinstimmungsund
ein Differenzmodell. Ein rekursiver Vergleich entlang der hierarchischen Struktur eines
Modells wird durchgeführt, um ein Übereinstimmungsmodell mit dem anderen Modell erstellen
zu können. Auf jeder Hierarchieebene werden ähnliche Elemente identifiziert. Im
Übereinstimmungsmodell wird jedes Element aus dem ersten Modell dem ähnlichsten Element
des zweiten Modells zugeordnet. Die Ähnlichkeit der Modellelemente wird anhand von
vier Metriken gemessen:
• Modellelementnamen (engl. name similarity)
• Referenzenvergleich(engl. relations similarity)
• Attributenvergleich (engl. value similarity)
• Metamodellelementenvergleich(engl. type similarity)
Alle Metriken werden gewichtet und zu einer Gesamtmetrik zusammengerechnet. Zwei Elemente
sind ähnlich, im Fall wenn ihre Namen identisch sind oder die Gesamtmetrik über
einem bestimmten Schwellwert liegt. Dieser Algorithmus zeichnet sich durch die hohe Korrektheit
und die Effizienz aus. Aus dem Übereinstimmungsmodell wird ein Differenzmodell
5 http://projects.ikv.de/qvt/discussion/
6 http://www.siegfried-nolte.de/GI2010/GI2010.html
80

5.5. Die zusammengesetzte Toolumgebung
Abbildung 5.4.: Der Vergleich zweier UWE-Modelle. Die Differenzen der zwei Modelle.
abgeleitet. Das Differenzmodell enthält alle additiven, subtraktiven Änderungen und die Updates
an den Modellelementen. Das Übereinstimmungs- und das Differenzmodell sind zur
automatisierten Weiterverarbeitung gut geeignet, da sie selbst EMF-Modelle sind.
Die GUI des EMF-Compare Tools besteht aus zwei Ansichten: der Ansicht der strukturellen
Modelldifferenzen und der Visualisierung dieser Differenzen. Die Abbildung 5.4 zeigt die
strukturelle Differenz zwischen einem UWE-Modell mit angewendetem UWE-Profil und dem
mithilfe der Modell-Co-Evolution-Transformation generiertem UWE-Modell. Für die Page
sind folgende Differenzen zu sehen: im Vergleich zu dem Zielmodell ist im Quellmodell bei
der Klasse Homepage das Stereotype angewendet. Bei dem Zielmodell wurden
im Laufe der Transformation die neuen Attribute collapse und dragdrop hinzugefügt. Die
Visualisierung der strukturellen Ansicht zeigt die Modelle nebeneinander. Die Differenzen
werden farblich gekennzeichnet. (Abb. 5.4)
81

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
Der Algorithmus wird absichtlich generisch gehalten. Es besteht die Möglichkeit an diesem
Algorithmus eigene Anpassungen durchzuführen. Dafür stehen APIs zur Verfügung.
82

5.6. Beispiel der Modell-Co-Evolution für UWE-Modelle mit angewendetem UWE-Profil
5.6. Beispiel der Modell-Co-Evolution für UWE-Modelle mit
angewendetem UWE-Profil
In diesem Abschnitt wird ein Beispiel der Modell-Co-Evolution an einem UWE-Modell mit
dem angewendeten UWE-Stereotyp vorgestellt. Hierfür wird das Präsentationsmodell der
einfachen Webseite (engl. Simple Website) von der UWE-Seite verwendet. 7 . In der Abbildung
5.5 ist das Präsenationsmodell der einfachen Webseite zu sehen. In der TOPCASED-
Abbildung 5.5.: Das Präsentationsmodell der einfachen Webseite in der Version 1.7 des
UWE-Profils.
Modellierungsumgebung werden Modelle durch eine spezielle textuelle und eine grafische
Komponente dargestellt, wobei diese in zwei getrennten Dateien gespeichert werden. Diese
sind die *.uml-Datei und der *.umldi-Datei. In der Transformationskonfiguration wird
das SimpleWebSite.uml-Datei als Quelldatei angegeben. Als Zielmodell wird wiederum eine
*.uml-Datei generiert.
Die Klassen, auf die Stereotyp angewendet ist, werden kopiert. In dem Zielmodell
wird auf diese Kopien das Stereotyp angewendet. Dies Betrifft
die Klassen ” ProjectHomepage“, ” Acknowledgement“ und ” Article“. Der Presentation-
Group wurden in der neuen Version die Attribute collapse und dragdrop hinzugefügt. Somit
werden diese Attribute in den oben genannten Klassen im Zeilmodell definiert.
Die Klasse ” SectionRequirements“ wird im Zielmodell mit dem Stereotype
markiert. Dies wird aus der Anwendung des -Stereotyps
7 http://uwe.pst.ifi.lmu.de/examples.html
83

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
im Quellmodell abgeleitet. Die Attribute collapse und dragdrop werden der ” SectionRequirements“
neu hinzugefügt.
Abbildung 5.6.: Der Vergleich der Versionen 1.7 und 1.8 der SimpleWebSite.
Alle Modellelemente, die mit im Quellmodell markiert sind, werden
in dem Zielmodell mit markiert. Da IteratedPresentationGroup
eine Subklasse der PresentationGroup ist, werden bei den betroffenen Klassen
entsprechend die neuen collapse- und dragdrop-Attribute definiert. In diesen Klassen werden
die anchors-Attribute der Quellklasse als PresentationProperties definiert. In dem Modell
der einfachen Webseite sind drei AnchoredCollection-Elemente vorhanden: ” ArticleIndex“,
” SectionMenu“ und ” ExternalAnchor“.
Alle Klassen, auf die ein -Stereotyp angewendet ist, werden mit denselben Stereotyp
in dem Zielmodell markiert. Einzige Anpassung, die im Rahmen der Modell-Co-Evolution
an diesen Elementen stattfindet ist die Hinzunahme der Attribute periodicRefresh und li-
84

5.6. Beispiel der Modell-Co-Evolution für UWE-Modelle mit angewendetem UWE-Profil
veReport.
Sehr ähnlich werden die Klassen mit dem angewendeten Stereotyp behandelt.
Diese Klassen werden im Zielmodell mit demselben Stereotyp markiert und um einen neuen
Attribut liveReport erweitert.
In der Abbildung 5.6 ist der Vergleich des Modells der einfachen Webseite in der Version
1.7 und der Version 1.8 unter dem Einsatz des EMF-Compare-Tools dargestellt. Für die
Erkennung der Profil-Differenzen muss das EMF-Compare-Vergleichsalgorithmus erweitert
werden.
Das Tool EMF-Compare stellt alle strukturellen Differenzen, wie die neu hinzugefügte Klassen
oder Attibute sehr übersichtlich dar. Diese Differenzen sind in der strukturellen Ansicht
in Form einer Liste beschrieben. Die Vizualisierung der Differenzen veraunschaulicht diese
sehr gut. Beide Modelle sind in ihren textuellen baumartigen Struktur nebeneinander dargestellt,
wobei die Modellelemente, die sich unterscheiden, farblich hervorgehoben werden.
Abbildung 5.7.: Das Präsentationsmodell der einfachen Webseite in der Version 1.8 des
UWE-Profils.
In der Abbildung 5.7 ist die grafische Repräsentation des generierten Modells dargestellt.
Dieses Diagramm wurde manuell erstellt, da leider noch kein angemessener automatisierter
Ansatz zur Generierung der grafischen Komponente zur Verfügung steht. Auf der nächsten
Seite in der Abb. 5.8 werden die beiden Versionen des Modells der einfachen Webseite in
vollem Umfang nebeneinander in der Topcased-UML-Ansicht dargestellt.
85

5. Integration des UWE-Profil-basierten transformativen Ansatzes in die UWE Toolumgebung
Abbildung 5.8.: Die Präsentationsmodelle der einfachen Webseite in der Version 1.7 un der
Version 1.8.
86

6. Die Zusammenfassung und der Ausblick
6.1. Die Zusammenfassung
Das UWE-Metamodell erfährt einige Änderungen an bestimmten Teilmodellen bzw. an allen
Teilmodellen mehrmals im Jahr. An dem UWE-Metamodell wird aktiv gearbeitet, so dass
ständig neue RIA-Features, Design Pattern, Verbesserungen in Form der ” best practices“-
Lösungen dem Metamodell hinzugefügt werden. Dieser Evolutionsprozess bringt einen hohen
Bedarf an einer Anpassung der existierenden Modelle auf jeweils neue UWE-Metamodell-
Version, solcher wie die Beispielsmodelle, die auf der UWE-Webseite 1 zu finden sind. Diese
Anpassung soll am besten automatisiert durchgeführt werden.
Laut den neuesten Erkenntnisse auf dem Gebiet der Modell-Co-Evolution, ist diese auf der
Basis der Metamodelländerungen durchzuführen. Diese Arbeit beschreibt genau vor wie die
Modell-Co-Evolutionsstrategie aus den Metamodelländerungen abzuleiten ist. Eine illustrative
Transformation wurde definiert, um die metamodellbasierte Modell-Co-Evolution der
UWE-Präsentationsmodelle zu veranschaulichen.
Da die UWE-Methodologie eine leichtgewichtige Erweiterung der UML mithilfe eines UWE-
Profils vorschlägt, wurde die Strategie entwickelt, welche die Modell-Co-Evolution der Modelle
mit dem angewendeten UWE-Profil ermöglicht. Dies wurde durch die Tatsache gewährt,
dass die UWE-Metamodellspezifikation die Mappings zwischen dem Metamodel und dem
Profil konkret spezifiziert. Anhand dieser Mappings wurde aus der metamodellbasierten
Transformation durch geringfügige Anpassungen eine UWE-Profil-basierte Transformation
abgeleitet.
Die in dieser Arbeit geschaffene Basis für die Integration des transformativen Ansatzes im
Rahmen der UWE-Methodologie erlaubt die weitgehende Automatisierung des Modell-Co-
Evolutions-Prozesses und bietet somit eine wohlgeformte, einheitliche und konsistenzerhaltende
Lösung.
Für die Integration des transformativen Ansatzes in die UWE-Methodologie wurde eine Auswahl
von Werkzeugen ausgesucht, welche die automatisierte Modell-Co-Evolution ermöglichen.
Das Modellierungswerkzeug TOPCASED mit einem UWEclipse-Plug-in wurde als
Grundlage für die Toolumgebung in dieser Arbeit verwendet. In UWEclipse sind Funktionalitäten
enthalten, welche die UWE-basierte Modellierung von RIAs ermöglichen. Weitere
Tools wurden ausgewählt und getestet, um den Modell-Co-Evolutionsprozess zu unterstützen.
Das TOPCASED mit UWEClipse Plug-in wurde mit weiteren benötigten Werkezeugen
erweitert: dem mediniQVT-Tool für die Durchführung der Transformationen in der
1 http://uwe.pst.ifi.lmu.de
87

6. Die Zusammenfassung und der Ausblick
relationalen QVT-Sprache und dem EMF-Compare-Tool für die Repräsentation der Modelldifferenzen.
Für die Validierung der Modelle werden interne TOPCASED-Tools eingesetzt.
Somit ist die Modell-Co-Evolution für UWE-Modelle als toolbasierter MDA-Entwicklungsprozess
erarbeitet worden. Alle erforderlichen Konzepte, welche diesen Prozess unterstützen,
sind durch die OMG spezifiziert und standardisiert. Die Zusammensetzung der ausgewählten
Tools erfüllt alle an diese Integration im Rahmen dieser Arbeit gestellten Anforderungen.
Die Transformationen in der relationalen QVT-Sprache, welche automatisierte UWE-Modell-
Co-Evolution ermöglichen, sind erarbeitet und mit dem Werkzeug mediniQVT getestet worden.
Das mediniQVT-Tool verfügt über keine grafische Modellierungskomponente. Das Tool
lässt sich in anderen Eclipse-basierten Modellierungstools wie TOPCASED integrieren. Im
Rahmen dieser Arbeit wurde eine solche Integration durchgeführt und eine Basis für die
Modell-Co-Evolution an den mit UWE-Profil erweiterten TOPCASED-UML-Modellen geschaffen.
Die Modelle und Metamodelle, die zu einer Transformation herangezogen werden, müssen für
die Transformation in einer serialiesierten textbasierten Form vorliegen. Dies ist im TOPCA-
SED dadurch gegeben, dass ein UML-Modell aus einer textbasierten und einer graphischen
Konponenten besteht, welche in getrennten Dateien gespeichert sind. Die Modelle müssen
nicht exportiert werden, um für die Transformation in das mediniQVT-Tool importiert zu
werden. Das Tool ist als ein Teil der Modellierungsumgebung integriert. Diese Tatsache
bringt einen großen Vorteil mit sich: die graphische Repräsentation der exisierenden Modelle
geht nicht verloren.
Die Zusammensetzung der graphischen Modellierung und der textbasierten Transformation
hat ihre Nachteile: das generierte Zielmodell ist nur in textueller Form vorhanden. Dies
ist eine im Rahmen der MDA sehr verbreitete Problematik. Die graphische Komponente
kann aus dem Quellmodell nicht abgeleitet werden und muss somit manuell erstellt werden.
Im TOPCASED lässt sich ein Diagramm aus einem textbasierten Modell mit wenigen Klicks
erstellen. Dieses Diagramm wird als leeres Diagramm erstellt. Alle Elemente können per
drag&drop in das Diagramm aus dem textuell repräsentierten Teil des Modells übertragen
werden. Leider muss man sich mit dieser Möglichkeit zufrieden geben. Die UWE-Modelle
sind gemäß dem Prinzip des ” Separation of Concerns “ in Teilmodelle unterteilt, die keine
allzugroße Anzahl von Elementen aufweisen und ziemlich überschaubar sind. Somit ist
der Zeitaufwand für den Wiederaufbau der graphischen Repräsentation im Fall der UWE-
Modelle relativ gering.
6.2. Der Ausblick
Die Transformationen wurden mit dem Open Source-Werkzeug mediniQVT entwickelt und
ausgeführt. Im Rahmen dieser Arbeit wurde festgestellt, dass sich dieses Werkzeug wunderbar
für die Modelltransformationen eignet. Bei der Transformation der Modelle mit einer
UML-Profil-Anwendung, kann auf die angewendeten Stereotypen zugegriffen und anhand
88

6.2. Der Ausblick
diesen Stereotypen die Transfromation gesteuert werden. Es tritt ein Problem bei der Generierung
eines Modells auf, auf dem eine Profil-Anwendung erforderlich ist. Das Ziel-Profil
kann auf das Zielmodell in der vorliegenden Implementierung des mediniQVT-Tools nicht
angewendet werden. Leider eignet sich die relationale QVT-Sprache in der mediniQVT Implementierung
nicht für die UWE-Modell-Co-Evolution. Es hat sich ergeben, dass die Anwendung
des UWE-Profils und der UWE-Stereotypen an den Elementen des generierten Modells
mit mediniQVT nicht umsetzbar ist. Aufgrund der Tatsache, dass das mediniQVT die Spezifikation
der relationalen QVT-Sprache von OMG zur Zeit am vollständigsten abbildet,
dürfte der Einsatz der operationalen QVT-Sprache in diesem Fall eine bessere Alternative
darstellen.
Ein weiteres Tool, namens EMF-Compare dient zur Unterstützung der Modell-Co-Evolution
und wird für die Darstellung von Modelldifferenzen zwischen dem Quellmodell und dem
generierten Zielmodell eingesetzt. Dieses Tool erlaubt den Vergleich der UML-Modelle mit
dem angewendeten UML-Profil unter Einsatz eines generischen Vergleichsalgorithmus.
Dieser Algorithmus bedarf einiger Verbesserungen. Im Falle eines Vergleichs der Modelle
mit angewendeten Stereotypen werden leider die Stereotypen, welche sich in der neuen
Version nicht geändert haben, trotzem als neuhinzugefügte Stereotypen erkannt. Das EMF-
Compare bietet eine Erweiterungsmöglichkeit zur Verwendung eigener Vergleichsalgorithmen
an. Dafür stellt EMF-Compare umfangreiche Schnittstellen zur Implementierung eigener
Vergleichsalgorithmen zur Verfügung. Also wäre es möglich, den Vergleichsalgorithmus
so anzupassen, dass die gleichnahmigen Stereotypen als nicht verändert angezeigt werden.
Die EMF-Compare-Implementierung in Java lässt sich in ein beliebiges Modellierungstool
integrieren, wie z.B. das MagicDraw.
Für den Einsatz von der operationalen QVT spricht auch folgender Umstand. Ein QVT-Plugin
für die Transformationen in der operationalen QVT-Sprache ist bereitgestellt worden, das
in das MagicDraw integriert werden kann. 2 Dabei handelt es sich um eine Implementierung
des ” Operational QVT“, die im Rahmen der M2M-Projektes von Eclipse 3 entstanden ist
(Ein Teil des Eclipse Modeling Frameworks). Somit könnte die Durchführung der Transformationen
in der operationalen QVT-Sprache innerhalb des Tools MagicUWE mit diesem
Plug-in ermöglicht werden. Durch eine Integration der EMF-Compare-Implementierung zur
Visualisierung der Modelldifferenzen könnte somit das MagicUWE-Tool um eine umfassende
Erweiterung für die automatisierte Modell-Co-Evolution ergänzt werden.
2 http://www.nomagic.com/products/magicdraw-addons/qvt-plugin.html
3 http://www.eclipse.org/m2m/
89

6. Die Zusammenfassung und der Ausblick
90

A. Darstellung der Metamodelle
Im Folgenden wird die Vorgehensweise der Erstellung der vereinfachten SimpleUWEold und
SimpleUWEnew der MOF-Metamodelle erläutert. Die Voraussetzung für die Verwendung
von Metamodellen im Rahmen einer QVT-Transformation ist, dass diese Metamodelle eine
Serialisierung der Metamodelle im Eclipse-Ecore-Format unterstützen. Die Metamodelle
werden mithilfe des Modellierungstools ” Eclipse Galileo - Eclipse Modeling Tools“ [1] erstellt.
Das Modellierungspaket enthält eine Sammlung von Eclipse Modeling Project Komponenten
1 , einschließlich EMF, GMF, MDT XSD/OCL/UML2, M2M, M2T, und EMFT Elemente.
Zur Bearbeitung von Ecore-Modellen stellt das Eclipse Modeling Tool die ” Ecore Tools“ zur
Verfügung, die einen graphischen Editor für die Erstellung der Ecore-Modelle bereitstellt.
Abbildung A.1 zeigt SimpleUWEold-Metamodell in grafischen Ecore Editor von Eclipse.
Abbildung A.1.: Grafischer Ecore Editor in Eclipse-Umgebung
1 http://www.eclipse.org/downloads/packages/eclipse-modeling-tools-includes-incubating-components/
galileor
91

A. Darstellung der Metamodelle
A.1. Erstellung von Metamodellen in Ecore-Format
Bevor Metamodelle modelliert werden können, muss ein ” Ecore Tools Project“ erstellt werden:
• File ->New ->Other ->Ecore Tools ->Ecore Tools Project
Abbildung A.2.: Einen neuen ” Ecore Tools Project“ erstellen
Ein Ecore Diagramm wird wie folgt erstellt:
• File ->New ->Other ->Ecore Tools ->Ecore Diagram
Abbildung A.3.: Eine neue Ecore Diagramm erstellen
Nach der Erstellung erscheinen zwei Dateien: SimpleUWEold.ecore und SimpleUWEold.ecorediag.
Die erste Datei enthält das erstellte Modell in Ecore Format. Die zweite Datei enthält die
Diagramminformationen der grafischen Repräsentation des Modells und kann in einem ” Ecore
Diagramm Editor“ geöffnet und bearbeitet werden:
• open with ->Ecore Diagram Editor
Die Ecore Datei kann mit dem speziellen ” Sample Ecore Model Editor“ angezeigt und bearbeitet
werden:
92
• open with -> ” Sample Ecore Model Editor“

A.1. Erstellung von Metamodellen in Ecore-Format
Abbildung A.4.: Ecorediag - Datei mit dem ” Ecore Diagramm Editor“ öffnen
Abbildung A.5.: Ecore - Datei mit ” Sample Ecore Model Editor“ öffnen
Im ” Sample Ecore Model Editor“ können Modelle in spezieller textbasierter Form angezeigt
und bearbeitet werden. Graphischer Editor bietet eine bessere Alternative hierzu. Bearbeitet
man ein Model im graphischen ” Ecore Diagram Editor“, so werden alle Änderungen sofort
in Ecore Modell übernommen. ” Sample Ecore Model Editor“ sieht folgendermaßen aus:
Abbildung A.6.: Das erstellte Modell im ” Sample Ecore Model Editor“
Der grafische Editor wurde bereits in der Abbildung A.1 veranschaulicht. Im Outline-Bereich
auf der linken Seite ist das erstellte Modell in Ecore-Repräsentation, siehe in der Abbildung
A.6, dargestellt. Auf folgenden zwei Seiten sind die Ecore-Darstellungen der SimpleUWEnew
und der SimpleUWEold Metamodelle dargeboten.
93

A. Darstellung der Metamodelle
94
Abbildung A.7.: UWE-Präsentations-Metamodell. Version 1.7 in der Ecore Darstellung

A.1. Erstellung von Metamodellen in Ecore-Format
Abbildung A.8.: UWE-Präsentations-Metamodell. Version 1.8 in der Ecore Darstellung
95

A. Darstellung der Metamodelle
A.2. Ein Generator-Modell aus Ecore-Modellen erstellen
Die Metamodelle werden in Form von Eclipse-Plug-ins, die in die Entwicklungsumgebung
mit eingebunden werden können, gebraucht. Dies ermöglicht die Erstellung Modelle in entsprechender
Form basierend auf diesen Metamodellen. Das Werkzeug ” Eclipse Modeling Framework“[2]
ermöglicht die Erstellung der Metamodelle als Eclipse-Plug-ins aus den Ecore-
Metamodellen. Zuerst soll das EMF-Modell, die auf dem Ecore-Modell basiert, erstellt werden.
Diese EMF-Modell soll vom Typ ” EMF Generator Model“ sein:
• File ->Other ->Eclipse Modeling Framework ->EMF Generator Model
Abbildung A.9.: Ein Generator Modell aus einem Ecore-Modell erstellen
Das Generator-Model soll SimpleUWEold.genmodel bzw. SimpleUWEnew.genmodel heißen:
Abbildung A.10.: Namen für das Generator-Modell wählen
Als ” Model Importeur“ soll SimpleUWEold.ecore bzw. SimpleUWEnew.ecore gewählt werden:
Als nächstes soll das Ecore-Modell geladen werden. Hierfür soll man den Button Load
96

A.2. Ein Generator-Modell aus Ecore-Modellen erstellen
Abbildung A.11.: Als ” Model Importer“ das Ecore-Modell wählen
betätigen. Ist das Ecore-Modell korrekt, so wird es ohne weitere Meldungen geladen und
” Next“-Button wird aktiviert. Ansonsten erscheint eine Fehlermeldung, dass das Ecore-
Modell korrigiert werden soll. Die Erstellung von Generator-Modell muss nach der Korrektur
des Ecore-Modells von vorne angestoßen werden. Wir gehen davon aus, dass das Ecore-Modell
korrekt war und Next“-Button betätigt wurde. Als letzter Schritt kann man referenzierte
”
Genmodelle hinzufügen, was in unserem Fall entfällt, und den Button Finish“ betätigen.
”
97

A. Darstellung der Metamodelle
A.3. Erstellung der Metamodelle in Form von Eclipse-Plug-ins
Das Generator-Modell SimpleUWEold.genmodel bzw. SimpleUWEnew.genmodel ist jetzt
die Quelle für den EMF-Generator. Das Generator-Modell kann man in EMF Generator
öffnen:
• Open with ->EMF Generator
Abbildung A.12.: Generator Modell mit EMF Generator öffnen
Letztendlich mit der Auswahl der folgenden Menü-Option ” Generate“ -> ” Generate all“ werden
für das SimpleUWEold-Metamodell bzw. SimpleUWEnew-Metamodell die Eclipse-Plugin-Projekte
erstellt:
• Generate ->Generate all
Abbildung A.13.: Eclipse Plug-in-Projekte erstellen
In unserem Fall heißen die generierten Plug-in-Projekte SimpleUWEold, SimpleUWEold.edit,
SimpleUWEold.editor, SimpleUWEold.test bzw. SimpleUWEnew, SimpleUWEnew.edit, SimpleUWEnew.editor,
SimpleUWEnew.test:
98
Abbildung A.14.: Eclipse Plug-in-Projekte

A.4. Das Deployment der Metamodell-Eclipse-Plug-ins
A.4. Das Deployment der Metamodell-Eclipse-Plug-ins
Die Projekte, die deployable sind, sollen ausgewählt und nach der Angabe eines Speicherortes
als JAR-Dateien dort gespeichert werden.
• File ->Export
Abbildung A.15.: Das Export der Metamodell-Eclipse-Plug-ins
Im nächsten Schritt soll der Speicherort für die zu generierenden Plug-ins angegeben werden:
Abbildung A.16.: Speicherortangabe beim Export der Metamodell-Eclipse-Plug-ins
99

A. Darstellung der Metamodelle
Unter dem angegebenen Speicherort befinden sich nach dem Betätigen des ” Finish“-Buttons
die generierten JAR-Dateien. Das Deployment von den generierten Metamodell-Eclipse-
Plug-ins erfolgt dadurch, dass die generierten Jar-Dateien in das Plug-ins-Verzeichnis der
aktuellen Eclipse-Plattform hineinkopiert werden. Nach dem Neustart von Eclipse, kann
Abbildung A.17.: Das Deployment der Plug-ins
man Modelle, denen die SimpleUWEold und die SimpleUWEnew Metamodelle zugrunde
liegen, in einem speziellen Editor in ihrer flachen, textuell repräsentierten Struktur erstellen.
Im Weiteren wird die Erstellung dieser Modelle beschrieben
Abbildung A.18.: Ein Beispiel eines SimpleWebSite-Modells, dem SimpleUWEold-
Metamodell zugrunde liegt
100

A.5. Modelle basierend auf Metamodellen erstellen
A.5. Modelle basierend auf Metamodellen erstellen
Nachdem die Metamodell-Plug-ins in die Eclipse-Umgebung eingebunden sind und die Eclipse-
Umgebung neu gestartet wurde, können Instanzen der Metamodelle erstellt werden. Um ein
Model, das zu SimpleUWEold-Präsentationsmodell konform ist, zu erstellen, soll man folgendes
ausführen:
• New ->Other ->Example EMF Model Creation Wizard ->SimpleUWEold Model
Abbildung A.19.: Ein SimpleUWEold Modell erstellen
Metamodell-Plug-ins beinhalten unter anderem einen speziellen Model Editor, mit dessen
Hilfe die Modelle in ihrer flacher, textuell repräsentierter Struktur, modelliert werden können.
Dieser Editor verfügt über das Menü ” SimpleUWEold Editor“, dass oben an der Menüleiste
des Eclipse angezeigt wird. Man kann mit ” New Sibling“ neue Elemente dem SimpleUWE-
Abbildung A.20.: SimpleUWEold Modell Editor Menü
101

A. Darstellung der Metamodelle
Modell hinzufügen. Die Liste der möglichen Elemente, siehe Bild A.20, wird angezeigt, wenn
man mit der Maus über den Menüeintrag ” New Sibling“ fährt. Attribute, in unserem Fall
PresentationProperties, werden mit ” New Child“ angelegt. ” Properties View“ ermöglicht die
Modifikation der Detail-Informationen jedes Elements. Um die ” Properties View“ in Eclipse
anzeigen zu lassen, wählt man den ” Show Properties View“-Menüeintrag des SimpleUWE-
Modell-Editors-Menü. Mit ” Refresh“ wird das Modell aktualisiert. Außerdem gibt es eine
Möglichkeit die Konformität des Modells gegenüber dem Metamodell mit ” Validate“ überprüfen
zu lassen. Alternativ lassen sich die neuen Elemente und PresentationProperties direkt
Abbildung A.21.: SimpleUWEold Modell Editor - Kontext-Menü
im Modell über ein Kontext-Menü anlegen. In dem Modell in der Abbildung A.21 ist das
Element Page ProjectHome ausgewählt. Mit dem Kontext-Menü über ” New Child“ -> ” PresentationProperty“
kann dem Page ProjectHome neue PresentationProperty hinzugefügt
werden.
102
Abbildung A.22.: SimpleUWEold Modell Editor Überblick

1
B. Transformationsskript mapUWEversion
2 transformation mapUWEversion ( s r c : SimpleUWEold , t r g : SimpleUWEnew )
3 {
4
5 −− E r s t e l l t das PresentationPackage im Z i e l m o d e l l −−
6 −− mit dem Namen aus Quellmodell −−
7 top relation mapPackage
8 {
9 pckgName : String ;
10 checkonly domain s r c srcPckg : SimpleUWEold : : Package
11 {
12 name = pckgName
13 } ;
14 enforce domain t r g tgtPckg : SimpleUWEnew : : Package
15 {
16 name = pckgName
17 } ;
18 −− Hier e i n e Bedingung : der Name s o l l P r e s e n t a t i o n s e i n −−
19 where
20 {
21 name = ’Presentation’ ;
22 }
23 }
24 −− Relation mapPage mappt Page auf PresentationPage . −−
25 −− P r e s e n t a t i o n P r o p e r t i e s werden übernommen −−
26 top relation mapPage
27 {
28 pageName : String ;
29 checkonly domain s r c srcPg : SimpleUWEold : : Page
30 {
31 namespace = srcPckg : SimpleUWEold : : Package {} ,
32 name = pageName ,
33 −− Es wird geprüft , ob page Stereotype −−
34 −− b e i dem Page angewendet i s t −−
35 kind = ’page’ ,
36 ownedAttribute = presProp : SimpleUWEold : : PresentationProperty
{}
37 } ;
38 enforce domain t r g trgPg : SimpleUWEnew : : PresentationPage
39 {
40 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
41 name = pageName ,
42 kind = ’presentationPage’ ,
43 c o l l a p s e = f a l s e ,
103

B. Transformationsskript mapUWEversion
44 dragdrop = f a l s e ,
45 ownedAttribute = presProp2 : SimpleUWEnew : : PresentationProperty
{}
46 } ;
47 when
48 {
49 mapPackage ( srcPckg , tgtPckg ) ;
50 }
51 where
52 {
53 −− B e s i t z t e i n e Page e i n e PresentationProperty , −−
54 −− so wird d i e R elation mapProperty a u f g e r u f e n −−
55 mapProperty ( presProp , presProp2 ) ;
56 }
57 }
58 −− Relation mapProperty wird j e d e s Mal in der where−Klausel −−
59 −− der Elementen , d i e e i n e PresentationProperty b e s i t z e n können , −−
60 −− a u f g e r u f e n sobald e i n e Property vorhanden i s t −−
61 relation mapProperty
62 {
63 propName : String ;
64 checkonly domain s r c pp : SimpleUWEold : : PresentationProperty
65 {
66 name = propName ,
67 presentationElement = pe : SimpleUWEold : : PresentationElement {}
68 } ;
69 enforce domain t r g pp2 : SimpleUWEnew : : PresentationProperty
70 {
71 name = propName ,
72 presentationElement = pe2 : SimpleUWEnew : : PresentationElement {}
73 } ;
74 when
75 {
76 −− Sobald e i n e P r e s e n t a t i o n Property einen P r e s e n t a t i o n −−
77 −− Element b e s i t z t , s o l l entsprechende Relation a u f g e r u f e n −−
78 −− werden −−
79 mapText ( pe , pe2 ) or mapAnchor ( pe , pe2 ) or mapImage ( pe , pe2 ) or
mapButton ( pe , pe2 ) or mapTextInput ( pe , pe2 ) or
mapAnchoredCol ( pe , pe2 ) or mapForm( pe , pe2 ) or mapPresClass (
pe , pe2 ) or mapPresGroup ( pe , pe2 ) ;
80 }
81 }
82 −− Relation mapPresClass mappt P r e s e n t a t i o n C l a s s auf P r e s e n t a t i o n −−
83 −− Group −−
84 top relation mapPresClass
85 {
86 className : String ;
87 checkonly domain s r c pc : SimpleUWEold : : P r e s e n t a t i o n C l a s s
88 {
89 namespace = srcPckg : SimpleUWEold : : Package {} ,
90 name = className ,
91 −− Es wird geprüft , ob P r e s e n t a t i o n C l a s s Stereotype −−
92 −− b e i dem P r e s e n t a t i o n C l a s s angewendet i s t −−
104

93 kind = ’presentationClass’ ,
94 ownedAttribute = pp : SimpleUWEold : : PresentationProperty {}
95 } ;
96 enforce domain t r g pg : SimpleUWEnew : : PresentationGroup
97 {
98 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
99 name = className ,
100 kind = ’presentationGroup’ ,
101 c o l l a p s e = f a l s e ,
102 dragdrop = f a l s e ,
103 ownedAttribute = pp2 : SimpleUWEnew : : PresentationProperty {}
104 } ;
105 when
106 {
107 mapPackage ( srcPckg , tgtPckg ) ;
108 not mapPage ( pc , pg ) ;
109 not mapPresGroup ( pc , pg ) ;
110 }
111 where
112 {
113 −− B e s i t z t e i n P r e s e n t a t i o n Class e i n e P r e s e n t a t i o n Property ,
−−
114 −− so wird d i e Relation mapProperty a u f g e r u f e n −−
115 mapProperty ( pp , pp2 ) ;
116 }
117 }
118 −− Relation mapPresGroup mappt PresentationGroup auf P r e s e n t a t i o n −−
119 −− Group −−
120 top relation mapPresGroup
121 {
122 pageName : String ;
123 checkonly domain s r c srcPg : SimpleUWEold : : PresentationGroup
124 {
125 namespace = srcPckg : SimpleUWEold : : Package {} ,
126 name = pageName ,
127 kind = ’presentationGroup’ ,
128 ownedAttribute = presProp : SimpleUWEold : : PresentationProperty
{}
129 } ;
130 enforce domain t r g trgPg : SimpleUWEnew : : PresentationGroup
131 {
132 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
133 name = pageName ,
134 kind = ’presentationGroup’ ,
135 c o l l a p s e = f a l s e ,
136 dragdrop = f a l s e ,
137 ownedAttribute = presProp2 : SimpleUWEnew : : PresentationProperty
{}
138 } ;
139 when
140 {
141 mapPackage ( srcPckg , tgtPckg ) ;
142 }
105

B. Transformationsskript mapUWEversion
143 where
144 {
145 −− B e s i t z t e i n P r e s e n t a t i o n Group e i n e P r e s e n t a t i o n −−
146 −− Property , so wird d i e Relation mapProperty a u f g e r u f e n −−
147 mapProperty ( presProp , presProp2 ) ;
148 }
149 }
150 −− Relation mapText e r s t e l l t e i n e Kopie des Text−Elements −−
151 −− im Z i e l m o d e l l −−
152 top relation mapText
153 {
154 textName : String ;
155 checkonly domain s r c te : SimpleUWEold : : Text
156 {
157 namespace = srcPckg : SimpleUWEold : : Package {} ,
158 name = textName ,
159 kind = ’text’
160 } ;
161 enforce domain t r g te2 : SimpleUWEnew : : Text
162 {
163 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
164 name = textName ,
165 kind = ’text’ ,
166 p e r i o d i c R e f r e s h = f a l s e ,
167 l i v e R e p o r t = f a l s e
168 } ;
169 when
170 {
171 mapPackage ( srcPckg , tgtPckg ) ;
172 }
173 }
174 −− Relation mapAnchor e r s t e l l t e i n e Kopie des Anchor−Elements −−
175 −− im Z i e l m o d e l l −−
176 top relation mapAnchor
177 {
178 anchorName : String ;
179 checkonly domain s r c an : SimpleUWEold : : Anchor
180 {
181 namespace = srcPckg : SimpleUWEold : : Package {} ,
182 name = anchorName ,
183 kind = ’anchor’
184 } ;
185 enforce domain t r g an2 : SimpleUWEnew : : Anchor
186 {
187 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
188 name = anchorName ,
189 kind = ’anchor’ ,
190 l i v e R e p o r t = f a l s e
191 } ;
192 when
193 {
194 mapPackage ( srcPckg , tgtPckg ) ;
195 }
106

196 }
197 −− Relation mapImage e r s t e l l t e i n e Kopie des Image−Elements −−
198 −− im Z i e l m o d e l l −−
199 top relation mapImage
200 {
201 imageName : String ;
202 checkonly domain s r c im : SimpleUWEold : : Image
203 {
204 namespace = srcPckg : SimpleUWEold : : Package {} ,
205 name = imageName ,
206 kind = ’image’
207 } ;
208 enforce domain t r g im2 : SimpleUWEnew : : Image
209 {
210 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
211 name = imageName ,
212 kind = ’image’ ,
213 p e r i o d i c R e f r e s h = f a l s e ,
214 l i v e R e p o r t = f a l s e
215 } ;
216 when
217 {
218 mapPackage ( srcPckg , tgtPckg ) ;
219 }
220 }
221 −− Relation mapButton e r s t e l l t e i n e Kopie des Button−Elements −−
222 −− im Z i e l m o d e l l −−
223 top relation mapButton
224 {
225 buttonName : String ;
226 checkonly domain s r c bu : SimpleUWEold : : Button
227 {
228 namespace = srcPckg : SimpleUWEold : : Package {} ,
229 name = buttonName ,
230 kind = ’button’
231 } ;
232 enforce domain t r g bu2 : SimpleUWEnew : : Button
233 {
234 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
235 name = buttonName ,
236 kind = ’button’ ,
237 l i v e R e p o r t = f a l s e
238 } ;
239 when
240 {
241 mapPackage ( srcPckg , tgtPckg ) ;
242 }
243 }
244 −− Relation mapTextInput e r s t e l l t e i n e Kopie des TextInput−Elements
−−
245 −− im Z i e l m o d e l l−−
246 top relation mapTextInput
247 {
107

B. Transformationsskript mapUWEversion
248 tiName : String ;
249 checkonly domain s r c t i : SimpleUWEold : : TextInput
250 {
251 namespace = srcPckg : SimpleUWEold : : Package {} ,
252 name = tiName ,
253 kind = ’textInput’
254 } ;
255 enforce domain t r g t i 2 : SimpleUWEnew : : TextInput
256 {
257 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
258 name = tiName ,
259 kind = ’textInput’ ,
260 l i v e R e p o r t = f a l s e ,
261 autoCompletion = f a l s e ,
262 l i v e V a l i d a t i o n = f a l s e
263 } ;
264 when
265 {
266 mapPackage ( srcPckg , tgtPckg ) ;
267 }
268 }
269 −− Relation mapChoice mappt Element Choice −−
270 −− auf das Element S e l e c t i o n im Z i e l m o d e l l −−
271 top relation mapChoice
272 {
273 choiceName : String ;
274 mult : Boolean ;
275 checkonly domain s r c c h o i c e : SimpleUWEold : : Choice
276 {
277 namespace = srcPckg : SimpleUWEold : : Package {} ,
278 name = choiceName ,
279 kind = ’choice’ ,
280 m u l t i p l e = mult
281 } ;
282 enforce domain t r g s e l e c t i o n : SimpleUWEnew : : S e l e c t i o n
283 {
284 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
285 name = choiceName ,
286 kind = ’selection’ ,
287 m u l t i p l e = mult ,
288 l i v e R e p o r t = f a l s e ,
289 autoCompletion = f a l s e ,
290 l i v e V a l i d a t i o n = f a l s e
291 } ;
292 when
293 {
294 mapPackage ( srcPckg , tgtPckg ) ;
295 }
296 }
297 −− Relation mapAnchoredCol mappt Element AnchoredCollection −−
298 −− auf d i e Elemente IteratedPresentationGroup des Z i e l m o d e l l s −−
299 −− und f ü g t a l l e Anchors des u r s p r ü n g l i c h e n Elements a l s −−
300 −− P r e s e n t a t i o n P r o p e r t i e s hinzu −−
108

301 top relation mapAnchoredCol
302 {
303 acName : String ;
304 anchorName : String ;
305 checkonly domain s r c ac : SimpleUWEold : : AnchoredCollection
306 {
307 namespace = srcPckg : SimpleUWEold : : Package {} ,
308 name = acName ,
309 kind = ’anchoredCollection’ ,
310 anchors = ancs : SimpleUWEold : : Anchor
311 {
312 name = anchorName
313 }
314 } ;
315 enforce domain t r g t i 2 : SimpleUWEnew : : IteratedPresentationGroup
316 {
317 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
318 name = acName ,
319 kind = ’iteratedPresentationGroup’ ,
320 c o l l a p s e = f a l s e ,
321 dragdrop = f a l s e ,
322 −−i n l i n e Erzeugung von Anchorn −−
323 ownedAttribute = presProp : SimpleUWEnew : : PresentationProperty
324 {
325 name = anchorName ,
326 presentationElement = pe : SimpleUWEnew : : PresentationElement
{}
327 }
328 } ;
329 when
330 {
331 mapPackage ( srcPckg , tgtPckg ) ;
332 mapAnchor ( ancs , pe ) ;
333
334 }
335 }
336 −− Relation mapForm mappt das Element Form −−
337 −− auf das Element InputForm des Z i e l m o d e l l s −−
338 −− und f ü g t a l l e elements des u r s p r ü n g l i c h e n −−
339 −− FormElements a l s P r e s e n t a t i o n P r o p e r t i e s hinzu −−
340 top relation mapForm
341 {
342 formName : String ;
343 formElemName : String ;
344 checkonly domain s r c form : SimpleUWEold : : Form
345 {
346 namespace = srcPckg : SimpleUWEold : : Package {} ,
347 name = formName ,
348 kind = ’form’ ,
349 elements = e l s : SimpleUWEold : : UIElement
350 {
351 name = formElemName
352 }
109

B. Transformationsskript mapUWEversion
353 } ;
354 enforce domain t r g iform : SimpleUWEnew : : inputForm
355 {
356 namespace = tgtPckg : SimpleUWEnew : : Package {} ,
357 name = formName ,
358 kind = ’inputForm’ ,
359 c o l l a p s e = f a l s e ,
360 dragdrop = f a l s e ,
361 −−i n l i n e Erzeugung von FormElementen −−
362 ownedAttribute = presProp : SimpleUWEnew : : PresentationProperty
363 {
364 name = formElemName ,
365 presentationElement = pe : SimpleUWEnew : : PresentationElement
{}
366 }
367 } ;
368 when
369 {
370 mapPackage ( srcPckg , tgtPckg ) ;
371 mapText ( e l s , pe ) or mapImage ( e l s , pe ) or mapAnchor ( e l s , pe ) or
mapTextInput ( e l s , pe ) or mapButton ( e l s , pe ) or mapChoice ( e l s
, pe ) ;
372 }
373 }
374 }
Listing B.1: Kompletter Transformationsskript, der eine automatisierte
UWE-Präsentationsmodell-Co-Evolution ermöglicht.
110

Abbildungsverzeichnis
2.1 Metamodell der Grunddefinitionen der MDA [10] . . . . . . . . . . . . . . . . 8
3.1 Eine Übersicht der Beziehungen zwischen einem Metamodell und den Softwareartefakten
[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Das Petri-Netze-Metamodell MM0 [7] . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Das Petri-Netze-Metamodell MM1 [7] . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Das Petri-Netze-Metamodell MM2 [7] . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Das UWE-Präsentations-Metamodell. Version 1.7 . . . . . . . . . . . . . . . . 28
3.6 UWE-Präsentations-Metamodell. Version 1.8 . . . . . . . . . . . . . . . . . . 29
4.1 Der Aufbau einer Transformation in der relationalen QVT-Sprache [19] . . . 35
4.2 Die Durchführung der Transformation.[19] . . . . . . . . . . . . . . . . . . . . 57
4.3 Das Präsentationsmodell für das Adressbuch in der Version 1.7. . . . . . . . . 59
4.4 Das AddressBook vor und nach der Ausführung der Transformation in der
textuellen Präsentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Die Deklaration der Metamodelle in der mediniQVT-Umgebung. . . . . . . . 61
4.6 Die Run-Konfiguration der Transformation. . . . . . . . . . . . . . . . . . . . 61
5.1 Das UML-Profil in Version 1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Die Anwendungsfälle für den UWE-Co-Evolutionsprozess . . . . . . . . . . . 76
5.3 Die Konfiguration der Transformation in der mediniQVT-Umgebung. . . . . . 79
5.4 Der Vergleich zweier UWE-Modelle. Die Differenzen der zwei Modelle. . . . . 81
5.5 Das Präsentationsmodell der einfachen Webseite in der Version 1.7 des UWE-
Profils. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.6 Der Vergleich der Versionen 1.7 und 1.8 der SimpleWebSite. . . . . . . . . . . 84
5.7 Das Präsentationsmodell der einfachen Webseite in der Version 1.8 des UWE-
Profils. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.8 Die Präsentationsmodelle der einfachen Webseite in der Version 1.7 un der
Version 1.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.1 Grafischer Ecore Editor in Eclipse-Umgebung . . . . . . . . . . . . . . . . . . 91
A.2 Einen neuen ” Ecore Tools Project“ erstellen . . . . . . . . . . . . . . . . . . . 92
A.3 Eine neue Ecore Diagramm erstellen . . . . . . . . . . . . . . . . . . . . . . . 92
A.4 Ecorediag - Datei mit dem ” Ecore Diagramm Editor“ öffnen . . . . . . . . . . 93
A.5 Ecore - Datei mit ” Sample Ecore Model Editor“ öffnen . . . . . . . . . . . . . 93
A.6 Das erstellte Modell im ” Sample Ecore Model Editor“ . . . . . . . . . . . . . 93
A.7 UWE-Präsentations-Metamodell. Version 1.7 in der Ecore Darstellung . . . . 94
A.8 UWE-Präsentations-Metamodell. Version 1.8 in der Ecore Darstellung . . . . 95
A.9 Ein Generator Modell aus einem Ecore-Modell erstellen . . . . . . . . . . . . 96
111

Abbildungsverzeichnis
112
A.10 Namen für das Generator-Modell wählen . . . . . . . . . . . . . . . . . . . . . 96
A.11 Als ” Model Importer“ das Ecore-Modell wählen . . . . . . . . . . . . . . . . . 97
A.12 Generator Modell mit EMF Generator öffnen . . . . . . . . . . . . . . . . . . 98
A.13 Eclipse Plug-in-Projekte erstellen . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.14 Eclipse Plug-in-Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.15 Das Export der Metamodell-Eclipse-Plug-ins . . . . . . . . . . . . . . . . . . 99
A.16 Speicherortangabe beim Export der Metamodell-Eclipse-Plug-ins . . . . . . . 99
A.17 Das Deployment der Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.18 Ein Beispiel eines SimpleWebSite-Modells, dem SimpleUWEold-Metamodell
zugrunde liegt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.19 Ein SimpleUWEold Modell erstellen . . . . . . . . . . . . . . . . . . . . . . . 101
A.20 SimpleUWEold Modell Editor Menü . . . . . . . . . . . . . . . . . . . . . . . 101
A.21 SimpleUWEold Modell Editor - Kontext-Menü . . . . . . . . . . . . . . . . . 102
A.22 SimpleUWEold Modell Editor Überblick . . . . . . . . . . . . . . . . . . . . . 102

Tabellenverzeichnis
2.1 Tabelle. Die Metalevels nach der MOF [10] . . . . . . . . . . . . . . . . . . . 12
3.1 Tabelle. Die Abhängigkeit zwischen dem Metamodell und den Softwareartefakten.
[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Klassifizierung der Änderungen eines Metamodells im Überblick.[7][24] . . . . 26
3.3 Überblick der Metamodell-Änderungen im Bezug auf Änderungstypen . . . . 30
4.1 Alle Klassen des SimpleUWEold-Metamodells mit den entsprechenden Transformationsaktionen
und den Relationen. . . . . . . . . . . . . . . . . . . . . . 46
4.2 Attribute aus den Abstrakten Klassen. . . . . . . . . . . . . . . . . . . . . . . 47
113

Tabellenverzeichnis
114

Listings
4.1 Der Syntaktischer Aufbau eines Transformationsskriptes[19] . . . . . . . . . . 36
4.2 Der Syntaktischer Aufbau einer Transformation[19] . . . . . . . . . . . . . . . 37
4.3 Das Beispiel einer Transformation[19] . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Das Beispiel einer Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Das Beispiel einer Relation unter dem Einsatz der when- und where-Klauseln 39
4.6 Die Syntax einer Domäne[19] . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Das Beispiel eines prozeduralen Teil(pattern expression) einer Domäne . . . . 40
4.8 Beispiel einer where-Klausel . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.9 Das Beispiel einer object template expression . . . . . . . . . . . . . . . . 42
4.10 Das Beispiel einer object template expression. Alternative . . . . . . . . . 43
4.11 Das Beispiel einer Inline-Objekterzeugung. . . . . . . . . . . . . . . . . . . . 44
4.12 Transformationssignatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.13 Identifizierte Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.14 Relation mapPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.15 Relation mapPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.16 Relation mapPresClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.17 Relation mapText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.18 Relation mapForm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.19 Relation mapAnchoredCol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.20 Die Relation mapProperty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1 Die Hilfsfunktionen für das Zugriff auf ein angewendetes Stereotyp . . . . . . 65
5.2 Die Anwendung des Stereotyps text wird unter der when-Klausel geprüft . . 65
5.3 Die Relationen für das Modell und das Paket . . . . . . . . . . . . . . . . . . 66
5.4 Die Relation für die Textelemente . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5 Die Relation für die Erzeugung eines liveReport-Attributs . . . . . . . . . . . 68
5.6 Die Relation für die PresentationClass . . . . . . . . . . . . . . . . . . . . . . 68
5.7 Die Relation für die PresentationProperties . . . . . . . . . . . . . . . . . . . 70
5.8 Das Erzwingen eines UML-Profil-Elements in einer Relationsdomäne. . . . . . 80
B.1 Kompletter Transformationsskript, der eine automatisierte UWE-Präsentationsmodell-
Co-Evolution ermöglicht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
115

Liste der Definitionen
1.1 Modell-Co-Evolution
Unter Modell-Co-Evolution wird eine Anpassung der existierenden Modelle verstanden,
die wegen der Evolution des zugrundeliegenden Metamodells durchgeführt
werden muss. Die Anpassung bewirkt, dass diese Modelle mit dem neuen geänderten
Metamodell konform gehen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Rich Internet Applications
” Rich Internet Applications (RIAs) are web applications, which use data that can be
processed both by the server and the client. Furthermore, the data exchange takes
place in an asynchronous way so that the client stays responsive while continuously
recalculating or updating parts of the user interface. On the client, RIAs provide a
similar look-and-feel as desktop applications and the word rich“ means particularly
”
the difference to the earlier generation of web applications. RIAs are basically
characterized by a variety of interactive operating controls, the possibility of on-
/offline use of the application, and the transparent usage of the client and server
computing power and of the network connection..“[13] . . . . . . . . . . . . . . . . 5
2.3 System
” Ein System ist ein aus Teilen zusammengesetztes und strukturiertes Ganzes. Es
hat eine Funktion, erfüllt einen Zweck und verfügt über eine Architektur.“[10] . . . 7
2.4 Model
” Ein Modell beschreibt oder spezifiziert ein System zu einem bestimmten Zweck.
Dazu erfasst es alle hierfür relevanten Aspekte, etwa Struktur, Verhalten, Funktion
und die Umwelt des Systems.“[10] . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Metamodell
” Ein Metamodell ist die Menge von Elementen mit denen Modelle, die Instanzen
dieses Metamodells sind, erstellt werden können. Es enthält die Regeln, die bei
der Erstellung des Modells beachtet werden müssen (abstrakte Syntax) sowie die
Bedeutung der Elemente und Elementkonstellationen (Semantik).“[10] . . . . . . . 8
2.6 Profile
” Ein Profil ist eine leichtgewichtige Erweiterung eines Metamodells. Dazu stellt es
neue Modellelemente zur Verfügung oder redefiniert bzw. erweitert die Semantik
oder Syntax bereits bestehender Elemente. Im Gegensatz zur Definition völlig neuer
Metamodelle (schwergewichtiger Ansatz) können sie die Bedingungen, die an
Elemente der Modelle gestellt werden, nur verschärfen.“[10] . . . . . . . . . . . . . 8
116

Liste der Definitionen
2.7 Domain
” Unter dem Begriff Domäne versteht man ein abgrenzbares, kohärentes Wissensgebiet.
In einem Metamodell (respektive in einem Profil) werden die Konzepte einer
Domäne in Bezug gesetzt und beschrieben. Zusammen mit ihrem sprachdefinierenden
Charakter bezeichnet man Metamodell und Profil daher als Domänenspezifische
Sprache (engl. Domain-Specific Language, DSL).“[10] . . . . . . . . . . . . . .
2.8 Application
”
9
Eine Anwendung oder Applikation (engl. Application) ist ein zu erstellendes Stück
Software, welches die zu entwickelnde Funktionalität umfasst. Ein System kann
sich aus einer oder mehreren Anwendung(en) zusammensetzen, die auf einer oder
mehreren Plattform(en) ausgeführt werden.“[10]
2.9 Plattform
. . . . . . . . . . . . . . . . . . . 9
” Eine Plattform ist eine Ausführungsumgebung für eine Anwendung. Ihre Funktionalität
stellt sie durch zweckmäßige Schnittstellen bereit, auf die die Anwendung
ohne Kenntnis der eigentlichen Implementierung zugreifen kann. Typische Beispiele
für Plattformen sind im Bereich Betriebssysteme (Unix, Windows), Programmiersprachen
(C++, Java) und Middleware (CORBA, Java EE, .NET) zu finden. Typisch
für Plattformen ist auch, dass sie oft in der Art eines Plattform-Stacks (dt. in
etwa Plattform Stapel) aufeinander aufsetzen. So bildet die Hardware eines Computers
die unterliegende Plattform für das Betriebssystem, das seinerseits wieder
Plattform für die einzelnen Anwendungen bietet usw.“[10] . . . . . . . . . . . . . .
2.10Transformation
”
9
Eine Transformation (oder genauer Modell-Transformation) ist der Prozess der
Umwandlung eines Modells in ein anderes Modell des gleichen Systems. Die Spezifikation
für eine solche Transformation ist in Abbildungsregeln (engl. Mapping
Rules) festgehalten, die in einer Abbildung (engl. Mapping) gebündelt sind.“[10] . 9
117

Liste der Definitionen
118

Literaturverzeichnis
[1] Eclipse Galileo. Eclipse Modeling Tools; online accessed 31-May-2012 . http://www.
eclipse.org/galileo/.
[2] Eclipse Modeling Framework, Online accessed 31-May-2012 . http://www.eclipse.
org/modeling/emf/?project=emf.
[3] Blagoev, P.: MagicDraw-Plugin zur Modellierung und Generierung von Web-
Anwendungen. Diplomarbeit, Ludwig-Maximilians-Universität, 2007.
[4] Brun, C. und A. Pierantonio: Model Differences in the Eclipse Modeling Framework.
UPGRADE The European J for the Informatics Professional, IX(2):29–34, 2008.
[5] Busch, M.: Migration und Erweiterung des MagicDraw-Plugins MagicUWE zur Entwicklung
von Web-Anwendungen. Ludwigs-Maximilians-Universität. 2009.
[6] Christian Kroiß, N. K. und S. Kozuruba: UWE Metamodel and Profile User Guide
and Reference. Version 1.7 . 2011.
[7] Cicchetti, A., D. D. Ruscio, R. Eramo und A. Pierantonio: Automating Coevolution
in Model-Driven Engineering. In: Proceedings of the 2008 12th International
IEEE Enterprise Distributed Object Computing Conference, S. 222–231, Washington,
DC, USA, 2008. IEEE Computer Society.
[8] Di Ruscio, D., L. Iovino und A. Pierantonio: What is needed for managing coevolution
in MDE?. In: Proceedings of the 2nd International Workshop on Model Comparison
in Practice, IWMCP ’11, S. 30–38, New York, NY, USA, 2011. ACM.
[9] Fowler, M.: UML konzentriert. Addison-Wesley, München [u.a.], 2004.
[10] Gruhn, V., D. Pieper und C. Röttgers: MDA: Effektives Software-Engineering mit
UML 2 und Eclipse. Springer, Berlin, 2006.
[11] Hitz, M., G. Kappel, E. Kapsammer und W. Retschitzegger: UML@Work, Objektorientierte
Modellierung mit UML 2 . dpunkt.verlag, Heidelberg, 2005.
[12] Knapp, A., N. Koch, M. Wirsing und G. Zhang: UWE - Ein Ansatz zur modellgetriebenen
Entwicklung von Webanwendungen (UWE - An Approach for the Model-
Driven Development of Web Applications). i-com, 6(3):5–12, 2007.
[13] Koch, N. und M. Busch: Rich Internet Application. State-of-the-Art. 2009.
[14] Koch, N., A. Knapp, G. Zhang und H. Baumeister: Uml-Based Web Engineering
- An Approach Based on Standards.. In: Rossi, G., O. Pastor, D. Schwabe und
L. Olsina (Hrsg.): Web Engineering, Human-Computer Interaction Series, S. 157–191.
Springer, 2008.
119

Literaturverzeichnis
[15] Kroiß, C. und N. Koch: UWE Metamodel and Profile User Guide and Reference.
Version 1.7 . 2008.
[16] Levendovszky, T., D. Balasubramanian, A. Narayanan und G. Karsai: A Novel
Approach to Semi-Automated Evolution of DSML Model Transformation. In: Second
International Conference on Software Language Engineering, SLE 2009, LNCS,
Bd. 5969, S. 23–41, Denver, CO, 05/2010 2010. Springer, Springer.
[17] MOF, O. M. G.: Object Management Group Terms And Acronyms; Online accessed 31-
May-2012 . http://www.omg.org/gettingstarted/save_terms_and_acronyms.htm.
[18] MOF, O. M. G.: OMG’s MetaObject Facility; Online accessed 31-May-2012 . http:
//www.omg.org/mof/.
[19] Nolte, S.: QVT - Relations Language. Springer, 2009.
[20] Pietrek, G. und J. Trompeter (Hrsg.): Modellgetriebene Softwareentwicklung: MDA
und MDSD in der Praxis. Entwickler.Press, Frankfurt am Main, 2007.
[21] Ruscio, D. D., R. Laemmel und A. Pierantonio: Automated co-evolution of GMF
editor models. In: Malloy, B., S. Staab und M. van den Brand (Hrsg.): 3rd
International Conference on Software Language Engineering (SLE 2010), S. 143–162.
Springer, Heidelberg, 2010.
[22] Sharonova, D.: Erweiterung eines Open Source-Werkzeugs für die UML-basierte Modellierung
von Webanwendungen. Diplomarbeit, Ludwig-Maximilians-Universität, 2011.
[23] Stahl, T. und M. Völter: Modellgetriebene Softwareentwicklung - Techniken, Engineering,
Management. dpunkt.verlag, 2007.
[24] Wachsmuth, G.: Metamodel Adaptation and Model Co-adaptation. In: ECOOP, S.
600–624, 2007.
120