Ausarbeitung

Westfälische Wilhelms-Universität Münster
Ausarbeitung
AndroMDA
im Rahmen des Seminars „Ausgewählte Themen des Software Engineering“
Irina Thome
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Christian Arndt
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft

Inhaltsverzeichnis
1 Einleitung................................................................................................................... 3
2 Model Driven Architecture........................................................................................ 4
3 AndroMDA................................................................................................................ 7
3.1 Architektur von AndroMDA ............................................................................ 7
3.2 Die Funktionsweise von AndroMDA ............................................................... 8
3.3 AndroMDA Cartridges ..................................................................................... 9
4 Arbeiten mit AndroMDA ........................................................................................ 12
4.1 Entwicklungsumgebung.................................................................................. 12
4.2 Implementierung eines Shop-Systems als Beispielanwendung...................... 13
4.3 Kritische Würdigung des Entwicklungsprozesses mit AndroMDA ............... 15
5 Zusammenfassung und Ausblick............................................................................. 17
6 Literaturverzeichnis ................................................................................................. 18
II

Kapitel 1: Einleitung
1 Einleitung
Model Driven Architecture (MDA) verändert die Sichtweise auf die Entwicklung von
Software grundlegend. Modelle werden in den Mittelpunkt des Entwicklungsprozesses
gestellt und dienen nicht länger nur als Dokumentation, sondern als wesentliche
Grundlage für den erstellten Quellcode. Software-Entwickler sollen durch Tools dabei
unterstützt werden, Code aus den Modellen zu generieren. Ferner wird eine
Unabhängigkeit von und Portabilität zwischen verschiedenen Plattformen angestrebt.
AndroMDA ist ein weit verbreitetes Open-Source-Tool, das dem MDA-Paradigma
entspricht. Die vorliegende Arbeit soll einen Einblick darin geben, wie MDA-
Anforderungen durch AndroMDA umgesetzt werden. Dazu wird – nach einer kurzen
Klärung der Begriffe rund um MDA – die Architektur von AndroMDA beschrieben. Im
Anschluss wird der Prozess der Codegenerierung dargestellt. Wegen der zentralen Rolle
von Cartridges für AndroMDA werden diese herausgegriffen und eingehend betrachtet.
Dieser theoretische Teil wird im dritten Abschnitt an Hand eines praktischen Beispiels
näher erläutert und demonstriert. Dabei sollen die Grundprinzipien von MDA
veranschaulicht werden. Den Abschluss bildet ein Fazit, das die Möglichkeiten von
AndroMDA bezüglich der automatisierten Codegenerierung zusammenfasst.
3

Kapitel 2: Model Driven Architecture
2 Model Driven Architecture
Model Driven Architecture (MDA) stellt ein Framework für die Entwicklung von
Software dar. MDA wurde von der Object Management Group (OMG) entwickelt und
in [OMG03] spezifiziert. Bei der OMG handelt es sich um ein internationales
Konsortium, das sich mit der Entwicklung von herstellerunabhängigen Standards für die
objektorientierte Programmierung beschäftigt.
Die traditionelle Methode zur Software-Entwicklung folgt nach [KWB03, Kapitel 1] in
der Regel einem ähnlichen Ablauf wie dem in Abb. 1 dargestellten. Besonders in den
frühen Phasen werden neben textuellen Beschreibungen auch Modelle generiert, die im
späteren Entwicklungsprozess jedoch lediglich zur Dokumentation dienen. Da in der
Praxis Iterationen des Prozesses aus Zeit- und Kostengründen hauptsächlich die
späteren Entwicklungsphasen umfassen, entfernt sich die tatsächliche Implementierung
zunehmend von den Modellen, die so ihre Bedeutung verlieren. Das führt zu Problemen
bei der Wartung und Weiterentwicklung der Systeme, wenn außer den initialen
Beschreibungen und Modellen keine aktuelle Dokumentation vorhanden ist. Weitere
Schwierigkeiten ergeben sich aus der schnellen technologischen Entwicklung im
Bereich der Software-Industrie und der damit entstehenden Notwendigkeit, Systeme
portabel und interoperabel zu gestalten.
MDA stellt im Gegensatz zum traditionellen Ansatz Modelle in den Mittelpunkt des
Software-Entwicklungs-Prozesses. Obwohl die Phasen des Entwicklungsprozesses
gleich bleiben (vgl. Abb. 1), werden nunmehr als Hauptartefakte formale Modelle
generiert, die von einem Computer verarbeitet werden können. Es existieren die
folgenden Modelltypen (vgl. [OMG03]):
Computer Independent Model (CIM): Das CIM beschreibt die fachlichen
Anforderungen an das spätere System und beinhaltet Geschäftsabläufe, Mitarbeiter,
Schnittstellen usw.
Platform Independent Model (PIM): Ein Model mit hohem Abstraktionsniveau, welches
die Struktur des Systems unabhängig von der späteren Implementierung beschreibt. Das
PIM enthält „die zu verwendenden Komponenten sowie deren Funktionalitäten und
Interaktionen“ [TBH04, S. 349].
4

