Lieferung 3.2 Erfahrungsbericht M24

Transkript

1 Lieferung 3.2 Erfahrungsbericht M24 für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket Arbeitspaketleitung Förderkennzeichen Projektleitung Partner Autoren Lieferdatum Letztes Änderungsdatum AP3 Referenzarchitektur und Benutzungsfälle arconsis IT-Solutions GmbH 01IS11012B andrena objects AG Jochen Winzen andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Johannes Tysiak M Version 1.0 ModAgile Mobile L3.2 Erfahrungsbericht M24 1

2 1 Einleitung Dieses Dokument fasst wichtige Erfahrungen und gesammelte Erkenntnisse aus dem Projekt ModAgile Mobile zusammen. Wie in den meisten explorativen Projekten im Forschungsbereich ging die ursprüngliche Planung von Annahmen aus, die sich während der Projektlaufzeit als nicht oder nicht vollständig zutreffend herausgestellt haben. In diesem Dokument sollen daher in Form einer Projekt-Retrospektive (Lessons Learned) Erfahrungen festgehalten werden, die über die gesammelten Erkenntnisse auf Inhaltsebene (so wie sie bereits in anderen Lieferungen geschildert wurden) hinausgehen. 2 Retrospektive Betrachtung Die folgende retrospektive Betrachtung für das Projekt ModAgile Mobile soll in erster Linie Antworten auf zwei Fragen geben: 1. Was genau lief gut während der Projektlaufzeit? 2. An welcher Stelle haben wir Verbesserungspotential identifiziert? Dieses Dokument erhebt dabei jedoch keinen Anspruch auf Vollständigkeit. Es sollen lediglich die für das Konsortium (subjektiv) wichtigsten Erkenntnisse zusammengetragen werden. 2.1 Domäne: Mobile Development Bereits bei der Planung des Projektes ModAgile Mobile wurde berücksichtigt, dass das Projekt bedingt durch das Umfeld der Software-Entwicklung für mobile Endgeräte einer hohen Volatilität unterliegt. Bei allen betrachteten mobilen Plattformen (Android, ios, Windows Phone) ist die Entwicklung während der Projektlaufzeit in großen Schritten vorangegangen. Bei Android war zum Projektstart lediglich die Version (API Level 10) für Phone, sowie die Version 3.0 (API Level 11) für Tablet-Devices verfügbar. Während der Projektlaufzeit wurden darüber hinaus die Versionen 3.1 (API Level 12), 3.2 (API Level 13), 4.0.x (API Level 14 und 15), Version 4.1 (API Level 16) und Version 4.2 (API Level 17) veröffentlicht, die jeweils Auswirkungen auf den zu generierenden Code und damit die Modell-zu-Code-Transformationen hatte. Insbesondere der Wechsel auf Android 4.0 brachte weitreichende Änderungen mit sich (beispielsweise die Verfügbarkeit von Fragments für die UI-Erstellung), auf die ModAgile Mobile reagieren musste. Im Falle von ios war zum Projektstart die Version 4.x verfügbar. Mittlerweile ist zum Projektende die Version 6.x verfügbar. Auch hier gab es eine Reihe von projektrelevanten Änderungen, unter anderem das Automatic Reference Counting, das eine vollständige Überarbeitung der Speicherverwaltung mit sich brachte. Das im Projektrahmen eingesetzte agile Vorgehen ermöglichte eine zeitnahe Reaktion auf solche äußeren Einflüsse. Dennoch ergaben sich durch die notwendigen Anpassungen an den entwickelten Werkzeugen erhebliche Mehraufwände für ModAgile Mobile. ModAgile Mobile L3.2 Erfahrungsbericht M24 2

