MDA auf Basis Open Source

Inhaltsverzeichnis

1 EINLEITUNG
1.1 Problemstellung
1.2 Zielsetzung
1.3 Abgrenzung
1.4 Vorgehen
1.5 Aufbau der Diplomarbeit

2 OPEN SOURCE
2.1 Was ist Open Source?
2.2 Was macht Open Source so interessant?
2.3 Open Source Lizenzen
2.3.1 GNU General Public License (GPL)
2.3.2 GNU Lesser General Public License (LGPL)
2.3.3 Eclipse Public License (EPL)
2.3.4 Berkeley Software Distribution (BSD) Lizenz

3 EINFÜHRUNG IN DIE MDA
3.1 Allgemeines
3.2 Ziele der MDA
3.3 Zusammenhang von MDA mit MOF, UML, XMI und QVT
3.4 Konzepte
3.4.1 Modelle
3.4.2 Plattform
3.4.3 UML-Profile
3.5 Abgrenzung

4 EVALUIERUNG DER MDA WERKZEUGE
4.1 Übersicht
4.1.1 Abgrenzung
4.1.2 Allgemeines Vorgehen für die Evaluierung
4.2 Evaluierung von Modellierungswerkzeugen
4.2.1 Einschränkungen
4.2.2 Anforderungen
4.2.3 Vorgehen
4.2.4 Übersicht
4.2.5 Werkzeuge im Detail
4.2.6 Fazit Modellierungswerkzeuge
4.3 Evaluierung von Generierungswerkzeugen
4.3.1 Einschränkungen
4.3.2 Anforderungen
4.3.3 Vorgehen
4.3.4 Übersicht
4.3.5 Werkzeuge im Detail
4.3.6 Fazit Generierungswerkzeuge
4.4 Fazit
4.4.1 Modellierungswerkzeuge
4.4.2 Generierungswerkzeuge
4.4.3 Empfehlung

5 PROTOTYP
5.1 Analyse
5.1.1 Geschäftsvorfall
5.2 Architektur
5.2.1 Verwendete Technologien
5.2.2 Verwendete AndroMDA Cartridges
5.2.3 AndroMDAs typische J2EE Architektur
5.3 Design
5.3.1 Domänenmodell
5.3.2 Value Objects
5.3.3 Services
5.3.4 Benutzer Frontend
5.4 Umsetzung
5.4.1 Persistenz
5.4.2 Fachliche Logik
5.4.3 Arbeitsabläufe (Workflow)
5.4.4 Middleware (Kommunikation)
5.4.5 Benutzer Frontend
5.4.6 Erweiterung von AndroMDA
5.5 Fazit

6 ZUSAMMENFASSUNG
6.1 Ergebnisbewertung
6.1.1 Probleme
6.1.2 MDA im Unternehmen
6.2 Stand der Technik und Ausblick

ABBILDUNGSVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

TABELLENVERZEICHNIS

LISTINGVERZEICHNIS

LITERATURVERZEICHNIS

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 evalua- tion 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.

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 ein- gesetzt werden kann. Deshalb soll in diesem Fall durch eine Evaluierung von Open- Source-Werkzeugen der aktuelle Stand der unterstützenden MDA-Werkzeuge aufge- zeigt 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 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: x Die Einarbeitung in MDA und UML

