MDA - Model Driven Architecture

Christian Ranz

Zusammenfassung
Diese Ausarbeitung stellt den Grundgedanken sowie die grundlegenden Konzep-
te der Model Driven Architecture (MDA) vor. Die MDA ist ein Standard der Object
Management Group (OMG). MDA ist ein neuer Schritt in Richtung Abstraktion
und Formalisierung des Softwareentwicklungsprozesses. Sie verspricht Applikatio-
nen aus Plattform unabhängigen Modellen automatisch zu generieren. Da der MDA
Standard noch relativ neu ist, gibt es einige zum Teil sehr unterschiedliche Inter-
pretationsansätze. In der Fachpresse wird der MDA für die Zukunft ein sehr hoher
Stellenwert zugeschrieben.

1 Einleitung
Die folgende Arbeit entstand im Rahmen des UML Proseminars im Sommersemester
2008 an der Universität Ulm. Dieses Proseminar beschäftigt sich mit den Grundkonzep-
ten der UML. Die Model Driven Architecture kann allerdings nicht als Unterbegriff der
UML verstanden werden, sondern ist ein eigenes Konzept, welches von der OMG spe-
zifiziert wurde. UML ist vielmehr ein Werkzeug, welches im MDA Entwicklungsprozess
benötigt wird. MDA ist eine von der OMG spezifizierte Verwirklichung des Model Driven
Development (MDD), welches aber im Gegensatz zur MDA genauere Aussagen über die
Vorgehensweise beim Entwicklungsprozess macht. MDA ist ein Konzept zur Software-
entwicklung, in dem wie der Name schon sagt, Modelle im Mittelpunkt stehen. In der
Fachpresse wird MDA als ein weiterer bahnbrechender Abstraktionsschritt gewertet und
mit dem Sprung von Assembler zu Hochsprache gleichgesetzt. MDA wird von der OMG
als ”The Architecture of Choice for a Changing World”[Gro07] bezeichnet.
Die OMG ist ein offenes Konsortium aus weltweit ca. 800 Firmen. Sie wurde 1989 ge-
gründet und verfasst herstellerneutrale Spezifikationen zur Verbesserung der Interopera-
bilität und Portabilität von Softwaresystemen.

1.1 Motivation
Moderne Softwaresysteme werden immer größer und komplexer. Dadurch wird es im-
mer schwieriger diese zu überschauen und zu planen. Weiterhin fehlen momentan noch
die geeigneten Mittel um Prozesse in der Softwareentwicklung zu automatisieren, was

1
zu extrem hohen Entwicklungskosten führt. Die Produktivität bei der Entwicklung von
Softwaresystemen befindet sich momentan auf einem noch sehr niedrigen Niveau.
Als Gründe hierfür nennt [Wei04] zum Beispiel, dass Code eine zu niedrige Abstraktions-
ebene besitzt. In einem ausimplementierten Programmcode ist das eigentlich umgesetze
Modell nicht mehr, oder nur schwer, rekonstruierbar. Das Domänenwissen ist über mehre-
re Quelldateien verteilt und mit plattformspezifischen Details, die nicht zum Verständnis
beitragen, vermischt. Dieses Problem lässt sich nur mit einer weiteren Abstraktionse-
be beheben, in der nicht auf programmier- und plattformspezifische Eigenheiten und
Details eingegangen wird. Anhand der Gegenüberstellung eines Klassendiagramms (Ab-
bildung 1) und des aus ihm erstellten Programmcode (Listing 1.1) wird dies verdeutlicht.
Im Klassendiagramm können die Zusammenhänge auf einen Blick erfasst werden und die
vermittelten Informationen beschränken sich auf das Wesentliche. Im Programmcode hin-
gegen, wird durch programmiersprachenspezifische Details sehr stark von den eigentlichen
Zusammenhängen abgelenkt.

Abbildung 1: Ausschnitt eines Klassendiagramms eines Tempomats

Listing 1: Programmcode zum obigen Klassendiagramm

