Seminar Aktuelle Themen der Informatik

Transkript

1 Fachhochschule Furtwangen Studiengang (Computer Networking) Seminar Aktuelle Themen der Informatik Thema: Model Driven Architecture Sommersemester 2006 am: vorgelegt von: Daniel Wehrle Oskar-Bier-Str Friedenweiler MDA by Daniel Wehrle 1/17

2 Inhaltsverzeichnis 1.MDA Gründe für Modelgetriebene Entwicklung MDA in der Theorie Was genau ist MDA Konzept der MDA Business Logik Erstellung in MDA Refactoring, Reverse Engeneering Wann macht generieren Sinn Weitere MDA Hilfs-Werkzeuge Tools Arten von Tools ArcStyler OpenArchitectureWare AndroMDA Zusammenfassung der Vor- und Nachteile von MDA Vorteile: Nachteile: Zukunft von MDA MDA by Daniel Wehrle 2/17

3 1. MDA 1.1. Gründe für Modelgetriebene Entwicklung In dem modernen Softwareentwicklungsprozess kommen in den letzten Jahren zunehmend Ingenieursmäßige Konzepte und Vorgehensweisen zum Einsatz. Dadurch ist auch das Design von Software zum Gegenstand der Kommunikation geworden. Um dieses vornehmlich in grafischen Modellen beschreiben zu können, wurde die Unified Modeling Languge (UML) entwickelt. Dennoch werden heute noch viele Projekte ohne oder mit geringem Einsatz an grafischer Notation für das Design durchgeführt. Dies liegt zum Teil am Entstehen eines Buches, beim Übergang von der grafischen Modellierung hin zur Implementierung im Code. Auch werden nach diesem Übergang zumeist alle Änderungen nur noch im Code festgehalten. Mit der Model Driven Architecture hat die OMG einen viel beachteten Ansatz vorgestellt, um dieses Problem zu lösen und Modelle über den gesamten Entwicklungsprozess hinweg nutzbar zu machen.[1] In dem IEEE Artikel [2] wird die bisherige Softwareentwicklung damit verglichen, als ob ein Chip-Entwickler, nachdem er das Layout erstellt hat, dieses wegwerfen würde, um dem Waverproduzenten dieses mündlich zu erklären, damit dieser die Waver negative aufgrund des Berichtes erstellen kann. Dabei ist die Model Driven Architecture sicher nicht der erste UML zum Code Ansatz, so gab es den Round-trip-Engineering Ansatz bereits vor MDA, welcher ebenfalls Abbildungsvorschriften, um vom Modell zum Quelltext zu gelangen einsetzt. Auch gab es schon Anfang der 90er diverse Codegeneratoren für spezielle Hersteller Frameworks. Diese hatten jedoch alle die Gemeinsamkeit, dass die Generierung sowie Transformierung nicht standardisiert war, und nur für ein spezielles Framework, mit einer speziellen Middleware eingesetzt werden konnte. Somit waren diese auf die beiden Hauptmotivationen der MDA nicht ausgelegt. Diese sind laut der Object Managment Group (OMG), welche die Model Driven Architecture standardisiert, Interoperabilität und Portabilität. ([3] S. 14) Herstellerunabhängigkeit und damit Interoperabilität soll durch die Standardisierung von Modellen und Transformationen erreicht werden. Auch soll eine Unabhängigkeit von den zugrundeliegenden Plattformen (Portabilität) erreicht werden. Einen der wichtigsten daraus hervorgehenden Vorteile verspricht man sich von einer verbesserten Wiederverwendung von Komponenten. Durch die MDA können diese unabhängig von der Plattform modelliert und somit auch entwickelt werden. Bisher war es bei einem Plattformwechsel beinahe unmöglich, die Applikation oder Teile der Applikation wiederzuverwenden, da der Code auch immer plattformspezifische Information enthält. Ein Austausch der Programmiersprache erschien noch unmöglicher, da die Anwendung nur in der entsprechenden Sprache ausgedrückt vorlag. Da MDA eine Wiederverwendung des Domain Modell ermöglichen soll, stellt dies zukünftig auch ein geringeres Problem dar. ([4] S. 7 ff.) MDA by Daniel Wehrle 3/17

