Model Driven Architecture: Jürgen Strauss vs. Claudio Hintermann
Artikel erschienen in Swiss IT Magazine 2003/14
Model Driven Architecture (MDA) ist spätestens seit dem Kauf der schwedischen Boldsoft durch Borland auch für Softwareentwickler im Microsoft-Umfeld ein Thema. Die kürzliche Absegnung der Version 2.0 der graphischen Modellierungssprache UML (Unified Modeling Language) durch die Object Managment Group (OMG) wird die Verknüpfung von Modellierung mit automatischer Code-Generierung weiter popularisieren.
Pro: Ein Grossteil der Datenbankabfragen wird direkt aus dem Framework in optimierter Form generiert, so dass die Applikation von Natur aus schnell ist. Für anspruchsvolle Statistiken oder Stapelverarbeitungen ergeben sich keine Vorteile. Hier umgehen wir manchmal das Framework und optimieren einzelne SQL-Abfragen oder setzen Data-Mining-Werkzeuge ein.
Kontra: Performance ist immer ein Thema, von unwichtigen Routinen abgesehen. Je nach Tool ist die Optimierung aufwendig, weil oftmals nicht einfach eine Zusatzinfo zur Optimierung mitgegeben werden kann, sondern gleich der ganze Teilbereich von Hand gemacht werden muss.
Pro: Die Menge an benötigtem Quellcode und Eingabeformularen reduziert sich mit MDA auf einen Bruchteil. Weniger Code, weniger Fehler. Bei der Weiterentwicklung sind wir selber immer wieder von neuem überrascht. Wir können in bestehende Applikationen nachträglich fundamentale Änderungen der Prozesse einbauen und das System sofort wieder stabilisieren. So haben wir schon innert Wochen in einer Branchenlösung Mandantenfähigkeit und Geschäftsbereiche eingebaut.
Kontra: Überall dort, wo mit den Standardmöglichkeiten eines Tools gearbeitet werden kann, ist Wartbarkeit ein klares Plus für MDA. Das gilt allerdings nur sehr eingeschränkt für jene Tools, bei denen im generierten Sourcecode manuell weitergearbeitet wird. Dann kann der Update auf die nächste Version zum Albtraum werden. Ausser MDA gibt es andere Ansätze, welche z.B. beim User Interface viel Flexibilität bieten. Abacus definiert beispielsweise die UIs in XML, von wo sie gerendert und vom Kunden selber angepasst werden können - mit standardisierten Tools.
Pro: Unsere Erfahrungen zeigen einen Gewinn von 300 bis 500 Prozent gegenüber traditioneller Programmierung. Wichtiger ist aber time-to-market. Ein halb so grosses Team ist in der halben Zeit mit dem Produkt fertig.
Kontra: MDA bietet auch bei diesem Punkt klare Vorteile. Es muss jedoch zwischen Entwicklungen auf der grünen Wiese und solchen mit Legacy-Daten und/oder -Systemen unterschieden werden. So lassen sich oftmals Legacy-Daten nur sehr schwer in einem Modell sinnvoll abbilden, was dann den Sinn des Einsatzes eines Tools generell in Frage stellen kann. Auch gute Programmiersprachen bieten heute einem guten Programmierer schon mächtige Möglichkeiten, effiziente Abstraktionen umzusetzen.
Pro: Spezialisten werden nicht benötigt. Das Spezialwissen liefern wir als Framework-Hersteller. Gute Applikationsprogrammierer lernen MDA schnell. Das Schwierige bei einem Paradigmawechsel ist nicht das Neulernen, sondern das Loslassen der alten Methoden, die mit so viel Gefühlen von Erfolg und Sicherheit verbunden sind. Wenn diese Blockade überwunden ist, ist die frühere Produktivität in wenigen Wochen erreicht.
Kontra: Jedes Tool oder Paradigma braucht eine gewisse Einarbeitungszeit und muss verstanden werden, bevor es produktiv genutzt werden kann. Das ist bei MDA nicht anders: Gerade hinter den genialen Konzepten stehen oft Gedankenmodelle, die sich nicht jeder Programmierer einfach so verinnerlichen kann. Wenn, wie oben erwähnt, Optimierungen manuell ausprogrammiert werden müssen, ist es notwendig, zwei total unterschiedliche Methoden zu beherrschen. Je nach Tool kann es zudem schwierig sein, wirklich gute Leute mit Erfahrung zu finden.
Pro: Das Framework selbst ist viel besser getestet als normale Applikationsprogramme und der Programmierer arbeitet im Rahmen des Frameworks. MDA ist ein ausgezeichnetes Instrument zur Disziplinierung einer Entwicklungsabteilung. Der Testprozess reduziert sich auf diejenigen Bauteile, die nicht vom Framework kontrolliert werden und wird bei uns zunehmend durch automatisierte Testumgebungen sichergestellt.
Kontra: Gerade die komplexesten Programmteile sind es, die "von Hand" erstellt werden müssen; genau diese sind aber am anfälligsten für Fehler und beanspruchen auch den grössten Testaufwand. Andere Programme lassen sich auch mit Test-Tools effizient auf Fehler überprüfen.
Pro: Der gemeinsame Modellierungsprozess von Entwickler und Anwender sorgt dafür, dass die Komplexität viel früher erkannt und in lauffähige Prototypen abgebildet wird. Das Applikationsmodell ist anschliessend der zentrale Referenzpunkt für alle Geschäftsprozesse und mehrheitlich selbst-dokumentierend. Auch komplexe Lösungen werden so viel greifbarer. Der Quellcode ist sehr schematisch und so leicht verständlich.
Kontra: Ein Modell kann erheblich dazu beitragen, ein komplexes Projekt von Hand übersichtlicher zu dokumentieren (automatisch erstellte Dokumentation ist nahezu wertlos). Je nach Arbeitsweise wird bereits das Erstellen unterstützt. Für komplexe Projekte braucht es aber immer gute Leute - darüber sollte kein noch so geniales Tool hinwegtäuschen.
Pro: MDA führt zu deutlichen Kostensenkungen auf allen Ebenen. Die Entwicklung wird günstiger durch höhere Produktivität, die Implementierung durch vereinfachte Anpassung an die Kundenbedürfnisse und die Anwendung durch die hohe Konsistenz der Benutzerführung. Unsere Entwicklungspartner bezahlen uns pro MDA-Entwickler ca. 10 Prozent der Kosten einer Entwicklerstelle. Sie sparen sich so die teuren und schwierig zu führenden technischen Spezialisten und können sich voll auf die Applikationen konzentrieren.
Kontra: Die Geschichte hat mehrfach gezeigt, dass bei Frameworks mit kürzeren Lebenszyklen als bei Programmiersprachen oder sogar Plattformen zu rechnen ist. Oder wer redet heute noch von Jackson? Langfristig überleben weniger proprietäre, globale Ansätze länger und sind somit günstiger.