Diplomarbeit. Entwicklung eines MDD-Tools für eine Virtuelle Ausstellung. Julia Damerow

Transkript

1 Diplomarbeit Entwicklung eines MDD-Tools für eine Virtuelle Ausstellung Julia Damerow 20. Mai 2008

2

3 Inhaltsverzeichnis 1 Einleitung 1 2 Ausgangssituation 2 3 Mögliche Alternativumsetzungen 4 4 Modellgetriebene Softwareentwicklung Model Driven Development Modell Domäne Domänenspezifische Sprachen Metamodell Abstrakte und konkrete Syntax Metametamodell Statische und dynamische Semantik Modellierung Modellvalidierung Domänenspezifische Sprachen Transformation Codegenerierung Modell-zu-Modell-Transformation Re-Generierung Model Driven Architecture Umsetzungmöglichkeiten Metamodellierung Domänenspezifische Sprachen/Modellierung Generator Eigener Ansatz 23 7 Anwendertests 24 I

4 INHALTSVERZEICHNIS 8 Ergebnisse 25 Literaturverzeichnis 26 Glossar 28 Abkürzungsverzeichnis 29 II

5 Kapitel 1 Einleitung - mentale Modell? 1

6 Kapitel 2 Ausgangssituation Vom 16. Mai bis 30. September 2005 präsentierte die Max-Planck-Gesellschaft im Berliner Kronprinzenpalais die Ausstellung Albert Einstein - Ingenieur des Universums. Konzipiert wurde die Ausstellung vom Max-Planck-Institut für Wissenschaftsgeschichte (MPIWG). Anlass war das Einsteinjahr Parallel zur physischen Ausstellung wurde eine virtuelle Ausstellung konzipiert. Dazu wurden alle Ausstellungsräume und Ausstellungsinhalte über das Internet zugänglich gemacht. Diese virtuelle Ausstellung ist auch nach Beendigung der Ausstellung im Kronprinzenpalais und damit auch zum Zeitpunkt der Anfertigung dieser Diplomarbeit weiterhin verfügbar. Wichtiger Bestandteil der Konzeption der Ausstellung Albert Einstein - Ingenieur des Universums waren Medienstationen in Form von über alle Ausstellungsräume verteilten Touch-Screens. Über diese Medienstationen konnten die Besucher Informationen zu den Ausstellungsobjekten sowie allgemeines Hintergrundwissen erlangen. Das Konzept der Medienstationen wurde auch in die Virtuelle Einsteinausstellung übernommen und ist ihr wichtigster Bestandteil. Neben den Fotos der Ausstellungsobjekte, die sich der Nutzer in beliebiger Vergrößerung anschauen kann, Abbildung 2.1: Medienstation in der Einstein Ausstellung stellen die für die Medienstationen aufbereiteten und kommentierten Materialien die Hauptinhalte in der virtuellen Ausstellung dar. Die Medienstationen bilden die Informationsknotenpunkte der Virtuellen Einsteinausstel- 2

7 Kapitel 2. Ausgangssituation Diplomarbeit lung und dienen der Vermittlung und Veranschaulichung von Wissen und Informationen. Ergänzungen: Projektion der Medienstationen an die Wand, Gestaltung der Medienstationen über Webbrowser 3

8 Kapitel 3 Mögliche Alternativumsetzungen CMS... resultiert in MDD Argumentation: Transformation in unterschiedliche Medien (pdf, static HTML, interactiv html) 4

9 Kapitel 4 Modellgetriebene Softwareentwicklung Thema dieser Diplomarbeit ist die modellgetriebenen Softwareentwicklung. Bei der modellgetriebenen Softwareentwicklung wird aus Modellen automatisch Software erzeugt. Ein Modell ist «ein vereinfachtes Abbild» ([BBD + 03], S. 588) einer Software. Unter einer Software wird hier ein Computerprogramm verstanden. Ein Computerprogramm ist «eine nach den Regeln einer Programmiersprache zusammengestellte Abfolge von Anweisungen, die zur Erledigung einer oder mehrerer Aufgaben dient.» ([BBD + 03], S. 729) Abbildung 4.1: Modellgetriebene Softwareentwicklung Ziele der modellgetriebenen Softwareentwicklung sind die Steigerung der Softwarequalität und die Steigerung der Effizienz bei der Entwicklung von Software. Ein wichtiges Konzept ist dabei die Programmierung auf einer höheren Abstraktionsebene, als es bei der Programmierung mit einer höheren Programmiersprach möglich ist. [SVEH07, Kap. 2.2] Unter einer höheren Programmiersprache wird hier... (Hochsprache) [BBD + 03] verstanden. Bei der Programmierung mit der Hochsprache Java beispielsweise wird von dem konkreten Betriebsystem abstrahiert. Der Quelltext wird durch den Java Compiler in Java Bytecode kompiliert. Dieser Bytecode wird bei der 5

