Lieferung 3.2 Erfahrungsbericht M18

Transkript

1 Lieferung 3.2 Erfahrungsbericht M18 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 01IS11012A-C andrena objects AG Jochen Winzen andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Zoya Durdik, Juri Dutt, Dominic Frei, Martin Küster, Johannes Tysiak, Jochen Winzen M Version 1.0 ModAgile Mobile L3.2 Erfahrungsbericht M12 1

2 Inhalt Lieferung 3.2 Erfahrungsbericht M Einleitung Referenzimplementierung MAMEX Referenzimplementierung MAMEX für ios Storyboard Personenwahl / PersonListViewController Personendetails / PersonDisplayViewController Person editieren / PersonEditViewController Freunde auswählen / FriendChooserViewController Adresse auswählen / AddressPickerViewController Weiterentwicklung von MAMEX für Android MAMEX MAMEX MAMEX Referenzumgebung für die Qualitätssicherung Änderungen am Metamodell (Modellevolution) Domänen-Bindings vor Metamodell-Überarbeitung Domänen-Bindings nach Metamodell-Überarbeitung Schlussfolgerung Testen: Unit-Test-DSL und UI-Test-DSL Unit-Test-DSL Transformation von Unit-Tests Stand der Entwicklung ModAgile Mobile L3.2 Erfahrungsbericht M12 2

3 4.1.3 Fazit UI-Test-DSL Entscheidungen Plugins Weiteres Vorgehen Grafische Editoren Entscheidungen Plugins Weiteres Vorgehen Fazit ModAgile Mobile L3.2 Erfahrungsbericht M12 3

4 1 Einleitung Dieses Dokument beschreibt die Erkenntnisse und den aktuellen Stand der Entwicklung im ModAgile Mobile Projekt. Es fokussiert sich zunächst auf den Entwicklungsstand der Referenzimplementierung MAMEX (ModAgile Mobile Example). Im Berichtszeitraum fand die Weiterentwicklung der Referenzimplementierung für Android statt. Hierbei stand unter anderem die Anpassung der Anwendung auf Tablet Devices sowie die Nutzung der von Google seit Android 4.0 ICS (Ice Cream Sandwich) aktualisierten Design & Development Guidelines. Zusätzlich fand die Einbindung weiterer Android-Systemfunktionalitäten statt. Zusätzlich zur Weiterentwicklung der Android-Impementierung wurde eine funktionsgleiche ios-version der Referenzanwendung MAMEX entwickelt. Neben der Weiterentwicklung der Referenzimplementierung für Android und ios berichtet dieses Dokument von der Weiterentwicklung des zentralen Metamodells der ModAgile Modellierungskette. Das Metamodell definiert eine abstrakte Sprache zur plattformunabhängigen Beschreibung von mobilen Anwendungen. Es dient als die zentrale Quelle für die Generierung von plattformspezifischen Anwendungscode unter Verwendung von plattformspezifischen Code- Templates. Ein weiterer Fokus dieses Dokuments stellt der Bericht des aktuellen Entwicklungsstands im Bereich der Qualitätssicherung dar. Zwei zentrale Elemente sind dabei die domänenspezifischen Sprachen (Domain Specific Language DSL) für Unit-Tests und Oberflächen-Tests (UI-Tests) sowie die dafür erstellten textuellen Modelleditoren. Zuletzt wird der aktuelle Stand der Entwicklung der graphischen Modelleditoren präsentiert. Die graphischen Modelleditoren ermöglichen dem Nutzer die Bearbeitung von Modellteilen, die sich insbesondere für eine graphische Darstellung eignen. 2 Referenzimplementierung MAMEX 2.1 Referenzimplementierung MAMEX für ios Im aktuellen Berichtszeitraum wurde neben der Android-Version von MAMEX zusätzlich eine ios-version entwickelt. Es entstand in diesem Schritt eine funktional identische App für das iphone. Als minimales Deployment-Target wird derzeit ios 5.0 verwendet, so dass aus einer großen Menge ios-framework gegriffen werden kann, um alle notwendigen Features zu entwickeln. Im Folgenden soll eine Übersicht über diese erste ios-version gegeben und zentrale Elemente, die bei der Entwicklung immer wieder zum Einsatz kommen, aufgezeigt werden. ModAgile Mobile L3.2 Erfahrungsbericht M12 4

