SEMINARARBEIT. MDA Model Driven Architecture

Transkript

1 SEMINARARBEIT MDA Model Driven Architecture durchgeführt am Studiengang Angewandte Informatik an der Naturwissenschaftlichen Fakultät der Universität Salzburg Fachbereich Computerwissenschaften vorgelegt von: Franz Alois Schiestl Michael Radlingmaier Betreuer: Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Salzburg, Jänner 2008

2 Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis ii iii 1 Einleitung 1 2 Model Driven Architecture (MDA) Prinzipielle Vorgehensweise Standards Metamodellierung Transformationen (Mappings) xuml OCL xuml - Vorteile und Nachteile Beispiele zur Anwendung der MDA Fujaba Zusammenfassung 16 Literaturverzeichnis 18 Abkürzungsverzeichnis 20 Anhang 21 A Methoden 22 A.1 main() A.2 inc() ii

3 Abbildungsverzeichnis 2.1 Vorgehensweise der MDA Model Driven Architecture (MDA) [OMGI08a] MDA Metalevels [Fran05] Beispiel zur Metamodellierung [StVo05] MDA Transformationen Modellelemente von xuml Object- und Testcode [Rump02] Fujaba - Klassendiagramm für die Klassen MainClass und Counter Activity - Diagramm für die Counter - Methode inc() Activity - Diagramm für die MainClass - Methode main() iii

4 1 Einleitung Derzeitige Softwareentwicklungsprojekte sind einerseits von sich schnell ändernden Technologien und Anforderungen durch den Auftraggeber sowie von Zeitüberschreitungen der geplanten Fertigungstermine und den daraus entstehenden Kosten geprägt. Um diesen Problemen im Entwicklungsprozess entgegen zu treten wurde von der Object Management Group (OMG) im Jahr 2001 die Initiative Model Driven Architecture (MDA) gegründet. Die OMG ist eines der wichtigsten Standardisierungsgremien für die objektorientierte Systementwicklung, welches bereits eine Vielzahl an Technologien spezifizierte. Zu diesen zählen beispielsweise die Unified Modeling Language (UML) und Meta Object Facility (MOF), welche im Folgenden noch genauer erwähnt werden [Fran05] [OMGI08a] [OMGI08b] [OMGI08c]. Laut Ansichten der OMG basiert die nächste Generation der Softwareentwicklung auf einem transformationalen Ansatz, welcher durch die MDA verfolgt wird. Dies würde bedeuten, dass es nicht mehr länger notwendig sein wird als Softwareentwickler Source- Code zu implementieren, sondern Geschäftsprozesse zu modellieren und die dafür benötigten Modelle zu entwerfen. Der gesamte Software-Entwicklungsprozess findet dabei in Form von Modellen statt, welche schließlich bis hin zu ausführbaren Anwendungen transformiert werden. [OMGI08a] Dieser Ansatz würde bei einer konsequenten Durchführung im Rahmen eines gesamten 1

5 1. Einleitung 2 Projektes eine enorme Reduzierung der Entwicklungszeiten sowie auch der Entwicklungskosten mit sich bringen, jedoch sind bis dato noch nicht alle erforderlichen Komponenten wie beispielsweise die Transformationen von den Modellen exakt spezifiziert. Es gibt bereits erste Ansätze von Entwicklungsumgebungen welche MDA-konform sind, jedoch wird von diesen lediglich ein sehr kleiner Teil der gesamten MDA-Funktionalitäten bereitgestellt. Als Grundvoraussetzung für die Anwendung dieses neuen Ansatzes zur Softwareentwicklung ist die Entwicklung von Software anhand von Modellen (Model Driven Software Development, MDSD). Dabei hat sich die Unified Modelling Language als Defacto-Standard für die Beschreibung von Softwaresystemen durchgesetzt. Erst mit Hilfe der UML ist es möglich Softwaresysteme durch Objekte und Beziehungen auf einer abstrakten Ebene darzustellen. Hierfür stellt die UML diverse Struktur- und Verhaltensdiagramme zur Verfügung, wodurch die Abbildung eines zu realisierenden Softwaresystems in Form von Modellen ermöglicht wird. Wie bereits zuvor erläutert, wurde die UML wie auch die MDA von der OMG standardisiert und befindet sich aktuell in der offiziellen Version [OMGI08c] [StVo05]. In den nachfolgenden Abschnitten werden zunächst die Prinzipien und Vorgehensweisen sowie die bei der MDA zum Einsatz kommenden Technologien genauer dargestellt. Als eine spezielle Ausprägung der Programmiersprache UML handelt ein Kapitel über executable UML (xuml), welche alle nötigen Konstrukte beinhaltet um schließlich lauffähige Anwendungen aus erstellten Modellen zu generieren. Als praktisches Beispiel wird eine minimale Anwendung, welche mittels Fujaba (From UML to Java and back again) erstellt wurde, dargestellt. Schließlich bildet eine Zusammenfassung, in welcher die Ansätze der MDA kritisch betrachtet werden, den Abschluss der Arbeit.

