Wiederverwendung von Metamodellen in ModelJoin-Sichten · und Datenorganisation(IPD) Erstgutachter: Prof. Dr. Ralf H. Reussner Zweitgutachter: Prof. Dr. Walter F. Tichy Betreuender

Wiederverwendung von Metamodellenin ModelJoin-Sichten

Diplomarbeit

Aleksandar Toshovski

An der Fakultät für InformatikInstitut für Programmstrukturen

und Datenorganisation(IPD)

Erstgutachter: Prof. Dr. Ralf H. ReussnerZweitgutachter: Prof. Dr. Walter F. TichyBetreuender Mitarbeiter: Dipl.-Inform. Erik BurgerZweiter betreuender Mitarbeiter: Dipl.-Inform. Jörg Henß

Bearbeitungszeit: 16. Januar 2013 – 15. Juli 2013

KIT – Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu

Ich versichere wahrheitsgemaß, die Arbeit selbststandig angefertigt, alle benutzten Hilfs-mittel vollstandig und genau angegeben und alles kenntlich gemacht zu haben, was ausArbeiten anderer unverandert oder mit Abanderungen entnommen wurde.

14.07.2013, Karlsruhe

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .(Aleksandar Toshovski)

Danksagung

An dieser Stelle mochte ich all jenen danken, die durch ihre fachliche und personlicheUnterstutzung zum Gelingen dieser Diplomarbeit beigetragen haben.

Ich bedanke mich bei Herrn Prof. Dr. Ralf H. Reussner fur das Bereitstellen diesesinteressanten Themas der Diplomarbeit.

Namentlich erwahnt sei dabei in erster Linie mein Betreuer, Diplom-Inf. Erik Burger,der durch seine vielen wertvollen Anregungen im Rahmen gemeinsamer Diskussionen undseine standige Hilfsbereitschaft sehr zur Entstehung dieser Arbeit beigetragen hat. Ichbedanke mich bei Jorg Henß fur seine Teilnahme im Code- und Architekturreview. Auchgenannt seien ausnahmslos alle Mitarbeiter der Lehrstuhl Software Design und Quality,die das Forschen und Arbeiten in einem sehr angenehmen Klima ermoglicht haben.

Mein besonderer Dank gilt meiner Familie, insbesondere meinen Eltern, die mir wahrendmeines Studiums und der Erstellung dieser Diplomarbeit stets den fur mich so wichtigenRuckhalt gegeben haben. Ihre großzugige Unterstutzung und fortwahrende Motivierunghat maßgeblich zum erfolgreichen Gelingen meines Studiums beigetragen.

Herzlich bedanken mochte ich mich auch bei meiner Freundin, die mich immer wiederermutigte und mich wahrend des Studiums unterstutzte.

v

Inhaltsverzeichnis

1. Einleitung 31.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Wissenschaftliche Vorgehensweise und Struktur der Arbeit . . . . . . . . . . 5

2. Grundlagen und Stand der Technik 72.1. Theoretische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2. Modelle und Metamodelle . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2.1. Meta-Object Facility . . . . . . . . . . . . . . . . . . . . . 92.1.2.2. Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . 10

2.2. ModelJoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2. Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1. Metamodel Reuse with MOF . . . . . . . . . . . . . . . . . . . . . . 142.3.2. Virtual Composition of EMF Models . . . . . . . . . . . . . . . . . . 142.3.3. UML Konsistenzuberprufung . . . . . . . . . . . . . . . . . . . . . . 142.3.4. Prozessmodell fur halbautomatische Co-Evolution . . . . . . . . . . 152.3.5. Konformitatsbedingungen nach Burger und Gruschko . . . . . . . . 172.3.6. Eclipse EMF Edapt . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.7. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4. Berechnung eines Diffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.1. EMF Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.2. EMF Diff/Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.3. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5. Metamodell Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.1. Dateibasierte Repository . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.2. Eclipse CDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.3. Eclipse Teneo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.4. EMFStore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.5. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6. Regelbasierte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3. Anforderungen an das Verfahren 253.1. Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1. Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 263.2.3. Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 27

vii

viii Inhaltsverzeichnis

4. Losungsansatz 294.1. Voruberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2. Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1. Metamodell Repository . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.2. Diff Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.3. Konformitatsbedingungen . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.3.1. Regeln fur Existenzanderungen . . . . . . . . . . . . . . . . 324.2.3.2. Anderung einer Eigenschaft . . . . . . . . . . . . . . . . . . 35

4.3. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4. Integration in ModelJoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5. Prototypische Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5.1. Kern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.5.2. Benutzeroberflache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.3. Integration in ModelJoin . . . . . . . . . . . . . . . . . . . . . . . . 48

5. Validierung des Konzepts 515.1. Edapt Test-Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.1. Strukturelle primitive Anderungen . . . . . . . . . . . . . . . . . . . 525.1.2. Nicht-strukturelle primitive Anderungen . . . . . . . . . . . . . . . . 535.1.3. Spezialisierungs-/Generalisierungsanderungen . . . . . . . . . . . . . 535.1.4. Vererbungsanderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.5. Delegierte Anderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 555.1.6. Austausch von Typen . . . . . . . . . . . . . . . . . . . . . . . . . . 565.1.7. Verschmelzung- und Trennanderungen . . . . . . . . . . . . . . . . . 575.1.8. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2. Weitere Test-Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.3. Palladio Evaluierungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . . 615.4. Validierung von den Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 64

6. Fazit und Ausblick 67

Anhang 69A. EMFCompare Tipps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69B. EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70C. Code-Snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77D. Implementierte Konformitatsbedingungen mit drools . . . . . . . . . . . . . 80E. Installation und Gebrauchsanleitung . . . . . . . . . . . . . . . . . . . . . . 85

E.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85E.2. Gebrauchsanleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

E.2.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86E.2.2. GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Literaturverzeichnis 87

viii

Abkurzungsverzeichnis

KIT Karlsruher Institut fur Technologie

SQL Structured Query Language

DSL Domain Specific Language

EMF Eclipse Modeling Framework

MOF Meta-Object Facility

UI User Interface

MDSD Model-Driven Software Development

EMOF Essential Meta-Object Facility

CMOF Complete Meta-Object Facility

GEF Graphical Editing Framework

OMG Object Management Group

SWT Standard Widget Toolkit

JMI Java Metadata Interface

XMI XML Metadata Interchange

XML Extensible Markup Language

UML Unified Modeling Language

HQL Hibernate Query Language

EJB-QL Enterprise Java Beans Query Language

JPA Java Persistence API

ix

Tabellenverzeichnis

2.1. Vergleich zwischen EMF Diff/Merge und EMF Compare . . . . . . . . . . 212.2. Vergleich zwischen Datei Repository, Eclipse CDO, EMFStore und Eclipse

Teneo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3. Vergleich zwischen JESS und Drools . . . . . . . . . . . . . . . . . . . . . . 24

5.1. Strukturelle primitive Anderungen nach [HVW11] . . . . . . . . . . . . . . 525.2. Nicht-strukturelle primitive Anderungen . . . . . . . . . . . . . . . . . . . . 535.3. Spezialisierungs-/Generalisierungsanderungen . . . . . . . . . . . . . . . . . 545.4. Vererbungsanderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5. Delegierte Anderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.6. Austausch von Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.7. Verschmelzung- und Trennanderung . . . . . . . . . . . . . . . . . . . . . . 575.8. Validierung den Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 65

B.1. ECore Anderungen nach [BGGK07], die nach [Gru07] kategorisiert sindQuelle: [Gru07] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

B.2. MOF 1.4 Non-Breaking Anderungen nach [BG10] . . . . . . . . . . . . . . 77

xi

Abbildungsverzeichnis

1.1. Beispiel der Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Schematische Darstellung der Gliederung der Diplomarbeit . . . . . . . . . 6

2.1. ModelJoin Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2. KIT-Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Amazon-Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4. Ziel-Metamodell: BookCollection Library . . . . . . . . . . . . . . . . . . . 13

2.5. RIDE Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6. Migration Prozess Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.7. EMF Compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1. Konzept Ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2. IDiff Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3. Beispiel: Konformitatsverletzung bem Loschen einer Klasse . . . . . . . . . 33

4.4. Beispiel: Konformitatsverletzung bem Hinzufugen von einem Attribut . . . 34

4.5. Beispiel: Konformitatsverletzung beim Loschen von einem Attribut . . . . . 34

4.6. Beispiel: Konformitatsverletzung beim Loschen von einem EEnumLiteral . 36

4.7. Beispiel: Konformitatsverletzung beim Andern von eOpposite . . . . . . . . 39

4.8. UML-Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.9. ModelJoin Architektur. Quelle: modifizierte Version von [BHS+13] . . . . . 42

4.10. UML-Klassendiagramm von dem Kern . . . . . . . . . . . . . . . . . . . . . 43

4.11. Sequenzdiagramm: Arbeitsablauf einer Konformitatsuberprufung . . . . . . 45

4.12. UML-Klassendiagramm von der Benutzeroberflache . . . . . . . . . . . . . . 46

4.13. Metamodel View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.14. Status Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.15. Einstellungen: Compliance Validator . . . . . . . . . . . . . . . . . . . . . . 48

4.16. Package Explorer Context Menu . . . . . . . . . . . . . . . . . . . . . . . . 48

4.17. Extension Point Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1. Pull up Feature: Verschiebe ein Attribut zu einer Superklasse . . . . . . . . 55

5.2. Fold Super Class: Eine Klasse zu einer Superklasse . . . . . . . . . . . . . . 55

5.3. Beispiel: Split Reference by Type . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4. Szenario 1: Verschiebe ein Pflichtattribut zu einer Superklasse . . . . . . . . 58

5.5. Szenario 2: Verschiebe eine Pflichtreferenz zu einer Superklasse . . . . . . . 58

5.6. Szenario 3: Losche eine Klasse und verschiebe alle Attributen zu den Un-terklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.7. Szenario 4: Generalisierung umkehren . . . . . . . . . . . . . . . . . . . . . 59

5.8. Szenario 5: Generalisierung umkehren . . . . . . . . . . . . . . . . . . . . . 60

5.9. Szenario 6: Hierarchie von den Supertypen andern . . . . . . . . . . . . . . 60

5.10. Szenario 7: Verschiebe ein Attribut zu einer Superklasse . . . . . . . . . . . 60

xiii

xiv Abbildungsverzeichnis

5.11. Sensor Network Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.12. Das erzeugte Zielmetamodell. Quelle: [BHS+13] . . . . . . . . . . . . . . . . 625.13. Das neue Zielmetamodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

B.1. EMF Diff/Merge Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70B.2. ECore Version 2.1 Struktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B.3. EMFCompare UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

xiv

Listings

2.1. ModelJoin Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1. ReferenceChange EClass: delete . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. ReferenceChange Attribute: add . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3. ReferenceChange Attribute: delete . . . . . . . . . . . . . . . . . . . . . . . 34

4.4. ReferenceChange EReference: add . . . . . . . . . . . . . . . . . . . . . . . 34

4.5. ReferenceChange EReference: delete . . . . . . . . . . . . . . . . . . . . . . 35

4.6. ReferenceChange EReference: move . . . . . . . . . . . . . . . . . . . . . . 35

4.7. ReferenceChange EEnumLiteral: delete . . . . . . . . . . . . . . . . . . . . 35

4.8. PropertyChange ENamedElement: name . . . . . . . . . . . . . . . . . . . . 36

4.9. PropertyChange EPackage: nsURI . . . . . . . . . . . . . . . . . . . . . . . 36

4.10. PropertyChange EPackage: nsPrefix . . . . . . . . . . . . . . . . . . . . . . 36

4.11. PropertyChange ETypedElement unique . . . . . . . . . . . . . . . . . . . . 37

4.12. PropertyChange ETypedElement: lower bound . . . . . . . . . . . . . . . . 37

4.13. PropertyChange ETypedElement: upper bound . . . . . . . . . . . . . . . . 37

4.14. PropertyChange ETypedElement: eType . . . . . . . . . . . . . . . . . . . 37

4.15. PropertyChange EStructuralFeature: volatile . . . . . . . . . . . . . . . . . 37

4.16. PropertyChange EStructuralFeature: transient . . . . . . . . . . . . . . . . 38

4.17. PropertyChange EStructuralFeature: unsettable . . . . . . . . . . . . . . . 38

4.18. PropertyChange EStructuralFeature: derived . . . . . . . . . . . . . . . . . 38

4.19. PropertyChange EReference: containment . . . . . . . . . . . . . . . . . . . 38

4.20. PropertyChange EReference: eOpposite . . . . . . . . . . . . . . . . . . . . 39

4.21. PropertyChange EAttribute: id . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.22. PropertyChange EClass: abstract . . . . . . . . . . . . . . . . . . . . . . . . 39

4.23. PropertyChange EClass: interface . . . . . . . . . . . . . . . . . . . . . . . 39

4.24. ReferenceChange EClass: supertype . . . . . . . . . . . . . . . . . . . . . . 40

4.25. ModelJoin Extension Point . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1. ModelJoin-Query. Quelle: [BHS+13] . . . . . . . . . . . . . . . . . . . . . . 62

5.2. Die hinzugefugten Elemente in der ModelJoin-Query. . . . . . . . . . . . . . 63

6.1. EMFCompare: Uberprufung der Differenz zwischen zwei ECore Modelle . . 69

6.2. EMFCompare: Filter zur Ignorierung von strukturelle Anderungen . . . . . 70

6.3. Uberprufung von der Untergrenze einer Referenz oder einem Attribut . . . 77

6.4. Uberprufung, ob ein Feature zu einem Supertyp verschoben ist . . . . . . . 77

6.5. Uberprufung, ob eine Klasse abstrakt ist. . . . . . . . . . . . . . . . . . . . 78

6.6. Uberprufung, ob die gelosche Elemente nicht abstrakte Klassen enthalten . 78

6.7. Uberprufung von der Untergrenze von den Supertypen . . . . . . . . . . . . 79

6.8. Uberprufung der geloschten Element . . . . . . . . . . . . . . . . . . . . . . 80

6.9. AttributeChange EAttribute id . . . . . . . . . . . . . . . . . . . . . . . . . 80

xv

xvi Listings

6.10. AttributeChange EClass abstract . . . . . . . . . . . . . . . . . . . . . . . . 806.11. AttributeChange EClass interface . . . . . . . . . . . . . . . . . . . . . . . . 816.12. ReferenceChange EClass add Attribute/Reference . . . . . . . . . . . . . . 816.13. EClass remove Attribute/Reference . . . . . . . . . . . . . . . . . . . . . . . 816.14. ReferenceChange EClass add Supertype . . . . . . . . . . . . . . . . . . . . 816.15. ReferenceChange EClass delete Supertype . . . . . . . . . . . . . . . . . . . 816.16. ReferenceChange EEnum delete literal . . . . . . . . . . . . . . . . . . . . . 826.17. AttributeChange ENamedElement . . . . . . . . . . . . . . . . . . . . . . . 826.18. AttributeChange EPackage nsURI . . . . . . . . . . . . . . . . . . . . . . . 826.19. AttributeChange EPackage nsPrefix label . . . . . . . . . . . . . . . . . . . 826.20. ReferenceChange eClassifier delete EClass/EENum/EDataType . . . . . . . 826.21. ReferenceChange eClassifier move EClass/EENum/EDataType . . . . . . . 836.22. AttributeChange EReference containment . . . . . . . . . . . . . . . . . . . 836.23. AttributeChange EReference eOpposite . . . . . . . . . . . . . . . . . . . . 836.24. EStructuralFeature volatile . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.25. EStructuralFeature transient . . . . . . . . . . . . . . . . . . . . . . . . . . 836.26. EStructuralFeature unsettable . . . . . . . . . . . . . . . . . . . . . . . . . . 846.27. EStructuralFeature derived . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.28. EStructuralFeature eContainingClass . . . . . . . . . . . . . . . . . . . . . . 846.29. AttributeChange ETypedElement unique . . . . . . . . . . . . . . . . . . . 846.30. AttributeChange ETypedElement lower bound . . . . . . . . . . . . . . . . 846.31. AttributeChange ETypedElement upper bound . . . . . . . . . . . . . . . . 856.32. AttributeChange ETypedElement eType . . . . . . . . . . . . . . . . . . . . 85

xvi

Kurzfassung

Die modellgetriebene Softwareentwicklung wird immer ofter nicht nur in der Forschung,sondern auch in der Praxis verwendet. Die Entwickler treffen oft das Problem, dass dieInformation in mehreren Instanzen auf unterschiedliche Metamodellen verteilt sind. DasFramework ModelJoin erlaubt eine rapide und losgekoppelte Entwicklung von Sichten die-ser Metamodellen und Instanzen mit der Hilfe einer SQL-ahnlichen Sprache. Um die Mo-dellierung von Sichten effizienter zu machen, wird eine Wiederverwendung dieser Sichtengebraucht, um sie mit variierenden Instanzen verwendet werden konnen.

Im Rahmen dieser Arbeit wird eine Konzeption zur Wiederverwendung von Metamodellenin ModelJoin-Sichten aufgestellt. Um das zu erreichen, wird uberpruft, ob das neu gene-rierte Metamodell mit einem anderen konform ist. Diese Konformitat wird mit der Hilfevon Regeln uberpruft. Die Konformitat wird auf eine Differenzebene definiert. Jede ein-fache Anderung wird mittels der Regel uberpruft. Die definierten Regeln basieren auf derKlassifizierung von [BGGK07] und [BG10]. Dabei wird auch eine technologieunabhangigeArchitektur vorgestellt.

Als Referenzimplementierung wird die Architektur in der Form von Eclipse Plug-Ins er-stellt. Die Regeln werden mit der Hilfe von regelbasierten Systemen implementiert undausgefuhrt. Da die Regeln auf Differenzebene die Uberprufung machen, wird auch ein Fra-mework zur Berechnung dieser Differenz. Mit der Hilfe von Anwendungszenarien werdendie Regeln uberpruft, ob sie stimmen. Zusatzlich wird den Ansatz mit den definierten in[HVW11] Operationen validiert.

Der Beitrag dieser Arbeit ist eine automatische Berechnung der Kompabilitat von einemMetamodell mit einem anderen. Fur die prototypische Entwicklung wird EMFComparezur Berechnung der Differenz und fur die Regeln wird das Rahmenwerk drools verwendet.

Schlusselworter: metamodellgetriebene Softwareentwicklung, Wiederverwendung, Mo-delJoin, Regeln, Konformitatsuberprufung

1

1. Einleitung

In der modellgetriebenen Softwareentwicklung treffen die Entwickler in der Praxis oftdas Problem, dass die Informationen uber mehrere heterogene Metamodelle verteilt sind[BE09]. In den meisten Fallen uberdecken sich diese Informationen semantisch aber siesind nicht strukturell identisch [BHS+13]. Dieses Problem tritt oft auf, wenn mehrereEntwickler am gleichen Projekt verteilt arbeiten.

Dabei wird aktuell das eclipse-basierte Tool ModelJoin vom Lehrstuhl fur Software-Entwurf und -Qualitat am Karlsruher Institut fur Technologie (KIT) entwickelt, mit demheterogene Metamodelle und Instanzen mit Hilfe einer textuellen, SQL-ahnlichen DomainSpecific Language (DSL) verschmolzen werden konnen. So konnen angepasste Sichten furEntwickler erstellt werden. Die Interpretation eines ModelJoin-Ausdrucks liefert ein neuesZiel-Metamodell sowie die verschmolzenen Instanzen der Eingabe-Metamodelle. Auf dieseWeise kann der Entwickler mit der Hilfe von ModelJoin sehr schnell Sichten erstellen,ohne ein Metamodell zu spezifizieren oder manuell zu transformieren. Außerdem bleibendie Eingabe-Metamodelle lose gekoppelt. Das bedeutet, dass es keine direkten Referenzenzwischen den Metamodellen besteht Bei einer erneuten Evaluierung eines Ausdrucks wirdein neues Ziel-Metamodell generiert. Im Ziel-Metamodell werden die Eingabe-Metamodellemit der Hilfe von Annotationen referenziert. Fur eine bessere Wiederverwendbarkeit einerModelJoin-Anfrage ist es jedoch notig, dass ein existierendes Metamodell als Ziel verwen-det werden kann [BHS+13].

Die traditionelle Anpassung von Metamodellen ist immer gut geplant, so dass es eine Kon-formitat mit den alten Instanzen existiert. Im Gegensatz dazu hat ein ModelJoin-Artefaktein kurzer Evolutionszyklus und die Sichten werden sehr oft geandert und angepasst. Dasgeneriert unnotig viele Metamodellen.

Die derzeitige Version von ModelJoin unterstutzt die Persistierung von den generiertenZiel-Metamodellen nicht. Bei jeder Anderung der Anfrage wird ein neues Metamodellgeneriert und kann nicht wiederverwendet werden [BHS+13]. Herrmannsdoerfer, Benzand Juergens zeigen in einer Studie, dass mehr als die Halfte von den Anderungen einesMetamodells betreffen die Modells nicht und diese mussen nicht migriert werden [HBJ08].Das erlaubt eine Wiederverwendung von den alten Metamodellen.

Eine andere Anwendung diesem Ansatz ware die Anpassung von ModelJoin-Queries bisein gewunschtes Metamodell erreicht wird. In diesem Fall werden die Instanzen auf Mo-

3

4 1. Einleitung

dellebene fur das Metamodell vorbereitet werden. Das wird zur Zeit von ModelJoin nichtunterstutzt.

1.1. Motivation

Als Beispiel werden zwei eigenerstellte Metamodelle genommen – namlich KIT-Library(Abbildung 2.2) und Amazon(Abbildung 2.3). Sie werden zur Illustration der Problema-tik verwendet und sind keine echte Anwendungsfalle. Das erste Metamodell beschreibtdie Bibliothek an der Universitat Karlsruhe. Das zweite - Amazon ist eine Online-Verkaufsplattform, wobei hier nur der Bucherverkauf betrachtet wird. Beide sind mit-tels EMF modelliert und werden mittels ModelJoin verschmolzen. Aus zwei ahnlichenModelJoin-Queries, werden zwei Metamodelle generiert. Sie sind auf Abbildung 1.1 dar-gestellt. Der Unterschied zwischen den beiden Metamodellen ist, dass Ziel-MetamodellB keine ausgehende Referenz nach der Klasse Review hat. In diesem Fall kann das Ziel-Metamodell A auch in den zweiten ModelJoin-Query verwendet werden kann, da allemogliche Modelle von Metamodell B mit Metamodell A konform sind. Das Metamodell Akann von der zweiten Sicht wiederverwendet werden.

BookCollectiontitle: Stringlanguage: String

Reviewrating: int

1 0..*has

Authorname: String

*

1

Ziel-Metamodell ABookCollection

title: Stringlanguage: String

Authorname: String

*

1

Ziel-Metamodell B

BC1:BookCollectiontitle = The Hitchhiker's Guide to the Galaxylanguage = English

R1:Reviewrating = 5

name = Douglas AdamsA:Author

R2:Reviewrating = 4



M2

M1

Abbildung 1.1.: Beispiel der ProblemstellungQuelle: Eigene Darstellung

Wie bei der Metamodellmodellierung, enthalt die ModelJoin-Querymodellierung evolutio-nare Anderungen und Anpassungen. Die generierten Metamodellen werden bereits vonAnwendungen verwendet und eine Anderung des Metamodells erfordert auch die Anpas-sung der Anwendung. Das obengeschriebene Beispiel hat gezeigt, dass es Falle existieren,wo die Erstellung von einem neuen Ziel-Metamodell nicht notig ist. Um das zu vermeiden,ist eine Wiederverwendung von Ziel-Metamodellen in ModelJoin ersichtlich.

1.2. Zielsetzung

Das Ziel dieser Arbeit ist die Konzeption und die prototypische Implementierung einer Me-thodik zur Uberprufung der Wiederverwendbarkeit von Ziel-Metamodellen in ModelJoin-Sichten. Der Schwerpunkt dieser Aussarbeitung ist die Uberprufung eines ModelJoin-Fragment, ob es bereits ein konformes Metamodell in einer Metamodell-Repository exi-stiert. Um das zu uberprufen, wird die Differenz zwischen zwei Metamodellen berechnet.

4

1.3. Wissenschaftliche Vorgehensweise und Struktur der Arbeit 5

Dann wird die Differenz nach Konformitat uberpruft. Dabei sollen Bedingungen definiertwerden, die diese Konformitat zwischen den Metamodellen uberprufen. Sie werden in derForm von Regeln dargestellt. Wenn es ein konformes Metamodell existiert, dann wirddieses wiederverwendet. Um diese Methodik zu validieren, wird das Konzept prototy-pisch implementiert. Dabei wird ein Vorschlag gegeben, wie das Konzept dieser Arbeit inModelJoin integriert werden kann.

Aus dieser Zielsetzung werden die folgenden Teilaufgaben abgeleitet:

• Erstellung einer generischen Architektur

• Definition von Konformitatsbedungungen zur Kompatibilitatsuberprufung von Me-tamodellen

• Prototypische Entwicklung der Methodik

– Implementierung der generischen Architektur

– Auswahl einer Metamodell-Repository

– Auswahl eines Werkzeugs zur Berechnung von Differenz zweier Metamodellen

– Integration der Methodik in ModelJoin als Eclipse-Plugin

• Validierung der Methodik mittels Tests

1.3. Wissenschaftliche Vorgehensweise und Struktur der Ar-beit

Das Losungskonzept der oben beschriebenen Problemstellung wird nach dem Verfahren von[RA79] erarbeitet. Dabei wird von einem praxisrelevanten Problem und einem dement-sprechend identifizierten Handlungsbedarf ausgegangen. Es werden Anwendungsfalle fest-gelegt und Beispielszenarien erstellt, von denen die Anforderungen an die zu konzipierendeLosungsmethodik hergeleitet werden. Nach der Anforderungsanalyse wird eine Einarbei-tung in sichtenbasierte modellgetriebene Software-Entwicklung gemacht. Dann wird eineEinfuhrung in verschiedene problemrelevante Grundlagen und Vorstellung gangiger Tech-niken und Verfahren aus der Praxis. Wichtige Kriterien werden ermittelt, die bei derspateren Evaluierung des Konzeptes verwendet werden. Dann wird das Losungskonzepterstellt. Dabei wird die Problemstellung aufgeteilt und fur jede Teilaufgabe eine Losungs-methode gefunden. Mittels Integration im ModelJoin-Editor wird eine Evaluierung desLosungskonzeptes mit Praxisbeispielen durchgefuhrt und konzeptionelle Verbesserungenvorgenommen.

