Lieferung 7.1 Plattformspezifische Generatortemplates für Code-Gerüst, Test, Konfiguration der Qualitätswerkzeuge

Transkript

1 Lieferung 7.1 Plattformspezifische Generatortemplates für Code-Gerüst, Test, Konfiguration der Qualitätswerkzeuge für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket AP 7 Transformationen Arbeitspaketleitung arconsis Förderkennzeichen 01IS11012A-C Projektleitung andrena objects AG Jochen Winzen Partner andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Autoren Martin Küster, Johannes Tysiak, Nikolas Herbst Lieferdatum M21 Letztes Änderungsdatum Version 1.0 Qualitätswerkzeuge 1

2 1 Einleitung Ein zentrales Element der ModAgile Werkzeugkette ist der Generator, der auf Basis der zuvor erstellten plattformunabhängigen Modelle Quellcode für die Anwendung sowie Testrümpfe und sonstige Artefakte (wie beispielsweise Konfigurationen) erstellt. Das vorliegende Dokument erläutert den Aufbau und die Struktur der gewählten Implementierung und diskutiert während der Erstellung getroffene Entscheidungen. Anschließend wird aus Sicht des Endanwenders die Nutzung des Generators innerhalb der Eclipse Entwicklungsumgebung anhand eines konkreten Beispiels veranschaulicht. 2 Umsetzung Im Folgenden wird die Werkzeugkette zur Generierung von Quellcode aus dem Anwendungs-, Domänenund Testmodellen beschrieben. Die Kette wird pro Zielplattform so konfiguriert, dass der entsprechende Zielcode entsteht. Zurzeit ist dies für die Plattformen android (in Java) und ios (in Objective-C) umgesetzt. Die gemeinsamen Bestandteile wurden so herausfaktorisiert, dass der gemeinsame Kern der technischen Infrastruktur für die jeweilige Plattform nur an wenigen Stellen angepasst werden muss. Dies bezieht sich insbesondere auf das Aufsetzen des Workflows, der die Generierung startet sowie selbstverständlich die unterschiedlichen Templates während der Code-Generierung. Abbildung 1 veranschaulicht die einzelnen Schritte der Generierung: Workflow- Instanziierung (ios / android) Modelltraversierung Quellcode- Generierung Kompilierung und Ausführung der Tests Abbildung 1 Übersicht der Schritte zur Code-Generierung Zunächst wird ein Workflow aufgesetzt, der die verschiedenen Stufen der Generierung aneinanderfügt und ausführt. Dazu wird die Eclipse-interne Modeling Workflow Engine (MWE2) verwendet. Während zu Beginn des Projekts diese Workflows als Textartefakte vorlagen, die von Hand angepasst werden mussten, um die richtigen Pfade und Generierungskomponenten zu enthalten, wird der Workflow in der aktuellen Version programmatisch angestoßen. Die Hauptkomponente, die den Startpunkt für die Traversierung des Anwendungsmodells und die nachfolgende Generierung von Quellcode darstellt, wird in diesem Workflow lediglich mit der jeweiligen Zielplattform parametrisiert. Dies ermöglicht eine einfache Erweiterung für weitere Plattformen, ohne den Kern anpassen zu müssen. Die Schritte Modelltraversierung und Codegenerierung sind danach plattformspezifisch. Für die jeweilige Ziel-IDE (Integrated Development Environment) werden die jeweiligen Anwendungsprojekte automatisch erzeugt und können danach editiert werden. Im Java- / android-fall wird aus dem Anwendungs- und Domänenmodell ein Eclipse-Projekt erstellt, das nach sehr geringen Anpassungen als android- Anwendung bereits lauffähig ist und direkt getestet werden kann. Im ios-fall wird ein Xcode-Projekt erstellt, das eine lauffähige ios-anwendung enthält. Qualitätswerkzeuge 2