6 2 Model Driven Architecture (MDA) In diesem Abschnitt der Arbeit werden die Kernaspekte der MDA genauer erläutert. Dazu zählen vor allem die prinzipielle Vorgehensweise, die verwendeten Standards, das Prinzip der Metamodellierung sowie auch die Transformationen. 2.1 Prinzipielle Vorgehensweise Das Prinzip der MDA ist eine Trennung der Definition der Funktionalität eines Systems von der Definition der Implementierung eines Systems mit bestimmten technologiespezifischen Eigenschaften beziehungsweise mit bestimmten pattformspezifischen Eigenschaften. Durch diese Trennung wird eine leichtere Implementierung der Lösung auf verschiedenen Plattformen ermöglicht, da diese Lösungen von einem zuvor entwickelten plattformunabhängigen Modell abgeleitet werden können. Des Weiteren ist es bei der Entwicklung einfacher das Verhalten eines Systems ohne plattform- beziehungsweise technologiespezifische Details zu beschreiben. Die Vorgehensweise bei der Entwicklung von Software mit dem Ansatz der MDA basiert auf verschiedenen Modellen mit einem unterschiedlichen Abstraktionslevel des zu entwickelnden Gesamtsystems. Ein prinzipieller Ablauf ist in Abbildung 2.1 dargestellt und wird im Folgenden genauer erläutert [MiMu03][Muke01] [Sole00]. 3

7 2. Model Driven Architecture (MDA) 4 Abbildung 2.1: Vorgehensweise der MDA Auf der höchsten Ebene befindet sich das Computation Independent Model (CIM). Dieses beinhaltet sämtliche Anforderungen und beschreibt, ohne jegliche technische Details, die zu realisierenden Geschäftsprozesse. Das CIM wird durch eine Transformation in ein plattformunabhängiges Modell PIM (Platform Independent Model) übergeführt. Hier wird die eigentliche Funktionalität und Struktur der Anwendung mit sämtlichen Details modelliert. Einen wesentlichen Vorteil den dieses Modell mit sich bringt ist, dass es bei eventueller Änderung der Zielplattform während des Entwicklungsprozesses weiter verwendet werden kann, da es keine implementierungsspezifischen Details beinhaltet. Das PIM wird mithilfe einer weiteren Transformation in ein Platform Specific Model (PSM) oder mehrere PSM s transformiert. Diese Modelle beinhalten nun zusätzlich auch technische Realisierungsdetails zu den jeweiligen Plattformen, für welche sie erstellt werden. Beispielsweise könnten dies CORBA, Java oder.net sein. In einem letzten Schritt kommt es schließlich zur Generierung des Source-Codes von den PSM s. Da dieser Schritt nicht zu dem modellgetriebenen Ansatz der MDA zählen würde, wird die Codegenerierung mittels eines Modells welches die Beschreibung der

8 2. Model Driven Architecture (MDA) 5 Zielplattform beinhaltet durchgeführt (Platform Description Model, PDM) [MiMu03]. Hinzuzufügen ist dabei, dass der gesamte Ablauf in Form von model2model sowie model2code Transformationen stattfindet und schließlich ein ausführbarer Source-Code beziehungsweise ausführbare Anwendungen resultieren. Im Folgenden werden die dafür bereits existierenden OMG-Standards kurz dargestellt. 2.2 Standards Bei der Standardisierung der MDA wurden bereits veröffentlichte Standards der OMG mit eingebracht. Abbildung 2.2 zeigt die Standard-Darstellung der MDA seitens der OMG. Abbildung 2.2: Model Driven Architecture (MDA) [OMGI08a] Wie in Abbildung 2.2 ersichtlich, befinden sich im Kern der MDA wichtige OMG Standards wie UML, Meta Object Facility (MOF) und Common Warehouse Metamodel (CWM). Dabei dient die UML dem Modellieren des Gesamtsystems. Um die

