Modellgetriebene Codegenerierung auf Basis von UML Klassendiagrammen und dem Austauschformat XMI

Transkript

1 Modellgetriebene Codegenerierung auf Basis von UML Klassendiagrammen und dem Austauschformat XMI Nicole Steffi Pilkenroth D I P L O M A R B E I T eingereicht am Fachhochschul-Masterstudiengang Digitale Medien in Hagenberg im Juni 2010

2 Copyright 2010 Nicole Steffi Pilkenroth Alle Rechte vorbehalten ii

3 Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Hagenberg, am 25. Juni 2010 Nicole Steffi Pilkenroth iii

4 Inhaltsverzeichnis Erklärung Danksagung Kurzfassung Abstract iii vi vii viii 1 Einführung und Motivation Ausgangslage Motivation Aufbau der Diplomschrift MDSD und Codegenerierung MDSD Umfrage 2009 von der IF-ModE Begriffsdefinitionen Model Driven Development Codegeneratoren Transformationsarten Unified Modeling Language Grundlagen der UML Klassendiagramme Erweiterung der UML für MXML XMI XML Metadata Interchange State of the Art UML Werkzeuge Einteilung von UML Werkzeugen ArgoUML EnterpriseArchitect VisualParadigm iv

5 Inhaltsverzeichnis v 5 CoMo CodeModeler CoMo im Überblick Flexframework Architektur Implementierung Bedienung Ausblick: XMI Export Generatorkomponente Konzeptionelle Vorüberlegungen Architektur Templates und Einbindung von anderen Programmiersprachen Generierter Code Bedienung Evaluierung der Generatorkomponente Problemstellung und Zielsetzung Funktionsumfang Nutzen geplante Ergebnisse erreichte Ergebnisse Ablauf einer Transformation Mögliche Erweiterungen Fazit Zusammenfassung Ausblick A Inhalt der CD 66 Literaturverzeichnis 70

6 Danksagung An dieser Stelle möchte ich mich bei allen bedanken, die mich beim Schreiben dieser Arbeit unterstützt haben. Dabei geht ein besonderer Dank an Regine Pilkenroth für die unermüdliche Unterstützung sowohl im Bachelorstudium, als auch im Masterstudium. Bei der FH Oberösterreich, Campus Hagenberg, möchte ich mich für die freundliche Aufnahme in das Masterstudium bedanken. Ein besonderer Dank geht an Dipl.-Ing. Rimbert Rudisch-Sommer der mich beim Schreiben dieser Arbeit tatkräftig unterstützt und für neue Anregungen gesorgt hat. Des Weiteren bedanke ich mich bei meinen Kommilitonen, die mich sehr gut in ihre Gemeinschaft aufgenommen haben und mit denen ich sehr viel Spaß hatte. vi

7 Kurzfassung Die Zahl der Flash/Flexentwickler nimmt stetig zu. Leider ist ActionScript bei vielen Entwicklern noch nicht als vollwertige Programmiersprache anerkannt, was die Suche nach einem UML-Werkzeug oder gar einem Codegenerator sehr erschwert. Die Zahl der vorhandenen Tools ist sehr gering. Bei einigen ist die Bedienung entweder sehr schwierig, es fehlen wichtige Funktionen und die Generierung von Code wird nur teilweise oder überhaupt nicht unterstützt. Durch diese Situation gehen vielen Flexentwicklern wertvolle Vorteile, nicht nur bezüglich UML, sondern auch der modellgetriebenen Softwareentwicklung verloren. Vorteile wie eine sehr gute Dokumentation des Vorhabens, gleich bleibende Codequalität oder das Round-Trip Engineering sind nur einige. Trotz vieler angenehmer Nebeneffekte nutzen bis Heute nur wenige Flex-Softwareentwickler im allgemeinen die Möglichkeiten von CASE-Tools. Um gerade im Bereich Flex die Nutzung von modellgetriebener Softwareentwicklung zu unterstützen, wurde im Rahmen dieser Arbeit ein UML- Werkzeug speziell für ActionScript und MXML entwickelt. Es geht dabei auf die Besonderheiten der beiden Sprachen ein und erweitert die UML-Notation um wichtige MXML-Elemente. Integriert ist ein Codegenerator, der nicht nur einzelne Klassen, sondern komplette Projekte generieren kann. Als eine Erweiterung und als Möglichkeit unabhängig von der Zielsprache Code zu generieren, wurde ein generischer Codegenerator auf Basis von XMI und XSLT entwickelt. Durch die vorgestellten Werkzeuge ist ein Schritt in Richtung modellgetriebener Softwareentwicklung mit Flex getan. Durch die einfache Bedienung, Funktionen die auf das Wesentliche begrenzt sind und die gleich bleibende Qualität des generierten Codes sollen die Entwicklung von Flexprojekten vorteilhaft unterstützen. vii

8 Abstract At the moment the computer language ActionScript is not generally accepted by web-developers. Due to this circumstance it s very hard to find good working UML tools or a generator for source codes. As a result, many Flex developers are missing the promises of the model driven software development. For instance the benefits like documentation, a consistent code quality and round-trip engineering, to name only a few. Especially in the Flex world an UML tool with an integrated code generation was developed to support the model driven software development. In addition a stand-alone generic generator component was designed. With the help of XMI and XSLT templates the generator creates the code. The foundation for the model driven software development in the Flex world was laid with both of these tools. Easy handling, minimalistic functions and excellent quality of the source code should help to develop projects with Flex. viii

9 Kapitel 1 Einführung und Motivation 1.1 Ausgangslage Modellgetriebene Softwareentwicklung bietet zweifelsohne zahlreiche Vorteile. Durch eine Automation können verschiedene Schritte der Entwicklung vereinfacht und unterstützt werden. Für die Entwicklung mittels Java gibt es einige Werkzeuge, die diese Art der Softwareentwicklung unterstützen. Im Bereich der Flexentwicklung bietet der Markt für ActionScript und MXML gemeinsam so gut wie keine Tools an. Zwar gibt es für die Programmiersprache ActionScript alleine einige wenige Tools, in Kombination mit der Layoutsprache MXML sucht der Flexentwickler leider vergebens. Deshalb wurde im praktischen Teil zur Diplomarbeit das UML-Werkzeug CoMo CodeModeler entwickelt. Es ist direkt auf die Bedürfnisse von ActionScript und MXML zugeschnitten und ist in der Lage, ein graphisches Modell in Quellcode zu transformieren. Auf Grundlage dieses Tools wurde eine Erweiterung realisiert, die es ermöglicht aus einem Diagramm ActionScript mit MXML, aber auch verschiedene alternative Zielsprachen zu generieren. 1.2 Motivation Die Idee die hinter CoMo steckt ist ein Codegenerierungstool, welches ActionScript 3 und MXML vereint. Bei der Entwicklung von Software sollte man sich vorher Gedanken über den generellen Aufbau machen. Dazu gehört die Klassenstruktur und deren zugehörigen Attribute und Operationen. Ein Ansatz dafür ist die modellgetriebene Softwareentwicklung, kurz MDSD. Als ein Standard dafür wurde das MDA, Model Driven Architecture, von der OMG umgesetzt. Dabei wird ein Modell in Quellcode transformiert. Nach der Recherche nach bereits bestehenden Applikationen stand fest, dass es kein Tool gibt, welches sowohl ActionScript 3 und MXML kombiniert. Aber gerade für Flexentwickler ist dies ein gutes Feature, um auch gleich den grafischen Bezug zur eigenen Anwendung herzustellen. Des Weiteren sollte es 1

10 1. Einführung und Motivation 2 möglich sein, die einzelnen packages einer Projektstruktur abzubilden und so den kompletten Aufbau des Projektes abzubilden. All diese Vorüberlegungen können dann in Code übersetzt werden und der Benutzer kann sofort mit der weiteren Programmierung beginnen. Die Erweiterung von CoMo durch einen generischen Codegenerator würde die Möglichkeiten beschränken, ein UML-Werkzeug seiner Wahl zu benutzen. Um dieses Problem zu umgehen, wurde die Entscheidung getroffen, einen Stand-Alone-Generator zu erstellen. Dieser ist unabhängig von CoMo, arbeitet aber dennoch auf Grundlage von Klassendiagrammen. Damit der Generator die Modelle verarbeiten kann, werden diese zuvor in das Standardformat XML Metadata Interchange (XMI) übersetzt. XMI ist ein Austauschformat für Objekte, welches die graphische Repräsentation eines Modells in eine textuelle Repräsentation überführt. Durch den Einsatz dieses Standards kann erwartet werden, dass die Generierung von Quellcode von XMI-Daten aus verschiedenen UML-Werkzeugen sehr einfach funktioniert. Durch den zusätzlichen Einsatz von XSL Transformation (XSLT) soll das Ziel erreicht werden, dass der Benutzer sehr einfach eigene Templates erstellen kann, die die Regeln für die Generierung beschreiben. Dadurch wird es möglich, Code für unterschiedliche Programmiersprachen generieren zu lassen. 1.3 Aufbau der Diplomschrift Die vorliegende Diplomschrift gliedert sich in acht Kapitel. Die theoretischen Grundlagen werden in den Kapiteln eins bis fünf gelegt. Das praktische Konzept und deren kritische Prüfung werden in den Kapiteln sechs und sieben behandelt. Das Kapitel 1 gibt eine kurze Einführung in das Thema und geht auf die Motivation dieser Diplomschrift ein. Kapitel 2 geht auf die Konzepte der modellgetriebenen Softwareentwicklung ein, erläutert verschiedene Ansätze und klärt die wichtigsten Begrifflichkeiten. Des Weiteren wird die Codegenerierung und deren verschiedenen Ausprägungen vorgestellt. Kapitel 3 beschäftigt sich mit der Unified Modeling Language. Es gibt sowohl einen Überblick über diesen Standard, als auch über Erweiterungsmöglichkeiten bezüglich MXML. Für den Austausch der UML-Diagramme wird der Standard XMI untersucht. Im Kapitel 4 werden die aktuellen Werkzeuge für die Modellierung von UML-Diagrammen untersucht und verglichen. Den UML-Grundlagen folgend, wird im Kapitel 5 auf die Umsetzung von CoMo eingegangen.

11 1. Einführung und Motivation 3 Das Kapitel 6 enthält alle konzeptionellen Überlegungen bezüglich eines generischen Codegenerators, und beschreibt die Umsetzung eines solchen als unabhängige Komponente. Kapitel 7 setzt sich kritisch mit der erstellten Komponente auseinander. Es werden erreichte und geplante Ziele gegenübergestellt, eingesetzte Techniken überprüft und mögliche Alternativen angesehen. Kapitel 8 fasst die Arbeit zusammen und gibt einen Ausblick auf mögliche Erweiterungen.