- Die Evaluierung der Modellierungswerkzeuge
- Die Evaluierung der Generierungswerkzeuge
- Die Entwicklung des Prototypen
- Die Finalisierung der Diplomarbeit

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1: Zeitplan der Diplomarbeit mit den Phasen Meilensteinen

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.

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 Generierungs- werkzeuge 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 erge- ben haben.

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: x 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 Si- cherheitslöcher sehr viel schneller behoben als bei kommerzieller Software.
- 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. x 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 ver- stä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 Programm- code mitverteilt werden oder zugänglich sein muss. Der Empfänger erhält diesel- ben Freiheiten. Lizenzgebühren sind nicht erlaubt. Niemand ist verpflichtet Ko- pien zu verteilen, wenn er es aber tut, dann nur nach den Regeln der GPL.
- 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 ex- terne Programme, die eine mit der LGPL Lizenzierte Software nutzen, ihre eigene Li- zenz behalten. Deshalb ist die LGPL besonders für Bibliotheken geeignet. Viele Stan- dardbibliotheken 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 Pro- gramm auch unter die EPL gestellt werden. Kommt ein neuer Teil zu der Software hin- zu, 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 ver- trieben 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.

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 ange- wendet werden. Hier werden meist die Geschäftsprozesse abgebildet.
- Platform Specific Model (PSM). Das PSM verbindet die unabhängigen Spezifi- kationen des PIM mit den plattformspezifischen Gegebenheiten der entspre- chenden Plattform.
- Zielplattform (Code). Aus dem PSM wird der Quellcode für die Zielplattform ge- neriert. Meist entsteht dabei noch kein ausführbarer Code, sondern lediglich ein Grundgerüst, das für die weitere händische Implementierung genutzt wird.

Allerdings konnte sich nur in einzelnen Nischenmärkten, beispielsweise im Be- reich 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 con- cerns) erreicht. Durch die abstrakten Modelle will die MDA nicht nur eine Plattformu- nabhä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än- gere Zeit genutzt, z.B. in CASE-Werkzeugen, um Code aus Modellen zu ge- nerieren.

Die Transformationen erzeugen dabei aus den Elementen des Quellmodells die E- lemente 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 in dieser Leseprobe nicht enthalten

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

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, plattformunab- hä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 wer- den 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 be- reits Modelle in der Analyse und im Design eingesetzt. Oft werden diese Mo- delle aber bei Änderungen nicht angepasst und somit im weiteren Projektab- lauf unbrauchbar. Daraus resultiert, dass die Modelle auch selten bei der Imp- lementierung genutzt werden können und immer wieder von vorn begonnen werden muss. Ein Grund hierfür ist sicherlich auch die mangelnde Tool Unter- stü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 verwen- det werden können.
- Verbesserung der Softwarequalität. Wenn im Team entwickelt wird, entsteht bei jeder beteiligten Person qualitativ unterschiedlicher Code. Durch die 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 Pro- duktivität.

3.3 Zusammenhang von MDA mit MOF, UML, XMI und QVT

Die Meta Object Facility (MOF) ist ein Meta-Metamodell zur Definition von Metamodel- len. 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, son- dern 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 verhin- dert. Aus diesem Grund wurde bei der Entwicklung von UML 2 besonders darauf ge- achtet, eine architektonische Abstimmung beider Standards zu erreichen. Es wurde eine gemeinsame Basis in Form des Core -Paketes der Infrastructure-Library geschaf- fen. 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.

Abbildung in dieser Leseprobe nicht enthalten

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 entstanden. 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 "transformations" (Transformationen).

Abbildung in dieser Leseprobe nicht enthalten

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.

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 Betriebssys- tem oder J2EE für eine Webanwendung sein. Da die OMG aber vor allem an der Ver- besserung der Interoperabilität und Portabilität von Enterprise-Anwendungen interes- siert 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 unter- scheiden sich jedoch in ihren Zielen. Die CASE-Ansätze haben zum Ziel, die Softwareentwicklung durch den Einsatz von IT-gestützten Werkzeugen zu unter- stützen. Fachliche Anforderungen werden dabei möglichst vollständig und auto- matisiert erstellt. Somit ist eine Trennung von fachlichen und technischen Aspek- ten 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 Interoperabili- tät verletzt.
- 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 Umset- zung von MDSD. MDSD ermöglicht es, Softwaresysteme durchgängig mit Model- len zu beschreiben. Das Modell ist dabei der Ausgangspunkt für den Entwick- lungsprozess. MDA spezifiziert diese allgemeine Aussage detaillierter, beispiels- weise durch plattformunabhängige und plattformspezifische Modelle.

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 Funktions- umfang 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 Anwendun- gen 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 wer- den:

- 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 vor- wiegend 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.
- Plattformspezifische Werkzeuge. Werkzeuge dieser Kategorie sind für eine spezielle Technologie ausgerichtet. Durch die Einschränkung auf eine be- stimmte Plattform können diese Werkzeuge besondere Funktionalitäten bie- ten, wie beispielsweise eine automatische Verteilung von Komponenten. Lei- der ist der Benutzer aber auch durch diese Plattformabhängigkeit an die ent- sprechende Technologie gebunden. Speziell für objektorientierte Komponen- tentechnologien 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 Werkzeu- gen 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 Programmierspra- che unabhängig ist? Oder gar erst, wenn es ein reines Businessmodell ist? Diese Fra- gestellung muss jeder für sich selbst beantworten, da sie explizit von den Anforderun- gen der Software abhängt. Im Enterprise Umfeld ist allerdings meist die Unabhängig- keit 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 vor- gegebene 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 Generie- rungswerkzeuge.

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.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4-1: Gewichtungen und ihre Bedeutung

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

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 Anforde- rung 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 Komplexi- tät entstanden.

Tabelle 4-3: Beispiel für eine detaillierte Zuordnung von der Bedeutung einer Bewertung für die Anforderung Interoperabilität bei Modellierungswerkzeugen

Abbildung in dieser Leseprobe nicht enthalten

4.2 Evaluierung von Modellierungswerkzeugen

Unter Modellierungswerkzeugen versteht man Werkzeuge, die in erster Linie zum Erstellen von Modellen benutzt werden. Die Modelle werden üblicherweise nach der Erstellung in einem bestimmten Format, beispielsweise XMI, abgespeichert und dann von einem Generierungswerkzeug wieder eingelesen.

Einige Modellierungswerkzeuge besitzen selbst auch einen integrierten CodeGenerator, der aber an die Funktionalität und Flexibilität der Generierungswerkzeuge meist nicht heran reicht.

4.2.1 Einschränkungen

Da das Thema dieser Arbeit „MDA auf Basis Open Source“ ist, werden grundsätzlich nur Open-Source-Werkzeuge betrachtet. Die frei erhältlichen Community Versionen der kommerziellen Werkzeuge werden nicht untersucht.

Am Markt existieren viele Modellierungswerkzeuge, die sich jedoch in ihrer Qualität als auch ihrer Funktionalität sehr stark unterscheiden. Viele Werkzeuge basieren auf proprietären Metamodellen und bieten oft keine Möglichkeit zum standardisierten Im- port oder Export der Modelle, beispielsweise im XMI-Format. Einige beherrschen nicht ein Mindestmaß an Diagrammtypen oder sie sind unvollständig implementiert. Einige Werkzeuge sind auch noch in einem sehr frühen Entwicklungsstadium oder haben eine katastrophale Usability, weshalb sie nicht vernünftig zu bedienen sind.

Daher beschränkt sich die Evaluierung nur auf wenige Werkzeuge. Im Abschnitt 4.2.4 wird dennoch eine Übersicht über alle, zur Zeit der Evaluierung gefundenen Werkzeuge gegeben, auch wenn diese für die detaillierte Evaluierung ausgeschlossen wurden.

4.2.2 Anforderungen

Die Anforderungen an ein Modellierungswerkzeug im Bezug auf die Nutzung im MDA- Kontext:

- Interoperabilität: Das Modellierungswerkzeug sollte ein Mindestmaß an Intero- perabilität bieten. Das heißt, das Werkzeug muss die erstellten Modelle exportieren können und Modelle anderer Werkzeuge möglichst importieren können. Ein gutes Austauschformat ist hier XMI, wobei es leider viele verschiedene zueinander inkompatible XMI-Versionen gibt.
- Metamodell: Die Modelle des Werkzeugs sollten auf einem MOF konformem Metamodell basieren, wie von MDA gefordert, beispielsweise UML. Dies erleichtert den Modellaustausch und auch die Modelltransformation.
- Diagrammtypen: Es muss mindestens das Klassendiagramm verfügbar sein. Um auch grafische Benutzeroberflächen modellieren zu können, sollte das Werkzeug auch Anwendungsfalldiagramme und Aktivitäts- oder Zustandsdia- gramme beherrschen. Alle anderen Diagrammtypen sind meist nicht zwingend für die Weiterverarbeitung durch ein MDA-Generierungswerkzeuges nötig.
- Wichtige (UML) Notationen: Notationen der UML, wie Stereotypen, Eigen- schaftswerte (Tagged Values) oder Einschränkungen (Constraints) werden oft von Generatoren verwendet, um entsprechende Ereignisse auszulösen oder die Codegenerierung zu beeinflussen. UML-Profile spielen dabei auch eine wichtige Rolle. Deshalb sind diese Aspekte auch entscheidend für die Auswahl des Modellierungswerkzeuges.
- Teamunterstützung: Heutzutage gibt es verschiedene Rollen in einem Soft- wareprojekt, die gemeinsam an den Modellen arbeiten müssen, beispielswei- se Softwareanalysten, -architekten und -entwickler. Ohne Unterstützung des Werkzeuges ist es praktisch nicht möglich im Team an einem Modell gemein- sam zu arbeiten.
- Support: Eine aktive Community und eine gute Dokumentation ist für eine schnelle Lösung von Problemen bei einer Open Source Software sehr hilfreich. In Foren oder Newsgroups finden sich meist sehr schnell die dringend benötigten Antworten für spezielle Fragen. Aus diesem Grund ist dies auch eine wichtige Anforderung an ein Werkzeug.
- Usability: Das Werkzeug sollte sich intuitiv und möglichst einfach bedienen las- sen. Dies reduziert die Einarbeitungsphase, spart Zeit bei der täglichen Bedienung und erhöht die Akzeptanz bei den Anwendern.
- IDE Integration: Idealerweise lässt sich das Werkzeug auch in die bestehende Entwicklungsumgebung integrieren, beispielsweise in Eclipse oder Microsofts Visual Studio.

4.2.2.1 Gewichtung

- Interoperabilität (5): Da die Interoperabilität bereits ein Grundbaustein der MDA ist, ist diese Anforderung unverzichtbar und wird deshalb mit fünf gewichtet.
- Metamodell (4): Auch das Metamodell wird von der MDA Spezifikation beschrie- ben. Es ist aber trotzdem nicht als unverzichtbar zu bewerten, da z.B. durch die Interoperabilität Schwächen beim Metamodell wieder kompensiert werden könnten. Deshalb die Gewichtung mit vier.
- Diagrammtypen (4): Die Vielfalt der Diagrammtypen ist sehr wichtig, da sie die Präzision und die Reichweite der Modelltransformation stark beeinflussen. Aus diesem Grund wird diese Anforderung ebenfalls mit vier gewichtet.
- Wichtige (UML) Notationen (3): Die Unterstützung der UML Notationen beein- flusst ebenfalls die Reichweite der Modelltransformation, allerdings nicht in dem Maße wie das die Diagrammtypen tun. Deshalb die Gewichtung mit drei.
- Teamunterstützung (3): Die Teamunterstützung ist ein wichtiger Punkt bei der Auswahl eines Werkzeuges. Je größer das Projekt, desto wichtiger ist die Mehrbenutzerunterstützung. Sie beeinflusst dabei aber nicht den MDA-Ansatz und wird deshalb mit drei gewichtet.
- Support (3): Durch einen guten Support kann bei Fragen und Problemen erheb- lich Zeit und dadurch Geld gespart werden. Allerdings hat diese Anforderung nicht so starken Einfluss auf den MDA-Ansatz und wird deshalb mit drei ge- wichtet.
- Usability (3): Durch eine gute Usability wird das Werkzeug schnell akzeptiert und es macht Spaß, damit zu arbeiten. Die Usability hat, ähnlich wie der Sup- port, wenig Einfluss auf den MDA-Ansatz, deshalb auch hier die Gewichtung mit drei.
- IDE Integration (1): Durch die Integration in eine Entwicklungsumgebung ver- bessert sich auch die Usability und die Round-Trip-Zeiten können sich verkürzen. Da die IDE Integration aber auch als Unterpunkt der Usability gesehen werden kann, wird diese Anforderung sehr gering, mit eins gewichtet.

