Model-Driven Engineering

Transkript

1 Model-Driven Engineering Seminararbeit im Masterstudiengang Information Systems Engineering Sebastian Dreher Fachhochschule Aachen Fachbereich Elektrotechnik und Informationstechnik Eupener Straße 70, Aachen Kurzfassung. In dieser Seminararbeit werden verschiedene Vorgehensmodelle des Model-Driven Engineering, u.a. Computer Aided Software Engineering, Domain Specific Language und Model-Driven Architecture vorgestellt. Ein besonderer Fokus liegt hierbei auf der Entwicklungsmethode Model-Driven Architecture, sowie Forschungsprojekte und Zukunftschancen dieser Methodik. Keywords: Model-Driven Engineering, Model-Driven Architecture, Computer Aided Software Engineering, Domain Specific Language 1 Einleitung Charakteristisch für die Softwareentwicklung der heutigen Zeit sind sich schnell wandelnde, fachliche Anforderungen und rasante technologische Fortschritte, sowie ein hoher Zeit- und Kostendruck. Vor diesem Hintergrund offenbaren sich weitreichende Probleme eines inkrementellen, iterativen Verfahrens oder des traditionellen Wasserfall-Vorgehensmodells. (1) Model-Driven Engineering (dt. Modellgetriebene Softwareentwicklung, kurz MDE) ist ein Oberbegriff für die Anwendung ingenieursmäßiger Techniken, um automatisiert aus formalen Modellen lauffähige Anwendungssoftware zu entwerfen. Durch den Einsatz des MDE wird eine Effizienzsteigerung im Softwareentwicklungsprozess propagiert. Diese soll durch die Anhebung des Abstraktionsniveaus durch Modellbildung im Vergleich zur Softwareentwicklung auf Codeebene erreicht werden. Ein Faktor der Effizienzsteigerung ist die gleichbleibende Qualität des Codes, welcher aus formalen Modellen automatisch erzeugt wird. Man spricht in diesem Zusammenhang von Automation durch Formalisierung. Mit dem Hinzufügen von Abstraktionsebenen wird ebenfalls eine Umsetzung des Paradigmas Separation of Concerns erzwungen, welches die Wartbarkeit eines Softwaresystems erheblich vereinfacht.

2 Interoperabilität, Portabilität und Wiederverwendung zählen hierbei zu den primären Zielen des MDE. Grundlegend wird zwischen drei verschiedenen Implementierungen unterschieden, welche in dieser Ausarbeitung vorgestellt werden: Model Driven Architecture (dt. Modellgetriebene Architektur, kurz MDA) der Object Management Group (OMG) 1 (2) Domain-Specific-Languages (dt. Domänen Spezifische Sprachen, kurz DSL) 2 Computer Aided Software Engineering (dt. Computergestützte Softwareentwicklung, kurz CASE) 3 Da die MDA ein sehr junger Entwicklungsansatz mit interessanten Forschungsthemen ist, wird diese Methodik in den nachfolgenden Kapiteln ausführlich erläutert. Abbildung 1: Ausdruckgsgrad der Lösungsbeschreibung Abbildung 1 zeigt den Ausdrucksgrad der Lösungsbeschreibung und die Einordung der MDE-Implementierungen. Je generischer die Implementierung bzw. Modellabstraktion gehalten ist, desto größer ist der Aufwand der Anpassung des generierten Codes. Für code - bzw. problemspezifische Aufgaben eignet sich die Verwendung von DSLs besonders. Diese Seminararbeit erläutert die zuvor benannten Implementierungen, sowie aktuelle Forschungsansätze, Vor- und Nachteile bzw. Problemstellungen des MDA. 2 Computer Aided Software Engineering Ziel des Computer Aided Software Engineering (kurz CASE) -Ansatzes ist es, Software möglichst vollständig und automatisiert aus fachlichen Beschreibungen zu erstellen. CASE-Tools sind Programme, die den Softwarearchitekten während Planung, Entwurf und Dokumentation automatisiert unterstützen sollen. Diese Tools werden 1 weiterführende Literatur: Poland Petraschl, Model driven architecture, dpunkt.verlag GmbH, weiterführende Literatur: Martin Fowler, Domain-specific Languages, Addison Wesley Verlag, weiterführende Literatur: Thomas J. Bergin, Computer-Aided Software Engineering Issues and Trend for the 1990s and Beyond, Idea Group Publishing, 1993

