model driven architecture

objekte
model driven architecture
v o n g ü n t h e r r a c k l , u l r i k e s o m m e r,
k l a u s b e s c h o r n e r, h e i n z k ö ß l e r
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.
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-
5/2004
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.3konforme 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.
d i e a u t o re n
Dr. Günther Rackl
(E-Mail: [email protected])
beschäftigt sich im Bereich IT-Lösungen
der BMW Group schwerpunktmäßig
mit den Themengebieten SoftwareModellierung und UML Case Tools.
Dr. Ulrike Sommer
(E-Mail: [email protected])
arbeitet im Kompetenzzentrum ITArchitekturen der BMW Group mit den
Themenschwerpunkten komponentenbasierte Entwicklung und J2EE.
Dr. Klaus Beschorner
(E-Mail: [email protected]) 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
(E-Mail: [email protected]) arbeitet im Kompetenzzentrum IT-Architekturen in der Ressort-IT Produktion
der BMW Group als Chefarchitekt in
Projekten mit dem Schwerpunkt J2EE.
Adam Bien
(E-Mail: [email protected]) ist freiberuflicher Berater, Dozent und Buchautor mit dem Schwerpunkt EnterpriseArchitekturen, Frameworks und J2EE.
w w w. s i g s - d a t a c o m . d e
objekte
model driven architecture
genaue Erläuterung der wichtigsten Modellierungselemente erfolgt in Tabelle 1.
Abbildung auf J2EE 1.3
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 CADesignsprache 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 „ServiceSchnittstellen”, „Ablaufsteuerung”, „Verhalten” und „Daten” strukturieren. Eine
Die Formalisierung der zu verwendenden
Modellierungselemente und deren durchgängige Verwendung im PIM ermöglichen
die automatisierte Abbildung auf die J2EEPlattform. 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
44
45
w w w. o b j e k t s p e k t r u m . d e
objekte
model driven architecture
Name des Artefakts
Kurzbeschreibung
Abbildung auf J2EE
Business Component (BC)
Fachliche CA-2.0-Komponente. Sie bildet einen Container,
der verschiedene CA-Artefakte auf Basis bestimmter
Architekturvorschriften gruppiert.
Ein strukturiertes Composite Java-Package mit
definierten Abhängigkeiten zu
Nachbarkomponenten.
Business Component
Interface (BCI)
Fachliche Schnittstelle (Spezifikation); Service-Schnittstelle,
die von den Clients bzw. der Präsentationslogik verwendet
wird. Das BCI ist Bestandteil der Spezifikation und
gewährleistet somit auch die einfache Wiederverwendbarkeit und Testbarkeit der Komponenten.
Business Delegate-Pattern, Service Locator (Bestandteil des CA-2.0-Frameworks) und eine konfigurierbare
Factory. Die öffentliche chnittstelle des Business S Delegates
realisiert das BCI mit Hilfe eines Java Interfaces.
Zusätzlich wird ein passender JUnit-Test angelegt.
Business Facade (BF)
Ablaufsteuerung des modellierten Use-Cases, Dekoration um
zusätzliche Fähigkeiten und Abbildung von fachlichen Prozessen.
Zu ihren Aufgaben gehören z. B. die Zustandsverwaltung des Clients,
die Transaktionssteuerung und die Realisierung der Sicherheit.
Das Verhalten der Komponente wird durch einzelne fachliche
Aktivitäten (Business Activities) abgebildet.
Session Façade Pattern mit Stateless oder Stateful
Session Bean. Alle Methoden des Remote-Interfaces
werden mit dem Transaktionslevel Required
oder Requires New versehen.
Business Activity (BA)
Abbildung einzelner fachlicher Aktivitäten, wie z. B. notwendige Algorithmen. Eine BA ist transient und zustandslos.
Jede einzelne Methode einer BA bildet eine atomare Aktivität
ab, die vollständig ausgeführt wird, oder gar nicht.
Lokale Stateless Session Bean. Aus der BA
entstehen die Methoden des Local-Interfaces
der Stateless Session Bean. Eine BA wird mit dem
Transaktionslevel Mandatory versehen.
Business Entity (BE)
Sind für die eigentliche Datenhaltung
zuständig. Eine BE besteht aus einer
zusammengehörigen Gruppierung von
Attributen mit fachlichen oder elementaren
Datentypen.
CMP 2.0 Entity Bean oder ein Data Access Object (DAO)
und ein Value Object (VO). Aus den Attributen einer
BE entsteht immer zumindest ein VO, das als Parameter oder
Rückgabetyp verwendet wird. Falls ein DAO für die Abbildung
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-ComponentInterface oder eines Business-Component-Interface asynchron aus.
Bei der PIM-Erstellung ist die Art der technischen Realisierung eines EL
noch nicht bekannt (Threads, Messaging usw.).
Eine Message Driven Bean oder die
Implementierung eines Message Listeners.
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 PIMElemente aus den fachlichen Anforderungen. Anhand von Use-Cases und
fachlichen Grundkonzepten (Key Abstractions) werden BAs und BEs identifiziert,
die dann zu kohäsiven Business Compo-
nents 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-
objekte
model driven architecture
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:
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.
PIM/PSM-Transformation
Die Implementierung der PIM/PSMTransformation erfolgt auf Basis eines
Metamodells, das die Abbildung der PIMElemente auf die J2EE-Plattform beschreibt und das selbst in UML modelliert
ist. PIM und PSM werden dabei unter
Verwendung von Mechanismen zur UMLProfilbildung 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 Meta-
■ möglichst weit gehende StandardKonformitä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 MDAInitiative sowie der auf dem Markt verfügbaren Werkzeuge sind leider nicht alle obigen Kriterien in der Praxis erfüllbar. Weil
46
47
Abb. 4: Modelltransformationen im
Entwicklungsweg der CA
modell spezifizierten PSM-Elemente
erzeugt. Die Kernelemente des UMLProfils 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-SourceWerkzeug 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-
w w w. o b j e k t s p e k t r u m . d e
objekte
model driven architecture
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
J2EEKonstrukten, wie z. B. ClientInterfaces, Deskriptoren, Anwendungsarchiven, reduziert wird.
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 UMLModells die Definition der PIM/PSMTransformation 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 CAWerkzeugumgebung 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
5/2004
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 J2EEEntwurfsmustern steht unmittelbar für
Entwickler unterschiedlicher Kenntnisstufen zur Verfügung, die Systeme
sind von Beginn an klarer strukturiert
und erlauben eine noch stärkere
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-06-01, 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
w w w. s i g s - d a t a c o m . d e