9 2. Model Driven Architecture (MDA) 6 Konstrukte einer Modellierungssprache definieren zu können, ist eine Metamodellierungssprache erforderlich. Für diese Aufgabe wurde von der OMG der Standard MOF spezifiziert. Eine genauere Beschreibung des Konzeptes der Metamodellierung folgt im anschließenden Abschnitt. CWM beinhaltet den gesamten Life-Cycle des Designs, der Implementierung und der Wartung eines Data Warehouse. Anhand dieser Technologien werden die Plattform Independent Models erstellt. Des Weiteren beinhaltet der Kern UML-Profile für verschiedene Plattformen, wie beispielsweise CORBA, JAVA,.NET, WEB-Services, XML Metadata Interchange (XMI) und Extensible Markup Language (XML). Im äußeren Ring befinden sich Dienste, welche prinzipiell in allen Anwendungen vorhanden sind (pervasive services). Schließlich werden anhand der Pfeile nach außen mögliche Einsatzgebiete von der MDA dargestellt, wie beispielsweise im Finanzwesen, in der Fertigungswirtschaft oder im Gesundheitswesen [MiMu03] [OMGI08a]. Wie bereits erwähnt basiert der Ansatz der MDA lediglich auf Transformationen von Modellen. Ein sehr wichtiges Konzept für die Umsetzung dieses Ansatzes ist daher das im folgenden Abschnitt erläuterte Konzept der Metamodellierung. 2.3 Metamodellierung Im Bezug auf die modellgetriebene Softwareentwicklung mit Transformationen und Codegeneratoren ist die Metamodellierung, welche durch Meta Object Facility (MOF) definiert wird, ein äußerst wichtiger Aspekt. In einem Metamodell werden alle möglichen Konstrukte einer Modellierungssprache, wie zum Beispiel die Beziehungen oder die Regeln für das korrekte Modellieren definiert, ohne die konkrete Syntax einer Programmiersprache zu verwenden. Beispielsweise ist auch UML durch MOF definiert. Ziel des MDA Ansatzes ist es, möglichst viel auf der Ebene von Modellen zu beschreiben [Fran05] [MiMu03] [OMGI08a]. Wie in Abbildung 2.3 dargestellt, beschreibt die MOF Architektur ein Metamodell, welches aus vier Metalevels besteht.

10 2. Model Driven Architecture (MDA) 7 Abbildung 2.3: MDA Metalevels [Fran05] Jedes dieser vier Metalevels (M0 - M3) steht dabei in einer Class-Beziehung zu dem jeweiligen höheren Level und in einer Instance-Beziehung zu dem jeweiligen niedrigeren Level. Beispielsweise bedeutet dies, dass ein Element von M0 eine Instanz von einer Klasse aus M1 ist und somit die Klasse aus M1 das Metamodell zu den Instanzen der Elemente von M0 ist. Schließlich ist ein Element von M3 wieder eine Instanz von M3, wodurch sich eine Selbstbeschreibung dieses Metamodells ergibt [Fran05]. Die folgende Abbildung 2.4 dient einer anschaulichen Darstellung und Beschreibung des Prinzips der Metamodellierung anhand eines konkreten Beispiels mit UML. Auf dem untersten Level M0 ist eine Person mit dem Namen John Doe vorzufinden. Diese Person stellt eine Instanz der Klasse PERSON dar, welche auf Level M1 definiert ist. Im Bezug auf UML befinden sich im Level M1 unter anderem Klassendiagramme oder Sequenzdiagramme. Um überhaupt erst die Möglichkeit zu haben Klassendiagramme zu erstellen, ist es erforderlich die Konstrukte der Klassen zu definieren. Solche Konstrukte sind beispielsweise Beziehungen oder Attribute, welche auf der nächst höheren Ebene im Metamodell auf Level M2 beschrieben werden. Auf dieser Ebene ist UML definiert. Um schließlich die Möglichkeit zu haben neue Meta-Modelle zu erstellen, ist