12 Kapitel 2 Model Driven Software Development und Codegenerierung Model Driven Software Developmentist ein Ansatz eine modellgetriebene Entwicklung bei der Erstellung von Software einzusetzen. Model Driven Software Development (MDSD) ist einer von verschiedenen Anätzen und Techniken auf dem Markt. Diese verwenden zum Teil gleiches Vokabular oder auch gleiche Grundideen. Begriffsdefinitionen, weitere Ansätze sowie die Erzeugung von Quellcode werden im Verlauf des Kapitels erläutert. Zum besseren Verständnis wird an dieser Stelle noch kurz der Unterschied zwischen modellbasierter und modellgetriebener Modellnutzung erläutert. Bei der modellbasierten Nutzung dient ein Modell bei der Softwareentwicklung meist nur zu Zwecken der Dokumentation. Das heißt, dass die zu entstehende Software mit zum Beispiel der UML grafisch dokumentiert wird und die Programmierer anschließend händisch aus diesem Modell die Software entwickeln. Dem gegenüber steht der Ansatz der modellgetriebenen Entwicklung, bei dem das Modell nicht nur für Dokumentationszwecke erstellt, sondern um aus diesem automatisch Quellcode zu generieren MDSD Umfrage 2009 von der IF-ModE Nicht nur in der Forschung, sondern auch der Industrie nimmt das Interesse an der modellgetriebenen Entwicklung zu. Um die Aktualität dieser Problematik zu zeigen, soll an dieser Stelle näher auf die MDSD-Umfrage 2009 [20] von der Interoperabilität und Feature-Tracing für Werkzeugketten in der modellgetriebenen Entwicklung (IF-ModE) eingegangen werden. 1 [19] 4

13 2. MDSD und Codegenerierung 5 Die Umfrage befasst sich mit der Verwendung und Verbreitung von modellgetriebenen Methoden und Werkzeugen[20]. Sowohl in deutscher, als auch in englischer Sprache wurden 18 Fragen erstellt, die den Benutzern als Onlineumfrage zur Verfügung gestellt wurde. Es wurden keine ausgewählten Personen angeschrieben, womit die Zielgruppe dieser Umfrage nicht eingeschränkt war. Im Zeitraum vom 01. Juli 2009 bis zum 10. September 2009 haben insgesamt 181 Besucher an der Umfrage teilgenommen. Diese Zahl ergibt sich aus 139 deutschsprachigen und 42 englischsprachigen Teilnehmern. Für die Auswertung der Umfrage konnten allerdings nur 92 Fragebögen herangezogen werden, da die anderen nicht komplett ausgefüllt waren. Die insgesamt 92 Fragebögen setzen sich aus 72 deutschsprachigen und 20 englischsprachigen Fragebögen zusammen. Dies lässt erkennen, dass es eine sehr hohe Absprungrate gibt, sowohl im deutschsprachigen als auch im englischsprachigen Raum. Im nachfolgenden wird kurz das Projekt IF-ModE vorgestellt und auf einige prägnante Ergebnisse der Umfrage eingegangen Das Projekt IF-ModE Das folgende Zitat stammt aus den veröffentlichten Ergebnissen[20] der Umfrage und beschreibt das Projekt IF-ModE in einigen wenigen Sätzen sehr prägnant: Das Projekt IF-ModE (Interoperabilität und Feature-Tracing für Werkzeugketten in der modellgetriebenen Entwicklung) beschäftigt sich mit der Zusammenarbeit bestehender Werkzeuge in Werkzeugketten eines MDSD-Entwicklungsprozesses. Die Schwerpunkte liegen dabei auf der Interoperabilität heterogener Werkzeuge und der Nachvollziehbarkeit von Modellartefakten über die Elemente einer Werkzeugkette hinweg. IF-ModE wird vom Bundesministerium für Bildung und Forschung im Rahmen der Fördermaßnahme KMU-innovativ gefördert. Projektträger ist das Deutsche Zentrum für Luft- und Raumfahrt e. V. (DLR). Das Projekt wird durchgeführt von der Delta Software Technology GmbH und dem OFFIS - Institut für Informatik Auswertung der Ergebnisse All die nachfolgenden grafischen Auswertungen wurden in Anlehnung an die Umfrage [20] erstellt. In dieser Arbeit wird allerdings nicht auf alle Fragen eingegangen, sondern es werden die interessantesten im Bezug auf die modellgetriebene Entwicklung ausgewählt. Die Auswahl an MDSD-Werkzeugen ist sehr groß. Dennoch lässt sich ein Trend bezüglich bestimmter Präferenzen in der Abbildung 2.1 erkennen.

14 2. MDSD und Codegenerierung 6 Xtext 2 RSA 3 Magic Draw 5 Matlab 7 Meta Edit+ Together 4 4 AndroMDA 8 oaw 47 Eclipse GMF 35 Eclipse EMF 54 Keine 2 Abbildung 2.1: Welche MDSD-Werkzeuge nutzen Sie? Zu den meist genutzten gehören EclipseEMF 2, oaw 3 und EclipseGMF 4. Ein sehr kleiner Anteil, nämlich genau 2 Personen, nutzt keine MDSD- Werkzeuge. Die restlichen Personen verteilen sich fast sehr gleichmäßig auf die anderen Werkzeuge. Sehr gut kann in der Abbildung 2.2 abgelesen werden, das die am meisten genutzte Modellierungssprache die UML in der Version 2.0 ist. Auch die Version 1.4 der UML wird noch von einigen wenigen eingesetzt. Insgesamt macht die UML den größten Anteil der Modellierungssprachen in dieser Umfrage aus. Der Einsatz der Codegenerierung ist im produktiven Einsatz mit 52 Stimmen bei der Umfrage sehr hoch und ist damit der Bereich, für den der Code am häufigsten generiert wird. Allerdings stehen dem immerhin 9 Stimmen gegenüber, die überhaupt keine Codegenerierung einsetzen. Dennoch geht aus der Abbildung 2.3 eindeutig hervor, dass der Einsatz der Codegenerierung, auch wenn nur zur Erprobung oder in Pilotprojekten, viel Anklang findet. In der Abbildung 2.4 ist deutlich zu sehen, dass es zwei Template-Sprachen gibt die keine große Zustimmung erhalten und sehr weit abschlagen. Dazu gehört Code Smith und die Templates für Microsoft DSL-Tools. Ganz weit vorn ist die Sprache XPand, auf die kurz im Abschnitt eingegangen wird

15 2. MDSD und Codegenerierung 7 BPMN 16 Ecore-DSLs 46 UML-DSLs 31 UML UML Abbildung 2.2: Welche Modellierungssprachen nutzen Sie? Produk v 52 In einem Pilotprojekt 21 Erprobung der Technologie 20 Überhaupt nicht 9 Abbildung 2.3: Wie stark nutzen Sie Code-Generierung? Auch gibt es immerhin noch 13 Stimmen, die gar keine Template-Sprache einsetzen. Bei der Frage nach dem Austausch von Artefakten wurden mehr als die Hälfte der Stimmen für die Modelle selbst abgegeben. Das zeigt, dass die Modelle mit das Wichtigste in der MDSD sind. Dennoch gibt es noch 9 Stimmen, die überhaupt keinen Austausch von Artefakten zwischen Werkzeugen vornehmen, wie in der Abbildung 2.5 zu sehen ist.

16 2. MDSD und Codegenerierung 8 Velocity 12 Code Smith 2 Templates für Microso DSL-Tools 2 Xpand 43 JET 17 Keine 13 Abbildung 2.4: Welche Template-Sprachen verwenden Sie für die Code-Generierung? Modelltransforma on 23 Metamodelle 44 Modelle 70 Keine 9 Abbildung 2.5: Welche Arten von Artefakten tauschen Sie zwischen Werkzeugen im Rahmen von MDSD aus (z.b. Modelle zwischen Modellierungswerkzeugen und Code-Generatoren)? Für eine komplette Übersicht über alle Fragen und deren Auswertung steht die PDF [20] zur Verfügung.

17 2. MDSD und Codegenerierung 9 Domäne Metamodell abstrakte Syntax ausgedrückt mit Mitteln statische Semantik <<instance of >> ausgedrückt mit Mitteln konkrete Syntax DSL formales Modell respektiert Semantik Abbildung 2.6: Begriffzusammenhänge in der MDSD [19, in Anlehnung an S. 28] 2.2 Begriffsdefinitionen An dieser Stelle des Kapitels werden die grundlegenden, für das weitere Verständnis, wichtigen Begriffe definiert. Damit kann davon ausgegangen werden, dass ein einheitliches Verständnis vorliegt. In der Abbildung 2.6 werden die wichtigsten Begriffe und die Beziehung zueinander dargestellt Domäne Eine Domäne oder auch Einsatzbereich bildet das Problemfeld oder Interessengebiet der zu erstellenden Software ab. Diese wird durch die Domäne eingegrenzt. Durch diese Eingrenzung wird eine besondere Anforderung an die Modellierung gestellt, da diese auf das Anwendungsgebiet abgestimmt werden muss. Sollten die Anforderungen einer Domäne zu groß werden, können sie in sogenannte Subdomänen aufgeteilt werden. Das Prinzip der Aufteilung nennt man auch divide and conquer, zu deutsch: teile und herrsche. Dadurch wird die Komplexität einer Domäne in viele kleine Domänen aufgeteilt und jede Subdomäne enthält eine eigene Verantwortlichkeit. Dabei ist es möglich, das verschiedene Modelle verschiedene Domänen besitzen können. Domänen können in fachliche und technische Domänen eingeteilt werden. Eine technische Domäne bildet dabei die Viewpoints der Softwarearchitektur [19, S. 28] ab. Beispiele sind Komponentenmodelle oder Datenmodelle. Dahingegen sind die fachlichen Domänen die, die eine genaue Ausprägung auf die gewählte Domäne abbilden.

18 2. MDSD und Codegenerierung 10 Meta-Metamodell-Ebene Metamodell-Ebene Modell-Ebene Abbildung 2.7: Meta-Ebenen Hierarchie Metamodell Ein Metamodell stellt die Ontologie der Domäne dar. Das heißt, das es eine formalisierte Beschreibung eines Problems ist. Dieses Metamodell wird aus der statischen Semantik und der abstrakten Syntax gebildet. Die meisten Metamodelle sind UML-basiert, was aber nicht zwingend notwendig ist Meta-Metamodell Neben dem Metamodell gibt es auch das Meta-Metamodell, und stellt das Metamodell des Metamodells [19, S. 31] dar. Es gibt zwei sehr bekannte Meta-Metamodelle: zum einen das Meta Object Facility 5, kurz MOF, von der OMG. Dies ist auch das am häufigsten verbreitetste Meta-Metamodell. Zum anderen gibt es Ecore 6, welches ein Meta-Metamodell vom Eclipse Modeling Framework (EMF) ist. Bei der Modellierung ist es möglich, beliebig viele Meta-Ebenen zu haben. Allerdings hat sich in der Praxis eine dreistufige Ebenenhierarchie durchgesetzt. Die erste Ebene ist die Modellebene, die zweite die Metamodellebene und die Meta-Metamodellebene als dritte Ebene. Diese Hierarchie wird in Abbildung 2.7 nochmals verdeutlicht Abstrakte und konkrete Syntax Die Syntax einer Sprache stellt ihre Grammatik dar. So hat auch die MDSD unterschiedliche Grammatiken: die Abstrakte und die Konkrete. Verschiedene konkrete Syntaxen können zu einer abstrakten Syntax gehören. Die abstrakte Syntax beschreibt die Beziehung von Modellelementen untereinander. Das heißt, dass die konkrete Syntax abstrahiert wird. Darstel

