Model-to-Code Teil 1

Wie bin ich zu Model-to-Code gekommen?

Ich stand häufig vor Problemen, bei denen eine Reihe von Klassen zwar viel Ähnlichkeit aufwiesen, aber auch gravierende Unterschiede. Wo ich nach der Analyse so genaue Information besaß, dass ein Großteil des „Auscodierens“ fast schon mechanisch hätte geschehen können.

Häufig genug habe ich mit Copy-and-Paste, gefolgt von Search-and-Replace gearbeitet, wenn ich z.B. eine Klasse um ein zusätzliches Attribut erweitern musste. Ähnlich, aber mit noch mehr Umfang, kann man eine Klasse "erstellen" in dem man eine ähnliche Klasse als "Vorlage" verwendet, und umfangreich Search-and-Replace betreibt. Aber diese Verfahren sind zeitaufwändig und fehleranfällig.

In Spezialgebieten habe ich früher schon Code-Generatoren verwendet: Zum Einen SWIG, um einen Adapter zwischen C-/C++-Code und einem Interpreter (Perl, Tcl, Python) erzeugen zu lassen. Zum Anderen den State Machine Compiler SMC, um den Code für Zustandsautomaten erzeugen zu lassen.

Was schätze ich an Model-to-Code?

Die genannten Tools helfen mir in klar abgegrenzten Aufgabengebieten.
Für Probleme, die davon nicht abgedeckt sind, kann ich mittels Model-to-Code flexibel und einfach Lösungen entwerfen (modellieren) und daraus mittels Vorlagen (Templates) maßgeschneiderten Code generieren lassen.
Ein Großteil des Aufwands in der Softwareentwicklung entfällt auf Änderungen. Hier ein paar Beispiele für die Stärken von Model-to-Code: In allen Klassen eine neue Methode anlegen oder die Funktionsweise einer Methode in allen Klassen ändern? Einfach das Template ändern. Eine Klasse oder ein Attribut anlegen? Einfach das Modell ändern.
Mit der gleichzeitigen Änderung mehrerer Klassen und der Änderung von Methoden auf Anweisungsebene ist Model-to-Code wesentlich leistungsfähiger als die Refactoring-Tools einer IDE.

Zu guter Letzt gefällt dem Anforderungsmanager in mir, dass das Modell eine verständliche Dokumentation der Analyse ist. Und weil der Code aus dem Modell erzeugt wird, wird die Analyse laufend aktuell gehalten.

Wollen Sie es mal ausprobieren?

Im Teil 2 dieser Serie: "Eclipse Epsilon einrichten“ beschreibe ich, wie Sie sich mit Eclipse Epsilon eine lauffähige Umgebung einrichten. Gleichzeitig lernen Sie Epsilon in groben Zügen kennen.

Wie können Sie selber starten?

Wählen Sie eine überschaubare Aufgabe, deren Struktur sie gut kennen. Sie sollten in der Lage sein, einen Teil der Lösung von Hand zu programmieren, aber die Aufgabe sollte für "Handarbeit" zu groß sein.
In Teil der Serie „Toleranter XML-Parser“ stelle ich ein solches Problem vor. Und wie ich es mittels Model-to-Code gelöst habe.

Lust auf mehr?

Im vierten und letzten Teil „Die Möglichkeiten von Model-to-Code ausschöpfen“ zeige ich Ihnen zwei weitere spannende Techniken. Erstens wie Sie Modelle mittels Java lesen und schreiben können. Und zwar mittels Java-Klassen, die aus dem Metamodell erzeugt werden.
Und darauf aufbauend: Wie Sie aus einem Modell Testfälle erstellen können, um daraus dann Testdaten und Testcode erzeugen zu lassen.

Hier geht es zu den weiteren Teilen der Artikelserie:

2) Tutorial "Eclipse Epsilon einrichten“

3) XML-Parser: Ein praxisnahes Beispiel für Model-to-Code

4) Die Möglichkeiten von Model-to-Code ausschöpfen