4 Für den Anwender bedeutet dies einen höheren Investitionsschutz, durch die Wiederverwendbarkeit des von der Plattform unabhängigen Entwurf, welcher einfach für eine neue Zielplattform generiert werden kann. Da so bei einem Plattformwechsel das von der Plattform unabhängige Modell nicht verloren geht, sondern daraus ein Großteil des Codes für die neue Plattform generiert werden kann. So sagte der OMG-Chef Soley auf der OOP 2004 in München, dass MDA eine Reaktion auf den anhaltenden Wandel der Softwareinfrastruktur sei (Corba, Java,.Net, XML, Web-Services etc.), welche sich mit herkömmlichen Mitteln nicht mehr bewerkstelligen lassen. ([5] S. 18 f.) Generell lassen sich auch neue Verfahren in der Softwareentwicklung leicht mittels MDA in bestehende Projekte integrieren. So können zusätzliche Dateien oder Statements für neue Entwicklungskonzepte leicht zusätzlich in einen bestehenden Code generiert werden, ohne die benötigten Änderungen von Hand vornehmen zu müssen. Zum Beispiel kann so die Service Oriented Architecture oder die Aspekt Orientierte Programmierung mittels des Generators in das bestehende Projekt mit integriert werden, ohne alle Klassen und Konfigurationen einzeln anpassen zu müssen. Solle dies einmal nicht den erhofften Nutzen bringen, kann es über das Verwenden des alten Generators auch genau so einfach wieder entfernt werden. Abbildung 1: Die Probleme der Wiederverwendung MDA by Daniel Wehrle 4/17

5 1.2. MDA in der Theorie Was genau ist MDA MDA ist eine Standardisierungsinitziative der Object Managment Group (OMG), welche auf der Idee beruht, dass Modellierung eine bessere Weise ist, um Anwendungen zu entwickeln. Außerdem ist sie ein Zertifikat für Produkte, welche diesen Standard umsetzen und eine Reihe von Techniken und Technologien, die mit diesem Standard verbunden sind. ([4] S. XX) MDA basiert auf Standards wie der Unified Modeling Language (UML) und der XML Metadata Interchange (XMI). Vieles von ihr ist jedoch noch Zukunftsmusik, der grundsätzliche Ansatz über das Architekturdesign zur konkreten Implementierung zu kommen, findet jedoch in den ersten Projekten Anklang. ([5] S. 18 f.) Es existieren auch andere Abkürzungen wie MDD (Model Driven Design), DDD (Domain Driven Design) oder MDSD (Model Driven Software Development). Hierbei handelt es sich um ähnliche Konzepte wie bei der MDA, welche sich jedoch zumeist nicht an die Spezifikation von der OMG halten. Meist dient nicht nur UML als Grundlage für die Generierung, sondern es kommen auch herstellerspezifische Erweiterungen oder eigens für die Tools entwickelte Modelle und Meta Modelle zum Einsatz. [6] Und [3] Konzept der MDA In der Model Driven Architecture wird zwischen Modellen mit verschiedenen Detailierungsgraden unterschieden: CIM (Computation Independent Model) für die umgangssprachliche Beschreibung der Anwendung. PIM (Platform Independent Model), von der Zielplattform unabhängiges Model der Anwendung. PSM (Platform Specific Model), Model welches auch Informationen speziell für die Zielplattform beinhaltet. Quellcode, die Zielplattform MDA by Daniel Wehrle 5/17