Abbildung 1.2 zeigt eine schematische Darstellung der Gliederung der Diplomarbeit im Be-zug auf die einzelnen Vorgehensmethoden fur die Konzepterstellung. Die Abbildung stelltdie Vorgehensweise von [RA79] dar. Die Einfuhrung in die Problematik und die Erfas-sung der praxisrelevanten Probleme werden in Kapitel 1 und darauf aufbauend in Kapitel3 beschrieben. Bei der Erstellung des 3. Kapitels werden die festgestellten Anforderun-gen beschrieben. Kapitel 2 bietet eine Einfuhrung in die verschiedenen probemrelevantenGrundlagen und stellt gangige Techniken und Verfahren aus der Praxis vor. Die konzep-tuelle Losung wird in Kapitel 4 beschrieben. Der Softwareprototyp und die Konzeptvali-dierung werden in Kapitel 5 vorgestellt. Das Kapitel 6 stellt eine Zusammenfassung undeinen Ausblick auf eine weitere Entwicklung dar.

5

6 1. Einleitung

Einarbeitung in die Problematik

Anforderungsanalyse

Einarbeitung, Grundlagen und Stand der Technik

KriterienkatalogGrobkonzept

Konzeption

Prototyp

Evaluierung mit Praxisbeispielen

Konzeptverbesserung

Verifikation und Validierung

1. Einleitung

2. Grundlagen

3. Anforderungen

4. Lösungskonzept

5. Validierung des Konzepts

6. Zusammenfassung und Ausblick

Glie

deru

ng d

iese

r Arb

eit

Vorg

ehen

swei

se n

ach

Raf

fee

Abbildung 1.2.: Schematische Darstellung der Gliederung der DiplomarbeitQuelle: [RA79]

6

2. Grundlagen und Stand der Technik

Bevor der Vorstellung einer Konzeption und prototypischen Implementierung werden diebegrifflichen Grundlagen der vorliegenden Arbeit gelegt. Da die prototypische Implemen-tierung als ein Eclipse Plug-In entwickelt ist, werden die theoretische Grundlagen in Eclipsevorgestellt. Sie werden in der prototypischen Implementierung verwendet. Dabei wird dasFramework Eclipse Modeling Framework (EMF) erklart. Dann wird eine Einleitung inMeta-Object Facility (MOF) gemacht. Dabei wird auch der Zusammenhang zwischenEMF und MOF erlautert. Da das Thema dieser Arbeit die Wiederverwendung von Meta-modellen in ModelJoin-Sichten umfangt, wird eine Einfuhrung in ModelJoin gemacht. InKapitel 2.3 werden die verwandten Arbeiten vorgestellt. Folglich werden die unterschied-lichen Methoden zur Klassifizierung von Anderungen eines Metamodells naher betrachtet.Sie werden zur Uberprufung von der Wiederverwenbarkeit von Metamodellen verwendet.Diese Uberprufung wird auf der Differenzebene gemacht. Um die Differenz zwischen zweiMetamodelle zu berechnen, werden zwei Technologien in Kapitel 2.4 vorgestellt. In Ka-pitel 2.5 werden verschiedene Moglichkeiten zur Persistierung des wiederverwendbarenMetamodellens vorgestellt. Schließlich werden im Kapitel 2.6 zwei regelbasierte Systemebeschrieben. Sie werden fur die technischen Realisierung von den Regeln verwendet, diein Konzeption vorgestellt werden.

2.1. Theoretische Grundlagen

Als erstens werden in diesem Kapitel die theoretischen Grundlagen in Eclipse beschrieben.Weil diese Arbeit sich mit MOF und EMF beschaftigt, werden diese Technologien erlautert.

2.1.1. Eclipse

Eclipse ist ein Open-Source Plattform zur Entwicklung von Software verschiedenster Art.Ursprunglich wurde Eclipse als integrierte Java Entwicklungsumgebung konzipiert undentwickelt, aber seit der Version 3.0 ist Eclipse selbst nur der Kern, die die einzelnePlug-Ins verwaltet. Heutzutage wird der Kern als Basis fur die Implementierung vonEntwicklungsumgebungen unterschiedlichsten Arten verwendet. Die Runtime-Plattformbeschaftigt sich mit dem dynamischen Finden, Laden und Entladen von Plug-Ins. DieseFunktionalitat basiert auf Equinox - ein Framework, dass das OSGi-Standard implemen-tiert [BdR06]. Das bietet eine Erweiterbarkeit und Modalisierung und kann als Basis fur

7

8 2. Grundlagen und Stand der Technik

Entwicklung von Software-Produkten oder Entwicklungsumgebungen verwendet werden.Die Modulen sind Plug-Ins gennant und sind vollstandig in Java implementiert. Sie kon-nen mit der Hilfe einer Update-Seite oder durch Drop-In installiert werden. Die grafischeOberflache ist mit Standard Widget Toolkit (SWT) implementiert und unterstutzt nati-ven GUI-Komponenten fur 14 verschiedene Systeme und Architekturen. Das bietet einePlattformunabhangigkeit an [BdR06].

Im folgenden werden die wichtigsten Komponenten beschrieben.

• Plug-Ins:Die Plug-Ins sind die kleinste funktionelle Einheit, die auf der Eclipse Plattformentwickelt werden kann. Normalerweise werden kleine Erweiterungen als ein einzigesPlugin entwickelt. Wenn die Erweiterung komplex ist, dann wird sie in mehrerenPlug-Ins verteilt, so dass die Plug-Ins wiederverwendet werden (S 194) [KW11].Jedes Plug-in beinhaltet Metainformation, die sich in der Datei plugin.xml 1. Siebeschreibt, wie das Plug-in die Eclipse Plattform erweitert. Jedes Plugin kann eineoder mehrere Erweiterungspunkte (Extension Points) definieren.

• Features:Ein Feature besteht aus einer Menge von Plug-Ins, die vom Update Manager bzw.Equinox2 p2 als Einheit betrachtet wird. Bei der Erstellung eines Produktes konnendie Features optional oder pflichtmaßig definiert werden (S 193) [KW11]. Ein Featurekann als eine logische strukturelle Einheit betrachtet werden.

• Extension Points:Die Erweiterungspunkte (Extension Points) bieten eine Erweiterbarkeit und loseKopplung von den Plug-Ins an. Das erlaubt eine leichtere Austauschbarkeit. Ein Er-weiterungspunkt beschreibt, wie das Plug-In erweitert werden kann. Die Erweiterungerfolgt in einem Dialekt von XML Schema und kann zusatzlich auf Java-Interfacesverweisen. Plug-Ins, die sich zu einem Extension Point anbinden mochten, mussensich an die Schnittstellen des Erweiterngspunktes halten [ext13].

Die Platform UI ist ein High-Level-Framework, dass fertige UI-Komponente anbietet.Diese Komponente sind auf JFace, SWT und viele andere Bibliotheken basiert. Im folgen-den werden einige Komponente vorgestellt [ecl13]:

• Workbench:Jedes Workbench enthalt eine oder mehrere Perspektiven und kontrolliert welcheUI-Komponente wie z.B. Menus, Toolbars, Sichten und Editoren angezeigt werdensollen.

• Perspective:Eine Perspektive definiert, wie und welche Ansichten (Views) und Editoren (Editors)auf dem Bildschirm angeordnet werden. Es konnen mehrere Perspektiven definiertwerden, die normalerweise nach Funktionalitaten oder Rollen gruppiert werden.

• Editor:Die Editoren dienen zur Bearbeitung von Ressourcen oder Eingabeobjekten. Einwesentlicher Unterschied zu Views ist die Tatsache, dass sie einen Offnen-Speichern-Schließen Lifecycle besitzen. Die Editoren werden im Editorbereich angezeigt, dersich normalerweise in der Mitte des Hauptfensters befindet.

1FAQ What is the plug-in manifest file (plugin.xml)? Quelle: [man13]2Equinox ist ein OSGi R4 Spezifikation. Quelle: [equ13]

8

2.1. Theoretische Grundlagen 9

• View:Die Views werden zur Darstellung von Information, die sich auf globale Informatio-nen oder den aktuellen Editor beziehen. Sie dienen zur Navigieren von Hierarchienvon Information oder zur Anzeige von Eigenschaften von einem aktiven Editor.

• Wizard:Die Wizards werden hauptsachlich zur Erstellung von neuen Ressourcen und Importbzw. Export von Ressourcen verwendet. Sie finden Verwendung auch bei der Aus-fuhrung von Aufgaben, die mehrere in bestimmten Reihenfolge Schritten benotigen.

• Dialog:Die Dialogs werden zur modale Interaktion mit dem Benutzer verwendet. Sie dienenzur Darstellung einer Statusinformation oder zur Eingabe von Information.

2.1.2. Modelle und Metamodelle

In diesem Abschnitt werden die Begriffe Modell und Metamodell erlautert. Diese Begriffewerden innerhalb der Arbeit sehr oft erwahnt und deswegen ist eine Erklarung als Grund-lage dieser Arbeit notig. Dann werden zwei Modellierungsframeworks - MOF und EMFvorgestellt.

• Metamodell: Laut [Joh13] ist ein Metamodell eine prazise Definition von Kon-strukten und Regeln, die fur die Erstellung von semantischen Modellen benotigtwerden. [SVEH07] beschreibt ein Metamodell als eine Formalisierung einer Domane,d.h. eines begrenzten Interessen- oder Wissensgebiets. Die Vorsilbe

”meta” bedeutet

auf griechisch”uber”. Ein Metamodell ist also ein Modell, dass die Konstruktion von

Modellen beschreibt.

• Modell: Eine klassische Definition von einem Modell ist von Stachowiak in [Sta73]definiert. Er definiert in [Sta73] drei Charakteristiken, die ein Modell haben soll -Abstraktion, Isomorphismus und Pragmatismus. Die Abstraktion bedeutet, dass dasModell bestimmte Teile der Realitat abstrahiert. Ein Modell projektiert die Realitatund diese Projektierung soll isomorph sein. Die Erstellung eines Modells hat einZweck und deshalb sind sie pragmatisch. Inspiriert von dieser Definition definie-ren [RH08] und [Bec08] eine Definition in im Kontext von Model-Driven SoftwareDevelopment (MDSD), die im Rahmen der Ausarbeitung verwendet wird.

A formal representation of entities and relationships in the real world (ab-straction) with a certain correspondence (isomorphism) for a certain pur-pose (pragmatics) [Bec08].

2.1.2.1. Meta-Object Facility

MOF bietet einen Rahmenwerk zum Metadaten-Management an. Das Rahmenwerk stellteine Reihe von Metadaten-Services, die die Interoperabilitat von Modellen und Metada-ten erlaubt. MOF uberbruckt die Lucke zwischen unterschiedlichen Metamodellen, indemeine allgemeine Grundlage fur Metamodelle geschaffen wird. Einige von Object Manage-ment Group (OMG) standardisierten Technologien wie z.B. UML, MOF, XMI und andereUML-Profilen verwenden MOF zum Austausch von Metadaten. In der aktuellsten Ver-sion - MOF 2.0 sind die Modellierungskonzepte von Unified Modeling Language (UML) 2Infrastructure library wiederverwendet. Damit werden einfache Regeln zur Modellierungdefiniert, die auf UML Class Modellierung basieren und es wird eine bessere Unterstutzungvon Werkzeugen angeboten [omg11].

9


Das OMG bietet kein festes Schichtenarchitektur an. Das Hauptmodellierungskonzept istdie Verwendung von Classifier und Instance oder Class und Object . Damit konnenunterschiedliche Schichten definiert werden. Zum Beispiel eine relationale Datenbank kannmit drei Schichten modelliert werden - SysTable, Table und Row. Laut [omg11] muss dieAnzahl von Schichten mindestens zwei sein. Fur die Definition von UML werden vonOMG vier Schichten spezifiziert. Die Schichtung ist so strukturiert, dass ein Elementauf Ebene M<i> eine Instanz von Ebene M<i+1> ist. Im folgenden wird eine typische4-Schichtenarchitektur vorgestellt:

• M3-Ebene: Meta-Meta-Modelle (bzw. MOF-Ebene). Die Definition dieser Ebeneerfolgt mit der M3-Ebene selbst. Diese Ebene wird zur Definition der M2-Ebeneverwendet.

• M2-Ebene: Meta-Modelle. In der M2-Ebene wird definiert, wie die Modellestrukturiert und definiert sind. Hier werden die Elemente Klassen, Attributen undAssoziationen definiert.

• M1-Ebene: Modellebene. Diese Ebene definiert Sprachen, die die semantischeDomane spezifiziert. Ein Model ist eine Instanz von dem Metamodell (M2) undenthalt Modell-Elemente.

• M0-Ebene: Instanzebene. Die niedrigste Ebene beschreibt die Instanzen von M1.Diese Objekte existieren nur wahrend der Ausfuhrungszeit und stellen ein Snapshotvon dem System wahren der Ausfuhrungszeit dar.

MOF 2.0 besteht aus zwei Hauptpaketen namlich Essential Meta-Object Facility (EMOF)und Complete Meta-Object Facility (CMOF). CMOF erganzt das Paket EMOF. Siewerden im folgenden beschrieben werden:

• Essential MOF (EMOF): EMOF ist eine Untermenge von MOF 2.0, so dass dieKonstrukte in objektorientierten Programmiersprachen und Extensible Markup Lan-guage (XML) folgt. EMOF erlaubt ein einfaches Mapping mit Implementierungenwie z.B. Java Metadata Interface (JMI) und XML Metadata Interchange (XMI). DasHauptziel dieser Untermenge ist die einfache Definierung von Metamodellen, ohnedie gesamte MOF Infrastruktur zu verstehen. EMOF ist mit ECore kompatibel[omg11].

• Complete MOF (CMOF): CMOF wird fur die Spezifizierung von anderen Me-tamodellen wie z.B. UML2 verwendet. Das ist eine Erweiterung von EMOF, dieKernkonstrukten von UML2 entspricht [omg11].

2.1.2.2. Eclipse Modeling Framework (EMF)

EMF ist ein Framework zur Modellierung von Metamodellen sowie zur Erstellung von demdazu passenden Editor. Mit dem Editor konnen eigene Modelle bearbeitet werden. Dasvon EMF verwendete Meta-Metamodell ist ECore. ECore basiert auf EMOF, der vonOMG definiert ist. Die OMG beschaftigt sich mit der Entwicklung von Standards fur dieherstellerunabhangige systemubergreifende Objektorientierte Programmierung [omg13].

Mit der Hilfe von dem EMF kann ein reflektiver und dynamischer Editor gestartet werden.Mit ihm konnnen Modelle erzeugt werden, die mit dem definierten Metamodell konformsind. Es ist auch moglich, dass ein autonomer EMF-basierter Editor generiert wird. Derkann als eigenstandige Anwendung verwendet werden. EMF ist auf zwei Metamodelle

10

2.2. ModelJoin 11

basiert - ECore und Genmodel. ECore beinhaltet die Information uber die definierte Klas-sen und Genmodel beschreibt die zusatzliche Information uber die Pfaden, die Dateienund wie der Quellkode generiert wird. Bei komplexen Metamodellen mit Relationen ist esschwer mit dem generierten baumartigen Editor Modellen zu erzeugen. Deswegen unter-stutzt EMF die Generierung von GEF-Editoren. Das Graphical Editing Framework (GEF)bietet Werkzeugen zur Erstellung von umfangreichen graphische Editoren, die im Eclipseintegrierbar sind [gef13]. Mit ihnen konnen die Modelle manipuliert werden. Der generierteQuellkode vom Modell und Editor kann angepasst werden und bei einer Neugenerierungwird der modifizierte Quellcode mit dem generierten verschmolzen - die manuelle Ande-rungen werden behalten [SBPM08].

2.2. ModelJoin

Das Framework ModelJoin erlaubt eine rapide und losegekoppelte Entwicklung von Sichtenvon Metamodellen und Instanzen mit der Hilfe einer SQL-ahnlichen Sprache. Im folgen-den werde erstens die Grundlagen von ModelJoin beschrieben. Dann wird anhand einesBeispiels die Funktionsweise von ModelJoin erlautert.

2.2.1. Grundlagen

ModelJoin erlaubt eine intuitive und rapide Erstellung von Sichten auf Basis von he-terogenen Metamodellen. Die Ausdrucke werden mittels einer Structured Query Lan-guage (SQL)-ahnlichen DSL definiert. Es wird automatisch ein neues Ziel-Metamodellgeneriert, das Information aus den Eingabemodellen zusammenfasst. Wenn die ModelJoin-Query geandert und die Datei gespeichert wird, wird das Ziel-Metamodell und die entspre-chenden Skripten zur Modelltransformation neu generiert. Mit diesen Skripten werden dieneue Modelle generiert. Das Ziel-Metamodell ist annotiert und enthalt eine Beziehung zuden Eingabe-Metamodellen.

Die folgenden Sprachenkonstrukte sind bei ModelJoin definiert, die von der SQL-Spracheinspiriert sind.

• Join: ModelJoin erlaubt die Verschmelzung von zwei oder mehreren Metamodellenin einem Ziel-Metamodell. Es werden natural join und outer join unterstutzt.

• Keep: Mit Keep werden die Attribute bestimmt, die das neue Ziel-Metamodellbeinhalten. Mit diesem Konstrukt konnen auch Referenzen auf anderen Klassen ausden Eingabe-Metamodellen erstellt werden.

• Where: Das Where-Konstrukt erlaubt die Einschrankung/Selektion von Elementen,die das logische Pradikat erfullen. Weil ModelJoin QVT im Hintergrund verwendet,wird OCL! (OCL!)3 verwendet. Das Where-Konstrukt funktioniert als Filter aufInstanzebene.

• Rename: Dieses Konstrukt wird zur Umbenennung von Entitaten im Ziel-Metamodell benotigt.

Auf der Abbildung 2.1 ist die Struktur der prototypischen Implementierung von Model-Join dargestellt. Als Eingabe werden zwei oder mehreren Metamodelle benotigt. Je-des Eingabe-Metamodell hat eine oder mehrere konforme Modelle. Mit der Hilfe von

3OCL! ist eine deklarative Sprache zur Beschreibung von Regeln, die im UML verwendet werden [ocl12]

11


einer ModelJoin-Anfrage wird das neue Ziel-Metamodell definiert. Diese Anfrage bein-haltet Referenzen zu den Eingabe-Metamodellen. Sie wird nach [GBB12] als ModelJoin-Sichttyp gennant. Nach der Ausfuhrung der Query wird das Metamodell-Synthesis aus-gelost und dadurch wird das Ziel-Metamodell generiert. Schließlich werden die Ziel-Modelle(ModelJoin-Sichten) mittels Modell-2-Modell Transformation erzeugt [BHS+13].

Input Metamodels

Model 1..n

ModelJoin Query

Metamodel Synthesis

Transformation Generation

Model-to-model Transformation

Target Metamodel

Join Result

<<conforms to>>

<<references>>

<<conforms to>>

Runtime generation Runtime generation

Abbildung 2.1.: ModelJoin WorkflowQuelle: Eigene Darstellung nach [BHS+13]

ModelJoin ist prototypisch mit Metamodell mit Xtext4, Xtend25 als Eclipse-Plugin im-plementiert. Das erlaubt eine einfache und intuitive Verwendung in der Eclipse Umge-bung. Alle Eclipse-Funktionalitaten wie z.B. automatische Vervollstandigung und Syntax-Highlighting werden unterstutzt. Beim Speichern einer Query wird die Metamodellgene-rierung und -transformation mit QVT-O6 generiert.

2.2.2. Beispiel

In dieser Unterabschnitt wird gezeigt, wie ModelJoin funktioniert. Dafur wird eineQuery geschrieben und es wird gezeigt, wie das Ziel-Metamodell generiert wird. AlsEingabe-Metamodelle werden ein KIT-Library und ein Amazon-Library Metamodellund die entsprechende Modellen betrachtet. Beide Modelle sind in Form von UML-Klassendiagrammen auf Abbildung 2.2 bzw. 2.3 dargestellt. Mittels ModelJoin wird einneues Metamodell aus diesen erzeugt, bei dem die Book behaltet wird und die Rezeren-zen nach Author und Rating ubernommen werden. Aus dem Author wird das Attributname ubernommen. Aus der Klasse Rating wird das Attribut rating ins neue Meta-modell gespeichert. Um das zu erreichen, wird eine ModelJoin-Query(Code-Snippet 2.1)verwendet. Die erste Zeile ist ein natural join zwischen den Klassen Book aus KIT- undAmazon-Library. Die Attributen mit der gleichen Struktur werden ubernommen. Dannwerden die ausgehenden Referenzen mit keep outgoing und die entsprechende Attributenmit with keep attributes ubernommen. Mit where wird eine Selektion auf Modelle-bene gemacht. In diesem Beispiel wird das Attribut isbn auf die Attributen isbn-10und isbn-13 abgebildet. Das Ziel-Metamodell und die transformierte Modelle sind aufAbbildung 2.4 dargestellt.

4http://www.eclipse.org/Xtext/5http://www.eclipse.org/xtend/6http://m2m.eclipse.org

12

2.3. Verwandte Arbeiten 13

Mediatitle: Stringyear: intmonth: intlanguage: Stringisbn: String

Customername: Stringtype: CustomerType

Authorname: String

1..* 0..1rented by

release: StringBook

lenght: intDVD

*1

KDA:Booktitle = The Hitchhiker's Guide to the Galaxyyear: 1979month: 10language: Englishisbn: 0-330-25864-8

MM:Customername = Max Mustermanntype = Student

Authorname = Douglas Adams

KIT Library

M2

M1

Abbildung 2.2.: KIT-Library

Booktitle: Stringlanguage: Stringpublisher: Stringweight: doubleisbn-10: Stringisbn-13: String

Reviewtitle: Stringrating: intdate: Stringdescription: String

1 0..*has

ADA:Booktitle: The Hitchhiker's Guide to the Galaxylanguage = Englishpublisher = Pan Booksweight: 0.5isbn-10 = 0-330-25864-8isbn-13 = 978-0345453747

R1:Reviewtitle: best Book everrating: 5date: 13.01.2013description: 42

R2:Reviewtitle:not badrating: 4date: 13.01.2013description: nice book

Amazon

M2

M1

Abbildung 2.3.: Amazon-Library

//Join and Renamenatural join library.Book with amazon.Book as jointarget.BookCollection//Keep References and Attributeskeep outgoing amazon.Book.reviews as type jointarget.Reviewwith keep attributes jointarget.Review.ratingkeep outgoing library.Media.author as type jointarget.Authorwith keep attributes jointarget.Author.name//Selectionwhere ibrary.Book.isbn−>forAll (p | amazon.Book.isbn−> exists (a | (isbn ==

a.isbn−13)||(isbn == a.isbn−10)))

Listing 2.1: ModelJoin Beispiel

BookCollectiontitle: Stringlanguage: String

Reviewrating: int

1 0..*has

Authorname: String

*

1

Ziel-Metamodell


R1:Reviewrating = 5


R2:Reviewrating = 4

M2

M1

Abbildung 2.4.: Ziel-Metamodell: BookCollection Library

2.3. Verwandte Arbeiten

[BGGK07], [eda13]. [BG10] und [Wac07] beschaftigen sich mit der automatischen undsemi-automatischen Adaptierung von Modellen bei einer Anderung von Metamodellen.Sie definieren eine Liste von Anderungen und klassifizieren sie nach denen Auswirkung aufModellebene fur MOF. [BRR05] definiert ein drittes Wiederverwendungstyp reuse and

13


generalize in MOF, mit dem die Metamodellen zusammengefasst werden konnen. Im EMF-Kontext stellen Steffan Becker et al. ein Prozess zur Migrierung von Modellen vor unddefiniert eine Liste von Anderungen in [BGGK07], die nach [Gru07] klassifiziert werden. InRichtung Komposition von Metamodellen beschaftigen sich [BRR05] und [CJC11]. [Egy06]stellt einen interessanten Ansatz zur Uberprufung der Konsistenz von UML-Modellen mitder Hilfe von Regeln vor. Der wird von [RE12] optimiert und weiterentwickelt.

Im den folgenden Unterabschnitten werden die verwandten Veroffentlichungen naher be-trachtet. Am Ende des Abschnitts wird diskutiert, wie die vorgestellten Arbeiten in Zu-sammenhang mit dieser Ausarbeitung stehen.

2.3.1. Metamodel Reuse with MOF

In der Veroffentlichung”Metamodel Reuse with MOF” werden zwei Wiederverwendungs-

typen gennant [BRR05]. Sie sind reuse as is und reuse as specialization. Der erste Typbeschreibt eine Wiederverwendung von Metamodellen mit der Hilfe der import Funktionim MOF. Der zweite Typ verwendet die Vererbungsfunktion - merge. Der Author schlagteinen dritten Typ – reuse and generalize und empfehlt einen Ansatz zur Generalisierungvon Metamodellen. Die Idee ist herauszufinden, welche gemeinsame Elemente in mehrerenMetamodellen existieren und diese in einem neuen Metamodell zu generalisieren.

Der Aspekt dieser Arbeit ist die Wiederverwendung und Komposition von Metamodel-len. Das Ziel dieser Arbeit ist die komplete Wiederverwendung von Metamodellen undherauszufinden, wann eine Wiederverwendung moglich ist.

2.3.2. Virtual Composition of EMF Models

Clasen et al. schlagen einen Ansatz zur Verwendung von virtuellen Kompositionen in EMFModellen vor [CJC11]. Anstatt die Erstellung von neuen Metamodellen und Modellen,wird eine Proxy erstellt, die die Information zur Verfugung stellt. Der Vorteil diesemAnsatz ist, dass die Modellen nicht kopiert werden. Sie werden referenziert und jedeAnderung uber das Proxy wird direkt auf die Quelle angewendet.

Die Arbeit generiert immer ein neues Metamodell und hat keine Mechanismen zur Wie-derverwendung von diesen. Der Author behauptet, dass die Metamodelle deutlich kleinerals die Modelle sind und das verletzt die Performanz nicht. Sie werden immer mit der Hilfevon ATL-Transformationen generiert. Wenn der Benutzer ein bestimmtes Ziel-Metamodellgenerieren will, so dass die Instanzen auf Modellebene zu diesem Metamodell konform sind,ist das mit diesem Ansatz nicht leicht moglich.

2.3.3. UML Konsistenzuberprufung

In diesem Unterabschnitt werden unterschiedliche Arbeiten in Richtung Konsistenzuber-prufung von UML Diagrammen. Die Idee ist zu sehen, wie die Konsistenzuberprufung indieser Domane realisiert ist.

In der Veroffentlichung”Instant Consistency Checking for the UML” wird einen Ansatz

zur inkrementellen Uberprufung der Konsistenz von UML [Egy06]. Eine Erweiterung vondiesem Ansatz wird von [RE12] gemacht. Mit der Hilfe von hierarchische Regeln wird dieGeschwindigkeit der Uberprufung von der Konsistenz verbessert. Mit der Hilfe von Regelnwerden die Anderungen uberpruft, ob die Konsistenz gehalten ist. Ein ahnlicher Ansatzwird in [KS06] beschrieben. Dort wird der Begriff Inconsistency Trigger verwendet unddie Regeln sind formal beschrieben.

