In der mitunter hitzig geführten Debatte über Sinn und Unsinn von Codegenerierung sind Argumente der MDSD-Gegner meist schnell zur Hand: Zu schwierig sei der Einstieg in MDSD, schwer wartbar der generierte Code. MDSD beschneide zudem die Kreativität und führe zu einem Kontrollverlust über sein Projekt. Eike Stepper, Leiter des Eclipse-Modeling-Projekts CDO Model Repository und Moderator des Eclipse Modeling Day auf der JAX 2010, nimmt Stellung zu diesen Vorwürfen und erklärt, warum er ausdrücklich keine Domäne sieht, in der Modeling-Technologien nicht von Nutzen wären.

JAXenter: Hallo Eike! Modeling wird von einigen beinahe als „Heilger Gral“ der Softwareentwicklung angesehen, da es ihrer Meinung nach den Entwicklungsprozess entscheidend vereinfacht – andere können gar nichts mit MDSD anfangen. Woran liegt es, dass hier so ein Glaubenskrieg herrscht?

Eike Stepper: Ich denke, das hängt mit den spezifischen Erwartungen zusammen und, falls ein Proof of Concept gewagt wurde, ob diese Erwartungen erfüllt wurden oder nicht. Wenn beispielsweise der Fokus auf der Konservierung von Geschäftswissen auf hohem semantischem Niveau liegt, dann führt wohl kaum ein Weg an Modeling vorbei. Wenn die modellierten Konzepte dann noch für mehrere Plattformen implementiert werden müssen, sehe ich wenig Alternativen zur Code-Generierung.

Man darf nicht verleugnen, dass die Einführung von Modellierung und Generierung einen enormen Einfluss auf alte und lieb gewonnene Entwicklungsprozesse haben kann. Ohne externe Unterstützung oder eigene Erfahrungen darin sind die Erfolgschancen tatsächlich fragwürdig. Und schließlich ist die Wahl der Tools auch nicht zu unterschätzen. In diesem Bereich ist durchaus noch Potenzial bei den Eclipse-Modeling-Technologien vorhanden, und wir haben kürzlich begonnen, diesen Bedarf in formalen Gremien mit der Industrie zu besprechen. Ich bin sicher, dass daraus sehr interessante Produkte erwachsen und die Overall Experience von Eclipse Modeling auf ein neues Niveau gehoben werden kann.

Was übrigens bei der "Heiligen-Gral-Debatte“ oft übersehen wird, ist die Tatsache, dass Modeling nicht nur eine mögliche Disziplin des Entwicklungsprozesses ist, sondern dass Modeling-Technologien zunehmend auch integrale Bestandteile von Laufzeitsystemen werden. Beim CDO Model Repository, dessen Lead ich seit 6 Jahren bin, ist der Einsatz als Runtime Library traditionell sogar der Hauptanwendungsbereich. Meiner Erfahrung nach wird die Diskussion in diesem Bereich nicht ganz so hitzig geführt, da die technologischen Vorteile leichter argumentierbar sind.

JAXenter: Was sind für dich die größten Vorteile Modell-getriebener Verfahren? Und wo macht es keinen Sinn, Modelle einzusetzen?

Eike Stepper: Ich sehe den Hauptvorteil von Modeling darin, dass das Geschäftswissen einer bestimmten Domäne auf einem sehr hohen Niveau und dadurch für eine längere Zeit konserviert werden kann, als dies mit Low-Level-Technologien wie Java oder EJB getan werden könnte. Das Wissen ist somit von mehr Menschen und anderen Technologien konsumierbar.

Je nachdem, wie geschickt man sich bei der Einführung von Modellierung und Generierung anstellt, kann man außerdem mit Kosteneinsparungen rechnen. Es ist interessant bei den erfolgreichen Benutzern zu beobachten, wie zu Beginn die Kosten ansteigen. Dies verwundert nicht, da teilweise intensiv in Wissensaufbau investiert werden muss. Wenn dieses Wissen dann aber sinnvoll eingesetzt wird, bleibt am Ende schlicht und einfach dramatisch weniger Code übrig, der dann ja für eine lange Zukunft gewartet werden muss.

Ferner gibt es bestimmte Anforderungen, die den Einsatz von Modeling-Technologien sogar fast unabdingbar machen. Ein mir bekanntes Beispiel ist die Notwendigkeit, mit enorm großen Datenmengen umzugehen. Wenn man sein Domänenmodell, egal ob es zur Entwicklungszeit oder Laufzeit benutzt wird, mit EMF umsetzt, dann kann man mit wenigen Mausklicks beliebige Skalierbarkeit dazugenerieren oder die Daten-Backends ohne Impact auf den Code austauschen.

Ich kenne kein Gebiet, in dem es ausdrücklich nicht sinnvoll wäre, Modelle einzusetzen. Probleme lassen sich einfach besser mit Modellen als mit Code beschreiben. Und zur Lösung dieser Probleme kann man dann oft wenigstens teilweise Generierung einsetzen. Das ist MDSD.

JAXenter: In unserem Quickvote auf JAXenter sagen über 30 %, dass der MDSD-Ansatz gescheitert ist, da der spätere Aufwand mit generiertem Code zu groß sei. Für weitere 5% ist die Lernkurve für MDSD zu steil. Alles Vorurteile oder ist da etwas Wahres dran?

