Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven...

31
Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA Stuttgart Außenstelle Horb Florianstr. 6 72160 Horb a.N. [email protected] [email protected] [email protected] [email protected]

Transcript of Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven...

Page 1: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein

Informationstechnik BA Stuttgart Außenstelle Horb

Florianstr. 6 72160 Horb a.N.

[email protected] [email protected] [email protected] [email protected]

Page 2: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Abstract

Within the scope of the lecture “Software Engineering III”, in the fifth term of the study course “computer science”, there was the assignment to show the draughts and basic technologies of Model Driven Development and Model Driven Architecture. Furthermore, a prototype should be developed with the tool objectiF by Microtool. The project team consists of four students and is looked after by Mr. Prof. Dr. phil. A. van Hoof.

The elaboration sets goals at the debate of the matter of Model Driven Development and Model Driven Architecture as well as showing and clarifying its properties.

Initially, the intention of Model Driven Development and Model Driven Architecture is discussed. In consideration of this the definitions of Model Driven Development and Model Driven Architecture are being displayed. The analysis of these two software development strategies demonstrates the differences as well as the advantages and disadvantages of Model Driven Development and Model Driven Architecture.

Due to the fact that „Model Driven Development“ and „Model Driven Architecture” build on UML 2.0, the types of diagram and their perception are described and shortly defined.

The category "Tools" gives a general idea of possible tools of software development using Model Driven Development and Model Driven Architecture.

Finally, an example prototype on the basis of an Inline Skate clarifies the implementation of Model Driven Development and Model Driven Architecture. According to the conceptual formulation the prototype was designed with objectiF,.

According to the requirement of the exercise by using objectiF the prototyp was constructed. It is the target of the prototype to assemble an individual inline-skate from a collection of different components. But not every alternative can be combined with the variation of another component.

Page 3: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Inhalt Model Driven Architecture/Model Driven Development ................................................. 1 

Abstract ............................................................................................................................. 2 

1.  Einführung ................................................................................................................ 5 

1.1  Intention Model Driven Architecture .............................................................. 5 

1.2  Intention Model Driven Development ............................................................. 5 

1.3  Definition MDD – Model Driven Development .............................................. 6 

1.4  Entwicklung von MDA – Model Driven Architecture .................................... 7 

1.5  Definition MDA – Model Driven Architecture ............................................... 8 

2  Analyse ..................................................................................................................... 9 

2.1  Unterschiede MDA / MDD ............................................................................. 9 

2.2  Vorteile / Nachteile MDD ............................................................................. 10 

2.3  Analyse von MDD ......................................................................................... 10 

2.3.1  Wartbarkeit von Modellen ............................................................................. 10 

2.3.2  Modell Ausführbarkeit .................................................................................. 11 

2.3.3  Effizienz des generierten Codes .................................................................... 11 

2.3.4  Fazit ............................................................................................................... 12 

2.4  Vorteile / Nachteile MDA ............................................................................. 13 

2.5  Darstellung UML Diagramm Gattungen ....................................................... 13 

3  Tools ....................................................................................................................... 17 

3.1  Überblick ....................................................................................................... 17 

3.1.1  OpenSource Produkte .................................................................................... 17 

3.1.2  Kommerzielle Produkte ................................................................................. 19 

3.2  ObjectIF ......................................................................................................... 20 

3.2.1  Benutzerfreundlichkeit .................................................................................. 21 

Page 4: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

4  Prototyp ................................................................................................................... 24 

4.1  Funktionsweise .............................................................................................. 25 

Use-Case-Diagramm ............................................................................................... 25 

Aktivitätsdiagramm ................................................................................................. 26 

Paketdiagramm ....................................................................................................... 27 

Klassendiagramm .................................................................................................... 29 

Literaturverzeichnis ........................................................................................................ 31 

Abbildungsverzeichnis .................................................................................................... 31 

Tabellenverzeichnis ........................................................................................................ 31 

Page 5: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

1. Einführung

Im Kapitel Einführung wird die Intention von Model Driven Architecture und Model Driven Development beschrieben und somit dargestellt welcher Gedanke hinter diesem Thema liegt. Des Weiteren werden die Begriffe Model Driven Architecture, deren Entwicklung und Model Driven Development durch eine Definition beschrieben und näher erläutert.

1.1 Intention Model Driven Architecture

Die Object Management Group, kurz OMG, versucht den Ansatz der generativen Softwareentwicklung seit geraumer Zeit durch die Standardisierung zu etablieren. Mit der Entwicklung der Model Driven Architecture, kurz MDA, sollen Voraussetzungen geschaffen werden, die zu einer Vereinheitlichung der derzeit sehr heterogenen Prozess- und Werkzeuglandschaft führen. Diese Entwicklung soll ähnlich zur Entwicklung der UML verlaufen, die sich zu Beginn der 1990er-Jahre ebenfalls aus vielen heterogenen Ansätzen entwickelt hat und momentan Industriestandard ist.

Das Erstellen von Programmtext soll bei MDA im Hintergrund stehen. Stattdessen soll viel größerer Wert auf die früheren Phasen der Softwareentwicklung gelegt werden. Die fachlichen Details eines im Programm umzusetzenden Problems sollen mehr Bedeutung erhalten und grafisch, annähernd vollständig in UML 2.0 visualisiert werden. Mit dieser Visualisierung soll es Möglich sein mit Hilfe von Generatoren, Programmcode zu erzeugen. Dies ist die Vision des MDA Standards. [ZEW06]

1.2 Intention Model Driven Development

Die Idee von Model Driven Development, kurz MDD, ist es, dass nur noch wenig bis gar keinen Code mehr geschrieben werden muss, sondern nur noch Modelle entwickelt und daraus die Software generiert. Viele Teile einer Software sollen so modellgetrieben und plattformunabhängig entwickelt werden um anschließend aus der Modellierung des Problems automatisiert den Code zu generieren.

MDD trifft gegenüber von MDA zusätzlich Aussagen über die einzelnen Prozessbausteine und gibt an wie das Problem strukturiert gelöst werden kann.

Die Modelle, welche während eines Softwareentwicklungsprozesses entwickelt werden, sollen für künftige Probleme wieder verwendet werden können. Diese Idee kennt man aus anderen Ingenieursberufen, wie dem Baugewerbe. Dort werden zum Beispiel vor dem Bau einer Brücke ebenfalls auch zuerst Modelle und Zeichnungen gemacht, um so zu testen ob und wie das Problem lösbar ist. [SEB03]

Page 6: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

1.3 Definition MDD – Model Driven Development