class Umdrehungsmesser {
private int umdrehungen ;
public Umdrehungsmesser () {}
public void startZaehlen () {}
public int stoppZaehlen () {}
}
class Tempomat {
private Umdrehungsmesser umdrehungsmesser ;
private float u md r e hu n g en P r oM e t er ;
private float s ol l G es c h wi n d ig k e it ;
private double umdrehungen ;
private static Tempomat tempomat ;

private Tempomat ( Umdrehungsmesser messer ) {}

public static Tempomat Instance ( Umdrehungsmesser messer ) {}
public bool s e t S o l l G e s c h w i n d i g k e i t ( float speed ) {}
public void startKalibrieren () {}
public void stoppKalibrieren () {}
}

2
Ein weiterer Grund sei, dass Programmspezifikationen sehr stark mit der Infrastruktur
verflochten sind. Die Technologien und Plattformen, auf denen Softwaresysteme aufbauen
sind heute in der Regel sehr kurzlebig. Sie unterliegen einem ständigen Entwicklungspro-
zess. In Abbildung 2 wird die Entwicklung von drei Grundlegenden Softwareplattformen
gezeigt. Das Model hingegen, d.h. der grundlegende Denkansatz und die Funktionsweise
der Software bleibt meist über einen längeren Zeitraum erhalten. Wenn sich nun aber die
Technologie ändert führt dies dazu, dass die Software auf die neue Technologie portiert
werden muss. Durch die starke Verflechtung des Domänenwissens mit den technologie-
abhängigen Details führt dies meist zu einer Neuentwicklung basierend auf der neuen
Technologie. Das “Rad” muss sozusagen nocheinmal neu erfunden werden.

Abbildung 2: Technologiewandel

Weiterhin werden die Business to Software Mappings“ nicht archiviert. Das heißt,
”
beim Design von Software entfernt man sich oft sehr schnell vom zu Beginn entworfe-
nen Modell. Dies ist bei einem normalem Vorgehen unumgänglich, da man die plattfor-
mabhängigen Eigenheiten bei der Implementierung nicht ausser Acht lassen kann. Dies
führt entweder zu einer Inkonsistenz zwischen der modellierten Architektur und dem
ausimplementierten Programmcode, oder das Modell geht ganz verloren. Es ist zwar im
entstandenen Code mit enthalten, jedoch so stark mit programmierspezifischen Details
vermischt, dass man nur durch ein extrem aufwändiges Re-Engeneering an das ursprüng-
liche Modell gelangt.
Dies weckt den Ruf nach einem Entwicklungsprozess, bei dem diese Probleme und Inkon-
sistenzen nicht auftreten oder zumindest eingeschränkt werden können.

1.2 Visionen und Ziele der MDA

Die OMG zielt mit der MDA darauf ab, eine wesentliche Effizienzsteigerung bei der Soft-
wareentwicklung zu erreichen. Dies soll dadurch erreicht werden, dass große Teile des
Softwareerstellungsprozesses automatisiert ablaufen. Das heißt, es sollen aus formal ein-
deutigen Modellen automatisch durch Generatoren weitere konkretere Modelle oder Code

3
erzeugt werden [PR03]. Dadurch erhofft man sich eine Steigerung der Softwarequalität,
um dann vor allem eine gleichbleibende, hohe Qualität zu erreichen. Eine gleichbleibende
Qualität hebt den Grad der Wiederverwendbarkeit.
Durch die höhere Abstraktionsebene, die mit MDA erreicht wird, kann mit einem evtl.
auftretenden Technologiewandel besser umgegangen werden. Dies wirkt sich auf die Wart-
barkeit und den Pflegeaufwand eines Softwaresystems positiv aus. Zusammenfassend kann
man sagen, dass das Ziel des MDA Entwicklungsprozesses ein voll funktionsfähiges Soft-
waresystem ist, in dem so wenig Programmcode wie möglich händisch geschrieben wurde.
In Fachbüchern wird von einem sinnvollen Anteil an Automatisierung gesprochen. Dieser
kann zwischen 20 und 80 Prozent liegen [KZ05].

2 Model Driven Architekture - MDA

2.1 Der MDA Entwicklungsprozess

