Metamodel Evolution in the Context of a MOF-Based Metamodeling Infrastructure
Total Page：16
File Type：pdf, Size：1020Kb
Diplomarbeit Metamodel Evolution in the Context of a MOF-Based Metamodeling Infrastructure eingereicht am 30.09.2008 beim Institut für Theoretische Informatik der Universität Karlsruhe (TH) Dozent: Prof. Dr. P. H. Schmitt Betreuer: Dipl.-Ing. Boris Gruschko, SAP AG Erik Burger Im Bauernbrunnen 8 74821 Mosbach Matrikelnummer: 1146018 E-Mail: [email protected] Versicherung der selbständigen Erarbeitung Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig verfasst und weder ganz oder in Teilen als Prüfungsleistung vorgelegt und keine anderen als die angegebenen Hilfsmittel benutzt habe. Sämtliche Stellen der Arbeit, die benutzten Werken im Wortlaut oder dem Sinn nach entnommen sind, habe ich durch Quellenangaben kenntlich gemacht. Dies gilt auch für Zeichnungen, Skizzen, bildliche Darstellungen und dergleichen sowie für Quellen aus dem Internet. Ort, Datum: Unterschrift: Zuletzt geändert am 27.9.2008 CONTENTS i Contents 1 Introduction 1 1.1 ProblemStatement................................ ........ 1 1.2 Structure ....................................... ...... 1 2 Background 2 2.1 Model-Driven Architecture (MDA) . ............ 2 2.2 Meta-ObjectFacility(MOF) . .......... 2 2.3 JMI ............................................. ... 4 2.4 MOIN............................................ ... 6 3 Changes in MOF-Based Metamodels 8 3.1 Definition ....................................... ...... 8 3.2 Prerequisites ................................... ........ 8 3.3 Classification ................................... ........ 9 3.4 DeterminationofOverallSeverity. .............. 17 3.5 MOIN-SpecificChanges . .. .. .. .. .. .. .. .. .. .. .. .. ........ 19 4 Query Visibility of Changes 21 4.1 Changes Without Effects on Queries and Result Sets . ............... 21 4.2 ChangesAffectingtheResultSet . ........... 21 4.3 ChangesMakingtheQueryInvalid . ........... 22 5 JMI Interfaces 24 5.1 JMIMetamodel.................................... ...... 24 5.2 JMITransformationMetamodel. ........... 28 5.3 ChangesinJMIInterfaces . .......... 31 5.4 AssignmentofMOFChangestoJMIChanges. ........... 33 6 Example 38 6.1 Description ..................................... ....... 38 6.2 SeveritiesregardingM1instances . .............. 39 6.3 SeveritiesregardingQueries . ............. 39 6.4 Transformation into JMI model instance . .............. 39 6.5 SeveritiesregardingJMIinterfaces . ............... 40 7 Related Work 44 7.1 MOFrepositories................................. ........ 44 7.2 MetamodelEvolution .............................. ........ 44 8 Conclusion 46 Bibliography 47 Glossary 49 Appendices A Change Severities Overview 50 CONTENTS ii B OCL Constraints 53 B.1 ChangeMetamodelConstraints . ........... 53 B.2 SeverityConstraints .. .. .. .. .. .. .. .. .. .. .. .. .......... 55 B.3 JMIMetamodelConstraints. .......... 59 B.4 HelperFunctions ................................. ........ 67 LIST OF FIGURES iii List of Figures 1 TheMOFabstractionlayers. .. .. .. .. .. .. .. .. .. .. .. ........ 2 2 The MOF metamodel, simplified view (from [Het06]) . ............. 3 3 Generated Java inheritance patterns (from [JMI02]) . ................ 5 4 TheMOFchangemetamodel ............................. ..... 7 5 Example: Deletion of a class makes M1 data invalid . ............. 10 6 Example: Associationcardinality . ............ 11 7 Example:Compositioncycle .. .. .. .. .. .. .. .. .. .. .. ........ 14 8 Example:Containmentchange . ........ 16 9 Example: Deletion of generalization leads to invalid M1 data ................ 16 10 Example: Typechangeonanassociationend . ............ 17 11 Example: Changeintypehierarchy. ........... 18 12 Example: Inversionoftypehierarchy . ............. 19 13 Query visibility: Adding generalization . ................ 21 14 Query visibility: Deleting generalization . ................. 22 15 Query visibility: Deleting generalization with association................... 23 16 TheJMImetamodel .................................. ..... 26 17 TheJMIprimitivetypepackage . ......... 27 18 TheJMIreflectivepackage . .. .. .. .. .. .. .. .. .. .. .. ........ 27 19 MOFtoJMItransformationprocess . .......... 28 20 Thetransformationmetamodel . .......... 32 21 Examplemetamodel ................................. ...... 38 22 ChangestepsasChangeMetamodelinstances . ............. 38 23 Examplemetamodel,Version1 . ......... 41 24 Examplemetamodel,Version2 . ......... 42 25 JMI interfaces of example metamodel, Version 2 . .............. 43 Abstract The evolution of software systems can produce incompatibilities with existing data and appli- cations. For this reason, changes have to be well-planned, and developers should know the impact of changes on a software system. This also affects the branch of model-driven development, where changes occur as modification of the metamodels that the system is based on. Models that are instantiated from an earlier metamodel version may not be valid instances if the new version of a metamodel. Also, changes in the interface definition may require adaptations to the modeling tools. In this thesis, the impact of meta-model changes is evaluated for the modeling standards Meta Object Facility (MOF) and the interface definition Java Metadata Interface (JMI), based on the Modeling Infrastructure (MOIN) project at SAP, which includes a MOF- based repository and im- plements the JMI standard. For the formalisation of changes to MOF-bases metamodels, a Change Metamodel is introduced to describe the transformation of one version of a metamodel to another by the means of modeling itself. The changes are then classifed by their impact on the compatibility of existing model data and the generated JMI interfaces. The description techniques and change classifications presented in this thesis can be used to implement a mechanism that allows metamodel editors to estimate the impact of metamodel changes with the help of modeling tools that can adapt existing data semi-automatically. Zusammenfassung Die Weiterentwicklung von Software-Systemen kann zu Inkompatibilitäten mit bestehenden Daten und Anwendungen führen. Daher sollten die dabei vollzogenen Änderungen gründlich geplant werden, und Entwickler sollten sich der Folgen von Änderungen an einem Software-System bewusst sein. Dies betrifft auch modellgetriebene Entwicklung, bei der Änderungen in Form von Modifikationen an den zugrundeliegenden Metamodellen auftreten. Bestehende Modelldaten, die aus einer früheren Version des Metamodells heraus instanziiert wurden, sind nicht zwingend gültige Instanzen einer weiterentwi- ckelten Version. Weiterhin können Änderungen in der Schnittstellen-Spezifikation es erfordern, dass vorhandene Modellierungswerkzeuge angepasst werden. In dieser Arbeit werden die Auswirkungen von Änderungen an Metamodellen für die Model- lierungsstandards Meta Object Facility (MOF) und Java Metadata Interface (JMI) untersucht. Dies geschieht anhand des SAP-Projektes Modeling Infrastructure (MOIN), welches ein MOF-basiertes Metadaten-Repository enthält und den JMI-Standard implementiert. Für die formale Definiton von Änderung an MOF-basierten Metamodellen wird zuerst ein Ände- rungs-Metamodell (Change Metamodel) vorgestellt, mithilfe dessen die Transformation einer Metamo- dell-Version zur nächsten unter Verwendung von Modellierungstechniken beschrieben werden kann. Diese Änderungen werden dann anhand ihrer Auswirkung auf die Kompatibilität zu bestehenden Modelldaten und Schnittstellen klassifiziert. Die Beschreibungstechniken und die Klassifizierung, die in dieser Arbeit vorgestellt werden, können für eine Implementierung genutzt werden, die es Metamodell-Entwicklern erlaubt, die Folgen von Änderungen an Metamodellen für bestehende Daten und Anwendungen einzuschätzen und diese mit halbautomatischer Unterstützung anzupassen. 1 INTRODUCTION 1 1 Introduction One of the challenges in software development is the handling of evolutionary changes in a software system. If a system evolves, the functionality and the interfaces may be changed in a way that existing applications that are built on top of this system cannot continue working without adaptation to the new circumstances. For this reason, changes to a system have to be well-planned, and the impact on existing data and application must be described so that existing applications can be adapted. In order to keep this effort as small as possible, it is preferable if the effect of changes on existing installations is predictible, so that the modification of a system can be performed with knowledge of the impact it may have. In the field of model-driven development, systems are described by modeling languages such as the Meta Object Facility (MOF). Together with the graphical notation of the Unified Modeling Language (UML), domain-specific metamodels are created that reflect the properties of a certain business domain. These metamodels are afterwards instantiated as actual models by customers for the description of their data. 1.1 Problem Statement Like every kind of software component, metamodels are also subject to evolutionary changes, for example if a new version of the piece of software that includes the metamodel is released. If customers of this software have built models with the previous version, they rely on the availability of migration rules to adapt their model content to the new version. On the side of the software developer, the editor of the metamodel should be aware of the way in which changes to the metamodel layout will affect the compatibility to existing data in terms of metamodel compliance and interface compatibility, so that