Seite 2: Best Practices und Vorteile

Inhaltsverzeichnis

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.