6 Abbildung 2: Vom CIM zum Code Das CIM findet dabei in der Literatur nicht immer Erwähnung, da es sich hierbei nur um Entwürfe handelt, welche für die Codegenerierung nicht oder nicht direkt verwendet werden können. Dies sind zum Beispiel Use Cases oder andere Dokumente welche die Benutzererwarungen in einem sehr sprachlichen Stil erfassen. Das Plattform Independent Model hingegen ist das Zentrale Model in der MDA, da es das von der Zielplattform unabhängige Design repräsentiert. Dadurch wird eine Wiederverwendung des PIMs für eine andere Plattform ermöglicht. Das Plattform Specific Model soll durch die Nutzung von automatisierten Abbildungen aus dem PIM gewonnen werden. Dies soll ein Verlassen der Werkzeugumgebung verhindern und das Model mit dem Quelltext synchron halten. Im Endeffekt steht im PSM das gesamte Wissen über die Zielplattform zur Verfügung. Jedoch reichen dazu die im PIM gegeben Informationen nicht aus, so dass das generierte PSM noch verfeinert werden muss. Da Regeln für die Transformation vom PIM zum PSM schwer zu definieren sind, und das Reverse Engineering noch nicht standardisiert ist, verzichten so gut wie alle MDA Werkzeuge auf die explizite Erzeugung eines PSM Modells. [1] Oftmals werden deshalb auch plattformspezifische Merkmale über Annotationen an die Modellelemente im PIM geheftet, welche dann von den entsprechenden Generatoren verarbeitet werden. Dem Transformationsschritt vom PIM zum PSM kommt dabei jedoch eine entscheidende Bedeutung zu. Die Qualität der Transformation beeinflusst direkt die Qualität des Endproduktes. Daher fällt ein wesentlicher Teil des Programmieraufwandes innerhalb eines durch MDA unterstützten Projektes für die Erstellung und Anpassung des MDA by Daniel Wehrle 6/17

7 Generators an. Dieser zusätzliche Aufwand macht sich aber zumeist nur langfristig bezahlt, wenn man mehrere Projekte auf der gleichen Basis abwickelt und so den einmal erstellten Generator wiederverwenden kann. [6] Abbildung 3: Design Phasen MDA Durch diese Aufteilung wird der Abstraktionsgedanke in der Softwareentwicklung konsequent weiter geführt. Beispielsweise stellte des C++ Code eine höhere Abstraktion als Assembler dar, bei dem sich die Plattform (in diesem Fall der Prozessor) einfach durch den Austausch des C++ Compilers wechseln lässt. Durch MDA geht man einen Schritt weiter und entwickelt zunächst ein Modell anstelle von Code, welches zunächst von der Hardware- und Softwareumgebung unabhängig ist (Platform Independent Model) und als Vorlage für die Codegenerierung dient. [7] Einige gehen sogar so weit und erzeugen aus dem Modell direkt die entsprechenden ausführbaren Dateien. Das Problem stellt in diesem Fall zumeist die Erzeugung der Business Logik dar. Darunter versteht man die Teile des Programmes, welche sich nicht in dem abstrakten UML Modell festhalten lassen, sondern für das jeweilige Projekt sehr individuelle Eigenschaften aufweisen. In der zunehmenden Abstrahierung sehen viele eine Lösung für die immer komplexer werdenden Softwareprojekte, bei denen heute schon bis zu 100 Entwickler keine Seltenheit mehr sind. Da dieser Trend sich auch weiter fortsetzen wird, könnte eine weitere Abstrahierung dank MDA ein Weg sein, um die Erstellung von lauffähigen Programmen auch weiterhin zu gewährleisten. [6] MDA by Daniel Wehrle 7/17

8 Abbildung 4: Höhere Abstraktion geht mit der zeitlichen Entwicklung von Programmiersprachen einher Business Logik Erstellung in MDA Die Geschäftslogik wird direkt in den Operationen oder den dynamischen Diagrammen (State-, Activity- und Collaborationdigrammen) hinterlegt. Innerhalb des Modells kann diese in den Operationen mittels einer herstellerspezifische Action Sementic Language (ASL) oder über programmiersprachenspezifischen Syntax erfolgen. Es gibt jedoch auch die Möglichkeit, den Buisnesscode nicht im Modell, sondern im geschützten Bereich des Codes zu hinterlegen. [7] Beim Umgang mit manuell erzeugten Erweiterungen an den generierten Artefakten, gibt es unterschiedliche Ansätze. Bei einigen Tools muss man von den generierten Klassen ableiten oder delegieren, häufig werden auch geschützte Bereiche, meist als protected areas bezeichnet, eingesetzt Refactoring, Reverse Engeneering Das Erstellen von Artefakten aus einem Modell wird als Forward Engineering (FE) bezeichnet. Wenn Änderungen zurück ins Modell übernommen werden, so bezeichnet man dies als Reverse Engeneering (RE). Wird beides zusammen verwendet, spricht man von Roundtrip Engeneering (RTE). Da der Entwickler zumeist nicht alle Tätigkeiten im Modell durchführen kann, sollte RE unterstützt werden, damit er nicht immer gezwungen ist, Änderungen zuerst im Modell durchzuführen. Leider sind solche Rückabbildungsvorschriften sehr schwer zu finden und zu definieren, insbesondere wenn man nicht jede unnötige Kleinigkeit mit ins Modell aufnehmen MDA by Daniel Wehrle 8/17

