Lieferung 2.2 Validierung der Anforderungen

Transkript

1 Lieferung 2.2 Validierung der Anforderungen für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket Arbeitspaketleitung Förderkennzeichen Projektleitung Partner Autoren Lieferdatum Letztes Änderungsdatum AP 2 Anforderungsanalyse; Validierung andrena objects 01IS11012A andrena objects ag Jochen Winzen andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Christian nsohn, Antonia Volk, Jochen Winzen M Version 1.0 ModAgile Mobile L2.2 Validierung der Anforderungen 1

2 1 Einleitung In diesem Dokument werden die Ergebnisse der Validierung der Anforderungen des Projektes ModAgile Mobile vorgestellt. Dazu werden im nächsten Kapitel noch einmal die ursprünglichen Ziele des Projektes betrachtet und darin genauer ausgeführt, inwieweit diese Anforderungen erfolgreich umgesetzt werden konnten. Im Verlauf des Projektes hat sich mehr und mehr gezeigt, dass die Modelle zur Implementierung und Validierung der Generatoren gar nicht einfach genug sein können. Insofern haben wir uns in einer Lernkurve von kompletten Referenzbeispielen (Mamex01) hin zu minimalen Featurebasierten Validierungsmodellen bewegt. Dies zeigt auch für den modellgetriebenen Ansatz eine Ähnlichkeit zu den Techniken Test-First / Unit Tests bei der agilen Softwareentwicklung. Die weiteren Kapitel (Validierungsmodelle, Features mobiler Anwendungen) legen den Schwerpunkt auf eine konkrete Auswertung, wie weit die Funktionalität der Modelle und Generatorwerkzeuge von ModAgile Mobile für die unterstützten mobilen Plattformen Android, ios und Windows Phone realisiert worden ist. Wie sich in der Auswertung zeigt, sind die Validierungsmodelle hinreichend, um den kompletten Funktionsumfang des Frameworks zu testen, und sie ermöglichen im letzten Kapitel eine Aussage darüber, welche Klasse von mobilen Anwendungen nun mit ModAgile Mobile erzeugt werden kann. 2 Anforderungen an das Projekt ModAgile Mobile Schon im Projektantrag wurden die erwarteten Ergebnisse formuliert (folgende acht Punkte): 1. Agiler integrierter Entwicklungsprozess für mobile Anwendungen Die Ergebnisse für diesen Punkt werden in Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen genauer beschrieben. Grundsätzlich ist es im Rahmen eines Forschungsprojektes schwierig, einen ganzen Entwicklungsprozess zu validieren. a) Dazu hätten wir u.a. in mehreren Fallstudien die Entwicklung mobiler Anwendungen mit verschiedenen Prozessen und einer statistisch relevanten Menge an Entwicklern durchführen müssen, um hier einen Vergleich vornehmen zu können. b) Die Fallbeispiele zur Prozessvalidierung sollten reale Anwendungsfälle sein. Dem steht jedoch entgegen, dass die Ergebnisse aus dem Projekt erst nach der Projektlaufzeit wirtschaftlich verwertet werden dürfen. Im Laufe des Projektes konnte das ModAgile Mobile Framework dahingehend validiert werden, dass es grundsätzlich die Voraussetzungen für den Einsatz in einem Agilen Entwicklungsprozess erfüllt. Dazu zählt vor allem, dass alle Prozessschritte (Modellierung, Test, Entwicklung, QS) inkrementell und in kurzen Iterationen möglich sind. 2. Domänenspezifische Sprache zur Formulierung von mobilen Anwendungen Die Erstellung einer Domänenspezifischen Sprache (DSL) war einer der ersten Punkte, die im Projekt angegangen wurden. Hierzu wurden umfassende (Meta-)Modelle auf ModAgile Mobile L2.2 Validierung der Anforderungen 2