3 Im letzten Schritt wird die Anwendung automatisch von der Entwicklungsumgebung übersetzt und getestet. Dies wird von der jeweiligen Entwicklungsumgebung übernommen. Die Java-Klassen im android-fall werden also genau wie der Objective-C-Code im ios-fall automatisch übersetzt und gebündelt. de.modagile.generator.ios.modeltraverser de.modagile.generator.ios org.eclipse.xtext.generator.igenerator de.modagile.generator.common de.modagile.generator.android.modeltraverser de.modagile.generator.android Injected at runtime via Google Guice Abbildung 2 Plugins, die bei der Generierung involviert sind Technisch musste die Herausforderung gelöst werden, dass das Plugin, das die allgemeinen, plattformunabhängigen Dienste erbringt (de.modagile.generator.common) nicht von den jeweiligen plattformspezifischen Generierungsplugins wissen sollte. Daher wurde die Schnittstelle, die den Code generiert (org.eclipse.xtext.generator.igenerator) von verschiedenen Klassen implementiert wird, aber die Entscheidung, welche Implementierung genutzt wird, von sogenannter dynamischer Bindung Gebrauch macht. Über das Google-Guice-Modul wird der Generator erst zur Laufzeit der Plugins injiziert. Damit haben wir erreicht, dass die Plugins unabhängig und flexibel erweiterbar sind. 2.1 Modelltraversierung und Quellcode-Generierung Die gesamte Generierungsworkflow setzt auf der Modelltraversierung auf. Modelltraversierung bedeutet, dass das vom App-Entwickler erstellte konkrete App-Modell vollständig durchlaufen wird. Bei diesem Durchgang gelangt der Modelltraverser zu allen im Modell vorhandenen Elementen. Er stößt jeweils die Generierung der Artefakte an, welche für die Plattform spezifische Realisierung benötigt werden. Das für die Generierung benötigte plattformspezifische Wissen ist in Templates, also wiederverwendbaren Codeschablonen, gekapselt. Diese Templates werden bei der Generierung durch Informationen aus dem Modell konfiguriert und verknüpft. Wie dieser Schritt unter Verwendung von Xtend2 im Detail vonstattengeht, ist in Abschnitt 2.2 beschrieben. Ein zentraler Punkt bei der Generierung aus dem App-Modell heraus ist die Organisation der generierten Artefakte. Es ist nötig, ein strukturiertes Projekt in der entsprechenden Entwicklungsumgebung für die Zielplattform neu anzulegen oder bei Neugenerierung zielgerichtet zu modifizieren und manuelle Erweiterungen zu schützen. Hierzu implementiert die JavaFileSystemAccess-Klasse des entsprechenden Generators die IFileSystemAcces-Schnittstelle mit 2 Erweiterungen, welche in Abbildung 3 dargestellt sind. Die Interfaces werden um die Funktionen generatefile(), addoutputconfiguration() und setproject() erweitert. Mit dieser Funktionalität werden die generierten Artefakte zuerst ins Dateisystem geschrieben. Hierbei wird ebenfalls Qualitätswerkzeuge 3

4 eine Ordnerstruktur angelegt, welche zum einen das App-Modell widerspiegelt, sich aber auch nach plattformspezifischen Anforderungen richtet. Anschließend wird eine Projektdatei für die entsprechende Entwicklungsumgebung entweder erzeugt, sofern noch keine vorhanden war, oder eine vorhandene modifiziert. Als Ergebnis sind in der Projektdatei alle generierten Artefakte registriert, so dass sie ohne weiteren Konfigurationsaufwand bei der Kompilierung des Projekts für die entsprechende Zielplattform mit berücksichtigt werden. Die saubere Trennung der generierten Artefakte in Projektstruktur und auf Dateisystemebene von weiteren manuellen Erweiterungen, ist ein weiterer Punkt, der bei der automatisierten Projekt-Erstellung bzw. Anpassung zu beachten ist. Auf diese Weise wird es ermöglicht, erneute Code-Generierungen und damit auch spätere Modellanpassungen in bereits existierende Projekte mit einfließen zu lassen. Damit eine Entkopplung von generierten und manuell erstellten Codeartefakten gewährleistet ist ohne die Freiheit für Erweiterungen einzuschränken, werden dem App-Entwickler gekennzeichnete Erweiterungspunkte, sog. Hooks, angeboten. «interface» IFileSystemAccess + String DEFAULT_OUTPUT = DEFAULT_OUTPUT +generatefile(string filename, CharSequence contents): void +generatefile(string filename, String outputconfiguration, CharSequence contents): void +deletefile(string filename): void «interface» IFileSystemAccessExtension +deletefile(string filename, String outputconfiguration): void «interface» IFileSystemAccessExtension2 +geturi(string filename, String outputconfiguration): URI +geturi(string filename): URI AbstractFileSystemAccess - outputs: Map<String, OutputConfiguration> - postprocessor: IFilePostProcessor + generatefile(string filename, CharSequence contents): void + deletefile(string filename): void + deletefile(string filename, String outputconfigurationname): void + geturi(string filename): URI + getoutputconfigurations() : Map<String, OutputConfiguration> + setoutputconfigurations(map<string, OutputConfiguration> outputs): void + setoutputpath(string path): void + setoutputpath(string outputname, String path): void JavaFileSystemAccess - encodingprovider: IEncodingProvider - registry: IResourceServiceProvider.Registry + generatefile(string filename, String outputconfigname, CharSequence contents): void + geturi(string filename, String outputconfiguration): URI + deletefile(string filename, String outputconfigurationname): void de.modagile.generator.common - project: IProject - monitor: IProgressMonitor JavaFileSystemAccess2 + generatefile(string filename, String outputconfigname, CharSequence contents): void + addoutputconfiguration(outputconfiguration newoutputconf): void + setproject(iproject project): void Abbildung 3 Schnittstellen zum Speichern von generierten Dateien Qualitätswerkzeuge 4

