Lieferung 4.2 Entwicklungsumgebung für die Integration von der modellgetriebenen Entwicklung in den Entwicklungszyklus

Transkript

1 Lieferung 4.2 Entwicklungsumgebung für die Integration von der modellgetriebenen Entwicklung in den Entwicklungszyklus für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket Arbeitspaketleitung Förderkennzeichen Projektleitung Partner Autoren Lieferdatum AP 4 Agile Entwicklungsumgebung andrena objects 01IS11012A andrena objects AG Jochen Winzen andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Christian Jansohn, Martin Küster, Johannes Tysiak, Antonia Volk, Jochen Winzen M24 Letztes Änderungsdatum Version 1.0 Entwicklungszyklus 1

2 1 Einleitung In diesem Dokument wird die im Projekt ModAgile Mobile verwendete Entwicklungsumgebung beschrieben. Diese basiert zunächst auf der frei verfügbaren Eclipse-IDE ( ) und wurde um eigene Editoren und Werkzeuge erweitert, um den kompletten modellgetriebenen Entwicklungszyklus (soweit möglich) in einer Umgebung abbilden zu können. Schon im Projektantrag wurde für die Entwicklungsumgebung folgendes Ziel definiert: Die modellgetriebene Entwicklung, das Schreiben von Unit- und Integrationstest und die manuelle Entwicklung der Anwendung muss in einer Entwicklungsumgebung ermöglicht werden. In den folgenden Kapiteln wird der aktuelle Stand der Entwicklungsumgebung mit einer schrittweisen Anleitung zur Erstellung einer mobilen Anwendung für die jeweilige Plattform vorgestellt. Am Ende erfolgt eine kurze Zusammenfassung, inwieweit das ursprüngliche Ziel erfüllt werden konnte. 2 Schrittweise Anleitung Das hier vorliegende Tutorial zur Erstellung einer einfachen mobilen App findet man auch auf der Webseite des Projektes: Der erste Schritt zur Generierung von Apps mit ModAgile Mobile ist die Modellerstellung (siehe Kapitel 2.1). Diese ist zielplattformunabhängig und erfolgt in der Eclipse-IDE. Die genaue Version der IDE und weitere verwendete Tools (z.b. Android SDK) findet man unter der URL: Nach der Modellerstellung folgt dann die Generierung für die jeweilige Plattform. Momentan unterstützt das ModAgile Mobile Framework die Generierung von Apps für Android, ios und Windows Phone. Die Generierung für jede Plattform wird dabei in einem eigenen Kapitel beschrieben, weil zumindest die manuelle Implementierung von Code in der nativen Entwicklungsumgebung erfolgt (Microsoft Visual Studio bzw. XCode unter ios). Das ist nötig, weil sich keine Anwendung zu 100% generieren lässt. Es gibt immer Anteile (insbesondere Geschäftslogik), die manuell implementiert werden müssen. Das Framework generiert hierfür dann Methodenrümpfe (Hooks), so dass die App jederzeit lauffähig ist. 2.1 Modellerstellung Hinweis: Dieses Kapitel kann auch ohne Vorkenntnisse mit den Eclipse Modeling Tools durchgearbeitet werden. Wer sich weitergehende Informationen zur Einarbeitung wünscht, kann zunächst diese beiden Dokumente lesen (dort sind auch viele Begriffe genauer erläutert): Lieferung 6.2 Modellierungsumgebung: Graphische Editoren für alle identifizierten Sichten Lieferung 6.3 Textuelle Editoren für alle identifizierten Sichten Entwicklungszyklus 2

3 Unter der URL < findet man ein Archiv mit mehreren Beispielprojekten. Darin befindet sich auch das Projekt de.modagile.validation.dynamiclist.models, das ein komplettes Modell einer mobilen Anwendung enthält. Anhand dieses Beispiels wird in diesem Kapitel die Struktur der notwenigen Modelle erläutert. Nach dem Download kann das Projekt über File Import General Existing Projects into Workspace als Archiv-File in den Workspace importiert werden. Das Modell, welches unsere Minimalapplikation beschreibt liegt im Projekt de.modagile.validation.dynamiclist.models im Unterverzeichnis model. Folgende Modelldateien repräsentieren unsere Beispielapplikation: Das oben abgebildete Modell repräsentiert die UI-Elemente der zu generierenden Applikation. Das StoryBoard definiert einzelne Screens der Anwendung und die Übergänge zwischen den Screens (Screenflow). Im BindingRepository werden Display-Elemente an Attribute von Domänenentitäten gebunden. Im Composite Display Element Type Repository können komplexere Displayelemente vordefiniert werden, die später innerhalb von Screens instanziiert werden können. Im Generator Config Container findet man die Konfigurationen, die für die Generatoren jeder Plattform notwendig sind. Der Event Container beinhaltet die Definition aller benötigten Events, die beispielsweise beim Klick auf einen Button ausgelöst werden. Entwicklungszyklus 3

