Model Driven Architecture

Inhaltsverzeichnis

Abkürzungsverzeichnis

1 „How Systems Will Be Built“

2 Entwicklungsgeschichte
2.1 Die OMG
2.2 Die Vision

3 MDA Framework
3.1 Modelle
3.1.1 Metamodellierung
3.1.2 Modellkategorien in der MDA
3.1.3 Computation Independent Model (CIM) .
3.1.4 Platform Independent Model (PIM) . .
3.1.5 Platform Specific Model (PSM)
3.2 Transformationen

4 Entwicklungsstand
4.1 Unified Modeling Language (UML)
4.2 Object Constraint Language (OCL)
4.3 Meta Object Facility (MOF)
4.4 XML Metadata Interchange (XMI)
4.5 Common Warehouse MetaModel (CWM)
4.6 Common Object Request Broker Architecture (COR- BA)

5 Softwareentwicklung mit MDA
5.1 Klassische Softwareentwicklung
5.2 MDA Development Lifecycle
5.3 Vergleich
5.3.1 Produktivität
5.3.2 Portabilität
5.3.3 Interoperabilität
5.3.4 Wartung und Dokumentation
5.4 Entwicklungswerkzeuge
5.5 MDA und Komponentenmodelle
5.6 Wirtschaftliche Bedeutung
5.6.1 Produktivitätsanalyse der Middleware Com- pany
5.6.2 Gothaer Versicherungen - Entwicklung einer Angebotssoftware
5.6.3 Deutsche Bauspar AG - System zum Dar- lehensmanagement
5.6.4 Zusammenfassung

6 „The Architecture of Choice for a Changing World“

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 „How Systems Will Be Built“

So präsentiert die Object Management Group (OMG) eine ihrer neuesten Entwicklungen im World Wide Web.

Seit Beginn des Informationszeitalters versucht die Softwarein- dustrie, Verfahren, Werkzeuge und Methoden zu entwerfen, um die Arbeit mit Informationstechnologie (IT) einfacher und vor al- lem effizienter zu gestalten. Von der Einführung der ersten Hoch- sprachen über den Erfolgszug der objektorientierten Sprachen und Integrierten Entwicklungsumgebungen bis zu Modellierungs- techniken wie der Unified Modeling Language (UML) beherrscht die fortschreitende Abstrahierung vom reinen Maschinencode im- mer stärker den Softwareentwicklungsprozess.

Eine fast logische Folge aus dieser Entwicklung ist der sich ab- zeichnende Standard der Model Driven Architecture (MDA) der OMG. Grundgedanke dieses Konzepts ist es, konstruktive Mo- delle in das Zentrum des Softwareentwicklungsprozesses zu stel- len. Diese Modelle dienen nicht mehr nur der abstrakten Beschreibung des zu entwickelnden Systems, sondern zur automatisierten Erzeugung von weiteren Modellen des selben Systems sowie der Generierung des Quellcodes.

Wesentlich für die MDA ist die Trennung der Spezifikation der Systemfunktionalität von der verwendeten Plattform. Die MDA ermöglicht es außerdem, Plattformen zu beschreiben, eine be- stimmte Plattform für das System auszuwählen und den System- entwurf für die gewählte Plattform zu transformieren:

„Ziel (...) ist es, Plattform-unabhängige Modelle zu entwickeln, auf deren Basis für unterschiedliche Platt- formen Plattform-spezifische Modelle erstellt wer- den können. Diese Plattform-spezifischen Modelle können für konkrete Systemplattformen - z.B. für einen spezifischen J2EE-Applikationsserver oder einen CORBA-Server - genutzt werden, indem man aus- führbare Anwendungen generiert.“ (Andresen (2003), S. 77)

Diese Arbeit soll einen Überblick über die Entwicklungsgeschich- te, den Softwareentwicklungsprozesses mit der MDA, über die grundlegenden Technologien sowie den aktuellen Entwicklungs- stand geben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Das MDA-Prinzip

2 Entwicklungsgeschichte

2.1 Die OMG