5 2.1.1 Storyboard Abbildung 1: Storyboard-Feature in ios 5.0 Zur Festlegung des Screenflows wird ein Storyboard genutzt. Dieses Feature wurde mit ios 5.0 eingeführt und ermöglicht, die Übergänge zwischen Screens (und View Controllern) zu erstellen und zu parameterisieren, etwa durch die Angabe der Art des Screenwechsels. Die Controller und ihre Views, die hier im Detail auftreten, werden in den folgenden Kapiteln besprochen Personenwahl / PersonListViewController Der Startscreen der ios-app ist, wie auch bei der Android-Version, die Übersicht der Personen, der PersonListViewController. Hierfür wurde ein UITableViewController verwendet, eines der am häufigsten verwendeten Elemente in ios. Die Gestaltungsmöglichkeiten sind sehr vielfältig. Beispielsweise können sowohl prototypische Zellen, als auch statische Zellen eingesetzt werden, um den View optimal den Anforderungen anpassen zu können. Wie bei Android, werden hier Namen und Altersangaben angezeigt beim Anklicken die entsprechenden Details bereit gestellt. Das Hinzufügen von neuen Personen und die manuelle Aktualisierung mit der Datenbank finden ebenfalls von hier statt und werden durch die Buttons links und rechts oben gestartet. Der Navigation liegt ein UINavigationController zu Grunde. Für die Kommunikation der Datenbank (Core Data) mit dem Backend, wird eine REST-Schnittstelle verwendet, die Daten als JSON empfängt und versendet. ModAgile Mobile L3.2 Erfahrungsbericht M12 5

6 Abbildung 2: Startbildschirm der MAMEX-Version für ios Personendetails / PersonDisplayViewController Nach der Auswahl einer Person gelangt man auf den PersonDisplayViewController, der lediglich ein Label enthält, in dem Name und Alter wieder verwendet werden. Von hier aus ist auch ein Wechsel in den Edit-Modus für eine Person möglich. Abbildung 3: Detailansicht einer Person in MAMEX Person editieren / PersonEditViewController Den zentrale View, welcher auch die meiste Funktionalität enthält, ist der PersonEditViewController, der dem Editieren der Person dient oder auch (mit unausgefüllten Feldern) genutzt wird, um eine neue Person anzulegen. ModAgile Mobile L3.2 Erfahrungsbericht M12 6

7 Auch hier wird wieder ein UITableViewController als zentrales Element genutzt, da alle Daten in Form einer Tabelle dargestellt sind. Verknüpfung mit der Kontakte-App Apple stellt mit AddressBook und AddressBookUI zwei Frameworks bereit, mit deren Hilfe es recht einfach möglich ist, Kontakte aus dem Adressbuch auszuwählen und zu laden, aber auch Kontakte aus MAMEX im Adressuch abzulegen. Hinzufügen von Audio und Video Abbildung 4: PersonEditViewController in MAMEX Einer Person kann außerdem eine Audioaufnahme und eine Videoaufnahme zugeordnet werden. Hier kommt vor allem das MediaPlayer-Framework zum Einsatz, was die benötigten Klassen wie AudioRecorder, AudioPlayer und AudioSession bereit stellt. Abbildung 5: Multimediaanbindung in MAMEX für ios ModAgile Mobile L3.2 Erfahrungsbericht M12 7