9 will. Deshalb wird das Reverse Engeneering von den wenigsten Tools unterstützt. Auch hat noch kein Hersteller einen Weg gefunden, dem Benutzer die Möglichkeit zu geben, diese Vorschriften selbst anzupassen Wann macht generieren Sinn Generierung von Artefakten mach dann Sinn, wenn die Entwicklung innerhalb eines Projektes durch einen festen Prozess vorgegeben ist, bei welchem zunächst ein UML Modell erstellt wird und dann darauf aufbauend die Software entwickelt wird. In diesem Fall bietet die Generierung der daraus erzeugbaren Artefakte erhebliche Vorteile. Diese müssen nicht mehr von Hand implementiert werden, außerdem werden Abbildungsfehler werden ebenfalls vermieden. Probleme können nun auftreten, wenn die weiteren Änderungen lediglich im Code stattfinden. So macht in diesem Fall eine weitere Verwendung von MDA keinen Sinn, insbesondere wenn das MDA Tool kein Reverse Engineering unterstützt. Wenn der Entwicklungsprozess jedoch so angelegt ist, dass eine Änderung zuerst im Code erfolgt, dann stellt auch das Fehlen von Reverse Engeneering Methoden kein Problem dar. Dies hängt jedoch auch von der Einstellung der Mitarbeiter ab, ob diese bereit sind, Änderungen zuerst im Modell vorzunehmen, um sie dann generativ in den Code zu übernehmen. Nicht zuletzt wird hierbei jedoch auch bei jeder Abwandlung des Modells ein Perspektivenwechsel innerhalb der Entwicklung notwendig. Wenn der generierte Code jedoch zumindest so abgewandelt werden kann, dass Änderungen durch eine neue Generierung nicht verloren gehen, dann kann zumindest eine spätere Verfeinerung des Modells ermöglicht werden. Jedoch kann es auch sein, dass bei der Generierung entstandene Metainformationen in den Artefakten von der Entwicklungsumgebung überschrieben oder gelöscht werden, und somit für den Generator verloren gehen. Dies kann zum Beispiel bei der Kennzeichnung geschützter Bereiche auftreten, und die Verwendung von diesen innerhalb bestimmter Dateien verhindern. Da sich durch die Model Driven Architecture der Entwicklungsschwerpunkt von dem Sourcecode in das UML Modell verlagert, ist es notwendig, dass sich das Team in UML sehr gut zurecht findet Weitere MDA Hilfs-Werkzeuge Um sicherzustellen, dass ein Modell sich auch in ein anderes Modell bzw. Code übersetzen lässt, ist in der Model Driven Architecture die Modellverifizierung vorgesehen. Hierbei kann es sich um statische, syntaktische und semantische Prüfungen handeln, manche Tools ermöglichen auch die Erweiterung der Verifikation über Scriptsprachen oder spezielle Modellierungen. Wenn möglich soll die Generierung nicht statisch erfolgen sondern erweitert werden können, damit der Generator an die individuellen Projektanforderungen angepasst werden kann. Wie und ob diese Erweiterungen möglich sind, hängt von den einzelnen Tools ab. Einige bieten eine eigene Modellierungssprache um Generatoren zu entwickeln, andere setzen hier auf Skriptsprachen oder Templates. Einige Tools gehen MDA by Daniel Wehrle 9/17