Die OMG wurde 1989 von damals elf Firmen, darunter IBM, Ap- ple und Sun, gegründet. Ziel dieser Organisation von heute mehr als 800 Mitgliedern ist es, Standards für die herstellerunabhängi- ge und systemübergreifende objektorientierte Programmierung zu entwickeln. Eine der bekanntesten Früchte dieser Arbeit ist die Common Object Request Broker Architecture (CORBA), die das Erstellen von verteilten Anwendungen ermöglicht.

Mit der Adaption der UML als Modellierungssprache und der Meta-Object Facility (MOF) als Metamodellierungsframework 1997 erweiterte die OMG ihr Augenmerk auf die Modellierung von Systemen. Im Jahr 2000 fasste sie weit verbreitete Indus- triestandards für die Visualisierung, Speicherung und den Aus- tausch von Softwaredesigns und -modellen zur MDA zusammen und löste hierdurch die seit Anfang der neunziger Jahre bestehen- de Object Management Architecture (OMA) ab, die bis dahin die

Grundlage aller Standardisierungsaktivitäten der OMG war.¹ Die Ursache hierfür war die Erkenntnis, dass nicht mehr nur die Inte- roperabilität von Komponenten eines Softwaresystems, sondern auch die Interoperabilität der Informationen ü ber diese Kompo- nenten sichergestellt sein muss, um ein effektiveres Arbeiten der Entwicklerteams zu ermöglichen (vgl. Kleppe u. a. (2003), S. XI; Born u.a. (2004), S. 275).

Während üblicherweise Initiativen dieser Art Jahre zur Konsens- findung benötigen hat die MDA bereits jetzt einen starken Rück- halt in der Industrie. Selbst sonst harte Rivalen wie Microsoft, IBM und Sun beteiligen sich stark an der Entwicklung (vgl. Fran- kel (2003), S. Xxi), erste Projekte unter Nutzung der MDA sind bereits verwirklicht.

2.2 Die Vision

„The myth of the standalone application, never needing repair, never needing integration, with data models inviolate and secret, died a long and painful death through the end of the Twentieth Century.“ (Miller/Mukerji (2003), S. 1-1)

Nahezu keine Software wird heute mehr nur einmal erstellt und dann eine vorbestimmte Dauer in einem Unternehmen einge- setzt. Kostenzwänge, Änderungen im Geschäftsablauf und die Einführung neuer Technologien führen dazu, dass jede Anwen- dung immer wieder gewartet, integriert, aktualisiert und überar- beitet werden muss. Trotz allem wird dieser Beobachtung bei der Softwareentwicklung kaum Rechnung getragen. Anwendungen werden heute nach seit langem eingebrannten Mustern geschrie- ben, die zwar meistens Diagramme und textuelle Beschreibun- gen des Systems in den ersten Phasen des Prozesses beinhal- ten, sich aber spätestens bei der Implementation hauptsächlich auf den Code konzentrieren und die Dokumentation vernachläs- sigen.

