Einleitung
Die Abkürzung QVT steht für „Query / View / Transformation“ und es handelt sich dabei um einen Standard der Object Management Group (OMG) für die Definition und Beschreibung von Modell- und Datentransformationen.
Der Standard ist relativ unbekannt, da es bisher keine nennenswerten praktischen Umsetzungen in Form von Werkzeugen gab, die die Anwendung des Standards möglich gemacht hätten. Da liegt das Problem vieler Standards – wenn sie nicht von irgendwem umgesetzt werden, gibt es sie zwar, aber sie haben keine praxisrelevante Bedeutung.
Dies könnte sich für QVT jetzt aber ändern. Ich habe im Rahmen von mehreren Forschungsprojekten und studentischen Arbeiten immer mal wieder an der praktischen Umsetzung von QVT gearbeitet. Dies begann mit meiner Dissertation 2006, setzte sich in einem Forschungsprojekt fort und fand nun in den letzten drei Jahren in meiner Freizeit und im Rahmen einer studentischen Abschlussarbeit, die ich als Ausbilder betreute, eine weitere Fortsetzung. Manchmal braucht es einfach 20 Jahre und einen langen Atem und Enthusiasmus, um etwas so weit zu bringen, dass man selbst damit zufrieden ist.
Ich möchte QVT nun etwas näherbringen.
Was ist eine Modelltransformation?
Im Rahmen einer modellbasierten Entwicklung im Software- und Systems Engineering entstehen Modelle die Software- oder auch mechatronische Systeme und deren Aspekte spezifizieren oder beschreiben. Bei einer Modelltransformation geht es nun darum ein Modell oder Modellteile in ein anderes Modell umzuwandeln. Der Zweck davon ist, dass man dadurch neue Arten von Modellen automatisch erzeugen kann von denen man dann einen Mehrwert hat (Abbildung 1).
Beispielsweise können so aus technologieunabhängigen Modellen technologieabhängige Modelle gemacht werden aus denen dann zum Beispiel Code oder andere Daten für die Produktumsetzung gewonnen werden. Eine Codegenerierung ist dabei wiederum eine Transformation. Transformation heißt Umwandlung und es werden aus bestehenden Modelldaten andere Daten erzeugt.
Modelltransformationen sind spezielle Datentransformationen
Wenn man Modelle bzw. Modelldaten transformiert, dann transformiert man im Grunde genommen auch nur eine spezielle Art von Datenstruktur in eine andere. Daher sind Modelltransformationen nur ein Spezialfall einer Datentransformation. Man kann auch sagen „einer Datenumwandlung“. Ob man jetzt aus einem Modell z.B. eine JSON-Datei in einem bestimmten Format erzeugt, oder diese Datei auf Basis einer anderen JSON-Datei ist das gleiche Prinzip.
Abbildung 2 zeigt dieses allgemeine Prinzip der Datenumwandlung. Daten werden von einem Transformationswerkzeug eingelesen, umgewandelt und als Zieldaten gespeichert.
Die Anwendungen von Datentransformationen stellt ein häufiges Problem in der Informationstechnik und in der Digitalisierung dar. Oftmals geht es zum Beispiel darum verschiedene Werkzeuge zu verwenden und Daten, die man bereits in einem Werkzeug eingegeben hat für ein weiteres Werkzeug zugänglich zu machen. Wenn die Werkzeuge unterschiedliche Datenformate haben, muss eine Datenumwandlung erfolgen.
Datenumwandlungen werden oft programmiert
Um Daten von einem Format in eine anderes zu wandeln, wird oft Software in Form von Skripten oder spezialisierten Anwendungen entwickelt und programmiert. Dies ist ein gängiger Weg, hat jedoch den Nachteil, dass das Wissen darüber, wie die Daten vom Quell- in das Zielformat gewandelt werden müssen im Softwarecode drinsteckt und für nicht so programmieraffine Personen dieses Wissen somit nicht so ohne weiteres zugänglich ist. Man bezeichnet so etwas auch als eine Black-Box-Transformation. Ein weiterer Nachteil an einer solchen Transformationslösung ist, dass bei einer Änderung der Anforderungen wie etwas transformiert werden soll, immer die Software durch eine Änderung angepasst werden muss. Dies erfordert immer Programmierkenntnisse und kann ein komplexer Prozess sein.
Transformationen mit speziellen Sprachen oder Regeln beschreiben
Ein anderer Ansatz als die Transformationen mit allgemeinen Programmiersprachen zu realisieren ist der Einsatz spezieller Sprachen, die darauf ausgelegt sind, solche Regeln einer Modelltransformation zu beschreiben. Diese Transformationsanweisungen können dann von dafür entwickelten Modell- bzw. Datentransformatoren eingelesen und die Transformation entsprechend durchgeführt werden. Da die Transformationsregeln unabhängig von ihrer Ausführung vorliegen und einfach änderbar sind, spricht man hier von einer White-Box- Transformation.
Abbildung 3 zeigt das Prinzip der Nutzung von Transformationsregeln. Man beschreibt die benötigte Transformation durch spezielle Transformationsregeln und gibt diese in den Daten- oder Modelltransformator rein. Hat man nun eine Änderung an der Transformation werden nur die Regeln angepasst, aber nicht das Transformationswerkzeug selbst. Damit hat man eine No-Code-Lösung für Daten- und Modelltransformationen.
QVT standardisiert die Beschreibung von Transformationsregeln
Der QVT-Standard der OMG standardisiert nun die Art wie man solche Transformationsregeln beschreibt. Dabei definiert der Standard nicht nur eine Möglichkeit Daten- und Modelltransformationen zu beschreiben, sondern gleich mehrere (Abbildung 4).
Am interessantesten ist dabei die QVT-Relationssprache, da diese es erlaubt Transformationen auf deklarative und nicht imperative Art zu beschreiben.
Imperativ bedeutet man definiert eine Reihe von Befehlen, die die Transformation durchführen. Genauso machen es auch Skripte und Programme bei Black-Box-Transformationen: Man sucht mit Schleifen nach Daten und wenn man diese findet, dann prüft man, ob diese zu transformieren sind durch IF-Anweisungen. Wenn ja, dann werden im Zielmodell entsprechend Elemente erzeugt oder verändert.
Im Gegensatz dazu geht man bei einer deklarativen Transformationssprache anders vor. Hierbei definiert man lediglich, wie die Quell- und Zielseite aussieht bzw. aussehen soll. Man geht nach dem Prinzip vor „Das habe ich und das will ich haben.“. Man beschreibt nicht WIE man die Elemente der Quellseite finden muss oder wie die Elemente der Zielseite im Einzelnen angelegt werden müssen. Einen ähnlichen Ansatz einer deklarativen Beschreibung kennt man vielleicht von der Datenbankabfragesprache SQL. Auch hierbei wird deklarativ beschrieben was zum Beispiel ausgewählt werden soll. Es wird nicht imperativ beschrieben wie z.B. „Gehe alle Zeilen einer Datenbanktabelle durch und vergleiche den Inhalt von Spalte A mit dem gegebenen Suchbegriff“. Man beschreibt nur „Ich möchte gerne alle Daten haben, wo der Inhalt von Spalte A dem Suchbegriff entspricht!“. Dies ist eine deklarative Beschreibung.
Ein guter Ansatz, lange ohne Umsetzung
Der QVT-Standard enthält gute Ansätze und Ideen zur Beschreibung von Modell- und Datentransformationen. Leider konnte man diese bisher nicht oder nur schwach benutzen, da es an entsprechenden Werkzeugen und praktischen Umsetzungen fehlte.
Hinzu kommt, dass der QVT-Standard eigentlich vorschlägt Transformationsregeln mit Hilfe der Relationssprache zu beschreiben, diese in die ebenfalls beschriebene Core-Sprache zu transformieren und dann imperativ durch die Operational Mappings-Sprache durchzuführen. Da es keine Umsetzungen dieser ganzen Sprachen gibt, bleibt dies leider ein frommer Wunsch.
Grafische Definition der Transformationsregeln
Da QVT aus dem Bereich der modellbasierten Entwicklung – wie viele andere Standards der OMG – kommt, definiert der QVT-Standard für die Relationssprache nicht nur eine textuelle Syntax, sondern auch eine grafische unter Nutzung von bekannten UML-Modellelementen. Diese bildhafte Darstellung der deklarativen QVT-Relationen erleichtert vielen Anwendern den Einstieg, da grafische Darstellung für viele Personen einfacher zu erfassen sind als textuelle. Nicht umsonst sagt das Sprichwort: „Ein Bild sagt oft mehr als tausend Worte.“.
Die grafische Darstellung einer QVT-Relation basiert im Grunde auf dem UML-Objektdiagramm. Dieses wird um ein paar Elemente erweitert, so dass es möglich wird die Zusammenhänge zwischen Quellseite und Zielseite zu definieren.
In Abbildung 5 ist eine QVT-Relation als grafisches Modell gegeben. Charakteristisch für solche Diagramme ist der sechseckige QVT-Relationsknoten. Dieser dient als Bindeglied zwischen Quelle und Ziel und setzt die Objektstrukturen beider Seiten zueinander „in Relation“. Die Buchstaben „C“ für Check Only und „E“ für Enforce definieren, was die Quell- und Zielseite ist. Bei Check Only werden Daten nur gelesen, bzw. gesucht und bei Enforce (deutsch: umsetzen, erzwingen) muss am Ende der Transformation die dargestellte Objektstruktur so existieren wie sie definiert wurde.
Alle QVT-Transformationen basieren auf Datenmodellen bzw. Metamodellen (siehe auch Datenmodelle in Code und Datenmodellierung mit UML und Was ist ein Metamodell?). Diese geben das Gerüst vor auf dessen Basis dann Objektstrukturen entstehen können.
Im Beispiel aus Abbildung 5 definiert die Relation einen Zusammenhang zwischen Daten von Personen, definiert durch ein einfaches Personen-Datenmodell und dem Sparx Systms Enterprise Architect (UML-Werkzeug) Metamodell.
Die Relation legt fest, dass für jedes gefundene Personen-Objekt ein „Element“-Objekt in Enterprise Architect angelegt werden soll, welches vom Typ „Actor“ sein soll.
Um weitere Daten von der Quelle zum Ziel zu transportieren, werden Variablen mit frei wählbaren Namen verwendet. Im Beispiel gibt es die Variablen „firstName“ und „lastName“, die sich sowohl als Objekteigenschaften auf der Quell- wie auf der Zielseite finden. Bei Check Only werden Daten in die Variablen geschrieben, und auf der Enforce-Seite diese Daten ausgelesen und in die Objekte geschrieben. So bekommt man mit QVT-Relationen Daten von der Quelle zum Ziel.
Die QVT-Umsetzung
Damit es nicht bei Bildern bleibt, braucht es eine Umsetzung eines Transformationswerkzeuges, das die QVT-Regeln als Modelltransformation ausführen kann.
Die Geschichte dieser Umsetzung geht wie oben schon angedeutet 20 Jahre auf die Zeit meiner Dissertation zurück. Dort wurde ein erster Ansatz realisiert, der prinzipiell funktionierte, jedoch aus technischen Gründen so extrem langsam lief, dass er als praxistaugliches Werkzeug leider nicht zu gebrauchen war.
Zehn Jahre später gab es einen neuen Anlauf QVT praxistauglich umzusetzen im Rahmen einer Christian-Doppler-Labor Forschungsmoduls an der TU Wien. Die Idee, die QVT-Umsetzung zu beschleunigen bestand daraus, dass man aus den grafischen QVT-Relationen vollautomatisch C#-Quellcode generiert, der dann übersetzt und ausgeführt werden kann. Diese Umsetzung wurde von Erwan Bousse unter meiner Anleitung 2016 durchgeführt und stellte sich als vielversprechend in Punkto Geschwindigkeit heraus.
Mit dem Ende des Forschungsprojektes konnte dann leider keine Version mehr realisiert werden, die man als besonders benutzerfreundlich bezeichnen würde. Aber die Ergebnisse der Umsetzung wurden zumindest ein Jahr später als Open-Source zur Verfügung gestellt.
In den letzten drei Jahren habe ich das Thema QVT-Umsetzung nun erneut aufgegriffen – immer, wenn es meine Zeit erlaubte. Dabei wurde nun die Benutzerfreundlichkeit durch eine automatische Generierung einer grafischen Benutzeroberfläche stark verbessert. Man kann nun aus dem QVT-Modell direkt ausführbaren Code inklusive einer Benutzeroberfläche generieren und dann direkt Daten- und Modelltransformationen ausführen.
Um diese Umsetzung einmal in Aktion zu sehen, habe ich kürzlich ein erstes Video darüber erstellt:
Ich glaube fest daran, dass es möglich ist Daten- und Modelltransformationen zukünftig vermehrt modellbasiert mit Hilfe von QVT zu beschreiben und durchzuführen. Die Anwendungen sind vielfältig und besonders im Bereich der Modelltransformation ermöglicht eine funktionierende QVT-Umsetzung ganz neue Möglichkeiten für die Nutzung von Modellen im Software- und Systems Engineering.
Falls ich ihr Interesse an QVT geweckt habe, kontaktieren Sie mich gerne für Unterstützung in diesem Umfeld über https://specificator.com