10 auch davon aus, dass die Information über die Abbildung von Elementen in einen Code innerhalb des MetaModells anzusiedeln sind. Diese bieten deshalb die Möglichkeit einer Erweiterung oder Änderung des Metamodells an. Einige Tools ermöglichen das Erstellen eines Modell Reports, welcher zur Dokumentation der Entwicklung sowie der Generierung dienen kann.[7] 1.3. Tools Arten von Tools Generell kann man drei verschiedenen Arten von MDA Tools unterscheiden: Vollständige MDA Engeens X-UML Tools/Engeens Codegeneratoren Die Gruppe der Vollständigen MDA Tools beinhaltet immer ein UML Tool und einen Generator. Zumeist sind auch Generatoren sowohl für Model 2 Code als auch für Model 2 Model enthalten. Auch unterstützen diese Tools oftmals Roundtrip Engeneering. Manche von diesen Tools sind bereits vollständig in eine IDE integriert um dem Benutzer eine möglichst einheitliche Entwicklungsoberfläche zu bieten und ein ständiges Springen von einer zur anderen Anwendung zu ersparen. Beispiele dafür sind: Ameos von Aonix Real-Time Studio von Artisan Rapsody von I-Logix TAU von Telelogic Rational Software Architect von IBM Optimal J von Compuware Together von Borland ArcStyler von Interactive Objects MetaEdit+ von MetaCase ObjectIF von MicroTool Innovator von MID X-UML Tools führen das Modell zumeist direkt in einer Virtuallen XML-Maschine aus oder generieren direkt den ausführbaren Bytecode. Deshalb besitzen sie zumeist eine eigene ASL Syntax, um die Businesslogik zu spezifizieren. Beispiele hierfür sind: iuml von Kennedy Carter Cassandra xuml von KnowGravity OpenMDX von Omex Codegeneratoren sind meist recht einfach gestrickte Open Source Tools, welche das Verwenden von verschiedenen Template oder Scripten zur Generierung aus verschiedenen UML Tools ermöglichen. Dazu wird zumeist ein XMI Importer zum Import der Modelle bereit gestellt, auf welchem eine vom User spezifizierte Model 2 Code Transformation abläuft. Dies Tools verzichten zumeist vollkommen auf die MDA by Daniel Wehrle 10/17

11 Erstellung eines PSMs, der Code wird von dem Generator direkt in den Sourcecode umgewandelt. Beispiele hierfür sind: Open ArchitektureWare von b + m Informatik (open source) SmartGenerator von BITPlan XCoder von dem Xcoder-Project (open source) Iqgen von InnoQ AndroMDA (open source) ArcStyler Der ArcStyler ist eine Softwareentwicklungsplattform für die automatisierte Generierung von Softwareartefakten aus UML-Modellen, basierend auf der Model Driven Architecture. Er wird von der Firma Interactive Objects Software GmbH in Freiburg entwickelt. Der ArcStyler ist in Java geschrieben, um Plattformunabhängigkeit zu erreichen. Leider wurde dadurch eine hohe Anforderung an den Arbeitsspeicher, sowie die Prozessorleistung notwendig. Auch muss man zumeist lange auf das Laden und Generieren von Modellen warten. Der ArcStylers ist auf den gesamten Lebenszyklus eines Enterprise Softwaresystems fokussiert: Von Analyse, Entwurf, Entwicklung bis hin zur Verteilung und den Tests. Als UML-Modellierungswerkzeug ist Magic Draw der Firma No Magic integriert. Die interne Struktur des ArcStylers wird durch Abbildung 3 grob skizziert. Der ArcStyler besteht aus 3 Modulen, diese sind: Abbildung 5: Interner Aufbau des ArcStyler Ein Modell Repository, welches den Zugriff auf das Modell über MOF oder UML erlaubt. Dem integrierten Modellierungstool, Magic Draw von No Magic. Einer MDA Engine, welche das Einbetten einer MDA-Cartridge ermöglicht. Die konkrete Generierung übernimmt dann diese eingebettete MDA-Cartridge. MDA by Daniel Wehrle 11/17