Der MDA Entwicklungsprozess ist immer ein gerichteter Pfad von einer höheren Ab-
straktionsebene zu einer geringeren. Die Entwicklung wird beim Computation Indepen-
dent Model (CIM) begonnen. Zu diesem Zeitpunkt wird nur das reine Domönenwissen
in den Entwicklungsprozess aufgenommen. Dies ist noch von jeglichem Gedanken an eine
Zieltechnologie losgelöst. Es wird also nur definiert, wie sich das System aus Sicht des
Auftraggebers verhalten soll. Im nächsten Schritt wird das CIM, also das Domänenwis-
sen, mit Details angereichert, die aus einer abstrakten Zieltechnologie kommen. Es werden
also schon die grundlegenden programmierspezifischen Konzepte wie zum Beispiel Daten-
typen und Klassen mit in das Modell aufgenommen. Dieser Schritt führt zum Platform
Independent Model (PIM). Zu diesem Zeitpunkt muss allerdings noch eine Technologieu-
nabhängigkeit gegeben sein. Erst bei der Transformation des PIM in das Platform Specific
Model (PSM) werden die zuvor abstrakt beschriebenen Programmierkonzepte in die eine
konkreten Zieltechnologie übertragen. So wird beispielsweise aus dem im PIM definier-
ten Datentyp “String” nach der Transformation in das PSM ein “VARCHAR(MAX)”,
wenn das PSM eine Datenbankumgebung beschreiben soll. Diese Details kommen aus
dem Platform Model, welches die Zieltechnologie beschreibt. Aus dem PSM wird dann
mit Hilfe einer automatischen Transformation der Programmcode erzeugt. Dies sollte im
Idealfall so automatisiert ablaufen, dass kein Programmcode von Hand geschrieben wer-
den muss.
Aus einem CIM sollte genau ein PIM erzeugt werden können, d.h. diese Transforma-
tion sollte möglichst eindeutig sein. Erst nach dem PIM kann in mehrere verschiedene
PSMs transformiert werden, je nach dem auf welcher Zielplattform das System umgesetzt
werden soll. Die Transformation vom PSM zum Programmcode muss ebenfalls nicht ein-
deutig sein, da die Konzepte im PSM in der konkreten Implementierung unterschiedlich
umgesetzt werden können.

4
2.2 Modelle und Metamodelle

Abbildung 3: Modelle und Metamodelle [Wim05]

Modelle und Metamodelle spielen ein der MDA wie der Name schon sagt eine außeror-
dentlich wichtige Rolle. Nur durch sie ist es möglich eine derart große Abstraktion vom
Programmcode zu erreichen. Im Allgemeinen sind Modelle nicht nur zur Beschreibung
von Softwaresystemen sehr gut geeignet, jedoch gerade in diesem Bereich erleichtern sie
die Darstellung und Visualisierung von Problemen und Systemen erheblich. Ein Modell
ist eine sehr “menschenfreundliche” Darstellungsweise und erleichtert somit das verstehen
eines Systems. Somit können Fehler schneller erkannt werden oder Informationen über
das System schneller weitergegeben werden. Auch zu Dokumentationszwecken und zur
späteren Erweiterung von Systemen sind Modelle sehr hilfreich. Dies ist allerdings nur der
Fall, wenn die Modelle während des Entwicklungsprozesses konsistent gehalten werden.
Sie müssen immer genau das Zielsystem beschreiben und es darf nicht zu Inkonsisten-
zen zwischen Modellen in Unterschiedlichen abstraktionsebenen kommen. Für den MDA
Entwicklungsprozess ist dies sogar unumgänglich, da die Modelle das einzige und zentrale
Entwicklungswerkzeug sind. Weil in der MDA die Modelle automatisiert verarbeitet wer-
den, müssen sie mit einer wohldefinierten Sprache eindeutig definiert sein. Hierbei bieten
sich Sprachen wie die UML an, die zum Beispiel von der OMG standardisiert wurden.
Die oben genannten wohldefinierten Sprachen werden durch Metamodelle definiert. Meta-
modelle beschreiben Metasprachen. Metamodelle definieren ein Vokabular und gramma-
tische Regeln einer Modellierungssprache. Um Sprachen zu definieren stellt die OMG ein

