Seite 3: Eclipse Modeling, MetaEdit+, MPS

Inhaltsverzeichnis

Eclipse Modeling und openArchitectureWare

Im Rahmen von eclipse.org wird neben der eigentlichen Plattform eine Reihe von Werkzeugen entwickelt, die mit Modellierung und modellgetriebener Entwicklung zu tun haben. Sie finden sich im Eclipse-Modeling-Projekt, seinen Unterprojekten und -komponenten. Bei Eclipse Modeling handelt es sich genau genommen nicht um ein Produkt, sondern um eine Sammlung von Frameworks und Tools. Kern des Ganzen stellt das Eclipse Modeling Framework (EMF) dar. Es dient zur Beschreibung der abstrakten Syntax von DSLs (des Metamodells). EMF enthält eine Reihe von APIs und Bibliotheken zum Umgang mit EMF-Modellen sowie eine auf XML aufsetzende Persistenzschicht. Mit CDO gibt es zudem eine Anbindung an relationale Datenbanken und andere Repositories.

Neben EMF ist insbesondere das Graphical Modeling Framework (GMF) zu nennen. Mit ihm lassen sich grafische Editoren erstellen (Box-and-Line-Diagramme). Die Erstellung grafischer Editoren ist zwar mit GMF flexibel möglich, bedarf aber einiges an Einarbeitung und Handarbeit, wenn man wirklich benutzbare und skalierbare Editoren entwickeln will. Im Gegensatz zu MetaEdit+ (siehe nächster Abschnitt) ist einiges an detaillierter Konfiguration und teils auch Programmierung notwendig.

Als Gegenstück für textuelle DSLs befindet sich derzeit das Textual Modeling Framework (TMF) in der Entwicklung. Zur Validierung von Modellen existieren unterschiedliche Implementierungen von OCL (Object Constraint Language). Zur Überführung von Modellen in andere Modelle gibt es unterschiedliche, teils auf OMG-Standards beruhende Modelltransformationssprachen, darunter QVT Operational, ATL und Xtend. Zur Codegenerierung kommt insbesondere Xpand zum Einsatz. Allerdings existieren auch hier Alternativen.

Weil Eclipse Modeling kein fertiges Produkt darstellt, gibt es unterschiedliche Distributionen und Zusammenstellungen, die dem Anwender den Umgang mit der großen Menge an Tools und Frameworks erleichtern. Neben kommerziellen Angeboten (beispielsweise Borlands Together) ist insbesondere das Open-Source-Werkzeug openArchitectureWare (oAW) verbreitet.

Eclipse Modeling im Allgemeinen und openArchitectureWare im Besonderen stellen eine bewährte und praxistaugliche Plattform zur modellgetriebenen Entwicklung dar. Der größte Vorteil ist die Flexibilität und Offenheit der Plattform und ihrer Werkzeuge. Viele Aspekte lassen sich – entsprechende Programmierkenntnisse vorausgesetzt – an die eigenen Anforderungen anpassen. Das ist nicht zuletzt deshalb der Fall, weil alle Werkzeuge und Frameworks unter der Eclipse Public Licence (EPL) als Open Source verfügbar sind.

TMF (und sein Vorläufer openArchitectureWare Xtext) unterstützt die Erstellung textueller DSLs und ihrer Editoren. Eine EBNF-artige Grammatik (Extended Backus-Naur Form) dient nicht nur als Basis für Parser und Metamodell, sondern auch für den Eclipse-Editor, der für die DSL Syntax-Highlighting, Code Completion, Go to Definition und andere aus modernen IDEs bekannte Features implementiert.

MetaEdit+

Schon seit 1995 entwickelt und vertreibt die finnischen Firma MetaCase das kommerzielle Produkt MetaEdit+. Sein Fokus liegt auf grafischen DSLs und Codegenerierung. Zur Beschreibung grafischer konkreter Syntax bringt MetaEdit+ einen schönen Editor mit. Mit ihm kann man in WYSIWYG-Manier Symbole erstellen und sie mit den Abstraktionen des Metamodells verbinden. Der damit entwickelte Editor lässt sich direkt in der entsprechenden Laufzeitumgebung zur Modellierung nutzen. Es sind dazu weder Codegenerierung noch ein separater Deployment-Schritt erforderlich, die Editoren sind vollkommen interpretativ implementiert. Dies hat den Vorteil eines schnellen Turn-arounds, aber andererseits den Nachteil, dass alle Anwender der DSL die MetaEdit+-Laufzeitumgebung benötigen. Die Beschreibung von Codegeneratoren geschieht mit einer Template-Sprache. Die Werkzeugpalette zum Entwickeln grafischer DSLs ist mit Abstand die beste auf dem Markt .

