DANKSAGUNG

Ich danke Andreas Springer und Dorothea Klitsche für ihre Hilfe beim Korrekturlesen

der Arbeit.

Natürlich danke ich auch Professor Walter Kriha und meinem Betreuer aus der Fir-

ma, Frank Gröhler, für die Betreuung und Unterstützung während der Diplomarbeit.

Kurzfassung Diese Diplomarbeit befasst sich mit der Model Driven Architecture (MDA) und deren Anwendung auf Basis von Open Source.

Für ein Unternehmen ist es immer wichtig zu wissen, wie der aktuelle Stand der Technik ist und ob diese Technik produktiv eingesetzt werden kann, um sich dadurch Vorteile am Markt zu verschaffen.

Es werden zunächst einige Grundlagen von Open Source und MDA erörtert. Danach wird mittels einer Evaluierung von Open Source Modellierungs- und Generierungswerkzeugen ein Überblick über die am Markt verfügbaren Werkzeuge gegeben. Anschließend wird die prototypenhafte Umsetzung eines Geschäftsvorfalles einer Versicherung beschrieben, um den Stand der Technik zu demonstrieren. In der Schlussbetrachtung folgt ein Fazit über den Verlauf und die Resultate der Diplomarbeit. Zum Schluss wird ein Ausblick für die Model Driven Architecture gegeben.

Abstract

This diploma thesis is concerned with the Model Driven Architecture (MDA) and their appliance to basis of Open Source.

For an enterprise it is always important to know, how the current state of the art is and whether this technology can be used productively, in order to provide thereby advantages at the market.

First some bases of Open Source and MDA are discussed. Afterwards, by an evaluation of Open Source modelling and generation tools, an overview of the market of the supporting tools is given. Subsequently, the prototypeful implementation of a business use case of an insurance company is described, in order to demonstrate the state of the art. In the final consideration a result follows over the process and the results of the diploma thesis. In the end a view in the future for the Model Driven Architecture is given.

Inhaltsverzeichnis 1

  Inhaltsverzeichnis  

  Seite  

  INHALTSVERZEICHNIS  1

1  EINLEITUNG  4

1.1  Problemstellung  4

1.2  Zielsetzung  4

1.3  Abgrenzung  5

1.4  Vorgehen  5

1.5  Aufbau der Diplomarbeit  6

2  OPEN SOURCE  7

2.1  Was ist Open Source  7

2.2  Was macht Open Source so interessant  7

2.3  Open Source Lizenzen  8

2.3.1  GNU General Public License (GPL)  8

2.3.2  GNU Lesser General Public License (LGPL)  9

2.3.3  Eclipse Public License (EPL)  9

2.3.4  Berkeley Software Distribution (BSD) Lizenz  9

3  EINFÜHRUNG IN DIE MDA  10

3.1  Allgemeines  10

3.2  Ziele der MDA  12

3.3  Zusammenhang von MDA mit MOF UML XMI und QVT  13

  Diplomarbeit MDA auf Basis Open Source Andreas Keefer  

Inhaltsverzeichnis 2

3.4  Konzepte  14

3.4.1  Modelle  15

3.4.2  Plattform  15

3.4.3  UML-Profile  15

3.5  Abgrenzung  15

4  EVALUIERUNG DER MDA WERKZEUGE  17

4.1  Übersicht  17

4.1.1  Abgrenzung  17

4.1.2  Allgemeines Vorgehen für die Evaluierung  18

4.2  Evaluierung von Modellierungswerkzeugen  20

4.2.1  Einschränkungen  20

4.2.2  Anforderungen  21

4.2.3  Vorgehen  22

4.2.4  Übersicht  26

4.2.5  Werkzeuge im Detail  28

4.2.6  Fazit Modellierungswerkzeuge  38

4.3  Evaluierung von Generierungswerkzeugen  38

4.3.1  Einschränkungen  38

4.3.2  Anforderungen  39

4.3.3  Vorgehen  41

4.3.4  Übersicht  41

4.3.5  Werkzeuge im Detail  43

4.3.6  Fazit Generierungswerkzeuge  64

4.4  Fazit  65

4.4.1  Modellierungswerkzeuge  65

4.4.2  Generierungswerkzeuge  65

4.4.3  Empfehlung  65

5  PROTOTYP  67

5.1  Analyse  67

5.1.1  Geschäftsvorfall  67

5.2  Architektur  70

5.2.1  Verwendete Technologien  70

5.2.2  Verwendete AndroMDA Cartridges  70