5
weiteres Werkzeug zur Verfügung, mit dessen Hilfe auch die UML definiert wurde. Dieses
Werkzeug ist die Meta Object Facility (MOF). Mit der MOF können beliebige Mode-
lierungssprachen definiert werden. Metasprachen wie MOF dienen rein zur Beschreibung
anderer Modelle, wohingegen Modellsprachen wie UML Softwaresysteme beschreiben.
Plausibel wäre, dass es wieder Sprachen geben muss, die Metasprachen beschreiben. Dies
würde dann zu einer unendlichen Verkettung, sich beschreibender Sprachen führen. Die
OMG löst dieses Problem indem sie die MOF reflexiv, d.h. sich selbst erklärend definiert
hat [Wim05]. Dies verdeutlicht Abbildung 3.

2.2.1 Die Rolle von UML in der MDA

Die Unified Modelling Language (UML) ist ein sehr zentraler Punkt in der MDA. Durch
dieses Metamodell wird das Platform Independent Model und das Platform Specific Model
beschrieben. Da die UML jedoch nicht dafür entwickelt wurde, die durch sie beschriebenen
Modelle automatisiert in andere Metamodelle oder in Programmcode zu transformieren,
können mit ihr nicht alle für eine Transformation nötigen Details abgebildet werden. Das
führt dazu, dass die UML um die fehlenden Elemente und Semantiken erweitert werden
muss. Eine solche Erweiterung darf jedoch nicht einfach in ein UML Diagramm geschrie-
ben werden, sondern muss eindeutig definiert werden. Hierzu gibt es zwei Möglichkeiten.
Die Erweiterung der UML durch MOF, oder durch UML Profile. Beide dieser Ansätze
bieten die Möglichkeit die UML wohldefiniert zu erweitern.

2.2.2 UML Profile

Mit ULM Profilen wird die UML mit Hilfe der dafür vorgesehenen Möglichkeiten wie
Stereotypen, TaggedValues und Constraints erweitert. Hiermit sind Erweiterungen ohne
einen Eingriff in die Metasprache der UML möglich. Allerdings ist es kaum möglich be-
reits in der UML vorhandene Konzepte und Elemente wirksam auszublenden. Die OMG
stellt für viele Softwareplattformen bereits fertige genormte UML Profile bereit, wie zum
Beispiel für Java und EJB, CORBA, EDOC, usw. Der Vorteil bei UML Profilen liegt
darin, dass zur Definition nur UML eigene Notationen verwendet werden. Somit können
UML Modellierungswerkzeuge sehr gut mit UML Profilen umgehen. UML Profile wer-
den immer als Paket mit dem Schlüsselwort profiledefiniert. Ein vereinfachtes Beispiel
hierfür ist die Definition des EJB Profils in Abbildung 4.

6
 Abbildung 4: UML Profil für EJB [Thi06]

2.2.3 MOF - Meta Object Facility

In diesem Abschnitt wird der Metamodellierungsansatz der OMG Meta Object Facility
näher betrachtet. Genau genommen kann man die UML mit MOF nicht erweitern son-
dern auf einer höheren Ebene neu definieren. Dies führt meist zu Problemen mit UML
Modellierungswerkzeugen, da diese, die neu definierte Metasprache nicht kennen. Um
dies zu verstehen, sollte das Grundprinzip von MOF zuerst geklärt werden. Durch die
Reflexivität hat die OMG MOF auf 4 Metastufen beschränkt. Das heißt, die letzte Stufe
ist selbstbeschreibend. Die unterste Stufe bildet die M0 Ebene. Sie stellt das laufende
System dar und beinhaltet konkrete Objekte. Die darüberliegende Stufe ist die M1 Ebe-
ne. Auf dieser Stufe befindet sich das Systemmodell d.h. das UML Modell mit Klassen,
Attributen, Operationen,... . Die Konzepte der M1 Ebene beschreiben Elemente auf der
M0 Ebene. Alle Elemente der M0 Ebene sind somit Instanzen der M1 Ebene. Auf der M0
Ebene dürfen keine nicht in der M1 Ebene definierten Elemente existieren. Die Beziehung
zwischen der M0 und M1 Ebene wird aufsteigend mit instanceOfbeschrieben. Auf der
nächst höheren Ebene, der M2 Ebene, sind die Modellelemente der M1 Ebene definiert.
Die Elemente der M1 Ebene sind Instanzen der M2 Ebene. Hier werden Konzepte defi-
niert, die für die Beschreibung der M1 Ebene benötigt werden, wie zum Beispiel Class,
Attribute. Die Beziehung zwischen M1 und M2 Ebene wird genau wie eine Ebene darun-
ter mit instanceOfbeschrieben. Die M2 Ebene wird auch Metamodellebene genannt,
da in dieser Ebene Modellierungssprachen definiert werden [Wim05]. Auf der höchsten
Ebene, der M3 Ebene, wird die Definition der Modellelemente definiert. Hier sind wieder
die Elemente der darunterliegenden M2 Ebene Instanzen der Elemente auf M3 Ebene.
Typische Elemente dieser Ebene wären zum Beispiel eine MOF class. Diese Ebene ist
selbstbeschreibend [Thi06]. Die Hierarchien von MOV werden in Abbildung 5 grafisch

