In der Diskussion: Lightweight Domain Specific Modeling

"Improving Developer Productivity with Lightweight Domain Specific Modeling" lautet der Titel eines aktuellen Artikels von Patrik Nordwall, einem erfahrenen Java-Architekten bei der schwedischen Unternehmensberatung Avega AB. Veröffentlicht wurde der Artikel auf den Seiten von TheServerSide.com, der größten Java-Community im Web. Nordwall vergleicht verschiedene Software-Entwicklungstechniken miteinander, die zum Teil in Konkurrenz zueinander stehen. Tatsächlich kombiniert Nordwall diese Techniken, von denen der Einsatz von Codegeneratoren eine ist, zu einer echten Methodik namens "Lightweight Domain Specific Modeling". Die Verwendung domänenspezifischer Modelle, insbesondere für die Codegenerierung, ist dabei ein wichtiger Punkt. Wir halten Nordwalls Artikel für sehr lesenswert, und haben ihn hier für Sie kritisch kommentiert.

In seinem Artikel beschreibt Nordwall zunächst, dass Programmierer häufig einfache, sich wiederholende Dinge tun würden, beispielsweise durch exzessives Copy-Paste-Adapt, also durch das ständige manuelle Kopieren und Anpassen von Codefragmenten. Wenn man dies aber automatisiere, werde die Sache schnell aufwändig und schwierig. Als Lösung schlägt Nordwall die Verwendung domänenspezifischer Sprachen (Domain Specific Language, DSL) und darauf aufbauender Codegeneratoren vor.

So sinnvoll Nordwalls Ansatz ist, ist seine Begründung hier etwas unscharf: Gerade triviale Codierungs-Tätigkeiten kann man auch einfach durch (primitive) Generator-Techniken umsetzen, beispielsweise durch Makros oder Filter. Das eigentliche Problem liegt in nicht-trivialen Tätigkeiten, die sich nur aufwändig automatisieren lassen. Ein Generator für eine solche Aufgabe realisiert eine höhere, domänenorientierte Abstraktionsebene. Seine domänenspezifische Ausrichtung schränkt jedoch zugleich sein Einsatzgebiet ein und macht seine Erstellung aufwändig.

In Bezug auf solche domänenspezifischen Generatoren favorisiert Nordwall deren projektspezifische Entwicklung an Stelle des Zukaufs vorhandener Generatoren. Dann habe man die Generatoren voll und ganz unter eigener Kontrolle, was bei sich ändernden Anforderungen wichtig sei. Diese Feststellung Nordwalls deckt sich durchaus mit den Erfahrungen von Delta Software Technology mit dem kommerziellen Einsatz von Generatoren: Sie müssen oft projektspezifisch entwickelt werden und dabei hochgradig an wechselnde Kundenanforderungen anpassbar sein. Nicht zuletzt muss der Kunde in der Lage sein, die Wartung solcher projektspezifischer Generatoren allein zu übernehmen. Nordwall präsentiert diesen Sachverhalt in einer gewissen Pauschalität, so dass es fast nahe liegt, diesen nicht nur auf Codegeneratoren zu beziehen. Wie auch immer, die Make-or-Buy-Entscheidung in Bezug auf Generierungswerkzeuge anhand objektiver Kriterien zu analysieren, ist sicher ein interessantes Feld für weitere Untersuchungen.

Zurück zum Artikel. Nordwall bezieht sich auf eine Variante von "Domain Specific Modeling" (DSM), die speziell für kleinere Projekte geeignet sei und die deshalb den Zusatz "Lightweight" trägt. Damit sich der Ansatz lohne, müsse der Aufwand für die Erstellung eines Generators sich innerhalb des Projekts rechnen. Einen Systemfamilienansatz vertritt Nordwall hier nicht. Dieser kann jedoch für die Aufwandsrechnung "Lohnt sich ein Generator oder nicht?" entscheidend sein (vgl. den Bericht "Prozesse als Input: Generierung von Web-Portalen").

Konkret schlägt Nordwall den Einsatz einer Reihe frei verfügbarer Eclipse-basierter Tools und Techniken vor: Die jeweilige DSL könne mit ArgoUML definiert werden und anschließend in ein Ecore-Modell konvertiert werden. Basierend darauf würden JET-Templates zur Generatordefinition herangezogen, wobei das Eclipse-Plug-In Merlin die Verknüpfungen zum Ecore-Modell realisieren würde.

In dem vertretenen minimalistischen Ansatz verzichtet Nordwall insbesondere auf die Definition eines Metamodells für das domänenspezifische Modell, was laut Nordwall ein wesentlicher Unterschied zum Konzept der OMG MDA (Model Driven Architecture) sei. Unserer Ansicht nach werden damit eine domänenübergreifende Toolunterstützung, die Nutzung des Softwarefamilienkonzepts und Modelltransformationen zumindest erschwert, wenn nicht unmöglich.

Mit einem Missverständnis räumt Nordwall allerdings auf: Modelle seien keine 1:1-Repräsentationen von Implementierungen, sondern Abstraktionen, die bestimmte Dinge vereinfachten. Es geht nicht darum, möglichst codenah UML-Modelle zu definieren, sondern in den Modellen die wesentlichen Dinge für die Codegenerierung zu konzentrieren. Laut Nordwall sei dies kein Problem, da man bei einem projektspezifischen Generator technische Details sowie vom domänenspezifischen Modell nicht abgedeckte Elemente im projektspezifisch entwickelten Generator, z.B. dessen Templates, selbst im Zugriff habe.

Delta bietet mit HyperSenses eine Basistechnologie für die Entwicklung modellbasierter Generatoren, deren Schwerpunkt gerade auf projektspezifischen Generatoren liegt. Vergleicht man Nordwalls Ansatz mit HyperSenses, so liegt ein wesentlicher Unterschied in der Definition der Modelle: Ein HyperSenses-Modell besitzt immer ein Metamodell, welches die Variationspunkte für einen Generator genau festlegt. Dieses ist immer domänenspezifisch. Ein domänenspezifisches Modell nach Nordwall entspricht einem HyperSenses-Modell, das Metamodell existiert jedoch nicht in expliziter Form. Bei HyperSenses hingegen gewährleistet ein Meta-Metamodell eine domänenübergreifende, einheitliche Systematik für alle HyperSenses-Modelle, -Tools und -Komponenten.

Abschließend ist festzustellen, dass für den lohnenden Einsatz von Codegeneratoren die Aufwandsrechnung entscheidend ist. Dass sowohl in dem hier diskutierten Artikel wie auch anderswo immer wieder mit vagen Begriffen und pauschalen Annahmen argumentiert wird, ist bemerkenswert. Es ist sehr wünschenswert, dass die Forschung hierzu eines Tages klare, objektive Kriterien, wie z.B. Metriken, entwickelt.

Machen Sie sich selbst ein Bild und lesen Sie Nordwalls Artikel unter:
http://www.theserverside.com/tt/articles/article.tss?l=LightweightModeling