Magisterarbeit zur Erlangung des akademischen Grades eines Magisters der Sozial- und Wirtschaftswissenschaften

Transkript

1 TU Wien Business Informatics Group Institut für Softwaretechnik und Interaktive Systeme Model Driven Architecture - Vollständige Codegenerierung mittels AndroMDA Magisterarbeit zur Erlangung des akademischen Grades eines Magisters der Sozial- und Wirtschaftswissenschaften eingereicht bei o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel mitbetreuender Assistent: Dipl.-Ing. Dr. Gerhard Kramler Bakk.rer.soc.oec Arnold Karner Wien, 11. Oktober 2006

2 Eidesstattliche Erklärung Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Wien, 11. Oktober 2006 Arnold Karner

3 Danksagung Ich möchte mich bei o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel und Dipl.-Ing. Dr. Gerhard Kramler für die Anregung zu dieser Diplomarbeit und für die Unterstützung bei der Erstellung der Arbeit bedanken. Weiter möchte ich mich ganz besonders herzlich bei meinen lieben Eltern, Evelyn und Ernst Karner bedanken, die mir immer die notwendige moralische sowie finanzielle Unterstützung für mein Studium gaben.

4 Kurzfassung Mit der Model Driven Architecture (kurz: MDA) gibt es einen neuen Standard zur generativen Softwareentwicklung. Dieser wurde von der Object Management Group im Juni 2003 spezifiziert. Ziel einer MDA ist es, technologienunabhängige Spezifikationen zu erstellen, die für automatische Codegenerierung auf unterschiedlichen Plattformen wie.net, J2EE, oder CORBA genutzt werden können. Mit dem Einsatz von MDA liegt der Fokus der Entwicklung hauptsächlich auf der Modellebene, die eigentliche Programmierung rückt zusehends in den Hintergrund. Der Idealfall wäre, eine auf unterschiedlichen Plattformen, völlig automatisierte, vollständige Codegenerierung aus UML Modellen. Da dies derzeit aber noch nicht der Fall ist, müssen Software Entwickler auf 2 unterschiedlichen Abstraktions- und Technologieebenen, der Modellebene und der Codeebene, arbeiten. Bis dato implementieren schon eine geraume Anzahl von Tools die MDA Spezifikation (AndroMDA, OpenArchitectureWare 1 etc.). Das in dieser Arbeit untersuchte AndroMDA ist ein Open Source Framework und wurde im März 2003 der Öffentlichkeit vorgestellt. Es benutzt zur Codetransformation aus UML-Modellen verschiedene, so genannte Cartridges 2. Mit diesen Cartridges verarbeitet AndroMDA Metamodell-Elemente, die durch Stereotypen und Schlüsselwörtern, wie z.b. <<Entity>> oder <<Service>> gekennzeichnet werden und generiert daraus Codefragmente. AndroMDA unterstützt derzeit primär die Zielsprachen Java und C#/.NET. Die Codegenerierung wird über Templates gesteuert, so dass jede erdenklich Zielsprache (HTML, PHP etc.) damit realisiert werden kann. Ziel dieser Magisterarbeit ist es, das MDA Framework AndroMDA anhand der Beispielanwendung Onlinebibliothek zu evaluieren. Hierbei soll die Funktionsweise der einzelnen Komponenten, unterstützte Technologien sowie Stärken und Schwächen des Frameworks bezüglich vollständiger Codegenerierung ermittelt werden. 1 (Stand: ) 2 (Stand: )

5 Aus diesen Ergebnissen soll im weiteren Verlauf der Arbeit die Codegenerierungsfunktionalität hinsichtlich möglichst vollständiger Codegenerierung optimiert werden. Gemessen soll das Verhältnis der automatisch generierten Lines Of Code (LOC) zu den manuell erstellten LOC werden. Daraus lässt sich die Güte des Codegenerators von AndroMDA bestimmen.

6 Abstract With Model Driven Architectures (MDA), there is a new standard for generative software development. This new standard has been introduced in June 2003 by a Team, called Object Management Group. The main target of the MDA technology is, to build specifications which are independent from any technology, to use it for generating Code to different platforms, like.net, J2EE, or CORBA. MDA brings the focus of development to the model layer. The main programming is shifted more and more to the background. The best case would be to automatically generate complete code from the UML models to any kind of platform. But at present this vision isn't accomplishable, so software engineers have to work on 2 different kinds of layers, the abstraction layer which is the model layer, and the technology layer, which is, more specifically, the code layer. At present, many tools are implementing the MDA specification (e.g. AndroMDA, OpenArchitectureWare 3 ). In this diploma thesis, the tool AndroMDA, which is a open-source framework released in march 2003, will be researched. For the code generation from UML models, AndroMDA uses cartridges 4. For generating codefragments, the cartridges are processing meta-model elements, which are marked with stereotypes or key values, like for example <<Entity>> or <<Service>>. AndroMDA presently supports 2 main target languages, Java and C#/.NET. The code-generation process is controlled by templates. With this technique, AndroMDA is able to automatically generate code for any imaginable target language (e.g. HTML, PHP). The main target of this diploma thesis is to evaluate the MDA framework AndroMDA on the basis of a case study of an online library. In particular, the functionality of AndroMDA's several components should be determined, as well as basic technologies and pros and contras of the framework regarding fully code generation. Based on the results of the evaluation, the code generating functionality should be optimized, re- 3 (Stand: ) 4 (Stand: )

7 garding full code generation. The code generator's quality will be measured by the rate of automatically generated lines of code to the amount of manually written lines of code.

8 Inhaltsverzeichnis Kapitel 1 - Einleitung Einleitung Aufbau der Arbeit...12 Kapitel 2 - Model Driven Architecture MDA Model Driven Architecture MDA Modelle CIM Computation Independent Model PIM Platform Independent Model PM Platform Model PSM Platform Specific Model Modelltransformation Modell Modell Transformation Modell-Code Transformation Metamodelle M3 Metametamodell M2 Metamodell M1 Modell M0 Instanz UML Profile...27 Kapitel 3 - AndroMDA Einleitung AndroMDA Komponenten UML Modellierungs-Tool Maven Plugin MetaData Repository Metafacades Aufbau der Cartridges Template Engine Translation Libraries...47

9 3.2.8 Datatype Mapping Installation des AndroMDA Frameworks AndroMDA Verzeichnisse...53 Kapitel 4 - Fallstudie Onlinebibliothek Anwendungsfälle Bibliotheksbenutzer Administrator AndroMDA Metamodell Datentypen Entity Manageable Entities CRUD Valueobject Hibernate Criteria Service Controller Modellierung des Fallbeispiels Use Cases Rollen Login Buch Suche User und Bücher administrieren Buch kaufen Codeanalyse...91 Kapitel 5 - Zusammenfassung und Ausblick Zusammenfassung Ausblick...96