10 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG Ausführung des Programms durch die Java Virtual Machine betriebssystemabhängig interpretiert. Das selbe Java-Programm kann somit auf verschiedenen Betriebssystemen ausgeführt werden. Java ermöglich dadurch die Programmierung auf einer höheren Abstraktionsebene als Maschinencode, bei dem für jedes Betriebssystem und jeden Prozessor das Programm neu geschrieben werden muss. Cite wen? Bei der modellgetriebenen Softwareentwicklung wird durch das Modell von der konkreten Programmiersprache abstrahiert. Im Modell werden alle implemenierungsspezifischen Details weggelassen. Der Entwickler konzentriert sich auf die Funktionalität der zu entwickelnden Anwendung [AK03]. Dadurch wird zum einen erreicht, dass die Software plattformunabhängig entwickelt werden kann. Plattformunabhängig bedeutet in diesem Zusammenhang, dass die Anwendungslogik weder auf eine bestimmte Programmiersprache, noch auf ein bestimmtes Betriebssystem festgelegt ist. Zum anderen werden Routinearbeiten bei der Implementierung dem Entwickler abgenommen und automatisch ausgeführt. Dies kann zu einer Zeitersparnis gegebenüber der Softwareentwicklung ohne modellgetriebenen Ansatz führen. Darüber hinaus werden dadurch Fehler minimiert, da nur getesteter und dokumentierter Quellcode automatisch erzeugt wird [SVEH07, Kap. 2.2]. In diesem Kapitel wird zunächst der Begriff modellgetriebene Softwareentwicklung definiert. Im Anschluss daran werden relevante Begriffe und Konzepte der modellgetriebenen Softwareentwicklung erläutert. Zuletzt wird auf Model Driven Architecture (MDA), eine spezielle Ausprägung von modellgetriebener Softwareentwicklung eingegangen. 4.1 Model Driven Development Modellgetriebene Softwareentwicklung wird als Model Driven Development (MDD) oder Model Driven Software Development (MDSD) bezeichnet. [TPB + 07, S. 12] «Modellgetriebene Softwareentwicklung (Model Driven Software Development, MDSD) ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen.» ([SVEH07], S. 11) Zunächst muss für das Verständnis dieser Definition geklärt werden was ein Modell ist und wie es erstellt wird (Modellierung). Im Anschluss daran wird erläutert, wie aus einem Modell lauffähige Software erzeugt wird (Generierung). 6

11 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit 4.2 Modell «Ein Modell stellt ein Abbild eines realen oder abstrakten Systems dar [... ].» ([PM06], S. 42) In der modellgetriebenen Softwareentwicklung ist dieses System eine Software. Modelle gibt es in unterschiedlichen Ausprägungen. Ein Modell kann beispielsweise eine Skizze sein, ein UML-Diagramm oder es kann in textueller Form vorliegen. Es kann menschen- und/oder maschinenlesbar sein. [PM06, Kap. 2.2] Für die modellgetriebene Softwareentwicklung muss ein Modell formal sein. Formal bedeutet, dass sich das Modell an ein Regelwerk hält, «das mathematisch exakt, widerspruchsfrei und vollständig definiert» ([PM06], S. 42) ist. Ein formales Modell beschreibt einen Teil einer Software vollständig. Dieser Teil kann technisch oder fachlich sein. Ein technischer Teil wäre beispielsweise die Architektur der Software. Ein fachlicher Teil ist zum Beispiel die Fachlogik der Anwendung. [SVEH07, Kap. 2.1] Zweck eines Modells ist nicht nur die Dokumentation und Beschreibung der Software. Aus einem Modell wird auch automatisch die ausführbare Anwendung erzeugt [TPB + 07, Kap. 1.3]. Darüber hinaus ist das Ziel bei der Erstellung eines Modells, die Komplexität des Modells gegenüber der Komplexität der Software zu reduzieren, um die Entwicklung der Software zu vereinfachen. Eigenschaften, die nicht zum durch das Modell abgebildeten Teil der Software gehören, werden dafür weggelassen [PM06, Kap. 2.2]. Im Zusammenhang mit dem Modellbegriff stehen weitere Begriffe, die in Abbildung 4.2 dargestellt sind. Im Folgenden werden diese Begriffe erläuert Domäne Eine Domäne ist ein begrenztes Wissens- oder Interessengebiet. Sie kann technisch oder fachlich sein. Eine technische Domäne bezieht sich auf den technischen Teil einer Software. Eine fachliche Domäne bezieht sich auf den fachlichen Teil einer Software. Eine Domäne kann aus Subdomänen bestehen. Eine Subdomäne ist eine Teilmenge der Domäne. Subdomänen sind beispielsweise sinnvoll für den Umgang mit sehr komplexen Domänen, um die Überschaubarkeit der Domäne zu gewährleisten. [SVEH07, Kap. 3.1] 7

12 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG Abbildung 4.2: Begriffe der MDD, Quelle: [SVEH07, S. 28] Domänenspezifische Sprachen Eine domänenspezifische Sprache wird als Domain Specific Language (DSL) bezeichnet. Sie ist eine speziell auf eine Domäne abgestimmte Sprache [CM07]. Die Sprachelemente der DSL werden von Mensch und Maschine verstanden. Mittels der DSL wird ein formales Modell erstellt. Der Mensch kann so den Sachverhalt einer Domäne maschinenverständlich abbilden [TPB + 07, Kap. 3.6]. Im Wesentlichen umfasst eine DSL ein Metamodell und eine konkrete Syntax Metamodell Ein Metamodell macht Aussagen über die mögliche Struktur eines Modells. Es ist die formale Beschreibung einer Domäne [SVEH07, Kap. 3.1]. Die Vorsilbe meta bedeutet hier soviel wie über oder übergeordnet. Die einzelnen Elemente eines Modells sind Instanzen der Modellelemente des Metamodells. Das heißt, das Metamodell steht auf einer höheren Ebene als das Modell [PM06, Kap. 2.2]. Zur Veranschaulichung der Beziehung zwischen Domäne, Modell und Metamodell siehe Abbildung Abstrakte und konkrete Syntax Eine DSL hat zwei Syntaxen. Die abstrakte Syntax und die konkrete Syntax. Die abstrakte Syntax beschreibt die Metamodellelemente und ihre Beziehungen untereinander [SVEH07, Kap. 3.1]. Allgemeiner ausgedrückt definiert die abstrakte Syntax die syntaktischen Elemente (z. B. Buchstaben) und legt fest wie daraus Konstrukte (z. B. Wörter) gebildet werden. Ein Konstrukt ist eine Kombination von syntaktischen Elementen. [PM06, Kap. 1.3]. Die abstrakte Syntax 8