14


[LEM02] verwendet eine regelbasiertes System zur dynamischen Uberprufung von Inkon-sistenzen in UML. Das erlaubt eine dynamische Anderung von den Regeln. Prototypischwird JESS verwendet. Die Architektur – RIDE (Rule-based Inconsistency Detection En-gine) beschreibt wie der Ansatz mit ArgoUML und andere Modellierungswerkzeuge inte-griert werden kann. Auf der Abbildung 2.5 ist die Architektur dargestellt.

Abbildung 2.5.: RIDE ArchitekturQuelle: [LEM02]

• Synchronizer: Mit dieser Komponente werden die Objekte im UML-Werkzeugund die Objekte im regelbasierten System synchroniziert, so dass sie identisch blei-ben. Das ist notig, wenn die Regeln das UML-Modell modifizieren.

• Rule Engine Abstraction Layer: Diese Schicht erlaubt die Verwendung vonanderen regelbasierten Systemen.

• Rule Editor: Mit der Hilfe von dem Rule Editor werden die Regeln vom Benutzermodifiziert.

2.3.4. Prozessmodell fur halbautomatische Co-Evolution

Im folgenden wird ein Prozessmodell fur halbautomatische Co-Evolution vorgestellt. Inder Veroffentlichung [BGGK07] wird ein Prozessmodell fur Migration von Modellen bei derAnderung von Metamodellen betrachtet. Dabei wird eine Klassifikation den Operationenzur Anderung von Metamodellen ausgewertet. Es wird beschrieben, ob eine Anderungeine Migration benotigt oder nicht. Wenn eine Migration benotigt wird, wird uberpruft,ob die Migration automatisch oder semi-automatisch gemacht werden kann.

Die Abbildung 2.6 ist einen Ubersicht von dem Prozessmodell. Als Eingabe werden zweiVersionen von einem Metamodell gebraucht. Dann werden die folgenden Schritte ausge-fuhrt:

• Change Detection: In diesem Schritt wird uberpruft welche Elemente geandertsind. Es gibt zwei Methoden zur Erkennung von den Anderungen. Die erste Methodeverwendet einen direkten Vergleich zwischen zwei Metamodellen - direct comparison.Dafur wird eine Differenz berechnet und auf Basis dieser Differenz werden die Ande-rungen erkannt. Bei der zweiten Methodik - change trace werden die ausgefuhrtenAnderungen zwischen den beiden Versionen geloggt. Der Vorteil dieser Methodik istdie leichte Erkennung von den Operationen. Der Nachteil ist, dass man bestimmte

15


Werkzeuge fur die Anderungen verwenden muss, die die Operationen aufnehmen undsie fur die Transformation verwenden. Damit konnen keine fremde Anderungen einesMetamodells ausgewertet werden.

• Classification: Die Anderungen werden in drei Gruppen nach [Gru07] - NotBreaking, Breaking & Not Resolvable und Breaking & Resolvable klassifiziert. DieseGruppen werden in Kapitel 2.3.5 detailiert beschrieben. Der nachste Schritt ist vonder Klassifizierung abhangig. Wenn die Anderung von Typ Not Breaking ist, dannwird keine Migration fur sie gebraucht. Die Anderungen von Typ Breaking & NotResolvable sind Anderungen, bei denen die Migrationsskripten nicht automatischerstellt werden konnen. Deswegen wird eine Eingabe von dem Benutzer gebraucht.Fur die Breaking & Resolvable Anderungen konnen Migrationsskripte automatischgeneriert werden und brauchen keinen Einfluss vom Benutzer.

• User Input Gathering: In diesem Schritt werden die Breaking & Not ResolvableAnderungen von dem Benutzer bearbeitet. Diese Anderungen haben keine eindeutigeTransformationsausgabe und konnen nicht automatisch angepasst werden. Deswegenbrauchen sie einen Einfluss von dem Benutzer.

• Migration Algorithms Determination: Dieser Schritt”Migration Algorithms

Determination” bestimmt, welcher Algorithmus fur eine bestimmte Anderung dieserMigration durchgefuhrt wird.

• Migration: Der letzte Schritt fuhrt die Migration durch. In diesem Schritt werdendie Modelle anhand der generierten Transformationssripten migriert.

Abbildung 2.6.: Migration Prozess ModellQuelle: [BGGK07]

Becker kategorisiert alle moglichen Operationen fur Ecore nach [Gru07]. Er teilt die mog-lichen Metamodellanderungen in unterschiedlichen Teilen auf - Elemente hinzufugen/ent-

16


fernen und Anderung von Metamodellelementen. Diese Klassifizierung ist in Tabelle B.1zu sehen.

2.3.5. Konformitatsbedingungen nach Burger und Gruschko

Burger und Gruschko beschaftigen sich mit der Klassifizierung von allen moglichen Meta-modellanderungen fur MOF 1.4 nach dem Einfluss von diesen Anderungen auf Modellebene[BG10]. Die Anderungen werden nach [Gru07] klassifiziert. Die erste Klasse - Not Brea-king Changes enthalt keine konformitatsverletzenden Anderungen. Solche Anderungendes Metamodells erfordern keine Migration auf der Modellebene. Die zweite Kategorie- Breaking and Resolvable Changes besteht aus Anderungen im Metamodell, die die In-stanzen ungultig machen. Sie konnen aber automatisch an die Anderungen angepasstwerden. Die dritte Kategorie - Breaking and Unresolvable Changes wird aus Anderungengebildet, die die Instanzen ungultig machen. In diesem Fall konnen die Instanzen nichtautomatisch angepasst werden. [BG10] gruppiert die Anderungen in drei Klassen namlichExistenceChange, PropertyChange und LinkChange. Die Tabelle B.2 im Anhang beinhal-tet die klassifizierten Anderungen. Jede Anderung wird nach [Gru07] klassifiziert und dieBedingungen fur die Gultigkeit der Klassifizierung werden beschrieben.

2.3.6. Eclipse EMF Edapt

Edapt ist ein Rahmenwerk, der die Komplexitat der Migration von Ecore Modelle redu-ziert. Wenn ein Metamodell geandert wird, mussen auch die erzeugte Modelle angepasstwerden, weil sie nicht mehr zu den neuen Metamodell konform sind. Diese Modelle mus-sen migriert werden. Edapt bietet eine Methodik zur automatisierte Co-Evolution an. DieAnderungen des Metamodells werden durch Refactoring-Operationen ausgefuhrt, die vonEdapt definiert sind. Diese Operationen werden vom Framework geloggt und dadurchspater Transformationsskripte generiert. Diese werden zur Anpassung von den Modellenverwendet. Die von Edapt definierte -Sprache kann zur manuellen Definition von Transfor-mationen verwendet werden. Damit konnen komplexe Transformationen erstellt werden[eda13].

Edapt betrachtet drei Typen von Metamodellanderungen namlich Metamodel-only,Metamodel-specific und Metamodel-independent. Metamodel-only betrachtet nur die An-derungen eines Metamodells, die keine Migration von den Modellen brauchen. Das sindzum Beispiel Erweiterungen wie das Hinzufugen von einem optionalen Attribut. DieMetamodel-independent sind Anderungen, die nicht von einem spezifischen Metamodellabhangig sind. Diese konnen in mehreren Metamodellen wiederverwendet werden. EinBeispiel fur solche Anderungen ist die Umbenennung einer Klasse. Metamodel-specificsind die Anderungen, die auf ein spezifisches Metamodell angewendet werden und kon-nen nicht in anderen Metamodellen wiederverwendet werden. Metamodel-only sind dieAnderungen, die keine Migration brauchen [HBJ09].

Edapt verwendet ein operationsbasiertes Verfahren und die change trace Methodik. JedeOperation beinhaltet Anderungen des Metamodells und die Migration von dem Modell.Diese Operationen konnen wiederverwendet werden. Das Rahmenwerk unterstutzt 61wiederverwendbare Operationen, die in 90% der Fallen ausreichen. Wenn eine Migrationnicht mit den angebotenen Operationen ausgedruckt werden kann, dann konnen dieseTransformationen manuell definiert werden [eda13].

In [HVW11] werden alle wiederverwendbaren Operationen beschrieben. Die Operationenwerden in vier Gruppen geteilt namlich Structural Primitives, Non-structural Primitives,

17


Specialization/Generalization Operators und Inheritance Operators. Structural Primiti-ves sind alle Anderungen, die die Struktur des Metamodells betreffen. Es werden neueElemente zum Metamodell hinzugefugt oder geloscht. Wenn die erstellten/geloschten Ele-mente non-mandatory sind, dann sind sie Model-preserving. Bei Non-structural Primiti-ves werden die Anderungen von den Eigenschaften eines Metamodell-Elements betrach-tet. Specialization/ Generalization Operators sind alle Anderungen, bei denen es um eineVerschiebung von Attributen/Referenzen in die Vererbungshierarchie geht. InheritanceOperators ist die Verschiebung von Features in die Vererbungshierarchie.

2.3.7. Diskussion

Die Klassifizierung von [Gru07] gibt die Grundlagen, bei welchen Anderungen von einemMetamodell das Modell nicht angepasst werden soll. Das sind die Non-Breaking Changes.Eine ahnliche Gruppierung wird auch bei Edapt gemacht [HVW11]. Die Non-BreakingChanges werden unter dem Begriff Model-Preserving verwendet. In dieser Arbeit wird dieBezeichnung von [Gru07] verwendet.

Das von Becker definierte Prozessmodell fur halbautomatische Co-Evolution wird in die-ser Arbeit verwendet werden. Die ersten zwei Schritte - Change Desertion or Tracingund Classification konnen wiederverwendet werden. User Input Gathering und Migra-tion Algorithmus Determination werden nicht gebraucht. Im ModelJoin-Kontext wird dasMetamodell immer neu generiert und eine Migration wird nicht gebraucht. Diese Arbeitbeantwortet die Frage, ob die Metamodelle in ModelJoin wiederverwendet werden konnen.Das kann durch eine Klassifizierung von den Anderungen erreicht werden. Eine Kombina-tion von den Veroffentlichungen von [BG10] und [Gru07] wird zur Bestimmung von denAnderungstypen verwendet werden.

Burger ([BG10]), Becker ([BGGK07]) und Herrmannsdorfer ([HVW11]) haben bereits ahn-liche Klassifizierungen vorgestellt. Burger hat eine Klassifizierung von MOF 1.4 definiert.ModelJoin verwendet Ecore. Wie in Kapitel 2.1.2.1 erwahnt wurde, ist Ecore mit EMOF2.0 kompatibel. Es muss uberpruft werden welche Anderungen fur Ecore gelten und wel-che nicht. Becker hat eine Kategorisierung von Ecore erstellt, die in der Konzeptionverwendet wird. Um das Konzept zu validieren, werden die vorgestellten Operationenvon Herrmannsdorfer verwendet werden. Er hat eine Menge von Operationen definiert,die auch kompliziertere Anderungen vorstellen. Diese Anderungen bestehen aus mehrereneinfache Anderungen, die im [BG10] und [BGGK07] beschrieben sind.

Die Veroffentlichung von Egyerd [Egy06], die weiter von [RE12] verbessert wird, be-schreibt die Verwendung von Regeln fur die Konsistenzuberprufung von UML Metamodel-len. [LEM02] verwendet fur die Uberprufung der Konsistenz ein regelbasiertes System undbeschreibt, wie es mit z.B. ArgoUML [arg13] integriert werden kann. Die Uberprufung derWiederverwendung von Metamodellen wird mit der Hilfe von Regeln uberpruft. In derprototypischen Implementierung wird drools verwendet, dass auch die Regeln hierarchischbildet und optimiert, so dass die Idee von [RE12] und [Egy06] verwendet wird.

2.4. Berechnung eines Diffs

Um die Anderungen zwischen zwei Metamodelle zu ermitteln, ist ein Rahmenwerk zurBerechnung der Differenz erforderlich. Zur Zeit existieren zwei solche Rahmenwerke, mitdenen eine Differenz berechnet werden kann. Das sind EMF Compare und EMF Diff/-Merge. Naturlich kann auch eine textuelle Differenz wie zum Beispiel das Hunt?McIlroyAlgorithmus [HM76] gemacht werden. Ein Nachteil dieser Werkzeuge ist allerdings, dass

18

2.4. Berechnung eines Diffs 19

sie meist weder die Struktur noch die Semantik der Texte kennen und sie nur zeilenweisevergleichen. Aus diesem Grund werden nur die oben genannte Frameworks naher betrach-tet.

Laut [BE09] ist Modelldifferenz (Diff) der Unterschied zwischen zwei Versionen von Mo-dellen, die den selben Typ haben. Es existieren zwei Verfahren zur Berechnung von Diffs,namlich operationsbasiertes Verfahren und zustandsbasiertes Verfahren. Das operations-basierte Verfahren berechnet die Differenz beim Aufnehmen von den Anderungsschritten,die von dem Benutzer gemacht werden. Bei dem zustandsbasierten Verfahren wird dieDifferenz zwischen zwei Zustanden berechnet [KKPS12]. Im folgenden werden zwei Algo-rithmen vorgestellt, die zustandsbasiert sind.

2.4.1. EMF Compare

Das EMF-Compare ist ein Rahmenwerk, das fur den Vergleich der logischen Struktur vonModellen/Metamodellen heranzieht [emf12]. Darauf aufbauend unterstutzt ein Vergleichs-werkzeug den Benutzer beim Zusammenfuhren unterschiedlicher Modelle. EMFComparebesteht aus einem generischen Engine zum Vergleich von Modellen, die Moglichkeit zumExportieren von Differenzen in der Form von einem Patch und ist mit dem Eclipse TeamAPI integriert. Damit besteht die Moglichkeit zu gemeinschaftliche Modellierung von Mo-dellen.

EMF Compare hat einen Editor, mit dem die Differenz von zwei EMF Metamodellen/-Modellen mit einander verglichen werden kann. Ein Screenshot des Editors ist im Anhangauf der Abbildung B.3 zu sehen.

Der Workflow ist auf der Abbildung 2.7 dargestellt und beinhaltet 6 Phasen. Sie werdenim folgenden beschrieben:

A'

Model Resolving

A

Match Diff

Runtime generation

Equivalence

Requirements

Conflicts

Logical Models

Models

Abbildung 2.7.: EMF CompareQuelle: Eigene Darstellung nach [emf12]

• Model Resolving: In dieser Phase werden alle benotigten Fragmente geladen.Das sind die Modelle, die verglichen werden und auch alle referenzierten Modellen.

• Matching: In diesem Schritt werden beide Modelle iteriert, um die Elemente zufinden, die miteinander ubereinstimmen. Vor er Berechnung der Differenz mussen diegleichen Elemente gefunden werden. In diesem Fall sind die Elemente mit der glei-chen Struktur und Parametern. Dafur wird einen Algorithmus zur Berechnung derDistanz zwischen den Elementen verwendet. Wenn die Elemente einen Identifikatorhaben, wird er fur den Vergleich verwendet.

19


• Differencing: Die Matching bestimmt, welche Elemente in den beiden Modellengleich sind. In dieser Phase werden die Elemente gefunden, die kein Aquivalenthaben. Sie stellen die Differenzen zwischen den beiden Modellen dar. Ein Beispielsolcher Anderung ist die Umbenennung einer Klasse.

• Equivalences: Die Differenzphase hat die Differenz zwischen den beiden Modellenberechnet. Trotzdem konnen zwei Anderungen die selbe Differenz darstellen. Indieser Phase werden alle Differenzen gemappt, die aquivalent sind. Ein Beispielsolcher Anderung ist die Differenz von zwei gegenuberliegende Referenzen.

• Requirements: In dieser Phase wird es uberpruft, ob es zwischen den AnderungenAbhangigkeiten gibt. Ein Beispiel ist, wenn eine Klasse C1 in Paket P1 hinzugefugtwird. Um Diese Anderung zu machen, soll aber zuerst das Paket P1 hinzugefugtwerden. Das sind zwei Anderungen die von einander abhangig sind.

• Conflicts: Diese Phase uberpruft, ob Konflikte zwischen den beiden Modellenexistieren.

Die Anderungsuberprufung wird mit dem UMLDiff berechnet [emf12]. UMLDiff ist ein Al-gorithmus fur strukturelle Anderungsuberprufung von zwei Metamodellen. Beide werdenmiteinander auf strukturelle Ahnlichkeiten bzw. Differenzen untersucht. Alle Differenzenwie zum Beispiel Entfernung, Hinzufugen, Verschiebung oder Umbenennung von Elemen-ten werden erkannt [XS05].

EMFCompare kann auch programmatisch verwendet werden. Es wird ein API angeboten,mit dem die einzelnen Schritte verwendet werden konnen. Einige Tipps, die wahrend dieserArbeit verwendet werden, sind im Anhang B zu finden.

EMFCompare bietet eine grafische Darstellung (siehe Abbildung B.3) zur Verschmelzungvon den Anderungen an. Sie dient auch zur Verschmelzung von den Metamodellen, diemiteinander verglichen werden.

2.4.2. EMF Diff/Merge

Wie EMF Compare ist EMF Diff/Merge ein Rahmenwerk zur Berechnung der Differenzund zur Verschmelzung von Modellen. Der Prozess besteht aus 3 Schritten. Zuerst werdendie Modellen verglichen und eine Differenz wird nach gegebenen Strategien berechnet. DieDifferenz wird auf Basis von IDs berechnet. Das Rahmenwerk besteht aus wiederverwend-baren GUIs und einer Engine, die erweiterbar sind. Dabei konnen Strategien definiertwerden. Die Strategien sind Mechanismen und Regeln, mit denen man definieren kann,wie die Verschmelzung von Modellen gemacht wird. EMF DIff/Merge fokussiert sich aufdie Verschmelzung von Modellen. Dann werden die Differenzen verschmolzen. In dieserSchritt werden auch die von dem Benutzer definierten Strategien beachtet. Zum Schlusskann der Benutzer entscheiden, ob er die Anderungen ubernimmt, oder nicht. AbbildungB.1 zeigt die schematische Darstellung des Prozesses.

2.4.3. Diskussion

Obwohl beide Algorithmen die Berechnung der Differenz und den Vergleich zwischen Mo-dellen anbietet, sind beide komplementar. EMF Diff/Merge bietet eine niedrigere Ebenevon Abstraktion und das fuhrt zu mehr Flexibilitat und Anpassbarkeit der Engine. Daserfolgt durch die Verwendung von Strategien. Es werden auch einige UI Komponentenangeboten, die man wiederverwenden kann. Im Gegensatz zu EMF DIff/Merge wird EMF

20

2.5. Metamodell Repository 21

Funktionalitat EMF Compare EMF Diff/Merge

Erweiterbarkeit ja ja

Strategien nein ja

Erweiterbarkeit ja ja

Dokumentation ja noch keine

Entwickler OBEO und andere Thales Global Services SAS

Community ja fast keine

Ahnlichkeitsgrad UUID und Ahnlichkeitsgrad nur UUID

Lizenz Eclipse Public License 1.0

Version 2.0.0 (12.09.2012) 0.1.1 (17.12.2012)

Nachste Version 2.1.0 (26.06.2013) ?

Tabelle 2.1.: Vergleich zwischen EMF Diff/Merge und EMF Compare

Compare als Endbenutzer-Tool entwickelt. Es existiert aber API, die man verwendenkann.

Beide Rahmenwerke bieten einen Vergleich zwischen Metamodellen nach UUID. Die UUIDsmussen aber gesetzt werden. EMF Compare bietet einen Strukturvergleich zwischen denMetamodellen und kann den Ahnlichkeitsgrad zwischen zwei Metamodellen berechnen,ohne die UUIDs zu verwenden. Damit kann man sehen, welche Metamodelle am nahstensind. EMF Compare existiert seit mehr als 6 Jahren und wird aktiv weiterentwickelt.EMF Diff/Merge ist relativ neu und es gibt kaum Dokumentation und noch fast keineCommunity. Beide sind unter Eclipse Public License 1.0 lizenziert. In der Tabelle 2.1 sinddie Eigenschaften zusammengefasst.

2.5. Metamodell Repository

In diesem Abschnitt werden diverse Technologien zur Persistenz von EMF Modellen undMetamodellen vorgestellt. Zum Schluss werden sie nach den wichtigsten Eigenschaften furdiese Arbeit verglichen und diskutiert.

2.5.1. Dateibasierte Repository

Eine einfache Losung ware die Verwendung von dateibasierter Repository. Die Metamo-delle werden in einem Ordner gespeichert und gelesen. Der Vorteil dieses Ansatzs ist dieleichte Implementierung und die leichte Integration mit anderen Systemen. Der Inhalt derRepository kann ohne spezielle Anwendungen bearbeitet werden und es werden keine spe-zielle Datenbanken benotigt. Die Funktionalitaten wie Versionsverwalgung, Lazy Loadingund Queries sind mit diesem Ansatz nicht moglich.

2.5.2. Eclipse CDO

Das Rahmenwerk Eclipse CDO ist ein Java Modell Repository [cdo13] zur Persistierungvon EMF Modellen und Metamodellen. Der Hauptfokus dieses Repository liegt auf ver-schiedene Versionierungsfunktionen und eine moglichst effizienten Laufzeitverhalten. Das

21


CDO Repository unterstutzt die folgenden Datenbanken: JDBC, Hibernate, Objectivi-tyDB, MongoDB und DB4O. Eine Erweiterung ist die CDO Hibernate store. Sie fokus-siert sich bei der Erstellung von lesbaren und performanten Datenbanken und erlaubteine Integration mit Eclipse Teneo zur Erstellung von automatischen Mapping. EclipseCDO unterstutzt eine parallele Evolution und damit konnen die Modelle gleichzeitig vonmehreren Parteien modifiziert werden [cdo13].

2.5.3. Eclipse Teneo

Teneo ist ein Rahmenwerk, dass die Persistenz mittels Hibernate oder EclipseLink vonEMF-Modellen erlaubt. Die Modelle werden automatisch in einen relationalen Daten-bankschema abgebildet. Das Schema kann uber Java Persistence API (JPA)-Annotationenoder in einer XML-Datei abgebildet werden. Fur Ecore-Modelle erfolgt die Persistierungautomatisch, ohne weitere Mapping. Teneo unterstutzt die Verwendung von Queries wieHibernate Query Language (HQL) oder Enterprise Java Beans Query Language (EJB-QL)[ten13].

2.5.4. EMFStore

EMFStore ist ein Modell-Repository fur EMF, mit dem Modelle kollaborativ geandertund versioniert werden konnen. Es erfolgt Verschmelzung von Modellen und Erkennungvon Konflikten. EMFStore funktioniert ahnlich wie SVN oder CVS und unterstutz dasUpdate/Commit-Paradigm. Das Rahmenwerk kann sowohl Offline als auch Online funk-tionieren. Das Offline-Modus erlaubt dem Benutzer, die Modellen lokal zu andern undnur beim Ein-/Auschecken werden die Modelle mit dem Server synchronisiert. EMFStoreunterstutzt eine interaktive Konflikterkennung bei der Verschmelzung von Modellen. DasOnline-Modus erlaubt eine Echtzeit-Synchronisation mit dem Server. Die Anderungenwerden sofort persistiert. Wenn ein Modell geandert wird, wird auch einen Migratormittels Edapt generiert, mit dem die Modellinstanzen automatisch lokal und serverseitigangepasst werden [emf13c].

2.5.5. Diskussion

Oben wurden drei unterschiedliche Technologien zur Persistenz von ECore-Modelle vorge-stellt. Eclipse Teneo fokussiert sich mehr auf das Mapping von Modellen in relationalenDatenbanken. Das Rahmenwerk ist sehr leicht zu verwenden und uber Hibernate werdenviele relationale Datenbanken unterstuzt. Eclipse CDO unterstutzt die Erstellung vonClient-Server Anwendungen. EMFStore fokussiert sich auf die Speicherung von Metamo-dellen ahnlich wie SVN oder CVS in einer Repository. Es wird sowohl ein Online als auchein Offline Modus unterstutzt. Das Rahmenwerk unterstutzt eine Erkennung von Konflik-ten. Die Tabelle 2.2 bietet einen Vergleich zwischen den vorgestellten Technologien aufeinem Blick.

2.6. Regelbasierte Systeme

Die regelbasierten Systeme automatisieren das Losen von Problemen und bieten die Mog-lichkeit zur Erfassung und Veredelung menschlicher Kompetenz in der Form von Regeln[HR85]. Die Regel werden in einer Regelsprache definiert. Die meist verbreitete Open-Source Rahmenwerke in Java sind JESS und Drools [com13], [pro13]. Es existieren weitereWerkzeuge wie z.B. OpenRules, Mandarax, JLisa, JRuleEngine und viele andere [rul13].

22

2.6. Regelbasierte Systeme 23

Funktionalitat Datei Repository Eclipse CDO EMFStore Eclipse Teneo

Queries nein ja nein ja

Datenbankunabhangig nein ja nein ja

Lazy Loading nein nein ja ja

Online-Modus nein ja ja ja

Offline-Modus ja ja ja ja

Versionsverwaltung nein ja ja nein

Konfliktenerkennung nein nein ja nein

Client-Server Architecture nein ja ja nein

Automatische Mapping nein ja ja ja

Tabelle 2.2.: Vergleich zwischen Datei Repository, Eclipse CDO, EMFStore und EclipseTeneo

Fur die prototypische Entwicklung ist es aber ausreichend, nur die meistverbreitete zubetrachten.

JESS ist ein regelbasiertes System, die von Santa National Laboratiories entwickelt wurde.Mit JESS konnen Regeln deklarativ beschrieben werden. Beide verwenden modifizierteVersionen von ”Rete: A Fast Algorithm for the Many Pattern/ Many Object Pattern MatchProblem”. Drool ist mehr als ein regelbasiertes System - ein Geschaftslogik-Plattform zurBeschreibung von Regen, Arbeitsablaufe und Event-Handling.

Die deklarative Beschreibung von Regeln bringt mehr Flexibilitat und Erweiterbarkeit alssie im Quellkode fest zu kodieren. Diese Vorteile bergen auch Nachteile, wie Komplexi-tat, eine steile Lernkurve, Notwendigkeit zusatzlicher Software (namlich die Regelmaschineselbst) sowie erhohten Testaufwand. [Jef13] untersucht die Performanz zwischen Drools4, 5 und JESS [Sta07]. Diese Information und andere sind Tabelle 2.3 zu sehen. JESSverbraucht weniger Speicher aber beim Laden und ausfuhren von Regeln ist er deutlichlangsamer als Drools. Es gibt keine großen Unterschiede zwischen Drools 4 und 5 unddeswegen werden sie zusammen betrachtet. Beide Rahmenwerke verwenden Rate als Al-gorithmus und bieten jeweils ein Plugin fur Eclipse. Drools bietet eine Regel RepositoryGuvnor7 zur Verfugung.

7Drools Guvnor - http://www.jboss.org/drools/drools-guvnor.html

