Dreher Model Driven Engineering.pdf - FH Aachen

Model-Driven Engineering
Seminararbeit im Masterstudiengang
Information Systems Engineering
Sebastian Dreher
Fachhochschule Aachen
Fachbereich Elektrotechnik und Informationstechnik
Eupener Straße 70, 52066 Aachen
[sebastian.dreher@alumni.fh-aachen.de]
Kurzfassung. In dieser Seminararbeit werden verschiedene Vorgehensmodelle
des Model-Driven Engineering, u.a. Computer Aided Software Engineering,
Domain Specific Language und Model-Driven Architecture vorgestellt. Ein besonderer
Fokus liegt hierbei auf der Entwicklungsmethode „Model-Driven
Architecture“, sowie Forschungsprojekte und Zukunftschancen dieser Methodik.
Keywords: Model-Driven Engineering, Model-Driven Architecture, Computer
Aided Software Engineering, Domain Specific Language
1 Einleitung
Charakteristisch für die Softwareentwicklung der heutigen Zeit sind sich schnell wandelnde,
fachliche Anforderungen und rasante technologische Fortschritte, sowie ein
hoher Zeit- und Kostendruck. Vor diesem Hintergrund offenbaren sich weitreichende
Probleme eines inkrementellen, iterativen Verfahrens oder des traditionellen Wasserfall-Vorgehensmodells.
(1)
Model-Driven Engineering (dt. Modellgetriebene Softwareentwicklung, kurz MDE)
ist ein Oberbegriff für die Anwendung ingenieursmäßiger Techniken, um automatisiert
aus formalen Modellen lauffähige Anwendungssoftware zu entwerfen. Durch
den Einsatz des MDE wird eine Effizienzsteigerung im Softwareentwicklungsprozess
propagiert. Diese soll durch die Anhebung des Abstraktionsniveaus durch Modellbildung
im Vergleich zur Softwareentwicklung auf Codeebene erreicht werden.
Ein Faktor der Effizienzsteigerung ist die gleichbleibende Qualität des Codes, welcher
aus formalen Modellen automatisch erzeugt wird. Man spricht in diesem Zusammenhang
von „Automation durch Formalisierung“. Mit dem Hinzufügen von Abstraktionsebenen
wird ebenfalls eine Umsetzung des Paradigmas „Separation of Concerns“
erzwungen, welches die Wartbarkeit eines Softwaresystems erheblich vereinfacht.

Interoperabilität, Portabilität und Wiederverwendung zählen hierbei zu den primären
Zielen des MDE.
Grundlegend wird zwischen drei verschiedenen Implementierungen unterschieden,
welche in dieser Ausarbeitung vorgestellt werden:
� Model Driven Architecture (dt. Modellgetriebene Architektur, kurz MDA) der
Object Management Group (OMG) 1 (2)
� Domain-Specific-Languages (dt. Domänen Spezifische Sprachen, kurz DSL) 2
� Computer Aided Software Engineering (dt. Computergestützte
Softwareentwicklung, kurz CASE) 3
Da die MDA ein sehr junger Entwicklungsansatz mit interessanten Forschungsthemen
ist, wird diese Methodik in den nachfolgenden Kapiteln ausführlich erläutert.
Abbildung 1: Ausdruckgsgrad der Lösungsbeschreibung
Abbildung 1 zeigt den Ausdrucksgrad der Lösungsbeschreibung und die Einordung
der MDE-Implementierungen. Je generischer die Implementierung bzw. Modellabstraktion
gehalten ist, desto größer ist der Aufwand der Anpassung des generierten
Codes. Für code - bzw. problemspezifische Aufgaben eignet sich die Verwendung
von DSLs besonders.
Diese Seminararbeit erläutert die zuvor benannten Implementierungen, sowie aktuelle
Forschungsansätze, Vor- und Nachteile bzw. Problemstellungen des MDA.
2 Computer Aided Software Engineering
Ziel des Computer Aided Software Engineering (kurz CASE) -Ansatzes ist es, Software
möglichst vollständig und automatisiert aus fachlichen Beschreibungen zu erstellen.
CASE-Tools sind Programme, die den Softwarearchitekten während Planung,
Entwurf und Dokumentation automatisiert unterstützen sollen. Diese Tools werden
1 weiterführende Literatur: Poland Petraschl, „Model driven architecture“, dpunkt.verlag
GmbH, 2006
2
weiterführende Literatur: Martin Fowler, „Domain-specific Languages”, Addison Wesley
Verlag, 2012
3
weiterführende Literatur: Thomas J. Bergin, Computer-Aided Software Engineering – Issues
and Trend for the 1990s and Beyond“, Idea Group Publishing, 1993