Die Vision der OMG besteht deshalb darin, das Hauptaugenmerk im Softwareentwicklungsprozess nicht mehr auf die konkrete, zielplattformspezifische Implementation zu richten, sondern auf die Modellierung. Ein einmal aus verschiedenen Sichten seman- tisch exakt formuliertes Modell eines Systems soll dann ohne Eingriffe die Grundlage für eine automatisch generierte Anwen- dung auf jeder gewünschten Plattform bilden - bestehenden und jeder zukünftigen (vgl. Miller//Mukerji (2003), S. 1-1ff.). Die Idealvorstellung besteht in der nahezu vollständigen Generierung der fertigen Applikation aus Modellen und bereits zur Verfügung stehenden Komponenten.

3 MDA Framework

Die beiden wichtigsten Konzepte der MDA stellen Modelle und Transformationen dar.

3.1 Modelle

Ein Modell zeichnet sich allgemein und verständlich ausgedrückt durch folgende drei Punkte aus:

- Ein Modell ist immer eine Abstraktion von etwas, das bereits existiert oder geplant wird.
- Ein Modell unterscheidet sich von dem, was es abbildet, z.B. im Detaillierungsgrad oder der Größe.
- Ein Modell kann als Vorlage für etwas genutzt werden, das real existiert oder existieren soll (vgl. Kleppe u. a. (2003), S. 15f.).

Für die Modellierung mit der MDA heisst das:

- Ein Modell ist immer eine Abstraktion eines bestehenden oder zu planenden Systems.
- Ein Modell unterscheidet sich von dem zu modellierenden System hauptsächlich im Abstraktionsgrad.
- Ein Modell kann als Vorlage für ein weiteres Modell dienen, von welchem es wiederum abstrahiert.

3.1.1 Metamodellierung

Um Modelle im Umfeld der MDA genauer zu verstehen lohnt ein Blick auf die Metaebene.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: 4-Schichten-Metamodellarchitektur (vgl. Kleppe u. a. (2003), S. 89)

Die OMG nutzt zur Metamodellierung die 4-Schichten-Metamo- dellarchitektur. Unterste Schicht (M3) ist das Meta-Metamodell. Es stellt die eigentliche Infrastruktur der Metamodellarchitektur dar.¹ Hier wird die Sprache zur Spezifikation von Metamodellen definiert. Die MOF ist ein Standard für Meta-Metamodelle.

Ein Metamodell (M2) beschreibt als Instanz eines Meta-Meta- modells eine Sprache zur Beschreibung von Modellen. Die UML z.B. ist somit ein Metamodell.

Die dritte Schicht (M1) ist die des eigentlichen Modells, einer Instanz eines Metamodells. Ein Beispiel hierfür wäre das Modell eines Kunden in Form eines UML-Klassendiagramms mit der Klasse Kunde.

Die vierte Schicht (M0) bilden Objekte als Instanzen eines Mo- dells (vgl. OMG (2003b), S. 16 f.; Kleppe u. a. (2003), S. 85 ff.). Ein Objekt für das vorhergehende Beispiel wäre die konkrete In- stanz der Klasse Kunde HerrMayer oder HerrMueller.

3.1.2 Modellkategorien in der MDA

Die Bezeichnung Model Driven Architecture lässt bereits erken- nen, dass Modelle den Kern der MDA bilden. Ein Modell ist im Kontext der MDA als die Beschreibung eines Systems oder

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Einordnung von Modellen (vgl. Kleppe u. a. (2003), S. 20)

Teilsystems, die in einer wohldefinierten Sprache verfasst wird, zu verstehen. Als wohldefinierte Sprache wird eine Sprache be- zeichnet, die über eine definierte Form (Syntax) und Bedeutung (Semantik) verfügt und geeignet ist, automatisiert von Compu- tern verarbeitet zu werden (vgl. Kleppe u. a. (2003), S. 16).

Obwohl die UML als quasi „hauseigene“ Modellierungssprache der OMG am geeignetsten erscheint ist MDA ganz im Sinne der Unabhängigkeit von Techniken und Zukunftsentwicklungen hier nicht festgelegt. Auch für bspw. Petri-Netze oder Entity- Relationship (ER) Diagramme ist der Standard offen (vgl. Fett- ke/Loos (2003), S. 556). Wichtig ist jedoch immer die Wohlde- finiertheit der Sprache, denn ohne genau bekannte Syntax und Semantik kann das Hauptziel, nämlich die automatische Code- generierung, nicht oder zumindest nicht deterministisch erreicht werden.

Modelle beschreiben ein System in der MDA zudem aus einem bestimmten Blickwinkel, den sogenannten Viewpoints (vgl. Miller/Mukerji (2003), S. 2-5).

Als wichtigste Modellkategorien aus Entwicklersicht werden das Computation Independent Model (CIM), das Platform Indepen- dent Model (PIM) und das Platform Specific Model (PSM) un- terschieden.

3.1.3 Computation Independent Model (CIM)

Ein CIM beschreibt das darzustellende System vom Computati- on Independent Viewpoint aus. Dieser konzentriert sich auf die Einsatzumgebung des Systems und seine Anforderungen.

[...]

¹ OMA verfügt als Herzstück über den Object Request Broker (ORB) und beinhaltet somit als wesentlichen Kern die Nutzung von verteilten Objekten (vgl. Soley/Stone (1995), S. 17-24).

¹ Es gibt also kein Meta-Meta-Metamodell.