5.2.3  AndroMDAs typische J2EE Architektur  75

  Diplomarbeit MDA auf Basis Open Source Andreas Keefer  

Inhaltsverzeichnis 3

5.3  Design  76

5.3.1  Domänenmodell  76

5.3.2  Value Objects  77

5.3.3  Services  78

5.3.4  Benutzer Frontend  78

5.4  Umsetzung  81

5.4.1  Persistenz  81

5.4.2  Fachliche Logik  82

5.4.3  Arbeitsabläufe (Workflow)  83

5.4.4  Middleware (Kommunikation)  83

5.4.5  Benutzer Frontend  84

5.4.6  Erweiterung von AndroMDA  87

5.5  Fazit  92

6  ZUSAMMENFASSUNG  94

6.1  Ergebnisbewertung  94

6.1.1  Probleme  94

6.1.2  MDA im Unternehmen  95

6.2  Stand der Technik und Ausblick  95

  ABBILDUNGSVERZEICHNIS  98

  ABKÜRZUNGSVERZEICHNIS  100

TABELLENVERZEICHNIS   102

  LISTINGVERZEICHNIS  104

  LITERATURVERZEICHNIS  105

  Diplomarbeit MDA auf Basis Open Source Andreas Keefer  

Kapitel 2 - Open Source 4

1 Einleitung

Da heutige Software immer komplexer und der Konkurrenzdruck für die Gewinnung von Projekten immer schwieriger wird, muss ein Unternehmen versuchen, sich vom Markt abzuheben. Die Model Driven Architecture (MDA) bietet hierfür verschiedene Ansatzpunkte, welche in dieser Arbeit betrachtet werden.

1.1 Problemstellung

Die Technik entwickelt sich rasant weiter, deshalb ist es für ein Unternehmen wichtig zu wissen, wie der aktuelle Stand der Technik ist und ob diese Technik produktiv eingesetzt werden kann. Deshalb soll in diesem Fall durch eine Evaluierung von Open-Source-Werkzeugen der aktuelle Stand der unterstützenden MDA-Werkzeuge aufgezeigt werden.

Die Beschränkung auf Open Source, zum einen aus wirtschaftlichen Gründen und zum anderen um die Arbeit in einem gewissen Rahmen zu halten. Ein Prototyp soll dann die tatsächliche Machbarkeit bzw. den aktuellen Stand der Technik demonstrieren.

1.2 Zielsetzung

Die Diplomarbeit soll eine Übersicht über die bestehenden Open-Source-Modellierungs- und Generierungswerkzeuge geben und dadurch den aktuellen Stand der MDA-Werkzeuge aufzeigen.

Anhand eines Prototypen sollen die verfügbaren Möglichkeiten und der Stand der Technik durch die Auswahl eines oder mehrerer evaluierter Werkzeuge aufgezeigt

Diplomarbeit - MDA auf Basis Open Source

Kapitel 2 - Open Source 5

werden. Es soll ebenfalls herausgearbeitet werden, wie weit die Modellierung einer Anwendung einen Sinn ergibt und ab wann der traditionelle Weg über manuelles Codieren vorteilhafter ist.

1.3 Abgrenzung

In der Arbeit werden ausschließlich Open-Source-Werkzeuge betrachtet und evaluiert. Ebenso habe ich mich auf den MDA-Aspekt konzentriert und versucht, nicht in die allgemeine modellgetriebene Entwicklung abzurutschen. Einige Übergriffe waren allerdings unvermeidlich, um Parallelen oder Unterschiede anzudeuten.

1.4 Vorgehen

Das Vorgehen während der Diplomarbeit kann grob in fünf Phasen eingeteilt werden: Die Einarbeitung in MDA und UML

Die Evaluierung der Modellierungswerkzeuge

Die Evaluierung der Generierungswerkzeuge

Die Entwicklung des Prototypen

Die Finalisierung der Diplomarbeit

Mein Vorgehen während der praktischen Aufgaben war meistens so, dass ich parallel eine grobe Fassung in die Diplomarbeit dokumentiert habe. Dies hat die großen Vorteile, dass die Diplomarbeit parallel zu den praktischen Teilen entsteht, frühzeitig Probleme oder Engpässe erkannt werden können, am Ende weniger Hektik herrscht und Nichts vergessen wird.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 2 - Open Source 6

1.5 Aufbau der Diplomarbeit

Die Arbeit ist grob in fünf Teile aufgeteilt:

Einführung: Das erste Kapitel gibt eine Einführung in die Thematik und be-

schreibt die Fragestellung und Zielsetzung der Arbeit. Theorieteil: Die Kapitel 2 und 3 behandeln zum einen kurz das Thema Open

Source und zum anderen den Bereich MDA. Evaluierung: Das 4. Kapitel beinhaltet die Evaluierung der MDA-Werkzeuge. Es

werden zum einen Modellierungswerkzeuge und zum anderen Generierungswerkzeuge evaluiert.

Prototyp: Das 5. Kapitel beschäftigt sich mit dem Prototypen, von der Analyse

über das Design bis zur Implementierung der Anwendung. Zusammenfassung: Das Letzte, 6. Kapitel ist eine Zusammenfassung der Arbeit

mit den Problemen und Erkenntnissen, die sich durch die Diplomarbeit ergeben haben.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 3 - Einführung in die MDA 7

2 Open Source

In diesem Kapitel wird der Begriff „Open Source“ näher erläutert und es wird näher darauf eingegangen, warum dieses Thema momentan so interessant ist. Es werden die wichtigsten Open Source Lizenzen vorgestellt, um einen Überblick zu erhalten und zu erkennen welche Besonderheiten sich aus den einzelnen Lizenzen ergeben.

2.1 Was ist Open Source?

Der Ausdruck „Open Source“ wird meist mit Computer-Software assoziiert und meint im Sinne der Open-Source-Definition, dass es jedem ermöglicht wird Einblick in den Quelltext eines Programms zu haben, sowie die Erlaubnis zu haben diesen Quellcode auch beliebig weiterzugeben oder zu verändern (vgl. [Wikipedia2006a]).

2.2 Was macht Open Source so interessant?

Im privaten Bereich dürfte das sehr eindeutig sein. Die Open-Source-Software ist kostenlos und bietet deshalb natürlich das beste Preis-Leistungsverhältnis. Im Unternehmensbereich spielen dabei aber noch einige andere Aspekte eine Rolle: Es fallen natürlich keine Lizenz- oder Anschaffungskosten an, wodurch die Soft-

ware insgesamt einen Kostenvorteil gegenüber kommerziellen Produkten haben kann.

Der Quellcode kann geprüft werden. Besonders bei sicherheitskritischen Anwen-

dungen kann dieses Argument sehr überzeugend sein. Meist werden auch Sicherheitslöcher sehr viel schneller behoben als bei kommerzieller Software.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 3 - Einführung in die MDA 8

Die Anwendung kann einfacher, der zugrunde liegenden Lizenz entsprechend,

erweitert oder in bestehende Anwendungen integriert werden. Herstellerunabhängigkeit: Man ist nicht von einem einzigen Hersteller abhängig

und kann die Software selber weiterentwickeln.

Die Qualität der Software ist meist mit kommerziellen Produkten gleichzusetzen.

Interoperabilität: Bei Open Source wird meist auf offene und anerkannte Stan-

dards gesetzt, dies erleichtert das Zusammenspiel mit anderen Anwendungen.

2.3 Open Source Lizenzen

Es gibt drei charakteristische Merkmale, die eine Lizenz einer Open-Source-Software erfüllen muss:

Der Programmcode der Software liegt in einer für Menschen lesbaren und verständlichen Form vor.

Die Software darf beliebig kopiert, verbreitet und genutzt werden. Die Software darf verändert und in der veränderten Form weitergegeben werden.

Das Copyleft-Prinzip

Eine veränderte Software darf nur dann verbreitet werden, wenn sie selbst wieder unter derselben Lizenz lizenziert wird. Ziel dieses Prinzips ist es, die Freiheiten einer Software in der Weiterentwicklung von Anderen zu sichern, nach dem Wahlspruch: „Was frei ist soll frei bleiben!“.

Das Copyleft-Prinzip findet sich beispielsweise in den GNU-Lizenzen oder unter dem Begriff „Share Alike“ in einigen Creative Commons-Lizenzen.

2.3.1 GNU General Public License (GPL)

Die GPL gewährt im Grunde folgende Freiheiten:

Die Software darf ohne jede Einschränkung für jeden Zweck genutzt werden, auch Kommerziell.

Kopien dürfen kostenlos oder gegen Geld verteilt werden, wobei der Programmcode mitverteilt werden oder zugänglich sein muss. Der Empfänger erhält dieselben Freiheiten. Lizenzgebühren sind nicht erlaubt. Niemand ist verpflichtet Kopien zu verteilen, wenn er es aber tut, dann nur nach den Regeln der GPL.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 3 - Einführung in die MDA 9

