Grundlegende Konzepte und Einordnung der Model Driven Architecture (MDA)

Model Driven Architecture

Peter Roßbach, Thomas Stahl, Wolfgang Neuhaus
Ziele und Potenziale

MDA ist ein junger Standard der Object Management Group (OMG), welche 1989 gegründet wurde und heutzutage ein offenes Konsortium aus ca. 800 Firmen weltweit ist. Die OMG erstellt herstellerneutrale Spezifikationen zur Verbesserung der Interoperabilität und Portabilität von Softwaresystemen. Bekannte Ergebnisse sind CORBA (Common Object Request Broker Architecture), IDL, UML (Unified Modeling Language), XMI oder MOF (Meta Object Facility). Das neue Flaggschiff der OMG heißt MDA [1]. Mit MDA soll eine erhebliche Steigerung der Entwicklungsgeschwindigkeit erreicht werden. Das Mittel dazu heißt Automation durch Formalisierung. Aus formal eindeutigen Modellen soll durch Generatoren automatisch Code erzeugt werden. Durch den Einsatz der Generatoren und die formal eindeutig definierten Modellierungssprachen soll darüber hinaus die Softwarequalität gesteigert werden. Fehler in den generierten Codeanteilen können an einer Stelle – in den Generatorschablonen – beseitigt werden. Die Qualität des generierten Sourcecodes ist gleichbleibend, was zu einem höheren Grad der Wiederverwendung führen soll.

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.

Grundsätzlicher Ansatz

Mit welchem Ansatz will die OMG diese hehren Ziele erreichen? Fachliche Spezifikationen werden in pattformunabhängigen Modellen (PIM = Platform Independent Model) definiert. Dazu wird eine formal eindeutige Modellierungssprache – eine erweiterte UML-Notation (UML Profil) – verwendet. Die damit spezifizierte Fachlichkeit ist vollständig unabhängig von der späteren Zielplattform. Plattformen können zum Beispiel CORBA, J2EE oder .NET sein. Durch eine in der Regel mit Werkzeugen automatisierte Modelltransformation werden aus den plattformunabhängigen fachlichen Spezifikationen plattformabhängige Modelle (PSM = Platform Specific Model) gewonnen. Diese plattformabhängigen Modelle enthalten die spezifischen Konzepte der Zielplattform. Mit einer weiteren werkzeugunterstützten Transformation auf der Basis eines PSM wird dann für eine konkrete Zielplattform die Implementierung gewonnen (Abb. 1). Die Vision der OMG geht allerdings noch einen Schritt weiter: Plattformspezifische Modelle sollen ausführbar werden, sodass die Code-Generierung vollständig entfallen würde. Dazu müssten Compiler oder Interpreter für Plattformen existieren, die plattformspezifische Modelle ausführbar machen. Solche Compiler oder Interpreter sind heute nur in Nischenbereichen vorhanden bzw. in der Diskussion, wie beispielsweise bei der Entwicklung von Embedded-Systemen [2], [3].

Abb. 1: MDA Grundprinzip

Wichtig: PIM und PSM sind immer relativ zu einer Plattform definiert. Damit kann ein Modell beispielsweise spezifisch für die Plattform J2EE sein, jedoch unabhängig von der Plattform BEA Weblogic Server.

Abb. 2: Ausschnitt aus einem PIM

In Abpictureung 2 ist ein kleiner Ausschnitt aus einem PIM (Platform Independent Model) zu sehen. Dargestellt ist ein Klassenmodell mit zwei fachlichen Klassen: Customer und Account. Beide Klassen sind mit dem Stereotyp > ausgezeichnet. Weiterhin besitzen beide ein Attribut, das mit dem Stereotyp > ausgezeichnet ist. Zusätzlich finden wir beim Customer noch eine Methode findByLastName, die mit dem Stereotyp > versehen ist. Die Erweiterung des Standardsprachumfangs der UML durch Stereotypen ist ein Standardmechanismus, der zu diesem Zweck von der OMG spezifiziert wurde. Hier wird er genutzt, um eine formal eindeutige Modellierungssprache zu definieren. Erst diese Eindeutigkeit macht ein UML-Modell zu einem MDA-Modell. Die im PIM verwendeten Konzepte >, > und > sind vollständig unabhängig von der Zielplattform. Diese Abhängigkeit entsteht erst durch die Transformation des PIM auf das PSM. Hier finden wir die für J2EE spezifischen Konzepte >, > und >. Durch die dann folgende Transformation wird aus dem PSM letztlich Sourcecode, in dem sich die aufgeführten Konzepte dann in ihrer konkreten Ausprägung wiederfinden.

MDA Konzepte im Überblick