19 2. MDSD und Codegenerierung 11 lungsform der Syntax sind meist Klassen, Attributen und Referenzen, welche eine generische Struktur bilden. Sie beschreibt das vorhandene Vokabular, also den Aufbau der Sprache. Von einer abstrakten Syntax wird häufig im Zusammenhang beim Bau eines Compilers gesprochen. Was ein Programmierer genau eingeben muss bzw. wie der Quelltext aussieht, wird durch die konkrete Syntax beschrieben. Sie wird vom Parser oder Instantiator eingelesen, welcher dann konkrete Instanzen der abstrakten Syntaxklassen erstellt. Vorteil der konkreten Syntax ist, dass sie von Menschen gut lesbar ist, zum Beispiel in Form einer Backus Naur Form (BNF) 7. Es werden alle Elemente definiert, die die Sprache hat. Zum Beispiel vorhandene Schlüsselwörter, Trennzeichen oder vorhandene Konstanten Statische und dynamische Semantik Von Semantik spricht man immer dann, wenn es um die Bedeutung von etwas geht. Im Sinne der MDSD wird diese in die dynamische und statische Semantik unterteilt. Die dynamische Semantik beschreibt bzw. drückt aus, was welches Sprachelement bedeutet. Bei der statischen Semantik geht es vielmehr darum, Bedingungen festzulegen, welche definieren, wann ein Modell wohlgeformt ist. Diese Bedingungen werden auch Constraints genannt und sind abhängig von der zuvor vorgestellten abstrakten Syntax. Durch die Festlegung von Constraints für Modelle ist es möglich sehr früh Modellierungsfehler aufzudecken bzw. zu erkennen. Dadurch kann die Compilierungszeit verbessert werden, da bereits vor der Laufzeit mögliche Fehler aufgedeckt werden. Ein Beispiel für die statische Semantik ist die Vorgabe, dass Variablen deklariert werden müssen. [19, S. 30] Domänenspezifische Sprache Bekannt als Domain Specific Language (DSL) ist die domänenspezifische Sprache. Es ist eine genau auf die Domäne zugeschnittene Programmiersprache [19, vgl. S. 30], welche die Besonderheiten dieser abdeckt. Im Gegensatz zur DSL gibt es auch universell einsetzbare Programmiersprachen wie zum Beispiel Java. Diese sind nicht einer Domäne zugeschnitten und bieten sehr viel Mehraufwand im Bezug auf spezielle Domänen. Eine DSL wird aus den folgenden Bestandteilen gebildet: Metamodell, dynamische und statische Semantik, sowie die abstrakte und konkrete Syntax. Siehe dazu auch die Abbildung eine kontextfreie Grammatik oder Metasprache

20 2. MDSD und Codegenerierung 12 Metamodell abstrakte Syntax statische Semantik konkrete Syntax DSL Semantik Abbildung 2.8: Bildung einer DSL Formale Modelle Ein Programm, dass in einer DSL geschrieben ist [19, S. 31] nennt man formales Modell. Von einem formalen Modell spricht man dann, wenn dieses automatisiert in Quellcode transformiert werden kann Transformation Von einer Transformation im Sinne der MDSD spricht man immer dann, wenn aus einem formalen Modell etwas Anderes erzeugt wird. Dieses Ergebnis kann sowohl Quellcode, als auch ein neues Modell sein. Sprich, dass Modell wird auf die Gegebenheiten des Lösungsraums abgebildet. Ist das Ergebnis einer Transformation Quellcode, dann spricht man von einer Model-zu-Code-Transformation (M2C). Der Begriff Generierung wird aber auch häufiger eingesetzt. Eine Generierung ist immer zielplattformspezifisch und damit abhängig von der gewählten Plattform. Ist das Ergebnis ein anderes Modell sein, spricht man von der Model-zu- Model-Transformation (M2M) oder auch nur Modelltransformation. Hierbei bleibt das Quellmodell unverändert, es wird lediglich auf ein anderes transformiert. Für eine genauere Einteilung der Transformationen sollte der Abschnitt 2.5 gelesen werden Plattform Eine Plattform ist der Lösungsraum oder die Zieltechnik eines Modells. Beispiele für Zieltechniken sind JavaServer Faces oder Hibernate.

21 2. MDSD und Codegenerierung Plattform-Idiome Ein Idiom ist eine Besonderheit oder Eigenart von Etwas. Auf eine Plattform bezogen, sind es Besonderheiten des Lösungsraums. Das heißt, welche Best- Practices 8 gibt es in dieser Plattform. Ziel eines Plattform-Idioms ist die Erstellung von gut aussehendem Code Produkt Am Ende einer Softwareentwicklung entsteht ein Produkt, also eine fertige Software oder auch Komponente. Dieses Produkt setzt sich wie folgt zusammen: P rodukt = generiertercode + P lattf orm + handgeschriebenercode 2.3 Model Driven Development Model Driven Development (MDD) verfolgt den Ansatz, aus fachlichen Modellen technische Modelle und Quellcode automatisch zu generieren, was über eine automatische Transformation erfolgt. Die fachlichen Modelle enthalten all das, was die Software später können soll, zum Beispiel in Form von UML. Da hingegen beschreiben die technischen Modelle wie das ganze umgesetzt wird. Modelle selbst können dabei sowohl textuell, als auch grafisch zum Beispiel mit der UML modelliert werden. Bei dem Transformationsvorgang werden diese Modelle dann entweder interpretiert oder zunächst in Quellcode überführt, welcher anschließend compiliert und ausgeführt werden kann. Modelle dienen der Abstraktion, welches eines der Ziele von MDD ist. Des Weiteren sind die Modelle zielsprachenunabhängig, was den Vorteil hat, das zur Zeit der Entwicklung noch keine Aussagen über die Zielsprache vorliegen muss. Ebenfalls steigern sie die Softwarequalität und die Wartbarkeit, da ein Modell auch als Dokumentation einer Software dient. Ein weiterer wichtiger Vorteil ist die Portabilität. Sprich, ein Modell ist plattformunabhängig und kann für verschiedene Betriebssysteme, Compiler oder Architekturen übersetzt werden. Ein weiteres Ziel ist es, geringe Redundanz 9 im Code zu haben. Voraussetzung dafür ist, dass Komponenten oder Teile des Modells wiederverwendbar erstellt und entwickelt werden. Als eine Ausprägung der MDD wird in dieser Arbeit das Hauptaugenmerk auf die MDSD gelegt. Dennoch gibt es verschiedene Ansätze diese Vorstellungen der modellgetriebenen Entwicklung umzusetzen. Im folgenden sollen diese kurz zusammengefasst werden. 8 Erfolgsrezepte; erfolgreich eingesetzte Verfahren 9 mehrfaches oder doppeltes Auftreten von Informationen oder Ressourcen

22 2. MDSD und Codegenerierung MDA Model Driven Architecture Die Spezialisierung Model Driven Architecture (MDA) ist einer der bekanntesten Ansätze neben der MDSD, auf die später noch eingegangen wird. MDA ist ein Standard der OMG 10 und legt den Fokus auf die Interoperabilität und die Portabilität. Ziel der MDA ist es, die fachliche Logik von der technologischen Umsetzung[21] zu trennen. So wird Software meistens aus Modellen generiert, wobei hier ein großes Problem in kleinere Teile zerlegt wird. Es ist sogar möglich, dass man ausführbare UML-Modelle erstellt, was auch Executable UML genannt wird. Hierbei wird nicht nur Quellcode generiert, sondern dieser auch gleichzeitig ausgeführt. Man erhält also eine lauffähige Version der Software. Die MDA unterstützt nur das Metamodell MOF, welches ebenfalls von der OMG standardisiert wurde. Siehe dazu den Punkt 2.2 Metamodell Software Factories Ein weiterer Ansatz, welcher sehr stark von Microsoft geprägt wurde, sind die Software Factories. Dabei liefern Software Factories bewährte Techniken und Grundlagen für den sofortigen Einsatz mit. Solche fertigen Factories kann man direkt bei Microsoft beziehen. Bei Software Factories geht es darum, eine angepasste Integrated Development Environment (IDE), zum Beispiel Visual Studio, für eine bestimmte Domäne einzusetzen. Dadurch wird die Entwicklung für genau diese Domäne stark vereinfacht, begrenzt aber auch im gewissen Maße die Arbeit. Der modellgetriebene Ansatz macht nur einen kleinen Teil der Software Factories aus, allerdings einen wichtigen. Die Modelle sind normalerweise grafisch, wobei aber kein Standard der OMG verwendet wird. Also kein MOF oder UML. Es wird ein eigenes Metamodell eingesetzt, das sogenannte Meta Data Framework (MDF) Generative Programming Abschließend noch ein kurzer Einblick in das Generative Programming. Hierbei handelt es sich um eine 100%ige Automation[11]. Zum Einsatz kommt dieses Software Engineering Paradigma 11 eher bei der Entwicklung kleinerer Softwareentwicklungen oder auch Softwarefamilien. Im Gegensatz zu anderen Ansätzen verwendet die Generative Programming (GP) meist textuelle DSLs. Bekannt wurde das GP durch das Buch Generative Programming [6] von K. Czarnecki und U. Eisenecker. Aus diesem Buch[6, S. 5] stammt auch das folgende Zitat, in dem das GP wie folgt definiert ist: Muster für die Softwareentwicklung

23 2. MDSD und Codegenerierung 15 Generative Programming (GP) is a software engineering paradigm based on modeling software system families such that, given a particular requirements spcification, a highly customized and optimized intermediate or end-product can be automatically manufactored on demand from elementary, reusable implementation components by means of configuration knowledge. Weitere Ansätze, auf die hier nicht näher eingegangen wird, sind beispielsweise das Model-integrated Computing, die sprachorientierte Programmierung oder die domänenpezifische Modellierung. 2.4 Codegeneratoren Was sind Codegeneratoren Ein Codegenerator ist ein Metaprogramm, welches als Ergebnis ein neues Programm erzeugt. Dabei werden Modelle oder andere formale Sprachen in Quellcode einer speziellen Zielsprache übersetzt. Dieses Ergebnis wird als Generat bezeichnet. Um zu diesem Generat zu gelangen, werden verschiedene Schritte in einem Generator durchlaufen[19, S. 139]: 1. Modelle einlesen 2. Modelle verlinken 3. Modelle validieren 4. Modelle transformieren 5. Code generieren Patterns der Codegenerierung Thomas Stahl stellt in seinem Buch [18] verschiedene Patterns der Codegenerierung vor, mit der man die verschiedenen Ansätze der Codegenerierung beschreiben kann. Im Folgenden eine kurze Zusammenfassung der wichtigsten Ansätze. Templates und Filtering Die einfachste Form, auch direkte Codegenerierung genannt, ist das Muster Templates und Filtering. Templates sind Vorlagen, in denen Platzhalter enthalten sind. Diese können dann an Werte des Modells gebunden werden. Durch die anschließende Iteration über die Spezifikation, die textuell vorliegt, kann dann Quellcode generiert werden. In Abbildung 2.9 ist dieses Prinzip zu sehen. Ein bekanntes Beispiel für dieses Muster ist die Iteration einer XSLT über eine XML. XSLT definiert die Regeln, nach der die XML Datei umgewandelt