12 Verbunden werden diese durch den Tool Adapter Standard (TAS). Die Entwicklung von eigenen MDA-Cartridges wird durch die Cartridge Architecture (CARAT) ermöglicht. CARAT wird zur Modellierung von MDA-Cartridges und der anschließenden automatischen Generierung der Implementierung der MDACartridges aus den Modellen eingesetzt. Somit wird auch für die Erstellung von Transformationen der MDA-Ansatz verwendet und es können Konzepte wie Wiederverwendung und Spezialisierung von MDA-Cartridges genutzt werden. Die Cartridges selber werden nach Jpython generiert. In den generierten Dateien muss noch die konkrete Syntax ergänzt werden um die Generierung der Artefakte zu ermöglichen. Der ArcStyler ist von Haus aus mit folgenden Cartridges ausgestattet: Java EJB 1.1 / 2.0 IBM WebSphere, BEA WebLodig, JBoss C#.Net Java Accessors Auf die explizite Generierung eines PSM wird verzichtet, die plattformspezifischen Informationen werden mittels Marksets im Modell hinterlegt. Diese werden als UML Tagged Values gespeichert. Diese Informationen werden bei der Generierung für eine spezielle Plattform zur Generierung genutzt. Der ArcStyler ist eines der ersten Tools, welches einen Prototyp für die Query View Transformation besitzt. Hierbei handelt es sich um einen noch nicht vollständig spezifizierten und verabschiedeten OMG Standard für die Modell zu Modell Generierung OpenArchitectureWare OpenArchitectureWare ist ebenfalls ein Framework, zur Modell getriebenen Entwicklung. Dabei existieren keine vorgefertigten Cartridges (zur Erzeugung von beispielsweise C# Code) Applikationen, sondern nur das reine Framework zur Generierung von Applikationen mittels einem vorhandenen Metamodell. Die Cartridges müssen entweder gekauft oder selbst entwickelt werden. Der Ursprung des Projektes ist eine Entwicklung der b+m Informatik AG, welche den Open ArchitectureWare auch weiterhin kommerziell vermarktet. Deshalb stellt b+m auf ihren Web-Seiten weitere Artikel rund um das Open ArchitectureWare Framework zu Verfügung. An der Projektentwicklung nehmen sowohl Entwickler aus dem reinen Open- Source Bereich, als auch Entwickler von b+m teil. Das Open ArchitectureWare Framework arbeitet mit dem Ansatz, dass zu einem Modell immer ein Metamodell existiert. Ziel ist es dabei mittels des validen Metamodells, Code zu generieren. Der Ansatz ist vergleichbar mit dem Ansatz den UML verfolgt. Das UML Modell selber definiert sich als Metamodell, während das eigentliche Applikationsmodell ein Modell ist. Deshalb findet der größte Teil der Generierung in dem Metamodell statt, da dieses die Abbildungsregeln des repräsentierten Elements in den Source Code kennt und schreibt. MDA by Daniel Wehrle 12/17