23

http://www.jboss.org/drools/drools-guvnor.html


Funktionalitat JESS Drools

Algorithmus Rete Rete

Rule Firing Time + ++

Data Load Time – ++

Speicherverbrauch ++ +

in Eclipse integrierbar ja ja

Repository nein ja

Lizenz frei fur akademische Zwecke simplified ASL/BSD/MIT

Tabelle 2.3.: Vergleich zwischen JESS und Drools

24

3. Anforderungen an das Verfahren

In diesem Kapitel werden die Anforderungen an die Methodik zur Wiederverwendung vonMetamodellen in ModelJoin-Sichten beschrieben. Diese Anforderungen werden die Ent-wicklung des Losungskonzepts unterstutzen und sollen fur die Evaluation einer moglichenRealisierung verwendet werden. Als Anwendungsdomain wird eine Erweiterung des Mo-delJoin betrachtet, die den Entwickler beim Entwurf neuer Sichten unterstutzt. Es wirdein Anwendungsszenario beschrieben, das zur Ableitung der Anforderungen dient. DieAnforderungsanalyse wird nach [Rup07] gemacht. Diese Anforderungen bilden die Basisfur die Entwicklung des Losungskonzepts und sollen fur die Evaluation einer moglichenRealisierung verwendet werden.

3.1. Anwendungsszenario

Michael ist ein Softwareentwickler bei der KIT-Bibliothek. Wegen Platzbedarf mussenviele Bucher aussortiert werden. Um festzulegen, welche Bucher aussortiert werden sollen,will er fur die Bucher eine Bewertung bekommen. Dafur will er die Buchrezensionenvon Amazon verwenden. Aus den KIT- und Amazon-Metamodellen will er ein neuesMetamodell bzw. Sichtentyp entwerfen. Er will noch, dass die neuen Sichten des erzieltenMetamodells automatisch generiert werden. Weil es bereits ein Metamodell fur die KIT-Bibliothek gibt und die Bibliothek-Verwaltungssoftware modellbasiert entwickelt wurde,kann ModelJoin verwendet werden. Weil die beiden Quellen eine enorme Menge vonInformation beinhalten, soll wahrend des Entwurfs nur bei Bedarf die neuen Modellenerzeugt werden. Er will auch uberwachen, ob die neue Sicht mit der alten konform ist,weil er fur diese bestehende Sicht schon ein Tool entwickelt hat, das in der Bibliothekohne Anpassung verwendet wird. Das soll im Hintergrund passieren, so dass die Arbeitvon Michael ungestort bleibt. Bei einer Anderung der ModelJoin-Query will er sehen, obein neues Metamodell generiert wird. Die Uberprufung, wann ein Metamodell generiertwird, erfolgt durch Regeln (Konformitatsbedingungen). Sie uberprufen die Konformitatzwischen dem neu genenerierten Metamodell und seiner alten Version. Wenn sie verletztist, wird ein neues Metamodell generiert. Deswegen will Michael bei einer Verletzung derKonformitatsbedingungen benachrichtigt werden. Die Benachrichtigung soll genau zeigen,welche die Ursache der Konformitatsverletzung ist. Außerdem will er die Uberprufungvon den Konformitatsbedingungen fur seine eigene Zwecke anpassen. Dafur braucht ereine Schnittstelle. Er will seine Entwurfsfortschritte in einer Repository speichern und

25

26 3. Anforderungen an das Verfahren

wiederverwenden. Ausserdem will er beim Entwurf mittels einer Art von Ranking sehen,ob Metamodelle bereits existieren, die ahnlich zu seinem Ziel-Metamodell sind. Bei derEntwicklung einer Query will er eine von den bereits existierenden Queries anpinnen unddiese standig mit den entwickelten Query vergleichen, bis das Ziel-Metamodell passt.

3.2. Anforderungen

In diesem Abschnitt werden aus dem oben beschriebenen Anwendungsszenario Anforde-rungen abgeleitet. Sie werden nach den in (p. 227 – 235)[Rup07] vorgestellten Anfor-derungsschablone definiert. Zuerst werden die Stakeholder erkannt und dann werden diefunktionellen und nichtfunktionellen Anforderungen beschrieben.

3.2.1. Stakeholder

Aus dem Anwendungsszenario werden zwei Stakeholder nach der Definition von [SFG99]erkannt:

• S1 ModelJoin:ModelJoin generiert die neuen Zielmetamodelle, die uberpruft werden mussen, ob siemit einem Metamodell in der Repository kompatibel sind. Dann wird das Metamo-dell bzw. das kompatible Metamodell an ModelJoin zuruckgeliefert.

• S2 Entwickler:Der Entwickler( in dem Anwendungsszenario als Michael bekannt) bedient ModelJoinund damit erstellt er die Anderungen im Modell.

3.2.2. Funktionale Anforderungen

Die funktionale Anforderungen beschreiben, wie ein Benutzer mit dem System interagiert.Sie beschreiben auch die Geschaftsfunktionalitaten des Systems [Lef11]. Die folgendenAnforderungen werden fur die Konzeption dieser Ausarbeitung definiert:

• F1 Anpassung der Konformitatsbedingungen:Das System soll dem Benutzer ein API zur Anpassung von den Konformitatsbedin-gungen dem Benutzer zur Verfugung stellen.

• F2 Auswahl der Modellversionen:Jederzeit wird das System fahig sein, eine Auswahl der Modelversionen aus derMetamodell-Repository zum Vergleich anzubieten, so dass die geschriebene Querystandig mit einer anderen verglichen wird.

• F3 Anzeige der Probleme:Bei der Verletzung einer oder mehrerer Konformitatsbedinungen soll das System denBenutzer benachrichtigen.

• F4 Vergleich der Metamodelle nach Ahnlichkeit:Das System soll dem Benutzer die Moglichkeit bieten, die Metamodelle in der Repo-sitory nach Ahnlichkeitsgrad zu vergleichen.

• F5 Uberprufung der Wiederverwendung von Metamodellen:Beim Speichern einer Query soll das System die die Wiederverwendung von Meta-modellen uberprufen.

26

3.2. Anforderungen 27

• F6 Vergleichsprozess 1:Das System soll dem Benutzer die Moglichkeit bieten, das entwickelte Metamodellmit dem in der Repository nach Ahnlichkeitsgrad Metamodell zu vergleichen.

• F7 Vergleichsprozess 2:Das System soll dem Benutzer die Moglichkeit bieten, das Metamodell anzupinnenund Queries solange refaktorieren, bis das Ziel-Metamodell passt.

• F8 Keine miteinander konforme Metamodelle in der Repository:Das System soll gewahrleisten, dass es keine Metamodellen in der Repository exi-stieren, die miteinander konform sind.

3.2.3. Nicht-funktionale Anforderungen

Die nicht-funktionalen Anforderungen beschreiben die qualitativen Eigenschaften des Sy-stems. Die folgenden Anforderungen sind von dem Anwendungsszenario abgeleitet:

• NF1 Lose Koplung:Das System soll so entworfen werden, dass sie keine feste Kopplung mit ModelJoinhat.

• NF2 Umgebung:Das System soll in Java als Eclipse-PlugIn entwickelt werden.

• NF3 Beschreibung einer Konformitatsverletzung:Das System soll eine klare Beschreibung der Konformitatsverletzung geben.

• NF4: Validierung der Konformitatsuberprufung:Die Konformitatsuberprufung soll auf ihre Richtigkeit uberpruft und validiert wer-den.

27

4. Losungsansatz

In den vorangegangen Kapiteln sind die Grundlagen und Stand der Technik beschrieben.Im Kapitel 3 sind die Anforderungen der Konzeption und die prototypische Entwicklungauf Basis eines Beispiels definiert. Dieses Kapitel beschreibt den Losungsansatz dieser Di-plomarbeit, der auf den vergangenen zwei Kapiteln basiert. Im ersten Unterkapitel werdeneinige Voruberlegungen vorgestellt. Dann wird die Konzeption entworfen. Danach wirdeine Architektur auf Basis der Konzeption mit der Hilfe von UML Diagrammen vorge-stellt. Folgend wird die prototypische Entwicklung der Konzeption und der Architekturbeschrieben.

4.1. Voruberlegungen

Es wird ein Konzept fur die Wiederverwendung von Metamodellen in ModelJoin-Sichtenerstellt. Der Ablauf kann wie folgt grob beschrieben werden: Beim Speichern einer Querywird von ModelJoin ein neues Ziel-Metamodell generiert. Das Ziel-Metamodell wird andieser Methodik ubergeben und es wird uberpruft, ob ein oder mehrere Metamodelle ineiner Repository existieren, die alle moglichen Instanzen des Ziel-Metamodells unterstut-zen. Wenn es solche Metamodelle existieren, dann werden die zuruckgeliefert. Wenn eskein solches Metamodell existiert, dann wird es in der Repository gespeichert.

Fur die Realisierung der Konzeption ergeben sich die folgenden technischen und wissen-schaftlichen Fragen:

• Wissenschaftliche Fragen

– Wann ist ein Metamodell wiederverwendbar? Welche Anforderungen mussenerfullt werden?

– Aus welchen Komponenten soll die Architektur bestehen und wie werden dieKomponente realisiert?

– Welche Anforderungen haben die unterschiedlichen Komponente?

• Technische Fragen

– Wo werden die Metamodelle gespeichert?

29

30 4. Losungsansatz

– Wie kann die Architektur generisch gemacht werden, so dass sie von der Reali-sierung unabhangig bleibt?

– Wie werden die Komponente technisch realisiert?

– Wie wird die Konzeption dieser Arbeit in ModelJoin integriert?

– Soll die Methodik an den Anforderungen des Benutzers anpassbar sein?

Die nachsten Abschnitte dieser Kapitel sollen eine Antwort dieser Fragen geben.

4.2. Konzeption

Um die Wiederverwendung von Metamodellen in ModelJoin-Sichten zu ermoglichen, mus-sen zuerst die bereits generierten Metamodellen persistiert werden. Deswegen soll zuerstein Persistenz-Rahmenwerk zur Erstellung einer Repository aus dem in Kapitel 2.5 vorge-stellten Technologien ausgewahlt werden. Bei der Erstellung einer neuen ModelJoin-Querywird uberpruft, ob ein wiederverwendbares Metamodell in dieser Repository existiert. Da-fur muss die Differenz von jedem Metamodell in der Repository mit dem neu generiertenMetamodell berechnet werden und die Differenz soll mittels Regeln ausgewertet werden.Diese Auswertung wird in dieser Arbeit Konformitatsuberprufung genannt. Sie werden inKapitel 4.2.3.2 definiert.

Die Abbildung 4.1 stellt eine grafische Darstellung des Konzepts dar. Um zu uberprufen,ob ein wiederverwendbares Metamodell bereits existiert, wird das Ziel-Metamodell mitjedem Metamodell aus der Repository auf Wiederverwendbarkeit untersucht. Die Unter-suchung besteht aus einer Berechnung der Differenz zwischen den Metamodellen und dieUberprufung, ob alle Anderungen das Metamodell generalisieren. Jede Komponente diesesDiagramms werden in den folgenden Unterkapiteln beschrieben.

Ziel-Metamodell Metamodell-Repository

Diff(A,B)

Diff Engine

Konformitätsüberprüfung(A,B)

Abbildung 4.1.: Konzept Ubersicht

4.2.1. Metamodell Repository

Die Metamodell-Repository dient zur Speicherung und Verwaltung von den Metamodellen.Bei der Erstellung einer neuen Version von einem Metamodell wird diese in der Repositorygespeichert.

30

4.2. Konzeption 31

Die Komponente soll uberprufen, dass es keine Elemente in der Repository existieren,die miteinander konform sind. Damt ist die Repository minimal gehalten. Es soll beimHinzufugen von einem Metamodell uberpruft werden, ob andere Metamodelle mit diesemMetamodell konform sind.

4.2.2. Diff Engine

Die Aufgabe dieser Komponente ist die Berechnung der Differenz von zwei Metamodellen.

Es bestehen zwei Moglichkeiten ein Diff zu berechnen. Die erste ist die Erstellung einerDifferenz auf Sprachebene. Das ist aber unpraktikabel, weil man nicht immer die alteModelJoin-Anfrage im Ziel-Metamodell-Repository zur Verfugung hat. Die zweite Mog-lichkeit ist die Berechnung der Differenz auf der Target-Metamodellebene berechnet unddiese Anderungen werden analysiert.

Die Abblidung 4.2 stellt eine Differenz als Klassendiagramm dar. Die einzelnen Elementender Klasse IDiff werden in Kapitel 4.2.3.2 beschrieben.

getKind():DiffKindgetSource():IMetamodelgetType():DiffTypegetValue():EObjectgetOldParent():EObjectgetNewParent():EObjectgetParameter():String

IDiff

Abbildung 4.2.: IDiff Klassendiagramm

4.2.3. Konformitatsbedingungen

Um zu uberprufen, ob ein Metamodell mit einem anderen konform ist, muss eine eindeutigeDefinition von Konformitat in dieser Ausarbeitung gegeben werden. Diese Definition wirdim Rahmen der Arbeit verwendet werden. Sie ist auf der Definition von model preservingvon [HBJ09] und [Wac07] basiert.

Definition 1. Ein Metamodell ist zu einem zweiten Metamodell konform, wenn alle mog-lichen Instanzen von diesem auch mogliche Instanzen zu dem zweiten Metamodell sind.

Die Konformitat wird mit der Hilfe von Regeln uberpruft. Diese Regeln werden auf dieDifferenzebene zwischen den beiden Metamodellen angewendet. Fur jede Differenz wird esuberpruft, ob sie breaking and resolveable oder breaking and not resolveable ist [BGGK07].Wenn das der Fall ist, werden die Metamodelle als nicht konform bestimmt.

Jede Regel hat zwei Teilen. Der erste Teil – when beschreibt die Kondition, wann dieRegel erfullt ist. Mit den Operatoren and und or werden die Bedingungen gebildet. Imfolgenden werden die moglichen Bedingungen erklart. Jede Kondition besteht aus einemParameter und einem Wert.

• type:Der Parameter type beschreibt den Typ einer Anderung. Es gibt zwei moglichenWerten namlich ReferenceChange und AttributeChange. ReferenceChange tritt auf,wenn eine Referenz zwischen zwei ECore-Features geandert wird. AttributeChangebeschreibt alle Anderungen einer Attributeigenschaft.

31

32 4. Losungsansatz

• kind:Der Parameter kind beschreibt die Aktion einer Anderung. Es gibt drei moglichenWerten namlich Add, Delete und Move. Add tritt auf, wenn ein neues Elementhnzugefugt wird. Delete tritt beim Loschen eines Elements auf. Wenn ein Elementsein containment geandert wird, wird mit der Aktion Move bezeichnet.

• parameter:Mit parameter wird bezeichnet welche ECore-Attribute geandert werden.

• weitere Konditionen:Um die Uberprufung bestimmter Eigenschaften einer Anderung zu uberprufen, wer-den spezielle Konditionen definiert. Diese Konditionen sind als Code-Snippets imAnhang C dargestellt.

Der zweite Teil – (then) beschreibt was nach der Erfullung dieser Regel gemacht wird.Wenn eine Regel erfullt ist, dann ist die Konformitat verletzt. Deswegen liefert jede Regeleine Fehlermeldung (ERROR) als Ergebnis zuruck.

Die Regeln sind im Pseudocode definiert. Die implementierten Regeln werden mit droolsimplementiert und befinden sich im Anhang D.

Eine Differenz beinhaltet nur einfache Anderungen wie z.B. Anderung eines Attributesoder Loschen einer leeren Klasse. Komplexere Anderungen werden als mehrere einfachenAnderungen dargestellt [BVR96], [AP03].

Mit Beispielen werden die interessanten Falle beschrieben, wie eine Konformitatverletzungauftritt. Jede Abbildung besteht aus drei Teilen. Oben links steht das alte Metamodell.Oben rechts ist die veranderte Version dargestellt. Unten werden die Instanzen von demoriginalen Metamodell angezeigt, die auch Instanzen bei den neuen Metamodell seien sol-len.

In den folgenden Unterabschnitten werden die Regeln vorgestellt Sie verwenden die Klas-sifizierungen von [BGGK07] und [BG10]. Sie werden in zwei Gruppen geteilt. Die ersteGruppe beschreibt alle Existenzanderungen. Das sind Anderungen, wenn ein Metamodel-lelement geloscht, verschoben oder hinzugefugt wird. Die zweite Gruppe beinhaltet allemogliche Eigenschaftsanderungen. Die Gruppierung wird nach [BG10] gemacht.

Es wird angenommen, dass die Metamodelle keine Fehlern enthalten und validiert sind,d.h. wenn zum Beispiel eine Enum geloscht wird, darf dieses Element nicht als Attribut-Typ in einer Klasse verwendet wird.

Eine hierarchische Struktur von ECore ist im Anhang auf der Abbildung B.2 dargestellt.

4.2.3.1. Regeln fur Existenzanderungen

In diesem Abschnitt werden die Regeln beschrieben, die die Existenzanderungen uberpru-fen. Eine Existenzanderung tritt auf, wenn ein Element auf der Metamodellebene erstellt,geloscht oder verschoben wird.

• EClass: EClass stellt das Metamodell zur Modellierung von Klassen dar. DieErstellung von neuen Klassen verletzen die Konformitatsbedingung nicht, weil dieseKlassen noch keine Instanzen auf Modellebene haben. Beim Loschen einer Klassewird die Konformitat verletzt.

32

4.2. Konzeption 33

– delete: Wenn eine Klasse geloscht wird, kann es sein, dass es bereits Instanzenauf Modellebene von dieser Klasse existieren und sie sind nicht mehr mit demneuen Metamodell konform. Auf der Abbildung 4.3 wird die Klasse Book ge-loscht. Die existierende Instanz Book:theBook ist nicht mehr mit dem neuenMetamodell kompatibel, weil sie auf Metamodellebene nicht reprasentiert ist.Die Regel, die eine solche Anderung erkennt ist auf dem Code-Snippet 4.1 zusehen.

when type == ReferenceChange and kind==”Delete” and parameter ==”eClassifiers”

then ERROR

Listing 4.1: ReferenceChange EClass: delete

Booktitle: String

Book:theBooktitle="The Book"

Booktitle: String

Abbildung 4.3.: Beispiel: Konformitatsverletzung bem Loschen einer Klasse

• EAttribute: Mit EAttribute werden die Attribute einer Klasse modelliert. Siebesitzen einen Namen, einen Typ(EDataType) und eine Unter- und Obergrenze derKardinalitat.

– add: Beim Hinzufugen von neuen Attributen, mussen diese eine Unter-grenze(lower bound) gleich 0 haben. Wenn diese Grenze großer als 0 ist, istdie Konformitat verletzt. Zur Klasse Book wird in Abbildung 4.4 ein neuesAttribut hinzugefugt. Mit einer Untergrenze von 1 verletzen die Instanzen alterMetamodell die Konformitat, weil es kein Wert fur author gesetzt ist. Deswegenmuss es auch uberpruft werden, ob der Vorgabewert(default value) gesetzt ist.Diese Logik ist in der Regel auf dem Code-Snippet 4.2 abgebildet.

when type == ReferenceChange and kind==”Add” andparameter==”eStructuralFeatures” and (attribute.lower bound>0 orattribute.default value!=null)

then ERROR

Listing 4.2: ReferenceChange Attribute: add

– delete: Wenn ein Attribut geloscht wird, werden die Instanzen dieses Attributsinkompatibel. Wenn der Attribut zu einer Superklasse verschoben wird, bleibtdiese Anderung konform. Mit der Methode isPullUpFeature() wird dieser Falluberpruft. Die Java-Implementierung dieser Methode ist auf der Abbildung 6.4dargestellt. Die Methode isParentAbstract() uberpruft, ob die Klasse diesemAttribut abstrakt ist. Wenn dass der Fall ist, dann konnen keine Instanzendieser Klasse existieren.Die Regel, die eine solche Anderung erkennt ist auf demCode-Snippet 4.3 dargestellt.

33

34 4. Losungsansatz

Booktitle: String

Booktitle: Stringauthor: String

Book:theBooktitle="The Book"author = ?

Abbildung 4.4.: Beispiel: Konformitatsverletzung bem Hinzufugen von einem Attribut

when type == ReferenceChange and kind==”Delete” andparameter==”eStructuralFeatures” and !isPullUpFeature() and!isParentAbstract()

then ERROR

Listing 4.3: ReferenceChange Attribute: delete

Book:theBooktitle="The Book"author = "Max Muster"



Abbildung 4.5.: Beispiel: Konformitatsverletzung beim Loschen von einem Attribut

• EReference: Eine Referenz (EReference) beschreibt eine Beziehung in ECorezwischen genau zwei Klassen. Das Element EReference besitzt ein Typ(EDataType)und eine Unter- und Obergrenze.

– add: Wenn eine neue Referenz definiert wird, soll ihre Untergrenze gleich 0sein. Bei einer Untergrenze großer als 0 tritt eine Verletzung der Konformitatauf. In diesem Fall sind alle Instanzen auf Modellebene nicht kompatibel, weildie Referenz fruher nicht existiert hat. Die Regel auf dem Code-Snippet 4.4erkennt eine solche Anderung.

when type == ReferenceChange and kind==”Add” andparameter==”eStructuralFeatures” and attribute.lower bound>0

then ERROR

Listing 4.4: ReferenceChange EReference: add

– delete: Beim Loschen einer Referenz ist diese Anderung nicht konform. Wenndie Referenz zu einer Superklasse verschoben wird, bleibt diese Anderung kon-form. Wenn die Referenz. Wenn die Referenz aus einer abstrakten Klasse ge-loscht wird, ist diese Anderung konform. Die Hilffunktionen isPullUpFeature()und isParentAbstract() sind auf den Code-Snippets 6.4 bzw. 6.5 dargestellt.Diese Logik ist in der Regel auf dem Code-Snippet 4.5 abgebildet.

34

4.2. Konzeption 35

when type == ReferenceChange and kind==”Delete” andparameter==”eStructuralFeatures” and !isPullUpFeature() and!isParentAbstract()

then ERROR

Listing 4.5: ReferenceChange EReference: delete

– move: Wenn ein EClassifier in die hierarchische Struktur verschoben wird, istdiese Anderung nicht konform.

when type == ReferenceChange and kind==”Move” andparameter==”eClassifiers” and !isPullUpFeature()

then ERROR

Listing 4.6: ReferenceChange EReference: move

• EPackage: EPackage stellt ein Paket in EMF dar. Die Erstellung von Paketenverletzt die Konformitat nicht, weil es keine Instanzen auf Metamodellebene exi-stieren. Das Loschen eines Pakets ist konform, wenn das Paket leer ist. Wenn beimLoschen das Paket Klassen oder Enums beinthaltet, wird diese Operation von ECoreals mehrere Operationen erkannt. Das Loschen und Erstelle eines Paketes wirkt aufModellebene nicht.

• EOperation: Mit EOperation werden die Operationen definiert, die aus einerKlasse aufgerufen werden konnen. Die Erstellung und das Loschen von neuen Opera-tionen verletzt die Konformitat nicht, weil Operationen keinen Einfluss auf Instanzendes Modells haben.

• EEnum: Mit EEnum werden die Enums modelliert. Beim Hinzufugen von neuenEEnums gibt es keine Konformitatsverletzungen, da es keine Instanzen existieren. Eswird angenommen, dass die Metamodelle konsistent sind. Wenn ein Enum geloschtwird, dann darf er in anderen Elementen nicht verwendet werden.

• EEnumLiteral: Mit diesem Element werden die moglichen Werten von einemEEnum definiert. Beim Loschen wird die Konformitat verletzt. Die Erstellung vonneuen Elementen ist konform.

– delete: Wenn EEnumLiteral geloscht wird, dann fuhrt diese Anderung zur einerVerletzung der Konformtat. Die Abbildung 4.6 zeigt ein Beispiel fur solcheVerletzung.

when type == ReferenceChange and kind==”Delete” andparameter==”eLiterals”

then ERROR

Listing 4.7: ReferenceChange EEnumLiteral: delete

4.2.3.2. Anderung einer Eigenschaft

In diesem Abschnitt werden die Anderungen einer Eigenschaft von ECore-Elementen be-schrieben. Auf der Abbildung B.2 im Anhang ist die hierarchische Struktur von ECorezu sehen. Sie zeigt, dass die Eigenschaften allen modellierbaren Elementen in ECore ab-decken.

35

36 4. Losungsansatz

HARDSOFT

«enumeration»CoverBook

String: titleCover: cover

HARDSOFT

«enumeration»CoverBook

String: title

Book:theBooktitle="The Book"cover = Cover.SOFT

Abbildung 4.6.: Beispiel: Konformitatsverletzung beim Loschen von einem EEnumLiteral

• ENamedElement: Die Schnittstelle”ENamedElement” beschreibt die Elemente,

die einen Namen haben. Die meisten Elemente in der ECore Modell implementierendieses Interface.

– name: Wenn der Name eines Metamodell-Element geandert wird, dann mussendie Modelle angepasst werden. Diese Anderung ist nach [BG10] breaking andresolveable, wenn es keine UUID existiert. Im ModelJoin-Kontext werden keineUUIDs generiert und deswegen verletzt eine solche Anderung die Konformitat.

when type == AttributeChange attribute name == ”name”then ERROR

Listing 4.8: PropertyChange ENamedElement: name

• EPackage: EPackages dienen zur Gruppierung von verwandten Klassen und Da-tenTypen.

– nsURI: Namespace URI. Diese Anderung ist reaking and resolveable.

when type == AttributeChange and attribute name ==”nsURI”then ERROR

Listing 4.9: PropertyChange EPackage: nsURI

– nsPrefix: Namespace Prefix. Diese Anderung ist breaking and resolveable.

when type == AttributeChange attribute name ==”nsPrefix”then ERROR

Listing 4.10: PropertyChange EPackage: nsPrefix

• ETypedElement: Die ECore-Klasse ETypedElement stellt alle Elemente, die typi-siert sind. Das sind die Klassen EAttribute, EReference, EOperation und EParameter[MS09].

– unique: Diese Eigenschaft beschreibt, ob ein Attribut mehrere gleiche Instanzendieses Elements auf Modellebene erstellt sind. Wenn der alte Wert

”false” ist

und dieser auf”true” gesetzt wird, fuhrt diese Anderung zu einer Konformitats-

verletzung. Wenn es auf Modellebene Modelle existieren, die der gleiche Werthaben, sind sie nicht einzigartig. Das verletzt die Konformitat.

36

4.2. Konzeption 37

when type == AttributeChange and parameter==”unique” andparameter.old value==false and parameter.new value==true

then ERROR

Listing 4.11: PropertyChange ETypedElement unique