10 Kapitel 1 1 Einleitung 1.1 Einleitung Bis dato wurden Softwaresysteme von Entwicklern händisch verfasst. Viele tausende Zeilen Code müssen in Editoren geschrieben werden, um komplexe Softwaresysteme erstellen zu können. Dabei schlummern zahlreiche Fehlerquellen. Auch die Architektur einer Software, also wie diese aufgebaut wird, muss in der Planungsphase definiert werden. Dabei gibt es unzählige Möglichkeiten und nicht alle führen zum gewünschten Erfolg. Viele Projekte werden eingestellt weil die im Vorfeld der Entwicklung die falsche Architektur gewählt wurde. Schnittstellen zwischen Entwicklerteams können so nicht eingehalten werden. Zahlreiche Projekte scheitern an einer schlechten Dokumentation. Viele Projekte werden gar nicht mehr aufgenommen oder weiterentwickelt weil die Einarbeitungszeit in den komplexen schlecht dokumentierten Code länger dauern würde als das komplette Neuentwickeln der selben. Diese ganzen Probleme schreien förmlich nach einer einheitlichen Lösung, die das Entwickeln von Softwaresystemen transparenter, die Wiederverwendbarkeit der Systeme erhöht und potentielle Fehlerquellen minimiert. Die Lösung heißt Model Driven Architecture. Die Model Driven Architecture (kurz: MDA) wurde im Juni 2003 von der Object Management Group (kurz: OMG) spezifiziert. Durch die OMG wurden bis dato bereits viele Spezifikationen für die Softwareentwicklung erstellt, zu den bekanntesten zählen MOF, UML, XMI, CWM, CORBA u.v.a.

11 Kapitel 1 - Einleitung Seite 11 Das übergeordnete Ziel einer Model Driven Architecture ist es, Spezifikationen zu erstellen, die nicht plattform- oder herstellerabhängig sind. Es soll also eine allgemeingültige Spezifikation eines Softwaresystems erstellt werden, die ohne zusätzlichen Aufwand, automatisch auf unterschiedlichen Systemen zur Codegenerierung verwendet werden kann. Wie der Name schon sagt, verfolgt MDA eine modellgetriebene Entwicklung die das Modell stark betont. Die eigentliche Programmierung rückt stark in den Hintergrund, der Code soll im Idealfall automatisiert aus den Modellen erstellt werden. Das Ziel ist es, vollständige Codegenerierung zu erreichen, d.h. 100% des Codes für die zu erstellende Applikation aus dem Modell zu generieren. Mit der Entwicklungsmethode der MDA erhöht man die Wiederverwendbarkeit und Portabilität von Softwarespezifikationen und macht es damit möglich Aufwände in der Softwareentwicklung zu minimieren. Die verwendeten Modelle, müssen plattformunabhängig sein, d.h. das Softwaresystem muss auch ohne Wissen der zu verwendenden Plattform modelliert werden können. Die Plattform stellt dabei sämtliche verwendeten Technologien und Architekturen zur Verfügung. Erst in einem weiteren Schritt wird das Modell an die Plattform angepasst. Dieser Schritt geschieht durch eine Modell zu Modell Transformation automatisch. Erst wenn das Modell auf die spezifischen Belange einer bestimmten Plattform transformiert wurde ist, kann man es zur Codegenerierung verwenden. Da der Aufbau und die Architektur eines Softwaresystems in den Modellen abgebildet ist, dienen diese zusätzlich als Dokumentation. Somit muss jede Änderung der Architektur auch modelliert werden, da der Code aus den Modellen generiert wird. So ist gewährleistet, dass sich die Architektur nicht während der Entwicklung unbemerkt verändern kann. In heutigen Softwaresystemen der Online Domäne treten häufig ähnliche Problemstellungen auf. Kunden können sich am System einloggen, Administratoren verwalten Daten, Objekte werden bestellt oder verkauft, Datenbanken nach diversen Informationen durchsucht, verschiedene Eingabefelder müssen validiert werden oder Hilfemenüs und Tooltips sollen angezeigt werden. Wenn normal entwickelt wird, müssen eine große Anzahl von bereits bekannten Problemen implementiert werden, obwohl es auch hier Ansätze zur Wiederverwendung von Softwarekomponenten gibt. Eigentlich ist nur die Geschäftslogik eines Softwaresystems immer unterschiedlich zu implementieren. Datenhaltungsschicht und Datenzugriffe sind im Gegensatz dazu leicht aus Modellen zu generieren. Verwendet man nun den Ansatz einer MDA, so können eine Vielzahl obig erwähnter Probleme elegant aus Modellen generiert werden und müssen nicht manuell implementiert werden.

12 Kapitel 1 - Einleitung Seite 12 Wie viel, und was generiert wird, bestimmen die Modelle einer MDA. In ihnen sind alle Informationen des Systems untergebracht. Das übergeordnete Ziel einer MDA ist die vollständige Codegenerierung, also möglichst 100% des Applikationscodes aus den UML Modellen zu generieren. Der derzeitige Stand der Technik bei der Generierung von Softwareapplikationen aus MDA Modellen, steht bei Codegenerierungsgraden von 60-80% [laut ThS05], je nachdem wie viel Geschäftslogik zusätzlich manuell implementiert werden muss. 1.2 Aufbau der Arbeit Das erste Kapitel dient einer allgemeinen Einleitung und Einführung in Thematik der vollständigen Codegenerierung mittels Model Driven Architecture und die Motivation, diese Technologie einzusetzen. Im Kapitel 2 sollen zuerst allgemein die Methoden und Spezifikationen einer Model driven Archietcure illustriert werde. Nach einer kurzen Einführung in die Grundprinzipien einer MDA und deren Modelle (PIM, PSM, CIM etc.), werden besonders die UML Metamodelle und Modell-Transformationen beleuchtet. In Kapitel 3 wird dann, aufbauend auf der Theorie aus Kapitel 2, das Opensource Framework AndroMDA genau unter die Lupe genommen. Primär wird in diesem Kapitel der Aufbau und die Funktionsweise der einzelnen AndroMDA Komponenten gezeigt. Ebenfalls wird in diesem Kapitel auch ein Installationsleitfaden für AndroM- DA, bis hin zu einer Projekterstellung entwickelt. Kapitel 4 behandelt die praktische Ausarbeitung des Fallbeispiels Online Bibliothek. Hier wird die Funktionsweise des Fallbeispiels über Anwendungsfälle und einer Anwendungsfallbeschreibung erläutert. Danach wird beispielhaft anhand der UML Modelle das Fallbeispiel erläutert und schrittweise die zugrundeliegenden Technologien und das User Interface der Online Bibliothek präsentiert. Nach diesem Schritt wird eine Codeanalyse durchgeführt um so das Ergebnis der vollständigen Codegenerierung bewerten zu können.

