Modellgetriebene Architektur

Modellgetriebene Architektur (MDA; engl. model-driven architecture) bezeichnet einen modellgetriebenen Softwareentwicklungsansatz, der auf einer klaren Trennung von Funktionalität und Technik beruht. Er wurde 2001 von der Object Management Group (OMG) eingeführt.

Abgrenzung zu CASE und MDSD

MDSD (model-driven software development) bezeichnet die Verwendung von Modellen und Generatoren zur Verbesserung der Softwareentwicklung. Schon in den Anfangszeiten der Informatik stützte man sich auf Modelle und entwickelte Generatoren, um schematischen Quellcode daraus zu erzeugen. MDSD wird gelegentlich mit den CASE-Ansätzen der 1990er Jahre verwechselt. MDSD und CASE unterscheiden sich jedoch in ihren grundlegenden Zielen.

Ziel der CASE-Ansätze war und ist es, Software möglichst vollständig automatisiert aus fachlichen Beschreibungen zu erstellen. Da sich die Automatisierung dabei auch auf den Bereich der Softwarearchitektur erstreckt, erwiesen sich die CASE-Ansätze als sehr unflexibel. Diese Tatsache führte in Verbindung mit der Proprietät der verfügbaren Werkzeuge dazu, dass sich CASE nicht durchsetzen konnte.

Ein möglicher Weg zur Implementierung des MDSD ist die im Artikel beschriebene MDA.

MDA erfordert keine hundertprozentige Automatisierung, sondern einen sinnvollen Anteil. Dieser variiert je nach fachlicher Anforderung zwischen 20 und 80 Prozent. Da die Architektur eines Systems vollständig manuell erzeugt wird, ist MDA hochgradig flexibel und gewährt, im Gegensatz zum CASE-Ansatz, die vollständige Kontrolle während des Entwicklungsprozesses.

Ziele

Steigerung der Entwicklungsgeschwindigkeit

Ein Ziel der MDA ist die Steigerung der Entwicklungsgeschwindigkeit. Das Mittel dazu heißt „Automation durch Formalisierung“.

Aus formal eindeutigen Modellen soll durch Generatoren automatisch Code erzeugt werden, das sogenannte Generat. Dadurch soll auch die Softwarequalität gesteigert werden. Fehler im Generat können an einer Stelle – in den Generatorschablonen – beseitigt werden. Die Qualität des generierten Sourcecodes ist gleich bleibend, was zu einem höheren Grad der Wiederverwendung führen soll. Siehe auch Generative Programmierung.

Bessere Handhabbarkeit aufgrund höherer Abstraktion

Ein weiteres wesentliches Ziel ist die bessere Handhabbarkeit von Komplexität durch Abstraktion. Mit den Modellierungssprachen soll Programmierung auf einer abstrakteren Ebene möglich werden, die klare Trennung von fachlichen und technischen Anteilen zielt auf eine bessere Wartbarkeit durch Trennung von Verantwortlichkeiten ab. Die abstraktere, technologieunabhängige Beschreibung von Schlüsselkonzepten mit eindeutigen Modellierungssprachen verspricht eine verbesserte Handhabbarkeit des Technologiewandels. Und nicht zuletzt soll eine verbesserte Interoperabilität durch Standardisierung erreicht werden.

Vorgehen

Die Idee der MDA geht davon aus, dass für die Konstruktion eines Softwaresystems ein einziges Modell für die Abbildung einer größeren, komplexeren Applikation zu unscharf und überladen ist. Bei den meisten „klassischen“ (UML)-Modellen sind geschäftsrelevante mit technischen Informationen vermischt, MDA unterteilt das Gesamtmodell in mehrere Schichten:

• Computation Independent Model (CIM) für die umgangssprachliche Beschreibung
• Platform Independent Model (PIM), plattformunabhängiges Modell für Geschäftsprozesse
• Platform Specific Model (PSM), plattformabhängiges Modell für Architektur, Services
• ein Codemodell, die Zielplattform

Die Trennung der Modelle (separation of concerns) stellt eine inhaltliche Erweiterung des UML-Standards  dar. Insbesondere durch das CIM und vor allem das PIM möchte man nicht nur Plattformunabhängigkeit erreichen, sondern auch Sprach- und Systemunabhängigkeit.

MDA definiert neben der inhaltlichen Trennung der Modelle auch die Transformation der Modelle und unterscheidet zwei Typen:

• Die Modelltransformation von einem Modell in ein anderes Modell (siehe auch MOF QVT)
• Die Codetransformation von einem Modell in den Code.

Die Transformationen erzeugen aus den Elementen des Quellmodells die Elemente des Zielmodells. Die Transformation geschieht üblicherweise von der abstrakteren Ebene in die konkretere Ebene (CIM-PIM-PSM-Code). Dadurch kann aus einfacheren Modellelementen eine komplexere Anwendung erzeugt werden, indem erfahrene Architekten ihre Konstruktionsregeln in solche Transformationsprozesse einprogrammieren.

MDA ist eine Strategie der Object Management Group (OMG). Die OMG erstellt herstellerneutrale Spezifikationen zur Verbesserung der Interoperabilität und Portabilität von Softwaresystemen.

Vor- und Nachteile

Einer der wesentlichen Vorteile von MDA besteht darin, Systemdesigner und Softwareentwickler zu einer sorgfältigeren Konzeption der zu erstellenden Programme in der Entwurfsphase anzuhalten, was bei sehr komplexer Software, insbesondere bei der Erstellung von Standardsoftware, von großer Wichtigkeit ist.

