X perf =1.00 X loss =0.01 SDSoftware Design and Quality Designing a Change-Driven Language for Model Consistency Repair Routines Master Thesis of Heiko Klare at the Department of Informatics Institute for Program Structures and Data Organization (IPD) Reviewer: Prof. Dr. Ralf H. Reussner Second reviewer: Jun.-Prof. Dr.-Ing. Anne Koziolek Advisor: Dipl.-Inform. Max. E. Kramer Second advisor: M.Sc. Michael Langhammer 14. December 2015 – 13. June 2016 Karlsruher Institut für Technologie Fakultät für Informatik Postfach 6980 76128 Karlsruhe I declare that I have developed and written the enclosed thesis completely by myself, and have not used sources or means without declaration in the text. Karlsruhe, 10. June 2016 .................................... (Heiko Klare) Abstract A software system under development can be described by several models, which represent dierent concerns or abstractions of the system. These models can contain dependent or even redundant information. Whenever a software developer changes such models without considering their depen- dencies, the models can get inconsistent. A developer can hardly maintain an overview of all models involved in a development process and the dependencies between them. Therefore, automated mechanisms for restoring the consistency after model changes are necessary. Existing approaches provide declarative constructs for specifying the model depen- dencies and automatically derive consistency-restoring mechanisms from them. These approaches have limited expressiveness and only allow restricted inuence on the way consistency is restored. They prescribe a certain way of restoring consistency although dierent possibilities exist. In this thesis, we present the change-driven response language for the repair of model consistency. It allows to specify the way of repair explicitly in imperative routines, which are executed in reaction to specied changes. Besides, the language provides constructs that encapsulate recurring actions and make them reusable. We introduce a consistency denition focused on comprehensibility and a categorization of possible changes within models. The presented language reects a generic structure for change-driven consistency repair, derived from our consistency denition. We provide an evaluation of our approach in a case study realizing the consistency of architecture descriptions and their implementation in object-oriented code. The evaluation conrms the applicability of the proposed language for preserving consistency in that exemplary case and reveals benets compared with a manual implementation. i Zusammenfassung Ein Software-System kann während der Entwicklung durch verschiedene Modelle beschrie- ben werden, um unterschiedliche Teile oder Abstraktionen des Systems darzustellen. Diese Modelle können voneinander abhängige oder sogar redundante Informationen enthalten. Wenn ein Softwareentwickler an solchen Modellen Änderungen vornimmt ohne diese Abhängigkeiten zu beachten, können die Modelle inkonsistent werden. Ein Entwickler ist kaum in der Lage einen Überblick über alle Modelle eines Entwicklungsprozesses und deren Abhängigkeiten zu behalten. Daher sind automatisierte Verfahren zur Wiederherstellung von Konsistenz nach Modelländerungen notwendig. Existierende Methoden erlauben die deklarative Spezikation von Abhängigkeiten zwi- schen Modellen, aus denen automatisiert Mechanismen zur Konsistenzerhaltung abgeleitet werden. Diese Ansätze sind in ihrer Ausdrucksmächtigkeit beschränkt und bieten nur ein- geschränkten Einuss auf die Art und Weise in der Konsistenz wiederhergestellt wird. Sie legen automatisiert eine Art der Wiederherstellung der Konsistenz fest, obwohl es verschiedene Möglichkeiten dafür gäbe. In dieser Arbeit stellen wir die änderungsgetriebene Response-Sprache für die Konsis- tenzerhaltung von Modellen vor. Sie erlaubt es, die Art und Weise der Wiederherstellung von Konsistenz explizit in imperativen Programmen festzulegen, welche als Reaktion auf festgelegte Änderungen ausgeführt werden. Zusätzlich bietet sie Sprachkonstrukte an, die wiederkehrende Reaktionen kapseln und wiederverwendbar machen. Wir führen einen Konsistenzbegri mit dem Fokus auf Verständlichkeit ein und stellen eine Kategorisierung von möglichen Modelländerungen vor. Die Sprache ist entsprechend einer allgemeingülti- gen Struktur für die änderungsgetriebene Wiederherstellung von Konsistenz aufgebaut, welche wir aus unserem Konsistenzbegri herleiten. Wir stellen eine Evaluation unseres Ansatzes anhand einer Fallstudie zur Konsistenzer- haltung von Architekturbeschreibungen und deren Implementierung in objektorientiertem Code vor. Die Evaluation zeigt die Anwendbarkeit der vorgestellten Sprache für die Sicher- stellung von Modellkonsistenz in diesem konkreten Fall und verdeutlicht einige Vorteile gegenüber einer manuellen Implementierung der Mechanismen zur Konsistenzerhaltung. iii Contents Abstract i Zusammenfassung iii 1 Introduction 1 1.1 Describing Software Systems with Models . .1 1.2 Preserving Model Consistency . .2 1.3 The Response Language . .3 1.4 Structure of the Thesis . .4 2 Foundations 5 2.1 Model-Driven Software Development . .5 2.1.1 Metamodels . .6 2.1.2 Meta-Levels . .7 2.1.3 Domain-Specic Languages . .7 2.2 Model Transformations . .8 2.2.1 General Properties of Transformations . .9 2.2.2 Transformation Execution Modes . 10 2.2.3 Transformation Specication Approaches . 11 2.3 The Eclipse Modeling Framework . 12 2.3.1 Essential Meta-Object Facility and Ecore . 13 2.3.2 Textual Domain-Specic Languages with Xtext . 13 2.3.3 Reusable Programming Languages Xbase and Xtend . 14 2.4 View-based Software Development . 15 2.4.1 Projective and Synthetic Views . 16 2.4.2 Orthographic Software Modeling . 16 2.4.3 The Vitruvius Approach . 17 2.5 Change-Driven Development . 19 3 Running Example: Consistency of Soware Architecture and Implementation 21 3.1 A Software Architecture Description Metamodel . 21 3.2 A Metamodel for the Java Programming Language . 23 3.3 Relations between Software Architecture Descriptions and Code Models 25 3.3.1 Repository Mapping . 25 3.3.2 Component Mapping . 26 3.3.3 Interface Mapping . 27 3.3.4 Data Type Mapping . 27 v Contents 4 Model Changes and Model Consistency 29 4.1 Model Consistency . 29 4.1.1 Consistency Overlaps . 29 4.1.2 Identifying Consistency Overlaps . 32 4.1.3 Dependency between Consistency Overlaps . 34 4.1.4 Granularity of Consistency Overlaps . 35 4.1.5 Prescriptive and Descriptive Consistency Overlaps . 37 4.1.6 Correspondence Models . 37 4.1.7 Preserving Model Consistency . 38 4.2 Model Changes . 39 4.2.1 Change Descriptions . 40 4.2.2 Atomic Model Changes . 40 4.2.3 Atomic Model Changes in the Essential Meta-Object Facility . 41 4.2.4 Atomic Model Changes in Ecore . 43 4.2.5 Composite Model Changes . 44 4.3 Change-Driven Model Transformation Environments . 45 4.3.1 Monitors for Model Changes . 45 4.3.2 Transformation Execution Engines . 46 4.3.3 Change-Driven Model Transformations . 47 4.4 Change-Driven Consistency-Restoring Transformations . 47 4.4.1 Atomic Changes as Triggers . 47 4.4.2 Intra-Model Consistency after Atomic Changes . 49 4.4.3 Responsibilities of Transformations . 50 4.4.4 Structure of Transformations . 51 4.4.5 Change-Driven Consistency Repair Languages . 53 5 The Response Language 55 5.1 Introduction to the Response Language . 55 5.1.1 Language Structure . 55 5.1.2 Basic Language Constructs . 56 5.1.3 A Metamodel for Change Descriptions in Ecore . 58 5.2 Triggers: Identifying Potential Inconsistencies . 59 5.2.1 Specifying Change Type and General Preconditions . 60 5.2.2 Restricting Change Properties . 61 5.2.3 Change Type Generalization . 63 5.3 Matchers: Retrieving Elements of Consistency Overlaps . 65 5.3.1 Retrieving Corresponding Elements . 66 5.3.2 Restricting Retrieved Elements by Filter Functions . 67 5.3.3 Restricting Retrieved Elements by Correspondence Tags . 68 5.3.4 Retrieving Optional Elements . 70 5.3.5 Expecting the Non-Existence of Corresponding Elements . 71 5.3.6 Specifying Further Conditions . 71 5.4 Eects: Restoring Consistency . 72 5.4.1 Specifying General Eects . 73 5.4.2 Creating Model Elements . 74 vi Contents 5.4.3 Adding and Removing Correspondences . 75 5.4.4 Deleting Model Elements . 76 5.5 Separating Triggers from Repair Routines . 77 5.5.1 Specifying Repair Routines with Matchers and Eects . 78 5.5.2 Reusing Repair Routines . 79 5.5.3 Iterating Repair Routine Calls . 80 5.6 Language Properties and Responsibilities . 82 5.6.1 Target Models of Responses . 82 5.6.2 Transitivity of Consistency Repair Routines . 82 5.6.3 Visibility of Model States . 83 5.6.4 Persistence of Logical and Physical Models . 84 5.7 Aspects of Restoring Consistency with Responses . 85 5.7.1 Response Execution Order . 85 5.7.2 Modications of Bidirectional References . 85 5.7.3 Interaction with the Model User . 86 5.7.4 Meta-Level Breaks . 87 5.8 Possible Extensions . 89 5.8.1 Composite Change Triggers . 89 5.8.2 Constraint Satisfaction Change Triggers . 90 5.8.3 Explicit Consistency Overlap Type Specication . 91 5.8.4 Extensions for User Interaction . 91 5.8.5 Imperative Code Validation . 92 5.8.6 Language Constructs for Element Modications . 92 6 Response Language Implementation 93 6.1 The Vitruvius Framework . 93 6.1.1 Virtual Single Underlying Model . 93 6.1.2 Correspondences, TUIDs and Changes . 94 6.1.3 Model Synchronization . 95 6.2 Runtime Environment and Transformation Structure . 96 6.2.1 Structure of the Runtime Environment . 96 6.2.2 Runtime Data Structures . 97 6.2.3 Responses . 99 6.2.4