7
dargestellt.
Um nun die UML für die eigenen Anforderungen anzupassen, muss nur die M2 Ebene
verändert werden. Dies stellt allerdings einen Eingriff in die Definition der UML dar.
Somit kann die so neu definierte Metasprache nicht mehr als UML bezeichnet werden.
Genau hier liegt der Vorteil von UML Profilen, bei ihrer Definition wird nicht in das
Metamodell der UML eingegriffen und die Erweiterung bleibt somit UML konform.

Abbildung 5: Übersicht über die MOF Ebenen [Thi06]

8
2.3 MDA Konzepte
Im folgenden Abschnitt werden die grundlegenden Konzepte wie Computation Indepen-
dent Model, Platform Model, Platform Independent Model und Platform Specific Model
[MDA Guide] beschrieben, auf denen die Model Driven Architecture aufbaut. Ein weite-
res sehr wichtiges Konzept in der MDA sind die Transformationen mit denen die Modelle
untereinander, von einer höheren Abstraktionsebene zu einer niedrigeren, oder zu realem
Code transformiert werden können.

2.3.1 Computation Independent Model

Als CIM wird ein Modell bezeichnet, dass völlig von dem Gedanken gelöst ist, dass
das von ihm abgebildete System später von einem Computer verarbeitet wird, es ist
also frei von jeglichen technischen Aspekten. Mit ihm wird die Domänenschicht des zu
entwickelnden Softwaresystems modelliert. Im MDA Entwicklungsprozess ist das CIM
der erste Schritt und hat die höchste Abstraktionsebene. Das CIM bildet die Basis für
alle im MDA Entwicklungsprozess nachfolgenden Modelle.

2.3.2 Platform Independent Model

Das Platform Independent Model (PIM) ist wie das CIM noch unabhängig von der späte-
ren Zieltechnologie. Allerdings beschreibt das PIM im Gegensatz zum CIM schon ein
konkretes Softwaresystem. Das PIM ist das letzte Modell im MDA Entwicklungsprozess,
welches noch auf jede beliebige Plattform abgebildet werden kann. Es ist der zentrale
Schritt in der MDA, da nach dem PIM der Softwareentwicklungsprozess weitestgehend
automatisiert ablaufen sollte. Die Modellierung des PIM erfolgt mit Hilfe der UML. Al-
lerdings reichen die in der UML spezifizierten Notationen meist nicht aus, da die Objekte
für eine automatischen Weiterverarbeitung genauer spezifiziert werden müssen. So muss
das PIM mit Hilfe einer durch UML Profile oder MOF erweiterten UML beschrieben
werden. Die hinzugefügten Erweiterungen kennzeichnen zum Beispiel UML Klassen als
Entitäten oder Schnittstellen. Diese Erweiterungen sind in den Zielplattformen realisiert,
müssen jedoch im PIM noch plattformunabhängig definiert sein.

2.3.3 Platform Model