Model Driven Development (MDD) ist dadurch definiert, dass das primäre Ziel und Ergebnis von MDD Modelle eines Programms sind. Dies bedeutet, dass nur Modelle entwickelt werden und keine Zeilen Code geschrieben werden. Bei der Entwicklung der Modelle wird keine Programmiersprache festgelegt in der die spätere Implementierung stattfinden soll. Deshalb sind die Modelle völlig unabhängig von der späteren Plattform auf der die Software später lauffähig sein soll.

Der größte Vorteil von MDD ist, dass das Problem, welches gelöst werden soll, durch Modelle ausgedrückt wird und man somit viel näher am Problem ist als an der darunter liegenden Implementierung. Dies macht die Modelle des Problems einfacher zu definieren, zu verstehen und zu warten. Somit wird auch gewährleistet, dass ein Nicht-Entwickler mit an der Lösung eines Problems mitarbeiten kann, ohne jegliche Programmierkenntnisse zu besitzen.

Diese Entwicklung von Modellen macht sie unempfindlicher gegenüber der Plattform, auf welcher sie implementiert werden sollen. Wenn die Modelle allerdings nur zur Dokumentation dienen, dann sind sie von geringem Wert, weil Dokumentationen relativ schnell veraltet sind und in einer Dokumentenablage verschwinden.

Ein Schlüsselgedanke hinter MDD ist es, dass aus den Modellen des Problems direkt der Code zur Lösung des Problems generiert werden soll und keine bis wenige Zeilen Code selbst geschrieben werden sollen.

Die Modelle, welche abgebildet werden sollen, gliedern sich in zwei Gruppen:

• Fachliches Modell - Modelle welche die reale Welt abbilden, also zum Beispiel ein Produktionsablauf

• Technisches Modell - Modelle welche das Problem mittels Objekten, Klassen und Funktionen abbilden

[WIKI07]

Page 7: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

1.4 Entwicklung von MDA – Model Driven Architecture

In einer Analyse des Standes der Softwareentwicklung vor Einführung der ‚Model Driven Architecture‘, kurz MDA, beschreibt die Object Managment Group, kurz OMG, die Situation wie folgt:

„The myth of the standalone application, never needing repair, never needing integration, with data models inviolate and secret, died a long and painful death through the end oft he Twentieth Century“ [OMG03]

Dieses Zitat zielt nicht nur auf den Kosten- und Leistungsdruck ab, unter dem die Softwareentwicklung von heute steht, sondern betont auch die Pflege und Wartung von Projekten und die Notwendigkeit der Anpassung von Datenmodellen. Bereits das Dijkstra Verfahren „separation of concerns“, welches komplexe System in Teilsysteme zerlegt und jeweils in einzelne Teilfunktionen des Gesamtsystems abdecken zieht sich durch die Softwareentwicklungs-Geschichte wie ein roter Faden. Auch OMG greift dieses Prinzip auf und möchte mit der MDA folgende Verbesserungen bei der Softwareentwicklung erreichen:

„This is the promise of Model Driven Architecture: to allow definition of machine-readable application and data models which allow long-term flexibility of:

• Implementation: new implementation infrastructure can be integrated or targeted by existing designs,

• Integration: since not only the implementation but the design exists at time of integration, we can automate the production of data integration bridges and the connection to new integration infrastructures,

• Mainentance: the availability oft he design in a machine-readable form gives developers direct access tot he specification of the system, making maintenance much simpler,

• Testing and simulation: since the developed models can be used to generate code, they can equally be validated against requirements, tested against varoius infrastructures and can be used directly to simule the behaviour of the system beeing designed“ [OMG03]

Aus diesem Zitat der OMG wird deutlich, dass es sich bei der MDA um eine Vorgehensweise zur effizienten Softwaresystementwicklung handelt. Die Spezifikation von Anwendungen und Datenstrukturen in maschinenlesbarer Form soll alle Schritte der Softwareentwicklung von der Implementierung über die Integration bis hin zu Wartung und zum Testen unterstützen und somit den gesamten Prozess als eine zusammengehörende Einheit betrachten. Hierzu greift die MDA auf die bereits bekannte und bewährte Idee der Trennung zwischen der fachlichen Logik und der technologischen Umsetzung zurück.

Page 8: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Zusammengefasst, stellt die MDA keine absolut neue und alle Probleme lösende Vorgehensweise dar, sondern vereint vielmehr eine Reihe von vorhandenen Methoden und führt somit zu einer Standardisierung von Konzepten für die Entwicklung von Softwaresystemen. [ZEW06]

1.5 Definition MDA – Model Driven Architecture

Die ‚Model Driven Architecture‘ kurz MDA setzt sich zum Ziel einen anerkannten Standard für die modellgetriebene Softwareentwicklung zu definieren. MDA verwendet dabei Modelle und Generatoren zur Verbesserung der Softwareentwicklung. Plattformunabhängigkeit und Interoperabilität von Metamodellen definieren den Schwerpunkt dieser Ziele. Durch Transformation eines Metamodells wird die Interoperabilität erreicht.

Die vorerst theoretische Vorgehensweise soll es ermöglichen, Software größtenteils automatisch aus abstrakten Modellen zu erzeugen.

Bei MDA ist keine hundertprozentige Automatisierung angestrebt, sondern ein sinnvoller Anteil. Dieser variiert je nach fachlicher Anforderung zwischen 20 und 80 Prozent. Da die Architektur eines Systems vollständig manuell erzeugt wird, ist MDA hochgradig flexibel und gewährt im Gegensatz zum CASE-Ansatz die vollständige Kontrolle während des Entwicklungsprozesses. [ZEW06]

Page 9: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

2 Analyse

Im Kapitel Analyse werden zuerst die Unterschiede zwischen Model Driven Architecture und Model Driven Development erläutert. Anschließend werden Model Driven Architecture und Model Driven Development analysiert. Es werden die Vor- und Nachteile von beidem erläutert und einzelne Elemente, wie die Wartbarkeit von Modellen, näher betrachtet.

2.1 Unterschiede MDA / MDD

Bei MDD liegen die Schwerpunkte auf der Entwicklung von plattformunabhängigen Modellen. Mit Hilfe dieser Modelle wir der Gegenstandsbereich abgebildet und durch die Generierung in die fertige Software überführt. Getreu dem Motto “Ein Bild sagt mehr als tausend Worte” werden bei der Modellierung vorwiegend grafische Notationen benutzt.