– lower bound: Die Eigenschaft lower bound beschreibt die untere Grenze einerKardinalitat. Wenn diese erhoht wird, fuhrt diese Anderung zu einer Spezia-lisierung des Metamodells. Dann wird die Konformitat verletzt, weil Modelleexistieren werden konnen, die diese Grenze unterschreiten. Die Verringerungdes Wertes fuhrt zu einer Generalisierung und verletzt die Konformitat nicht.

when type == AttributeChange and parameter==”lower bound” andparameter.old value< parameter.new value

then ERROR

Listing 4.12: PropertyChange ETypedElement: lower bound

– upper bound: Die Eigenschaft upper bound beschreibt die obere Grenze einerKardinalitat. Wenn diese verringert wird, wird dann die Konformitat verletzt,weil sie von existierenden Modellen konnen, die diese Grenze uberschritten.Eine Erhohung dieses Wert fuhrt zu einer Generalisierung des Metamodellsund es beszteht keine Konformitatsverletzung.

when type == AttributeChange and parameter==”upper bound” andparameter.old value< parameter.new value

then ERROR

Listing 4.13: PropertyChange ETypedElement: upper bound

– eType: Diese Eigenschaft beschrebt den Typ von einem ETypedElement. EineAnderung von diesem Attribut verletzt die Konformitat. Eine Uberprufung,ob der neue Wert eine Superklasse von den alten ist, ist nicht notig. In ECorebeinhaltet die DataType primitive Typen und dieser Fall kommt nicht vor.

when type == AttributeChange and parameter==”eType” then ERROR

Listing 4.14: PropertyChange ETypedElement: eType

• EStructuralFeature:

– volatile: Wenn volatile==True ist, wird es fur dieses Element kein Speicher-feld gesetzt. Es werden nur leere getter und setter Methoden generiert, die perHand implementiert werden sollen [MS09]. Bei einer Anderung von True nachFalse erwartet das Metamodell ein Wert von den Instanzen, die nicht existieren.Wenn volatile von False nach True geandert wird, sollen die leeren Methodenimplementiert werden. Deswegen verletzt die Anderung dieser Eigenschaft im-mer die Konformitat.

when type == AttributeChange and attribute name ==”volatile”then ERROR

Listing 4.15: PropertyChange EStructuralFeature: volatile

37

38 4. Losungsansatz

– transient: Die Eigenschaft transient beschreibt, ob ein Attribut oder Referenzserialisiert wird oder nicht [MS09]. Wenn der Wert dieser Eigenschaft vonTrue nach False geandert wird, ist es nicht klar, was fur einen Wert diese At-tributen/Referenzen haben. Die Umstellung von False nach True ist von derImplementierung von dem Editor abhangig, wie die transitive Werte behandeltwerden. Deswegen wird eine Anderung dieser Eigenschaft als nicht konformerkannt.

when type == AttributeChange and attribute name ==”transient”then ERROR

Listing 4.16: PropertyChange EStructuralFeature: transient

– unsettable: Unsettable beschreibt, ob ein Element einen undefinierten Wertbesitzen kann [MS09]. Wen zum Beispiel ein Boolean definiert wird und un-settable=true ist, dann bekommt dieser Attribut drei mogliche Werte namlichtrue, false und undefinierten Wert. In diesem Beispiel, wenn ”unsettable” auffalse gesetzt wird, dann wird die Konformitat verletzt.

when type == AttributeChange and attribute name ==”unsettable”parameter.old value==true and parameter.new value==false

then ERROR

Listing 4.17: PropertyChange EStructuralFeature: unsettable

– derived: Die Eigenschaft beschreibt, ob ein Feature aus anderen Werten berech-net wird [MS09]. Jede Anderung dieser Eigenschaft verletzt die Konformitat.

when type == AttributeChange and attribute name ==”derived”then ERROR

Listing 4.18: PropertyChange EStructuralFeature: derived

• EReference: EReference wird zur Beschreibung von Assoziationen zwischen Klas-sen verwendet.

– containment: Jede Anderung dieser Eigenschaft fuhrt zur Verletzung der Kon-formitat. Die Eigenschaft beschreibt, dass ein Element nur zu einem Containergehort und es gibt immer eine gegenseitige Referenz [MS09].

when type == AttributeChange and attribute name ==”containment”then ERROR

Listing 4.19: PropertyChange EReference: containment

– eOpposite: Wenn eine gegenseitige Referenz erstellt wird, verletzt sie die Kon-formitat. Auf der Abbildung 4.7 sind die Klassen Book und Person dargestellt.Die Klasse Book enthalt eine Referenz nach Person, die die Einkaufer des Bu-ches darstellt. Die zweite Referenz ist von Person nach Book. Diese Referenzbeschreibt die Lieblingsbucher einer Person. Wenn die Referenzen als eine zwei-seitige Referenz uber das Setzen von eOpposite erstellt wird, dann sollte es gel-ten dass alle Personen, die ein Buch gekauft haben, soll das ein Lieblingsbuchsein. Das gilt aber nicht in allen Fallen und deswegen sind solche Anderungennicht konform. Wenn die gegenseitige Referenz geloscht wird, besteht es keineKonformitatsverletzung.

38

4.2. Konzeption 39

when type == AttributeChange and attribute name ==”eOpposite” andnewValue!=null and oldValue==null

then ERROR

Listing 4.20: PropertyChange EReference: eOpposite

BookString: titleCover: cover

PersonString: titleInt: birthYear

bought byfavorite

0..*0..*

Abbildung 4.7.: Beispiel: Konformitatsverletzung beim Andern von eOpposite

• EAttribute: EAttribute beschreibt modellierte Attribute. Ein Attribut enthaltid, Typ und Name.

– id: Bei einer Anderung der Id wird die Konformitat verletzt [BGGK07]. Dastritt auf, wenn es zwei oder mehreren Objekte existieren, die das gleiche Attributbesitzen. Das verletzt die Einzigartigkeit des Attributes.

when type == AttributeChange and attribute name ==”id” andold value==false and new value==true

then ERROR

Listing 4.21: PropertyChange EAttribute: id

• EClass: EClass reprasentiert eine modellierte in EMF Klasse. Eine Klasse hat diefolgenden Eigenschaften:

– abstract: Eine Verletzung tritt auf, wenn eine Klasse abstrakt gemacht wird(false=>true). Das Problem tritt auf, wenn mit dem alten Metamodell Instan-zen dieser Klasse erstellt sind. Die abstrakten Klassen durfen keine Instanzenbesitzen. Deswegen sind diese Instanzen mit dem neuen Metamodell nicht kom-patibel.

when type == AttributeChange and attribute name ==”abstract” andparameter.old value==false and parameter.new value==true

then ERROR

Listing 4.22: PropertyChange EClass: abstract

– interface: Wenn eine Klasse in einem Interface umgewandelt wird, fuhrt dieseAnderung zur Konformitatsverletzung(false=>true). Bei dieser Anderung darfdiese Schnittstelle keine Instanzen haben. Das furhrt zu einer Inkonsistenz aufModellebene.

when type == AttributeChange and attribute name ==”interface” andparameter.old value==false and parameter.new value==true

then ERROR

Listing 4.23: PropertyChange EClass: interface

– supertype: Wenn zu einer Klasse ein Supertyp hinzugefugt oder geloscht wird,sollen die Untergrenzen von den vererbten Referenzen und Attributen uberpruft

39

40 4. Losungsansatz

werden. Die Untergrenze soll gleich 0 sein. Wenn die Untergrenze großer 0 ist,mussen die Instanzen auf Modellebene diese Einschrankung erfullen. Da es dieseReferenzen und Attribute auf Modellebene noch nicht existieren, konnen siediese Anforderung nicht erfullen. Diese Uberprufung wird mittels der MethodecheckSupertypebounds() gemacht. Die Java Implementierung dieser Methodeist auf dem Code-Snippet 6.7 im Anhang dargestellt. Die Regel, die eine solcheAnderung erkennt ist auf dem Code-Snippet ?? dargestellt.

when type == ReferenceChange, parameter==”eSuperTypes” andcheckSupertypeBounds()

then ERROR

Listing 4.24: ReferenceChange EClass: supertype

Wahrend der Validierung werden in Kapitel 5 Kombinationen von den atomaren Ande-rungen untersucht. Die definierten Operationen von [HVW11] bestehen aus mehrerenatomaren Anderungen und damit wird es gepruft, dass die Regeln vollstandig sind.

4.3. Architektur

In diesem Abschnitt wird die Architektur von dem in Kapitel 4.2 vorgestellten Konzeptentworfen. Zuerst werden die wichtigsten Komponenten der Architektur und deren beno-tigten und angebotenen Schnittstellen vorgestellt. Im nachsten Abschnitt wird der Zusam-menhang von dieser Arbeit mit ModelJoin vorgestellt. In der Kapitel 4.5: PrototypischeEntwicklung wird die Architektur verfeinert und mittels Klassendiagramme und Zustands-diagramme erlautert.

In der Abbildung 4.8 ist mit der Hilfe eines Komponentendiagramms der Zusammenhangzwischen den verschiedenen Komponenten dargestellt. Im Mittelpunkt steht ComplianceValidator. Die Komponente enthalt die Logik dieser Arbeit und uberpruft die Wieder-verwendung von Metamodellen. Um die Wiederverwendung zu uberprufen, benotigt sieMetamodel Repository, Difference Engine, ModelJoin und Compliance Policy Registry. DieKomponente Compliance Validator stellt eine Benutzerschnittstelle zur Verfugung, die imKomponentendiagramm als UI Komponente bezeichnet ist. Im folgenden werden die ein-zelnen Komponenten beschrieben.

• Compliance Validator: Die Komponente Compliance Validator enthalt dieUbeprufung der Konformitat von Metamodellen. Hier wird es uberpruft, ob zweiMetamodelle miteinander konform sind. Sie beinhaltet die Logik zur Berechnungder Kompatibilitat zwischen Metamodellen. Um das zu berechnen, braucht dieseKomponente einen Zugriff auf die Metamodel Repository, Compliance Policy Regi-stry, DifferenceEngine und ModelJoin. Die Komponente ModelJoin soll ein Exten-sion Point anbieten, mit dem das ComplianceValidator die Eingabedaten bekommenkann.

• Metamodel Repository: Die Komponente dient zur Persistierung von den bereitsgenerierten Metamodellen, die wiederverwendet werden konnen. Diese Komponentesoll eine Schnittstele zum Lesen und Schreiben von Metamodellen anbieten.

• Compliance Registry: In dieser Komponente wird die Logik fur die Konformi-tatsuberprufung implementiert. Es ist wichtig, dass die Konformitatsbedingungennicht fest programmiert sind, so dass sie vom Benutzer angepasst werden konnen.

40

4.4. Integration in ModelJoin 41

• Difference Engine: In dieser Komponente wird die Differenz zwischen zwei Me-tamodellen berechnet. Die Different wird als eine Liste von einfachen Anderungendargestellt. Einfache Anderungen sind das Hinzufugen oder das Loschen von Ele-menten.

• UI: Die Benutzeroberflache enthalt die grafische Schnittstellen, die zur Erstellungvon GUI-Elementen ( wie zum Beispiel Menus, Sichten und Preferenzseiten) verwen-det werden.

• ModelJoin: ModelJoin stellt die Metamodelle zur Verfugung, die auf eine Konfor-mitat uberpruft werden. Dafur wird eine Schnittstelle gebraucht, die die Informationvon ModelJoin zur Verfugung gestellt wird. Da es zur Zeit noch keine solche Schnitt-stelle existiert, wird eine in dieser Arbeit vorgeschlagen. ModelJoin ist eine fremdeKomponente, die die prototypische Implementierung dieser Arbeit verwenden kann.

MetamodelRepository

DifferenceEngine

Compliance Policy

Registry

UI

ComplianceValidator

ModelJoin

Abbildung 4.8.: UML-Komponentendiagramm

4.4. Integration in ModelJoin

Die Abbildung 4.9 beschreibt den Zusammenhang zwischen dieser Diplomarbeit und demModelJoin. Beim Speichern einer ModelJoin-Query wird das neue Ziel-Metamodell ausden Eingabe-Metamodellen und der ModelJoin-Query synthetisiert. Der Target-Validatoruberpruft, ob das neue Ziel-Metamodell mit einem anderen Ziel-Metamodell kompatibelist. Die ausgegrauten Elemente sind die bereits implementierten ModelJoin-Komponenten.Der Target-Validator beinhaltet das entwickelte Verfahren dieser Arbeit.

Um die in dieser Arbeit angebotenen Funktionalitat zu integrieren, soll von ModelJoin einHook angeboten werden. Das Hook soll direkt nach der Metamodel Synthesis einer Model-Join-Query ausgefuhrt werden. Weitere Details uber die Schnittstellen und die technischeIntegrierung in ModelJoin werden in Kapitel 4.5 erlautert.

4.5. Prototypische Entwicklung

Der folgende Abschnitt beschreibt die prototypische Umsetzung der definierten Konzep-tion, welche im vorherigen Abschnitt beschrieben ist. Dabei wird detailliert auf die Gestaltder Schnittstelle und alle relevanten Funktionen des Prototyps eingegangen.

41

42 4. Losungsansatz

Input Metamodels

Model 1..n

ModelJoin Query

Metamodel Synthesis

Transformation Generation

Model-to-model Transformation

Target Metamodel

Join Result

<<conforms to>>

<<references>>

<<conforms to>>

Target ValidatorTarget Metamodel

Repository

Abbildung 4.9.: ModelJoin Architektur. Quelle: modifizierte Version von [BHS+13]

Weil ModelJoin als Eclipse-Plugin implementiert ist, soll der Prototyp auch als Eclipse-Plugin implementiert werden. Im Abschnitt 4.5.3 wird die Integration in ModelJoin be-schrieben.

Die Architektur wird mit EMF entworfen. Dafur wird XCore1 verwendet. Die prototypi-sche Entwicklung besteht aus sieben Eclipse Plug-In Projekte und einem Feature-Projekt.Das Projekt edu.kit.sdq.modeljoin.compliance.model enthalt eine technologieunabhangigeImplementierung der Architektur. Die anderen sechs Projekte entsprechen den in derKonzept definierten Komponenten und implementieren die Klassen aus dem Modell. DasFeature-Projekt beschreibt, dass die Plug-Ins zusammen zu einer P2-Repository gehoren.

4.5.1. Kern

Der Kern implementiert die im Kapitel 4.2 beschriebene Logik. Auf der Abbildung 4.10sind die Teile des Kerns als UML-Klassendiagramm dargestellt. Im folgenden werden diewichtigsten Klassen und die zugehorigen Methoden des Diagramms beschrieben.

• ComplianceFacade:Diese Klasse bietet eine einheitliche Schnittstelle des Kern und die wichtigsten Funk-tionalitaten an. Mit den MethodencheckCompliance(Metamodel):Metamodel undsearchForComplianceModelInRepository(Metamodel, Metamodel):Metamodel kanndirekt die Konformitatsuberprufung aufgerufen werden. Die Klasse bietet auch einMechanismus zur Registrierung von einem Listener. Damit wird eine einfache Ver-wendung von dem Kern erzielt und es wird eine lose Kopplung zwischen den Subsyste-men und Kunden gefordert. Diese Klasse verwendet das im (p. 185 - 193)[GHJV95]beschriebene Facade Pattern.

• MetamodelRepository:Die Schnittstelle MetamodelRepository dient zur Bindung eines Rahmenwerks zurPersistenz des bereits generierten Metamodells. Diese Schnittstelle ist technologieu-nabhangig und es kann jede Art von Persistenz verwendet werden.

1XCore ist eine Programmiersprache, mit der Metamodelle definiert werden. Damit kann die Strukturund die Logik des Modells erstellt werden. - http://www.eclipse.org/Xtext/

42

4.5. Prototypische Entwicklung 43

edu.kit.sdq.modeljoin.diffhandler.core

validateCompliance(Metamodel):MetamodelvalidateCompliance(Metamodel,Metamodel):Metamodel

ComplianceValidator

StatusObserveraddStatusListener(IStatusListener):voidremoveStatusListener(IStatusListener):voidnotify(StatusList):void

CompliancePolicyRegistryaddCompliancePolicy(ICompliancePolicy):voidremoveCompliancePolicy(ICompliancePolicy):voidgetPolicies():List<ICompliancePolicy>getPoliciesByKind(DiffKind):List<ICompliancePolicy>getPoliciesByType(DiffType):List<ICompliancePolicy>

IStatusgetSource():IDiffgetMessage():StringgetPolicy():ICompliancePolicy

ComplianceFacadecheckCompliance(Metamodel):MetamodelsearchForComplianceModelInRepository(Metamodel,Metamodel):MetamodeladdStatusListener(IStatusListener):voidremoveStatusListener(IStatusListener):voidaddCompliancePolicy(ICompliancePolicy):voidremoveCompliancePolicy(ICompliancePolicy):voidgetCompliancePilicies():List<ICompliancePolicy>

StatusListaddStatus(IStatus):voidremoveStatus(IStatus):voidclearList():voidgetAll():List<IStatus>

0*

<<uses>>

IStatusListenerstatusChanged(StatusEvent):void

<<uses>>

getStatusList():StatusListgetChangedElements():StatusList

IStatusEvent

<<uses>>

0*

computeDiff(ResourceSet,ResourceSet):List<IDiff>DiffEngineIMetamodelRepository

<<uses>>

<<uses>>

<<uses>>

<<uses>>

<<enumeration>>Severity

WARNINGERROR

getKind():DiffKindgetSource():IMetamodelgetType():DiffTypegetValue():EObjectgetOldParent():EObjectgetNewParent():EObjectgetParameter():String

IDiff

ADDREMOVECHANGEMOVE

<<enumeration>>DiffKind

ATTRIBUTEREFERENCERESOURCE

<<enumeration>>DiffType

<<uses>>

resourceSet: ResourceSetname: StringcomplianceRate: intdiffRate: int

Metamodel

<<uses>>

0

*

ICompliancePolicygetDescription():StringgetSeverity():Severityexecute(IDiff):Status

0*

Abbildung 4.10.: UML-Klassendiagramm von dem Kern

Im Kapitel 2.5 werden diverse Technologien zur Persistenz von EMF Modellen undMetamodellen vorgestellt. Fur die prototypische Entwicklung wird eine dateibasierteRepository entworfen. Dieser Ansatz bietet am wenigsten Funktionalitaten an, aberer ist am einfachsten und am schnellsten zu implementieren. Das ist fur die Kon-zeptuberprufung voll ausreichend.

Die Implementierung befindet sich in edu.kit.modeljoin.compliance.repository. DieKlasse FileMetamodelRepository implementiert MetamodelRepository.

• ComplianceValidator:Diese Klasse enthalt die Logik zur Uberprufung der Konformitat. Jede uberprufteDifferenz bekommt einen Status, der in dem StatusList gespeichert wird. Wenn sichdie Liste andert, werden alle Kunden uber den StatusProvider benachrichtigt.

Die Implementierung von dem ComplianceValidator befindet sich inedu.kit.modeljoin.compliance.validator. ComplianceValidator wird von Valida-tor implementiert.

• CompliancePolicyRegistry:Die CompliancePolicyRegistry bietet eine Erweiterbarkeit des Konzepts an. Hierwerden alle Konformitatsregeln ( ICompliancePolicy) registriert, die von dem Com-plianceValidator verwendet werden. Hier wird das Strategy Pattern (p. 315-323)[GHJV95] verwendet. Dieses Entwurfsmuster erlaubt eine Austauschbarkeitund Erweiterbarkeit von den Konformtatsbedingungen. ICompliancePolicyRegistry

43

44 4. Losungsansatz

deklariert eine Schnittstelle, die von allen unterstutzten Konformitatsbedingungenangeboten wird. Alle Konformitatsbedinungen sollen die Schnittstelle ICompliance-Policy implementieren.

Fur die prototypische Entwicklung wurde drools als RuleEngine verwendet. DieKlasse DroolsComplianceValidator fuhrt die Regeln auf zwei Metamodelle durch unduberpruft, ob sie miteinander konform sind. Die Regeln befinden sich in der gleichenProjekt -edu.kit.edq.modeljoin.compliance.register unter rules. DroolsUtils beinhal-tet Hilfe-Methoden, die von den Regeln verwendet werden. Jede Datei beinhaltetmehrere Regeln.

• ICompliancePolicy:Die Schnittstelle ICompliancePolicy entspricht einer Regel. Jede Regel hat die Me-thoden getDescription(), getSeverity() und execute(IDiff):IStatus. Die erste Methodeliefert eine Beschreibung zuruck. Jede Regel hat ein Gewicht, dass uber die MethodegetSeverity() ermittelt werden kann. Die dritte Methode ist zur Implementierungder Logik dieser Regel. Sie liefert ein IStatus zuruck.

Weil Drools die Regeln als Resource ladet und mehrere Regeln pro Datei existierenist es unmoglich jede Regel als ICompliancePolicy zu laden. Deswegen ist ICom-pliancePolicy in der prototypischen Entwicklung nicht verwendet.

• DiffEngine:Mit der Klasse DiffEngine wird die Differenz zwischen zwei Metamodelle berech-net. Im Kapitel 2.4 sind EMF Compare und EMF Diff/Merge vorgestellt. WeilModelJoin keine UIIDs generiert, ist die Verwendung von EMF Diff/Merge ausge-schlossen, weil das Rahmenwerk die Differenz uber UUIDs berechnet. EMF Compareist besser von einer Community unterstutzt und besitzt eine stabile API. Deswegenwird die Differenz fur die prototypische Implementierung der Methodik zwischenden Metamodellen mittels EMF Compare erstellt. Die Implementierung ist in deredu.kit.sdq.modeljoin.compliance.diffengine zu finden. Die Klasse EMFCompareDif-fEngine implementiert DiffEngineImpl.

Die Abbildung 4.11 stellt die Logik von dem ComplianceValidator als Sequenzdia-gramm dar. Hier wird betrachtet, dass die Konformitatsbedingung zwischen zweiMetamodellen berechnet wird. Die Methode checkCompliance(oldMM,newMM) wirdaufgerufen. Aus dieser Methode wird validateCompliance(oldMM, newMM) aufge-rufen. Sie berechnet die Differenz, ladet die registrierten Strategien und fuhrt dieDifferenzuberprufung aus. Die registrierte Strategien werden mittels der MethodegetPolicies() geladen. Mit einer Schleife wird es fur jede Differenz uberpruft, ob dieStrategien verletzt sind. Jede verletzte Strategie generiert ein Status. Jedes Statuswird in der StatusListe hinzugefugt. Nach der Uberprufung werden alle registriertenTeilnehmer uber den StatusProvider benachrichtigt.

• IDiff:Die Schnittstelle bietet die benotigte Information zur Uberprufung von den Konfor-mitatsbedingungen an. Der Typ einer Anderung (DiffType), die Quelle (IMetamodel)und der neue Wert (EObject) werden zur Verfugung gestellt.

Die Implementierung dieser Klasse ist in der edu.kit.sdq.modeljoin.compliance.modelzu finden.

Die KlasseDiffAdapter stellt die von EMFCmpare generierten Differenzen in IDiff.

44


sd Arbeitsablauf einer Konformitätsüberprüfung

validator:ComplianceValidator diff:DiffEngine

checkCompliance(oldMM,newMM)

loop (diffs)

validateCompliance(oldMM,newMM)

diffs

diff:CompliancePolicyRegistry

getPolicies()

policies

loop (policies)

alt[policy violated]

statuses:StatusList

addStatus(status)

providider:StatusProvider

notify(statuses)

Abbildung 4.11.: Sequenzdiagramm: Arbeitsablauf einer Konformitatsuberprufung

• IMetamodelRepository:Die Klasse beinhaltet eine Liste mit Metamodellen. Die Klasse ComplianceValidatorverwendet diese Klasse um die Metamodell-Repository zu laden.

• Metamodel:Die Klasse Metamodel entspricht einem Metamodell. Jedes Metamodell hat einenNamen, complianceRate und diffRate.

• StatusProvider:Nach der Konformitatsuberprufung werden Status-Meldungen von dem Complian-ceValidator generiert. Uber den StatusProvider werden andere Systeme uber denStatus benachrichtigt. Damit kann zum Beispiel die Benutzeroberflache aktualisiertwerden. Hier wird das Observer Pattern (S. 293-303)[GHJV95] verwendet. Die Ideevon diesem Muster ist die Benachrichtigung von Systemen und Subsystemen beieiner Anderung der Stratusliste.

4.5.2. Benutzeroberflache

Die zweite Komponente, die auf der Abbildung 4.12 zu sehen ist, stellt die Ergebnisse derKonformitatsuberprufung dar. Im Konzept werden zwei Arten der Darstellung vorgesehen.Beide implementieren die Schnittstelle IStatusListener, so dass die grafische Oberflacheaktualisiert wird, sobald neue Ergebnisse berechnet sind.

Im folgenden werden die einzelnen Klassen des Sequenzdiagramms beschrieben.

• ProblemViewContributor:Nach der Konformitatsuberprufung wird die Information in ProblemView mit Hilfeder Klasse ProblemViewContributor dargestellt. Diese Klasse dient zur Erstellungvon Markern.

• ModelJoinEditorUIContributor:Die Klasse ModelJoinEditorUIContributor dient zur Ruckfuhrung dem Problem auf

45

46 4. Losungsansatz

edu.kit.sdq.modeljoin.diffhandler.ui

ProblemViewContributor ModelJoinEditorUIContributor

IStatusListenerstatusChanged(StatusEvent):void

<<implements>>

MetamodelRepositoryView

Abbildung 4.12.: UML-Klassendiagramm von der Benutzeroberflache

ModelJoin-Query-Elemente. Damit konnen die Elemente markiert, die zu einer Kon-formitatsverletzung fuhren.

• MetamodelRepositoryView:In dieser Sicht werden die Metamodelle aus dem MetamodelRepository dargestellt.Bei einem Vergleich zwischen einem Metamodell und allen, die sich in der Repositorybefinden, werden sie nach Ahnlichkeitsgrad sortiert. Ein Ansatz ware die Berech-nung von dem Ahnlichkeitsgrad auf EObject-Ebene. Fur jedes Attribut wird dieLevenshteinsdistanz [Lev66] berechnet. Dann kann ein Wert fur alle Elemente be-rechnet werden. Wenn drei Attributnamen namlich ”name”, ”fullName” und ”came”betrachtet werden, werden sie nach der Levenshteinsdistanz in dieser Reihenfolgegeordnet: ”name”,”came”,”fullName”. Das macht aber keinen Sinn. Aussagekrafti-ger ist die Anzahl von den Differenzen und die Anzahl von den zusammenpassendenElementen. Es werden zwei Werte namlich Compliance Rate und Diff Rate definiert.

– Compliance Rate: Beschreibt die Anzahl von Anderungen, die nicht kon-form sind. Das ist die Anzahl aller Anderungen, die das Metamodell inkompa-tibel machen.

– Diff Rate: Beschreibt die Anzahl von aller Anderungen zwischen den Meta-modellen.

