Bereits seit Jahrzehnten müht sich die Software-Industrie damit ab, Lösungen zu finden, die den Software-Entwicklungsprozess weitgehend automatisieren sollen. Alle bisherigen Versuche sind mehr oder weniger gescheitert. Um die Vision einer selbsttätigen Generierung des Programm-Codes doch noch Realität werden zu lassen, hat die OMG (Object Management Group) unter dem Überbegriff Model Driven Architecture (MDA) eine neue Initiative gestartet, die nun allmählich Früchte zu tragen beginnt.
Die OMG ist ein offenes Konsortium, das bereits seit 1989 besteht. Mittlerweile umfasst es mehr als 800 Mitglieder, darunter namhafte Firmen wie IBM/Rational, Borland, Novell, Sun oder Oracle. Das Konsortium hat zum Ziel, herstellerneutrale Standards zu schaffen, die die Interoperabilität und Portabilität von Softwareprodukten verbessern und den Entwicklungsprozess beschleunigen sollen. Zu den bisherigen Ergebnissen der OMG gehören bekannte Standards wie Corba, UML oder XMI. MDA ist nun das jüngste Aushängeschild der OMG, das zu einem grossen Teil auf den aktuellen Spezifikationen des Gremiums aufbaut. MDA verspricht plattformunabhängiges und beschleunigtes Entwickeln von Software, und dies bei geringeren Kosten und gesteigerter Qualität.
Bestrebungen, die Programmerstellung auf Basis von Modellen zu automatisieren, gab es bereits in den 80er und in den frühen 90er Jahren. Unter dem Überbegriff CASE wurden Werkzeuge angepriesen, die zwar viel versprachen, leider aber oft enttäuschten. Der Grund für diese Misserfolge ist zu einem grossen Teil auf die rigide Architektur dieser Tools zurückzuführen, die die Anpassung der Codegenerierung an ein konkretes Projekt praktisch verunmöglichten. Statt die Welt des Software Engineering zu revolutionieren, verstaubten die für teures Geld eingekauften CASE-Pakete meist im Regal.
Der stetig zunehmende Zeit- und Budgetdruck hat den Fokus vor einigen Jahren wieder auf Werkzeuge gelenkt, die den Entwicklungsprozess mit Hilfe von Modellen und Codegeneratoren unterstützen. Mit neuen Konzepten soll MDA nun die Effektivität dieser Tools weiter verbessern und die Prozesse innerhalb des Software-Lifecycle optimieren.
Das Schlüsselkonzept bei MDA ist die strikte Trennung zwischen plattformunabhängigen und -spezifischen Modellen. Der Grundgedanke dabei ist, dass von der Plattform losgelöste Modelle gegenüber Änderungen am technischen Konzept viel resistenter sind und gleichzeitig eine Basis für portable Anwendungen bilden.
Dementsprechend bildet das sogenannte Platform Independent Model (PIM), das in den ersten Phasen des Designprozesses zum Tragen kommt, den Ausgangspunkt bei der Model Driven Architecture. Ein PIM wird völlig unabhängig von der technischen Implementierung und der umgebenden IT-Infrastruktur modelliert. Dabei lässt sich ein plattformneutrales Modell in zusätzlichen Verfeinerungsschritten weiter konkretisieren. Steht das PIM, lässt es sich in ein Platform Specific Model (PSM) umwandeln (Model to Model Transformation), in dem dann die technischen Details der Zielplattform berücksichtigt werden. Bei der anvisierten Plattform könnte es sich beispielsweise um Corba, J2EE, XML/SOAP oder .NET handeln. Auch auf der plattformspezifischen Ebene kann das Modell in zusätzlichen Schritten weiter verfeinert werden. In der letzten Phase wird dann aus dem PSM der benötigte Code generiert (Model-to-Code-Transformation). Da ein PSM bereits sehr stark auf die technische Zielplattform abgestimmt werden kann, ist dieser letzte Umwandlungsschritt weit trivialer als die Überführung eines PIM in ein PSM.
Die eigentlichen Transformationsprozesse werden innerhalb von MDA mit Hilfe von Mappings, UML-Profilen und entsprechenden Werkzeugen vorgenommen. Dabei sehen die Strategiepapiere der OMG vor, dass diese zumindest teilweise oder gar vollständig automatisiert werden können.
Die Vorteile des MDA-Konzepts liegen auf der Hand: Bei einem Technologiewechsel muss lediglich das passende Transformationsmodul verwendet werden, um aus dem ursprünglichen PIM ein neues PSM zu generieren. Dadurch werden Kosten und Zeitaufwand deutlich reduziert, wenn beispielsweise ein Applikationsserver oder ein Teil der Middleware ausgetauscht werden sollen. Die OMG schätzt, dass die Kosten bei einem Technologiewechsel um einen Prozentsatz reduziert werden, der deutlich im zweistelligen Bereich liegt. Ein weiterer Vorteil von MDA ist die schnellere Integration neuer Technologien in die bestehende Infrastruktur. Auch die Qualität der Software kann mit MDA erhöht werden. Fehler in generierten Codeteilen lassen sich an zentraler Stelle korrigieren. Und schliesslich trägt MDA auch zur Steigerung der Re-Usability bei, da mit Codegeneratoren auf Best-Practice-Prinzipien zurückgegriffen werden kann, die immer wieder denselben bewährten Code erzeugen können.
Wie eingangs erwähnt, fasst MDA verschiedene OMG-Standards in einem gemeinsamen Framework zusammen (siehe Diagramm "Eckpfeiler von MDA"). Kern dieser Architektur bilden UML, XMI, MOF und CMW, denen die folgenden Rollen zukommen:
• Unified Modeling Language (UML): Die Modellierungssprache dient der visuellen und semantischen Beschreibung von Architekturen, Prozessen und Komponenten sowie deren Interaktionen. Dabei ist UML so universell, dass es von der Spezifikationphase bis zum Deployment in allen Stadien des Lifecycle eingesetzt werden kann. UML ist vor kurzem in der komplett überarbeiteten Version 2.0 verabschiedet worden, die wichtige Neuerungen für die Umsetzung der MDA-Vision mit sich bringt. Im Zusammenhang mit UML sind auch die sogenannten UML-Profile erwähnenswert, über die sich die Modellierungssprache auf bestimmte Spezialgebiete massschneidern lässt. So können etwa Profile für bestimmte Plattformen (Corba, J2EE, .Net) oder Anwendungsbereiche (Realtime-Anwendungen, Business-Prozess-Modeling) definiert werden. Unter dem Dach der MDA spielen UML-Profile vor allem beim Mapping zwischen verschiedenen Modellen eine wichtige Rolle.
• XML Metadata Interchange (XMI): XMI ist für den Austausch von Modellierungsdaten über Toolgrenzen hinweg gedacht. Die Modelle werden dazu mit Hilfe des universellen Datenformats XML beschrieben.
• Meta Object Facility (MOF): MOF definiert ein gemeinsames Meta-Modell für alle Modeling-Spezifikationen von MDA. So werden auch UML und CWM auf Basis von MOF-Konstrukten definiert. Von MOF abgeleitete Spezifikationen arbeiten auf natürliche Weise zusammen. MOF definiert zudem eine API-Schnittstelle, die den Zugriff und die Manipulation von Modellen aus anderen Programmen erlaubt.
• Common Warehouse Meta-Model (CWM): CWM ist ein umfassendes Meta-Modell für Data-Warehouse-Anwendungen. CWM beschreibt unter anderem, wie Metadaten zwischen Datenbanken, Knowledge-Management-Anwendungen, Datamining- und Business-Intelligence-Lösungen ausgetauscht werden können. CWM ist insbesondere für das Mapping zu Datenbank-Schemata verantwortlich.
In einer weiteren Schicht definiert die MDA die sogenannten Pervasive Services. Dabei handelt es sich um allgemeine Funktionen, die in den meisten Applikationen immer wieder zum Einsatz kommen. Dazu gehören etwa Dienste wie Directory Services, Event-Logging, Persistenz- und Transaktions-Management oder Security. Plattformen wie J2EE oder .Net bieten für die meisten dieser Dienste bereits fixfertige Lösungen an, die sich über Schnittstellen aus der eigenen Anwendung nutzen lassen. Über die Pervasive Services der MDA wird es nun möglich, solche allgemeine Dienste bereits auf plattformneutraler Stufe (PI) einzuplanen. Erst bei der Umwandlung in das PSM werden die plattformspezifischen Charakteristika im Design berücksichtigt. Die Pervasive Services versprechen beschleunigtes Applikationsdesign und den Einbezug von Services auf der plattformunabhängigen Abstraktionsebene. Die OMG arbeitet derzeit an den Definitionen für vier Services: Transaktionen, Security, Directory Services sowie Event/Notification Services. Weitere Dienste werden bei Bedarf hinzugefügt.
Neben der Spezifikation dieser generellen Services ist man beim OMG auch mit der Ausarbeitung von vertikalen Standards für bestimmte Branchen beschäftigt. Für Bereiche wie E-Commerce, Finanz- und Versicherungswesen, Telekommunikation oder Medizinaltechnik sollen die typischen abstrakten Prozesse und Modellbausteine vordefiniert und für die Integration in ein PIM als sogenannte Domain-spezifische Core Models bereitgestellt werden. Dadurch lässt sich bereits vorhandenes Wissen innerhalb einer bestimmten Branche wiederverwenden.
Damit sich ein Modell überhaupt in ein anderes überführen lässt, müssen Regeln und Techniken bestimmt werden, über die der Transformationsprozess gesteuert werden kann. Innerhalb der MDA kommt diese Aufgabe den Mappings zu. Es wird zwischen vier Arten von Mappings unterschieden:
• PIM zu PIM: Diese Art der Transformation wird dann genutzt, wenn Modelle in den Anfangsphasen des Applikations-Lifecycle erweitert, gefiltert oder konkretisiert werden müssen. Eine typische Situation, in der ein PIM-zu-PIM-Mapping angewendet wird, ist der Übergang von der Analyse- in die Design-Phase.
• PIM zu PSM: Wie bereits erwähnt, kommt die Umwandlung von einem PIM in ein PSM dann zum Einsatz, wenn ein Modell soweit fortgeschritten ist, dass es in ein plattformspezifisches Design umgewandelt werden kann.
• PSM zu PSM: Projektionen innerhalb der plattformspezifischen Ebene werden vor allem dann genutzt, wenn es um die konkrete Realisierung von Komponenten und das Deployment geht.
• PSM zu PIM: Mit dieser Art des Mapping lässt sich eine konkrete Implementation in ein plattformunabhängiges, abstraktes Modell zurückführen. Dieses Verfahren ist kaum automatisierbar. Hier ist vor allem Handarbeit in Form eines Refactoring angesagt, das bestenfalls von einzelnen Tools unterstützt werden kann. Echtes toolgestütztes Roundtrip-Engineering zwischen PSM und PIM ist mit MDA praktisch unmöglich.
Für die Implementierung der Mappings müssen die Metamodelle des Input- und Output-Modells bekannt sein. Diese Metamodelle werden mit Hilfe von UML-Profilen beschrieben. Die OMG plant, eine Reihe solcher Profile für bestimmte Anwendungsbereiche und Plattformen zu standardisieren; Profile für Realtime-Anwendungen, Corba, EAI und EDOC existieren bereits. Weitere UML-Profile etwa für bestimmte J2EE-Plattformen oder .Net sind in nächster Zeit von Drittanbietern zu erwarten.
Experten rechnen damit, dass der Übergang von UML nach MDA fliessend vonstatten gehen wird: Ähnlich wie die Hersteller die OO-Tools der 90er Jahren schrittweise in UML-Werkzeuge überführt haben, werden jetzt immer mehr UML-Programme mit MDA-Funktionen ausgestattet. Bietet ein Hersteller bereits heute ein Produkt als MDA-Werkzeug an, ist Vorsicht geboten. Denn nicht überall, wo MDA draufsteht, ist auch MDA drin - zumindest nicht in dem Rahmen, den man sich bei der OMG vorstellt. Noch liegen nicht alle MDA-Spezifikationen als endgültige Standards vor oder sind, wie im Fall von UML 2.0, gerade erst fertig geworden. So kann ein Werkzeug zum heutigen Zeitpunkt allenfalls als Modeling-Tool mit MDA-Ansätzen bezeichnet werden. Experten rechnen damit, dass mit einem breiten Marktangebot an vollständig ausgereiften MDA-Werkzeugen frühestens 2004 oder 2005 zu rechnen ist.
Grundsätzlich kann man den Werkzeugmarkt derzeit in zwei Kategorien aufteilen:
• UML-Werkzeuge: Werkzeuge mit Fokus auf UML-Modeling. Sie bieten teilweise auch Generatoren zum Erzeugen von Coderümpfen und sind in einigen Fällen mit Reverse-Engineering-Funktionen ausgestattet. Zur Kategorie an UML-Tools gehören etwa Rational Rose, Visual UML oder MagicDraw UML.
• Tools mit MDA-Ansätzen: Hier lassen sich Pakete einordnen, die bereits mit einigen typischen Fähigkeiten der MDA-Vision wie etwa Model-to-Model-Transformation ausgestattet sind. Das Angebot solcher Tools ist derzeit noch sehr mager. Zu den wenigen MDA-Tools zählen etwa ArcStyler von Interactive Objects, OptimalJ von Compuware oder Rational XDE Modeler.
Der wichtigste Grundpfeiler der MDA bildet die Unified Modeling Language (UML), mit der sich Architektur, Objekte und Prozesse grafisch abbilden lassen. Zur Zeit der Drucklegung befand sich der Ratifizierungsprozess der letzten der vier UML-2.0-Spezifikationen ("Superstructure") in seiner entscheidenden Phase. Bis zum Erscheinen dieses Artikels dürfte UML 2.0 aber definitiv zum verbindlichen Standard ernannt worden sein. Bereits im März wurden die neuen UML-Spezifikationen "Infrastructure", "Object Constraint Language" und "Diagramm Interchange Protocol" als offizielle Standards freigegeben.
UML 2.0 soll vor allem einige Ungereimtheiten und Problembereiche der aktuellen 1.x-Versionen aus der Welt schaffen. Mit UML 1.x können Modelle oft nicht präzise genug formuliert werden, damit sich daraus qualitativ guter Programm-Code generieren lässt. UML 2.0 erlaubt nun explizitere Definitionen, bietet striktere Semantik und bessere Erweiterungsmöglichkeiten. Alles Neuerungen, die insbesondere für den erfolgreichen Einsatz von MDA von essentieller Bedeutung sind. Nachfolgend die wichtigsten Neuerungen im Überblick:
• Komponenten-Support: Erweiterte Unterstützung für Komponenten-basierte Entwicklung. Dies vereinfacht die Modellierung von Applikationen, die auf Basis von Enterprise JavaBeans, Corba oder COM+ realisiert werden.
• Behavioral Modeling: Die Möglichkeiten für Verhaltensmodelle (Activity-Diagramme, State-Charts) wurden punkto Skalierbarkeit verbessert. Restriktionen für das Mapping zwischen Activity Charts und State Machines wurden aufgehoben. Neu gibt es auch Szenario Modeling auf Basis von Sequenz-Diagrammen.
• Erweiterbarkeit: Eine bessere Architektur zum Anbringen von Erweiterungen wie etwa eigenen Meta-Klassen vereinfacht die Definition von neuen UML-Profilen. Damit lässt sich UML 2.0 viel besser für spezifische Anwendungsbereiche erweitern (z.B. für das Modeling von Web-Anwendungen).
• Runtime-Architektur: Unterstützung für Runtime-Architekturen erlaubt besseres Modellieren von Objekten und Datenflüssen zwischen verschiedenen Teilen eines Systems.
• Mehr Präzision: Genauere Beschreibung von Beziehungen verbessert das Modellieren von Vererbung, Kompositionen und Aggregation.
• Striktere Semantik: Eine komplette Überarbeitung der Sprache vereinfacht Syntax und Semantik und sorgt für bessere Organisation der Gesamtstruktur.
• Datenaustausch: Bessere Unterstützung für den Austausch von Diagrammen zwischen unterschiedlichen Werkzeugen durch ein neues Datenformat, das auf XMI basiert.
• Executable Models: Support von prozeduraler Semantik erlaubt das Erstellen von ausführbaren Modellen. So kann das Modell bereits in der Designphase bis zu einem gewissen Grad getestet werden.
Eines der Programme, bei dem die MDA-Fähigkeiten am weitesten fortgeschritten sind, ist die Version 4.0 von ArcStyler, die erst Mitte September vorgestellt wurde. Das Programm, das von der Freiburger (D) Softwareschmiede Interactive Objects stammt, verfügt über ein Cartridge-System, mit dem sich der Funktionsumfang individuell anpassen und erweitern lässt. ArcStyler wird mit Cartridges für automatische Modell-zu-Modell-Transformationen und für das Generieren von Code für diverse J2EE-Plattformen und .Net geliefert. Über die offene Plug-in-Architektur kann das Programm jederzeit mit neuen MDA-Features und Support für weitere Plattformen nachgerüstet werden.
Ein weiteres Werkzeug, das bereits mit MDA-Eigenschaften aufwarten kann, ist OptimalJ von Compuware. Wie ArcStyler unterstützt auch dieses Werkzeug Model-to-Model- und Model-to-Code-Transformationen. Zusätzlich zu seinen Modeling-Fähigkeiten bietet OptimalJ Pattern-orientiertes Design mit Hilfe von Templates und eine komplette Entwicklungsumgebung mit Source-Code-Editor, Klassenbrowser und Debugger. OptimalJ unterstützt derzeit nur J2EE-Plattformen.
Ebenfalls erwähnenswert ist Tau Generation 2 von TeleLogic. Es gehört zu den ersten Produkten überhaupt, die bereits mit der Unterstützung von UML 2.0 und ausführbaren UML-Modellen (Executable UML) aufwarten können. Damit lassen sich Modelle bereits in einem sehr frühen Stadium simulieren und verifizieren. Allerdings muss man Tau G2 in die Kategorie der UML-Werkzeuge einordnen, denn ein echtes Modell-Transforming à la MDA fehlt gänzlich.
UML- und MDA-Tools im Überblick
Auch die Grossen der Branche sind mit Volldampf in Richtung MDA unterwegs. So hat sich IBM mit dem Kauf von Rational eine Pole-Position für das Rennen um den MDA-Markt gesichert. Insbesondere mit Werkzeugen wie Rational XDE, das Entwicklungsumgebungen wie Visual Studio.Net, Eclipse oder WebSphere Studio um Modeling-Funktionen erweitert, und dem neuen Rapid Developer für die modellgestützte J2EE-Entwicklung werden bereits erste Lösungen geboten, die in Richtung MDA weisen.
Borland gehört seit dem Kauf von TogetherSoft und dem kürzlichen Beitritt zur OMG ebenfalls zu den Leadern in der Modeling-Zunft. Mit dem Together Control Center haben sich die Kalifornier eines der wichtigsten Modeling-Werkzeuge auf dem Markt einverleibt. Borland hat bereits damit begonnen, Together-Technologie in seine Entwicklungsumgebungen (JBuilder, C# Builder) zu integrieren und für Entwicklungsumgebungen von anderen Herstellern wie etwa Eclipse, SAP NetWeaver Studio, Visual Studio.Net oder BEA Weblogic Workshop anzupassen. Die Pascal-IDE Delphi 7 wird standardmässig mit den Modellierungs-Werkzeugen Bold und ModelMaker ausgeliefert. Borland hat bereits angekündigt, Together in naher Zukunft in einer um MDA-Funktionen erweiterten Version auf den Markt zu bringen.
Auch Microsoft plant, auf den Modeling-Zug aufzuspringen. Da die aktuelle UML-Lösung auf Visio-Basis nur mässig bei der Kundschaft ankommt, wollen die Redmonder das nächste Visual Studio.Net ("Whidbey") mit ersten Modeling-Funktionen ausrüsten. Eine umfassende Modeling-Lösung verspricht der Softwaregigant allerdings erst für "Orcas", der übernächsten Version von VS.Net. Ob und wie weit sich Microsofts Lösung an den Ideen und Standards der OMG orientiert, bleibt vorerst noch offen.
MDA-Hersteller versprechen für ihre künftigen Produkte, dass je nach Art des Projektes 40 bis 80 Prozent des kompletten Codes basierend auf UML-Modellen generiert werden können. Der Erfolg von MDA ist aber nicht nur von starken Werkzeugen und offenen Standards abhängig, sondern auch von der Akzeptanz der Software-Entwickler und -Architekten. Denn sie sind während der vergangenen Jahre skeptisch geworden. Zu oft wurde ihnen eine Wunderwaffe versprochen, die sich im Endeffekt als Nullnummer herausstellte. Auch gibt es noch einen sehr grossen Anteil an Software-Entwicklern, die Codegeneratoren grundsätzlich ablehnen und davon überzeugt sind, dass sie manuell besseren Code schreiben können als jedes Werkzeug.
Verfechter von MDA halten dem entgegen, dass die Tools im Laufe der nächsten Jahre grosse Fortschritte machen und dann die meisten Skeptiker überzeugen werden. Steigender Kostendruck und Zeitmangel würden es nicht mehr zulassen, Software wie bis anhin zu 100 Prozent manuell ohne vorgängige Modellierung zu entwickeln.
So gut wie sicher ist, dass sich das Skillset, das künftige Softwareingenieure mitbringen müssen, stark verändern wird. Die Programmierung wird sozusagen vom Code ins Modell verlagert. Die hartgesottene Fraktion der MDA-Anhänger prophezeit sogar, dass das Schreiben von Code schon bald überflüssig wird. Ob es je soweit kommt, ist aber sehr umstritten. Die Frage, wie weit MDA den Codierungsprozess automatisieren wird, kann nur die Zukunft beantworten.
Warum sollte MDA nicht scheitern wie einst CASE? Eine Erfolgsgarantie beim Einsatz von MDA-Tools gibt es natürlich nicht. Allerdings macht MDA einiges besser als die CASE-Werkzeuge. So beruht MDA auf offenen und erweiterbaren Spezifikationen. Eines der grossen Probleme der CASE-Werkzeuge war, dass Metamodelle und die Mappings für die Transformation nicht angepasst werden konnten. Die Modellierungssprache war meist proprietär und konnte gar nicht oder nur begrenzt erweitert werden. Damit fehlte einerseits die notwendige Interoperabilität zwischen verschiedenen Werkzeugen und andererseits die Flexibilität, um Modelle und Codegeneratoren auf projektspezifische Bedürfnisse zurechtstutzen zu können. Mit UML 2.0, den UML-Profilen und MOF merzt MDA diese Nachteile aus.
Richard Hubert ist CEO der Freiburger (D) Interactive Objects, die mit ArcStyler 4 eines der führenden MDA-Werkzeuge auf dem Markt herstellt. Hubert sitzt auch im MDA-Komitee der OMG und hat zum Thema ein Buch mit dem Titel "Convergent Architecture" (www.ConvergentArchitecture.com) verfasst. Wir haben mit ihm über die aktuellen Möglichkeiten und die Zukunft von MDA gesprochen.
InfoWeek: Der Standardisierungsprozess der OMG ist noch nicht abgeschlossen. Wie ist es möglich, dass Sie bereits heute ein MDA-Produkt anbieten können?
Richard Hubert: MDA ist eine Vision, die schrittweise umgesetzt und standardisiert wird. Aktuelle Produkte wie unser ArcStyler nutzen heute verfügbare Standards und bieten ergänzende Features, die zur MDA-Vision hinführen. Also eine ganz normale Evolution in das nächste Software-Engineering-Paradigma. Wir sind mit ArcStyler schon seit Jahren auf dem Markt und haben dabei viele Erfahrungen gesammelt. Deshalb haben andere sogenannte MDA-Produkte grosse Probleme, wenn sie mit unserem Werkzeug verglichen werden.
Wo liegen die Hauptvorteile beim Einsatz von MDA?
Lassen Sie mich einen Vergleich zu den früheren Compiler-Technologien ziehen: Heute programmiert kaum mehr ein Entwickler in Assembler-Code, weil sich dieser direkt aus einer Hochsprache (Cobol, C++, Java, C# etc.) automatisch und voll optimiert erzeugen lässt. Bis in 5 Jahren wird mit diesen Sprachen ähnliches passieren. Dann wird mit Modellen in UML "programmiert", weil diese noch einfacher erlernbar und effektiver sind. Es stellt sich nicht die Frage, "ob", sondern lediglich "wann" ein Software-Engineer mit MDA loslegt.
Wie gross ist die Kostenersparnis, die beim konsequenten Einsatz von MDA erreicht werden kann?
Bereits in einem ersten Projekt haben mehrere unserer Kunden eine Kostenersparnis von 35 bis 40 Prozent erzielt. Später, wenn man das Werkzeug und das Retooling im Griff hat, erreicht man bis zu 70 Prozent.
Und wie hoch ist dabei der Prozentsatz des generierten Codes?
Das ist projektabhängig. In einem ersten Projekt kann man bereits 50 Prozent erreichen. Da bei unserem Werkzeug die MDA-Automation flexibel erweiterbar ist, kann in den nachfolgenden Projekten nahezu 100 Prozent des Codes erzeugt werden. Und der Teil, den man herkömmlich schreiben muss, ist wohl annotiert und wird vom Modell auch verwaltet. Dies ist kein Bruch im Paradigma, sondern nur ein Zeichen dafür, dass unsere Modellierungssprachen noch nicht in allen Fällen besser sind als ein paar handcodierte Zeilen. Wir wollen ja nur 100 Prozent Generierung erreichen, wenn es effektiver ist als 90 Prozent generierter und 10 Prozent von Hand geschriebener Code.
Aber wie werden denn hier Code und Modell synchron gehalten? Ist das nicht ein Ding der Unmöglichkeit?
Bei dieser Frage ist der Markt gespalten: Zum einen gibt es das Lager der Illusionisten, die das sogenannte Round Trip Engineering (RTE) propagieren, was von vielen Tool-Herstellern als MDA-Feature verkauft wird. Wenn es aber darum geht, die Vorteile von MDA auszureizen, dann erweist sich gerade RTE als Hypothek. Eine Eins-zu-eins-Synchronisation, wie sie von dieser Technologie versprochen wird, bringt sogar viele Probleme mit sich, die gerade mit MDA gelöst werden können.
Zum anderen gibt es das Lager der Realisten, die nicht in einer Traumwelt leben, sondern sich an der Praxis orientieren. Hier geht es um ausdrucksstarke Modelle, auf beliebig hohen Ebenen, die vorwärts gerichtet immer wieder andere Modelle oder Infrastrukturen generieren. Diese Tools halten Änderungen in der Infrastruktur synchron, indem man solche explizit als "handcodiert" markiert. Diese sogenannten Protected Regions werden bidirektional mit dem Modell und dem Generator verwaltet. Dadurch erreichen wir die wirklichen Vorteile von MDA, ohne immer wieder den Frust einer Illusion erleben zu müssen.
Was ist bei der Einführung von MDA zu beachten? Wo können allenfalls Erwartungen nicht erfüllt werden?
Man muss bereit sein, den ersten Schritt zu machen. Viele der Programmierer und Code-Wizards in einer Firma werden nicht glauben wollen, dass ein Werkzeug in der Lage ist, ausgezeichneten Code zu erstellen. Meiner Meinung nach verspielen sie hier aber eine echte Chance und laufen Gefahr, ihre Leader-Position zu verlieren. Dabei bräuchten sie bloss eine Woche Zeit in einen Kurs zu investieren, um diesen Schritt zu machen.
Die Erwartungen an MDA werden nur dann nicht erfüllt, wenn jemand versucht, das erste Projekt ohne genügend Erfahrung und Weiterbildung oder ohne externe Berater durchzuziehen. MDA ist nach wie vor Engineering, und es gibt genügend Gefahren, etwas falsch zu machen.
MDA verspricht plattformunabhängiges Modellieren von Applikationen. Wird das tatsächlich Realität werden?
Ja. Erfolgsstories hierfür gibt es inzwischen genügend. Man muss aber immer wissen, wieviel Unabhängigkeit man will, denn ab einem bestimmten Grad kostet es auch mehr. Hier kommt die bekannte 80/20-Regel zum Zug.
Aber ist denn plattformunabhängiges Design überhaupt so wichtig? Schliesslich wechselt man nicht täglich von J2EE nach .Net und umgekehrt.
Genau, deshalb ist ein plattformunabhängiges Design dieser Art nur für wenige wirklich interessant. Lustigerweise fragt aber fast jeder danach.
Auch Microsoft will jetzt auf den MDA-Zug aufspringen. Rechnen Sie damit, dass die Redmonder sich an die OMG-Standards halten oder einmal mehr ihr eigenes Süppchen kochen werden?
Microsoft muss zumindest einen anderen Namen verwenden, weil die OMG MDA aus gutem Grund gut geschützt hat. Ich denke, Microsoft wird sich wie immer an einige Standards halten und andere missbrauchen.
Was kann in Zukunft sonst noch von MDA erwartet werden?
In fünf Jahren werden Code-Cracks genauso selten sein wie Assembler-Programmierer fünf Jahre nach Erfindung des Fortran- oder Cobol-Compilers. MDA-Werkzeuge sind noch am Anfang ihres Innovations-Zyklus. Für unseren ArcStyler haben wir eine Liste mit Hunderten von sinnvollen Neuerungen. Es befindet sich also noch viel in der MDA-Pipeline.