Model: 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 sind MDA-Modellierungssprachen. Ihre Programme sind MDA-Modelle. Diese sind wiederum unabhängig von der darunter liegenden Plattform – beispielsweise Bytecode oder Maschinencode. UML-Diagramme sind jedoch nicht per se MDA-Modelle. 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 sicher gestellt, die in einem UML-Profil (s.u.) festgelegt wird. Damit wird erreicht, dass das erzeugte Modell eindeutig durch Generatoren auf ein anderes Modell oder auf Sourcecode abgepictureet bzw. tranformiert werden kann.
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, J2EE oder Web Services 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: UML-Profile sind der Standardmechanismus zur Erweiterung des Sprachumfangs der UML. Sie enthalten Sprachkonzepte, die über Basis-UML-Konstrukte wie Klassen und Assoziationen, Stereotypen, Tagged Values und Modellierungsregeln (Constraints) festgelegt werden (Abb. 3).

Abb. 3: Verwendung eines UML-Profils

Definiert wird ein UML-Profil als Erweiterung des UML-Metamodells. Dieser Zusammenhang wird in Abpictureung 4 anhand eines vereinfachten Beispiels “ ein UML-Profil für Enterprise JavaBeans (EJB) “ verdeutlicht.

Abb. 4: UML-Metamodell und UML-Profil für EJB (Ausschnitt)

Die Standard-UML-Konzepte Attribute, Class und Operation werden im UML-Profil um die spezifischen Konzepte PrimaryKeyField, EJBEntityBean und EJBFinderMethod erweitert. Zusätzliche Erweiterungen werden durch Tagged Values und Modellierungsrichtlinien in Form von Constraints definiert. UML-Profile sind also Metamodelle und definieren formale Modellierungssprachen als Erweiterung der UML.
PIM und PSM: Die Trennung von Platform Independent Model (PIM) und Platform Specific Model (PSM) ist ein Schlüsselkonzept von MDA im Sinne der OMG. Der Hintergrund: Konzepte sind stabiler als Technologien und formale Modelle besitzen Potenzial für automatisierte Transformationen Das PIM abstrahiert von technologischen Details, während das PSM die Konzepte einer Plattform verwendet, um ein System zu beschreiben (Abb. 5). Der Rückweg – die Gewinnung eines PIMs aus einem PSM ist kaum automatisierbar. Dieser Weg erfordert manuelle, intellektuelle Arbeit in Form eines Refactorings, da mit dem PIM eine echte Abstraktion erreicht wird. Somit legt MDA einen Forward Engineering Prozess nahe und toolunterstütztes Roundtrip Engineering ist kaum möglich.

Abb. 3: Zusammenhang PIM “ PSM “ Plattform

Transformationen: Transformationen pictureen Modelle auf die jeweils nächste Ebene, weitere Modelle oder Sourcecode ab. Im Sinne von MDA müssen Transformationen flexibel und formal auf Basis eines gegebenen Profils definiert werden können. Dies ist eine Voraussetzung für die gewünschte Automatisierung der Transformation über Generatoren. Zur Zeit existiert allerdings noch keine OMG-Spezifikation für eine einheitliche Transformationssprache. Es liegt jedoch ein Request für Proposal dazu vor (MOF 2.0 Query/Views/Transformations RFP, OMG Document ad/2002-04-10). Darin soll eine Transformation zwischen Metamodellen beschrieben werden. Metamodelle können in UML-Profilen definiert sein. Nehmen wir an, uns läge ein UML-Profil für EJB und ein UML-Profil für Bea WebLogic Server vor. Die Transformation würde dann eine Abpictureung zwischen den Modellierungssprachen in diesen beiden UML-Profilen beschreiben. Als Resultat könnten dann Modelle aus der einen Modellierungssprache in die andere überführt werden.

Heutige Generatoren lösen dieses Problem auf andere Weise, indem sie proprietäre Transformationssprachen verwenden. Hier kommen beispielsweise jPhyton, TCL, JSP, XSLT oder zweckoptimierten Skriptsprachen zum Einsatz. Die mit diesen Sprachen definierten Generatorschablonen funktionieren nach dem Prinzip von Makros und verwenden die Modelle als Eingabeparameter. Derzeit ist demzufolge (noch) keine Interoperabilität für Modell-Transformationen gegeben.

Abgrenzung und Einordnung

