Unified Modeling Language (UML) – Totgesagte leben länger
Seit der Veröffentlichung der UML-Version 1.0 sind jetzt fast 13 Jahre vergangen. Mittlerweile wird heftige Kritik geäußert. Besonders kritisiert wird die kontinuierliche Zunahme von Umfang und Komplexität. Die neueste, im Mai 2010 von der OMG veröffentlichte Spezifikation der UML 2.3 umfasst knapp 1000 Seiten (UML Infrastructure und UML Superstructure). Dazu kommt eine prinzipielle Kritik: Die UML eigne sich vorwiegend zur Dokumentation aber nicht produktiv für die Entwicklung von Software. In Projekten würden daher nur Bilder ohne dauerhaften Wert entstehen. Ein weiterer diskutierter Aspekt ist die rudimentäre Generierung von Quell-Code, bei der nicht mehr als Klassendeklarationen und Signaturen produziert werden. Die Vielfalt der Argumente gegen den Einsatz der UML lässt sich in der Diskussion zu diesen Thesen gut verfolgen: 13 reasons for UML’s descent into darkness.
Ist diese Kritik berechtigt? Und wenn ja, welchen Sinn hat die UML-Modellierung von Softwaresystemen überhaupt? Sollte die Entwicklung von UML-Modellen gleich komplett aufgegeben werden? Die Antwort auf die letzte Frage lautet ganz klar: „Nein!“ Denn mit dem gezielten Einsatz der UML, der richtigen Methode und einer optimalen Toolunterstützung können Sie Produktivität und Qualität der Softwareentwicklung enorm erhöhen und gleichzeitig das Fachwissen Ihrer Organisation schützen. Das erreichen Sie mit
- dem Verzicht auf jeglichen Overhead durch die Beschränkung der Ausdrucksmöglichkeiten der UML. Sie modellieren nur das, was einen konkreten Nutzen für Ihr Projekt bringt.
- UML-basierter Automatisierung mit Model-Driven Development (MDD), einer der schnellsten und effektivsten Entwicklungstechniken für Software.
- dem Einsatz eines domänenspezifisch angepassten UML-Tools oder einer Toolvariante mit spezifischen Modellierungsfunktionen und Modelltransformatoren.
Das Prinzip Model Driven Development
Wie das in der Praxis aussehen kann, demonstriere ich Ihnen im folgenden Beitrag anhand einer Rich Internet Application (RIA) für .NET mit objectiF. Was ist eine RIA-Anwendung? In RIA-Anwendungen werden Daten aus einer Datenbank dem Nutzer auf Clients als Views präsentiert. Auf den Clients führen NutzerKommandos aus. Nach der Ausführung von Kommandos müssen geänderte Views auf dem Server gespeichert und schließlich geänderte Sichten auf dem Client angezeigt werden. Die Hauptkomponenten einer RIA-Anwendung sind clientseitig Views, Kommandos und ViewModels. Auf der Serverseite liegenServices und Entity-Klassen, ein O/R-Mapper und ein relationales Datenbanksystem. ViewDatas werden auf Client und Server verwendet. Sie dienen zum Transport der Attribute von Entities aus der Datenbank zu den Properties der ViewModels und umgekehrt. Das Mapping zwischen den Attributen von ViewDatas und Entities übernehmen Service-Operationen in ViewDataServices.
Architektur einer RIA Anwendung
Die Persistenzschicht: Vollständig automatisch implementiert
Die Persistenzschicht einer RIA-Anwendung wird als UML-Entity-Modell in Klassendiagrammen modelliert. Dafür werden keine speziellen Modellierungsfunktionen benötigt. Alle Entities werden durch Klassen mit einem entsprechenden Stereotyp und Attributen modelliert, zwischen den Klassen werden Beziehungen angelegt. Aus diesem Modell generiert objectiF die Persistenzschicht zu 100% automatisch. Ein entsprechender Modelltransformator sorgt dafür, dass aus den fachlichen Klassen NHibernate-Klassen einschließlich Konfigurationsdateien entstehen. Der Implementierungsaufwand ist gleich null. Die Transformation erfolgt per Mausklick.
Das Entity-Modell wird in NHibernate-Klassen mit Konfigurationsdatein transformiert
Das Präsentationsmodell: Modellierungsfunktionen für Views und Kommandos
Wenn Views und Kommandos modelliert werden sollen, werden Modellierungsfunktion benötigt, die über die Standardfunktionalität eines „normalen“ UML-Tools hinaus gehen. Die fachlichen Entity-Modelle sind nicht nur die Ausgangsbasis für die automatische Generierung der Persistenzschicht, sondern gleichzeitig Quelle für die Modellierung von Views. Bei der Definition von Views spezifizieren Sie, welche Daten aus dem Entity-Modell dem Nutzer präsentiert werden. objectiF besitzt dafür eine Funktion, nach deren Aufruf sie ein Entity selektieren können und anschließend das Entity selbst und die mit ihm verknüpften Entities einschließlich aller Attribute angeboten werden. Sie müssen nur die Attribute markieren, die im View enthalten sein sollen. Ein Klick auf OK und objectiF erzeugt alle Views automatisch mit den entsprechenden Attributen.
Die typischen Aktionen im Kontext von RIA-Anwendungen sind das Öffnen von Dialogen und Eingabemasken, das Bestätigungen und Speichern von Eingaben und Änderungen, das Navigieren zu Folgesichten etc. Die von einem Nutzer ausgelösten Kommandos müssen dafür sorgen, dass neu eingegebene oder geänderte Daten auf dem Server abgelegt und unmittelbar darauf alle von diesen Änderungen betroffenen Views auf den Clients aktualisiert werden.
Die Kommandos, die der Benutzer auslöst, unterscheiden sich in der Regel nur darin, welchen View sie als Input- oder Output-Parameter verwenden. Die meisten Kommandotypen sind daher in objectiF schon vorimplementiert. Die Modellierung konkreter Kommandos wird durch eine Modellierungsfunktion, die diese vorimplementierten Kommandotypen anbietet und die die einfache Spezifizierung der Kommandoparameter erlaubt, extrem beschleunigt und vereinfacht.
Die Modelle transformieren: Viel mehr als nur Signaturen
Domänenspezifische Modelltransformatoren und eine vordefinierte Softwarearchitektur sorgen dafür, das bei der Arbeit mit objectiF alle fachlichen Modelle automatisch in die Komponenten einer vordefinierten und erprobten Software-Architektur transformiert werden. Aus den UML-Artefakten des fachlichen Modells werden eine oder mehrere – in großen Teilen bereits vollständig implementierte C#-Klassen – komponentenabhängig automatisch an die vorgesehene Position in der zugehörigen .NET-Projektmappe generiert.
Aus allen Entity-Klassen entstehen NHibernate-Klassen mit Konfigurationsdateien. Aus jedem View des fachlichen Präsentationsmodells erzeugt objectiF bei der Transformation im technischen Modell einViewModel. Aus den fachlichen Modellen resultieren außerdem ViewDatas und ViewDataServices. Zu der Produktivität, die Sie bei der fachlichen Modellierung durch domänspezifische Modellierungsfunktionen gewinnen, kommt also die, die Sie bei der Transformation der UML-Modelle erzielen. Welche Komponenten durch die Transformation der fachlichen Modelle automatisch gefüllt werden, zeigt die folgende Abbildung:
Ergebnisse der Modelltransformationen
In der Praxis erfolgt die Modellierung und Transformation der fachlichen Modelle nicht linear, sondern iterativ: Änderungen oder Ergänzungen in den einzelnen fachlichen Modellen sind jederzeit möglich. Manuelle Ergänzungen an den generierten anwendungsspezifischen Klassen bleiben bei einer erneuten Transformation der fachlichen Modelle erhalten. Natürlich geht es auch bei der modellgetriebenen Entwicklung nicht ohne manuelle Implementierungen. Sie müssen z. B. die Services der Anwendung implementieren und – je nach Technologie – z. B. per DataBinding an XAML-Controls an der Oberfläche nutzbar machen.
RIA-Anwendungen sind nur ein Beispiel für eine Domäne. Sie finden in objectiF u.a. Vorlagen mit spezifischen Modellierungsfunktionen und Transformatoren für die Entwicklung von SOA-Anwendungen, Web-Services, EJB-Anwendungen und XÖV-konformen Standards.
Fazit
Die UML ist nicht tot. Im Gegenteil. Im Kontext modellgetriebener Entwicklung bietet sie ganz neue Chancen und Perspektiven für die Softwareentwicklung. Die Antwort auf die Kritik an der UML ist allerdings nicht ein Tool als Alleskönner, das möglichst viele UML-Konstrukte abdeckt und möglichst viele Diagrammtypen mitbringt, sondern ein domänenspezifisch angepasstes Werkzeug oder eine Toolvariante mit spezifischen Funktionen und Transformatoren für die jeweilige Domäne. Domänenspezifische Funktionen sorgen für die schnelle und einfache Modellierung von fachlichen Modellen, Modelltransformatoren für eine konsistente Umsetzung der fachlichen Modelle in die vorgegebene Systemarchitektur.
Zusammen mit der Beschränkung auf die projektspezifisch notwendigen UML-Konstrukte sorgen beide für mehr Produktivität und sparen wertvolle Zeit bei der Entwicklung von Software. Die UML ist in hohem Maße aktuell und unverzichtbar. Sie muss nur effektiv eingesetzt werden. Mit dem Einsatz der UML und Model-Driven Development schützen Sie zudem das Fachwissen Ihrer Organisation. Denn fachliche Modelle machen das Wissen Ihrer Organisation transparent und verbergen es nicht irgendwo im Code.
Diskutieren Sie mit und hinterlassen Sie einen Kommentar.