Der nächste Schritt ist nun, das PIM in den Kontext einer gewissen Zieltechnologie zu
setzen. dazu ist es notwendig, die Zieltechnologie zu kennen. Genau dies übernimmt das
Platform Model. Es beschreibt die Zieltechnologie, in die das PIM überführt werden soll
und stellt die Objekte, die für das Plattform Specific Model benötigt werden bereit.

2.3.4 Platform Specific Model

Das PSM stellt im MDA Prozess das erste Modell dar, welches nicht mehr von der Ziel-
technologie abstrahiert ist. Es vermischt das im PIM spezifizierte Modell mit den im PM

9
definierten technologischen Details. Dadurch verliert es seine Plattformunabhängigkeit.
Im Idealfall sollte die Transformation des PIM in das PSM automatisch durchgeführt
werden. Dies übernimmt ein Generator, der die in PIM enthaltenen plattformunabhängi-
gen Details mit Hilfe des PM in die Konzepte der Zielplattform transformiert.
In Abbilding 6 wird der Weg vom PIM bis zum Code anhand eines Beispiels demonstriert.

Abbildung 6: MDA Beispielprojekt [Wim05]

2.3.5 Transformationen
Um von einer Modell-Ebene zur anderen zu gelangen verwendet man sogenannte Trans-
formationen. Diese sind sowohl Herzstück, als auch das größte Problem in der MDA.
Das Hauptproblem der Transformationen liegt darin, dass die verschiedene Modelle auf
unterschiedlichen Abstraktionsebenen liegen. Somit haben sie eine unterschiedliche Se-
mantik, so kann man dem Datentyp “String” im PIM zum Beispiel nicht entnehmen,
welche Länge der Zieldatentyp “VARCHAR” haben soll [Som07]. Die Grundsemantik,
ist bei Quellmodell und Zielmodell immer die selbe, da es sonst zu Inkonsistenzen zwi-
schen den Modellen kommt. Der geringere Informationsgehalt des Quellmodells führt bei
der Transformation in ein darunterliegendes Modell zum Problemen. Zur Lösung dieses
Problems schlägt die OMG fünf verschidenen Ansätze vor: das sog. Marking, Metamodel

10
Transformation, Model Transformation, Pattern Application und Model Merging [Gro03].
Die Ansätze Marking, Metamodel Transformation und Model Transformation werde ich
an dieser Stelle näher erläutern.
Um die folgenden Ansätze besser verstehen zu können sollte der Begriff Transformations-
regel zuerst noch geklärt werden. Eine Transformationsregel beschreibt wie Elemente aus
dem Quellmodell in Elemente des Zielmodels übersetzt werden. Eine Transformetionsre-
gel besteht aus zwei Teilen, der right-hand Seite (RHS) und der left-hand Seite (LHS). Die
LHS greift auf das Quellmodel zu, welches die RHS in das Zielmodell ausweitet [dH08].

Marking Der Prozess der “Markings”, welcher in Abbildung 7 gezeigt wird, läuft fol-
gendermaßen ab. Zuerst werden diejenigen Modellelemente im Quellmodell ausgewählt
(markiert), die auf spezielle Konzepte der Zielplattform abgebildet werden sollen. Eine
solche Markierung stellt ein plattformspezifisches Konzept dar. Sie wird zu den Elemen-
ten im Quellmodell annotiert und beschreibt, wie diese Elemente übersetzt werden. Somit
enthalten Markierungen plattformspezifische Details, die aber im plattfomunabhängigen
Modell nicht erscheinen sollen [Wim05]. Hierzu wird eine Zwischenstufe eingefügt. Ein
“Marked PIM”(Abbildung 7). Das Mapping beschreibt wie die markierten Konzepte in
die Zielplattform übertragen werden. Dieses Mapping hängt von der Plattform ab.

Abbildung 7: Marking eines Modells [Gro03]

Metamodel Transformation Die Metamodel Transformation läuft auf ähnliche Wei-

se wie das Marking ab. Der Prozess der Metamodel Transformation wird in Abbildung
8 dargestellt. Das PIM wird mit der Sprache des Platform Independent Metamodels
dargestellt. Das PSM hingegen in der Sprache des Platform Specific Metamodels. Um
nun das PIM in das PSM zu transformieren, muss ein Mapping zwischen dieses beiden