8 2.1.5 Freunde auswählen / FriendChooserViewController Auch für die Auswahl der Freunde wird ein UITableViewController eingesetzt: Abbildung 6: Auswahl von Freunden in MAMEX für ios Adresse auswählen / AddressPickerViewController Als letzter View soll der AddressPickerViewControllerView vorgestellt werden. Hierüber kann die Adresse eingegeben oder auf der Karte ausgewählt werden. Im Gegensatz zu den sonst verwendeten Listen, gibt es hier UILabels, UUTextFields und einen UIMapView zu sehen. Außerdem werden die Daten bei der Rückgabe an den CLGeocoder übergeben, der dann die Berechnung von Länge und Breite übernimmt. Abbildung 7: Adressbearbeitung in MAMEX für ios ModAgile Mobile L3.2 Erfahrungsbericht M12 8

9 2.2 Weiterentwicklung von MAMEX für Android Neben der Entwicklung einer ios-variante des MAMEX-Beispiels fand im Berichtszeitraum die Weiterentwicklung der MAMEX-Implementierung für Android statt. Im Fokus standen dabei einerseits notwendige Anpassungen, die sich durch die Weiterentwicklung des Android- Frameworks (von Version 2.x auf Version 4.x) ergaben. Daneben wurden im Rahmen der iterativen Weiterentwicklung der Beispielapplikation neue, für mobile Anwendungen typische, Architektur- und Designkonstrukte aufgenommen, die nun im Folgenden kurz angerissen werden. Die Weiterentwicklung der MAMEX-Beispielanwendung für Android fand in mehreren Zyklen statt, aus denen die MAMEX-Versionen MAMEX02 bis MAMEX04 entstanden MAMEX 02 Um Applikationen auf Tablets optimal gestalten zu können, kam ab Android 3.x die Komponente Fragment dazu. Fragments stellen komponierte und komponierbare Bildschirmelemente dar, die einzeln oder zusammengesetzt einen Screen darstellen können. Fragments werden von einer Activity gesteuert. Eine Activity kann somit aus einer oder mehreren Fragments bestehen. Das MAMEX-Beispiel enthält Fragments als Designkonstrukt ab MAMEX02. Abbildung 8 zeigt den Hauptbildschirm der MAMEX-Anwendung, wobei die verwendeten Fragmente rot umrandet sind. Abbildung 8: Fragmente in MAMEX Mit Android 3.x wurde daneben die ActionBar als Navigationselement eingeführt. Abbildung 9 zeigt die MAMEX-Smartphone-Variante. Die im UI enthaltene ActionBar ist rot umrandet. ModAgile Mobile L3.2 Erfahrungsbericht M12 9

10 Abbildung 9: ActionBar ab Android 3.0 Um Anwendungen trotz Verwendung der neueren Android-Features (Fragments, ActionBar) auch auf älteren Android-Varianten betreiben zu können, wurde die Library SherlockActionBar 1 eingesetzt. Damit bleibt die MAMEX-Anwendung rückwärtskompatibel für Android 2.x MAMEX03 Eine der größten Neuerungen für MAMEX03 war die Erweiterung um Tablet-Funktionalitäten. Um dieselbe App sowohl auf Smartphones als auch optimiert für Tablet nutzen zu können, wurde eine Weiche eingebaut, die überprüft ob die App auf einem Tablet oder Smartphone ausgeführt wird. Für die jeweilige Umgebung wird dabei das jeweils optimale User Interface angezeigt (siehe auch Abbildung 10). 1 ModAgile Mobile L3.2 Erfahrungsbericht M12 10

11 Abbildung 10: Hauptbildschirm von MAMEX03 auf Smartphone (links) und Tablet (rechts) Eine weitere Optimierung in MAMEX03 war die Verwendung von asynchronen Tasks. Diese werden nicht im MainThread ausgeführt. Damit wird verhindert, dass das UI (User Interface) durch Hintergrundoperationen einfriert. So werden alle DB-Abfragen in der App als AsyncTask ausgeführt. Da dieselben DB-Abfragen auch für die Synchronisation (BackgroundService) verwendet werden, müssen diese auch in einer synchronen Variante vorhanden sein, da in einem BackgroundService kein AsyncTask ausgeführt werden kann MAMEX04 In MAMEX04 stand die Einbindung mehrerer häufig verwendeter Systemfeatures im Fokus. So wurde eine Anbindung an die Kontakt- und Kalender-Anwendungen realisiert, sowie die Verwendung von Multimedia-Features exemplarisch umgesetzt. Durch einen Intent wird die native Kontakte App (siehe Abbildung 11) geöffnet und es kann dann einen Kontakt ausgewählt werden. Dieser kann dann wieder in der MAMEX App verarbeitet werden. Für die Anbindung an die Kalender-Funktionalität werden Geburtstage von in MAMEX gepflegten Personen im nativen Kalender gespeichert. ModAgile Mobile L3.2 Erfahrungsbericht M12 11