MetaEdit+ enthält ein Repository, sodass das Arbeiten im Team an einem gemeinsamen, im Repository abgelegten Modell möglich ist. Man merkt bei Metacase, dass sie schon lange in diesem Geschäft unterwegs sind. Aus der langjährigen Erfahrung ist ihnen bewusst, dass die Migration von Modellen bei Änderungen der zugrunde liegenden Sprache ein nicht triviales, aber wichtiges Problem darstellt. MetaEdit+ bringt daher entsprechende Werkzeuge mit, um solche Modellmigrationen weitgehend "schmerzfrei" umzusetzen. Die Tatsache, dass die Editoren die Sprachdefinition interpretieren (und nicht wie bei GMF auf aus der Sprache generiertem Code beruhen), erleichtert den Umgang mit alten Modellversionen.

MetaEdit+ liefert übrigens keinen direkten Support für Modell-zu-Modell-Transformationen. Das ist dadurch zu emulieren, dass man mit dem Codegenerator die serialisierte Form des Zielmodells erstellt.

JetBrains MPS

JetBrains, bekannt durch Werkzeuge wie IntelliJ IDEA oder Resharper, hat Ende 2008 die öffentliche Beta-Phase des Werkzeugs MPS eingeläutet. MPS steht für Meta Programming System und dient dem Bauen und der Verwendung von (derzeit vor allem) textuellen DSLs. Im Gegensatz zur klassischen Implementierung von textuellen Sprachen mit Parsern kommt MPS vollständig ohne Parser aus. Als Folge davon lassen sich Sprachen leicht kombinieren. Dazu gleich mehr. MPS verwendet sogenannte strukturelle Editoren, in denen die textuelle Syntax eine Projektion des abstrakten Syntaxbaums darstellt. Der Benutzer editiert direkt den Baum, wobei sich MPS redlich Mühe dabei gibt zu simulieren, dass man Text editieren würde. Bei der Definition einer neuen Sprache ist zunächst das Metamodell zu definieren und dann, in einer Art Formularsprache, die Abbildung der Metamodellbestandteile auf eine textuelle Syntax.

Standardmäßig enthält MPS eine Java-Implementierung, genannt BaseLanguage. Sie erfüllt zwei Aufgaben. Zum einen werden DSLs oft auf BaseLanguage abgebildet, sodass die Programme dann mit dem mitgelieferten Compiler in normalen Java-Bytecode zu überführen sind (natürlich kann man auch XML oder beliebigen anderen Text generieren). Zum anderen lässt sich BaseLanguage erweitern. Beispielsweise kann man mit wenig Aufwand Zustandsmaschinen in Java-Klassen einbauen, neue Statements einführen oder Interfaces mit Vor- und Nachbedingungen erweitern. Die resultierende Sprache präsentiert sich im Editor genauso wie das mitgelieferte Java. Das liegt daran, dass eine Erweiterung der Sprache automatisch immer eine Erweiterung des Editors mit sich führt. Konsequenterweise verwendet MPS auch keine Codegenerierungs-Templates. Die Überführung von DSL- in zum Beispiel Java-Code ist tatsächlich eine Modelltransformation, da ja auch Java als "Modell" abgelegt wird. Das Schöne ist allerdings, dass solche Modelltransformationen die konkrete Syntax der Zielsprache verwenden, weswegen sie aussehen wie Codegenerierungs-Templates.

Mit MPS eröffnen sich für den DSL-Implementierer neue Möglichkeiten, da er nicht nur separate, externe DSLs entwickeln, sondern existierende Sprachen (im Falle von MPS derzeit leider nur Java) transparent erweitern kann. Projekte können beispielsweise mit "normalem" Java beginnen, und wenn sich domänenspezifische Abstraktionen herauskristallisieren, lassen sie sich in Sprache und Tools integrieren. Der Haken ist, dass man zur Verwendung der Sprachen MPS einsetzen muss. Ein normaler Texteditor reicht nicht aus, da eben kein Text editiert wird. Außerdem ist durchaus zu bemerken, dass man direkt auf einer textuell aussehenden Baumstruktur arbeitet. Daran gewöhnt man sich aber im Laufe von ein paar Tagen.

MPS liegt derzeit als Beta vor und ist unter der Apache-2.0-Lizenz verfügbar. Spätestens im zweiten Quartal des Jahres sollte eine Version 1.0 zu haben sein.