Modellgetriebene Softwareentwicklung

Transkript

1 Technische Universität Berlin Ausarbeitung SWT Praxis-Seminar SS 2008 Modellgetriebene Softwareentwicklung Roman P. Zimmer (300835) 29. Juni 2008 Betreut durch Dr. Stephan Herrmann und Marco Mosconi

2 Inhaltsverzeichnis 1 Einleitung Traditionelle Softwareentwicklung Problematik Unied Modeling Language Anwendungs-Frameworks am Beispiel von Ruby on Rails Domainbasierte Modellierung Die Vision von Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung Denition nach [1] Formale Modelle Lauähige Software erzeugen Automatisch Funktionsweise Domäne Modellierungssprachen Domain Specic Language Modellierung Transformationen Abschlieÿende Worte Kernkonzepte Gründe für Modellgetriebene Softwareentwicklung Ausblick Fazit

3 1 Einleitung 1.1 Traditionelle Softwareentwicklung Problematik Es gibt unzählige Möglichkeiten, Software zu implementieren. In der Regel stellen die Ansprüche an das System die Softwareentwickler vor gewisse Probleme. Neben dem Erfüllen der funktionalen Anforderungen soll es u. a. meist modular aufgebaut, in groÿen Teilen wiederverwendbar, einfach wartbar sein. Gerade im Hinblick auf die zunehmende Komplexität der Softwaresysteme erforderte dies ein sinnvoll durchdachtes Design. Um die dafür nötige Abstraktion zu erreichen, haben sich insbesondere in der objektorientierte Programmierung (OOP) Modellierungssprachen etabliert Unied Modeling Language Unied Modeling Language (UML) ist wohl eine der populärsten Modellierungssprache, die sich im Laufe der 90er Jahre durchsetzte. Durch die UML werden eine Vielzahl von unterschiedlichen Diagrammtypen deniert, wobei hier nur auf das Klassendiagramm eingegangen werden soll. UML-Klassendiagramme sind darauf ausgelegt, abgegrenzte Systeme im Kontext der Objektorientierung zu modellieren, wobei sie dabei auf keine Domäne beschränkt sind. Ist solch ein System erst einmal modelliert, wird dies in der Regel manuell sprich durch einen oder mehrere Softwareentwickler oder durch entsprechende Tools in Quelltext einer beliebigen OOP-Sprache überführt. Daraus ergeben sich jedoch eine Reihe von Problemen. Zum einen ist solch eine Abbildung durch einen Programmierer u. U. sehr interpretativ. Selbst bei der Verwendung von Tools ist man auf die Klassendiagramm- Interpretation der Tools-Entwickler angewiesen. Zum anderen wird nach dem erstmaligen Erstellen des Quelltextgrundgerüsts fortan nur noch im Code selber gearbeitet. Eine Gewährleistung, dass das Diagramm den aktuellen Quelltext repräsentiert, gibt es dann nicht mehr. In der Regel kommt es zwangsläug im Zuge der Softwareevolution zur Divergenz von Quelltext und Modell, welche letzten Endes zu einer Diskrepanz führt 1. Das Klassendiagramm dient dann nur noch zu Dokumentationszwecken ohne jedwede Garantie auf Richtigkeit. Ein weiterer nicht zu vergessener Nachteil ist die Tatsache, dass sich Klassendiagramme meist an Softwareentwickler richten und nur von ihnen verstanden werden andere beteiligte Experten haben das Nachsehen. 1 Selbst die besten UML-Werkzeuge können dies nicht wirklich verhindern. 3

