Modellgetriebene Softwareentwicklung mit UML und Java

Inhaltsverzeichnis

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.

Best Practices und Vorteile

Aus der Praxis

Nach Beobachtungen des Autors gibt es zwei typische Einsatzbeispiele für die modellgetriebene Softwareentwicklung mit UML und Java:

1. Es werden kleine und große Projekte mit der modellgetriebenen Softwareentwicklung mit UML umgesetzt. Hier gilt es, den Vorteil einer guten Dokumentation sofort zu erkennen. Für sämtliche Anwendungen und Komponenten ("Hausplanung") gibt es stets gute Beschreibungen zu Geschäftsobjekten und -prozessen. Änderungen und Erweiterungen lassen sich somit effizienter einbauen, da Entwickler den Überblick über sämtliche Komponenten haben. Eine übergreifende Dokumentation der Anwendungslandschaft ("Stadtplanung") gibt es daraus nicht unmittelbar, jedoch ist das durchaus über die Verknüpfungen unterschiedlicher "Hausplanungen" möglich. In einem Umfeld, in dem externe Entwickler kommen und gehen, zeigt die modellgetriebene Softwareentwicklung mit UML ihre Stärke. Die Einarbeitung neuer Entwickler beschränkt sich auf die Stereotypen der UML-Modelle und das fachliche Gebiet der Anwendung. Techniken wie Spring und Hibernate werden unter normalen Umständen in den Hintergrund geschoben.
2. Es wird nicht beziehungsweise noch nicht durchgängig mit der modellgetriebenen Softwareentwicklung gearbeitet. Dort sind viele Komponenten händisch implementiert. Es gibt wenig bis keine Hausplanung. Stadtplanung wird hier händisch in Form großer Poster entworfen, ist jedoch meistens "veraltet". Falls in diesem Umfeld doch modellgetriebene Softwareentwicklung mit UML herangezogen wird, werden einige Best Practices (siehe unten) nicht beachtet, die neue Probleme nach sich ziehen. Neue Entwickler müssen – bevor sie produktiv arbeiten können – Werkzeuge zum Reverse Engineering einsetzen, damit sich die Strukturen wie Persistenzklassen visuell darstellen lassen.

Best Practices und Vorteile

Über die Jahre hinweg haben sich folgende Best Practices im Rahmen der modellgetriebenen Softwareentwicklung mit UML herausgestellt (siehe auch die Slides zum Vortrag "MDD: the Good, the Bad and the Ugly" von Steven Kelly und Markus Völter):

• Top-down als Richtung: Das zu entwickelnde System wird zunächst mit UML beschrieben ("deskriptiv"). Aus dem UML-Modell generiert man anschließend Artefakte (Java-Code, XML). Der generierte Java-Code wird anschließend vervollständigt und implementiert ("imperativ"). Der Mechanismus funktioniert stets in einer Richtung: Top-down und nicht von unten nach oben oder in beide Richtungen.
• Generierte Artefakte werden nie per Hand editiert und in das Versionierungssystem eingecheckt: Daher braucht ein Entwickler meistens unterschiedliche Ablageorte für die generierten und nichtgenerierten Artefakte: in Maven beispielsweise target/generated-sources/java. Geschützte Bereiche ("protected regions") bei generierten Artefakten sind eine schlechte Idee. Diese werden nie in das Versionierungssystem eingecheckt, da sie stets generiert werden. In Maven gibt es eine eigene Phase aus dem Maven-Build-Lebenszyklus, generate-sources, für den Generierungsprozess.
• UML-Modelle sind "first-class citizens", sie werden genauso wie Java-Code oder XML-Dateien behandelt: Hierfür benötigt man exzellente Werkzeuge, nicht weniger gut als Eclipse für die Entwicklung von Java-Code.
• Partitionierung: Genauso wie Maven-Projekte beziehungsweise -Module sind die UML-Modelle zu partitionieren, sodass diese nicht zu groß werden. Allgemein gilt: In einem Maven-Projekt existiert genau ein UML-Modell.
• Cartridge- und Anwendungsentwickler sind zwei getrennte Rollen, analog zu Framework- und Anwendungsentwicklern. Cartridges und Anwendungen müssen ihren eigenen Lebenszyklus haben, und die Anwendungen nutzen eine bestimmte Version einer Cartridge/eines Generators.
• Man fängt bei der Einführung der UML-Modelle und Cartridges immer klein an: Es sollten nicht sämtliche Maven-Projekte direkt mit UML-Modellen und Cartridges erweitert werden, sondern man startet mit einem weniger wichtigen Maven-Projekt.