Kapitel 2: Model Driven Architecture
Platform Specific Model (PSM): Ein PIM wird in ein oder mehrere PSM transformiert,
die aus Entwicklersicht auf Details der Implementierung eingehen. In der Regel wird für
jede Plattform ein eigenes PSM erstellt, das typischerweise Konstrukte und Begriffe der
jeweiligen Technologie enthält.
Code: Abschließend werden die PSM in Code umgewandelt. Diese Umwandlung wird
durch die große Nähe eines PSM zu der entsprechenden Technologie vereinfacht.
Traditioneller Ablauf der Software­
Entwicklung
Anforderungen
Hauptsächlich
Text
Ablauf der Software­Entwicklung mit
MDA
Anforderungen
CIM
Analyse
Diagramme
und Text
Analyse
PIM
Systemnahes Design
Diagramme
und Text
Systemnahes Design
PSM
Code
Code
Code
Code
Testen
Testen
Code
Code
Deployen
Deployen
Abbildung 1: Ablauf der Software-Entwicklung mit und ohne MDA (vgl. [KWB03], S. 3, S. 7)
Die Umwandlung von PIM zu PSM und von PSM zu Code wird im MDA-Prozess
durch entsprechende Werkzeuge unterstützt. Eine vollständige Generierung von
Anwendungen aus einem PIM ist zur Zeit zwar nicht möglich, jedoch können lauffähige
Anwendungen mit Basisfunktionalitäten bereits automatisiert erstellt werden.
Das Augenmerk der Entwickler verlagert sich im MDA-Prozess auf die Entwicklung
des PIM. [KWB03] beschreibt die Vorteile durch den Einsatz von MDA wie folgt: Die
Produktivität kann deutlich gesteigert werden, wenn ein Großteil des Codes automatisch
erstellt wird. Ferner wird die Portabilität erhöht, da verschiedene plattformspezifische
Modelle aus demselben PIM generiert werden können. Zur Verbesserung der
5

Kapitel 2: Model Driven Architecture
Interoperabilität bietet MDA die Möglichkeit, sog. Bridges zu generieren, die eine
Übersetzung zwischen Modellen für verschiedene Plattformen auf PSM- oder Code-
Ebene ermöglichen. Schließlich wird die Dokumentation und Wartung der Systeme
erleichtert, da die Modelle konsistent und aktuell gehalten werden. [TBH04] nennt die
durch MDA gesteigerte Qualität der Software als weiteren Vorteil.
6