4 1.1.3 Anwendungs-Frameworks am Beispiel von Ruby on Rails Frameworks erleichtern die Arbeit von Entwicklern ungemein, in dem sie ihn von lästigen und sich immer wiederholenden Programmieraufgaben befreien. Anhand von wenigen Parametern generieren sie Basisbestandteile des Systems. Ein populäres Beispiel dafür ist Ruby on Rails (Rails). Rails ist u. a. in der Lage aus Datenbanktabellen ein gesamtes CRUD-Interface ohne groÿes Zutun des Entwicklers zu generieren. Ändert man die Tabelle, so ändert sich auch das entsprechende Interface zur Bearbeitung. Weiteres Prinzip, welches hilft, ein gutes Design umzusetzen: Rails setzt das DRY-Prinzip um. So ist jede Information nur einmal im System vorhanden und somit lokal anpassbar. So viel Arbeit dies dem Programmierer abnimmt, so limitiert ist diese Generierung dann doch. Sie beschränkt sich hauptsächlich auf das Datenbankmodell und setzt direktes Auseinandersetzen mit der verwendeten Technologie voraus. Dadurch wird das System auf einem relativ niedrigen Abstraktionslevel entwickelt, welches sich für Nicht- Entwickler nicht erschlieÿt Domainbasierte Modellierung Schön wäre es doch, wenn man ein Abstraktionslevel erreichen könnte, welches für Domainexperten und Softwareentwickler gleichermaÿen aussagekräftig ist. Dabei dürfte es trotz der Abstraktion nichts an seiner Präzision und Aussagekraft verlieren. Diesen Spagat schat die domainbasierte Modellierung. Sie hat zum Ziel, das System mit Sprachmitteln aus der Domäne zu beschreiben. Die Modelle enthalten so viel Semantik, dass sie gewissermaÿen den gleichen Stellenwert wie Code erreichen. Dabei bleiben sie abstrakt genug und hängen insbesondere von keiner Zielplattform oder -technologie ab. 1.2 Die Vision von Modellgetriebene Softwareentwicklung Die Vision hinter der Modellgetriebene Softwareentwicklung (MDSD) ist es nun, auf Basis eines domainbasierten Modells sozusagen auf Knopfdruck Software für eine beliebige Zielplattform zu generieren. In wie weit dies vielleicht schon heute Realität ist oder ob dieses ehrgeizige Ziel Utopie bleiben wird, soll u. a. in dieser Ausarbeitung näher beleuchtet werden. Beispiel Es soll eine Handyapplikation zum An- und Abmelden für Konferenzen entwickelt werden. Mittels domainbasierter Entwicklung würde z. B. ein Modell dabei herauskommen, wie es in 1.1 gezeigt wird. Je nach Auswahl, soll der Benutzer durch einen An- bzw. Abmeldeprozess geführt werden. Dabei bekommt er stets Feedback durch das System. 4

5 Man beachte insbesondere die Modellelemente für SMS und die GUI. An diesem Beispiel sieht man gut, dass das System auch für Nicht-Entwickler intuitiv verständlich ist, dabei aber nicht an Präzision einbüÿt. Anhand dieses Beispiels sieht man auch die hinter MDSD steckende Vision: Per Knopfdruck kann entschieden werden, für welche Zielplattform aus ein und demselben Modell ein lauähiges Softwareprodukt wird. Die Tools generieren uns automatisch das entsprechende Programm (siehe Run As in 1.1). Abbildung 1.1: Eine simple, domainbasierte modellierte Handyapplikation. 5