An dieser Stelle fragen Sie sich möglicherweise, wo denn nun der bahnbrechende Unterschied zu bisherigen Ansätzen der Code-Generierung liegt. Daher hier eine kurze Abgrenzung: MDA ist kein CASE-Ansatz. Klassische CASE-Tools zeichnen sich dadurch aus, dass häufig sowohl Metamodell wie auch Transformation fix sind. Darüber hinaus besitzen sie in der Regel proprietäre Modellierungssprachen. Damit fehlt die angestrebte Interoperabilität und insbesondere lassen sich Modellierungssprache und der generierte Anteil nicht auf projektspezifische Bedürfnisse anpassen.

MDA ist keine 4GL. Ähnlich wie bei den CASE-Tools sind bei den 4GL-Tools häufig Transformation und Metamodell fest. Zusätzlich beruhen sie auf festen Laufzeitsystemen, die durch den Entwickler nicht modifiziert werden können. MDA macht hier dem gegenüber keine Einschränkungen.
Und MDA ist kein Code-Wizard oder Pattern-Expander. Jeder kennt sie: Die nützlichen Code-Wizards in Entwicklungsumgebungen oder die Pattern Expansion in den UML-Tools. Sie erlauben die automatische Erzeugung eines Klassenrumpfes beispielsweise eines Entity Beans bzw. die Erzeugung mehrerer Klassenrümpfe bei der Pattern Expansion. Dieser Schritt ist im Unterschied zu MDA jedoch einmalig. Die mit MDA erreichbare wiederholte Generierung bei Erhaltung der vorgenommenen Individualisierungen fehlt. Außerdem geht die Abstraktion verloren, die mit MDA im Modell vorgenommen wird.

Praktische Interpretation

Soweit die reine OMG Lehre. Damit MDA praktisch anwendbar wird, muss man diesen jungen OMG-Standard allerdings in geeigneter Weise interpretieren und entsprechende Werkzeuge einsetzen, die zu der Interpretation passen. Heute existieren im Markt unterschiedliche Interpretationen, sowohl den MDA/D-Prozess wie auch die dazu gehörigen Werkzeuge betreffend. Die weiteren Artikel zum MDA-Titelthema vertiefen eine mögliche Interpretation, die durch die Mitglieder der Arbeitsgemeinschaft Architecture Management Group [4] diskutiert und unterstützt wird. Als Richtschnur dazu dient der Generative Development Process GDP [5]. Dieser Prozessleitfaden ist aus der Praxis zahlreicher MDA-Projekte bei der b+m Informatik AG [6] entstanden und berücksichtigt die besonderen Bedürfnisse beim praktischen Einsatz von MDA.

Der erste Artikel wird dazu den GDP und die im Prozess benötigten Rollen beschreiben [7]. Der zweite Artikel beschäftigt sich mit der frühen Phase in einem MDA-Projekt – dem Übergang zwischen Geschäftsprozessmodellierung und objektorientierter Analyse. Hier erfahren Sie, welche Möglichkeiten durch den Einsatz der UML-Notation zur Geschäftsprozessmodellierung erschlossen werden können und wie dies in MDA-Projekten genutzt werden kann [8]. Der dritte Artikel betrachtet die besonderen Aspekte aus der Entwicklersicht [9]. In der nächsten Ausgabe des Java Magazins beleuchten wir dann ein MDA-Projekt aus Architektursicht, denn wie der Name Model Driven Architect schon vermuten lässt, kommt der Architektur eine besondere Bedeutung zu [10]. Und schließlich nimmt ein fünfter Artikel zum Themenkomplex MDA eine Einordnung in weitere generative und generische Techniken vor [11].

  • [1] MDA Specifications, 2003, www.omg.org/mda/
  • [2], Statemate – ausführbare UML Diagramme für Embedded Systems, 2003, www.ilogix.com/products/magnum/index.cfm
  • [3], M. Völter: A Generative Component Infrastructure for Embedded Systems, 2003, www.voelter.de/data/pub/SmallComponents.pdf
  • [4] Achitecture Management Group: www.a-m-group.de/
  • [5] Generative Development Process,2003, www.architectureware.de/
  • [6] b+m Informatik AG: www.bmiag.de/
  • [7], W. Neuhaus, C. Robitzki: MDA/D – Eine praktische Interpretation, Java Magazin 9.2003
  • [8], T. Weilkiens: Vom Geschäftsprozess zum Code – ein kurzer Weg mit MDA, Java Magazin 9.2003
  • [9], M. Schepe, W. Neuhaus, P. Roßbach: Model Driven Developer, Java Magazin 9.2003
  • [10], T. Stahl, M. Schepe, C. Robitzki: Model Driven Architect, Java Magazin (noch nicht veröffentlicht)
  • [11], M. Völter: Codegenerierung – Ein Überblick, Java Magazin (noch nicht veröffentlicht)
Geschrieben von
Peter Roßbach, Thomas Stahl, Wolfgang Neuhaus
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.