Kapitel 3: AndroMDA
3 AndroMDA
3.1 Architektur von AndroMDA
Bei AndroMDA (gesprochen: Andromeda) handelt es sich um einen Open Source
MDA-Generator, der über das Webportal „SourceForge.net“ verwaltet wird. Die
offizielle Homepage unter [And07a] beinhaltet die Dokumentation und ein Forum für
den Support. Die aktuelle stabile Version ist AndroMDA 3.2. Kurz vor Fertigstellung
der vorliegenden Arbeit wurde AndroMDA 4.0-M1-SNAPSHOT veröffentlicht, jedoch
konnten die Eigenschaften dieser Version hier nicht weiter berücksichtigt werden.
Das Ziel von AndroMDA ist es, die Arbeit der Entwickler zu erleichtern und die
Transformation von PIM in PSM zu übernehmen. Es kann zwar keine vollständige
Anwendung aus einem PIM direkt erstellt werden, der Entwickler kann sich jedoch auf
die Implementierung der Geschäftslogik konzentrieren. Langwierige, redundante
Aufgaben werden von AndroMDA automatisiert erledigt.
Abbildung 2: Architektur von AndroMDA (in Anlehnung an [Dew06] und [Kar06])
AndroMDA weist eine modulare Struktur auf (vgl. Abb. 2). Die Kernkomponente stellt
ein template-basierter Generator dar. Dieser erhält Modelle im XMI-Format (XML
Metadata Exchange) als Input und generiert aus diesen Komponenten der Anwendung,
entweder als vollständigen Code oder als vom Entwickler anzupassende
7

Kapitel 3: AndroMDA
Codefragmente. Mit Hilfe von Plugins (sog. Cartridges und Translation Libraries)
können Komponenten für verschiedene Programmiersprachen oder Technologien
erstellt werden. Durch das Auswechseln der Plugins kann aus einem Modell der
Quellcode für jede beliebige Plattform generiert werden.
Das MetaData Repository dient zum Einlesen einer XMI-Datei und der internen
Abbildung der Daten. Es ist auch möglich, Repositories für andere Formate zu erstellen.
Cartridges stellen JAR-Archive mit Templates und Metafacades dar. Mit Hilfe von
Metafacades kann auf die von MetaData Repository geladenen Modell-Objekte
zugegriffen werden. Die Templates ihrerseits ermöglichen den Zugriff auf die
Methoden der Metafacade-Klassen. Eine Reihe verschiedener Cartridges liegt bereits
vor, z. B. für EJB, Spring, Struts oder Hibernate. Den Anwendern ist es jedoch jederzeit
möglich, eigene Cartridges für ihre speziellen Bedürfnisse zu programmieren.
Die Template Engine verarbeitet die Templates. AndroMDA verwendet standardmäßig
Velocity 1.4, eine auf Java basierende Open-Source Template Engine (nähere
Informationen hierzu unter [Vel07]).
Translation Libraries werden verwendet, um auf Modellebene Ausdrücke zu
verarbeiten, die in OCL (Object Constraint Language) geschrieben sind. Solche
Ausdrücke können dazu dienen, die Modelle zu validieren oder Datenbankabfragen
unabhängig von einer Plattform zu formulieren.
3.2 Die Funktionsweise von AndroMDA
Grundlage der Codegenerierung mit AndroMDA bilden i. d. R. UML-Modelle. Dabei
kann es sich sowohl um Struktur- als auch um Verhaltensdiagramme handeln. Die
Modelle müssen ins XMI-Format exportiert werden, damit sie von der Repository-
Komponente von AndroMDA gelesen werden können. Aus dem eingelesenen Modell
wird im Speicher ein instanziiertes UML-Metamodell in Form von Java-Objekten
erzeugt.
Um die Erstellung des Metamodells zu ermöglichen werden UML-Stereotypen und
Eigenschaftswerte, sog. tagged values bei der Modellierung verwendet. Mit Hilfe von
Stereotypen ist es möglich, Modellelemente zu klassifizieren und den passenden
Quellcode zu dieser Klasse durch entsprechende Templates einer Cartridge zu
generieren. Wird z. B. der Stereotyp einer Klasse zugeordnet, dann wird
8