3 als eigenständige Applikation (Standalone) oder in Form einer Funktionserweiterung (Plugin) für eine entsprechende Entwicklungsumgebung, wie Eclipse (Abbildung 2) angeboten. Im Allgemeinen verbirgt sich hinter dem CASE die Vorstellung eines klassischen Wasserfallmodells unter besonderer Berücksichtigung der Phasen: Analyse, Design und Implementierung. CASE-Werkzeuge gibt es sowohl für 3GL (Third Generation Programming Language) - und 4GL (Fourth Generation Programming Language) Programmiersprachen 4, als auch für objektorientierte Entwicklungen. Abbildung 2: Grafische Java Notation mit dem Omondo-UML Editor (3) Moderne CASE-Tools bieten eine grundlegende Unterstützung für die grafische Notationsweise, Strukturierte Analyse und das Strukturierte Design. Nachfolgend werden diese drei elementaren CASE-Bestandteile erläutert. 2.1 Grafische Notationsweise Mit Hilfe der grafischen Notation können Ablaufdiagramme oder UML-Diagramme in Codegerüste mit Funktionsrümpfen transformiert werden. So können beispielsweise eine Klasse mit Membervariablen und Zugriffs-Modifiern, sowie die Schnittsellen und Kommunikationsmuster grafisch gestaltet werden. 2.2 Strukturierte Analyse Die Strukturierte Analyse wird während der Analysephase zur formalen Systembeschreibung im Rahmen der Softwareentwicklung verwendet. 4

4 2.3 Strukturiertes Design Strukturiertes Design (SD) ist ein Entwurfsmuster in der Softwaretechnik nach Edward Yourdon und Larry Constantine, welches modulares Design unterstützt, um neben der reinen Funktionshierarchie auch die Wechselwirkungen von übergeordneten Modulen zu beschreiben. (4) Es handelt sich hierbei um eine Verfeinerung der zuvor durchgeführten, strukturierten Analyse. Abbildung 3: Strukturiertes Design (Schema), entnommen aus Oft wird das Schema aus Abbildung 3 für die Top-Down Strukturierung von Menüpunkten verwendet, um Hauptkategorien mit zugehörigen Unterkategorien bis hin zur Datenkapselung übersichtlich erfassen zu können. Die Landing Page der Fachhochschule Aachen (Abbildung 4) bietet z.b. den Hauptnavigationspunkt Studienangebote. Dieser wird unterteilt in die Module: Bachelorstudiengänge, Mastersudiengänge, duales Studium etc.. Selektieren wir nun das Modul Masterstudiengang, erhalten wir bezogen auf Abbildung 3, die aufgerufene vordefinierte Datenkapsel, was dem Content der zugrunde liegenden Website entspricht.

5 Abbildung 4: Landing-Page Menü der FH-Aachen (5) 3 Domain Specific Language Unter DLSs werden im Allgemeinen abstrakte Sprachen bezeichnet, welche für ein bestimmtes Problem, die Domäne, entworfen und implementiert werden. Im Vergleich zu universell einsetzbaren Programmiersprachen, wie C/C++, Java, etc. erzeugen DSLs bedeutend weniger Overhead und Redundanz, aufgrund des meist beschränkten Umfangs. DSLs werden in Verbindung mit Codegeneratoren und Interpretern verwendet, um die Beschreibung eines Sachverhaltes oder Problems deklarativ zu gestalten. Im Folgenden werden die einzelnen Prozessschritte von der Domänenbeschreibung bis hin zum fertigen Code unter Verwendung der DSL beschrieben. (6) Die Vorgehensweise bei der Entwicklung einer DSL, lässt sich wie folgt beschreiben: Domänenbeschreibung Die Domänenbeschreibung ist gekennzeichnet durch eine fachliche oder technische Wissensbeschreibung des darzustellenden Gesamtsystems. Hier werden Grenzen und Schnittstellen, sowie das Verhalten klar definiert. Metamodellierung Abgrenzung: Nichtberücksichtigung irrelevanter Objekte Reduktion: Weglassen von Objektdetails Dekomposition: Zerlegung, Auflösung in einzelne Segmente Aggregation: Vereinigung von Segmenten zu einem Ganzen Abstraktion: Begriffs- bzw. Klassenbildung Ableiten der DSL Externe DSL: Eine von Grund auf neu definierte Sprache. Sowohl die konkrete Syntax als auch die Semantik können hier frei definiert werden. Interne DSL: Eine interne DSL ist eine echte Untermenge einer generelleren Sprache. Modellierung des Systems unter Verwendung der DSL Validierung des Systems Glue-Code Manuelle Anpassung des Implemetierungscodes