13 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit Abbildung 4.3: (Meta-)Modellebenen, Quelle: Angelehnt an [SVEH07, S. 60] und [PM06, S. 49] der Programmiersprache Java beispielsweise legt fest, dass es Klassen gibt, die einen Namen haben, die Methoden haben können, etc. [SVEH07, Kap. 3.1]. Die konkrete Syntax hingegen legt fest wie ein Modell oder allgemein gesagt ein Konstrukt konkret beschrieben wird. Sie legt die «Ausdrucksmittel (Darstellungsform, Notation)» ([PM06], S. 19) der DSL fest. Für die Programmiersprache Java legt die konkrete Syntax fest, dass eine Klasse mit dem Schlüsselwort class beginnt, dass wenn eine Klasse ein Interface implementiert, dies mit dem Schlüsselwort implements notiert wird, etc. Weiterhin kann gesagt werden, dass eine konkrete Syntax graphisch oder textuell sein kann. Ein Beispiel für eine graphische konkrete Syntax ist die UML-Notation. Eine textuelle konkrete Syntax ist die Notation in XML [SVEH07, Kap. 3.1]. Ein Modell und das zugehörige Metamodell haben immer eine unterschiedliche abstrakte Syntax. Hingegen können sie die gleiche konkrete Syntax haben [PM06, S. 50] Metametamodell Ein Metametamodell ist das Metamodell eines Metamodells. Die Modellelemente des Metamodells sind also Instanzen der Modellelemente des Metametamodells. In der Theorie kann es beliebig viele Meta-Ebenen eines Modells geben. In der Praxis sind drei Ebenen in den meisten Fällen ausreichend (Modell, Metamodell und Metametamodell). Das Metametamodell beschreibt sich dabei meist selbst. Ein weitverbreitetes Metametamodell ist die Meta Object Facility (MOF), ein Standard der Object Management Group (OMG). Die MOF ist un- 9

14 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG ter anderem das Metamodell der Unified Modeling Language (UML). [SVEH07, Kap. 3.1] Statische und dynamische Semantik Die statische Semantik legt die Bedingungen fest, die ein Modell erfüllen muss um wohlgeformt (valide) zu sein. Diese Bedingungen werden Constraints genannt [SVEH07, Kap. 3.1]. Allgemein gesagt, legt die statische Semantik fest wie ein Konstrukt mit einem anderen verbunden ist, um eine Bedeutung zu erhalten. Die statische Semantik der booleschen Algebra beispielsweise legt fest, dass ein boolescher Ausdruck der Form boolescher Wert, boolescher Operator, boolescher Wert einen booleschen Wert zurückliefert [PM06, Kap. 1.3]. Bei statisch getypten Programmiersprachen sind die Bedingungen, die vom Compiler geprüft werden, die statische Semantik. Diese legen beispielsweise fest, dass Variablen deklariert sein müssen [SVEH07, Kap. 3.1]. Die dynamische Semantik legt die erlaubten Ausführungen des durch die statische Semantik definierten Konstrukts fest. Nur wenn ein Konstrukt wohlgeformt ist, definiert die dynamische Semantik eine Bedeutung. Die dynamische Semantik legt beispielsweise fest, dass ein boolescher Ausdruck der Form boolescher Wert, boolescher Operator, boolescher Wert bezogen auf den UND-Operator nur dann zu true evaluiert, wenn beide booleschen Werte true sind, sonst evaluiert er zu false [PM06, Kap. 1.3]. Wird bei der Programmierung gegen die dynamische Semantik verstoßen, wird dies erst zur Laufzeit erkannt. Das folgende Beispiel verdeutlicht dies. 1 int i = x; 2 i = i - 1; 3 i = 1/ i; Die potentielle Division durch Null wird erst zur Laufzeit erkannt. Da eine Division durch Null gegen die dynamische Semantik verstößt, kommt es für den Fall, dass x den Wert 1 hat zu einem Fehler. [Sch96] 4.3 Modellierung Modelle sind das zentrales Konzept bei MDD. Ihre Erstellung wird als Modellierung bezeichnet. Die Elemente eines Modells sind Instanzen der Elemente eines Metamodells. Die modellgetriebene Entwicklung muss daher mit der Definition des Metamodells beginnen. Die Schwierigkeit hierbei ist, das Metamodell vollständig zu definieren. Zu diesem Zweck sollten mehrere konkrete Szenarien 10

15 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit vor und während der Erstellung des Metamodells durchdacht werden. [SVEH07, Kap. 5.5] Für die Modellierung wird eine konkrete Syntax benötigt. Die konkrete Syntax ist die Schnittstelle zum Modellierer. Ihre Qualität ist entscheidend für die Lesbarkeit des Modells. Es durchaus möglich, dass es mehrere konkrete Syntaxen für ein Modell gibt, z. B. eine graphische und eine textuelle. [SVEH07, Kap. 5.1] Modellvalidierung Bei der Modellierung besonders von komplexen Modellen kommt es oft zu Modellierungsfehlern. Modellierungsfehler sind Verstöße gegen die durch die statische Semantik festgelegten Constraints. Je später diese Verstöße erkannt werden, desto höher ist meistens der Aufwand sie zu beheben [TPB + 07, Kap. 3.7]. Teil der modellgetriebenen Softwareentwicklung ist daher die Modellvalidierung (Validierung). Bei der Modellvalidierung wird geprüft ob alle Constraints vom Modell eingehalten werden [SVEH07, Kap. 5.1]. Das Zusammenspiel von Modellierung und Validierung ist ein iterativer Prozess. Durch die Validierung entdeckte Fehler werden durch erneute Modellierung behoben. Abbildung 4.4 verdeutlicht den Modellierungs- und Validierungs- Prozess [TPB + 07, Kap. 3.7]. Bei der Generierung wird meistens vorausgesetzt, Abbildung 4.4: Modellierung und Validierung, Quelle: [TPB + 07, S. 67] dass das Modell valide ist. Ist das Modell nicht valide, kann es zur Generierung von fehlerhaftem Quelltext kommen. Die Modellvalidierung ist daher direkt vor der Generierung notwendig. Der frühestmögliche Zeitpunkt für die Validierung ist während der Eingabe des Modells. Die Validierung wird dabei durch den Editor durchgeführt. Diese Technik der Validierung während der Eingabe ist weit- 11