Die MDD ist gewissermaßen eine Zusammenfassung der MDA und trifft zusätzlich Aussagen über Prozessbausteine und Best Practices in den Bereichen Technik, Engineering und Management. Ein wesentlicher Eckpfeiler ist im Gegensatz zur MDA der Plattformbegriff (Wiederverwendung existierender Frameworks, Komponenten etc. zur Reduzierung der Komplexität). Letztendlich betrachtet die MDD viel stärker den Entwicklungsprozess.

In Bezug auf MDA sind die Hauptmotivationen der OMG Interoperabilität (also Herstellerunabhängigkeit durch Standardisierung) und Portabilität bzw. Plattformunabhängigkeit von Softwaresystemen. Dabei fordert die OMG die Spezifizierung von der Implementierung auf einer gegebenen Plattform zu trennen. Eine weitere Besonderheit ist die Zielvorstellung von ausführbaren Modellen. MDA verwendet außerdem Model Object Facility, kurz MOF als Metamodell, wobei eine domänenspezifische Programmiersprache wiederum auf Basis der MOF definiert werden soll. Konkret regt die MDA die Verwendung von UML-Profilen in diesem Zusammenhang an. [WIKI07]; [ZEW06]

Page 10: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

2.2 Vorteile / Nachteile MDD

Die Vor- und Nachteile von Model Driven Development sind bei der Wahl der Entwicklungsstrategie für eine Software gegeneinander abzuwägen.

Vorteile MDD

• Automatische generieren von Programmen aus Modellen

• Automatischen Verifizieren der Funktionalität von Programmen

• Modelle sind auch von für Nicht-Entwickler verständlich

Nachteile MDD

• Minderwertige Codequalität

• Schwieriges Nachvollziehen des Codes

[SEB03]

2.3 Analyse von MDD

2.3.1 Wartbarkeit von Modellen

Es kommt oft vor, dass der generierte Code durch interne Optimierungsverfahren nicht einfach gegenüber dem Modell nachzuvollziehen ist und deswegen für den Menschen, also für einen Softwareentwickler, schwer verständlich ist.

Deswegen ist es schwierig, wenn der automatisch generierte Code, trotz der korrekten Modellierung, von Fehlern behaftet ist diese zu diagnostizieren und zu lokalisieren um diese anschließend manuell beheben zu können.

Somit kommt es zu fehlerhaften Programmen, welche natürlich auch nicht ausführbar sind. Die Softwareentwickler müssen bei solch auftretenden Fehlern zuerst manuell die automatisch generierte Implementierung debuggen um die Fehler zu lokalisieren. Erst wenn die Lokalisierung der Fehler stattgefunden hat können die Fehler manuell behoben werden.

Die Behebung dieser Fehler gestaltet sich oft schwierig, da durch die internen Optimierungsverfahren welche durchgeführt wurden, die Fehler und deren Ursachen nicht einfach zu finden und zu beheben sind. Deswegen kommt es oft vor, dass die Softwareentwickler bei der nächsten Programmentwicklung wieder ohne Model Driven Development Werkzeuge entwickeln. [SEB03]

Page 11: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

2.3.2 Modell Ausführbarkeit

Die Ausführbarkeit von Modellen soll zu jeder Zeit der Modellierung der Software möglich sein. Dies bedeutet, dass es jederzeit möglich sein sollte das bisher entworfene Modell auszuführen.

Hiermit soll es den Programmentwicklern ermöglicht werden, bereits im Anfangsstadium der Entwicklung die ersten Ansätze ihrer Modelle auf ihre Funktionalität hin zu überprüfen. Daraus resultiert, dass das Modell in eine Programmiersprache überführt werden soll um anschließend das erstellte Programm schrittweise manuell auszuführen und automatisch ausführen zu lassen.

Die Ausführung des Programms, sollte auf einer Testplattform oder auf einer Plattform auf der das Programm später eingesetzt werden soll stattfinden. Die beste Lösung zum Testen eines bisher entworfenen Modell, beziehungsweise dessen Implementierung ist es, wenn man eine Kombination von beidem wählt. Mit einer Kombination aus beidem, also dem Testen auf einer Testplattform und auf einer späteren Einsatzplattform, können somit mehrere Testszenarien abgedeckt werden. Mit dieser Möglichkeit kann bereits in eine frühen Stadium der Entwicklung mögliche Fehler und ihre Ursachen entdeckt werden. [SEB03]

2.3.3 Effizienz des generierten Codes

Die Effizienz des generierten Codes kann positive wie auch negative Einwirkungen auf die Funktionalität der zu entwickelnden Software haben.

Die internen Optimierungsverfahren des automatischen Codeerzeugers des jeweiligen Model Driven Development Tools können dazu führen, dass der generierte Code ein Musterbeispiel an Programmierkunst darstellt. Somit kann der generierte Code viel effizienter sein, als wenn ein Softwareentwickler das Programm manuell entwickelt hätte.

Allerdings kann ein Softwareentwickler auch durch seine Erfahrungen, welche er über Jahre gesammelt hat, viele Dinge eventuell manuell besser Implementieren als der automatische Codeerzeuger des Model Driven Development Werkzeugs.

Bei der Effizienz des automatisch erzeugten Codes muss eventuell bei wichtigen Funktionen und Klassen ein Vergleich vorgenommen werden, welche dieser beiden Varianten besser sein könnte. [SEB03]

Page 12: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

2.3.4 Fazit

Mit Model Driven Development trifft man eine gute Wahl einer Entwicklungsstrategie. Dies bringt mit sich das die entwickelten Modelle oder auch nur Teile davon in anderen Problemlösungen wieder verwendet werden können.

Somit ist es möglich zukünftige Entwicklungen schneller zum Ziel zu führen und einen schnelleren Abschluss des Projektes zu gewährleisten. Um dies zu gewährleisten muss eine sorgfältige Auswahl des Model Driven Development Werkzeugs erfolgen.

Bei der Auswahl des Model Driven Development Werkzeuges sollte darauf geachtet werden, dass es verschiedene Komponenten umfasst.

Sinnvolle Komponenten, welches ein Model Driven Development Werkzeug beinhalten sollte sind:

• Verschiedene Compiler

• Debugger

• Code Analysatoren

• Softwareversionierungssystem

Vor allem der letzte Punkt, Softwareversionierungssystem, ist ein wichtiges Kriterium bei der Auswahl eines Model Driven Development Werkzeugs. Ohne solch ein System ist heutzutage, in dem mehrer Softwareprogrammierer an einem Projekt arbeiten, kaum mehr eine Entwicklung möglich. Deshalb sollte es nicht erforderlich sein solch ein System speziell anzuschaffen.