3 2.2 Breites Technologiespektrum Neben dem volatilen Umfeld des Projekts hat sich auch das eingesetzte breite Technologiespektrum als Herausforderung dargestellt. Neben den eigentlichen Zieltechnologien (Android, ios, Windows Phone), die jeweils für sich schon eine hohe Komplexität mit sich bringen, waren im Projektkontext auch Technologien für den Werkzeugbau gefordert. Insbesondere die eingesetzten Eclipse Technologien (Eclipse Plugin Development, Xtext, GMF, Xtend2) spannten einen weiteren Technologiefächer auf, der den Einstieg in das Projekt insbesondere für Quereinsteiger oder Absolventen enorm komplex gestaltete. Jede Fluktuation des im Projekt eingesetzten Personals gestaltete sich dadurch als Herausforderung. Die hier beschriebene Komplexität des eingesetzten Technologiespektrums wirkt sich auch auf Projekte aus, die mit der ModAgile Mobile Werkzeugkette entwickelt werden. Während ein reiner Entwickler (und Benutzer der ModAgile Tools) wenig Wissen über die zugrunde liegenden Modellierungs- und Generierungs-Technologien benötigt, so ist dieses Wissen für eine Wartung und Weiterentwicklung der Werkzeuge unabkömmlich. Sollte die Volatilität im Umfeld der Softwareentwicklung für mobile Endgeräte weiter hoch bleiben, so können Anpassungen auf neue Frameworks und Konzepte nur mit dem geeigneten Expertenwissen erfolgen. 2.3 Referenzbeispiel Bei der Entwicklung von Modell-zu-Code-Transformationen wird in der Regel mit einer (manuell geschriebenen) Referenzimplementierung als Vorlage für die zu erarbeitenden Code-Templates gearbeitet. Auch für ModAgile Mobile wurde so gearbeitet. Bedingt durch die in den Abschnitten 2.1 und 2.2 erörterten Schwierigkeiten ergaben sich weitere Herausforderungen, denen das Projekt geeignet gegenüber treten musste. Die hohe Volatilität der zugrunde liegenden Technologieplattformen (Android, ios) führte dazu, dass ein einmal erstelltes Referenzbeispiel nicht in Stein gemeißelt als Vorlage dienen konnte, sondern dass es permanent an neue Konzepte angepasst werden musste. Änderungen an der Vorlage wiederum implizierten Änderungen an den erstellten Templates, was zu einem erheblichen Mehraufwand für das Projekt führte. Darüber hinaus ergab sich unter anderem durch die hohe Komplexität der Zielplattformen eine weitere Hürde. Initial wurde im Projekt das Produkt FleetJournal als repräsentative mobile Anwendung und damit als Referenzbeispiel identifiziert. FleetJournal ist eine Applikation zum Management einer Fahrzeugflotte für mittelständische Unternehmen. Es zeigte sich dabei jedoch schnell, dass die Komplexität dieser Anwendung zu hoch ist, um sie als Referenzbeispiel einsetzen zu können. Als Konsequenz daraus wurde MAMEX (ModAgile Mobile EXample) entwickelt, das ein minimales Referenzbeispiel darstellen sollte, mit dem alle relevanten Technologieaspekte in möglichst einfacher und anschaulicher Art vorgegeben werden sollten. Bedingt durch die Vielzahl der eingesetzten Technologieaspekte und die Volatilität der Plattformen wurde auch MAMEX über die Projektlaufzeit langsam immer größer und eignete sich immer schlechter als Referenzbeispiel. Daraufhin wurde in späteren Projektphasen auf feature-zentrierte Referenzbeispiele gesetzt. Dabei zeigt ein Referenzbeispiel auf möglichst einfache Form die Implementierung eines spezifischen Features. Seiteneffekte zwischen Features können dadurch ausgeblendet werden und der Werkzeug-Entwickler kann sich auf sein originäres Ziel konzentrieren. Weitere Features können bei dieser Verfahrensweise iterativ hinzugezogen werden. Der Einsatz dieses Verfahrens hat sich bewährt und sollte in zukünftigen Projekten dieser Art von Anfang an gewählt werden. ModAgile Mobile L3.2 Erfahrungsbericht M24 3