11 2. Model Driven Architecture (MDA) 8 auf dem höchsten Level im Meta-Metamodell, MOF definiert. MOF stellt verschiedene Konstrukte zur Verfügung, anhand welcher Meta-Modelle auf Level M2 erstellt werden können. Aufgrund der selbstbeschreibenden Architektur der Metamodellierung ist bereits dafür gesorgt MOF bei Bedarf erweitern zu können [Fran05] [StVo05]. Abbildung 2.4: Beispiel zur Metamodellierung [StVo05] 2.4 Transformationen (Mappings) Wie im letzten Abschnitt erwähnt, basiert die Entwicklung anhand des MDA Ansatzes auf Modellen und Transformationen (Mappings) die schließlich hin zu ausführbaren Anwendungen beziehungsweise ausführbaren Source-Code führen. Bezüglich der Sprache der Transformationsdefinitionen (Mappingsprache) wird derzeit von der OMG versucht, diese anhand der Spezifikation MOF 2.0 Query/View/Transformations (QVT) allgemein zu standardisieren. Allgemein werden Transformationsregeln immer im Bezug auf eine vorhandene Ausgangssituation und eine gewollte Endsituation erstellt. Durch solche Regeln ist es jedoch

12 2. Model Driven Architecture (MDA) 9 nicht möglich ein allgemeines Konstrukt zu definieren, welches alle möglichen Situationen abdeckt. Daher wurden von der OMG Konstrukte auf der Basis des MOF Metamodells entwickelt, um allgemein gültige Transformationsregeln definieren zu können. In Abbildung 2.5 wird der Zusammenhang der Transformationen mit der Metamodellierung dargestellt. Die untere Hälfte stellt dabei die Bedingung dar. Mithilfe einer Transformation soll ein Source-Modell (beispielsweise PIM) in ein Traget-Modell (beispielsweise PSM) unter Erfüllung der Anforderungen (satisfy Requirements) übergeführt werden. Abbildung 2.5: MDA Transformationen Die obere Hälfte beschreibt den Zusammenhang bezüglich der Entstehung der Transformationen. Die Transformationsdefinitionen werden in einer spezifizierten Transformationssprache geschrieben. Des Weiteren verwendet die Transformationsdefinition die beiden Metamodelle des Source- und des Target-Modells. Grund dafür ist, wie zuvor bei der Metamodellierung beschrieben, dass in den Metamodellen die Konstrukte der zu Grunde liegenden Modelle definiert sind und diese somit Informationen enthalten, welche zur Konstruktion der Transformationsdefinitionen erforderlich sind [Muke01] [MiMu03].

13 3 xuml - Executable UML xuml ist eine Sprache aus der Familie der UML Sprachen, welche die Zusammenhänge in UML semantisch beschreibt und unter Anderem die in Abbildung 3.1 dargestellten und im folgenden aufgelisteten Modellelemente beinhaltet [Graw02, Rump02]: Sequence - Diagramme Interaktion zwischen Use Case - Objekten, Kontrollfluss Class - Diagramme Statische Struktur von von xuml Objekten State Chart - Diagramme Behaviorale Aspekte von Objekten einer Klasse OCL Constraints Regeln, Werteinschränkungen, etc (siehe 3.1) Use Case - Diagramme (nicht in Abbildung 3.1 dargestellt) Beschreibung von Anforderungen in einer frühen Phase der Entwicklung Collaboration - Diagramme (nicht in Abbildung 3.1 dargestellt) Interaktion zwischen Objekten mittels Messages Das Ziel der Entwickler von xuml ist die einfache Erzeugung von Programmen in einer höheren Abstraktionsebene, welche sowohl spezifische Programmiersprachen als auch Softwareorganisation beschreiben soll. Ein xuml - Modell beinhaltet Strukturen zur 10

14 3. xuml 11 Abbildung 3.1: Modellelemente von xuml Object- und Testcode [Rump02] Verwaltung von Daten, Kontrollelementen und Algorithmen, trifft jedoch keine Entscheidungen bezüglich Implementierung, Task Strukturen, Distribution und Kapselungen [Mell02]. Was von xuml beschrieben wird, sind Daten und Verhalten, organisiert durch Klassen. Somit befindet sich der Entwickler scheinbar auf einer höheren Ebene der Abstraktion, da er nur mit Daten und Verhalten direkt konfrontiert ist. Um ein solches Modell ausführbar zu machen ist ein Modell - Compiler notwendig. Der Compiler zielt nun auf eine spezifische Implementierung bezüglich Task Strukturen, Distribution, Datenstrukturen und die Programmiersprache ab [Mell02]. 3.1 OCL - Object Constraint Language OCL ist eine formale Sprache die es ermöglicht, Spezifikationen, die in UML nicht vorgenommen werden können, durchzuführen. Um zu garantieren, dass OCL eine reine Spezifikationssprache ohne Seiteneffekte ist, wurde gewährleistet, dass die Evaluierung eines OCL Ausdruckes einen Wert zurückliefern muss, im UML Modell selbst jedoch nichts ändern kann. Da OCL in erster Linie eine Modelliersprache ist können OCL - Ausdrücke per Definition nicht direkt ausgeführt werden. Weiters wird eine Evaluierung eines OCL Ausdruckes mit sofortiger Wirkung durchgeführt, was bedeutet, dass sich