13 Kapitel 1 - Einleitung Seite 13 Im Kapitel 5, gleichzeitig das letzte Kapitel dieser Arbeit, soll der Einsatz von AndroMDA resümiert werden. Dabei soll ein Bogen von der Handhabung AndroM- DAs, bis hin zur Ergebnisanalyse des Fallbeispiels gezogen werden. Positives sowie Negatives wird diskutiert und Verbesserungsmöglichkeiten vorgeschlagen. Ein mögliches Ergebnis in Richtung der vollständigen Codegenerierung wird hier analysiert und diskutiert.

14 Kapitel 2 2 Model Driven Architecture 2.1 MDA Model Driven Architecture MDA steht für Model Driven Architecture und findet seine Anwendung in der generativen Softwareentwicklung. MDA ist ein noch sehr junger Standard entwickelt von der OMG (Object Management Group) zur modellgetriebenen generativen Softwareentwicklung. Ziel der MDA Spezifikation ist es, aus technologieunabhängigen Modellen, Code effizient und fehlerfrei, automatisch auf unterschiedliche Plattformen, wie CORBA,.NET oder J2EE zu generieren. In diesem Standard wird klar zwischen verschiedenen Abstraktionsschichten unterschieden. So wird die Geschäftslogik in einem plattformunabhängigen Modell modelliert. Diese, auch fachliche Spezifikation genannt, ist somit von den verwendeten Systemen und Technologieebenen unabhängig. Dies erhöht die Wiederverwendbarkeit, Testbarkeit, Portabilität sowie die Lebensdauer der einzelnen Modelle bzw. Spezifikationen. Daraus ergeben sich klare Vorteile: Implementierung: Einsatz von neuer Technologie erfordert keine Änderungen des Designs. Modell / Code Konsistenz steigt, damit sinkt die Fehleranfälligkeit. Wartung dieser Systeme gestaltet sich erheblich einfacher.

15 Kapitel 2 - Model Driven Architecture Seite 15 Testen und Simulieren: Es kann schon auf der Modellebene getestet werden. Modelle können validiert und mit den Anforderungen überprüft werden. Die Technologie der Model Driven Architecture ist in 4 Basis-Aktivitäten gegliedert: Domänensicht des Systems, Anwendungsfalldiagramm (CIM) Spezifizieren eines systemunabhängigen Modells (PIM) Spezifizieren einer Plattform und des Plattform Modells (PM) Modell-Modell Transformation vom PIM auf ein plattformspezifisches Modell (PSM) Modell-Code Transformation von der PSM Systemspezifikation auf die Zielplattform 2.2 MDA Modelle Das MDA Konzept besteht darin, aus einem sehr allgemeinen plattformenabhängigem Modell (PIM) ein Modell für eine gewünschte Zielplattform zu generieren bzw. transformieren (PSM). So ist es mit MDA möglich auf unterschiedlichen Plattformen ohne zusätzlichen Aufwand das gleiche Softwaresystem zu implementieren. Dazu sind zwei Modell Transformationen nötig. Zuerst folgt die Modell-Modell- Transformation, die von der fachlichen Spezifikation ein plattformspezifisches Modell ableitet. Danach wird die eigentliche Modell-Code Transformation durchgeführt, die die gewünschte Codegenerierung der jeweiligen Plattform ausführt. In Anlehnung an [JMag03], illustriert Abbildung 1 das MDA Prinzip.

16 Kapitel 2 - Model Driven Architecture Seite 16 Fachliche Spezifikation PIM - Platform Independent Model Modelll-Modell-Transformation J2EE-Modell.NET-Modell DB-Modell PSM - Platform Specific Model Modell-Code-Transformation J2EE Code.NET Code SQL-Skripte Implementierung Abbildung 1: MDA Prinzip CIM Computation Independent Model Mit dem CIM wird die Geschäfts- bzw. Domänensicht eines Softwaresystems beschrieben. Im Zusammenhang mit Model Driven Architecture, beschreibt das Computation Independent Model das höchste Abstraktionsniveau. Es werden keine technikbzw. maschinenbezogenen Aspekte modelliert, vielmehr wird das Softwaresystem allgemein beschrieben. Damit ist das Modell unabhängig von der Implementierung des Systems, quasi berechnungsunabhängig. Modelliert wird das CIM mit Anwendungsfall- und Aktivitätsdiagrammen PIM Platform Independent Model Das Platform Independent Model (plattformunabhängiges Modell) beschreibt die Struktur und das Verhalten eines Softwaresystems. Es baut auf dem CIM auf und ist plattformunabhängig. Das PIM ist ein Modell, welches das Softwaresystem beschreibt, ohne auf plattformspezifische Aspekte einzugehen. Damit ist das PIM von der verwendeten Plattform unabhängig und damit auch gegenüber etwaigen Technologieänderungen.

17 Kapitel 2 - Model Driven Architecture Seite PM Platform Model Um überhaupt die Begriffe plattformunabhängig und plattformspezifisch anwenden zu können, benötigt es der Definition einer Plattform. Eine Plattform im MDA- Kontext, ist zunächst einfach ein Setup aus bestimmten Architekturen, Technologien und Funktionalitäten. Um nun von einem PIM zu einem PSM transformieren zu können, benötigt man ein Plattform Modell, welches die technischen Konzepte der zugrunde liegenden Plattform definiert. Ein Plattform Modell beinhaltet sämtliche Komponenten und Elemente, die zur Modellierung eines PSM notwendig sind. Abbildung 2: PSM - Plattform Modell PSM Platform Specific Model Das Platform Specific Model erweitert das allgemeine PIM um plattformspezifische Aspekte. Aus dem PIM wird nun mit Hilfe einer Modell Transformation (siehe 2.3) das PSM generiert. Das PSM beinhaltet sämtliche plattformspezifische Konzepte, vorgegeben durch das Plattform Modell. Damit ist nun die Implementierung an die Eigenschaften der jeweiligen Zielplattform angepasst. In Abbildung 3 wird ersichtlich wie die Transformation vom PIM zum PSM und schließlich zum generierten Code erfolgt.

18 Kapitel 2 - Model Driven Architecture Seite 18 Als Beispiel dienen 2 Klassen, die unter Verwendung der AndroMDA UML Profile mit dem Stereotyp <<Entity>> gekennzeichnet sind. Damit sind die Klassen als persistente Objekte ausgewiesen. Mit dem Stereotyp <<Identifier>> wird das jeweilige Attribut als eindeutig identifizierbar markiert. Dies ist nun die plattformunabhängige Modellierung des Sachverhalts (PIM). Das PSM soll nun gemäß der J2EE Plattform, Entity Beans aus dem PIM modellieren. Diese sind mit dem Stereotyp <<EntityBean>> gekennzeichnet und der <<Identifier>> Stereotyp wird auf PSM- Ebene zum <<PK>> Stereotyp umgewandelt. Mit dem Tagged Value {persistence=cmp} wird angegeben, dass die Persistenz vom EJB-Container bereitgestellt werden soll. Nun ist das Modell plattformspezifisch und kann der Codetransformation zugeführt werden. Der Codegenerator erstellt jeweils zwei Interfaces und die eigentliche Entity Bean Klasse. Abbildung 3: PIM - PSM Code, angelehnt an [Wim05]

