Seite 3: Nachteile und Fazit

Inhaltsverzeichnis

Probleme und offene Punkte

Doch es sind auch die Nachteile modellgetriebener Softwareentwicklung mit UML zu benennen:

• Ein UML-Metamodell zu verstehen ist nicht einfach. Obwohl die Anwendungsentwickler wenig mit der Entwicklung der Generatoren zu tun haben, ist es ratsam, sich zumindest mit dem Begriff des Metamodells zu beschäftigen. Für die Cartridge-Entwickler gibt es keinen Weg daran vorbei, damit sich die Cartridges realisieren lassen.
• Es existieren wenige ausgereifte Cartridges für den direkten Einsatz in der modellgetriebenen Softwareentwicklung mit UML. AndroMDA ist hier eine Ausnahme.
• Der Einstieg ist leider nicht trivial, da die UML-Modellierung mit ihrer Werkzeugkette benötigt wird.
• Es gibt kein gutes quelloffenes UML-Werkzeug, sodass der Einstieg stets mit Kosten und Anträgen für den Einsatz eines neuen Produkts beziehungsweise der Produktanalyse verbunden ist. Eclipse Papyrus ist wahrscheinlich das einzige ausgereifte freie UML-Werkzeug. Für einen sinnvollen Einsatz der modellgetriebenen Softwareentwicklung mit UML sind jedoch kommerzielle UML-Produkte wie MagicDraw unverzichtbar.

Werkzeuge für die modellgetriebene Softwareentwicklung mit UML und Java

Falls modellgetriebene Softwareentwicklung mit UML und Java in einem Projekt zum Einsatz kommen soll, gibt es glücklicherweise einige Open-Source-Projekte, die die Einführung vereinfachen sollten. Folgende Werkzeuge sind die bekanntesten aus diesem Bereich:

AndroMDA

• Status: aktiv, Release der Version 3.4 ist fertig
• Vorteile: Produkt und Community haben trotz unterschiedlicher Hauptentwickler und Committer überlebt. Das zeigt, dass AndroMDA ein "wahres" Open-Source-Projekt ist. Außerdem existieren viele fertige und produktive Cartridges für unterschiedliche Techniken.
• Nachteile: komplexe Cartridge-Entwicklung, ein Cartridge wird mit einem Cartridge ("eat your own dog food") entwickelt. Das ist prinzipiell ein guter Mechanismus, jedoch für viele zu komplex.

oAW

• Status: keine Aktivität, letzte produktive Version oAW 4.3.1 seit 2008
• Vorteile: Die einzelnen Werkzeuge sind in der Eclipse-Community beheimatet. Eine kommerzielle Unterstützung erfolgt durch die itemis AG.
• Nachteile: keine Community-Entwicklung, außerdem gibt es zu viele unterschiedliche DSLs (Check, Xpand, Xtend), was die Entwicklung von Cartridges verkompliziert. Kaum produktive Cartridges, nur eine kleine Sammlung einfacher Cartridges.

Eclipse Acceleo

• Status: aktiv, Version 3.3.0
• Vorteil: Das Produkt wird unter dem Eclipse-Dach entwickelt.
• Nachteile: Enge Kopplung in Eclipse, "standalone" mit Maven ist jedoch prinzipiell möglich. Neue DSL für die Transformation, Standard von OMG, das sogenannte MTL (Model to Text Language). Einige fertige und produktionsreife Cartridges sind vorhanden.

Taylor

• Status: letzte Version im August 2011, Version 1.4.0, nicht so aktiv
• Vorteile: viele fertige Cartridges, etwa für EJB 3, JSF/JBoss Seam, JMX MBeans und Webservice, sind vorhanden. Ausschließliche Nutzung von Eclipse-Techniken, um generieren zu können: Eclipse UML, Eclipse GMF (Graphical Modeling Framework) und Eclipse JET (Java Emitter Templates).
• Nachteile: Enge Kopplung in Eclipse, Generierung des Codes kann nur innerhalb der Eclipse-Umgebung stattfinden. Keine aktive Community. Produkt eines einzigen Entwicklers.

Topcased

• Status: aktiv, Version 5.2.0, basiert auf Eclipse 3.7.2
• Vorteile: integriert unterschiedliche Eclipse-Werkzeuge (UML2, Papyrus), Simulation von Modellen möglich
• Nachteile: enge Kopplung in Eclipse, Generierung des Codes kann nur innerhalb der Eclipse-Umgebung stattfinden, keine fertigen Cartridges für Java-Enterprise-Entwicklungen, mehr für kritische Systementwicklungen gedacht.

openMDX

• Status: aktiv, Version 2.10.0
• Vorteile: Keine Abhängigkeiten zu Eclipse
• Nachteile: Es gibt ausschließlich ein Cartridge für die Enterprise-Entwicklungen (REST-Architektur mit JDO)

KissMDA

• Status: aktiv, Version 1.0.0
• Vorteile: basiert hundertprozentig auf Java 6 und Maven, keine Eclipse-Abhängigkeiten, Java-Generatoren werden mit JDT (Java) umgesetzt, Dependency Injection wird überall genutzt.
• Nachteile: Noch zu neu, keine produktiven Cartridges.

Fazit

Inzwischen ist es um die modellgetriebene Softwareentwicklung mit UML und Java ruhig geworden. Diese Methode spielt bei der generellen agilen Anwendungsentwicklung fast keine Rolle mehr. "Zu unflexibel", "zu aufwendig", "zu komplex" und "zu kompliziert" werden als Gründe oft genannt. Leider ist ein wichtiger Faktor bei der Anwendungsentwicklung oft vernachlässigt worden: die Wartung. Die Weiterentwicklung einer Anwendung und Einarbeitung eines neuen Entwicklers sind ohne aktuelle und visuelle Dokumentation auf einer richtigen Abstraktionsebene kaum möglich beziehungsweise aufwendig. Hier spielt die modellgetriebene Softwareentwicklung mit UML definitiv ihre Stärke aus. Zugegeben, es gibt einige Defizite in der modellgetriebenen Softwareentwicklung mit UML wie ein höherer Aufwand für den Einstieg und eine fehlende Auswahl produktionsreifer Cartridges. Das ist jedoch beherrschbar und stellt kleinere Nachteile im Vergleich der vorgestellten Vorteile dar.

Dr. Lofi Dewanto
arbeitet als Softwarearchitekt und -entwickler bei der Deutschen Post Renten Service. Er engagiert sich insbesondere für "javanische" Open-Source-Software sowie modellgetriebene Softwareentwicklung mit UML.