Studentische Arbeiten
Entwicklung eines Werkzeugs zur Metamodell-Modell Co-Evolution
Typ der Arbeit:
Master-Thesis
Bearbeitungsstand: Laufende Arbeiten
Möglicher Beginn der Arbeit: 13.03.2024
Betreuer*in: Dr.-Ing. Lars Fritsche
Student*in: Luise Mai
Motivation
Ein Ziel des Model-driven Software Engineering, also der modellgetriebenen Software Entwicklung, ist es, eine schnellere und intuitivere Arbeitsweise zu ermöglichen. Modelle erlauben es, die Eigenschaften und Beziehungen zwischen einzelnen Elementen der Software in einer leichter verständlichen Art und Weise darzustellen. Da aber häufig verschiedene Instanzen mit gleicher allgemeiner Struktur benötigt werden, ist es sinnvoll, diese Struktur als Grundlage festzulegen.
Beispiel: Bibliotheksverwaltung
Wenn verschiedene Bibliotheken betrachtet werden, zeigt sich, dass diese sehr ähnlich aufgebaut sind. Es gibt viele Bücher, Angestellte und Menschen, die sich Bücher ausleihen. Jeder Mensch und jedes Buch wird von Attributen beschrieben. Diese allgemeine Struktur lässt sich wie in Abb. 1 als Metamodell darstellen.
Abbildung 1: Metamodell für Bibliotheksverwaltungen (vereinfacht).
Mithilfe von Elementen wie Klassen und Referenzen zwischen den Objekten wird modelliert, wie die einzelnen Bestandteile definiert sind und wie sie in Verbindung zueinander stehen. Metamodelle geben
somit eine Struktur vor, die von den konkreten Instanzen eingehalten werden muss. Basierend auf diesem Metamodell, können konkrete Instanzen (Modelle) erstellt werden. Instanzen
müssen die Vorgaben des Metamodells und ggf. zusätzliche Bedinungen (constraints) erfüllen. Dafür kann Code generiert werden, auf den dann die weitere Software aufbauen kann. So wird die Implementierung der Struktur des Programms, insbesondere zu Beginn der Entwicklung, erleichtert. Eine konkrete Instanz des Metamodells „Bibliotheksverwaltung“ wäre beispielsweise die Verwaltung der Stadtbibliothek Darmstadt.
Ein Hauptargument für Model-driven Software Engineering ist, dass es die Unterstützung bietet, Software mithilfe der Metamodelle leicht zu entwickeln und bei Bedarf auch zu ändern. Während ihres Lebenszyklus werden Programme weiter entwickelt, um neue Funktionen zur Verfügung zu stellen, Datenstrukturen ändern sich und Fehler werden ausgebessert. Anstatt deshalb komplizierte Code Strukturen mit all ihren Abhängigkeiten anpassen zu müssen, werden die intuitiveren Metamodelle geändert. Hierbei zeigt sich allerdings ein Problem: Wenn das Metamodell verändert wird, nachdem bereits die konkreten Instanzen erstellt wurden, kann es sein, dass eben diese nicht mehr konform zu der neuen Version des Metamodells sind. Daher müssen nun die Instanzen so angepasst werden, dass sie konform zu dem neuen, veränderten Metamodell sind. Diese Anpassung der Instanz an das aktualisierte Metamodell wird auch „Co-evolution von Metamodell und Modell“ genannt. In Bibliotheken gibt es meist unterschiedliche Arten von Medien, die ausgeliehen werden können. Neben Büchern stehen beispielsweise auch DVDs zur Verfügung. Deshalb wurden in Abb. 2 dem ersten Metamodell aus Abb. 1 die Klassen „Medium“ und „DVD“ hinzugefügt. Diese Anpassung muss also auch in den konkreten Instanzen, bspw. der Verwaltung der Stadtbibliothek Darmstadt, umgesetzt werden, damit diese konform zum neuen Metamodell sind.
Abbildung 2: Veränderte Version des ursprünglichen Metamodells für Bibliotheksverwaltung.
Aufgabenstellung
Es soll ein Rahmenwerk angefertig werden, das in 4 Arbeitspaketen entstehen wird:
- Definition eines generischen Metamodells, welches Modelle und Metamodelle zur Laufzeit repräsentiert: Der übliche Aufbau einer Metamodell/Modell-Struktur besteht aus einem Metamodel und (ggf. mehreren) Modellen. Basierend auf dem Metamodell wird Programmcode generiert, in dem die Elemente (Typen) des Metamodells als Klassen dargestellt werden. Ein Modell kann als Laufzeitmodell zum Beispiel aus einer Datei geladen werden und stellt eine Instanz des Metamodells dar. Da es in dieser Arbeit darum geht, Metamodelle kontinuierlich zu verändern, müssen verschiedene Versionen des selben Metamodells zur Laufzeit darstellbar und veränderbar sein. Auch die Verbindung zwischen Metamodell und den Instanzen muss flexibel gestaltet werden, um in der Lage zu sein, strukturelle Änderungen auf Instanzen zu übertragen, wie zum Beispiel eine Änderung des Typs eines Instanzelements. Aus diesem Grund wird eine generisches Metamodell eingeführt, welches sowohl die Metamodell- als auch die Instanzmodellebene generisch darstellt. Somit sind strukturelle Abhängigkeiten Referenzen, die zur Laufzeit verändert werden können. Metamodell und Modell sind damit beides Instanzen des selben generischen Metamodells. Hierdurch entfällt die Notwendigkeit, für zwei verschiedene Metamodellversionen Code zu generieren. Zudem sind wir in der Lage, alle Elemente mit eindeutigen IDs auszustatten. Mithilfe solcher IDs lassen sich gleiche Elemente über verschiedene Modellversionen hinweg identifizieren, ohne Diff-Werkzeuge verwenden zu müssen.
- Änderungen des Metamodells dokumentieren und speichern: Die Änderungen an einem Metamodell werden dokumentiert. Hierfür wird das EMF-Framework benutzt, mit welchem Modelle dargestellt werden und welches bereits in der Lage ist, Modelländerungen über ein Nachrichtensystem nach außen hin verfügbar zu machen. Auf Basis dieser Nachrichten wird ein Historienmodell befüllt und persistiert.
- Erstellung einer Migrationsstrategie durch Zuordnung von Metamodelländerungen zu vorderfinierten oder benutzerdefinierten Migrationskomponenten: Basierend auf den gespeicherten Änderungen zwischen zwei Versionen des Metamodells wird eine Migrationsstrategie erstellt. Diese Strategie wird als eine Sequenz von Migrationskomponenten angegeben, die die durchgeführten Metamodelländerungen abdecken und propagieren. Hierfür ist das Ziel eine textuelle DSL anzubieten, mit der die Orchestrierung der Migrationskomponenten angegeben werden kann. Der Migrationsdesigner wird hierbei unterstützt, in dem überprüft wird, ob alle Metamodelländerungen abgedeckt wurden und Migrationskomponenten tatsächlich kompatibel mit den auswählten feingranularen Änderungen sind. Während die Migrationskomponenten frei anpassbar sind, ist das Ziel anfangs eine Standardmigration zu erzeugen, die dann vom Migrationsdesigner weiter verfeinert oder komplett angepasst werden kann.
- Implementierung der Migrationskomponenten: Auf Basis der in 3. angegebenen Orchestrierung werden Migrationskomponenten aufgerufen, die Metamodelländerungen propagieren. Hierfür muss eine Schnittstelle implementiert werden, die beschreibt, was jede Migrationskomponente an Funktionalitäten anbietet. Außerdem lassen sich nicht alle Informationen über Parameter automatisch übergeben, sondern müssen vom Migrationsdesigner selbst zusammengestellt werden. Hierfür müssen Funktionen bereitgestellt werden, mit denen auf Basis der übergebenen Parameterinformationen über die generischen Modelle navigiert werden kann. Außerdem muss es möglich sein, effizient zusammengehörige Elemente über Versionen hinweg zu identifizieren.
Literatur
[1] Angela Bonifati, Peter Furniss, Alastair Green, Russ Harmer, Eugenia Oshurko, and Hannes
Voigt. Schema Validation and Evolution for Graph Databases. In Conceptual Modeling. Springer
International Publishing, 2019.
[2] Soumaya Boukettaya, Ahlem Nabli, and Faiez Gargouri. Data Migration in Graph-oriented Databa-
ses. Res. Comput. Sci., 149(10):317–336, 2020.
[3] Andreas Demuth, Roberto E Lopez-Herrejon, and Alexander Egyed. Co-evolution of Metamodels
and Models through Consistent Change Propagation. 2013.
[4] Kai Herrmann, Hannes Voigt, Jonas Rausch, Andreas Behrend, and Wolfgang Lehner. Robust and
simple database evolution. Information Systems Frontiers, 20(1):45–61, 2018.
[5] Wael Kessentini and Vahid Alizadeh. Semi-automated metamodel/model co-evolution: A multi-
level interactive approach. Software and Systems Modeling, 21(5):1853–1876, 2022.
[6] Wael Kessentini, Sahraoui Houari, and Manuel Wimmer. Automated metamodel/model co-
evolution: A search-based approach. Information and Software Technology, 106:49–67, 2019.