Klassifikation von Modelltransformationen feat. feature diagrams Andreas Blunk blunk@informatik.hu-berlin.de 1
Agenda 1. Einführung in Modelltransformationen 2. Vorstellung von Merkmalsdiagrammen 3. Beschreibung der Merkmale von Modelltransformationen (auszugsweise am Beispiel von Transformationsregeln) 4. Einteilung der Modelltransformationen in Kategorien Model-to-Code Model-to-Model 2
1. Einführung MDA = Intiative der OMG für Softwareentwicklung auf der Basis von Modellen automatische Umwandlung PIM-nach-PSM MDA-Basismuster: Transformation PSM Java PIM Transformation PSM C++ 3
1. Einführung MOF + UML bieten gesicherte Basis für die Definition von PIM s und PSM s Aber: keine solche existiert für die Transformation von PIM s in PSM s MDA-Basismuster: Transformation PSM Java PIM Transformation PSM C++ 4
1. Einführung MOF + UML bieten gesicherte Basis für die Definition von PIM s und PSM s Aber: keine solche existiert für die Transformation von PIM s in PSM s 2002: Standardisierungprozess für Modelltransformation durch OMG initiiert (QVT RFP siehe nachfolgender Vortrag) Motiviert durch OMG und Bedarf in der Praxis: vielzahl von Ansätzen für Modelltransformationen 5
2. Merkmalsmodellierung Merkmalsmodell ( feature model ) als Ergebnis der Domain-Analyse Darstellung der Gemeinsamkeiten und Unterschiede zwischen den Mitgliedern einer Systemfamilie Merkmalsdiagramm ( feature diagram ) grafische Notation zur Darstellung von Abhängigkeiten zwischen Merkmalen beschreibt alle möglichen Konfigurationen bzw. Instanzen eines Systems Anwendungsfelder: - Entwurf domänspezifischer Sprachen - Beschreibung von Produktfamilien 6
2. Merkmalsmodellierung verbindlich optional exklusive Auswahl inklusive Auswahl besteht aus 7
2. Merkmalsmodellierung verbindlich optional exklusive Auswahl inklusive Auswahl besteht aus Instanz = Auswahl atomarer Merkmale mögliche Instanzen: 12 1 (Karrosserie) x 3 (Motor) x 2 (Schaltung) x 2 (Anhängerkupplung) = 12 8
3. Merkmale von Modelltransformationen Das Merkmalsmodell für Modelltransformationen: Darstellung der möglichen Entwurfsentscheidungen 8 Hauptunterscheidungspunkte 9
3. Merkmale Transformationsregeln 10
3. Merkmale Transformationsregeln LHS (left-hand side): operiert auf dem Quellmodell RHS (right-hand side): erweitert das Zielmodell LHS/RHS: Darstellung als Mix aus. Variablen, Mustern und Logik 11
3. Merkmale Transformationsregeln LHS (left-hand side): operiert auf dem Quellmodell - enthalten Elemente aus dem Quell- oder Zielmodell RHS (right-hand side): erweitert das Zielmodell LHS/RHS: Darstellung als Mix aus. Variablen, Mustern und Logik 12
3. Merkmale Transformationsregeln - enthalten Elemente aus dem Quell- oder Zielmodell - Modellfragmente der Quelle oder des Ziels mit 0 n Variablen - Zeichenketten (in Templates) - Term- oder Graph-Muster (in Model-to-Model) - Darstellung in abstrakter oder konkreter Syntax in der Quell- oder Zielmodellsprache 13
3. Merkmale Transformationsregeln - Modellfragmente der Quelle oder des Ziels mit 0 n Variablen - Zeichenketten (in Templates) - Term- oder Graph-Muster (in Model-to-Model) - Darstellung in abstrakter oder konkreter Syntax in der Quell- oder Zielmodellsprache - untypisiert - syntaktisch typisiert - semantisch typisiert 14
3. Merkmale Transformationsregeln - non-executable = spezifiziert Beziehungen zwischen Modellen - deklarativ: Vor- und Nachbedingungen - imperativ: Operationen z.b. direkte Modell-Manipulation durch API-Aufrufe in einem Programmcode JMI: Java API -> MOF Repository - untypisiert - syntaktisch typisiert - semantisch typisiert 15
3. Merkmale Transformationsregeln - non-executable = spezifiziert Beziehungen zwischen Modellen - deklarativ: Vor- und Nachbedingungen - imperativ: Operationen z.b. direkte Modell-Manipulation durch API-Aufrufe in einem Programmcode JMI: Java API -> MOF Repository LHS/RHS können syntaktisch getrennt auftreten oder aber ohne Trennung (z.b. in einer Transformationsregel implementiert als Java-Programm) 16
4. Kategorien Model-to-Code Model-to-Model visitor based direct-manipulation template based relational graph-transformation Spezialfall von Model-to-Model!? Theoretisch ja: Angabe eines Meta-Modells für die Zielsprache Aber: existierende Compiler arbeiten auf Textdateien, nicht auf Modellen Deshalb besser: Model-to-Text structure-driven hybrid others 17
4. Kategorien Besucher-basiert sehr einfache Methode der Codegenerierung die interne Struktur des Modells wird durchlaufen dabei wird Code erzeugt und als Textstrom ausgegeben Model-to-Code visitor based template based Beispiel: Jamda objektorientiertes Framework in Java API für Modellmanipulation sog. CodeWriters zur Codegenerierung 18
4. Kategorien Template-basiert von den meisten aktuellen MDA-Tools verwendet Template in Text-Form wird als Basis für das Ziel-Modell benutzt darin enthaltene Meta-Tags werden durch Elemente aus dem Quell-Modell ersetzt Model-to-Code visitor based template based Beispiel: AndroMDA durchsucht das Quell-Modell nach markierten Elementen entsprechende Templates werden ausgeführt und Code wird erzeugt 19
4. Kategorien Template-basiert #if ($stringutils.isnotblank($class.packagename)) package $class.packagename; #end public class $class.name #if ($class.generalization) extends ${class.generalization.fullyqualifiedname} #end... #foreach ($attribute in $class.attributes) private $attribute.gettersettertypename $attribute.name #if ($attribute.defaultvaluepresent) = $attribute.defaultvalue #end;... #end Model-to-Code visitor based template based LHS: enthält ausführbare Logik, um das Quell-Modell abzufragen RHS: kombiniert Textfragmente des Templates mit ausführbarer Logik (Auswahl und Wiederholung der abgefragten Elemente) keine syntaktische Trennung zwischen LHS und RHS verschiedene Formen der LHS: imperativ (Java-Code mit API-Zugriff) deklarativ (OCL-Abfragen) 20
4. Kategorien Model-to-Model direct-manipulation relational graph-transformation structure-driven hybrid others 21
4. Kategorien Direkte Manipulation Werkzeuge bieten interne Darstellung des Modells API für Manipulation Model-to-Model direct relational graph-based häufig als objektorientiertes Framework implementiert Transformationsregeln und Anwendungsablauf müssen komplett vom Benutzer implementiert werden (z.b. in Java) 22
4. Kategorien Relationaler Ansatz Model-to-Model basiert auf dem deklarativen Ansatz (aber algebraische Relationen im Vordergrund) direct relational graph-based Regeln bestehen aus Bedingungen nicht ausführbar Aber: können durch ausführbare Semantik erweitert werden (z.b. Elementsuche, Elementmatching aus Logik-Programmierung) 23
4. Kategorien Relationaler Ansatz Demonstration: Transformationssprache ATLAS Abbildung eines Buch auf ein Veröffentlichung RHS enthält zusätzliche Logik zur Auswahl der richtigen Daten aus der LHS Model-to-Model direct relational graph-based Ausschnitt aus der Transformationsdefinition helper context Book!Book def : getauthors() : String = self.chapters->collect(e e.author)->asset()->iterate(authorname; acc : String = '' acc + if acc = ' then authorname else ' and ' + authorname endif ); rule Book2Publication { from b : Book!Book ( b.getnbpages() > 2 ) to out : Publication!Publication ( title <- b.title, authors <- b.getauthors(), nbpages <- b.getnbpages() ) } 24
4. Kategorien Relationaler Ansatz Noch ein relationaler Ansatz: QVT Model-to-Model direct relational Unterscheidung: bi-direktional und nicht ausführbar (Relationen) uni-direktional und ausführbar (Mappings) graph-based mehr dazu im nachfolgenden Vortrag 25
4. Kategorien Graph-basierter Ansatz Transformation von Graphen (auch Graph Rewriting) Model-to-Model direct relational Ansätze operieren auf typisierten Graphen versehen mit Attributen und Bezeichnern speziell geeignet zur Darstellung UML-ähnlicher Modelle graph-based Beschreibung mit Regeln LHS: Pattern L als Vorbedingung RHS: Pattern R als Nachbedingung Transformation besitzt eine deklarative Logik Unterscheidung vom relationalen Ansatz durch Vergleich ganzer Patterns statt nur Variablen 26
4. Kategorien Graph-basierter Ansatz 2 Regeln je eine Pre- und Postcondition (erwarten Parameter) neg-pattern darf nicht eintreten Funktionsweise: in Graph G wird ein Knoten, der Pattern L entspricht gesucht und dann entfernt neuer Knoten mit Pattern R wird in G eingefügt Verbindungen werden durch Einführung neuer Kanten sichergestellt Wiederholung bis keine Regel mehr zutrifft 27
Ende Fazit: viele Werkzeuge noch in Entwicklung welche Transformationstechnik sich durchsetzt wird sich zeigen Quellen: Classification of Model Transformation Approaches (Krzysztof Czarnecki and Simon Helsen) Model Transformation (Peter Birchmeier) Model Driven Software Development - ATLAS Model Management Architecture (Robert Schwarzer) 28