Die Software darf verändert werden. Wird die veränderte Software weitergege-

ben, gelten die Regeln der GPL. Hier gilt auch das Copyleft-Prinzip.

2.3.2 GNU Lesser General Public License (LGPL)

Die LGPL gewährt im Grunde dieselben Freiheiten wie die GPL. Allerdings dürfen externe Programme, die eine mit der LGPL Lizenzierte Software nutzen, ihre eigene Lizenz behalten. Deshalb ist die LGPL besonders für Bibliotheken geeignet. Viele Standardbibliotheken von Programmiersprachen, beispielsweise die glibc-Bibliothek, sind unter der LGPL lizenziert.

2.3.3 Eclipse Public License (EPL)

Die EPL ist eine Abwandlung der Common Public License (CPL) und speziell auf die Eclipse Foundation abgestimmt. Die grundlegenden Freiheiten und Regeln sind jedoch dieselben. Anders als bei der GPL muss nicht jedes auf der Software basierende Programm auch unter die EPL gestellt werden. Kommt ein neuer Teil zu der Software hinzu, so muss dieser nicht unter die EPL gestellt werden. Wenn allerdings ein unter der EPL stehender Teil verändert wird, so muss dieser auch weiterhin unter der EPL vertrieben werden.

2.3.4 Berkeley Software Distribution (BSD) Lizenz

Das BSD Lizenzmodell ähnelt im Groben auch der GPL, allerdings enthält die Lizenz kein Copyleft. Wird eine unter der BSD-Lizenz stehende Software verändert, so muss der Programmcode der veränderten Software nicht veröffentlicht werden. Allerdings muss der Copyright-Vermerk der ursprünglichen Software enthalten bleiben. Software unter der BSD-Lizenz eignet sich somit gut als Grundlage für Kommerzielle Produkte.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 4 - Evaluierung der MDA Werkzeuge 10

3 Einführung in die MDA

Die Model Driven Architecture (MDA) versucht die schon lange existierende Idee, von der Trennung von fachlichen Aspekten und Technik umzusetzen (vgl. [OMG2003], 2.1.2 Overview). MDA erreicht dies im Grunde mit Hilfe von architektonischer Trennung der Zuständigkeiten über Modelle.

3.1 Allgemeines

MDA ist eine Strategie bzw. ein Standardisierungskonzept der Object Management Group (OMG). Die OMG ist eine offene Gesellschaft und erstellt herstellerunabhängige Spezifikationen zur Verbesserung der Interoperabilität und Portabilität von Enterprise-Anwendungen.

Da im klassischen Vorgehen mit (UML)-Modellen meist nur ein Modell existiert, in dem fachliche und technische Informationen vermischt sind, teilt MDA das Gesamtmodell in mehrere Schichten:

Computation Independent Model (CIM). Das CIM beschreibt ein System aus der Sicht des Business und ist somit von der IT völlig unabhängig. Das CIM wird oft auch als „Domänen-Modell“ oder „Business-Modell“ bezeichnet. Platform Independent Model (PIM). Das PIM bietet eine plattformunabhängige Sicht auf ein System. Es kann somit für viele verschiedene Plattformen angewendet werden. Hier werden meist die Geschäftsprozesse abgebildet. Platform Specific Model (PSM). Das PSM verbindet die unabhängigen Spezifikationen des PIM mit den plattformspezifischen Gegebenheiten der entsprechenden Plattform.

Zielplattform (Code). Aus dem PSM wird der Quellcode für die Zielplattform generiert. Meist entsteht dabei noch kein ausführbarer Code, sondern lediglich ein Grundgerüst, das für die weitere händische Implementierung genutzt wird.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 4 - Evaluierung der MDA Werkzeuge 11

Allerdings konnte sich nur in einzelnen Nischenmärkten, beispielsweise im Bereich Echtzeitsysteme, in dem schon immer eine hohe Präzision der Modelle gefordert wurde, die vollständige Modellierung durchsetzen (vgl. [Hitz2005], S.348).

Durch diese Schichten wird die Trennung der Zuständigkeiten (separation of concerns) erreicht. Durch die abstrakten Modelle will die MDA nicht nur eine Plattformunabhängigkeit erreichen, sondern auch eine Sprach- und Systemunabhängigkeit. Mit Hilfe von Transformationen können die Modelle in anderen Schichten abgebildet werden. MDA unterscheidet dabei zwei Typen von Transformationen: Modell-zu-Modell Transformation. Ein Modell wird in ein anderes Modell trans-