5 2.2 Struktur der Templates und M2T-Transformationen mit Xtend2 Abbildung 4 und Abbildung 5 geben einen Überblick über die plattformspezifische Struktur der Templates in den jeweiligen Codegeneratoren. So werden in beiden Fällen zum Beispiel Templates für die Synchronisierungsfunktionalität und für Konstanten angeboten. In der Struktur der Templates beider Generatoren ist auch das MVC (modell/view/control) Architekturpattern erkennbar. Im Gegensatz dazu sind die Templates unter modagile.appdelegate zum Beispiel plattformspezifisch. Diese werden lediglich in ios-anwendungen als Programmeinstiegspunkt benötigt. Abbildung 4: Templatestruktur ios Generator Abbildung 5: Templatestruktur Android Generator Die Templates sind in der Xtend Sprache realisiert. Xtend2 ist eine statisch getypte Programmiersprache, welche sich zu Java Quellcode übersetzen lässt und auf Xtext aufbaut. Xtext selbst bietet Unterstützung beim Erstellen von domänenspezifischen Sprachen. Mit Xtend2 als Werkzeug ist es also möglich, auf einer hohen Abstraktionsebene die einzelnen Modellelemente mit den plattformspezifischen Artefakten zu verweben und die Erzeugung von lauffähigem Quellcode anzustoßen. Qualitätswerkzeuge 5

6 3 Erstellung einer Beispiel-App Die im Rahmen des Projekts ModAgile Mobile entwickelte Werkzeugkette integriert sich nahtlos in die Eclipse Entwicklungsumgebung. Die Installation kann über den Eclipse-spezifischen Update- Mechanismus P2 erfolgen. Hierzu steht eine Eclipse Update Site zur Verfügung. Die Installation der ModAgile Mobile Werkzeugkette wird auf den Webseiten des Projektes unter folgendem Link erklärt: Neben den ModAgile Mobile Werkzeugen müssen zudem noch die herkömmlichen Werkzeuge für plattformspezifische Entwicklung von mobilen Anwendungen (u.a. Android SDK für Android und Xcode für ios) installiert werden. 3.1 Modellbearbeitung Als erster Schritt muss ein neues Eclipse-Projekt erstellt werden, dass die Modelle für die zu entwickelnde Anwendung enthält. In diesem neuen Projekt können über den New-Wizard nun leere Modelle für die weitere Arbeit angelegt werden. Als erstes Modell sollte das App-Model angelegt werden (über File -> New -> Other -> Example EMF Model Creation Wizards -> App Model). Zunächst muss nun der Dateiname für die Modelldatei angegeben werden. Anschließend wird das Mobile App Element als Model Object ausgewählt. Das App Model ist nun initial angelegt. Eine grafische Repräsentation des Screenflow-Modells kann in ähnlicher Form über einen Wizard initialisiert werden (File -> New -> Other -> Examples -> modagil Diagram). Abbildung 6: App Model Wizard Qualitätswerkzeuge 6

7 Neben den App- und Screenflow-Modellen ist ein Domänenmodell erforderlich, das die Entitäten und Relationen aus der Anwendungsdomäne beschreibt. Für die ModAgile Werkzeugkette wurde hierzu kein eigenes Metamodell erzeugt. Anstatt dessen wird das Ecore Metamodell aus dem Eclipse Modeling Project wiederverwendet, das sich in vielen Bereichen als de facto Industriestandard etabliert hat und für das bereits eine Reihe von geeigneten Editoren existiert. Für eine detaillierte Beschreibung der verwendeten Metamodelle sei an dieser Stelle lediglich auf die Dokumentation der jeweiligen Metamodelle verwiesen. Im Folgenden wird ein kurzer Überblick über die zuvor genannten Modelle gegeben. Die dabei verwendeten Screenshots zeigen das Simple App Modell, das für den schnellen Einstieg als fertiges Beispielprojekt im Download-Bereich der Projektwebsite heruntergeladen werden kann. Abbildung 7: App Model Das App-Modell (siehe Abbildung 7) repräsentiert unter anderem die UI-Elemente der zu generierenden Applikation. Das Storyboard definiert einzelne Screens der Anwendung und den dazugehörigen Screenflow. Im Binding Repository werden Display-Elemente an Attribute von Domänenentitäten gebunden. Im Complex Display Element Type Repository können komplexere Displayelemente vordefiniert werden, die später innerhalb von Screens instanziiert werden können. Qualitätswerkzeuge 7