Ein weiteres wichtiges Kriterium ist das Model Driven Development Werkzeug gleich “out-of-the-box“ funktioniert. Dies bedeutet, dass es nach der Installation ohne jegliches Customizing einsetzbar sein sollte.

Wenn alle diese Kriterien bei der Auswahl eines Model Driven Development Werkzeugs berücksichtigt werden, steht dem Model Driven Development an sich nichts mehr im Wege. [SEB03]

Page 13: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

2.4 Vorteile / Nachteile MDA

Die Vorteile der Abstraktion und der Entwicklung technologieneutraler Anwendungsmodelle liegen dabei auf der Hand:

• Das in den Modellen enthaltene Fachwissen kann über lange Zeiträume festgehalten werden

• Bei einem technologiebedingten Plattformwechsel kann immer wieder auf dasselbe fachliche Modell zurückgegriffen bzw. kann dasselbe Modell auf verschiedensten Plattformen umgesetzt werden.

Auch der generative Ansatz der Softwareentwicklung weist einige Stärken auf:

• Die Modellierung ist rein fachlich und somit entkoppelt von technologie-abhängigen und werkzeugspezifischen Aspekten

• Generatoren befolgen immer gleiche Regeln für die Abarbeitung gleichartiger Problemstellungen, so dass der produzierte Quelltext einfacher zu testen, pflegen und zu warten ist, da er durchgängig gleiche Bezeichnungen verwendet

• Standardaufgaben können durch ausreichende formale Modellierung automatisiert werden, so dass der entsprechende zugehörige Quelltext generiert werden kann.

• Alle fachlichen Änderungen werden im Modell vorgenommen, so dass das aufwändige Nachverfolgen einzelner Programmzeilen auf ein Minimum reduziert wird

[WIKI07]; [ZEW06]

2.5 Darstellung UML Diagramm Gattungen

Die Unified Modelling Language, kurz UML, ist eine formale Sprache, mit deren Hilfe alle Arten von Systemen, so auch Systeme außerhalb des informationstechnischen Bereichs spezifiziert, modelliert, visualisiert und dokumentiert werden können. Dabei ist die Modellierung frei von jeder technikabhängigen Spezifikation und dient dazu, die fachliche Leistungsfähigkeit und die Funktionalität des Systems zu beschreiben. Sie kommt daher in der objektorientierten Softwareentwicklung vor allem in der Analyse und im Design zum Einsatz. Das fertige Modell wird durch Generatoren und Programmierer umgesetzt und kann im Anschluss dazu genutzt werden, das erstellte System auf Vollständigkeit und Richtigkeit zu überprüfen.

Page 14: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Für MDA und MDD wird UML 2.0 als Standard verwendet. Die UML 2.0 umfasst zwei unterschiedliche Arten von Modellen:

• Modelle, welche die Systemstruktur bzw. die Statik des Systems präsentieren (statische Modelle, Strukturdiagramme) und

• Modelle, die das Verhalten des zu realisierenden Systems darstellen (dynamische Modelle, Verhaltensdiagramme)

Für die Abbildung der Modelle bietet die UML 2.0 insgesamt 13 unterschiedliche Diagramme an, welche jeweils eine eigene Sichtweise auf die Gesamtlösung des Systems repräsentieren. [ZEW06]

Abbildung 1: Die Diagrammarten von UML 2.0 [ZEW06]

UML 2.0 Diagramme

statisch dynamisch

Klassendiagramm

Objektdiagramm

Paketdiagramm

Kompositionsstruktur-diagramm

Implementierungs-diagramme

Komponentendiagramm

Verteilungsdiagramm

Geschäftsprozessdiagramm

Verhaltensdiagramme

Zustandsdiagramm

Aktivitätsdiagramm

Interaktionsdiagramme

Sequenzdiagramme

Kommunikations-diagramme

Timingdiagramme

Interaktionsübersichts-

diagramme

Page 15: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

In der objektorientierten Softwareentwicklung kommt den Geschäftsprozess-, den Klassen-, den Verhaltens, den Interaktions- und dem Implementierungsdiagrammen die wichtigste Bedeutung zu. In der folgenden Tabelle werden die einzelnen Diagramme mit ihrer Sichtweise auf das gesamte System und den verwendeten Notationselementen kurz vorgestellt.

Diagramm Darstellung Notationselemente

Klassendiagramm (class diagramm)

…von den Klassen und deren Beziehung

Klasse Assoziation Aggregation Komposition Generalisierung

Objektdiagramm (object diagramm)

…des Klassendiagramms zu einem bestimmten Zeitpunkt

Objekt Link

Paketdiagramm (package diagramm)

…logisch zusammengehörender Modellelemente

Paket Classifier Paketimport Paketmerge

Kompositionsdiagramm (composite structure diagram)

… der inneren Strukturen von Teilsystemen, Komponenten oder Klassen

Part Port Kollaborationstyp Kollaboration

Komponentendiagramm (component diagramm)

…der technischen Systemkomponenten und deren Beziehungen untereinander

Komponente Artefakt Abhängigkeitsbeziehung

Verteilungsdiagramm (deployment diagram)

…der einzelnen Systemteile zur Laufzeit des Programms

Artefakt Knoten Einsatzspezifikation Knotenbeziehung

Geschäftsprozessdiagramm (use case diagramm)

… der fachlichen Leistungsfähigkeit des Systems

Geschäftsprozess Akteur Assoziation

Zustandsdiagramm (state chart diagramm)

…der Zustände, die Objekte o.Ä. innerhalb des Systems annehmen können

Zustand Anfangs-/Endzustand Transition Pseudozustand Unterzustand

Page 16: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Aktivitätsdiagramm (activity diagram)

…der Abläufe von Systemprozesse

Aktionszustand Objekt Kante

Sequenzdiagramm (sequence diagramm)

…zeitlicher Abläufe und des Informationsaustausches zwischen unterschiedlichen Objekten

Objekt Nachricht

Kommunikationsdiagramm (communication diagramm)

…der Kommunikationspartner und des zwischen ihnen stattfindenden Informationsaustausches

Lebenslinie Nachricht Interaktionsrahmen

Timingdiagramm (timing diagramm)

…des zeitlichen Verhaltens von Kommunikationspartnern in einzelnen Objektzuständen.

Lebenslinie Nachricht Interatkionsrahmen Zustand Zeitverlaufslinie

Interaktionsübersichts-diagramm (interaction overview diagram)

… aller Interaktionsdiagramme in einem zeitlichen Kontext