3 Basis des Eclipse Modeling Frameworks (EMF) geschaffen. Im späteren Verlauf kamen grafische Editoren (GMF) hinzu und eine eigene Testsprache (Test-DSL). Diese Punkte sind in folgenden Lieferungen genauer beschrieben: Lieferung 5.2 Detaillierte Dokumentation und Formalisierung der Entwicklungskette Lieferung 6.1 Prototyp und Mockup der Visualisierung der DSL Modelle Lieferung 6.2 Modellierungsumgebung: Graphische Editoren für alle identifizierten Sichten Lieferung 6.3 Textuelle Editoren für alle identifizierten Sichten Lieferung 8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests 3. Plattformunabhängige Definition von Anwendungen zur Reduzierung der Time- To-Market für verschiedene Plattformen gleichzeitig Dieser Punkt korreliert mit dem Thema DSL (unter 2.). Die Reduzierung der Time-To- Market konnte schon im kleineren Maßstab innerhalb des Projektes festgestellt werden. Wir unterstützen bei der Multi-Plattform-Generierung die Plattformen Android, ios und Windows Phone. Die zuletzt genannte Plattform Windows Phone wurde erst sehr spät im Projekt angegangen. Hier zeigten sich dann aber auch enorme Synergieeffekte. So entfiel bei dieser Plattform komplett der Aufwand zur Erstellung der (Meta-)Modelle, welche 1:1 von den anderen Plattformen übernommen werden konnten. Auch die Erstellung der Generator-Templates lief in sehr kurzer Zeit. Dies lässt den Schluss zu, dass der einmalige Entwicklungsaufwand des Frameworks selbst (Meta-Modell / DSL, Editoren, Generatoren / Templates) den Großteil des Entwicklungsaufwandes ausmacht. D.h. das Hinzufügen weiterer Plattformen oder Modellieren neuer Anwendungen wird zunehmend kosteneffizient und die Gesamtentwicklungszeit über mehrere Plattformen hinweg verkürzen. Somit ist eines der Hauptziele im Projekt erreicht und sollte nun im Praxisalltag mit der Erstellung mehrerer mobiler Anwendungen erprobt werden. 4. Integrierte Entwicklungsumgebung für agile modellgetriebene Softwareentwicklung mobiler Anwendungen Schon sehr früh wurde im Projekt die Entscheidung getroffen, die integrierte Entwicklungsumgebung auf Basis der Eclipse-IDE ( umzusetzen. Diese Entscheidung hat bis zum heutigen Tag Bestand und alle nötigen Editoren und Werkzeuge konnten erfolgreich in die eine Entwicklungsumgebung integriert werden. Dies ist genau beschrieben in Lieferung 4.2 Entwicklungsumgebung für die Integration von der modellgetriebenen Entwicklung in den Entwicklungszyklus. 5. Modellgetriebene Techniken zur schnellen Umsetzung von Anforderungen in mobile Applikationen Auch hier sei wieder auf die schon zuvor genannten Punkte verwiesen. Eine schnelle Umsetzung bei der Modellierung ist dadurch gegeben, dass für die integrierte Entwicklungsumgebung komfortable Editoren (EMF, GMF) geschaffen wurden. ModAgile Mobile L2.2 Validierung der Anforderungen 3

4 Es soll hier jedoch nicht verschwiegen werden, dass eine schnelle Umsetzung von Anforderungen maßgeblich davon abhängt, wie vertraut der jeweilige Entwickler mit den modellgetriebenen Techniken und Werkzeugen ist. Von Vorteil ist hier, dass bei ModAgile Mobile nur auf bekannten Standards aufgesetzt wird, d.h. kein projektspezifisches Spezial-Know-How aufgebaut werden muss. Zudem erhöht sich mit steigender Anzahl der Plattformen der Zeitgewinn beim Einsatz modellgetriebener Techniken gegenüber manueller Implementierungen (siehe Beispiel Windows Phone). 6. Integrierte automatische Qualitätssicherung für die Endapplikationen auf verschiedenen Plattformen, abgeleitet aus plattformunabhängigen Definitionen Für die Qualitätssicherung auf verschiedenen Plattformen wurden mehrere Maßnahmen umgesetzt. So gibt es zum einen die Möglichkeit, plattformunabhängig Modell-Metriken zu messen. Dies ist genauer beschrieben in Lieferung 8.3 Erweiterung von USUS um Metriken auf der Modell-Ebene. Auch dieses Tool steht als Eclipse-Plugin zur Verfügung (und kann zudem in einen automatisierten Build-Prozess integriert werden). Zum anderen kann man mit der (UI-)Test-DSL plattformunabhängige Tests auf der Modellebene erstellen. Diese werden dann mit den Generatoren in für die jeweilige Plattform spezifische Tests umgesetzt (z.b. Robotium für Android). Auch hier ist bei mehreren Plattformen ein Zeitgewinn gegenüber der manuellen Implementierung gegeben. Die Test-DSL ist dokumentiert in Lieferung 8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests. Diese Maßnahmen zur automatischen Qualitätssicherung konnten im Rahmen des Projektes nicht validiert werden, weil hierzu analog zum Entwicklungsprozess (Punkt 1) umfangreiche Fallstudien durchzuführen sind, bevor man zu einer qualitativen Aussage bzgl. der Wirksamkeit der Maßnahmen kommen kann. So bleibt dies ein Punkt für weitere Forschungsarbeit(en). 7. Plattformübergreifendes Framework zur Erstellung mobiler Anwendungen Dies ist die zentrale Anforderung an das Projekt. Der Reifegrad des ModAgile Mobile Frameworks wird in den Folgekapiteln mit Hilfe der Validierungsmodelle genauer untersucht. 8. Beispielanwendung zur Validierung der Projektergebnisse (über projektexternen Partner) Diese Anforderung mussten wir schon sehr früh im Projektverlauf streichen, weil die Diskrepanz zwischen der Forschung an neuen Entwicklungsmethoden und der Forderung externer Partner nach produktreifen Anwendungen nicht in Einklang zu bringen war. Nach Abschluss des Projektes ist es für die Partner ggf. interessant, diese Option wieder aufzugreifen. ModAgile Mobile L2.2 Validierung der Anforderungen 4

5 3 Validierung des Frameworks mit Hilfe geeigneter Validierungsmodelle Das Ziel der Validierung ist zu prüfen, ob alle Features mobiler Anwendungen (siehe Liste in Kapitel 4) für alle Plattformen korrekt erzeugt werden. Dafür wurden mehrere Validierungsmodelle erstellt, deren Fokus jeweils auf einem Feature liegen. Dabei wurden sowohl Modelle berücksichtigt, die sich auf die Oberfläche konzentrieren, als auch Modelle, die eine korrekte Generierung von Domänenobjekten sicherstellen. 3.1 Beschreibung der Validierungsmodelle In diesem Abschnitt werden die Validierungsmodelle genauer beschrieben de.modagile.validation.label.models Dieses Modell enthält genau einen Screen. Auf diesem soll das Label mit dem Inhalt "Hello World" angezeigt werden. Das Ziel dieses Modells ist, die Generierung von statischen Labels zu prüfen de.modagile.valdidation.flow.models In diesem Modell wird ein Flow zwischen zwei Screens definiert. In der generierten App soll es möglich sein, zwischen den beiden Screens zu wechseln. Ausgelöst wird dies über das Betätigen des jeweiligen Buttons. Das Storyboard zu diesem Modell wird in Abbildung 1 Storyboard des Flow ModelsAbbildung 1 dargestellt. Abbildung 1 Storyboard des Flow Models ModAgile Mobile L2.2 Validierung der Anforderungen 5

6 3.1.3 de.modagile.validation.imagebutton.models Dieses Modell prüft die Generierung eines Imagebuttons. Es basiert auf de.modagile.validation.flow.models. Der einzige Unterschied ist der Button selber, der auf dem ersten Screen kein Textlabel hat, sondern ein Bild de.modagile.validation.inputfield.models Auch dieses Modell basiert auf dem Validierungsmodell für Flows. Die Erweiterung besteht darin, ein Eingabefeld zu verwenden. Der Text auf Screen 1 ist nicht mehr statisch, sondern wird im Eingabefeld auf dem zweiten Screen eingegeben. Ändert sich dieser, wechselt auch der angezeigt Text de.modagile.validation.dynamiclist.models Dieses Modell erweitert das vorige Modell um eine dynamische Liste. Auf dem Startscreen wird nicht nur der letzte eingegebene Text angezeigt, sondern alle. Hiermit wird die korrekte Generierung einer dynamischen Liste getestet de.modagile.validation.checkbox.models Auf dem "StartScreen" liegt lediglich eine Checkbox. Es geht hier nur darum, dass die Checkbox richtig generiert bzw. angezeigt wird und bedienbar ist de.modagile.validation.menubar.models Dieses Modell ähnelt dem Modell aus de.modagile.validation.flow.models. Der Unterschied besteht darin, dass der Button auf dem "StartScreen" nun in einer Menubar angezeigt wird. Die Funktionalität bleibt die gleiche de.modagile.validation.image.models Dieses Modell besteht aus einem Screen. Auf diesem soll ein Label mit dem Text "Hello World" und ein Bild mit den Maßen 200 (height) x 100 (width) angezeigt werden de.modagile.validation.datepicker.models In diesem Modell wird ein Datepicker auf einem Screen definiert. Wird der Button betätigt, öffnet sich der Datepicker und ein Datum kann ausgewählt werden. Hiermit wird die korrekte Generierung eines Datepickers getestet de.modagile.validation.locationicker.models Analog zu dem vorigen Modell wird hier ein Modell mit einem Locationpicker definiert.. Bei Betätigung des Buttons soll sich eine Karte öffnen, auf der man eine Lokation auswählen kann. ModAgile Mobile L2.2 Validierung der Anforderungen 6

7 de.modagile.validation.composite.models Dieses Modell besteht aus einem Screen. Dieser Screen enthält ein Display Composite, das zwei Labels enthält. Beide sind mit festen Werten belegt. Es wird erwartet, dass auf dem Screen der Text "Hello composite" und "Bye composite" angezeigt wird de.modagile.validation.composition.models Dieses Model testet die Generierung einer Composition (Containment-Referenz) im Domainmodell. Es ist angelehnt an de.modagile.validation.inputfield.models. Der Unterschied ist, dass die anzuzeigende Nachricht in eine weitere Klasse ausgelagert wurde. Das Diagramm dazu findet sich in Abbildung 2. Von der Funktionalität unterscheiden sich beide Modelle nicht. Dieses Modell erfordert Testdaten, um die Funktionalität zu zeigen de.modagile.validation.onetomanyreference.models Dieses Modell testet die Generierung einer One-To-Many Referenz. In dem Modell werden zwei Screens definiert. Auf dem ersten Screen werden alle Messages in einer DynamicList angezeigt. Bei Klick auf einen Listeneintrag werden die der ausgewählten Message zugehörigen Empfänger in einer DynamicList auf dem zweiten Screen angezeigt. Dieses Modell erfordert Testdaten, um die Funktionalität anzuzeigen de.modagile.validation.manytomanyreference.models Dieses Modell testet die Generierung einer Many-To-Many Referenz im Domänenmodell. In dem Modell werden zwei Screens definiert. Auf dem ersten Screen befindet sich eine Liste mit allen Absendern (es wird jeweils das Attribut name gezeigt). Bei Click auf einen Listeneintrag werden auf dem zweiten Screen in einer DynamicList alle Messages (Attribut text) aufgelistet, wobei eine CheckBox jeweils anzeigt ob die Message zum gewählten Sender gehört. (Diese Funktionalität erfordert manuellen Code). Dieses Modell erfordert Testdaten, um die Funktionalität anzuzeigen. Abbildung 2 Composition im Domänenmodell ModAgile Mobile L2.2 Validierung der Anforderungen 7

8 3.2 Auswertung der Validierungsmodelle für die Plattformen Anhand der erstellten Validierungsmodelle wurde die korrekte Codegenerierung bzgl. Oberfläche und Domänenmodell überprüft. Die folgenden Tabellen geben einen Überblick darüber, zu welchen Modellen vollständig korrekter Code bzw. lauffähige Apps generiert wird. Dabei wird zwischen den Zielplattformen Android, ios und Windows Phone unterschieden. In der ersten Spalte der Tabelle findet man den Modellnamen. Diese Modelle wurden in Kapitel 3.1 näher beschrieben. Die zweite Spalte gibt an, ob der Code für die jeweilige Plattform korrekt generiert wird. Ein bedeutet, dass der Code richtig generiert wird und die entstehende App lauffähig ist. Nein bedeutet, dass es nicht möglich ist eine lauffähige App zu erzeugen, die das Feature enthält. Teilweise wird nur bei den Modellen verwendet, die die Generierung der Domänenobjekte validieren sollen. An dieser Stelle bedeutet es, dass die Objekte zwar richtig generiert werden, aber nicht an der Oberfläche angezeigt werden können. In der dritten Spalte findet man Anmerkungen zur Generierung, falls notwendig Android Modell de.modagile.validation.label.models de.modagile.validation.flow.models de.modagile.validation.imagebutton.models de.modagile.validation.inputfield.models Wird generiert? Anmerkungen de.modagile.validation.dynamiclist.models Manueller Code notwendig de.modagile.validation.checkbox.models de.modagile.validation.menubar.models de.modagile.validation.image.models de.modagile.validation.datepicker.models de.modagile.validation.locationpicker.models de.modagile.validation.composite.models de.modagile.validation.composition.models de.modagile.validation.onetomanyreference.models Nein Nein Teilweise Fehlende Funktionalität für Fragmente Fehlende Funktionalität für Fragmente Auf Modellebene richtig generiert. Entsprechung in der Oberfläche fehlt, da Funktionalität für Fragmente fehlt. ModAgile Mobile L2.2 Validierung der Anforderungen 8

9 de.modagile.validation.manytomanyreference.models Teilweise Auf Modellebene richtig generiert. Entsprechung in der Oberfläche fehlt, da Funktionalität für Fragmente fehlt. Für die Zielplattform Android können aus den meisten Modellen die richtigen lauffähigen Apps generiert werden. Die restlichen Modelle können nur zum Teil oder gar nicht erzeugt werden. Beim Erzeugen der dynamischen Liste ist manueller Code notwendig, damit die App richtig funktioniert. Der Code in Abbildung 3 muss im ClickEvent des Buttons ergänzt werden. Abbildung 3 Code zur Ergänzung der dynamischen Liste in Android Aktuell ist es nicht möglich Fragmente mit ModAgile zu erzeugen. Deswegen lässt sich aus den Modellen Locationpicker und Composite keine lauffähige App generieren. Dieses Problem betrifft auch die Modelle One-To-Many-Reference und Many-To-Many-Reference. Deren Fokus liegt allerdings auf dem Domänenmodell, welches korrekt erzeugt wird. Eine passende Oberfläche lässt sich aktuell aber nicht dazu anzeigen ios Modell de.modagile.validation.label.models de.modagile.validation.flow.models de.modagile.validation.imagebutton.models Wird generiert? Nein Anmerkungen de.modagile.validation.inputfield.models Nein String Binding funktioniert nicht de.modagile.validation.dynamiclist.models de.modagile.validation.checkbox.models de.modagile.validation.menubar.models de.modagile.validation.image.models Nein Nein Manueller Code notwendig, um das Einfügen in die Liste zu ergänzen Navigationscontroller wird nicht erzeugt ModAgile Mobile L2.2 Validierung der Anforderungen 9

10 de.modagile.validation.datepicker.models de.modagile.validation.locationpicker.models de.modagile.validation.composite.models Nein Manueller Code notwendig, damit das ausgewählte Datum im Label angezeigt wird de.modagile.validation.composition.models Teilweise Datenmodell wird korrekt angelegt de.modagile.validation.onetomanyreference.models Teilweise Datenmodell wird korrekt angelegt de.modagile.validation.manytomanyreference.models Teilweise Datenmodell wird korrekt angelegt Für ios lassen sich weniger Apps zu den Validierungsmodellen generieren. Die App mit dem Inputfield kann nicht vollständig generiert werden, da das String Binding dabei nicht funktioniert. Die Oberflächenelemente dazu werden aber richtig erzeugt. Beim Generieren der dynamischen Liste ist manueller Code notwendig, damit das Persistieren der Liste funktioniert: Abbildung 4 ios Code zum Persistieren einer Liste Der Datepicker funktioniert im Gegensatz zu Android nicht ohne zusätzliche Anpassung. Bei ios wird noch Code benötigt, der dafür sorgt, dass das ausgewählte Datum in dem dazugehörigen Label angezeigt wird. Benutzerdefinierte Bilder werden aktuell nicht unterstützt, da diese niedriger priorisiert waren. Bei den Validierungsmodellen, die sich auf das Domänenmodell beziehen, gibt es ein ähnliches Verhalten wie für die Plattform Android. Das Datenmodell wird bereits korrekt generiert, auf der Oberfläche ist das allerdings nicht sichtbar Windows Phone Modell de.modagile.validation.label.models de.modagile.validation.flow.models Wird generiert? Anmerkungen ModAgile Mobile L2.2 Validierung der Anforderungen 10

11 de.modagile.validation.imagebutton.models de.modagile.validation.inputfield.models de.modagile.validation.dynamiclist.models de.modagile.validation.checkbox.models Manuelle Anpassung im Click Event Handler des Next Buttons notwendig Manuelle Anpassung im Click Event Handler des Add New Buttons notwendig de.modagile.validation.menubar.models Icon in Menubar de.modagile.validation.image.models de.modagile.validation.datepicker.models de.modagile.validation.locationpicker.models de.modagile.validation.composite.models de.modagile.validation.composition.models de.modagile.validation.onetomanyreference.models de.modagile.validation.manytomanyreference.models Nein Teilweise Teilweise Teilweise Windows Phone Datepicker hat integriertes Label. Für das Karten-Control von Windows Phone muss ein Schlüssel vom Microsoft- Kartenservice "Bing" angefordert werden Auf Modellebene richtig generiert. Anpassungen im Code notwendig für Anzeige. Auf Modellebene richtig generiert. Anpassungen im Code notwendig für Anzeige. Auf Modellebene richtig generiert. Anpassungen im Code notwendig für Anzeige. Mit einigen manuellen Anpassungen im Code sind viele der Features funktionsfähig. Wie bei den anderen Plattformen ist auch bei Windows Phone zusätzlicher Code notwendig, damit die dynamische Liste wie gewünscht funktioniert: Abbildung 5 Manueller Code für das Hinzufügen in die dynamische Liste in Windows Phone Der Datepicker hat bei Windows Phone schon ein integriertes Label, daher ist das Verhalten leicht anders, als im Modell vorgegeben. Die Funktionalität ist aber komplett identisch. Der Locationpicker in Windows Phone benötigt einen Zugangsschlüssel zum Microsoft Kartenservice Bing. Dieser ist nicht integriert, deswegen funktioniert die App nicht. ModAgile Mobile L2.2 Validierung der Anforderungen 11

12 Bei den Validierungsmodellen des Domänenmodells findet man auch unter Windows Phone das Verhalten, welches schon bei den anderen beiden Zielplattformen aufgetreten ist. Die Klassen des Domänenmodells werden generiert. Eine visuelle Anzeige fehlt, bzw. muss manuell ergänzt werden. 4 Features mobiler Anwendungen und deren Abdeckung in ModAgile Mobile Mobile Anwendungen verwenden mehrere Features, die plattformübergreifend Anwendung finden. Mit ModAgile Mobile sollen Apps für die gängigsten Plattformen Android, ios und Windows Phone generiert werden können. Um die dafür grundlegenden Features verwenden zu können, müssen diese für die Modellierung der Apps verfügbar sein und nachgelagert richtig generiert werden. Deshalb soll in diesem Kapitel untersucht werden, welche Features grundlegend für die App- Entwicklung sind und in welchem Maß sie in ModAgile Mobile umgesetzt wurden. Die folgenden Elemente bilden die Grundlage von Mobile Anwendungen und ermöglichen es, eine Vielzahl verschiedener Apps zu entwickeln: 1. Screen 2. Label 3. Button (mit Beschriftung) 4. Screen-Flow (Wechsel zwischen mehreren Screens) 5. Events (Click, NotifyChanged) 6. Image 7. Imagebutton 8. Eingabefeld (Inputfield) 9. Dynamische Liste 10. Checkbox 11. Menubar 12. Datepicker 13. LocationPicker 14. Datenbindung a. Ressource: Domänenmodell, einfaches Attribut b. Ressource: Liste von Objekten 15. Slider 16. Notifications Die Umsetzung der Elemente 1 bis 13 wird bereits mit den Validierungsmodellen in Kapitel 2 überprüft. Die Validierungsergebnisse können dort nachgelesen werden. Feature 5 wird dabei implizit überprüft. Events finden unter anderem Verwendung in allen Validierungsmodellen, die einen Button enthalten. Bei der Modellierung kann einem Button ein Event zugewiesen werden, das ausgelöst wird, wenn der Button betätigt wird. Datenbindung (Feature 14) wird ebenfalls implizit geprüft. Ein Binding für ein einfaches Attribut aus dem Domänenmodell wird u.a. in dem Validierungsmodell für das Inputfield verwendet. Die Anbindung einer Liste von Objekten findet in der dynamischen Liste Verwendung. ModAgile Mobile L2.2 Validierung der Anforderungen 12

13 Die beiden Features Slider und Notifications werden im Moment nicht unterstützt. Diese stellen für die Zukunft sinnvolle Erweiterungen dar, bilden aber nicht die Grundlage für die Entwicklung vielseitiger Apps. Die Funktionalität eines Sliders kann zudem auch durch eine Checkbox angeboten werden. In der folgenden Tabelle wird die Abdeckung der Features pro Plattform zusammengefasst. Feature Android ios WP Screen Label Button Screen-Flow Events Image Imagebutton Eingabefeld Dynamische Liste Checkbox Menubar Datepicker Locationpicker Datenbindung Attribut Datenbindung Liste Slider Notification funktionsfähig mit manuellen Anpassungen funktionsfähig nicht funktionsfähig 5 Fazit Die ursprünglichen Ziele des Projektes, allen voran die Anforderung, ein plattformübergreifendes Framework zur Erstellung mobiler Anwendungen zu schaffen, wurden erreicht. Leider konnten nicht für alle unterstützten Plattformen (Android, ios, Windows Phone) alle Features umgesetzt werden. Hier war eine klare Priorisierung nötig (wie es in jedem agilen Projekt der Fall ist bzw. sein sollte). Die noch offenen Punkte bringen keine wesentliche Einschränkung für Entwickler mit sich. Es ist ggf. nur mehr manuelle Implementierungsarbeit zu ModAgile Mobile L2.2 Validierung der Anforderungen 13

14 leisten. Dabei hat sich der hybride Ansatz von ModAgile Mobile, d.h. die inkrementelle Erweiterung der Modelle und der generierten Code-Basis ergänzt mit manuellen Implementierungen (via Hooks) als sehr vielversprechend erwiesen. Das Framework kann leicht um weitere Plattformen ergänzt und die noch fehlenden Features komplettiert werden. ModAgile Mobile L2.2 Validierung der Anforderungen 14