Modellgetriebene Softwareentwicklung mit UML und Java

Modellgetriebene Softwareentwicklung mit UML und Java ist sicherlich nicht mehr das Thema der Stunde. Insbesondere bei der Diskussion zur agilen Softwareentwicklung im Kontext von Java wird kaum jemand den modellgetriebenen Ansatz damit verbinden. Zu komplex und nicht flexibel genug sind öfter genannte Gründe dagegen. Es gibt jedoch gute Gründe, warum MDSD mit UML für eine agile Softwareentwicklung mit Java geeignet sein kann.

Bei der Untersuchung der Verbreitung der modellgetriebenen Softwareentwicklung mit der Unified Modeling Language (UML) (siehe zur Begriffsklärung den Exkurs) stellt sich zumeist heraus, dass sie insbesondere in der Anwendungsentwicklung keine oder nur eine untergeordnete Rolle spielt. In kleinen Projekten machen sich die Verantwortlichen keine Gedanken über modellgetriebene Softwareentwicklung, da diese angeblich zu komplex, zu träge und zu kostspielig sei. In großen ist es schwer, auf einen gemeinsamen Nenner zu kommen, da unterschiedliche Mechanismen – beispielsweise unterschiedliche Generatoren – zum Tragen kommen. Auch ist modellgetriebene Softwareentwicklung unerwünscht, da man sich oft nicht über das Modellierungswerkzeug einigen kann. Bei den UML-Werkzeugen kommt erschwerend hinzu, dass sie untereinander oft inkompatibel sind.

Anscheinend sind auch Schulungsanfragen im Bereich der modellgetriebenen Softwareentwicklung mit UML gering und deshalb vernachlässigbar. Es gibt derzeit offenbar wenig Bedarf für modellgetriebene Softwareentwicklung mit UML. Die Unified Modeling Language wird hingegen bei den Analyse- beziehungsweise allgemeinen Modellierungssprachen als De-facto-Standard angesehen, und der Schulungsbedarf bleibt in dem Bereich entsprechend stabil.

Aus den Beobachtungen lässt sich ableiten, dass modellgetriebene Softwareentwicklung mit UML unwichtig für zeitgemäße Java-Softwareentwicklung geworden ist.

Ein Blick zurück

Die Geschichte von MDSD mit UML und Java begann mit einem Framework namens AndroMDA. Mit ihm, das etwa 2004 größere Verbreitung erfuhr, ließen sich endlich Entitäten und Services mit UML modellieren, und anschließend wurde der benötigte EJB-Infrastrukturcode (Enterprise JavaBeans) automatisiert generiert. Der Entwickler musste "nur" noch die generierten Klassen erweitern und die Implementierung mit Leben versehen. AndroMDA stellt jedoch nicht nur die Infrastruktur für die Erstellung von Generatoren (bei AndroMDA werden Generatoren als Cartridges bezeichnet – im Artikel werden Generatoren und Cartridges gleichbedeutend eingesetzt) zur Verfügung, sondern auch fertige Cartridges, die sich direkt bei der Anwendungsentwicklung einsetzen lassen.

Danach ging es bergauf für die modellgetriebene Softwareentwicklung mit UML und Java. Überall wurde in der Folge über das Thema diskutiert. Kurz darauf kam ein zweites MDSD-Framework, openArchitectureWare (oAW), hinzu, dieses jedoch mit einem anderen Ansatz. Fertige Cartridges gab es nicht, da sie für jede Anwendung unterschiedlich sein müssten, so hieß es. Allgemeine Cartridges und somit allgemeine Anwendungsarchitekturen könnten nicht jeden befriedigen und seien vor jedem Einsatz anwendungs- beziehungsweise unternehmensspezifisch zu implementieren.

Dieser Ansatz ist nach Ansicht des Autors bis heute fraglich, da Referenzanwendungsarchitekturen definitiv eine sinnvolle Wiederverwendung sind. Warum sollte es keine Best Practices in der Verwendung von Spring Framework und JPA (Java Persistence API) geben, die produktionstauglich sind? Viel später wurden Cartridges für oAW, ähnlich wie bei AndroMDA, innerhalb der Fornax-Plattform angeboten.

2006 – wahrscheinlich der Höhepunkt der modellgetriebenen Softwareentwicklung mit UML – dachte man, dass sich die Wiederverwendung "nur noch" auf der Modell- und nicht mehr auf der Code- beziehungsweise Binärcode-Ebene abspiele. Das Open-Source-Produkt openCRX (ein Open Source CRM) hat gezeigt, wie die Wiederverwendung auf der Modellebene funktionieren kann. Bis heute zeigt sich jedoch, dass dieser schöne Ansatz immer noch nicht erfüllt ist.