formiert. Somit kann z.B. ein PIM mit Hilfe von Transformationsregeln in ein PSM transformiert werden.

Modell-zu-Code Transformation. Ein Modell wird in den Source Code einer be-

stimmten Programmiersprache transformiert. Diese Methode wird schon längere Zeit genutzt, z.B. in CASE-Werkzeugen, um Code aus Modellen zu generieren.

Die Transformationen erzeugen dabei aus den Elementen des Quellmodells die Elemente des Zielmodells. Üblicherweise laufen die Transformationen von der abstrakteren zur konkreteren Schicht (CIM PIM PSM Code).

Da MDA keinen festen Standard darstellt, sondern eher eine Strategie, ist die MDA auch sehr offen und bietet viel Spielraum für Interpretationen. Die OMG sieht für die Umsetzung von MDA die Verwendung von UML-Modellen vor. Generell ist es aber auch denkbar MDA mit einer andere Modellierungssprache umzusetzen, wenn diese sich an die Spezifikation der MDA hält (siehe Abschnitt 3.3).

Abbildung 3-1: MDA Strategie (vgl. [OMG2006])

Diplomarbeit - MDA auf Basis Open Source

Kapitel 4 - Evaluierung der MDA Werkzeuge 12

MDA kann mit dem damaligen Evolutionsschritt von der Assembler-Entwicklung zu den kompilierbaren Hochsprachen verglichen werden. Die Model Driven Architecture macht dem Schritt von Code basierten Hochsprachen zu abstrakteren, plattformunabhängigen Modellen.

3.2 Ziele der MDA

Interoperabilität. Durch saubere, offene und anerkannte Standards wie UML (Unified Modeling Language), MOF (Meta-Object Facility) oder XMI (XML Metadata Interchange) soll die Interoperabilität von verschiedenen Werkzeugen und Systemen vereinfacht werden.

Plattform Unabhängigkeit. Die Realisierung, also, wie die Software erstellt werden soll, ist sehr wechselhaft. Vor nicht all zu ferner Zeit waren es noch COBOL, C++ oder CORBA, heute sind es Technologien wie WebServices, XML oder EJBs und in Zukunft wird es immer wieder neue Technologien und Plattformen geben. MDA versucht, dies mit Hilfe der verschiedenen Abstraktionsstufen der Modelle zu lösen.

Höhere Wiederverwendbarkeit und Langlebigkeit. Durch die verschiedenen Abstraktionsstufen der Modelle sind diese jeweils von der darunter liegenden Schicht entkoppelt und können so leichter wieder verwendet werden. Konsistenz zwischen Code und Modellen. In vielen Unternehmen werden bereits Modelle in der Analyse und im Design eingesetzt. Oft werden diese Modelle aber bei Änderungen nicht angepasst und somit im weiteren Projektablauf unbrauchbar. Daraus resultiert, dass die Modelle auch selten bei der Implementierung genutzt werden können und immer wieder von vorn begonnen werden muss. Ein Grund hierfür ist sicherlich auch die mangelnde Tool Unterstützung, bzw. Inkompatibilität zwischen den Tools wegen proprietärer Schnittstellen. MDA liefert hierfür eine solide Grundlage mit offenen Standards wie UML, MOF, XMI oder OCL (Object Constraint Language). Somit kann durch eine bessere Tool-Pipeline die Konsistenz zwischen Code und Modellen eher gewährleistet werden.

Steigerung der Entwicklungsgeschwindigkeit. Dadurch, dass die Modelle im Entwicklungsprozess durchgehend verwendet werden können und am Ende Code generiert werden kann, verkürzt sich die Entwicklungszeit. Vor allem in zukünftigen Projekten, wenn Modelle oder Transformationen wieder verwendet werden können.

Verbesserung der Softwarequalität. Wenn im Team entwickelt wird, entsteht bei jeder beteiligten Person qualitativ unterschiedlicher Code. Durch die

Diplomarbeit - MDA auf Basis Open Source

Kapitel 4 - Evaluierung der MDA Werkzeuge 13

Transformation der Modelle kann eine konstante und reproduzierbare Qualität erreicht werden. Ebenso ist es möglich Tests oder Simulationen auf die Modelle anzuwenden.

Bessere Dokumentation. Das Modell ist einfacher lesbar sowohl von Entwick-