Kapitel 3: AndroMDA
für die Codegenerierung eine Persistenz-Cartridge mit geeigneten Templates verwendet.
Ferner können Detailinformationen zu einer Klasse über die Eigenschaftswerte ihrer
Attribute oder Operationen festgelegt werden. Zulässige Stereotype und
Eigenschaftswerte der jeweiligen Cartridges werden in UML-Profilen
zusammengefasst, die als XMI-Dateien importiert werden können.
Für die Formulierung von Datenbankabfragen wird OCL unterstützt. OCL-Ausdrücke
können in Abfragen für unterschiedliche Plattformen übersetzt werden.
Mit Hilfe von AndroMDA-Cartridges können zwei verschiedene Arten von Quellcode
generiert werden:
• vollständig generierten Code, der nicht manuell verändert werden sollte; dieser
Code wird bei einer erneuten Generierung neu erstellt, wodurch Änderungen
überschrieben und verloren gehen würden, sowie
• Rahmen für vom Entwickler zu schreibenden Code, der bei einer erneuten
Generierung nicht überschrieben wird. Dabei handelt es sich in der Regel um die
Geschäftslogik der Anwendung.
Aus diesen Bestandteilen entsteht die fertige Anwendung.
3.3 AndroMDA Cartridges
Cartridges stellen die zentrale Komponente zur Steuerung der Codegenerierung mit
AndroMDA dar. Mit ihrer Hilfe können Modellelemente, die mit Stereotypen
gekennzeichnet sind, oder Elemente, deren Abhängigkeit sich aus bestimmten
Konditionen ergibt, verarbeitet werden (vgl. [And06]). Über Templates wird der zu
generierende Code vorgegeben.
Jede Cartridge enthält einen Cartridge Descriptor und einen Metafacade Descriptor. Der
Cartridge Descriptor enthält Informationen in XML-Form über die Templates, die in der
Cartridge zur Verfügung stehen. Der Metafacade Descriptor definiert und steuert die
Metafacade-Klassen.
Unter [And07a] wird eine Reihe von fertigen Cartridges für folgende Technologien zur
Verfügung gestellt:
9

Kapitel 3: AndroMDA
Name
BPM4Struts
jBPM
JSF
EJB
Hibernate
Java
Meta
Spring
WebService
XmlSchema
Beschreibung
Business Process Modelling for Struts: generiert Struts-Webseiten aus
UML-Modellen, in denen Abläufe der Anwendung modelliert sind
JBOSS BPM: generiert Prozesssdefinitionen und Handler für die jBPM-
Workflow-Engine aus UML-Aktivitätsdiagrammen und Use-Case-
Diagrammen
Basiert auf dem JavaServer Faces Framework, einem serverseitigen UI
Komponenten-Framework für Java-basierte Web-Anwendungen
Enterprise JavaBeans: generiert CMP (Container Managed Persistence)
EJBs und Session Beans
Generiert das gesamte objektrelationale Mapping von AndroMDA
Generiert Java-Code
Generiert AndroMDA MetaFacades
Generiert Code basierend auf dem Spring Framework
Generiert WSDD- (Web Service Deployment Description) und WSDL-
(Web Service Definition Language) Files für Apache AXIS
Generiert XML-Schemata aus Klassendiagrammen
Tabelle 1: AndroMDA Cartridges (vgl. [Kar06])
Darüber hinaus können Anwender Cartridges für ihre eigenen Zwecke programmieren
oder bestehende Cartridges anpassen. Unter [And07a] wird eine 10-Schritt-Anleitung
zur Erstellung einer Cartridge angeboten. Demnach beinhaltet der Entwicklungsprozess
für eine Cartridge die folgenden Schritte:
Vorgehensschritt
Ergebnis
1
Zieltechnologie (PSM) Kernkonzepte und Dateiformate der
analysieren
verwendeten Technologie
2
PSM Metaklassen identifizieren, Ergebnis ist ein UML-Klassendiagramm der
entwickeln und generieren Metaklassen
3
Regeln zur Transformation von PIM-
Transformationsregeln
Elementen in PSM-Elemente, die als
identifizieren
Metafacade-Operationen implementiert sind
4
Metafacades modellieren, Die benötigten Metafacade-Klassen, in denen
generieren und schreiben Transformationsregeln enthalten sind
5 Templates schreiben Templates zum Transformieren der Inhalte
10