16 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG verbreitet und in den meisten modernen Entwicklungsumgebungen umgesetzt. Bei der Validierung im Editor und bei der Validierung direkt vor der Codegenerierung sollte auf die gleiche Implementierung der Constraints zurückgegriffen werden, um die Konsistenz in der Validierung zu gewährleisten. [SVEH07, Kap. 5.1] Domänenspezifische Sprachen Domänenspezifische Sprachen (DSLs) können auf verschiedene Weise kategorisiert werden. Sie können in interne und externe DSLs einteilt werden oder in graphische und textuelle DSLs. Die Wahl der DSL und damit der konkreten Syntax ist von Bedeutung, da an ihr unter anderem die Wahl des Modellierungswerkzeugs und die Lesbarkeit des Modells hängt. [SVEH07, Kap. 6] Martin Fowler hat die Begriffe der internen DSL (auch embedded DSL) und externen DSL geprägt [Fow05]. Eine interne DSL ist eine DSL, die in eine andere Sprache, die sogenannte Hostsprache, eingebettet ist (daher der Begriff der embedded DSL). Die Hostsprache ist meist eine dynamisch getypte Sprache wie beispielsweise Ruby. Eine externe DSL wird dagegen von Grund auf neu erstellt. Für sie wird ein extra Parser benötigt, der die Information der DSL einliest und zur Generierung oder Interpretation bereitstellt. Eine interne DSL hat verschiedene Nachteile. Zum einen kann eine interne DSL immer nur eine textuelle konkrete Syntax haben. Des Weiteren fehlt die Möglichkeit spezielle Modellierungswerkzeuge für die DSL zu entwickeln. Eine interne DSL kann erst zur Laufzeit validiert werden. Vorher ist sie nur durch die Hostsprache begrenzt. Dadurch werden Modellierungsfehler erst spät oder eventuell gar nicht erkannt [SVEH07, Kap. 6.1]. Ein weiterer Nachteil ist, dass ein Entwickler, der mit der DSL ein Modell erstellen möchte, die Hostsprache jedoch nicht beherrscht, verwirrt werden kann, da ihm mehr Möglichkeiten zur Verfügung stehen als für die Modellierung gebraucht werden. Vorteil einer internen DSL ist, dass ein Entwickler, der die Hostsprache dagegen gut kennt, die volle Mächtigkeit der Hostsprache ausnutzen kann. Nachteil externer DSLs ist, dass der Editor und Parser für die DSL zusätzlich zur DSL entwickelt werden muss. Der Vorteil liegt darin, dass ein graphischer Editor entwickelt werden kann, der im Gegensatz zur internen DSL nur die Funktionalität, die zur Erstellung des Modells benötigt wird, bereitstellt [Fow05]. Eine weitere Kategorisierung, die vorgenommen werden kann, ist die Unterteilung von DSLs in graphische und textuelle DSLs. Modelle mit einer graphische DSL geben meist einen guten Überblick über die Struktur des dargestellten Mo- 12

17 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit dells und sind als Diskussionsgrundlage geeignet. Dabei muss jedoch beachtet werden, nicht zu viele Elemente oder Konzepte darzustellen, um die Übersichtlichkeit beizubehalten. Textuelle DSLs sind in der Regel weniger übersichtlich. Dies kann durch entsprechende Hilfsmittel des benutzten Editors (z. B. Code Folding, Syntax Highlighting, etc.) verbessert werden. Als Diskussionsgrundlage sind sie meistens ungeeignet. [SVEH07, Kap. 6.1] 4.4 Transformation Bei einer Transformation wird aus einem formalen Modell etwas anderes erzeugt. Durch die Transformation kann Text erzeugt werden wie z. B. Quelltext oder Dokumentationsdateien oder es kann ein weiteres Modell erzeugt werden [SVEH07, Kap. 3.1]. Was erzeugt wird und wie es erzeugt wird, wird durch Regeln festgelegt, die zuvor definiert werden müssen [TPB + 07, Kap. 3.8]. Wird Quelltext erzeugt spricht man im Allgemeinen von Modell-zu-Code- Transformation (abgekürzt M2C) oder auch Codegenerierung bzw. Generierung. Die Codegenerierung wird ausführlich in Abschnitt besprochen. Wird ein weiteres Modell erzeugt, wird dies Modell-zu-Modell-Transformation (abgekürzt M2M) genannt. Die Modell-zu-Modell-Transformation wird in Abschnitt behandelt [SVEH07, Kap. 3.1] Codegenerierung Einer der Hauptbestandteile der modellgetriebenen Softwareentwicklung ist, wie bereits in Abschnitt 4.1 erwähnt, die automatisierte Erzeugung von Quelltexten und anderen Artefakten, die Codegenerierung. Sie wird auch als Modell-zu- Code-Transformation bezeichnet [SVEH07, Kap. 3.1] [PM06, Kap. 3]. Bei der Codegenerierung muss zwischen zwei Arten von Informationen unterschieden werden. Die variablen Informationen und die statischen Informationen. Variable Informationen werden durch das Modell festgelegt und sind je nach Modell verschieden. Statische Informationen werden für die gesamte Codegenerierung vorgegeben. Dies sind die sogenannte Generatorvorschriften. Sie sind für die Modellierung irrelevant und werden erst bei der Generierung hinzugezogen. Für die Codegenerierung gibt es verschiedene Techniken, die im Folgenden beispielhaft betrachtet werden. Zuvor werden jedoch erst einmal die wichtigsten Merkmale eines Codegenerators bei MDD angeführt, wie sie von Stahl et al. definiert werden. [SVEH07, Kap. 8] Ein MDD-Codegenerator sollte die folgenden Merkmale haben, um effizient eingesetzt werden zu können (siehe hierzu [SVEH07, S. 145]). 13

