Sicherlich ist "Model Driven Architecture" einer der verheißungsvollsten Trends der letzten Jahre. Keinen schmerzhaften CRUD Code schreiben, die Abstraktionsebene auf das eigentliche Problem heben und gelegentlich den „Erstellen“ Button drücken um einen Prototypen zu erzeugen. Das Frontend benötigt dann, zur Projektabgabe nur noch den letzten Feinschliff. So schön die Theorie.
Ich muss natürlich gestehen, das alle meine versuche zum Thema bisher rudimentär waren. Ich habe und das ist wirklich schon ein wenig länger her, mit Rational XDE und „Enterprise Architect“ Klassen generiert. XDE konnte damals (2003) schon „roundtrip engineering“ und hat das Klassen Model in beide Richtungen aktualisiert, also vom Designer Richtung Code und zurück. Gierig habe ich mir auch Microsofts „Domain Specific Language Tools“ angeschaut (die nicht wie der Name vermuten läst DSLs im klassischen Sinne bearbeiten u. erstellen lässt sondern eher in die MDA Tool Kategorie gehört). Alles natürlich keine reinen MDA Tools aber sie decken eine Schnittmenge ab, von dem was ich von einem derartigen Tool erwarten würde.
Leider waren alle diese Versuche nur einziges Zeitgrab. Eine Klassendiagram ist nur ein Ausschnitt eines Problems und repräsentiert die Implementierung nur eben ungefähr. Alles andere führt zu einer Informationsexplosion, die das eigentliche Ziel von Uml-Diagrammen, Modellierung und Kommunikation, obsolet werden lässt. Meine zweite Erfahrung war, dass das eigentlich Implementieren in händischer Manier, inkrementell, von Problemfeld zu Problemfeld von Klasse für Klasse zu sauberem Code führte. Das Ergebnis lebt davon, dass Zeit in das Modellieren von Ausschnitten investiert wurde, was zu vielen kleinen, auf die Anforderung angepassten Detail-Lösungen führt. In allen Schichten der Anwendung. Drittens: Für mich die schnellste Form eine Anforderung zu verstehen, ist eine Skizze auf Papier und eine schnelle Implementierung, die auch gern ein Mock-up sein kann. Das führt zu vielen kleinen Iterationen, die Stück zu Stück zu einem runden Ganzen führen.
Es gibt die schöne Analogie, die so entstandene, organisch gewachsene Software mit Orten zu vergleichen, die sich um eine Kirche herum scharen, mit vielen kleinen Geschäften. Hingegen MDA generierter Code so ist, wie eine am Reisbrett entworfene Vorstadt, mit eine großen Supermarkt, nebst großem Parkplatz in der Nähe. Ich weiß für meinen Teil wo ich lieber arbeiten und wohnen möchten ;-)
Ein oft gehörtes pro MDA Argument ist, das man teuren Architekten das Designen überlassen kann, während billige Standard Coder für das Grobe zuständig sind. Für mich hat dieser Grundansatz schon eine Reihe von Fehlern. Architekten die nicht Coden verlieren an Fähigkeit. Sie programmieren nicht aktiv. Sie können kein Beispiel geben für guten Code. Und viele B-Klasse Coder, das klingt auch nicht wie ein erfolgreiches Dream-Team?
Zu all dem muß hinzugefügt werden, das ich ein großer Freund von Code-Generierung bin :-) Was aber erstmal nichts mit MDA gemein hat.