11
Metamodelsprachen hergestellt werden [dH08]. Dieses Mapping bildet die Transforma-
tion Specification, welche beschreibt wie die Konzepte des Quellmetamodells in die des
Zielmetamodells abgebildet werden.

Abbildung 8: Metamodell Transformation [Gro03]

Model Transformation Bei der Model Transformation sind alle Elemente des Quellm-
odels Subtypen der im “Plattform Independent Type Model” definierten Typen und alle
Elemente des Zielmodels Subtypen der im “Plattform Dependent Type Model” definierten
Typen. Die Transformationsregeln bilden einen plattformunabhängigen Typ auf Meta-
modellebene direkt auf einen oder mehrere plattformabhängige Typen ab. Die LHS einer
Regel wählt einen plattformunabhängigen Typ aus und die RHS einen plattformabhängi-
gen. Die Komplexität dieser Transformation ist relativ einfach, wenn jedem Typen im
Quellmodell genau ein Typ im Zielmodell zugewiesen werden kann. Genau dann ist die
Transformation auch bidirektional [dH08].

12
 Abbildung 9: Modell Transformation [Gro03]

3 Zusammenfassung und differenzierte Betrachtung

Der von der OMG spezifizierte Standard MDA ist zweifellos ein bedeutender Schritt in
der Softwareentwicklung. Jedoch ist man von der tatsächlichen praktischen Anwendung,
im Sinne, dass der lauffähige Programmode völlig automatisiert erzeugt wird noch weit
entfernt. Wenn man allerdings davon ausgeht, dass die MDA den Entwickler nur un-
terstützen soll, wie das zum Beispiel der “Elaborationist” Ansatz (s. unten) vorsieht,
sind die momentan verfügbaren Tools schon durchaus praktikabel. Die OMG gibt aber
keinerlei Empfehlungen hinsichtlich der Verwendung von Tools und Entwicklungsumge-
bungen. Es bleibt der Industrie überlassen sich den bestmöglichen Weg zu suchen. So
gibt es zum Beispiel zwei Interpretationsansätze für die MDA. Der “Elaborationist” und
der “Translationist” Ansatz. Diese beiden Ansätze werden im Paper “MDA: The Vision
with the Hole?” [McN03] gegenübergestellt. Die Unterschiede kann man sehr deutlich
erkennen, wenn man die zwei Konzepte wie in Abbildung 10 gegenüberstellt.

13
 Abbildung 10: Elaborationist vs. Translationist [McN03]

Elaborationist Beim “Elaborationist” Ansatz, Abbildung 10 (links), wird zuerst das

PIM von Hand erstellt. Aus diesem wird dann mit Hilfe einer automatischen Transfor-
mation eine Art Grundgerüst des PSM erzeugt. Dieses wird dann durch den Entwickler
mit weiteren Informationen ergänzt. Der Schritt vom PSM zum Programmcode erfolgt
auf die gleiche Art und Weise. Aus dem PSM wrid wieder automatisch ein Codegerüst
erzeugt, welches dann händisch ergänzt wird. Diese Vorgehensweise kann dazu führen,
dass es zwischen dem Modell auf einer niedrigeren Ebene und dem Ausgangsmodell zu
Inkonsistenzen kommt. Daher muss das Modell auf der höheren Ebene aus dem Modell
der darunterliegenden Ebene neu erzeugt werden (round-trip Engeneering), wie in Abbil-
dung 10 (links) zu sehen ist. Bei diesem Ansatz muss das automatisch erzeugte Modell
bzw. der automatisch erzeugte Programmcode von Menschen lesbar sein. Wenn dies nicht
gegeben ist, kann der Entwickler das PSM bzw. den Programmcode nicht ergänzen. Der
“Elaborationist” Ansatz hat eine sehr große Ähnlichkeit mit dem normalen Objektori-
entierten Entwicklungsprozess. Es wird zuerst ein Analysemodell (OOA) erstellt, dann
ein Designmodell (OOD) und dann als letzter Schritt der Programmcode. Der einzige
Unterschied besteht darin, dass der Übergang von Modell zu Modell oder zu Code durch
eine Transformation automatisiert ist [McN03].