18 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG Die variablen Informationen (das Modell) sind von den statischen Informationen (die Generatorvorschriften) getrennt. Die Generatorvorschriften basieren auf dem Metamodell. Aus einem Modell können die Artefakte beliebig oft erzeugt werden. Ein Generator kann für beliebig viele Modelle verwendet werden. Einzige Bedingung ist, dass die Modelle dem Metamodell entsprechen. Handgeschriebener Code und generierter Code sollten getrennt werden. Die Zusammenführung des handgeschriebenen Quelltextes und des generierten Quelltextes sollte soweit möglich mit den Mitteln der Zielsprache geschehen, z. B. durch Vererbung. Sehr viel grundlegender gesagt, muss ein Codegenerator die folgenden drei Funktionen unterstützen. Zunächst sollte er das Schreiben von Text in Dateien erlauben. Des Weiteren sollte die Abfrage von Werten aus einem eingegebenen Modell möglich sein. Zuletzt sollte die Konkatenation von statischem Text (d. h. statischen Informationen) und Informationen aus dem Modell unterstützt werden. Die verschiedenen Technologien zur Codegenerierung setzen unterschiedliche Schwerpunkte was diese Funktionen angeht. Bei der Wahl des Codegenerators sollte dies daher bedacht werden. Im Folgenden werden zwei mögliche Techniken der Codegenerierung vorgestellt. Zunächst wird die Codegenerierung mit Hilfe von Templates erläutert. Im Anschluss wird die Codegenerierung mittels einer Programmiersprache dagegengestellt. [SVEH07, Kap. 8] Die Codegenerierung mittels Templates ist sinnvoll, wenn viel statischer Text generiert werden soll. Dabei werden die Artefakte von dem Generator anhand von Vorlagen (sogenannten Templates) erstellt. Ein Template besteht aus beliebigem Text, der Tags beinhaltet. Ein Tag ist ein Platzhalter in einer speziellen Notation, der während des Generierungsprozesses von dem Generator durch einen entsprechenden Wert ersetzt wird. Die Notation der Tags wird durch die Template-Sprache spezifiziert. Die Template-Sprache legt fest, wie ein Template aufgebaut ist, wie ein Tag notiert wird, etc. Ein Tag enthält einen Ausdruck, der durch den Generator mittels der Informationen des Modells evaluiert wird. Das Ergebnis wird an die Stelle des Tags gesetzt. Die Form des Ausdrucks ist ebenso wie die Notation der Tags von der Template-Sprache abhängig. Die Technik der Codegenerierung mittels Templates ist spezialisiert auf die Konkatenation von statischem Text und Modellinformationen. Beispiele hierfür sind Template- Sprachen wie JSP, PHP oder aus dem XML-Umfeld XSLT. [SVEH07, Kap ] 14

19 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit Bei der Codegenerierung mittels einer Programmiersprache wird der Generator mittels einer Programmiersprache wie beispielsweise Java oder C# entwickelt. Meistens werden dabei Klassen entwickelt, die bestimmte Konzepte der Zielsprache repräsentieren. Diese Klassen können dann im gesamten Generator wiederverwendet werden. Listing 4.1 zeigt beispielhaft wie die Implementierung einer solchen Klasse aussehen kann. 1 public class JavaClass { 2 public String packagename ; 3 public String name ; 4 public List < JavaMember > members ; 5 7 public String tostring () 8 { 9 String buff = " package " + packagename + ";\ n" + 10 "\n" + 11 " public class " + name + " {\ n"; 12 for ( Member m : members ) 13 buff += m; 14 buff += "}\ n"; 15 return buff ; 16 } 17 } Listing 4.1: Beispiel Klasse zur Erstellung von Java-Klassen, Quelle: [SVEH07], S. 150 Bei dieser Technik der Codegenerierung muss bedacht werden, dass die Eigenheiten der gewählten Programmiersprache in die Entwicklung des Generators miteinfließen, was u. U. zu Problemen oder zumindest zu Unhandlichkeiten führen kann. In dem angeführten Beispiel wird beispielsweise mit Strings in Java gearbeitet. Das bringt mehrere Nachteile mit sich. Es gibt z. B. in Java keine mehrzeiligen Strings (Zeilenumbrüche müssen mit Escape-Sequencen (z. B. \n ) beschrieben werden), Strings können im Quelltext nicht über mehrere Zeilen gehen, sie müssen mit + konkateniert werden, etc. Der Vorteil der Codegenerierung mittels einer Programmiersprache ist dagegen, dass die volle Unterstützung der meist sehr leistungsstarken Entwicklungsumgebungen für die Entwicklung des Generators genutzt werden kann. [SVEH07, Kap ] Modell-zu-Modell-Transformation In der klassischen modellgetriebenen Entwicklung folgt nach der Modellierung und Validierung des Modells die Codegenerierung. Das bedeutet, dass es zwei Abstraktionsebenen gibt. Die Ebene des Modells und die Ebene des Quelltextes. In den meisten Fällen ist dies ausreichend. Die Codegenerierung überbrückt 15