4.2.3 Vorgehen

In diesem Abschnitt möchte ich mein Vorgehen während der Evaluierung der Modellierungswerkzeuge beschreiben.

Zuerst habe ich die unten stehenden Quellen nach möglichen Werkzeugen durchsucht und in einer Tabelle aufgelistet.

Danach wurde die Tabelle um Informationen zu jenen Werkzeugen erweitert, die sich auf den jeweiligen Webseiten der Werkzeuge finden ließen. Diese Tabelle ist unten im Abschnitt 4.2.4 zu sehen. Hierbei sind einige Werkzeuge schon ausgeschieden, z.B. weil sie lediglich als Werkzeug zum Zeichnen von Diagrammen angepriesen wurden, ähnlich wie Microsoft Visio.

Quellen:

- http://oose.de/uml-tools
- http://www.objectsbydesign.com/tools/umltools_byPrice.html x http://www.jeckle.de/umltools.htm
- http://google.de
- http://sourceforge.net

Als nächsten Schritt habe ich die restlichen Werkzeuge nacheinander installiert und ausprobiert. Dabei habe ich zuerst ein Klassendiagramm erstellt, das die wichtigsten Elemente dieses Diagrammtyps verwendet. Ebenso bin ich beim Anwendungsfall-, Aktivitäts- und Zustandsdiagramm vorgegangen. Die nachfolgenden Abbildungen zeigen die einzelnen Referenzdiagramme. Dabei ist darauf hinzuweisen, dass die Semantik der Diagramme irrelevant ist. Nur die technischen Funktionen und Elemente der Diagramme sind ausschlaggebend, beispielsweise, ob mehrfache Stereotypen möglich sind oder ob Signale (richtig) dargestellt werden.

Die Referenzdiagramme wurden mit der Community Edition von „poseidon“ und „MagicDraw“ erstellt. Es wurden genau diese Werkzeuge ausgewählt, weil sie von einigen Herstellern von Generierungswerkzeugen empfohlen werden. Damit existieren die Modelle im XMI 1.2 mit UML 1.4 Metamodell, XMI 2.1 mit UML 2.0 Metamodell und im EMF XMI 2.0 mit UML 2.0 Metamodell Format. Dadurch ist eine gute und breite Referenzgrundlage für die Evaluierung gegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-1: Referenz Klassendiagramm

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-2: Referenz Anwendungsfalldiagramm

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-3: Referenz Aktivitätsdiagramm

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-4: Referenz Zustandsdiagramm

Der nächste Schritt ist das Exportieren des Modells mit den vier Diagrammen. Dieses Modell wird, nachdem alle Werkzeuge diese Prozedur durchlaufen haben, dazu benötigt, um die Import-Funktion zu testen. Jedes Werkzeug muss jedes exportierte Modell der anderen Werkzeuge importieren. Somit entsteht eine Matrix, aus der man die Kompatibilität unter den Werkzeugen ablesen kann. Durch diese Prozedur lassen sich die Anforderungen „Interoperabilität“, „Metamodell“, „Diagrammtypen“ und ein Teil der „wichtigen (UML) Notationen“ einheitlich bewerten.

Die übrigen Anforderungen wurden durch Testen des Werkzeugs empirisch ermit- telt.

4.2.4 Übersicht

Tabelle 4-4: Übersicht über alle Modellierungswerkzeuge die auch im Detail evaluiert wurden.

Abbildung in dieser Leseprobe nicht enthalten

1) nur ein Stereotyp pro Element möglich

[...]