6 4 Model Driven Architecture MDA bietet ein offenes, herstellerneutrales Vorgehen, um während des Softwareentwicklungsprozesses die Business- und Applikationslogik, sowie Plattformtechnologie voneinander zu trennen. Abbildung 5: Integration der MDA (2) Bei der Modellierung mit MDA wird berücksichtigt, dass ein einziges Modell nicht die Komplexität eines Software-Gesamtsystems abbilden kann. Entweder wird das fachliche Detail im Zusammenhang mit der Geschäftslogik zu intensiv dargestellt, was zu einer überladenen und nicht überschaubaren Komplexität führt, oder es wird nicht mit genügend Detailtreue abgebildet, was zu einer Unschärfe der Anforderungen führen kann. Als Konsequenz führt MDA eine Trennung des Gesamtmodelles in Teil- Modelle durch (Abbildung 5). Hierbei liegt der Scope nicht auf einer vollständigen Automatisierung der Code-Generierung, denn diese variiert in Abhängigkeit der fachlichen Anforderung zwischen 20 und 80 Prozent. (7) Abbildung 6: Schema unter Anwendung der MDA Abbildung 6 zeigt einen schematischen Top-Down-Ansatz, mit welchem die verschiedenen Phasen durchlaufen werden.

7 4.1 Computation Independent Model (CIM) Mit Hilfe des CIM wird die Geschäfts- oder Domänensicht des zu entwickelnden Softwaresystems modelliert. Das CIM ist im Rahmen der MDA der Modelltyp mit der höchsten Abstraktionsebene. Es ist unabhängig von technischen Aspekten der Implementierung, d.h. es beschreibt keine internen Strukturen oder das innere Verhalten des Softwaresystems. (8) Als Werkzeuge kommen hierbei umgangssprachliche Beschreibungen, Use-Case-Diagramme, Interaktionsdiagramme und Aktivitätsdiagramme zum Einsatz. 4.2 Platform Independent Model (PIM) Das PIM ist ein plattformunabhängiges Modell für Geschäftsprozesse, welches logische Prozesse abstrahiert. Das zuvor erstellte CIM wird hierbei mit Hilfe einer Model- Model-Transformation in ein PIM überführt (Abbildung 7). Durch ein UML-Profil wird die Darstellung fachlicher Elemente (Services, Business Classes, Business Rules) projekt- und anwendungsspezifisch vorgegeben. 4.3 Platform Specific Model (PSM) Das PSM ist ein abstraktes, plattformabhängiges Modell der Zielarchitektur. Es entsteht durch die Transformation des CIM unter Berücksichtigung spezieller Architektureigenschaften und Services der späteren Zielplattform (Abbildung 7), so z.b. J2EE, Corba oder XML. 4.4 Codemodell Nach einer weiteren Transformation wird das PSM in den Implementierungscode der zuvor gewählten Plattform (Abbildung 7) überführt. Wie bereits erwähnt, erhebt das MDA-Verfahren keinen Anspruch auf eine vollständige Codegenerierung. Gegebenenfalls müssen Glue-Code 5 oder das Ausprogrammieren von Funktionsrümpfen manuell vorgenommen werden. 5 Glue-Code: funktionsfreier Quellcode der einzelne Software-Module untereinander verbindet, welche sonst nicht kompatibel zueinander wären

8 Abbildung 7: MDA-Transformationsbeispiel (9) Abbildung 7 zeigt den Transformations-Ablauf der verschiedenen Modelle von 4.1 bis Forschungsansätze des MDA Obwohl MDE noch nicht lange in den wissenschaftlichen Bereichen vertreten ist, gibt es bereits einen Großteil an nationalen und internationalen Forschungsprojekten und Konferenzen. Dieses Kapitel gibt einen groben Überblick über nationale Forschungseinrichtungen im Bereich MDE, sowie die zugehörigen Projekte. Im Jahr wurde 2010 an der TU München - Lehrstuhl IV: Software & Systems Engineering ein MDE-Kompetenzzentrum gegründet, welches die Forschungsaktivitäten in den folgenden Bereichen intensiviert hat. (10) Seamless model-based development Model-based development of mechatronic systems Formal specification of (mostly embedded) software systems Model-based debugging Analysis of costs and benefits of model-based development of embedded software systems in the car industry Modeling of probabilistic systems Formal semantics of UML2 Transition from documents in natural language to system models Model validation Model-based deployment Model-based testing

