KOMPONENTENBASIERTE ENTWICKLUNG AUF BASIS DER MODEL DRIVEN ARCHITECTURE

Transkript

1 von günther rackl, ulrike sommer, klaus beschorner, heinz kößler und adam bien KOMPONENTENBASIERTE ENTWICKLUNG AUF BASIS DER MODEL DRIVEN ARCHITECTURE Der generative Entwicklungsweg der Model Driven Architecture (MDA) ermöglicht auf Basis modellgetriebener Softwareentwicklung die effiziente und effektive Abbildung von Geschäftsprozessen auf Code. Die produktive Umsetzung und der gewinnbringende Einsatz dieses viel diskutierten Modellierungsparadigmas erfordern jedoch zunächst eine geeignete Interpretation der Kernkonzepte. Der Artikel zeigt einen durchgängigen Entwicklungsweg vom Geschäftsmodell zum Code anhand der in der BMW Group entwickelten Component Architecture (CA) und liefert damit ein Beispiel für die praktische Umsetzbarkeit der MDA. die autoren Dr. Günther Rackl ( beschäftigt sich im Bereich IT-Lösungen der BMW Group schwerpunktmäßig mit den Themengebieten Software- Modellierung und UML Case Tools. Aufgrund der immer weiter steigenden Komplexität der zu beherrschenden Entwicklungsstandards und der wachsenden Verbreitung von konkurrierenden Technologien wie J2EE, CORBA oder.net setzen sich modellgetriebene Entwicklungsmethoden zunehmend in der Praxis durch. Universell gültige Anwendungsmodelle versprechen in Verbindung mit generativer Softwareentwicklung eine größere Effizienz, die einfachere Integration von Fachexperten in den frühen Designphasen und die bessere Qualitätssicherung und Wartung der Anwendungen (vgl. [Völ04]). Da die Software teilweise oder vollständig aus technologieunabhängigen Modellen generiert wird, können Abhängigkeiten zu einer konkreten Technologie und Inkonsistenzen zwischen den verschiedenen Architekturschichten einer Anwendung überwunden werden. Zusätzlich fördern einheitliche Designvorgaben und Kodierungsrichtlinien die Standardisierung von Anwendungsarchitekturen und führen durch die Verwendung von Entwurfsmustern und Best Practices zu einer höheren Softwarequalität. Modellgetriebene Entwicklungsansätze sind vor allem dann gewinnbringend, wenn ein hoher Automatisierungsgrad und die Wiederverwendung von Modellen, Generatoren und Transformatoren in verschiedenen Projekten gewährleistet sind. Voraussetzung hierfür ist die exakte Beschreibung der Architektur oder die Festlegung eines Architekturstils. Die Kernkonzepte der MDA müssen entsprechend für die produktive Umsetzung im Hinblick auf die jeweilige Anwendungs- gruppe geeignet interpretiert werden. Vor diesem Hintergrund wurde in der BMW Group eine zentrale Komponentenarchitektur für die durchgängige Abbildung von Geschäftslogik auf eine unternehmensweite IT-Anwendungsarchitektur entwickelt. Um eine pragmatische Herangehensweise zu ermöglichen, wurde bei der Abbildung auf eine Technologie zunächst nur das J2EE-Umfeld (Java 2 Enterprise Edition) betrachtet. Die Komponentenarchitektur Der modellgetriebene Ansatz der Component Architecture (CA) basiert auf dem generativen Entwicklungsweg der MDA und den damit verbundenen drei Architekturschichten Platform Independent Model (PIM), Platform Specific Model (PSM) und Implementierung. Die CA besteht aus den folgenden Elementen: einem Modellierungsprofil, mit dessen Hilfe das plattformunabhängige Modell auf Basis der UML, komponentenbasierter Entwicklung und allgemeinen Architekturprinzipien formuliert werden kann, Modelltransformatoren, die das Modellierungsprofil auf das J2EE-1.3- konforme plattformspezifische Modell und anschließend auf Code abbilden, und einem Framework, das die J2EE-Infrastruktur kapselt und dem Anwender als Basisfunktionalität zur Verfügung stellt. Dr. Ulrike Sommer ( ulrike.sommer@bmw.de) arbeitet im Kompetenzzentrum IT- Architekturen der BMW Group mit den Themenschwerpunkten komponentenbasierte Entwicklung und J2EE. Dr. Klaus Beschorner ( klaus.beschorner@bmw.de) ist IT-Spezialist im Bereich IT-Lösungen der BMW Group und beschäftigt sich mit Architekturen und Frameworks im J2EE-Umfeld. Heinz Kößler ( heinz.koessler@bmw.de) arbeitet im Kompetenzzentrum IT-Architekturen in der Ressort-IT Produktion der BMW Group als Chefarchitekt in Projekten mit dem Schwerpunkt J2EE. Adam Bien ( abien@adam-bien.com) ist freiberuflicher Berater, Dozent und Buchautor mit dem Schwerpunkt Enterprise- Architekturen, Frameworks und J2EE. 5/2004

2 genaue Erläuterung der wichtigsten Modellierungselemente erfolgt in Tabelle 1. Abb. 1: Aufbau einer Komponente In allen drei Elementen werden gängige Entwurfsmuster, Best Practices und konzernweit gültige Richtlinien bei der Implementierung von Softwaresystemen berücksichtigt. Modellierung der Fachlogik In der CA wird die Geschäftslogik zunächst technologieneutral in einem Komponentenmodell (PIM) mit Hilfe der UML spezifiziert. Den Kern der CA- Designsprache bilden die Geschäftsobjekte, die als fein-granulare und wieder verwendbare Einheiten Daten, Logik und Regeln zusammenfassen und in Komponenten strukturiert sind. Die CA versteht unter dem Begriff Komponente eine konsistente, eigenständige Einheit, die aus kohäsiven Elementen besteht, auf die nur über ihre fachliche Schnittstelle zugegriffen wird. Die verfügbaren Modellierungselemente (Artefakte) der CA sind in Abbildung 1 dargestellt. Wichtig ist die Unterscheidung zwischen der Außensicht (Spezifikation) und der Innensicht (Realisierung) einer Komponente. Lediglich die Spezifikation ist nach außen sichtbar und stellt die fachlichen Schnittstellen einer Anwendung zur Verfügung. Die Implementierungsdetails werden in der Komponente gekapselt. Entsprechend lassen sich die Modellierungselemente gemäß ihren Aufgaben in die verschiedenen Schichten Service- Schnittstellen, Ablaufsteuerung, Verhalten und Daten strukturieren. Eine Abbildung auf J2EE 1.3 Die Formalisierung der zu verwendenden Modellierungselemente und deren durchgängige Verwendung im PIM ermöglichen die automatisierte Abbildung auf die J2EE- Plattform. Dabei basiert die Architektur des J2EE-PSM im Wesentlichen auf den bekannten J2EE-Patterns (vgl. [Alu01], [Fow03]), die jedoch im Detail erweitert wurden. Die CA-Komponenten werden auf Java-Packages abgebildet, die entsprechend der Schichtung in spec, facade, behavior, data und adapter Unter-Packages strukturiert sind. Im PIM werden lediglich die Beziehungen zwischen den Modellierungselementen sowie ihre Methoden und Attribute modelliert für die Berücksichtigung der Designprinzipien sind der Transformationsprozess und das PSM zuständig. Abbildung 2 zeigt ein Beispiel für ein PIM, in dem die Prozessartefakte Business Entities (BEs) als Parameter oder Rückgabewerte verwenden. Bei der Transformation werden diese kontextabhängig in Value-Objekte (VOs), lokale Schnittstellen oder Primärschlüssel umgewandelt. Die OrderStatusBE wird beispielsweise entweder in ein OrderStatusBEVO oder eine OrderStatusBEIF transformiert. Innerhalb der Realisierung einer Komponente verwenden die Business Activities (BAs) die Abb. 2: Eine Business Component im PIM

3 Name des Artefakts Kurzbeschreibung Abbildung auf J2EE Business Component (BC) Fachliche CA-2.0-Komponente. Sie bildet einen Container, Ein strukturiertes Composite Java-Package mit der verschiedene CA-Artefakte auf Basis bestimmter definierten Abhängigkeiten zu Architekturvorschriften gruppiert. Nachbarkomponenten. Business Component Fachliche Schnittstelle (Spezifikation); Service-Schnittstelle, Business Delegate-Pattern, Service Locator (Bestand- Interface (BCI) die von den Clients bzw. der Präsentationslogik verwendet teil des CA-2.0-Frameworks) und eine konfigurierbare wird. Das BCI ist Bestandteil der Spezifikation und Factory. Die öffentliche chnittstelle des Business S Delegates gewährleistet somit auch die einfache Wiederverwend- realisiert das BCI mit Hilfe eines Java Interfaces. barkeit und Testbarkeit der Komponenten. Zusätzlich wird ein passender JUnit-Test angelegt. Business Facade (BF) Ablaufsteuerung des modellierten Use-Cases, Dekoration um Session Façade Pattern mit Stateless oder Stateful zusätzliche Fähigkeiten und Abbildung von fachlichen Prozessen. Session Bean. Alle Methoden des Remote-Interfaces Zu ihren Aufgaben gehören z. B. die Zustandsverwaltung des Clients, werden mit dem Transaktionslevel Required die Transaktionssteuerung und die Realisierung der Sicherheit. oder Requires New versehen. Das Verhalten der Komponente wird durch einzelne fachliche Aktivitäten (Business Activities) abgebildet. Business Activity (BA) Abbildung einzelner fachlicher Aktivitäten, wie z. B. not- Lokale Stateless Session Bean. Aus der BA wendige Algorithmen. Eine BA ist transient und zustandslos. entstehen die Methoden des Local-Interfaces Jede einzelne Methode einer BA bildet eine atomare Aktivität der Stateless Session Bean. Eine BA wird mit dem ab, die vollständig ausgeführt wird, oder gar nicht. Transaktionslevel Mandatory versehen. Business Entity (BE) Sind für die eigentliche Datenhaltung CMP 2.0 Entity Bean oder ein Data Access Object (DAO) zuständig. Eine BE besteht aus einer und ein Value Object (VO). Aus den Attributen einer zusammengehörigen Gruppierung von BE entsteht immer zumindest ein VO, das als Parameter oder Attributen mit fachlichen oder elementaren Rückgabetyp verwendet wird. Falls ein DAO für die Abbildung Datentypen. der Persistenz einer BE gewählt wird, entstehen aus den statischen BE-Methoden die Methoden des DAO-Interfaces. Das Business-Interface (DataEntity) der CMP 2.0 Entity Bean dient der Abstraktion von der jeweiligen Technologie und könnte als Vorgabe von z.b. Java Data Objects dienen. Event Listener (EL) Ein EL führt beliebige, synchrone Methoden eines Inter-Component- Eine Message Driven Bean oder die Interface oder eines Business-Component-Interface asynchron aus. Implementierung eines Message Listeners. Bei der PIM-Erstellung ist die Art der technischen Realisierung eines EL noch nicht bekannt (Threads, Messaging usw.). Tabelle 1: Modellierungselemente der CA mit Abbildungsregeln auf J2EE 1.3 Referenz der BE. Erst kurz vor der Übertragung (in der Ablaufsteuerung) kommen VOs zum Einsatz. Abbildung 3 zeigt einen Ausschnitt aus der Transformation des PIM in das zugehörige PSM. Das PSM verfügt über Annotationen, die für die letzte Stufe der Generierung benötigt werden. Informationen über die Transaktionssteuerung, Pooling, Caching oder Locking-Strategien werden für die Generierung der Deployment-Deskriptoren und der Enterprise Archives (EARs) benötigt. Generative Entwicklung auf Basis der MDA Die Entwicklung mit der CA ist eine Form der modellgetriebenen Softwareentwicklung (Model Driven Software Development, vgl. [Völ04]) und basiert auf einer pragmatischen Umsetzung der MDA (vgl. [Mil03]). Neben der Definition der Modellebenen PIM, PSM und Implementierung (Quellcode) spielt hier die Automatisierung der Transformationen zwischen den Ebenen eine essenzielle Rolle. Der Ablauf der Entwicklung ist iterativ und beginnt mit der Ableitung der PIM- Elemente aus den fachlichen Anforderungen. Anhand von Use-Cases und fachlichen Grundkonzepten (Key Abstractions) werden BAs und BEs identifiziert, die dann zu kohäsiven Business Components gruppiert werden. Die Definition der Business Component Interfaces als Außenschnittstellen der Komponenten wird aus den resultierenden BFs abgeleitet. Im Anschluss an die Modellierung des PIM wird der Entwicklungsprozess mit der automatischen Transformation in das PSM fortgesetzt (siehe Abb. 4), das mit technischen Aspekten verfeinert und anschließend durch eine Transformation auf Quellcode abgebildet wird. Dieser Prozess wird iterativ durchlaufen, wobei zu beachten ist, dass fachliche Änderungen (z. B. Hinzufügen von Methoden in BAs) ausschließlich im PIM durchgeführt werden. Die iterative Transformation des PIM aktualisiert das PSM und den Code ohne Beeinträchtigung existierender Elemente. Generiert werden nur die Codegerüste der Anwendung, die Applikationslogik wird anschließend vom Entwickler manuell hinzugefügt. Der CA-Entwicklungsweg setzt also auf der dreistufigen Hierarchie von PIM, PSM und Quellcode auf im Gegensatz zu einigen in der Praxis gängigen Werkzeugen ist hier auch die Stufe des PSM explizit im Modellierungswerkzeug sichtbar. Die Gründe für diese explizite Darstellung des PSM liegen einerseits in der Möglichkeit zur Anreicherung des PSM mit technischen Informationen, die im rein fachlichen PIM nicht gewünscht sind (wie zum Beispiel Tabellennamen für die Datenbank), und zum anderen in der Verwendung des PSM als Dokumentation für die entstehende technische Architektur des Systems. Vor allem auch die Funktion des PSM als Dokumentation ist für den späteren Betrieb der Anwendung nicht zu unterschätzen, da hier ein schneller Überblick über die technischen Gegebenheiten der Anwendung gewonnen werden kann. Modelltransformationen Die kritischen Punkte bei der Umsetzung modellgetriebener Entwicklungsprozesse sind die Modelltransformationen, welche die verschiedenen Abstraktionsstufen (PIMs, PSMs) ineinander überführen. Eine Umsetzung im Sinne der MDA legt eine Verwendung der OMG-Technologien zur Beschreibung der Abstraktionsstufen sowie der Transformationen nahe. Die Beschreibung der Abstraktionsstufen erfolgt dabei durch die Definition von domänenspezifischen Metamodellen auf Basis der Meta Object Facility (MOF) oder anhand von UML-Profilen. Die Definition der Modelltransformation soll mit der zur Zeit bei der OMG als Entwurf vorliegenden QVT-Spezifikation (Queries, Views and Transformations) festgelegt werden (vgl. [OMG03]), wobei der Prozess zur Standardisierung der Transformationen noch nicht abgeschlossen ist und daher zur Zeit keine standar-

4 Abb. 3: Abbildung der Business Component ins PSM disierte Lösung zur Beschreibung der Modelltransformationen existiert. Auf dem Markt vorhandene Werkzeuge setzen folglich allesamt auf proprietären Ansätzen zur Definition von Modelltransformationen auf. Die Beschreibung der Modelltransformationen erfolgt in den meisten verfügbaren Werkzeugen durch die Verwendung von Skriptsprachen oder template-basierten Ersetzungsmechanismen, was einer Programmierung der Modelltransformationen entspricht. Weiterführende Ansätze ermöglichen eine Modellierung der Transformationen, was der Definition eines Metamodells für die Modelltransformationen gleichkommt. Die CA-Werkzeugumgebung Die Auswahl der Werkzeugumgebung für die Umsetzung des CA-Entwicklungsprozesses und der Modelltransformationen ist durch folgende Auswahlkriterien motiviert: möglichst weit gehende Standard- Konformität, explizite Modellierbarkeit mehrerer Abstraktionsstufen, geringer Aufwand zur Implementierung eigener domänenspezifischer Umgebungen und zur Wartung der Abbildungsvorschriften, Unabhängigkeit von Modellierungswerkzeugen und Integrierbarkeit in existierende Werkzeuglandschaften und Prozesse. Im derzeitigen Stadium der MDA- Initiative sowie der auf dem Markt verfügbaren Werkzeuge sind leider nicht alle obigen Kriterien in der Praxis erfüllbar. Weil die Standardisierungsbestrebungen der OMG noch nicht abgeschlossen sind und der Markt der MDA-Werkzeuge noch stark in Bewegung ist, verwendet die CA einen pragmatischen Weg zur Umsetzung des Entwicklungsprozesses mit existierenden Werkzeugen, um zeitnah die Vorteile der modellgetriebenen Entwicklung in der Praxis nutzen zu können. Abb. 4: Modelltransformationen im Entwicklungsweg der CA PIM/PSM-Transformation Die Implementierung der PIM/PSM- Transformation erfolgt auf Basis eines Metamodells, das die Abbildung der PIM- Elemente auf die J2EE-Plattform beschreibt und das selbst in UML modelliert ist. PIM und PSM werden dabei unter Verwendung von Mechanismen zur UML- Profilbildung mittels Stereotypen definiert. Der Modelltransformator reagiert nun auf die durch die Stereotypen identifizierbaren Artefakte des PIMs und erzeugt die dazu passenden PSM-Elemente, wobei jedes im PIM definierte CA-Element die im Metamodell spezifizierten PSM-Elemente erzeugt. Die Kernelemente des UML- Profils im CASE-Tool sind in Abbildung 5 dargestellt bei der Anwendung der Transformation werden die entsprechenden Platzhalter der Metamodell-Elemente durch die tatsächlichen verwendeten Namen im PIM ersetzt. Der PIM/PSM-Transformator ist technisch in das bei der BMW Group eingesetzte Modellierungswerkzeug Borland Together integriert und erlaubt dort sowohl die Modellierung des PIMs als auch die Definition des Metamodells für die Transformationen in das PSM. Um eine weitgehende Werkzeugunabhängigkeit zu wahren, abstrahiert der Transformator-Kern von der Together-Programmierschnittstelle und erlaubt so eine unkomplizierte Übertragung auch auf andere UML-Werkzeuge. PSM-Quellcode-Transformation (Codegenerierung) Aus der Transformation des PIM entsteht im UML-Werkzeug ein PSM, das mit zusätzlichen Informationen angereichert oder verfeinert werden kann. Die anschließende Abbildung des PSM für J2EE auf Quellcode wird durch das Werkzeug xdoclet (vgl. [XDOC]) realisiert. xdoclet ist ein Open-Source- Werkzeug zur Codegenerierung, das auf Basis attribut-orientierter Programmierung für die Codegenerierung aus dem PSM in die J2EE-Plattform und die verwendeten Applikationsserver bestens geeignet ist. Die Attribute für die J2EEspezifische Codegenerierung werden bei der Erzeugung des PSM durch den PIM/PSM-Transformator bereits erstellt und können bei Bedarf im PSM nochmals angepasst werden. Die Transforma

5 Abb. 5: Kernelemente des CA-Metamodells tionsregeln werden durch xdoclet-templates gesteuert, welche die Abbildung der xdoclet-tags auf Quellcode definieren. Indem die Abbildung des PSM auf die J2EE-Plattform weitgehend stabil ist, sind diese Templates nur sehr selten anzupassen im Rahmen der CA wurden lediglich marginale Anpassungen der Templates an verwendete Applikationsserver durchgeführt. Vorteile des CA-Entwicklungsweges Der Vorteil der CA-Werkzeugumgebung besteht vor allem in der einfachen und schnellen Implementierung und Anpassung der Abbildungsregeln auf Basis der beschriebenen Metamodellierung, die anhand eines übersichtlichen UML- Modells die Definition der PIM/PSM- Transformation erlaubt. Diese Realisierung ermöglicht überdies eine Beschreibung der Transformationen ohne die Verwendung proprietärer Skriptsprachen. Somit bleibt die implementierte Lösung durch ihre Flexibilität auch offen für einen potenziellen Übergang zu neuen, standardisierten MDA-Lösungen, auch wenn derzeit nicht alle der eingangs genannten Forderungen durch die CA- Werkzeugumgebung erfüllt werden können. In seiner Gesamtheit betrachtet, stellt der CA-Entwicklungsweg damit einen iterativen und teil-automatisierten Prozess im Sinne der MDA dar. Der Mehrwert der Modellierung von Anwendungssystemen wird durch die automatisierte Transformation auf technische Plattformen klar herausgestellt, was einerseits die Motivation zur Modellierung fördert und andererseits ein stets aktuelles fachliches Modell einer Anwendung als Ergebnis liefert. Dies stellt einen essenziellen Vorteil bei der langfristigen Betreuung und Wartung von Systemen dar und trägt massiv zu einer nachhaltigen Modellierung von IT-Systemen bei. Erfahrungen und Ausblick Die MDA ist ein viel versprechendes Konzept für die Softwareentwicklung und bereits heute praktisch einsetzbar. Hierfür ist es jedoch notwendig den MDA-Ansatz mit pragmatischen Konzepten geeignet zu interpretieren. So ist es heute kaum praktisch umsetzbar, fachliche Algorithmen in Diagrammen zu modellieren, um daraus eine vollständige Code-Generierung zu erreichen. Bei dem pilothaften Einsatz der CA in Projekten der BMW Group konnten folgende Erfahrungen gemacht werden: Als großer Vorteil der CA wird die einheitliche Designsprache gewertet. Mit dem Modellierungsprofil der CA ist es nun möglich, auch in der fachlichen Modellierung eine gemeinsame Sprache innerhalb eines Teams zu benutzen, was den Einstieg neuer Projektmitglieder erleichtert und insbesondere auch die verbesserte Mitarbeit der Fachexperten ermöglicht. Die Unabhängigkeit von Geschäftslogik und Technologie in Kombination mit dem generativen Entwicklungsweg führen zu einer deutlichen Verkürzung der Entwicklungszeiten. Die technische Umsetzung durch die Integration in ein UML-Werkzeug vereinfacht dabei die Anwendung der Transformationen. Durch die Trennung der Geschäftslogik von der darunter liegenden Plattform bleiben die langlebigen fachlichen Anteile einer Anwendung von kurzlebigen Technologien und Versionswechseln relativ unberührt (vgl. [Eic04]). Durch die Verwendung von Best Practices und einheitlichen Transformationsregeln ergeben sich homogene Anwendungen, die sich an konzernweit gültigen Standards orientieren. Neben der einfacheren Testbarkeit erleichtern einheitliche Namenskonventionen, Code- und Package-Strukturen zusätzlich die Wartung der Systeme. Expertenwissen in Form von J2EE- Entwurfsmustern steht unmittelbar für Entwickler unterschiedlicher Kenntnisstufen zur Verfügung, die Systeme sind von Beginn an klarer strukturiert und erlauben eine noch stärkere Fokussierung auf die Implementierung der Fachlichkeit. Die damit verbundene Erhöhung der Softwarequalität wird grundsätzlich auch durch die Codegenerierung gefördert, da die Auseinandersetzung mit J2EE- Konstrukten, wie z. B. Client- Interfaces, Deskriptoren, Anwendungsarchiven, reduziert wird. Aufgrund der positiven Erfahrungen in Pilotprojekten soll die CA in Kürze konzernweit eingeführt werden. Die Herausforderung beim weitläufigeren Einsatz der CA besteht dabei auch in einer Änderung der Arbeitsweise bei der Entwicklung, da das Denken in Modellen sich etablieren und die Modellierung gegenüber der Codierung an Stellenwert gewinnen muss. In Zukunft ist außerdem eine stark verbesserte Werkzeugunterstützung für generative Lösungen zu erwarten. Dazu gehören insbesondere eine verbesserte Standardisierung der Austauschformate von Modellen und aus Sicht der MDA wünschenswerte Funktionalitäten, wie z.b. Profile und Constraint-Unterstützung. Ein hier viel versprechender Ansatz ist die UML 2.0, da die Neuauflage der Modellierungssprache hinsichtlich der MDA wesentliche Verbesserungen bringt (z.b. UML-Profile, Modellaustausch mit XMI). Diese Entwicklungen könnten in Zukunft dazu führen, dass die Eigenimplementierung des Transformationsprozesses durch eine Standardlösung ersetzt werden kann. Diese Möglichkeit wurde in der CA durch die Architektur des Transformators so weit wie möglich berücksichtigt. Literatur & Links [Alu01] D. Alur, J. Crupi, D. Malks, Core J2EE Patterns Best Practices and Design Strategies, Sun Microsystems, 2001 [Eic04] S. Eich, E. Wagner, D. Menges, Geschäftslogik-zentrierte Architekturen in J2EE, in: OBJEKTspektrum 4/04 [Fow03] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2003 [Mil03] J. Miller, J. Mukerji (Hrsg.), MDA Guide Version 1.0.1, OMG Dokument omg/ , 2003 [OMG03] Object Management Group (OMG), MOF 2.0 Query/Views/Transformations RFP, Oktober 2003 [Völ04] M. Völter, Modellgetriebene Softwareentwicklung, in: OBJEKTspektrum 4/04 [XDOC] xdoclet Homepage, siehe: xdoclet. sourceforge.net 5/2004