als eigenständige Applikation (Standalone) oder in Form einer Funktionserweiterung
(Plugin) für eine entsprechende Entwicklungsumgebung, wie Eclipse (Abbildung 2)
angeboten. Im Allgemeinen verbirgt sich hinter dem CASE die Vorstellung eines
klassischen Wasserfallmodells unter besonderer Berücksichtigung der Phasen: Analyse,
Design und Implementierung. CASE-Werkzeuge gibt es sowohl für 3GL (Third
Generation Programming Language) - und 4GL (Fourth Generation Programming
Language) Programmiersprachen 4 , als auch für objektorientierte Entwicklungen.
Abbildung 2: Grafische Java Notation mit dem Omondo-UML Editor (3)
Moderne CASE-Tools bieten eine grundlegende Unterstützung für die grafische Notationsweise,
Strukturierte Analyse und das Strukturierte Design. Nachfolgend werden
diese drei elementaren CASE-Bestandteile erläutert.
2.1 Grafische Notationsweise
Mit Hilfe der grafischen Notation können Ablaufdiagramme oder UML-Diagramme
in Codegerüste mit Funktionsrümpfen transformiert werden. So können beispielsweise
eine Klasse mit Membervariablen und Zugriffs-Modifiern, sowie die Schnittsellen
und Kommunikationsmuster grafisch gestaltet werden.
2.2 Strukturierte Analyse
Die Strukturierte Analyse wird während der Analysephase zur formalen Systembeschreibung
im Rahmen der Softwareentwicklung verwendet.
4 http://www.atalasoft.com/cs/blogs/rickm/archive/2009/06/11/a-short-history-of-programming-
languages-generations.aspx

2.3 Strukturiertes Design
“Strukturiertes Design (SD) ist ein Entwurfsmuster in der Softwaretechnik nach Edward
Yourdon und Larry Constantine, welches modulares Design unterstützt, um
neben der reinen Funktionshierarchie auch die Wechselwirkungen von übergeordneten
Modulen zu beschreiben.” (4) Es handelt sich hierbei um eine Verfeinerung der
zuvor durchgeführten, strukturierten Analyse.
Abbildung 3: Strukturiertes Design (Schema), entnommen aus
http://www.infforum.de/themen/anwendungsentwicklung/thema_SEmethode_sd.htm
Oft wird das Schema aus Abbildung 3 für die Top-Down Strukturierung von Menüpunkten
verwendet, um Hauptkategorien mit zugehörigen Unterkategorien bis hin
zur Datenkapselung übersichtlich erfassen zu können. Die Landing Page der Fachhochschule
Aachen (Abbildung 4) bietet z.B. den Hauptnavigationspunkt „Studienangebote“.
Dieser wird unterteilt in die Module: Bachelorstudiengänge,
Mastersudiengänge, duales Studium etc.. Selektieren wir nun das Modul Masterstudiengang,
erhalten wir bezogen auf Abbildung 3, die “aufgerufene vordefinierte Datenkapsel”,
was dem Content der zugrunde liegenden Website entspricht.