8 Abbildung 8: Graphischer Screenflow Editor Neben der Darstellung im Baum-Editor kann der Screenflow des App-Modells auch in einem graphischen Editor angezeigt und bearbeitet werden. Im gezeigten Beispiel ist ein Screen mit einer dynamischen Liste zu sehen. Abbildung 9: Ecore Domänenmodell Abbildung 9 zeigt das Domänenmodell der Anwendung als Ecore-Repräsentation. Es kann sowohl im baumbasierten Editor als auch in einem graphischen Ecore-Editor dargestellt werden. Qualitätswerkzeuge 8

9 3.2 Anwendungsgenerierung Um aus den zuvor beschriebenen Modelldateien den Rumpf einer mobilen Anwendung zu genieren, muss das App-Modell geöffnet werden. Im Baumeditor muss nun der oberste Knoten geöffnet werden, so dass das Modellelement Mobile App sichtbar ist. Mit einem Rechtsklick auf das Mobile App Element können die Funktionen Generate App (für Android) und Generate App ios (für ios) ausgeführt werden Android-Generierung Der Generator für Android produziert zunächst zwei neue Eclipse-Projekte. Das Projekt mit dem im App- Modell konfigurierten Namen ist das eigentliche Anwendungsprojekt. Das Projekt com.actionbarsherlock beinhaltet Kompatibilitätsbibliotheken, die die Funktionalitäten der ActionBar aus Android 3.0 (und größer) auch für vorhergehende Android-Versionen zur Verfügung stellt. Dieses Projekt muss in der Regel nicht mehr editiert werden. Das Anwendungsprojekt enthält einen Ordner src-gen, in dem sich die generierten Klassen befinden. Inhalte dieses Ordners werden bei jedem Generierungsvorgang vollständig überschrieben. Aus diesem Grund dürfen innerhalb dieses Ordners keine manuellen Anpassungen erfolgen. Im Verzeichnis src-man befindet sich manuell geschriebener Code. Daneben werden einmalig in dieses Verzeichnis Hooks generiert, die es ermöglichen, manuell geschriebenen Code im Framework-Code zu verankern. Hier lassen sich unter anderem die Lifecycle-Methoden überschreiben. Qualitätswerkzeuge 9

10 Abbildung 10: Generierte Android-Projekte in Eclipse Das so generierte Projekt lässt sich bereits in diesem initialen Zustand als Android-Anwendung ausführen und auf Geräten installieren ios-generierung Der Generator für ios-projekte ist zum Zeitpunkt der Erstellung dieses Dokuments noch nicht so weit entwickelt wie der Android-Generator. Bei der Generierung für ios wird ein ios-projekt erstellt, das gleichzeitig auch als Eclipse-Projekt geladen werden kann. Die eigentliche Entwicklung für ios muss jedoch in der Apple Xcode-Entwicklungsumgebung fortgesetzt werden, da zum momentanen Zeitpunkt für Eclipse kein Compiler und/oder Simulator für ios-projekte existiert. Das generierte Projekt lässt sich direkt als Projekt in XCode importieren. Wie beim Android-Projekt werden auch für ios die generierten Klassen in ein eigenes Verzeichnis abgelegt, das bei jedem Generierungsvorgang vollständig überschrieben wird. Im Gegensatz zu Android- Projekten gibt es bei Xcode-Projekten keinen direkten Zusammenhang zwischen der Struktur im Dateisystem und der logischen Projektstruktur in der Entwicklungsumgebung. Um dennoch generierten Code von manuell erstelltem Code unterscheiden zu können, werden generierte Klassen in eine eigene logische Projektgruppe ( Group ) abgelegt, so für den Entwickler die Art des Codes (generiert vs. nicht Qualitätswerkzeuge 10

11 generiert) zu jedem Zeitpunkt klar ersichtlich ist. Auch das generierte ios-projekt ist nach der initialen Generierung bereits ausführbar. 4 Fazit Im Rahmen von Arbeitspaket 7 ist ein Generatorwerkzeug für die Generierung von Android- und ios- Projekten, -Quellcode, -Testrümpfen und weiteren Artefakten entstanden. Ein Fokus der gewählten Implementierung liegt auf der Erweiterbarkeit der Generatoren für weitere Plattformen. So ist zukünftig (nach Abschluss des Projektes) eine Anbindung anderer mobiler Plattformen, wie beispielsweise Windows Phone oder Blackberry, vorstellbar. Durch die Integration des Generators in die Eclipse Entwicklungsumgebung, für die auch die Modelleditoren erstellt wurden, ist eine durchgängige Werkzeugkette für das Erstellen und Bearbeiten von Modellen, sowie für die Code-Generierung entstanden. Die Bedienung des Generators ist möglichst intuitiv gehalten, so dass eine hohe Entwicklungseffizienz für die plattformübergreifende Softwareentwicklung für mobile Plattformen geschaffen wurde. Qualitätswerkzeuge 11