15 3. xuml 12 die States eines Objektes während der Durchführung einer Evaluierung nicht ändern können [OMGI03]. Weiters dient die OCL in xuml unter anderem der Eliminierung von Mehrdeutigkeiten. 3.2 xuml - Vorteile und Nachteile Die Ausführbarkeit von Spezifikationen oder eines spezifizierten Modells bringt Vorund Nachteile mit sich. Als der wichtigste Vorteil von xuml wird die Abstraktionsebene, auf der sich der Programmierer befinden soll, prolongiert. Leider kann xuml jedoch die Komplexität von Applikationen nicht verbergen (siehe Kapitel 3.1) und befindet sich somit objektiv betrachtet nicht auf einer höheren Abstraktionsebene, sondern schafft es lediglich Programmcode graphisch darzustellen. Probleme mit xuml können auftreten, wenn es um die Effizienz einer Applikation geht, da der Source Code und damit auch der Kontrollfluss nicht mehr manuell, sondern zum Großteil vom xuml - Compiler erzeugt wird. Des Weiteren wird die Programmierung von komplizierten Algorithmen, wie zum Beispiel die Implementierung eines Sortieralgorithmus erschwert und oft unlesbar [Rump02]. Ein Grund hierfür ist die Verwendung von Sequenzdiagrammen, welche eigentlich ein Relikt aus den 80er Jahren sind und im Zusammenhang mit der MDA eine Renaissance erleben. Diese Diagramme dienen der Darstellung von Kontrollfluss und Ablauf einer Applikation. Leider nehmen Sequenzdiagramme aber bereits bei sehr kleinen Applikationen enorme Ausmaße an und sind somit für große Applikationen offensichtlich ungeeignet.

16 4 Beispiele zur Anwendung der MDA In diesem Kapitel wird die Implementierung eines Counters in xuml mit Fujaba dargestellt. Der Counter soll in der Lage sein, zwischen geraden und ungeraden Integer - Werten zu unterscheiden und diese auf der Konsole auszugeben. 4.1 Fujaba Fujaba ist ein Akronym für From UML to Java And Back Again und dient als Entwicklungsumgebung für den Entwurf von xuml Modellen. Fujaba ist vollständig in Java implementiert und kann, da ein Platform - Independend - Model fehlt, auch nur Java Source - Code generieren. Somit stellt Fujaba nur einen Teil der MDA - Funktionalität zur Verfügung. Weitere Informationen über Fujaba können unter [Fuja07] und [Klen99] eingesehen werden. Ein in Fujaba entwickeltes Applikationsmodell besteht aus Klassen- und Story- beziehungsweise Activity - Diagrammen, wobei jede Methode einer Klasse durch ein Story - Diagramm implementiert werden muss. Diese Diagramme werden nun anhand eines einfachen Beispiels erläutert: In Abbildung 4.1 wird ein Klassendiagramm mit zwei Klassen dargestellt. Links befindet sich die Klasse MainClass, welche über die Methode main() und die Variable var 13

17 4. Beispiele zur Anwendung der MDA 14 Abbildung 4.1: Fujaba - Klassendiagramm für die Klassen MainClass und Counter verfügt. Die main() Methode wird in Abbildung 4.3 als Activity - Diagramm dargestellt. Die Klasse Counter besteht aus einer Methode mit Namen inc() und der Variablen countvar. Die beiden Klassen sind durch die [1..1] Assoziation uses verknüpft. Abbildung 4.2: Activity - Diagramm für die Counter - Methode inc() Die Funktionen main() und inc() werden mittels Activity - Diagrammen erzeugt und verfügen über verschiedene States. Jede Funktion verfügt über eine Start - und eine Stop - Activity. Die Start - Activity stellt die Funktionsdeklaration dar, die Stop - Activity bezeichnet das Ende beziehungsweise den Return - Wert der Funktion. In beiden Activity - Diagrammen kommt eine so genannte NOP Activity ( No Operation Activity ) zum Einsatz, welche mit einem Bool schen Ausdruck und einer Else - Verknüpfung ausgestattet ist. Diese NOP Activities werden vom Model - Compiler frei interpretiert,

