Designermodelle

Inhaltsverzeichnis

Bereits im November 2000 gab die Object Management Group (OMG) ein Whitepaper heraus, das die modellgetriebene Entwicklung von Applikationen unter dem Namen MDA (Model Driven Architecture) vorstellte. Mittlerweile bieten Hersteller eine Menge von Werkzeugen an, die die Softwareentwicklung auf der Basis von MDA unterstützen.

Eine Liste der Firmen, sich dem MDA-Ansatz verschrieben haben, ist auf dem Webserver der OMG zu finden. Leider ist diese Übersicht nicht gut gepflegt. Vom Consulting-Angebot über Ankündigungen (Paperware) und einige Open-Source-Codegeneratoren bis hin zum umfassenden MDA-Produkt findet man bunt gemischt eine URL-Sammlung. Da eine Einordnung der Produkte in unterschiedliche Leistungskategorien die Entscheidung für ein Werkzeug deutlich erleichtern dürfte, erläutert dieser Artikel nicht nur den prinzipiellen Aufbau von MDA/MDD/UML-Tools, sondern stellt außerdem einige wichtige Kriterien für deren Auswahl vor.

Einen Überblick über die einzelnen Werkzeuge und die verschiedenen Kategorien, in die sie sich unterteilen lassen, geben die Tabellen MDA-UML-Werkzeuge ( Wer ausführlichere Informationen wünscht, kann sich eine erweiterte, nicht redaktionell bearbeitete PDF-Fassung herunterladen. ), Codegeneratoren und X-UML-Werkzeuge/UML-Virtual-Machine . Die genannten Merkmale basieren auf den Angaben der Hersteller, die einen Fragebogen mit 90 Fragen ausgefüllt haben. Einige Firmen haben unsere Anfrage nicht beantwortet und fehlen folglich in der Übersicht. Der vorliegende Artikel nimmt keine Bewertung vor, sondern gibt einen Überblick über die Bandbreite der MDA-Tools. Vor der Entscheidung für ein konkretes Produkt muss auf jeden Fall eine ausführliche Evaluation stehen, um ein Gefühl für die Vor- und Nachteile der einzelnen Produkte zu bekommen. Neben den im Fragebogen genannten Kriterien gibt es natürlich diverse weitere wie Einarbeitungsaufwand, Support oder bereits erfolgreich realisierte Projekte.

Nach dem CORBA-Standard, der für die Kapselung von Hardware, Betriebssystemen und Programmiersprachen zunächst gute Dienste geleistet hatte, ist die Model Driven Architecture der nächste wichtige Schritt der OMG in Richtung Plattformunabhängigkeit durch Abstraktion. Man hatte erkannt, dass ständig wechselnde Techniken und neue Komponenteninfrastrukturen wie EJB, J2EE, COM und .Net die schnelle Anwendungserstellung erschwerten, wenn nicht sogar verhinderten.

Offenheit schafft Flexibilität

Die Antwort der Object Management Group auf diese Situation heißt MDA. Wie Abbildung 1 zeigt, verwendet die OMG ein Schichtenmodell für das Zusammenspiel der verschiedenen Bestandteile. Der MDA-Kern integriert die von der OMG spezifizierten Standards UML (Unified Modeling Language), MOF (Meta-Object Facility) und CWM (Common Warehouse Metamodel), wobei UML bereits seit mehreren Jahren Anwendung findet.

UML dient, wie die Auflösung des Akronyms vermuten lässt, der Modellierung. Die aktuelle Version 2.0, die wichtige Neuerungen bringt, wartet noch immer auf ihre offizielle Verabschiedung. Zurzeit gilt die sogenannte „formal“ Version UML 1.5, wobei viele Hersteller inzwischen UML-2.0-Support anbieten. Die Beschreibung der Modellierungssprache selbst erfolgt über ein Meta-Modell, sodass sich UML-Modelle gegenüber diesem verifizieren lassen. UML ist eine mögliche, aber bei weitem nicht nicht die einzige Modellierungssprache. Für gewisse Marktbereiche (Domains) existieren sogenannte Domain Specific Languages (DSL), die oft für die jeweiligen Spezialisten intuitiver sind als die „allgemein gehaltene“ Unified Modeling Language. Auch deren Verwendung unterstützt MDA.