Kapitel 3: AndroMDA
eines Project-Objekts in eine XML-Datei (oder
ein anderes Austauschformat)
6
Deployment-Deskriptoren Die Deskriptoren des Cartridges als XMLschreiben
Dateien
7 Ein UML-Profil erstellen
Ein UML-Profil, das als
Modellierungsanleitung für Anwender dient
8
Test-Modell für die Cartridge Mit Hilfe des UML-Profils wird ein
erstellen
Testmodell erstellt
9 Cartridge testen Möglichst fehlerfreie Cartridge
10 Cartridge deployen Fertige Cartridge
Tabelle 2: Vorgehensmodell zur Erstellung einer Cartridge
Die eigenhändige Erstellung einer Cartridge erfordert eine intensive Einarbeitung in die
jeweilige Zieltechnologie und ist für unerfahrene Anwender nicht zu empfehlen.
Erfahrende Entwickler, die eine Unterstützung der von ihnen bevorzugten Technologie
vermissen, sollten jedoch in der Lage sein, eine eigene Cartridge zu schreiben oder eine
bestehende Cartridge entsprechend anzupassen. Diese sollte dann auf der
Projekthomepage von AndroMDA anderen Anwendern zur Verfügung gestellt werden.
Bei der Entwicklung eigener Cartridges sollte berücksichtigt werden, dass die Online-
Tutorials unter [And07a] unvollständig sind. Das erschwert die Einarbeitung und
erfordert u. U. intensive Recherche im Supportforum der AndroMDA-
Projekthomepage, in anderen Internet-Foren oder weiteren Quellen. Auch aus diesem
Grund ist die Entwicklung eigener Cartridges nur für erfahrene Entwickler zu
empfehlen.
11