lern als auch vom Fachbereich. Die Dokumentation kann mit hoher Qualität automatisch aus den Modellen abgeleitet werden, somit steigt auch die Produktivität.

3.3 Zusammenhang von MDA mit MOF, UML, XMI

und QVT

Die Meta Object Facility (MOF) ist ein Meta-Metamodell zur Definition von Metamodellen. Andere Metamodelle, wie das der Unified Modeling Language (UML) oder des Common Warehouse Metamodel (CWM) und auch MOF selbst, wurden auf Basis von MOF definiert. MOF ist aber nicht nur zur Definition von Metamodellen geeignet, sondern bietet auch Funktionalität um Metadaten zu manipulieren. Es können Elemente von Metamodellen erzeugt, abgefragt, manipuliert und gelöscht werden. MOF bietet dabei auch Interoperabilität zwischen Metamodellen (PIMs), die auf Basis von MOF definiert wurden. Zum Beispiel erlaubt es der XMI-Standard, MOF-Metamodelle auf XML-Schemadefinitionen in Form von DTDs oder XML-Schema abzubilden (vgl. [Hitz2005], S.328).

Historisch gesehen entstand MOF aus dem Sprachkern von UML 1, allerdings be-standen noch einige essentielle Unterschiede. Eine vollständige Integration und damit auch eine vollständige Nutzung der Vorteile beider Standards wurde dadurch verhindert. Aus diesem Grund wurde bei der Entwicklung von UML 2 besonders darauf geachtet, eine architektonische Abstimmung beider Standards zu erreichen. Es wurde eine gemeinsame Basis in Form des Core-Paketes der Infrastructure-Library geschaffen. Dieser Kern wird sowohl von Meta-Metamodellen wie MOF (auf M3) als auch von anderen Metamodellen, wie dem UML-Metamodell, auf M2 verwendet (vgl. [Hitz2005], S.328). Das heißt, dass das UML 2 Metamodell auch eine Instanz des MOF Meta-Metamodells ist, und somit alle Vorteile von MOF nutzen kann.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 4 - Evaluierung der MDA Werkzeuge 14

Abbildung 3-2: Zusammenhang zwischen Infrastruktur, MOF, UML und anderen Metamodellen (vgl. [Hitz2005], S. 329)

Somit ist jetzt ein plattformunabhängiges System zum Austausch von Modellen ent-standen. Es kann z.B. Ein UML 2 Modell mittels XMI auf eine andere Modellierungssprache, die auf MOF basiert, wie CWM, abgebildet werden. Für diese Abbildung ist allerdings eine Metamodell Transformation notwendig.

Für (Meta)modell Transformationen empfiehlt die OMG die Verwendung von MOF QVT. Das Akronym QVT steht für "queries" (Anfragen), "views" (Sichten) und "trans-formations" (Transformationen).

Abbildung 3-3: Metamodell Transformation (vgl. [OMG2003], Figure 3-2)

Daraus folgt, dass jeder Werkzeughersteller sein eigenes (proprietäres) MOFbasiertes Metamodell verwenden könnte, aber trotzdem ein Austausch der Modelle gewährleistet ist.

3.4 Konzepte

In diesem Teil der Arbeit werden die Kernkonzepte der MDA kurz erläutert. Das sind die Modelle, die Plattform und die UML-Profile.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 4 - Evaluierung der MDA Werkzeuge 15

3.4.1 Modelle

Modelle sind eine abstrakte Repräsentation von Struktur, Funktion oder Verhalten eines Systems (vgl. [Wikipedia2006]). Sie werden üblicherweise mit der Modellierungssprache UML definiert.

MDA-Modelle unterscheiden sich von gewöhnlichen UML-Modellen darin, dass ihre Bedeutung formal definiert ist. Dies wird durch UML-Profile erreicht (siehe unten). Es ist also nicht jedes UML-Modell auch gleichzeitig ein MDA-Modell und umgekehrt.

3.4.2 Plattform

Eine Plattform, und deren Abstraktionsgrad, ist durch die MDA nicht fest definiert. Eine Plattform kann dann beispielsweise die X86 Architektur für ein Windows Betriebssystem oder J2EE für eine Webanwendung sein. Da die OMG aber vor allem an der Verbesserung der Interoperabilität und Portabilität von Enterprise-Anwendungen interessiert ist, spiegelt sich das auch in der praktischen Bedeutung des Begriffes wieder.

3.4.3 UML-Profile