19 Kapitel 2 - Model Driven Architecture Seite Modelltransformation Um ein PIM in ein PSM zu überführen, muss eine Modelltransformation stattfinden (Abbildung 1). In dieser Transformation wird das plattformunabhängige Modell der jeweiligen Ziel-Plattform angepasst, ohne dabei die Semantik des ursprünglichen Modells zu verlieren. Allgemein lassen sich sämtliche Modelltransformationen von Modell-Type und Modell-Instanz Transformationen ableiten (siehe Abschnitt 2.3.1). Es gibt zwei Modell-Transformationsansätze, dies sind die Modell-Code und die Modell-Modell Transformationen. Führt man eine Modell-Modell Transformation auf das Quellmodell (PIM) aus, so müssen zusätzlich mit einer zweiten Transformation, der Modell-Code Transformation, die Code- bzw. Textartefakte aus dem Zielmodell (PSM) transformiert werden. Es gibt jedoch einen Spezialfall Modelltransformation, nämlich direkt aus dem PIM mittels einer Modell-Code Transformation, ohne den Umweg über ein PSM, den Code zu generieren. Abbildung 4: Modelltransformationen Der Prozess der Transformation selbst, sollte automatisch ablaufen. Die Transformationsregeln müssen somit einheitlich definiert werden um nicht inkonsistent zu werden. Die OMG hat deshalb einen Standard für die Modell-Modell Transformation im

20 Kapitel 2 - Model Driven Architecture Seite 20 November 2005 definiert, den MOF QVT (Meta Object Facility - Query, View, Transformation) [QVT05]. Bis dato gibt es noch keine vollständige Implementierung von QVT, doch mit der ATL (Atlas Transformation Language) 5, einem Open Source Framework Projekt der Eclipse Foundation, ist ein Anfang gemacht Modell Modell Transformation Modell-Modell Transformationen transformieren primär von einem PIM in ein PSM des gleichen oder nicht gleichen Metamodells. Dies kann in einem oder mehreren Schritten erfolgen, wie man der an [Wim05] angelehnten Abbildung 5 entnehmen kann. Abbildung 5: Modell-Transformationsschritte Das PIM ist auf einer sehr hohen Abstraktionsstufe angesiedelt, während das PSM schon viel konkreter und weniger abstrakt modelliert wird. Oft ist es nötig, aufgrund der großen unterschiede der Abstraktionsniveaus zwischen dem Quell- und dem Ziel- Modell, Zwischenmodelle einzuführen, die Entwicklungsschritte modularer und überschaubarer machen und somit die Wiederverwendbarkeit der Modelle erhöhen. 5 (Stand: )

21 Kapitel 2 - Model Driven Architecture Seite 21 Modell-Instanz Transformation Bei dieser Art der Transformation wird das PIM im ersten Schritt mit Markierungen (Marks), bestehend aus Stereotypen oder Wert-Schlüssel Paaren (z.b. persitence=cmp) gekennzeichnet. Diese Markierungen beinhalten plattformspezifische Informationen, um auf die Zielplattform transformieren zu können. Es wird ein Zwischenmodell erstellt (marked PIM), da die spezifischen Markierungen nicht direkt im PIM modelliert werden können. Erst aus dem Zwischenmodell wird das PSM transformiert. Abbildung 6: Model-Instance Transformation [MDA03] Modell-Type Transformation Mit der Modell-Typ Transformation ist es möglich mit einer Transformationsdefinition, plattformunabhängige Quelltypen in plattformspezifische Typen zu transformieren. Um von einem PIM in ein PSM transformieren zu können, müssen die jeweiligen Typen des Quellmodells über spezielle Transformationsregeln auf die des Zielmodells abgebildet werden. Da die Typen von Quell- und Zielmodell von der Meta Object Facility abgeleitet sind, können die Transformationsregeln auf Metamodellebene definiert werden.

22 Kapitel 2 - Model Driven Architecture Seite 22 Abbildung 7: Model-Typ Transformation [MDA03] Bei Modell-Modell Transformationen unterteilt man grundsätzlich in 6 konkrete Ansätze, nämlich direct-manipulation, relational, graph-transformation-based, structuredriven, and hybrid Ansätzen. [Cza03] Details zu diesen Transformationsansätzen findet man unter [Cza03] und [Bier06] Modell-Code Transformation Modell-Code Transformationen werden auch als Modell-Text Transformationen bezeichnet, weil sie nicht nur Programm-Code, sondern auch z.b. XML Artefakte generieren. Auch der eigentliche Code wird im ersten Schritt als Text generiert und erst danach einem Compiler zugeführt. Bei Modell-Code Transformationen unterscheidet man zwischen dem Visitor-Based und Template Based Ansatz. Diese werden nun genauer unter die Lupe genommen, weil sie in den meisten MDA Tools implementiert sind. Visitor Based Der Visitor Based Ansatz ist eine sehr einfache Methode der Modell-Code Transformation. Dieser Ansatz implementiert einen so genannten Visitor Mechanismus der es ermöglicht das UML Modell zu durchlaufen und daraus den Code als Textstrom zu generieren. Als bekanntester Vertreter dieser Transformationsart gilt das Opensource

23 Kapitel 2 - Model Driven Architecture Seite 23 Projekt Jamda 6. Dieses repräsentiert UML Modelle durch Java Klassen und verfügt über so genannte Codewriter, die die Modelle durchforsten und den Code daraus generieren. Template Based Der templatebasierte Transformationsansatz ist der meist angewandte und in MDA Tools implementierte Ansatz der Modelltransformationen. Als bekannteste Vertreter von MDA Tools, die diese templatebasierte Modell-Code Transformation einsetze sind z.b. b+m Generator Framework, JET, FUUT-je, Codagen Architect, AndroM- DA, ArcStyler, OptimalJ and XDE. [Cza03] Dieser Ansatz verwendet Templates im Textformat, die der Zielplattform bzw. dem Zielmodell entsprechen. Über Variablen in den Templates können Informationen aus dem Quellmodell in die Templates eingebunden werde. Die Templates sind beliebig erweiterbar und können auch selbst wieder Templates enthalten. Der Vorteil der Templates ist, dass damit in nahezu jede Zielsprache generiert werden kann. Auch das in dieser Arbeit zu untersuchende AndroMDA transformiert seine Modelle templatebasiert, wie in Abbildung 8 illustriert wird. Abbildung 8: Template Based Ansatz mit AndroMDA [APA06] 6 (Stand: )