18 4. Beispiele zur Anwendung der MDA 15 das heißt, sie werden in ein passendes Kontrollflusselement umgewandelt. So wird das NOP Element in Abbildung 4.3 für die inc() Methode durch eine WHILE - Schleife ersetzt, das NOP Element in Abbildung 4.2 für die main() Methode durch eine passende IF - Verzweigung aufgelöst. Weiters verfügt die main() - Methode über zwei so genannte Storyboards, die in Abbildung 4.3 mit den Nummern 1 und 2 gekennzeichnet sind. Im Storyboard mit der Nummer 1 wird die Klasse Counter initialisiert. Im Storyboard mit Nummer 2 wird der Variablen var der Rückgabewert der Funktion inc() zugewiesen. Das NOP - Element der Methode ist mit dem Bool schen Ausdruck [var == 5] versehen, welches das Programm zur Terminierung führt, wenn der maximale Wert der Variablen var, in diesem Fall 10, erreicht wird. Die in Abbildung 4.2 dargestellte Methode inc() verfügt über Statements, welche die Variable countvar erhöhen und die Strings EVEN beziehungsweise ODD auf die Konsole ausgeben wenn der Wert der Variablen countvar eine gerade beziehungsweise ungerade Zahl ist. Abbildung 4.3: Activity - Diagramm für die MainClass - Methode main() Der von Fujaba generierte Source Code der beiden Funktionen wird in Anhang A dargestellt.

19 5 Zusammenfassung Durch den Ansatz der MDA ist es möglich den Zeit- und Kostenfaktor einer Entwicklung zu reduzieren sowie auch den Grad der Widerverwendbarkeit von vorhandenen Lösungen zu steigern. Des Weiteren wird die Langlebigkeit von Softwarelösungen gesteigert, da es aufgrund der vorhandenen Plattform unabhängigen Modellen (PIM) rasch möglich ist die vorhandene Lösung an neue Technologien anzupassen. Zusätzlich kann mit diesem Ansatz auch gut auf sich ändernde Anforderungen seitens des Auftraggebers reagiert werden, da es lediglich nötig ist die Anforderungen im CIM anzupassen und die nachfolgenden Modelle (PIM, PSM) erneut zu transformieren. Durch die Modellierung des zu realisierenden Softwaresystems auf unterschiedlichen Abstraktionslevels ist es möglich diese Modelle für die Kommunikation mit dem Auftraggeber zu nutzen. So kann beispielsweise die Vollständigkeit der Funktionalitäten anhand des PIM mit dem Auftraggeber abgesprochen werden. Durch das Generieren des Source-Codes durch Transformationen ist zusätzlich zur Zeitreduktion noch der Vorteil zu erwähnen, dass die Qualität des generierten Codes höher ist als von Source- Code der manuell erzeugt wird. Jedoch hat der Ansatz der MDA nicht nur Vorteile und somit werden nachfolgend einige Nachteile beschrieben. Derzeit befindet sich MDA noch in der Entwicklung und wie bereits erwähnt wird bezüglich der Definition und Sprache für die Transformationen noch nach einer standardisierbaren Lösung gesucht. Aus diesem Grund realisieren derzeitige MDA-Tools lediglich einen Bruchteil der Funktionalitäten welche die MDA 16

20 5. Zusammenfassung 17 spezifiziert. So ist beispielsweise nicht der gesamte Ablauf vom CIM bis hin zum Code enthalten oder die Codegeneration funktioniert nur semiautomatisch. Dies bedeutet, dass nur die Gerüste (Skeletons) der Modelle erzeugt werden, jedoch die eigentliche Logik der Anwendungen anschließend von einem Programmierer manuell implementiert werden muss. Wie im Beispiel zu sehen war ist die Programmierung mit xuml und im speziellen mit Fujaba mit erheblichem Aufwand verbunden der beim gezeigten Beispiel in keiner Relation zur Komplexität der erzeugten Applikation steht. Bei etwas komplexeren Applikationen ist somit für ungeübte Benutzer von der Verwendung von Fujaba abzuraten, wenn der Faktor Zeit eine wichtige Rolle spielt. Der erzeugte Code ist generell in Ordnung, beinhaltet jedoch zu viele Fujaba - proprietäre Statements. Die Frage, ob xuml auf einem anderen Level der Abstraktion operiert ist unseren Erfahrungen nach mit einem eindeutigen NEIN zu beantworten, da die Komplexität einer Anwendung in keinem Fall versteckt werden kann. Genau das Gegenteil ist bis dato der Fall, die Komplexität steigt durch die Verbindung von unüberschaubaren Sequenzdiagrammen, den darin enthaltenen Story - und Code - Elementen. Weiters muss die Frage xuml, just another OO Language? zum jetzigen Zeitpunkt mit JA beantwortet werden, da zum jetzigen Zeitpunkt xuml nur eine graphische Darstellung von Source - Code beinhaltet und wichtige Konzepte der MDA wie beispielsweise das PIM noch keine Verwendung finden können.

