Erkennung modelltypspezifischer Editieroperationen auf

Diplomarbeit
Erkennung modelltypspezifischer
Editieroperationen auf symmetrischen Differenzen
Timo Kehrer
Lehrstuhl Softwaretechnik und Datenbanksysteme
Institut für Praktische und Technische Informatik
Fachbereich Elektrotechnik und Informatik
Universität Siegen, 21.12.2010
Gutachter:
Prof. Dr. Udo Kelter (Universität Siegen)
Prof. Dr. Gabriele Taentzer (Universität Marburg)
Kurzfassung: Die modellgetriebene Softwareentwicklung hat in vielen Bereichen
an Bedeutung gewonnen. Bei diesem Vorgehen steht das Modell des zu realisierenden
Systems im Vordergrund, welches iterativ mittels geeigneter Werkzeuge und Sprachen
erstellt, transformiert und präzisiert wird. Die externe und interne Repräsentation der
Modelle unterscheiden sich dabei erheblich. Der Benutzer interagiert mit dem Modell
auf Basis einer konkreten, meist grafischen Syntax (externe Repräsentation). Werkzeuge
verarbeiten diese Modelle jedoch auf Basis einer technologiegebundenen Implementierung des abstrakten Syntaxgraphen (interne Repräsentation). Dieser Bruch zwischen
maschineller Darstellung und Benutzerverständnis führt häufig zu Problemen.
Bspw. können Modelländerungen dem Benutzer durch die Beschreibung von elementaren Operationen auf dem abstrakten Syntaxgraphen nur schwer kommuniziert werden.
Besser geeignet ist hier eine Beschreibung der inhaltlichen Änderungen auf Basis von
Editieroperationen, die sich auf den vorliegenden Modelltyp aus Sicht des Benutzers anwenden lassen. Im Kontext zustandsbasierter Differenzberechnungsverfahren resultiert
die Erkennung modelltypspezifischer Editieroperationen auf den berechneten, symmetrischen Differenzen in einem Pattern Matching Problem. Diese Arbeit stellt einen auf
regelbasierten Graphtransformationen beruhenden, generischen Lösungsansatz vor, mit
dem sich modelltypspezifische Editieroperationen auf symmetrischen Differenzen automatisiert erkennen lassen.
Abstract: Model-driven engineering increasingly becomes common practice in contemporary software development. Thereby, models of a system to be implemented are
iteratively developed and transformed by means of appropriate tools and languages.
Most often, the external and internal representation of the models differ considerably.
The user interacts with the model based on a concrete, usually graphical syntax (external representation). Tools process these models, however, based on a technology-based
implementation of the abstract syntax graph (internal representation). This mismatch
often leads to problems.
For example, model changes can be hardly presented to a user in terms of basic
operations on the abstract syntax graph. Here, describing model changes in terms of
editing operations that are applicable to a specific type of model would be preferable.
In the context of state-based difference calculation, the detection of model type-specific
editing operations on symmetrical differences results in a pattern matching problem. This
thesis presents a generic approach that uses rule-based graph transformations in order
to automatically detect model type-specific editing operations on symmetric differences.
Inhaltsverzeichnis
1 Einführung
1
1.1
Einführendes Beispiel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Problemmotivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4
Struktur der Arbeit
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
7
2.1
Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
EMF-Ecore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Modelldifferenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4
2.3.1
Begriffliche Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2
Repräsentation symmetrischer Differenzen . . . . . . . . . . . . . . 14
2.3.3
Korrespondenzbildungsverfahren . . . . . . . . . . . . . . . . . . . 20
Das Graphtransformationswerkzeug EMF-Henshin . . . . . . . . . . . . . 21
2.4.1
Grundlagen algebraischer Graphtransformationen . . . . . . . . . . 21
2.4.2
Ecore-spezifische Erweiterungen . . . . . . . . . . . . . . . . . . . . 25
2.4.3
Repräsentation von Transformationsregeln . . . . . . . . . . . . . . 26
3 Konzeptueller Lösungsansatz
29
3.1
Gruppierung von Divergenzen . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2
Repräsentation gruppierter Divergenzen . . . . . . . . . . . . . . . . . . . 31
3.3
Gruppierungsalgorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1
Transformationsregeln . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2
Regelanwendungsstrategie . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.3
Nachbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Implementierung
41
4.1
Eingesetzte Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2
Basis-Transformationssystem . . . . . . . . . . . . . . . . . . . . . . . . . 42
i
ii
INHALTSVERZEICHNIS
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
Einfügungen . . . . . . . . . . . . . . . . . . . . . . .
Änderung skalarer struktureller Eigenschaften . . . . .
Änderung mengenwertiger struktureller Eigenschaften
Löschungen . . . . . . . . . . . . . . . . . . . . . . . .
Globale Verschiebungen . . . . . . . . . . . . . . . . .
Übersicht . . . . . . . . . . . . . . . . . . . . . . . . .
5 Fallstudien
5.1 UML-Klassendiagramme . . . . . . .
5.1.1 Metamodell . . . . . . . . . .
5.1.2 Editierdatentyp . . . . . . . .
5.1.3 Transformationssystem . . .
5.2 Blockdiagramme in Matlab/Simulink
5.2.1 Metamodell . . . . . . . . . .
5.2.2 Editierdatentyp . . . . . . . .
5.2.3 Transformationssystem . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Evaluation
6.1 Korrektheit . . . . . . . . . . . . . . . . . . . . .
6.2 Korrelation mit Korrespondenzbildungsverfahren
6.3 Praktischer Nutzen . . . . . . . . . . . . . . . . .
6.4 Performanz . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
47
47
48
52
53
.
.
.
.
.
.
.
.
55
55
55
56
57
59
59
61
61
.
.
.
.
63
65
65
67
69
7 Zusammenfassung und Ausblick
73
7.1 Zusammenfassung und Bewertung . . . . . . . . . . . . . . . . . . . . . . 73
7.2 Ausblick und zukünftige Forschungsarbeiten . . . . . . . . . . . . . . . . . 74
Abbildungsverzeichnis
78
Literaturverzeichnis
83
A BTS-Adaption für UML-Klassendiagramme
85
B Matlab/Simulink-Metamodell
89
C BTS-Adaption für Matlab/Simulink
91
1 Einführung
Die modellbasierte Softwareentwicklung (MBSE) hat in vielen Bereichen an Bedeutung
gewonnen. Bei diesem Vorgehen steht das Modell des zu realisierenden Systems im Vordergrund, welches iterativ mittels geeigneter Werkzeuge und Sprachen erstellt, transformiert und präzisiert wird. Die externe und interne Repräsentation der Modelle unterscheiden sich dabei erheblich. Der Benutzer interagiert mit dem Modell auf Basis einer
konkreten, meist grafischen Syntax (externe Repräsentation). Diese kommt dem mentalen Modell des Benutzers i.d.R. am nächsten. Die physische Repräsentation der Modelle
erfolgt jedoch in klassischen Speicherformaten wie XML, relationalen Datenbanken oder
proprietären Text- bzw. Binärformaten. Werkzeuge wie bspw. Editoren, Transformationssysteme oder Differenzwerkzeuge verarbeiten Modelle auf Basis einer Datenstruktur,
deren Instanzen konzeptuell als abstrakter Syntaxgraph (ASG) aufgefasst werden können
(interne Repräsentation).
Der Bruch zwischen maschineller Darstellung und Benutzerverständnis führt häufig
zu Problemen, so auch im Kontext von Differenzwerkzeugen für Modelle. Die auf der
physischen Repräsentation, i.d.R. dem textuellen Inhalt von Dateien, arbeitenden Algorithmen traditioneller Werkzeuge für das Konfigurationsmanagement liefern für Modelle
meist unbrauchbare Resultate [BE09]. Vergleichsalgorithmen auf Basis des abstrakten
Syntaxgraphen erzielen hier deutlich bessere Ergebnisse, allerdings können Modelländerungen dem Benutzer durch die Beschreibung von elementaren Operationen auf dem
ASG nur schwer kommuniziert werden. Der Umbau des ASG kann bereits für — aus
Benutzersicht — einfache Modelländerungen komplex und unüberschaubar werden. Anzustreben ist hingegen eine Beschreibung der inhaltlichen Änderungen auf Basis von
Editieroperationen, die sich auf den vorliegenden Modelltyp aus Sicht des Benutzers
anwenden lassen.
Zur Veranschaulichung wird in Abschnitt 1.1 ein Beispiel eingeführt, welches als Ausgangspunkt für die in Abschnitt 1.2 motivierte und im Rahmen dieser Arbeit adressierte
Problemstellung dient. Verwandte Arbeiten werden in Abschnitt 1.3 betrachtet. Abschnitt 1.4 liefert einen Überblick über den strukturellen Aufbau der Arbeit.
1
2
1 EINFÜHRUNG
1.1 Einführendes Beispiel
Als einführendes Beispiel dienen die in Abb. 1.1 dargestellten UML-Klassendiagramme1 .
Der konzeptuelle Inhalt der Differenz der beiden dargestellten Varianten A und B liegt in
diesem Beispiel lediglich in der Navigierbarkeit der Assoziation C1-C2, welche in Modell
A als ungerichtet, in Modell B als gerichtet modelliert ist.
A
B
Abbildung 1.1: Beispielmodelle A und B
Abb. 1.2 zeigt die Beispielmodelle A und B in ihrer internen Repräsentation als abstrakte Syntaxgraphen. Die den Syntaxgraphen zu Grunde liegende Struktur sowie die
lokalen Eigenschaften der Knoten genügen dabei dem UML-Metamodell [OMG07], welches als Typgraph zu den dargestellten Syntaxgraphen fungiert.
In beiden Fällen bilden die Knoten des ASG je zwei Instanzen der Metaklasse Class
(C1 und C2), eine Instanz der Metaklasse Association (C1-C2) sowie zwei Instanzen
der Metaklasse Property (p1 und p2). Die Property-Knoten sind in beiden Fällen Enden
der Assoziation (memberEnd) und vom Typ (type) der Klassen C1 bzw. C2, was durch
die entsprechenden Kanten im ASG ersichtlich ist. Die beiden Varianten des ASG unterscheiden sich lediglich in ihrer Kompositionsstruktur. Property-Knoten p1 ist in beiden
Fällen ein nicht navigierbares Assoziationsende und gehört daher beides mal der Assoziation C1-C2. Property-Knoten p2 ist in Variante A nicht navigierbar und gehört dort
ebenfalls der Assoziation C1-C2, während er in der navigierbaren Variante B der Klasse
C1 gehört. Die Eigenschaft der Navigierbarkeit entscheidet also darüber, ob ein Property
einer Klasse als Attribut (ownedAttribute) oder einer Assoziation als Assoziationsende
(ownedEnd) gehört.
1
In der UML sind Diagramme als eine partielle Visualisierung eines Modells konzipiert. Wir gehen hier
davon aus, dass die dargestellten Diagramme den Inhalt der visualisierten Diagramme vollständig
wiedergeben und verwenden daher im Rahmen dieses Beispiels die Begriffe Diagramm und Modell
synonym.
1.2. PROBLEMMOTIVATION
3
A
B
Abbildung 1.2: ASG-Repräsentationen der Beispielmodelle A (oben) und B (unten)
1.2 Problemmotivation
Bereits anhand dieses einfachen Beispiels lässt sich der konzeptuelle Bruch zwischen externer und interner Repräsentation von Modellen veranschaulichen. Die Elemente des
abstrakten Syntaxgraphen sind teilweise zu feingranular. In unserem Beispiel ordnet
der Modellierer die als eigene Knoten im ASG vorhandenen Property-Knoten mental
den Eigenschaften der Assoziation zu. Das Löschen und Einfügen je einer Kante in den
ASG (in Abb. 1.2 angedeutet durch die rote bzw. grüne Einfärbung der Kanten) ist
eine aus Benutzersicht „ungeschickt“ formulierte Differenz; sie spiegelt nicht die konzeptuell durchgeführte Änderung der Navigierbarkeit der Assoziation C1-C2 in Richtung
der assoziierten Klasse C2 wieder. Allgemein lassen sich die Ursachen für ungeschickte
Differenzen in drei Kategorien einteilen:
1. Das Metamodell des betrachteten Modelltyps ist für den Modellvergleich ungeeignet. Dies ist im einführenden Beispiel der Fall. Aus Benutzersicht stellt die
Navigierbarkeit konzeptuell ein Attribut eines Assoziationsendes dar. Im Sinne des
UML-Metamodells folgt die Navigierbarkeit jedoch aus der zu Grunde liegenden
Kompositionsstruktur.
4
1 EINFÜHRUNG
2. Wenn man Modelle vergleicht, können sie technisch nur in einer technologiespezifischen, persistenten oder transienten Repräsentation vorliegen. Die technologiespezifischen Anteile in den Repräsentationen der Modelle führen dabei häufig zu
Differenzen, welche konzeptuell als irrelevant eingestuft werden. Derartige Differenzen werden auch als Pseudodifferenzen bezeichnet [Kel10b].
3. In der Regel führen modelltypspezifische Editieroperationen auf Modellen zu mehreren elementaren Änderungen auf dem abstrakten Syntaxgraphen. Im Zuge des
Modellvergleichs auf ASG-Basis führen diese Änderungen zu einer Vielzahl an Unterschieden, welche konzeptuell der Durchführung einer Editieroperation entsprechen.
Im Kontext des zustandsbasierten Modellvergleichs erweist sich die Erkennung modelltypspezifischer Operationen als schwierig und bisher unzureichend adressiertes Problem.
Vergleichsalgorithmen auf ASG-Basis berechnen primär Paare von einander entsprechenden Knoten der abstrakten Syntaxgraphen der zu vergleichenden Modelle. Unserem
Beispiel liegt die Annahme zu Grunde, dass die Knoten C1, C2, C1-C2, p1 und p2 jeweils korrespondieren. Die Differenz der verglichenen Modelle lässt sich anschließend auf
Basis der gebildeten Korrespondenzen ableiten. Die so gewonnenen, symmetrischen Differenzen enthalten die angewendeten, modelltypspezifischen Editieroperationen lediglich
implizit. Diese Arbeit stellt einen auf Graphtransformationstechniken basierenden, generischen Lösungsansatz vor, mit dem sich modelltypspezifische Editieroperationen auf
symmetrischen Differenzen automatisiert erkennen lassen.
1.3 Verwandte Arbeiten
Metamodell-Unzulänglichkeiten im Hinblick auf den Modellvergleich lassen sich prinzipiell durch die Anpassung des Metamodells eliminieren. Vor dem Ausführen der eigentlichen Vergleichsfunktion sind die zu vergleichenden Modelle hier durch eine Eingangstransformation in Instanzen des redefinierten Metamodells zu überführen. Eine
Diskussion zur Eignung des UML-Metamodells für den Vergleich von Zustandsautomaten ist in [KS08] zu finden. Die extrahierten Richtlinien lassen sich dabei auf ähnlich
strukturierte Verhaltensmodelle verallgemeinern.
Zur Vermeidung von Pseudodifferenzen werden in [Kel10b] zwei grundlegende Lösungsansätze skizziert: (1) Die Verwendung normierter Darstellungen in den implementierungsnahen Modellrepräsentationen und (2) die Rekonstruktion der frühphasigen Modelle, auf deren Basis der anschließende Modellvergleich durchgeführt wird. Beide führen
1.3. VERWANDTE ARBEITEN
5
im Kern darauf zurück, konzeptuell irrelevante Teile der zu vergleichenden Modelle auszublenden.
Mit dem By-Example Operation Recorder [BLSW09, BSW+ 09] wird ein auf EMFCompare2 basierendes Werkzeug vorgestellt, mit dessen Hilfe sich modelltypspezifische
Editiervorgänge aufzeichnen und als Differenzmuster exportieren lassen. Die Menge der
mittels des Operation Recorder erstellten Differenzmuster, welche konzeptuell die auf
einen Modelltyp anwendbaren Editieroperationen enthält, lässt sich anschließend im
Rahmen des Modellvergleichs einsetzen. Wird ein Differenzmuster auf der durch EMFCompare berechneten Differenz gefunden, so kann das in der Differenz auftretende Änderungsmuster mit der entsprechenden Änderungsoperation semantisch annotiert werden.
Der beschriebene Ansatz wurde jedoch bislang nicht implementiert und weist zudem das
konzeptuelle Problem auf, dass Differenzmuster mit einer undefinierten Anzahl an Änderungen mittels des Operation Recorder nicht aufgezeichnet werden können. Diese treten
jedoch oftmals als Seiteneffekte einer Editieroperation auf, so z.B. implizit gelöschte
Assoziationen beim Löschen einer Klasse in UML-Klassendiagrammen.
Könemann beschreibt einen Ansatz zur modellunabhängigen Repräsentation von Differenzen, welche als Patch-Skript eingesetzt werden können [Kö09]. Zentrale Idee zur
Umsetzung der Modellunabhängigkeit der Differenz ist die Ersetzung physikalischer Referenzen auf Modellelemente durch symbolische Referenzen. Die Auflösung symbolischer
Referenzen bildet im Rahmen der Ausführung eines Patches den Kontext, in dem die
in der Differenz enthaltenen Änderungen angewandt werden können. Elementare Änderungen lassen sich zudem anhand ihrer Abhängigkeiten gruppieren. In [Kö10] werden
zudem verschiedene Heuristiken vorgestellt, wie die Beschreibung des Kontextes, in dem
Änderungen angewandt werden können, aufgeweitet werden kann. Änderungen lassen
sich dadurch zu einer Klasse ähnlicher Änderungen gruppieren. Die Gruppierungsheuristiken sind dabei jedoch sehr unscharf und erfordern i.d.R. eine Vielzahl manueller
Nacharbeiten.
Taentzer et al. [TELW10] stellen einen auf Graphtransformationen beruhenden Ansatz vor, welcher eine Modelldifferenz zunächst als, nicht notwendigerweise regelbasierte,
Graphmodifikation des abstrakten Syntaxbaumes auffasst. Aus einer Graphmodifikation lässt sich eine minimale Regel extrahieren, welche genau die erkannten Änderungen
mit einem minimalen Kontext ohne zusätzliche Anwendungsbedingungen enthält. Die
2
http://www.eclipse.org/modeling/emf/?project=compare
6
1 EINFÜHRUNG
minimale Regel wird anschließend mit einer Menge vordefinierter Transformationsregeln
verglichen, welche die auf den zu Grunde liegenden Modelltyp anwendbaren Operationen repräsentiert. Enthält diese Menge eine Unterregel der minimalen Regel, so kann die
Differenz als Effekt der entsprechenden Operation aufgefasst werden. In [TELW10] wird
dabei lediglich der Fall betrachtet, dass eine Differenz durch die Ausführung genau einer
Operation hervorgerufen wird. Der beschriebene Ansatz lässt sich prinzipiell auch auf die
Erkennung von Operationssequenzen erweitern. Aufgrund der Anzahl möglicher Kombinationen von Regelanwendungen wird ein entsprechender Backtracking-Algorithmus
allerdings sehr schnell ineffizient.
1.4 Struktur der Arbeit
In Kapitel 2 werden die Grundlagen eingeführt, auf welchen der in dieser Arbeit vorgestellte Lösungsansatz aufbaut. Der konzeptuelle Ansatz zur Erkennung modelltypspezifischer Editieroperationen auf symmetrischen Differenzen wird in Kapitel 3 vorgestellt. Die
im Rahmen dieser Arbeit entstandene Implementierung wird in Kapitel 4 beschrieben.
Kapitel 5 skizziert die Anwendung der Implementierung auf zwei konkrete Modelltypen;
UML-Klassendiagramme und Matlab/Simulink-Blockdiagramme. Evaluationsergebnisse
für konkrete Testmodelle werden in Kapitel 6 beschrieben. Kapitel 7 fasst die wesentlichen Beiträge der Arbeit zusammen und liefert einen Ausblick auf zukünftige, darauf
aufbauende Forschungsarbeiten.
2 Grundlagen
Die wesentliche konzeptuelle Struktur der in der modellbasierten Softwareentwicklung
eingesetzten Modelle kann i.d.R. als abstrakter Graph angesehen werden. Knoten und
Kanten dieses Graphen bezeichnen wir hier als Modellelemente, welche in der externen
Darstellung der Modelle meist als grafische Knoten bzw. grafische Kanten visualisiert
werden [Kel10a]. Um die abstrakten Graphen mittels verschiedenster Werkzeuge bearbeiten zu können, sind zur internen Repräsentation der Modelle geeignete Datenstrukturen
zu entwerfen, deren Instanzen wir aus Sicht der Systemanalyse ebenfalls als abstrakte
Graphen, meist als abstrakte Syntaxgraphen (ASG) bezeichnet, auffassen können.
Abschnitt 2.1 führt in die graphentheoretischen Grundlagen ein und bildet damit
die formale Basis zur Beschreibung abstrakter Syntaxgraphen und darauf aufbauender
Konzepte. In Abschnitt 2.2 wird mit EMF-Ecore ein Framework zur Implementierung
abstrakter Graphen in verschiedenen technologischen Varianten vorgestellt. Abschnitt
2.3 führt in die Grundlagen der Modelldifferenzen ein. Dabei wird insbesondere der konzeptuelle Inhalt symmetrischer Differenzen definiert und ferner eine konkrete Variante
der Repräsentation symmetrischer Differenzen auf Basis von EMF-Ecore beschrieben.
Abschnitt 2.4 beleuchtet das Graphtransformationssystem EMF-Henshin und skizziert
dessen theoretische Grundlagen.
2.1 Graphen
Graphen bilden die Grundlage vieler Bereiche der Informatik und existieren in zahlreichen Varianten. Im Kern besteht ein Graph aus einer Menge von Knoten sowie einer
Menge von Kanten, wobei eine Kante zwei Knoten miteinander verbindet. Wir betrachten i.F. lediglich gerichtete Graphen.
Definition 2.1.1 (Graph)
Ein (gerichteter) Graph G ist eine algebraische Struktur (V, E, src, tgt) bestehend aus
einer endlichen Menge von Knoten V (engl.: Vertices), einer endlichen Menge von Kanten
E (engl.: Edges) sowie zwei Funktionen src, tgt : E → V , welche jeder Kante einen Quellrespektive einen Zielknoten zuweisen.
7
8
2 GRUNDLAGEN
Auf Basis von Definition 2.1.1 lassen sich Abbildungen von Graphen auf Graphen
formulieren. Von zentraler Bedeutung sind dabei Abbildungen, welche die zu Grunde
liegende Struktur erhalten. Strukturerhaltende Abbildungen auf Graphen werden als
Graph-Homomorphismen bezeichnet.
Definition 2.1.2 (Graph-Homomorphismus)
Seien G1 = (V1 , E1 , src1 , tgt1 ) und G2 = (V2 , E2 , src2 , tgt2 ) zwei Graphen gemäß Definition 2.1.1. Ein Graph-Homomorphismus Φ = (ΦV , ΦE ) : G1 → G2 ist ein Paar von
Abbildungen ΦV : V1 → V2 und ΦE : E1 → E2 , wobei für alle Kanten e ∈ E1 gilt:
src2 (ΦE (e)) = ΦV (src1 (e))
(2.1.1)
tgt2 (ΦE (e)) = ΦV (tgt1 (e))
(2.1.2)
Wir unterstellen i.F. typisierte Graphen und erweitern Definition 2.1.1 um Typinformationen, d.h. um Knoten- und Kantentypen.
Definition 2.1.3 (Typisierter Graph)
Sei T G ein Graph gemäß Definition 2.1.1. Ein Graph G wird durch T G typisiert, wenn
ein Graph-Homomorphismus type = (typeV , typeE ) : G → T G existiert, welcher jedem
Knoten (jeder Kante) in G einen Knotentyp (Kantentyp) in T G zuweist.
Der Graph T G wird dann auch als Typgraph, G = (V, E, src, tgt, type) als T Gtypisierter Instanzgraph bezeichnet. Definition 2.1.2 erweitern wir nachfolgend um die
zusätzliche Bedingung des Erhalts von Knoten- und Kantentypen.
Definition 2.1.4 (Typisierter Graph-Homomorphismus)
Sei T G ein Typgraph, G1 = (V1 , E1 , src1 , tgt1 , type1 ) und G2 = (V2 , E2 , src2 , tgt2 , type2 )
zwei T G-typisierte Instanzgraphen. Ein T G-typisierter Graph-Homomorphismus Φ ist
ein Graph-Homomorphismus gemäß Definition 2.1.2, wobei zusätzlich für alle Knoten
v ∈ V1 und Kanten e ∈ E1 gilt:
type2,V (ΦV (v)) = type1,V (v)
(2.1.3)
type2,E (ΦE (e)) = type1,E (e)
(2.1.4)
Es existieren zahlreiche Erweiterungen der oben eingeführten, typisierten Graphen.
Die im Hinblick auf das im Rahmen dieser Arbeit eingesetzte Framework zur Implementierung abstrakter Graphen (s. Abschnitt 2.2) wichtigsten konzeptuellen Erweiterungen
werden i.F. kurz skizziert, auf entsprechende formale Definitionen wird indessen verzichtet.
2.2. EMF-ECORE
9
Attributierte Graphen. Werden durch die Knoten- bzw. Kantentypen abstrakte Attribute definiert, die bei Knoten- bzw. Kanten dieses Typs vorhanden sind, so spricht man
auch von attributierten Graphen. Ein formaler Ansatz zur Attributierung von Graphen
ist in [EEPT06] zu finden.
Typgraphen mit Vererbungsbeziehungen. Eine weitere Erweiterung der Grundform
typisierter Graphen ist die Einführung von Typhierarchien. Eine formale Definition von
Typgraphen mit Vererbungsbeziehungen sowie entsprechende Erweiterungen der Definition typisierter Graphen ist in [BET08] zu finden.
Graphen mit Kompositionsstrukturen. Graphen mit Kompositionsstrukturen sind Graphen, für die eine Teilmenge der Kanten explizit als Kompositionskanten markiert sind.
Eine Kompositionskante definiert eine hierarchische Beziehung zwischen dem Quellknoten, welcher die Rolle des Vaterknotens einnimmt, und dem Zielknoten, welcher die Rolle
des Kindknotens einnimmt. Kompositionsstrukturen müssen zyklenfrei sein und unterliegen zudem der Einschränkung, dass ein Knoten höchstens einen Vaterknoten besitzt
[BET08].
2.2 EMF-Ecore
Das Eclipse Modeling Framework (EMF) ist ein eigenständiges Eclipse-Projekt, welches
eine technologieübergreifende Implementierung abstrakter Graphen, in EMF auch als
Objektstrukturen bezeichnet, unterstützt. Objektstrukturen in EMF können konzeptuell
als getypte, attributierte Graphen mit Kompositionskanten aufgefasst werden. Objekte
entsprechen den Knoten, Objektreferenzen den Kanten in der graphentheoretischen Konzeptwelt. Die Grundlage zur Formulierung entsprechender Typgraphen in EMF bildet
EMF-Ecore, eine Implementierung der Essential Meta-Object Facility (EMOF) Spezifikation der OMG [OMG10]. EMF-Ecore hat sich inzwischen als quasi-Standard in der
modellbasierten Software-Entwicklung etabliert.
Abbildung 2.1 zeigt den für die Definition von Typgraphen relevanten Ausschnitt
der Ecore-Spezifikation. Knotentypen werden in Ecore als Klassen (EClass), Kantentypen als Referenztypen (EReference) bezeichnet. Referenztypen von Kompositionskanten
werden durch die Merkmalsausprägung containment = true definiert. Referenzen und
Attribute werden in Ecore ferner als strukturelle Eigenschaften (EStructuralFeature)
von Objekten erachtet. Wesentliches Merkmal struktureller Eigenschaften ist zunächst
10
2 GRUNDLAGEN
die Kardinalität (definiert durch die Angabe einer unteren (lowerBound) und einer oberen Schranke (upperBound)). Strukturelle Eigenschaften mit upperBound = 1 bezeichnen wir als skalar, strukturelle Eigenschaften mit upperBound > 1 als mengenwertig. Als
Spezialfall mengenwertiger struktureller Eigenschaften betrachten wir ferner geordnete,
mengenwertige strukturelle Eigenschaften (ordered = true).
Abbildung 2.1: Ecore-Spezifikation (Ausschnitt)
In Ecore formulierte Typgraphen werden im Rahmen dieser Arbeit allgemein als EcoreModell, typisierte Graphen (Instanzgraphen) als Ecore-Instanzen bezeichnet3 . Ecore ist
ausdrucksstark genug, um sich selbst zu beschreiben. Aufgrund der Selbstreferentialität
ist die Ecore-Spezifikation damit Ecore-Modell und -Instanz zugleich. Diesem Umstand
wird in der Ecore-Spezifikation durch die Klassen EObject und EModelElement Rechnung getragen, welche hier jeweils eine Sonderrolle einnehmen: EObject ist die Oberklasse aller Typen von Knoten eines typisierten Graphen. EModelElement ist die Oberklasse aller Typen von Knoten eines Typgraphen. Aufgrund der Selbstreferentialität von
EMF-Ecore ist eine Instanz von EModelElement (also ein Knoten eines Typgraphen)
3
Aus MBSE-Sicht können Ecore-Modelle konzeptuell sowohl als Modell, als auch als Metamodell eingesetzt werden.
2.3. MODELLDIFFERENZEN
11
gleichzeitig auch eine Instanz von EObject (also Knoten eines typisierten Graphen);
EModelElement ist damit eine Spezialisierung der Klasse EObject (vgl. Abb. 2.1).
Ein Überblick über die wesentlichen Begriffe von Ecore und deren graphentheoretischer
Entsprechung ist in Tabelle 2.1 zusammengefasst.
EMF-Ecore
Graphentheorie
Ecore-Instanz
Objekt (EObject)
Referenz
Ecore-Modell
Klasse (EClass)
Referenztyp (EReference)
Instanzgraph
Knoten eines Instanzgraphen
Kante eines Instanzgraphen
Typgraph
Knotentyp (Knoten eines Typgraphen)
Kantentyp (Kante eines Typgraphen)
Tabelle 2.1: Implementierung graphentheoretischer Konzepte in EMF-Ecore
2.3 Modelldifferenzen
Mit der zunehmenden Verbreitung modellbasierter Entwicklungsansätze werden leistungsfähige Werkzeuge für das Konfigurationsmanagement von Modellen unverzichtbar.
Hieraus hat sich ein vielschichtiger Forschungszweig in der Informatik entwickelt, in dessen Mittelpunkt die Berechnung und Verarbeitung von Modelldifferenzen stehen. Die im
Rahmen dieser Arbeit relevanten Aspekte werden i.F. beleuchtet. Abschnitt 2.3.1 führt
die begrifflichen Grundlagen ein. Im Detail wird dabei insbesondere der konzeptuelle
Inhalt symmetrischer Differenzen betrachtet. Darauf aufbauend stellt Abschnitt 2.3.2
die dieser Arbeit zu Grunde liegende, technologiegebundene Variante zur Repräsentation symmetrischer Differenzen auf Basis von EMF-Ecore vor. Abschließend werden in
Abschnitt 2.3.3 verschiedene Ansätze zur Korrespondenzbildung vorgestellt, welche die
Grundlage der Berechnung symmetrischer Differenzen bildet.
2.3.1 Begriffliche Grundlagen
Eine Modelldifferenz (i.F. auch kurz als Differenz bezeichnet) ist eine Darstellung der
Unterschiede zwischen zwei Modellen. Im Folgenden werden zwei grundsätzliche Varianten zur Darstellung des konzeptuellen Inhalts von Differenzen betrachtet; asymmetrische
und symmetrische Differenzen. Inwiefern mehrere Darstellungen des Unterschieds zweier
12
2 GRUNDLAGEN
Modelle denkbar sind, wird im Kontext der beiden Konkretisierungen des Differenzbegriffs kurz beleuchtet.
Der hier verwendeten Definition asymmetrischer Differenzen liegt ein operationaler
Ansatz zu Grunde [Kel09]:
Definition 2.3.1 (Asymmetrische Differenz)
Eine asymmetrische Differenz von einem Modell M1 nach einem Modell M2 ist eine
Transformationsvorschrift mit operationaler Semantik, durch die M1 in M2 transformiert
werden kann.
Als Transformationsvorschrift gegebene Differenzen bezeichnen wir deshalb als asymmetrisch, weil die Transformation i.d.R. gerichtet ist, so z.B. eine Sequenz von Änderungsoperationen. Hier lässt sich die Nicht-Eindeutigkeit asymmetrischer Differenzen
erkennen. Eine Operationssequenz kann beliebig viele Paare inverser Operationen beinhalten, welche sich gegenseitig aufheben. Auch die Darstellung des Unterschieds mittels
bereinigter Sequenzen ohne sich gegenseitig aufhebende Operationen ist nicht eindeutig. Dies zeigt sich bereits an der für alle Unterschiede anwendbaren trivialen Operationssequenz, welche zunächst alle Modellelemente aus M1 löscht und anschließend M2
schrittweise neu aufbaut.
Hinsichtlich der auf ein Modell anwendbaren Änderungsoperationen unterscheiden wir
verschiedene Abstraktionsebenen; von elementaren Graphoperationen auf dem abstrakten Syntaxgraphen bis hin zu komplexen, modelltypspezifischen Refactoring-Operationen
[FBB+ 99]. Eine wichtige Rolle nehmen hierbei Änderungsoperationen ein, welche sich auf
dem Abstraktionsniveau modelltypspezifischer Editoren befinden. Derartige Änderungsoperationen bezeichnen wir i.F. als Editieroperationen. Sofern eine explizite Abgrenzung
zu komplexen Änderungsoperationen wie bspw. Refactorings vorgenommen werden soll,
sprechen wir auch von Basis-Editieroperationen.
Definition 2.3.2 (Editieroperation)
Unter einer Editieroperation verstehen wir eine Operation, mit der ein Modell mittels
eines Editors für den entsprechenden Modelltyp geändert werden kann. Die syntaktische
Konsistenz eines Modells wird durch die Ausführung einer Editieroperation bewahrt.
Editieroperationen entsprechen i.d.R. nicht einer, sondern mehreren elementaren Graphoperation auf dem ASG. Ein Beispiel, das Setzen der Navigierbarkeit von Assoziationsenden in UML-Klassendiagrammen, wurde bereits im Rahmen der einführenden
Problemmotivation gezeigt (vgl. Abschnitt 1.1). Aus Sicht des Modellierers hingegen
stellen Editieroperationen atomare Änderungen auf einem Modell dar, welche von den
elementaren Änderungen des ASG abstrahieren.
2.3. MODELLDIFFERENZEN
13
Die Menge aller Editieroperationen für einen Modelltyp kann als Spezifikation einer
möglichen ASG-Repräsentation von Modellen dieses Typs aufgefasst werden. In Anlehnung an den abstrakten Datentyp als implementierungsneutrale Spezifikation eines
Datentyps verwenden wir hier den Begriff des Editierdatentyps.
Definition 2.3.3 (Editierdatentyp)
Die Menge aller Editieroperationen für einen Modelltyp bezeichnen wir als Editierdatentyp.
Asymmetrische Differenzen lassen sich als direktes Resultat der Protokollierung von
Editieroperationen im Editor gewinnen. In der Praxis ist dies allerdings nur beschränkt
möglich, da hier offene Entwicklungsumgebungen mit den notwendigen Erweiterungspunkten vorausgesetzt werden. Ferner ist hier zu unterstellen, dass die betrachteten Modelle Revisionen voneinander sind. Unterschiede zwischen Modellen, welche unabhängig
voneinander entstandenen sind, lassen sich auf diese Weise nicht gewinnen.
Hat man auf den Editiervorgang keinen direkten Einfluss, so sind Differenzen auf Basis
des aktuellen Zustands der Modelle zu bilden. Entsprechende Verfahren werden auch als
zustandsbasierte Verfahren oder Modellvergleich bezeichnet. Verfahren des Modellvergleichs liegt im Kern ein symmetrischer Differenzbegriff zu Grunde, welcher auf den aus
der Mengenlehre bekannten Begriff der symmetrischen Differenz zurückgeführt werden
kann. Eine schrittweise Erweiterung der mengenbasierten Definition ist in [Kel09] zu
finden und in Definition 2.3.4 zusammengefasst.
Definition 2.3.4 (Symmetrische Differenz)
Eine symmetrische Differenz zwischen zwei Modellen M 1 und M 2 besteht aus folgenden
Angaben (vgl. Abb. 2.2):
1. Einer Menge von Korrespondenzen, welche auch als Matching bezeichnet wird.
Eine Korrespondenz ist ein Paar von je einem Element aus M 1 bzw. M 2, welche
als einander entsprechend angesehen werden,
2. zwei Teilmodellen KM 1 ⊆ M 1 und KM 2 ⊆ M 2, die jeweils genau die Modellelemente enthalten, die in den Korrespondenzen vorkommen,
3. einer bidirektionalen Transformation T , die KM 1 in KM 2 bzw. KM 2 in KM 1 umwandelt und
4. je einer Einfügetransformation pro Modell, die ausgehend von KM 1 bzw. von KM 2
die Modelle M 1 bzw. M 2 rekonstruiert.
14
2 GRUNDLAGEN
Die Menge der korrespondierenden Elemente bildet den Kern symmetrischer Differenzen. Eine allgemeine Anforderung an Korrespondenzen stellt die Typgleichheit der korrespondierenden Elemente dar. Ferner kann jedes Modellelement in höchstens einer Korrespondenz auftreten. Weitere Details, welche Elemente für die Korrespondenzbildung
in Frage kommen, hängen vom Modelltyp und dem Korrespondenzbildungsverfahren (s.
Abschnitt 2.3.3) ab. Gleiches gilt für die Transformation T , welche, je nach Modelltyp
und Berechnungsverfahren, Attributänderungen, Referenzänderungen und Verschiebungen von Elementen umfassen kann. Werden Korrespondenzen nur zwischen identischen
Elementen zugelassen, so entfällt die Transformation T .
Abbildung 2.2: Konzeptueller Inhalt symmetrischer Differenzen
2.3.2 Repräsentation symmetrischer Differenzen
Die Repräsentation symmetrischer Differenzen erfordert den Entwurf einer geeigneten
Datenstruktur, i.F. als Differenzmodell bezeichnet, welche den konzeptuellen Inhalt symmetrischer Differenzen abbildet. In der Literatur werden verschiedene Differenzmodelle
vorgestellt [BP08, RV08, Kö09, CDRP07]. Meist wird der weiteren Verwendung der
Differenz ein konkreter Anwendungsfall unterstellt. So z.B. eine spezielle Variante der
Differenzanzeige, das Patchen von Modellen, die Komposition von Differenzen oder das
Mischen. Ferner werden meist nur sehr einfache Operationen zur Formulierung der Transformation T (s. Definition 2.3.1) zugelassen, welche bspw. für keinen der oben genannten
Ansätze Verschiebungen von Modellelementen beinhaltet.
Diese Arbeit stützt sich auf das im Rahmen des SiDiff-Projekts4 entwickelte Differenzmodell, welches i.F. kurz als SiDiff-Differenzmodell bezeichnet wird. Das Differenzmodell
wurde auf Basis von EMF-Ecore implementiert und verfolgt das Ziel einer anwendungsfallneutralen Beschreibung von Differenzen. Hinsichtlich der Transformation T wird das
4
http://www.sidiff.org
2.3. MODELLDIFFERENZEN
15
gesamte Spektrum elementarer Graphoperationen (inkl. Verschiebungen) unterstützt. Im
Folgenden wird zunächst der Kern des Differenzmodells beschrieben, welcher anschließend weiter ausdifferenziert wird. Zur Veranschaulichung wird abschließend die Differenz
der in Abschnitt 1.1 eingeführten Beispielmodelle als Instanz des SiDiff-Differenzmodells
skizziert.
Abbildung 2.3: SiDiff-Differenzmodell: Kern
SiDiff-Differenzmodell zur Repräsentation symmetrischer Differenzen
Der Kern des Sidiff-Differenzmodells ist in Abb. 2.3 dargestellt. Die Basis einer Differenz
(Difference) zwischen zwei Modellen, i.F. als Modell A und Modell B bezeichnet, bildet
16
2 GRUNDLAGEN
das Matching (Matching). Ein Matching besteht aus einer Menge von Korrespondenzen
(Correspondence), wobei eine Korrespondenz ein Paar korrespondierender Elemente,
bestehend aus einem Element in Modell A (matchedA) und dem dazugehörigen Partner in
Modell B (matchedB) repräsentiert. Aufgrund der Implementierung des Differenzmodells
auf Basis von EMF-Ecore handelt es sich bei den Modellen A und B jeweils um EcoreInstanzen. Knoten der abstrakten Syntaxgraphen der Modelle A und B werden folglich
durch EMF-Objekte (EObject) repräsentiert (vgl. Abschnitt 2.2).
Desweiteren setzt sich eine Differenz aus Kongruenzen (Congruence) und Divergenzen (Divergence) zusammen. Eine Kongruenz bezieht sich auf genau eine Korrespondenz, deren korrespondierende Elemente in allen strukturellen Eigenschaften übereinstimmen. Hinsichtlich der Divergenzen wird zwischen nicht korrespondierenden Elementen (Unmatched) und elementaren Änderungen auf dem ASG (Change) unterschieden.
Änderungen befinden sich konzeptuell zwar im Durchschnitt der Modelle A und B, sind
aber, im Gegensatz zu den kongruenten Elementen, der Transformation T (s. Definition
2.3.1) unterworfen. Wir unterscheiden zwischen Attributänderungen (AttributeChange),
Referenzänderungen (ReferenceChange) und globalen Verschiebungen (Move), welche
i.F. konkretisiert werden.
Attributänderungen. Mögliche Ausprägungen von Attributänderungen sind in Abb.
2.4 dargestellt. Eine Attributänderung bezieht sich konzeptuell auf die Definition des
Attributs in dem zu Grunde liegenden Metamodell, welches hier als EMF-Modell vorliegt. Die Definition eines Attributs wird somit durch eine Instanz der Ecore-Metaklasse
EAttribute repräsentiert (s. Abschnitt 2.2).
Wir betrachten zunächst Attributänderungen an nicht korrespondierenden Elementen: Werte von Attributen spezieller Elemente in A (bzw. B) sind in B (bzw. A) nicht
vorhanden. Für skalare und mengenwertige Attribute wird dies durch Instanzen der Klasse AttributeValueNotInB (bzw. AttributeValueNotInA) ausgedrückt. Für geordnete
mengenwertige Attribute wird zudem die Position (position) angegeben, an welcher der
Wert nicht vorhanden ist (AttributeIValueNotInB bzw. AttributeIValueNotInA).
Im Falle von Attributänderungen korrespondierender Elemente unterscheiden wir zwischen Änderungen an Attributen, welche als skalare (1.), mengenwertige (2.) oder geordnete mengenwertige (3.) strukturelle Eigenschaften definiert sind:
1. Attributwertänderungen (AttributeValueChange) treten lediglich im Kontext skalarer Attributdefinitionen auf und repräsentieren die Änderung eines Attributwerts
der korrespondierenden Elemente.
2.3. MODELLDIFFERENZEN
17
2. Im Falle mengenwertiger Attribute werden alle Attributwerte als gelöscht oder eingefügt (AttributeValueNotInB bzw. AttributeValueNotInB) betrachtet. Existiert ein Konzept der Gleichheit von Attributwerten, so kann der konzeptuelle
Durchschnitt der Mengen von Attributwerten gebildet werden. Die im Durchschnitt
enthaltenen Attributwerte sind dann keiner Änderung unterworfen.
3. Die oben beschriebenen Ausprägungen von Attributänderungen lassen sich für Änderungen an geordneten mengenwertigen Attributen spezialisieren. Zusätzlich wird
hier jeweils die Listenposition (position) angeben, welche der entsprechenden Änderung unterworfen ist. Existiert ein Konzept der Gleichheit von Attributwerten, so
lassen sich zudem lokale Verschiebungen eines Attributwerts (AttributeValueMove)
von positionA nach positionB beschreiben.
skalar
mengenwertig
mengenwertig,
geordnet
Abbildung 2.4: SiDiff-Differenzmodell: Attributänderungen
Referenzänderungen. Eine Referenzänderung an einem Modellelement, welches als
Träger der geänderten Referenz fungiert, bezieht sich auf die Definition eines Referenztyps (EReference) im den Modellen A bzw. B zu Grunde liegenden Metamodell.
Bei nicht korrespondierenden Elementen als Träger von Referenzen sprechen wir, in
Analogie zu Attributänderungen, von nicht vorhandenen Referenzen; ReferenceNotInA
bzw. ReferenceNotInB im Falle skalarer und mengenwertiger Referenztypen. Für geordnete Kollektionen von Referenzen wird auch hier die entsprechende Position der nicht
vorhandenen Referenzen angegeben (ReferenceINotInA bzw. ReferenceINotInB).
Konkrete Ausprägungen von Referenzänderungen an korrespondierenden Elementen
als Träger von Referenzen ergeben sich in Analogie zu den Ausprägungen von Attributän-
18
2 GRUNDLAGEN
derungen anhand der Klassifizierung in skalare, mengenwertige und geordnete mengenwertige Referenztypen (s. Abb. 2.5).
skalar
mengenwertig
mengenwertig,
geordnet
Abbildung 2.5: SiDiff-Differenzmodell: Referenzänderungen
Globale Verschiebungen. Korrespondierende Elemente, deren jeweilige Vaterelemente
nicht korrespondieren, stellen globale Verschiebungen dar (Move). Eine globale Verschiebung kann als Aggregation zweier Referenzänderungen aufgefasst werden; der gelöschten Kompositionsreferenz in A (ReferenceChangeA) und der erzeugten Kompositionsreferenz in B (ReferenceChangeB). Handelt es sich bei dem verschobenen Element um
einen Wurzelknoten in A, bzw. wird ein Element zum Wurzelknoten in B, so entfallen
die entsprechenden Referenzänderungen ReferenceChangeA bzw. ReferenceChangeB.
Differenz der Varianten A und B des einführenden Beispiels
Zur Veranschaulichung zeigt Abb. 2.6 die Differenz der Varianten A und B des in Abschnitt 1.1 eingeführten Beispiels als Instanz des SiDiff-Differenzmodells. Wir unterstellen hier die Korrespondenzpaare (C2,C2), (a,a), (C1,C1), (C1-C2), (C1-C2) und (b,b), von
denen in Abb. 2.6 lediglich die letzteren drei dargestellt sind. Aus Gründen der Übersichtlichkeit sind die Korrespondenzen sowie die Elemente der abstrakten Syntaxgraphen
A und B transparent dargestellt. Die aus den Korrespondenzen abgeleiteten Divergenzen
werden in Abb. 2.6 hervorgehoben.
Die Referenzänderung :ReferenceNotInB repräsentiert die gelöschte Kompositionsreferenz ownedEnd zwischen dem Assoziations-Knoten C1-C2 und dem Property b. Die
Referenzänderung :ReferenceNotInA repräsentiert die eingefügte Kompositionsreferenz
ownedAttribute zwischen dem Klassen-Knoten C1 und dem Property b. Das Aggregat
2.3. MODELLDIFFERENZEN
19
der Referenzänderungen :ReferenceNotInB und :ReferenceINotInA kann als Verschiebung des Property-Knotens b aufgefasst werden.
targetA
sourceA
matchedA
matchedA
A
matchedA
targetA
:ReferenceTargetChange
:ReferenceNotInB
correspondence
:Correspondence
:Correspondence
referenceChangeA
:Move
correspondence
:Correspondence
correspondence
correspondence
referenceChangeB
:ReferenceNotInA
matchedB
correspondence
:ReferenceTargetChange
matchedB
sourceB
targetB
B
targetB
matchedB
Abbildung 2.6: Technische Differenz der Beispielmodelle A und B
Die beiden Referenzänderungen vom Typ ReferenceTargetChange stellen jeweils Referenzzieländerungen aus Sicht des Property-Knotens b dar; in Variante A hat sich das
Ziel der Referenz vom Typ des skalaren Referenztyps owningAssociation von C1-C2
nach null geändert, in Variante B hat sich das Ziel der Referenz vom Typ des skalaren Referenztyps class von null nach C1 geändert. Beide Referenzzieländerungen
20
2 GRUNDLAGEN
stellen Pseudodifferenzen dar, welche lediglich aus der Implementierung konzeptuell ungerichteter Kanten als zwei gegenläufig synchronisierte, gerichtete Kanten in EMF-Ecore
resultieren.
Aufgrund der Beschreibung der Differenz auf Basis elementarer Operationen auf der
jeweiligen Implementierung der abstrakten Syntaxgraphen, im Beispiel A und B, bezeichnen wir derartige Differenzen auch als technische Differenzen. Der Unterschied zweier
Modelle wird dabei zwar korrekt und vollständig wiedergegeben, entspricht aber meist
nicht der intuitiven Auffassung des Benutzers.
2.3.3 Korrespondenzbildungsverfahren
Im Kern basiert die Berechnung symmetrischer Differenzen auf der Bildung von Korrespondenzen (s. Abschnitt 2.3.1). Eine Klassifikation der verschiedenen Algorithmen zur
Korrespondenzbildung ist in [KDRPP09] zu finden. Die verschiedenen Ansätze werden
i.F. kurz beschrieben.
Korrespondenzbildung auf Basis persistenter Identifizierer. Bei diesem Ansatz wird
unterstellt, dass Modellelementen bei der Erzeugung ein vom Modellierungswerkzeug
vergebener, eindeutiger Identifizierer zugewiesen wird, welcher auch in der physischen
Repräsentation des Modells erhalten bleibt. Die Bildung von Korrespondenzen auf Basis
von persistenten Identifizierern ist damit trivial und kann sehr effizient implementiert
werden. Der Ansatz erfordert jedoch eine homogene Modellierungsumgebung und unterstellt zudem, dass die verglichenen Modelle Revisionen voneinander sind. Auf unabhängig
voneinander entstandene Varianten eines Modells kann dieser Ansatz nicht angewendet
werden.
Signaturbasierte Verfahren. Signaturbasierte Verfahren ersetzen statische Identifizierer durch die Berechnung dynamischer Signaturen. Die Signatur eines Modellelements
wird dabei durch eine Funktionsvorschrift gebildet, welche auf einer Menge bzw. Teilmenge der lokalen Eigenschaften sowie der „Umgebung“ eines Modellelements definiert
ist. Modellelemente gleicher Signatur sind potentielle Kandidaten zur Bildung von Korrespondenzen. Im Gegensatz zur Korrespondenzbildung auf Basis persistenter Identifizierer
ist hier jedoch zu beachten, dass die erzeugten Signaturen nicht eindeutig sein müssen,
was eine geeignete Behandlung von Duplikaten erfordert.
Ähnlichkeitsbasierte Verfahren. Grundlage ähnlichkeitsbasierter Verfahren ist die Berechnung der Ähnlichkeiten aller für eine Korrespondenz in Frage kommenden Paarbil-
2.4. DAS GRAPHTRANSFORMATIONSWERKZEUG EMF-HENSHIN
21
dungen typgleicher Elemente aus M1 und M2. Die Ähnlichkeit zweier Modellelemente
e1 und e2 wird dabei auf Basis einer Heuristik bestimmt. Korrespondenzen werden prinzipiell zwischen Elementen mit der höchsten Ähnlichkeit gebildet, sofern ein gewisser
Mindestwert überschritten wird, wobei versucht wird, eine global optimierte MatchingSituation herzustellen. Die Komplexität ähnlichkeitsbasierter Verfahren ist dadurch begründet, dass die Umgebungen zweier Modellelemente, neben deren lokalen Eigenschaften, i.d.R. einen Anteil an der Ähnlichkeit der Elemente besitzen. Ähnlichkeiten beeinflussen sich damit gegenseitig. Zyklisch voneinander abhängige Ähnlichkeiten können
nach dem in [MGMR02] beschriebenen Similarity Flooding Algorithmus propagiert werden, bis sich stabile Ähnlichkeitswerte „aufgeschaukelt“ haben oder eine gewisse Anzahl
an Iterationen erreicht wurde.
2.4 Das Graphtransformationswerkzeug EMF-Henshin
Ersetzungsmechanismen auf Zeichenketten (Chomsky-Grammatiken), Ersetzungsmechanismen auf Termen (Term-Rewriting) sowie Petrinetze bilden den Ursprung verschiedener Ansätze zur regelbasierten Graphtransformation, von denen wir in Abschnitt
2.4.1 die Grundlagen des algebraischen Double-Pushout-Ansatzes betrachten, welcher die
theoretische Basis des Graphtransformationswerkzeugs EMF-Henshin bildet. Abschnitt
2.4.2 betrachtet die Ecore-spezifischen Erweiterungen der in Abschnitt 2.4.1 eingeführten
Grundlagen. Abschließend werden in Abschnitt 2.4.3 die abstrakte und konkrete Syntax
zur Repräsentation von Transformationsregeln in Henshin beleuchtet.
2.4.1 Grundlagen algebraischer Graphtransformationen
Die formale Basis des algebraischen Double-Pushout-Ansatzes (DPO-Ansatz) bildet die
Kategorientheorie, auf deren Grundlagen hier nicht näher eingegangen wird. Wir unterstellen i.F. die Definition einer geeigneten Kategorie Graphs, wie sie bspw. in [EHKPP91]
zu finden ist. Darauf basierend lässt sich eine Graphtransformation mittels Pushouts in
der Kategorie Graphs beschreiben. Wir beginnen mit der Definition von Graphtransformationsregeln.
Definition 2.4.1 (Graphtransformationsregel)
l
r
Eine Graphtransformationsregel (oder Graphproduktion) p = (L ← K → R) besteht
aus drei Graphen L, K, R und einem Paar injektiver Graphmorphismen l, r mit dem
gemeinsamen Urbild K.
22
2 GRUNDLAGEN
Graphtransformationsregeln werden i.F. auch kurz als Transformationsregel oder Regel bezeichnet. Die Graphen L und R werden auch als linke Seite (engl.: left-hand side,
kurz LHS) bzw. rechte Seite (engl.: right-hand side, kurz RHS) der Regel bezeichnet.
Den Graphen K bezeichnen wir in diesem Kontext auch als Klebegraphen, welcher die
LHS und die RHS miteinander verbindet. Unter einem Transformationssystem verstehen
wir hier eine definierte Menge von Transformationsregeln, wobei wir einen gemeinsamen
Typgraphen unterstellen.
Definition 2.4.2 (Graphtransformationssystem)
Ein Graphtransformationssystem (T G, P ) ist ein Paar bestehend aus einer Menge von
Transformationsregeln P und einem Graphen T G, welcher den Typgraph der Graphen
L, K und R aller Transformationsregeln ∈ P bildet.
Gegenstand der nachfolgenden Betrachtungen ist die Anwendung von Transformationsregeln, welche wir zunächst aus symmetrischer, anschließend aus asymmetrischer
Perspektive betrachten.
Definition 2.4.3 (Direkte Graphtransformation)
l
r
Sei p = (L ← K → R) eine Transformationsregel und c ein Graphmorphismus K → C,
p
so ist G ⇒ H eine direkte Transformation des Graphen G in den Graphen H mittels p,
gegeben durch die beiden Pushouts P O1 und P O2 nach Diagramm (2.4.1).
(2.4.1)
Im Sinne der Kategorientheorie können die beiden Pushouts (P O1 ) bzw. (P O2 ) interpretiert werden als Verklebungen der Graphen L und C über K bzw. R und C über
K. Dies reflektiert die symmetrische Sicht auf direkte Graphtransformationen, bei der,
zusätzlich zur Transformationsregel p, der Kontextgraph C zusammen mit dem Morphismus K → C gegeben sind, und G und H durch Pushouts wie folgt konstruiert werden:
Das Tripel (G, m, g) ist Pushout des Morphismenpaars (l, c), das Tripel (H, n, h) ist
Pushout des Morphismenpaars (r, c). G und H werden dann auch als Pushout-Objekte
bezeichnet.
In der Praxis interessiert, im Gegensatz zu der oben beschriebenen, symmetrischen
Sicht auf direkte Transformationen, i.d.R. die Anwendung einer Regel p auf einen gegebenen Arbeitsgraphen G über einem Vorkommen (engl.: Occurence) m : L → G der
2.4. DAS GRAPHTRANSFORMATIONSWERKZEUG EMF-HENSHIN
23
LHS in G. Der Morphismus m wird auch als Match bezeichnet. Ein Match kann entweder (partiell) gegeben sein (Prematch), oder durch die Lösung eines Constraint-Problems
berechnet werden. Die in Definition 2.4.3 eingeführte Notation für die Anwendung einer
Regel p wird dann auch um das Vorkommen o der LHS im Arbeitsgraphen G erweitert;
p(o)
p(o)
G =⇒ H. Intuitiv wird der Ergebnisgraph H durch G =⇒ H in den folgenden drei
Schritten konstruiert [Hec06]:
1. Es wird ein Vorkommen oL der LHS in G gesucht.
2. Anschließend werden alle Knoten und Kanten in G gelöscht, welche durch m(L\R)
gematcht werden.
3. Abschließend wird eine Kopie der exklusiv in der RHS enthaltenen Knoten und
Kanten R \ L eingefügt.
p1 (o1 )
p1 (o1 )
Unter einer Transformationssequenz G =⇒ . . . =⇒ H verstehen wir ferner eine
Folge direkter Transformationen unter Anwendung der Transformationsregeln p1 . . . pn
und deren LHS-Vorkommen o1 . . . on in G. Die Existenz einer solchen Folge wird mit
G ⇒∗ H abgekürzt und hängt von der Anwendbarkeit der Transformationsregeln ab.
Definition 2.4.4 (Anwendbarkeit von Transformationsregeln)
l
r
Sei p = (L ← K → R) eine Transformationsregel, G ein Graph und m : L → G
ein Auftreten von L in G, so ist p dann auf G anwendbar, wenn die folgenden beiden
Bedingungen erfüllt sind:
1. Es existieren ein Kontextgraph C und Morphismen c : K → C und g : C → G,
so dass P O1 in Diagramm (2.4.1) ein Pushout wird. Das Tripel (C, c, g) ist in
diesem Fall das Pushout-Komplement zu (l, m). C wird dann auch als PushoutKomplement-Objekt bezeichnet.
2. Es existiert ein Graph H zusammen mit den Morphismen n : R → H und h : C →
H, so dass (H, n, h) der Pushout zu (r, c) entsprechend P O2 in Diagramm (2.4.1)
wird.
Man kann zeigen, dass Pushouts für Graphen immer existieren. Dies gilt nicht für
das Pushout-Komplement. Es zeigt sich jedoch, dass für die Existenz eines PushoutKomplement-Objekts die Klebebedingung hinreichend ist, und somit ein zu Definition
2.4.4 äquivalentes Kriterium für die Anwendbarkeit von Transformationsregeln darstellt
[Ehr79].
24
2 GRUNDLAGEN
Definition 2.4.5 (Klebebedingung)
l
r
Sei p = (L ← K → R) eine Transformationsregel und m : L → G ein Auftreten von L in
G, so ist die Klebebedingung (engl.: Gluing Condition) dann erfüllt, wenn DP ∪IP ⊆ GP
mit:
• GP = lV (VK ) ∪ lE (EK ) = l(K)
• DP = {v ∈ VL |∃e ∈ EM \ mE (EL ) : mV (v) = src(e) ∨ mV (v) = tgt(e)}
• IP = {v ∈ VL |∃v 0 6= v : mV (v 0 ) = mV (v)} ∩ {e ∈ EL |∃e0 6= e : mE (e0 ) = mE (e)}
Die Mengen GP , DP und IP repräsentieren dabei jeweils Teilmengen der Knoten und
Kanten der LHS (Graph L). Die Menge GP (engl.: Gluing Points) beinhaltet die durch
die Regelanwendung erhaltenen Knoten und Kanten. Die Menge DP (engl.: Dangling
Points) beinhaltet diejenigen Knoten, welche einen durch den Match zugewiesenen Bildknoten in G besitzen, der Quelle oder Ziel einer Kante in G ist, die kein Urbild in L
besitzt. Der Erhalt der durch die Menge DP repräsentierten Knoten stellt sicher, dass
im Zuge der Regelanwendung keine hängenden Kanten entstehen. Die Menge IP (engl.:
Identification Points) beinhaltet alle Knoten, welche durch m nicht-injektiv abgebildet
werden. Der Erhalt nicht-injektiv abgebildeter Knoten und Kanten vermeidet Konfliktsituationen, in denen ein Knoten oder eine Kante sowohl erhalten, als auch gelöscht
werden müsste.
Als Eigenschaften der Transformationsregeln eines Transformationssystems werden
abschließend die parallele sowie die sequentielle Unabhängigkeit von Regeln betrachtet.
Definition 2.4.6 (Parallele Unabhängigkeit)
Die parallele Unabhängigkeit von Transformationsregeln ist induktiv wie folgt definiert:
p1 (o1 )
• Eine direkte Graphtransformation G =⇒ H ist schwach parallel unabhängig von
p2 (o2 )
einer Transformation G =⇒ H, wenn o1 (L1 ) keine Knoten und Kanten enthält,
welche durch die Anwendung von p2 gelöscht werden.
• Zwei direkte Graphtranformationen sind parallel unabhängig, wenn sie jeweils
schwach parallel unabhängig sind.
• Zwei Transformationsregeln sind voneinander unabhängig, wenn alle möglichen Transformationen (auf beliebigen Graphen G und allen möglichen LHSVorkommen o in G) mit diesen Regeln voneinander unabhängig sind.
2.4. DAS GRAPHTRANSFORMATIONSWERKZEUG EMF-HENSHIN
25
Definition 2.4.7 (Sequentielle Unabhängigkeit)
Die sequentielle Unabhängigkeit von Transformationsregeln ist induktiv wie folgt definiert:
p1 (o1 )
p2 (o2 )
• Zwei direkte Graphtransformationen G =⇒ Z =⇒ H sind sequentiell unabhängig, wenn
1. o2 (L2 ) keine Knoten und Kanten enthält, welche durch die Anwendung von
p1 erzeugt werden und
2. p2 keine Knoten und Kanten löscht, welche in o1 (L1 ) enthalten sind.
• Die sequentielle Unabhängigkeit von Transformationsregeln ist analog zur parallelen Unabhängigkeit definiert.
2.4.2 Ecore-spezifische Erweiterungen
Die Adaption des in Abschnitt 2.4.1 eingeführten DPO-Ansatzes auf die Implementierung abstrakter Graphen in EMF-Ecore erfordert die konzeptuelle Erweiterung auf
attributierte Graphen mit Kompositionskanten und Typgraphen mit Vererbung. Eine
formale Definition der Erweiterungen ist in [BET08] zu finden. Die sich dadurch ergebenden Implikationen werden i.F. kurz zusammengefasst.
Für Graphen mit Kompositionskanten gelten die Invarianten, dass jeder Knoten höchstens einen Container-Knoten besitzt und ferner die Kompositionsstruktur des Graphen
keine Zyklen enthält. Zusätzlich zu den in der Klebebedingung (vgl. Definition 2.4.5)
formulierten Konsistenzkriterien sind Konsistenz-erhaltende Transformationen für Graphen mit Kompositionskanten somit weiter einzuschränken. Folgende Aktionen, welche
die Änderung der Kompositionsstruktur betreffen, führen zu Transformationen, welche
die Konsistenz erhalten:
1. Das Löschen eines Knotens inklusive der zugehörigen Kompositionskante.
2. Die Erzeugung eines Knotens, welcher direkt in einen geeigneten Container-Knoten
eingefügt wird.
3. Die Löschung einer Kompositionskante, sofern der zugehörige Kindknoten ebenfalls
gelöscht wird oder einen neuen Container-Knoten zugewiesen bekommt.
4. Die Erzeugung einer Kompositionskante, sofern der zugehörige Kindknoten ebenfalls erzeugt wird oder einen neuen Container-Knoten zugewiesen bekommt.
26
2 GRUNDLAGEN
5. Kompositionskanten, welche potentiell Zyklen in der Kompositionsstruktur erzeugen können, dürfen zusätzlich nur dann erzeugt werden, wenn der alte und der neue
Container-Knoten in der transitiven Hülle eines gemeinsamen Container-Knotens
enthalten sind.
Die Existenz von Typhierarchien führt ferner insofern zu einem polymorphen Verhalten bei der Anwendung von Transformationsregeln, als dass abstrakter typisierte Knoten
der Regel auf konkreter typisierte Knoten des Arbeitsgraphen abgebildet werden können.
2.4.3 Repräsentation von Transformationsregeln
Nachfolgend wird zunächst die abstrakte Syntax zur Repräsentation von Transformationsregeln in EMF-Henshin beschrieben. Anschließend wird die im Rahmen dieser Arbeit
verwendete konkrete Syntax skizziert.
Abstrakte Syntax
Abb. 2.7 zeigt den im Rahmen dieser Arbeit relevanten Anteil der abstrakten Syntaxdefinition, in [ABJ+ 10] auch als „Henshin-Metamodell“ bezeichnet, von Transformationsregeln in Henshin, welche i.F. beschrieben wird.
Abbildung 2.7: Transformationsregeln in EMF-Henshin: Abstrakte Syntax
2.4. DAS GRAPHTRANSFORMATIONSWERKZEUG EMF-HENSHIN
27
Transformationsregeln. Eine Transformationsregel (Rule) besteht aus einem LHS- und
einem RHS-Graphen (Graph), welche die konzeptuellen Graphen L und R in Diagramm
2.4.1 repräsentieren. Knoten (Node), Kanten (Edge) und Attribute (Attribute) werden
jeweils durch Instanzen der Ecore-Metaklassen EClass, EReference und EAttribute typisiert. Der konzeptuelle Klebegraph K ergibt sich implizit aus der Abbildung (Mapping)
von Knoten der RHS auf Knoten der LHS.
Anwendungsbedingungen. LHS-Graphen können zusätzlich mit Anwendungsbedingungen annotiert werden (NestedCondition), welche die Existenz bzw. Nicht-Existenz bestimmter Graph-Muster (conclusion) im Arbeitsgraphen erzwingen. Einzelne Anwendungsbedingungen können in Form logischer Formeln (Formula) zu komplexen Anwendungsbedingungen verknüpft werden. Eine wichtige Teilmenge von Anwendungsbedingungen sind negative Anwendungsbedingungen (engl: Negative Application Condition,
kurz NAC), welche die Anwendung einer Transformationsregel in bestimmten Kontexten
verbieten.
Amalgamierung. Über das Konzept der Amalgamierung [BET10] lassen sich allquantifizierte Regeln zur Anwendung auf eine unbestimmte Anzahl gleicher Muster-Instanzen
definieren. Eine AmalgamationUnit besteht aus einer Kernel-Regel (kernelRule) und
einer beliebigen Anzahl an Multi-Regeln (multiRules). Die Einbettung einer KernelRegel in eine Multi-Regel wird durch Abbildungen von Knoten der Kernel-Regel auf
Knoten der Multi-Regel (lhsMappings und rhsMappings) definiert. Bei der Ausführung
einer AmalgamationUnit wird nach genau einem Vorkommen der LHS der Kernel-Regel
gesucht. Ein gefundener Match dient als gemeinsamer Teilmatch aller Multi-Regeln,
welche anschließend parallel so oft wie möglich, d.h. für alle möglichen Vorkommen der
jeweiligen LHS einer Multi-Regel, angewendet werden. Knoten einer Multi-Regel werden
auch als Multi-Objekte bezeichnet, welche stellvertretend die Menge aller Knoten mit
den definierten Eigenschaften (Typ, Attributwerte und Beziehungen zu anderen Knoten)
des entsprechenden Knotens der Multi-Regel repräsentieren.
Konkrete Syntax
Zur Notation von Transformationsregeln wird in dieser Arbeit die konkrete Syntax des
integrierten Diagrammeditors von Henshin verwendet, welche an die Notation von UMLObjektdiagrammen [OMG07] angelehnt ist. LHS und RHS werden dabei in einem Vereinigungsdiagramm dargestellt. Exklusiv in der LHS vorkommende Knoten und Kanten,
28
2 GRUNDLAGEN
d.h. bei der Anwendung der Regel gelöschte Elemente, werden rot dargestellt und mit
dem „Stereotyp“ «delete» annotiert. Exklusiv in der RHS vorkommende, d.h. bei der Anwendung der Regel erzeugte, Elemente werden in grün dargestellt und mit dem Stereotyp
«create» annotiert. Durch die Anwendung der Regel bewahrte Elemente, d.h. Elemente
des konzeptuellen Klebegraphen K, werden in schwarz dargestellt und mit dem Stereotyp «preserve» annotiert. In Anwendungsbedingungen vorkommende Graph-Muster
werden in orange dargestellt und mit dem Stereotyp «forbid» annotiert.
In Abweichung zum Henshin-Diagrammeditor stellen wir zudem Kernel- und MultiRegeln einer amalgamierten Regel in einem Diagramm dar. Knoten der Multi-Regel
werden in Anlehnung an die Notation von Multi-Objekten in UML-Objektdiagrammen
als doppelt gerahmte Rechtecke notiert.
3 Konzeptueller Lösungsansatz
Grundlegende Idee des hier vorgestellten Lösungsansatzes ist es, technische Divergenzen, d.h. elementare Änderungen auf dem ASG (s. Abschnitt 2.3.2), zu gruppieren.
Die Gruppierung erfolgt dabei anhand von in der Differenz auftretenden Änderungsmustern, welche konzeptuell aus der Ausführung einer Editieroperation (vgl. Definition
2.3.2) resultieren. Abschnitt 3.1 veranschaulicht zunächst das Prinzip der Gruppierung
von Divergenzen, bevor sich Abschnitt 3.2 der Repräsentation gruppierter Divergenzen
widmet. Anschließend wird in Abschnitt 3.3 ein auf regelbasierten Graphtransformationstechniken basierender, generischer Ansatz vorgestellt, mit dem die Erkennung von
Änderungsmustern und die daraus folgende Gruppierung der Divergenzen automatisiert
werden kann.
3.1 Gruppierung von Divergenzen
Die aus einer Editieroperation resultierenden Modelländerungen setzen sich i.d.R. aus
mehreren elementaren Divergenzen zusammen. Dies zeigt sich bereits an dem einfachen
Beispiel, welches in Abschnitt 1.1 eingeführt wurde. Hier ist die technische Differenz
der Varianten A und B des betrachteten Klassendiagramms — eine globale Verschiebung (Move) bestehend aus zwei Referenzänderungen (ReferenceNotInA), ferner zwei als
Pseudodifferenzen aufzufassende Referenzzieländerungen (ReferenceTargetChange)5 —
als das Setzen der Navigierbarkeit des Assoziationsendes b aufzufassen. Konzeptuell
lassen sich diese technischen Divergenzen somit zu einer zusammengesetzten Divergenz gruppieren, welche der Editieroperation zum Setzen der Navigierbarkeit von UMLAssoziationsenden, i.F. als setNavigabilityOfAssociationEnd (vgl. Tab. 5.2) bezeichnet,
entspricht (s. Abb. 3.1).
Editieroperationen können indessen in einer weitaus größeren Anzahl an technischen
Divergenzen resultieren, als dies für das Setzen der Navigierbarkeit von Assoziationsen-
5
vgl. auch Abbildung 2.6
29
30
3 KONZEPTUELLER LÖSUNGSANSATZ
setNavigabilitOfAssociationEnd:EditOperation
:ReferenceTargetChange
:Move
:ReferenceNotInA
:ReferenceTargetChange
:ReferenceNotInB
Abbildung 3.1: Exemplarische Divergenzgruppierung: setNavigabilityOfAssociationEnd
Technische
Divergenzen
Fragmente
Editieroperationen
den in UML-Klassendiagrammen der Fall ist. Hier kann es zweckmäßig sein, Teilmengen
der Menge aller technischen Divergenzen einer Editieroperation zu Fragmenten zu gruppieren. Fragmente entsprechen für sich genommen keiner Editieroperation, bilden jedoch
einen konzeptuell zusammenhängenden Anteil einer Editieroperation.
addAttribute:EditOperation
addNode:Fragment
addNode:Fragment
addNode:Fragment
addNode:Fragment
property:Unmatched
literalLower:Unmatched
literalUpper:Unmatched
:ReferenceNotInA
:AttributeValueNotInA
:ReferenceNotInA
:AttributeValueNotInA
:ReferenceNotInA
:AttributeValueNotInA
Abbildung 3.2: Exemplarische Divergenzgruppierung; Editieroperation addAttribute
Abb. 3.2 adressiert hier exemplarisch die Einfügung eines Attributs in eine Klasse im
Falle von UML-Klassendiagrammen (vgl. Tabelle 5.2: Editieroperation addAttribute).
Auf ASG-Ebene führt die Einfügung eines Attributs zur Erzeugung eines Property-
3.2. REPRÄSENTATION GRUPPIERTER DIVERGENZEN
31
Knotens (Fragment (1)) sowie zwei Knoten zur Repräsentation der Kardinalität6 des
Attributs (Fragmente (2) und (3)). Da die Einfügung eines Property-Knotens untrennbar mit der Angabe der Kardinalität verbunden ist, sind die Fragmente (1), (2) und (3)
zu einem weiteren Fragment (4) gruppiert. Dieses repräsentiert somit das Einfügen eines
Property-Knotens inklusive der Angabe der Kardinalität. Da die Klasse Property im
UML-Metamodell die gemeinsame Abstraktion von Attributen und Assoziationsenden
darstellt [OMG07], können Fragmente vom Typ addProperty sowohl als Baustein der
Editieroperation addAttribute, als auch der Editieroperation addAssociation (vgl. Tabelle 5.2) fungieren. Ersterer beider Fälle ist in Abb. 3.2 exemplarisch dargestellt. Ebenfalls
dargestellt sind hier die aufeinander aufbauenden Abstraktionsebenen, auf welchen wir
Divergenzen im Rahmen dieser Arbeit betrachten: Auf unterster Ebene befinden sich die
technischen Divergenzen, eine erste Abstraktionsstufe bilden Fragmente und auf oberster
Ebene befinden sich Gruppierungen, welche das Resultat modelltypspezifischer Editieroperationen repräsentieren.
3.2 Repräsentation gruppierter Divergenzen
Abb. 3.3 zeigt die zur Repräsentation gruppierter Divergenzen vorgenommenen Erweiterungen des in Abschnitt 2.3.2 eingeführten Differenzmodells. Der Kern der Erweiterungen
ist gemäß dem Entwurfsmuster Kompositum [GHJV95] umgesetzt. Komponenten sind
dabei vom Typ Divergence. Der Kompositumtyp ComplexOperation ist zunächst abstrakt definiert, wobei Fragmente (Fragment) und Editieroperationen (EditOperation)
konkrete Spezialisierungen darstellen. Die Aggregationsbeziehung7 divergences dient
der hierarchischen Gliederung von Komponenten. Blätter konkreter Kompositionsstrukturen bilden technische Divergenzen (Instanzen der Typen Unmatched und Change inklusive der in Abschnitt 2.3.2 eingeführten Subtypen). Eingeschränkt werden die möglichen
Kompositionsstrukturen dahingehend, dass Fragmente lediglich Fragmente und elementare Divergenzen, nicht jedoch Editieroperationen enthalten dürfen. Editieroperationen
unterliegen hinsichtlich des Typs aggregierter Komponenten keinen Einschränkungen.
6
Das UML-Metamodell sieht zur Definition der Kardinalität von Property-Knoten zwei eigenständige
Literal-Knoten erster Ordnung vor, welche die obere und untere Schranke der Kardinalität definieren.
7
Aus Sicht der Implementierung des Differenzmodells in EMF-Ecore sind die hier dargestellten Kompositionsstrukturen lediglich als logische Kompositionsstrukturen anzusehen; physische ContainerKlasse aller Fragmente und Editieroperationen ist die Differenz (Difference).
32
3 KONZEPTUELLER LÖSUNGSANSATZ
Abbildung 3.3: Repräsentation gruppierter Divergenzen
Ferner sind einige abgeleitete Referenztypen definiert, welche die folgenden Knotenmengen repräsentieren:
• /nonAggregatedTechnicalDivergences: Die Menge der nicht aggregierten, technischen Divergenzen
• /nonAggregatedOperations: Die Menge der nicht aggregierten Fragmente und
Editieroperationen
• /allTechnical: Die Menge der aus Sicht eines Fragments bzw. aus Sicht einer
Editieroperation direkt und rekursiv enthaltenen, technischen Divergenzen
3.3 Gruppierungsalgorithmus
Die Repräsentation symmetrischer Modelldifferenzen lässt sich konzeptuell als Klebegraph 8 auffassen, welcher die Unterschiede zweier Modelle auf Basis von deren abstrakten
Syntaxgraphen darstellt. Dies ermöglicht den Einsatz regelbasierter Graphtranformationstechniken zur weiteren Verarbeitung von Differenzen. Sowohl die Mustererkennung als
8
Der Begriff Klebegraph entspricht in diesem Kontext nicht dem Klebegraphen der formalen Definition
von Transformationsregeln (s. Abschnitt 2.4.1), sondern wird hier lediglich zur Veranschaulichung
verwendet.
3.3. GRUPPIERUNGSALGORITHMUS
33
auch die Gruppierung der musterbildenden Divergenzen lassen sich mittels Graphtranformationen automatisiert durchführen. Ein entsprechender Gruppierungsalgorithmus
wird i.F. vorgestellt. Abschnitt 3.3.1 beschreibt zunächst den prinzipiellen Aufbau der
Transformationsregeln und identifiziert grundlegende Eigenschaften von Transformationssystemen, welche die Gesamtheit der Transformationsregeln für einen konkreten Modelltyp umfassen. Die identifizierten Eigenschaften des Transformationssystems werden
der in Abschnitt 3.3.2 beschriebenen Regelanwendungsstrategie unterstellt. Abschnitt
3.3.3 motiviert und beschreibt die Nachbearbeitung des Zwischenresultats, welches durch
die Anwendung der Transformationsregeln erzeugt wird.
3.3.1 Transformationsregeln
Das in Abschnitt 3.1 beschriebene Prinzip der Gruppierung von Divergenzen beruht auf
der Existenz von Änderungsmustern in der Differenz. Die LHS einer Transformationsregel kann zur Erkennung von Änderungsmustern eingesetzt werden, während die RHS
die Gruppierung der Divergenzen erzeugt.
Abb. 3.4 zeigt exemplarisch eine mögliche Transformationsregel zur Behandlung von
Navigierbarkeitsänderungen von Assoziationsenden in UML-Klassendiagrammen (vgl.
Abschnitte 1.1 und 3.1). Wir unterstellen hierbei die in Abschnitt 2.3.2 eingeführte
Repräsentation symmetrischer Differenzen sowie die im Rahmen des Eclipse UML2Projekts9 verfügbare Implementierung des UML-Metamodells. Zur grafischen Darstellung der Transformationsregel wird die konkrete Syntax des integrierten Diagrammeditors in EMF-Henshin (s. Abschnitt 2.4.3) verwendet.
Die LHS der in Abb. 3.4 dargestellten Regel entspricht strukturell i.W. der in Abb.
2.6 skizzierten, technischen Differenz. In Abweichung zur Differenzdarstellung in Abb.
2.6 werden hier zur Formulierung der LHS die im Kontext der Klasse Move des Differenzmodells definierten Referenztypen parentInA, parentInB, movedInA und movedInB
verwendet. Eine Divergenz vom Typ Move (9), sowie der von einer Assoziation (8) in
eine Klasse (5) verschobene Property-Knoten (3 in Variante A bzw. 4 in Variante B)
bilden somit den Kern des Änderungsmusters. Die elementaren Referenzänderungen,
welche die gelöschte bzw. eingefügte Kompositionskante des ASG repräsentieren, werden bereits durch die Instanz des Divergenztyps Move aggregiert. Sie werden hier zur
Spezifikation der LHS nicht verwendet.
9
http://www.eclipse.org/uml2/
34
3 KONZEPTUELLER LÖSUNGSANSATZ
Abbildung 3.4: Exemplarische Transformationsregel: setNavigabilityOfAssociationEnd
Einziger Knoten der RHS der Regel ist Knoten 11 vom Typ EditOperation, welcher die Editieroperation setNavigabilityOfAssociationEnd repräsentiert, was durch die
Attributwertzuweisung name="setNavigabilityOfAssociationEnd" ausgedrückt wird.
Der Knoten wird im Zuge der Anwendung der Regel erzeugt und aggregiert den gematchten Move-Knoten durch die Erzeugung einer Referenz vom Typ divergences. Die
Referenzänderungen 1 und 6 entsprechen den im Kontext von Abb. 2.6 beschriebenen
Pseudodifferenzen. Diese werden ebenfalls der erzeugten Gruppierung zugeordnet.
Eigenschaften des Transformationssystems
Im Allgemeinen hängen Details des Aufbaus eines Transformationssystems für einen konkreten Modelltyp von verschiedenen Entwurfsentscheidungen ab. Ein Variationspunkt
stellt hier bspw. die Fragestellung dar, welche Änderungsmuster als eigenständige Fragmente erachtet werden, die somit auch durch entsprechende Transformationsregeln erzeugt und im Kontext von Editieroperationen oder zusammengesetzter Fragmente verwendet werden.
Unabhängig von der Implementierung für einen konkreten Modelltyp besitzt ein Transformationssystem die als Lemma 3.3.1 und 3.3.2 formulierten Eigenschaften.
3.3. GRUPPIERUNGSALGORITHMUS
35
Lemma 3.3.1
Alle Transformationsregeln eines konkreten Transformationssystems sind paarweise voneinander parallel unabhängig.
Divergenzen und Fragmente werden bei der Gruppierung zu zusammengesetzten Fragmenten oder Editieroperationen nicht gelöscht. Die paarweise parallele Unabhängigkeit
aller Transformationsregeln folgt damit unmittelbar aus Definition 2.4.6.
Lemma 3.3.2
Eine sequentielle Abhängigkeit einer Regel R2 von einer Regel R1 besteht lediglich dann,
wenn
(a) von R1 erzeugte Fragmente oder Editieroperationen in der LHS von R2 verwendet
werden, oder
(b) R1 Fragmente oder Editieroperationen erzeugt, deren Existenz in einem bestimmten Kontext R2 verbietet.
Da Divergenzen und Fragmente bei der Gruppierung zu zusammengesetzten Fragmenten oder Editieroperationen nicht gelöscht werden, ist hinsichtlich der sequentiellen
Abhängigkeit von Transformationsregeln lediglich Bedingung 1. aus Definition 2.4.7 zu
betrachten. Gilt die grundlegende Annahme, dass alle Transformationsregeln insofern
atomar sind, als dass Instanzen unseres Differenzmodells (vgl. Abschnitte 2.3.2 und 3.2)
die Differenz der Varianten A und B nach jeder Regelanwendung korrekt und vollständig
wieder geben, so folgt daraus unmittelbar Lemma 3.3.2.
Topologische Sortierung der Transformationsregeln
Für den im weiteren Verlauf dieses Kapitels beschriebenen Algorithmus wird zudem
gefordert, dass, zusätzlich zu den oben genannten Eigenschaften, Voraussetzung 3.3.1
erfüllt ist, welche für konkrete Transformationssysteme nachzuweisen ist.
Voraussetzung 3.3.1
Der aus der Menge der sequentiellen paarweisen Abhängigkeiten resultierende Abhängigkeitsgraph ist zyklenfrei.
Anhand der Anzahl der Pfadsegmente des längsten Pfades transitiver Abhängigkeiten im Abhängigkeitsgraphen lässt sich jede Transformationsregel einer konzeptuellen
Ebene zuordnen. Auf der untersten Ebene des Abhängigkeitsgraphen, i.F. als Ebene 0
bezeichnet, befinden sich somit lediglich Regeln, in deren LHS-Graphen ausschließlich
36
3 KONZEPTUELLER LÖSUNGSANSATZ
Knoten vom Typ elementarer, technischer Divergenzen enthalten sind. Befindet sich eine Transformationsregel Rn auf der konzeptuellen Ebene n des Abhängigkeitsgraphen,
so existiert mindestens eine Regel Rn−1 der konzeptuellen Ebene n − 1, von der Rn
sequentiell abhängig ist.
Die Regeln eines Transformationssystems lassen sich somit in eine Liste überführen,
welche an Position n die Menge der sich auf der konzeptuellen Ebene n des Abhängigkeitsgraphen befindlichen Regeln beinhaltet. Dies wird i.F. als topologische Sortierung
des Abhängigkeitsgraphen bezeichnet. Eine in Pseudocode notierte, rekursive Sortierfunktion sort ist in Listing 3.1 dargestellt. Formale Parameter der Funktion sort sind
die Menge aller Transformationsregeln (unsorted) sowie die — beim initialen Aufruf der
Funktion leere — Liste der konzeptuellen Ebenen (sorted). Der Sortieralgorithmus bestimmt zunächst die Teilmenge layer der Menge aller Regeln in unsorted, welche keine
sequentiellen Abhängigkeiten besitzen (Zeilen 3-8). Die Teilmenge layer wird anschließend an das Ende der Liste sorted hinzugefügt (Z. 9), die Elemente von layer werden
aus der Menge der unsortierten Regeln entfernt (Z. 10). Das Verfahren wird rekursiv
fortgesetzt (Z. 14), bis die Menge der unsortierten Regeln leer ist (Z. 12).
Listing 3.1: Topologische Sortierung von Transformationsregeln
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function s o r t ( Set<Rule> u n s o r t e d , L i s t <Set<Rule>> s o r t e d ) {
i f ( unsorted ! = ∅) {
Set<Rule> l a y e r = new Set<Rule > ( ) ;
f o r each Rule r in u n s o r t e d {
i f ( ! hasDependencies ( r ) ) {
l a y e r . add ( r ) ;
}
}
s o r t e d . add ( l a y e r ) ;
u n s o r t e d . removeAll ( l a y e r )
} else {
return ; // s t o p r e c u r s i o n
}
s o r t ( u n s o r t e d , s o r t e d ) ; // r e c u r s i o n
}
Nicht dargestellt ist hier die Funktion hasDependencies(Rule r), welche in Zeile 5
der in Listing 3.1 beschriebenen Funktion sort aufgerufen wird. Die Umsetzung der
Funktion hasDependencies folgt aus Lemma 3.3.2.
3.3. GRUPPIERUNGSALGORITHMUS
37
3.3.2 Regelanwendungsstrategie
Listing 3.2 zeigt das Hauptprogramm des hier vorgestellten Gruppierungsalgorithmus.
Als gegeben wird die symmetrische Differenz (diff) angenommen, welche als Instanz
des in Abschnitt 2.3.2 eingeführten Differenzmodells vorliegt. Hierbei wird unterstellt,
dass die technischen Divergenzen auf Basis der zuvor gebildeten Korrespondenzen abgeleitet wurden. Im Rahmen der Evaluation (s. Kapitel 6) wurden hierfür verschiedene
Komponenten der SiDiff-Toolbox eingesetzt.
Ferner werden eine Transformations-Engine (engine) sowie ein Transformationssystem (system) für den zu Grunde liegenden Modelltyp als gegeben angenommen. Dem
Transformationssystem wird die Erfüllung von Voraussetzung 3.3.1 unterstellt, so dass
sich die Regeln des Transformationssystems in einem ersten Schritt mittels der Funktion sort (vgl. Listing 3.1) topologisch sortieren lassen (Z. 6-7). Anschließend erfolgt die
Anwendung der Transformationsregeln (Z. 10), die Regelanwendungsstrategie wird i.F.
detailliert beschrieben. Hierbei werden u.U. zu viele Editieroperationen erzeugt („False
Negatives“ ), welche in einem nachgelagerten Verarbeitungsschritt wieder entfernt werden (Z. 13). Eine Beschreibung des Nachbearbeitungsalgorithmus ist in Abschnitt 3.3.3
zu finden.
Listing 3.2: Hauptprogramm des Gruppierungsalgorithmus
1
2
3
Difference diff = . . . ;
TransformationEngine engine = . . . ;
TransformationSystem system = . . . ;
4
5
6
7
// ( 1 ) S o r t a l l r u l e s t o p l o g i c a l l y
L i s t <Set<Rule>> r u l e s = new L i s t <Set<Rule > >();
s o r t ( system . g e t R u l e s ( ) , r u l e s ) ;
8
9
10
// ( 2 ) Apply r u l e s bottom−up
applyRules ( r u l e s ) ;
11
12
13
// ( 3 ) P o s t p r o c e s s i n g
postprocess ( d i f f ) ;
Die Anwendung der Transformationsregeln erfolgt in einem strikten bottom-up Durchlauf des topologisch sortierten Abhängigkeitsgraphen (rules). Eine Formulierung des
Algorithmus ist in Listing 3.3 abgebildet. In der äußeren Schleife (Z. 3-18) wird über
die konzeptuellen Ebenen des Abhängigkeitsgraphen iteriert. Alle sich auf einer Ebene (layer) befindlichen Regeln sind gemäß Lemma 3.3.1 parallel unabhängig und da-
38
3 KONZEPTUELLER LÖSUNGSANSATZ
her parallel ausführbar. Die Umsetzung der parallelen Ausführung erfolgt dabei in zwei
Schritten:
1. Dem Auffinden aller möglichen Regelanwendungen: Hierzu wird für jede Regel
(rule) zunächst die Menge aller möglichen Vorkommen der Regel-LHS in der aktuellen Differenz gesucht (Z. 7). Für alle gefundenen Vorkommen (match) wird eine
Regelanwendung (app) mit match als entsprechendem Prematch erzeugt, wobei die
Menge aller Regelanwendungen (apps) für eine Ebene temporär verwaltet wird (Z.
8-12).
2. Nachdem alle möglichen Vorkommen der LHS-Graphen aller Regeln der aktuellen
Ebene gefunden wurden, erfolgt die parallele Ausführung der temporär verwalteten
Regelanwendungen (Z. 15-17).
Listing 3.3: Regelanwendungsstrategie
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
function a p p l y R u l e s ( L i s t <Set<Rule>> r u l e s ) {
// S e q u e n t i a l e x e c u t i o n o f dependency graph l a y e r s
f o r each Set<Rule> l a y e r in r u l e s {
// ( 1 ) c o l l e c t r u l e a p p l i c a t i o n s
Set<R u l e A p p l i c a t i o n > apps = new Set<R u l e A p p l i c a t i o n > ( ) ;
f o r each Rule r u l e in l a y e r {
L i s t <Match> matches = e n g i n e . f i n d A l l M a t c h e s ( r u l e ) ;
f o r each Match match in matches {
R u l e A p p l i c a t i o n app = new R u l e A p p l i c a t i o n ( r u l e ) ;
app . setMatch ( match ) ; // s e t s t h e prematch
apps . add ( app ) ;
}
}
// ( 2 ) p a r a l l e l e x e c u t i o n o f c o l l e c t e d r u l e a p p l i c a t i o n s
f o r each R u l e A p p l i c a t i o n app in apps {
e n g i n e . applyRule ( app )
}
}
}
3.3.3 Nachbearbeitung
Die in Abschnitt 3.3.2 beschriebene Regelanwendungsstrategie führt u.U. dazu, dass zu
viele Gruppierungen von Divergenzen erzeugt werden („False Negatives“ ). Derartige
False Negatives können immer dann auftreten, wenn
3.3. GRUPPIERUNGSALGORITHMUS
39
1. die aus zwei Editieroperationen resultierenden Änderungsmuster nicht überlappungsfrei sind (notwendige Bedingung) und
2. das durch die Überlappung gegebene Teilmuster als Vorkommen für die LHS mehrerer Transformationsregeln fungieren kann (hinreichende Bedingung).
Ein konkretes Beispiel stellen die Editieroperationen addAttribute und addAssociation
(vgl. Abschnitt 5.1.2) in UML-Klassendiagrammen dar. Hier ist das aus der Ausführung von addAttribute resultierende Änderungsmuster vollständig in dem aus der Einfügung von Assoziationen mit mindestens einem navigierbaren Ende resultierenden Änderungsmuster enthalten. Dies ist dadurch begründet, dass die UML-Metaklasse Property
die gemeinsame Abstraktion von Attributen und Assoziationsenden darstellt [OMG07],
und navigierbare Assoziationsenden strukturell als Kindelemente dem „gegenüberliegenden“ Klassifizierer zugeordnet sind (vgl. Abschnitt 1.1). Ein weiteres Beispiel ist
im Kontext der Matlab/Simulink-Operation createSubsystem zu finden. Hier sind die
Änderungsmuster der eigenständigen Editieroperationen createInportBlock, createOutportBlock und createConnection, welche das neu erzeugte Subsystem in den bestehenden
Kontext einbetten, in unbestimmter Anzahl vollständig in der Operation createSubsystem enthalten (vgl. Abschnitt 5.2).
Listing 3.4 zeigt eine Heuristik zur Eliminierung von False Negatives. In einer Schleife
(Z. 2-14) über alle in der Differenz enthaltenen Editieroperationen wird für jede Operation e entschieden, ob diese als obligatorisch oder als optional anzusehen ist. Hierzu
wird zunächst die transitive Hülle h = H∗ (e) aller in e enthaltenen Divergenzen gebildet
(Z. 3). Für alle in h enthaltenen Divergenzen div wird anschließend geprüft, ob div in
weiteren Gruppierungen enthalten ist (Z. 6). Ist dies für eine der durch e aggregierten
Divergenzen nicht der Fall, so wird e als obligatorisch deklariert (Z. 7). Die Suche nach
weiteren Divergenzen, welche exklusiv in e enthalten sind, kann abgebrochen werden (Z.
8). Sofern für alle in e enthaltenen Divergenzen div Editieroperationen != e existieren,
in denen jede Divergenz div ∈ h ebenfalls enthalten ist, wird die Editieroperation e als
optional erachtet und aus der Differenz gelöscht (Z. 11-13).
Listing 3.4: Nachbearbeitung der Differenz
1
2
3
4
5
6
p o s t p r o c e s s ( D i f f e r e n c e d){
f o r each E d i t O p e r a t i o n e in d {
S e t h = H∗ ( e ) ; // t r a n s i t i v e c l o s u r e o f r e f e r e n c e d d i v e r g e n c e s
boolean mandatory = f a l s e ;
f o r each D i v e r g e n c e d i v in h {
i f ( g e t R e f e r e n c i n g E d i t O p s ( d i v ) \e == ∅ ) {
40
3 KONZEPTUELLER LÖSUNGSANSATZ
mandatory = true ;
break ;
7
8
}
}
i f ( ! mandatory ) {
d . remove ( e ) ;
}
9
10
11
12
13
}
14
15
}
Da die Menge der in der Differenz enthaltenen Editieroperationen nicht geordnet ist,
kann das in Listing 3.4 dargestellte Verfahren zu nicht-deterministischen Ergebnissen
führen: Wenn prinzipiell zwei Editieroperationen Kandidaten einer Löschung darstellen
(d.h. alle Divergenzen beider Editieroperationen nicht exklusiv in der jeweiligen Editieroperation enthalten sind), nach der Löschung der einen Editieroperation aber die jeweils
andere nicht mehr gelöscht werden kann (da mindestens eine Divergenz existiert, welche
nun exklusiv enthalten ist), so entscheidet die zufällige Reihenfolge, in der die Regeln
verarbeitet werden, dass die zuerst verarbeitete beider Editieroperationen gelöscht wird.
Die Nachbearbeitung stellt indessen nicht sicher, dass alle Divergenzen genau einer
Editieroperation zugeordnet sind. Auftreten kann dies im Kontext skalarer Referenztypen. Wird hier eine Referenz durch eine Editieroperation gelöscht und durch eine andere Editieroperation erzeugt, so resultiert dies in lediglich einer elementaren Änderung
vom Typ ReferenceTargetChange. Gleiches gilt im Kontext mengenwertiger geordneter Referenztypen, wenn eine Referenz an einer Position durch eine Editieroperation
gelöscht und durch eine andere erzeugt wird. Dies resultiert in einer Divergenz vom Typ
ReferenceITargetChange. Die Zuordnung einer Divergenz zu zwei Editieroperationen
ist in beiden Fällen somit als korrekt zu betrachten.
4 Implementierung
Der in Kapitel 3 vorgestellte, konzeptuelle Lösungsansatz wurde im Rahmen dieser Arbeit implementiert. Nachfolgend werden in Abschnitt 4.1 zunächst die hierzu eingesetzten
Technologien skizziert. Anschließend wird in Abschnitt 4.2 eine detaillierte Vorlage zum
Aufbau von Transformationssystemen für konkrete Modelltypen beschrieben, welches
wir i.F. als Basis-Transformationssystem (BTS) bezeichnen.
4.1 Eingesetzte Technologien
Grundlegend basiert die im Rahmen dieser Arbeit entwickelte Implementierung auf dem
Eclipse Modeling Framework (s. Abschnitt 2.2). Darauf aufbauend wird das in den Abschnitten 2.3.2 und 3.2 eingeführte SiDiff-Differenzmodell eingesetzt. Zur Korrespondenzbildung und der Ableitung technischer Differenzen wurden im Rahmen der durchgeführten Evaluation (s. Abschnitt 6) verschiedene Komponenten der SiDiff-Toolbox10
verwendet.
Als Graphtransformationstechnologie wird das ebenfalls auf EMF basierende Werkzeug EMF-Henshin (s. Abschnitt 2.4) eingesetzt. Der in Abschnitt 3.3 beschriebene
Gruppierungsalgorithmus wurde auf Basis der Henshin-API in Java implementiert. Eine
Abweichung von der konzeptuellen Beschreibung des Algorithmus besteht lediglich in
der Behandlung von Regeln mit Multi-Objekten, welche in Henshin über das Konzept
der Amalgamierung (s. Abschnitt 2.4) realisiert werden. Für alle konzeptuellen Transformationsregeln ist im Rahmen der Implementierung des Algorithmus aus Basis von
EMF-Henshin daher eine Fallunterscheidung zwischen elementaren Regeln (Rule) und
amalgamierten Regeln (AmalgamationUnit) notwendig (vgl. Abschnitt 2.4.3). Auswirkungen hat dies insbesondere auf das Auffinden aller möglichen Regelanwendungen im
Kontext der Regelanwendungsstrategie (s. Listing 3.3, Zeilen 5-13). Hier wird im Falle
einer AmalgamationUnit nach allen potentiellen Matches der Kernel-Regel gesucht.
10
http://www.sidiff.org
41
42
4 IMPLEMENTIERUNG
Für die Anwendung der implementierten Algorithmik auf konkrete Modelltypen beschränkt sich der weitere Aufwand auf die Spezifikation eines Transformationssystems.
Ein Basis-Transformationssystem, bestehend aus generischen Transformationsregeln und
Regel-Templates, wird i.F. vorgestellt.
4.2 Basis-Transformationssystem
Der prinzipielle Aufbau von Transformationsregeln wurde bereits in Abschnitt 3.3.1 skizziert; die LHS einer Transformationsregel dient zur Erkennung von Änderungsmustern,
während die RHS die Gruppierung der Divergenzen erzeugt. Als Arbeitsgraphen fungieren im Rahmen der hier vorgestellten Implementierung die als Instanz des SiDiffDifferenzmodells vorliegenden Repräsentationen symmetrischer Differenzen. Der Typgraph ergibt sich demzufolge als Vereinigung aus dem SiDiff-Differenzmodell, der EcoreSpezifikation selbst, sowie dem Ecore-basierten Metamodell des vorliegenden Modelltyps.
Details der Transformationsregeln hängen stets vom unterstellten Editierdatentyp und
dem zu Grunde liegenden Metamodell des jeweiligen Modelltyps ab. Ein Großteil der
Editieroperationen lässt sich jedoch durch generische Transformationsregeln und darauf
aufbauende Regeln nach festem Schema abdecken. Generische Transformationsregeln
sind Bestandteil aller an konkrete Modelltypen adaptierten Transformationssysteme. Für
darauf aufbauende Regeln nach festem Schema werden parametrisierte Regel-Templates
angegeben, welche im Kontext konkreter Modelltypen instanziiert werden können.
Die im Folgenden vorgenommene Klassifizierung der Regeln orientiert sich an den verschiedenen Kategorien von Editieroperationen, welche typischerweise den Großteil eines
Editierdatentyps umfassen; Einfügungen, die Änderung skalarer und mengenwertiger
struktureller Eigenschaften, Löschungen sowie globale Verschiebungen von Modellelementen.
4.2.1 Einfügungen
Die Einfügung eines Modellelements entspricht im Kern der Einfügung eines oder mehrerer Knoten in den abstrakten Syntaxgraphen. Wir betrachten zunächst die Einfügung
einzelner Knoten aus generischer Perspektive, anschließend wird die Einfügung konkreter
Modellelemente behandelt und ein Transformationsregel-Template für den Standardfall
vorgestellt.
4.2. BASIS-TRANSFORMATIONSSYSTEM
43
Einfügung einzelner Knoten in den ASG
Abb. 4.1 zeigt die generische Transformationsregel addNode zur Behandlung eingefügter
Knoten. Die amalgamierte Regel besteht aus einer Kernel-Regel (k1-k5) und zwei MultiRegeln (m1_1 bzw. m2_1 - m1_3).
Abbildung 4.1: Generische Transformationsregel: addNode
In Instanzen des SiDiff-Differenzmodells werden eingefügte Knoten (k2) durch ein
UnmatchedElement (k3) in der Kollektion nicht korrespondierender Knoten im abstrakten Syntaxgraphen des Modells B (unmatchedB) repräsentiert. Hinzu kommt die aus
Sicht des Vaterknotens erzeugte Kompositionskante (affectedContainment, k1). Das
entsprechende Änderungsmuster wird durch die LHS der Kernel-Regel (k1 - k4) definiert. Die Erzeugung einer Fragment-Instanz zur Gruppierung der Divergenzen einer
gematchten Muster-Instanz ist Bestandteil der RHS der Kernel-Regel (k5).
In direktem Zusammenhang mit der Einfügung eines Knotens stehen die Zuweisungen
der jeweiligen Attributwerte des eingefügten Knotens (AttributeValueNotInA). Aufgrund der unbestimmten Anzahl der für den Typ des eingefügten Knotens definierten
Attribute werden diese Änderungen im Rahmen der Multi-Regel m1_1 verarbeitet.
44
4 IMPLEMENTIERUNG
Desweiteren können im Zuge der Einfügung eines Knotens Seiteneffekte an Instanzen von Referenztypen auftreten, welche den Typ des eingefügten Knotens als Quelle
(ausgehende Referenztypen) oder Ziel (eingehende Referenztypen) besitzen. Mögliche
Seiteneffekte sind i.d.R. als Pseudodifferenzen (PD) zu betrachten und werden i.F. diskutiert:
E.1 Ausgehende Referenztypen:
E.1.a Ein generisch als Pseudodifferenz klassifizierbarer Seiteneffekt wird durch die
zweite Multi-Regel (m2_1 - m2_3) der in Abb. 4.1 dargestellten Transformationsregel addNode behandelt. Eingefügte Referenzen (m2_1), welche den eingefügten Knoten als Quelle (sourceB) besitzen, sind dann als Seiteneffekt der
Einfügung zu betrachten, wenn sie Instanz desjenigen Referenztyps (m2_2)
sind, welcher als Gegenstück (eOpposite) des Kompositions-Referenztyps
(m2_3) fungiert.
E.1.b Für alle anderen möglichen Seiteneffekte an ausgehenden Referenztypen ist
modelltypspezifisch zu entscheiden, ob diese als Pseudodifferenzen zu betrachten sind.
E.2 Eingehende Referenztypen:
Für Änderungen an eingehenden Referenztypen kann lediglich modelltypspezifisch
entschieden werden, ob diese als Seiteneffekt der Einfügung und damit als Pseudodifferenz zu klassifizieren sind. Näher betrachtet werden i.F. mengenwertige,
eingehende Referenztypen. Hier ist zwischen der Einfügung in ungeordnete und
geordnete Kollektionen des referenzierenden Knotens zu unterscheiden:
E.2.a Einfügungen in ungeordnete Kollektionen führen zu einer neu erzeugten Kante
im ASG (ReferenceNotInA). Derartige Pseudodifferenzen sind als Seiteneffekt der eigentlichen Einfügung modelltypspezifisch behandelbar.
E.2.b Einfügungen in geordnete Kollektionen können — zusätzlich zur Erzeugung
neuer Kanten (ReferenceINotInA), welche analog zu Fall E.2.a zu behandeln sind — zu impliziten lokalen Verschiebungen (LocalMove) oder indizierten Referenzzieländerungen (IReferenceTargetChange) im referenzierenden Knoten führen. Inwiefern derartige Seiteneffekte modelltypspezifisch als
Pseudodifferenzen klassifiziert werden können, ist anhand des Kriteriums zu
entscheiden, ob der unterstellte Editierdatentyp weitere Editieroperationen
enthält, welche potentiell in lokalen Verschiebungen bzw. indizierten Referenzzieländerungen resultieren:
4.2. BASIS-TRANSFORMATIONSSYSTEM
45
E.2.b.i Falls nein, kann der beschriebene Seiteneffekt im Rahmen modelltypspezifischer Transformationsregeln der Einfügung des Knotens zugeordnet
werden.
E.2.b.ii Falls ja, kann nicht automatisiert entschieden werden, ob die lokale Verschiebung bzw. die indizierte Referenzzieländerung als Seiteneffekt der
Einfügeoperation zuzuordnen ist, oder als direktes Resultat einer anderen Editieroperation betrachtet werden muss. Eine mögliche Konfliktlösungsstrategie ist es, derartige Änderungen nicht als Seiteneffekt der
Einfügeoperation, sondern als Resultat der alternativen Editieroperation zuzuordnen, auch wenn diese möglicherweise vom Modellierer nicht
durchgeführt wurde.
Für die Einfügung von Wurzelknoten entfallen die Behandlung der aus Sicht des Vaterknotens eingefügten Kompositionskante sowie der Pseudodifferenz E.1.a (s. Abb. 4.2).
Durch die explizite Angabe einer negativen Anwendungsbedingung (nac) wird hier zudem die parallele Anwendbarkeit der Regeln addNode und addRootNode sicher gestellt,
welche sich aufgrund der negativen Anwendungsbedingung wechselseitig ausschließen.
Abbildung 4.2: Generische Transformationsregel: addRootNode
Einfügung konkreter Modellelemente
Die Einfügung konkreter Modellelemente entspricht im Standardfall der Einfügung eines einzelnen Knotens in den ASG. Formale Parameter des in Abb. 4.3 dargestellten
Templates <addElement> sind die Metaklasse (<Metaclass>) des eingefügten Modell-
46
4 IMPLEMENTIERUNG
elements sowie der Name der einfügenden Editieroperation (<addElement>). Diese sind
im Kontext der Instanziierung des Templates durch aktuelle Parameter zu substituieren.
Abbildung 4.3: Regel-Templates: <addElement> und <addCompositeElement>
Im Falle von Kompositionsstrukturen, welche aus Benutzersicht lediglich ein atomares Modellelement repräsentieren, entspricht die Einfügung eines Modellelementes der
Einfügung eines Teilbaumes in den ASG. So z.B. Blöcke und deren Ports in Matlab/Simulink. Entsprechende Gruppierungen werden durch die amalgamierte Template-Regel
<addCompositeElement> (s. Abb. 4.3) realisiert. Den Ankerpunkt bildet der eingefügte
Knoten, welcher die Wurzel des eingefügten Teilbaumes darstellt. Die Zuordnung der zu
gruppierenden Kindknoten erfolgt durch die Angabe des Referenztyps <referenceType>.
In seltenen Fällen kann die Einfügung eines Modellelements auch der Einfügung mehrerer Knoten entsprechen, welche hinsichtlich ihrer Struktur keinen Teilbaum darstellen.
Eine UML-Assoziation inklusive ihrer Assoziationsenden bspw. muss keinen Teilbaum
bilden, da die Assoziationsenden hierarchisch auch den assoziierten Klassifizierern zugeordnet sein können. Entsprechende Gruppierungen können i.d.R. ebenfalls durch die
Instanziierung der Template-Regel <addCompositeElement> realisiert werden. Der Pa-
4.2. BASIS-TRANSFORMATIONSSYSTEM
47
rameter <referenceType> identifiziert hier den Referenztyp, dessen Instanzen die Kante
zwischen dem eingefügten Element (p) und dem Knoten (c) bildet, welcher ebenfalls der
Einfügung zuzuordnen ist.
4.2.2 Änderung skalarer struktureller Eigenschaften
Die Änderung skalarer struktureller Eigenschaften wird in der technischen Differenz
durch Attributwertänderungen (AttributeValueChange) oder Referenzzieländerungen
(ReferenceTargetChange) repräsentiert. Oftmals entsprechen diese Änderungen direkt
dem Resultat einer Editieroperation, sind also lediglich modelltypspezifisch zu interpretieren. Die Änderung der Werte von Meta-Eigenschaften, so z.B. die Sichtbarkeit einer
Klasse in UML-Klassendiagrammen, resultieren direkt in Attributwertänderungen in der
technischen Differenz (s. Abb. 4.4, links). Namensgebend für das auf Referenzzieländerungen basierende Template (s. Abb. 4.4, rechts) sind hier Typänderungen, welche auf
Ebene der technischen Differenz i.d.R. direkt in einer Referenzzieländerung resultieren.
Abbildung 4.4: Regel-Templates: <setMetaProperty> und <changeType>
4.2.3 Änderung mengenwertiger struktureller Eigenschaften
Änderungen mengenwertiger struktureller Eigenschaften sind oftmals als Seiteneffekte
anderer Editieroperationen, insbesondere einfügender (s. Abschnitt 4.2.1) und löschender
Editieroperationen (s. Abschnitt 4.2.4) zu beobachten. Ausnahmen sind lokale Verschiebungen (LocalMove) oder indizierte Referenzzieländerungen (ReferenceITargetChange),
welche im Kontext geordneter mengenwertiger struktureller Eigenschaften auftreten kön-
48
4 IMPLEMENTIERUNG
nen. Entsprechende Transformationsregel-Templates <localMove> und <indexedChange>
sind in Abb. 4.5 dargestellt.
Abbildung 4.5: Regel-Templates: <localMove> und <indexedChange>
4.2.4 Löschungen
Das Löschen eines Modellelements entspricht dem Löschen eines Knotens oder Teilbaumes im ASG. Wir betrachten i.F. zunächst das Löschen einzelner Knoten und anschließend das Löschen von Teilbäumen, jeweils aus generischer Perspektive. Abschließend
wird das Löschen konkreter Modellelemente behandelt und ein TransformationsregelTemplate für den Standardfall vorgestellt.
Löschen einzelner Knoten
Abb. 4.6 zeigt die amalgamierte Transformationsregel removeNode zur Behandlung gelöschter Knoten. Aufgrund der symmetrischen Repräsentation eingefügter und gelöschter
Knoten im zu Grunde liegenden Differenzmodell sind die LHS- und RHS-Graphen der
Kernel-Regel (k1-k5) und der ersten Multi-Regel (m1_1) isomorph zu den jeweiligen
LHS- und RHS-Graphen von Kernel-Regel und erster Multi-Regel in der Transformationsregel addNode (vgl. Abb. 4.1).
Unterschiede in der Formulierung der LHS- und RHS-Graphen für die Regeln addNode und removeNode bestehen lediglich hinsichtlich der Behandlung von Seiteneffekten
an Instanzen von Referenztypen, welche den Typ des gelöschten Knotens als Quelle
(ausgehende Referenztypen) oder Ziel (eingehende Referenztypen) besitzen. Mögliche
Seiteneffekte sind i.d.R. als Pseudodifferenzen zu betrachten und werden i.F. diskutiert:
4.2. BASIS-TRANSFORMATIONSSYSTEM
49
Abbildung 4.6: Generische Transformationsregel: removeNode
L.1 Ausgehende Referenztypen:
Änderungen an Instanzen ausgehender Referenztypen sind stets als Pseudodifferenzen zu klassifizieren. Eine generische Behandlung erfolgt durch die zweite MultiRegel der in Abb. 4.1 dargestellten Transformationsregel addNode. Da der gelöschte
Knoten (k2) in Variante B nicht existiert und dort somit als Träger einer Referenz
nicht in Frage kommt, resultieren Änderungen an ausgehenden Referenzen stets
in Änderungen vom Typ ReferenceNotInB, welche als Seiteneffekt der Löschung
zugeordnet werden können (m2_1).
L.2 Eingehende Referenztypen:
L.2.a Wird ein Knoten gelöscht, welcher das Ziel eingehender Referenzen darstellt,
die Instanzen mengenwertiger, ungeordneter Referenztypen darstellen, so ist
die resultierende Änderung stets vom Typ ReferenceNotInB. Derartige Pseudodifferenzen können generisch durch die Multi-Regel (m4_1, m4_2) der in
Abb. 4.1 dargestellten Transformationsregel addNode behandelt werden.
L.2.b Änderungen an Instanzen skalarer Referenztypen resultieren in Referenzzieländerungen (ReferenceTargetChange), wobei in A ein Referenzziel vorhanden ist, in B nicht, was in der Transformationsregel removeNode durch die
50
4 IMPLEMENTIERUNG
negative Anwendungsbedingung (nac) sichergestellt wird. Derartige Pseudodifferenzen werden generisch durch die Multi-Regel m3_1 der Löschung zugeordnet.
L.2.c Die Betrachtung möglicher Seiteneffekte an Instanzen eingehender Referenztypen, welche als mengenwertig und geordnet deklariert sind, führt zu analogen Ergebnissen wie im Falle von Einfügungen (s. Abschnitt 4.2.1, Fall E.2.b).
Die entsprechenden Seiteneffekte sind modelltypspezifisch analog zu den in
Abschnitt 4.2.1 beschriebenen Varianten E.2.b.i und E.2.b.ii zu behandeln
und werden i.F. als L.2.c.i und L.2.c.ii bezeichnet.
Hinsichtlich des Löschens von Wurzelknoten gelten die gleichen Überlegungen wie
für das Einfügen von Wurzelknoten (s. Abschnitt 4.2.1). Aufgrund der symmetrischen
Repräsentation eingefügter und gelöschter Knoten (vgl. Abschnitt 2.3.2) sind LHS und
RHS der entsprechenden Transformationsregel removeRootNode damit isomorph zu LHS
und RHS der Regel addNode, so dass hier auf eine Abbildung der Transformationsregel
removeRootNode verzichtet wird.
Löschen von Teilbäumen. Abb. 4.7 zeigt die generische Regel removeSubtree zur Behandlung gelöschter Teilbäume. Die Regel stützt sich dabei auf bereits durch die Regel
removeNode (s. Abb. 4.6) erzeugte "removeNode"-Fragmente.
Abbildung 4.7: Generische Transformationsregel: removeSubtree
Die LHS der Kernel-Regel (k1 - k3) bildet den Ankerpunkt der amalgamierten Regel
und matcht auf alle gelöschten Knoten (k2). Die LHS der Multi-Regel (m1_1 - m1_4)
4.2. BASIS-TRANSFORMATIONSSYSTEM
51
identifiziert indessen alle gelöschten Knoten, welche Kindknoten von k2 sind. Die entsprechenden "removeNode"-Fragmente der gelöschten Kindknoten (m1_4) werden durch
die LHS der Multi-Regel den "removeNode"-Fragmenten des gelöschten Vaterknotens
zugeordnet. Die Anwendung von removeCompositeNode auf alle Vorkommen der LHS
der Kernel-Regel führt zur rekursiven Aggregation der "removeNode"-Fragmente für gelöschte Teilbäume.
Löschung konkreter Modellelemente. Die Löschung konkreter Modellelemente entspricht der Löschung des Wurzelknotens eines Teilbaumes im ASG. Abb. 4.8 zeigt
das entsprechende Transformationsregel-Template. Die negative Anwendungsbedingung
(nac) stellt dabei sicher, dass nur solche Fragmente durch modelltypspezifische Einfügeoperationen aggregiert werden, welche die Wurzel eines gelöschten Teilbaumes darstellen.
Abbildung 4.8: Transformationsregel-Template: <removeElement>
In seltenen Fällen kann die Löschung eines Modellelements auch der Löschung mehrerer Knoten entsprechen, welche hinsichtlich ihrer Struktur keinen Teilbaum darstellen.
Entsprechende Gruppierungen können durch die Instanziierung der in Abb. 4.9 dargestellten Template-Regel <removeCompositeElement> realisiert werden.
52
4 IMPLEMENTIERUNG
Abbildung 4.9: Transformationsregel-Template: <removeCompositeElement>
4.2.5 Globale Verschiebungen
Die globale Verschiebung eines Modellelements entspricht der Verschiebung eines Knotens (welcher i.d.R. die Wurzel eines Teilbaumes darstellt) im ASG und ist als Move bereits in der technischen Differenz enthalten. In Abb. 4.10 ist ein einfaches Regel-Template
zur Behandlung globaler Verschiebungen von Modellelementen dargestellt.
Potentiell können bei globalen Verschiebungen ähnliche Seiteneffekte wie beim Löschen bzw. Einfügen von Elementen auftreten. Diese wurden bereits in den Abschnitten
4.2.1 und 4.2.4 diskutiert. Typischerweise treten hier lediglich Seiteneffekte an ausgehenden Referenztypen auf, welche als Ziel den Knotentyp des Vaterknotens des verschobenen Elements besitzen. Diese sind als Pseudodifferenzen (PD.M) zu betrachten und der
Verschiebung zuzuordnen. Modelltypspezifische Instanzen der in Abb. 4.10 dargestellten
Template-Regel sind dann entsprechend zu erweitern. Konkrete Ausprägungen der Pseudodifferenzen PD.M wurden bereits anhand des einführenden Beispiels aus Abschnitt 1.1
diskutiert. Die Behandlung im Rahmen einer entsprechenden Transformationsregel ist
in Abb. 3.4 dargestellt.
4.2. BASIS-TRANSFORMATIONSSYSTEM
53
Abbildung 4.10: Transformationsregel-Template: <globalMove>
4.2.6 Übersicht
Tabelle 4.1 zeigt die Adjazenzliste des Abhängigkeitsgraphen, welcher aus den Regeln
und Regel-Templates des Basis-Transformationssystems resultiert. Der Abhängigkeitsgraph ist zyklenfrei und erfüllt damit die grundlegende Voraussetzung 3.3.1. Zudem sind
in Tab. 4.1 die Typen von Pseudodifferenzen vermerkt, welche durch die jeweilige Regel behandelt werden bzw., im Falle von Regel-Templates, modelltypspezifisch auftreten
können und entsprechend zu behandeln sind.
Tabelle 4.1: Regeln und Regel-Templates des Basis-Transformationssystems
Regel-(Template)
Abh. von Regel-(Template)
Pseudodifferenzen
addNode
addRootNode
<addElement>
addNode
addRootNode
addNode
addRootNode
{E.1.a}
{E.1.b, E.2}
<setMetaProperty>
<changeType>
-
-
<localMove>
<indexedChange>
-
-
removeNode
removeRootNode
removeSubtree
-
{L.1, L.2.a, L.2.b}
-
<addCompositeElement>
{E.1.b, E.2}
54
4 IMPLEMENTIERUNG
<removeElement>
<removeCompositeElement>
<globalMove>
removeNode
removeRootNode
removeSubtree
removeNode
removeRootNode
removeSubtree
-
{E.1.b, E.2, L.2.c}
{E.1.b, E.2, L.2.c}
{M.PD}
5 Fallstudien
Die Menge der für einen gegebenen Modelltyp auftretenden Änderungsmuster folgt
aus der Wahl des Editierdatentyps sowie dem technologiegebundenen Metamodell, welches der Repräsentation der Modelle dieses Modelltyps zu Grunde liegt. Editierdatentyp und Metamodell bilden somit den Ausgangspunkt einer Adaption des in Abschnitt 4.2 vorgestellten Basis-Transformationssystems an konkrete Modelltypen. Für
die im Rahmen dieser Arbeit durchgeführten Fallstudien für UML-Klassendiagramme
und Matlab/Simulink-Blockdiagramme betrachten wir daher i.F. jeweils zunächst das
der Implementierung zu Grunde liegende Metamodell und den unterstellten Editierdatentyp. Anschließend wird jeweils die Adaption des BTS an den betrachteten Modelltyp
skizziert. Evaluationsergebnisse der Anwendung auf konkrete Testmodelle sind in Kapitel
6 beschrieben.
5.1 UML-Klassendiagramme
Modelltyp dieser Fallstudie ist die zur Strukturmodellierung eingesetzte Teilmenge des
UML-Metamodells, deren Instanzen typischerweise in Form von Klassendiagrammen visualisiert werden. Als Ausgangsbasis werden zunächst das Ecore-basierte Metamodell
(Abschnitt 5.1.1) sowie der unterstellte Editierdatentyp (Abschnitt 5.1.2) vorgestellt,
bevor in Abschnitt 5.1.3 die Adaption des Basis-Transformationssystems skizziert wird.
5.1.1 Metamodell
Als Metamodell wurde die Implementierung der UML-Spezifikation [OMG07] verwendet,
welche im Rahmen des Eclipse UML2-Projekts11 verfügbar ist. Da der in Abschnitt 5.1.2
beschriebene Editierdatentyp keine Operationen enthält, welche zu indizierten Referenzänderungen oder lokalen Verschiebungen an Instanzen der in Tabelle 5.1 aufgeführten
11
http://www.eclipse.org/uml2/
55
56
5 FALLSTUDIEN
Referenztypen führen, wurde die Ordnungseigenschaft dieser Referenztypen von geordnet
auf ungeordnet umdefiniert. Weitere Änderungen wurden nicht vorgenommen.
Quell-Metaklasse
Referenztyp
Änderung
StructuredClassifier
Association
Association
Class
ownedProperty
ownedEnd
memberEnd
ownedOperation
geordnet
geordnet
geordnet
geordnet
→
→
→
→
ungeordnet
ungeordnet
ungeordnet
ungeordnet
Tabelle 5.1: Geänderte Referenztypen des UML2-Metamodells
5.1.2 Editierdatentyp
Grundlage des im Rahmen dieser Fallstudie unterstellten Editierdatentyps für UMLKlassendiagramme sind die in [Wie10] und [MBT10b] beschriebenen Operationskataloge.
Eine Auflistung aller Editieroperationen ist in Tabelle 5.2 dargestellt. Formale Parameter, Vor- und Nachbedingungen sowie die Beschreibung der Semantik der Editieroperationen sind den Entsprechungen des jeweiligen Operationskataloges zu entnehmen.
Tabelle 5.2: Editierdatentyp für UML-Klassendiagramme
Entsprechung in:
Editieroperation
[Wie10]
[MBT10b]
1
2
3
4
addEmptyPackage
removePackage
setMetaPropertyOfPackage
movePackage
-
Op1
Op4
Op6
Op5
5
6
7
8
addEmptyClass
removeClass
setMetaPropertyOfClass
moveClass
AddEmptyClass
RemoveEmptyClass
SetMetaPropertyOfClass
-
Op1
Op4
Op7
Op5
9
10
11
12
13
addAttribute
removeAttribute
setMetaPropertyOfAttribute
moveAttribute
changeTypeOfAttribute
AddAttribute
RemoveAttribute
SetMetaPropertyOfAttribute
ChangeDatatypeOfAttribute
Op1
Op4
Op10
Op5
Op10
14
15
setLowerBoundOfProperty
setUpperBoundOfProperty
SetLowerBoundOfProperty
SetUpperBoundOfProperty
Op9 / Op10
Op9 / Op10
5.1. UML-KLASSENDIAGRAMME
57
16
17
18
19
20
21
22
23
addOperation
removeOperation
setMetaPropertyOfOperation
moveOperation
addParameterToOperation
removeParameterFromOperation
changeParameterType
changeParameterIndex
AddOperation
RemoveOperation
SetMetaPropertyOfOperation
AddParameterToOperation
RemoveParameterFromOperation
ChangeParameterDatatype
-
Op3
Op4
Op11
Op5
Op2
Op4
Op12
-
24
25
26
27
28
29
addAssociation
removeAssociation
setMetaPropertyOfAssociation
setMetaPropertyOfAssociationEnd
setNavigabilityOfAssociationEnd
changeTypeOfAssociationEnd
AddAssociation
RemoveAssociation
SetMetaPropertyOfAssociation
SetMetaPropertyOfAssociationEnd
-
Op15
Op4
Op9
Op9
Op9
-
30
31
addDependency
removeDependency
AddDependencyToClasses
RemoveDependencyFromClasses
Op4
32
33
addGeneralization
removeGeneralization
AddGeneralizationToClasses
RemoveGeneralizationFromClasses
Op16
Op4
34
35
addDataType
removeDataType
AddDatatype
RemoveDataType
Op1
Op4
36
37
38
39
40
41
addEnumeration
removeEnumeration
addLiteralToEnumeration
removeLiteralFromEnumeration
setMetaPropertyOfEnumeration
setMetaPropertyOfEnumerationLiteral
AddDatatype
RemoveDataType
AddLiteralToEnumeration
RemoveLiteralFromEnumeration
-
Op1
Op4
Op1
Op4
Op13
Op14
5.1.3 Transformationssystem
Ein Transformationssystem für UML-Klassendiagramme lässt sich vollständig durch die
Adaption des in Abschnitt 4.2 beschriebenen Basis-Transformationssystems realisieren.
Da die Instanziierung der Regel-Templates invariant gegenüber sequentiellen Abhängigkeiten ist, erfüllt das Transformationssystem für UML-Klassendiagramme die geforderte
Grundvoraussetzung 3.3.1.
Tabelle 5.3 zeigt hier exemplarisch die Adaption des BTS für die Teilmenge der Editieroperationen auf UML-Klassen, die Behandlung der restlichen Editieroperationen ist
Anhang A zu entnehmen. Um die Adaption des BTS zu beschreiben, wird für jede Editieroperation angegeben, welche Template-Regeln unter welchen Parameter-Bindungen
58
5 FALLSTUDIEN
instanziiert werden. Für amalgamierte Regeln kann die Multi-Regel auch mehrfach unter
verschiedenen Parameter-Bindungen instanziiert werden, was durch die Notation
=
n
=
n
mn =
n
k
m1
..
.
Kernel-Regel Parameter-Bindungen
Multi-Regel Parameter-Bindungen
Multi-Regel Parameter-Bindungen
dargestellt wird. Ferner werden zu behandelnde Pseudodifferenzen (PD) durch die Angabe der in Abschnitt 4.2 erläuterten Typen von Pseudodifferenzen und die Angabe des
betroffenen Referenztyps skizziert.
Tabelle 5.3: BTS-Adaption für Editieroperationen auf UML-Klassen
5
Regel-Template
Parameter-Bindungen
PD
<addElement>
2:<Metaclass> 7→ Class
E.1.b(type)
k
=
n
p:<Metaclass> 7→ Class
(
m1
=
c:<Metaclass> 7→ Dependency
<referenceType> 7→ client
(
6
<removeComp.Element>
m2
=
c:<Metaclass> 7→ Dependency
<referenceType> 7→ supplier
-
(
m3
=
c:<Metaclass> 7→ Association
<referenceType> 7→ endType
(
m4
=
c:<Metaclass> 7→ Generalization
<referenceType> 7→ general
4
<setMetaProperty>
2:<Metaclass> 7→ Class
3:<Metaclass> 7→ Class
<metaProperty> 7→ *
-
8
<globalMove>
2:<Metaclass> 7→ Class
3:<Metaclass> 7→ Class
-
Editieroperation 5 (addClass) wird durch die Instanziierung des TransformationsregelTemplates <addElement> behandelt, wobei der formale Parameter 2:<Metaclass> durch
den aktuellen Parameter, die UML-Metaklasse Class, zu ersetzen ist. Zudem kann der
Seiteneffekt E.1.b an Instanzen des Referenztyps type auftreten, welcher als Pseudodifferenz zu klassifizieren ist und entsprechend der Einfügung zugeordnet werden kann.
5.2. BLOCKDIAGRAMME IN MATLAB/SIMULINK
59
Editieroperation 6 (removeClass) wird durch die Instanziierung des Regel-Templates
<removeCompositeElement> behandelt. Den Ankerpunkt zur Erkennung der Operation
bildet die gelöschte Klasse. Diese bildet damit das LHS-Pattern der Kernel-Regel der
amalgamierten Regel. Ferner ist der Editieroperation eine Reihe gelöschter Beziehungen
zuzuordnen, welche typischerweise beim Löschen der Klassen ebenfalls gelöscht werden.
Konkret sind dies (m1 ) die Löschung von Dependency-Beziehungen, in denen die Klasse in der Rolle client vorkommt; (m2 ) die Löschung von Dependency-Beziehungen, in
denen die Klasse in der Rolle supplier auftritt; (m3 ) die Löschung von Assoziationen,
welche die gelöschte Klasse assoziieren (endType); und (m4 ) die Löschung von Generalisierungsbeziehungen, in denen die gelöschte Klasse als Oberklasse (general) vorkommt.
Weitere mit der Löschung der eine Klasse korrelierende Löschungen werden bereits durch
die generischen Transformationsegeln removeNode und removeSubtree behandelt.
Die Behandlung von Editieroperation 7 (setMetaPropertyOfClass) erfolgt durch die Instanziierung der Template-Regel <setMetaProperty>, wobei das betroffene Meta-Attribut
beliebig (*) ist.
Die Verschiebung von Klassen (Editieroperation 8, moveClass) kann auf Basis des
Regel-Templates <globalMove> erkannt werden, wobei hier keine der in Abschnitt 4.2.5
diskutierten Pseudodifferenzen auftreten.
5.2 Blockdiagramme in Matlab/Simulink
Modelltyp dieser Fallstudie sind Blockdiagramme der Matlab/Simulink-Toolbox12 , welche typischerweise zur Verhaltensspezifikation eingebetteter Systeme eingesetzt werden.
Als Ausgangsbasis werden zunächst das hier eingesetzte Simulink-Metamodell (Abschnitt
5.2.1) sowie der unterstellte Editierdatentyp (Abschnitt 5.2.2) vorgestellt, bevor in Abschnitt 5.2.3 die Adaption des Basis-Transformationssystems skizziert wird.
5.2.1 Metamodell
Die physische Repräsentation von Simulink-Modellen erfolgt beim Export der Modelle aus Matlab in einem proprietären Format. Zur Verarbeitung der Modelle als EMFInstanzen wurde am Lehrstuhl für Praktische Informatik der Universität Siegen eine
Komponente zur Konvertierung des proprietären Formats nach EMF-Ecore entwickelt.
12
http://www.mathworks.de/products/simulink/
60
5 FALLSTUDIEN
Ein vereinfachter Ausschnitt des Simulink-Metamodells, welches das Zielmetamodell der
Eingangstransformation bildet, ist in Anhang B zu finden. Die wesentlichen Aspekte des
verwendeten Simulink-Metamodells werden i.F. skizziert.
Blöcke und Konnektionen. Den Kern des entwickelten Matlab/Simulink-Metamodells
bilden Blöcke (Block). Die lokalen Eigenschaften von Blöcken werden durch generische Schlüssel-Wert-Paare (Property) repräsentiert. Blöcke besitzen ferner geordnete
Mengen von Eingangsports (InPort) und Ausgangsports (OutPort). Über Konnektionen (Connection), welche einen Ausgangsport mit n Eingangsports verbinden, werden
Datenflusskanten modelliert. Blöcke und Konnektionen sind Bestandteile eines Systems
(System).
Subsysteme. Ein Konzept der hierarchischen Modularisierung von Blockdiagrammen
stellen Subsysteme (Subsystem) dar. Subsysteme sind spezielle Systeme, welche durch
Subsystem-Blöcke in andere Systeme eingebettet werden können. Die Konnektion des
Subsystem-Blocks mit Blöcken des umschließenden Systems erfolgt dabei über die speziellen Port-Typen HierarchyInPort und HierarchyOutPort. Innerhalb des Subsystems
existieren für alle HierarchyInPorts und HierarchyOutPorts des Subsystem-Blocks spezielle Blöcke vom Typ InportBlock bzw. OutportBlock. Die Ports der Inport- bzw.
Outport-Blöcke stellen die Konnektionspunkte innerhalb des Subsystems bereit; als spezielle Typen von Ports werden hier wiederum HierarchyOutPort (im Falle von InportBlöcken) und HierarchyInPort (im Falle von Outport-Blöcken) verwendet. Die explizit
gebildeten Paare, bestehend aus einem HierarchyInPort und einem HierarchyOutPort,
bilden somit die systemübergreifenden Konnektionspunkte.
Layout-Informationen. Ein fundamentaler Unterschied zwischen der UML und Matlab/Simulink stellt der Umgang mit Layout-Informationen dar. Während die UML eine
Philosophie der partiellen Visualisierung von Modellen in Form von Diagrammen, und
damit eine strikte Trennung von Layout-Informationen und Modellinhalten verfolgt, werden im Falle von Matlab/Simulink Layout-Informationen als integraler Bestandteil eines
Modells betrachtet. So werden in dem hier verwendeten Metamodell auch die grafischen
Stützpunkte (BendPoint) von Konnektionen sowie die Positionseigenschaft von Blöcken
(position) abgebildet.
5.2. BLOCKDIAGRAMME IN MATLAB/SIMULINK
61
5.2.2 Editierdatentyp
Grundlage des hier unterstellten Editierdatentyps für Matlab/Simulink-Blockdiagramme
ist der in [MBT10a] beschriebene Operationskatalog. Eine Auflistung aller Editieroperationen ist in Tabelle 5.4 dargestellt. Formale Parameter, Vor- und Nachbedingungen
sowie die Beschreibung der Semantik der Editieroperationen sind dem Operationskatalog zu entnehmen. Einzige Abweichung bilden die Editieroperationen 12-15, welche keine
Entsprechung in [MBT10a] besitzen. Im Kern sind dies Spezialfälle der Editieroperationen addBlock bzw. removeBlock. Eine explizite Abgrenzung erfolgt hier aufgrund der
Tatsache, dass bei deren Erzeugung (bzw. Löschung) die zugehörigen HierarchyIn- bzw.
HierarchyOutPorts implizit ebenfalls erzeugt (bzw. gelöscht) werden. Die formalen Parameter, Vor- und Nachbedingungen der Editieroperationen 12-15 sind analog zu den
Operationen addBlock bzw. removeBlock definiert.
Tabelle 5.4: Editierdatentyp für Matlab/Simulink-Blockdiagramme
Editieroperation
Entsprechung in [MBT10a]
1
2
3
4
addBlock
removeBlock
changeBlockPosition
editBlockProperty
Op1
Op3
Op3
Op12
5
6
7
addInport
removeInport
editOutport
Op7
Op10
Op9
8
9
10
11
addConnection
removeConnection
layoutConnection
editConnection
Op4
Op6
Op5
Op15
12
13
addInportBlock
removeInportBlock
-
14
15
addOutportBlock
removeOutportBlock
-
16
createSubsystem
Op13
5.2.3 Transformationssystem
Die Erkennung der Editieroperationen 1-11 des Editierdatentyps für Matlab/SimulinkBlockdiagramme lässt sich durch die Instanziierung von Regel-Templates des in Ab-
62
5 FALLSTUDIEN
schnitt 4.2 beschriebenen Basis-Transformationssystems realisieren. Die entsprechenden
Parameter-Bindungen sind Anhang C zu entnehmen.
Die Instanziierung der Regel-Templates zur Behandlung der Editieroperationen 1-11
ist invariant gegenüber sequentiellen Abhängigkeiten. Zudem zeigt sich, dass die Transformationsregeln, welche nicht als Instanzen von Regel-Templates formuliert sind, lediglich sequentielle Abhängigkeiten zu generischen Regeln des Basis-Transformationssystems
besitzen. Der resultierende Abhängigkeitsgraph ist somit zyklenfrei und die geforderte
Grundvoraussetzung 3.3.1 erfüllt. Im Folgenden wird die Behandlung der Editieroperationen skizziert, welche nicht vollständig durch die Instanziierung von Regel-Templates
abgedeckt werden können.
Löschen und Erzeugen von Inport- und Outport-Blöcken. Hinsichtlich der Kompositionsstruktur lässt sich die Erkennung von Editieroperation 12 (addInportBlock)
als Instanz des Regel-Templates <addCompositeElement> formulieren. Für die enthaltenen Property-, InPort- und OutPort-Elemente sind die entsprechenden ParameterBindungen Tabelle C.1 (Editieroperation 1) zu entnehmen. Für die Gruppierung des
implizit ebenfalls angelegten HierarchyInPorts des zugehörigen Subsytem-Blocks kann
als Grundlage ebenfalls das Template <addCompositeElement> eingesetzt werden. Die
zu matchende Kante zwischen den Knoten p:<Metaclass> und c:<Metaclass> vom
Typ <referenceType> ist hier jedoch durch den Teilgraphen zu ersetzen, welcher die
Zuordnung des HierarchyInPorts des zugehörigen Subsytem-Blocks zum HierarchyOutPort des eingefügten InportBlocks repräsentiert. Auf analoge Weise werden auch die
Regeln zur Behandlung der Editieroperationen 13-15 gebildet.
Erzeugen von Subsystemen. Zur Behandlung von Editieroperation 16 (createSubsystem) wird eine amalgamierte Regel verwendet, deren Ankerpunkt ein eingefügter
Subsystem-Block sowie das zugehörige, ebenfalls erzeugte Subsystem bilden. Im Rahmen
von Multi-Regeln werden zunächst jeweils Verschiebungen von Blöcken und Konnektionen in das neu erzeugte Subsystem der Editieroperation zugeordnet. In vier weiteren
Multi-Regeln werden ferner die Divergenzen gruppiert, welche aus den innerhalb des
Subsystems erzeugten Inport- und Outport-Blöcken sowie den zugehörigen Konnektionen resultieren.
6 Evaluation
Die in Abschnitt 4 beschriebene Implementierung wurde zur Evaluation des in dieser
Arbeit beschriebenen Ansatzes zur Erkennung modelltypspezifischer Editieroperationen
auf symmetrischen Differenzen eingesetzt. Dabei wurden die in Abschnitt 5 vorgestellten
Fallstudien für UML-Klassendiagramme und Matlab/Simulink-Modelle einer Reihe von
Black-box Tests unterzogen.
Variiert wurden dabei die Testdaten und das zur Korrespondenzbildung eingesetzte
Verfahren. Als Testeingaben dienten Modelle, deren asymmetrische Differenzen in Form
der durchgeführten Editieroperationen bekannt waren. Die vorhandenen Editiersequenzen konnten somit als Referenzdaten genutzt werden. Derartige Testdaten wurden zum
einen durch kontrolliert editierte Testmodelle erstellt, und zum anderen durch die Rekonstruktion möglicher asymmetrischer Differenzen für Paare von Revisionen existierender
Modellhistorien gewonnen. Auf beide Kategorien von Testdaten als auch auf die zur
Korrespondenzbildung eingesetzten Verfahren wird i.F. eingegangen.
Testdaten aus kontrolliert editierten Testmodellen. Die erste Kategorie von Testdaten stellten kontrolliert editierte Testmodelle dar. Testeingaben, d.h. Paare von Modellen, welche aus kontrolliert editierten Testmodellen resultierten, wurden dabei in vier
Äquivalenzklassen klassifiziert:
1. CONGRUENT: Repräsentanten dieser Äquivalenzklasse bilden kongruente Modelle, d.h. Modelle, welche keine Unterschiede aufweisen. Eine einfache Methode zur
Durchführung von Testfällen auf Basis kongruenter Modelle ist der Vergleich eines
Modells mit sich selbst.
2. EMPTY_∩: Repräsentanten dieser Äquivalenzklasse bilden Modelle, deren symmetrische Differenz keine korrespondierenden Modellelemente enthält. Asymmetrische Differenzen bestehen hier lediglich aus der trivialen Operationssequenz,
welche zunächst alle Modellelemente des einen Modells löscht und anschließend
das andere Modell schrittweise neu aufbaut. Eine Methode zur Durchführung von
Testfällen dieser Äquivalenzklasse ist die synthetische Vergabe von persistenten
63
64
6 EVALUATION
Identifizierern von Modellelementen, welche für die beiden verglichenen Modelle
Werte aus disjunkten Wertebereichen annehmen. Die anschließende Korrespondenzbildung ist auf Basis der künstlich erzeugten, persistenten Identifizierer vorzunehmen. Ähnlichkeitsbasierte Korrespondenzbildungsverfahren sind zur Durchführung von Testfällen dieser Kategorie indessen ungeeignet, da hier i.d.R. einige
Elemente hinreichend ähnlich für die Bildung von Korrespondenzen sind.
3. CHANGE: Paare von Modellen als Repräsentanten dieser Äquivalenzklasse umfassen die gleichen Mengen von Modellelementen und unterscheiden sich lediglich in
deren Struktur bzw. den lokalen Eigenschaften der enthaltenen Modellelemente.
Derartige Testdaten lassen sich erzeugen, indem auf ein gegebenes Modell ausschließlich Editieroperationen angewendet werden, welche keine Modellelemente
löschen oder erzeugen.
4. COMBINED: Paare von Modellen dieser Äquivalenzklasse entstehen durch die Anwendung von Editieroperationen auf ein gegebenes Modell, wobei die Auswahl der
Editieroperationen dabei im Gegensatz zur Äquivalenzklasse CHANGE keinen Einschränkungen unterliegt. Repräsentanten der Äquivalenzklasse COMBINED kommen realen Szenarien aus der Praxis i.d.R. am nächsten.
Testdaten aus existierenden Versionshistorien. Zusätzlich zu kontrolliert editierten
Testmodellen als Repräsentanten der oben beschriebenen Äquivalenzklassen dienten im
Rahmen der Evaluation existierende Versionshistorien als Testdaten. Aufeinanderfolgende Revisionen wurden dabei jeweils paarweise verglichen. Für UML-Klassendiagramme
wurde eine zehn Revisionen umfassende Versionshistorie des Datenmodells eines fiktiven
Flugbuchungssystems (AIR) verwendet. Für Matlab/Simulink-Blockdiagramme standen
vier Revisionen eines realen Verhaltensmodells eines Tempomats mit Abstandsregelung
(TmA) zur Verfügung.
Eingesetzte Korrespondenzbildungsverfahren. Zur Korrespondenzbildung und der Ableitung technischer Differenzen wurden im Rahmen der Evaluation verschiedene Komponenten der SiDiff-Toolbox verwendet. Variiert wurde hier zwischen der Korrespondenzbildung auf Basis persistenter Identifizierer, und einem hybriden Ansatz aus signaturbasiertem und ähnlichkeitsbasiertem Matching (vgl. Abschnitt 2.3.3). Die Vorschaltung
einer signaturbasierten Matching-Komponente dient hierbei lediglich der Performanzop-
6.1. KORREKTHEIT
65
timierung, indem Modellelemente mit identischen Signaturen13 sehr effizient gematcht
werden können. Im Folgenden wird das Verfahren daher konzeptuell als ähnlichkeitsbasiert betrachtet.
6.1 Korrektheit
Die Korrektheit des vorgestellten Verfahrens zur Erkennung von Editieroperationen auf
symmetrischen Differenzen wurde unter der Annahme von perfekten Korrespondenzen
getestet. Unter perfekten Korrespondenzen verstehen wir hier Korrespondenzen, welche die Paare von Modellelementen zweier Modelle A und B unter Kenntnis der tatsächlich durchgeführten Editieroperationen reflektieren. Perfekte Korrespondenzen wurden für UML-Klassendiagramme auf Basis von persistenten Identifizierern gewonnen.
Matlab/Simulink-Modelle, für welche keine persistenten Identifizierer vorliegen, wurden
in der nachfolgend beschriebenen Testreihe nicht eingesetzt.
Für kontrolliert editierte UML-Klassendiagramme wurde jeweils ein Repräsentant der
Äquivalenzklassen CONGRUENT, EMPTY_∩ und CHANGE verwendet. Für die Äquivalenzklasse COMBINED wurden jeweils Testfälle auf Basis fünf verschiedener Repräsentanten (COMBINED1 - COMBINED5 ) durchgeführt. Zudem wurden die Revisionspaare der Versionshistorie AIR auf Basis persistenter Identifizierer verglichen und als
Testdaten eingesetzt. Für alle Testfälle stimmten die erkannten Editieroperationen mit
der jeweiligen Referenz-Operationssequenz überein.
Tabelle 6.1 liefert einen Überblick über die charakteristischen Kennzahlen der Testmodelle und deren Differenzen. Dargestellt ist hier jeweils die Anzahl der Knoten (|VA | bzw.
|VB |) und Kanten (|EA | bzw. |EB |) der abstrakten Syntaxgraphen der Modelle A bzw.
B, was einen Eindruck von der Größe der Testmodelle vermittelt. Die Modelldifferenz
wird durch die Anzahl der Korrespondenzen sowie die Anzahl der in der asymmetrischen
Differenz enthaltenen Editieroperationen charakterisiert.
6.2 Korrelation mit Korrespondenzbildungsverfahren
Korrespondenzen bilden den Kern symmetrischer Differenzen und sind somit von entscheidender Bedeutung für die darauf basierende Erkennung von Editieroperationen. Zur
13
Hier wurden Hashwerte über die lokalen Attribute der Modellelemente gebildet und als Signaturen
eingesetzt.
66
6 EVALUATION
CONGRUENT
EMPTY_∩
CHANGE
COMBINED1
COMBINED2
COMBINED3
COMBINED4
COMBINED5
AIR6 → AIR7
AIR7 → AIR8
AIR8 → AIR9
AIR9 → AIR10
AIR10 → AIR11
AIR11 → AIR16
AIR16 → AIR17
AIR17 → AIR21
AIR21 → AIR22
|VA |
|VB |
|EA |
|EB |
Korrespond.
Editierop.
45
46
47
11
21
11
57
47
16
36
53
83
137
154
164
178
168
45
46
47
7
16
18
57
47
36
48
83
137
154
164
178
168
176
92
95
96
15
43
18
111
95
29
80
119
190
328
374
392
430
404
92
95
96
8
32
33
111
93
80
106
190
328
374
392
430
404
426
45
1
47
3
5
4
50
44
11
36
53
81
137
117
164
158
168
0
33
14
5
10
3
24
20
14
12
13
26
18
43
14
19
8
Tabelle 6.1: Modellkennzahlen und Differenzmetriken
Untersuchung der Korrelation von Korrespondenzbildungsverfahren und der Erkennung
von Editieroperationen wurde die in Abschnitt 6.1 beschriebene Testreihe unter dem
Einsatz des in SiDiff implementierten, ähnlichkeitsbasierten Korrespondenzbildungsverfahren wiederholt. Tabelle 6.2 zeigt hier lediglich die von Tabelle 6.1 abweichenden Testergebnisse. Dargestellt werden jeweils die Anzahl der gebildeten Korrespondenzen sowie
die Anzahl der nicht aggregierten technischen Divergenzen und Fragmente.
Wie Tab. 6.2 zu entnehmen ist, konnten im Falle der ähnlichkeitsbasierten Korrespondenzbildung für einige Testfälle nicht alle Divergenzen zu konzeptuellen Editieroperationen gruppiert werden. Die zu Grunde liegende Heuristik führte hier zu KorrespondenzZuständen, für die eine Gruppierung aller technischen Divergenzen auf Basis des gegebenen Editierdatentyps nicht möglich war. Generell kann im Falle von ähnlichkeitsbasierten
Korrespondenzen nicht garantiert werden, dass sich die daraus abgeleitete, symmetrische
Differenz vollständig in Editieroperationen überführen lässt, sofern lediglich Operationen
des unterstellten Editierdatentyps zugelassen werden.
6.3. PRAKTISCHER NUTZEN
67
Interessant ist hier insbesondere der Aspekt, dass die ähnlichkeitsbasierten Korrespondenzen intuitiv meist als qualitativ hochwertiger empfunden werden, als dies für
Resultate, welche auf Basis von persistenten Identifizierern gewonnen werden, der Fall
ist. Auch wenn im letzteren Fall intuitiv schlechtere und i.d.R. auch weniger Korrespondenzen gebildet werden, ist dennoch garantiert, dass die tatsächlich durchgeführten
Editieroperation vollständig rekonstruiert werden können. Hier zeigt sich insbesondere,
dass der Qualitätsbegriff für Modelldifferenzen nicht anwendungsfallneutral formuliert
werden kann. Die Entwicklung systematischer Ansätze zur Definition der Qualität von
Differenzen ist indessen Gegenstand zukünftiger Forschungsarbeiten (s. Kapitel 7.2).
Korrespond.
CHANGE
COMBINED3
COMBINED4
COMBINED5
AIR7 → AIR8
AIR17 → AIR21
Nicht aggregierte
Technische Divergenzen Fragmente
36
9
20
31
29
152
6
0
20
6
4
2
6
4
20
6
3
1
Tabelle 6.2: Nicht aggregierte technische Divergenzen und Fragmente
6.3 Praktischer Nutzen
Ein wesentliches Qualitätsmerkmal des vorgestellten Ansatzes ist der praktische Nutzen. Aufschluss hierüber werden zukünftige Forschungsarbeiten bringen, in denen die
Anwendung der Erkennung von Editieroperationen auf verwandte Problemfelder untersucht werden soll (s. Abschnitt 7.2). Zum derzeitigen Stand wird hier zur Beurteilung des
praktischen Nutzens die Optimierung der Qualität der Differenz herangezogen. Die hier
verwendete Metrik zur Messung der Qualitätsoptimierung stellt der Kompressionsfaktor
dar, welcher sich durch die Gruppierung der technischen Divergenzen zu Editieroperationen ergibt:
cf =
|T echnDiv.|
|EditOp.|
(6.3.1)
68
6 EVALUATION
In (6.3.1) stellt |T echnDiv.| die Gesamtzahl der technischen Divergenzen dar, welche in Editieroperationen enthalten sind, |EditOp.| stellt die Gesamtzahl der erkannten
Editieroperationen dar. Der Kompressionsfaktor kann somit aufgefasst werden als die
durchschnittliche Anzahl der technischen Divergenzen pro Editieroperation. In Tabelle 6.3 sind für die jeweiligen Testfälle zudem die minimale und maximale Anzahl der
technischen Divergenzen pro Editieroperation aufgeführt.
Als konkrete Testdaten dienten hier die zur Evaluation der Korrektheit (s. Abschnitt
6.1) eingesetzten Paare von UML-Klassendiagrammen. Die Korrespondenzen wurden
auch hier auf Basis der persistenten Identifizierer gebildet. Ferner dienten die drei Paare der aufeinander folgenden Revisionen des Simulink TmA-Modells (TmA1 - TmA4 )
als Testdaten, wobei die jeweiligen Korrespondenzen hier ähnlichkeitsbasiert gebildet
wurden.
Auffällig sind hier insbesondere die hohen Kompressionsfaktoren für Editiersequenzen,
welche überwiegend aus einfügenden und löschenden Operationen bestehen. Dies ist zum
einen durch den Aufbau des Differenzmodells zu erklären, da die Attributwerte von eingefügten und gelöschten Knoten des ASG als eigene technische Divergenzen repräsentiert
werden. Zum anderen resultiert die im Falle von Löschungen durchgeführte Gruppierung
aller Divergenzen eines gelöschten Teilbaumes in einer großen Anzahl an technischen
Divergenzen pro Editieroperation. Dies wird insbesondere für den Testfall EMPTY_∩
ersichtlich. Die maximale Anzahl von 320 technischen Divergenzen pro Editieroperation resultiert hier aus der Löschung eines umfangreichen UML-Paketes. Der höchste
Kompressionsfaktor wird für den Repräsentanten der Äquivalenzklasse COMBINED3
erreicht. Die zu Grunde liegende Editiersequenz besteht lediglich aus der Einfügung
und Löschung von UML-Assoziationen, welche in verhältnismäßig großen Änderungsmustern auf dem ASG resultieren. Auch für die Testfälle auf Basis der Historie des
UML-Modells AIR sind die Kompressionsfaktoren relativ hoch. Da das Modell über die
Historie ständig angewachsen ist, bestehen die Editiersequenzen der einzelnen Testfälle
nahezu ausschließlich aus einfügenden Editieroperationen.
Im Gegensatz dazu wurden im Falle der TmA-Historie vornehmlich ändernde Operationen zur Konsolidierung des Modells vorgenommen. So wurden bspw. von Version
TmA1 nach TmA2 hauptsächlich Änderungsoperationen zur Umsetzung von Namenskonventionen durchgeführt. Ein hoher Kompressionsfaktor ist für die Differenz der Versionen TmA3 und TmA4 zu beobachten. Maßgebend hierfür ist die Erzeugung zweier
Subsysteme, welche jeweils in mehr als 50 technischen Divergenzen resultierte.
Insgesamt zeigen die Testergebnisse, dass die resultierende Differenz durch die Erkennung modelltypspezifischer Editieroperationen stark optimiert werden kann. Der Kom-
6.4. PERFORMANZ
69
|T echnDiv.|
echnDiv.
MIN( TEditOp.
)
echnDiv.
MAX( TEditOp.
)
cf
CONGRUENT
EMPTY_∩
CHANGE
0
700
28
4
1
320
3
21,2121
2,0000
COMBINED1
COMBINED2
COMBINED3
COMBINED4
COMBINED5
90
199
165
222
80
7
7
55
3
1
32
64
55
13
15
18,0000
19,9000
55,0000
9,2500
4,0000
AIR6 → AIR7
AIR7 → AIR8
AIR8 → AIR9
AIR9 → AIR10
AIR10 → AIR11
AIR11 → AIR16
AIR16 → AIR17
AIR17 → AIR21
AIR21 → AIR22
303
97
282
594
155
792
172
293
100
7
5
1
6
1
1
10
5
10
47
14
55
47
14
48
14
47
14
21,6429
8,0833
21,6923
22,8462
8,6111
18,4186
12,2857
15,4211
12,5000
TmA1 → TmA2
TmA2 → TmA3
TmA3 → TmA4
13
311
1129
1
1
1
8
24
56
2,1667
3,8395
12,5444
Tabelle 6.3: Technische Divergenzen pro Editieroperation
pressionsfaktor liefert hier ein intuitives Maß für den Grad der Optimierung. Eine Beurteilung, inwiefern die Erkennung modelltypspezifischer Editieroperationen die Verständlichkeit von Differenzen aus Benutzersicht verbessert, wird zukünftig weiter zu erforschen
sein. Voraussetzung hierfür ist die Integration der Erkennung komplexer Editieroperationen in Differenzanzeige- oder Mischwerkzeuge (s. Abschnitt 7.2).
6.4 Performanz
Die Berechnung von Modelldifferenzen erfolgt i.d.R. im Rahmen interaktiver Benutzerprozesse, so z.B. im Kontext des Konfigurationsmanagements. Die Laufzeit der Differenz-
70
6 EVALUATION
berechnung stellt damit einen nicht unwesentlichen Faktor für die praktische Einsetzbarkeit von Differenzwerkzeugen dar, so dass im Rahmen der Evaluation die Erkennung
modelltypspezifischer Operationen auch einer Performanz-Analyse unterzogen wurde.
Untersucht wurde hier das Laufzeitverhalten in realen Szenarien sowie das Laufzeitverhalten für große Differenzen.
Um Prognosen über die Performanz in realen Szenarien treffen zu können, werden i.F.
lediglich die Laufzeitmessungen für die Testfälle auf Basis des Simulink TmA-Modells
aufgeführt14 . Die Testdaten weisen dabei insbesondere die realistische Charakteristik
auf, dass der Umfang der Differenzen (s. Tab. 6.3) in Relation zur Größe der Modelle
(der ASG umfasst jeweils ca. 5000 Knoten und 7000 Kanten) relativ gering ist. Für
die Simulink TmA-Testfälle wurden in jeweils zehn Versuchen die durchschnittlichen
Laufzeiten für die sequentiell ablaufenden Phasen des Modellvergleichs gemessen; (1) die
Berechnung der Korrespondenz (Matching), (2) die Ableitung der technischen Differenz
(Techn. Diff.) und (3) die Erkennung der komplexen Operationen (Kompl. Op.).
Abbildung 6.1: Laufzeitverhalten in realen Szenarien
Abbildung 6.1 zeigt die Mittelwerte der absoluten Laufzeiten in Millisekunden auf
einem Doppelkernprozessor mit Taktfrequenzen von jeweils 2,53 GHz (links). Ebenfalls
dargestellt ist die relative Verteilung der Laufzeiten auf die einzelnen Phasen der Differenzberechnung (rechts). Der auf die Erkennung von Editieroperationen entfallende
Anteil ist dabei in allen drei Testfällen vernachlässigbar klein.
14
Für die restlichen Testfälle waren die Laufzeiten des gesamten Modellvergleichs in allen Fällen < 5
Sekunden.
6.4. PERFORMANZ
71
Abb. 6.2 gibt zudem Aufschluss über das Laufzeitverhalten der Operationserkennung
für große Differenzen. Als Testdaten wurden hier Repräsentanten der Äquivalenzklasse
EMPTY_∩ verwendet. Konkrete Testmodelle waren sieben unterschiedlich große Teilmengen der Ecore-basierten Implementierung des UML2-Metamodells, welche jeweils mit
sich selbst verglichen wurden, wobei als Eingabe für die Differenzberechnung jeweils eine
leere Menge von Korrespondenzen vorgegeben wurde. Wie aus Abb. 6.2 ersichtlich wird,
war hier die Laufzeit zur Erkennung von Editieroperationen annähernd proportional zur
Anzahl der technischen Divergenzen. Somit ist zu erwarten, dass die Operationserkennung auch für verhältnismäßig große Differenzen skaliert.
Abbildung 6.2: Laufzeitverhalten für große Differenzen
Auch wenn hier keine empirische Untersuchung erfolgte, ist zu erwarten, dass die Optimierung der symmetrischen Differenz durch die Erkennung von Editieroperationen in
realen, interaktiven Anwendungsszenarien eingesetzt werden kann, ohne die Latenzzeiten
merklich zu verschlechtern.
7 Zusammenfassung und Ausblick
In Abschnitt 7.1 werden die wesentlichen Beiträge dieser Arbeit zusammengefasst, Abschnitt 7.2 liefert einen Ausblick auf zukünftige, darauf aufbauende Forschungsarbeiten.
7.1 Zusammenfassung und Bewertung
Der Fokus existierender Ansätze des Modellvergleichs liegt auf der Korrespondenzbildung. Den Kern daraus abgeleiteter, symmetrischer Differenzen bilden korrespondierende Elemente des abstrakten Syntaxgraphen. Unterschiede werden in Form von elementaren Graphoperationen auf dem ASG beschrieben. Die semantische Anhebung der
abgeleiteten Differenzen auf das Niveau modelltypspezifischer Editieroperationen, welche
i.d.R eine Vielzahl elementarer Graphoperationen umfassen, ist bislang nur unzureichend
adressiert worden.
In dieser Arbeit wurde ein konzeptueller Ansatz vorgestellt, mit dem sich modelltypspezifische Editieroperationen auf Basis symmetrischer Differenzen automatisiert erkennen lassen. Kernidee ist es dabei, die in der Repräsentation der Differenz, welche
ebenfalls als Graph aufgefasst werden kann, auftretenden Divergenzen anhand von Änderungsmustern zu Gruppen von Divergenzen zusammenzufassen, welche konzeptuell das
Resultat modelltypspezifischer Editieroperationen darstellen. Hierzu wurde ein generischer Algorithmus vorgestellt, welcher auf regelbasierten Graphtransformationen basiert
und mittels EMF-Henshin implementiert wurde.
Auf Grundlage des SiDiff-Differenzmodells wurde ein Basis-Transformationssystem bestehend aus generischen Transformationsregeln und Regel-Templates entworfen, welches
mit geringem Aufwand an konkrete Modelltypen adaptiert werden kann. Eine entsprechende Adaption wurde in zwei Fallstudien für UML-Klassendiagramme und Blockdiagramme in Matlab/Simulink durchgeführt. Die Korrektheit des Verfahrens wurde unter
der Annahme perfekter Korrespondenzen im Rahmen der durchgeführten Evaluation
nachgewiesen. Weiterhin wurde im Rahmen der Evaluation der praktische Nutzen des
Ansatzes demonstriert. Evaluationsergebnisse hinsichtlich der Performanz legen dar, dass
das Verfahren auch in interaktiven Prozessen eingesetzt werden kann.
73
74
7 ZUSAMMENFASSUNG UND AUSBLICK
Ausgehend von der konkreten Repräsentation der symmetrischen Differenzen lassen
sich mittels des vorgestellten Ansatzes zudem Pseudodifferenzen eliminieren, welche lediglich aufgrund von technologiespezifischen Anteilen in den Repräsentationen der Modelle auftreten, konzeptuell jedoch als irrelevant betrachtet werden können. Ferner lassen
sich Differenzen korrigieren oder semantisch anheben, deren Ursache aus den zu Grunde
liegenden Metamodellen resultiert, welche im Hinblick auf die Bildung von Modelldifferenzen Unzulänglichkeiten aufweisen. In der Praxis ist hinsichtlich beider Ursachen für
„ungeschickte“ Differenzen im Einzelfall zu entscheiden, ob der Einsatz alternativer Lösungsansätze zu präferieren ist. Pseudodifferenzen lassen sich durch geeignete Maßnahmen zur Ausblendung technologiespezifischer Details in der Repräsentation der Modelle
eliminieren. Metamodell-Unzulänglichkeiten lassen sich durch eine Adaption oder Redefinition des Metamodells korrigieren. In der Regel wird hier ein Kompromiss zwischen
dem jeweiligen Realisierungsaufwand und der Performanz der Differenzberechnung zu
treffen sein.
Eine konzeptuelle Einschränkung des Ansatzes stellt die Beschränkung des Editierdatentyps auf verhältnismäßig einfache Basis-Editieroperationen dar. Modelldifferenzen
können jedoch aus weitaus komplexeren Operationen wie bspw. Refactoring-Operationen
[FBB+ 99] auf Modellen resultieren. Eine entsprechende Erweiterung des Ansatzes ist Gegenstand zukünftiger Forschungsarbeiten. Ein Überblick über geplante Aktivitäten wird
i.F. skizziert.
7.2 Ausblick und zukünftige Forschungsarbeiten
Zukünftig ist die Erweiterung des Ansatzes um die Unterstützung komplexer Operationen wie bspw. Refactorings [FBB+ 99] zu untersuchen. Zu klären ist hier insbesondere,
welche Implikationen sich daraus hinsichtlich der Eigenschaften des Transformationssystems, welche dem in Kapitel 3.3 vorgestellten Gruppierungsalgorithmus unterstellt
wurden, ergeben. Die Erkennung einiger Refactorings erfordert ferner eine Anpassung
des Korrespondenzbegriffs auf n-stellige Korrespondenzen. Ein Beispiel hierfür ist die
Operation „Extract Superclass“ [FBB+ 99]. Die Operation erzeugt eine neue Superklasse
für Klassen, welche eine Schnittmenge identischer Eigenschaften (Attribute oder Operationen) besitzen und verschiebt die Eigenschaften in die neu erzeugte Superklasse.
Konzeptuell korrespondieren hier also die Eigenschaften aller betroffenen Klassen mit
den jeweiligen Eigenschaften der neu erzeugten Superklasse.
Um den Aufwand für die Erstellung von Transformationssystemen für konkrete Modelltypen zu reduzieren, soll die Instanziierung der in Abschnitt 4.2 beschriebenen Regel-
7.2. AUSBLICK UND ZUKÜNFTIGE FORSCHUNGSARBEITEN
75
Templates durch geeignete Werkzeuge unterstützt werden. Zusätzlich zu den im Rahmen dieser Arbeit durchgeführten Fallstudien für UML-Klassendiagramme und Blockdiagramme in Matlab/Simulink sollen zukünftig weitere Modelltypen unterstützt werden, um den beschriebenen Ansatz in weiteren Studien zu evaluieren.
Der Modellvergleich bildet ferner den Kern einer Reihe von angrenzenden Problemfeldern und Werkzeugen, welche intern auf Modelldifferenzen basieren. Hier wird zu
untersuchen sein, inwiefern sich die Erkennung komplexer Operationen gewinnbringend
auf die jeweiligen Problemfelder anwenden lässt. Einige der Problemfelder sowie darauf
mögliche Anwendungen komplexer Operationen werden i.F. kurz beleuchtet.
Werkzeuge zur Differenzanzeige. Ein möglicher Anwendungskontext sind Werkzeuge
zur Differenzanzeige. Hier lassen sich bspw. komplexe Editieroperation in die Darstellungsform der klickbaren Liste lokaler Unterschiede [KSW08] integrieren. Die Differenz
wird somit kompakter und für den Benutzer verständlich dargestellt. Zusätzlich zur Optimierung der Verständlichkeit einer Differenz lassen sich weitere Anwendungskontexte
indentifizieren, welche im Kern auf Modelldifferenzen basieren. Beispielhaft werden i.F.
die Co-Evolution von Metamodellen und Modellen sowie das Mischen von Modellen
betrachtet.
Co-Evolution von Metamodellen und Modellen. Im Falle der Evolution von Metamodellen ergibt sich das Problem der Migration (Co-Evolution) bestehender ModellInstanzen. In diesem Kontext existieren bereits einige Ansätze, welche entsprechende
Migrationsvorschriften auf Basis der Metamodell-Differenzen semi-automatisiert ableiten [RPKP09]. Die Ableitung geschieht hier jedoch auf Basis der technischen Differenz.
Die Integration komplexer Editieroperationen, welche den Automatisierungsgrad der Ableitung der Migrationsvorschrift vielfach deutlich erhöht [CREP08], wird lediglich als
Ansatzpunkt für zukünftige Arbeiten identifiziert [Eys09].
Mischen von Modellen. Ein weiterer möglicher Anwendungskontext ist das Mischen
von Modellen. Durch die semantische Anhebung technischer Differenzen auf die Abstraktionsebene komplexer Editieroperationen kann, im Falle des 3-Wege-Mischens, die
Anzahl der manuell zu treffenden Mischentscheidungen sowie die Anzahl manuell aufzulösender Mischkonflikte deutlich reduziert werden. Insbesondere wird hier zu untersuchen
sein, inwiefern sich existierende Arbeiten zum Mischen von Modellen adaptieren lassen,
welche auf der Existenz komplexer Editierprofile basieren [DMJN08, KGE10]. Ansatz-
76
7 ZUSAMMENFASSUNG UND AUSBLICK
punkt ist dabei die Konversion von um Editieroperationen angereicherten symmetrischen Differenzen in komplexe Editiersequenzen entlang der Pfade hM 1, einf g −1 (M 1 \
M 2), KM 1 , T, KM 2 , einf g(M 2 \ M 1), M 2i (bzw. umgekehrt) in Abb. 2.2. Gleiches gilt
für die Adaption operations-basierter Ansätze [Wac07, HBJ08] zur Co-Evolution von
Metamodellen und Modellen.
Weiterer Untersuchungsgegenstand zukünftiger Forschungsarbeiten ist der Einsatz von
Metriken, die sich auf Basis von Differenzen bilden lassen, welche um komplexe Operationen angereichert wurden. In Abschnitt 6 wurde der Kompressionsfaktor als Differenzmetrik zur Evaluation des praktischen Nutzens des hier vorgestellten Ansatzes eingesetzt.
Darüber hinaus existieren weitere Anwendungsgebiete, von denen i.F. Qualitätsmaße für
Differenzen sowie die Analyse von Modellevolution kurz beleuchtet werden.
Qualitätsmaße für Differenzen. Die Beurteilung verschiedener Verfahren zur Differenzberechnung gestaltet sich derzeit schwierig, da keine systematischen Ansätze zur
Definition der Qualität von Differenzen existieren. Der Qualitätsbegriff besitzt hier indessen mehrere Dimensionen und ist ferner nicht anwendungsfallneutral definierbar, wie
bereits im Rahmen der Evaluation aufgezeigt wurde. Für die Kategorie von Anwendungsfällen, welche auf der Erkennung komplexer Operationen basieren, stellt die Ableitbarkeit möglicher Editieroperationen einen Ansatz zur Beurteilung der Qualität von
Korrespondenzen dar, welcher zukünftig zu untersuchen sein wird. Die Definition von
Qualitätsmaßen ist eines der wesentlichen Ziele des 2010 am Lehrstuhl für Praktische
Informatik der Universität Siegen angelaufenen DFG-Forschungsprojekts „QuDiMo“15 .
Analyse von Modellevolution. Ein weiteres Anwendungsfeld für Differenzmetriken auf
Basis komplexer Operationen ist die Untersuchung von Eigenschaften der Modellevolution. Basierend auf existierenden Versionshistorien lassen sich hier mittels der Erkennung
komplexer Operationen Editierprofile für Modelle extrahieren, welche für weitere Analysen eingesetzt werden können. Ferner können die extrahierten Editierprofile zu weiteren
Forschungszwecken eingesetzt werden, so z.B. zur Gewinnung statistischer Parameter
zur synthetischen Erzeugung von Benchmarks für verschiedenste Werkzeuge der modellbasierten Entwicklung.
15
http://pi.informatik.uni-siegen.de/qudimo/
Abbildungsverzeichnis
1.1
Beispielmodelle A und B . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
ASG-Repräsentationen der Beispielmodelle A und B . . . . . . . . . . . .
3
2.1
Ecore-Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2
Konzeptueller Inhalt symmetrischer Differenzen . . . . . . . . . . . . . . . 14
2.3
SiDiff-Differenzmodell: Kern . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4
SiDiff-Differenzmodell: Attributänderungen . . . . . . . . . . . . . . . . . 17
2.5
SiDiff-Differenzmodell: Referenzänderungen . . . . . . . . . . . . . . . . . 18
2.6
Technische Differenz der Beispielmodelle A und B . . . . . . . . . . . . . . 19
2.7
Transformationsregeln in EMF-Henshin: Abstrakte Syntax . . . . . . . . . 26
3.1
Exemplarische Divergenzgruppierung: setNavigabilityOfAssociationEnd . . 30
3.2
Exemplarische Divergenzgruppierung; Editieroperation addAttribute . . . 30
3.3
Repräsentation gruppierter Divergenzen . . . . . . . . . . . . . . . . . . . 32
3.4
Exemplarische Transformationsregel: setNavigabilityOfAssociationEnd . . 34
4.1
Generische Transformationsregel: addNode . . . . . . . . . . . . . . . . . . 43
4.2
Generische Transformationsregel: addRootNode . . . . . . . . . . . . . . . 45
4.3
Regel-Templates: <addElement> und <addCompositeElement> . . . . . . 46
4.4
Regel-Templates: <setMetaProperty> und <changeType> . . . . . . . . . 47
4.5
Regel-Templates: <localMove> und <indexedChange> . . . . . . . . . . . 48
4.6
Generische Transformationsregel: removeNode . . . . . . . . . . . . . . . . 49
4.7
Generische Transformationsregel: removeSubtree . . . . . . . . . . . . . . . 50
4.8
Transformationsregel-Template: <removeElement> . . . . . . . . . . . . . 51
4.9
Transformationsregel-Template: <removeCompositeElement> . . . . . . . 52
4.10 Transformationsregel-Template: <globalMove> . . . . . . . . . . . . . . . 53
6.1
Laufzeitverhalten in realen Szenarien . . . . . . . . . . . . . . . . . . . . . 70
6.2
Laufzeitverhalten für große Differenzen . . . . . . . . . . . . . . . . . . . . 71
77
78
ABBILDUNGSVERZEICHNIS
B.1 Matlab/Simulink-Metamodell: Blöcke und Konnektionen . . . . . . . . . . 89
B.2 Matlab/Simulink-Metamodell: Einbettung von Subsystemen . . . . . . . . 89
Literaturverzeichnis
[ABJ+ 10]
Arendt, Thorsten ; Biermann, Enrico ; Jurack, Stefan ; Krause, Christian ; Taentzer, Gabriele: Henshin: Advanced Concepts and Tools for InPlace EMF Model Transformations. In: MODELS 2010: Proceedings of the
13th Int. Conference on Model Driven Engineering Languages and Systems,
2010
[BE09]
Bendix, Lars ; Emanuelsson, Par: Collaborative work with Software
Models - Industrial experience and requirements. In: 2009 International
Conference on Model-Based Systems Engineering, IEEE, March 2009. –
ISBN 978–1–4244–2967–7, 60–68
[BET08]
Biermann, Enrico ; Ermel, Claudia ; Taentzer, Gabriele: Precise Semantics of EMF Model Transformations by Graph Transformation. In:
MoDELS ’08: Proceedings of the 11th international conference on Model
Driven Engineering Languages and Systems. Berlin, Heidelberg : SpringerVerlag, 2008. – ISBN 978–3–540–87874–2, S. 53–67
[BET10]
Biermann, Enrico ; Ermel, Claudia ; Taentzer, Gabriele: Lifting Parallel Graph Transformation Concepts to Model Transformation based on the
Eclipse Modeling Framework. Electronic Communications of the EASST,
Volume 26, 2010
[BLSW09]
Brosch, Petra ; Langer, Philip ; Seidl, Martina ; Wimmer, Manuel:
Towards end-user adaptable model versioning: The By-Example Operation Recorder. In: CVSM ’09: Proceedings of the 2009 ICSE Workshop on
Comparison and Versioning of Software Models, IEEE Computer Society,
2009. – ISBN 978–1–4244–3714–6, S. 55–60
[BP08]
Brun, Cédric ; Pierantonio, Alfonso: Model Differences in the Eclipse
Modelling Framework. In: UPGRADE - The European Journal for the
Informatics Professional 2 (2008), S. 29–34
79
80
LITERATURVERZEICHNIS
[BSW+ 09]
Brosch, Petra ; Seidl, Martina ; Wieland, Konrad ; Wimmer, Manuel
; Langer, Philip: The operation recorder: specifying model refactorings
by-example. In: OOPSLA ’09: Proceeding of the 24th ACM SIGPLAN
conference companion on Object oriented programming systems languages
and applications, ACM, 2009. – ISBN 978–1–60558–768–4, S. 791–792
[CDRP07]
Cicchetti, Antonio ; Di Ruscio, Davide ; Pierantonio, Alfonso: A Metamodel Independent Approach to Difference Representation. In: Journal
of Object Technology 6 (2007), October, S. 165–185
[CREP08]
Cicchetti, Antonio ; Ruscio, Davide D. ; Eramo, Romina ; Pierantonio, Alfonso: Automating Co-evolution in Model-Driven Engineering.
In: EDOC ’08: Proceedings of the 2008 12th International IEEE Enterprise
Distributed Object Computing Conference, IEEE Computer Society, 2008.
– ISBN 978–0–7695–3373–5, S. 222–231
[DMJN08]
Dig, Danny ; Manzoor, Kashif ; Johnson, Ralph E. ; Nguyen, Tien N.:
Effective Software Merging in the Presence of Object-Oriented Refactorings. In: IEEE Trans. Softw. Eng. 34 (2008), Nr. 3, S. 321–335. – ISSN
0098–5589
[EEPT06]
Ehrig, H. ; Ehrig, K. ; Prange, U. ; Taentzer, G.: Fundamentals
of Algebraic Graph Transformation (Monographs in Theoretical Computer
Science. An EATCS Series). Springer, 2006. – ISBN 3540311874
[EHKPP91] Ehrig, Hartmut ; Habel, Annegret ; Kreowski, Hans-Jörg ; ParisiPresicce, Francesco: From Graph Grammars to High Level Replacement
Systems. In: Proceedings of the 4th International Workshop on GraphGrammars and Their Application to Computer Science, Springer, 1991. –
ISBN 3–540–54478–X, S. 269–291
[Ehr79]
Ehrig, Hartmut: Introduction to the algebraic theory of graph grammars (a
survey). In: Claus, Volker (Hrsg.) ; Ehrig, Hartmut (Hrsg.) ; Rozenberg,
Grzegorz (Hrsg.): Graph-Grammars and Their Application to Computer
Science and Biology Bd. 73. Springer, 1979, S. 1–69
[Eys09]
Eysholdt, Moritz: EMF Ecore Based Meta Model Evolution and Model Co-Evolution, University of Oldenburg, Germany, Diplomarbeit, 2009.
http://moritz.eysholdt.name/publications/
LITERATURVERZEICHNIS
81
[FBB+ 99]
Fowler, Martin ; Beck, Kent ; Brant, John ; Opdyke, William ; Roberts, Don: Refactoring: Improving the Design of Existing Code. AddisonWesley, 1999
[GHJV95]
Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John:
Design patterns: elements of reusable object-oriented software. Boston, MA,
USA : Addison-Wesley, 1995. – ISBN 0–201–63361–2
[HBJ08]
Herrmannsdoerfer, Markus ; Benz, Sebastian ; Juergens, Elmar: COPE: A Language for the Coupled Evolution of Metamodels and Models.
In: Deridder, Dirk (Hrsg.) ; Gray, Jeff (Hrsg.) ; Pierantonio, Alfonso
(Hrsg.) ; Schobbens, Pierre-Yves (Hrsg.): MCCM08’: Proceedings of 1st
International Workshop on Model Co-Evolution and Consistency Management, 2008
[Hec06]
Heckel, R.: Graph Transformation in a Nutshell. In: Electronic Notes
in Theoretical Computer Science 148 (2006), Nr. 1, S. 187–198. – ISSN
15710661
[KDRPP09] Kolovos, Dimitrios S. ; Di Ruscio, Davide ; Pierantonio, Alfonso ;
Paige, Richard F.: Different models for model matching: An analysis of
approaches to support model differencing. In: CVSM ’09: Proceedings of the
2009 ICSE Workshop on Comparison and Versioning of Software Models,
IEEE Computer Society, 2009. – ISBN 978–1–4244–3714–6, S. 1–6
[Kel09]
Kelter, Udo: Lehrmodul Dokumentdifferenzen. 2009
[Kel10a]
Kelter, Udo: Lehrmodul Modellierung graphartiger Dokumente. 2010
[Kel10b]
Kelter, Udo: Pseudo-Modelldifferenzen und die Phasenabhängigkeit von
Metamodellen. In: Engels, Gregor (Hrsg.) ; Luckey, Markus (Hrsg.) ;
Schäfer, Wilhelm (Hrsg.): Software Engineering Bd. 159, GI, 2010 (LNI).
– ISBN 978–3–88579–253–6, 117-128
[KGE10]
Küster, Jochen ; Gerth, Christian ; Engels, Gregor: Dynamic Computation of Change Operations in Version Management of Business Process
Models. In: Kühne, Thomas (Hrsg.) ; Selic, Bran (Hrsg.) ; Gervais,
Marie-Pierre (Hrsg.) ; Terrier, François (Hrsg.): Modelling Foundations
and Applications Bd. 6138. Springer, 2010, S. 201–216
82
LITERATURVERZEICHNIS
[KS08]
Kelter, Udo ; Schmidt, Maik: Comparing state machines. In: Proceedings of the 2008 international workshop on Comparison and versioning of
software models, ACM, 2008 (CVSM ’08). – ISBN 978–1–60558–045–6, S.
1–6
[KSW08]
Kelter, Udo ; Schmidt, Maik ; Wenzel, Sven: Architekturen von Differenzwerkzeugen für Modelle. In: Herrmann, Korbinian (Hrsg.) ; Brügge,
Bernd (Hrsg.): Software Engineering 2008. Fachtagung des GI-Fachbereichs
Softwaretechnik, 18.-22.2.2008 in München Bd. 121, GI, 2008 (LNI). –
ISBN 978–3–88579–215–4, S. 155–168
[Kö09]
Könemann, Patrick: Model-independent differences. In: CVSM ’09: Proceedings of the 2009 ICSE Workshop on Comparison and Versioning of
Software Models, IEEE Computer Society, 2009. – ISBN 978–1–4244–3714–
6, S. 37–42
[Kö10]
Könemann, Patrick: Semantic grouping of model changes. In: IWMCP
’10: Proceedings of the 1st International Workshop on Model Comparison
in Practice, ACM, 2010. – ISBN 978–1–60558–960–2, S. 50–55
[MBT10a]
MBT2, Projektgruppe: Benutzeroperationen für Matlab/Simulink. 2010.
– Bericht der Projektgruppe Modellbasiertes Testen 2, Universität Siegen,
Praktische Informatik
[MBT10b]
MBT2, Projektgruppe: Benutzeroperationen für UML-Klassendiagramme.
2010. – Bericht der Projektgruppe Modellbasiertes Testen 2, Universität
Siegen, Praktische Informatik
[MGMR02] Melnik, S. ; Garcia-Molina, H. ; Rahm, E.: Similarity flooding: a versatile graph matching algorithm and its application to schema matching.
In: Data Engineering, 2002. Proceedings. 18th International Conference on,
2002, 117–128
[OMG07]
OMG: UML 2.1.2 Superstructure Specification. http://www.omg.org/
spec/UML/2.1.2/Superstructure/. Version: 2007
[OMG10]
OMG: Essential Meta-Object Facility Specification (EMOF). http://www.
omg.org/mof/http://www.omg.org/mof/. Version: 2010
LITERATURVERZEICHNIS
83
[RPKP09]
Rose, Louis M. ; Paige, Richard F. ; Kolovos, Dimitrios S. ; Polack,
Fiona A.: An Analysis of Approaches to Model Migration. In: Proc. Models
and Evolution (MoDSE-MCCM) Workshop, 2009
[RV08]
Rivera, José E. ; Vallecillo, Antonio: Representing and Operating with
Model Differences. In: Aalst, Will (Hrsg.) ; Mylopoulos, John (Hrsg.)
; Sadeh, Norman M. (Hrsg.) ; Shaw, Michael J. (Hrsg.) ; Szyperski,
Clemens (Hrsg.) ; Paige, Richard F. (Hrsg.) ; Meyer, Bertrand (Hrsg.):
Objects, Components, Models and Patterns Bd. 11. Springer, 2008. – ISBN
978–3–540–69824–1, S. 141–160
[TELW10]
Taentzer, Gabriele ; Ermel, Claudia ; Langer, Philip ; Wimmer, Manuel: Conflict Detection for Model Versioning Based on Graph Modifications.
In: ICGT ’10: Proceedings of Int. Conference on Graph Transformation,
2010
[Wac07]
Wachsmuth, Guido: Metamodel Adaptation and Model Co-adaptation.
In: Ernst, Erik (Hrsg.): Proceedings of the 21st European Conference on
Object-Oriented Programming (ECOOP’07) Bd. 4609, Springer, 2007 (Lecture Notes in Computer Science), 600-624
[Wie10]
Wierse, Gerd: A Catalog of Modeling Patterns for the Unified Modeling Language, From the Perspective of Model-Driven Software Development with AndroMDA / Philipps-Universität Marburg. Version: 2010.
http://www.uni-marburg.de/fb12/swt/forschung/wierse10tr. 2010. –
Forschungsbericht
A BTS-Adaption für
UML-Klassendiagramme
Tabelle A.1: UML-Adaption des Basis-Transformationssystems: Pakete
Regel-Template
Parameter-Bindungen
PD
1
<addElement>
2:<Metaclass> 7→ Package
-
2
<removeElement>
2:<Metaclass> 7→ Package
-
3
<setMetaProperty>
2:<Metaclass> 7→ Package
3:<Metaclass> 7→ Package
<metaProperty> 7→ *
-
4
<globalMove>
2:<Metaclass> →
7 Package
3:<Metaclass> →
7 Package
-
Tabelle A.2: UML-Adaption des Basis-Transformationssystems: Attribute
Regel-Template
Parameter-Bindungen
PD
9
<addElement>
2:<Metaclass> 7→ Property
-
10
<removeElement>
2:<Metaclass> 7→ Property
-
11
<setMetaProperty>
2:<Metaclass> 7→ Property
3:<Metaclass> 7→ Property
<metaProperty> 7→ *
-
12
<globalMove>
2:<Metaclass> 7→ Property
3:<Metaclass> 7→ Property
-
13
<changeType>
14
<setMetaProperty>
3:<Metaclass> 7→ Property
4:<Metaclass> 7→ Property
<type> 7→ type
2:<Metaclass> →
7 LiteralInteger
3:<Metaclass> →
7 LiteralInteger
85
-
-
86
ANHANG
<metaProperty> 7→ value
15
<setMetaProperty>
2:<Metaclass> 7→ LiteralUnlimitedNatural
3:<Metaclass> 7→ LiteralUnlimitedNatural
<metaProperty> 7→ value
-
Tabelle A.3: UML-Adaption des Basis-Transformationssystems: Operationen
Regel-Template
Parameter-Bindungen
PD
16
<addElement>
2:<Metaclass> 7→ Operation
-
17
<removeElement>
2:<Metaclass> 7→ Operation
-
18
<setMetaProperty>
2:<Metaclass> 7→ Operation
3:<Metaclass> 7→ Operation
3:<metaProperty> 7→ *
-
19
<globalMove>
2:<Metaclass> →
7 Operation
3:<Metaclass> →
7 Operation
PD.M(class)
20
<addElement>
2:<Metaclass> 7→ Parameter
21
<removeElement>
2:<Metaclass> 7→ Parameter
22
<changeType>
3:<Metaclass> 7→ Parameter
4:<Metaclass> 7→ Parameter
<type> 7→ type
-
23
<localMove>
2:<Metaclass> 7→ Parameter
3:<Metaclass> 7→ Parameter
<referenceType> 7→ ownedParameter
-
Tabelle A.4: UML-Adaption des Basis-Transformationssystems: Assoziationen
Regel-Template
Parameter-Bindungen
k
24
=
p:<Metaclass> 7→ Association
(
<addCompositeElement>
m
=
c:<Metaclass> 7→ Property
<referenceType> 7→ memberEnd
16
E.1.b(memberEnd)
PD
n
16
ANHANG
87
k
25
=
n
p:<Metaclass> 7→ Association
(
<removeComp.Element>
m
=
c:<Metaclass> 7→ Property
-
<referenceType> 7→ association
26
<setMetaProperty>
2:<Metaclass> 7→ Association
3:<Metaclass> 7→ Association
<metaProperty> 7→ *
-
27
<setMetaProperty>
2:<Metaclass> 7→ Property
3:<Metaclass> 7→ Property
<metaProperty> 7→ *
-
28
<globalMove>
2:<Metaclass> →
7 Property
3:<Metaclass> →
7 Property
<changeType>
3:<Metaclass> 7→ Property
4:<Metaclass> 7→ Property
<type> 7→ type
29
17 18
-
Tabelle A.5: UML-Adaption des Basis-Transformationssystems: Dependencies
30
31
Regel-Template
Parameter-Bindungen
PD
<addElement>
<removeElement>
2:<Metaclass> →
7 Dependency
2:<Metaclass> →
7 Dependency
E.2.a(clientDependency)
-
Tabelle A.6: UML-Adaption des Basis-Transformationssystems: Generalisierungen
32
33
17
18
Regel-Template
Parameter-Bindungen
PD
<addElement>
<removeElement>
2:<Metaclass> →
7 Generalization
2:<Metaclass> →
7 Generalization
E.1.b(general)
-
PD.M(class)
PD.M(owningAssociation)
88
ANHANG
Tabelle A.7: UML-Adaption des Basis-Transformationssystems: Datentypen
34
Regel-Template
Parameter-Bindungen
PD
<addElement>
2:<Metaclass> 7→ Datatype
E.1.b(type)
k
=
n
p:<Metaclass> 7→ Datatype
(
35
<removeComp.Element>
m1
=
<referenceType> 7→ client
(
m2
c:<Metaclass> 7→ Dependency
=
c:<Metaclass> 7→ Dependency
<referenceType> 7→ supplier
Tabelle A.8: UML-Adaption des Basis-Transformationssystems: Enumerationen
36
Regel-Template
Parameter-Bindungen
PD
<addElement>
2:<Metaclass> 7→ Enumeration
E.1.b(type)
k
=
n
p:<Metaclass> 7→ Enumeration
(
37
<removeComp.Element>
m1
=
<referenceType> 7→ client
(
m2
c:<Metaclass> 7→ Dependency
=
-
c:<Metaclass> 7→ Dependency
<referenceType> 7→ supplier
38
<addElement>
2:<Metaclass> 7→ EnumerationLiteral
-
39
<removeElement>
2:<Metaclass> 7→ EnumerationLiteral
-
40
<setMetaProperty>
2:<Metaclass> 7→ Enumeration
3:<Metaclass> 7→ Enumeration
<metaProperty> 7→ *
-
41
<setMetaProperty>
2:<Metaclass> 7→ EnumerationLiteral
3:<Metaclass> 7→ EnumerationLiteral
<metaProperty> 7→ *
-
B Matlab/Simulink-Metamodell
Abbildung B.1: Matlab/Simulink-Metamodell: Blöcke und Konnektionen
Abbildung B.2: Matlab/Simulink-Metamodell: Einbettung von Subsystemen
89
C BTS-Adaption für Matlab/Simulink
Tabelle C.1: BTS-Adaption für Matlab/Simulink
Op.
Regel-Template
Parameter-Bindungen
k
=
n
p:<Metaclass> 7→ SimulinkBlock
(
m1
1
c:<Metaclass> 7→ Property
=
<referenceType> 7→ properies
(
<addCompositeElement>
m2
c:<Metaclass> 7→ InPort
=
<referenceType> 7→ inPorts
(
m3
c:<Metaclass> 7→ OutPort
=
<referenceType> 7→ outPorts
2
<removeElement>
2:<Metaclass> 7→ SimulinkBlock
3
<setMetaProperty>
2:<Metaclass> 7→ SimulinkBlock
3:<Metaclass> 7→ SimulinkBlock
<metaProperty> 7→ position
4
<setMetaProperty>
2:<Metaclass> 7→ Property
3:<Metaclass> 7→ Property
<metaProperty> 7→ *
5
<addElement>
2:<Metaclass> 7→ InPort
6
<removeElement>
2:<Metaclass> 7→ InPort
7
<setMetaProperty>
2:<Metaclass> 7→ OutPort
3:<Metaclass> 7→ OutPort
<metaProperty> 7→ name
91
PD
92
ANHANG
k
8
=
n
p:<Metaclass> 7→ Connection
(
<addCompositeElement>
m
=
c:<Metaclass> 7→ BendPoint
19 20
<referenceType> 7→ bendPoints
9
<removeElement>
2:<Metaclass> 7→ Connection
<setMetaProperty>
2:<Metaclass> 7→ BendPoint
3:<Metaclass> 7→ BendPoint
<metaProperty> 7→ position
2:<Metaclass> 7→ BendPoint
2:<Metaclass> 7→ BendPoint
10
<addElement>
<removeElement>
21
11
19
<changeType>
3:<Metaclass> 7→ Connection
4:<Metaclass> 7→ Connection
<type> 7→ targetPorts
E.1.b(sourcePort)
E.1.b(targetPorts)
21
Knoten 1 ist hier in Abweichung zum Regel-Template vom allgemeineren Typ ReferenceChange.
20
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig unter ausschließlicher Nutzung der angegebenen Quellen und Hilfsmittel angefertigt habe. Alle Stellen,
die wörtlich oder sinngemäß aus Veröffentlichungen entnommen wurden, sind als solche
gekennzeichnet.
Diese Arbeit lag in gleicher oder ähnlicher Weise noch keiner Prüfungsbehörde vor und
wurde bisher noch nicht veröffentlicht.
Siegen, den 21. Dezember 2010
Timo Kehrer