Nachteilig ist der sehr hohe Abstraktionsgrad, der den Softwareentwicklern abverlangt wird. Bei kleineren oder weniger komplexen Anwendungen, z. B. bei Datenbankanwendungen als Individuallösung zur Unterstützung typischer Verwaltungsabläufe, wird der Aufwand einer abstrakten Definition aller Objekte und Prozesse oft als unangemessen hoch empfunden. Mit demselben Zeitaufwand lässt sich bei einigen alternativen Softwaretechnologien bereits die Software selbst erstellen. Durch die formalisierte strikte Trennung der Modellebenen wird auch die Steigerung der Produktivität durch Einsatz von Modellen mit gemischtem fachlichem und technischem Inhalt verhindert.

Des Weiteren erfordert eine automatisierte Transformation eines Modells häufig eine wesentlich formalere Beschreibung, als dies für die Transformation durch einen Menschen erforderlich ist. Beispielsweise sei eine Klasse Person mit dem Attribut geborenAm gegeben. Ein Programmierer braucht keine besonders detaillierte Beschreibung, um die Funktion gibAlterInJahren zu implementieren. Für eine automatische Transformation (zu Quellcode oder in ein anderes Modell) muss jedoch eine genaue Spezifikation vorliegen.

Vorteilhaft ist, dass Änderungen an der Anwendung im Modell vorgenommen werden. Diese werden durch eine erneute Codegenerierung in den Quellcode übernommen. Somit wird das Auseinanderlaufen von Modell und Code unterbunden. Insbesondere ein wild hacking, bei dem Änderungen im Quellcode nicht in das ursprünglich zugrunde liegende Modell übernommen werden und somit das Modell mit der Zeit fehlerhaft und letztendlich unbrauchbar wird, wird vermieden. Daraus ergibt sich, dass gerade der MDA-Ansatz optimal für ein iterativ-inkrementelles Vorgehensmodell geeignet ist und keineswegs einen Wasserfallansatz unterstützt oder gar fordert.

Beim Einsatz generischer Modellierungssprachen wie UML muss außerdem klar definiert sein, durch welche Elemente und mit welchen Mitteln der Modellierungssprache fachliche Sachverhalte zu beschreiben sind, damit ein im Sinne der folgenden Transformationen valides Modell entsteht. Diese Abbildung führt oft mehr neue Komplexität ein, als durch die Abstraktion verborgen wird. Der Einsatz domänenspezifischer Sprachen kann hier deutliche Vorteile bringen.

MDA-Konzepte im Überblick

Modell

Ein Modell ist eine abstrakte Repräsentation von Struktur, Funktion oder Verhalten eines Systems.

MDA-Modelle werden in der Regel in UML definiert. Aber auch klassische Programmiersprachen eignen sich als Modellierungssprachen. Ihre Programme sind MDA-Modelle. Diese sind wiederum unabhängig von der darunter liegenden Plattform (Bytecode-, Maschinencode und API).

Nicht jede Sammlung von UML-Diagrammen stellt ein Modell im Sinn von MDA dar. Der wichtigste Unterschied zwischen allgemeinen UML-Diagrammen (z. B. Analyse-Modellen) und MDA-Modellen liegt darin, dass die Bedeutung von MDA-Modellen formal definiert ist. Dies wird durch die Verwendung einer formal eindeutigen Modellierungssprache sichergestellt, die in einem UML-Profil (s. u.) festgelegt wird. Ein Generator muss genügend Informationen vorfinden, um das MDA-Modell auf ein anderes Modell oder auf Sourcecode abbilden bzw. transformieren zu können.

Plattform

MDA sagt (zunächst) nichts über den Abstraktionsgrad von Plattformen aus. Plattformen können aufeinander aufbauen.

Beispielsweise ist Intel PC eine Plattform für Linux. CORBA, Jakarta EE oder Webservices sind mögliche Plattformen für ein eBusiness-System, und C++ ist eine mögliche Plattform für CORBA. Auch eine wohldefinierte Anwendungsarchitektur mit dazugehörigem Laufzeitsystem kann eine Plattform für Applikationen sein.

UML-Profile

Ein UML-Profil ist die Erweiterung des Standard-UML-Sprachumfanges zur Bildung einer spezifischeren Designsprache unter Anwendung der in UML vorgesehenen Erweiterungsmechanismen (Stereotype, TaggedValues, Constraints, Custom Icons). Die im UML-Metamodell vorgegebenen Meta-Typen werden durch Anwendung der Erweiterungsmechanismen weiter spezialisiert.

Die in UML-Profilen definierten spezifischeren Designsprachen werden insbesondere benötigt, um domänen- oder plattformspezifische Semantiken abbilden zu können.

Während die Einführung neuer Konzepte durch Profile relativ gut unterstützt ist, lassen sich vorhandene Konzepte mit diesem Mechanismus nur schlecht ausblenden, was insbesondere bei der Modellierung mit Standard-UML-Tools leicht zu Missverständnissen führen kann.

Siehe auch

• Vorgehensmodell zur Softwareentwicklung
• Generative Programmierung
• Universal Binary

Weblinks

• OMG Model Driven Architecture
• Einführung zu MDA mit Begriffserklärungen
• Model Driven Architecture – Eine Einführung
• Berichte über diverse Tools, die den MDA-Ansatz beherzigen