5 Best Practices (S. 119-120)

In den bisherigen Kapiteln wurde viel über modellgetriebene Architekturen und modellgetriebene Entwicklung geschrieben. Kapitel 2 hat versucht MDA und MDSD in ihr Vorgehensmodell und ihre Projektorganisation einzuordnen. Kapitel 3 hat viel über Modelle und deren Metamodelle vermittelt, und es wurden verschiedene praxisrelevante Modellierungssprachen vorgestellt. Kapitel 4 hat sich dem Thema domänenspezifische Sprachen (DSL) angenommen.

In Kapitel 5 geht es nun um Best-Practices für die modellgetriebene Softwareentwicklung. Dieses Kapitel widmet sich den Themen Cartridge-Erstellung (eine Teilkomponente eines Code-Generators im Sinne von MDSD) und deren Integration in die Buildumgebung. Wir erläutern außerdem, wie die Cartridge und der generierte Quelltext einfach und sinnvoll dokumentiert werden kann und stellen Best-Practices zum Thema „handgeschriebener vs. generierter Code" vor. Zu diesen Themen gibt es viele Fragen, zu denen wir Lösungsansätze anbieten, die aus unserem Projektalltag stammen.

5.1 Entwicklung von Cartridges

5.1.1 Was sind Generatoren?

Aus den vorherigen Kapiteln wissen Sie, dass Sie einen Generator benötigen, um aus einem Modell Quelltext zu generieren. Aber wie kann ein solcher Generator aussehen und welche Bestandteile hat er? Ein Generator dient dem Zweck, aus einem Modell Artefakte zu generieren. Solche Artefakte können z.B. Programmcode, Konfiguration und Datenbankskripte sein. Um das zu erreichen, hat ein Generator verschiedene Bestandteile, die es ermöglichen, aus dem Modell die gewünschten Elemente zu extrahieren und daraus die gewünschten Artefakte zu generieren.

Funktionsweise eines Generators

Modelle, die mit der UML oder mit dem Eclipse Modeling Framework (EMF) erstellt wurden, bestehen in erster Linie aus XML-Dateien. Frühere Ansätze von Generatoren haben dies genutzt, indem sie das XML-Dokument mit einem DOM-Parser in den Speicher geladen und mit XSL-Stylesheets die Artefakte erzeugt haben. Bei größeren Modellen führte das regelmäßig zu sehr langen Generierungszeiten, wenn nicht sogar zu Abbrüchen, da die Systemressourcen oft nicht ausreichten.

Aus diesem Grund basieren moderne Generatoren auf einem Objektmodell, welches auf dem zugrundeliegenden Metamodell basiert, z.B. UML oder einem EMF-basierten Metamodell. Bekannte Vertreter dieser Objektmodelle sind Netbeans MDR, welches bei AndroMDA zum Einsatz kommt, und das Eclipse Modelling Framework (EMF). Dabei wird das XML-Dokument nicht mit einem DOM-Parser eingelesen und der DOMTree im Speicher gehalten, sondern mit einem schnellen SAX-Parser direkt auf das Objektmodell gemappt. Alle Aktionen – Transformationen, Generierungen – werden dann nur noch auf Basis des instanziierten Modells ausgeführt. Dieses Vorgehen ist deutlich ressourcenschonender und somit schneller. Ein weiterer deutlicher Mehrwert dieses Verfahrens ist die Möglichkeit, das instanziierte Modell der Templateengine zur Verfügung zu stellen.

Templates

Die Qualität eines Generators steht und fällt mit der Ausdrucksfähigkeit der verwendeten Templatesprache. AndroMDA verwendet Velocity und Freemarker. Beide Templatesprachen sind dynamisch typisiert. Das openArchitectureWare Framework verwendet die eigene Templatesprache xPand. xPand ist eine statisch typisierte Sprache. Doch wo ist der Unterschied zwischen einer statisch und einer dynamisch typisierten Sprache?

Bei einer statisch typisierten Sprache wird einer Variablen ein konkreter Typ zugeordnet, der nicht änderbar ist. Mit diesen Informationen kann ein besserer Editorsupport angeboten werden. Ein solcher Editor kann Features wie Online Syntax-Checking und Autocompletion haben. Bei dynamisch typisierten Sprachen ist es deutlich schwieriger, einen solchen Editor zur Verfügung zu stellen, da eine Variable jederzeit einen beliebigen Typ annehmen kann.