14
Translationist Beim “Translationist” Ansatz, Abbildung 10 (rechts), wird das durch
den Entwickler erstellte PIM direkt in Programmcode transformiert. Die Übersetzungsre-
geln (“generation rules”) definieren, wie die Elemente des PIM im Programmcode umge-
setzt werden. Eine solche Transformation wird durch einen sogenanntem “Model Compi-
ler” durchgeführt. Von außen ist in diesem Entwicklungsprozess das PSM nicht mehr zu
erkennen, da es nur als innerer Zustand des Code Generators existiert. Der große Vorteil
liegt darin, dass das PIM zusammen mit den Übersetzungsregeln die gesamte Quelle des
Systems darstellen. Der erzeugte Programmcode muss durch den Entwickler nicht mehr
ergänzt werden. Somit entfällt auch die Notwendigkeit eines round-trip Engeneerings um
die Modelle synkron zu halten.

Das Prinzip Modelle automatisiert in Programmcode umzuwandeln ist im Bereich der ein-
gebetteten Systeme bereits seit den 80er Jahren unter dem Begriff CASE-Tools bekannt.
Solche Werkzeuge wie zum Beispiel Statemate setzen die Modelle bereits zuverlässig um.
Allerdings lassen sich diese Systeme meist durch Zustandsautomaten beschreiben. Solche
Modelle von Zustandsautomaten lassen sich besonders einfach in Programmcode überset-
zen. Bei komplizierten bisiness Systemen werden allerdings nur selten Zustandsautomaten
eingesetzt. Hier erfolgt ein Großteil der Modellierung über UseCase und Collaborations
Diagramme der UML [McN03]. Diese Modelle eignen sich sich nur bedingt für eine au-
tomatische Programmcodeerzeugung, und müssen mit zusätzlichen Elementen erweitert
werden, um die Semantik korrekt darzustellen.
Es bleibt nun abzuwarten ob die Model Driven Architecture sich in der Praxis als eine
neue Abstraktionsebene über der Hochsprache durchsetzt, oder ob die Industrie mit ande-
ren Ansätzen wie Rapid Application Development oder Extreme Programming versucht
der geringen Effizienz in der Softwareentwicklung entgegenzuwirken.

Literatur
[dH08] Johan den Haan. MDA and Model Transformation, Februar 2008. http://www.
theenterprisearchitect.eu/archive/2008/02/18/mda and model transformation.

[Gro03] Object Management Group. MDA Guide Version 1.0.1, Juni 2003. http://
www.omg.org/docs/omg/03-06-01.pdf.

[Gro07] Objekt Management Group. Executive Overview, Mai 2007. http://www.omg.

org/mda/executive overview.htm.

[KZ05] Regine Wolters Klaus Zeppenfeld. Generative Software Entwicklung mit der
MDA, volume 1. Spektrum Akademischer Verlag, November 2005.

[McN03] Ashley McNeile. MDA: The Vision with the Hole?, 2003.

[PR03] Wolfgang Neuhaus Peter Roßbach, Thomas Stahl. Model driven architecture.
Javamagazine, 09, 2003.

15
[Som07] Michael Sommerhalder. Design Guidelines und Erfahrungsberichte in MDD/M-
DA, 2007. http://seal.ifi.uzh.ch/fileadmin/User Filemount/Vorlesungs Folien/
Seminar SE/SS07/SemSE07-Michael Sommerhalder.pdf.

[Thi06] Peter Thiemann. Metamodeling, 2006. http://proglang.informatik.uni-freiburg.

de/teaching/mda/2006ss/04-meta.pdf.

[Wei04] S. Mellor K. Scott A. Uhl D. Weise. MDA Distilled: principles of model-driven

architecture. Addison-Wesley Professional, 2004.

[Wim05] Manuel Wimmer. Model Driven Architecture in der Praxis - Evalu-

ierung aktueller Entwicklungswerkzeuge und Fallstudie. Master’s thesis,
TU Wien, März 2005. http://www.big.tuwien.ac.at/research/publications/
diplomatheses/wimmer.pdf.

16