9 Model-based safety-cases Im folgenden Auszug der aktuellen Forschungsprojekte der TU München lassen sich als Förderungspartner u.a. das BMBF (Bundesministerium für Bildung und Forschung), BMWi (Bundesministeriums für Wirtschaft und Technologie), Altran Technologies ( sowie Siemens Automation finden. Große Institutionen und Firmen zeigen also durchaus (finanzielles) Interesse in diesem Forschungsbereich. (11) SPES SPES 2020 ist ein vom BMBF gefördertes Forschungsprojekt zur Entwicklung einer Methodik zur durchgängig, modellbasierten Entwicklung von eingebetteten Systemen. Im Rahmen des Projekts werden Lösungen für die domänenübergreifende und modellbasierte Entwicklung von eingebetteter Software erarbeitet. Modellbasierte Verfahren auf Basis eines soliden mathematischen Fundaments ermöglichen eine effiziente Entwicklung eingebetteter Systeme, beginnend bei den initialen Kundenanforderungen über den Entwurf und die Implementierung bis hin zur Verifikation und Zertifizierung von Systemen. (11) Analyse der Kosten und des Nutzen modellbasierter Entwicklung eingebetteter Softwaresysteme in der Automobilindustrie. In Zusammenarbeit mit dem Technologieberatungsunternehmen Altran werden die notwenigen Kosten für eine Modellbasierte Entwicklung und der daraus resultierende Nutzen analysiert. Ziel ist es wesentliche Kosten- und Nutzentreiber zu identifizieren und zu analysieren wie man die Wirtschaftlichkeit der modellbasierten Entwicklung optimieren kann. Die Ergebnisse der Arbeit werden aus Fallstudiengesprächen und einer globalen Studie abgeleitet. (11) AutoVIBN. Gefördert durch das BMWi (AiF) entwickelt das Kompetenzzentrum Modellbasierte Entwicklung zusammen mit dem iwb und mehreren Industriepartnern Beschreibungstechniken und Methoden für die logische Verhaltensmodellierung mechatronischer Systeme im Anlagenbau. Diese Modelle dienen der Unterstützung im Entwicklungsprozess durch Exploration und Simulation verschiedener Lösungsansatze auf logischer Ebene. Zudem lassen sich die Modelle als Basis für die Generierung abgeleiteter Modell nutzen, wie etwa von Modellen für die virtuelle Inbetriebnahme. (11) FlaSCo. Eine Machbarkeitsstudie der modellbasierten Entwicklung eingebetteter Systeme im industriellen Umfeld: von Anforderungen bis zum Entwurf n Zusammenarbeit mit Siemens Automation. (11) In der Universität Ulm - Institut für Programmiermethodik und Compilerbau gibt es seit 2009 ebenfalls einen Forschungsbereich zum MDE, wodurch das Projekt Active Charts entstanden ist: Wir beschäftigen uns mit der Frage, wie mächtigere Soft-

10 ware-werkzeuge konstruiert werden können, welche die Synchronisation von Analyse/Entwurfs- und Implementierungsartefakten unterstützen bzw. sicherstellen können ohne den Entwickler in seinen bisherigen Implementierungsmöglichkeiten zu sehr einzuschränken. (12) Unser Ansatz ActiveCharts kombiniert Modelle aus den Analyse/Design-Phasen und (handgeschriebenen) Code aus der Implementierungsphase auf eine neue Art: Wir modellieren den Kontrollfluss einer Anwendung mit UML 2 Aktivitätsdiagrammen, die von einer Laufzeitumgebung (ActiveChartsIDE) interpretiert werden. Mit dieser Laufzeitumgebung können die Aktivitätsdiagramme simuliert und visualisiert werden. Funktionen wie beispielsweise Breakpoints oder schrittweises Vorgehen ermöglichen ein einfaches Debuggen der Anwendung. Analyse- bzw. Designartefakte werden in unserem Ansatz nahtlos für die Implementierungsphase übernommen. Wir wollen damit die Lücken zwischen den unterschiedlichen Phasen im Softwareentwicklungsprozess verkleinern und die Dokumentation und die Wartbarkeit von Softwareprodukten verbessern. (13) Einen weiteren, interessanten Ansatz verfolgt das Transferprojekt Agile Model Driven Architecture an der Universität Leipzig. Hier werden zwei Ansätze kombiniert, die augenscheinlich nichts miteinander zu tun haben MDE der Object Management Group und Agile Softwareentwicklung. Im Kern geht es bei agiler Softwareentwicklung um möglichst häufige Rückkopplungsprozesse und zyklisches (iteratives) Vorgehen auf allen Ebenen: bei der Programmierung, im Team und beim Management. Im Vergleich zum direkten Vorgehensmodell wird die Zielsetzung nicht ausschließlich zu Beginn der Softwareentwicklung erarbeitet, sondern kann während des Entwicklungsprozesses noch angepasst werden. (14) Unser Lösungsansatz lautet: "Agile MDA" oder "Prefabricated Architectures" oder "MDA Domesticated" oder einfach "Leipziger Softwareprozessmodell". Das Leipziger Software-Prozessmodell (LSP) versucht das Beste beider Welten miteinander zu verbinden. Modelle, die die Fachlichkeit möglichst umfassend ausdrücken, aber keine Generierung um jeden Preis, genauso wie kontinuierliche Einbeziehung des Anwenders und schlanke Inkremente, ohne dabei die Pandora-Büchse des unkontrollierten Hacking zu öffnen. (15) Ein Blick auf die Publikationswebsite des Frauenhofer Instituts (16) zeigt anhand der Dissertation A methodology for pattern-oriented model-driven testing of reactive software systems von Vouffo-Feudjio, A.-G., dass auch dort Ansätze des MDE erforscht werden: The thesis presents a catalogue of test design patterns, along with a methodology for the proposed approach. The methodology is based on a new notation called Unified Test Modeling Language (UTML), specifically designed to support patternoriented model-driven testing. UTML is a Domain-Specific Modeling Language (DSML) for designing test objectives, test architectures, test data and test behaviour at a high level of abstraction, using predefined test design patterns. The result are socalled abstract test models, that can then be subsequently refined through a series of

11 iterative transformation processes into executable test sequences, scripts or documentation artifacts. (17) 6 Offene Punkte beim MDA Da das MDE eine relativ junge Entwicklungsmethode beschreibt, gibt es noch einige ungeklärte Aspekte, die bei der Einführung dieser Methodik berücksichtigt werden sollten. Bei der Umsetzung der Standards wirken viele Tools keinesfalls überzeugend. Bezug nehmend auf die Wirtschaftlichkeit dieses Verfahrens - speziell im Vergleich zur konventionellen Entwicklung, gibt es kaum verfügbare Belege. Es stellt sich also die Frage, ob die Einführung des MDE für die jeweilige Unternehmung rentabel ist. So kommen Lewis, G.A. und Wrage, L. in einer MDA Studie im Jahr 2005 (18) zu dem Resultat, dass die Entwicklungszeit unter Einsatz von MDA zunächst zunimmt und sich nur lohnt, wenn mehrere Projekte dieser Art durchgeführt werden. Ergebnisse aktuellerer Studien lagen zum Zeitpunkt des Verfassens dieser Arbeit nicht vor. Abbildung 8: Kernaussagen aus MDA Studien, entnommen aus Model- Driven Architecture: Konzeption, Einordnung und Wirtschaftlichkeit [S.60] von Johannes Vetter

12 Die Frage nach der Rentabilität kann also nicht mit einem einfachen Ja oder Nein beantwortet werden. Vielmehr müssen eine Vielzahl von Aspekten gegeneinander ab gewägt werden. Das Internetportal Software-Engineering ( listet hierzu die nachfolgenden Punkte, welche an dieser Stelle übernommen und nach fachlicher bzw. wirtschaftlicher Relevanz sortiert wurden. (19) 6.1 Fachliche Relevanz Reengineering / Wartung MDA ist ursprünglich für Neuentwicklungen gedacht. Wie können aber bestehende Softwaresysteme in MDA übernommen werden, so dass die Weiterentwicklung mit Hilfe dieser Methodik erfolgen kann? Ein weiterer Aspekt ist die Erzeugung von Releases, Patches oder Updates, welches ein wichtiger Bestandteil der laufenden Wartung von Anwendungen ist. Wie geht MDA damit um? Ist es notwendig jedes Mal das komplette System neu installieren? Stabilität des Datenmodells Änderungen am Datenmodell können großen Aufwand nach sich ziehen, der bei der Änderung des Modells nicht sofort sichtbar ist. Es ist für den Designer oder Entwickler beispielsweise sehr einfach, im Modellierungstool ein Attribut zu einer persistenten Klasse hinzuzufügen. Die MDA-Generatoren erzeugen dann im Datenbankskript für die Tabelle, die zu der Klasse gehört, eine weitere Spalte. Dadurch entsteht nun die Notwendigkeit, zumindest die neue Spalte in den bestehenden Zeilen mit einem definierten Leerwert zu füllen. Entfremdung des Entwicklers vom Code Der generierte Code ist für den Entwickler nur noch schwer verständlich und nachvollziehbar. Weiterhin stellt sich das Problem mit Fehlern in den Codegeneratoren auf neue Weise wieder. Es wird dadurch potenziert, dass die Generatoren teilweise Code erzeugen, der auf Annahmen basiert, welche die Architekten bei der Entwicklung der Templates für den Codegenerator gemacht haben und welche dem Entwickler unbekannt sind. Resultierend hierbei ist Code, der von den Entwicklern in vielen Fällen schwer zu verstehen ist. Aus Sicht des Entwicklers ist es schwierig Codefragmenten zu vertrauen, die nicht selber entwickelt wurden und kaum lesbar sind. Unzulänglichkeiten in den Tools Die Erwartungshaltungen der Entwickler sind derzeit nur schwer zu erfüllen. Dies betrifft sowohl die funktionalen, als auch die nicht-funktionalen Aspekte.

13 Zu den nicht-funktionalen Einschränkungen gehört z. B. die Performance. So dauert beispielsweise das Umbenennen einer Implementierungsklasse im Code in der Regel nur Sekunden. Inklusive der damit verbundenen Nachfolgeänderungen (z. B. Umbenennung der Datei im Konfigurationsmanagementsystem) bewegt man sich jedoch im Minutenbereich. Die Umbenennung einer Klasse im UML-Modell eines MDA-Tools hingegen kann schon aufwändiger werden. Der MDA-Codegenerator muss den gesamten Code neu generieren. Die Arbeitsumgebung muss konsistent gehalten werden. Dazu gehört, dass alle Artefakte mit dem alten Namen gelöscht werden. 6.2 Wirtschaftliche Relevanz ROI (Return-on-Investment) Bisher gibt es nur sehr wenige Überlegungen, ab wann sich der Einsatz von MDA lohnt. Für den Einsatz von MDA sind viele Vorbereitungen und Vorarbeiten notwendig. Hierzu gehören nicht nur Schulungen der Entwickler, sondern auch konzeptionelle Arbeiten (z. B. Anpassung des Softwareentwicklungsprozesses). Dies sind nicht unerhebliche Aufwände. EAI (Enterprise Application Integration) Modellierung auf hoher Ebene erscheint auf den ersten Blick sinnvoll. Neue Anwendungen laufen aber selten für sich isoliert, sondern müssen in eine vorhandene Anwendungslandschaft integriert werden. Wie kann dies in der MDA-basierten Entwicklung berücksichtigt werden? Herstellerabhängigkeit Da der MDA-Standard derzeit noch nicht vollständig und einheitlich von den Toolherstellern umgesetzt wird, bedeutet die Festlegung auf ein Werkzeug damit auch eine gewisse Herstellerabhängigkeit. Solche Abhängigkeiten haben sich in der Vergangenheit jedoch oftmals als negativ herausgestellt, da eine Kompatibilität zu Konkurrenz-Produkten meist nicht gegeben ist. 7 Fazit Abschließend ist festzuhalten, dass sich die modellgetriebene Softwareentwicklung noch in einem sehr frühen Entwicklungsstadium befindet. So gibt es Ansätze verschiedener Hersteller, unterstützende Tools bereitzustellen, aber oft ist der generierte Output schwer wartbar oder die Umsetzung der Standardisierungen ist nicht ausreichend implementiert. Dies kann zu Problemen im Zusammenspiel mit anderen Softwareprodukten führen. Langzeiterfolge des MDA-Ansatzes sind sehr eng mit der

14 Entwicklung marktreifer, praxistauglicher MDA-Tools, speziell im Bereich der Model-to-Model-Transformation verknüpft. (20) International, als auch auf nationaler Ebene gibt es verschiedene, meist universitäre Forschungsprojekte, deren gemeinsames Ziel in der Optimierung der MDE- Entwicklungsmethoden liegt, um die Wirtschaftlichkeit dieses Verfahrens weiterhin zu optimieren. Gerade bei der Durchführung komplexer, großangesetzter Softwareentwicklungen wäre die Etablierung vollständiger, standardisierter MDE-Tools eine große Bereicherung. Es bleibt zu hoffen, dass Techniken, wie das MDA noch zu einem Durchbruch finden und nicht irgendwann lautlos verschwunden sein werden. Wie gezeigt wurde, gibt es noch offene Punkte beim MDA die besonders für Entwickler eine Eintrittsbarriere auf Grund der hohen Komplexität darstellen. Ein großer Vorteil von DSL hingegen ist, dass die Sprachkonzepte auf die Zieldomäne abgestimmt sind. Das heißt, dass in möglichst natürlicher Sprache, bezogen auf die Domäne, Sachverhalte formuliert werden können. Je nach Grad der Abstraktion und Syntax können dies auch Nicht-Entwickler übernehmen oder Experten der Domäne, ohne IT-Kenntnisse. Weiterhin ist die allgemeine Produktivität innerhalb des Projekts deutlich erhöht, sobald die DSL einmal fertiggestellt ist, da dann auf höherem Abstraktionsgrad gearbeitet werden kann. (21) 8 Literaturverzeichnis 1. Anneke Kleppe, Jos Warmer, Wim Bast. MDA Explained, The Practice. s.l. : Addison Wesley, OMG. The Architecture of Choice for a Changing World. [Online] 27 06, [Cited: 07 16, 2012.] Omondo UML. [Online] [Cited: 09 20, 2012.] /refactoring/refactor_class_class_diagram.png. 4. Wikipedia. Strukturiertes Design. [Online] [Cited: 09 20, 2012.] 5. FH-Aachen. Landing-Page. [Online] 6. Wikipedia. Domänenspezifische Sprache. [Online] [Cited: 08 12, 2012.] 7. Model Driven Architecture. [Online] 04 27, [Cited: 07 16, 2012.] 8. VSEK. Computation Independent Model (CIM). [Online] [Cited: 07 16, 2012.] 9. Thomas, Dr. Marc. MDA Praktisch. [PDF] s.l. : itemis GmbH & Co. KG, TU München - Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering. Research Areas. [Online] [Cited: 08 21, 2012.]

15 11. TU München - Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering. Aktuelle Projekte. [Online] [Cited: 08 21, 2012.] Universität Ulm. Model Driven Development. [Online] [Cited: 08 20, 2012.] Universität Ulm. ActiveCharts. [Online] [Cited: , 2012.] IT-Agile DIE EXPERTEN FÜR AGILE SOFTWAREENTWICKLUNG. Was ist agile Softwareentwicklung? [Online] [Cited: 07 26, 2012.] Universität Leipzig. Transferprojekt "Agile Model-Driven Architecture". [Online] [Cited: 07 26, 2012.] Frauenhofer. Schlagwort Suche: Model-Driven Engineering. [Online] [Cited: 07 26, 2012.] Vouffo-Feudjio, A.-G. Frauenhofer. A methodology for pattern-oriented model-driven testing of reactive software systems. [Online] [Cited: 07 26, 2012.] Vetter, Johannes. Model-Drive Architecture. Konzeption, Einordnung und Wirtschaftlichkeit. Ravensburg : GRIN Verlag, Software-Engineering. MDA in der Wissenschaft. [Online] [Cited: 07 23, 2012.] Thomas Stahl, Markus Völter. Modellgetriebene Softwareentwicklung Techniken, Engineering, Management. s.l. : dpunkt-verlag, Maximilian Stroh. Hauptseminar Web Engineering im SS Model Driven Development and Domain Specific Languages. [Online] [Cited: 09 21, 2012.]