12 Abbildung 11: Verwendung der Kontakt-Anwendung Um die Referenzimplementierung um Multimedia-Funktionalitäten zu erweitern, kann zu einer Person eine Audio und Video Aufnahme hinzugefügt werden. Abbildung 12 zeigt die dafür bereitgestellten Buttons. Abbildung 12: Audio- und Video-Memo-Funktionalität in MAMEX04 ModAgile Mobile L3.2 Erfahrungsbericht M12 12

13 2.2.4 Referenzumgebung für die Qualitätssicherung Um die Referenzimplementierung für Android durch geeignete Qualitätssicherungswerkzeuge zu ergänzen, wurden State of the Art Werkzeuge für die kontinuierliche Integration (Jenkins) und die Code Analyse (Sonar) in die Werkzeugkette integriert. Bei Sonar 2 handelt es sich um eine Platform für Statische Code Analyse, um die Qualität des Quellcodes zu messen. Sonar analysiert den Sourcecode hinsichtlich folgender Qualitätsbereiche: Softwarearchitektur & Softwaredesign Doppelter Code Modultests Komplexität Potentielle Fehler Kodierrichtlinien Kommentare Jenkins CI 3 ist ein webbasiertes System zur kontinuierlichen Integration. Für MAMEX wurde ein Profil angelegt welches auf einem zentralen Server die Anwendung baut und anschließend per verteilt. 3 Änderungen am Metamodell (Modellevolution) Während der Erstellung des Metamodells für mobile Anwendungen haben sich für das ModagileMobile-Konsortium einige wichtige Richtungsentscheidungen ergeben. Das agile Vorgehen im Projekt führte zu Beginn zu einer initialen Version des App-Metamodells, das an einigen Stellen noch überarbeitet werden musste. Für die erste Generierung von Code war es zwar geeignet, hatte aber noch Elemente, die entweder eindeutiger (für den Modellierer und den Ersteller der Templates) oder einfacher oder ausdrucksstärker werden mussten. Besonders am Beispiel des Pakets domain, das die Abbildung von Domänenelementen (wie etwa Kunde, Konto, etc. und deren Beziehungen) und den grafischen Elementen der Anwendung (UI-Elemente) herstellt, wird dies deutlich. Im Folgenden gehen wir auf die Evolution des Metamodells im Bereich dieses Pakets ein. 3.1 Domänen-Bindings vor Metamodell-Überarbeitung Zunächst waren alle Verbindungen zwischen dem Modell der Domäne, das wir durch eine UMLartigen Modellierung realisiert haben, und den Elementen der grafischen Oberfläche explizit modelliert. Das spiegelt sich in den MM-Elementen DomainEntity und DomainAdapter wider. Es musste aber für jede Entität des Domänenmodells (z.b. Kunde ) auch eine DomainEntity angelegt werden. Die Information war unnötigerweise doppelt vorhanden (vgl. Abbildung 13) ModAgile Mobile L3.2 Erfahrungsbericht M12 13

14 Abbildung 13 Metamodell "Domäne" im App-MM vor Evolution Zwar war die Erstellung der Templates aus diesem Modell recht einfach. Jedoch waren Modelle immer in Gefahr, inkonsistente Informationen zu enthalten, wenn entweder das Domänenmodell oder die DomainEntity-Elemente geändert wurden. 3.2 Domänen-Bindings nach Metamodell-Überarbeitung Im Laufe der Verfeinerung des gesamten Metamodells kam es auch zu einer deutlichen Überarbeitung der Domänenkonstrukte. Die direkten Verbindungen zwischen UI-Elementen (wie Listen, Labels, Buttons etc.) und den Domänenentitäten (aus dem Paket ecore ) wurden eingeführt und das Modell um einiges ausdrucksstärker, aber auch einfacher (vgl. Abbildung 14). ModAgile Mobile L3.2 Erfahrungsbericht M12 14