24 2. MDSD und Codegenerierung 16 Filter anwenden auf Untermenge der Spezifikation anwenden auf Templates Spezifikation Generierter Code Abbildung 2.9: Templates und Filtering [18, vgl. S. 176] parsen Konfiguration Spezifikation basiert auf Metamodell erstellt instance of Metamodellinstanz anwenden auf Templates Generierter Code Abbildung 2.10: Templates und Metamodell [18, vgl. S. 178] werden soll. Hierbei kann es aber sehr schnell sein, dass die XSLT sehr groß wird. Deshalb ist der Einsatz eher für kleinere Systeme geeignet, um den Überblick weiterhin zu gewährleisten. Templates und Metamodell Im Gegensatz zur Generierung mit Templates und Filtering ist die Generierung mittels Templates und Metamodell ein mehrstufiger Generierungsprozess. Dabei wird als erstes die XML bzw. die Spezifikation eingelesen und geparst. Anschließend wird das Metamodell instanziiert. Aus dieser Kombination plus die Templates kann anschließend der Code generiert werden. Der Vorteil ist, dass die Templates nicht direkt auf die Spezifikation angewendet werden, sondern auf die Instanz des Metamodells. Somit ist die Abhängigkeit zu der konkreten Syntax geringer und es besteht die Möglichkeit, das Modell mit Hilfe des Metamodells zu verifizieren. Abbildung 2.10 zeigt das Prinzip von Templates und Metamodell.

25 2. MDSD und Codegenerierung 17 Generator (1) erstelle & instanziiere Spezifikations- Frame (2) instanziiere und parametriere Code- Code- Code- Frame Frame Frame {wiederhole} instanziiere und parametriere (3) generiere Generierter Code Abbildung 2.11: Frame-Prozessoren [18, vgl. S. 179] Frame-Prozessoren Frames stellen die Spezifikation des zu generierenden Codes dar. Innerhalb der Frames gibt es sogenannte Slots, die wie bei den Templates an die Werte vom Modell gebunden werden. Es ist möglich solche Slots auch zu schachteln, die mehrwertige Slots oder Collection genannt werden. Für die Generierung von Code muss der Frame instanziiert werden, genau wie eine Klasse in der Programmierung auch instanziiert werden muss. Anschließend kann der Code generiert werden. Eine grafische Darstellung zeigt die Abbildung API-basierte Generatoren Die wohl bekannteste Art der Codegenerierung ist die API-basierte Generierung, welche in Abbildung 2.12 zu sehen ist. Ein Application Programming Interface (API) ist eine Schnittstelle die beschreibt, wie man Zugriff auf ein bestimmtes System erhält. Ein API-basierter Generator arbeitet immer auf der abstrakten Syntax der Zielsprache wodurch sich eine Abhängigkeit ergibt. Um auf dieser arbeiten zu können, wird dem Generator eine API der jeweiligen Zielplattform zur Verfügung gestellt. Dadurch ergibt sich der Nachteil, dass gleichartiger Code immer wieder per Hand programmiert werden muss. Das heißt, es gibt nicht wie bei den Templates Platzhalter, sondern es wird immer der gesamte Code in der Spezifikation programmiert. Inline-Generierung Bei der Inline-Generierung, siehe Abbildung 2.13, werden direkt im Quellcode verschiedene Konstrukte bzw. Artefakte angegeben, die dann anschließend direkt an dieser Stelle beim Compilieren durch weiteren Code ersetzt wer-

26 2. MDSD und Codegenerierung 18 Grammar AST/CST formuliert auf Basis der instanceof, entspricht Client- Programm verwendet API erstellt oder modifiziert Code Abbildung 2.12: API-basierte Generatoren [18, vgl. S. 181] Konfiguration {optional} {optional} Integrierter Compiler Quellcode enthält alle Variantenspezi. preprocess Quellcode alle Varianten aufgelöst preprocess [all resolved] Quellcode einige Varianten aufgelöst compilation Maschinenoder Bytecode Abbildung 2.13: Inline-Generierung [18, vgl. S. 183] den. Der entstandene Code kann entweder normaler Quellcode, aber auch Byte- oder Maschinencode sein. Beispiele für diese Art der Generierung sind die C++-Templates oder der C++-Präprozessor. Code-Attribute Das Muster der Code-Attribute ist eher weniger modellgetrieben, da das erzeugte Generate direkt am Attribut der Spezifikation eingefügt wird. Der Ursprung dieser Art liegt in der Java-Programmierung mit Einführung von JavaDoc. Bei der Generierung werden spezielle Attribute im Quellcode eingefügt, welche dann ersetzt werden. Durch die Angabe der Attribute