Verschiedene Elemente aus Zustands-, Aktivitäts-, Kommunikations- und Timimgdiagramm

Tabelle1: Übersicht der UML Diagrammarten [ZEW06]

Page 17: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

3 Tools

3.1 Überblick

Im Folgenden werden verschiedene Tools vorgestellt, mit denen Anwendungen, welche der MDA zu Grunde liegen erzeugt werden können. Die Kernaussage hierbei heißt „Automation durch Formalisierung“. Aus formal eindeutigen Modellen, soll durch die vorgestellten Tools automatisch Quellcode erzeugt werden. Darüber hinaus, soll durch die Tools und die darin formal eindeutig definierten Modellierungssprachen die Softwarequalität gesteigert werden. Es wird ein Überblick über die vorhandenen Tools gegeben. Außerdem wird das Tool ObjectIF, welches im Rahmen dieses Projektes für die Generierung des Prototyps eingesetzt wird, genauer vorgestellt.

3.1.1 OpenSource Produkte

AndroMDA ist ein Projekt, das sich zum Ziel gesetzt hat, Komponenten schnell generieren zu können. Dabei liegt das Hauptziel auf der Generierung von J2EE - Applikationen. Das Projekt wird bei Sourceforge verwaltet und ist somit Freeware. Auf der Webseite sind grundlegende Informationen zu AndroMDA und seiner Funktionsweise verfügbar, jedoch findet sich hier keine genaue Dokumentation. [MBN07]

Die ATL Engine, ist eine der QVT verwandten Transformationssprache, die vom INFRIA Atlas Team entwickelt wurde. ATL ist eine der Kerntechnologien im Eclipse Model-to-Model (M2M) Projekt. Das Tool wurde als eine Reihe von Eclipse Plugins entwickelt und dient als Entwicklungsumgebung für Transformationen zwischen Modellen, welche zusätzliche Debugging Möglichkeiten für diese Transformation bieten. [MBN07]

Der Gernerativ Model Transformer (GMT) ist ein Eclipse Projekt, welche forschungsorientierte Modelltransformationstechnologien auf Basis der Eclipse Plattform zur Verfügung stellt. Das Projekt beinhaltet mehrere bereits vorgestellte Tools, u.a. MOFScript und OpenArchitectureWare. [MBN07]

Das Kent Modelling Framework (KMF) ist ein Tool für die Generierung von Quellcode, welches das dynamische Überprüfen von Bedingungen unterstützt. [MBN07]

Kermeta ist als Erweiterung für Eclipse EMF (Eclipse Modeling Framework) vom INRIA Tirskell Team entwickelt worden. Es handelt sich hierbei um eine auf Eclipse basierende Entwicklungsumgebung, welche auf die Erzeugung von Metamodellen spezialisiert ist. Zum Funktionsumfang gehört die Festlegung einer abstrakten Syntax, einer dynamischen sowie einer statischen Semantik mit Verbindung zur konkreten Syntax. Zusätzlich ist das Erzeugen von Prototypen, Aspect Weaving und die Simulation von Modellen und Metamodellen möglich. Kermata wird in Eclipse integriert und steht als OpenSource Tool kostenlos zur Verfügung. [MBN07]

Page 18: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Das von IBM entwickelte Model Transformation Framework (MTF) basiert auf den Grundlagen des EMF und ist aktuell bei alphaWorks zu erhalten. Das Tool stellt deklarative Hilfsmittel zur Verfügung, um Verbindungen zwischen Metamodellen festzulegen, wie sie aus Query View Transformation (QVT) Verbindungen bekannt sind. [MBN07]

MOFScript ist ein Tool für die Umwandlung von Modellen in Code. Es basiert auf einer der „Model to Text Transfromation“ (MOF) Vorlagen von OMG. Das Tool ist eine Eclipse Plugin und ist auf die Erzeugung von Modellen und Metamodellen wie im EMF spezialisiert. [MBN07]

OpenArchitectureWare ist ein weiteres Framework, dass Modell getriebene Entwicklung unterstützen und ermöglichen soll. Es werden hier keine Templates für die verschiedenen Probleme mitgeliefert, sondern man ist hier darauf bedacht, jedes Problem auf jede beliebige Art und Weise zu lösen. Der Ursprung des Projektes ist eine kommerzielle Entwicklung der b+m Informatik AG, die von Entwicklern aus dem OpenSource Bereich und von b+m Informatik voran getrieben wurde und jetzt Freeware ist. Auf der Projekt Webseite finden sich mehrere Case-Studies, White Paper und Tutorials wieder, welche den Einstieg in die Entwicklung erleichtern. [MBN07]

OpenMDX ist eine OpenSource Umgebung für MDA. Das Tool integriert mehrere andere Tools durch XMI und unterstützt die Generierung von Quellcode für mehrere Verschiedene Zielplattformen wie J2EE oder .NET. [MBN07]

OMONDO® UML, ist ein Tool zur modellgetriebenen Softwareentwicklung, welches direkt in die Eclipse - Oberfläche integriert ist. Mit Hilfe von OMONDO® UML soll der Entwickler unabhängig von einer technischen Implementierung sein Modell planen und später in Quellcode umsetzten können. Dies erreicht OMONDO® durch die Integration von offiziellen Standards wie zum Beispiel dem UML 2.0 OMG/IBM Standard, dem EclipseUML2 open source metadata Standard oder der Verwendung von XMI Schemas. OMONDO® UML unterstützt ein bidirektionales Modell auf Bytecodeebene, welches die wechselseitige Verwendung von Modellentwicklung und Codeentwicklung zulässt. Durch seine Multiuserfähigkeit ist OMONDO® UML für den Einsatz in Entwicklerteams geeignet. Es gibt eine kostenlose Free-Edition mit eingeschränkten Funktionalitäten und die mächtigere Studio-Edition, welche 20 Tage mit allen Funktionalitäten testbar ist. [CZF07]

Page 19: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

3.1.2 Kommerzielle Produkte

ArcStyler ist eine kommerzielles MDA Tool, welches von Interactive Objects entwickelt wurde. Es ist im Paket mit MagicDraw UML-Tool erhältlich, es unterstützt aber auch andere UML-Tools durch Tool Adapter. [MBN07]

iOgen 3.0 ist ein Templatebasierender Quellcode Generator, welcher Modelle in verschieden Formaten einschließlich XMI, XML und ECore importieren kann. Die Templates basieren auf de JSP Technologie. [MBN07]