20 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG in solchen Fällen die komplette Lücke zwischen Modell und Quelltext. Unter Umständen wird der Codegenerator bei diesem Ansatz jedoch sehr komplex. Ein weiteres Problem besteht darin, dass bei der Generierung dasselbe Metamodell wie bei der Modellierung verwendet wird. Dadurch wird das Metamodell möglicherweise zu sehr aufgebläht, da alle für die Generierung notwendigen Abstraktionen in das Metamodell mit aufgenommen werden. Es wird ein weiterer Schritt benötigt, der in der Regel zwischen der Modellierung bzw. Validierung und der Codegenerierung liegt, die Modell-zu-Modell-Transformation. In diesem Schritt wird das Modell für die Codegenerierung aufbereitet. Diese Aufbereitung ist eine Anreicherung des Modells mit zusätzlichen Informationen (die Modellmodifikation) oder die Überführung des Modells in ein anderes Modell (die Modelltransformation). [SVEH07, Kap. 10.1] Bei der Modellmodifikation wird das Ausgangsmodell modifiziert. Das Ausgangsmodell ist das Modell, auf welches die Transformation angewandt wird. Abbildung 4.5 verdeutlicht diese Art der Modell-zu-Modell-Transformation. Das Modell wird dabei mit Informationen angereichert. Hierfür werden basieren auf den Metamodellelementen Regeln definiert, wie die Modellelemente mit Informationen anzureichern sind [TPB + 07, Kap ]. Das so entstandene Modell hat weiterhin dasselbe Metamodell wie das Ausgangsmodell. In der Abbildung ist dies durch die gleiche geometrische Form der Modellelemente beider Modelle dargestellt. Es werden lediglich neue Instanzen der Metamodellelemente hinzugefügt und bestehende verändert. In der Abbildung ist dies verdeutlich durch eine andere Färbung [SVEH07, Kap. 10.2]. Abbildung 4.5: Modellmodifikation, Quelle: [SVEH07, S. 199] Als einen Spezialfall der Modellmodifikation führen Stahl et al. das sogenannte Modell-Weaving (Linking) an. Manchmal ist es notwendig, nicht alle Informationen in einem Modell zu speichern. Die Informationen sind dann auf mehrere Modelle aufgeteilt. In diesem Fall müssen die Modelle vor der Codegenerierung miteinander in Verbindung gebracht werden (verlinkt werden). Die 16

21 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit Modellelemente des Ausgangsmodells werden mit den Verlinkungen zu den Modellelementen des anderen Modells angereichert. Die Modelle müssen dabei nicht dasselbe Metamodell haben. Abbildung 4.6 verdeutlicht das Modell-Weaving. Die Verlinkungen sind dabei durch die gepunkteten Linien dargestellt. [SVEH07, Kap. 10.2] Abbildung 4.6: Modell-Weaving, Quelle: [SVEH07, S. 200] Bei der Modelltransformation wird im Gegensatz zur Modellmodifikation das Ausgangsmodell nicht verändert. Es besteht außerdem die Möglichkeit mehrere Ausgangsmodelle zu einem Modell zusammenzuführen. Diese Form der Transformation wird beispielsweise angewandt, wenn das Ausgangsmodell ein anderes Metamodell hat, als das Modell in das es transformiert werden soll. Abbildung 4.7 zeigt diese Form der Modell-zu-Modell-Transformation. Die verschiedenen Metamodelle werden durch die unterschiedliche geometrischen Formen der Modellelemente der beiden Modelle dargestellt. [SVEH07, Kap. 10.2] Abbildung 4.7: Modelltransformation, Quelle: [SVEH07, S. 200] 17

