OMG Model Driven Architecture - Grundlagen der MDA
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Westfälische Wilhelms-Universität Münster
Seminararbeit
OMG Model Driven Architecture -
Grundlagen der MDA
Im Rahmen des Seminars
“Ausgewählte Kapitel des Software Engineering insbesondere Formale Spezifikation“
Markus Pepping
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Dipl.-Wirt. Inform. Christoph Lembeck
Institut für Wirtschaftsinformatik
Praktische Informatik in der WirtschaftInhaltsverzeichnis
Inhaltsverzeichnis
1 Einführung in die Modell Driven Architecture............................................................ 1
2 Theoretische Konzepte und Implementierungsbeispiele der MDA ............................. 2
2.1 Architektur und konstituierende Grundprinzipien ................................................ 2
2.1.1 Modelle in der MDA ................................................................................... 7
2.1.2 Elementare Modelltypen.............................................................................. 8
2.1.3 Metamodelle .............................................................................................. 11
2.2 Transformationen ................................................................................................ 13
2.2.1 Grundlegende Transformationsmöglichkeiten .......................................... 14
2.2.2 Modelltansformationsansätze .................................................................... 16
3 Kritische Beurteilung der MDA................................................................................. 18
4 Fazit und Ausblick ..................................................................................................... 20
Literaturverzeichnis ........................................................................................................ 21Kapitel 1: Einführung in die Modell Driven Architecture
1 Einführung in die Modell Driven Architecture
Mehr als zuvor ist die Entwicklung von Software eine diffizile und problematische
Herausforderung geworden. Eines der wichtigsten Faktoren ist die zunehmende Größe
und gewachsene Komplexität von Softwareprodukten. Dieser wird versucht durch
ausgewählte Problemlösungsstrategien, wie beispielsweise durch Abstraktion oder
Isolierung von Teilproblemen, im Streben nach Überschaubarkeit entgegenzuwirken.
Besonders der Gebrauch von Softwaremodellen ist ein klassischer Weg, um diese
Prinzipien effizient zu nutzen [Se03a, S. 1].
Der modellgetriebene Ansatz zur Softwareentwicklung besitzt großes Potential, die
Qualität und Produktivität der Softwareentwicklung zu steigern, indem die wichtigsten
Aspekte in der Lösung in einer menschlich lesbaren Form beschrieben
werden [Se03b, S. 1]. Um diesen Ansatz zu standardisieren, ist die OMG ins Leben
gerufen worden. Dieses offene Konsortium führender Softwareentwickler haben sich
zur Aufgabe gemacht, vereinheitlichte Regeln im Rahmen der industriellen
Softwareentwicklung vorzugeben. Dieser Standardisierungsprozess hat zur Zeit den
Status einer konzeptionellen Vorschrift. Ziel der MDA ist eine einheitliche und
modellgetriebene Softwareentwicklung, die eine konsistente und aufeinander
aufbauende Entwicklung einzelner Softwareentwicklungsphasen unterstützt [OMG05d].
Hierzu gibt Kapitel 2 einen Überblick über die konzeptionellen Grundlagen und
Zusammenhänge der MDA. Es werden Schrittweise die wichtigsten Aspekte der MDA
eingehend beschrieben und an passenden Stellen ein einheitliches Beispiel zur
Illustration aufgezeigt. Da die MDA viele Technologien vereint, werden aufgrund des
begrenzten Rahmens der Seminararbeit ihre Ziele und Grundlagen dargelegt und für ein
eingehendes Studium wird auf weitere Quellen verwiesen.
Kapitel 3 setzt sich kritisch mit dem Nutzen und den Kosten der MDA auseinander.
Hier werden die wichtigsten Vor- und Nachteile modellgetriebener Architekturen
dargestellt und auf Basis dessen beispielhafte Abgrenzungskriterien aufgezeigt, die
einen Einsatz rechtfertigen oder eine Anwendung der MDA ausschließen.
Anschließend wird in Kapitel 4 ein kleiner Ausblick auf zukünftige Fortentwicklungen
der MDA gegeben.
1Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
2 Theoretische Konzepte und Implementierungsbeispiele der
MDA
Eines der Ziele der OMG (Object Management Group) ist die Erstellung von
herstellerneutralen Spezifikationen zur Verbesserung der Interoperabilität und
Portabilität zwischen verschiedenen Softwaresystemen [OMG05c]. Seit ihrer Gründung
im April 1989 ist das Konsortium von elf auf etwa 800 Mitglieder
angewachsen [Pf04, S. 1]. Primäres Ziel ist die Sicherstellung der „reusability,
portability and interoperability of object-based software in distributed, heterogeneous
environments“ [OMG02a]. Dafür werden von der OMG objektorientierte
Industriestandards erstellt, verabschiedet und gepflegt [Ko01, S. 32]. Dies geschieht in
einem klar definierten Verfahren, dem so genannten „Open Process“, an dem sich jedes
Mitglied der OMG beteiligen kann. In diesem Verfahren werden Vorschläge für
Spezifikationen eingebracht, verhandelt und schließlich als Standards verabschiedet. Als
Rahmen für diese Spezifikationen wurde von der OMG die Model Driven Architecture
(MDA) verabschiedet. Zu den bekanntesten Spezifikationen der OMG zählen CORBA,
UML, XMI oder MOF. Die direkte Beziehung von erstellten Modellen zu dem
eigentlichen Softwaresystem stellt ein Schlüsselkonzept der MDA dar. Das formale
Modell (meist in UML) eines Softwaresystems tritt weiter in den Vordergrund der
Entwicklung - die eigentliche Programmierung in den Hintergrund [Ge04, S. 12].
2.1 Architektur und konstituierende Grundprinzipien
„OMG’s Model Driven Architecture ® (MDA ®) provides an open, vendor-neutral
approach to the challenge of business and technology change [OMG05].“ MDA
definiert die Trennung der Spezifikation der Funktionalität einer Softwarelösung von
der Realisierung dieser Spezifikation auf der Grundlage einer bestimmten Plattform.
Das Ziel von MDA ist es, die momentane Lücke zwischen Modellen und Quellcode zu
schließen. Der Schwerpunkt bei MDA liegt auf der konzeptionellen Ebene. Es geht in
erster Linie darum, Entwurfsentscheidungen für ein System zu treffen, auf deren
Grundlage dann zwangsläufig der Coderahmen bzw. die Implementierung generiert
wird. Hierzu hat die OMG eine Architektur Vorschlag unterbreitet, der sprachen-,
kunden- und middlewareneutral ist (Abb. 1). Dieser kann grob in vier Bereiche
eingeteilt werden [OMG05b, S. 2].
Der innerste Kreis umfasst die wichtigsten Technologien für die Modellierung von
Softwaresystemen. Diese sind Unified Modeling Language (UML) [OMG03a], Meta
Object Facility (MOF) [OMG03c], Common Warehouse Model (CWM) [OMG01c].
2Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Abb. 1: OMG’s Model Driven Architecture [OMG05]
Diese Technologien stellen bereits existierende OMG-Standards dar. UML wird für die
Modellierung von Struktur und Verhalten von Systemen eingesetzt und bietet dafür
unterschiedliche Diagrammarten wie Klassen-, Aktivitäts- und Sequenzdiagramme. Sie
eignet sich besonders für diese Architektur, da es eine Modellierungssprache ist, die
zum einen ausreichende Sprachmechanismen besitzt, um von plattformspezifischen
Details zu abstrahieren, zum anderen über einen Detailierungsgrad verfügt, der
allgemein benötigte Konzepte zur Spezifikation von Softwaresystemen zur Verfügung
stellt.
Ein weiterer wesentlicher Aspekt ist, dass UML anhand eines MOF kompatiblen
Metamodells eindeutig beschrieben ist, wodurch die Möglichkeit besteht, mittels MOF
Query/View/Transformation (QVT) UML Modelle in andere MOF kompatible
Modellierungssprachen abzubilden, speziell im Kontext der Transformation von
Platform Independent Models (PIM) nach Platform Specific Modells (PSM) [QVT03b].
Für den Bereich Data Warehouse wurde von der OMG ein eigenes Metamodell namens
CWM entwickelt. Dieses unterstützt den gesamten Lebenszyklus vom Entwurf über die
Entwicklung bis zur Wartung der Data Warehouse-Applikationen.
In dem Architekturvorschlag werden die fundamentalen Technologien der OMG
angegeben, die im Laufe der stetigen Fortentwicklung ergänzt worden sind, um das
mögliche Potential der MDA weiter auszuschöpfen. Zu diesen Technologien zählen
Object Constraint Language (OCL) und UML-Profiles. Der Einsatz von OCL
ermöglicht die textuelle Spezifikation von Einschränkungen, die durch grafische
Notationen nur unzureichend dargestellt werden können [OMG05c]. Der Ausdruck
“Constraint“ des Ausdruckes ist ein Überbleibsel aus der Zeit, als OCL in UML
3Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Modellen zur Einschränkung von Wertebereichen genutzt worden ist. Heute ist OCL
eine stark ausgeprägte Suchsprache, die mit der Structured Query Language (SQL)
vergleichbar ist. In Kombination mit UML bietet sie eine qualitativ hochwertige
Möglichkeit, konsistente und genaue PIM Modelle zu generieren [Kl03, S. 56].
UML-Profile sind im Allgemeinen domänen-, fach-, projekt- oder vorgangsspezifische
Erweiterungen des UML-Metamodells. Mit UML-Profilen ist es möglich, spezifische
Sprachkonstrukte, wie z. B. EJB DataClass, WebAction oder BusinessMethod in einem
UML-Diagramm darzustellen und darüber hinaus die Standardisierung und
Interoperabilität von UML sicherzustellen [OMG02]. Der große Nutzen der sich durch
Anwendung bereichspezifischer Profile ergibt, ist die Standardisierung von allgemein
gültigen Problemstellungen. Die OMG schlägt mit diesen eine standardisierte Lösung
vor, die von vielen großen Herstellern mitentwickelt worden ist, und somit eine hohe
Akzeptanz bei ihrem Anwenderkreis hat [Kl03, S. 56].
Die Trennung von der Problemstellung und der plattformspezifischen Implementierung
wird auch im Logo der MDA angedeutet. Rund um die Modellierungstechnologien
werden aktuell genutzte Technologien aufgelistet, die Zielplattformen für die
Modelltransformationen darstellen. Die wichtigsten Softwareplattformen sind Common
Object Request Broker Architecture (CORBA), J2EE und .NET. Für den Modellexport
bzw. für die Modellspeicherung wird XML Metadata Interchange (XMI) als Plattform
verwendet [OMG01b].
Durch XMI können XML Schemata und DTDs aus MOF-basierenden Metamodellen
abgeleitet werden und Instanzen als XML-Dokumente exportiert bzw. gespeichert
werden. Die dargestellten Plattformen spezifizieren keine abgeschlossene Menge von
Zieltechnologien der MDA, sondern zeigen häufig genutzte Technologien mit
Beispielcharakter. Daher liegen ältere Technologien, wie z.B. COBOL oder
FORTRAN, gleichermaßen im Fokus der modellgetriebenen Entwicklung wie neu
entstehende Technologien. Der äußere Ring beinhaltet so genannte unterstützende
Services (Pervasive Services). Diese Services sind allgemeine grundlegende Dienste,
die unabhängig von der zu implementierenden Plattform benötigt werden und durch
Transformationen in beliebige Implementierungen realisiert werden. Für verteilte
Systeme sind vor allem unterstützende Services in den Bereichen Sicherheit,
Transaktionen und Persistenz relevant.
Die Vektoren am Rand geben einen Überblick über die verschiedenen Domänen, die
bereits in Form von OMG IDL standardisiert sind. Bei der OMG liegt ein großes
Augenmerk bei der Standardisierung von Services und günstigen Möglichkeiten in
spezifischen vertikalen Märkten durch die Domain Task Forces (DTFs) des Domain
Technical Committee (DTC) [Mi01, S. 21]. Mit Hilfe dieser werden für bestimmte
4Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Domänen Standards definiert, die Allgemeingültigkeit besitzen und den Anforderungen
des Bereichs genügen.
Nach Soley ist MDA ein Ansatz zur vollständigen Integration und Interoperabilität von
kompletten Unternehmenssystemen inklusive Software, Hardware, Menschen und
Geschäftspraktiken [So00, S. 23]. Der Ansatz stellt einen Rahmen zur Verfügung, um
ein System mit Hilfe von Methoden und Werkzeugen zu verstehen, zu entwerfen,
anzuwenden und weiterzuentwickeln [Ds01, S. 2]. Ein weiterer Grundgedanke der
MDA besteht darin, dass die Definition der Funktionalität des Systems von der
Definition der Implementierung dieser Funktionalität für eine bestimmte Plattform
getrennt wird [Pf04, S. 2].
Das Grundprinzip der MDA ist durch seinen schichtenhaften Aufbau gekennzeichnet
(siehe Abb. 2.2). Ausgangspunkt jeder Entwicklung ist immer die fachliche
Spezifikation, welche anhand eines plattformunabhängigen Modells (PIM) in UML
oder einer ähnlichen Technik spezifiziert wird. Die fachliche Spezifikation hat keinerlei
Bezug auf eine konkrete Technologie. Über verschiedene Transformationen (T1-T3)
wird das Fachkonzept auf die gewünschten Plattformen abgebildet. Dabei richtet sich
die Anzahl der notwendigen Transformationsschritte nach dem zu lösenden Problem.
Bei komplexeren Anwendungen empfiehlt es sich mehrere Transformationsschritte
durchzuführen, um Transparenz zwischen den Modellen zu schaffen. Es existieren
deshalb innerhalb den plattformunabhängigen Modellen (PIM) und
plattformspezifischen Modelle (PSM) mehrere Zwischenstufen.
Abb. 2.2: Grundprinzip der MDA [Bm03, S. 2]
5Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Grundsätzlich entstehen aus den PIM mehrere PSMs, die alle auf dem zuvor
spezifizierten Fachkonzept basieren. Weitere Transformationen (T4-T6) generieren den
spezifischen Code für die jeweilige Plattform.
An dieser Stelle soll darauf hingewiesen werden, dass von der OMG bisher nur das
Konzept der MDA vorgegeben wurde. Spezielle Teilaspekte, wie beispielsweise die
Durchführung einer Transformation, sind im Detail noch nicht festgelegt
worden [OMG03d, S. 3-6]. Dazu bestehen so genannte Requests, die Vorschläge zur
weiteren Implementierung darstellen. Diese werden im folgenden Kapitel näher
erläutert.
Ein weiterer Schlüsselbegriff ist die Abstraktion [OMG05b, S. 4]. Diese versteckt in
Modellen unnötige Details eines Systems, die zum Zeitpunkt des Entwurfs nicht
erforderlich sind. Daher gehört zu jeder Abstraktion eine Realisierung, die die Details
zur Ausführung der Systemfunktionen enthält. Bei komplexen Modellen kann es
mehrere Stufen der Abstraktion (Levels of Abstraction) in Abhängigkeit des
Blickwinkels geben. So hat beispielsweise ein Projektleiter einer Fachabteilung eine
andere Sicht auf ein Buchungssystem als der Systemarchitekt oder der
Applikationsprogrammierer. Der Projektleiter möchte die Anwendungsfälle und
fachlichen Objekte seiner Domäne sehen, die ihm das System zur Verfügung stellt,
während den Anwendungsprogrammierer vor allem die technischen Objekte und
Variablen interessieren. Die MDA gibt vor, dass zwischen den verschiedenen Modellen,
die eine Ebene der Abstraktion abbilden, Verfeinerungen erfolgen. Bei der praktischen
Umsetzung wird zunächst der zu modellierende Blickwinkel festgelegt. Anschließend
werden in einem oder mehreren Transformationsprozessen plattformspezifische Details
hinzugefügt.
Im Folgenden werden die Grundprinzipien der MDA anhand eines Beispiels illustriert,
in Anlehnung an „Rosa's Breakfast Service“ [Kl03]. Zugrunde liegt ein standardisierter
Bestellabwicklungservice, der auf einer Webschnittstelle und auf einem Drei-Schichten-
Modell fußt (Abb. 3). Die Anwendung umfasst zwei Schnittstellen, eine zum Kunden
und die andere für die Angestellten, die die Bestellungen aufnehmen. Dazu erklären sich
die Kunden bereit, dass ihr Name und ihre Anschrift in einer Datenbank gespeichert
werden, damit sie nach einer bestimmten Anzahl an Bestellungen einen Rabatt
bekommen. Als Funktionalität werden Bestellungen und Kunden in der Datenbank
gespeichert und gegebenenfalls angezeigt. Um das Beispiel auf der einen Seite
realistisch erscheinen zu lassen, werden alle drei Schichten exemplarisch mit Inhalt
gefüllt.
6Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Abb. 3: Die drei Schichten der Modelle von „Rosa’s Breakfast Service“
In Abb. 3 wird dies durch die Datensicht (Relationales Datenbankschema),
Funktionssicht (EJB) und die Präsentationssicht (JSP) umgesetzt. Auf der anderen Seite
sind viele Details und notwendige Funktionalitäten weggelassen worden, um ein
besseres Verständnis für den Gesamtzusammenhang zu haben. .
2.1.1 Modelle in der MDA
„In the MDA, a model is a representation of a part of the function, structure and/or
behavior of a system [OMG01, S. 3].“ Für die Erstellung eines Modells wird von der
OMG die Modellierungssprache UML vorgeschlagen. Alternativ können auch
Schnittstellendefinitionen, Programmcode oder normaler Text eingesetzt werden. Ein
wichtiger Aspekt ist die Formalisierung der Modelle, damit sie eindeutig beschrieben
sind und mit Werkzeugen zum Teil automatisch verarbeitet werden können. Damit
Geschäftsmodelle nicht erneut erstellt werden müssen, sind für einige zentrale
Anwendungsbereiche wie beispielsweise „Anwendungen im Finanzwesen“
Kernmodelle definiert, die auf die spezifischen Anwendungssituationen angepasst sind.
MDA bietet dem Anwendungsentwickler die Möglichkeit Modelle zwischen den
verschiedenen Geschäftsbereichen oder zwischen den Modellebenen aufeinander
abzubilden (engl. mapping). Die Abbildung soll möglichst automatisiert ablaufen und
den Entwickler von dieser Arbeit entlasten. Darüber hinaus wird eine klare Trennung
7Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
zwischen Modellierer und Entwickler vollzogen. Ein Geschäftsprozessmodellierer kann
die Modelle auf einer plattformunabhängigen Ebene erstellen und mit Hilfe von
entsprechenden Werkzeugen werden automatisch plattformspezifische Modelle
generiert.
2.1.2 Elementare Modelltypen
In MDA wird hauptsächlich zwischen drei Typen von Modellen unterschieden: den
computerunabhängigen (CIM, Computation Independent Model), plattform-
unabhängigen (PIM, PlatformIndependent Model) und plattformspezifischen (PSM,
Platform Specific Model) Modellen. Darüber hinaus können weitere Modelle eingefügt
werden, um den zu modellierenden Anwendungsbereich weiter zu verfeinern.
Beispielsweise können unabhängig von einander gestaltete Geschäftsbereiche in
unterschiedliche Verfeinerungsstufen modelliert sein und somit einer unterschiedlichen
Bedeutsamkeit gerecht werden.
Computation Independent Model
Das CIM beschreibt ein System in seiner zukünftigen Einsatzumgebung, speziell die
Nutzung des Systems, seine Anforderungen an die Umgebung, sowie den Nutzen des
Systems für die Umgebung. Es liefert prinzipiell keine Beschreibung der internen
Struktur oder des internen Verhaltens des Systems, sondern beschränkt sich sehr stark
auf dessen externe Sicht. CIMs haben die Aufgabe ein System mit seiner Umgebung zu
beschreiben. Zudem sollen sie ein besseres Verständnis der Aufgaben des Systems
ermöglichen. Vorwiegend wird ein CIM auch als Domänenmodell oder
Geschäftsmodell bezeichnet, da es eine gemeinsame Grundstruktur des
Problembereiches definiert. Als Notationsmöglichkeiten können beliebige
Flussdiagramme – besonders geeignet sind UML2-Aktivitätsdiagramme – oder
Klassen- bzw. Anwendungsfalldiagramme eingesetzt werden. Bei dem Einsatz dieser
Modelle ist zu beachten, dass sie nicht genügend Strukturinformation besitzen und
daher für eine praktikable Transformation unbrauchbar sind. Trotzdem bieten sie dem
Modellierer eine solide Grundlage für die weiteren Modelle (PIM, PSM) im MDA
Entwicklungsprozess.
Platform Independent Model
Neben den Transformationen bildet das PIM das Kernstück des MDA Ansatzes. Es
beschreibt die strukturellen und operationalen Aspekte eines Systems unabhängig von
den einzusetzenden Hardware- und Softwareplattformen [OMG03d, S. 3-1]. In Abb. 4
wird das weiter oben skizzierte Beispiel weiter detailliert. Ein Customer kann eine oder
mehrere BreakfastOrders aufgeben. Eine BreakfastOrder muss mindestes ein Breakfast
besitzen, da eine BreakfastOrder ohne Breakfast nicht sinnvoll ist. Jedes bestellte
8Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Breakfast besteht aus weiteren Bestandteilen, die durch die Angabe einer degenerierten
Assoziationsklasse weiter spezifiziert wird. Ein Breakfast kann auch ein
StandardBreakfast sein, das selbst aus weiteren Bestandteilen besteht. Bei der
Darstellung im UML Klassendiagramm werden auf dieser Ebene nur die Attribute und
wichtigsten Methoden der Klassen modelliert. Weitere Details wie beispielsweise get()-
und set()-Methoden werden erst in einem PSM spezifiziert.
BreakfastOrder
deliveryAddress : Address Customer
deliveryDate : Date +orders +customer accountNumber : Integer
deliveryTime : Date
address : Address
discount : Real
1..n 1
OrderDate : Date
createOrder()
calculatePrice()
+order 1
+breakfasts
1..n StandardBreakfast
Breakfast +standard name : String
number : Integer price : Real
n 1 style : Style
n
n
Comestible
+comestible name : String
+comestible
minimalQuantity : Integer
price : Real
n 1..n Part
transportForm : String
Change quantity : Integer
quantity : Integer
Abb. 4: Vereinfachtes PIM von „Rosa’s Breakfast Service“
Im Unterschied zu CIM wird beim PIM auf Computer unterstützende Verarbeitung
zurückgegriffen. Zur Realisierung einer solchen Plattformunabhängigkeit bieten sich
klassische Verfahren, wie die Spezifikation auf Basis einer virtuellen Maschine oder die
Nutzung einer generischen Plattform an. Hierbei können standardisierte Dienste und
Elemente wie „Pervasive Services“, die mit Hilfe von UML-Profiles spezifiziert sind,
ebenfalls Verwendung finden (Abb. 1).
Dadurch begründet, dass in PIMs Business Logik, Domänenwissen als auch
Problemlösungen erfasst werden, dienen sie als ”Know-How Speicher“ für IT-
Entwicklungsunternehmen. Plattformunabhängige Modelle sind aus folgenden Gründen
vorteilhaft: erstens ist es einfacher die Korrektheit zu prüfen, wenn die Semantik des
Modells zwischen den Bereichen getrennt ist und zweitens wird die Implementierung
auf verschiedenen Plattformen einfacher, da die Integration und Interoperabilität über
Systemgrenzen hinweg klarer definiert ist. Ein weiterer Nutzen liegt bei dieser
Problemlösung in der Trennung von plattformspezifischen Details, wodurch für die
9Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Realisierung notwendige Informationen verschiedenen Plattformen zur Verfügung
stehen und bei einem Technologiewechsel ihre Gültigkeit beibehalten [Bo03]. Zur
Darstellung von PIM’s wird von der OMG vorgeschlagen, alle in UML verfügbaren
Modell- und Diagrammformen zu verwenden [OMG03d, S. 1-4].
Platform Specific Model
In einem plattformspezifischen Modell wird ein PIM anhand konkreter Details über die
Hard- und Softwareplattform, die anhand eines PM spezifiziert ist, ergänzt und in ein
PSM überführt [OMG03d, S. 3-8].
BreakfastOrder Customer
Comestible StandardBreakfast
Abb. 5: Erstes grobes EJB Modell
In einer ersten Transformation wird das abstrakte PIM in ein sehr groben EJB PSM
übersetzt (Abb. 5). Mit Hilfe von Stereotypen werden weitere Informationen zum
Modell hinzugefügt, die für die darauf aufbauenden Transformationen von Bedeutung
sind.
standardBreakfast
StandardBreakfast StandardBreakfastKey
standardBreakfastID : int
name : String
price : float standardBreakfast
style : Style StandardBreakfastUpper
1
+standardBrealfast 1
PartKey
standardBreakfastID : int
comestibleID : int
+Part 0..n
comestible
Part
ComestibleKey
quantity : int
1
Abb. 6: PSM von Rosa’s Breakfast Service in Form von EJB
10Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Um die Interaktionshäufigkeit in einer verteilten Umgebung zwischen den
Komponenten zu minimieren, werden in dem Beispiel alle Attribute eines Objektes bei
einem Aufruf übertragen, anstatt jedes Attribut einzeln zu senden (Abb. 6). Das zu
übertragende Objekt ist in der Regel komplexer und beinhaltet eine relativ große Menge
an Daten, jedoch reduziert diese Vorgehensweise die Belastung des Netzwerkes
erheblich. Daher wurde Rosa’s Breakfast Service im ersten Schritt in ein grob
granuliertes EJB Komponenten Modell transformiert (Abb. 5). Nach dem zweiten
Transformationsschritt wird bei dem erstellten Modell zwischen einem EJB Daten
Schema und EJB Daten Klassen unterschieden. Während erstere einer Zusammen-
stellung von Klassen, Attributen und Assoziationen entspricht, ist eine EJB Daten
Klasse ein Teil eines EJB Daten Schemas. Zur Unterscheidung bzw. zur Transformation
der beiden Typen wird die Eigenschaft Komposition verwendet. Beispielsweise ist die
Klasse Breakfast als Bestandteil der BreakfastOrder definiert und daher wird nur das
EJB Data Schema BreakfastOrder erstellt und keine extra Komponente Breakfast. Eine
weitere Detaillierung hat in Form der getter()- und setter()-Methoden stattgefunden.
Diese plattformspezifischen syntaktischen Konventionen werden eingehalten, die sich
in den Diagrammen widerspiegeln (Abb. 6).
Einerseits kann ein PSM alle Details enthalten, die zur Implementierung des Systems
notwendig sind. Andererseits besteht die Möglichkeit, dass ein PSM von einer Reihe
von Implementierungsdetails abstrahiert und Ausgangspunkt für weitere
Transformationen ist (z.B. ein Modell, welches plattformspezifische Details bzgl. der
J2EE Plattform enthält, kann als PIM gegenüber einem Modell betrachtet werden,
welches zusätzlich herstellerspezifische Informationen über einen konkreten J2EE
Application Server spezifiziert, auf welchem das System implementiert werden soll).
Daher sind PIM und PSM immer als relativ zu betrachten [OMG01a, S. 7].
2.1.3 Metamodelle
Mit dem 4-Schichtenmodell der OMG wird eine Modellhierarchie beschrieben, welche
sukzessive die verschiedenen Modellebenen definiert [OMG03d]. Normalerweise
modellieren UML-Anwender vorwiegend auf der Modell-Schicht M1 und erstellen
unter Hinzunahme eines geeigneten UML-Metamodells oder UML-Profils ein
UML-Modell.
Die 4-Schichtenarchitektur der MOF setzt sich aus folgenden Ebenen zusammen:
M0 Objekte: Objekte sind Instanzen des Modells und beschreiben die Ausprägungen
einer bestimmten Domäne bzw. repräsentieren reale Entitäten oder ihre entsprechenden
Abbildungen in der Software (Abb. 7). Dies entspricht dem Beispiel bei einer konkreten
Bestellung (BreakfastOrder: deliveryAdress=“Geiststrasse 23“,
11Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
deliveryDate=“01.12.2005“) eines Kunden (Customer: accountNumber=“012“,
address=“Steinfurterstr. 70“).
M1 Modell: Modelle sind Instanzen von Metamodellen. Zu ihnen gehören die
bekannten UML-Modelle, wie z. B. Klassendiagramme. Auf dieser Ebene befinden sich
Modelle von Softwaresystemen. Die Konzepte auf der M1-Ebene stellen
Kategorisierungen von Instanzen der M0-Ebene dar. Ein Element der M0-Ebene wird
durch ein Element der M1-Ebene repräsentiert. Dies entspricht den Klassen „Customer“
und „BreakfastOrder“ mit den Attributen deliveryAdress, deliveryDate, accountNumber
und address.
M3: Meta-Metamodell
MOF Class
name: String
MOF-Modell
Instance of Instance of Instance of
M2: Metamodell
UML Class Association UML Attribute UML-Metamodell
name: String name: String
Instance of Instance of
Instance of
Instance of
Customer BreakfastOrder M1: UML-Modell
accountNumber: Integer deliveryAddress: Address
address: Address deliveryDate: Date
deliveryTime: Date
discount: Real
orderDate: Date
Instance of Instance of
Instance of
Customer Customer BreakfastOrder
M0: Objekte/
accountNumber: 012 accountNumber: 013 deliveryAddress: „Geiststrasse 23" Ausprägungen
address: „Steinfurterstr.70" address: „Geiststrasse 23" deliveryDate: „01.12.2005"
deliveryTime: „23:23"
discount: „4%“
orderDate: „01.12.2005“
Abb. 7: Gesamtübersicht des 4-Schichtenmodells der OMG
M2 UML-Metamodell: Metamodelle sind Instanzen von Meta-Metamodellen und
definieren die Sprachelemente für Modelle. Auf dieser Ebene befinden sich
beispielsweise die Sprachdefinitionen für UML. Darüber hinaus liegen hier die
sprachspezifischen UML-Profile vor, da sie spezifische Erweiterungen bezüglich der
Metamodelle darstellen. Die Elemente der M1 Ebene sind Instanzen von Elementen der
M2 Ebene. Mit Hilfe von Ebenen werden Elemente und deren Aufgaben voneinander
getrennt, um dadurch M2-Elemente und M1-Elemente kategorisieren können. Auf M1
müssen nur die Konzepte definiert werden, welche für Instanzen der M0-Ebene relevant
sind. Ebene M2 beinhaltet wiederum nur Konzepte (z.B. Klassen und Attribute), die auf
12Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
M1 verwendet werden. Die M2-Ebene wird auch Metamodellebene genannt, da auf
dieser Ebene die Modellierungssprachen der OMG definiert werden.
M3 Meta-Metamodell: Auf der Ebene M3 ist die gemeinsame Basis für alle weiteren
Metamodelle angesiedelt. Die Elemente der M2-Ebene können als Instanzen der
übergeordneten M3-Ebene angesehen werden. Dabei stellen Elemente auf M3
Kategorisierungen von Elementen der Ebene M2 dar. M3 soll allgemein als Grundlage
für die Erstellung von Metamodellen (Modellierungssprachen) dienen. Deshalb wird
diese Ebene auch Metametamodellebene genannt. Die OMG setzt die M3-Ebene mit
MOF gleich und dadurch sind alle OMG-Sprachtechnologien Instanzen von MOF.
Durch die MOF werden auf dieser Schicht die Sprachelemente zur Spezifikation von
Metamodellen spezifiziert (z. B. ModelElement, Namespace, Classifier, etc.).
Theoretisch können weitere Ebenen über M3 bzw. MOF eingeführt werden. Diese
unendliche Problemverschiebung ist mit der Einführung der reflexiven M3-Ebene
vermieden worden. Darüber hinaus erbringt eine weitere Ebene keinen
Abstraktionsgewinn bzw. Nutzen für die praktische Modellierung.
2.2 Transformationen
PIM Abbildungs-
basiert auf techniken
UML
modelliert mit
Abbildung PIM - PIM
1..n PIM
MOF Metamodell 1..n
beschrieben mit
unabhängig von
modelliert mit
basiert auf
1..n
Abbildung Abbildung
modelliert mit PIM - PSM PSM - PIM
andere Sprache
beschrieben mit
PSM Infrastruktur
PSM Abbildungs- hängt ab
techniken
1..n
Abbildung PSM - PSM
Abb. 8: MDA Metamodell-Beschreibung
Neben den eingesetzten Techniken nimmt die Transformation die wichtigste Rolle ein.
Sie ist das „Herzstück“ jeder MDA Umsetzung und bestimmt den Erfolg der
eingesetzten Methoden (Abb. 8). Mit ihnen steht und fällt eine auf Basis der MDA
erstellte Softwareentwicklung. Daher wird intensiv an möglichen
13Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Transformationssprachen geforscht. Nach den Visionen der OMG sollen alle erstellten
Sprachen wieder durch ein geeignetes Metamodell beschrieben werden. Auch hier sollte
es eine gemeinsame Sprache geben, die von der OMG beispielhaft mit der MOF (Meta
Object Facilies) angegeben wird. Auf diese sollen sich alle Sprachen stützen.
2.2.1 Grundlegende Transformationsmöglichkeiten
Grundsätzlich können auf abstrakter Ebene folgende Typen von Transformationen
unterschieden werden (Abb. 8) [QVT03b]:
1. PIM zu PIM: Diese Transformation wird benutzt, wenn die Modelle während des
Entwicklungsprozesses erweitert, gefiltert oder verfeinert werden ohne plattform-
abhängige Informationen zu nutzen. Oft spricht man in diesem Zusammenhang auch
von Modellverfeinerung. Es ist eine Möglichkeit ein Geschäftsmodell aus
verschiedenen Gesichtspunkten aufzuzeichnen.
2. PIM zu PSM: Die Transformation von plattformunabhängigen Modellen an die
speziellen Gegebenheiten einer technologieabhängigen Plattform. Es erleichtert bei
der Entwicklung das Modell auf unterschiedliche Komponenten im System
abzubilden. Komponenten werden dabei in Abhängigkeit der gewählten Plattform
unterschiedlich definiert. Zusätzlich kann durch die PSM-PSM-Transformation ein
bestehendes Modell weiter verfeinert werden.
3. PSM zu PSM: Die PSM-Modelle können auch bei Bedarf weiter verfeinert werden,
um die fehlende Implementierungsdetails zu ergänzen, oder auch um sie in eine
andere Zielplattform zu transformieren.
4. PSM zu PIM: Diese Transformation wird meistens bei bestehenden Systemen
eingesetzt, um aus dem PSM-Modell ein PIM-Modell zu erzeugen. Die
Transformation von PSM ins PIM ermöglicht die Abstraktion von Modellen der
existierenden, plattformspezifischen Implementierungen zu plattformunabhängigen
Modellen. Der Transformationsprozess ist allerdings recht schwierig, da die
Informationen über Metamodelle fehlen. Diese Transformation kann man als
Refactoring bezeichnen.
5. PSM zu Code: Ein Hauptziel der MDA ist die automatische Generierung von Code
aus Modellen. Dabei sollte nicht nur Programmcode erzeugt werden, sondern auch
alle für die erfolgreiche Inbetriebnahme der Software notwendigen Dateien wie
beispielsweise XML-Dateien wie Deployment Descriptors sowie SQL-Skripte.
14Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Aufgrund der Annahme, dass von einem sehr abstrakten und wenig detaillierten Modell
(PIM) in ein konkretes und detaillierteres Modell (PSM) transformiert wird, ist es
mitunter sinnvoll mehrere Transformationsschritte und temporäre Zwischenmodelle
einzuführen. Somit können die Aufgabenbereiche der Transformationen besser getrennt
und die Komplexität der einzelnen Transformationen verringert werden. Trotzdem ist
hierbei zu beachten, dass zusätzlich eingefügte Transformationsstufen zur Erhöhung der
Komplexität des Gesamtzusammenhanges führen.
BreakfastOrder
Breakfast
Customer orderID
customerID (FK) breakfastID
customerID orderID (FK)
deliveryAddress customerID (FK)
accountNumber deliveryDate
address standardBreakfastID (FK)
deliveryTime
discount number
OrderDate
StandardBreakfast
standardBreakfastID
name
style
price
Change Comestible
comestibleID (FK) comestibleID
breakfastID (FK) Part
orderID (FK) name standardBreakfastID (FK)
customerID (FK) minimalQuantity comestibleID (FK)
standardBreakfastID (FK) price
transportform comestible
comstibleID quantity
quantity
Abb. 9: Überblick Transformationen oder MDA Projekt
Ein überschaubares Beispiel einer Transformation ist in Abb. 9 beschrieben. Hier wird
ein UML Diagramm in ein relationales Datenbank Modell überführt. Die meisten der
notwendigen Regeln und Vorschriften sind bereits Gegenstand einiger
wissenschaftlichen Arbeiten gewesen [Bl98]. Änderung in einem PIM kann eine große
Variation in einem relationalen Modell zur Folge haben, wenn beispielsweise aus einem
primitiven Datentyp eine Klasse wird. Diese wird als Fremdschlüssel in der
entsprechenden Tabelle geführt. Für einen einfachen Datentyp wird eine Spalte in der
dazugehörigen Tabelle eingefügt während für den Datentyp Klasse auch eine Spalte
angelegt wird, die jedoch einen Verweis auf eine andere Tabelle enthält. So wird
beispielsweise aus einem UML String ein SQL VARCHAR(40). Auf diese Art und Weise
können automatisch komplette SQL Skripte generiert werden, die unabhängig von einer
konkreten Datenbank wie beispielsweise Oracle oder MySQL genutzt werden können.
Änderungen auf einer Seite einer Transformation können direkt auf die andere Seite
abgebildet werden.
15Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
2.2.2 Modelltansformationsansätze
Modelltransformationen werden in der OMG-Spezifikation sehr allgemein beschrieben
und stehen derzeit in Bearbeitung. In der aktuellen Version wird der Ansatz der
QVT-Partner (Query/Views/Transformations) als Lösung vorgeschlagen [QVT03b]. Es
gibt einige Möglichkeiten, Modelltransformationen durchzuführen, wobei an dieser
Stelle nur die gebräuchlichsten vorgestellt werden. Die beschriebenen Transformations-
ansätze sind nicht klar voneinander abgrenzbar. Es ist durchaus möglich und es wird
gefordert eine Kombination der Ansätze zu verwenden.
Modelltransformation mit Markierungen
Modelltransformationen mit Markierungen bzw. instanzbasierte Abbildungen stellen
eine Möglichkeit dar, Modelle abzubilden. Dazu werden Modellelemente im
Quellmodell auf Modellebene ausgewählt, die auf zielplattformspezifische Konzepte
abgebildet werden. Um individuelle Transformationen durchführen zu können, müssen
die Elemente im Quellmodell mit einer besonderen Syntax markiert
werden [OMG3d, S. 3-8]. Eine Markierung repräsentiert ein plattformspezifisches
Konzept und wird zu den Elementen im Quellmodell annotiert, um die daraus
abgeleiteten Transformationsregeln eindeutig zuordnen zu können. Markierungen
beinhalten somit plattformspezifische Details, die von denen in plattformunabhängigen
Modellen abstrahiert werden. Daher werden Markierungen nicht direkt im Modell
eingetragen, sondern in einer „transparenten“ Schicht über dem plattformunabhängigen
Modell annotiert. Diese Vorgehensweise hat den Vorteil, dass diese Schicht unabhängig
vom Modell existiert und damit eine flexiblere Portierbarkeit beim Tool-Import möglich
ist.
Abb. 10: Modelltransformation mit Markierungen
16Kapitel 2: Theoretische Konzepte und Implementierungsbeispiele der MDA
Metamodelltransformation
Eine Metamodelltransformation bzw. typbasierte Abbildung definiert Abbildungsregeln
für die Metamodellelemente des Quell- und Zielmodells. Eine Regel spezifiziert wie
Metamodellelemente bzw. ein bestimmter Typ des Quellmodells auf einen Typ oder
mehrere Typen des Zielmodells abgebildet werden. Metamodellabbildungen sind eine
spezielle Form von typbasierten Abbildungen, wobei die Typen der Modellelemente
durch das MOF-Modell spezifiziert werden sollten. Somit reicht es aus die
Transformationsregeln auf Metamodellebene zu definieren. Die Modelle auf M1-Ebene
brauchen in die Transformationsdefinition nicht einzufließen, da die Regeln auf die
Typen der Elemente der Modelle angewendet werden [OMG03d, S. 3-9].
Abb. 11: Metamodelltransformation
In der Praxis wird eine Kombination aus typbasierten und instanzbasierten Abbildungen
für den erfolgreichen Einsatz von Transformationen verfolgt. Eine typbasierte
Abbildung stellt einen Typ des Quellmodells in einem Typ oder in mehreren Typen des
Zielmodells dar. Besteht keine Möglichkeit Markierungen an das Quellmodell zu
setzen, werden nur Informationen der Metamodelle des Quell- und Zielmodells für die
Generierung des Zielmodells verwendet. Ein Quellmodell erfordert in vielen Fällen
Markierungen, damit das Zielmodell die geforderten funktionalen und nicht
funktionalen Eigenschaften erfüllt, die jedoch aus dem Quellmodell nicht direkt
abgeleitet werden können. Viele der heute erhältlichen MDA-Entwicklungswerkzeuge
setzen eine Kombination aus typbasierten und instanzbasierten Abbildungen ein [Co05].
Diese Werkzeuge ziehen für typbasierte Abbildungen Stereotypen und UML
Metaklassen und für instanzbasierte Abbildungen Schlüsselwort/Wert-Paare heran.
17Kapitel 3: Kritische Beurteilung der MDA
3 Kritische Beurteilung der MDA
Die Anwendungsmöglichkeiten der MDA sind vielseitig, wobei sich die Idee an die
Entwicklung von großen und komplexen Anwendungen richtet [Kl01]. Besonders
vorteilhaft ist dieser Ansatz für Unternehmen, die aufgrund ihrer Größe oder bisherigen
Tätigkeit auf heterogenen Plattformen gearbeitet haben [Li03, S. 6]. Aufgrund des
hohen Komplexitätsgrades der MDA und der damit verbundenen Notwendigkeit neue
Standards zu definieren ergeben sich, neben den aufgeführten Beispielen, einige
Vorteile [Mi01]:
- Einfachere Validierung eines von plattformspezifischen Details befreiten Modells
- Konformere Implementierungen eines einheitlich definierten Modells auf
heterogenen Plattformen
- Gesteigerte Entwicklungsgeschwindigkeit bei der Softwareherstellung durch
Wiederverwendung von Modellen bzw. Komponenten
- Bessere Handhabbarkeit und Kontrolle der Software, infolge des höheren
Abstraktionslevels
- Garantie für Interoperabilität und Portabilität von Softwarekomponenten
- Schließung der momentanen Lücke zwischen Modellen und Quellcode auf der
konzeptionellen Ebene
- Weiterreichende Unterstützung des Softwareentwicklers, indem Änderungen auf
einem hohen Abstraktionslevel auf alle anderen Level auswirken
- Weitgehend Automatisierung der Codegenerierung, Dokumentierung und Wartung
Neben Vorteilen, die sich aus der Architektur ergeben, liegen der MDA Nachteile
zugrunde:
- Trotz vollständiger Beschreibung des theoretischen Konzeptes fehlen praktische
Mittel zur Umsetzung
- Technische Beschränkung des Modellierers in seinen Möglichkeiten auf bestehende
Komponenten
- Unvollständige Beschreibung von UML2.0, welche die Grundlage für UML-Profile
darstellt
- Unzureichende MDA-Entwicklungswerkzeuge, die einen spezifischen Bereich der
UML bzw. MDA unterstützen
18Kapitel 3: Kritische Beurteilung der MDA
Neben den oben genannten Vor- und Nachteilen ergeben sich darüber hinaus eine Reihe
organisatorischer Fragen bezüglich der MDA. Ein erster Punkt ist die Daten- und
Anwendungsmigration. Das Problem besteht in der Existenz bereits vorhandenen
großen Mengen an Daten und Anwendungen, die in das neue System übernommen
werden müssen. Bestehende UML-Diagramme müssen um entsprechende Stereotypen
ergänzt werden oder an den neuen UML2.0 Standard angepasst werden. Ein weiterer
Punkt ist die Softwarewartung, bei der die Erzeugung von Releases, Patches oder
Updates ein oftmals wichtiger Bestandteil der laufenden Wartung von Anwendungen
ist. Bei dem MDA-Prozess ist eine komplette Neuinstallation bzw. ein komplett neues
Deployment notwendig, welches auf die fehlende Versionierungsmöglichkeit
zurückzuführen ist. Darüber hinaus stellt sich die Kostenfrage bei der Entwicklung mit
MDA, ab wann ein Projekt, auf der Grundlage von MDA, zu entwickeln ist. Dieses
wird auch in der Fachsprache als Return-on-Investment (ROI) bezeichnet. Es stellt sich
die Frage, ob das einzusetzende Framework gekauft oder selbst entwickelt werden
muss.
19Kapitel 4: Fazit und Ausblick
4 Fazit und Ausblick
Die Entwicklung heutiger betrieblicher Anwendungssysteme ist durch eine zunehmende
Komplexität und Heterogenität der technischen Plattformen und die Anforderung der
Integration voneinander unabhängiger Softwarekomponenten gekennzeichnet. Mit der
gleichzeitig steigenden Bedeutung der Informationstechnologie für die strategische
Entwicklung eines Unternehmens, erhöhen die Anforderungen an die Qualität und
Langlebigkeit von Anwendungssystemen unter der Berücksichtigung der bei der
Entwicklung auftretenden Kosten den Druck, wiederverwendbare
Softwarekomponenten zu generieren.
Das von der Object Management Group (OMG) entwickelte Konzept der Model Driven
Architecture (MDA) ist ein viel versprechender Ansatz, einen einheitlichen Standard
zur Anwendung modellzentrierter Softwareentwicklung zu etablieren und durch
Formalisierung der abzubildenden Geschäftslogik eine Automatisierung der
Softwareentwicklung zu ermöglichen. Durch die Verwendung modellzentrierter
Softwareentwicklung kann die Produktivität der Softwareerstellung durch kürzere
Entwicklungszeiten erhöht werden. Gleichzeitig soll durch Trennung unterschiedlicher
konzeptioneller Modellebenen eine Entkopplung des Softwareentwurfs von der
zugrunde liegenden Technologieplattform erfolgen. Hierdurch werden die
Möglichkeiten wie Portabilität und Wiederverwendbarkeit von Software begünstigt.
In der vorliegenden Arbeit werden die theoretischen Basiskonzepte und Ziele der Model
Driven Architecture (MDA) erläutert. Der Modellzentrierung wird durch die
konsequente Darstellung eines einheitlichen Beispiels im Rahmen der MDA Rechnung
getragen. An den dargestellten Beispielen wird deutlich, welchen neuen
Herausforderungen ein Modellierer zu bewältigen hat. Im Mittelpunkt steht nicht mehr
allein die Codierung des zunächst erstellten Fachkonzepts bzw.
Geschäftsprozessmodells, sondern die saubere Modellierung der fachlichen Inhalte, an
die sich die Transformation der Modelle anschließt. Konzeptionell liegen Lösungen für
die Transformationssprachen vor, doch unterstützen heutige Werkzeughersteller nur
einen kleinen Teil des gesamten Potentials. Trotz der innovativen Visionen der MDA
gibt es immer noch keine formalen Kriterien, die einen Einsatz der MDA rechtfertigen
bzw. bestimmen. Es bedarf viel Erfahrung und Know-How der Verantwortlichen einen
durch MDA unterstütztes Projekt zum Erfolg zu führen.
20Kapitel 4: Fazit und Ausblick
Literaturverzeichnis
[bm03] b+m: Grundlegende Konzepte und Einordnung der Model Driven Architecture,
http://www.architectureware.de/download/MDA_JavaMagazin_09_03.pdf,
Abrufdatum 02-11-2005, 2003.
[Bl98] M. Blaha: Object-Oriented Modeling and Design for Database Applications,
Prentice Hall, 1998.
[Ds01] D. Dsouza: Model-Driven Architecture and Integration – Opportunities and
Challenges Version 1.1, ftp://ftp.omg.org/pub/docs/ab/01-03-02.pdf, Abrufdatum
02-11-2005, 2001.
[Ge04] R. Geiger: Evaluierung von Produktivitätspotenzialen im Software-
Entwicklungsprozess für Web-Anwendungen,
http://www.stz-ida.de/download/forschung/da/da_geiger.pdf, Abrufdatum 03-11-
2005, 2004.
[Kl03] A. Kleppe, J. Warmer, W. Blast: MDA Explained - The Model Driven
Architecture: Practice and Promise, Addison-Wesley, 2003.
[Ko01] A. Korthaus: Komponentenbasierte Entwicklung computergestützter
betrieblicher Informationssysteme, 2001.
[Li03] Y. Liu: Metamodellierung und MDR. Seminar: Grundlagen der modellbasierten
Softwareentwicklung,
http://www.uni-pade-born.de/cs/ag-engels/ag_dt/People/Heckel/DO/GmbS/pdf/Ya
nAusarbeitung.pdf, Abrufdatum 04-11-2005, 2003.
[Mi01] J. Miller, J. Mukerji: Model Driven Architecture (MDA),
http://www.omg.org/mda/mda_files/MDA_Briefing_Mukerji.pdf. Abrufdatum 02-
11-2005, 2001.
[OMG01] OMG: Architecture Board MDA Drafting Team: Model Driven Architecture – A
Technical Perspective, http://www.omg.org/cgi-bin/apps/doc?ormsc/01-07-01.pdf.
Abrufdatum 04-11-2005, 2001.
[OMG01] OMG: Model Driven Architecture (MDA), http://www.omg.org/mda/, 2001.
[OMG01a] OMG: Developing in OMG’s Model-Driven Architecture,
ftp://ftp.omg.org/pub/docs/omg/01-12-01.pdf, Abrufdatum 17-11-2005, 2001.
[OMG01b] OMG: MOF 2.0/XMI Mapping Specification, v2.1,
http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf, Abrufdatum
16-11-2005, 2001.
21Kapitel 4: Fazit und Ausblick
[OMG01c] OMG: CWM Specification, http://www.omg.org/cgi-bin/doc?ad/2001-02-01.
Abrufdatum 17-11-2005, 2001.
[OMG02] OMG: UML Profile for CORBA Specification,
http://www.omg.org/cgi-bin/apps/doc?formal/02-04-01.pdf,
Abrufdatum 17-11-2005, 2002.
[OMG02a] OMG: Meta Object Facility (MOF) Specification, http://www.omg.org/cgi-
bin/doc?formal/2002-04-03, 2002.
[OMG03a] OMG: UML, http://www.uml.org/, Abrufdatum 07-11-2005, 2003.
[OMG03b] OMG: MDA Spezifikation, http://www.omg.org/mda/Profiles, Abrufdatum
07-11-2005, 2003.
[OMG03c] OMG: MOF Spezifikation,
http://www.omg.org/cgi-bin/apps/doc?formal/02-04-03.pdf,
Abrufdatum 17-11-2005, 2003.
[OMG03d] OMG: MDA MDA Guide Version 1.0.1,
http://www.omg.org/cgi-bin/apps/doc?omg/03-06-01.pdf, Abrufdatum
17-11-2005, 2003.
[OMG05] OMG: MDA, http://www.omg.org/mda/, 2005.
[OMG05a] OMG: MDA Spezifikation UML Profiles,
http://www.omg.org/mda/specs.htm#Profiles, Abrufdatum 20-10-2005, 2005.
[OMG05b] OMG: Model Driven Architecture, ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf
Abrufdatum 02-11-2005, 2005.
[OMG05c] OMG: OCL 2.0 Specification. 2005.
http://www.omg.org/cgi-bin/apps/doc?ptc/05-06-06.pdf. Abrufdatum 2005-16-11.
[OMG05d] OMG: About The Object Management Group,
http://www.omg.org/gettingstarted/gettingstartedindex.htm, 2005.
[Co05] Compureware: OptimalJ, http://www.compuware.de/products/optimalj, 2005.
[Pf04] M. Pflug, D. Unger: MDA - Model Driven Architecture Einführung und Beispiel
an einer praktischen Anwendung, http://www.uni-
paderborn.de/cs/ag-engels/ag_dt/People/Heckel/DO/GmbS/pdf/MDAUnger-
Pflug.pdf, Abrufdatum 10-11-2005, 2004.
[QVT03a] QVT Partners: QVT Initial Submission, http://qvtp.org, 2003.
22Kapitel 4: Fazit und Ausblick
[QVT03b] QVT Partners: Revised submission for MOF 2.0 Query / Views / Transformations
RFP, http://qvtp.org/downloads/1.1/qvtpartners1.1.pdf, Abrufdatum 10-11-2005,
2003.
[Se03a] S. Sendall, G. Perrouin, N. Guelfi, O. Biberstein: Supporting Model-to-Model
Transformations: The VMT Approach. In: IC TECHNICAL REPORT, 51,
http://ic2.epfl.ch/publications/documents/IC_TECH_REPORT_200351.pdf,
Abrufdatum 03-11-2005, 2003.
[Se03b] S. Sendall, W. Kozaczynski,: Model Transformation – the Heart and Soul of
Model-Driven Software Development. In: IC TECHNICAL REPORT, 52,
http://ic2.epfl.ch/publications/documents/IC_TECH_REPORT_200352.pdf,
Abrufdatum 03-11-2005, 2003.
[So00] Soley R. : Model Driven Architecture,
http://qvtp.org/downloads/talks/orlando20030302.pdf, Abrufdatum 10-11-2005,
2000.
23Sie können auch lesen