27 2. MDSD und Codegenerierung 19 direkt in der Spezifikation hat der Generator Zugriff auf viele Informationen die bereits im Code vorhanden sind. Dazu gehören zum Beispiel die Kommentare oder auch dem abstrakten Syntaxbaum 12 (AST). Im Bereich der Flexprogrammierung können die sogenannten metadata tags[1] ebenfalls als Code-Attribute angesehen werden. Sie teilen dem Compiler zur Laufzeit mit, wie der Inhalt der Komponente benutzt wird. Dabei wird kein ausführbarer Code erzeugt, sondern Informationen bereitgestellt, wie der vorhandene Code compiliert werden soll[1]. Code-Weaving Wie der Name schon vermuten lässt, handelt es sich bei dieser Art der Generierung um die Zusammenführung verschiedener Quellcodebestandteile. Der vorliegende Code muss zunächst analysiert werden, um dann die so genannten JoinPoint oder Hooks festzulegen. Diese JoinPoint oder Hooks kennzeichnen die Stellen im Code, an denen dieser zusammengeführt werden kann. Der Weaver fügt dabei die verschiedenen Codeteile zusammen, der vollständig, aber unabhängig voneinander ist. Zusammenfassend kann festgehalten werden, dass die templatebasierten Codegeneratoren immer dann eingesetzt werden, wenn sehr viel gleichartiger Code erzeugt wird. Wenn es um die Generierung von feingranularen Code geht, dann sollten besser API-basierte Codegeneratoren eingesetzt werden Konstruktion eines Codegenerators Bei der Erstellung eines effizienten Codegeneratoren gibt es Voraussetzungen die es zu erfüllen gibt. Als Erstes muss die Sprache die verwendet wird generell in der Lage sein Quellcode zu generieren. Des Weiteren sollte vor Beginn der Planung eines Codegenerators darauf geachtet werden, welche Art von Typisierung die Sprache bereitstellt, wie gut die Modellabfragesprache ausgereift ist und wie es der Sprache möglich ist Texte zu konkatenieren, sprich verschiedene Stringliterale zusammenzufügen. In jedem Fall muss die Sprache die Möglichkeit bieten, einen Text in eine Datei zuschreiben, bestimmte Werte aus dem Eingabemodell lesen zu können und die Möglichkeit einen statischen Text mit den dynamischen Werten aus dem Modell zu konkatenieren[19, S. 145]. Wie bereits im Abschnitt beschrieben gibt es verschiedene Arten der Codegenerierung. Die Erstellung eines Generators wird nicht so feingranular eingeteilt, sondern man fasst diese Arten in drei Kategorien zusammen. Dazu...) 12 logische Baumstruktur, die nur nützliche Dinge enthält (keine Kommentare, Klassen

28 2. MDSD und Codegenerierung 20 gehört die template-basierte Generierung, die Generierung mit Hilfe von imperativen Programmiersprachen und eine Kombination aus Templatesprache mit einer funktionaler Sprache. Da die einzelnen Arten bereits beschrieben wurde, soll in diesem Abschnitt darauf eingegangen werden, was konkret für die Konstruktion eines Generators beachtet werden muss Codegenerierung mit Templates Der Einsatz von Templates ist immer dann von Vorteil, wenn viel statischer Text generiert werden soll. Der dynamische Text kommt dabei aus dem Modell und wird an die Stelle der Tags gesetzt. Die Sprache die zum Einsatz kommt, sollte zumindest grundlegende Kontrollstrukturen kennen und können. Ebenfalls sollte diese Templatesprache auch eine Form der Modularisierung bieten Codegenerierung mit imperativen Programmiersprachen Bei der Verwendung einer imperativen oder auch befehlsorientierten Programmiersprache werden Folgen von Anweisungen ausgeführt, die nacheinander den Programmstatus explizit ändern. Im Gegensatz dazu beschreiben deklarative Sprachen was passiert, aber nicht wie etwas passiert. Der Vorteil bei der Nutzung einer imperativen Sprache ist eine größere Modularisierung als bei der Nutzung von Templates. Das heißt, dass es möglich ist Klassen zu erstellen, die die Konzepte der Zielsprache umsetzen. Diese erstellten Klassen können, wie auch in der OOP, wiederverwendet werden Codegenerierung mit Template- und funktionaler Sprache Durch die Kombination einer template-basierten Sprache und einer funktionalen Sprache können die Vorteile der Beiden gut genutzt werden. Am Beispiel der openarchitectureware 4.x[8] sollen diese kurz erläutert werden. Die openarchitectureware kombiniert die Templatesprache XPand und die funktionale Sprache Xtend. XPand bietet die Möglichkeit die Templates zu modularisieren und stellt bereits eine eigene, kompakte Syntax zur Verfügung. Mit Xtend hingegen ist es möglich, die Metamodelltypen zu erweitern und neue Objektelemente zu erzeugen und initialisieren. Alle der vorgestellten Arten haben ihre Vor- und Nachteile. So sollte vor der Erstellung abgewogen werden, welche Funktionen der Generator bieten soll. Anschließend sollte festgelegt werden, mit welcher Vorgehensweise weitergearbeitet werden soll.

29 2. MDSD und Codegenerierung 21 Modifikation Transformation Weaving (a) Modellmodifikation (b) Modelltransformation (c) Modellweaving Abbildung 2.14: Modell-zu-Modell Transformation [19, in Anlehnung an S. 199ff.] 2.5 Transformationsarten Bei der Transformation von Modellen unterscheidet man zwei wesentliche Arten: die Modell-zu-Modell Transformation und die Modell-zu-Code Transformation Modell-zu-Modell Transformation M2M Bei der Modell-zu-Modell Transformation wird kein Code erzeugt sondern ein anderes Modell. Die Erzeugung eines neuen Modells wird in drei Arten unterschieden: Modelltransformation, Modellmodifikation und Modell-Weaving. Bei der Modelltransformation handelt es sich um eine Veränderung des eigentlichen Modells. Dabei bleibt das Quellmodell unverändert und als Ergebnis kommt ein transformiertes Modell heraus. Transformiert heißt in diesem Fall, dass sowohl das Quell- als auch das Zielmodell auf einem unterschiedlichen Metamodell beruhen. Im Gegensatz zur Modelltransformation ist das Ergebnis einer Modellmodifikation ein Zielmodell, welches vom gleichen Metamodell ist wie das Quellmodell. Dabei werden bestehende Quellmodelle modifiziert, so dass das Modell am Ende einen anderen Zustand aufweist. Dabei werden entweder neue Elemente hinzugefügt oder vorhandene Elemente werden bearbeitet bzw. entfernt. Das Modell-Weaving oder auch Modellverwebung ist eine spezielle Art der Modellmodifiktaion. Hier wird nicht aus einem Modell ein modifiziertes Modell erstellt, sondern man verwebt zwei verschiedene Quellmodelle zu einem Zielmodell. Dabei ist es unabhängig davon, welches Metamodell das jeweilige Quellmodell hatte. Die Abbildung 2.14 zeigt das jeweilige Quell- und Zielmodell für die verschiedenen Arten der Modell-zu-Modell Transformation Modell-zu-Code TransformationM2C Die Modell-zu-Code Transformation wird auch Codegenerierung genannt und wird typischerweise mit der Kurzschreibweise M2C abgekürzt. Im Ge-

30 2. MDSD und Codegenerierung 22 gensatz zu der zuvor genannten M2M-Transformationen ist das Ergebnis eine konkrete Syntax bzw. Quellcode. Durch den generierten Code kann nicht nur die Qualität der Software gesteigert werden, es gibt auch noch weitere Gründe die für eine Generierung von Quellcode oder Quellcodeartefakten sprechen. Auch hier hat Thomas Stahl [19, S. 141] sehr gut Ansätze geliefert. Dazu gehören die verbesserte Performance, die Möglichkeit einer Fehlerfrüherkennung, die verbesserte Codegröße oder die Introspection. Eine genaue Erklärung zur Codegenerierung und auch die verschiedenen Möglichkeiten wurden bereits im Abschnitt auf Seite 15 diskutiert. Aber generell läuft die Codegenerierung in folgenden Schritten ab: Als erstes erstellt man ein Modell. Dieses wird mit Hilfe eines Codegenerators, siehe Seite 15, in Code-Artefakte transformiert, welche von der Zielplattform abhängig sind.

31 Kapitel 3 Unified Modeling Language Die Unified Modeling Language, kurz UML, ist eine vereinheitlichte Sprache mit der Software visuell modelliert werden kann. Die Softwarekrise in den 70er Jahren war mit ein Auslöser für die Schaffung eines einheitlichen Standards. Wie genau dieser Standard aussieht und aus welchen Bestandteilen er besteht wird das folgende Kapitel erläutern. Abschließend wird ein Überblick über das Austauschformat XMI gegeben, welches es ermöglicht UML-Diagramme in Form von XML zwischen verschiedenen Programmen auszutauschen. 3.1 Grundlagen der UML Die UML unterscheidet bei der Modellierung zwischen statischen und dynamischen Aspekten. Daher werden die vorhandenen Diagramme in Strukturund Verhaltensdiagramme unterteilt. Insgesamt definiert die UML 13 verschiedene Diagrammarten für verschiedene Anforderungen und kann somit verschiedene Bereiche in der Softwareentwicklung abdecken. Dazu gehören zum Beispiel die Anwendungsfalldiagramme für verschiedene Szenarien, Sequenzdiagramme oder Aktivitätsdiagramme um das Verhalten näher zu beschreiben. Dabei werden die Diagramme immer sprach- und plattformunabhängig, sowie technikunabhängig modelliert. Das heißt, dass bei der Modellierung die genaue Technik für die spätere Umsetzung noch nicht bekannt sein muss und auch die Programmiersprache im Laufe der Erstellung festgelegt werden kann. Verantwortlich für die Spezifikation ist das Standardisierungsgremium Object Management Group (OMG) 1, dem mittlerweile mehr als 800 Unternehmen angehören. Diese Firmen, welche hauptsächlich aus der Softwarebranche kommen, sind an der Entwicklung und Arbeit der UML beteiligt. Einen wichtigen Grundstein legten die drei Amigos Booch, Jacobson und Rumbaugh mit ihren anfangs unabhängigen Spezifikationen. Grady Booch

32 3. Unified Modeling Language 24 zeichnete sich für die Booch-Methode 2 verantwortlich. James Rumbaugh arbeitete an der Object Modeling Technique (OMT) 3 und Ivar Jacobson entwickelte die Object Oriented Software Engineering (OOSE) 4. Später wurden die Spezifikationen zusammengefasst. Erstmals sprach man im Jahre 1996 von UML. Allerdings gab es die erste offizielle Version 1.0 erst Diese war noch nicht von der OMG freigegeben. Erst die Version UML 1.3 wurde von der OMG im Jahre 1999 offiziell freigegeben. UML wurde in der Zwischenzeit ständig weiter entwickelt. Erst im Jahre 2005 gab es Version 1.5. Dann allerdings entschied sich die OMG direkt auf Version 2.0 (2005) zu setzen, welches viele, zum Teil komplette Überarbeitungen enthielt und neue Diagrammtypen enthält. Zum jetzigen Zeitpunkt (Juni 2010) liegt die UML Spezifikation in der Version 2.3 vor, die allerdings noch im Betastadium ist. 3.2 Klassendiagramme Das Klassendiagramm gehört zu den zuvor erwähnten Strukturdiagrammen. Es werden nicht nur die Eigenschaften der Elemente visualisiert, sondern auch die Beziehung der Elemente untereinander. Für den Einsatz einer Modellierungssoftware sprechen viele Gründe. Vor allem auch für die Arbeit in Teams stellen UML-Diagramme ein wichtiges Kommunikationsformat dar. Auch zu Dokumentationszwecken ist UML wichtig. Die Erstellung von Diagrammen findet meist in der Analyse- und Entwurfsphase des Softwareentwicklungsprozesses statt. Dieses dient einer genauen Anforderungserhebung, sowohl für den Kunden, als auch für den Entwickler. Dabei können nicht nur Anforderungen an das System gestellt werden, sondern auch Datenmodelle für Datenbanken erstellt werden. Damit ist bereits ein großer Teil der Software-Entwicklung mit einem Diagramm abgedeckt. Die Architektur wird mit Hilfe von Klassen beschrieben und ist für jeden zugänglich. So können neue Entwickler sich schnell in die bestehende Struktur hineindenken und diese leichter verstehen. Für die Erstellung eines Diagramms stehen verschiedene Notations- oder Modellelemente und Assoziationen zur Verfügung. Die wichtigsten Elemente sind die Klasse, das Interface und die Enumeration. Ebenfalls nicht zu vergessen ist die Notiz, mit der man sich kleinere Hinweise zu den einzelnen Elementen erstellen kann. Um eine Beziehung zwischen diesen Elementen herzustellen gibt es verschiedene Assoziationen, sowie die Aggregation, die Komposition, die Abhängigkeit und die Generalisierung. Die Tabelle 3.1: Notationselemente und Assoziationen gibt einen Überblick über die Spezi

33 3. Unified Modeling Language 25 fikationen und erklärt die einzelnen Funktionen innerhalb eines Klassendiagramms. 3.3 Erweiterung der UML für MXML Grundlage dieser Arbeit ist der UML Editor CoMo CodeModeler. Eine genaue Beschreibung hierzu befindet sich im Kapitel 5. Mit diesem Programm ist es möglich sowohl ActionScript, als auch MXML visuell mit Hilfe der UML Notation darzustellen. Von Haus aus bietet UML keine Unterstützung für die Layoutsprache MXML 5. Um diese dennoch abbilden zu können, wurde eine Erweiterung auf Grundlage vorhandener Notations- und Assoziationselemente entwickelt. Bei der Erstellung einer Komponente mit dem Flexframework gibt es drei verschiedene layout-attribute: vertical, horizontal und absolute. Die absolute Positionierung erfolgt über angegeben Koordinaten. Bei der horizontalen und vertikalen Positionierung werden die verwendeten Komponenten automatisch an der horizontalen bzw. vertikalen Achse angeordnet. Dieses erfolgt auf Grundlage der Reihenfolge der Instanziierung der Komponenten. Dabei werden bei einem horizontalen Layout die Komponenten, die als Erstes instanziiert werden am weitesten links positioniert. Als internes Speicherformat verwendet CoMo die Spezifikation Extensible Markup Language (XML). Die explizite Darstellung der zwischen den MXML-Komponenten gegebenen Reihenfolge stellte eine besondere Herausforderung dar. Dabei wurde auf das natürliche Leseverhalten im europäischen Raum zurückgegriffen. Man liest von links nach rechts und von oben nach unten. Somit wird ebenfalls eine Hierarchie und Wichtigkeit der einzelnen Wörter dargestellt. Dieses Prinzip wurde letztendlich auf das Abbilden von MXML übertragen. Je weiter links eine MXML-Komponente im Klassendiagramm abgebildet wird, desto weiter oben steht diese in der Hierarchie. Das ganze könnte man sich auch wie folgt bildlich vorstellen: Nach der Abbildung im Klassendiagramm kann dieses um 90 im Uhrzeigersinn gedreht werden und stellt somit ebenfalls die Hierarchie dar. Die Abbildung 3.1 zeigt dieses Prinzip. Für die konkrete Abbildung in der UML wurden zwei neue Notationselemente, sowie eine neue Assoziation entwickelt. Zum einen gibt es das Element Rootkomponente, welches die Basis einer MXML-Komponente darstellt. Zum anderen gibt es die Subkomponente, die einer Rootkomponente hinzugefügt werden kann. Jeder Komponente muss eine Typ zugewiesen werden. Beispielsweise ob es sich um einen Button, einem DataGrid oder einem Tab- 5

34 3. Unified Modeling Language 26 Element Klasse Interface Enumeration binäre Assoziation reflexive Assoziation n-äre Assoziation qualifizierte Assoziation Aggregation Komposition Generalisierung Abhängigkeit Funktion Wichtigste Element eines Klassendiagramms. Es stellt eine Art Bauplan für Objekte der Realität dar. Auch Schnittstelle genannt, die es ermöglicht einer Klasse Vorgaben zu machen, welche Operationen mindestens implementiert werden müssen. Enumerations stellen Aufzählungen jeglicher Art dar. Ist ein Spezialfall der n-ären Assoziation und stellt Beziehungen zwischen genau zwei Klassen dar. Eine reflexive Beziehung ist eine Assoziation einer Klasse mit sich selbst. Sind Beziehungen von n Klassen. Die Darstellungsform ist eine Raute. Bei einer qualifizierten Beziehung wird ein Attribut als Qualifizierer eingesetzt. Dadurch ist es der einen Klasse möglich, Objekte der anderen Klasse eindeutig zu referenzieren. Eine Teil-Ganze-Beziehung wird durch eine Aggregation realisiert. Bei dieser Beziehung kann jedes Teil als Einzelnes bestehen. Die Komposition stellt eine stärkere Verbindung einer Teil-Ganze-Beziehung dar. Hierbei ist es nicht möglich, dass das Teil als Einzelnes besteht. Dient der Darstellung einer Vererbung (extends) zwischen Klassen bzw. einer Implementierung (implements) eines Interfaces. Abhängigkeiten werden nicht in Quellcode umgesetzt und dienen nur der Veranschaulichung innerhalb des Diagramms. Tabelle 3.1: Notationselemente und Assoziationen

35 3. Unified Modeling Language 27 Root Komponente Komponente A Komponente B Komponente C Komponente A Komponente B Komponente C Root Komponente (a) Abbildung in UML (b) nach einer 90 Drehung im UZS Abbildung 3.1: MXML Abbildung in UML Klassendiagrammen Navigator handelt. Dieser Typ wird über den sogenannten Stereotype 6 gemacht. Dazu wurde eine Flexbibliothek angelegt, die alle auswählbaren Komponenten enthält. Nachdem eine Komponente gewählt wurde, wird mittels Reflection 7 die vorhandenen Attribute in einer AutoComplete-Komponente 8 dargestellt. So wird verhindert, dass Attribute vergeben werden, die nicht unterstützt werden. Trotzdem hat der Benutzer bereits bei der Erstellung des Diagramms Kontrolle über für ihn wichtige Eigenschaften. Für die Assoziation wurde die vorhandene gerichtete Assoziation aus der UML Sprache übernommen. Dabei ist die Verknüpfungsrichtung wie folgt definiert: Eine Rootkomponente enthält eine Subkomponente. Das heißt, die Assoziation beginnt immer bei der übergeordneten Komponente. Durch diese Erweiterung ist es mit Hilfe von CoMo möglich, auch eine Abbildung von einer eigentlich visuellen Beschreibung zu erstellen. Der Einsatz von der Metapher der Leserichtung erleichtert den ersten Einsatz dieser Möglichkeit. 3.4 XMI XML Metadata Interchange XMI ist ein Format zum Austausch von Model Object Facility (MOF)- Metadaten wie Modelle und Metamodelle wie zum Beispiel UML. Es wurde 1999 von der OMG als Standard verabschiedet und definiert Regeln, wie 6 Verwendungskontext zum Beispiel einer Klasse 7 zur Laufzeit können die public-attribute einer Klasse ausgelesen werden 8 durch eintippen eines Buchstaben oder einer Buchstabenfolge werden die möglichen Suchergebnisse eingeschränkt

36 3. Unified Modeling Language 28 XMI (Objekte) XML (Daten) Unicode (Text) Abbildung 3.2: XMI basiert auf XML [10, in Anlehnung an S. 11] eine XML-Datei in eine andere XML-Datei transformiert werden kann. Diese Regeln werden in der sogenannten Extends Backus Naur Form (EBNF) 9 definiert. XMI wurde geschaffen, da es einen einheitlichen Austausch zwischen Entwurfswerkzeugen und Codegeneratoren geben musste. Ohne XMI war es möglich, die erstellte Modelle in einem proprietären Format zu speichern. Dieses führte zu Versionsproblemen zwischen den einzelnen Entwicklungswerkzeugen, woraufhin ein einheitliches Format definiert werden musste. Das neue Format sollte den Austausch und die Speicherung der Modelle fördern. Die meist graphisch vorliegenden Modelle werden in eine textuelle Form überführt und liegen in einer einheitlichen Form vor. XMI ist sowohl MOF-basierend, als auch XML-basierend. Die Abbildung 3.2 zeigt diesen Aufbau. Aus dieser Abbildung wird ersichtlich, dass ein XMI-Dokument auch immer ein XML-Dokument ist. Es enthält eine Repräsentation des Modells in Form von XML und kann zusätzlich die Technologien von XML nutzen. Eine XMI besteht aus verschiedenen Elementen, die immer eine uniqeid benötigen um über xpath[5] adressiert zu werden. Ein XMI-Dokument besteht immer aus zwei Teilen: der Document Type Definition (DTD) oder dem Schema und dem sogenannten Stream. Das Schema oder die DTD beschreibt das UML-Modell. Es definiert Tags welche dafür eingesetzt werden können und wo diese im Dokument auftreten können. Durch diese Definition ist es möglich valide Dokumente zu erstellen. Der Stream hingegen enthält eine genaue Ausprägung vom UML-Modell. XMI unterscheidet zwischen den Versionen 1.x und 2.x. In der Version 1.x wird XMI mit Hilfe von DTD s definiert. Im Gegensatz dazu, werden ab der Version 2.x die XMI mit Hilfe von Schemas definiert. Ab der Version 9 Erweiterung der Backus Naur Form zum Beispiel für die Zahlendefinition

37 3. Unified Modeling Language 29 XSD XML Schema Definition große Menge an Datentypen (einfache und komplexe) ist selber eine XML W3C-Standard unterstützt Namepsaces OO-Konzepte DTD Document Type Definition Extended Backus Nauer Form und kein XML wenige Datentypen können intern oder extern definiert werden unterstützt keine Namespaces W3C-Standard Tabelle 3.2: Vergleich XML-Schema und DTD 2.x ist es auch einfacher eine Vererbung zu modellieren, was in vorherigen Versionen nur mit viel Aufwand verbunden war. Die Tabelle 3.2 zeigt die Unterschiede und Gemeinsamkeiten von DTD und XSD. Zusammenfassend kann gesagt werden, dass mit der Einführung von XMI auch die Codegenerierung gefördert wurde. Durch einen erleichterten Austausch von Modellen ist es für Codegeneratoren einfacher diese zu transformieren. Auch wenn XMI für die Transformation von XML in andere XML- Dokumente gedacht ist, ist es durch das Tag <xsl:text> möglich normalen Text und somit auch Quellcode zu generieren.

38 Kapitel 4 State of the Art UML Werkzeuge Das folgende Kapitel zeigt einen Überblick über die derzeit bekanntesten UML-Editoren. Da der Markt sehr viele dieser Werkzeuge bereithält, wurde die Übersicht eingeschränkt und nur die Editoren ArgoUML, Enterprise- Architect und VisualParadigm untersucht. Eine Liste von knapp 100 UML- Werkzeugen hat die OOSE zusammengestellt, in der die Eigenschaften dieser verglichen wird Einteilung von UML Werkzeugen UML-Werkzeuge unterstützen den Entwickler bei der Erstellung von UML- Diagrammen. Es sind Modellierungswerkzeuge, mit denen eine grafische Darstellung einer Softwarestruktur modelliert werden kann. Einige UML-Tools unterstützen das Reverse Engineering und/oder Round-Trip Engineering. Beim Reverse Engineering wird vorhandener Quellcode in ein Modell überführt. Dabei ist es möglich, dass einige Informationen verloren gehen. Durch den hohen Informationsgehalt von Quellcode und den etwas eingeschränkten UML-Notationen ist eine 1:1 Abbildung nicht immer möglich. Sollte ein UML-Tool die Möglichkeit des Round-Trip Engineerings anbieten, so heißt das, dass das Modell und der daraus generierte Quellcode synchron gehalten werden. Das heißt, dass eine Änderung am Modell eine Neugenerierung des Codes zur Folge hat. Genau so auch bei einer Änderung am Quellcode. Hier wird automatisch das Modell an den neuen Code angepasst werden. Als Einstieg in die Thematik zeigt die Tabelle 4.1 einen Überblick der wichtigsten Eigenschaften der gewählten Werkzeuge

39 4. State of the Art UML Werkzeuge 31 Werkzeug UML Version Codegenerierung Open Source Reverse Engineering ArgoUML 1.4 C#, PHP4+5, C++, Java Enterprise- Architect Visual- Paradigm 2.1 C++, C#, Java, Delphi, AS, PHP, Python Java, C#, PHP, AS, C++, Python, Ruby... ja nein nein ja ja ja Tabelle 4.1: UML-Werkzeuge im Überblick Vorwegzunehmen ist, dass alle drei UML-Editoren zur Kategorie der Computer Aided Software Engineering (CASE)-Tools gehören. Case Aided Software Engineering-Tools helfen dem Entwickler bei computergestützter Softwareentwicklung. Wichtige Schritte wie die Softwareplanung, der Softwareentwurf und die Dokumentation werden ebenfalls unterstützt. Dabei steht das Ziel im Vordergrund, Software weitestgehend automatisch zu erstellen. 4.2 ArgoUML ArgoUML 2 wurde von der Firma Gentleware erstellt und ist komplett in Java geschrieben. Dadurch ist es nahezu plattformunabhängig und kann auf allen javafähigen Betriebssystemen genutzt werden. Aktuell unterstützt ArgoUML die Version 1.4 der UML, was dazu führt, dass einige Diagrammtypen fehlen. Im Gegensatz zu den zwei folgenden Tools 2

40 4. State of the Art UML Werkzeuge 32 ist ArgoUML Open Source 3. Neben dieser Version ist auch eine kommerzielle Lösung einsetzbar, welche unter der BSD-Lizenz steht. Die BSD-Lizenz Berkeley Software Distribution bezeichnet eine Lizenz für Software, die frei verwendet werden darf. Der ursprüngliche Copyright darf bei Veränderungen und Weitergabe nicht entfernt werden. Ein Vorteil gegenüber den anderen Tools ist die Möglichkeit das Programm direkt aus dem Internet ohne Installation zu starten. Dazu wird der Java Web Start verwendet. Im Gegensatz zu Java-Applets wird kein Browser benötigt und der Anwender hat die Möglichkeit, immer mit der aktuellsten Version zu arbeiten. Sowohl die Codegenerierung, als auch das Reverse Engineering werden von ArgoUML unterstützt. Die gängigsten Sprachen die bei der Generierung unterstützt werden sind C#, PHP in der Version 4 und 5, C++ und Java. Für den Austausch der erstellten Diagramme bietet es die Möglichkeit offene Standards wie UML, XMI oder auch Scaleable Vector Graphics (SVG) zu nutzen. UML wurde bereits zuvor in diesem Kapitel erläutert. XMI ist ein auf XML basierendes Austauschformat, welches im Kapitel 6 näher erklärt wird. SVG ist ebenfalls ein Standard welcher auf XML basiert. Es beschreibt eine Vektorgrafik mit Hilfe von verschiedenen Elementen in Form eines XML- Baumes. 4.3 EnterpriseArchitect Die Firma SparxSystems Ltd entwickelte das CASE-Tool EnterpriseArchitect 4. Es bietet nicht nur einen objektorientierten Ansatz, sondern unterstützt als einziges der gewählten Werkzeuge die MDA. Eine Erklärung dieses Ansatzes befindet sich im Kapitel 2. EnterpriseArchitect deckt die Bedürfnisse der UML Version 2.1 ab. EnterpriseArchitect unterstützt sowohl die Codegenerierung, als auch das Round-Trip Engineering. Quellcode kann für viele Programmiersprachen wie C++, C#, Java, Delphi, ActionScript, PHP und Python out-of-the-box 5 generiert werden. Einige CASE-Tools unterstützen auch das so genannte simultane Round-Trip Engineering. Simultan bedeutet hierbei, dass direkt nach Änderungen eine Synchronisation angestoßen wird. EnterpriseArchitect unterstützt ebenfalls den Export von XMI und bietet die Möglichkeit eigene Technologien über eine erweiterbare Modellierungsumgebung einzubinden. 3 öffentlich zugänglicher Quelltext, für den keine Zahlungsverpflichtungen besteht von der Stange, vorgefertigter Code

41 4. State of the Art UML Werkzeuge VisualParadigm VisualParadigm 6 ist das einzige der vorgestellten Werkzeuge, welches die UML Version 2.2 unterstützt. Da es kein Open Source ist kann sich mit Hilfe einer 30-tägigen Testversion ein Bild über die verschiedenen Funktionen gemacht werden. Es ist sowohl in einer Stand-Alone-Lösung 7, als auch als PlugIn 8 für die Entwicklungsumgebung Eclipse 9 beim Hersteller zu beziehen. Codegenerierung wird wie bei den zuvor erwähnten Tools ebenfalls unterstützt. Dazu gehören Sprachen wie Java, C#, PHP, ActionScript, C++, Python und einige andere. Der zu generierende Code kann zuvor selber angepasst werden. Auch schon das zuvor beschriebene Round-Trip Engineering wird seitens VisualParadigm unterstützt. Ein Vorteil gegenüber Mitbewerbern ist die Möglichkeit Datenbankmodelle zu erstellen. Abschließend zeigt Tabelle 4.2 eine Einschätzung der verschiedenen Werkzeuge im Hinblick auf die Bedienbarkeit, den Aufbau der Oberfläche, den vorhandenen Umfang der Funktionen und die Möglichkeiten der Modellierung. ArgoUML intuitiv sehr übersichtlich Werkzeug Bedienung Oberfläche Funktionen Modellierung Enterprise- Architect sehr viele Möglichkeiten Visual- Paradigm intui- nicht tiv Bedarf einer Einarbeitungszeit sehr überladen sehr überladen ausreichend sehr viele Möglichkeiten schnelle Ergebnisse möglich nicht intuitiv sehr verteilt, dadurch keine schnellen Ergebnisse Tabelle 4.2: Einschätzung der UML-Werkzeuge ohne zusätzliche Software einsetzbar 8 Erweiterungsmodul für Software 9

42 Kapitel 5 CoMo CodeModeler CoMo ist ein Entwurfswerkzeug für UML-Klassendiagramme. Es ermöglicht neben der Modellierung auch das Generieren von Quellcode für ActionScript und MXML. Für CoMo wurde eine Erweiterung von UML im Bezug auf MXML vorgenommen. Diese Erweiterung wurde bereits im Kapitel 3 beschrieben. Das nachfolgende Kapitel erläutert die genauen Funktionen von CoMo, die Architektur, den Ablauf einer Codegenerierung sowie die Bedienung. 5.1 CoMo im Überblick Nachfolgend werden die drei Hauptfunktionen Diagrammmodellierung, Projektstrukturmodellierung und Codetransformation von CoMo im Überblick erklärt. Sie bilden die drei Eckpfeiler des Werkzeugs Diagrammmodellierung Mit Hilfe der in Kapitel 3 beschriebenen Modellierungssprache UML werden die Diagramme für die spätere Transformation erstellt. Dabei ist die Anwendung in der UML soweit eingeschränkt, dass nur Notationselemente und Assoziationen erstellt werden können, die später auch in ActionScript 3 und MXML abgebildet werden können. Bei der Modellierung besteht die Möglichkeit die Arbeitsfläche zu zoomen, damit auch ein etwas größeres Diagramm Platz findet. Die modellierten Diagramme können gespeichert und anschließend wieder geöffnet werden. Des Weiteren ist ein Export als *png möglich, um die Weitergabe oder auch einen Ausdruck zu gewährleisten Projektstrukturmodellierung Bei der Entwicklung einer Software ist unter anderem die Strukturierung des Projektes sehr wichtig. Diese Strukturierung ermöglicht ein schnelles Auffinden von gesuchten Klassen oder Funktionen, aber auch den schnelleren 34

43 5. CoMo CodeModeler 35 Überblick für andere Programmierer. In CoMo gibt es eine eigene Ansicht für die Projektstruktur. Mit Hilfe eines Baumes kann die gesamte Struktur abgebildet werden. Durch einfaches hinzufügen und entfernen von packages 1 kann dies in wenigen Minuten geschehen. Mittels Drag&Drop können die erstellten packages verschoben und geschachtelt werden. Durch Doppelklick auf den Packagenamen kann dieser einfach umbenannt werden. Die modellierte Packagestruktur wird bei der späteren Codetransformation ebenso berücksichtigt, wie das zuvor erstellte Modell. Hinzu kommt, das erstellte Elemente sowohl im Diagramm als auch im Baum angezeigt werden. Durch Drag&Drop können diese den einzelnen packages zugeordnet werden Codetransformation Die Codetransformation erfolgt über zuvor erstellte XML-Daten. Das heißt, ein gezeichnetes Modell wird vor der eigentlichen Transformation in eine XML-Struktur transformiert, welches dann für jedes einzelne Element über eine vorgegeben String erstellt und als Datei gespeichert wird. Zuvor werden die einzelnen packages als Ordner an einem selbst bestimmbaren Ort gespeichert. Die Transformation über einen vorgegeben String soll im neuen Konzept überarbeitet werden und zum Beispiel über Templates realisiert werden. Dadurch ergibt sich der Vorteil, dass das Tool auch für andere Programmiersprachen einsetzbar wird. Diese weiteren Sprachen können dann vom Benutzer selbst erstellt werden. Weiteres dazu wird im Kapitel 6 erläutert. 5.2 Flexframework Sowohl CoMo als auch die neue Generatorkomponente werden mit Flex und ActionScript umgesetzt. Daher gibt es an dieser Stelle einen Überblick über das Flexframework. In der Version 1 ist Flex bereits 2004 unter Macromedia auf den Markt gekommen. Mit dieser war es das erste Mal möglich, aus Quellcode eine *.swf-datei zu generieren. Ein Jahr später, im Jahre 2005, wurde es von der Version 1.5 abgelöst. In beiden Versionen war Flex noch kein Open Source, wodurch hohe Lizenzgebühren anfielen. Die Kompilierung erfolgte über einen Server und nicht über eine IDE oder einem Kommandozeilen-Compiler. Mit der Version 2 änderte sich dieses grundlegend, da sie unter Adobe veröffentlicht wurde. In der dritten Version vom , welche bereits als Open Source veröffentlicht wurde, konnte die Entwicklergemeinde stärker mit einbezogen werden. Erstmals gibt es vom Flex Builder zwei kostenpflichtige Versionen: Standard und Professional. Die Professional-Version enthält zu- 1 Klassen werden in verschiedenen Ordnern erstellt und können so über einen qualifizierten Namespace angesprochen werden

44 5. CoMo CodeModeler 36 sätzliche Komponenten wie das Charting für die Diagrammvisualisierung und Testwerkzeuge wie den Profiler. Seit dem liegt Flex nun in der vierten Version vor. Bei dieser Version sind die zuvor genannten Diagrammvisualisierungen nicht mehr Bestandteil der kostenpflichtigen Version, sondern bereits im kostenlos erhältlichen SDK vorhanden. Flex wurde für Entwickler konzipiert, welche ihren Fokus auf die Entwicklung von Anwendungen gelegt haben, aber dennoch auf die verschiedenen Animationsmöglichkeiten von Flash und ActionScript nicht verzichten wollen. Flexanwendungen selbst sind, im Gegensatz zu Webanwendungen, nicht seitenbasierend. Flex nutzt nämlich die Metapher der Screens und States. States sind Zustände, die unter anderem das Aussehen und das Verhalten der Anwendung beschreiben. In Abhängigkeit von einem Statewechsel können Farben angepasst, Komponenten ersetzt oder hinzugefügt werden. Eine Änderung des States kann durch eine Benutzerinteraktion erfolgen, aber auch auf Grundlage von Datenänderungen. Anwendungen selbst laufen als Webanwendung im FlashPlayer und als Desktopanwendungen, mit Hilfe von Adobe Integrated Runtime (AIR), auf dem Desktop. Da Flex Open Source ist, können Anwendungen mit jedem beliebigen Texteditor erstellt werden. Voraussetzung dafür ist nur das kostenlose Flex SDK. ActionScript 3 ist eine objektorientierte Programmiersprache, die zusammen mit MXML 2 das Programmierungsmodell von Flex bilden. Es stellt die Logik einer Anwendung bereit. ActionScript 3 ist eine auf den Grundlagen der objektorientierten Programmierung aufgesetzten Sprache. Dieses geschah unter Berücksichtigung von objektorientierten Paradigmen wie Vererbung, Kapselung und Polymorphie. ActionScript erweitert zudem MXML um Funktionen für die Objektmanipulation, die in MXML nicht zur Verfügung stehen. 5.3 Architektur Das in Abbildung 5.1 gezeigte Klassendiagramm stellt die wichtigsten Klassen, und somit nur einen Ausschnitt der Architektur, und ihre Beziehungen untereinander dar. Die nachfolgende Erläuterung benutzt das Wort Klasse auch für eine MXML Datei, da diese während des Buildprozesses ebenfalls in eine ActionScript Klasse kompiliert wird. Einstiegspunkt der Anwendung ist die Klasse Diplomarbeit.mxml. Sie ist dafür verantwortlich Instanzen der drei Hauptbereiche OverviewView.mxml, DiagramView.mxml und PropertyView.mxml zu erstellen. Die OverviewView stellt alle benötigten Notationselemente, Assoziationen sowie der Projektstruktur zur Verfügung. Die eigentliche Arbeit geschieht in der Diagram- View. Hier werden die Notationselemente angelegt, per Drag&Drop verscho- 2 die Beschreibungssprache von Flex welche auf XML basiert

45 5. CoMo CodeModeler 37 Abbildung 5.1: Klassendiagramm von CoMo ben oder mittels einer Assoziation in Beziehung gesetzt. In der PropertyView hat der Benutzer die Möglichkeit Eigenschaften von Klassen, Attributen oder Operationen zu ändern. Durch eine übersichtliche Darstellung aller Eigenschaften ist es sehr einfach diese zu erweitern oder bearbeiten. Da die Notationselemente von der Grundfunktion gleich aufgebaut sind, wurde die Superklasse NotationElementContainer.mxml erstellt. Alle vorhandenen Elemente erben die Grundfunktion und fügen eigene Funktionen hinzu. So gibt es die Klassen ClassElement.mxml, EnumerationElement.mxml, InterfaceElement.mxml, MemoElement.mxml, sowie RootTagMXML.mxl und SubTagMXML.mxml. Für die Darstellung der Assoziationen ist die Klasse ElementLink.mxml verantwortlich. Hier wird in Abhängigkeit der Assoziation die richtige grafische Darstellung erstellt. Für die einzelnen ElementLink Bestandteile wurden Enumerations erstellt, die mögliche Werte als statische Attribute enthalten. LineStyle.as enthält nur zwei mögliche Ausprägungen: eine durchgezogene und eine gestrichelte Linie. In der Klasse LinkEnd.as sind die zugehörigen Enden der Assoziationen enthalten. Alle vorhandenen Beziehungstypen sind in der Klasse LinkType.as als statische Attribute verfügbar. Die Funktionalität für das Generieren des Projektes ist in der Klasse GenerateProject.as implementiert. Dazu bedient sie sich an Funktionen aus den Templateklassen. Genauso wie die GenerateProject.as bedient sich sowohl die CreateDiagram.as und der XMLVOMapper.as an diesen Funktionen. Dabei bietet jede der Templateklasse drei Funktionen an: getxml(), getvo() und getstring(). Um aus dem gezeichneten Diagramm eine XML für das Speichern zu erstellen, ruft man die getxml() Methode auf. Erstellt man aus

46 5. CoMo CodeModeler 38 einer gespeicherten Datei wieder ein Diagramm, wird die Methode getvo() benutzt. Für das Generieren eines Diagramms wird ein String benötigt, welcher mit Hilfe der Methode getstring() erstellt wird. Das Listing 5.1 zeigt einen Ausschnitt aus den Templateklassen. Listing 5.1: ExampleTemplate.as 1 public class ExampleTemplate 2 { 3 public function ExampleTemplate() 4 { 5 } 6 7 public static function getxml( value : OperationVO ) : XML 8 { 9 return xml; 10 } public static function getvo( value : XML ) : OperationVO 13 { 14 return examplevo; 15 } public static function getstring( value : XMLList ) : String 18 { 19 return string; 20 } private static function getparameter( value : XMLList ) : String 23 { 24 return string; 25 } } Im nächsten Abschnitt wird auf die wichtigsten Implementierungen von CoMo CodeModeler eingegangen. Aufgrund des Projektumfangs, geschieht dieses nur Auszugsweise. 5.4 Implementierung Bei der Implementierung von CoMo wurde darauf geachtet, dass es weitestgehend wiederverwendbar umgesetzt ist und die Prinzipien der OOP 3 berücksichtigt werden. Abbildung 5.2 zeigt die Projektstruktur von CoMo. Die Aufteilung in einzelne packages dient der Strukturierung. Die einzelnen Komponenten und Klassen sind mit Hilfe von Flex 3 und ActionScript 3 implementiert. 3 Object Oriented Programming

47 5. CoMo CodeModeler 39 Abbildung 5.2: Projektstruktur von CoMo Der Ordner assets beinhaltet alle Grafiken, eventuelle Konfigurationsdateien oder CSS-Dateien. Die Aufteilung innerhalb des Ordners ist projektspezifisch. Die Quelldateien liegen im package at.fhooe.umltool. Dieses package wird unterteilt in command, controller, events, externalhelpers, map-

48 5. CoMo CodeModeler 40 per, model, util, view und vo. Das package externalhelpers enthält Dateien von externen Quellen die nicht vom Autor erstellt sind. Dazu gehört die AutoComplete-Komponente und den ScaledCanvas, welcher für die Diagrammfläche eingesetzt wird. Im mapper package liegen die XML-Mapper für die einzelnen Notationselemente. Über diese Mapper kann man sowohl die XML-Struktur zum Speichern erstellen, und umgekehrt aus dieser wieder ein Value Object (VO) erstellen. Ein VO besteht nur aus Attributen und ähneln einem einfachen Datentyp. Es dient dem Datenaustausch innerhalb eines Programms. Der ModelLocator im Ordner model enthält alle Daten und dient lediglich zur Datenhaltung. Alle Notationselemente und Assoziationen befinden sich im package util. Es beinhaltet alle Dateien die zur Unterstützung des Projektes benötigt werden. Um nicht alle Views in einer Datei zu haben, werden diese nach ihren Funktionen aufgeteilt. Jedes der drei vorhanden Teile erhält eine eigene View. Wie der Name des packages vo schon sagt, beinhaltet dieses alle vorhandenen ValueObjects. Für die Implementierung der dynamischen Berechnung der verlinkten Elemente wurde das Observer Pattern[15] eingesetzt. Das Pattern ist eines von vielen Design Pattern die in der Programmierung bereits gelöste Probleme als eine Art Vorlage anbieten. Das Pattern besteht aus einem Observer (Subscriber) und dem Observable (Publisher). Der Observer hat die Möglichkeit sich bei einem Observable zu registrieren oder auch wieder abzumelden. Sobald sich ein bestimmtes Attribut des Observable ändert, informiert dieser alle bei ihm registrierten Observer. Nach der Benachrichtigung kann dieser dann darauf reagieren. Ein Beispiel hierfür wäre eine zentrale Wetterstation als Sender, bei der sich viele kleinere Stationen als Empfänger registriert haben. Ändert sich nun der Temperaturwert der großen Station, werden alle bei ihm registrierten Stationen benachrichtigt und können ebenfalls ihre Temperatur updaten. Durch den Einsatz dieses Patterns ist es sehr einfach möglich, das automatische Neuzeichnen einer Beziehung zwischen zwei Klassen umzusetzen. Im Konkreten heißt das, das eine Klasse der Observable ist und die Beziehung ein Observer. Ändert sich nun die Position der Klasse, wird die Beziehung (Observer) benachrichtigt und kann damit die Verbindung neu zeichnen. 5.5 Bedienung Bei der Umsetzung von CoMo wurde versucht eine möglichst einfache Benutzerführung zu gewährleisten. Dennoch sollen die nachfolgenden Erläuterungen beim Einstieg in die Arbeit mit CoMo helfen. Die Grundlagen von UML, ActionScript 3 und MXML sollten bekannt sein, da diese die Hauptthematik des Programms sind.

49 5. CoMo CodeModeler 41 Abbildung 5.3: Benutzeroberfläche Benutzeroberfläche Die Benutzeroberfläche in Abbildung 5.3 ist in drei Bereiche geteilt: die Notationsansicht, die Diagrammansicht und die Propertiesansicht. In der Notationsansicht sind die einzelnen UML-Elemente und UML- Assoziationen aufgelistet. Des Weiteren können packages für das Projekt hinzugefügt, gelöscht und umbenannt werden. Durch Drag&Drop können diese verschoben und verschachtelt werden. Sobald Notationselemente dem Diagramm hinzugefügt werden, sind diese ebenfalls dort sichtbar und können per Drag&Drop in die packages verschoben werden. Die Diagrammansicht ist die eigentliche Visualisierungsfläche. Auf dieser werden die Elemente und Assoziationen dargestellt und bearbeitet. Elemente können auf der gesamten Fläche verschoben werden und mit Hilfe der Zoommöglichkeit auch verkleinert dargestellt werden. Zum Bearbeiten von Attributen, Operationen und allgemeinen Klasseneigenschaften dient die Propertieansicht. Je nach ausgewähltem Element ändert sich die Ansicht oder bleibt bei Auswahl bestimmter Elemente leer Menü CoMo bietet zwei Arten Aktionen auszuführen: das normale, textuelle Menü und ein grafisches Menü. Die Menüleiste aus Abbildung 5.4 enthält folgende Menüs: Datei hier befinden sich die Menüpunkte wie Neu, Öffnen, Speichern, Speichern unter, aber auch Quellcode importieren, als PNG exportieren und Beenden.

50 5. CoMo CodeModeler 42 Abbildung 5.4: Menüleiste Projekt hier findet man die Generierungseinstellungen, die Projekteinstellungen, aber auch selektiertes Element generieren und Projekt generieren. Ansicht bietet die Möglichkeit das Raster ein- bzw. auszublenden. Hilfe gibt Auskunft über CoMo, enthält eine Hilfe zur Bedienung und einen kurzen Abriss über UML, welches derzeit aber noch nicht implementiert wurde. Das grafische Menü enthält die wichtigsten Aktionen nochmals kompakt an einer Stelle. Dazu gehören: Zoomfaktor um auch größere Diagramme abbilden zu können, gibt es Zoomstufen von 50%, 75% und 100%. Raster ein/ausblenden blendet das gepunktete Raster entweder ein oder aus. Projekt generieren generiert das komplette Projekt mit allen Elementen und packages. Klasse importieren importiert den Quellcode einer Klasse und bildet ihn grafisch ab (noch nicht implementiert). PNG exportieren bietet die Möglichkeit ein Bild vom Diagramm zu speichern. Hilfe öffnet die Hilfe von CoMo (noch nicht implementiert) Diagramm erstellen Ein Diagramm lässt sich sehr einfach erstellen. Über den Menüpunkt Neu oder Strg + N wird eine neue, leere Arbeitsfläche geschaffen. Zuvor kann der Benutzer einige Angaben wie Autor, Projektname und eine Beschreibung eingeben. Anschließend kann per Klick auf das jeweilige Element in dem linken Panel ein grafisches Abbild auf der Arbeitsfläche erstellt werden. Der Grundaufbau ist bei allen Elementen gleich. Dieser ist in der Abbildung 5.5 am Beispiel einer Klasse beschrieben. Für jedes Element wurde ein eigenes Icon hinzugefügt um diese schnell auseinander halten zu können. Die Abbildung 5.6 zeigt alle Icons für die Elemente, sowie die Assoziationsicons. Nachdem alle Elemente angelegt wurden, können diese verknüpft bzw. Assoziationen aufgebaut werden. Dieses erfolgt über die Assoziationsansicht. Dazu wählt man einen Assoziationstyp aus, woraufhin sich der Cursor in den jeweiligen Typ ändert. Dann klickt man bei dem Ausgangselement auf die Fläche für die Assoziation und dann bei dem Endelement auf die gleiche Fläche. Nun erscheint eine Assoziation zwischen den beiden Elementen. Einige

51 5. CoMo CodeModeler 43 Abbildung 5.5: Grundaufbau eines Elementes Abbildung 5.6: Icons

52 5. CoMo CodeModeler 44 Abbildung 5.7: Propertiesansicht von diesen Assoziationen können mit weiteren Parametern versehen werden. Dazu klickt man das Bearbeitungssymbol einer Assoziation an und in der Propertieansicht öffnet sich eine abhängige Ansicht. Die Abbildung 5.7 zeigt ein Beispiel Diagramm speichern und öffnen Ein Diagramm kann sowohl gespeichert, als auch später wieder geöffnet werden. Dabei wird als internes Format XML benutzt. Es wird unterschieden zwischen Speichern und Speichern unter Projekt generieren Bei der Projektgenerierung muss ein Zielpfad angegeben werden, wohin die generierte Datei gespeichert wird. Diesen kann man über ein Menü bequem auswählen. Bei der Generierung werden sowohl alle Elemente, als auch die Projektstruktur generiert. Möchte man nur ein einzelnes Element generieren,