MCC ist ein von InferData entwickeltes Produkt, welches auf die Erzeugung von J2EE Anwendungen spezialisiert ist. [MBN07]

MDWorkbench ist ein Text- und Modelltransformationstoolset, welches jede Art von Metamodellen als Eingabe unterstützt. Das Tool basiert auf Eclipse und EMF. Es ist als Freeware Edition, Studentenversion und als Professional Edition erhältlich. [MBN07]

MetaEdit+ ist ein integriertes Modellierungs- und Metamodellierungstool um sprachübergreifenden Quellcode zu generieren. Das Tool untertützt XML und SOAP/Webservices Schnittstellen für die Modelle als auch für die Metamodelle. [MBN07]

Model-inAction ist eine MDA Toolsuite von Mia Software, welche die Erzeugung von Quellcode und eine Transformationen zwischen verschiedenen Modellen in einem flexibeln Framework unterstützt. [MBN07]

OptimalJ ist ein Produkt der Firma Compuware, welches vorgegebene Patterns benutzt, um eine Plattformspezifische Transformation zu erhalten. Es besitzt ein eingebautes UML Tool für die Analyse, für den MDA Teil wird hier eine leicht abgewandelte Notation verwendet. [MBN07]

SosyInc liefert einen Modellierer und eine Transformations-Engine. Die Engine ermöglicht die Generierung von lokalen GUIs und von serverseitigen Anwendungen, welche auf den OASIS/UML Modellen, den Anwendungsstrukturregeln und den Geschäftsregeln basieren. [MBN07]

Xactium XMF Mosic ist eine komplette Toolsuite für das Erstellen von Modellen, die Zuordnung und Generierung des entsprechenden Quellcodes und dessen Ausführung. [MBN07]

Page 20: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

3.2 ObjectIF

Bei dem von der Firma microTOOL stammenden kommerziellen Produkt ObjectiF handelt es sich um ein modellgetriebenes Entwicklungstool, welches für den Einsatz im kompletten Entwicklungsteam gedacht ist und über alle Entwicklungsphasen hinweg eingesetzt werden kann.

So definiert der Entwickler zu Anfang ein fachliches Modell mithilfe der UML und objectiF transformiert dieses Modell in die technische Architektur (technisches Modell) und generiert dabei große Teile des Codes. Die Professional Edition von objectiF geht sogar so weit, dass sie dem Benutzer Modellierungsmöglichkeiten auf Ebene der Geschäftsprozesse anbietet.

Bei der Transformation in das Technische Modell hat der Entwickler die Möglichkeit, den generierten Code in Eclipse1 zu exportieren und dort zu bearbeiten. Allerdings kann der Benutzer, auch ohne Eclipse, den generierten Code direkt in objectiF selbst bearbeiten, da es als eigenständiges Programm gestartet wird und nicht etwa in Eclipse integriert ist. Dies hat den Vorteil, dass die Synchronisation nur zu, vom Benutzer definierten Zeitpunkten, durchgeführt wird und nicht parallel zur Änderung am Code oder im Modell.

objectiF unterstützt folgende UML-Diagrammarten:

• UseCase-Diagramme

• Aktivitätsdiagramme

• Paketdiagramme

• Klassendiagramme

• Sequenzdiagramme

Insbesondere durch die UseCase-Diagramme stellt objectiF ein effektives Kommunikationsinstrument für die Entwicklung und die formale Beschreibung der Anforderungen in einem Projekt dar. Hier hat der Entwickler außerdem die Möglichkeit, Anwendungsfälle mithilfe integrierter Worddokumente zu beschreiben. Ein besonderes Feature von objectiF ist, dass die, in den Worddokumenten genannten Klassen, direkt als Klassen im Klassendiagramm aufgenommen werden können.

1 Eclipse ist ein Open-Source-Framework zur Entwicklung von Software nahezu aller Art. Die bekannteste Verwendung ist die Nutzung als Entwicklungsumgebung (IDE) für die Programmiersprache Java.

Page 21: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

3.2.1 Benutzerfreundlichkeit

In diesem Unterabschnitt soll kurz auf die Benutzbarkeit von objectiF eingegangen werden und die Vorteile, sowie die Nachteile der Benutzeroberfläche erörtert werden.

Die Modellierung von Use-Cases scheint in objectiF auf den ersten Blick sehr intuitiv. Der Benutzer kann die verschiedenen Komponenten des Uses-Case Diagramms ganz einfach per ‚Drag&Drop’ im Diagramm organisieren und Beziehungen zwischen Anwendungsfällen untereinander und zu Akteuren darstellen.

Abbildung 2: Benutzeroberfläche von objectiF

Wenn der Anwender jedoch einzelne Beziehungen wieder aus dem Diagramm löschen möchte, wird es umständlich. Aus anderen Anwendung ist man oft gewohnt, ein Objekt mit der Maus zu selektieren und per ENTF-Taste zu Löschen. In objectiF muss der Benutzer das zu löschende Objekt allerdings zuerst selektieren und kann anschließend über ein Kontextmenü, welches durch einen Rechtsklick mit der Maus geöffnet wird, bestimmen, dass das Objekt gelöscht werden soll. Dies rührt aber eher daher, dass nicht nur das Objekt selbst gelöscht werden kann, sondern auch entschieden werden kann, ob sowohl das Objekt als auch die Beziehung zu anderen Objekten entfernt werden soll.

Page 22: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Möchte der Entwickler seine modellierten Anwendungsfälle bzw. deren Funktionsweise näher spezifizieren, hat er in objectiF die Möglichkeit, dies ebenfalls wieder direkt über das Kontextmenü zu erledigen. Hier bietet objectiF, abhängig vom Typ des Objekts (Anwendungsfall, Akteur oder Beziehung) verschiedene Möglichkeiten an. Im Falle eines Anwendungsfalles wird dem Anwender die Modellierung eines Aktivitäts-, Zustands- oder Sequenzdiagrammes angeboten.

Abbildung 3: Word Kompatibilität

Außerdem besteht die Möglichkeit, ebenfalls wieder über das Kontextmenü, jedes Objekt in einem Worddokument näher zu beschreiben. Aus dem Worddokument heraus können dann einzelne Wörter als Klasse definiert werden und über ein, in Word integriertes objectiF-Menü in ein vom Benutzer angelegtes Klassendiagramm aufgenommen werden.

Abbildung 4: Ausschnitt eines Klassendiagramms

Page 23: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Im Klassendiagramm wird dem Entwickler die Möglichkeit geboten, Beziehungen zwischen den Klassen auf Knopfdruck völlig automatisch generieren zu lassen, was dem Entwickler eine Menge Arbeit und Zeit erspart.