15 Abbildung 14 Metamodell "Domäne" im App-MM nach Evolution Durch die Einführung geeigneter Konstrukte (Unterklassen von PrimitiveBinding) wurde Typsicherheit erreicht. Außerdem kamen notwendige Binding-Typen für die Auswahl von Elementen (SelectionBinding) hinzu, und die Bindung an Listen-Elemente wurde eindeutiger (ListBinding). 3.3 Schlussfolgerung Die besonders kritischen Elemente des App-Metamodells wurden früh fixiert, Elemente, die spezifische Eigenschaften wie die Datenpersistenz (Bindung von Domänenentitäten) angehen, konnten später nachgezogen werden. Insgesamt zeigt die Evolution des Metamodells, dass das agile Vorgehen große Vorteile gebracht hat: Die frühen Iterationen ließen zu, dass schnell mit der Erstellung von Templates für die Generierung von plattformspezifischem Code begonnen werden konnte. Außerdem konnten andere Metamodelle (wie das für Testen auf Unit- oder UI-Ebene) sehr früh auf dieses Modell Bezug nehmen. Dies ermöglichte früh arbeitsteiliges Arbeiten zwischen den Partnern. 4 Testen: Unit-Test-DSL und UI-Test-DSL 4.1 Unit-Test-DSL Unit-Tests sind in der Software-Entwicklung das Standardmittel, um die korrekte Funktion von einzelnen Softwarekomponenten in der Regel einzelne Klassen und Methoden isoliert vom Rest des Systems sicherzustellen. Das Grundverfahren beim Unit-Testen ist das Aufrufen der ModAgile Mobile L3.2 Erfahrungsbericht M12 15

16 zu testenden Methoden mit vom Entwickler definierten Parametern. Nach dem Aufruf wird das Ergebnis mit dem erwarteten Ergebnis verglichen. Kommt es hierbei zu Abweichungen, wurde ein Programmierfehler entdeckt. Bei der gewöhnlichen plattformspezifischen Entwicklung werden Unit-Tests in der Regel technisch durch ein Stück Software realisiert, welche in der gleichen Programmiersprache wie der zu testende Programmcode geschrieben wurde. Unterstützt wird das Schreiben von Programm-Code durch plattformspezifische Test-Frameworks. Diese erleichtern das Initialisieren von Testdaten sowie das Organisieren und strukturieren von Tests sowie das Erzeugen von Übersichtlichen Ausgaben von Test-Ergebnissen. Im Modagile-Entwicklungsprozess ist vorgesehen, dass bestimmte Programmteile wie die anwendungsspezifische Logik vom Entwickler selbst für alle Zielplattformen entwickelt werden soll. Beim Entwurf des Domänenmodells hat der Entwickler die Möglichkeit Methoden zu deklarieren, welche die Schnittstelle zu anwendungsspezifischer Logik darstellen. Während des Transfomationsprozesses werden aus dem plattformunabhängigen Domänenmodell plattformspezifische Generate erzeugt. Im Generat werden für alle deklarierten Methoden leere Methodenrümpfe erzeugt, welche vom Entwickler mit passendem Programmcode gefüllt werden. Es ist wünschenswert, die Qualität dieses Codes durch Unit-Tests sicherzustellen. Eine Möglichkeit hierfür wäre, für jede Implementierung einen Unit-Test von Hand zu schreiben und dabei die etablierten Frameworks der Zielplattformen zu definieren. Der hier entstehende Nachteil ist, dass die gleichen Testszenarien von Hand für jede gewünschte Zielplattform zu entwickeln. Das bringt einerseits zusätzlichen Aufwand bei der Entwicklung und birgt andererseits auch noch das Risiko, dass sich die Testszenarien unterscheiden und somit ein gleiches Verhalten der Anwendungslogik auf verschiedenen Plattformen nicht mehr sichergestellt ist. Für Modagile wurde eine Unit-Test-DSL entwickelt, welche das plattformunabhängige Entwickeln von Tests ermöglicht. Die Test-DSL ist eine Sprache, welche einen speziell für Unit- Tests zugeschnittenen Befehlssatz bereitstellt. Dabei werden folgende Aspekte von Unit-Tests berücksichtigt: Strukturierung von Testdaten: Eine Test-Datei kann eine beliebige Menge von Tests enthalten. Dabei ist jeder Test durch einen Block mit eindeutigem Namen definiert. Initialisieren von Daten: Es können Instanzen von Domänenobjekten erzeugt und initialisiert werden. Methodenaufrufe: Die zu testenden Methoden können aufgerufen werden. Überprüfung von Ergebnissen: Assertion-Ausdrücke ermöglichen das spezifizieren erwarteter Daten Transformation von Unit-Tests Die mit Hilfe der Test-DSL spezifizierten Unit-Tests können durch Transformation in plattformspezifischen Test-Code übersetzt werden. Der generierte Test-Code basiert auf ModAgile Mobile L3.2 Erfahrungsbericht M12 16