22 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG Re-Generierung Wichtiger Bestandteil der modellgetriebenen Softwareentwicklung ist das Zusammenspiel von Modellierung/Validierung und Generierung. Ähnlich wie bei der Modellierung und Validierung ist dies ein iterativer Prozess. Das Modell nimmt bei MDD die Rolle des Quelltextes ein. Daher werden Änderungen immer am Modell vollzogen. Diese Änderungen können auch nach der ersten Generierung vorgenommen werden [SVEH07, Kap. 2.2]. Den vorgenommenen Änderungen folgt eine erneute Codegenerierung, die Re-Generierung. Meist ist die erste Generierung unproblematisch, es entstehen Quelltext-Dateien. Sehr häufig muss jedoch Code manuell hinzugefügt werden. Selten lässt sich eine Anwendung bei MDD zu 100% generieren. Bei einem erneuten Generatordurchlauf würde der manuell hinzugefügte Code überschrieben werden. Um dieses Problem zu handhaben, gibt es zwei Lösungsansätze: die Verwendung von Protected Regions und die Trennung von generierten und handgeschriebenen Code in verschiedene Dateien [PM06, Kap. 3.3]. Diese beiden Techniken werden im Folgenden erläutert. Protected Regions sind geschützte Bereiche im Quelltext. Diese geschützten Bereiche werden bei einer erneuten Codegenerierung nicht mit generiertem Code überschrieben. Anfang und Ende einer Protected Region werden mit entsprechenden Kommentaren ausgezeichnet. Der folgende Pseudocode zeigt das Schema einer Protected Region [TPB + 07, Kap. 5.4]. 1 public class Person { String name = null ; 4 5 // begin protected region 6 7 // hierhin kommt der manuell geschriebene Quelltext 8 9 // end protected region } Listing 4.2: Beispiel einer Protected Region, Quelle: [TPB + 07], S. 177f Diese Technik hat einige Nachteile. Zum einen gibt es keine klare Trennung zwischen generierten und manuell erstellten Artefakten, da sich generierter und handgeschriebener Code innerhalb einer Datei vermischen. Des Weiteren muss der Entwickler daran denken nur innerhalb einer Protected Region Änderungen am Code vorzunehmen. Er kann nicht wie bei manuell erstelltem Code, alle Code-Teile beliebig ändern [PM06, Kap. 3.3]. Ein weiteres Problem besteht darin, dass generierter Code, der manuell verändert wurde, unter Versionskontrolle 18

23 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit gestellt werden muss. Generell sollte generierter Code jedoch nicht in einem Versionsverwaltungsystem erfasst werden. Da das Modell die Rolle der Quelltexte einnimmt, sind die generierten Quelltexte nur eine Art Zwischenprodukt, ähnlich den Class-Dateien bei Java [SVEH07, Kap. 2.2]. Weiterhin wird der Generator bei der Verwendung von Protected Regions unter Umständen sehr komplex, da er sich um die Verwaltung, Erkennung und Erhaltung der geschützten Bereiche kümmern muss. In der Praxis geht dabei oft Code verloren, da es nicht immer einfach ist Protected Regions zu erhalten. Zuletzt kommt noch hinzu, dass der Entwickler bei Protected Regions den generierte Code verstehen muss, was nicht immer einfach und manchmal auch nicht sinnvoll ist [SVEH07, Kap. 8.5]. Vorteil von Protected Regions ist, dass der Generator die volle Kontrolle über die generierten Dateien behält. Des Weiteren wird die vom Modell vorgegebene Architektur eingehalten [TPB + 07, Kap. 5.4]. Wird der generierte Code und der manuell erstellte Code in seperate Dateien getrennt, ergeben sich dagegen andere Probleme. Zunächst einmal muss hierbei abhängig vom Artefakttyp (Java-Klasse, Properties-Datei, XML-Datei, etc.) eine andere Strategie entwickelt werden, um generierten Code und handgeschriebenen Code zusammenzuführen. Bei objektorientierten Sprachen kann beispielsweise mit Vererbung oder Delegation gearbeitet werden. Bei nicht objektorientierten Sprachen kann man Includes benutzen. Unter Includes werden hier Anweisungen verstanden, die Code aus anderen Dateien ausführen [PM06, Kap. 3.3]. In jedem Fall hat der Generator nicht mehr die volle Kontrolle über alle Dateien. Bei strukturellen Änderungen beispielsweise, werden die generierten Dateien vom Generator angepasst. Die manuell erstellten Artefakte müssen jedoch per Hand nachgezogen werden. Der Vorteil dieser Technik generierten und manuell erstellten Quelltext zusammenzubringen ist, dass es eine klare Trennung von generiertem und handgeschriebenem Code gibt. Die generierten Artefakte müssen nicht in das Kontrollsystem gestellt werden. [TPB + 07, Kap. 5.4]. Um aus dem Modell lauffähige Software zu erzeugen, wird ein Generator oder Interpreter benötigt. Ein Generator ist eine Software, die aus einem Modell Quellcode erzeugt. Im Gegensatz dazu liest ein Interpreter das Modell zur Laufzeit ein und führt daraufhin durch das Modell festgelegte Aktionen aus. Für die obenstehende Definition bedeutet dies, dass mit Hilfe des Generators oder Interpreters aus dem Modell eine durch den Rechner ausführbare Software entsteht. Das Modell dient nicht als Vorlage für die manuelle Implementierung, sondern der Quellcode wird automatisch aus dem Modell erzeugt. Der Grundgedanke hierbei ist, dass Änderungen immer an dem Modell vollzogen werden und der 19

24 KAPITEL 4. MODELLGETRIEBENE SOFTWAREENTWICKLUNG erzeugte Code somit immer konsistent ist [SVEH07, Kap. 2.1]. Trompeter et al. formulieren die Zielsetzung noch etwas allgemeiner. In der modellgetriebenen Softwareentwicklung werden «möglichst viele Artefakte eines Softwaresystems [...] aus formalen Modellen abgeleitet» ([TPB + 07], S. 11). Diese Artefakte sind zum einen Quelltexte. Zum anderen sind es alle weiteren Dateien, die zur Ausführung der Anwendung nötig sind wie beispielsweise Konfigurationsdateien oder Datenbankskripte. Darüber hinaus können Artefakte auch für die Entwicklung notwendige Dokumente und sonstige Dateien sein wie Dokumentationsdateien oder Softwaretests. [TPB + 07] 4.5 Model Driven Architecture MDA ist ein Standard der Object Management Group (OMG). [SVEH07, Anhang A] - OMG * 1989 gegründet * offenes Konsortium aus etwa 800 Firmen weltweit * OMG erstellt herstellerunabhängige Spezifikationen zur Interoperabilität und Portabilität von Softwaresystemen. * Bekannte Spezifikationen sind beispielsweise CORBA (Common Object Request Broker Architecture) oder UML (Unified Modeling Language) * Die beiden primären Motivationen sind bei MDA dementsprechend Interoperabilität und Portabilität - MDA verwendet MOFals das einzige Metametamodell - MDA sieht vor das DSLs auf Basis der MOFformuliert werden - für die MOFwird XMI (XML Metadata Interchange) als XML-Mapping verwendet. Mit Hilfe von XMI werden mit der MOF erstellte Modelle unter den verschiedenen Tools ausgetauscht. - seit UML2.0 basiert UML komplett auf der Meta Object Facility (MOF), dadurch ist UML formal beschrieben und kann zur Konstruktion von Metamodellen herangezogen werden. - OMGsieht den Hauptzweck von MDA darin, die Anwendungslogik plattformunabhängig entwickeln zu können - plattformunabhängig bedeutet in diesem Zusammenhang, dass die Anwendungslogik weder auf eine bestimmte Programmiersprachen, noch auf ein bestimmtes Betriebssystem, etc. festgelegt ist. - dazu wird bei MDA die Anwendungslogik MOF-basiert modelliert. - mittels entsprechender Transformationen werden aus diesem Modell dann die plattformspezifischen Implementierungen generiert. - Zentrales Konzept bei MDA ist das PIM (Platform Independent Model). Das ist das Modell der Anwendungslogik völlig plattformunabhängig. - aus dem PIM wird durch eine geeignete Transformation ein PSM (Platform Specific Model) erstellt. Dies ist platformspezifisch z. B. spezifisch für Java EE oder.net - daraus können durch weitere Transformationen noch weitere, spezifischere Modelle erstellt werden bis letztendlich der Quellcode generiert wird. - weiteres Modell ist das PDM (Platform Description Model). Dies ist das Metamodell(?) der Zielplattform. Hier 20

25 Kapitel 4. Modellgetriebene Softwareentwicklung Diplomarbeit werden die Informationen zur Zielplattform gehalten. 21

26 Kapitel 5 Umsetzungmöglichkeiten Model-Driven Development in the enterprise -> tool vergleich 5.1 Metamodellierung - MOF - Ecore - Klassen - XML/XSD 5.2 Domänenspezifische Sprachen/Modellierung - UML - EMF - GMF + Editor - Xtext + Editor - GME + Editor 5.3 Generator - AndroMDA - JET/JMerge - oaw - (SmartQVT, Tefkat, Medini QVT) 22

27 Kapitel 6 Eigener Ansatz Vergleich der zuvor beschriebenen Tools und Auswahl. Objekte kurz beschreiben Trickies. 23

28 Kapitel 7 Anwendertests kurze Einführung Aufgaben (anlegen scene, modul,... ) Zeit messen 24

29 Kapitel 8 Ergebnisse Testauswertung kritische Betrachtung probleme mit delta pack 25

30 Literaturverzeichnis [AK03] Atkinson, Colin ; Kühne, Thomas: Model-driven development: a metamodeling foundation. In: IEEE Software 20 (2003), Nr. 5, S [BBD + 03] Barnert, Silvia ; Boeckh, Martin ; Delbrück, Dr. M. ; Greulich, Walter ; Heinisch, Carsten ; Karcher, Ruth ; Lienhart, Klaus ; Radons, Dr. G. ; Voets, Stephan ; Wallenwein, Klaus: Einführung in die Theoretische Informatik. Formale Sprachen und Automatentheorie. F. A. Brockhaus, ISBN [CM07] [Fow05] [MM03] Cuadrado, Jesús S. ; Molina, Jesús G.: Building Domain-Specific Languages for Model-Driven Development. In: IEEE Software 24 (2007), Nr. 5, S Fowler, Martin: Language Workbenches: The Killer-App for Domain Specific Languages? languageworkbench.html. Version: Letzte Änderung am 12. Jun. 2005, besucht am 13. Mai 2008 Miller, Joaquin (Hrsg.) ; Mukerji, Jishnu (Hrsg.): MDA Guide Version Version: Letzte Änderung am 12. Jun. 2003, besucht am 15. Mai 2008 [Obj07] Object Management Group: About the Object Management Group. gettingstartedindex.htm. Version: Letzte Änderung am 9. Nov. 2007, besucht am 9. Mai 2008 [PM06] Petrasch, Roland ; Meimberg, Oliver: Model Driven Architecture - Eine praxisorientierte Einführung in die MDA. 1. Auflage. dpunkt.verlag, ISBN

31 Literaturverzeichnis Diplomarbeit [Sch96] Schiedermeier, Prof. Dr. R.: Klassifikation von Fehlern. fh-muenchen.de/~schieder/programmieren-1-ws96-97/ fehlerarten.html#section_10_1_3. Version: Letzte Änderung am 10. Okt. 1996, besucht am 9. Mai 2008 [SVEH07] Stahl, Thomas ; Völter, Markus ; Efftinge, Sven ; Haase, Arno: Modellgetriebene Softwareentwicklung - Techniken, Engineering, Management. 2. Auflage. dpunkt.verlag, ISBN [TPB + 07] Trompeter, Jens (Hrsg.) ; Pietrek, Georg (Hrsg.) ; Beltran, Juan Carlos F. ; Holzer, Boris ; Kamann, Thorsten ; Kloss, Michael ; Mork, Steffen A. ; Niehues, Benedikt ; Thoms, Karsten: Modellgetriebene Softwareentwicklung - MDA und MDSD in der Praxis. entwickler.press,

32 Glossar Constraints Bedingungen, die erfüllt sein müssen, damit ein Modell wohlgeformt ist. 10 IDE Anwendungsprogramm zur Entwicklung von Software 11 Meta Object Facility Metametamodell der OMG 8, 28 Object Management Group Internationales Konsortium, das sich mit der Entwicklung von Technologie- Standards beschäftigt. Die OMG wurde 1989 gegründet.[obj07] 8, 28 Ruby Dynamisch getypte Programmiersprache, die ursprünglich von Yukihiro matz Matsumoto entwickelt wurde. 13 valide siehe wohlgeformt 10, 11 wohlgeformt Ein Ausdruck ist wohlgeformt, wenn alle Regeln, die die statische Semantik festlegt, erfällt sind

33 Abkürzungsverzeichnis DSL Domain Specific Language 8 MDA Model Driven Architecture 5, 20 MDD Model Driven Development 5, 11, 17 MDSD Model Driven Software Development 5 MOF Meta Object Facility 8 OMG Object Management Group 8, 20 UML Unified Modeling Language 8 29

34 Abbildungsverzeichnis 2.1 Medienstation in der Einstein Ausstellung Modellgetriebene Softwareentwicklung Begriffe der MDD, Quelle: [SVEH07, S. 28] (Meta-)Modellebenen, Quelle: Angelehnt an [SVEH07, S. 60] und [PM06, S. 49] Modellierung und Validierung, Quelle: [TPB + 07, S. 67] Modellmodifikation, Quelle: [SVEH07, S. 199] Modell-Weaving, Quelle: [SVEH07, S. 200] Modelltransformation, Quelle: [SVEH07, S. 200]