Die Abbildung 4.13 reprasentiert das MetamodelView. Die Sicht enthalt eine Tabelle,in der die Metamodelle in der Repository dargestellt sind. Die Tabelle enthalt dieSpalten Name, Compliance Rate und Diff Rate. Jedes Metamodell kann abgehaktwerden und wird als Standardwert bei der Berechnung der Konformitat verwendet.

• Status Dialog:Mit Status Dialog (siehe Abbildung 4.14) wird zusatzliche Information uber die Dif-ferenz angezeigt. Hier kann man sehen, welche Anderungen eine Konformitatsver-letzung verursachen. Das Feld Message wird bei einem Fehler aus dem Namen derRegel generiert, so dass man sehen kann, welche Regel verletzt ist.

• Einstellungen: Compliance Validator:Mit der Einstellungsseite Compliance Validator werden der Ordner mit den Regelnund der Ordner mit den Metamodellen bestimmt. Aus dem Ordner Rule Folderwerden die Regeln geladen, die zur Berechnung der Konformitat verwendet werden.

46


Abbildung 4.13.: Metamodel View

Abbildung 4.14.: Status Dialog

Sie konnen auch in Unterordner verteilt werden. Da eine File Metamodel Reposi-tory entworfen wurde, wird der Pfad von den Metamodellen mit Metamodels folderbestimmt. Sie werden in der Sicht Compliance Models geladen. Auf der Abbildung4.15 ist die Einstellungsseite dargestellt.

• Kontextmenu:In dem Kontextmenu in der Sicht Project Explorer sind die Befehle zu finden, mit de-nen die Konformitat auf bestimmte ECore-Modelle ausgefuhrt werden kann. Es gibtzwei Varianten. Mit dem ersten Befehl konnen zwei ECore-Dateien selektiert unddiese miteinander uber Run Compliance Validator –> Each Other verglichen werden.Der zweite Befehl - Run Compliance Validator –> With pinnet metamodel vergleichtdas selektierte ECore-Modell mit dem in der Compliance Models Sicht abgehaktenMetamodell. Auf der Abbildung 4.16 sind die hinzugefugten Kontextmenuelementendargestellt.

47

48 4. Losungsansatz

Abbildung 4.15.: Einstellungen: Compliance Validator

Abbildung 4.16.: Package Explorer Context Menu

4.5.3. Integration in ModelJoin

Es gibt mehrere Varianten die prototypische Implementierung in ModelJoin zu integrieren.Die erste Moglichkeit ist der direkte Aufruf von der ComplianceFacade nach dem Speichern.Das fuhrt zu einer Abhangigkeit zwischen ModelJoin und dieser Implementierung. Diezweite Moglichkeit verwendet die von Eclipse angebotenen Extension Points (siehe Kapitel2.1.1).

Ein Vorschlag fur ein Extension Point ist auf dem Code-Ausschnitt 4.25 zu sehen. Esbeinhaltet ein listener -Element, der als Attribut eine Implementierung der Schnittstellebenotigt. Die Schnittstelle ist auf der Abbildung 4.17 zu sehen. Die Methode targetGe-nerated() mit dem generierten Ziel-Metamodell als Eingabeparameter soll von ModelJoinausgefuhrt werden, wenn ein neues Ziel-Metamodell generiert wird, so dass die Kundenbenachrichtigt werden konnen. Die Kunden bekommen eine Liste mit vorgeschlagenenMetamodellen zuruck. Die Implementierung dieser Schnittstelle befindet sich im Projektedu.kit.modeljoin.extensionpoint.

edu.kit.sdq.modeljoin.diffhandler.extensionpoint

TargetMetamodelGeneratedtargetGenerated(ResourceSet generatedTarget):List<ResourceSet>

Abbildung 4.17.: Extension Point Interface

48


<element name=”listener”><complexType>

<attribute name=”class” type=”string” use=”required”><annotation>

<appinfo><meta.attribute kind=”java”

basedOn=”:TargetMetamodelGenerated”/></appinfo>

</annotation></attribute>

</complexType></element>

Listing 4.25: ModelJoin Extension Point

49

5. Validierung des Konzepts

In diesem Abschnitt wird das Konzept validiert. Zunachst wird es mittels allgemeiner Test-Szenarien untersucht. Diese sollen uberprufen, ob die Anforderungen an das Verfahrenserfullt sind. Dann wird Palladio [pal12] als zweites Test-Szenario verwendet. So kannuberpruft werden, wie sich das Konzept in einem echten Anwendungsfall verhalt.

5.1. Edapt Test-Szenarien

In der Veroffentlichung”An Extensive Catalog of Operators for the Coupled Evolution of

Metamodels and Models” [HVW11] ist ein Katalog von 61 Operationen definiert, die aufeinem ECore-Metamodell angewendet werden konnen. Diese Operationen sind aus 9 unter-schiedlichen Veroffentlichungen und 9 echte Anwendungsfalle gesammelt. Die Operationensind in drei Gruppen geteilt. Die erste Gruppe enthalt einfache strukturelle Anderungen.Die zweite Gruppe enthalt die Nicht-strukturelle Anderungen und in der dritten Gruppesind alle komplexe Anderungen enthalten. Jede Operation ist beschrieben, ob es eineAnpassung auf Modellebene benotigt wird.

Die Operationen, die bei Herrmansdorfer als Model preserving bezeichnet werden, ent-sprechen in der Klassifizierung von [BGGK07],[Gru07] und [BG10] der Gruppe der ”non-breaking”-Operationen. Eine Operation ist Model Preserving, wenn die Instanzen des altenMetamodells mit der neuen Metamodell konform sind. Dann mussen die Instanzen nichtangepasst werden. Das entspricht der Definition 1. Um der Ansatz zu Validieren, werdendie Operationen mit der in dieser Arbeit beschriebenen Methodik ausgefuhrt. Die ein-fache Anderungen werden direkt mittels JUnit-Tests getestet. Das sind alle strukturelleund nicht-strukturelle primitive Anderungen, die im Kapitel 5.1.1 bzw. 5.1.2 beschriebenwerden.

Fur die komplexen Operationen, die aus mehreren Anderungen bestehen, werden Meta-modelle verwendet. Jeder Testfall beinhaltet zwei Dateien: metamodel old und metamo-del new. Die erste metamodel old beinhaltet das Metamodell vor der ausgefuhrten Opera-tion. Die Datei metamodel new beinhaltet die Datei nach der Ausfuhrung der Operation.Um eine Operation auszufuhren wird das Plug-In Eclipse Edapt 0.13 verwendet, dass aufder Veroffentlichung von Herrmannsdorfer [HVW11] basiert ist. Dann wird es uberpruft,ob die Metamodelle konform sind.

51

52 5. Validierung des Konzepts

Operation Ergebnis nach [HVW11] Ergebnis

Create Package model-preserving konform

Delete Package model-preserving konform

Create Class model-preserving konform

Delete Class unsafely model-migration nicht konform

Create Attribute safely model-migration konform

Create Reference safely model-migration konform

Delete Feature unsafely model-migration nicht konform

Create Opposite Reference unsafely model-migration nicht konform

Delete Opposite Reference model-preserving konform

Create Data Type model-preserving konform

Delete Data Type model-preserving konform

Create Enum model-preserving konform

Delete Enum model-preserving konform

Create Literal model-preserving konform

Merge Literal unsafely model-migration nicht konform

Tabelle 5.1.: Strukturelle primitive Anderungen nach [HVW11]

Die primitive Testfalle sind im Projekt edu.kit.sdq.modeljoin.compliance.tests enthalten.Die Klasse ComplexTests im Projekt edu.kit.sdq.modeljoin.compliance.validator beinthal-tet alle komplexe Testfalle.

Die folgenden Tabellen 5.1, 5.2, 5.3, 5.4, 5.5, 5.6 und 5.7 enthalten die definierten von[HVW11] Operationen. Jede Tabelle beinhaltet die Spalten: Name der Operation, daserwartete Ergebnis und das Ergebnis nach der Methodik dieser Arbeit.

5.1.1. Strukturelle primitive Anderungen

Diese Art von Anderungen modifizieren die Struktur des Metamodells. Es werden neueElemente erstellt oder geloscht. Die Tabelle 5.1 enthalt diese Anderungen und zeigt, dasssie richtig von dieser Methodik ausgewertet sind.

Das Loschen( Delete Package) und Erstellen( Create Package) von Paketen braucht keineAnpassung auf die Modellebene. Die Erstellung einer neuen Klasse ist konform. DieOperation Delete Class wird von der Regel 4.1 als nicht konform erkannt. Die Erstellungvon Attributen und Referenzen ist auch Konform, wenn sie eine Untergrenze großer als0 haben. Wenn sie geloscht werden, dann verletzen sie die Konformitatsbedingungen.Diese Operationen werden von den Regeln 4.3 und 4.5 erkannt. Bei der Erstellung neuenAttributen und Referenzen muss es beachtet werden, dass das Feature kein Pflichtelementist. Das Loschen von Features verletzt die Konformitat. Create Opposite Reference wirdals nicht konform von der Regel 4.20 erkannt. Weil Enum eine endliche Wertemenge besitztund nicht initialisiert werden kann, sind die OperationenCreate Enum und DeleteEnumkonform. Die Erstellung von neuen Literal-Elemente verletzt die Konformitatsbedingungennicht. Die Operation Merge Literal wird als zwei einfache Operationen in dieser Arbeitberechnet. Sie sind Create Literal und Delete Literal. Wenn ein Literat geloscht wird,

52

5.1. Edapt Test-Szenarien 53


Rename safely model-migration nicht konform

Change Package safely model-migration nicht konform

Make Class Abstract unsafely model-migration nicht konform

Drop Class Abstract model-preserving konform

Add Supertype model-preserving konform

Remove Supertype unsafely model-migration nicht konform

Make Attr. Identifier unsafely model-migration nicht konform

Drop Attr. Identifier model-preserving konform

Referenz Composite machen model-preserving konform

Referenz Composite andern model-preserving konform

Referenz Opposite machen model-preserving konform

Referenz Oposite entfernen model-preserving konform

Tabelle 5.2.: Nicht-strukturelle primitive Anderungen

wird diese Operation als nicht konform markiert. Aus diesem Grund ist Merge Literat alsnicht konform erkannt.

5.1.2. Nicht-strukturelle primitive Anderungen

Die Nicht-strukturelle primitive Anderungen modifizieren die Eigenschaften einesMetamodell-Element. Die Tabelle 5.2 beschreibt die definierten Operationen.

Mit der Operation Rename werden die Namen des Elementen umbenannt. Sie wird alsnicht konform von der Regel 4.8 erkannt. Change Package dient zur Verschiebung vonPaketen und Elementen in der hierarchischen Struktur. Die Regel 4.6 ist fur die Erkennungsolchen Anderungen zustandig. Die Operationen Make Class Abstract und Drop ClassAbstract andern das Typ der Klasse. Die Regel 4.22 erkennt, wenn eine Klasse abstraktgemacht wird. Die Erstellung von neuen Supertypen erfolgt mittels der Operation AddSupertype und fuhrt zur keine Verletzung der Konformitat. Das gilt nur, wenn es keinePflichtelemente die Superklasse enthalt. Wenn es solche Elemente existieren, dann fuhrt eszu einer Verletzung der Konformitat. Remove Supertype wird als nicht konform erkannt.Die Regel 4.21 erkennt, wenn ein Attribut gemacht wird.

5.1.3. Spezialisierungs-/Generalisierungsanderungen

In der Veroffentlichung [HVW11] wird Spezialisierung als eine Reduzierung von den mog-lichen Modellen beschrieben. Die Generalisierung erweitert die Menge von moglichen Mo-dellen, die von einem Metamodell unterstutzt werden. Das kann durch eine Anderung derUnter-/Obergrenze oder durch eine Anderung des Typs erreicht werden.

In EMF konnen die Operationen Generalize Attribute und Specialize Attribute nur dieOber- und Untergrenze angepasst werden. Die Regeln 4.12 und 4.13 uberprufen, ob solcheAnderungen auftreten. Das gilt auch bei Anderungen der Unter-/Obergrenze von Refe-renzen. Bei den Operationen Generalize Reference und Specialize Reference kann auchder Typ geandert werden. Hier soll es uberpruft werden, ob dieser Typ eine Superklasse

53



Generalize Attribute model-preserving konform

Specialize Attribute unsafely model-migration konform

Generalize Reference model-preserving konform

Specialize Referenz unsafely model-migration nicht konform

Specialize Composite Ref. unsafely model-migration nicht konform

Generalize Super Type unsafely model-migration nicht konform

Specialize Super Type safely model-migration nicht konform

Tabelle 5.3.: Spezialisierungs-/Generalisierungsanderungen


Push up Feature model-preserving konform

Push down Feature unsafely model-migration nicht konform*

Extract Super Class model-preserving konform

Inline Super Class unsafely model-migration nicht konform*

Fold Super Class safely model-migration nicht konform*

Unfold Super Class unsafely model-migration nicht konform*

Extract Sub Class safely model-migration nicht konform*

Inline Sub Class unsafely model-migration nicht konform*

Tabelle 5.4.: Vererbungsanderungen

des alten Typs ist. Wenn dass der Fall ist, dann erfolgt eine Generalisierung, die dieKonformitat nicht verletzt. Die Regel 4.14 erkennt diese Anderungen. Die Generalisie-rung und Spezialisierung von Supertypen ist nicht nicht konform, wenn die entferntenAttributen/Referenzen durch die Vererbungsanderungen eine Untergrenze großer 0 haben.

5.1.4. Vererbungsanderungen

Mit diesen Operationen werden Elemente in die hierarchischen Struktur verschoben. Dievon [HVW11] definierten Anderungen sind aus dem im Buch

”Refactoring: Improving the

Design of Existing Code” [Fow99] beschriebenen Refactoringstechniken inspiriert.

Die Operation Pull up Feature verschiebt Features, die sich in einem Subklassen befinden,zu einer Superklasse. Die Abbildung 5.1 beschreibt ein Beispiel, in dem ein Attribut ausden Klassen Book und CD zu der Superklasse verschoben wird. Die linke Seite der Abbil-dung zeigt der erste Zustand des Metamodells und die rechte Seite stellt das Metamodellnach der Pull up Feature Operation dar. Diese Anderung wird von den Regeln als konformerkannt. Wenn die Abbildung von rechts nach links betrachtet wird, dann geht es um einePush down Feature Operation. Beide Operationen werden durch den Regeln richtig er-kannt. Extract Super Class ist eine Kombination von den Operationen Create Class, Pullup Feature und Add Supertype. Weil diese Operationen konform sind, wird diese Opera-tion von den Regeln als konform erkannt. Inline Super Class ist die Umkehroperation von

54


Extract Super Class und ist nicht konform. Sie besteht aus Push down Feature, DeleteClass und Remove Supertype. Alle diese Operationen verletzen die Konformitat und ausdiesem Grund ist auch Inline Super Class nicht konform. Fold Super Class ist ahnlich wieExtract Super Class. Anstatt die Erstellung einer neue Superklasse wird eine bestehendeKlasse verwendet. Die Abbildung 5.2 beinhaltet ein Beispiel nach der Anwendung solcherOperation. Sie wird auf die Klasse Booklet angewendet. Die rechte Seite der Abbildungist das Ergebnis zu sehen. Die Umkehroperation ist Unfold Super Class und trennt eineKlasse von einer Superklasse. Beide Operationen verletzen die Konformiat. Extract SubClass erstellt eine Subklasse von eine andere Klasse und verschiebt Features zu dieserSubklasse. Die Umkehroperation ist Inline Sub Class. Sie verschmelzt eine Klasse undeine von ihren Subklassen. Beide Operationen werden als nicht konform von den Regelnerkannt, weil sie einfache Operationen beinhalten, die Attributen und Klassen loschen.

Die Konformitat von diesen Operationen hangt davon ab, ob die geanderte Klasse abstraktist. Fur alle Operationen, die mit einem Stern bezeichnet sind, gilt das. In der Veroffent-lichung von Herrmannsdorfer wird dieser Fall nicht betrachtet. Wenn die Operation Pushdown Feature auf eine abstrakte Klasse ausgefuhrt wird, ist diese Anderung konform, weiles keine Instanzen geben kann. Das gleiche gilt fur Inline Super Class, Fold Super Class,Unfold Super Class, Extract Super Class und Inline Super Class.

Media

BookString: title

CDString: title

MediaString: title

Book CD

Abbildung 5.1.: Pull up Feature: Verschiebe ein Attribut zu einer Superklasse

BookDouble:size

BookletString: titleDouble: sizeString: publisher

MediaString:publisher

BookDouble:size

BookletString: title


Abbildung 5.2.: Fold Super Class: Eine Klasse zu einer Superklasse

5.1.5. Delegierte Anderungen

Die delegierte Operationen verschieben, extrahieren und verschmelzen Metamodell-Elemente. Die Tabelle 5.5 beinhaltet die diese Operationen.

Die Operation Extract Class trennt die Elementen aus einer Klasse und erstellt eineKomposite-Referenz zwischen die alte und die neu-extrahierte Klasse. Die Umkehrope-ration ist Inline Class. Fold Class und Unfold Class sind ahnlich zu den ersten zwei

55



Extract Class safely model-migration nicht konform

Inline Class safely model-migration nicht konform

Fold Class safely model-migration nicht konform

Unfold Class safely model-migration nicht konform

Move Feature over Ref. safely model-migration nicht konform

Collect Feature over Ref. unsafely model-migration nicht konform

Tabelle 5.5.: Delegierte Anderungen


Subclass to Enum safely model-migration nicht konform

Enum to Subclass safely model-migration nicht konform

Reference to Class safely model-migration nicht konform

Class to Reference safely model-migration nicht konform

Inheritance to Delegation safely model-migration nicht konform

Delegation to Inheritance safely model-migration nicht konform

Reference to Identifier safely model-migration nicht konform

Identifier to Reference unsafely model-migration nicht konform

Tabelle 5.6.: Austausch von Typen

Operationen. Bei Fold Class werden bereits existierende Klassen verwendet. Die Opera-tion Move Feature over Reference verschiebt ein Feature uber eine Referenzklasse. DieUmkehroperation ist Collect Feature over Ref.

Die oben beschriebenen Operationen werden als nicht konform erkannt, weil sie einfacheAnderungen erhalten, die die Konformitat verletzen.

5.1.6. Austausch von Typen

Im folgenden werden die Operationen uberpruft, die zum Austausch von Typen verwendetwerden. Sie sind nach [HVW11] als nicht konform bezeichnet und brauchen eine Migrationauf Modellebene. Auf der Tabelle 5.6 sind diese Operationen dargestellt.

Die Operation Subclass to Enum wird verwendet, wenn eine Klasse mehrere Unterklassenbesitzt. Sie loscht die Unterklassen und erstellt ein Enum, dass von der Klasse referenziertwird. Die Umkehroperation von Subclass to Enum ist Enum to Subclass. Mit dieserwird aus einem Enum fur jeden Literat eine Unterklasse erstellt.Die Operation Inheritanceto Delegation entfernt die Vererbung einer Klasse und fugt eine Referenz hinzu. DieUmkehroperation ist Delegationn to Inheritance. Mit Reference to Identifier kann eineReferenz entkoppelt werden. Die Operation erstellt eine indirekte Referenz zwischen denKlassen mit der Hilfe einem Identifizierer. Die Umkehroperation ist Identifier to Reference.Alle Operationen werden richtig von den in dieser Arbeit definierten Regeln erkannt.

56



Merge Features unsafely model-migration nicht konform

Split Reference by Type safely model-migration nicht konform

Merge Classes unsafely model-migration nicht konform

Split Classes unsafely model-migration nicht konform

Merge Enumerations unsafely model-migration nicht konform

Tabelle 5.7.: Verschmelzung- und Trennanderung

5.1.7. Verschmelzung- und Trennanderungen

Diese Gruppe von Anderungen werden Metamodell-Elemente verschmolzen und getrennt.

Merge Features beschreibt die Verschmelzung von zwei oder mehreren Features in einem.Diese Operation enthalt die Loschung von Features und ist aus diesem Grund nicht kon-form. Split Reference by Type beschreibt die Aufteilung einer Referenz anhand der Unter-klassen. Auf der Abbildung 5.3 ist ein Beispiel solcher Anderung dargestellt. Die KlasseAuthor hat eine Referenz mit der Klasse Media. Media hat zwei Unterklassen namlichBook und CD. Die rechte Seite der Abbildung stellt den Zustand nach der Ausfuhrungder Operation Split Reference by Type. Die Referenz zwischen Author und Media wirdmit 2 Referenzen ersetzt. Diese Anderung ist nicht konform, weil die Referenz zwischenMedia und Author geloscht wird. Die Operation Split Classes teilt eine Klasse in zweioder mehreren auf. Als einfache Operationen sind die Erstellugn von den neuen Klas-sen. die Verschiebung von den Features zu den neuen Klassen. Die Verschiebung bestehtaus dem Loschen und das Erstellen von Elementen. Die Loschung von Features verletztdie Konformitat. Laut der Veroffentlichung von herrmannsdoerfer10a ist diese Operationmodel-preserving in der Tabelle, aber im Text wird sie als unsafe und braucht eine Mi-gration. Die Umkehroperation ist Merge Classes, die die Operation Delete Class benotigt.Das gleiche gilt fur Merge Enumerations. Diese Operation dient zur Verschmelzung vonzwei oder mehreren Enums.

Media

Book CD

Author Media

Book CD

Author

Abbildung 5.3.: Beispiel: Split Reference by Type

5.1.8. Diskussion

In den letzten Abschnitten wurde gezeigt, dass alle Edapt Operationen richtig erkanntwerden. Da der Katalog die bekantesste Operationen aus der Literatur abdeckt, wird eshiermit gezeigt, dass die definierten Regeln ausreichend zur Uberprufung der Wiederver-wendbarkeit sind.

57


5.2. Weitere Test-Szenarien

In diesem Abschnitt werden sieben weitere interessante Test-Szenarien untersucht. Dassind Szenarien, die im von den Operationen von [?] nicht abgedeckt sind. Jede Szenariowird mit der Hilfe einer Abbildung beschrieben. Die linke Seite der Abbildung beschreibtden alten Zustand der Abbildung. Die linke Seite beschreibt den Zustand nach den Ande-rungen.

• Testszenario 1: Ein Pflichtattribut zu einer Superklasse verschieben. Diese Ande-rung soll nicht konform sein.

Die Testszenario ist auf Abbildung 5.4 beschrieben. Das Pflichtattribut title wird vonder Klasse Book in die Klasse Media verschoben. Da die Klasse CD das Attributenicht enthalt, ist die Verschiebung zur Superklasse Media als nicht konform erkannt.Die Modelle der Klasse CD sollen das Attribut enthalten und im alten Zustand istdas nicht der Fall.

Media

BookString: title [1]

CD

MediaString: title [1]

Book CD

Abbildung 5.4.: Szenario 1: Verschiebe ein Pflichtattribut zu einer Superklasse

• Testszenario 2: Eine Referenz mit einer Untergrenze großer als 0 zu einer Super-klasse verschieben. Diese Anderung soll als nicht konform erkannt werden.

Die Testszenario, die auf Abbildung 5.5 dargestellt ist, beschreibt eine Verschiebungvon der Referenz von der Klasse Book nach der Klasse Media. Nach der Konformi-tatsuberprufung werden die Anderung wird als konform erkannt. Die Ursache ist,dass die Untergrenze großer als 0 ist. Die Verschiebung fordert an, dass alle Mo-delle von der Klasse Media eine Referenz mit der Klasse Publisher haben sollen. Dadie Modellen von der Klasse Media keine solche Referenz enthalten, kann das neueMetamodell diese Modelle nicht unterstutzen.

Media

Book Publisher

Media

Book

Publisher

1

1

Abbildung 5.5.: Szenario 2: Verschiebe eine Pflichtreferenz zu einer Superklasse

• Testszenario 3: Eine Klasse loschen und alle Attributen zu den Unterklassen ver-schieben. Diese Anderung darf nicht konform sein.

Auf der Abbildung 5.6 beschreibt die Testszenario die Entfernung der Klasse Mediaund das Attribut title wird in die Unterklassen verschoben. Die Anderungen sollen

58

5.2. Weitere Test-Szenarien 59

nicht konform sein, weil es Instanzen von der Klasse Media existieren. Die Regelnerkennen die Loschung der Klasse und liefern als Ergebnis, dass das neue Metamodellmit den alten nicht konform ist.

MediaString: title

Book CD BookString: title

CDString: title

Abbildung 5.6.: Szenario 3: Losche eine Klasse und verschiebe alle Attributen zu denUnterklassen

• Testszenario 4: Ein Attribut generalisieren. Diese Anderung soll konform sein.

Die Testszenario auf Abbildung 5.1 beschreibt den Testfall. Das Attribut title wirdvon den Klassen Book und CD geloscht. Das Attribut wird in der Klasse Mediahinzugefugt. Das Attribut wird fur die Klassen Book und CD von der Superklassevererbt und sie sind praktisch nicht geloscht. Die Erstellung von einem neuen Attri-but in Media verletzt die konformitat nicht, wenn das Attribut kein Pflichtattributist. Deswegen wird diese Anderung als konform erkannt.

Media

BookString: title

CDString: title

MediaString: title

Book CD

Abbildung 5.7.: Szenario 4: Generalisierung umkehren

• Testszenario 5: Eine Generalisierung umkehren. Diese Anderung soll konform sein.

Die Testszenario auf Abbildung 5.8 beschreiben eine Anderung der Richtung einerGeneralisierung. Dabei werden die Referenzen und Attributen angepasst. Die Re-ferenz zwischen Book und Publisher wird geloscht. Anstatt dieser Referenz wirdeine neue Referenz zwischen Booklet und Publisher erstellt. Dabei wird die Gene-ralisierung umgekehrt. Diese Anderungen. Das Attribut title wird von der KlasseBooklet nach Book verschoben. Beide Metamodelle haben die gleiche Bedeutung unddie gleiche Menge von Modellen. Die gemachten Anderungen werden als konformerkannt.

• Testszenario 6: Eine Hierarchie von den Supertypen andern. Diese Anderung sollals konform erkannt werden.

Die Testszenario ist auf der Abbildung 5.9 beschreiben eine Anderung von der Hier-archie den Supertypen. Die Klasse DigitalContent wird ein Supertyp von Media. DasSupertyp DigitalContent wird von der Klasse CD geloscht. Wenn die Attribute undReferenzen von der Klasse DigitalContent nicht pflicht sind, sind diese Anderungenkonform.

59


Book

BookletString: title

Publisher BookString: title

Booklet

Publisher

Abbildung 5.8.: Szenario 5: Generalisierung umkehren

Ein Problem ware, wenn das Attribut url ein Pflichtattribut ist. Die Klassen Mediaund CD vererben das Attribut und mussen auf Modellebene enthalten werden. Indiesem Fall waren die Anderungen nicht konform.