Eike Stepper: Normalerweise kaufe ich das Lernkurvenargument nicht. Sollte man jemandem trauen, der eine steile Lernkurve, also das Erreichen von viel Wissen in kurzer Zeit, für etwas Schlechtes hält? Nein ernsthaft, ich frage jedes Mal zurück, wenn ich diesen Einwand höre: "Was ganz konkret und genau ist es denn, das euch Steine in den Weg gelegt hat?" Wenn wir dies wüssten, dann könnten wir ja vermutlich etwas dagegen unternehmen. Ob Du es glaubst oder nicht, ich habe kein einziges Mal eine nützliche Antwort darauf bekommen. Ich glaube, man muss sich auch einfach mal von der verlockenden Vorstellung verabschieden, dass die Lösungen für komplexe Probleme in jedem Falle simpel sind. Ich kenne sehr viele Modeling User, welche alle diese Hürden innerhalb einiger weniger Tage genommen haben. Wenn lediglich 5% dies nicht schaffen, bin ich damit sogar ganz zufrieden. Dies dürfte ungefähr gleich dem Anteil an der Gesamtentwicklerschaft sein, der generall keine anspruchsvollen Probleme lösen kann.

In vielen Fällen hat sich der Anspruch, möglichst 100% der Zielanwendung zu generieren, als nachteilig herausgestellt. Obwohl dies manchmal gelingen mag, ist es meistens besser, einen pragmatischeren Ansatz zu wählen und nur die Teile eines Systems zu modellieren, die dafür besonders geeignet sind. Die Datenstrukturen einer Geschäftsdomäne gehören auf jeden Fall dazu.

Was den späteren Aufwand mit dem generierten Code betrifft, würde ich gerne genauer wissen, worin sich dieser Aufwand manifestiert. Meiner ausnahmslosen Erfahrung mit Kunden nach, tritt bei angemessener Anwendung von MDSD genau der gegenteilige Effekt ein. Generierter Code verursacht ja eigentlich gar keine Aufwände. Lediglich die Integration handgeschriebener Geschäftslogik kann einen gewissen Overhead verursachen. Dieser wird jedoch meistens durch die Einsparung auf der Lines-Of-Code-Achse mehr als wettgemacht.

JAXenter: Welche Rolle spielt die Eclipse-Plattform im Bereich Modeling?

Eike Stepper: Abgesehen davon, dass Eclipse Modeling die Referenzimplementierungen für einige der OMG-Spezifikationen beherbergt, gibt es wohl nirgends sonst eine solche Fülle an Zusatztechnologien mit einem so hohen Interoperabilitätsgrad. Wenn man sich erst einmal an EMF als Integrationstechnologie gewöhnt hat, bleibt zukünftig kaum ein Zusatzwunsch unerfüllt. Und die Eclipse Foundation und ihr Open-Source-Prozess garantieren ein Maximum an Transparenz und Offenheit. In Umkehrung der Frage erklärt dies wohl auch, warum Modeling einer der wichtigsten Bereiche innerhalb von Eclipse ist und ständig an Bedeutung gewinnt.

In diesem Zusammenhang ist noch erwähnenswert, dass der Großteil der Eclipse-Modeling-Technologien, welche auch zur Laufzeit in Endprodukten Einsatz finden, auch außerhalb der Eclipse-Plattform und ohne OSGi lauffähig sind.

JAXenter: Du moderierst zusammen mit Sven Efftinge den Eclipse Modeling Day. Kannst du kurz beschreiben, was die Besucher erwartet?

Eike Stepper: Wir haben versucht, den Fokus zu etwa gleichen Teilen einerseits auf einige der Haupttechnologien von Eclipse Modeling (EMF, CDO, Xtext, Data Binding und Query) und andererseits auf Erfahrungsberichte aus spannenden Anwendungsprojekten (z.B. Banking, Homeland Security) aufzuteilen. Abgerundet wird das ganze mit einem kontroversen Talk über die Ups und Downs der Code-Generierung, sowie einer längeren Abschlussdiskussion zum Thema Modeling vs. Solving Problems. Mit diesen insgesamt neun Slots sollte für jeden etwas Spannendes dabei sein.

JAXenter: Wie geht es deiner Einschätzung nach weiter mit der Software-Modellierung? Welche Projekte werden in Angriff genommen? Welche Probleme gilt es zu bewältigen?

Eike Stepper: Natürlich hat jeder der existierenden Building Blocks bei Eclipse Modeling seine eigenen kleineren oder größeren Potenziale. Aber ich denke, eine der größten Herausforderungen des Modeling-Projekts als Ganzem ist die erhebliche Verbesserung einer konsistenten Tool-Erfahrung. Wie ich eingangs erwähnte, ist es diesbezüglich bereits gelungen, ein Forum für die Anforderungen der Industrie und die Technologieanbieter bei Eclipse aufzusetzen. Ich bin sehr gespannt, ob wir es nun endlich bald schaffen, eine übergreifende Werkzeugplattform für Modeling bereitzustellen, die in Punkto Funktionsumfang, Komfort, Skalier- und Erweiterbarkeit den Vergleich mit dem Flaggschiff JDT nicht mehr zu scheuen braucht.

JAXenter: Vielen Dank für dieses Gespräch!

Links & Literatur

1. Blog von Eike Stepper