Kapitel 4: Arbeiten mit AndroMDA
4 Arbeiten mit AndroMDA
4.1 Entwicklungsumgebung
AndroMDA wird i. d. R. über Maven gesteuert, ein Build-Tool der Apache Software
Foundation. Maven wird über ein spezielles Plugin an AndroMDA angebunden und
ermöglicht dem Anwender die Steuerung der Codegenerierung über Kommandos, die
Goals genannt werden. Die dazu benötigten Informationen werden in XML-
Dokumenten abgelegt. Maven bietet Goals für den Generierungsprozess, das
Kompilieren, Testen, das Deployen im Applikationsserver und das Erzeugen von
Datenbankschemata. Maven kann unter [Mav07] kostenlos bezogen werden und liegt in
der Version 2.0.6 vor; aus Kompatibilitätsgründen wurde für das hier beschriebene
Beispiel jedoch auf Maven 2.0.5 zurückgegriffen.
Neben Maven beinhaltet die Entwicklungsumgebung eine Reihe weiterer Werkzeuge.
So werden z. B. ein UML-Modellierungswerkzeug und eine Datenbank benötigt. Für
die Wahl eines Modellierungswerkzeugs ist entscheidend, ob die Modelle in ein von
AndroMDA unterstütztes Format exportiert werden können. Momentan unterstützt
AndroMDA UML 1.4/XMI sowie UML 2/EMF. Somit kommt eine Reihe von
Modellierungstools in Frage; die Projekthomepage von AndroMDA beinhaltet Tutorien
für folgende Tools: ArgoUML, MagicDraw 9.x, MagicDraw 11.5 und Rational
Software Modeller / Architect 6. Die Entscheidung für ein bestimmtes Produkt liegt
beim Entwickler.
Im Rahmen dieser Arbeit wurden die unter [And07a] für die Entwicklung empfohlenen
Werkzeuge gewählt. So bestand die Entwicklungsumgebung aus dem Java
Development Kit 1.0.5 (JDK 1.0.5, zu beziehen unter [Sun07]), einem JBoss
Application Server (Homepage unter [JBo07], einem MySQL Server 5.0 samt
dazugehörigen Tools (weitere Informationen unter [SQL07], sowie Eclipse (unter
[Ecl07]. Das vom AndroMDA entwickelte Eclipse-Plugin Android erleichtert die
Integration von Eclipse und AndroMDA Für das Erstellen der UML-Modelle wurde
MagicDraw Community Edition 9.5 (herunterladbar unter [Mag07]) verwendet; auf die
Verwendung von MagicDraw 11.5 wurde aus Kompatibilitätsgründen verzichtet.
12

Kapitel 4: Arbeiten mit AndroMDA
4.2 Implementierung eines Shop-Systems als Beispielanwendung
Die Beispielanwendung beschreibt eine simple Version eines Online-Shops. Es gibt
Kunden, die über eine Webseite Produkte bestellen können. Ein Kunde kann beliebig
viele Bestellungen aufgeben, die ihrerseits aus beliebig vielen Bestellpositionen
bestehen können. Bestellpositionen setzen sich aus Produkten des Online-Shops
zusammen. Die Produkte sind in einer hierarchischen Struktur kategorisiert. Abb. 3
zeigt das entsprechende Klassendiagramm.
Abbildung 3: Klassendiagramm
13

Kapitel 4: Arbeiten mit AndroMDA
Ein Kunde hat auf der Webseite die Möglichkeit, eine Bestellung anzulegen und
Bestellpositionen hinzuzufügen. Dazu wählt er aus der Produktliste ein Produkt aus,
gibt die gewünschte Menge an und fügt die Bestellposition seinem Warenkorb hinzu.
Das kann beliebig oft wiederholt werden. Ist die Bestellung vollständig, übermittelt der
Kunde seine Auswahl an den Anbieter und erhält eine Bestätigung. Beim Anlegen einer
neuen Bestellung sowie bei der Durchführung einer Bestellung muss sich der Kunde
gegenüber dem System identifizieren. Abb. 4 verdeutlicht dies in einem
Anwendungsfalldiagramm.
Abbildung 4: Anwendungsfalldiagramm
Um die Beispielanwendung zu implementieren, ist eine Reihe von weiteren UML-
Diagrammen und Klassen erforderlich, die aus Platzgründen nicht präsentiert werden
können.
Bei der Modellierung sind verschiedene Regeln zu beachten. Zum einen sollten alle
Klassen mit UML-Stereotypen verknüpft werden, weil der Prozess der Codegenerierung
auf Basis dieser Stereotype abläuft. Jedem Stereotyp entsprechen bestimmte Templates
in der jeweiligen Cartridge, aus denen Code erzeugt wird. Ferner existiert eine Reihe
von Standardregeln, um die syntaktische und semantische Korrektheit der Modelle
sicherzustellen (vgl. [And07b]). Diese entsprechen weitgehend den allgemeinen Regeln
für die Erstellung von UML-Modellen. AndroMDA-spezifisch sind u. a. folgende
Forderungen:
• Es sollten keine getter- und setter-Methoden für Attribute benutzt werden. Alle
benötigten Methoden werden während der Codegenerierung von der Cartridge
erzeugt.
14

Kapitel 4: Arbeiten mit AndroMDA
• Aus dem selben Grund sollten keine getter- und setter-Methoden für
Assoziationsenden benutzt werden.
• Für einfache Datentypen wie String oder Collection sollten allgemeine UML
Datentypen anstelle von technologie-spezifischen Typen benutzt werden. Auf
diese Weise bleiben die Modelle so weit wie möglich plattformunabhängig.
Cartridges finden mit Hilfe von Mapping-Tabellen die technologie-spezifischen
Datentypen zur Generierungszeit. Für Java beispielsweise würde die Transformation
wie folgt aussehen: String --> java.lang.String oder Collection -->
java.util.Collection.
Nach erfolgter Modellierung wurde mit Hilfe von AndroMDA automatisch Code für die
Anwendung generiert. Die dabei erzeugten Dokumente kann man grob in zwei Gruppen
gliedern: fertigen Code und Codefragmente. Codefragmente stellen dabei konkrete
Erweiterungen der automatisch erstellen Klassen dar und sollen als Container für
jeglichen zusätzlichen Code dienen, der von den Entwicklern hinzugefügt wird.
Codefragmente kann man an dem Kürzel „Impl“ im Namen erkennen, so ist z. B.
KundeImpl.java die Erweiterung für Kunde.java.
4.3 Kritische Würdigung des Entwicklungsprozesses mit AndroMDA
Nach der Implementierung der Beispielanwendung lässt der Entwicklungsprozess mit
AndroMDA sich wie folgt bewerten:
Bereits das Einrichten der Entwicklungsumgebung gestaltete sich problematisch. Eine
Vielzahl von unterschiedlichen Werkzeugen musste einzeln herunter geladen und
installiert werden. Dabei ergaben sich an mehreren Stellen Kompatibilitätsprobleme
zwischen den einzelnen Tools. So traten z. B. mehrmals Schwierigkeiten bei der
Benutzung von MagicDraw 11.5 auf, weswegen zu MagicDraw 9.5 gewechselt werden
musste. Gerade für unerfahrene Benutzer nicht trivial ist auch das notwendige manuelle
Setzen von Umgebungsvariablen und die stellenweise erforderliche Manipulation von
XML-Dokumenten.
Gerade bei auftretenden Problemen wurden die Schwächen des AndroMDA-Supports
deutlich, die durch den Open-Source-Charakter des Projekts begünstigt werden. Negativ
aufgefallen sind die stark schwankende Qualität der Dokumentation, die wenig
hilfreiche FAQ-Liste, sowie eine Reihe von „toten“ Links auf der Webseite. Die
15

Kapitel 4: Arbeiten mit AndroMDA
vorhandenen Online-Tutorials enthalten z. T. Fehler oder sind unvollständig. So bricht
die Einleitung zur Erstellung einer Cartridge nach der Hälfte der notwendigen Schritte
ab; die entsprechenden Webseiten enthalten seit März 2006 lediglich den Hinweis auf
den geplanten Inhalt. Positiv sticht das Online-Forum hervor, in dem schnell und
kompetent auf Fragen und Probleme eingegangen wird.
Der Entwicklungsprozess erfordert eine intensive Einarbeitung in die verwendeten
Werkzeuge. Gerade weil wenig Unterstützung bei auftretenden Schwierigkeiten zu
erwarten ist, sollten Werkzeuge gewählt werden, die entweder dem Entwickler gut
bekannt oder ausführlich dokumentiert sind.
Nach Bewältigung der Anfangsschwierigkeiten funktionierte die Code-Generierung mit
AndroMDA gut. Ein Großteil des Code kann automatisch aus den Modellen generiert
werden. Gerade die langwierigen, lästigen Aufgaben werden dem Entwickler
abgenommen; manuell zu implementieren ist lediglich die Geschäftslogik. Das
verringert die Entwicklungskosten und enthebt den Entwickler von der Notwendigkeit,
einen Großteil der Zeit mit eher langweiligen Standardaufgaben zu verbringen.
16

Kapitel 5: Zusammenfassung und Ausblick
5 Zusammenfassung und Ausblick
Diese Arbeit hatte das Ziel, den Entwicklungsprozess mit AndroMDA zu untersuchen.
Nach einer kurzen Darstellung von MDA wurden der Aufbau und die Funktionsweise
von AndroMDA beleuchtet; speziell hervorgehoben wurde die Rolle der Cartridges im
AndroMDA-Framework. Im zweiten Teil der Arbeit wurde ein Ausblick auf das
Arbeiten unter AndroMDA gegeben und die Implementierung einer Beispielanwendung
vorgestellt.
Zusammenfassend lässt sich sagen, dass es sich bei AndroMDA um ein mächtiges und
flexibles Werkzeug zum Einsatz von MDA in der Software-Entwicklung handelt. Eine
Vielzahl von Technologien und Plattformen wird bereits unterstützt. Wo das nicht der
Fall ist, steht es dem Anwender frei, die von ihm präferierte Technologie in das
Framework einzubinden.
Jedoch lässt die Benutzerfreundlichkeit von AndroMDA zu wünschen übrig. Die
aufwändige Installation, die mangelhafte Dokumentation und die nicht mehr zeitgemäße
Bedienung über die Kommandozeile erschweren gerade ungeübten Benutzern den
Einstieg.
Bevor über den Einsatz von AndroMDA fundiert entschieden werden kann, ist jedoch
der Vergleich mit anderen MDA-Werkzeugen angebracht. Die Flexibilität und
Anpassbarkeit von AndroMDA könnte gegenüber kommerziellen Produkten einen
großen Vorteil darstellen. Eine Verbesserung der Benutzerfreundlichkeit bleibt
abzuwarten.
17

6 Literaturverzeichnis
[And07a]
[And07b]
[Dew06]
[Ecl07]
[JBo07]
[Kar06]
[KWB03]
[Mag07]
[Mav07]
[MSUW04]
[OMG03]
[SQL07]
[Sun07]
[TBH04]
AndroMDA: Homepage.
URL: http://www.andromda.org, Abrufdatum: 12. Mai 2007
AndroMDA: Modeling for AndroMDA.
URL: http://galaxy.andromda.org/docs/modeling.html, Abrufdatum:
12. Mai 2007.
Blasius Lofi Dewanto: The Enterprise Java Open Source Architecture
Template, 2006.
URL:http://www.jaxmagazine.com/itr/online_artikel/psecom,id,653,node
id,147.html, Abrufdatum: 12. Mai 2007
Eclipse: Homepage,
URL: http://www.eclipse.org, Abrufdatum: 12. Mai 2007.
JBoss Application Server: Homepage,
URL: http://labs.jboss.com/jbossas, Abrufdatum: 12. Mai 2007.
Arnold Karner: Model Driven Architecture – Vollständige
Codegenerierung mittels AndroMDA, TU Wien, 2006.
URL:http://big.tuwien.ac.at/research/publications/diplomatheses/karner.p
df, Abrufdatum: 12. Mai 2007
Anneke Kleppe, Jos Warmer, Wim Bast: MDA Explained, The Model
Driven Architecture: Practice and Promise, Addison-Wesley, 2003.
MagicDraw: Homepage.
URL: http://www.magicdraw.com. Abrufdatum: 12. Mai 2007
Apache Maven Project: Homepage.
URL: http://maven.apache.org, Abrufdatum: 12. Mai 2007.
Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise: MDA Distilled,
Principles of Model-Driven Architecture, Addison-Wesley, 2004.
Object Management Group: Technical Guide to Model Driven
Architecture: The MDA Guide Version 1.0.1, 2003
MySQL Developer Zone: Homepage,
URL: http://dev.mysql.com, Abrufdatum: 12. Mai 2007.
Sun Developer Network: JAVA SE Downloads,
URL:http://java.sun.com/javase/downloads/index_jdk5.jsp, Abrufdatum:
12. Mai 2007.
Rainer Thome, Martin Böhn, Alexander Hagn: Model Driven
Architecture, WISU 3/04, S. 348-357, Lange Verlag, 2004.

[Vel07]
Apache Velocity Project: Homepage.
URL: http://velocity.apache.org, Abrufdatum: 12. Mai 2007.