DigitalContenturl: String

CD

Mediatitle: String

DigitalContenturl: String

CD

Mediatitle: String

Abbildung 5.9.: Szenario 6: Hierarchie von den Supertypen andern

• Testszenario 7: Superklassen verschmelzen. Diese Anderung darf nicht konformsein.

Auf der Abbildung 5.10 links sind die Klassen Media und DigitalContent Superklas-sen von der Klasse CD. Beide Superklassen werden verschmolzen. Die Attributenvon DigitalContent werden in Media verschoben und die Klasse DigitalContent wirdgeloscht. Das Problem hier ist, dass die geloschte Klasse Instanzen besitzen kann.In diesem Fall sind diese Instanzen mit dem neuen Metamodell inkompatibel. DieseTestszenario wird als nicht Konform erkannt.

DigitalContentDouble:size

CD


CD

MediaDouble:sizeString:publisher

Abbildung 5.10.: Szenario 7: Verschiebe ein Attribut zu einer Superklasse

60

5.3. Palladio Evaluierungsszenario 61

5.3. Palladio Evaluierungsszenario

Es wird das Experiment von [BHS+13] verwendet. Die Eingabemetamodelle sind Palladiound das Sensor Framework. Als Beispiel wird aus der Veroffentlichung von [BKR09] dasMediaStore verwendet. Das Sensor Framework ist ein Teil der Palladio Workbench und lie-fert Ergebnisse, die im Sensor Model persistiert werden konnen. Auf der Abbildung 5.11 isteine vereinfachte Version des Sensor Frameworks dargestellt. Beide Metamodelle sind losegekoppelt und enthalten keine direkte Referenzen zu einander, wird eine Verschmelzungmit ModelJoin erstellt. [BHS+13] definiert eine Query, die aus beiden Metamodellen einZiel-Metamodell erzeugt. Dann wird die ModelJoin-Query mit geandert und mit dem indieser Diplomarbeit beschriebenen Verfahren uberpruft, ob das neugenerierte Metamodellmit dem alten konform ist.

Abbildung 5.11.: Sensor Network Framework

Die Idee des Experiments ist zu zeigen, dass mit ModelJoin schneller und kompakter Sich-ten im Vergleich der traditionellen Methoden erstellt werden konnen. Um das zu zeigen,wird eine Verschmelzung von den Metamodellen erstellt. Aus Palladio wird die Komponen-teninformation und das Zusammenbauen-Kontext behaltet. Von der Klasse Componentwird der Name genommen. Im AssemblyContext werden die Attributen entityName undsensorName ubernommen. Aus dem Sensor Network wird die Klasse SensorStatistics be-haltet, die im neuen Metamodell als Statistics genannt wird. Das Code-Snippet 5.1 ist eineAnfrage, die den neuen Sichttyp erstellt. Auf der Abbildung 5.12 ist das Ziel-Metamodellerstellt.

Um der Ansatz auf MediaStore anzuwenden, wird die ModelJoin-Query 5.1 ausgefuhrt.Daraus wird das Ziel-Metamodell auf der Abbildung 5.12 erstellt. Dann wird die Querygeandert und das neue Metamodell wird erzeugt. Schließend wird es uberpruft, ob diebeiden Metamodellen mit einander konform sind. Und es wird auch uberpruft, ob dieInstanzen mit dem neuen Metamodell konform sind.

61


Abbildung 5.12.: Das erzeugte Zielmetamodell. Quelle: [BHS+13]

import ”platform:/resource/edu.kit.ipd.sdq.mdsd.mj.experiment/models/pcm.ecore”import ”platform:/resource/edu.kit.ipd.sdq.mdsd.sensormodel/model/Sensor.ecore”

target ”http://sdq.ipd.kit .edu/mdsd/ComponentSpeed/0.1”

theta join Entities.TimeSpanSensor with pcm.core.composition.AssemblyContextwhere ”TimeSpanSensor.sensorName.indexOf(AssemblyContext.id) > 0” as

jointarget.AssemblyContext

keep attributes pcm.core.entity.NamedElement.entityName,Entities .Sensor.sensorName

keep outgoingpcm.core.composition.AssemblyContext.encapsulatedComponent

AssemblyContext as type jointarget.Component

keep attributes pcm.core.entity.NamedElement.entityNamekeep subtype pcm.repository.BasicComponent as type

jointarget.BasicComponentkeep subtype pcm.repository.CompositeComponent as type

jointarget.CompositeComponent

keep incoming Entities.SensorStatistics .sensor as type jointarget. Statistics

keep attributes Entities.SensorStatistics .measurementCountkeep subtype Entities.TimeSpanSensorStatistics as type

jointarget.TimeStatistics

keep attributes Entities.TimeSpanSensorStatistics.mean,Entities .TimeSpanSensorStatistics.stddev,Entities .TimeSpanSensorStatistics.variance

Listing 5.1: ModelJoin-Query. Quelle: [BHS+13]

62

5.3. Palladio Evaluierungsszenario 63

Die Anfrage wird geandert. Aus der Klasse Sensor wird das Attribut sensorID hinzuge-fugt. Die Referenz measurements wird aus der Klasse Sensor hinzugefugt. Dabei werdendie Attributen measurementID und eventTime ubernommen. Das Code-Snippet 5.2 be-schreibt die hinzugefugten Elemente in die ModelJoin-Query. Nach der Aufuhrung derAnfrage wird das neue Metamodell generiert. Auf der Abbildung 5.13 ist das neue Zielme-tamodell als UML-Klassendiagramm dargestellt. Im Vergleich zum alten Metamodell hatdas neue die hinzugefugten Attribute sensorID und entityName. Die Klasse Measurementund die dazugehorigen Attribute sind hinzugefugt. Dabei ist eine Referenz zwischen Sensorund Measurement erstellt. Die Anderungen zwischen den beiden Metamodellen sind nach[HBJ09] und [BG10] als not breaking beschrieben. Sie werden mit der Hilfe von den defi-nierten Regeln als konform erkannt. In diesem Fall unterstutzt das neue Metamodell dieInstanzen von dem alten Metamodell. Das alte Metamodell kann nicht wiederverwendetwerden, es nicht alle Instanzen von dem neuen Metamodell abdeckt.

Ein weiteres Beispiel ist, wenn das obengeschriebene Anderungen ruckwarts angewendetwerden. In diesem Fall werden die Attributen sensorID , entityName, measurementIDund eventTime und die Klasse Measurement geloscht. Das neue Metamodell ist mit demalten Metamodell nicht konform, aber das alte Metamodell ist mit dem neuen konform.In diesem Fall kann das alte Metamodell wiederverwendet werden.

...keep attributes pcm.core.entity.NamedElement.entityName

keep attributes Entities.Sensor.sensorIDkeep outgoing Entities.Sensor.measurements

keep attributes Entities.Measurement.measurementIDkeep attributes Entities.Measurement.eventTime

...

Listing 5.2: Die hinzugefugten Elemente in der ModelJoin-Query.

Abbildung 5.13.: Das neue Zielmetamodell.

63


5.4. Validierung von den Anforderungen

In diesem Abschnitt werden die definierten Anforderungen in Kapitel 3 auf ihre Erfullunguntersucht. Die Tabelle 5.8 beinhaltet eine Zusammenfassung uber die erfullte bzw. nichterfullte Anforderungen.

Die Architektur erlaubt die Verwendung von anpassbaren Konformitatsbedingungen. Furdie prototypische Impfementierung wurde das Rahmender Drools verwendet. Leider beiDrools konnen aus einer Datei einzelne Regeln nicht geladen werden und wurde die KlasseIPolicyPolicy nicht verwendet. Trotzdem uber drools konnen die Regeln angepasst wer-den. Deswegen wird die Anforderung F1: Konformitatsbedinungen anpassen erfullt. Umdie Modellversionenauswahl zu ermoglichen, wurde in der Architektur ein Metamodell-Repository definiert. Fur die prototypische Entwicklung wurde die Repository wurde alseine dateibasierte Repository umgesetzt. Die Repository wird in der Sicht ComplianceModels. Aus diesem Grund ist die Anforderung F2: Modellversionenauswahl als erfulltmarkiert. Die Architektur unterstutzt Statuses und sie werden in der prototypischenImplementierung in der Sicht Status View angezeigt. Somit wird die Anforderung F3:Probleme anzeigen als erfullt markiert. Um die Metamodelle nach Ahnlichkeit zu verglei-chen wurden zwei Werte: Diff Compliance Rate und Diff Rate vorgestellt. Somit ist dieAnforderung F4 erfullt. Die Anforderung F5 soll von der ModelJoin-Seite implementiertwerden. In dieser Ausarbeitung wurde einen Vorschlag gemacht, wie das gemacht werdenkann. Die Anforderungen F6 und F7 sind in der Sich Status View implementiert.

Um eine lose Kopplung mit ModelJoin zu erreichen, wurde ein Vorschlag fur ein ExtensionPoint gemacht, dass in ModelJoin integriert werden soll. Somit ist die nicht-funktionelleAnfrorderung NF1 erfullt. NF2: Umgebung ist erfullt, weil die prototypische Implemen-tierung ist als Eclipse Plug-In entwickelt ist. Jede Beschreibung einer Regel wird durchsein Name beschrieben. Die Regeln und die Status-Ausgaben sind in der Sicht Status Viewangezeigt. Wenn ICompliancePolicy verwendet wird, kann dort auch eine Beschreibunggegeben werden. Im Kapitel 5.2 wurde gezeigt, dass die Regeln alle Edapt Operationenrichtig erkennen kann und damit werden uber 90% der Anderungen abgedeckt.

64

5.4. Validierung von den Anforderungen 65

Anforderungsbezeichnung erfullt Anmerkung

Funktionale Anforderungen

F1: Konformitatsbedingungen anpassen ja uber drools Regeln

F2: Modellversionenauswahl ja uber Model Viewer

F3: Probleme anzeigen ja uber Status View

F4: Metamodelle nach Ahnlichkeit vergleichen ja Anzahl Diffs und dieAnzahl von Diffs, dienicht Compliant sind

F5: Metamodell Konformitatsuberprufung ja

F6: Vergleichsprozess 1 ja

F7: Vergleichsprozess 2 ja

Nicht-funktionale Anforderungen

NF1: Lose Koplung ja durch OSGI

NF2: Umgebung ja

NF3: Beschreibung einer Konformitatsverletzung ja

NF4: Die Konformitatsuberprufung validieren ja

Tabelle 5.8.: Validierung den Anforderungen

65

6. Fazit und Ausblick

Der Beitrag dieser Arbeit ist eine Berechnung der Kompabilitat von einem Metamodel miteinem anderen und die Verwendung von einer Repository zum Speichern von den gene-rierten Metamodellen. Da es mehr als die Halfte Anderungen keine Migration erfordern,konnen die alten Metamodellen wiederverwendet werden. Um das zu erreichen, wurde einFramework definiert, das eine Erweiterbarkeit, Technologieunabhangigkeit und Flexibili-tat anbietet. Als Basis wurden 24 Regeln in Preudo-Code definiert, die die Kompabilitatuberprufen. Als Referenzimplementierung wurde die Architektur in der Form von EclipsePlug-Ins erstellt. Fur die Berechnung der Differenz wurde EMFCompare verwendet undfur die Regeln wurde das Rahmenwerk drools verwendet. Das Framework drools bietet eineErweiterbarkeit von den Regeln an, ohne die implementierten Eclipse Plug-Ins anzupas-sen. Da die Wiederverwendung im Kontext von ModelJoin ist, wurde eine lose gekoppelteIntegration in ModelJoin vorgeschlagen. Die Anwendungsszenarien in Kapitel 5 haben ge-zeigt, dass das Rahmenwerk robust und fehlerfrei funktioniert. Es wurde gezeigt, dass dieRegeln sowohl mit den definierten von [HVW11] Operationen, als auch mit einem echtenAnwendungsfall von Palladio richtig die Wiederverwendbarkeit erkennen. Da die Ope-rationen aus komplexeren Anderungen bestehen, wurde gezeigt, dass sie auch komplexeAnderungen unterstutzen. Die Regeln konnen als Basis fur die Uberprufung der Wieder-verwendbarkeit verwendet werden und die definierten JUnit-Test uberprufen, ob bei einerAnderung von den Regeln die gewunschten Logik geandert wurde.

Die Regeln sind nicht vollstandig und sind nicht verifiziert, sondern nur mit Beispielenvalidiert. Es existieren noch Falle, die nicht erkannt werden. Ein Beispiel ist, wenn esAttribute aus einer abstrakten Klasse geloscht werden, die keine Subtypen enthalten. DieVerwendung von drools hat gezeigt, dass fur komplizierte Uberprufungen Hilfe-Methodenbenotigt werden, die die Erweiterbarkeit von den Regeln storen. Die Versuche haben auchgezeigt, dass die Inkompatibilitat von Metamodellen sehr stark von der Anwendung dieserMetamodellen abhangig ist. In dieser Arbeit wurden die Regeln nicht fest in dem Plug-Inimplementiert, so dass der Anwender sie selbst fur eigene Anwendungsfalle anpassen kann.

Da das Rahmenwerk generisch gehalten ist, kann sie fur andere Anwendungsfalle verwen-det werden kann. Ein Anwendungsfall ware die Verwendung von dem Rahmenwerk alsUberprufung der Konsistez des Metamodells, dass in [BLD+11] erforscht wurde.

Die Repository kann mit der Hilfe von Einschrangungen und Query-Sprachen optimiertwerden, da sonst die Performance bei großen Repositories sehr schlecht werden kann. Eine

67

68 6. Fazit und Ausblick

weitere Optimierung der Repository ist die Verwendung von dem Ansatz von [BRR05].Fur die prototypische Implementierung wurde eine dateibasierte Repository verwendet,weil sie fur die prototypische Implementierung am besten geeignet war. Sie bietet keineAnfragen und soll ein anderes Rahmenwerk fur diesen Zweck ausgewahlt werden. EinVergleich zwischen den meist verbreitete ist in Kapitel 2.5 gemacht.

Es wurde es nur einen Vorschlag fur die Integration in ModelJoin gemacht und eine rich-tige Integration in ModelJoin ist nicht implementiert. Auf die ModelJoin-Seite ware eineIntegration im Editor sehr hilfreich fur die Entwickler.

Eine Integration dieser Ausarbeitung in ModelJoin kann der Entwicklungsprozess vonModelJoin-Sichten erleichtert werden. Bei einer Anpassung von einer ModelJoin-Sichtwird das neue Ziel-Metamodell generiert. Wenn das neue Ziel-Metamodell mit dem al-ten konform ist, kann das alte Ziel-Metamodell wiederverwendet werden. Das erlaubt dieVerwendung von unterschiedliche Sichten von einem Metamodell, um die Komplexitat desProjektes zu verringern. Somit kann der Entwickler nur die Information in seiner Sichthinzufugen, die er in seiner Domane braucht.

68

Anhang

A. EMFCompare Tipps

Mit EMFCompare konnen die Differenze, Aquivalenzen und Konflikten auch programa-tisch berechnet werden. Der folgende Codeausschnitt 6.2 ist ein Beispiel, wie das furECore-Modelle gemacht wird. Es gibt 3 Arten von Diffs:

• AttributeChange

• ReferenceChange

• ResourceAttachmentChange

//URL von den Modellen, die verglichen werdenURI uri1 = URI.createFileURI(”model/KITLibrary2.ecore”);URI uri2 = URI.createFileURI(”model/KITLibrary.ecore”);ResourceSet resourceSet1 = new ResourceSetImpl();ResourceSet resourceSet2 = new ResourceSetImpl();resourceSet1.getResource(uri1, true);resourceSet2.getResource(uri2, true);

//Es wird ein ResourceFactory fur ecore registriert .//Das Paket org.eclipse.emf.ecore.xmi.impl enthalt auch andere Factories.Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put(”ecore”, new

EcoreResourceFactoryImpl());

//Scope definierenIComparisonScope scope = EMFCompare.createDefaultScope(resourceSet1,

resourceSet2);Comparison comparison = EMFCompare.builder().build().compare(scope);

//Die Liste beinthaltet die DifferenzenEList<Diff> differences = comparison.getDifferences();//Die Liste beinthaltet die KonfliktenEList<Conflict> conflicts = comparison.getConflicts();

//Die Liste beinthaltet die AquivalenzenEList<Equivalence> equivalences = comparison.getEquivalences();

Listing 6.1: EMFCompare: Uberprufung der Differenz zwischen zwei ECore Modelle

EMF Compare erkennt strukturelle Anderungen. Unerwunscht ist die Erkennung vonden Reihenfolgeanderungen. Diese Anderungen konnen mit der Erstellung einem Filterignoriert werden. Das folgende Kodeabschnitt beschreibt die Losung dieser Problematik:

69

70 Anhang

IDiffProcessor diffProcessor = new DiffBuilder();IDiffEngine diffEngine = new DefaultDiffEngine(diffProcessor)

@Overrideprotected FeatureFilter createFeatureFilter()

return new FeatureFilter()

@Overridepublic boolean

checkForOrderingChanges(EStructuralFeaturefeature)

return false;;

;

...Comparison comparison =

EMFCompare.builder().setDiffEngine(diffEngine).build().compare(scope);

Listing 6.2: EMFCompare: Filter zur Ignorierung von strukturelle Anderungen

B. EMF

Abbildung B.1.: EMF Diff/Merge ProzessQuelle: [emf13a]

70

B. EMF 71

Abbildung B.2.: ECore Version 2.1 Struktur.Quelle: [emf13b]

Attr./Ref. NB BR BN Comment

ENamedElement

name yes

EPackage

nsURI yes

nsPrefix yes

eClassifiers yes

eSubpackages yes

eSuperPackage yes

EtypedElement

ordered yes false->true should yield a warning

unique yes true->false

71

72 Anhang

yes false->true

lowerBound yes decrease

yes increase

upperBound yes decrease

yes increase

eType yes new type super class of old type

yes any other case

EStructuralFeature

changeable yes

volatile yes true->false

yes false->true and lowerCardinality == 0

yes false->true and lowerCardinality != 0

transient yes true->false: compute attr. and store value

yes false->true: delete all values from M1 mo-del

defaultValueLiteral yes

unsettable yes

yes

derived yes same as transient

eContainingClass yes

Ereference

containment yes M1 instances not contained in other object

yes M1 instances contained in other object

resolveProxies yes ignored

eOpposite yes

Eattribute

iD yes all values of the structural feature are un-ique

yes non unique values exist

EClass

abstract yes true->false

yes false->true: instances of the class not re-quired

yes false->true: Instances required: not resol-vable

interface yes yes yes same as abstract

eSuperTypes yes added/removed super type empty

yes added super type has non-mandatory fea-tures

yes removed super type contains structuralfeatures

72

B. EMF 73

yes added super type contains mandatory fea-tures

eStructuralFeatures yes added feature not mandatory

yes feature removed

yes added feature mandatory

eOperations yes

EEnum

eLiterals yes literals added

yes literals removed, no refering M1 entities

yes otherwise

EEnumLiteral

value ignored due to atomicity of enum literals

instance same as value

literal same as value

eEnum same as value

Tabelle B.1.: ECore Anderungen nach [BGGK07], die nach [Gru07] kategorisiert sindQuelle: [Gru07]

73

74 Anhang

Abbildung B.3.: EMFCompare UIQuelle: Screenshot aus EMFCompare 2.1.0 Framework

Attr./Ref. NB BR BN Comment

ExistenceChange

Class add yes

delete yes supertype has mandatory asso-ciation end

yes other cases

Attribute add yes minimum cardinality > 0, no in-itializer

yes minimum cardinality > 0, initia-lizer exists

yes minimum cardinality = 0

delete yes

Association add yes minimum cardinality > 0

yes minimum cardinality > 0, no in-stances

yes minimum cardinality = 0

delete yes

AssociationEnd same as for Association

Reference add yes

delete yes

Package add yes

delete yes contents resolvable

yes contents not resolvable

Import add yes

delete yes elements resolvable otherwise

yes elements not resolvable

74

B. EMF 75

Tag add yes

delete yes

Constraint add yes

delete yes

Operation add/delete yes

Exception add/delete yes

Parameter add/delete yes

DataType add/delete yes

StructureField add/delete yes

PropertyChange

ModelElement name yes refactoring, unique ids

annotation yes

Generalizable isRoot yes

Element isLeaf yes

isAbstract yes true -> false

yes false -> true

visibility yes increase

yes decrease

Association isDerived yes true -> false

yes false -> true

Class isSingleton yes true -> false

yes false -> true

Constraint expression yes

language yes

evaluationPolicy yes

Feature scope yes instance level -> classifier level

yes classifier level -> instance level

visibility yes increase

yes decrease

StructuralFeature multiplicity yes widening

yes narrowing

isChangeable

Attribute isDerived yes true -> false

yes false -> true

Operation isQuery yes

Constant value yes

Parameter direction yes

multiplicity yes

AssociationEnd isNavigable yes

aggregation yes composite -> none

75

76 Anhang

yes none -> composite, compositionclosure rule violated

yes closure rule not violated

multiplicity yes widening

yes narrowing

isChangeable yes

EnumerationType labels yes addition

yes delete/modify

LinkChange

Contains yes not mandatory; to supertype

yes not mandatory; to other type

yes mandatory; to new or abstractsupertype

yes mandatory; to other type

Generalizes add yes supertype contains mandatoryfeatures or associations

yes supertype contains non-mandatory features or asso-ciations

yes supertype contains no features orassociations

delete yes no associations to supertype ortype compatible; new features insupertype

yes no associations to supertype ortype compatible; no new featuresin supertype

yes supertype has adjacent manda-tory association ends; change nottype compatible

yes supertype has adjacent non-mandatory association ends;change not type compatible

IsOfType yes new type is supertype; generalcase

yes new type is supertype; specialcase for association end withmandatory other end

yes new type is subtype and instan-ces are type compatible

yes new type is no sub- or supertype

RefersTo yes

CanRaise yes

76

C. Code-Snippets 77

Tabelle B.2.: MOF 1.4 Non-Breaking Anderungen nach [BG10]

C. Code-Snippets

public static boolean checkAttributeBounds(Object a, Object b) List<ETypedElement> removedAttributes = (List<ETypedElement>)

computeDifference(a, b);

List<ETypedElement> addedAttributes = (List<ETypedElement>)computeDifference(

a, b);if (removedAttributes == null)

return false;for (ETypedElement li : removedAttributes)

if ( li .getLowerBound() > 0) return true;

for (ETypedElement li : addedAttributes)

if ( li .getLowerBound() > 0) return true;

return false;

Listing 6.3: Uberprufung von der Untergrenze einer Referenz oder einem Attribut

public static boolean isPullUpFeature(Object oldValue, Object newValue,Object clazz)

if (clazz == null) return true;

List<?> deletedItems = computeDifference(oldValue, newValue);EList<EStructuralFeature> features = ((EClass) clazz)

.getEAllStructuralFeatures();for (Object item : deletedItems)

EStructuralFeature deletedFeature = (EStructuralFeature)item;

if (! containsFeature(features , deletedFeature)) return false;

return true;

Listing 6.4: Uberprufung, ob ein Feature zu einem Supertyp verschoben ist

77

78 Anhang

public static boolean isParentAbstract(Object clazz) return ((EClass) clazz).isAbstract() ;

Listing 6.5: Uberprufung, ob eine Klasse abstrakt ist.

public static boolean containsNonAbstractClasses(Object oldValue, ObjectnewValue)

List<EClassifier> deletedItems = (List<EClassifier>)computeDifference(oldValue, newValue);

boolean containsNonAbstractClasses = false;for( EClassifier clazz : deletedItems)

if (clazz instanceof EClass)EClass eclazz = (EClass) clazz;if (! eclazz .isAbstract())

containsNonAbstractClasses=false;

return containsNonAbstractClasses;

Listing 6.6: Uberprufung, ob die gelosche Elemente nicht abstrakte Klassen enthalten

78

C. Code-Snippets 79

public static boolean checkSupertypeBounds(Object a, Object b) boolean status = false;List<EClass> addedElements = (List<EClass>)

computeDifference(b,a);for (EClass li : addedElements)

if (checkReferenceBounds(li) || checkAttributeBounds(li)) status = true;

List<EClass> deletedElements = (List<EClass>)computeDifference(a, b);

for (EClass li : deletedElements) if (checkReferenceBounds(li) || checkAttributeBounds(li))

status = true;

return status;

private static boolean checkReferenceBounds(EClass li) for (EReference reference : li .getEReferences())

if ( reference .getLowerBound() > 0) return true;

return false;

private static boolean checkAttributeBounds(EClass li) for (EAttribute reference : li .getEAllAttributes())

if ( reference .getLowerBound() > 0&& reference.getDefaultValue() == null)

return true;

return false;

Listing 6.7: Uberprufung von der Untergrenze von den Supertypen

79

80 Anhang

public static boolean verifyDeletedElementsType(Object oldValue,Object newValue)

List<?> elements = computeDifference(oldValue, newValue);for (Object element : elements)

if (verifyDeletedElementType(element)) return true;

return false;

private static boolean verifyDeletedElementType(Object obj) if (obj instanceof EClass)

return true;if (obj instanceof EEnum)

return false;if (obj instanceof EDataType)

return false;return false;

Listing 6.8: Uberprufung der geloschten Element

D. Implementierte Konformitatsbedingungen mit drools

rule ”AttributeChange EAttribute id”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”id”, oldValue==false,newValue==true )

thenend

Listing 6.9: AttributeChange EAttribute id

rule ”AttributeChange EClass abstract”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”abstract”, oldValue==false,newValue==true)

thenend

Listing 6.10: AttributeChange EClass abstract

80

D. Implementierte Konformitatsbedingungen mit drools 81

rule ”AttributeChange EClass interface”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”interface”, oldValue==false,newValue==true)

thenend

Listing 6.11: AttributeChange EClass interface

rule ”ReferenceChange EClass add Attribute/Reference”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.REFERENCE, parameter==”eStructuralFeatures”,DroolsUtils.checkAttributeBounds(newValue,oldValue))

thenend

Listing 6.12: ReferenceChange EClass add Attribute/Reference

rule ”ReferenceChange EClass remove Attribute/Reference”when

diff : IDiff ( operationType == OperationType.DELETE, differenceType ==DiffType.REFERENCE, parameter==”eStructuralFeatures”,DroolsUtils.isPullUpFeature(oldValue,newValue,newParent))

thenend

Listing 6.13: EClass remove Attribute/Reference

rule ”ReferenceChange EClass add Supertype”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.REFERENCE, parameter==”eSuperTypes”,DroolsUtils.checkSupertypeBounds(oldValue,newValue))

thenend

Listing 6.14: ReferenceChange EClass add Supertype

rule ”ReferenceChange EClass delete Supertype”when