13 Als Eingabedaten verwendet der Generator ein Modell. Dieses wird von einem Parser geparst; der daraus entstehende Parserbaum wird dann vom Metamodellinstantiator unter Verwendung des konfigurierbaren Metamodells instantiiert. Das Eingabeformat ist dabei austauschbar, da verschiedene Parser im Generator verwendet werden können. Bei Open ArchitectureWare kommt dabei XMI zum Einsatz, welches zur Beschreibung von UML Modellen in Textform und zum Diagrammaustausch verwendet werden kann. Nach der Instantiierung des Metamodells kann, basierend auf der Metamodellinstanz, die eigentliche Codegenerierung stattfinden. Als Benutzer des Open ArchitectureWare Frameworks muss man nun das UML Metamodell an seine eigenen Bedürfnisse anpassen. Dies geschieht zum Beispiel mittels Stereotypen und Tagging. Wird später ein Modell geparst, werden die aufgetretenen Stereotypen (also aus dem UML Metamodell verfeinerte Klassen) gegen das entsprechende Element im Metamodell zu instantiieren versuchen. Damit die richtige Klasse instantiiert wird, gibt es eine Metamap Tabelle, die die entsprechenden Stereotypen bestimmten Klassen zuordnet. Diese Konfiguration ist in einer XML Datei enthalten und kann innerhalb von dieser angepasst werden. Gibt es für ein bestimmten Stereotyp keine Klasse, wird die nächst höhere Klasse im Vererbungsbaum instantiiert (z.b. Class statt BesondereClass, wenn BesondereClass Stereotyp ist und Class erweitert). Der Codegenerierungsprozess selber benutzt Templates um den Code zu erzeugen. Als Templateengine wird dabei XPand benutzt. Diese wurde von b+m im Zuge von Open ArchitectureWare entwickelt. Ein Template besteht grundsätzlich aus zwei Aspekten: Dem Code, der über die Metamodellinstanz iteriert, sowie dem zu generierenden Quellcode, gegebenenfalls mit Zugriff auf Attribute des Metamodells. Der OpenArchitectureWare ist vollständig in Eclipse integriert. Dazu existieren mehrere Plug ins um zum Beispiel die benötigten Templates anpassen zu können. Die Generierung selbst wird mittels Apache ANT gesteuert und ausgeführt. Aufgrund der ANT Eclipse Plug ins ist ein Verlassen der IDE dazu nicht notwendig AndroMDA Bei AndroMDA handelt es sich um ein in Java entwickeltes MDA-Tool, welches als Open-Source-Projekt unter der BSD-Lizenz veröffentlicht wird. Die Dokumentation erfolgt ausschließlich über die offizielle Homepage. Zusätzlich existieren wie bei OpenArchitectureWare kostenpflichtige Beratungs- und Schulungsangebote von den Entwickler bereitgestellt. Das Projekt beschäftigt sich bisher nur mit der Entwicklung eines Generatorkerns, eine integrierte Entwicklungsumgebung oder ein integriertes Modellierungstool existieren nicht. Kernkomponente von AndroMDA ist ein Template-basierter Generator, der aus UML- Modellen Quellcode für beliebige Plattformen und Programmiersprachen generiert. Hierzu werden ebenfalls UML-Modelle mittels XMI eingelesen. Die Anpassung der Codegenerierung an eine spezifische Plattform erfolgt mittels Cartridges, aus JAR-Archive, welche Java-Klassen enthalten, die Metafacades darstellen, sowie Templates, die als Schablonen für den zu generierenden Quellcode dienen. MDA by Daniel Wehrle 13/17

14 AndroMDA kommt dabei als Plugin in das Projekt Build Management Tools Maven daher. Als Alternative kann auch das nicht vollständig unterstützte Apache Ant benutzt werden. Die Standard Java XML Parsing Technologie wird zum Einlesen der XMI Modelle verwendet. Die Template Engine Velocity stellen hingegen das Kernstück der Code Erzeugung dar, der Code wird deshalb aus Velocity Templates generiert. AndroMDA verfolgt das Konzept, manuelle Ergänzungen nicht direkt im Generat vorzunehmen. Stattdessen soll von jeder generierten Klasse eine Klasse mit manuellem Code abgeleitet werden (dafür wird einmalig eine Vorlage generiert), um den manuellen Code zu isolieren und zu schützen Zusammenfassung der Vor- und Nachteile von MDA Vorteile: Verbesserung des Entwicklungsprozesses. Kein Bruch in einem Entwicklungsprozess, da diese von der Erstellung einer Spezifikation über ein Modells hin zum Code erfolgt. Die automatisch Generierung von Code direkt aus dem Modell, beschleunigt die Entwicklung von Softwareprojekten. Reduktion der Fehler in der Entwicklung. Der generiertete Code weist keine Fehler auf. Redundanzen innerhalb von Artefakten werden (z.b. zwischen den Deploymentdiscriptoren und den Klassen) durch Modell und Generierung immer synchron gehalten. Investitionsschutz: Durch stark erhöhte Wiederverwendbarkeit durch die Unabhängigkeit von der Plattform (Middleware, Betriebssystem, Hardware) Nachteile: Noch nicht ausgereifte Technologie Durch die ungenügende Spezifizierung von XMI ist eine Übertragung des Modells von einem zum nächsten zumeist nur schwer möglich. Während der Implementierungsphase muss zumeist ständig zwischen Modell und Code hin und her geschaltet werden, um Änderungen vorzunehmen. Dies wird sich erst verbessern, wenn die MDA Tools vollständig in die Entwicklungsumgebung integriert werden. Einige Diagramme und Modell-Elemente, welche für MDA gebraucht werden, sind in UML 1.x noch nicht vorhanden. Da UML 2.0 jedoch von den wenigsten Tools unterstützt wird, können aktuell wichtige Abbildungen im Modell noch nicht vorgenommen werden. Probleme durch fehlendes Round Trip Engeneering MDA by Daniel Wehrle 14/17