4 Die Modelldatei example.app_storyboard ist eine graphische Darstellung des Screenflows aus dem App-Modell. Im gezeigten Beispiel ist der Startscreen mit einer dynamischen Liste zu sehen. Dieser ist über einen Flow mit dem Secondscreen verbunden. Der Übergang wird durch Betätigen des Buttons ausgelöst. Auf dem zweiten Screen befindet sich ein Inputfield, das genutzt werden kann, um die dynamische Liste zu füllen. Über den Button wird wieder der Flow auf den ersten Screen ausgelöst. Entwicklungszyklus 4

5 In der Ecore-Modell-Datei (example.ecore) ist das Domänenmodell der Anwendung repräsentiert. Unser Minimalbeispiel enthält eine Entität Greeting mit dem Attribut message und eine Entität GreetingList, die alle Greetings zusammenfasst. Das Domänenmodell kann sowohl im baumbasierten Editor als auch in einem graphischen Editor angezeigt werden. Dazu muss aus der Ecore-Datei nur eine entsprechende graphische Darstellung erzeugt werden. 2.2 Generierung Android Um aus den zuvor erstellten Modelldateien den Rumpf einer Android-Anwendung generieren zu können, muss das example.app Modell geöffnet werden. Im Baumeditor muss nun der oberste Knoten geöffnet werden, so dass Mobile App ExampleApp sichtbar ist. Mit einem Rechtsklick auf Mobile App ExampleApp kann die Option Generate Android App ausgeführt werden. Dabei entstehen zwei Projekte: com.actionbarsherlock und de.modagile.validation.dynamiclist.models.gen.android. Im ActionBarSherlock Projekt (siehe auch liegen 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 Projekt de.modagile.validation.dynamiclist.models.gen.android ist das eigentliche Anwendungsprojekt. Das Projekt enthält ein Verzeichnis src-gen, in dem sich die generierten Java-Klassen befinden. Inhalte dieses Ordners werden bei jeder Generierung 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 Entwicklungszyklus 5

6 geschriebenen Code im Framework-Code zu verankern. Hier lassen sich unter anderem die Lifecycle-Methoden überschreiben. Daneben finden sich hier manuelle Bindings wieder. Das generierte Beispielprojekt lässt sich in diesem Stadium bereits ausführen. Dazu kann einfach auf das Projekt de.modagile.validation.dynamiclist.models.gen.android mit rechter Maustaste geklickt werden. Anschließend startet durch Run As Android Application der Android Emulator mit der generierten Applikation. Sobald die App gestartet ist, ist ein Screen mit einer Liste zu sehen. Da zum jetzigen Zeitpunkt jedoch noch keine Personen innerhalb der App angelegt sind, ist der Screen bis auf den Add new Button leer. Über Add new kann ein neuer Gruß angelegt werden. Das Speichern auf dem zweiten Screen persistiert die Daten jedoch noch nicht. Um dies zu ändern, erweitern wir nachfolgend den manuellen Sourcecode. Das Paket de.modagile.validation.dynamiclist.models.activity.listener im Verzeichnis src-man enthält die Klasse de.modagile.validation.dynamiclist.models. Die Methode onclick() kann nun angepasst werden, um die eingegebenen Daten auf Knopfdruck zu persistieren. Dazu wird folgender Code benötigt: GreetingManager gm = new GreetingManagerImpl(mActivity); gm.create(mactivity.getgreeting()); GreetingListManager gml = new GreetingListManagerImpl(mActivity); GreetingList gl = new GreetingList(); gl.setgreetings(new ArrayList<Greeting>()); gml.create(gl); Wird jetzt die Applikation erneut gestartet, werden die eingegebenen Grußtexte persistiert. Entwicklungszyklus 6

7 2.3 Generierung ios Für die Generierung einer App unter Mac sind zunächst dieselben Schritte notwendig wie für Android. Nach der Erstellung des Anwendungsmodells kann aus der Entwicklungsumgebung (Eclipse) heraus die Generierung gestartet werden. Es wird ein Eclipse-Projekt mit den Quelldateien in Objective-C erstellt sowie eine Projektdatei für die ios-entwicklungsumgebung Xcode. Entwicklungszyklus 7

8 Das Zielprojekt kann danach mit der Xcode-Entwicklungsumgebung geöffnet werden. Eclipse ist für das Editieren von ios-projekten nicht geeignet. Stattdessen sollte immer der Apple-eigene Editor verwendet werden. Die Struktur des Projekts ist ähnlich wie die unter Android. Es werden Ordner für generierten und nicht generierten Code angelegt (src-gen und src-man), sowie Ordner für die verschiedenen Belange der Anwendung (Datenmodell, Viewcontroller, Persistenz, etc.). Diese Ordner sind in Xcode als Gruppen registriert und daher auch im Baumeditor sichtbar. Die Build-Eigenschaften des Projekts sind bereits so gesetzt, dass alle generierten Dateien bei einer Ausführung des Builds kompiliert werden. Entwicklungszyklus 8

9 Für das Beispiel der Anwendung mit einer Liste und einem Hinzufügen-Button (vgl. oben) wird nahezu der gesamte ausführbare Anwendungscode generiert. Ohne manuelle Änderungen würde die App jedoch den Zustand der hinzugefügten Greetings nicht nach dem Beenden speichern. Ist eine persistente Verwendung der Daten gewünscht, muss daher noch eine Zeile im Code ergänzt werden, die den managed object context, also die gesamten persistenten Daten fest speichert. Dies geschieht über die Zeile [self.managedobjectcontext save:nil]; Nach dieser kleinen Änderung ist die App ausführbar und liefert die gewünschte Funktionalität. Sie enthält eine Liste sowie einen Button zum Anlegen von Greetings. Auf dem zweiten Bildschirm befindet sich ein Eingabefeld und ein Button zum Speichern, der den Benutzer wieder zurück auf das Listen-Fenster bringt. Das neu erzeugte Greeting wird dort angezeigt. Entwicklungszyklus 9

10 Im Simulator kann die App getestet werden. Die Abbildung zeigt einen Lauf auf einem iphone- 6.1-Simulator, in der schon einmal verschiedene Greetings eingefügt wurden. Diese werden in der Liste angezeigt. 2.4 Generierung Windows Phone Auch für die recht neue Plattform WindowsPhone wurde im Projekt Modagile Mobile ein Generator entwickelt. Dies zeigt, dass der Ansatz grundsätzlich nicht auf die gegenwärtig bekannten Plattformen beschränkt ist, sondern sich erweitern lässt, sobald neue Zielplattformen gewünscht sind und realisiert werden sollen. Entwicklungszyklus 10

11 Der Einstieg in die Generierung ist wie bei den anderen Plattformen über das Kontextmenü erreichbar, das auf einem Anwendungsmodell angeklickt wird. Dort kann Generate Windows Phone App gewählt werden, worauf die Generierung startet. Auch unter WindowsPhone (WP) wird ein Eclipse-Projekt erstellt. Jedoch ist Eclipse für das Editieren und Bauen einer WP-App nicht geeignet. Stattdessen sollte das Microsoft-eigene Produkt Visual Studio verwendet werden. Klickt man auf das generierte Projekt (.sln), öffnet sich das Visual Studio mit den entsprechenden Sourcen sofort. Entwicklungszyklus 11

12 Die Struktur ist vergleichbar mit den anderen Zielplattformen. Auch hier gibt es die Unterteilung in generierten (src-gen) und manuellen (src-man) Code, sowie eine Unterteilung nach Belang. In WindowsPhone wurde bereits ein etwas anderer Ansatz verfolgt, bei dem mehr Code in Bibliotheken verlagert wurde, die von jeder generierten App verwendet werden. Dies ermöglicht etwas schlankeren Code bei der Generierung und vermeidet Redundanzen. Die Bibliothek muss einfach mit der App eingebunden werden. Entwicklungszyklus 12

13 Die WP-App ist auch fast voll funktionsfähig. Allein innerhalb des Button-Click-Event-Handlers fehlt noch etwas Code, der ein neues Greeting anlegt, und in das Datenmodell der Anwendung einfügt: Greeting g = Greeting.Create(); g.message = "<new greeting>"; ViewModel.DataContext.InsertAndSubmit(g); Danach wird, vergleichbar mit ios, das angelegte Greeting in den Daten-Kontext des Screens gespeichert und die Daten sind damit persistent. Führt man die Anwendung auf dem WP-Emulator aus, wird ein Screen mit dem modellierten Button sowie einem Listen-Feld gezeigt. Klicken auf add new führt den Benutzer zum zweiten Screen, auf dem über ein Eingabefeld die Begrüßung eingegeben werden kann. Beim Speichern über back wird der Eintrag in die Liste geschrieben und gespeichert. 3 Fazit und Ausblick Wie schon am Anfang genannt, sei hier nochmals auf die Webseite des Projektes verwiesen: Dort stehen auch alle hier genannten Werkzeuge des ModAgile Mobile Frameworks zum Download bereit: Insgesamt ist es gelungen, eine umfassende Integration der modellgetriebenen Entwicklung zu erreichen. Für die Zielplattform Android ist es nicht mehr nötig, die Entwicklungsumgebung zu verlassen. Alle Abläufe zur Entwicklung einer mobilen App sind in einer Umgebung integriert. Für andere Zielplattformen gibt es nach der initialen Generierung einen Wechsel in die plattformspezifische Entwicklungsumgebung. Diese ist den jeweiligen App Entwicklern am Entwicklungszyklus 13

14 besten vertraut und daher aus unserer Sicht die logische Wahl. Die Option, auch diese Entwicklungsschritte in Eclipse zu integrieren wurde frühzeitig und bewusst verworfen. Mit der vorliegenden Version des Frameworks können bereits lauffähige Anwendungen für die Zielplattformen Android, ios und Windows Phone generiert werden. Der konkrete Einsatz in mehreren Multi-Plattform Projekten wäre ein nächster Schritt, um die nötige Produktreife zu erlangen und das Framework um noch fehlende Features zu ergänzen. Entwicklungszyklus 14