24 Kapitel 2 - Model Driven Architecture Seite Metamodelle Der Ausdruck Meta stammt aus dem Griechischen und bedeutet über, hinter [DUD67]. Ein Modell ist die Abstraktion der Realität. Um ein Modell erstellen und beschreiben zu können, bedient man sich einer Sprache. Die Grammatik und Regeln dieser Sprache müssen ebenso definiert werden. Diese Sprachen werden nun in so genannten Metamodellen definiert. Auch Metamodelle sind in einer Sprache verfasst, nämlich der Metasprache. Metasprachen müssen wiederum in Metametamodellen definiert sein. Rein theoretisch würde diese Kette aus Sprachen und dessen Modellen nie stoppen, weil ja jede Sprache wiederum in einem Modell definiert sein müsste. Am Beispiel der OMG führte man deswegen, die Meta Object Facility als Metasprache und zugleich oberste Instanz der Metamodellierung ein. Somit hat das Metametamodell keine darüber liegende Sprache, sondern bedient sich ebenso wie das Metamodell der Metasprache. Abbildung 9: Aufbau von Modelle und Sprachen M3 Metametamodell Die M3 Ebene, die so genannte Metametamodell Ebene, ist die oberste Schicht des Modells und hat damit das höchste Abstraktionsniveau. Auf der M2 Ebene befinden sich die Instanzen der auf der M3 Ebene definierten Konstrukte. Die OMG definiert auf der Metametamodellebene die Meta Object Facility (MOF). Sie beschreibt den Aufbau der Metamodelle UML (Unified Modeling Language) und CWM (Common

25 Kapitel 2 - Model Driven Architecture Seite 25 Warehouse Metamodel), welche wiederum Instanzen zu M1 und M0 Ebene bilden Dies wird jeweils durch den Stereotyp <<instanceof>> in Abbildung 11 angezeigt. zeigt den Aufbau des MOF Modells der Version 1.4 (siehe [MOF02]), spezifiziert durch die OMG. Abbildung 10: MOF Modell [MOF02] M2 Metamodell Auf der M2, der so genannten Metamodell Ebene, definiert die OMG die Sprachen mit denen auf der M1-Schicht Systeme modelliert werden. Es gibt zwei von der OMG definierten Sprachen, UML und CWM. Im Falle einer Model Driven Architecture, wird das Metamodell UML verwendet. Aus Abbildung 11 kann man erkennen dass die Elemente (Class und Attribute) der M2 Metamodellebene Instanzen auf der M1 Modellebene haben. Oft kann es vorkommen, dass die Elemente die auf M2 Ebene definiert werden nicht zur domänenspezifischen Modellierung ausreichen. Dafür gibt es die so genannten Profile, die die Sprachen mit Elementen erweitern. In Abschnitt werden UML Profile genauer beschrieben.

26 Kapitel 2 - Model Driven Architecture Seite M1 Modell Auf der M1 Ebene befindet sich das Modell zum Abbilden bzw. Beschreiben eines Systems. Dieses Modell wird mittels UML, CWM oder anderen, auf M2 definierten Metamodell- Sprachen modelliert, wie man aus Abbildung 13 erkennen kann. Das M1 Modell definiert die Eigenschaften seiner instanziierten Objekte auf der M0 Ebene (Abbildung 11) M0 Instanz Objekte auf der M0 Schicht repräsentieren Instanzen von M1 Objekten. Sie bilden damit reale Entitäten ab. Zum Beispiel wäre das Buch mit dem Titel Work" [siehe Kapp99] eine Instanz der in M1 modellierten Klasse "Buch". Die Eigenschaften dieses Buches werden eine Schicht höher, in M1 definiert. Abbildung 11: MOF Ebenen der Metamodellierung

27 Kapitel 2 - Model Driven Architecture Seite 27 Metasprachen der Model Driven Architecture Das MDA Logo der OMG aus Abbildung 12 verdeutlicht den Aufbau und die verwendeten Metasprachen in MDA. Ausgehend von der Meta Object Facility (MOF), gibt es 2 Metamodell Sprachen, die Unified Modelling Language (UML) für den Aufbau von Applikationsmodellen und das Common Warehouse Metamodel (CWM) für das Modellieren von Daten. Abbildung 12: OMG's MDA-Konzept Mit dem CWM definiert die OMG ein eigenes Metamodell für die Modellierung von Datawarehouses. UML und CWM sind somit die Sprachkonstrukte mit denen Modelle für MDA hergestellt werden können. Diese können noch mit so genannten Profilen ausgebaut werden, wie der nächste Ring des Logos zeigt. Für Modelle die zur Codegenerierung herangezogen werden, benötigt man oft Konstrukte, die nicht in UML bzw. CWM selbst definiert sind. Man muss die Sprache also mit bestimmten Elementen erweitern oder einschränken. Dies erreicht man durch UML oder CWM- Profile, welche im Abschnitt genauer beleuchtet werden UML Profile Mit UML Profilen kann man den bestehenden Sprachumfang von UML auf der M2 Ebene erweitern, um sie an technische bzw. fachliche Domänen anpassen zu können.

28 Kapitel 2 - Model Driven Architecture Seite 28 Erst damit ist es möglich aus einem PIM ein PSM zu transformieren. UML Profile sind ähnlich zur Grammatik einer Programmiersprache, die Syntax und Semantik der Modellierungssprache. Sie sind aus Stereotypen, Constraints (Einschränkungen) sowie Tagged Values (Eigenschaftswertpaare) aufgebaut. Im Bezug auf MDA werden UML Profile vor allem dann eingesetzt wenn man, die bestehende UML Sprache hinsichtlich ihrer Semantik einschränken (Constraints) will, oder UML um diverse Sprachkonstrukte erweitern will, die noch nicht im Standardpaket enthalten sind. Aus Abbildung 13 ist zu erkennen, dass die UML Profile eine Erweiterung in der M2 Schicht des UML Metamodells sind. Auch für das Common Warehouse Metamodel gibt es Profile zur Erweiterung des Funktionsumfanges, z.b. das OLAP Profil. Es ist auch möglich aus bestehenden Profilen, benutzerspezifische Profile abzuleiten. M3 - MetaMetamodell MOF M2 - Metamodell UML CWM Weitere Metamodelle EDOC-Profil CORBA- Profil CCM-Profil Testing- Profil OLAP-Profil Benutzerspezifisches Profil EAI-Profil QoS-Profil Performance -Profil M2 - Standard/Benutzer Profile M1 - Modell M0 - Instanzen Abbildung 13: UML Profile im Metamodell