Abbildung 4: Landing-Page Menü der FH-Aachen (5)
3 Domain Specific Language
Unter DLSs werden im Allgemeinen abstrakte Sprachen bezeichnet, welche für ein
bestimmtes Problem, die Domäne, entworfen und implementiert werden. Im Vergleich
zu universell einsetzbaren Programmiersprachen, wie C/C++, Java, etc. erzeugen
DSLs bedeutend weniger Overhead und Redundanz, aufgrund des meist beschränkten
Umfangs. DSLs werden in Verbindung mit Codegeneratoren und Interpretern
verwendet, um die Beschreibung eines Sachverhaltes oder Problems deklarativ zu
gestalten. Im Folgenden werden die einzelnen Prozessschritte von der Domänenbeschreibung
bis hin zum fertigen Code unter Verwendung der DSL beschrieben. (6)
Die Vorgehensweise bei der Entwicklung einer DSL, lässt sich wie folgt beschreiben:
� Domänenbeschreibung
─ Die Domänenbeschreibung ist gekennzeichnet durch eine fachliche oder technische
Wissensbeschreibung des darzustellenden Gesamtsystems. Hier werden
Grenzen und Schnittstellen, sowie das Verhalten klar definiert.
� Metamodellierung
─ Abgrenzung: Nichtberücksichtigung irrelevanter Objekte
─ Reduktion: Weglassen von Objektdetails
─ Dekomposition: Zerlegung, Auflösung in einzelne Segmente
─ Aggregation: Vereinigung von Segmenten zu einem Ganzen
─ Abstraktion: Begriffs- bzw. Klassenbildung
� Ableiten der DSL
─ Externe DSL: Eine von Grund auf neu definierte Sprache. Sowohl die konkrete
Syntax als auch die Semantik können hier frei definiert werden.
─ Interne DSL: Eine interne DSL ist eine echte Untermenge einer generelleren
Sprache.
� Modellierung des Systems unter Verwendung der DSL
� Validierung des Systems
� Glue-Code
─ Manuelle Anpassung des Implemetierungscodes

4 Model Driven Architecture
MDA bietet ein offenes, herstellerneutrales Vorgehen, um während des Softwareentwicklungsprozesses
die Business- und Applikationslogik, sowie Plattformtechnologie
voneinander zu trennen.
Abbildung 5: Integration der MDA (2)
Bei der Modellierung mit MDA wird berücksichtigt, dass ein einziges Modell nicht
die Komplexität eines Software-Gesamtsystems abbilden kann. Entweder wird das
fachliche Detail im Zusammenhang mit der Geschäftslogik zu intensiv dargestellt,
was zu einer überladenen und nicht überschaubaren Komplexität führt, oder es wird
nicht mit genügend Detailtreue abgebildet, was zu einer Unschärfe der Anforderungen
führen kann. Als Konsequenz führt MDA eine Trennung des Gesamtmodelles in Teil-
Modelle durch (Abbildung 5). Hierbei liegt der Scope nicht auf einer vollständigen
Automatisierung der Code-Generierung, denn diese variiert in Abhängigkeit der fachlichen
Anforderung zwischen 20 und 80 Prozent. (7)
Abbildung 6: Schema unter Anwendung der MDA
Abbildung 6 zeigt einen schematischen Top-Down-Ansatz, mit welchem die verschiedenen
Phasen durchlaufen werden.

4.1 Computation Independent Model (CIM)
Mit Hilfe des CIM wird die Geschäfts- oder Domänensicht des zu entwickelnden
Softwaresystems modelliert. Das CIM ist im Rahmen der MDA der Modelltyp mit der
höchsten Abstraktionsebene. Es ist unabhängig von technischen Aspekten der Implementierung,
d.h. es beschreibt keine internen Strukturen oder das innere Verhalten des
Softwaresystems. (8) Als Werkzeuge kommen hierbei umgangssprachliche Beschreibungen,
Use-Case-Diagramme, Interaktionsdiagramme und Aktivitätsdiagramme zum
Einsatz.
4.2 Platform Independent Model (PIM)
Das PIM ist ein plattformunabhängiges Modell für Geschäftsprozesse, welches logische
Prozesse abstrahiert. Das zuvor erstellte CIM wird hierbei mit Hilfe einer Model-
Model-Transformation in ein PIM überführt (Abbildung 7). Durch ein UML-Profil
wird die Darstellung fachlicher Elemente (Services, Business Classes, Business Rules)
projekt- und anwendungsspezifisch vorgegeben.
4.3 Platform Specific Model (PSM)
Das PSM ist ein abstraktes, plattformabhängiges Modell der Zielarchitektur. Es entsteht
durch die Transformation des CIM unter Berücksichtigung spezieller Architektureigenschaften
und Services der späteren Zielplattform (Abbildung 7), so z.B. J2EE,
Corba oder XML.
4.4 Codemodell
Nach einer weiteren Transformation wird das PSM in den Implementierungscode der
zuvor gewählten Plattform (Abbildung 7) überführt. Wie bereits erwähnt, erhebt das
MDA-Verfahren keinen Anspruch auf eine vollständige Codegenerierung. Gegebenenfalls
müssen Glue-Code 5 oder das Ausprogrammieren von Funktionsrümpfen
manuell vorgenommen werden.
5 Glue-Code: funktionsfreier Quellcode der einzelne Software-Module untereinander „verbindet“,
welche sonst nicht kompatibel zueinander wären