UML-Profile stellen die Möglichkeit zur Erweiterung des UML-Metamodells dar. Sie erlauben die Formalisierung von Domänenmodellen. Das bedeutet, dass mittels UML-Profilen der UML-Sprachumfang so erweitert werden kann, dass domänen- oder platt-formspezifische Semantiken abgebildet werden können, beispielsweise EJBs.

3.5 Abgrenzung

MDA wird gelegentlich mit anderen Technologien oder Konzepten gleichgesetzt:

MDA wir oft synonym zu den CASE-Ansätzen verwendet. MDA und CASE unterscheiden sich jedoch in ihren Zielen. Die CASE-Ansätze haben zum Ziel, die Softwareentwicklung durch den Einsatz von IT-gestützten Werkzeugen zu unterstützen. Fachliche Anforderungen werden dabei möglichst vollständig und automatisiert erstellt. Somit ist eine Trennung von fachlichen und technischen Aspekten nicht gegeben. Meist sind Metamodelle und Transformationen vorgegeben und lassen sich nicht anpassen. Oft werden proprietäre Modellierungssprachen zur Spezifikation der Systeme verwendet, was das Mindestmaß an Interoperabilität verletzt.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 4 - Evaluierung der MDA Werkzeuge 16

Oft wird MDA auch mit der Generierung gleichgesetzt. Dem ist aber nicht so. Die

Generierung von Code ist nur ein Teil, der MDA ausmacht. MDA abstrahiert hier auch einen Schritt weiter. So spricht man im Kontext von MDA eher von Trans-formation und nicht von Generierung, da MDA nicht nur Modell-zu-Code Trans-formationen vorsieht, sondern auch Modell-zu-Modell Transformationen.

Zu beachten ist auch, dass MDA nicht mit der Modellgetriebenen Softwareent-

wicklung (MDSD) gleichzusetzen ist. MDA ist dabei nur eine mögliche Umsetzung von MDSD. MDSD ermöglicht es, Softwaresysteme durchgängig mit Modellen zu beschreiben. Das Modell ist dabei der Ausgangspunkt für den Entwicklungsprozess. MDA spezifiziert diese allgemeine Aussage detaillierter, beispielsweise durch plattformunabhängige und plattformspezifische Modelle.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 5 - Prototyp 17

4 Evaluierung der MDA Werkzeuge

In diesem Kapitel werden verschiedene Open Source Werkzeuge, die momentan am Markt erhältlich sind, vorgestellt, auf ihre Stärken und Schwächen hin untersucht und miteinander verglichen. Am Ende wird ein oder auch mehrere Werkzeuge für die prototypenhafte Umsetzung des vorgegebenen Geschäftsvorfalles ausgewählt.

4.1 Übersicht

Es existiert eine große Anzahl an verschiedenen MDA-Werkzeugen, deren Funktionsumfang und Einsatzgebiet stark variieren. Dies ist nicht verwunderlich, da der MDA-Ansatz sehr offen und allgemein für die gesamte Softwareentwicklung definiert ist. Es können beispielsweise Webanwendungen, Echtzeitsysteme oder verteilte Anwendungen gleichermaßen auf Basis der MDA entwickelt werden (vgl. [Hitz2005], S. 350).

4.1.1 Abgrenzung

Im Moment existiert leider kein generisches MDA-Werkzeug, mit dem sämtliche Arten an Software abgedeckt werden können. Für eine bestimmte Art von Anwendung muss man ein entsprechendes Werkzeug aus der Masse der verfügbaren MDA-Werkzeuge auswählen. Diese Werkzeuge können grob in drei Werkzeugkategorien eingeteilt werden:

xUML-Werkzeuge. Diese Werkzeugkategorie benutzt Executeable UML (xUML), dass eine Variante von UML darstellt und ausführbare Modelle unterstützt. Mit diesen Werkzeugen kann die komplette Anwendung modelliert werden und eine lauffähige Anwendung generiert werden. Diese Werkzeuge werden vorwiegend für Echtzeit- und Embeddedsysteme eingesetzt und produzieren meist C, C++ oder Ada Code (vgl. [Hitz2005], S. 350). Vertreter dieser Werk-zeugkategorie ist beispielsweise iUML oder BridgePoint.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 5 - Prototyp 18