Allerdings birgt das Klassendiagramm auch einen Schönheitsfehler. Wird eine Klassenvariable als Feld deklariert, erscheint diese im Klassendiagramm selbst nicht so und kann zu Missverständnissen des Klassendiagramms führen. In der Abbildung ist dies z.B. an der Klassenvariable ‚kompatible Schuhe’ in der Klasse ‚Bremse’ zu sehen.

Page 24: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

4 Prototyp

Der Prototyp wird einen Baukasten für Inline-Skates darstellen. Der Sinn des Prototyps ist es, einen individuellen Inline-Skate aus einer Sammlung verschiedener Bauteile zusammenzustellen. Für jedes Bauteil stehen verschiedene Varianten zur Verfügung wobei nicht jede Variante mit jeder Variante eines anderen Bauteils kombinierbar ist. Für die Zusammenstellung der einzelnen Bauteile des Inline-Skates ist nicht nur die Kompatibilität von Varianten maßgebend, sondern auch der Faktor Kosten relevant.

Der Prototyp wird Mithilfe des MDD-Werkzeugs ObjectiF von microTools erstellt. Mit dem Werkzeug wird zuerst ein fachliches, plattformunabhängiges Modelle mit Hilfe der UML erstellt, um anschließend daraus automatisch den Quellcode für ein ausführbares Programm in einer ausgewählten Programmiersprache zu erzeugen. Der Prototyp soll nach den weit verbreiteten Architekturvorschriften, wie sie heutzutage „State of the Art“ sind, entworfen werden.

Ein Inline-Skate soll aus den folgenden Bauteilen mit den entsprechenden Attributen bestehen:

Abbildung 5: Komponenten eines Inline Skates

Page 25: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

4.1 Funktionsweise

Im folgenden wird der Prototyp ausführlich beschrieben. Dazu gehören die verschiedenen Diagramme, wie Use-Case- und Aktivitätsdiagramm, Paket- und Klassendiagramme. Zusätzlich werden die einzelnen Diagramme erläutert und die vorkommenden Klassen beschreiben.

Use-Case-Diagramm

Abbildung 6: Use-Case-Diagramm

Im Use-Case-Diagramm wird sichtbar, dass der Benutzer ausschließlich mit dem System „Skate konfigurieren“ kommuniziert. Hieraus sollen die verschiedenen Funktionalitäten aufgerufen werden.

Eine Vollständigkeitsprüfung muss stattfinden, damit überprüft wird, ob der momentan konfigurierte Skate vollständig ist, dass heißt, ob es alle benötigten Bauteile besitzt.

Außerdem soll eine Gesamtkostenberechnung stattfinden. Diese wird auch durchgeführt, wenn einzelne Bauteile geändert werden, damit der Benutzer immer die aktuelle Gesamtsumme im Blick hat.

Der Benutzer soll die Möglichkeit besitzen, die verschiedenen Bauteile auszuwählen. Dabei kann er auf zwei Attributen filtern. Zum einen kann er einen Höchstpreis für jedes Bauteil angeben, zum anderen Kann er auf die verschiedenen Hersteller filtern.

Sobald der Benutzer ein Bauteil zu seinem Gesamtskate hinzufügt, wird automatisch die Kompatibilität zwischen den einzelnen Bauteilen ermittelt und dem Benutzer mitgeteilt.

Page 26: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Wenn der Benutzer den kompletten Skate konfiguriert bzw. zusammengestellt hat, bekommt er eine Übersicht mit seinem konfigurierten Skate. Hier ist wieder der Gesamtpreis und die Kompatibilität der Bauteile sichtbar.

Aktivitätsdiagramm

Abbildung 7: Aktivitätsdiagramm

Page 27: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Im Aktivitätsdiagramm wird die Interaktion zwischen dem Benutzer und dem System genauer betrachtet. Es wird deutlich, dass das System erst eine Liste mit den verschiedenen Bauteilen ausgibt. Der Benutzer hat dann die Möglichkeit, ein Bauteil zu wählen. Das System zeigt die verschiedenen Varianten eines Bauteils an. Der Benutzer kann entweder einen Filter über die angezeigten Bauteile legen, oder direkt ein Bauteil auswählen und somit zu seiner Gesamtkonfiguration hinzufügen. Sobald der Benutzer ein Bauteil ausgewählt hat, prüft das System auf die Kompatibilität zwischen den einzelnen Bauteilen ab. Sind Bauteile nicht miteinander kompatibel, wird der Benutzer aufgefordert, eines der nicht Bauteile auszutauschen, damit die Gesamtkonfiguration kompatibel wird. Wenn alle Bauteile kompatibel sind, wird vom System überprüft, ob alle benötigten Bauteile ausgewählt wurden. Ist dies nicht der Fall, kann der Benutzer eines der noch fehlenden Bauteiltypen auswählen und die Prozedur beginnt von vorne. Wenn alle Bauteile in der Gesamtkonfiguration vorhanden sind, wird der gesamte Skate angezeigt.

Paketdiagramm

Abbildung 8: Paketdiagramm

Im Paketdiagramm werden die drei vorhandenen Pakete, und deren Beziehung untereinander dargestellt.

Im Paket de.mda.bauteile befinden sich sowohl alle Bauteiltypen, als auch der Gesamtskate, welcher alle Bauteile aufnimmt. Zu den Bauteilen gehören wie oben aufgelistet, die Bresme, das Kugellager, die Rolle, die Schiene, die Schrauben und der Schuh.

Page 28: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Im Paket de.mda.view befindet sich ausschließlich die grafische Benutzeroberfläche (GUI), welche zum anzeigen der Prototypkonfigurationen benötigt wird.

Das Paket de.mda.steuerung beinhaltet die Steuerungsklassen, welche die Geschäftslogik der Anwendung aufnehmen.

Es wird sichtbar, dass das Steuerungspaket die verschiedenen Bauteile, sowie den Gesamtskate benutzt, um eine Zufallskonfiguration zu erstellen, und um die Kompatibilität der Bauteile zu überprüfen. Das Viewpaket benutzt die beiden anderen Pakete, und importiert auch einen Teil der Klassen der Pakete als Klassenvariablen.

Page 29: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Klassendiagramm Da das Klassendiagramm bereits für den Prototypen zu umfangreich ist, wird im folgenden nur eine textuelle Beschreibung der einzelnen Klassen aufgeführt.