17 gängigen plattformspezifischen Test-Frameworks(zum Beispiel JUnit für Java). So können für das Ausführen der Tests gewohnte Werkzeuge verwendet werden(zum Beispiel der integrierte JUnit-Runner der Eclipse-IDE für Java). Bei der Transformation wird die Struktur der Tests also die Namen von Dateien und Benennung einzelner Tests beibehalten. So können die komfortablen Ausgaben der plattformspezifischen Test-Werkzeuge problemlos genutzt und vom Entwickler interpretiert werden Stand der Entwicklung Es wurde eine Modagile-spezifische Test-DSL entwickelt, welche alle wesentlichen Aspekte eines Unit-Tests ausdrücken kann. Dazu wurde ein XTEXT-basierter Parser entwickelt, welcher die entwickelten Test-Dateien verarbeiten kann. Darauf aufbauend wurde ein Transformationswerkzeug entwickelt, welcher auf dem JUnit-Framework basierende Tests erzeugen kann Fazit Unit-Tests sind ein wichtiges Mittel, um die Qualität von Programmcode sicherzustellen. Dies gilt auch für die modellgetriebene Multi-Plattform-Entwicklung. Durch die Verwendung einer plattformunabhängigen Unit-Test-DSL wird die Effizienz bei der Entwickelung und Wartung von Tests reduziert. 4.2 UI-Test-DSL UI-Tests werden unter dem Aspekt der Qualitätssicherung entwickelt. Dies sind Akzeptanztests, die im Rahmen dieses Projekts auf 2 Ebenen laufen: Sie finden ihren Einsatz sowohl auf der plattformunabhängigen Modellebene als auch auf der plattformspezifischen Codeebene. Zunächst wird für das vorliegende App-Modell ein plattformunabhängiges UI-Test-Modell modelliert, wofür eigens in Xtext eine UI-Test-DSL entwickelt wurde. Bereits hier lassen sich Mängel des App-Modells feststellen: Sollte beispielsweise ein Inputfeld fehlen, das von dem UI- Test-Modell benötigt wird, wird dies hier aufgedeckt. Anschließend wird aus dem Test-Modell mit Hilfe der in Xtend geschriebenen Templates für jede Plattform Quellcode generiert. Auf diese Weise werden die plattformspezifischen Generate getestet. Das folgende Bild soll diesen Sachverhalt veranschaulichen. ModAgile Mobile L3.2 Erfahrungsbericht M12 17