diff : IDiff ( operationType == OperationType.DELETE, differenceType ==DiffType.REFERENCE, parameter==”eSuperTypes”,DroolsUtils.checkSupertypeBounds(oldValue,newValue))

thenend

Listing 6.15: ReferenceChange EClass delete Supertype

81

82 Anhang

rule ”ReferenceChange EEnum delete literal”when

diff : IDiff ( operationType == OperationType.DELETE, differenceType ==DiffType.REFERENCE, parameter==”eLiterals”)

thenend

Listing 6.16: ReferenceChange EEnum delete literal

rule ”AttributeChange ENamedElement”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”name”, !oldValue.equals(newValue) )

thenend

Listing 6.17: AttributeChange ENamedElement

rule ”AttributeChange EPackage nsURI”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”nsURI”, !oldValue.equals(newValue))

thenend

Listing 6.18: AttributeChange EPackage nsURI

rule ”AttributeChange EPackage nsPrefix”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”nsPrefix”,!oldValue.equals(newValue) )

thenend

Listing 6.19: AttributeChange EPackage nsPrefix label

rule ”ReferenceChange eClassifier delete EClass/EENum/EDataType”when

diff : IDiff ( operationType == OperationType.DELETE, differenceType ==DiffType.REFERENCE, parameter==”eClassifiers”,DroolsUtils.verifyDeletedElementsType(oldValue, newValue))

thenend

Listing 6.20: ReferenceChange eClassifier delete EClass/EENum/EDataType

82

D. Implementierte Konformitatsbedingungen mit drools 83

rule ”ReferenceChange eClassifier move EClass/EENum/EDataType”when

diff : IDiff ( operationType == OperationType.MOVE, differenceType ==DiffType.REFERENCE, parameter==”eClassifiers”)

thenend

Listing 6.21: ReferenceChange eClassifier move EClass/EENum/EDataType

rule ”AttributeChange EReference containment”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”containment”,!oldValue.equals(newValue) )

thenend

Listing 6.22: AttributeChange EReference containment

rule ”AttributeChange EReference eOpposite”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”eOpposite”, oldValue==null,newValue!=null )

thenend

Listing 6.23: AttributeChange EReference eOpposite

rule ”EStructuralFeature volatile”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”volatile”,!oldValue.equals(newValue) )

thenend

Listing 6.24: EStructuralFeature volatile

rule ”EStructuralFeature transient”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”transient”,!oldValue.equals(newValue) )

thenend

Listing 6.25: EStructuralFeature transient

83

84 Anhang

rule ”EStructuralFeature unsettable”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”unsettable”,oldValue==true,newValue==false)

thenend

Listing 6.26: EStructuralFeature unsettable

rule ”EStructuralFeature derived”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”derived”,!oldValue.equals(newValue))

thenend

Listing 6.27: EStructuralFeature derived

rule ”EStructuralFeature eContainingClass”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”eContainingClass”,!oldValue.equals(newValue))

thenend

Listing 6.28: EStructuralFeature eContainingClass

rule ”AttributeChange ETypedElement unique”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”unique” )

thenend

Listing 6.29: AttributeChange ETypedElement unique

rule ”AttributeChange ETypedElement lower bound”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”lower bound”, oldValue<newValue )

thenend

Listing 6.30: AttributeChange ETypedElement lower bound

84

E. Installation und Gebrauchsanleitung 85

rule ”AttributeChange ETypedElement upper bound”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”upper bound”, oldValue<newValue )

thenend

Listing 6.31: AttributeChange ETypedElement upper bound

rule ”AttributeChange ETypedElement eType”when

diff : IDiff ( operationType == OperationType.ADD, differenceType ==DiffType.ATTRIBUTE, parameter==”eType”,!DroolsUtils.isAssignableFrom(oldValue, newValue))

thenend

Listing 6.32: AttributeChange ETypedElement eType

E. Installation und Gebrauchsanleitung

Fur die wettere Entwicklung dieser Arbeit werden im folgenden Abschnitt wird die Ent-wicklungsumgebung und die benotigten Eclipse Plug-Ins beschrieben. In Kapitel E.2 wirddie API und die GUI weiter erklart.

E.1. Installation

Als Entwicklungsumgebung wird Eclipse 4.2 IDE for Java EE Developers( http://www.

eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr2) ver-wendet. Dazu mussen die benotigten Plug-Ins installiert werden. Es ist wichtig, dieReihenfolge zuhalten. Das Plug-In XCore ist optional und wird fur die Ausfuhrung desKonzepts nicht benotigt. Weil das EMF Model mit XCore definiert ist, wird das Plug-Inplugin zum Offnen der Datei benotigt.

1. EMF 2.9.0 - http://download.eclipse.org/modeling/emf/emf/updates/

nightly

2. EMF Compare - http://download.eclipse.org/modeling/emf/compare/

updates/milestones/2.1/S201305281426/

• EMF Compare Core

• EMF Compare Core SDK

• EMF Compare IDE UI

• EMF Compare IDE SDK

3. XText 2.4.1 - http://download.eclipse.org/modeling/emf/compare/updates/

milestones/2.1/S201305281426/

• XText

• XCore (Optional)

Am Schluss muss der Quellkode importiert werden. Der Quellkode ist im CD beigefugt.

85

http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr2

http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr2

http://download.eclipse.org/modeling/emf/emf/updates/nightly

http://download.eclipse.org/modeling/emf/emf/updates/nightly

http://download.eclipse.org/modeling/emf/compare/updates/milestones/2.1/S201305281426/




86 Anhang

E.2. Gebrauchsanleitung

In diesem Abschnitt wird die Verwendung der API und der GUI beschrieben.

E.2.1. API

Um die Plug-Ins programmatisch zu verwenden, kann die Klasseedu.kit.sdq.modeljoin.compliance.validator.Validator verwendet werden. Die MethodeisCompliant(newMetamodel, oldMetamodel) uberpruft, ob oldMetamodel mit newMeta-model konform ist. Weitere Beispiele konnen im selben Projekt unter tests gefundenwerden.

Der Quellkode besteht aus 7 Projekten, die im folgenden beschrieben werden.

• edu.kit.sdq.modeljoin.compliance.feature - Ein Feature-Projekt beschreibt die Listemit allen Plugins und wird spater fur eine eventuelle p2-Repository benotigt.

• edu.kit.sdq.modeljoin.compliance.diffengine - Dieses Projekt enthalt die Implemen-tierung des DiffEngine. Die Klasse EMFCompareDiffEngine enthalt die Logik zurBerechnung eines Diffs mit EMFCompare.

• edu.kit.sdq.modeljoin.compliance.model - In diesem Projekt ist das abstrakte Modellimplementiert. Dafur wird XCore verwendet. Die XCore-Datei befindet sich immodel/.

• edu.kit.sdq.modeljoin.compliance.registry - Die Regel werden mit der Hilfe vonDrools implementiert. Sie befinden sich unter rules/. Die Klasse DroolsCompliance-Validator enthalt die Logik zur Ausfuhrung von den Regeln.

• edu.kit.sdq.modeljoin.compliance.repository -

• edu.kit.sdq.modeljoin.compliance.ui - Hier werden die UI-Elemente wie z.B. Sichten,Dialogs und Kontextmenus erstellt.

• edu.kit.sdq.modeljoin.compliance.validator - Dieses Projekt implementiert die imAbbildung 4.11 dargestellte Logik.

E.2.2. GUI

Um die Anwendung zu starten, starten Sie diese uber die Datei product.product inedu.kit.modeljoin.compliance.ui als Eclipse Application.

Als erstes mussen einige Einstellungen gemacht werden. In Windows –> Preferences –>Compliance Validator sollen die Pfaden Metamodels Folder und Rules Folder gesetzt wer-den. Metamodels Folder bestimmt der Pfad, wo die Ziel-Metamodelle gespeichert werden.Rules Folder ist die Stelle von den Regeln. Die in dieser Arbeit vorgestellten Regeln sindin dem Projektedu.kit.sdq.modeljoin.compliance.registry/rules zu finden. Bitte, geben Sieden Pfad zu diesen Regeln an.

Uber das Menu Window –> Show View –> Other ... konnen die Views Status View undModel View geoffnet werden.

Erstellen Sie ein neues Projekt und definieren Sie Metamodellen, die Sie vergleichen moch-ten. Selektieren Sie beide im Projekt-Explorer und wahlen Sie mit dem Kontextmenu RunCompliance Validator –> Each Other aus. In Status View sind die Ergebnisse zu sehen.Mit Doppelklick kann detaillierte Information angezeigt werden.

86

Literaturverzeichnis

[AP03] Marcus Alanen und Ivan Porres: Difference and Union of Models. In: UML,Seiten 2–17. Springer, 2003.

[arg13] ArgoUML, 2013. http://argouml.tigris.org.

[BdR06] W. Beaton und J. d. Rivieres: Eclipse Platform Technical Overview. Techni-scher Bericht, The Eclipse Foundation, 2006.

[BE09] Lars Bendix und Par Emanuelsson: Requirements for Practical Model Merge —An Industrial Perspective. In: Proceedings of the 12th International Conferenceon Model Driven Engineering Languages and Systems, MODELS ’09, Seiten167–180, Berlin, Heidelberg, 2009. Springer-Verlag, ISBN 978-3-642-04424-3.http://dx.doi.org/10.1007/978-3-642-04425-0_13.

[Bec08] Steffen Becker: Coupled model transformations for QoS enabled component-based software design. Dissertation, Karlsruhe, 2008, ISBN 978-3-86644-271-9.

[BG10] Erik Burger und Boris Gruschko: A Change Metamodel for the Evolution ofMOF-Based Metamodels. In: Gregor Engels, Dimitris Karagiannis und Hein-rich C. Mayr (Herausgeber): Modellierung 2010, Klagenfurt, Austria, March24-26, 2010, Band P-161 der Reihe GI-LNI, 2010. http://sdqweb.ipd.kit.

edu/publications/pdfs/burger2010a.pdf.

[BGGK07] Steffen Becker, Thomas Goldschmidt, Boris Gruschko und Heiko Koziolek:A Process Model and Classification Scheme for Semi-Automatic Meta-ModelEvolution. In: Proc. 1st Workshop MDD, SOA und IT-Management (MSI’07).GiTO-Verlag, 2007.

[BHS+13] Erik Burger, Jorg Henss, Kruse Steffen, Martin Kuster und Lucia Happe: View-based Model-driven Software Development with ModelJoin. Manuskript, 2013.

[BKR09] Steffen Becker, Heiko Koziolek und Ralf Reussner: The Palladio componentmodel for model-driven performance prediction. Band 82, Seiten 3–22, NewYork, NY, USA, Januar 2009. Elsevier Science Inc. http://dx.doi.org/10.1016/j.jss.2008.03.066.

[BLD+11] Basil Becker, Leen Lambers, Johannes Dyck, Stefanie Birth und Holger Gie-se: Iterative development of consistency-preserving rule-based refactorings. In:Proceedings of the 4th international conference on Theory and practice ofmodel transformations, ICMT’11, Seiten 123–137, Berlin, Heidelberg, 2011.Springer-Verlag, ISBN 978-3-642-21731-9. http://dl.acm.org/citation.

cfm?id=2022007.2022016.

[BRR05] Xavier Blanc, Franklin Ramalho und Jacques Robin: Metamodel Reuse withMOF. In: Lionel Briand und Clay Williams (Herausgeber): Model Driven

87

http://argouml.tigris.org

http://dx.doi.org/10.1007/978-3-642-04425-0_13

http://sdqweb.ipd.kit.edu/publications/pdfs/burger2010a.pdf

http://sdqweb.ipd.kit.edu/publications/pdfs/burger2010a.pdf

http://dx.doi.org/10.1016/j.jss.2008.03.066

http://dx.doi.org/10.1016/j.jss.2008.03.066

http://dl.acm.org/citation.cfm?id=2022007.2022016


88 Literaturverzeichnis

Engineering Languages and Systems, Band 3713 der Reihe Lecture Notes inComputer Science, Seiten 661–675, Berlin/Heidelberg, 2005. Springer-Verlag,ISBN 3-540-29010-9. http://dx.doi.org/10.1007/11557432_49.

[BVR96] Philippe Breche, Projet Verso und Inria Rocquencourt: Advanced Primitivesfor Changing Schemas of Object Databases, 1996, ISBN 978-3-540-61292-6.http://dx.doi.org/10.1007/3-540-61292-0_26.

[cdo13] CDO Model Repository, Februar 2013. http://www.eclipse.org/cdo.

[CJC11] Caue Clasen, Frederic Jouault und Jordi Cabot: Virtual Composition of EMFModels. In: 7emes Journees sur l’Ingenierie Dirigee par les Modeles (IDM2011), Lille, France, Juli 2011. http://hal.inria.fr/inria-00606374.

[com13] Stackoverflow: What rule engine should I use?, Juni 2013. http://

stackoverflow.com/questions/6613/what-rule-engine-should-i-use.

[ecl13] Eclipse User Interface Guidelines Version 2.1, Marz 2013. http://www.

eclipse.org/articles/Article-UI-Guidelines.

[eda13] Edapt - Framework for Ecore model adaptation and instance migration, Januar2013. http://www.eclipse.org/edapt/libraryexample.php.

[Egy06] Alexander Egyed: Instant consistency checking for the UML. In: Proceedingsof the 28th international conference on Software engineering, ICSE ’06, Seiten381–390, New York, NY, USA, 2006. ACM, ISBN 1-59593-375-1. http://doi.acm.org/10.1145/1134285.1134339.

[emf12] EMF Compare, Dezember 2012. http://wiki.eclipse.org/EMF_Compare/

FAQ.

[emf13a] EMF DiffMerge, Januar 2013. http://wiki.eclipse.org/EMF_DiffMerge.

[emf13b] EMF Documentation, 2013. http://download.eclipse.org/modeling/emf/emf/javadoc/2.9.0/org/eclipse/emf/ecore/package-summary.html.

[emf13c] EMFStore, Februar 2013. http://eclipse.org/emfstore/.

[equ13] Eclipse Equinox, 2013. http://www.eclipse.org/equinox/.

[ext13] FAQ What is the plug-in manifest file (plugin.xml)?, Marz 2013. http://

wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F.

[Fow99] Martin Fowler: Refactoring: improving the design of existing code.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999,ISBN 0-201-48567-2.

[GBB12] Thomas Goldschmidt, Steffen Becker und Erik Burger: View-based Modelling -A Tool Oriented Analysis. In: Proceedings of the Modellierung 2012, Bamberg,Marz 2012.

[gef13] Graphical Editing Framework(GEF), Januar 2013. http://www.eclipse.

org/gef/.

[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides: Design pat-terns: elements of reusable object-oriented software. Addison-Wesley LongmanPublishing Co., Inc., Boston, MA, USA, 1995, ISBN 0-201-63361-2.

88

http://dx.doi.org/10.1007/11557432_49

http://dx.doi.org/10.1007/3-540-61292-0_26

http://www.eclipse.org/cdo

http://hal.inria.fr/inria-00606374

http://stackoverflow.com/questions/6613/what-rule-engine-should-i-use

http://stackoverflow.com/questions/6613/what-rule-engine-should-i-use

http://www.eclipse.org/articles/Article-UI-Guidelines

http://www.eclipse.org/articles/Article-UI-Guidelines

http://www.eclipse.org/edapt/libraryexample.php

http://doi.acm.org/10.1145/1134285.1134339

http://doi.acm.org/10.1145/1134285.1134339

http://wiki.eclipse.org/EMF_Compare/FAQ

http://wiki.eclipse.org/EMF_Compare/FAQ

http://wiki.eclipse.org/EMF_DiffMerge

http://download.eclipse.org/modeling/emf/emf/javadoc/2.9.0/org/eclipse/emf/ecore/package-summary.html

http://download.eclipse.org/modeling/emf/emf/javadoc/2.9.0/org/eclipse/emf/ecore/package-summary.html

http://eclipse.org/emfstore/

http://www.eclipse.org/equinox/

http://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F

http://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F

http://www.eclipse.org/gef/

http://www.eclipse.org/gef/


[Gru07] Boris Gruschko: Towards synchronizing models with evolving metamo-dels. http://www.sciences.univ-nantes.fr/MoDSE2007/p15.pdf, Manu-skript, 2007.

[HBJ08] Markus Herrmannsdoerfer, Sebastian Benz und Elmar Juergens: Automatabi-lity of Coupled Evolution of Metamodels and Models in Practice. In: MODELS2008. VOLUME 5301 OF LNCS, Seiten 645–659. Springer Heidelberg, 2008.

[HBJ09] Markus Herrmannsdoerfer, Sebastian Benz und Elmar Juergens: COPE- Automating Coupled Evolution of Metamodels and Models. In: Pro-ceedings of the 23rd European Conference on ECOOP 2009 — Object-Oriented Programming, Genoa, Seiten 52–76, Berlin, Heidelberg, 2009.Springer-Verlag, ISBN 978-3-642-03012-3. http://dx.doi.org/10.1007/

978-3-642-03013-0_4.

[HM76] J. W. Hunt und M. D. Mcilroy: An Algorithm for Differential File Comparison.Technischer Bericht 41, Bell Laboratories Computing Science, Juli 1976. http://www1.cs.dartmouth.edu/~doug/diff.ps.

[HR85] Frederick Hayes-Roth: Rule-Based Systems. Commun. ACM, 28(9):921–932,1985.

[HVW11] Markus Herrmannsdoerfer, Sander D. Vermolen und Guido Wachsmuth: Anextensive catalog of operators for the coupled evolution of metamodels andmodels. In: Proceedings of the Third international conference on Softwarelanguage engineering, Software Language Engineering 2010, Seiten 163–182,Berlin, Heidelberg, 2011. Springer-Verlag, ISBN 978-3-642-19439-9. http:

//dl.acm.org/citation.cfm?id=1964571.1964585.

[Jef13] Ralph Jeffery: Banking Benchmark Performance: Jess vs.Drools?, 2013. http://blogs.illation.com/2009/08/

banking-benchmark-performance-jess-vs-drools/.

[Joh13] Ernst Johannes: What is metamodeling, and what is it good for?, Marz 2013.http://infogrid.org/trac/wiki/Reference/WhatIsMetaModeling.

[KKPS12] Timo Kehrer, Udo Kelter, Pit Pietsch und Maik Schmidt: Operation-basedModel Differencing meets State-based Model Comparison. In: WorkshopsCom-parison and Versioning of Software Models (CVSM 2012). Springer-Verlag,2012.

[KS06] Ken Kaneiwa und Ken Satoh: Consistency Checking Algorithms for RestrictedUML Class Diagrams. In: Jurgen Dix und StephenJ. Hegner (Herausgeber):Foundations of Information and Knowledge Systems, Band 3861 der Reihe Lec-ture Notes in Computer Science, Seiten 219–239. Springer Berlin Heidelberg,2006, ISBN 978-3-540-31782-1. http://dx.doi.org/10.1007/11663881_13.

[KW11] T. Kunneth und Y. Wolf: Einstieg in Eclipse 3.7: Aktuell zu Indigo und Java7. Galileo Computing. Galileo Press GmbH, 2011, ISBN 9783836216685.

[Lef11] Dean Leffingwell: Agile software requirements : lean requirements practicesfor teams, programs, and the enterprise. Agile software development series.Addison-Wesley, Upper Saddle River, NJ, 2011.

[LEM02] Wenqian Liu, Steve Easterbrook und John Mylopoulos: Rule-Based Detectionof Inconsistency in UML Models. In: Workshop on Consistency Problems in

89

http://www.sciences.univ-nantes.fr/MoDSE2007/p15.pdf

http://dx.doi.org/10.1007/978-3-642-03013-0_4

http://dx.doi.org/10.1007/978-3-642-03013-0_4

http://www1.cs.dartmouth.edu/~doug/diff.ps

http://www1.cs.dartmouth.edu/~doug/diff.ps



http://blogs.illation.com/2009/08/banking-benchmark-performance-jess-vs-drools/

http://blogs.illation.com/2009/08/banking-benchmark-performance-jess-vs-drools/

http://infogrid.org/trac/wiki/Reference/WhatIsMetaModeling

http://dx.doi.org/10.1007/11663881_13

90 Literaturverzeichnis

UML-Based Software Development, Seiten 106–123, 2002. http://www.cs.

toronto.edu/~wl/papers/2002/uml02wl.18.pdf.

[Lev66] Vladimir I. Levenshtein: Binary codes capable of correcting deletions, inserti-ons, and reversals. Technischer Bericht 8, 1966.

[man13] FAQ What is the plug-in manifest file (plugin.xml)?, Marz 2013.http://wiki.eclipse.org/FAQ_What_is_the_plug-in_manifest_file_

%28plugin.xml%29%3F.

[MS09] Ed Merks und James Sugrue: The Essential EMF Cheat Sheet, 2009. http:

//refcardz.dzone.com/refcardz/essential-emf.

[ocl12] OCL (Object Constraint Language), Dezember 2012. http://www.eclipse.

org/projects/project.php?id=modeling.mdt.ocl.

[omg11] omg: Meta Object Facility (MOF) Core Specification Version 2.4.1, 2011.http://www.omg.org/spec/MOF/2.4.1/PDF/.

[omg13] Object Management Group(OMG), Januar 2013. http://www.omg.org.

[pal12] Palladio Simulator, Dezember 20012. http://www.palladio-simulator.

com.

[pro13] Stackoverflow: What rule engine should I use?, Ju-ni 2013. http://stackoverflow.com/questions/2167358/

pros-and-cons-of-java-rules-engines.

[RA79] H. Raffee und B. Abel: Wissenschaftstheoretische Grundlagen der Wirtschafts-wissenschaften. WiSt-Taschenbucher. Vahlen, 1979.

[RE12] Alexander Reder und Alexander Egyed: Incremental Consistency Checkingfor Complex Design Rules and Larger Model Changes. In: RobertB.France, Jurgen Kazmeier, Ruth Breu und Colin Atkinson (Herausgeber):Model Driven Engineering Languages and Systems, Band 7590 der Rei-he Lecture Notes in Computer Science, Seiten 202–218. Springer BerlinHeidelberg, 2012, ISBN 978-3-642-33665-2. http://dx.doi.org/10.1007/

978-3-642-33666-9_14.

[RH08] Ralf H. Reussner und Wilhelm Hasselbring: Handbuch der Software-Architektur. dPunkt.verlag Heidelberg, 2. Auflage, December 2008,ISBN 3898645592.

[rul13] Open Source Rule Engines, Juni 2013. http://java-source.net/

open-source/rule-engines.

[Rup07] Chris Rupp (Herausgeber): Requirements-Engineering und -Management: professionelle, iterative Anforderungsanalyse fur die Praxis. Han-ser, Munchen, 4., aktualisierte und erw. aufl. Auflage, 2007,ISBN 3-446-40509-7; 978-3-446-40509-7.

[SBPM08] Dave Steinberg, Frank Budinsky, Marcelo Paternostro und Ed Merks: EMF:Eclipse Modeling Framework (2nd Edition). Addison-Wesley Professional,2. Auflage, Dezember 2008, ISBN 0321331885.

[SFG99] H Sharp, A Finkelstein und G Galal: Stakeholder identification in the requi-rements engineering process. Proceedings Tenth International Workshop onDatabase and Expert Systems Applications DEXA 99, 0(Dexa 1999):387–391,1999. http://eprints.ucl.ac.uk/744/.

90

http://www.cs.toronto.edu/~wl/papers/2002/uml02wl.18.pdf

http://www.cs.toronto.edu/~wl/papers/2002/uml02wl.18.pdf

http://wiki.eclipse.org/FAQ_What_is_the_plug-in_manifest_file_%28plugin.xml%29%3F

http://wiki.eclipse.org/FAQ_What_is_the_plug-in_manifest_file_%28plugin.xml%29%3F

http://refcardz.dzone.com/refcardz/essential-emf

http://refcardz.dzone.com/refcardz/essential-emf

http://www.eclipse.org/projects/project.php?id=modeling.mdt.ocl

http://www.eclipse.org/projects/project.php?id=modeling.mdt.ocl

http://www.omg.org/spec/MOF/2.4.1/PDF/

http://www.omg.org

http://www.palladio-simulator.com

http://www.palladio-simulator.com

http://stackoverflow.com/questions/2167358/pros-and-cons-of-java-rules-engines

http://stackoverflow.com/questions/2167358/pros-and-cons-of-java-rules-engines

http://dx.doi.org/10.1007/978-3-642-33666-9_14

http://dx.doi.org/10.1007/978-3-642-33666-9_14

http://java-source.net/open-source/rule-engines

http://java-source.net/open-source/rule-engines

http://eprints.ucl.ac.uk/744/


[Sta73] Herbert Stachowiak: Allgemeine Modelltheorie. Springer-Verlag, 1973,ISBN 9783211811061.

[Sta07] Gernot Starke: Regelbasierte Systeme. Java SPEKTRUM, 6:36–38, 2007. http://www.sigs.de/publications/js/2007/06/starke_JS_06_07.pdf.

[SVEH07] Thomas Stahl, Markus Volter, Sven Efftinge und Arno Haase: ModellgetriebeneSoftwareentwicklung: Techniken, Engineering, Management. dpunkt, Heidel-berg, 2. Auflage, 2007, ISBN 978-3-89864-448-8.

[ten13] Eclipse Teneo, Februar 2013. http://wiki.eclipse.org/Teneo.

[Wac07] Guido Wachsmuth: Metamodel Adaptation and Model Co-adaptation. In: ErikErnst (Herausgeber): ECOOP 2007 - Object-Oriented Programming, Band4609 der Reihe Lecture Notes in Computer Science, Seiten 600–624. Sprin-ger Berlin Heidelberg, 2007, ISBN 978-3-540-73588-5. http://dx.doi.org/

10.1007/978-3-540-73589-2_28.

[XS05] Zhenchang Xing und Eleni Stroulia: UMLDiff: an algorithm for object-orienteddesign differencing. In: Proceedings of the 20th IEEE/ACM international Con-ference on Automated software engineering, ASE ’05, Seiten 54–65, New York,NY, USA, 2005. ACM, ISBN 1-58113-993-4. http://doi.acm.org/10.1145/1101908.1101919.

91

http://www.sigs.de/publications/js/2007/06/starke_JS_06_07.pdf

http://www.sigs.de/publications/js/2007/06/starke_JS_06_07.pdf

http://wiki.eclipse.org/Teneo

http://dx.doi.org/10.1007/978-3-540-73589-2_28

http://dx.doi.org/10.1007/978-3-540-73589-2_28

http://doi.acm.org/10.1145/1101908.1101919

http://doi.acm.org/10.1145/1101908.1101919

Documents

Wiederverwendung von Metamodellen in ModelJoin-Sichten · und Datenorganisation(IPD) Erstgutachter: Prof. Dr. Ralf H. Reussner Zweitgutachter: Prof. Dr. Walter F. Tichy Betreuender