Die Klasse Bauteil ist abstrakt und dient als Überklasse für alle Bauteile, sie Besitzt zwei Klassenvariablen, welche für alle Bauteile benötigt werden. Dies ist zum Einen der Preis und zum anderen die Marke, da diese beiden Attribute von allen Bauteilen benötigt werden.

Die Klasse Bremse wird von Bauteil abgeleitet. Sie beinhaltet als Klassenvariable das Material, aus welchem die Bremse besteht. Zum anderen besitzt sie zwei Arrays, in welchen die kompatiblen Schienen und Schuhe aufgeführt werden können.

Die Klasse Kugellager repräsentiert die Kugellager der Gesamtkonfiguration. In den Klassenvariablen sind die verschiedenen Attribute der Kugellager festgelegt. Dazu gehört die Größe eines Kugellagers, das Material, die Qualität und die Schmierung.

Die Klasse Rolle stellt eine Skaterolle dar. Eine Rolle besitzt eine Kategorie wie Stunt oder Speed, einen Durchmesser, die Härte der Rolle, und eine Farbe. Diese Eigenschaften werden wieder in Klassenvariablen festgehalten. Zusätzlich gibt es hier ein Array, in welchem die kompatiblen Kugellager aufgelistet werden.

In der Klasse Schiene nimmt die Eigenschaften der Schiene des Skates auf. Zu den Eigenschaften gehört die Länge der Schiene, die Anzahl der möglichen Rollen, die an der Schiene gefestigt werden können, die maximale Rollengröße, das Material, das Gewicht und die Steifigkeit der Schiene.

Die Klasse Schrauben beinhaltet zwei Arrays, in welchen die kompatiblen Spacer und die kompatiblen Schienen abgelegt werden. Außerdem wird in einer Klassenvariable die Kopfeigenschaft der Schrauben festgelegt, welche entweder Imbuss oder Torx sein kann.

Die Klasse Schuh definiert den Schuh des Gesamtskates. Der Schuh besitzt folgende Attribute, welche in Klassenvariablen abgelegt werden. Das Material, die Farbe, die Größe, den Lochabstand und die Kategorie des Schuhs.

Die Klasse Spacer repräsentiert die Spacer der Gesamtskates. Ein Spacer besitzt als Eigenschaften ausschließlich das Material des Spacers, sowie dessen Größe.

In der Klasse Skate werden alle oben beschriebenen Bauteile zusammengefasst. Diese werden in Klassenvariablen abgelegt. Zusätzlich besitzt der Skate einen Gesamtpreis, welcher sich aus den gewählten Bauteilen und deren Anzahl berechnet. Außerdem wird eine Gesamtkompatibilität aufgenommen, in der festgelegt wird, ob die beinhalteten Bauteile miteinander kompatibel sind.

Page 30: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

In der Klasse Abhängigkeiten ist die Geschäftslogik der Anwendung implementiert. In dieser Klasse sind Filter Methoden vorhanden, welche abhängig von der übergebenen Marke bzw. der übergebenen Preisspanne eine Liste von entsprechenden Bauteilen zurück liefert. Außerdem ist eine Methode vorhanden, welche einen Skate übergeben bekommt, und die Kompatibilität der einzelnen Bauteile des Skates überprüft und entsprechend true oder false zurück liefert. Eine weitere Methode bekommt auch einen Skate übergeben, und berechnet die Vollständigkeit des Skates, d.h. es wird Überprüft, ob alle Bauteile vorhanden sind. Die letzte hier enthaltenen Methode bekommt wie die beiden Methoden zuvor einen Skate übergeben und berechnet den entsprechenden Gesamtpreis, welcher sich aus den Preisen und der Anzahl der einzelnen Bauteile zusammensetzt.

Die Klasse Skate_Generator beinhaltet für jede Klassenvariable der verschiedenen Bauteile ein Array mit drei unterschiedlichen Werten. Es wird eine zufällige Zahl zwischen null und zwei generiert um dann aus den verschiedenen Arrays ein Bauteil generiert. Aus den Bauteilen wird dann ein Gesamtskate erstellt und zurückgeliefert.

In der Klasse GUI wird schließlich eine grafische Oberfläche erzeugt, in welcher die zufälligen Konfigurationen angezeigt werden. Dazu wird von der Klasse JFrame abgeleitet, welche ein Fenster in Java repräsentiert. In der GUI wird ein die Methode der Skate_Generator Klasse aufgerufen, welche einen zufälligen Skate generiert. Die verschiedenen Bauteile des generierten Skates werden dann grafisch dargestellt. Zusätzlich findet dann eine Kompatibilitätsprüfung statt welche dann auch dargestellt wird. Die Headline der grafischen Oberfläche fügt eine weitere Klasse GenerateListener hinzu, welche einen MouseListener implementiert. Hier wird immer wieder eine neue Konfiguration erzeugt und in der GUI dargestellt.

Page 31: Model Driven Development / Model Driven Architecture · 2012-07-05 · Model Driven Architecture/Model Driven Development Haizmann, Köster, Neugart, Stein Informationstechnik BA

Literaturverzeichnis

[OMG03] Miller Jarquin, Mukerij Jishnu, MDA Guide Version 1.0.1, OMG, 2003 [SEB03] Bran Selic, IIISoftware, Ausgabe September 2003 [WIKI07] http://de.wikipedia.org/wiki/Model_Driven_Architecture

http://de.wikipedia.org/wiki/Modellgetriebene_Softwareentwicklung; 01.Dez. 2007

[ZEW06] Klaus Zeppenfeld, Regine Wolters, Generative Software Entwicklung mit der MDA, 1. Aufl. 2006

[CZF07] Christoph Zang, Frankfurt 01.12.2007 http://www.christoph-zang.de/4__Evaluierung_von_MDA.67.0.html

[MBN07] Jon Oldevik, 01.12.2007 http://www.modelbased.net/mda_tools.html

Abbildungsverzeichnis

Abbildung 1: Die Diagrammarten von UML 2.0 [ZEW06] ............................................ 14 

Abbildung 2: Benutzeroberfläche von objectiF .............................................................. 21 

Abbildung 3: Word Kompatibilität ................................................................................. 22 

Abbildung 4: Ausschnitt eines Klassendiagramms ......................................................... 22 

Abbildung 5: Komponenten eines Inline Skates ............................................................. 24 

Abbildung 7: Aktivitätsdiagramm .................................................................................. 26 

Abbildung 8: Paketdiagramm ......................................................................................... 27 

Tabellenverzeichnis

Tabelle1: Übersicht der UML Diagrammarten [ZEW06] ............................................... 16