6 2 Modellgetriebene Softwareentwicklung 2.1 Denition nach [1] Modellgetriebene Softwareentwicklung (MDSD) ist ein Oberbegri für Techniken, die aus formalen Modellen automatisiert lauähige Software erzeugen. Im Folgenden sollen die wichtigen Aspekte dieser Denition noch einmal aus der Nähe betrachtet werden Formale Modelle Formale Modell beschreiben die anwendungsspezischen Anforderungen an die Software. Formal in diesem Zusammenhang bedeutet, dass das Modell einen beliebigen Aspekt des Programms vollständig speziziert. Die Repräsentation von formalen Modellen erfolgt nicht immer zwangsläug in gra- scher oder UML-basierter Form. Vielmehr ist oft genug die textuelle Notation ein adäquates Mittel zur Beschreibung von formalen Modellen Lauähige Software erzeugen Das Resultat von MDSD ist lauähige Software. Wird ein formales Modell dagegen nur zu Dokumentationszwecken oder als Grundlage für eine manuelle Implementation speziziert, so spricht man nicht von modellgetriebener Entwicklung. Um aus Modellen lauähige Software zu erzeugen, gibt es hauptsächlich zwei Herangehensweisen: mittels Generatoren und mittels Interpretern. Generatoren übersetzen ein Modell in Quelltext einer beliebigen Programmiersprache, während Interpreter Modelle einlesen und direkt ausführen. In beiden Ansätzen entsteht am Ende lauähige Software Automatisch Die Überführung von einem Modell zur Software soll automatisch bzw. automatisierbar sein. D. h. konkret, dass ein Build-Prozess denierbar ist, der als Eingabe ein formales Modell bekommt und bei dem am Ende ein lauähiges Stück Software als Ergebnis steht. Im Entwicklungsprozess nehmen die Modelle die Rolle von Software ein. Im Gegensatz zu Wizards, die am Anfang der Entwicklung beim Erstellen eines Grundgerüstes helfen, welches fortan manuell auszubauen ist, werden in der MDSD Änderungen an 6