29 Kapitel 2 - Model Driven Architecture Seite 29 Für UML existieren derzeit schon unzählige Profile die nachfolgend aufgelistet und beschrieben sind. UML Profile for CORBA [OMG02]: Definiert die Transformation eines PIMs in ein CORBA spezifisches PSM. UML Profile for CCM (CORBA Component Model) [OMG04]: Definiert ein Profil für das komponentenbasierte Programmieren. Das Java Mapping wird mittels EJBs (Enterprise JavaBeans) erreicht. UML Profile for EDOC [OMG04a]: Das Enterprise Distributed Object Computing Profil wird zur plattformunabhängigen Modellierung (PIM) von verteilten Unternehmensanwendungen eingesetzt. Das EDOC Profil besteht aus einer Reihe weiterer untergeordneter UML Profile. o UML Profile for Java and EJB [OMG04b]: Dieses Profil wird zur Transformation eines PIM in ein Java/EJB spezifisches PSM verwendet. o UML Profile for Patterns [OMG04c]: Das Patterns Profil wird verwendet um spezifische Software-Patterns zu modellieren (z.b. Business Function Object Pattern BFOP). o UML Profile for Enterprise Collaboration Architecture (ECA), v1.0 [OMG04d]: Das ECA Profil erweitert das EDOC Profil hinsichtlich Services, Events und Notifications sowie der Modellierung von persistenten Objekten auf der PIM Ebene von Unternehmensanwendungen. o UML Profile for Meta Object Facility[OMG04e]: Dieses Profil beschreibt das Mapping zwischen UML Elementen und MOF Elementen. o UML Profile for Relationships [OMG04f]: Dieses Profil erweitert das UML Core um spezielle Beziehungen für die Modellierung von Unternehmensanwendungen, basierend auf dem ISO General Relationship Model. UML Profile for EAI [OMG04g]: Definiert ein Profil für lose gekoppelte Systeme, welche asynchron oder nachrichtenbasiert kommunizieren. Das UML Profil für EAI wird häufig zur Modellierung bei so genannter Enterprise Application Integration eingesetzt.

30 Kapitel 2 - Model Driven Architecture Seite 30 UML Profile for Quality of Service (QoS) and Fault Tolerance [OMG04h]: Definiert ein Framework für die Modellierung in Echtzeit- und Hochsicherheitsumgebungen. UML Profile for Schedulability, performance, and time [OMG05a]: Erweitert UML hinsichtlich verschiedener Performanzkriterien bei Echtzeitanwendungen. UML Testing Profile [OMG03]: Dieses Profil enthält eine eigene Modellierungssprache für automatisierte Tests, deren Spezifikation und Dokumentation, in MDA Entwicklungsumgebungen.

31 Kapitel 3 3 AndroMDA 3.1 Einleitung AndroMDA ist ein Open Source MDA Framework, welches zur Codegenerierung verschiedener Zielsprachen eingesetzt werden kann. Entwickelt wurde es von Matthias Bohlen und einer mächtigen Open Source Community, dem AndroMDA Team. AndroMDA wurde auf Basis des Codegenerators UML2EJB weiterentwickelt. UML2EJB, ebenfalls eine Open Source Entwicklung von Matthias Bohlen, wurde für die Vereinfachung der Codegenerierung von Enterprise JavaBeans (kurz: EJB) im Juli 2002 vorgestellt. 7 Mit diesem Programm ist es möglich, automatisch aus UML Klassendiagrammen im XMI Format, Code für Enterprise JavaBeans zu generieren. Aus der Idee, aus verschiedenen UML Modellen nicht nur statische sondern auch dynamische Sachverhalte abzubilden und daraus Code für Softwareapplikationen zu generieren, wurde AndroMDA entwickelt. Mit der Fertigstellung von AndroMDA im März 2003, sollte es nun möglich sein, aus UML Modellen sämtliche Implementierungen auf verschiedenen Zielsprachen zu generieren. Derzeit hält man bei dem Stable Release der Version 3.2 8, für die Zielsprachen Java und C#/.NET. 7 (Stand: ) 8 (Stand: )

32 Kapitel 3 - AndroMDA Seite 32 Unternehmens-Anwendungen (sog. Enterprise Applications) sind in mehreren Schichten (Layer) aufgebaut. Verschiedene Komponenten gleicher Funktion werden einer Schicht zugeordnet. Komponenten einer höheren Schicht nutzen die Funktionen und Services der Komponenten unterer Schichten [Andr06]. Aus Abbildung 14 geht hervor, wie die in AndroMDA verwendeten Technologien den einzelnen Schichten zugeordnet sind. Der Datenaustausch zwischen den einzelnen Schichten erfolgt über Value Objects (siehe 4.3.4). Abbildung 14: AndroMDA Schichtenmodell [Andr06] In Absatz wird der Begriff einer Plattform definiert. Wenn man nun diese Definition auf AndroMDA anwendet, so kann man die Architektur der einzelnen Schichten aus Abbildung 14, als die verwendete Plattform für AndroMDA bezeichnen. Sämtliche Modelle werden an die Belange dieser plattformspezifischen Eigenschaften angepasst.

33 Kapitel 3 - AndroMDA Seite 33 Presentation Layer AndroMDA bietet zwei grundsätzliche Technologien zum generieren einer webbasierten Präsentationsschicht, JSF (Java Server Faces) und Struts. Damit ist es möglich, aus Workflows, modelliert mit UML Aktivitätsdiagrammen, Webkomponenten, die auf dem JSF bzw. Struts Framework basieren, zu generieren. Business Layer Die Geschäftslogik wird in AndroMDA basierend auf dem Spring Framework generiert. Es werden leere Methodenrümpfe generiert, die dann vom Benutzer selbst mit der entsprechenden Geschäftslogik aufgefüllt werden müssen. Die Services des Business Layer können entweder mittels EJBs oder Webservices implementiert sein. Im Falle der EJBs, müssen diese in einem speziellen EJB Container "deployed" werden, z.b. JBoss. [Andr06] Data Access Layer AndroMDA bedient sich für den Datenzugriffslayer des Hibernate Objekt-relationalen Mappings. [siehe Hib05]. Data Stores Als Datenbanken kommen alle diejenigen in Frage, die von Hibernate unterstützt werden. [siehe Hib05].

34 Kapitel 3 - AndroMDA Seite AndroMDA Komponenten Da AndroMDA kein abgeschlossenes Tool, sondern ein Codegenerierungs- Framework ist, besteht es aus mehreren verschiedenen Komponenten. In Abbildung 15 wird der prinzipielle Aufbau und das Zusammenspiel der einzelnen Komponenten AndroMDAs veranschaulicht. Abbildung 15: AndroMDA Komponenten

35 Kapitel 3 - AndroMDA Seite UML Modellierungs-Tool AndroMDA selbst bietet kein integriertes Modellierungstool zur Auswahl an. Alle Referenzbeispiele AndroMDAs werden unter der Verwendung des Open Source Tools ArgoUML 0.20 oder dem kommerziellen MagicDraw 9.5 durchexerziert. Es gibt jedoch unzählige andere UML Tools, wie in [Andr06] Kapitel "UML Tools" aufgelistet. MagicDraw biete auch eine Community Version an, welche kostenlos verwendbar ist 9. Diese bietet jedoch nur volle Funktionalität für die Verwendung von Klassendiagrammen und Aktivitätsdiagrammen, mit bis zu 25 Objekten, an. Abbildung 16: MagicDraw UML Community Edition Generell müssen UML Tools nach [Andr06] für den Einsatz mit AndroMDA folgende Funktionalitäten besitzen: XMI (=XML MetaData Interchange) Export Funktionalität XMI Datei muss ein UML 1.4 Metamodel besitzen Klassendiagramme 9 Stand:

36 Kapitel 3 - AndroMDA Seite 36 Aktivitätsdiagramme (nur unter Verwendung mit der BPM4Struts und der jbpm Cartridge) UML Tagged Values UML Constraints (OCL) Maven Plugin Das gesamte AndroMDA Framework wird über das Maven Plugin gesteuert, welches aus dem Apache Ant Projekt weiterentwickelt wurde. Maven ist ein auf Java basierendes Build Management Tool welches mittels einer Plugin Architektur aufgebaut ist. Diese macht es möglich, dass Maven sämtliche für die jeweilige Applikation benötigten Plugin's automatisch über Internet bezieht ohne sie eigens installieren zu müssen. AndroMDA wird demzufolge als Plugin in Maven geladen und ausgeführt. Derzeit hält die Entwicklung von Maven bei der Version 2. AndroMDA.NET unterstützt jedoch nur die ältere Version, Maven MetaData Repository Um es AndroMDA zu ermöglichen, eine XMI Datei einzulesen und die Daten intern abzubilden, benötigt es ein MetaData Repository. Je nach verwendetem Modell, ob auf XMI [OMG05] oder EMF [EMF05] basierend, kann in AndroMDA ein anderes MetaData Repository eingesetzt werden. Im Falle AndroMDA ist dies das NetBeans Metadata Repository. Dieses wurde im Laufe des NetBeans Projektes entwickelt und ist kompatibel zu UML 1.3 und 1.4 [MDR03]. In AndroMDA werden die XMI Daten eines UML Modells mittels dem MDR im Speicher abgebildet (intanziiertes Metamodell) und können so für den weiteren verlauf der Codetransformation verwendet werden. So wird für jedes Modell-Element ein eigenes Java Objekt instanziiert. Die so im Speicher abgebildete Metamodell Objekte werden auch "Abstract Syntax Tree"(AST) genannt [Andr06]. Über Java Metadata Interfaces (JMI) [JMI02] kann nun auf die Java Metadaten Objekten zugegriffen werden.

37 Kapitel 3 - AndroMDA Seite Metafacades Metafacades (Kurzwort für Metamodel Facades) werden in AndroMDA verwendet, um auf die vom MetaData Repository geladenen Modell-Objekte zugreifen zu können. Die Metafacades basieren auf dem so genannten Facades Softwareentwurfsmuster der GOF (Gang of Four), siehe auch [Tarr00]. Diese Java Klassen sind simple Schnittstellen, die auf die darunterliegende Metamodell Implementierung Zugriff haben. Über das MDR werden die Metamodell Daten instanziiert und über JMI (Java Metadata Interface) [JMI02] zugänglich gemacht (Abbildung 17). Diese Interfaces der UML Metamodellobjekte sind jedoch sehr komplex aufgebaut. Um diese Komplexität zu verstecken, wird in AndroMDA das Facade Pattern eingesetzt. Metafacades sind simple Interfaces, die mit eigenen Methoden auf die Metamodellobjekte zugreifen, und so deren Komplexität von außen verbergen. Ein weitere Vorteil der Metafacades ist, dass man unabhängig von der konkreten Version des zugrundeliegenden Metamodells ist (z.b. UML2.0, UML 1.4, UML, 1.3). Außerdem übernehmen die Metafacades auch noch andere Aufgaben, wie die Validierung des Metamodells oder die Umsetzung der Translation Libraries und der Datatype Mappings, siehe Abschnitt und Abbildung 17: AndroMDA MetaFacades [Meta06]

38 Kapitel 3 - AndroMDA Seite 38 Über Templates ist es nun möglich, auf die Methoden der Metafacade Klassen zuzugreifen. In AndroMDA gibt es Basis Metafacades die bereits im AndroMDA Kern implementiert sind und spezielle Cartridge Metafacades. Die Basis Metafacades implementieren verschiedene Versionen von Metamodellen wie Abbildung 18 zeigt. Die Cartridge Metafacades basieren auf den Basis Metafacades und erweitern diese entsprechend. Auf welche Metafacades von den Templates aus zugegriffen wird, wird im Cartridges Deskriptor festgehalten, welcher im Abschnitt noch genauer unter die Lupe genommen wird. Abbildung 18: Metafacade Schichten [Meta06]

39 Kapitel 3 - AndroMDA Seite 39 Abbildung 19: ClassifierFacade Abbildung 19 zeigt den Zusammenhang zwischen einer Metaklasse Classifier und der zugehörigen Metafacade, ClassifierFacade. Die Klasse Classifier ist die Oberklasse der UML Klasse Class. ClassiefierFacade hat in diesem vereinfachten Fall 2 Methoden, getfullyqualifiedname(), welche den Namen der UML Klasse zurückgibt und getattributeslist(), welche eine Liste, bestehenden aus allen Attributen dieser Klasse zurückgibt. Über ein Template kann man die Methoden von ClassifierFacade folgend aufrufen: $class.getfullyqualifiedname $class.getattributesaslist Die Variable $class wird dabei im Cartridges Deskriptor definiert und zeigt in diesem Fall auf die Klasse ClassifierFacade Aufbau der Cartridges Cartridges (zu Deutsch: Kassette, Steckmodul, Patrone etc.) sind das Herzstück des AndroMDA Frameworks. Sie erlauben es, Modellelemente die mit Stereotypen gekennzeichnet sind, oder Elemente deren Abhängigkeit sich aus bestimmten Konditionen ergibt, (Akteure die eine Anhängigkeit zu einem <<Service>> haben) zu verarbeiten. [Andr06] Der zu generierende Code wird von den Templates vorgegeben, welche im Cartridge Deskriptor definiert sind. Tabelle 1 zeigt die in AndroMDA 3.2 standardmäßig verwendeten Cartridges. Cartridge Name BPM4Struts jbpm Beschreibung Business Process Modeling for Struts generiert Struts Webseiten aus UML Modellen, in denen Abläufe der Applikation modelliert sind. JBOSS BPM - generiert Prozess Definitionen aus UML Aktivitätsdiagrammen und Use Case Diagrammen