Modelle für Modelle definieren

MOF ist ein Meta-Meta-Modell, das diese Modellierungssprachen beziehungsweise deren Metamodelle einbindet. Mit Hilfe von MOF beschreibt der Entwickler, wie ein bestimmtes Meta-Modell aussehen soll. Das UML-Meta-Modell beispielsweise ist eine Instanz eines MOF-Modells, ein konkretes UML-Modell wiederum eine Instanz eines UML-Meta-Modells. So lässt sich ein Modell-Stack aufbauen, von M0 bis M3. Als grafische Notationselemente verwendet MOF die UML-Symbole, was die Einführung zusätzlicher Symbole (und die damit verbundenen Diskussionen) bewusst vermieden hat.

Der Kern der Spezifikation kümmert sich um den wichtigsten Teil von MDA: die Modellierung. In der nächsten Schale befinden sich die für den Ablauf der modellierten Anwendungen nötigen Techniken oder Plattformen. Dabei können Plattformen entweder Programmiersprachen (C, C++, C#, Java) oder komplette Infrastrukturen (CORBA, J2EE, .Net) sein. Prinzipiell kann man einen sinnvoll definierten Plattform-Stack aufbauen.

Die Grundidee von MDA ist, durch den Einsatz des Modells so viel Code wie möglich automatisiert für die Plattform zu generieren. Diese Vorgehensweise ermöglicht es, relativ einfach die Plattform zu wechseln (etwa von C++ nach Java oder von CORBA nach EJB), beziehungsweise sich an die Gegebenheiten einer bestimmten Plattform anzupassen. Beispielsweise kann man beim Übergang von EJB 1.1 auf die Version 2.0 die Methoden einfach neu generiert, ohne das Modell an die neue „Version“ der Plattform anzupassen.

MDA ist eine konsequente Weiterführung des Abstraktionsgedankens in der Softwareentwicklung. Geht man zunächst von Assemblercode aus, so stellt die Codierung beispielsweise in C++ eine höhere Abstraktion dar, bei der sich die darunter liegende Plattform (Prozessor) einfach durch Austauschen des C++-Compilers wechseln lässt. Der C++-Code bleibt weiterhin gültig. In MDA geht man einen Schritt weiter und entwickelt statt Sourcecode zunächst Modelle, die idealerweise sowohl von der Hardware als auch von der Softwareumgebung unabhängig sind (Platform Independent Model, PIM) und als Vorlage für die Codegenerierung dienen. Später erzeugt der Entwickler durch Modelltransformation oder die Angabe technischer Eigenschaften (etwa in Form von Properties oder Marksets) ein verfeinertes Modell für die Zielplattform (Platform Specific Model, PSM). Ziel ist, das Model weitgehend frei von technischen Details zu halten, sodass der Plattformwechsel durch neue Modelltransformation beziehungsweise den Austausch des Property- oder Mark-Set und der anschließenden Neugenerierung des Sourcecodes erfolgt.

In der äußersten Schale der Model Driven Architecture befinden sich allgemeinere Dienste wie Security, Events, Transaction et cetera, die die Umgebung zur Verfügung stellt, die aber auch schon in den Komponenteninfrastrukturen (beispielsweise J2EE) vorhanden sein können. Offensichtlich will die OMG mit MDA eine Vielzahl von Marktsegmenten beziehungsweise verschiedene Domains erreichen. Die Basis dafür ist durch den offenen modellbasierten Ansatz gegeben.

Toolhersteller sollen nun die benötigten MDA-Werkzeuge am Markt zur Verfügung stellen, damit Anwender auf Basis von Modellen einfach und schnell Applikationen erzeugen können. Die OMG bietet (wie bei CORBA) selbst keine Referenzimplementierung an, sondern nur die Spezifikationen hierfür sowie vereinzelt Test Suites, unter anderem für XMI (XML Metadata Interchange) als Austauschformat für Modelle.

Da MDA-Tools für verschiedene Domains und damit Zielmärkte konzipiert sind - etwa den Java-Enterprise- oder den Embedded-Bereich - ist es nicht ganz einfach, sie zu vergleichen. Selbst die Definition dessen, was ein UML- und was ein MDA-Tool ist, fällt nicht leicht. Einige Hersteller verwenden auch den Begriff MDD (Model Driven Development).

Generell lässt sich sagen, dass heutige Werkzeuge im Vergleich zu den CASE-Tools der 80er-Jahre deutlich robuster und benutzerfreundlicher sind und ihr Einsatz im Projekt spürbare Vorteile bringt. Insbesondere hinsichtlich der Codegenerierung - beziehungsweise allgemeiner der automatischen Erzeugung von Artefakten aus Modellelementen - hat sich ein Paradigmenwechsel vollzogen. Analog findet man erste Ansätze zu MDA auch in der aspektorientierten Programmierung oder den Java Meta-Data Annotations im neuen JDK 5.0, wobei diese, verglichen mit MDA, eher spezialisierte Teillösungen auf niedrigeren Ebenen und zudem plattformspezifisch sind (und daher nicht unbedingt zu empfehlen).

Einteilung in vier Gruppen

Eine grobe Klassifizierung soll zunächst eine Übersicht über die MDA-Tools bieten. (Eine kompakte Übersicht über die MDA-Tools und die Kategorien, in die sie sich einteilen lassen, inklusive Webadressen ist über den iX-Listingsservice erhältlich.)

Die erste Gruppe bilden Produkte mit direkt integriertem grafischen UML-Modellierungswerkzeug. Diese erlauben die Modellierung sowie die Generierung von Code und unterstützen häufig außerdem modellbasiertes Testen. Innerhalb dieser Gruppe sind einige Produkte speziell für den Echtzeit-, andere besonders für den Enterprise-Bereich geeignet. Dies äußert sich auch in jeweiligen Schwerpunkten bezüglich der Programmiersprache (C, Ada, Java) und den unterstützten Plattformen (RTOS, EJB/J2EE).

Als zweite große Gruppe lassen sich Codegeneratoren ohne eigentliches UML-Tool identifizieren. Anbieter dieser Produkte betten den Codegenerator in ein UML-Modellingswerkzeug eines Drittanbieters ein oder bieten ihn als eigenständige Anwendung mit XMI-Eingabe an. Gemeinsam ist den Codegeneratoren, dass sie sich sehr stark an die Bedürfnisse der Benutzter anpassen lassen (das heißt, oft mehrere Implementierungssprachen generieren) und dennoch meist leichtgewichtig sind.

Die dritte Gruppe umfasst die so genannten X-UML-Werkzeuge. Sie produzieren anhand des UML-Modells vollständig ausführbaren Code, das heißt, die Geschäftslogik schreibt der Programmierer nicht in einer konkreten Programmiersprache wie C, C++ oder Java, sondern formuliert sie in ASL (Action Semantic Language). Auf Basis der im Modell hinterlegten ASL erzeugt der Generator den ausführbaren Code, beziehungsweise die Anwendung läuft direkt in einer Art UML-VM (Virtual Machine).

Interessanterweise zählen einige der X-UML-Tools zu den Echtzeitprodukten der ersten Kategorie, so wie es auch weitere Überschneidungen zwischen den anderen Gruppen gibt. Beispielsweise hat ein X-UML-Werkzeug oft eine grafische Benutzerschnittstelle für den UML-Modellierungsteil (Gruppe 1), kann aber auch konkreten Code für eine Plattform generieren (Gruppe 2).

Tools, die ihren Fokus auf Modelltransformationen legen, bilden die vierte Gruppe. Natürlich ist Codegenerierung auch eine Form von Modelltransformation, den Übergang von PIM nach PSM lösen die heutigen MDA-Tools aber noch weitgehend auf herstellerspezifische Weise. Die OMG will hier mit QVT (Query View Transform) eine Basis für ein vereinheitlichtes Vorgehen schaffen, allerdings befindet sich die Spezifikation noch im Standardisierungsprozess. Die zurzeit verfügbaren MDA-Tools bieten zum Teil Modelltransformationen direkt mit an; per Zugriff auf das Repository können Benutzer auch eine eigene Modelltransformation entwickeln. (ka)