15 Der bereits implementierte Sourcecode kann verlorengehen, wenn man das System ummodelliert oder Teile neu designt werden. Ein MDA Projekt muss zumeist als solches gestartet werden, bei einer späteren Umstellung gehen zumeist Teile des Source Codes verloren. Vergrößerung des initialen Projektaufwandes durch: Vergrößerung des Lernaufwandes, um mit der Model Driven Architecture umgehen zu können. Die nötige Entwicklungszeit, um speziell für das Projekt eine Cartridge zu erstellen, kommt zur eigentlichen Entwicklungszeit hinzu Zukunft von MDA Mit der Freigabe von UML 2.0 und einer immer breiter werdenden Unterstützung von der neuen Spezifikation, werden auch die Möglichkeiten zur Code Generierung immer besser. Auch werden die Entwicklungsprozesse immer weiter verbessert, so dass in naher Zukunft fast immer zuerst ein Modell und daraus der Code erstellt wird, was einen Einsatz der MDA stark vereinfachen wird. Experten schätzen sogar, dass in nicht mehr all zu weit entfernter Zukunft die UML / MDA Tools die heutigen Programmiersprachen komplett ablösen und ersetzen werden. So wie bereits Tools im Chip- und Elektronik-Entwicklungs-Umfeld existieren, direkt die Softwareentwicklung übernehmen werden. Siehe hierzu [2] Um dieses Ziel zu erreichen, wird derzeit hart an Mitteln zur Realisierung von Modell zu Modell Transformation gearbeitet, sowie an Techniken zum Round-Trip-Engeneering geforscht und entwickelt. MDA by Daniel Wehrle 15/17

16 Literaturverzeichnis [1] Sturm, Thorsten; Bogner, Marko, Softwareentwicklung auf Basis der Model Driven Architecture, 2003, HMD Praxis der Wirtschaftsinformatik, 231 [2] Uhl, Axel, MDA is ready fort Prime Time, 2003, IEEE Computer Society, 3/2003 [3] Völler, Markus; Stahl, Thomas, Modellgetriebene Softwareentwicklung, 2005, 1. Auflage, dpunkt, Heidelberg [4] Mellor, Stephen J.; Scott, Kendall; Uhl, Axel; Weise, Dirk, MDA Distilled, 2004, 1. Auflage, Addison-Wesley, Bosten [5] Unbekannt, MDA, neuer Ansatz soll Entwicklung effektiver machen, 2004, Computer Woche, 5/2004 [6] Zockoll, Guido, Angetrieben, MDA: Schon da gewesen oder wirklich neu?, 2005, ix, 8/2005 [7] Merkle, Bernhard, Designermodelle, MDA: Überblick über die Tool-Landschaft, 2005, ix, 5/2005 MDA by Daniel Wehrle 16/17

17 Abbildungsverzeichnis Abbildung 1: Die Probleme der Wiederverwendung... 4 Abbildung 2: Vom CIM zum Code... 6 Abbildung 3: Design Phasen MDA...7 Abbildung 4: Höhere Abstraktion geht mit der zeitlichen Entwicklung von Programmiersprachen einher...8 Abbildung 5: Interner Aufbau des ArcStyler MDA by Daniel Wehrle 17/17