7 den Modellen vorgenommen. Generierte Artefakte sind temporäre Zwischenprodukte, bei Modelländerung wird einfach alles aus dem Modell neu erzeugt. Dies hat zur Folge, dass die Modelle immer den aktuellen Stand widerspiegeln und der Code einheitlich und synchron mit den Modellen bleibt. In wie weit tatsächlich alles automatisch generiert werden kann oder ob manuelles Implementieren nötig sind, soll im Laufe der Ausarbeitung deutlich gemacht werden. 2.2 Funktionsweise Die Entwicklung mittels MDSD teilt sich in drei Phasen (siehe Modellentwicklung in der Domäne 2. Transformation des Modells 3. Generierung plattformspezischer Artefakte Abbildung 2.1: Die drei Phasen der MDSD. Im Folgenden werden alle Phasen genauer betrachtet Domäne MDSD arbeitet immer im Rahmen einer Domäne. Eine Domäne ist ein begrenztes Interessengebiet oder ein bestimmter Einsatzbereich von Software ([3]). Dabei werden Domänen ggf. in Subdomänen unterteilt, um die Komplexität einer Domäne besser beherrschbar zu machen Modellierungssprachen Bevor die Modellierung in der Domäne genauer betrachtet wird, soll kurz der Begri der Modellierungssprache eingeführt werden. Modellierungssprachen bestehen aus: 7

8 Metamodell Abstrakte Syntax Statische Semantik Konkrete Syntax Metamodell Das Metamodell bildet die Basis der Modellierungssprache. Es ist eine formalisierte Beschreibung von Modellen, die die Struktur einer Domäne widerspiegelt. Dabei wird das Metamodell wieder durch ein Modell das sogenannte Metametamodell beschrieben. Ein Beispiel für ein Metamodell ist die UML. Dessen Metametamodell ist Meta Object Facility (MOF). Ein weiteres Beispiel für ein Metamodell ist eine Klasse in Java mit der Programmiersprache Java als Metametamodell. Abstrakte Syntax Das Metamodell deniert eine abstrakte Syntax. Diese besteht aus den Elementen des Metamodells und beschreibt deren Beziehungen untereinander. Die abstrakte Syntax ist dabei von der konkreten Syntax unterscheiden. Z. B. kann eine abstrakte Syntax aussagen, dass es Klassen mit Namen gibt, die von einander abgeleitet werden können. Wie diese nun zu repräsentieren sind, sagt die konkrete Syntax. Statische Semantik Die statische Semantik konkretisiert die abstrakte Syntax, in dem sie Bedingungen deniert, die für die Wohlgeformtheit von Modellen wichtig sind. Diese sogenannten Constraints hängen von der abstrakten Syntax ab. Die statische Semantik ermöglicht es, Fehler in der Modellierung frühzeitig zu erkennen. Konkrete Syntax Die konkrete Syntax gibt an, wie die abstrakte Syntax zu repräsentieren ist. Dies kann sowohl durch eine grasche als auch durch eine textuelle Notation erfolgen. UML z. B. wird normalerweise grasche dargestellt, man könnte sich aber auch genauso gut eine textuelle Repräsentation für UML überlegen. Eine abstrakte Syntax kann durch verschiedene konkrete ausgedrückt werden Domain Specic Language Domain Specic Language (DSL) ist eine Modellierungssprache innerhalb der Domäne. Die Bedeutung der einzelnen Sprachelemente muss noch klar deniert werden (sogenannte dynamische Syntax im Gegensatz zur konkreten). 8

9 DSLs können einfach gehalten oder beliebig umfangreich sein. In der Regel wählt man nicht UML, da es zu universell, allgemein und mächtig ist. Schon eher wählt man aber einschränkende UML-Dialekte, die mittels denierten UML-Prolen auf die konkrete Domäne angepasst sind. Letzten Endes möchte man nämlich nur die Probleme der zugehörigen Domäne modellieren können, jedoch nichts, was auÿerhalb liegt. Vorteile der Verwendung von DSLs im Vergleich zu allgemeinen Programmiersprachen sind u. a., dass Redundanzen vermindert werden und der Sachverhalt deklarativ beschrieben werden kann. So kann auf technischen Code verzichtet werden, was natürlich die Verständlichkeit für Nicht-Entwickler erhöht. Beispieldomänen Häug zitiert als fachliche Domänen wird z. B. das Finanz- und Versicherungswesen. Es zeichnet sich durch einen sehr speziellen Sprachgebrauch aus, der sich gut zum Abbilden in eine DSL eignet. Weitere Beispiele für Domänen sind: Simulationsanwendungen Web-basierte Businessanwendungen Eingebettete Software (siehe 2.2) Abbildung 2.2: Unterteilung einer Domäne durch Subdomänen anhand der Domäne Eingebettete Software Modellierung Die konkreten Modelle werden in der Domäne mittels der DSL entwickelt. Sie werden als Instanzen des zugrundeliegenden Metamodells angesehen ähnlich wie Objekte Instanzen von Klassen einer Programmiersprache sind. 9

10 Bei der Modellierung wird besonders darauf geachtet, dass sie anforderungsbezogen erfolgt. Modelliert wird das Verhalten. Letzten Endes soll das `Was im Mittelpunkt stehen und nicht das `Wie. Die Modellentwickler müssen sich dabei immer die Frage stellen, wie viel Semantik sie in das konkrete Modell einbauen wollen. Am Ende dieses Prozess steht ein Modell, welches das System beschreibt. In der Regel reicht ein Modell zum Beschreiben des Gesamtsystems nicht aus, sodass man dafür mehrere Modelle erstellen wird. Gerade bei der Entwicklung mittels MDSD ist die Modellierung Teil der Programmierung des Systems. Wie schon weiter vorne erwähnt, nehmen die Modelle hier die Rolle von Code ein. Auch wenn der hinter MDSD stehende Prozess auf Automatisierung ausgerichtet ist, muss die Erstellung, Wartung und Erweiterung von Modellen natürlich von Hand erledigt werden. Mittels Modellen kann ein System in der Regel kompakter als per Code dargestellt werden. Dies ist u. a. dem DRY-Konzept geschuldet, welches in der MDSD eine zentrale Bedeutung hat. Alle Informationen werden genau an einer Stelle im Modell speziziert und sind somit auch zentral wartbar. Beispiel 2.3 zeigt eine (sehr abstrahierte) beispielhafte Modellierung in der Domäne GUI-basierte Hochschulverwaltungssysteme. Die GUI besteht aus drei verschiedenen, domainspezischen Ansichten (Frames), die über eine Toolbar geönet werden kann. Im SearchFrame gibt es einen Button, der die Kurse und Studenten in den entsprechenden Frames ltern kann Transformationen Mit der Erstellung des Modells ist die erste Phase im MDSD-Entwicklungsprozess abgeschlossen. Nun sollen die Modelle weiter verarbeitet werden. Dies geschieht mittels Transformationen. Dabei gibt es zwei grundsätzliche Arten von Transformationen: Modell-zu-Modell-Transformationen (M2M) Modelltransformation Modellmodikation Modellverwebung Modell-zu-Code-Transformationen (M2C) Codegenerierung Compiler Interpreter Im Folgenden werden diese Transformationen näher beleuchtet. Zu beachten ist, dass in der Praxis meist mehrfach M2M transformiert wird, bis dann schlussendlich für jede gewünschte Zielplattform je eine M2C-Transformation durchgeführt wird. 10

11 Abbildung 2.3: Schematische Modellierung einer Anwendung in der Domäne GUIbasierte Hochschulverwaltungssysteme. 11

12 Modell-zu-Modell-Transformationen Modelltransformation Bei der Modelltransformation wird ein Modell in ein anderes überführt. Die dazu nötigen Transformationsregeln, werden auf Metamodellebene deklariert. Als Resultat wir ein neues Modell als Instanz des Ziel-Metamodells erzeugt. Das ursprüngliche Modell bleibt dabei unverändert und im alten Metamodell. Letztlich ist eine Modelltransformation nichts anderes als ein Wechsel des zugrundeliegenden Metamodells. Während des Transformationsvorgangs wird immer gegen das Metamodell validiert, sodass das neue Modell in jedem Fall konform zum Metamodell ist und bleibt. Modellmodikation Die Modellmodikation ist ein Sonderfall der Modelltransformation. Hier ndet kein Metamodellwechsel statt, sprich, das veränderte Modell bleibt Instanz des ursprünglichen Metamodells. Es wird kein neues Modell erstellt, sondern das bestehende modiziert. Modellmodikationen werden vorgenommen, um Veränderungen an einem bestehenden Modell durchzuführen wie z. B. das Hinzufügen oder Verändern von Funktionalitäten. Modellverwebung Gerade bei Systemen, in denen nicht alle Informationen in einem einzigen Modell festgehalten werden, braucht man eine Möglichkeit, die Modelle vor der Codegenerierung zusammenzuführen. Dies ist mittels Modellverwebung möglich. Dabei werden Modelle der gleichen oder unterschiedlicher Metamodelle miteinander verlinkt. Dieser Vorgang lässt sich mit dem Linking im Compilerbau vergleichen und ist deshalb von hoher praktischer Relevanz. Transformationssprachen Wie bereits erwähnt, sorgen Transformationsregeln für die M2M-Transformation. Sie werden auf Metamodellebene in deklarativer Art und Weise deniert und beschreiben, wie Elemente des einen Metamodells in Elemente des anderen zu überführen sind. Auch diese Regeln kommen nicht aus dem Nichts, sondern müssen vom Entwickler implementiert werden. Eine recht populäre Sprache zur Realisierung von M2M-Transformationen ist die Atlas Transformation Language (ATL) 1. Beispiel Das Modell aus 2.3 soll in ein Modell transformiert werden, dessen Metamodell näher an der späteren Zielplattform liegt. Da am Ende eine RCP-Anwendung das Ergebnis sein soll, wählen wir ein entsprechendes Metamodell. Dazu kommen Transformationsregeln zum Einsatz, die in ATL deniert sind. 1 rule Frame { 2 from 3 f : MMGui! Frame Listing 2.1: Beispielregel in ATL

13 4 to 5 v : MMRcp! View ( 6 // A t t r i b u t e uebernehmen 7 t i t l e < f. t i t l e 8 [... ] 9 ) 10 } In dieser simplen Regel wird deniert, dass ein Frame aus dem Metamodell MMGui zu einer View im Metamodell MMRcp wird. Die Attribute werden einfach übernommen. 2.4 könnte ein Ergebnis so einer M2M-Transformation sein. Abbildung 2.4: Das Modell aus 2.3 in der Domäne für RCP-Anwendungen. Dem Modell liegt nun das RCP-Metamodell zu Grunde. Dies hat natürlich ein niedrigeres Abstraktionslevel als das vorherige Modell. Wie man sieht wurden alle Frames in Views transformiert. Ebenso viele vorher relativ allgemein gehaltene Elemente in speziellerere der Domäne RCP (z. B. Menü zu Coolbar). An manchen Stellen kamen auch neue Elemente hinzu, beispielsweise der Filter, um die FilterSelection des ursprünglichen Modells zu realisieren. 13

14 Modell-zu-Code-Transformationen Codegenerierung Mittels eines Generators wird aus einem Modell ein Zielplattformspezisches Artefakt in konkreter Syntax. Dieses Artefakt kann beliebig sein: In der Regel handelt es sich um Quellcode oder Kongurationsdateien, es ist aber durchaus denkbar auch Dateien wie z. B. Webseiten oder gar Bilder aus dem Modell zu generieren. Prinzipiell ist jede Zielplattform denkbar, es muss nur ein Generator dafür vorhanden sein. Die Entwickler können die Codegenerierung mittels geeigneter Tools beeinussen. So ist es möglich zu entscheiden, was generiert werden soll und was nicht. Dies hat direkten Einuss auf die erzeugte Codegröÿe. Aufgrund des DRY-Prinzips ist im erzeugten Artefakt garantiert gewährleistet, dass Konventionen durchgängig eingehalten worden sind, da gleiche Strukturen immer gleich in Code überführt werden. Es ist wichtig, dass bei der Codegenerierung darauf geachtet wird, generierten und nicht-generierten Code zu separieren. Auch hier greift das Automatismus-Prinzip nicht zwangsläug. In der Regel kommt man trotz MDSD nicht drumherum, manuellen Code zu erstellen. Beispielsweise einen Algorithmus der Computergrak würde man eher direkt im Code implementieren anstatt in zu modellieren. 2 Es gibt verschiedene Arten von Codegenerierungstech- Codegenerierungstechniken niken: Templates Vorlage mit Platzhaltern. Diese werden durch Informationen aus dem Modell ersetzt. Codegenerierungssprachen Spezielle Sprachen, die auf Codegenerierung optimiert sind. Imperative Sprachen Prinzipiell kann mit jeder beliebigen imperativen Sprache ein Modell eingelesen und beliebiger Output daraus erstellt werden. Mit ihrer Hilfe lassen sich Generatoren für die entsprechende Zielplattform entwickeln. In der Praxis machen sie dabei exzessiven Gebrauch von Frameworks oder Middlewares. Die Generatoren werden in der Regel wiederverwendet oder müssen selbst geschrieben werden. Denn auch hier greift der Automatismus nicht zwangsläug, sodass der Softwareentwickler seinen Generator für die Zielplattform manuell entwerfen muss. Beispiel Mittels Templates soll aus 2.4 nun die fertige RCP-Anwendung generiert werden. Typisch dafür ist u. a. die Datei plugin.xml, auf die es sich hier beschränken soll. Ein Template dafür könnte folgendes Listing sein: 2 Wobei es durchaus auch Computergrak-Algorithmen geben mag, die sich gut mittels Modellen beschreiben lassen. 14

15 1 [.. ] 2 <view Listing 2.2: Template für plugin.xml 3 c l a s s=" {$ program. name }. g u i. views. { $ view. name}" 4 i d=" {$ program. name }. g u i. views. { $ view. name}" 5 name=" {$ view. t i t l e }"> 6 </ view> 7 [.. ] Gefüllt mit den Informationen aus dem Modell, könnte am Ende der Codegenerierung folgendes Produkt herauskommen: 1 [.. ] 2 <view Listing 2.3: Generierte plugin.xml 3 c l a s s="sacat. g u i. views. StudentView " 4 i d="sacat. g u i. views. StudentView " 5 name=" Studenten "> 6 </ view> 7 [.. ] 15

16 3 Abschlieÿende Worte In diesem Kapitel soll noch einmal konkret auf den Grundgedanken hinter MDSD eingegangen werden sowie eine abschlieÿende Beurteilung vorgenommen werden. 3.1 Kernkonzepte In der MDSD geht es im Kern um die Arbeit mit domainspezischen Bestandteilen. Die Bestandteile hier sind meist natürlich die Modelle selber, die in der entsprechenden Domäne deniert sind, aber auch je nach Abstraktionsgrad konkrete Technologien oder Frameworks. Nichtsdestotrotz nehmen bei der MDSD die Modelle die zentrale Bedeutung ein wie sonst bei traditionellen Entwicklungsmethoden der Quelltext. Im Laufe der gesamten Entwicklung ist es aufgrund des Metamodells immer möglich, das Modell (und damit das System) zu validieren und auf Konsistenz hin zu überprüfen. Fehler, die durch Änderungen an den Modellen entstanden, fallen sofort auf und können dort direkt behoben werden. Dabei kommt es einem natürlich zu gute, dass alles in der Regel nur an einer Stelle deniert wird: Das DRY-Prinzip steht im Mittelpunkt. Redundante Informationen gibt es so nicht, weshalb Änderungen zentral für das ganze System vorgenommen werden können. Zu guter Letzt ist die automatische Softwaregenerierung zu nennen. Die Modelle werden immer aktuell gehalten und der daraus generierte Code ist immer konform zum spezizierten Modell. Bei Modelländerungen wird einfach neu generiert. So kommt es zu keinerlei Divergenz zwischen Modell und Quelltext. 3.2 Gründe für Modellgetriebene Softwareentwicklung Einer der Hauptgründe für MDSD ist wohl das hohe Abstraktionsniveau. Je nach betrachteten Abstraktionslevel kann von allem abstrahiert werden: von der Programmiersprache, der Technologie und der Plattform. Das macht es natürlich möglich, dass sowohl die Entwickler als auch Domainexperten ohne Programmierfähigkeiten das Modell gleichermaÿen verstehen. Man kann sich so natürlich viel besser auf die Lösung des eigentlichen Problems konzentrieren ohne sich dabei schon Gedanken um die spätere Umsetzung machen zu müssen. 16

17 Ein weiterer Vorteil ist, dass MDSD für eine immer einheitliche Architektur des Systems sorgt. Dies ist dadurch gewährleistet, dass die Umsetzung der Modelle systemweit immer gleich geschieht. Die denierten Transformationen sind für alle gleichen Elemente o. ä. des Modells analog. Auch die Tatsache, dass Systemänderungen lokal vorgenommen werden, begünstigt eine dauerhaft einheitliche Architektur. So bleibt sie trotz der durch Softwareevolution bekannten Probleme immer konform mit der letztendlich generierten Software. 1 Letzten Endes erhöht sich dadurch natürlich die Wiederverwendbarkeit, Erweiterbarkeit und die Softwarequalität im Allgemeinen erheblich. MDSD ermöglicht eine sehr eziente Softwareentwicklung durch die Codegenerierung. Sicherlich, anfangs sind diverse Vorarbeiten zu leisten (z. B. Entwicklung der DSL, Transformationsregeln, Generatoren), doch in der Regel wird dies durch die Wiederverwendung einmal erstellter Zutaten für zukünftige Entwicklungen wieder wett gemacht. Dies ist auch u. a. ein Grund, weswegen MDSD ideal für die Entwicklung von Produktlinien ist. Einmal erstellte Modelle können die Basis für eine neue Produktlinie werden, genauso wie man Modelle so reduzieren (oder erweitern) kann, dass daraus eine neue Produktlinie wird durch entsprechende Toolunterstützung im Idealfall gar per Mausklick. Zu guter Letzt noch ein Wort zur Agilen Softwareentwicklung. Für viele Entscheider ist dies ein Argument für das Auswählen einer bestimmten Methodik. Sowohl hinter der MDSD als auch hinter agilen Prozessen steht ein iterativ-inkrementelles Vorgehen. Des Weiteren erfüllt MDSD das Agile Manifesto 2. (Es soll an dieser Stelle nur auf eine Auswahl der Punkte des agilen Manifests eingegangen werden.) Das Manifest erfordert z. B. eine beschleunigte Erstellung von Software, es soll schnell ein lauähiges Programm entstehen. Dieser Punkt wird die nötigen Vorarbeiten vorausgesetzt durch den MDSD- Ansatz aufgrund der automatischen Softwaregenerierung erfüllt. Die fortwährende Einbindung des Kundens beim Entwicklungsprozesses ist auch gegeben. Bei der MDSD wird diese Rolle in der Regel ein Experte der entsprechenden Domäne übernehmen. Ebenso können Anforderungsänderungen mittels Modelltransformationen rasch und ezient umgesetzt werden. Auch diesen Punkt des agilen Manifests erfüllt MDSD also. 3.3 Ausblick Wenn sich der durch MDSD losgetretende Trend weiter fortsetzt, könnte sie sich als neues Softwareentwicklungsparadigma durchsetzen. Dies würde unsere Art und Weise Software zu entwickeln natürlich radikal auf den Kopf stellen ähnlich vielleicht wie der Wechsel von Assembler- zu Hochsprachen. Bis dahin gehen die Arbeiten weiter, vollständige(re) Modellcompiler zu entwickeln, die noch mehr aus dem reinen Modell generieren können. Aber auch im Hinblick auf die Koexistenz von Modell und dem daraus generierten Code und manuellen Quelltext 1 Dies ist auch gar nicht anders möglich, da sich ja Modelländerungen auch immer in einem geänderten generierten Code widerspiegeln

18 sind weitere Verbesserungen zu erwarten. Ob nämlich tatsächlich alles nur mit einem Modell mit vertretbaren Aufwand beschrieben werden kann Beispiel hierfür wären die bereits erwähnten Algorithmen aus der Computergrak, ist noch umstritten. So oder so, die zugrundeliegenden Tools werden weiterhin groÿe Fortschritte machen und immer mehr möglich machen. Gerade im Eclipse-Umfeld gibt es dafür eine groÿe Zahl an Werkzeugen Fazit MDSD fasziniert! Allein die Vorstellung, das Austauschen einer im System verwendeten Technologie oder die Umsetzung des Modells für eine andere Zielplattform per Mausklick bewerkstelligen zu können, ist zu schön um wahr zu sein. Dass trotzdem in der Praxis noch einiges mehr zu tun ist und (noch?) nicht alles komplett automatisch zu realisieren ist, damit musste man rechnen. Aber hier gibt es jedenfalls noch sehr viel Potential für die Zukunft. Dennoch, durch die MDSD haben wir ein Mittel zur Hand, der immer mehr wachsenden Komplexität von Software Herr zu werden ohne dabei an Präzision einzubüÿen. Zusätzlich kriegen wir eine ganze Reihe weiterer Vorteile mitgeliefert, die die Softwareentwicklung sowohl beschleunigen als auch qualitativ hochwertiger machen können. Schlussendlich wird die Zeit und damit der Mainstream zeigen, ob und wie MDSD angenommen wird... 3 Sämtliche Eclipse Unterprojekte dazu auf 18

19 Abkürzungsverzeichnis MDSD Modellgetriebene Softwareentwicklung OOP objektorientierte Programmierung UML Unied Modeling Language Rails Ruby on Rails CRUD Create, Retrieve, Update, Delete DRY Don't repeat yourself SMS Short Message Service GUI Graphical User Interface MOF Meta Object Facility DSL Domain Specic Language M2M Modell-zu-Modell-Transformationen M2C Modell-zu-Code-Transformationen ATL Atlas Transformation Language RCP Rich Client Platform 19

20 Literaturverzeichnis [1] Thomas Stahl, Markus Völter, Sven Etinge, and Arno Haase. Modellgetriebene Softwareentwicklung. dpunkt.verlag, (document), 2.1 [2] Markus Völter. Model-driven software development tutorial. de/services/mdsd-tutorial.html. [3] Wikipedia. Anwendungsdomäne. Anwendungsdomäne [4] Wikipedia. Modellgetriebene softwareentwicklung. wiki/modellgetriebene_softwareentwicklung. 20