18 4.2.1 Entscheidungen Das UI-Test-Metamodell steht in direkte Abhängigkeit zum App-Metamodell - und zwar insbesondere zu dessen UI-Part. Wie bereits schon das App-Metamodell wurde auch das UI- Test-Metamodell mit EMF (Eclipse Modeling Framework) erstellt. Dieses referenziert auf die UI- Elemente ( Button, Label, Datepicker, ) des Erstgenannten. Da das UI-Test-Metamodell in EMF vorlag, hat es sich angeboten, Xtext zur Erstellung der UI-Test-DSL (Domain Specific Language) zu verwenden. Dieses referenziert nämlich auf die im UI-Test-Metamodell vorahanden Klassen und arbeitet dadurch Hand in Hand mit EMF. Die Konkrete Syntax dieser UI-Test-DSL ist im Bild, welches den UI-Test zum Erstellen einer Person in der Beispiel- Applikation MAMEX illustriert, auf der plattformunabhängigen Seite zu sehen. Um aus dem Modell plattformspezifischen Code zu generieren, wurden anschließend mit Xtend Templates geschrieben. Es soll für jede im Projekt vorhandene Plattform jeweils eine Datei mit dem zugehörigen UI-Testcode erstellt werden. Im Moment werden die Tests für die Plattformen Android und ios generiert, wobei die Android-Tests in *.java Dateien und die ios-test in *.js Dateien ausgegeben werden. Auch diese sind im Bild dargestellt Plugins de.modagile.test.uilanguage de.modagile.test.uilanguage.ui de.modagile.test.uimetamodel de.modagile.test.uimetamodel.edit de.modagile.test.uimetamodel.editor ModAgile Mobile L3.2 Erfahrungsbericht M12 18

19 4.2.3 Weiteres Vorgehen In den kommenden Wochen soll in einem zweiten Iterationsschritt das UI-Test-Metamodell feiner strukturiert und sowohl die Xtext-Grammatik als auch die Xtend-Templates um weitere Funktionalitäten, die in der ersten Basis-Version noch nicht vorhanden sind, erweitert werden. 5 Grafische Editoren Die graphischen Editoren wurden zur Unterstützung der Mobile-App-Erstellung entwickelt, insbesondere für die Steigerung der Effizienz und des Komforts der App-Modellierung. Die Editoren wurden im M16 fertiggestellt und in der Lieferung 6.2 Modellierungsumgebung: Graphische Editoren für alle identifizierten Sichten beschrieben. Die Editoren erfassen zwei Sichten auf das Modell - die Architektur- und Ablaufansichten, und bestehen aus drei Editoren: Einem Baum-Editor (auf Basis des Eclipse Modeling Frameworks, EMF), einem Modell-Editor für Story Board (GMF), und einem Modell-Editor für Composite Display Elements. Die aktuelle Ansicht der Editoren kann aus der Abbildung 15 entnommen werden. Abbildung 15 Die graphische Editoren, Modellierung der MAMEX Anwendung Entscheidungen Die GMF-basierten graphischen Editoren wurden für das UI-Paket des Meta-Modells implementiert, weil die UI-Elemente und deren Modellierung am ehesten mit Hilfe von GMF Editoren unterstützt werden können. Dagegen kann die Modellierung der anderen Elemente in einem GMF Editor, wie z.b. Events oder Adaptoren, sogar mehr Aufwand erfordern, da die Aktionen eher kleinschrittig sind und eine Baumansicht (EMF Editor) einen aussagekräftigeren Überblick bietet. Für das UI-Paket des Meta-Modells wurden zwei Belange identifiziert: Story Board und CompositeTypeRepository. Deswegen wurden die Editoren für das Story Board und für das Composite unabhängig voneinander implementiert, obwohl ein Überlapp an Funktionalität ModAgile Mobile L3.2 Erfahrungsbericht M12 19