4 2.4 Modellierung und Generierung Eine weitere wichtige Frage, die im Rahmen des Projekts beantwortet werden musste, betrifft die Abgrenzung von Modellierung und Generierung gegenüber der manuellen Implementierung. Dem Konsortium war bereits zu Projektanfang bewusst, dass eine vollständige Modellierung und Generierung von Anwendungen nicht realistisch umgesetzt werden kann. Die Freiheitsgrade, die eine manuelle Implementierung zulässt, können nicht mit vertretbarem Aufwand mit einem vollständig generativen Ansatz abgedeckt werden. Daher musste eine Auswahl der zu modellierenden und generierenden Aspekte getroffen werden und eine Integration von manuell geschriebenen Code in den generierten Code vorgesehen werden. Grundsätzlich wurden daher unter anderem folgende Aspekte mit Hinblick auf ihre Modellierund Generierbarkeit betrachtet: die Domänenmodellierung, die User-Interface-Modellierung und die Verhaltensmodellierung Verhaltensmodellierung Aufgrund der Erfahrungen des Projektkonsortiums im modellgetriebenen Umfeld wurde eine Verhaltensmodellierung schnell ausgeschlossen. Zum einen ist die Komplexität von Verhalten häufig so hoch, dass sie nicht oder nur schwer mit vertretbarem Aufwand modelliert und generiert werden kann. Daneben lässt eine Verhaltensgenerierung oft nicht die Freiheitsgrade zu, die eine manuelle Implementierung mit sich bringt. Im Projektkontext fand daher eine Konzentration auf die Domänenmodellierung und die User-Interface-Generierung statt User Interface Modellierung Die Modellierung und Generierung von User Interfaces brachte eine Vielzahl von Herausforderungen mit sich. Unter anderem sind die in den verschiedenen Plattformen verfügbaren UI Widgets nicht vollständig identisch mit Blick auf ihr Verhalten, so dass hierfür geeignete Umgehungen geschaffen werden mussten. Dies verschärft sich dadurch, dass es für die verschiedenen Plattformen jeweils unterschiedliche Guidelines zur Erstellung von User Interfaces gibt. Als Beispiel für solche Unterschiede sei hier der Back-Button genannt. In Android bietet die Hardware oder das System eine Schaltfläche für Zurück, während diese bei ios gesondert betrachtet werden muss. Eine weitere Hürde ergab sich dadurch, dass vor allem im Android-Framework während der Projektlaufzeit eine grundlegende Überarbeitung der Konzepte für die UI-Erstellung (z.b. ActionBar, Fragmente) stattfand. Diese Überarbeitung erfolgte, damit auch Tablet-Devices geeignet unterstützt werden konnten. Hierdurch ergab sich für das Projekt erheblicher Mehraufwand. Problematisch ist zudem die Integration in ein geschlossenes System wie Apples Xcode- Entwicklungsumgebung. Apple bietet mit dem Storyboard-Editor ein Werkzeug für die UI- Erstellung an. Aufgrund des proprietären Datenformats der jeweiligen Projektdateien ist es jedoch kaum möglich, eine zukunftssichere Integration der ModAgile Werkzeugkette mit diesem UI-Editor zu erreichen. Der vom Projekt verfolgte Weg, komplett ohne diesen Storyboard-Editor auszukommen, ist zwar gut möglich, weil alle Elemente auch programmatisch erstellt werden können. Er kommt allerdings an seine Grenzen, wenn das Design der Benutzeroberfläche komplex wird. Hier ist das Apple-eigene Werkzeug deutlich überlegen. ModAgile Mobile L3.2 Erfahrungsbericht M24 4

5 Retrospektiv betrachtet ist die Modellierung von User Interfaces eine Idee, von der eher Abstand genommen werden sollte. Abgesehen von den Schwierigkeiten, die auf der Volatilität der Plattformen basiert und den unterschiedlichen User Interface Guidelines, sind die von den jeweiligen Plattformen angebotenen Editoren zur Erstellung von User Interfaces gut geeignet, um mit überschaubarem Aufwand angepasste User Interfaces zu erstellen Domänenmodellierung Sehr bewährt hat sich im Rahmen des Projekts die Modellierung und Generierung des Codes für die jeweilige Domäne. Die Datenmodellierung hat sich bereits in vielen anderen Projekten als geeignetes Hilfsmittel bewiesen. Auch im Rahmen von ModAgile hat sich diese Erkenntnis bestätigt. Auf der Basis der modellierten Datenobjekte aus der Anwendungsdomäne lassen sich neben dem Code für die reine Datenhaltung der Domäne auch Code für die Persistenz der Daten auf dem mobilen Gerät, sowie für die Übertragung an Mobile Gateways über das Netzwerk generieren. Zudem kann durch die plattformunabhängige Modellierung sichergestellt werden, dass die unterschiedlichen Datenrepräsentationen für die verschiedenen Zielplattformen jeweils auf einem identischen Stand gehalten werden können. Der generative Ansatz für die Erstellung von mobilen Anwendungen hat sich als vorteilhaft erwiesen. Mit den ModAgile Werkzeugen ist es möglich, lauffähige Rümpfe für kleine Anwendungen innerhalb kurzer Zeit zu generieren. 3 Fazit Das Projekt hat eine Reihe von Erkenntnissen mit sich gebracht, die so nur schwer voraussehbar waren, die sich aber für zukünftige Projekte als nützliche Grundlage erweisen werden. Die entwickelte Werkzeugkette ermöglicht einen schnellen Start in die Entwicklung von Anwendungen für mobile Endgeräte. Dabei eignet sich die Werkzeugkette in erster Linie für die Entwicklung von datenlastigen und datenzentrierten Anwendungen, bei denen die Vorteile der Domänenmodellierung und generierung einen deutlichen Mehrwert gegenüber der herkömmlichen manuellen Entwicklung darstellen. ModAgile Mobile L3.2 Erfahrungsbericht M24 5