Ausarbeitung - Institut für Wirtschaftsinformatik

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Model Driven Architecture: AndroMDA
im Rahmen des Seminars Software Engineering
Thomas Korte
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Christian Hermanns
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Inhaltsverzeichnis
1 Motivation.................................................................................................................. 1 2 Grundlagen ................................................................................................................ 2 3 2.1 Model Driven Software Development ............................................................... 2 2.2 Model Driven Architecture ................................................................................ 3 AndroMDA ................................................................................................................ 5 3.1 Überblick ............................................................................................................ 5 3.2 Komponenten ..................................................................................................... 6 3.3 Vom Modell zum Quellcode ............................................................................ 10 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 4 5 Erstellen des UML-Modells...................................................................... 11 Einlesen des Modells in das Repository ................................................... 12 Festlegung der benötigten Cartridges ....................................................... 14 Instanziierung der Metafassaden .............................................................. 15 Auswahl der Templates ............................................................................ 16 Erstellung des Quellcodes anhand der Templates .................................... 17 AndroMDA in der praktischen Anwendung............................................................ 20 4.1 Anlegen eines AndroMDA Projektes............................................................... 20 4.2 Erstellen einfacher UML-Modelle ................................................................... 21 4.3 Generierung des Quellcodes ............................................................................ 22 Zusammenfassung und Fazit ................................................................................... 24 Literaturverzeichnis ........................................................................................................ 25 II
Kapitel 1: Motivation
1 Motivation
Effiziente Geschäftsprozesse bilden das Rückgrat einer jeden erfolgreichen Firma, sind
sie doch der Kern eines jeden Unternehmens. Um eine Effizienzsteigerung zu erreichen
bietet es sich häufig an die IT-Unterstützung der Geschäftsprozesse zu verbessern.
Durch neue Techniken ergeben sich praktisch alle paar Jahre neue Möglichkeiten für
die Unterstützung durch IT. Doch genau hier liegt das Problem. Nach einer Studie für
das Jahr 2004, wurden nur 29% aller IT Projekte erfolgreich abgeschlossen [PT07].
Diese erschreckend niedrige Quote resultiert zum einen aus illusorischen Fristen und zu
kleinen Budgets, zum anderen aus den ständig steigenden Anforderungen an die
Software und dem damit verbundenen Komplexitätsanstieg. Da jedoch Fristen und
Budget fast immer fixiert sind, kann als Ausgleich nur noch die Qualität der Software
sinken. Neue, den Entwicklungsprozess unterstützende Techniken sind somit gefragt.
Zwar wurden in den letzten Jahren, durch Entwicklungen wie Entwurfsmuster und
Objektorientierte Sprachen, Fortschritte für den Entwicklungsprozess eines Projekts
erreicht, dennoch wird dieser immer noch durch viele sich wiederholende Aufgaben
geprägt. An dieser Stelle setzt die modellgetriebene Softwareentwicklung an, indem sie
Teile der Anwendung selbständig generiert. Dabei handelt es sich vornehmlich um die
Teile, die ausschließlich Fleißarbeit für die Entwickler bedeuteten. Durch die
Generierung dieser Teile, kann sich der Entwickler voll und ganz auf die
Implementierung der Geschäftslogik konzentrieren.
Basis des modellgetriebenen Vorgehens ist das Modell der zu erstellenden Anwendung.
Häufig werden die Modelle nur zu Beginn eines Projektes erstellt, um zu sehen wohin
die Reise gehen soll. Sie dienten nur als Spezifikation und Dokumentation. Sobald mit
der Implementierung gestartet wurde, gerieten sie häufig vollständig in Vergessenheit
bzw. mussten mühsam im Nachhinein angepasst werden. Da die Modelle nun im Fokus
des Entwicklungsprozesses stehen, sind sie automatisch aktuell. Dies führt zu weniger
Wissensbindung durch Mitarbeiter und erleichtert die Einarbeitung neuer Mitarbeiter.
Diese können anhand der aktuellen Modelle deutlich schneller produktiv an dem
Entwicklungsprozess mitwirken.
1
Kapitel 2: Grundlagen
2 Grundlagen
2.1 Model Driven Software Development
Die modellgetriebene Softwareentwicklung (Model Driven Software Development,
MDSD) hat zum Ziel, möglichst viele Artefakte einer zu erstellenden Software
generativ aus formalen Modellen abzuleiten [PT07]. Da nach [PM06] Artefakte
Arbeitsergebnisse sind, die während eines Projektes produziert und benutzt werden,
bedeutet dies, dass nicht nur der eigentliche Quellcode in großen Teilen automatisch
generiert wird, sondern auch weitere wichtige Dokumente und Dateien generativ erstellt
werden (z.B. Konfigurationsdateien, Dokumentationen, Datenbankskripte).
[GPR06] und [PM06] sehen in der modellgetriebenen Entwicklung eine logische
Konsequenz aus dem im Laufe der Zeit immer weiter steigenden Abstraktionsgrad von
Programmiersprachen. Wie Abbildung 1 verdeutlicht, stehen Modellierungssprachen
am derzeitigen Ende der Entwicklung von Programmiersprachen.
Modellierungs
sprachen
Abstraktionsgrad
Objektorientierte
Sprachen
Prozedurale
Sprachen
AssemblerSprache
Maschinensprache
Zeit
Abbildung 1: Entwicklung von Programmiersprachen nach Abstraktionsgrad
Der Grund für das Steigen des Abstraktionsgrads liegt nach [GPR06] in der steigenden
Komplexität der Softwareentwicklung begründet. Steigt die Komplexität auf ein nicht
mehr zu beherrschendes Ausmaß an, so war in der Vergangenheit ein Sprung auf die
nächst höhere Abstraktionsstufe die Lösung. Nach dem gleichen Prinzip ist der Sprung
hin zu den Modellierungssprachen als Entwicklungssprache nur logisch.
2
Kapitel 2: Grundlagen
An dieser Stelle setzt die modellgetriebene Softwareentwicklung an, indem sie aus
formalen Modellen, die mithilfe von Modellierungssprachen erstellt wurden, generativ
große Teile der zu entstehenden Software erzeugt. Dieses Vorgehen hat den Vorteil,
dass Änderungen nicht mehr am Quellcode selber erfolgen, sondern in den
vorgelagerten Modellen durchgeführt werden. Hieraus ergibt sich, dass die bisher fast
ausschließlich zur Spezifikation und Dokumentation erstellten Modelle automatisch
konsistent gehalten werden und somit einen wesentlich leichteren Einstieg in den
Entwicklungsprozess ermöglichen.
2.2 Model Driven Architecture
Auf Basis der Idee des MDSD hat die Object Management Group (OMG) ein
Framework für eben dieses modellgetriebene Vorgehen bei der Softwareentwicklung
vorgestellt, die Model Driven Architecture (MDA). Im Jahr 2003 veröffentlichte die
OMG eine MDA Spezifikation [OMG03], die jedoch nach Ansicht vieler Autoren auch
heute noch wenig konkret ist (vgl. [PT07] S. 14 und [GPR06] S. 23). Es handelt sich
somit weniger um eine genaue Spezifikation, als vielmehr um ein Konzept für
modellgetriebenes Vorgehen.
Kern des MDA Frameworks sind Modelle mit unterschiedlichen Abstraktionsebenen:
•
Computation Independent Model (CIM): Hierbei handelt es sich um eine
umgangssprachliche Beschreibung von Zusammenhängen und Anforderungen der
gewünschten Anwendung, ohne auf Details der Implementierung einzugehen.
Technische Zusammenhänge entfallen somit vollständig. Vielmehr stellt das CIM
eine Brücke zwischen zwei Welten dar; dem Domänenexperten auf der einen und
dem Design- und Konstruktionsexperten auf der anderen Seite.
•
Platform Independent Model (PIM): An dieser Stelle wird die Anwendung mit
einem formalen Modell beschrieben, welches implementierungstechnische Details
enthält. Es bleibt jedoch unabhängig von der einzusetzenden Plattform und stellt
somit ein generisches Modell dar.
•
Platform Specific Model (PSM): Das PSM ist im Wesentlichen ein um technische
Details einer spezifischen Plattform (z.B. Java oder .Net) erweitertes PIM.
Beispielsweise werden erst an dieser Stelle die Datentypen der konkreten Plattform
verwendet.
3
Kapitel 2: Grundlagen
Für den Schritt vom PIM hin zum implementierten Quellcode, gibt es im Wesentlichen
zwei Wege. Zum einen über das PSM, zum anderen direkt vom PIM zum Code.
Abbildung 2 illustriert diese zwei Varianten.
Abbildung 2: Transformationsschritte der MDA
Für den Weg über das PSM wird unter anderem ein metamodellbasiertes Vorgehen
propagiert [OMG03, Abschnitt 3.10.2], das mit Hilfe von Metamodellen der beteiligten
Modelle Transformationsregeln für die Überführung des PIM in das PSM festlegt. Wie
dies im Einzelnen ablaufen soll, wird nicht genau spezifiziert. Die OMG liefert jedoch
an dieser Stelle mit ihrer Query/View/Transformation Spezifikation [OMG08] eine
umfassende Lösung für das Problem der model-to-model Transformation. QVT gehört
zu der Meta Object Facility (MOF) [OMG06], einer Architektur, die ein
Metametamodell für Modellierungssprachen darstellt. Die OMG stellt mit QVT einen
Standard bereit, mit dem Abfragen und Transformationen auf (Meta-)Modellen definiert
werden [Boh06]. Ziel ist es unter anderem, Modelle durch eine explizite
Abfragesprache (Queries) und der daran angelehnten Transformationsbeschreibung zu
transformieren [PT07, S. 71]. Dieses Vorgehen über das PSM, sollte im Rahmen der
MDA den Normalfall darstellen.
Die zweite Variante kommt ohne das PSM als Zwischenschritt aus. Für diese model-tocode Transformation direkt aus dem PIM, wird häufig ein auf Templates basierendes
Verfahren angewendet. Mithilfe dieser Templates (Schablonen) der Zielsprache, wird
das PSM durch eine Template Engine, wie beispielsweise Velocity [Vel08], in den
eigentlichen Code überführt. Das PIM wird zu diesem Zweck häufig um wenige
plattformspezifische Informationen erweitert. Dieser Punkt wird jedoch von [GPR06]
kritisiert, weil somit die Trennung von Technik und Fachlichkeit geopfert wird. Es wird
von einer Verunreinigung des Modells mit technischen Informationen gesprochen
[GPR06, S. 179]. In den meisten MDA-Tools wird heutzutage die zweite Variante
umgesetzt, da die sehr umständliche model-to-model Transformation häufig Probleme
bereitet. Abgedeckt werden beide Varianten durch die MDA Spezifikation der OMG
[OMG03, Abschnitt 3.6 und Abschnitt 3.7]].
4
Kapitel 3: AndroMDA
3 AndroMDA
3.1 Überblick
Bei AndroMDA handelt es sich um einen Open-Source MDA Generator, der in Java
entwickelt wurde und unter der BSD-Lizenz steht. Er bezieht UML-Modelle als Input
und liefert Quellcode als entsprechenden Output. Eine Entwicklungsumgebung oder ein
Modellierungstool für die Erstellung der UML-Modelle sind nicht Bestandteil des
Frameworks und müssen separat zur Verfügung gestellt werden. Zwar kann
AndroMDA prinzipiell direkt über die Konsole angesprochen und bedient werden,
jedoch wird von den Entwicklern dringend die Verwendung eines Build-ManagementTools empfohlen [Ando8b]. Hier wird dem Anwender explizit das Tool Maven nahe
gelegt, da es hierfür schon eine Reihe von Plugins gibt, die die Verwendung von
AndroMDA wesentlich vereinfachen.
Zu beziehen ist AndroMDA über das Webportal Sourceforge, wo eine Vielzahl von
Open Source Projekten verwaltet werden. Auf der Projekthomepage [And08] befinden
sich einige Tutorials, sowie Dokumentationen zu den einzelnen Komponenten von
AndroMDA. Es sei schon an dieser Stelle angemerkt, dass die Dokumentation von
AndroMDA weder aktuell noch vollständig ist, und somit nicht als zufriedenstellend
bewertet werden kann. Positiv herauszuheben ist jedoch das Supportforum [And08a]
des Projekts, über welches der Anwender bei konkreten Problemen Hilfe von
Entwicklern und anderen Anwendern bekommt.
Prinzipiell erstellt AndroMDA Quellcode für beliebige Zielplattformen und
Programmiersprachen wie Java und .Net. Diese Variabilität wird durch den Einsatz
auswechselbarer Module, sogenannten Cartridges, erreicht. Vereinfacht ausgedrückt
geben die Cartridges dem Generator vor, wie der zu generierende Quellcode aussehen
muss, um den Anforderungen einer bestimmten Zielplattform bzw. Programmiersprache
zu entsprechen.
Das momentan aktuelle Release von AndroMDA ist Version 3.3 final, welche im April
2008 veröffentlicht wurde. Die Veröffentlichung der Vorgängerversion 3.2 final lag zu
diesem Zeitpunkt eineinhalb Jahre zurück. Auch an einem komplett neuen Release 4.0
wurde gearbeitet, jedoch liegt dieses zurzeit auf Eis. Im Supportforum wird als Grund
für den momentanen Stillstand genannt, dass ein Entwickler der ersten Stunde das
5
Kapitel 3: AndroMDA
Projekt verlassen hat [And08a]. Die letzte Nachricht von Version 4.0 wurde im Mai
2007 in Form einer Preview auf den aktuellen Entwicklungsstand veröffentlicht.
Desweiteren gibt es Bestrebungen unter dem Namen Android, eine AndroMDA IDE als
Plugin für Eclipse zu entwickeln. Android erleidet jedoch momentan das gleiche
Schicksal wie AndroMDA 4.0. Das letzte Lebenszeichen von Android gab es im Juni
2006 in Form einer Preview mit der Versionsbezeichnung 0.0.5 [And08c].
3.2 Komponenten
Bevor im Anschluss in Kapitel 3.3 der Weg vom Modell zum generierten Code im
Detail erläutert wird, wird an dieser Stelle zunächst kurz auf die verschiedenen
Komponenten des AndroMDA Frameworks eingegangen. Die genaue Funktionsweise
der Komponenten und deren Zusammenspiel untereinander, ist ebenfalls Gegenstand
von Kapitel 3.3
AndroMDA Core
Da es sich bei AndroMDA um ein Framework handelt, das aus vielen Komponenten
besteht, muss die Zusammenarbeit eben dieser Komponenten koordiniert werden. Dies
ist Aufgabe des Kerns, welcher die Konnektoren der Komponenten beinhaltet. Über
einen Plugin-Discovery-Mechanismus erkennt AndroMDA automatisch im Klassenpfad
verfügbare Plugins, wie beispielsweise Cartridges und Translation Libraries. [PM06]
Cartridges
Die Cartridges sind der wichtigste Teil des Frameworks. Sie legen fest, wie aus einem
gegebenen PIM, vorliegend als UML-Modell, der angestrebte Quellcode generiert wird.
Doch es ist nicht nur eine Cartridge, die für den Code eines gesamten Projekts
verantwortlich ist. Jede Cartridge ist nur für eine Zielarchitektur zuständig. So gibt es
eine Reihe von verschiedenen Cartridges mit denen AndroMDA von Haus aus bestückt
ist. In Tabelle 1 werden die mitgelieferten Cartridges kurz und übersichtlich dargestellt
und deren Einsatzzweck erläutert.
Anhand der mitgelieferten Cartridges erkennt man schnell, das AndroMDA speziell für
den Einsatz im Rahmen von JavaEE Projekten erdacht wurde. Es gibt zwar auch eine
.Net Cartridge inklusive einer kleinen Einführung in die Erstellung eines .Net Projektes,
jedoch existiert keine Dokumentation zu der Cartridge an sich. Das Hauptaugenmerkt
von AndroMDA liegt somit bislang eindeutig auf Java als Programmiersprache.
6
Kapitel 3: AndroMDA
Name
Beschreibung
BPM4Struts
BPM4Struts steht für „Business Process Modeling for Struts“. Diese
Cartridge erstellt aus UML Aktivitätsdiagrammen und UML
Anwendungsfalldiagrammen (Use-Cases) Struts-konforme
Webapplikationen.
jBPM
Bei jBPM handelt es sich um eine Workflow-Engine die zur jBoss
Produktlinie gehört [jBPM08]. Diese Cartridge generiert
Prozessdefinitionen und Handler für jBPM aus UML
Aktivitätsdiagrammen.
JSF
Erstellt Komponenten für die JavaServer Faces Technologie [JSF08]
EJB
Generiert CMP Entity Beans für die Datenschicht und/oder Sessions
Beans für die Geschäftslogikschicht.
Hibernate
Dient dazu, eine komplette Hibernate Datenschicht zu erstellen.
[Hib08]
Java
Generiert grundsätzliche Java Objekte aus statischen
UML-Modellen
Meta
Erlaubt das Erstellen von Modellen für Metafassaden in UML, aus
welchen die eigentlichen Metafassaden generiert werden können.
Spring
Mithilfe dieser Cartridge lassen sich Spring Komponenten für die
Geschäftslogik erstellen [Spr08]. Sie muss zusammen mit der
Hibernate Cartridge verwendet werden, um die Datenschicht zu
gewährleisten.
WebService
Erstellt WSDD und WSDL Dateien für Apache Axis [Axis08]
XML-Schema
Generiert XMl-Schemata aus Klassenmodellen
Tabelle 1: In AndroMDA standardmäßig verfügbare Cartridges
Für jede der drei typischen Schichten einer Enterprise Applikation, gibt es
entsprechende Cartridges. So lässt sich die Datenschicht entweder mit der Hibernate
oder mit der EJB (CMP Entity Beans) Cartridge erstellen. Für die Geschäftslogikschicht
stellt AndroMDA die Spring Cartridge oder wiederum die EJB Cartridge zur
Verfügung. Die Präsentationsschicht kann mithilfe der BPM4Struts oder der JSF
7
Kapitel 3: AndroMDA
Cartridge erzeugt werden. Hier ist festzustellen, dass bis jetzt lediglich Cartridges für
Weboberflächen mitgeliefert werden.
AndroMDA ist jedoch nicht auf die mitgelieferten Cartridges beschränkt. Vielmehr
erlaubt das Framework das Verändern und Überschreiben vorhandener Cartridges. Aber
auch das komplette Selbsterstellen und Einbinden von Cartridges ist möglich.
Erläuterungen zum Vorgehen finden sich in [And08b].
Die Bestandteile einer Cartridge sind im hautpsächlich XML-Deskriptoren, diverse
Metafassaden als Java Klassen und die benötigten Templates zur eigentlichen
Codegenerierung. Diese Bestandteile befinden sich gepackt in einem JAR-Archiv,
welches wiederum die Cartridge darstellt.
Der wichtigste Deskriptor ist der Cartridge Deskriptor, der in Form einer
cartridge.xml daher kommt. In ihm werden das Verhalten und der
Leistungsumfang der Cartridge beschrieben. Dazu zählt, dass alle zur Verfügung
stehenden Ressourcen an dieser Stelle zugeordnet werden. So werden alle benötigten
Templates eingebunden und es wird festgelegt, welche Metafassaden sie verwenden um
auf die Modellelemente zugreifen zu können [Loew07].
Ein zweiter wichtiger Deskriptor ist die metafacades.xml. Er sorgt dafür, dass den
Metafassaden die entsprechenden Modellelemente anhand ihrer Stereotype zugeordnet
werden [Loew07].
Die profile.xml enthält eine vollständige Aufzählung und Beschreibung der von
der Cartridge unterstützen Stereotype und Eigenschaftswerten und ordnet die im Modell
verwendete Bezeichnung der internen Bezeichnung zu [PM06].
Translation-Libraries
Die Translation-Libraries dienen dazu, den an Modellen angefügten OCL-Code in eine
für die Zielplattform geeignete Sprache (z.B. Java oder SQL) zu übersetzen. OCL
bedeutet Object Constraint Language und ist Teil der UML Sprachfamilie. Mit OCL
können beispielsweise dynamische Aspekte in Form von Bedingungen an UMLDiagramme angefügt werden.
8
Kapitel 3: AndroMDA
Metafassaden
Der Begriff Metafassade steht für Metamodell-Fassade. Wie schon am Begriff zu
erkennen, handelt sich dabei um eine Ausprägung des Entwurfsmusters Fassade, dessen
Aufgabe es ist, eine vereinfachte Schnittstelle für den Zugriff auf ein System
bereitzustellen. So ist es Ziel der Metafassaden, die Komplexität des Metamodells vor
den
Templates
zu
verbergen
und
eine
vereinfachte
Schnittstelle
auf
die
Metamodellinstanzen anzubieten. AndroMDA stellt in seinem Kern bereits ein Set von
Metafassaden bereit, welche wichtige Methoden für den Zugriff auf das UML-Modell
bereitstellt. Zusätzlich enthalten die Cartridges eigene interne Metafassaden, welche die
Basis-Metafassaden um Methoden ergänzen, die speziell von den in der Cartridge
enthaltenen Templates benötigt werden. Abbildung 2 illustriert den Sachverhalt
anschaulich.
Die
Basis-Metafassaden
(UML
common)
implementieren
die
verschiedenen unterstützen UML-Metamodelle (UML 1.4, UML 1.3 und UML 2.0) und
werden durch den Einsatz der Cartridge-Metafassaden erweitert.
Abbildung 3: Zusammenspiel der Metafassaden. Übernommen aus [And08b]
9
Kapitel 3: AndroMDA
Ein weiterer Vorteil der Metafassaden als Schnittstelle zu den Metamodellinstanzen ist,
dass eine Unabhängigkeit gegenüber dem zugrundeliegenden Metamodell besteht. Dem
Template, welches nur die Methoden der Metafassade kennt, ist es egal, ob es sich um
ein UML 1.4 oder ein UML 2 Modell handelt. Desweiteren können über die
Metafassaden dynamische Aspekte, wie etwa Logikoperationen, bei der Generierung
wahrgenommen werden.
Repositories
Repositories dienen AndroMDA dazu, ein gegebenes (UML-)Modell in den Speicher zu
lesen und für die weitere Verarbeitung persistent zu halten. Bis Version 3.2 konnte
AndroMDA nur UML 1.4 Modelle verarbeiten. Zu diesem Zweck gibt es das
mitgelieferte Netbeans Meta Data Repository (MDR) [MDR08]. Seit Version 3.2 gibt es
über das Eclipse Modeling Framework (EMF) [EMF08] eine Unterstützung für Modelle
basierend auf UML2.
Template Engines
Für die Erzeugung von Code mithilfe von Templates wird eine sogenannte Template
Engine benötigt. Sie sorgt dafür, dass die in den Templates integrierten
Methodenaufrufe der Metafassaden durchgeführt werden, und somit die entsprechenden
Informationen aus den Modellelementen ausgelesen werden. Die Template Engine füllt
sozusagen das Template mit Informationen und gibt den daraus entstehenden Quellcode
aus. Bei den Versionen 2.x von AndroMDA war Apache Velocity als Template Engine
noch fest integriert. Bei Versionen 3.x ist Velocity zwar immer noch Bestandteil, jedoch
bietet sich hier die Möglichkeit, andere Template Engines einzusetzen.
3.3 Vom Modell zum Quellcode
Um das Zusammenspiel der Komponenten und die generelle Funktionsweise von
AndroMDA besser zu verstehen, ist zu Beginn eine Übersichtsgrafik hilfreich, auf die
im weiteren Verlauf des Kapitels bei Verständnisproblemen zurückgegriffen werden
kann. In Abbildung 2 werden die Zusammenhänge der AndroMDA Komponenten
dargestellt.
10
Kapitel 3: AndroMDA
Abbildung 4: Übersicht des Zusammenspiels der AndroMDA Komponenten
3.3.1 Erstellen des UML-Modells
Der erste Schritt auf dem Weg zum Quellcode ist das UML Modell der zu entwerfenden
Anwendung. Damit das UML-Modell eine AndroMDA konforme Gestalt hat, wird zum
Modellieren ein AndroMDA-eigenes UML-Profil verwendet. Durch das UML-Profil
11
Kapitel 3: AndroMDA
wird beispielsweise vorgegeben, welche Stereotype, Eigenschaftswerte und Datentypen
verwendet werden dürfen.
Die Stereotype dienen dazu, die Modellelemente zu klassifizieren. Soll beispielsweise
eine Klasse modelliert werden, die später eine Tabelle in einer relationalen Datenbank
darstellen soll, so bekommt sie das Stereotyp «Entity». Dies kennzeichnet die Klasse
als persistente Klasse.
Die Eigenschaftswerte (Tagged Values) dienen dazu, dem Modell weitere
Informationen hinzuzufügen. So kann einer persistenten Klasse beispielsweise mit auf
den Weg gegeben werden, welchen Namen die entsprechende Tabelle in der Datenbank
haben soll. Leider schränken die Eigenschaftswerte die Plattformunabhängigkeit des
erstellten Modells ein. Da sie jedoch optional sind, kann sich der Entwickler im
Vorhinein überlegen, ob sein Modell plattformunabhängig bleiben soll.
Unterstützt wird die Plattformunabhängigkeit hingegen durch die Verwendung von
plattformunabhängigen Datentypen. Über Mapping Dateien in den einzelnen Cartridges
werden die Datentypen des UML Profils in die Datentypen der Zielplattform übersetzt.
Weiterhin wird in [And08b] eine Reihe von Modellierungskonventionen festgelegt, die
beim modellieren einzuhalten sind. Dazu zählen auf den ersten Blick selbstverständliche
Hinweise, z.B. dass jedem Attribut zwingend einen Datentyp zugewiesen werden muss,
aber auch wichtigere Konventionen gehören dazu. So dürfen dem Modell beispielsweise
keine
getter-
und
setter-Methoden
hinzugefügt
werden,
da
diese
im
Generierungsprozess automatisch erstellt werden.
3.3.2 Einlesen des Modells in das Repository
Nach der Modellierung wird das UML-Modell dem entsprechenden Repository
übergeben. Bei UML 1.4 Modellen erfolgt dies, indem das Modell im XMI Format
(XML Metadata Interchange) abgespeichert wird und so direkt von der Netbeans MDR
interpretiert werden kann. UML 2.0 Modelle müssen zunächst von einem geeigneten
Modellierungstool oder einem anderen Programm mit Konvertierungsfunktion in den
EMF/UML2 Standard exportiert werden, bevor das EMF Repository mit diesen arbeiten
kann.
Im Folgenden sei am Beispiel des Netbeans MDR kurz erläutert, wie ein Repository im
Wesentlichen arbeitet. Zunächst benötigt das MDR das Metamodell der verwendeten
12
Kapitel 3: AndroMDA
Modellierungssprache, in diesem Fall das UML 1.4 Metamodell. Für dieses Metamodell
werden auf Basis von JMI (Java Metadata Interchange) [JMI08] Java Interfaces erstellt,
die den Zugriff auf Objekte des Metamodells erlauben. Für jedes Objekt des
Metamodells wird ein eigenes Java Interface generiert. Im Falle von UML gäbe es
somit, vereinfacht ausgedrückt, Interfaces für (UML-)Klassen, Attribute, Operationen
(Methoden), Assoziationen, etc. [Tho05].
Um das eigentliche Modell nun in das MDR einzulesen, wird es als Metamodellinstanz
im XMI Format benötigt. Metamodellinstanz bedeutet, dass alle Elemente aus denen
das Modell besteht, als Instanzen der jeweiligen Metamodellobjekte dargestellt werden.
Beispielsweise ist jedes im Modell vorkommende Attribut eine Instanz des Objekts
„Attribut“ des Metamodells. Auf Basis dieser Metamodellinstanz erstellt das MDR eine
interne Repräsentation des Modells in Form eines Abstract Syntax Tree (AST). Jeder
Knoten dieses Baums, also jedes Objekt bzw. Element der Metamodellinstanz wird
durch ein eigenes Java Objekt repräsentiert. An dieser Stelle kommen nun die erstellten
Java Interfaces ins Spiel, denn jedes dieser Java Objekte muss das entsprechende Java
Interface implementieren, damit ein sicherer Zugriff von außen gewährleistet ist. Da das
UML-Metamodell jedoch sehr komplex ist, bietet es sich an, dass die Templates später
bei der Codegenerierung über vereinfachte Schnittstellen auf die Objekte der
Metamodellinstanz zugreifen. Diese Schnittstellen sind die bereits im vorherigen
Kapitel erwähnten Metafassaden, von denen die AndroMDA Engine zur Laufzeit
Instanzen erzeugt. Abbildung 5 zeigt, wie der Zugriff auf ein Objekt der
Metamodellinstanz funktioniert.
Abbildung 5: Der Einsatz von Metafassaden. Übernommen aus [And08b].
13
Kapitel 3: AndroMDA
Bei der mit dem Stereotyp «metafacade» gekennzeichneten Klasse mit dem Namen
ClassifierFacade, handelt es sich um eine Metafassade, die zu den im Kern von
AndroMDA befindlichen Basis-Metafassaden gehört. Über diese Metafassade greift die
Template Engine bei der Codegenerierung auf die Classifier Objekte der
Metamodellinstanz zu. Zum besseren Verständnis: Bei Classifier handelt es sich
unter anderem um eine Oberklasse von Class, welche für jede Klasse aus einem
UML-Klassendiagramm instanziiert wird. Wie in Abbildung 5 zu sehen, delegiert die
Metafassade den Zugriff weiter an das JMI Java Interface namens Classifier.
Dieses Interface wird von der eigentlichen Implementierung des Metamodellobjekts,
der Klasse ClassifierImpl, implementiert. An dieser Stelle kann die Frage
aufkommen, warum das eigentliche Objekt des Metamodells nicht den Namen
Classifier, sondern ClassifierImpl trägt. Der Grund dafür ist, dass bei
Zugriffen von außen nach einem Objekt Classifier gesucht wird. Da der Zugriff
aber über das Interface erfolgen soll, muss dieses stattdessen den Namen Classifier
tragen.
3.3.3 Festlegung der benötigten Cartridges
Mittels der Java Interfaces, traversiert AndroMDA nun über den Objektbaum und prüft,
um welche Arten von Objekten es sich handelt. Anhand der Stereotype erkennt
AndroMDA welche Cartridges benötigt werden und weist ihnen die entsprechenden
Metafassadeninstanzen
zu,
welche
stellvertretend
für
die
Objekte
der
Metamodellinstanz stehen. Stößt die AndroMDA Engine beispielsweise auf eine Klasse,
die mit dem Stereotyp «Service» gekennzeichnet ist, durchsucht sie die in dem
Projekt eingebundenen Cartridges und stellt fest, welche dieser Cartridges für eine
Klasse mit dem Stereotyp «Service» verantwortlich ist. Von den in AndroMDA
enthaltenen Cartridges wären dies entweder die EJB oder die Spring Cartridge. Welche
es im konkreten Fall ist, hängt davon ab, welche von beiden im Klassenpfad des
Projekts eingebunden ist.
Nehmen wir für den weiteren Verlauf an, es würde sich um die Spring Cartridge
handeln. Anhand der profile.xml der Cartridge, erkennt die AndroMDA Engine,
für welche Stereotype die Cartridge verantwortlich ist. Der folgende Auszug aus der
profile.xml zeigt die Beschreibung der beiden Stereotype «Service» und
«Entity»:
14
Kapitel 3: AndroMDA
<elementGroup name="Stereotypes">
<element name="ENTITY">
<documentation>
[…]
</documentation>
<value>Entity</value>
<appliedOnElement>class</appliedOnElement>
</element>
<element name="SERVICE">
<documentation>
[…]
</documentation>
<value>Service</value>
<appliedOnElement>class</appliedOnElement>
</element>
</elementGroup>
Neben einer textuellen Beschreibung, was mit dem Stereotyp gekennzeichnet wird
(wurde aus Platzgründen weggelassen), wird in der profile.xml zusätzlich ein
Mapping der Bezeichnungen festgelegt. Die Stereotype in den UML-Modellen werden
«Service» und «Entity» geschrieben. Intern in den Metafassaden wird die
Bezeichnung jedoch vollständig in Großbuchstaben verwendet, so wie es das
<element name> Tag vorgibt. Das Tag <appliedOnElement> gibt an, bei
welchen Modellelementen das Stereotyp verwendet wird. In diesem Fall handelt es sich
um Stereotype für UML-Klassen.
3.3.4 Instanziierung der Metafassaden
Nun weiß die Engine, dass die Spring Cartridge verwendet wird, um aus der Klasse mit
dem Stereotyp «Service» eine dem Spring Framework entsprechende Java-Klasse zu
generieren.
Sie
weist
der
Cartridge
die
Zuständigkeit
in
Form
von
Metafassadeninstanzen zu, welche stellvertretend für die Modellelemente stehen. Von
welchen
Metafassaden
die
Engine
Instanzen
erstellen
muss,
steht
in
der
metafacades.xml. Wird zu diesem Zweck die metafacades.xml der Spring
Cartridge betrachtet, so entdeckt man folgenden Eintrag:
<metafacade class="org.andromda.cartridges.spring.metafacades.
SpringServiceLogicImpl" contextRoot="true">
<mapping>
<stereotype>SERVICE</stereotype>
</mapping>
[…]
</metafacade>
15
Kapitel 3: AndroMDA
Für eine beim Traversieren des Objektbaums gefundene Klasse mit dem Stereotyp
«Service», wird eine Instanz der Metafassade SpringServiceLogicImpl
erstellt.
3.3.5 Auswahl der Templates
Um mit der eigentlichen Codegenerierung zu beginnen, prüft die Cartridge anhand des
Cartridge Deskriptors cartridge.xml, welches Template von der Template Engine
zu verarbeiten ist. Der Cartridge Deskriptor enthält eine Aufzählung sämtlicher
verfügbarer Templates und prüft nun für jedes dieser Templates, ob die Bedingungen
zutreffen, die für das Erzeugen von Quellcode aus den Templates notwendig sind.
Beispielhaft werden im Folgenden zwei Einträge aus der langen Liste aller Templates
dargestellt, um die Arbeitsweise zu veranschaulichen.
<template
path="templates/spring/richclient/SpringClientTest.vsl"
outputPattern="$generatedFile"
outlet="client-test"
overwrite="false"
outputOnEmptyElements="false">
<modelElements>
<modelElement variable="service">
<type name="org.andromda.cartridges.spring.metafacades.
SpringService">
<property name="remotable"/>
[…]
</type>
</modelElement>
</modelElements>
</template>
<template
path="templates/spring/SpringService.vsl"
outputPattern="{0}/{1}.java"
outlet="service-interfaces"
overwrite="true">
<modelElements variable="service">
<modelElement>
<type name="org.andromda.cartridges.spring.metafacades.
SpringService">
<property name="configonly">false</property>
<property name="private">false</property>
</type>
</modelElement>
</modelElements>
</template>
Der erste Eintrag stellt ein Template dar, welches wegen nicht zutreffender
Bedingungen nicht ausgeführt werden würde. Aus Platzgründen wird an dieser Stelle
16
Kapitel 3: AndroMDA
nicht auf jedes einzelne Tag eingegangen. Informationen über die verwendeten Tags
liefert [And08b]. Damit ein Template zur Ausführung in die Template Engine gelangt,
muss ein entsprechendes Modellelement existieren, welches mithilfe dieses Templates
in Quellcode transformiert werden soll. Dies wiederum bedeutet, dass es eine
entsprechende
Metafassadeninstanz
geben
muss,
welche
stellvertretend
das
Modellelement darstellt. Das <type> Tag innerhalb des Tags <modelElement> gibt
an, von welcher Metafassade eine Instanz benötigt wird. In diesem Fall ist dies eine
Instanz der Metafassade SpringService. Dabei handelt es sich um ein Interface,
welches von der SpringServiceLogicImpl implementiert wird. Von dieser
Metafassade, wurde bereits eine Instanz erstellt. Die Bedingung, dass für das Template
ein entsprechendes Modellelement existieren muss, trifft also zu.
Durch das <property> Tag können noch weitere Bedingungen formuliert werden. In
dem dargestellten Auszug des Cartridge Deskriptors, ist eine zusätzliche Bedingung
festgelegt. Diese Bedingung fordert, dass es sich um eine Klasse handelt, die bei der
Modellierung über einen Eigenschaftswert als remotable deklariert worden ist. Für
unseren konkreten Fall wird festgelegt, dass der Service (darum handelt es sich bei dem
Modellelement übrigens) nicht remotable ist. Die Bedingung trifft also nicht zu.
Dies führt dazu, dass aus diesem Template kein Quellcode entsteht.
Angenommen, der zu generierende Service habe die Sichtbarkeit public, so würde
das Template, welches im zweiten Eintrag definiert wird, ausgeführt werden, und eine
Java Klasse würde enstehen. Denn hier trifft zusätzlich die Bedingung zu, dass es sich
nicht um eine Klasse mit der Sichtbarkeit private handelt.
3.3.6 Erstellung des Quellcodes anhand der Templates
Ausgeführt wird die eigentliche Codegenerierung über die Template Engine.
AndroMDA benutzt dafür standardmäßig die Velocity Engine [Vel08]. Deren
Sprachumfang
beschränkt
Variablenoperationen,
sich
Schleifen,
im
Wesentlichen
Verzweigungen
auf
und
Anweisungen
wie
Zeichenkettenoperationen.
Zusätzlich dazu besteht die Möglichkeit, Java Methoden aus einem Template heraus
aufzurufen [Loew07]. Diese Möglichkeit erlaubt den Zugriff aus den Templates, über
die Metafassaden, auf die Informationen der Modellelemente.
Ein Template hat im Wesentlichen die Struktur, die auch die daraus entstehende Klasse
haben muss. Zusätzlich zu den festen Java Fragmenten sind sowohl Anweisungen aus
17
Kapitel 3: AndroMDA
dem Velocity Sprachumfang integriert, also auch Aufrufe von Methoden der
Metafassade. Das folgende Template dient der Erstellung eines Spring Service
Interfaces.
// license-header java merge-point
//
// Attention: Generated code! Do not modify by hand!
// Generated by: SpringService.vsl in andromda-spring-cartridge.
//
#if ($stringUtils.isNotBlank($service.packageName))
package $service.packageName;
#end
/**
$service.getDocumentation(" * ")
*/
public interface $service.name
#if ($service.generalization)
extends $service.generalization.fullyQualifiedName
#if (!$service.interfaceAbstractions.empty)
, $service.implementedInterfaceList
#end
#else
#if (!$service.interfaceAbstractions.empty)
extends ${service.implementedInterfaceList}
#end
#end
{
##do generate operation declarations for all implemented service
##interfaces as well when spring transactions are enabled
##(workaround for spring MethodMapTransactionAttributeSource,
##which does no map inherited interface methods)
#if
($enableSpringTransactionsWhenEjbsEnabled.equalsIgnoreCase("true
") || !$ejbsEnabled)
#set ($serviceOperations = $service.implementationOperations)
#else
#set ($serviceOperations = $service.operations)
#end
#foreach ($operation in $serviceOperations)
/**
$operation.getDocumentation("
* ")
*/
#if ($operation.exceptionsPresent)
$operation.visibility
$operation.returnType.fullyQualifiedName
$operation.signature
$operation.throwsClause;
#else
$operation.visibility
$operation.returnType.fullyQualifiedName
$operation.signature;
#end
18
Kapitel 3: AndroMDA
#end
}
Der in blau eingefärbte Code kennzeichnet die Velocity Sprachbefehle. Alles schwarz
eingefärbte ist Java Code, der uneingeschränkt in den Zielquellcode übernommen wird.
Mit der Raute (#) werden in Velocity Anweisungen gekennzeichnet. Dabei handelt es
sich hauptsächlich um Bedingungen (#if und #else), das Setzen von Variablen
(#set) und das Ausführen von Schleifen (#foreach). Velocity Kommentare werden
mit einer Doppelraute (##) versehen und sind grün dargestellt. Die mit einem
Dollarzeichen ($) gekennzeichneten Ausdrücke sind Variablen. Methodenaufrufe, die
keine Parameter benötigen, können abgekürzt werden. So steht beispielsweise der
Ausdruck
fullyQualifiedName
für
die
Methode
getFullyQualifiedName().
Das Template beginnt mit Java Kommentaren, die besagen, dass es sich um generierten
Code handelt, der nicht von Hand verändert werden darf. Darauf folgt die Deklaration
des Interfaces (public interface). Über Bedingungen wird geprüft, ob und wenn
ja von welcher Klasse das Interface erben soll (extends). Im anschließenden Block
werden die Methoden deklariert. Hier sind fast ausschließlich Velocity Anweisungen zu
erkennen und kein Java Code der die Methodenrümpfe füllt. Dies verwundert nicht, da
es sich hier um ein Interface handelt, welche per Definition keine Methodenrümpfe
besitzt. Aber auch wenn es sich um eine normale Klasse handeln würde, wären die
Methodenrümpfe häufig leer, da die Geschäftslogik von Hand implementiert werden
muss. Die Velocity Anweisungen fügen zum einen die Dokumentation der Methode ein
(wenn verfügbar) und setzen, falls benötigt, die Exception Ausdrücke aus Variablen
zusammen.
Als Ergebnis liefert die Template Engine ein auf Basis des Templates entstandenes Java
Interface, welches bereits vollständig implementiert ist. Es ist nicht nötig und auch nicht
erlaubt, an dieses Interface manuell Hand anzulegen. Falls Änderungen notwendig sind,
müssen diese im UML-Modell getätigt werden und das Interface wird vollständig neu
generiert.
19
Kapitel 4: AndroMDA in der praktischen Anwendung
4 AndroMDA in der praktischen Anwendung
4.1 Anlegen eines AndroMDA Projektes
Das hier verwendete Beispiel stellt Teile der Entwicklung einer JavaEE Anwendung mit
Hilfe von AndroMDA dar. Hierfür sind eine Reihe von Programmen und Werkzeugen
notwendig. Neben eines Java Development Kits (JDK) wird ein Applikationsserver, ein
Modellierungstool und eine Datenbank benötigt. In diesem Beispiel wurden dazu der
Applikationsserver JBoss [JBo08], das Modellierungstool MagicDraw [Mag08] und die
Datenbank mySQL [SQL08] verwendet. Zur Steuerung von AndroMDA wird das
Build-Management-Tool Maven genutzt. Maven wird mit bestimmten Befehlen,
sogenannten Goals, über die Konsole gesteuert. Neben der Möglichkeit, AndroMDA zu
steuern, wird von Maven die komplette Projektverwaltung übernommen, und zwar vom
Erstellen der Projektstruktur über die Validierung, Testen, Packen, Kompilieren, bis hin
zum Deployment auf einem Applikationsserver. AndroMDA selber wird als Plugin für
Maven bereitgestellt und installiert. In [And08] ist eine „Schritt für Schritt“-Anleitung
bereitgestellt, die die genaue Installation und Konfiguration der benötigten
Komponenten erläutert. Auf eine genaue Ausführung im Rahmen dieser Ausarbeitung
wird aus diesem Grund verzichtet.
Das Erstellen eines Projektes wird über ein spezielles Maven Goal initiiert. Der dazu
notwendige Konsolenbefehl wird von dem Pfad aus ausgeführt, in dem der
Projektordner erstellt werden soll. Soll dieser auf Laufwerk C:/ erstellt werden, lautet
das entsprechende Maven-Goal:
C:\mvn org.andromda.maven.lugins:andromdapp-mavenplugin:3.3:generate
Es wird der Befehl generate des AndroMDA Plugins Version 3.3 ausgeführt. In dem
folgenden Dialog wird der Anwender dazu aufgefordert, die Details zu dem Projekt
anzugeben. Dazu zählen beispielsweise der Projektname, die zu verwendende UML
Version und die zu verwendenden Cartridges für die Persistenz- und die
Geschäftslogikschicht. Im Anschluss daran erstellt Maven die Projektstruktur und legt
sie dem Projektverzeichnis ab. Zur Unterstützung des Anwenders bzw. des Entwicklers,
wird zusätzlich eine readme.txt erstellt, in der die Verzeichnisstruktur des Projekts
und die benötigten Maven-Goals erläutert werden. Unser kleines Beispiel soll von einer
20
Kapitel 4: AndroMDA in der praktischen Anwendung
Autovermietung handeln, weswegen der Projektname schlicht „Autovermietung“ lautet.
Für die Daten- und Geschäftslogikschicht wird das Spring Framework in Verbindung
mit Hibernate verwendet. Auf die Präsentationsschicht wird aus Platzgründen in dieser
Ausarbeitung verzichtet.
4.2 Erstellen einfacher UML-Modelle
Unter Verwendung des AndroMDA-eigenen UML-Profils wird MagicDraw zum
Erstellen der UML-Modelle verwendet. Bei der Erzeugung des Projektes wurde ein
leeres Modell im XMI Format erstellt und unter
C:\autovermietung\mda\src\main\uml\autovermietung.xmi
abgelegt. Dieses gilt es nun in MagicDraw zu öffnen und zu editieren. Ein stark
vereinfachtes Datenmodell für den Fuhrpark einer Autovermietung könnte wie in
Abbildung 6 dargestellt aussehen.
Abbildung 6: Datenmodell der Autovermietung
Der Fuhrpark besteht aus Fahrzeugen, welche jeweils einen Hersteller, eine
Modellbezeichnung und ein Kennzeichen haben. Zusätzlich bekommen sie noch einen
Fahrzeugtyp zugewiesen, der festlegt, ob es sich um einen PKW, einen LKW oder ein
Motorrad handelt. Neben der Klasse Fahrzeug gibt es so noch eine Klasse Typ. Die
Kardinalitäten geben an, dass jedem Fahrzeug ein Typ zugeordnet wird. Jeder Typ kann
indes null bis unendlich viele Fahrzeuge repräsentieren.
Die Geschäftslogik dieses Beispiels beschränkt sich auf eine einzige Methode, nämlich
das Ermitteln der Daten eines Fahrzeugs. Zu diesem Zweck wird ein Spring Service
erstellt, der in Abbildung 7 dargestellt ist.
Abbildung 7: Modell der Geschäftslogik der Autovermietung
21
Kapitel 4: AndroMDA in der praktischen Anwendung
Die Beziehung zwischen dem FahrzeugService und der persistenten Klasse
Fahrzeug wird über eine Abhängigkeitsbeziehung modelliert.
4.3 Generierung des Quellcodes
Nachdem die Modellierung abgeschlossen ist, wird über das Goal mvn install die
Codegenerierung angestoßen. Dabei werden für jede der drei UML-Klassen, mehrere
Java Klassen erstellt. Generell können die Klassen in zwei Gruppen einteilen. Die
Klassen, die vollständig generiert wurden, kommen in ein spezielles Verzeichnis
innerhalb der Projektstruktur und werden bei jedem erneuten Aufruf des Maven Goals
mvn install überschrieben. Die zweite Gruppe sind Klassen, die manuellen Eingriff
erfordern. Sie werden mit dem Zusatz „impl“ im Klassennamen gekennzeichnet und
werden nicht von AndroMDA überschrieben. So ist sichergestellt, dass manuell
implementierter Code nie verloren geht.
Für die persistente Klasse Fahrzeug wurden folgende Klassen erstellt:
•
Fahrzeug.java: Diese Klasse stellt das eigentliche Entity dar. Hier sind die
Attribute deklariert und die getter- und setter-Methoden implementiert. Bedingt
durch die Assoziation zur persistenten Klasse Typ, erhält sie zusätzlich ein Attribut
Typ. Anzumerken ist, dass es sich um eine abstrakte Klasse handelt. Sie lässt sich
folglich nicht instanziieren.
•
Fahrzeugimpl.java: Hierbei handelt es sich um eine konkrete Unterklasse
von Fahrzeug. Über Factory-Methoden der Fahrzeug Klasse, werden
Instanzen dieser Klasse erzeugt. Zusätzlich dient sie dazu, manuellen Code zum
Fahrzeug Entity hinzuzufügen.
•
FahrzeugDao.java: Diese und die beiden folgenden Klassen stellen zusammen
das Konzept der Data Access Objects (DAO) dar, basierend auf dem gleichnamigen
Entwurfsmuster. Durch die Verwendung der DAO, ist der Zugriff auf die Entities
gekapselt. So ist es möglich die Datenbank auszutauschen, ohne die Entities selber
anzupassen. Das Interface FahrzeugDao spezifiziert die sogenannten CRUD
Methoden. CRUD steht für Create, Retrieve, Update und Delete. Sie dienen dem
Zugriff auf die Objekte.
•
FahrzeugDaoBase.java: In dieser abstrakten Klasse werden die im Interface
spezifizierten CRUD Methoden implementiert.
22
Kapitel 4: AndroMDA in der praktischen Anwendung
•
FahrzeugDaoImpl.java: Wie schon bei Fahrzeug und Fahrzeugimpl,
dient
auch
hier
die
Klasse
dem
manuellen
Hinzufügen
von
Code.
FahrzeugDaoImpl ist Unterklasse der abstrakten Klasse FahrzeugDaoBase.
•
Fahrzeug.hbm.xml: Hierbei handelt es sich um eine Mapping Datei, die das
Fahrzeug Entity auf den entsprechenden Eintrag in der Datenbank abbildet.
Die generierten Java-Klassen für Typ entsprechen ebenfalls diesem Aufbau aus zwei
Entity Klassen, drei DAO Klassen und einem Hibernate Deskriptor.
Für den Spring Service wurden folgende Klassen erstellt:
•
FuhrparkService.java: Hierbei handelt es sich um ein Interface für den
Zugriff auf den Service. Es spezifiziert die Methoden des Services, in diesem Fall
die Methode ZeigeFahrzeugDaten().
•
FuhrparkServiceBase.java: Implementiert das Interface und stellt
Methoden bereit, um auf die DAO Objekte der Entities zuzugreifen. Auch die
ZeigeFahrzeugDaten() Methode wird an dieser Stelle implementiert, indem
sie auf eine Handler Methode namens handleZeigeFahrzeugDaten() der
folgenden Klasse verweist.
•
FuhrparkServiceImpl.java: Hier wird die eigentliche Geschäftslogik
eingefügt, indem der Rumpf von handleZeigeFahrzeugDaten() manuell
implementiert wird.
Das Beispiel sollte einen kleinen Einblick in die Arbeitsweise mit AndroMDA geben.
Zusammenfassend lässt sich feststellen, dass die Klassen der Datenschicht vollständig
generiert wurden. Es kann über die „impl“ Klassen zwar manuell Code hinzugefügt
werden, jedoch ist dies nicht notwendig. Für die Geschäftslogik wird insgesamt weniger
generiert, da die Methoden der Geschäftslogik vollständig selber implementiert werden
müssen.
23
Kapitel 5: Zusammenfassung und Fazit
5 Zusammenfassung und Fazit
Diese Ausarbeitung beschäftigte sich mit dem Tool AndroMDA. Nach einem Überblick
über das Prinzip des Model Driven Software Development und der Model Driven
Architecture, wurden die Komponenten des Tools beschrieben. Darauf folgte eine
detaillierte Beschreibung des Wegs vom einfachen UML-Modell, hin zum generierten
Quellcode. Abschließend wurde anhand eines sehr einfachen Beispiels, die praktische
Anwendung des Tools demonstriert.
Im Prinzip handelt es sich um einen gut nutzbaren Codegenerator mit brauchbaren
Ergebnissen. Jedoch lassen die mitgelieferten Cartridges nicht viel Spielraum bei der
Auswahl der Technologien eines Projekts. Es ist die klare Tendenz hin zu Java EE
Projekten via Spring, Hibernate und Struts feststellbar. Zwar können dank der
modularen Architektur eigene Cartridges und Metafassaden entwickelt werden, doch
gilt es zu prüfen, ob der Aufwand der Entwicklung nicht die Einsparungen durch die
Generierung von Code übersteigt. Ein weiterer Punkt ist die Modellierung. Zwar
handelt es sich im Wesentlichen um normales UML, jedoch werden durch das
AndroMDA-eigene Profil Vorgaben gemacht, die eingehalten werden müssen. Wird zu
Beginn eines Projektes festgelegt, dass AndroMDA zum Einsatz kommt, stellt dies kein
Problem dar. Jedoch müssen bereits vorhandene Modelle erst den Vorgaben
entsprechend umgestaltet werden. Ein erfolgreicher Einsatz von AndroMDA bei der
Lufthansa Systems zeigt aber, das AndroMDA durchaus für Großprojekte geeignet ist.
[FB06]
Der größte Knackpunkt ist aber die momentane Vernachlässigung des Projekts seitens
der Entwickler. So liegen sowohl AndroMDA 4.0 als auch die AndroMDA IDE
(Android) zurzeit auf Eis. Es ist nicht absehbar, ob es in naher Zukunft noch Updates
geben wird. Ebenso fällt die lückenhafte und teilweise veraltete Dokumentation auf.
Aufgrund dieser Vernachlässigungen werden im Supportforum vermehrt Fragen
gestellt, ob das Projekt bereits gestorben sei.
24
Literaturverzeichnis
Literaturverzeichnis
[And08]
AndroMDA: Projekthomepage.
URL: http://www.andromda.org/, Abrufdatum: 6. November 2008.
[And08a] AndroMDA: Supportforum.
URL: http://forum.andromda.org/, Abrufdatum: 6. November 2008.
[And08b] AndroMDA: Dokumentation für Release 3.3.
URL: http://team.andromda.org/docs-3.3/, Abrufdatum: 6. November 2008.
[And08c] Android: Update Site.
URL: http://www.andromda.org/updatesite/, Abrufdatum 8. November
2008.
[Axis08]
Apache Axis: Projekthomepage.
URL: http://ws.apache.org/axis/, Abrufdatum: 8. November 2008.
[Boh06]
Matthias Bohlen: QVT und Multi-Metamodell-Transformationen in MDA,
OBJEKTspektrum, 02/2006, 2006.
[BS03]
Matthias Bohlen, Gernot Starke: MDA entzaubert, OBJEKTspektrum,
03/2003, S. 52-56, 2003.
[EMF08]
Eclipse Modeling Framework: Projekthomepage.
URL: http://www.eclipse.org/modeling/emf/, Abrufdatum 9. Dezember
2008.
[FB06]
Peter Friese, Matthias Bohlen: Erfolgreicher Einsatz von AndroMDA bei
Lufthansa Systems, OBJEKTspektrum, 03/2006, S. 62-68, 2006.
[GPR06]
Volker Gruhn, Daniel Pieper, Carsten Röttgers: MDA®, Effektives
Software-Engineering mit UML 2® und EclipseTM, Springer-Verlag, 2006.
[Hib08]
Hibernate: Projekthomepage.
URL: http://www.hibernate.org/, Abrufdatum: 8. Dezember 2008.
[JBo08]
JBoss: Projekthomepage.
URL: http://www.jboss.org/, Abrufdatum 10. Dezember 2008.
[jBPM08] JBoss jBPM: Projekthomepage.
URL: http://www.jboss.org/jbossjbpm/, Abrufdatum 7. Dezember 2008.
[JMI08]
Java Metadata Interface: Produkthomepage.
URL: http://java.sun.com/products/jmi/, Abrufdatum: 9. Dezember 2008.
[JSF08]
JavaServer Faces Technology: Projekthomepage.
URL: http://java.sun.com/javaee/javaserverfaces/, Abrufdatum 6. Dezember
2008.
25
Literaturverzeichnis
[Loew07] Christoph Loewer: Erstellen einer AndroMDA Cartridge, Orientation in
Objects GmbH, 2007. URL: http://www.oio.de/andromda-cartridge.pdf,
Abrufdatum: 9. Dezember 2008.
[Mag08]
MagicDraw UML: Produkthomepage.
URL: http://www.magicdraw.com/, Abrufdatum 8. Dezember 2008.
[Mav08]
Apache Maven: Projekthomepage.
URL: http://maven.apache.org/, Abrufdatum 10. Dezember 2008.
[MDR08] Netbeans Meta Data Repository: Projekthomepage.
URL: http://mdr.netbeans.org/, Abrufdatum 9. Dezember 2008.
[OMG03] Object Management Group: Technical Guide to Model Driven Architecture:
The MDA Guide v1.0.1, 2003.
[OMG06] Object Management Group: Meta Object Facility (MOF) Core
Specification, Version 2.0, 2006.
[OMG08] Object Management Group: Meta Object Facility (MOF) 2.0
Query/View/Transformation Specification, 2008.
[PM06]
Roland Petrasch, Oliver Meimberg: Model Driven Architecture, Eine
praxisorientierte Einführung in die MDA, dpunkt.verlag, 2006.
[PT07]
Georg Pietrek, Jens Trompeter: Modellgetriebene Softwareentwicklung,
MDA und MDSD in der Praxis, entwickler.press, 2007.
[Spr08]
Spring Framework: Projekthomepage.
URL: http://www.springframework.org/, Abrufdatum: 8. Dezember 2008.
[SQL08]
mySQL: Projekthomepage.
URL: http://www.mysql.com/, Abrufdatum 10. Dezember 2008.
[Tho05]
Alexander Thomas: Einsatz von Massgeschneiderten Codegeneratoren auf
Basis des „Java Metadata Interface“, OBJEKTspektrum, 02/2005, S. 1822, 2005.
[Vel08]
Velocity: Projekthomepage.
URL: http://velocity.apache.org/, Abrufdatum: 6. Dezember 2008.
26