20 teilweise festgestellt werden kann. Diese Entscheidung basiert nicht nur auf der konzeptionellen Ebene, sondern auch auf der technologischen Einschränkung von GMF, welches keine dynamischen Kopien oder Verlinkungen ermöglicht, und somit die Wiederverwendung von Teilen der Editoren nicht unterstürzt. Weiterhin kann das automatische Layout der graphischen Elemente in jedem Screen nicht automatisiert hergestellt werden, daher muss die Positionierung manuell angepasst werden. Das liegt daran, dass das graphische Design allgemein nicht automatisierbar ist und menschliche Hilfe und Fähigkeiten erforderlich sind. Die Editoren unterstützen daher nur ein initiales Layout, das dann, je nach gewünschtem Design und Grad der Erkennbarkeit, angepasst werden muss Plugins Im Folgenden sind die Plugins aufgeführt, die als Teile des GMF-basierten Editors installiert werden müssen, um das Feature graphische Editoren ausführen zu können. de.modagile.metamodel.app de.modagile.metamodel.app.compositerepository de.modagile.metamodel.app.diagram de.modagile.metamodel.app.edit de.modagile.metamodel.app.editor de.modagile.metamodel.app.gmfeditor Weiteres Vorgehen Die Editoren wurden zwar bereits in einer ersten Version im M16 fertiggestellt, jedoch brauchen sie permanente Wartung und Evolution, die aus der Evolution des App-Metamodells folgt. Die im Kapitel 3 beschrieben Änderungen an Meta-Modell werden demnächst auf der Editoren-Ebene umgesetzt. Die vorgesehenen Änderungen umfassen unter anderem die folgenden identifizierten Punkte: Löschung des Typs DomainEntity. Ersetzung durch eine Referenz auf EClass (Die Auswirkung auf der Editoren im Moment unklar) Einführung eines Startelementes für das CompositeDisplay-FragmentNavigation Element Einführung von CompositeDisplay-Elementen in das DynamicList Element Anzeige von Stereotypen und Typ-Informationen bei Composite Elementen Einführung des EditHelpers für das CompositeDisplay Element Anzeige des CompositeDisplay Elements im Screen-Element mit der gleiche Große wie im MenuBar-Element Implementierung des FragmentNavigation Elements ohne einen Pfeil Graphische Anpassung des Input-Elements an das Programmier-Inputfeld (Farbe: Grau, Rahmen: Dick) Auch die zukünftigen Änderungen an dem Meta-Modell, die durch das iterative Projektvorgehen ausgelöst werden, werden die Anpassung der Editoren erfordern. ModAgile Mobile L3.2 Erfahrungsbericht M12 20

21 6 Fazit Das iterative Vorgehen des ModAgile Mobile Projekts hat sich in den bisherigen Entwicklungszyklen bewährt, um geeignet auf die fortwährenden Marktentwicklungen zu reagieren. Aktuelle Neuerungen während der Projektlaufzeit werden kontinuierlich beobachtet und falls aus Projektsicht relevant in die aktuelle Projektentwicklung aufgenommen. Als Beispiele hierzu lassen sich die neuen Android-Versionen (Ice Cream Sandwich und Jelly Bean) sowie neue ios- und Windows Versionen (Windows Phone 7 und Windows Phone 8) anführen, sowie die jeweils damit verbundenen Design Guidelines und typische Architekturkonstrukte. Neuerungen in plattformspezifischen Frameworks (Android, ios, Windows) wirken sich in einer fortlaufenden Evolution nicht nur der jeweiligen Referenzimplementierungen aus. Diese Neuerungen bewirken gleichzeitig Anpassungen von Code-Templates für Applikations- und Test-Code sowie ggf. Erweiterungen des Metamodells und der jeweiligen Modelleditoren. Neben der Weiterentwicklung der ModAgile Toolchain, die sich unter anderem aus dem Metamodell, den textuellen und graphischen Editoren sowie den Codegenerierungs-Templates zusammensetzt, steht in den nächsten Projektphasen der Ausbau der Referenzimplementierung für Windows an sowie die Erweiterung der ios-implementierung auf Tablet-Umgebungen. Weiterhin wird daneben die schnelle und einfache Anpassbarkeit an aktuelle Marktentwicklungen eine wichtige nicht-funktionale Anforderung an das Modagile Mobile Projekt bleiben. ModAgile Mobile L3.2 Erfahrungsbericht M12 21