40 Kapitel 3 - AndroMDA Seite 40 JSF EJB Hibernate Java Meta Spring Webservice XML Schema Basiert auf dem Java Server Faces Framework generiert CMP (Container Managed Persistence) EJB's und Session Beans generiert das gesamte objektrelationale- Mapping AndroMDAs generiert Java Code generiert AndroMDA MetaFacades generiert Code basierend auf dem Spring Framework Generiert WSDD & WSDL (WS Deployment Description & WS-Definition Language) Files für Apache AXIS Generiert XML Schema aus einem Klassendiagramm Tabelle 1: Cartridges in AndroMDA Cartridge Deskriptor Jede Cartridge enthält einen Cartridge- und einen Metafacade Deskriptor. Der Cartridge Deskriptor beinhaltet sämtliche Informationen über die zur Verfügung stehenden Templates einer Cartridge in XML-Form. Folgendes Codestück zeigt einen Auszug aus dem Java Cartridge Deskriptor AndroMDAs. <cartridge> <templateengine class- Name="org.andromda.templateengines.velocity.VelocityTemplate Engine"/> <templateobject name="stringutils" class- Name="org.apache.commons.lang.StringUtils"/> <!-- cartridge-templateobject merge-point--> <property reference="serializable"/> <property reference="enablepropertyconstructors"/> <property reference="todotag"/> <property reference="enabletemplating"/> <property reference="securityenabled"/> <!-- cartridge-property merge-point--> <condition name="enabletemplating">$enabletemplating.equalsignorecase("true")</condition> <condition name="serializable">$serializable.equalsignorecase("true")</ condition>

41 Kapitel 3 - AndroMDA Seite 41 <!-- condition merge-point--> <!-- cartridge-resource merge-point --> <template path="templates/java/service.vsl" outputpattern="{0}/{1}.java" outlet="services" overwrite="true"> <modelelements variable="service"> <modelelement> <type name="org.andromda.metafacades.uml.service"/> </modelelement> </modelelements> </template> <template path="templates/java/serviceimpl.vsl" outputpattern="{0}/{1}impl.java" outlet="service-impls" overwrite="false"> <modelelements variable="service"> <modelelement> <type name="org.andromda.metafacades.uml.service"/> </modelelement> </modelelements> </template> <template path="templates/java/valueobject.vsl" outputpattern="{0}/{1}.java" outlet="value-objects" overwrite="true"> <modelelements variable="class"> <modelelement> <type name="org.andromda.metafacades.uml.valueobject"/> </modelelement> </modelelements> </template>... <template path="templates/java/interface.vsl" outputpattern="{0}/{1}.java" outlet="interfaces" overwrite="true"> <modelelements variable="interface"> <modelelement> <type name="org.andromda.metafacades.uml.classifierfacade"> <property name="interface"/> </type> </modelelement> </modelelements> </template> Listing 1: Cartridges Deskriptor

42 Kapitel 3 - AndroMDA Seite 42 Mit dem Element <templateobject> können Hilfs-Objekte einer Cartridge im Template verfügbar gemacht werden. Über das Attribute name= stringutils (das ist der Name der dann im Template verwendet wird) und einem classname kann vom Template aus auf das Objekt zugegriffen werden. Durch das <property> Element können Referenzen zu Werten diverser Eigenschaften der AndroMDA Cartridges hergestellt werden. Diese Werte sind im AndroMDA Konfigurationsfile (siehe Listing 2) in XML Form abgespeichert und stehen durch die Referenz während der Laufzeit zur Verfügung. Im Element <template> werden die wichtigsten Informationen über die Templates definiert. Zuerst wird der Pfad zur Template-Datei definiert. Mit outputpattern kann man steuern wie das File bzw. Template nach Verarbeitung der Template Engine ausgegeben werden soll (Dateiendung, Dateiname etc.). Mit variable=".." definiert man die Variable die im Template verwendet werden kann. Mit variable ="service" zum Beispiel macht man die Variable $service im Velocity Template verfügbar. Mit dem Element type verknüpft man das jeweilige Template mit der zugehörigen Metafacade Klasse. <namespace name="hibernate"> <properties> <property name="hibernatetypemappingsuri"> Hibernate </property> <property name="hibernateinheritancestrategy"> ${hibernate.inheritance.strategy} </property> <property name="defaulthibernategeneratorclass"> ${hibernate.generatorclass} </property> <property name="hibernatedefaultcascade"> none </property>... <property name="entity-impls"> ${maven.andromda.core.manual.dir} </property> <property name="entity-mappings"> ${maven.andro mda.core.generated.dir} </property> <property name="user-types"> ${maven.andromda. core.generated.dir} </property> <property name="customtypespackage"> ${appl ication.package}

43 Kapitel 3 - AndroMDA Seite 43 </property> <property name="compositiondefineseagerloading"> true </property> </properties> </namespace> <namespace name="java"> <properties> <property name="languagemappingsuri"> AxisJavaMappings </property> <property name="usearraysformultiplicitiesoftypemany"> True </property> <property name="enumerations"> ${maven.andromda.common.generated.dir} </property> <property name="exceptions"> ${maven.andromda.common.generated.dir} </property> <property name="value-objects"> ${maven.andromda.common.generated.dir} </property> </properties> Listing 2: Auszug aus dem AndroMDA Konfigurationsfile [Andro06] Metafacade Deskriptor Um die Metafacade Klassen steuern bzw. definieren zu können, benötigt man ebenfalls einen Deskriptor in XML-Form, der diese Arbeit übernimmt. Für diesen Deskriptor gibt es vielfältige Elemente und Variablen, in diesem Abschnitt sollen jedoch nur die wichtigsten erläutert werden. Folgender Codeabschnitt zeigt einen Ausschnitt des Metafacade Deskriptor der AndroMDA Hibernate Cartridge.

44 Kapitel 3 - AndroMDA Seite <metafacade class="org.andromda.cartridges.hibernate.metafacades.hibernateservicelogicimpl" contextroot="true"> <mapping class="org.omg.uml.foundation.core.umlclass$impl"> <stereotype>service</stereotype> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.hibernatetypelogicimpl"> <property reference="hibernatetypemappingsuri"/> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.hibernateenumerationlogicimpl"> <mapping class="org.omg.uml.foundation.core.umlclass$impl"> <stereotype>enumeration</stereotype> </mapping> </metafacade>... Listing 3: Metafacade Deskriptor der Hibernate Cartridge Die wichtigsten Elemente des Metafacade Deskriptor sind, <stereotype> und <mapping class="">. Mit ihnen lassen sich die Metafacade Klassen gezielt aufrufen wenn das Metamodell Element den jeweiligen Stereotypen enthält. Von welchem Typ das Meta Element sein soll, wird mit der class Variable des mapping Elements ausgewählt. Der fett gedruckte Bereich in obigem Codestück hat zur Folge, dass bei einem mit dem Stereotyp <<ENUMERATION>> gekennzeichneten Metamodell Element der Klasse org.omg.uml.foundation.core.umlclass$impl (also eine UML Klasse) die Metafacade Klasse org.andromda.cartridges.hibernate.metafacades.hiber nateenumerationlogicimpl ausgeführt wird. Mit diesem Mechanismus steuert man also die Instanziierung der Metafacade Klassen und Auswahl der zugehörigen Templates über die Stereotypen der Meta Modell Elemente. Dies funktioniert nicht nur bei UML Klassen sonder bei allen von der OMG definierten UML Meta Elementen (z.b. Klassen, Attribute, Operationen etc.)