• Die Dokumentation ist stets aktuell, beispielsweise Interface, Entity- und/oder Service-Struktur. Für viele externe Entwickler und Berater ist der Vorteil wahrscheinlich nicht so wichtig, da externe Mitarbeiter meistens zeitbegrenzt eingesetzt werden. Für die internen Entwickler ist die Dokumentation jedoch "lebenswichtig".
• Die Kommunikation und Diskussion mit der Fachseite beziehungsweise dem Betrieb sind transparenter, da Diagramme und/oder Bilder vorhanden und aktuell sind.
• Die Architektur der Anwendungen ist stets gleich. Das ist besonders wichtig, wenn das implementierte System eine bestimmte Größe überschreitet. Die Verwendung eines Frameworks wie Spring und JPA mit Hibernate erlaubt immer noch "zu viele freie" Interpretationen, die für die spätere Wartung des Systems ein Problem darstellen können.
• Die Einarbeitung neuer beziehungsweise externer Entwickler erfolgt einfacher und schneller. Sie lernen, wie sich mit UML Persistenz- und Serviceschicht modellieren lassen. Anschließend wird der Anwendungsrahmen generiert, der mit Inhalten zu befüllen ist.
  

Folgendes einfaches Beispiel aus der AndroMDA-Demoanwendung zeigt die Stärke eines visuellen UML-Modells für die fachliche Einarbeitung eines Entwicklers. Die Abbildungen 1 und 2 zeigen die Struktur der Anwendung mit Entitäten (Entity) und Services (Service) als UML-Modelle (grafisch)

Abbildung 3 zeigt die Struktur der Anwendung mit Entitäten (Entity) und Services (Service) als Java-Code (textuell) in der Eclipse-Umgebung.

Mit der visuellen Darstellung wird die Struktur der Anwendung sofort deutlich, beispielsweise dass ein User keinen bis mehrere Timecards besitzen kann. Zudem ist die Schichtenarchitektur in der Anwendung unmittelbar zu erkennen: Controller -> Service -> Entity.

Die textuelle Darstellung auf der Code-Ebene bringt auf Anhieb keine fachliche Hilfe. Die Java-Klasse, etwa TimecardDaoImpl, ist eine reine technische Klasse, die keine fachliche Bedeutung besitzt. Hinzu kommen andere technische Artefakte wie SpringFramework-XML oder JPA-XML, die die Übersichtlichkeit der Anwendungsstruktur definitiv verschlechtern.

Bei größeren Anwendungen ist die Bedeutung der grafischen Darstellung eines UML-Modells, das aktuell zum implementierten Quellcode ist, für die Agilität der Entwicklung nicht zu unterschätzen.

Nachteile und Fazit

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.

Exkurs

MDSD versus MDA

Zur Verallgemeinerung von MDA (Model Driven Architecture) entstand das MDSD-Konzept (Model-Driven Software Development). Es verwendet Modelle als zentrale Idee. Dabei wird die Anwendungslogik nicht in einer traditionellen Programmiersprache ausformuliert, sondern in einer domänenspezifischen Sprache (Domain Specific Language) umgesetzt. Zudem umfasst MDSD die Produktlinien-Softwaretechnik, die die Definition und Erstellung von Produktfamilien einer speziellen Domäne zum Ziel hat. Ein wichtiger Bestandteil des MDSD-Konzepts sind Transformationsregeln. Mit ihnen lassen sich aus Quell- neue Zielmodelle generieren. In der Praxis werden sie in Generatoren umgesetzt und als Cartridges verpackt. Als Quellmodelle dienen oft UML-Modelle, und als Zielmodelle stellen meistens textuelle Artefakte wie Java-Code XML dar.

MDSD sieht MDA als Spezialisierung dieses Konzepts, da MDA das MDSD-Konzept ausschließlich mit konkreten offenen Standards (UML, MOF und QVT) implementiert. Vereinfacht gelten folgende Definitionen:

• MDSD: allgemeine modellgetriebene Softwareentwicklung
• MDA: MDSD mit UML

Beim Einsatz der modellgetriebenen Softwareentwicklung mit UML ist auf zwei unterschiedliche Rollen zu achten:

• Anwendungsentwickler: Sie verwenden Cartridges, um aus einem oder mehreren UML-Modellen etwa Java-Code und XML zu generieren. Anwendungsentwickler sind im Prinzip analog zu allgemeinen Framework-Nutzern.
• Cartridge-Entwickler: Sie sind analog zu Framework-Entwicklern. Sie stellen den Anwendungsentwicklern Generatoren beziehungsweise Cartridges beispielsweise von UML zu Java-Code und XML zur Verfügung.
  

(ane)