Abbildung 7: MDA-Transformationsbeispiel (9)
Abbildung 7 zeigt den Transformations-Ablauf der verschiedenen Modelle von 4.1
bis 4.4.
5 Forschungsansätze des MDA
Obwohl MDE noch nicht lange in den wissenschaftlichen Bereichen vertreten ist, gibt
es bereits einen Großteil an nationalen und internationalen Forschungsprojekten und
Konferenzen. Dieses Kapitel gibt einen groben Überblick über nationale Forschungseinrichtungen
im Bereich MDE, sowie die zugehörigen Projekte.
Im Jahr wurde 2010 an der TU München - Lehrstuhl IV: Software & Systems Engineering
ein MDE-Kompetenzzentrum gegründet, welches die Forschungsaktivitäten
in den folgenden Bereichen intensiviert hat. (10)
� Seamless model-based development
� Model-based development of mechatronic systems
� Formal specification of (mostly embedded) software systems
� Model-based debugging
� Analysis of costs and benefits of model-based development of embedded software
systems in the car industry
� Modeling of probabilistic systems
� Formal semantics of UML2
� Transition from documents in natural language to system models
� Model validation
� Model-based deployment
� Model-based testing

� Model-based safety-cases
Im folgenden Auszug der aktuellen Forschungsprojekte der TU München lassen sich
als Förderungspartner u.a. das BMBF (Bundesministerium für Bildung und Forschung),
BMWi (Bundesministeriums für Wirtschaft und Technologie), Altran Technologies
(http://www.altran.de/), sowie Siemens Automation finden. Große Institutionen
und Firmen zeigen also durchaus (finanzielles) Interesse in diesem Forschungsbereich.
(11)
SPES 2020. SPES 2020 ist ein vom BMBF gefördertes Forschungsprojekt zur Entwicklung
einer Methodik zur durchgängig, modellbasierten Entwicklung von eingebetteten
Systemen. Im Rahmen des Projekts werden Lösungen für die domänenübergreifende
und modellbasierte Entwicklung von eingebetteter Software erarbeitet. Modellbasierte
Verfahren auf Basis eines soliden mathematischen Fundaments ermöglichen
eine effiziente Entwicklung eingebetteter Systeme, beginnend bei den initialen
Kundenanforderungen über den Entwurf und die Implementierung bis hin zur Verifikation
und Zertifizierung von Systemen. (11)
Analyse der Kosten und des Nutzen modellbasierter Entwicklung eingebetteter
Softwaresysteme in der Automobilindustrie. In Zusammenarbeit mit dem Technologieberatungsunternehmen
Altran werden die notwenigen Kosten für eine Modellbasierte
Entwicklung und der daraus resultierende Nutzen analysiert. Ziel ist es wesentliche
Kosten- und Nutzentreiber zu identifizieren und zu analysieren wie man die
Wirtschaftlichkeit der modellbasierten Entwicklung optimieren kann. Die Ergebnisse
der Arbeit werden aus Fallstudiengesprächen und einer globalen Studie abgeleitet.
(11)
AutoVIBN. Gefördert durch das BMWi (AiF) entwickelt das Kompetenzzentrum
Modellbasierte Entwicklung zusammen mit dem iwb und mehreren Industriepartnern
Beschreibungstechniken und Methoden für die logische Verhaltensmodellierung
mechatronischer Systeme im Anlagenbau. Diese Modelle dienen der Unterstützung
im Entwicklungsprozess durch Exploration und Simulation verschiedener Lösungsansatze
auf logischer Ebene. Zudem lassen sich die Modelle als Basis für die Generierung
abgeleiteter Modell nutzen, wie etwa von Modellen für die virtuelle Inbetriebnahme.
(11)
FlaSCo. Eine Machbarkeitsstudie der modellbasierten Entwicklung eingebetteter
Systeme im industriellen Umfeld: von Anforderungen bis zum Entwurf n Zusammenarbeit
mit Siemens Automation. (11)
In der Universität Ulm - Institut für Programmiermethodik und Compilerbau gibt es
seit 2009 ebenfalls einen Forschungsbereich zum MDE, wodurch das Projekt „Active
Charts“ entstanden ist: „Wir beschäftigen uns mit der Frage, wie mächtigere Soft-

ware-Werkzeuge konstruiert werden können, welche die Synchronisation von Analyse/Entwurfs-
und Implementierungsartefakten unterstützen bzw. sicherstellen können
ohne den Entwickler in seinen bisherigen Implementierungsmöglichkeiten zu sehr
einzuschränken.“ (12)
„Unser Ansatz ActiveCharts kombiniert Modelle aus den Analyse/Design-Phasen
und (handgeschriebenen) Code aus der Implementierungsphase auf eine neue Art:
Wir modellieren den Kontrollfluss einer Anwendung mit UML 2 Aktivitätsdiagrammen,
die von einer Laufzeitumgebung (ActiveChartsIDE) interpretiert werden. Mit
dieser Laufzeitumgebung können die Aktivitätsdiagramme simuliert und visualisiert
werden. Funktionen wie beispielsweise Breakpoints oder schrittweises Vorgehen
ermöglichen ein einfaches Debuggen der Anwendung.
Analyse- bzw. Designartefakte werden in unserem Ansatz nahtlos für die Implementierungsphase
übernommen. Wir wollen damit die Lücken zwischen den unterschiedlichen
Phasen im Softwareentwicklungsprozess verkleinern und die Dokumentation
und die Wartbarkeit von Softwareprodukten verbessern.“ (13)
Einen weiteren, interessanten Ansatz verfolgt das Transferprojekt „Agile Model
Driven Architecture“ an der Universität Leipzig. Hier werden zwei Ansätze kombiniert,
die augenscheinlich nichts miteinander zu tun haben – MDE der Object Management
Group und Agile Softwareentwicklung.
Im Kern geht es bei agiler Softwareentwicklung um möglichst häufige Rückkopplungsprozesse
und zyklisches (iteratives) Vorgehen auf allen Ebenen: bei der Programmierung,
im Team und beim Management. Im Vergleich zum direkten Vorgehensmodell
wird die Zielsetzung nicht ausschließlich zu Beginn der Softwareentwicklung
erarbeitet, sondern kann während des Entwicklungsprozesses noch angepasst
werden. (14)
„Unser Lösungsansatz lautet: "Agile MDA" oder "Prefabricated Architectures"
oder "MDA Domesticated" oder einfach "Leipziger Softwareprozessmodell".
Das Leipziger Software-Prozessmodell (LSP) versucht das Beste beider Welten miteinander
zu verbinden. Modelle, die die Fachlichkeit möglichst umfassend ausdrücken,
aber keine Generierung um jeden Preis, genauso wie kontinuierliche Einbeziehung
des Anwenders und schlanke Inkremente, ohne dabei die Pandora-Büchse des
unkontrollierten Hacking zu öffnen.“ (15)
Ein Blick auf die Publikationswebsite des Frauenhofer Instituts (16) zeigt anhand
der Dissertation „A methodology for pattern-oriented model-driven testing of
reactive software systems“ von Vouffo-Feudjio, A.-G., dass auch dort Ansätze des
MDE erforscht werden:
“The thesis presents a catalogue of test design patterns, along with a methodology
for the proposed approach. The methodology is based on a new notation called Unified
Test Modeling Language (UTML), specifically designed to support patternoriented
model-driven testing. UTML is a Domain-Specific Modeling Language
(DSML) for designing test objectives, test architectures, test data and test behaviour at
a high level of abstraction, using predefined test design patterns. The result are socalled
abstract test models, that can then be subsequently refined through a series of

iterative transformation processes into executable test sequences, scripts or documentation
artifacts.” (17)
6 Offene Punkte beim MDA
Da das MDE eine relativ „junge“ Entwicklungsmethode beschreibt, gibt es noch einige
ungeklärte Aspekte, die bei der Einführung dieser Methodik berücksichtigt werden
sollten. Bei der Umsetzung der Standards wirken viele Tools keinesfalls überzeugend.
Bezug nehmend auf die Wirtschaftlichkeit dieses Verfahrens - speziell im Vergleich
zur konventionellen Entwicklung, gibt es kaum verfügbare Belege. Es stellt sich also
die Frage, ob die Einführung des MDE für die jeweilige Unternehmung rentabel ist.
So kommen Lewis, G.A. und Wrage, L. in einer MDA Studie im Jahr 2005 (18) zu
dem Resultat, dass die Entwicklungszeit unter Einsatz von MDA zunächst zunimmt
und sich nur lohnt, wenn mehrere Projekte dieser Art durchgeführt werden. Ergebnisse
aktuellerer Studien lagen zum Zeitpunkt des Verfassens dieser Arbeit nicht vor.
Abbildung 8: Kernaussagen aus MDA Studien, entnommen aus “Model-
Driven Architecture: Konzeption, Einordnung und Wirtschaftlichkeit“ [S.60]
von Johannes Vetter

Die Frage nach der Rentabilität kann also nicht mit einem einfachen „Ja“ oder
„Nein“ beantwortet werden. Vielmehr müssen eine Vielzahl von Aspekten gegeneinander
ab gewägt werden.
Das Internetportal Software-Engineering (www.software-kompetenz.de) listet
hierzu die nachfolgenden Punkte, welche an dieser Stelle übernommen und nach
fachlicher bzw. wirtschaftlicher Relevanz sortiert wurden. (19)
6.1 Fachliche Relevanz
Reengineering / Wartung
MDA ist ursprünglich für Neuentwicklungen gedacht. Wie können aber bestehende
Softwaresysteme in MDA übernommen werden, so dass die Weiterentwicklung
mit Hilfe dieser Methodik erfolgen kann? Ein weiterer Aspekt ist die Erzeugung von
Releases, Patches oder Updates, welches ein wichtiger Bestandteil der laufenden
Wartung von Anwendungen ist. Wie geht MDA damit um? Ist es notwendig jedes
Mal das komplette System neu installieren?
Stabilität des Datenmodells
Änderungen am Datenmodell können großen Aufwand nach sich ziehen, der bei
der Änderung des Modells nicht sofort sichtbar ist. Es ist für den Designer oder Entwickler
beispielsweise sehr einfach, im Modellierungstool ein Attribut zu einer persistenten
Klasse hinzuzufügen. Die MDA-Generatoren erzeugen dann im Datenbankskript
für die Tabelle, die zu der Klasse gehört, eine weitere Spalte. Dadurch entsteht
nun die Notwendigkeit, zumindest die neue Spalte in den bestehenden Zeilen mit
einem definierten Leerwert zu füllen.
Entfremdung des Entwicklers vom Code
Der generierte Code ist für den Entwickler nur noch schwer verständlich und nachvollziehbar.
Weiterhin stellt sich das Problem mit Fehlern in den Codegeneratoren auf
neue Weise wieder. Es wird dadurch potenziert, dass die Generatoren teilweise Code
erzeugen, der auf Annahmen basiert, welche die Architekten bei der Entwicklung der
Templates für den Codegenerator gemacht haben und welche dem Entwickler unbekannt
sind. Resultierend hierbei ist Code, der von den Entwicklern in vielen Fällen
schwer zu verstehen ist. Aus Sicht des Entwicklers ist es schwierig Codefragmenten
zu vertrauen, die nicht selber entwickelt wurden und kaum lesbar sind.
Unzulänglichkeiten in den Tools
Die Erwartungshaltungen der Entwickler sind derzeit nur schwer zu erfüllen. Dies
betrifft sowohl die funktionalen, als auch die nicht-funktionalen Aspekte.

Zu den nicht-funktionalen Einschränkungen gehört z. B. die Performance. So dauert
beispielsweise das Umbenennen einer Implementierungsklasse im Code in der Regel
nur Sekunden. Inklusive der damit verbundenen Nachfolgeänderungen (z. B. Umbenennung
der Datei im Konfigurationsmanagementsystem) bewegt man sich jedoch im
Minutenbereich. Die Umbenennung einer Klasse im UML-Modell eines MDA-Tools
hingegen kann schon aufwändiger werden. Der MDA-Codegenerator muss den gesamten
Code neu generieren. Die Arbeitsumgebung muss konsistent gehalten werden.
Dazu gehört, dass alle Artefakte mit dem alten Namen gelöscht werden.
6.2 Wirtschaftliche Relevanz
ROI (Return-on-Investment)
Bisher gibt es nur sehr wenige Überlegungen, ab wann sich der Einsatz von MDA
lohnt. Für den Einsatz von MDA sind viele Vorbereitungen und Vorarbeiten notwendig.
Hierzu gehören nicht nur Schulungen der Entwickler, sondern auch konzeptionelle
Arbeiten (z. B. Anpassung des Softwareentwicklungsprozesses). Dies sind nicht
unerhebliche Aufwände.
EAI (Enterprise Application Integration)
Modellierung auf hoher Ebene erscheint auf den ersten Blick sinnvoll. Neue Anwendungen
laufen aber selten für sich isoliert, sondern müssen in eine vorhandene
Anwendungslandschaft integriert werden. Wie kann dies in der MDA-basierten Entwicklung
berücksichtigt werden?
Herstellerabhängigkeit
Da der MDA-Standard derzeit noch nicht vollständig und einheitlich von den
Toolherstellern umgesetzt wird, bedeutet die Festlegung auf ein Werkzeug damit auch
eine gewisse Herstellerabhängigkeit. Solche Abhängigkeiten haben sich in der Vergangenheit
jedoch oftmals als negativ herausgestellt, da eine Kompatibilität zu Konkurrenz-Produkten
meist nicht gegeben ist.
7 Fazit
Abschließend ist festzuhalten, dass sich die modellgetriebene Softwareentwicklung
noch in einem sehr frühen Entwicklungsstadium befindet. So gibt es Ansätze verschiedener
Hersteller, unterstützende Tools bereitzustellen, aber oft ist der generierte
Output schwer wartbar oder die Umsetzung der Standardisierungen ist nicht ausreichend
implementiert. Dies kann zu Problemen im Zusammenspiel mit anderen Softwareprodukten
führen. Langzeiterfolge des MDA-Ansatzes sind sehr eng mit der

Entwicklung marktreifer, praxistauglicher MDA-Tools, speziell im Bereich der Model-to-Model-Transformation
verknüpft. (20)
International, als auch auf nationaler Ebene gibt es verschiedene, meist universitäre
Forschungsprojekte, deren gemeinsames Ziel in der Optimierung der MDE-
Entwicklungsmethoden liegt, um die Wirtschaftlichkeit dieses Verfahrens weiterhin
zu optimieren.
Gerade bei der Durchführung komplexer, großangesetzter Softwareentwicklungen
wäre die Etablierung vollständiger, standardisierter MDE-Tools eine große Bereicherung.
Es bleibt zu hoffen, dass Techniken, wie das MDA noch zu einem „Durchbruch“
finden und nicht irgendwann lautlos verschwunden sein werden. Wie gezeigt
wurde, gibt es noch offene Punkte beim MDA – die besonders für Entwickler eine
Eintrittsbarriere auf Grund der hohen Komplexität darstellen.
Ein großer Vorteil von DSL hingegen ist, dass die Sprachkonzepte auf die Zieldomäne
abgestimmt sind. Das heißt, dass in möglichst natürlicher Sprache, bezogen auf
die Domäne, Sachverhalte formuliert werden können. Je nach Grad der Abstraktion
und Syntax können dies auch Nicht-Entwickler übernehmen oder Experten der Domäne,
ohne IT-Kenntnisse. Weiterhin ist die allgemeine Produktivität innerhalb des
Projekts deutlich erhöht, sobald die DSL einmal fertiggestellt ist, da dann auf höherem
Abstraktionsgrad gearbeitet werden kann. (21)
8 Literaturverzeichnis
1. Anneke Kleppe, Jos Warmer, Wim Bast. MDA Explained, The Practice . s.l. :
Addison Wesley, 2003.
2. OMG. The Architecture of Choice for a Changing World. [Online] 27 06, 2012.
[Cited: 07 16, 2012.] http://www.omg.org/mda.
3. www.forum-omondo.com. Omondo UML. [Online] [Cited: 09 20, 2012.]
www.forum-omondo.com/documentation_eclipseuml_2008
/refactoring/refactor_class_class_diagram.png .
4. Wikipedia. Strukturiertes Design. [Online] [Cited: 09 20, 2012.]
http://de.wikipedia.org/wiki/Strukturiertes_Design.
5. FH-Aachen. Landing-Page. [Online] www.fh-aachen.de.
6. Wikipedia. Domänenspezifische Sprache. [Online] [Cited: 08 12, 2012.]
http://de.wikipedia.org/wiki/Domänenspezifische_Sprache.
7. Model Driven Architecture. [Online] 04 27, 2012. [Cited: 07 16, 2012.]
http://de.wikipedia.org/wiki/Model_Driven_Architecture.
8. VSEK. Computation Independent Model (CIM). [Online] [Cited: 07 16, 2012.]
http://www.software-kompetenz.de/servlet/is/27119.
9. Thomas, Dr. Marc. MDA – Praktisch. [PDF] s.l. : itemis GmbH & Co. KG,
2006.
10. TU München - Fakultät für Informatik Lehrstuhl IV: Software & Systems
Engineering. Research Areas. [Online] [Cited: 08 21, 2012.]
http://www4.in.tum.de/research/modeldriven/research.shtml.

11. TU München - Fakultät für Informatik Lehrstuhl IV: Software & Systems
Engineering. Aktuelle Projekte. [Online] [Cited: 08 21, 2012.]
http://www4.in.tum.de/research/modeldriven/projects.shtml .
12. Universität Ulm. Model Driven Development. [Online] [Cited: 08 20, 2012.]
http://www.uni-ulm.de/in/pm/forschung/themen/mdd.html.
13. Universität Ulm. ActiveCharts. [Online] [Cited: 08 2012, 2012.]
http://www.uni-ulm.de/in/pm/forschung/themen/mdd.html.
14. IT-Agile DIE EXPERTEN FÜR AGILE SOFTWAREENTWICKLUNG.
Was ist agile Softwareentwicklung? [Online] [Cited: 07 26, 2012.] http://www.itagile.de/wasistagilesoftwareentwicklung.html.
15. Universität Leipzig. Transferprojekt "Agile Model-Driven Architecture".
[Online] [Cited: 07 26, 2012.] http://ebus.informatik.unileipzig.de/www/de/forschung/agile-mda/agilemda.html.
16. Frauenhofer. Schlagwort Suche: Model-Driven Engineering. [Online] [Cited:
07 26, 2012.] http://publica.fraunhofer.de/schlagwoerter/modeldriven%20engineering.
17. Vouffo-Feudjio, A.-G. Frauenhofer. A methodology for pattern-oriented
model-driven testing of reactive software systems. [Online] [Cited: 07 26, 2012.]
http://publica.fraunhofer.de/dokumente/N-195472.html.
18. Vetter, Johannes. Model-Drive Architecture. Konzeption, Einordnung und
Wirtschaftlichkeit. Ravensburg : GRIN Verlag, 2007.
19. Software-Engineering. MDA in der Wissenschaft. [Online] [Cited: 07 23,
2012.] http://ms.ligatus.com/de/finanzen/provea/miriale8_popunder/?v=3.
20. Thomas Stahl, Markus Völter. Modellgetriebene Softwareentwicklung –
Techniken, Engineering, Management. s.l. : dpunkt-Verlag, 2005.
21. Maximilian Stroh. Hauptseminar Web Engineering im SS 2012. Model
Driven Development and Domain Specific Languages. [Online] [Cited: 09 21, 2012.]
http://vsr.informatik.tu-chemnitz.de/edu/2012/webe-seminar-ss/papers/02/.