Plattformspezifische Werkzeuge. Werkzeuge dieser Kategorie sind für eine spezielle Technologie ausgerichtet. Durch die Einschränkung auf eine bestimmte Plattform können diese Werkzeuge besondere Funktionalitäten bieten, wie beispielsweise eine automatische Verteilung von Komponenten. Leider ist der Benutzer aber auch durch diese Plattformabhängigkeit an die entsprechende Technologie gebunden. Speziell für objektorientierte Komponententechnologien wie J2EE oder .NET werden viele Werkzeuge angeboten (vgl. [Hitz2005], S. 350). OptimalJ ist beispielsweise ein Vertreter dieser Werk-zeugkategorie.

Plattformunabhängige Werkzeuge. Werkzeuge dieser Kategorie setzen einen großen Teil der MDA-Konzepte um. Sie unterstützen mehrere Zielplattformen und lassen sich an die Bedürfnisse der Benutzer gut anpassen. Werkzeuge wie AndroMDA können dieser Kategorie zugeordnet werden.

Die Grenze zwischen plattformspezifischen und plattformunabhängigen Werkzeugen ist sehr fließend und es ist deshalb oft sehr schwer bestimmte Werkzeuge genau einer Werkzeugkategorie zuzuordnen. Dies hängt auch vom Verständnis der Plattform ab. Ab wann ist ein Modell plattformunabhängig? Wenn es von der Programmiersprache unabhängig ist? Oder gar erst, wenn es ein reines Businessmodell ist? Diese Fragestellung muss jeder für sich selbst beantworten, da sie explizit von den Anforderungen der Software abhängt. Im Enterprise Umfeld ist allerdings meist die Unabhängigkeit von bestimmten Technologien wie J2EE, .Net oder WebServices gemeint. Eine weitere Kategorie sind die reinen Codegeneratoren, die meist in CASE-Werkzeugen verwendet werden. Sie zählen nicht zu den MDA-Werkzeugen, da sie die MDA-Konzepte nicht beachten. Diese Werkzeuge können meist nur Code für eine vorgegebene Plattform erzeugen. Meist ist das eine Programmiersprache wie Java, C# oder PHP. Üblicherweise erzeugen sie aus Klassendiagrammen die entsprechenden Klassen der Programmiersprache mit Attributen und den Methodenrümpfen. Die Trans-formation lässt sich üblicherweise nicht oder nur sehr begrenzt anpassen. Diese Art von Werkzeugen wird deshalb für die Evaluierung ausgeschlossen.

Am Open Source Markt existieren momentan kaum komplette MDA-Werkzeuge. Fast immer sind diese in einen Modellierungs- und einen Generierungsteil aufgesplittet. Daher auch die Aufteilung der Evaluierung in Modellierungswerkzeuge und Generierungswerkzeuge.

4.1.2 Allgemeines Vorgehen für die Evaluierung

Als erstes werden die Anforderungen an das Werkzeug gesammelt, beschrieben und zu Anforderungskategorien zusammengefasst. Der nächste Schritt ist die Gewichtung der Anforderungen, da sie unterschiedliche Prioritäten haben. Die Gewichtung wird dabei in fünf Stufen eingeteilt.

Diplomarbeit - MDA auf Basis Open Source

Kapitel 5 - Prototyp 19

Tabelle 4-1: Gewichtungen und ihre Bedeutung

Als nächstes wurden die Werkzeuge nacheinander auf die einzelnen Anforderungen hin untersucht und die Umsetzung anschließend bewertet. Für die Bewertung stehen insgesamt sechs Stufen zur Verfügung.

Tabelle 4-2: Bewertungen und ihre Bedeutung

Gewichtet und bewertet werden die Anforderungen über die Anforderungskategorien um die Einfachheit und die Übersichtlichkeit zu gewährleisten. Das Ergebnis der Evaluierung einer Anforderung errechnet sich durch eine Multiplikation der Gewichtung mit der Bewertung (Bewertung * Gewichtung = Anforderungsergebnis). Das Gesamtergebnis errechnet sich durch die Addition der einzelnen Anforderungsergebnisse (Anforderungsergebnis 1 + Anforderungsergebnis n = Gesamtergebnis). Somit erhält man für jedes Werkzeug eine Summe, mit deren Hilfe man die Umsetzung der Anforderungen schnell vergleichen kann.

Auf eine detaillierte Zuordnung von der Bedeutung einer Bewertung einer Anforderung wurde bewusst verzichtet. Dies hätte dem Evaluierungsprozess eine unnötige Starrheit gegeben und da die Anforderungen nicht einzeln, sondern über Anforde-rungskategorien gewichtet und bewertet werden, wäre so eine unnötig hohe Komplexität entstanden.

Diplomarbeit - MDA auf Basis Open Source