21 Literaturverzeichnis [Fran05] [Fuja07] [Graw02] [Klen99] [Mell02] Frankel, D.S.: Model Driven Architecture: Applying MDA to Enterprise Computing. Wiley Publishing Inc., Indianapolis, Fujaba Tool Suite Developer Team, University of Paderborn Software Engineering Group: Fujaba is a public domain Case Tool for UML. http: // Juli Graw, G. und Herrmann,P.: Verification of xuml Specifications in the context of MDA. Participant Proceedings of the Workshop in Software Model Engineering (WISME@UML 2002), Oktober Klen, T. et al.: From UML to Java And Back Again. Technischer Bericht trri , University of Paderborn, Paderborn, Germany, September Mellor, S.J. und Balcer, M.J.: Executable UML - A Foundation For Model- Driven-Architecture. Addison-Wesley, Munich, [MiMu03] Miller, J. und Mukerji, J.: MDA Guide version org/docs/omg/ pdf, [Muke01] Mukerji, J.: Model Driven Architecture (MDA). docs/ormsc/ pdf, [OMGI03] Object Management Group, Inc.: UML 2.0 OCL Specification [OMGI08a] Object Management Group, Inc.: OMG Meta Object Facility

22 Literaturverzeichnis 19 [OMGI08b] Object Management Group, Inc.: OMG Model Driven Architecture. http: // [OMGI08c] Object Management Group, Inc.: Unified Modeling Language [Rump02] Rumpe, B.: Executable Modeling With UML - A vision or a Nightmare? Issues & Trends of Information Technology Management in Contemporary Associations, Seiten , [Sole00] [StVo05] Soley, R.: Model Driven Architecture. ftp://ftp.omg.org/pub/docs/omg/ pdf, Stahl, T. und Völter, M.: Modellgetriebene Softwareentwicklung: Techniken, Engineering, Management. dpunkt.verlag, Heidelberg, 2005.

23 Abkürzungsverzeichnis CIM CWM Computation Independent Model Common Warehouse Metamodel Fujaba From UML to Java and back again MDA MDSD MOF Model Driven Architecture Model Driven Software Development Meta Object Facility NOP No Object OMG OCL PDM PIM PSM Objekt Management Group Object Constraint Language Platform Description Model Platform Independent Model Platform Specific Model QVT Query/View/Transformations UML XMI XML xuml Unified Modelling Language XML Metadata Interchange Extensible Markup Language Executable Unified Modelling Language 20

24 Anhang 21

25 A Methoden A.1 main() /** * UMLMethod : + main (): Void. */ public void main () { Counter counter = null ; boolean fujaba Success = false ; Object fujaba TmpObject = null ; try { fujaba Success = false ; // create object counter = new Counter (); // create link this. setcounter ( counter ); fujaba Success = true ; } catch ( JavaSDMException fujaba InternalException ) { fujaba Success = false ; } // try catch do { try { fujaba Success = false ; // bind counter : Counter 22

26 A. Methoden 23 counter = this. getcounter (); JavaSDM. ensure ( counter!= null ); } // 1 var = counter. inc (); fujaba Success = true ; } catch ( JavaSDMException fujaba InternalException ) { fujaba Success = false ; } // try catch } while (!( this. var == 10) ); return; A.2 inc() /** * UMLMethod : + inc (): Integer. */ public int inc () { // Statement this. countvar = this. countvar + 1; System. out. println ( this. countvar ); if (( this. countvar % 2) == 0) { System. out. println (" EVEN "); return this. countvar ; } else { System. out. println (" ODD "); return this. countvar ; } }