Final Thesis. Entwicklung einer mobilen Applikation zur Erfassung von benachbarten Objekten

Transkript

1 Hochschule Bonn-Rhein-Sieg University of Applied Science Fachbereich Informatik Department of Computer Science Final Thesis im Bachelor Studiengang Business Information Systems Entwicklung einer mobilen Applikation zur Erfassung von benachbarten Objekten von Felix Mannhardt Erstbetreuer: Prof. Dr. Andreas Hense Zweitbetreuer: Prof. Dr. Martin E. Müller Eingereicht am: 31. August 2010

2 Inhaltsverzeichnis 1. Einleitung Ausgangssituation Zielsetzung Vorgehensweise Grundlagen Positionsbestimmung Global Positioning System Differential GPS Benachbarte Objekte Relative Lage kombiniert mit GPS Das Web-Framework Grails Motivation Überblick Ausgewählte Funktionen Die mobile Plattform Android Motivation Überblick Ausgewählte Funktionen Software Engineering Anforderungsanalyse Test-Driven-Development und Refactoring II

3 Inhaltsverzeichnis 3. Entwicklung Anforderungsanalyse Anforderungen des Kunden Mockups zur Kommunikation Entwicklung der Server-Anwendung Entwurf des Datenmodells Implementierung des Web-Service Entwicklung der mobilen Applikation Zugriff auf den Web-Service Synchronisation mit einem Content Provider Auto-Vervollständigung für Eingabefelder Positionsbestimmung mit GPS und Kompass Zusammenfassung Literatur 47 A. Anhang 50 A.1. Anforderungsanalyse ANSI/IEEE Std III

4 Abbildungsverzeichnis 1. Anwendungsfälle von MAEBO Nachbarschaftsbeziehungen repräsentiert als Graph System Architektur von Android Prototype SRS outline Mockup eines Bildschirms von MAEBO Anforderung in Steckbrief-Form Mockup: Erfassen der Daten zum Grabstein (REQ-003) Klassendiagramm von MAEBO Per Scaffolding erstellte Web-Oberfläche Foto aufnehmen (REQ-001) Sequenzdiagramm: Erzeugen eines Grabsteins über den Web-Service Service API für eine REST Client Applikation in Android Nachschlagen von bereits erfassten Materialien (REQ-004) Auto-Vervollständigung in Aktion Erfassen der relativen Position des Grabsteins (REQ-009) Orientierung in einem 9-Felder-Raster erfassen Positionsbestimmung mit GPS Positionsbestimmung mit Verbesserung durch den Nutzer Klassendiagramm UI der Positionsbestimmung Aktivitätsdiagramm LocationFrameLayout IV

5 Quelltextverzeichnis 1. Definition einer Domänenklasse in Hibternate Definition einer Domänenklasse in Grails Konvertierung von XML in beide Richtungen Schnittstelle ContentResolver Listing 6-3. Using shouldfail Beispiel für einen Web-Test Test eines Web-Service mit Canoo WebTest RESTful Url Mapping mit XML Parsing Konfiguration burning-image Plugin mit domänenspezifischer Sprache Unit Test der Deserialisierung Verkürzte Methode aus der Klasse SyncService Aufbau des Vervollständigungs-Index Mathematische Grundlagen der Positionsbestimmung Rotation um Himmelsrichtung V

6 Abkürzungsverzeichnis AGPS Assisted GPS. CRUD Create, Read, Update, Delete. DAO Data Access Object. DGPS Differential Global Position System. GORM Grails Object Relational Mapping. HSPA High Speed Packet Access. HTTP Hyper Text Transfer Protocol. IEEE Institute of Electrical and Electronics Engineers. JSON JavaScript Object Notation. LBS LTE Location Based Services. Long Term Evolution. MAEBO Mobile Applikation (zur) Erfassung benachbarter Objekte. VI

7 Abkürzungsverzeichnis REST Representational State Transfer. SDK Software Development Kit. TDD Test Driven Development. UI User Interface. XML Extensible Markup Language. VII

8 Glossar Canoo WebTest Ein Framework für das funktionale Testen einer Web-Oberfläche durch einen simulierten Browser 1. Closure Ein Stück Quelltext, mit keinem oder mehreren Parametern, der an einer beliebigen anderen Stelle im Programm ausgeführt werden kann. Entwurfsmuster Ein Entwurfsmuster benennt, abstrahiert und identifiziert die relevanten Aspekte einer allgemeinen Entwurfsstruktur. Diese Aspekte beschreiben, warum das Muster für die Entwicklung eines wiederverwendbaren objektorientierten Entwurfs nützlich ist 2. Evolvability Bezeichnet die Weiterentwickelbarkeit einer Software 3. Hibernate Ein Objekt-relationaler Mapper für Java 4. Middleware Im Prinzip versteht man darunter [Middleware] systemnahe Software, die als zusätzliche Schicht zwischen Betriebssystem und Anwendungssoftware gelegt wird 5. Mockups Ein Mockup ist ein schablonenhafter, nicht funktioneller Prototyp der grafischen Benutzeroberfläche einer Software Gamma, Helm und Johnson 2009, S Vgl. Riebisch und Bode Stahlknecht und Hasenkamp 2005, S. 75. VIII

9 Glossar MVC MVC ist die Abkürzung für Model, View und Controller und beschreibt ein Architekturmuster für die Strukturierung einer Software in drei Komponenten. objekt-relationale Mapper ORM ist die Abkürzung für Objekt-relationaler Mapper und beschreibt eine Software die Objekte einer Programmiersprache auf eine relationale Datenbank abbildet. optimistic locking Nutzung einer Spalte Version deren Wert, zum Erkennen von konkurrierenden Änderungen, bei jeder Änderung erhöht wird. Refactoring Verbesserung der internen Struktur bzw. Qualität einer Software, ohne das sich das äußere Verhalten ändert 6. Ruby on Rails Ein Web-Framework für die dynamische Programmiersprache Ruby 7. Scaffolding Scaffolding beschreibt, in der Software-Entwicklung, den Prozess aus einer Vorlage und einem Datenmodell automatisch Quelltext für bestimmte Grundfunktionen zu generieren.. WGS-84 Beim GPS verwendetes geodätisches Datum, also Kombination aus Referenzellipsoid und Fundamentalpunkt, das für die Berechnung der Koordinaten verwendet wird 8. Widget Ein Widget bezeichnet eine Komponente die in der Benutzeroberfläche einer Anwendung sichtbar ist und eine Funktionalität bietet. XPath XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer Vgl. Fowler und Beck 1999, S. xvi Vgl. Ramm und Topf 2008, S W3C 1999, Vgl. IX

10 1. Einleitung 1.1. Ausgangssituation Die Leistungsfähigkeit und Verfügbarkeit von mobilen Endgeräten mit einer schnellen Verbindung in das Internet, wozu insbesondere Smartphones zählen, hat sich in den letzten Jahren erheblich verbessert. Die verfügbare Bandbreite wächst mit neuen Übertragungstechniken sowie dem Ausbau der Mobilfunknetze durch die Netzbetreiber. Schon jetzt bietet der derzeit genutzte Standard HSPA (High Speed Packet Access) eine mit einem üblichen, privaten DSL Anschluss vergleichbare Bandbreite. 1 Durch den Nachfolgestandard LTE (Long Term Evolution) werden Geschwindigkeiten über 100 Mbit/s Downstream und 50 Mbit/s Upstream möglich. Die positive Entwicklung der verfügbaren Bandbreite und der GPS-Empfänger, der mittlerweile in vielen Smartphones vorhanden ist, bilden die Grundlage für standortbezogene Dienstleistungen, sogenannte LBS (Location Based Services), 2 die mit Informationen und Medien aus dem Internet angereichert werden. Durch offene Schnittstellen in den Betriebssystemen vieler Smartphones können diese Möglichkeiten nicht mehr nur vom jeweiligen Hersteller, sondern über nachladbare Applikationen von Drittanbietern oder dem Endnutzer selbst für vielfältige Zwecke genutzt werden. Durch die beschriebene Entwicklung und die kompakte Bauart eignen sich Smartphones für die Erfassung von Objekten aller Art in einem mobilen Umfeld. Der ständige Zugriff auf das Internet ermöglicht die simultane Arbeit an einer integrierten Datenbasis und bietet die Verfügbarkeit von zusätzlicher Information, die durch Nutzung der Standortinformation an den Kontext in dem sich der Benutzer befindet, angepasst werden kann. 1 Vgl. Alby 2008, S Vgl. Alby 2008, S. 47 ff. 1

11 1. Einleitung Eine spezielle Aufgabe in der Geschichtswissenschaft, die bisher nicht durch eine mobile Applikation unterstützt wird, ist die Erfassung historisch bedeutsamer Grabsteine auf Friedhöfen im Allgemeinen sowie auf jüdischen Friedhöfen im Besonderen. Die Inschriften auf alten Grabsteinen werden durch Witterungseinflüsse sowie mangelnde Denkmalpflege unlesbar und verlieren ihren geschichtlichen Wert. Insbesondere jüdische Friedhöfe haben einen hohen historischen Wert, da sie aufgrund einer religiösen Vorschrift, die besagt, dass das Grab für die Ewigkeit in Besitz des Gestorbenen bleibt, üblicherweise sehr alte Inschriften enthalten. Auf dieses Szenario passen die, im vorherigen Absatz bereits erwähnten, Möglichkeiten eines Smartphones mit einer dezidierten Applikation sehr gut. Zur besseren Lesbarkeit wird deshalb im Folgenden anstatt des generischen Begriffes Objekt, wie auch in der Applikation, der spezifische Begriff Grabstein verwendet. Die Arbeit soll jedoch auch für andere benachbarte Objekte Verwendung finden können Zielsetzung Im praktischen Teil dieser Arbeit wird eine mobile Applikation entwickelt. Diese Applikation soll ein Foto, textuelle Daten über den Zustand, Form, Symbolik, die Abmessungen des Grabsteines sowie vorhandene Inschriften und seine Position innerhalb des Friedhofs erfassen. Die mobile Applikation, im Folgenden mit der Abkürzung MAEBO (Mobile Applikation (zur) Erfassung benachbarter Objekte) bezeichnet, soll als funktionsfähiger Prototyp implementiert werden, welcher bereits die oben genannten Funktionen unterstützt und eine spätere Erweiterung zulässt. MAEBO wird in der Programmiersprache Java für Smartphones, die mit der Android-Plattform Version 1.6 betrieben werden, geschrieben. Weitere Anforderungen der Geschichtswissenschaften an die Applikation, welche im Rahmen dieser Arbeit nicht umgesetzt werden können, werden in einer Anforderungsanalyse nach dem Standard ANSI/IEEE Std festgehalten, um die zukünftige Entwicklung von MAEBO zu unterstützen. Der Prototyp berücksichtigt die besonderen Bedürfnisse der Erfassung von jüdischen Friedhöfen und bietet dem Nutzer Unterstützung bei der Erfassung von hebräischen Buchstaben sowie wiederkehrenden Bezeichnungen und Symbolen. Darüber hinaus ermöglicht der Prototyp bereits die Erfassung der Position des Grabsteines auf dem 2

12 1. Einleitung Abbildung 1.: Anwendungsfälle von MAEBO Friedhof. Mit diesen Positionsangaben soll ermöglicht werden, die erfassten Daten zum Beispiel zur Erstellung einer interaktiven Karte des Friedhofes zu nutzen. Diese interaktive Karte ist nicht Teil der Arbeit, jedoch können die erfassten Daten zukünftig diesbezüglich weiter verarbeitet werden. Die Anforderungen an den Prototyp sind in der Abbildung 1 in Form eines Anwendungsfalldiagramms ersichtlich Vorgehensweise Für den praktischen Teil dieser Arbeit wurden die Anforderungen an die Software mit einem Mitarbeiter des historischen Seminars der Universität Heidelberg, dem Kunden, in einem Gespräch bereits vor dem Bearbeitungszeitraum der Arbeit erörtert. Alle weiteren Schritte wurden im Bearbeitungszeitraum der Arbeit durchgeführt. 3

13 1. Einleitung Das Kapitel Grundlagen behandelt die in der praktischen Arbeit genutzten Techniken und Methoden und begründet deren Auswahl. Im Kapitel 2.1. werden die derzeit vorhandenen Möglichkeiten für die Positionsbestimmung durch ein Smartphone aufgeführt und eine Methode zur Verbesserung der gemessenen Position abgeleitet. Das Kapitel 2.2. bietet einen Überblick über das für die Server Komponente verwendete Web-Framework Grails und beschreibt ausgewählte Funktionen, die für die praktische Arbeit wichtig waren. Das Kapitel 2.3. widmet sich der Plattform Android, welche die Grundlage für die Entwicklung der mobilen Applikation zu dieser Arbeit ist. Das Kapitel 2.4. geht auf die Grundlagen der Software Engineering Methode Test- Driven-Development ein und beschreibt einen Standard zur Anforderungsanalyse. Beides Themen die für die praktische Arbeit von Bedeutung waren. Das Kapitel Entwicklung enthält einen Überblick über die in dem praktischen Teil geleistete Arbeit und erläutert ausgewählte Teile aus der Implementierung der Software. Das Kapitel 3.1. bietet einen Überblick über die Anforderungen an die Anwendung, beschreibt die Erstellung der Anforderungsanalyse und zeigt einen Teil der Ergebnisse. In Kapitel 3.2. wird der Entwurf des Datenmodells, die Umsetzung durch Domänenklassen im Web-Framework Grails und die Implementierung des Web-Services auf dem Server beschrieben. Das Kapitel 3.3. behandelt ausgewählte Komponenten der mobilen Applikation und erläutert deren Entwurf und Implementierung auf der Android Plattform. Der praktische Teil der Arbeit liegt in Form von zwei Installationspaketen und einer Installationsanleitung vor, die auf der beiliegenden CD abrufbar sind. 4

14 2. Grundlagen In den Folgenden vier Kapiteln werden die technischen, methodischen und theoretischen Grundlagen der Arbeit beschrieben. Technische Grundlagen für den praktischen Teil dieser Arbeit sind die mobile Plattform Android und das Web-Framework Grails. Android wird für die Entwicklung der Client Komponente MAEBO und Grails für die Entwicklung der Server Komponente MAEBO-Server verwendet. Die methodischen Grundlagen bilden eine Anforderungsanalyse und das Test Driven Development, eine Methode des Sofware Engineerings. Die besondere technische Herausforderung dieser Arbeit besteht darin, eine Methode zu entwickeln, mit der die Positionen der Grabsteine möglichst exakt erfasst werden können Positionsbestimmung Global Positioning System Die Erfassung der aktuellen Position ist, seitdem GPS-Empfänger in vielen Smartphones integriert sind, einfach zu realisieren. Somit liegt es nahe, für die Bestimmung der Ortskoordinate der Grabsteine das fast überall verfügbare GPS-Signal zu verwenden. Die Spezifikation des GPS gibt eine Genauigkeit von etwa 8 Metern an, 1 in der Praxis kann die tatsächlich erreichte Auflösung, wenn Satelliten des GPS durch Hindernisse verdeckt sind, deutlich schlechter sein. Leider reicht die räumliche Auflösung der GPS-Empfänger somit nicht aus, um die Lage der Grabsteine im Gelände einwandfrei zu erfassen, da Grabsteine auf einem Friedhof näher als einen Meter aneinander liegen können. Im Folgenden werden mehrere Techniken vorgestellt, wie 1 Vgl. United States of America Department of Defense 2008, S

15 2. Grundlagen die Position eines Grabsteins dennoch mit ausreichender Genauigkeit erfasst werden kann Differential GPS Ein GPS-Empfänger berechnet seine Position aus den Signallaufzeiten der Signale von mindestens vier verschiedenen Satelliten, die ständig ihre Position sowie die exakte Uhrzeit aussenden. 2 Durch atmosphärische Störungen kann die Geschwindigkeit mit der sich die Signale ausbreiten variieren, womit sich eine Ungenauigkeit bei der Positionsbestimmung ergibt. Die Technik DGPS (Differential Global Position System) verbessert die durch das normale GPS bestimmte Position, indem ein weiterer Empfänger, dessen exakte Position bekannt ist, die derzeitigen Abweichungen der GPS-Signale berechnet und diese Information sofort per Funk an den mobilen GPS-Empfänger weiterleitet oder im Nachhinein ein Abgleich der Messungen erfolgt. Da mit dieser Messmethode eine Genauigkeit im Bereich von Zentimetern möglich ist, wäre sie für die Zwecke dieser Arbeit geeignet. Leider ist für diese Technik eine zusätzliche Referenzstation nötig und steht somit für übliche Smartphones nicht zur Verfügung. Eine ähnliche Technik, welche in den GPS-Empfängern der Smartphones verbreitet ist, heißt AGPS (Assisted GPS). Auch AGPS kann die Genauigkeit durch über das Internet empfangene Korrektursignale verbessern, wird aber hauptsächlich dazu verwendet die Zeit, bis eine Ortskoordinate vorliegt zu verkürzen Benachbarte Objekte Bei nah beieinanderliegenden Objekten, die in einem kleinen Umfeld liegen, wie zum Beispiel bei Grabsteinen innerhalb eines Friedhofs ist schon die relative Position der Objekte zueinander eine nützliche Information. So ließe sich, wenn der Abstand und die Orientierung der Grabsteine zueinander bekannt sind, eine Karte des Friedhofes erstellen. Um das Verfahren formal zu beschreiben, wird das Vorgehen nun in Form eines graphentheoretischen Problems geschildert. 2 Vgl. United States of America Department of Defense 2008, S Vgl. Dodel und Häupler 2009, S

16 2. Grundlagen Die Knoten des Graphen repräsentieren die erfassten Grabsteine. An jeder der gerichteten Kanten wird ein Tupel aus der Himmelsrichtung sowie der Entfernung zum Grabstein geschrieben. (Abbildung 2) Voraussetzung für die Erstellung einer zusammenhängende Karte ist, dass die Menge der Knoten und Kanten einen stark zusammenhängenden, optimalerweise zyklenfreien Graphen bildet. Für einen stark zusammenhängenden Graphen muss ein Weg von jedem der Knoten zu jedem anderen Knoten im Graphen existieren. 4 Auf einem solchen Graphen könnte ein Algorithmus, ausgehend von einem Startknoten, die Nachbarschaftsbeziehung an den gerichteten Kanten nutzen, um eine Karte zu zeichnen. Abbildung 2.: Nachbarschaftsbeziehungen repräsentiert als Graph Es ist möglich die Orientierung und Entfernung zwischen den Grabsteinen mit einer besseren Genauigkeit als beim GPS zu bestimmen, somit können die Positionen innerhalb des Bezugssystems Friedhof genauer bestimmt werden. Leider addiert sich bei dieser Methode der unvermeidliche Fehler jeder Einzelmessung. Zudem ist eine exakte Winkel- sowie Entfernungsmessung nur mit einem Smartphone, also ohne weitere Hilfsmittel, nicht möglich. Ein weiteres Problem ist, dass Friedhöfe häufig aus mehreren Bereichen bestehen, die durch Fußwege oder Grünanlagen getrennt sind. Für diese Bereiche existiert keine unmittelbare Nachbarschaftsbeziehung und somit im modellierten Graphen keine gerichtete Kante zwischen den Knotenmengen der Bereiche. Aus solchen Graphen lässt sich keine Karte, die alle Zusammenhangskomponenten enthält, generieren. 4 Vgl. Krumke und Noltemeier 2009, S. 37 f. 7

17 2. Grundlagen Die Position ausschließlich über die im vorherigen Abschnitt beschriebene Methode zu bestimmen, ist demnach für einen großen Friedhof, auf dem einige Grabsteine auch weiter auseinanderliegen, nicht geeignet. Entweder müssten auch die Abstände und Winkel zwischen weit auseinanderliegen Grabsteinen mit Hilfsmitteln bestimmt werden oder es lässt sich keine vollständige Karte generieren Relative Lage kombiniert mit GPS Existiert jedoch zunächst für jeden der Knoten eine, mit der Ungenauigkeit des GPS, erfasste Ortskoordinate so ist es auch bei einem Graphen mit mehreren Zusammenhangskomponenten möglich, eine zusammenhängende Karte zu zeichnen. Ein möglicher Algorithmus wird im Folgenden informal beschrieben: 1. Setze K gleich der Menge aller Knoten 2. Wähle einen beliebigen Knoten k aus der Kontenmenge K 3. Zeichne k mit seiner GPS-Koordinate auf einer Karte ein 4. Bestimme über Orientierung und Entfernung die Position aller von k aus erreichbaren Knoten 5. Entferne alle in der Karte eingezeichneten Knoten aus der Knotenmenge K 6. Wenn K =, dann terminiere, sonst fahre fort mit Schritt 2 Auf diese Art und Weise können alle erfassten Grabsteine in eine zusammenhängende Karte eingezeichnet werden. Im Bezugssystem Erde erreicht die Karte allerdings bei der Bestimmung der Ortskoordinate keine höhere Genauigkeit, da hier auf so viele fehlerbehaftete Messungen durch GPS zurückgegriffen werden muss, wie Zusammenhangskomponenten im zugehörigen Graphen existieren. Steht der Nutzer der Anwendung vor dem Grabstein, so hat er eine gute Vorstellung davon, wie die Grabsteine im direkten Umfeld angeordnet sind. Die Herausforderung für die Entwicklung der mobilen Applikation besteht also darin, dem Nutzer zu ermöglichen diese Beobachtung möglichst komfortabel einzugeben. Auf die tatsächliche Umsetzung in der mobilen Applikation, eine Mischung zwischen automatischer Lokalisierung per GPS und manueller Korrektur durch den Nutzer, wird im Kapitel eingegangen. 8

18 2. Grundlagen 2.2. Das Web-Framework Grails Motivation Die Entscheidung, Grails für die Entwicklung der Server-Komponente zu benutzen, wurde getroffen, weil sich damit sehr schnell und mit wenig Aufwand ein Datenmodell in Form von Domänenklassen für eine beliebige Datenbank erstellen lässt. Außerdem generiert Grails automatisch eine Web-Oberfläche für die CRUD (Create, Read, Update, Delete)-Basisoperationen auf dem Datenbestand und die bidirektionale, automatische Konvertierung von Domänenklassen in ein geeignetes Austauschformat, wie zum Beispiel XML (Extensible Markup Language) und JSON (JavaScript Object Notation) Überblick Dynamische Programmiersprache Groovy für die Java virtuelle Maschine Spring Web-Framework Objekt-relationales Mapping mit GORM und Hibernate Anwendung des Coding by convention Paradigma für schnelle Anwendungsentwicklung Apache Lizenz 2.0 Grails ist ein Web-Framework, das auf der dynamischen Programmiersprache Groovy sowie sehr stark auf der weitverbreiteten Java Bibliothek Spring aufsetzt. Es folgt dem Paradigma coding by convention und ist für eine schnelle und agile Entwicklung von Web Anwendungen geeignet. Grails wird von SpringSource, einem Unternehmen das zu VMWare gehört, entwickelt und ist unter der Apache-Lizenz Version als Open Source freigegeben. In den Anfängen der Entwicklung bis Anfang 2006 noch als Groovy on Rails bekannt, erfüllt Grails in der Umgebung von Java eine ähnlich Rolle wie das Framework Ruby on Rails für die Programmiersprache Ruby. Der Name wurde auf Bitte des Entwicklers von Ruby on Rails in Grails geändert. 5 The Apache Software Foundation

19 2. Grundlagen Coding by convention, auf Deutsch Konvention vor Konfiguration, beschreibt den Ansatz, die in vielen Frameworks sehr komplexen sowie umfangreichen Konfigurationsmöglichkeiten durch Konventionen bei der Namensgebung von Komponenten im Quelltext zu ersetzen. Zusammen mit Voreinstellungen für die am häufigsten genutzten Anwendungsfälle soll damit die Lesbarkeit der Programme verbessert und durch den entfallenden Aufwand für die Konfiguration eine produktivere, schnellere Entwicklung ermöglicht werden Ausgewählte Funktionen Persistenz Der objekt-relationale Mapper GORM (Grails Object Relational Mapping) bindet die Java Bibliothek Hibernate, die bei einer klassischen Java Anwendung häufig mit vielen Konfigurationsdateien (Quelltext 1) im XML Format arbeitet, fast ohne die Notwendigkeit einer Konfiguration ein. Die vollständige Beschreibung der Datenbank befindet sich somit innerhalb einer oder mehrerer Domänenklassen. Lediglich für die Definition des Datenbanktreibers und der Zugangsdaten zur Datenbank ist eine externe Konfiguration nötig. 7 Durch GORM lassen sich diese Domänenklassen (Quelltext 2) automatisch, meist in einer Tabelle, in einer relationalen Datenbank abspeichern. <h i b e r n a t e mapping> <c l a s s name=" Cemetery " table=" cemetery "> <i d name=" i d " column=" i d " type=" j a v a. l a n g. Long "> <generator c l a s s=" increment "></ generator> </ i d> <property name=" name " column=" name " type=" s t r i n g " /> <one to one name=" l o c a t i o n " c l a s s=" de. hbrs. maebo. L o c a t i o n " /> <s e t name=" gravestones " table=" gravestone "> <key column=" i d " /> <one to many c l a s s=" de. hbrs. maebo. Gravestone " /> </ s e t> </ c l a s s> </ h i b e r n a t e mapping> Quelltext 1: Definition einer Domänenklasse in Hibternate Das Standardverhalten von GORM ist es, jedes Feld einer Domänenklasse auf eine Spalte in der Datenbank abzubilden und den Wert null nicht zu erlauben. Dies 6 Vgl. Chen Vgl. Rocher und Brown 2009, S. 61 ff. 10

20 2. Grundlagen ist vergleichbar mit der Anweisung NOT NULL in einer relationalen Datenbank. Soll von diesem Verhalten abgewichen werden, dann muss die statische Eigenschaft constraints innerhalb der Domänenklasse angepasst werden. c l a s s Cemetery { / E i n f a c h e s F e l d / String name ; / N zu 1 Beziehung zu e i n e r anderen Domänenklasse / L o c a t i o n l o c a t i o n ; / N zu M Beziehung zu e i n e r anderen Domänenklasse / s t a t i c hasmany = [ gravestones : Gravestone ] ; } / Einschränkungen, zu Beachten b e i der Generierung des Datenbank Schemas / s t a t i c c o n s t r a i n t s = { name ( s i z e : , blank : f a l s e ) l o c a t i o n ( n u l l a b l e : true ) g r a v e s t o n e s ( n u l l a b l e : true ) } Quelltext 2: Definition einer Domänenklasse in Grails Über die statische Closure constraints lassen sich die Einschränkungen für die Felder des Objektes abändern. Diese Einschränkungen heißen in Grails Validatoren und werden mit dem Validation Framework der Spring Bibliothek verwaltet. 8 Grails bietet mit der domänenspezifischen Sprache, auch hier den Vorteil redundanten Quelltext zu reduzieren. 9 Scaffolding Ist das Datenmodell der Anwendung in Domänenklassen umgesetzt, dann lässt sich mit Grails eine vollständige Web-Oberfläche für die CRUD-Operationen auf dem Datenmodell generieren. Bei dieser als Scaffolding bezeichneten Technik werden die beiden fehlenden Komponenten aus dem MVC Konzept, View und der Controller, automatisch erzeugt. Für jede Domänenklasse wird ein Controller mit Quelltext für die CRUD-Operationen und für jede Operation ein Web-Formular (View) in der Skriptsprache GSP erstellt. Der generierte Quelltext lässt sich dann als Basis für die Entwicklung der Anwendung verwenden. Für die Entwicklung von MAEBO ist es besonders hilfreich, dass sich das Scaffolding über Templates beliebig anpassen lässt. Durch veränderte Templates können zum Beispiel alle generierten Controller um REST Funktionalität erweitert werden. 8 Vgl. Tate und Gehtland 2004, S Vgl. Rocher und Brown 2009, S. 82 ff. 11

21 2. Grundlagen Web-Service nach REST Für die Kommunikation zwischen der mobilen Applikation und dem Server müssen ein Austauschformat und ein Protokoll gewählt werden. In Grails existiert eine sehr einfache Methode mit der, Domänenobjekte nach XML oder JSON sowie das generierte XML oder JSON wieder zurück zu Domänenobjekten konvertiert werden können. Ein Nachteil bei der Verwendung von XML gegenüber JSON oder einem noch kompakteren, binären Format ist die größere Datenmenge. Da die Implementierung von XML in Grails jedoch deutlich ausgereifter ist und auf dem Client in der Version 1.6 noch keine komfortable Unterstützung für JSON vorhanden ist, wurde trotzdem XML als Austauschformat gewählt. Für einen Prototyp gilt hier der Grundsatz Premature optimization is the root of all evil 10 und wie in Kapitel gezeigt wird, lässt sich das Format in der Zukunft noch optimieren. d e f t e s t I n s t a n c e = new Test ( name : " Test " ) ; // K o n v e r t i e r u n g nach XML und Ausgabe i n einem C o n t r o l l e r r e n d e r t e s t I n s t a n c e as XML // Ausgabe i n XML <?xml v e r s i o n=" 1. 0 " encoding="utf 8"?> <t e s t i d= 1 v e r s i o n= 0 > <name>test </name> </ test > // Konvertierung zurück zu einem Objekt aus einem HTTP Request in einem C o n t r o l l e r d e f t e s t I n s t a n c e = new Test ( params [ t e s t ] ) Quelltext 3: Konvertierung von XML in beide Richtungen REST (Representational State Transfer) konforme Web-Services zeichnen sich dadurch aus, dass sie eine einheitliche Schnittstelle definieren, meist mittels der HTTP- Methoden (POST, PUT, GET, DELETE), über die in einer zustandslosen Art auf Ressourcen zugegriffen werden kann. 11 Grails bietet über seinen URL Mapping Mechanismus eine einfache Möglichkeit die bestehende, zuvor automatisch generierte, Web-Applikation um einen REST konformen Web-Service zu erweitern. Da der Fokus dieser Arbeit auf der Entwicklung der mobilen Anwendung und der Erfassung der Position der Grabsteine liegt, wird hier die Architektur von REST nicht weiter ausgeführt. 10 Knuth 1974, S Vgl. Richardson und Ruby 2007, S. 89 ff. 12

22 2. Grundlagen 2.3. Die mobile Plattform Android Motivation Für die Implementierung von MAEBO wurde Android als Plattform bereits im Vorfeld der Arbeit festgelegt. Daher wird in dieser Arbeit kein Überblick über die auf dem Markt vorhandenen mobilen Plattformen gegeben. Für weitere Informationen empfiehlt sich das Buch Das mobile Web von Alby (2008). Aufgrund des begrenzten Rahmens dieser Arbeit wird ebenfalls nicht näher auf die Grundfunktionen von Android eingegangen, sondern nur ausgewählte Komponenten vorgestellt Überblick Vollwertiges Java mit neuer virtueller Maschine Linux-Kernel und Open Source Bibliotheken Marktanteil von 17% (2. Quartal 2010) 12 Apache 2.0 Lizenz Android besteht aus einem Betriebssystem, das auf einem Linux-Kernel basiert, einer Middleware, welche die Hardware des Smartphones über eine Java-Schnittstelle offen legt, sowie über einige Applikationen die Kernfunktionen eines Smartphones zur Verfügung stellen. 13 Android wird von der Open Handset Alliance, welche Google zusammen mit knapp 50 anderen Mobilfunk und Technologie-Unternehmen gegründet hat, entwickelt und vermarktet. Einige ausgewählte Mitglieder der Open Handset Alliance sind die Gerätehersteller HTC, LG, Motorola, Sony Ericsson, Acer sowie internationale Netzbetreiber wie T-Mobile, Vodafone und Sprint Nextel. 14 Ende 2008 ist mit dem T-Mobile G1 das erste mit Android ausgestattete Smartphone erschienen. Mittlerweile wird Android auf zahlreichen Smartphones verwendet und hat einen Marktanteil von 17% (2. Quartal 2010) 15 erreicht. 12 Vgl. Gartner Vgl. Becker und Pant 2010, 19ff. 14 Vgl. Meier 2009, S Vgl. Gartner

23 2. Grundlagen Abbildung 3.: System Architektur von Android (Google 2010) Technologisch basiert Android auf einem für geringe Prozessorleistung und geringen Speicherbedarf modifizierten Linux-Kernel, der Programmiersprache Java mit einer neu entwickelten, stark veränderten virtuellen Maschine mit dem Namen Dalivk VM sowie auf einigen weitverbreiteten Open Source Bibliotheken. (Abbildung 3) Das umfangreiche SDK (Software Development Kit), welches unter der Apache-Lizenz Version veröffentlicht wird, liegt mittlerweile in der Version 2.2 vor und bietet zahlreiche Möglichkeiten für die Anwendungsentwicklung Ausgewählte Funktionen REST und Content Provider Für die Kommunikation der Android Applikation mit dem Server ist ein geeignetes Protokoll und Austauschformat, mit dem die Daten durch das Internet übertragen werden, nötig. Wie im Abschnitt über Grails und die Server Applikation erläutert, bietet sich die Verwendung eines RESTful Webservice mit XML als Austauschformat für die Objekte an. Unter Android lassen sich durch die Bibliothek Apache HTTP 16 The Apache Software Foundation

24 2. Grundlagen Client mit geringem Aufwand Anfragen nach dem REST Paradigma stellen. Das Serialisieren und Deserialisieren der Objekte ist mit drei verschiedenen XML-Parser Bibliotheken in ein beliebiges XML-Format sowie in der neuesten Version 2.2, durch die enthaltene JSON Bibliothek, auch in das Austauschformat JSON möglich. Da in einem mobilen Umfeld nicht immer eine stabile Verbindung zum Internet vorhanden ist und auf einem Smartphone mit Android jede Applikation jederzeit, zum Beispiel durch einen eingehenden Anruf, unterbrochen werden kann, ist es sinnvoll, die Daten nicht ausschließlich im Internet zu speichern. Eine auch ohne Netzverbindung zuverlässige Zwischenspeicherung im lokalen Speicher auf dem Gerät hilft die erfassten Daten sicher zu speichern und kann zusätzlich Datentransfer in das Internet sparen. Daten können auf der Android Plattform im lokalen Dateisystem sowie in einer SQLite Datenbank abgespeichert werden. Der Zugriff auf die Daten kann direkt erfolgen, sollen aber auch andere Applikationen auf die Daten zugreifen oder binäre Daten gespeichert werden, so kann ein ContentProvider erstellt werden. 17 Ein ContentProvider kapselt bei Android den Zugriff auf Daten aus einer lokalen Datenbank oder Dateien im lokalen Dateisystem, selbst der Zugriff auf Daten, die in einem entfernten System abgelegt sind, ist möglich. Die Daten werden über eine Content-Uri addressiert und stehen, bei entsprechend konfigurierten Sicherheitseinstellungen, auch anderen Applikationen zur Verfügung. Eine Content-Uri ist nach dem Muster $scheme://$authority/$datadescriptor[$id] aufgebaut. 18 Abgerufen werden können die Daten über die vom Android System bereitgestellte Schnittstelle ContentResolver. Die Methoden der Schnittstelle orientieren sich an den üblichen SQL-Befehlen und geben die Daten in Form der Klasse Cursor zurück. Mit dem Cursor kann durch die Daten itteriert werden. (Quelltext 4) Cursor query ( Uri u r i, S t r i n g [ ] p r o j e c t i o n, S t r i n g s e l e c t i o n, S t r i n g [ ] s e l e c t i o n A r g s, S t r i n g s o r t O r d e r ) Uri i n s e r t ( Uri u r l, ContentValues v a l u e s ) int update ( Uri u r i, ContentValues v a l u e s, S t r i n g where, S t r i n g [ ] s e l e c t i o n A r g s ) int d e l e t e ( Uri u r l, S t r i n g where, S t r i n g [ ] s e l e c t i o n A r g s ) int b u l k I n s e r t ( Uri u r l, ContentValues [ ] v a l u e s ) InputStream openinputstream ( Uri u r i ) OutputStream openoutputstream ( Uri u r i ) Quelltext 4: Schnittstelle ContentResolver 17 Vgl. Becker und Pant 2010, S. 259 ff. 18 Becker und Pant 2010, S

25 2. Grundlagen Damit die Daten trotzdem auf den Server gelangen, bedarf es einer Strategie zur Synchronisation des lokalen Datenbestands mit dem Server. Google stellte auf seiner jährlichen Konferenz für Entwickler im Jahr 2010, der Google I/0 2010, in dem Vortrag Developing Android REST Client Applications drei ähnliche Entwurfsmuster für eben diese Aufgabe vor. Von einem der Entwurfsmuster leitet sich die Implementierung im praktischen Teil der Arbeit ab, daher wird es im Kapitel genauer erläutert. Location- und Sensor Manager Das Erkennen des aktuellen Standortes und der Ausrichtung des Gerätes sind wichtig, um im Gelände die exakte Position der Grabsteine zueinander, und im optimalen Fall auch absolut in Form von Ortskoordinaten, zu errechnen. Für die Lokalisierung des Smartphones gibt es in Android zwei nützliche Klassen, den LocationManager und den SensorManager. Die Klasse LocationManager bietet die Möglichkeit die aktuelle Position über den GPS-Empfänger des Smartphones in regelmässigen Abständen geliefert zu bekommen. Der SensorManager liefert Daten des eingebauten elektronischen Kompasses, also zur Himmelsrichtung in die das Gerät aktuell ausgerichtet ist. Die von diesen beiden Klassen gelieferten Daten werden bei den Berechnungen im Kapitel verwendet Software Engineering Zum Erfolg eines Software Projektes trägt die Verwendung von Methoden des Software Engineering bzw. der Softwaretechnik bei. Neben Vorgehensmodellen, welche die Abfolge von Phasen in einem Projekt definieren, 19 gibt es Methoden, die in den jeweiligen Phasen angewendet werden können, um etwa die Qualität des Quelltextes und somit auch die Qualität des Endproduktes in Form von Fehlerfreiheit, Wartbarkeit sowie Evolvability 20 sicherzustellen. In dieser Arbeit wird, aufgrund der geringen Anzahl der beteiligten Personen, je- 19 Vgl. Zuser, Grechenig und Köhle 2004, S Vgl. Riebisch und Bode 2009, S. 339 f. 16

26 2. Grundlagen doch auf die Verwendung eines formalen Vorgehensmodells zur Projektsteuerung (Scrum, V-Modell, Wasserfall, XP) verzichtet. Aus den zahlreichen Methoden der Softwaretechnik wird in der Anforderungsanalyse zunächst eine Methode für die Planungsphase vorgestellt. Anschließend werden mit Test-Driven-Development und Refactoring zwei agile Methoden aus der Implementierungsphase erläutert. Diese Methoden wurden im praktischen Teil der Arbeit umgesetzt Anforderungsanalyse Das IEEE (Institute of Electrical and Electronics Engineers) ist ein weltweit agierendes, gemeinnütziges Institut im Bereich Elektrotechnik, Telekommunikation und Informatik. Es ist insbesondere bekannt für das Organisieren von internationalen Konferenzen und für zahlreiche veröffentlichte Industriestandards. Unter diesen befindet sich mit dem ANSI/IEEE Std ein Standard der den formalen Aufbau einer Anforderungsanalyse für die Softwareentwicklung beschreibt. Nach der IEEE sollte eine gute Anforderungsanalyse unter anderem Kriterien wie Korrektheit, Eindeutigkeit und Konsistenz erfüllen. 21 Besonders wird darauf hingewiesen, dass die Anforderungsanalyse zwar möglichst alle Anforderungen an die Software aufnehmen soll ( Komplettheit ), aber noch keine Aussagen über die Art der Implementierung oder das Software-Design treffen soll. [..] (b) Should not describe any design or implementation details. These should be described in the design stage of the project. 22 Neben Empfehlungen zum Inhalt einer Anforderungsanalyse schlägt der IEEE Standard eine bestimmte Strukturierung des Dokuments vor und enthält Prototypen eines beispielhaften Inhaltsverzeichnisses sowie kurze Erklärungen zu jedem Kapitel. Hauptsächlich gibt der Standard der IEEE nur einen Rahmen für eine Anforderungsanalyse vor. (Abbildung 4) Grobe Schablonen einer grafischen Benutzeroberfläche, auch Mockups (Abbildung 8) genannt, werden im Zuge der Erhebung von Anforderungen und Analyse einer Soft- 21 Vgl. IEEE-SA Standards Board 1998, S. 4f. 22 IEEE-SA Standards Board 1998, S

27 2. Grundlagen Abbildung 4.: Prototype SRS outline (IEEE-SA Standards Board 1998, S. 11) warelösung eingesetzt, um dem späteren Anwender und Kunden bereits früh die geplante Funktionalität zu vermitteln. Mockups werden bewusst sehr grob gehalten, damit sie nicht mit einem realen UI (User Interface) verwechselt werden. In der frühen Analysephase soll durch die grobe Darstellung vermieden werden, dass der Kunde bereits den Eindruck erhält eine funktionsfähige Anwendung zu sehen. Mit den Mockups wird nur der grobe Ablauf und die grundlegende Funktionalität der Software auf eine, auch für technisch unversierte Nutzer, verständliche Art dargestellt. Mockups und der Standard ANSI/IEEE Std sind Hauptbestandteil der Anforderungsanalyse zu MAEBO. Das Vorgehen bei der Erstellung der Anforderungsanalyse zu MAEBO wird zum Anfang des 3.1 Kapitel ausführlich beschrieben Test-Driven-Development und Refactoring Test-Driven-Development ist eine Methode der agilen Softwareentwicklung, die von Kent Beck durch sein Buch Test-Driven Development. By Example entscheidend geprägt wurde. Diese Methode beschreibt eine stark iterative Vorgehensweise bei der sich das Schreiben von Test-Quelltext und funktionalem Quelltext abwechselt. Zuerst wird ein möglichst einfacher, automatisierter Unit-Test geschrieben, der definiert was die zu implementierende Funktion leisten soll. Anschließend wird diese 18

28 2. Grundlagen Abbildung 5.: Mockup eines Bildschirms von MAEBO Funktion so einfach wie möglich implementiert, bis beim automatisierten Test keine Fehler mehr auftreten. Nun kann der Test erweitert und somit die nächste Iteration gestartet oder wenn nötig ein Refactoring der Methode durchgeführt werden. 23 Kent nennt diesen Ablauf angelehnt an die Farbgebung bei vielen bekannten Test- Frameworks: Red/green/refactor the TDD mantra.. 24 Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. [... ] In essence when you refactor you are improving the design of the code after it has been written. 25 Häufiges Refactoring, der dritte Schritt beim Test-Driven-Development, trägt nach dieser Definition von Martin Fowler dazu bei, dass sich die interne Struktur, die 23 Vgl. Beck 2008, S. x. 24 Beck 2008, S. x. 25 Fowler und Beck 1999, S. xvi. 19

29 2. Grundlagen Qualität des Quelltextes, verbessert, ohne dass sich Veränderungen in der Funktionalität ergeben. Im Test-Driven-Development dient der stets vorhandene, ursprünglich geschriebene Test dazu sicherzustellen, dass sich das Verhalten der Methode nach außen nicht geändert hat. Analog zu dem Entwurfsmuster bei der Programmierung gibt es auch für das Refactoring selbst wiederkehrende Muster, die in der Literatur dokumentiert sind. Eines dieser Muster, welches in der praktischen Arbeit verwendet wurde, heißt Replace Error Code with Exception. 26 Das Refactoring Muster ersetzt Rückgaben von Fehlercodes oder des Wertes null im Falle einer falschen Eingabe oder eines Fehlers in der Berechnung durch eine benannte Exception. Dadurch besteht nicht die Gefahr, dass der aufrufende Quelltext mit einem ungültigen Wert weiterarbeitet. Zusätzlich kann die Ablaufsteuerung möglicherweise vereinfacht werden und der Quelltext wird durch die benannten Exceptions lesbarer. Im Kapitel werden beide Refactoring Muster anhand der praktischen Arbeit ausführlich vorgestellt. Die Unterstützung für das Test-Driven-Development in Android und Grails basiert grundsätzlich auf der Bibliothek JUnit, welche die Basisklasse für Unit-Tests in Java zur Verfügung stellt. Android und Java erweitern JUnit um Klassen sowie Befehle, die das Testen auf der jeweiligen Plattform vereinfachen. Grails bietet zum Beispiel mit dem GroovyTestCase eine Erweiterung zu JUnits TestCase, die zusätzliche Befehle unterstützt. Ein Befehl der stark zu der dynamischen Natur von Grails passt ist shouldfail mit einer Exception sowie einer Closure als Parameter. Damit lässt sich sehr einfach beschreiben, dass eine bestimmte Aktion eine Exception verursachen sollte. (Quelltext 5) 27 void testbadurl ( ) { d e f badurl = " a n i n v a l i d u r l " def b = new Bookmark ( ) shouldfail ( MalformedURLException ) { b. u r l = new URL( badurl ) } } Quelltext 5: Listing 6-3. Using shouldfail Neben dem Unit-Test gibt es in Grails ein Plugin, welches funktionale Tests der Weboberfläche mit Canoo WebTest integriert. Bei einem funktionalen oder auch Sys- 26 Vgl. Fowler und Beck 1999, S Rocher und Brown 2009, S

30 2. Grundlagen temtest wird die Applikation als Einheit getestet, 28 alle Komponenten sind gleichzeitig aktiv. Dadurch soll die spätere Produktivumgebung möglichst exakt simuliert werden. Das Framework Canoo WebTest simuliert intern einen Web-Browser und kann viele typische Aktionen, die ein Benutzer auf einer Webseite ausführt, nachbilden. Im Testlauf werden die definierten Aktionen sequenziell abgearbeitet und der Inhalt der resultierenden Webseiten kann unter anderem mit XPath Ausdrücken überprüft werden. void testcreateaction ( ) { invoke / gravestone c l i c k L i n k ( xpath : // / span c l a s s ="menubutton " ] /a ="/MAEBOServer/ g r a v e s t o n e / c r e a t e " ] ) } v e r i f y X P a t h ( xpath : / / c r e a t e " ] ) v e r i f y X P a t h ( xpath : // / span c l a s s ="menubutton " ] /a ="/MAEBOServer/ g r a v e s t o n e / l i s t " ] ) not { v e r i f y X P a t h ( xpath : // / span c l a s s ="menubutton " ] /a ="/MAEBOServer/ g r a v e s t o n e / c r e a t e " ] ) } Quelltext 6: Beispiel für einen Web-Test Android bietet neben den üblichen Unit-Tests mit den Klassen ProviderTestCase2 sowie ServiceTestCase spezialisierte Test Klassen für Content Provider und Services. Zusätzlich existiert mit der Klasse ActivityInstrumentationTestCase2 eine Art Integration Test mit dem eine komplette Activity im Kontext der normalen Systemumgebung getestet werden kann und Benutzereingaben simuliert werden können. Leider sind für eine reaktionsschnelle Android Applikation sehr häufig asynchrone Methoden notwendig und nebenläufige Methoden sind nur mit erhöhtem Aufwand zu testen. 29 Aus diesem Grund wurden bei der Android Entwicklung hauptsächlich Berechnungen und die Basisfunktionalität getestet, nicht aber das komplexe Zusammenspiel der Benutzeroberfläche, dem Lebenszyklus einer Activity und nebenläufig arbeitenden Service Klassen für den Netzwerk-Zugriff. 28 Vgl. Brügge und Dutoit 2004, S. 469 f. 29 Vgl. Link und Fröhlich 2003, S. 201 ff. 21

31 3. Entwicklung Der praktische Teil der Arbeit, die Entwicklung von MAEBO in Form einer Serversowie einer Client-Komponente, wird in den folgenden Abschnitten beschrieben. Es werden Themen aus dem Kapitel Grundlagen aufgegriffen und gezeigt wie die zuvor genannten Technologien und Methoden beim Entwurf sowie der Implementierung der Software angewendet werden. Die Gliederung richtet sich nach dem zeitlichen Ablauf der Implementierung. Zunächst wurde eine Anforderungsanalyse durchgeführt, danach wurden bedingt durch das Vorgehen nach Test-Driven-Development abwechselnd Implementierungen an der Server-Komponente und der mobilen Anwendung für Android vorgenommen. Übersichthalber wird die Implementierung der Server- und Client Komponente im Folgenden aber getrennt beschrieben. Sämtliche Bezeichnungen im Quelltext sind in englischer Sprache. Dies vermeidet eine Mixtur von Sprachen durch die englischsprachigen Schlüsselwörter der Programmiersprache. Im Text verwendete Klassen und Methodennamen werden durch kursive Schreibweise hervorgehoben Anforderungsanalyse Das im Rahmen der Anforderungsanalyse erstellte Dokument beschreibt die funktionalen sowie einige nicht-funktionalen Anforderungen 1 an die Software aus Sicht des Kunden. Die Gliederung des Dokuments ist, wie bereits erwähnt, an den Standard ANSI/IEEE Std angelehnt. Um die spezifischen, funktionalen Anforde- 1 Vgl. Brügge und Dutoit 2004, S. 125 ff. 22

32 3. Entwicklung rungen besser nachverfolgen zu können, wurde jede Anforderung mit einer Nummer versehen und in einem Steckbrief erfasst. (Abbildung 10) REQ-006 Erfassen einer neuen Inschrift offen Situation: Der Nutzer will eine Inschrift zu einem Grabstein erfassen. Ergebnis: Die Felder Bezeichnung, Nachname, Geburtsname, Vorname (deutsch), Vorname (hebräisch) sowie die Sprache und Besonderheiten konnten erfasst werden. Benutzer: Erfasser Abbildung 6.: Anforderung in Steckbrief-Form Anforderungen des Kunden Bei Gesprächen mit dem Kunden wurden zwei grundlegend unterschiedliche Anwendungsfälle der mobilen Applikation identifiziert: das Erfassen und das Anzeigen von Grabsteinen. Im Verlauf der Entwicklung wird der Anwendungsfall Erfassen von Grabsteinen in die beiden Spezialfälle Grabstein erfassen und Grabstein editieren unterteilt. (Abbildung 1) Die Hauptanforderungen an die Anwendung, innerhalb dieser zwei Anwendungsfälle, sind: Aufnehmen eines Fotos (REQ-001) Erfassen von Daten zum Grabstein (REQ-003) Erfassen von Inschriften auf dem Grabstein (REQ-006) Erfassen der Ortskoordinate des Grabsteins (REQ-008) Anzeigen der erfassten Grabsteine in Listenform (REQ-010) Anzeigen der erfassten Grabsteine in Kartenform (REQ-011) Verwaltung der Grabsteine über die Server Applikation (REQ-012) Die vollständige Liste der Anforderungen befindet sich in der Anforderungsanalyse im Anhang. 23

33 3. Entwicklung Mockups zur Kommunikation Insgesamt existieren zu MAEBO zwölf Steckbriefe sowie sieben Mockups der grafischen Benutzeroberfläche. Da die Mockups hauptsächlich nur für die Kommunikation der Anforderungen zum Kunden dienen, gibt es nicht zu jedem Steckbrief ein Mockup. Für die Umsetzung in der Implementierungsphase sollte die Beschreibung in den Steckbriefen ausschlaggebend sein, es hat sich im Verlaufe des Projekts jedoch herausgestellt, dass die Mockups insbesondere für das Design der Benutzeroberfläche hilfreich sind. Abbildung 7.: Mockup: Erfassen der Daten zum Grabstein (REQ-003) 3.2. Entwicklung der Server-Anwendung Die Server-Anwendung wurde mit dem Grails Framework in der Version und der Entwicklungsumgebung NetBeans durchgeführt. Die folgenden Abschnitte dokumentieren ausgewählte Schritte bei der Entwicklung. Die vollständige Dokumentation im JavaDoc Format befindet sich auf der beiliegenden CD. 24

34 3. Entwicklung Entwurf des Datenmodells Das Datenmodell zu MAEBO ist mit nur vier Entitäten und vier Assoziationen sehr einfach. Aus den Anforderungen konnten die Entitäten Cemetery, Gravestone sowie Inscription identifiziert werden. Zusätzlich wurde die Ortskoordinate als dezidierte Entität Location modelliert, da sowohl ein Grabstein, als auch ein Friedhof eine Ortskoordinate erhalten können. Ein Nachteil dieser Lösung liegt darin, dass bei der Abfrage über den Web-Service eine zusätzliche Anfrage an den Server gestellt werden muss, um die Position des Grabsteines zu erhalten. Der Vorteil die Ortskoordinate eines Friedhofes und eines Grabsteines zukünftig auf die gleiche Art und Weise behandeln zu können und die korrekte Normalisierung wiegt diesen Nachteil jedoch auf. Eine Optimierung beispielsweise durch den Transfer der Location als eingebettete Klasse innerhalb der XML Daten eines Gravestones ist möglich. Abbildung 8.: Klassendiagramm von MAEBO Die drei Operationen save, delete sowie get stellt das Framework Grails für Domänenklassen automatisch zur Verfügung. Somit entfallen die in Java übliche Defini- 25

35 3. Entwicklung tion eines DAO (Data Access Object) und der Aufwand die Datenbankabfragen zu schreiben. Nach der Generierung der Controller und Views steht somit eine einfache Web-Oberfläche zur Verfügung mit der Domänenobjekte angelegt und die Beziehungen unter den Objekten editiert werden können. Da die eben erwähnten Basisfunktionen auf den Domänenklassen und die generierten Controller und Views bereits durch das Framework bereitgestellt werden, konnte auf einen umfangreichen Test verzichtet werden. Lediglich für das Hinzufügen und das Entfernen einer Inscription zu einem Gravestone sowie eines Gravestone zu einer Cemetery wurden Unit-Tests geschrieben. Abbildung 9.: Per Scaffolding erstellte Web-Oberfläche Implementierung des Web-Service Grabstein CRUD Der nächste Schritt war die Erweiterung der Applikation um einen REST konformen Web-Service. Um das Test-First Paradigma des TDD (Test Driven Development) anzuwenden, wurde zuerst ein neuer Unit-Test für diese Funktion geschrieben. Da der Web-Service hauptsächlich eine Funktion aus dem Framework von Grails nutzen sollte, konnte kein einfacher Unit-Test angelegt werden. Die Funktion musste daher innerhalb eines Integration-Tests getestet werden. Der erste Entwurf eines Tests sah vor die automatische Erstellung eines neuen Grabsteines durch vorgegebene XML Daten, auch Auto-Unmarshaling genannt, zu testen. Durch einen Fehler 26

36 3. Entwicklung in Grails funktioniert das Auto-Unmarshaling nicht innerhalb eines Integration- Tests. Erst mit Canoo WebTest, das sich als Plugin für Grails einbinden lässt, war ein Test dieser Funktion möglich. Der funktionale Test ruft die Applikation mit einem simulierten Web-Browser auf, schickt vorgefertigte Test-XML-Daten und überprüft durch Analyse der Antwort, ob der Grabstein korrekt angelegt wurde. (Quelltext 7) void test001restfulpost ( ) { c o n f i g { header ( name : Content Type, v a l u e : a p p l i c a t i o n /xml ) } i n v o k e ( u r l : r e s t / g r a v e s t o n e, method : POST, content : <?xml v e r s i o n = "1.0" encoding="utf 8"?> <g r a v e s t o n e > <cemetery id ="1"/> <condition >condition </condition > <depth >3</depth> <form>form</form> <height >1</height> <i n s c r i p t i o n s /> <l o c a t i o n /> <material >material </material > <remarks>remarks </remarks> <r e s t o r a t i o n >r e s t o r a t i o n </ r e s t o r a t i o n > <symbols>symbols </symbols> <width >2</width> </g r a v e s t o n e > ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e =3] " ) verifyxpath ( xpath : " / gravestone / cemetery " ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e / m a t e r i a l ", t e x t : " m a t e r i a l ", r e g e x : true ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e / depth ", t e x t : " 3 ", r e g e x : true ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e / form ", t e x t : " form ", r e g e x : true ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e / h e i g h t ", t e x t : " 1 ", r e g e x : true ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e / i n s c r i p t i o n s " ) verifyxpath ( xpath : " / gravestone / remarks ", text : " remarks ", regex : true ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e / r e s t o r a t i o n ", t e x t : " r e s t o r a t i o n ", r e g e x : true ) verifyxpath ( xpath : " / gravestone / symbols ", text : " symbols ", regex : true ) v e r i f y X P a t h ( xpath : " / g r a v e s t o n e / width ", t e x t : " 2 ", r e g e x : true ) } Quelltext 7: Test eines Web-Service mit Canoo WebTest Damit der Testfall erfolgreich ausgeführt werden kann, muss die save Methode des GravestoneController um drei Funktionen erweitert werden: 1. Interpretieren der POST Anfrage nach dem REST Paradigma 2. Erstellen eines Domänenobjekts durch XML aus der Anfrage (Unmarshaling) 3. Erzeugen einer XML Repräsentation eines Domänenobjekts (Marshaling) Für die erste Funktion muss das Url Mapping, welches die Zuordnung einer eingehenden Anfrage zu einem Controller bestimmt, in der Art abgeändert werden, dass die drei HTTP (Hyper Text Transfer Protocol) Methoden GET, POST und 27

37 3. Entwicklung PUT auf die korrespondierenden Methoden list/show, save und update abgebildet werden. Die zweite Funktion lässt sich, der Grails Dokumentation zufolge, fast ohne Modifikation, an dem automatisch generierten Quelltext des Controllers implementieren. Es muss im Url Mapping für diesen Controller lediglich der Schalter parserequest gesetzt werden. Der Quelltext 8 zeigt einen Auszug aus der Implementierung der ersten beiden Funktionen. " / r e s t / $ c o n t r o l l e r " ( p a r s e R e q u e s t : true ) { r e s t = true a c t i o n = [GET: " l i s t ", POST: " s a v e " ] format = { r e q u e s t. format == " multipartform "? " multipartform " : " xml " } } Quelltext 8: RESTful Url Mapping mit XML Parsing Das Marshaling einer Gravestone -Instanz ist durch die in Grails eingebaute Konvertierung einer Domänenklasse mit der überladenen Typenumwandlung render gravestoneinstance as XML sehr einfach. Zusätzlich zu diesem Befehl musste über einen Parameter in der Konfiguration die Konvertierung des Feldes version, welches für das optimistic locking von Hibernate benötigt wird, eingeschaltet werden. Verwendet wird das Marshaling zum Beispiel bei der Antwort auf eine erfolgreiche POST -Anfrage oder bei einer GET -Anfrage. Nach diesen Schritten konnte der MAEBO Web-Service bereits Grabsteine anlegen, editieren und löschen und die Entwicklung der Android Applikation konnte beginnnen. Upload des Fotos Bisher konnte der MAEBO Web-Service zwar Grabsteine verwalten, jedoch wurde bei der Entwicklung des Clients schnell deutlich, dass die Anforderung REQ-001 (Foto aufnehmen) dort zuerst umgesetzt werden sollte. Aus diesem Grund musste der Web-Service, nach Fertigstellung der lokalen Funktionalität für das REQ-001 auf dem Client, um die Möglichkeit ein Foto hochzuladen erweitert werden. Leider erwies es sich als unmöglich das Foto zusammen mit den XML-Daten automatisch von Grails verarbeiten zu lassen. 28

38 3. Entwicklung REQ-001 Foto aufnehmen offen Situation: Der Nutzer steht vor einem bisher unerfassten Objekt und will es in die Datenbank aufnehmen. Ergebnis: Ein Foto auf dem das Objekt klar zu erkennen ist befindet sich in der Datenbank. Der weitere Prozess wird durch das Hochladen des Fotos nicht unterbrochen, da der Upload im Hintergrund erfolgt. Benutzer: Erfasser Abbildung 10.: Foto aufnehmen (REQ-001) Daher müssen die Daten und das Foto zu einem Grabstein mit zwei separaten Anfragen gespeichert werden. Beispielsweise kann der Grabstein innerhalb einer POST- Anfrage zuerst mit einem Foto angelegt werden und anschließend um die im vorherigen Abschnitt erwähnten Daten, durch eine PUT -Anfrage ergänzt werden. bi. Gravestone = [ images : [ l a r g e : [ s c a l e : [ width : , h e i g h t : , type : ScaleType.APPROXIMATE] ], s m a l l : [ s c a l e : [ width : 3 2 0, h e i g h t : 4 8 0, type : ScaleType.APPROXIMATE ] ] ], c o n s t r a i n t s : [ n u l l a b l e : true, contenttype : [ image /png, image / j p e g ] ] ] Quelltext 9: Konfiguration burning-image Plugin mit domänenspezifischer Sprache Für eine automatische Erzeugung eines kleineren Vorschaubildes wird das Grails Plugin burning-image genutzt, welches diese Aufgabe mit einer domänenspezifischen Sprache für die Konfiguration erheblich vereinfacht. (Quelltext 9) Im Prototyp werden die Fotos direkt in der genutzten Datenbank gespeichert. Sollte die Applikation in einem Umfeld mit sehr vielen Grabsteinen eingesetzt werden, so lässt sich die Strategie mit geringem Aufwand auf eine Speicherung im Dateisystem umstellen Entwicklung der mobilen Applikation Für die Entwicklung der mobilen Applikation wurde die Entwicklungsumgebung Eclipse in der Version 3.5 zusammen mit dem Android SDK in der Version 2.2 verwendet. Zusätzlich musste eine aktualisierte Version der Apache HTTP Client Bibliothek eingebunden werden. Eine Anforderung, die Möglichkeit hebräische Zeichen 29

39 3. Entwicklung einzugeben sowie Unterstützung in Form einer Tabelle mit den hebräischen Buchstaben, konnte nicht erfüllt werden, da das verfügbare Test-Gerät keine Schriftart mit hebräischen Zeichen hatte. Eine Recherche ergab, dass die Eingabe hebräischer Zeichen nach Installation einer speziellen On-Screen Tastatur grundsätzlich möglich ist. Durch die Nutzung der UTF-8 Kodierung unterstützt MAEBO mit einer passenden Schriftart demnach auch hebräische Schriftzeichen. In den nächsten vier Abschnitten werden die zentralen Schritte der Entwicklung beschrieben. Wie bei der Server Anwendung wird der geschriebene Quelltext durch begleitende Kommentare sowie ein Dokument im JavaDoc Format auf der beiliegenden CD erläutert Zugriff auf den Web-Service Der Zugriff auf den Web-Service der Server Anwendung wurde im nächsten Schritt implementiert. Zur Kommunikation mit dem Server wurde die Apache Bibliothek HTTP Client in der Version 4.0 benutzt. Die Bibliothek bietet umfangreiche Kontrolle über alle Aspekte des HTTP-Protokolls, erfordert allerdings einen höheren Konfigurationsaufwand als die in den Java Standard-Bibliotheken enthaltene Klasse URLConnection. Aus diesem Grund wird die komplexe Konfiguration der konkreten Klasse durch die Klasse MaeboHttpClientFactory gekapselt. Diese Klasse ist in MAEBO mit dem Entwurfsmuster Singleton 2 implementiert. Somit steht der Anwendung jederzeit genau eine Instanz zum Zugriff auf HTTP Ressourcen zur Verfügung und es müssen bei einem Netzwerkzugriff weniger Objekte neu instanziiert werden. Parsing von XML Neben der Kommunikation zum Server muss die zu übertragende Ressource von der Repräsentation als Java Objekt in das vom Server lesbare XML-Format umgewandelt werden. Android bietet, wie bereits im Kapitel Grundlagen erwähnt, mehrere Bibliotheken welche diese Aufgabe erfüllen. Die Bibliotheken lassen sich in 2 Vgl. Gamma, Helm und Johnson 2009, S. 157 ff. 30

40 3. Entwicklung drei Kategorien einordnen: Dokumentenbasierte Parser Ereignisbasierte Parser Pull Parser Dokumentenbasierte Parser lesen den kompletten Datenstrom und bauen die komplette Baumstruktur des XML-Dokuments im Speicher auf, ein Nachteil wenn nur bestimmte Bereiche benötigt oder die Daten ohnehin in eine eigene Datenstruktur aufgenommen werden. Wird nur ein Teil der Daten benötigt, bieten ereignisbasierte Parser den Vorteil, dass nicht das komplette Dokument gelesen werden muss. 3 Für MAEBO muss in jedem Fall der komplette Datenstrom ausgelesen werden. Der Mehraufwand für die Erzeugung der vollständigen Baumstruktur sollte aber vermieden werden. Daher wurde mit dem XmlPullParser aus der Android-Bibliothek ein Parser der dritten Kategorie verwendet. Bei einem Pull Parser wird zwar jeder Tag gelesen, die Erstellung einer Datenstruktur jedoch dem umgebenden Quelltext überlassen. Ein Pull-Parser ist nützlich, wenn Sie fast alle Ereignisse auch verarbeiten müssen. [... ] oder eine Datenstruktur zur späteren Verwendung aufbauen - die dann vermutlich kleiner ausfällt als eine durch einen Baum-Parser erstellte. 4 Vollständige REST Anfrage Der Zugriff auf den Web-Service mit dem HTTPClient und der statischen Klasse MaeboXmlSerializer, die sämtliche Serialiserungs- und Deserialisierungs-Funktionen enthält, ist in der Abbildung 11 in einem UML Sequenzdiagramm dargestellt. Die Klasse RestMethod enthält sämtliche Methoden, die eine Anfrage an den Web- Service stellen. Die Namensgebung der Methoden richtet sich nach der jeweiligen Operation im REST Paradigma und der Domänenklasse, die übertragen werden 3 Vgl. Richardson und Ruby 2007, S. 42 ff. 4 Richardson und Ruby 2007, S

41 3. Entwicklung soll. Für die Klasse Gravestone existieren derzeit die Methoden postgravestone, putgravestone und getgravestone. Abbildung 11.: Sequenzdiagramm: Erzeugen eines Grabsteins über den Web-Service In der Abbildung 11 ist dargestellt wie ein Grabstein mit der Methode postgravestone (4) auf dem Server erstellt wird. Zunächst wird eine Instanz der passenden HTTP Methode erzeugt (6) und die Domänenklasse in der Klasse MaeboXmlSerializer in das XML-Format serialisiert (7). Der erzeugte String wird nun mit der zuvor erzeugten Methode über den HttpClient an den Web-Service geschickt (9). Die Antwort der Server Anwendung wird anschließend ebenfalls über den MaeboXmlSerializer in eine ContentValues Klasse umgewandelt (10), die später einfach in ein Domänenobjekt umgewandelt oder in der Datenbank abgespeichert werden kann. Ein Refactoring für diesen Ablauf, dass für zukünftige Versionen eine größere Flexibilität bei der Wahl des Austauschformates zulässt wäre, die Einführung einer Schnittstelle für die Serialisierung. Durch die Realisierung der Operationen über eine Schnittstelle anstatt der expliziten Klasse MaeboXmlSerializer, könnte das Format flexibler den Anforderungen angepasst werden. 32

42 3. Entwicklung Test Für einen großen Teil der Funktionalität, die durch ein Sequenzdiagramm in der Abbildung 11 dargestellt ist, ist leider kein vom restlichen System isolierter Test mit JUnit möglich, da der Netzwerkzugriff auf den Server erfolgt. Beim TDD sollte ein Test aber möglichst nicht vom Zustand eines anderen Systems, welches nicht innerhalb der Testumgebung kontrollierbar ist, abhängen. Daher wäre hier die korrekte Lösung, einen HTTP Client zu implementieren der den Netzwerkzugriff nur vortäuscht und vorgefertigte Daten zurückliefert. Aufgrund des zusätzlichen Implementierungsaufwands wurde im Prototyp auf diesen Test verzichtet. Die Klasse MaeboXmlSerializer lässt sich allerdings einfach mit einem normalen Unit Test und vorgefertigten Testdaten im XML-Format gemäß TDD testen. Der Quelltext 10 zeigt einen Auschnitt aus dem erstellten Unit Test, der überprüft ob ein im XML-Format vorliegendes Gravestone Objekt korrekt eingelesen wird. private fi na l static String GRAVESTONE_XML = "<?xml version =\"1.0\" encoding =\"UTF 8\"?> " +"<gravestone id =\"15\" version =\"3\"> " +"<cemetery id =\"1\"/> " +"<condition >condition </condition >" +"<depth >5</depth>" +"<form>form</form>" +"<h e i g h t >42</h e i g h t >" +"<i n s c r i p t i o n s ></i n s c r i p t i o n s >" +"<l o c a t i o n ></l o c a t i o n >" +"<material >\u05d7 Material </material >" +"<remarks>remarks </remarks>" +"<r e s t o r a t i o n >RestÖration </ r e s t o r a t i o n >" +"<symbols>symbol</symbols>" +"<width >23</width>" +"</g r a v e s t o n e >" ; public void testreadgravestonefromxml ( ) { try { ContentValues gravestonemodel = MaeboXmlSerializer. readmodelfromxml (new ByteArrayInputStream ( GRAVESTONE_XML. g e t B y t e s ( "UTF 8" ) ), Gravestone.TABLE_NAME) ; a s s e r t N o t N u l l ( gravestonemodel ) ; a s s e r t E q u a l s ( 15, gravestonemodel. getaslong ( Gravestone.REMOTE_ID_COLUMN). longvalue ( ) ) ; a s s e r t E q u a l s ( 3, gravestonemodel. getaslong ( Gravestone.REMOTE_VERSION_COLUMN). longvalue ( ) ) ; a s s e r t E q u a l s ( " c o n d i t i o n ", gravestonemodel. g e t A s S t r i n g ( Gravestone.CONDITION_COLUMN) ) ; a s s e r t E q u a l s ( " form ", gravestonemodel. g e t A s S t r i n g ( Gravestone.FORM_COLUMN) ) ; [... ] } catch ( UnsupportedEncodingException e ) { f a i l ( e. getmessage ( ) ) ; } catch ( X m l P u l l P a r s e r E x c e p t i o n e ) { f a i l ( e. getmessage ( ) ) ; } catch ( IOException e ) { f a i l ( e. getmessage ( ) ) ; } } Quelltext 10: Unit Test der Deserialisierung 33

43 !"# $%&'(&)) *&' *&+& (E+&' /3))1,- )./ H- +./ 4- +./..01I- <-!"# 0%&' &0,,- (.=.> & A+'.+BC- DE.&) &0 B-)+7E J-)+7E.=.> '. BF- (&))8=+ )&G.&) 3. Entwicklung Synchronisation mit einem Content Provider Um nicht ständig auf eine Internetanbindung angewiesen zu sein und dem Benutzer eine flüssige Bedienung zu ermöglichen, wurde bei der Implementierung der Datenstrukturen in der mobilen Applikation, wie bereits im Kapitel erwähnt, eine Strategie für die Synchronisation der lokalen Daten mit den Daten auf dem Server verwendet. Generell ist es bei einer Android-Applikation snnvoll länger laufende Prozesse in eine Service Klasse auszulagern. 5 Daher wurde auch bei MAEBO für die Synchronisierung ein Service benutzt. Dieser Service stellt der Applikation die vier Operationen (GET, POST, PUT, DELETE) auf beliebigen Daten, die im Content- Provider von MAEBO gespeichert sind zur Verfügung. Abbildung 12.: Service API für eine REST Client Applikation in Android (Dobjanschi 2010, S. 17) Die Abbildung 12 zeigt eine Architektur, die ein Mitarbeiter des Unternehmens Google auf der Entwicklerkonferenz Google I/ vorgestellt hat. 6 Die Implementierung der Synchronisation bei MAEBO wurde an diese Architektur angelehnt. 5 Vgl. Applikation Fundamentals. 6 Vgl. Dobjanschi

44 3. Entwicklung Die Klasse SyncService vereinigt, abweichend von der Abbildung 12, die Funktionen der Klassen Service Helper, Service sowie Processor. Die Klasse RestMethod wurde bereits im Kapitel vorgestellt und die Klassen CursorAdapter sowie Activity gehören zur Benutzeroberfläche. Diese Klassen werden daher an dieser Stelle nicht weiter erläutert. Von der Klasse ContentProvider wurde eine abgeleitete Variante MaeboContentProvider erstellt, die als Schnittstelle zur SQLite Datenbank und den Fotos auf der SD-Karte dient. Gravestone gravestone = Gravestone. getnewinstancefromuri ( getcontentresolver ( ), contenturi ) ; s e t S t a t e G e t t i n g ( g r a v e s t o n e. g e t U r i ( ) ) ; try { ContentValues g r a v e s t o n e V a l u e s = restmethod. g e t G r a v e s t o n e ( g r a v e s t o n e ) ; doupdatelocalgravestone ( gravestone, gravestonevalues ) ; } } catch ( RestMethodFailedException e ) { Log.w( S y n c S e r v i c e.tag, "GET Request f a i l e d with HTTP s t a t u s " + e. statuscode, e ) ; throw new MaeboSyncException ( e ) ; } s e t S t a t e S y n c e d ( c o n t e n t U r i ) ; Quelltext 11: Verkürzte Methode aus der Klasse SyncService Der Quelltext 11 verdeutlicht den Ablauf bei der Synchronisation eines Gravestone-Objektes. Um die Idee zu verdeutlichen, ist der Quelltext gegenüber der echten Implementierung stark verkürzt. Zunächst werden die im lokalen ContentProvider gespeicherten Daten in eine Gravestone-Instanz geladen und der Status Getting geändert. Der Status einer Domänenklasse existiert nur in der mobilen Applikation und wird in der Datenbank verwaltet. Die Synchronisation läuft asynchron zur restlichen Applikation und es existiert keine Möglichkeit zwischen der Applikation und der Klasse SyncService zu kommunizieren. Durch den Status der Domänenklasse kann die Applikation auf den Zustand der Synchronisation reagieren und beispielsweise einen Ladebalken anzeigen. Wenn die Applikation bei Ende der Synchronisation benachrichtigt werden muss, bietet der ContentProvider die Möglichkeit über einen ContentObserver nach dem Observer-Pattern über Änderungen im Datenbestand informiert zu werden. Der typische Ablauf einer Synchronisation erfolgt in den folgenden Schritten: 1. ContentObserver auf die Uri des Grabsteins registrieren 2. Über den ContentResolver Änderungen am Grabstein vornehmen 3. Den SyncService mit Angabe der Uri des Grabsteins starten 4. Bei Benachrichtigung durch den ContentObserver auf die Änderungen reagieren 35

45 3. Entwicklung Im SyncService wurde das im Kapitel erwähnte Refactoring Replace Error Code with Exception angewendet. Zuerst hat die Methode getgravestone bei einem Fehler der Wert NULL zurückgeliefert und der umgebende Quelltext musste eine Fallunterscheidung durchführen. Damit wurde der Quelltext einerseits komplizierter zu lesen und andererseits konnte die Fehlermeldung nicht an den aufrufenden Quelltext weitergeleitet werden. Nach dem Refactoring ist der Quelltext besser lesbar und durch eine abgeleitete Exception-Klasse, kann mit dem Aufruf e.statuscode auf einen aussagekräftigen Fehlercode zugegriffen werden Auto-Vervollständigung für Eingabefelder REQ-004 Nachschlagen von bereits erfassten Materialien offen Situation: Der Nutzer will ein Material eingeben und hat eine Liste der bereits erfassten Materialien angefordert. Ergebnis: Eine Liste der bereits erfassten Materialien wird angezeigt und der Nutzer kann ein Material durch Anwählen in das Textfeld hinzufügen. Benutzer: Erfasser Abbildung 13.: Nachschlagen von bereits erfassten Materialien (REQ-004) Für die geforderte Funktionalität, bereits eingegebene Werte nachschlagen zu können, steht im Android SDK das vorgefertigte Oberflächen-Element (Widget) MultiAutoCompleteTextView zur Verfügung. MultiAutoCompleteTextView erweitert die üblicherweise für Text-Eingabefelder verwendete Klasse EditText um eine Schnittstelle zur Anbindung von Wörterlisten für die Vervollständigung des eingegebenen Textes. private static f in a l String TOKEN_REGEX = " (, ) " ; private List <String> buildautocompleteindex ( Cursor c, int columnindex ) { // Assuming t h e r e are an average of 2 words in each column Set<String> indexset = new HashSet<String >(c. getcount ( ) 2 ) ; c. movetofirst ( ) ; while ( c. movetonext ( ) ) { i f (! c. i s N u l l ( columnindex ) ) { S t r i n g [ ] explodedvalue = c. g e t S t r i n g ( columnindex ). s p l i t (TOKEN_REGEX) ; i n d e x S e t. addall ( Arrays. a s L i s t ( explodedvalue ) ) ; } } return new ArrayList<String >( indexset ) ; } Quelltext 12: Aufbau des Vervollständigungs-Index 36

46 3. Entwicklung Abbildung 14.: Auto-Vervollständigung in Aktion Zur Erzeugung der Wortliste wurden alle bereits im lokalen Speicher des Smartphones vorhandenen Werte für das derzeit editierte Feld abgerufen und an Kommas sowie Leerstellen aufgetrennt. Der Inhalt brüchiger Stein ergibt also die Liste [ brüchiger, Stein ]. Die aufgetrennten Fragmente werden anschließend zur Vermeidung von Duplikaten in ein HashSet eingefügt und dann an das MultiAutoCompleteTextView Widget weiter gegeben. Auf der Oberfläche erscheinen die Vorschläge nach dem Eintippen von zwei Buchstaben in einer Liste unterhalb des Eingabefeldes. (Abbildung 14) Positionsbestimmung mit GPS und Kompass Entwurf Für die Umsetzung der Anforderung REQ-009 (Erfassen der Position des Grabsteines) wurden beim Entwurf der Software verschiedene Varianten durchdacht. Der erste Entwurf sah vor, ähnlich wie im Kapitel beschrieben, die Richtung zu den Grabsteinen in der direkten Nachbarschaft in einem 9-Felder-Raster (Abbildung 16) und über einen Dialog oder ein Eingabefeld die Entfernung zu erfassen. 37

47 3. Entwicklung REQ-009 Erfassen der relativen Position des Grabsteins offen Situation: Eine Geo-Koordinate mit der Genauigkeit des GPS ist bekannt. Nun soll diese Messung durch eine Bestimmung der Position relativ zu bereits erfassten Grabsteinen verbessert werden. Ergebnis: Die relative Position des Grabsteins in Bezug zu seinen direkten Nachbarn ist erfasst. Wenn möglich soll die Geo- Koordinate durch diese Information verbessert werden. Benutzer: Erfasser Abbildung 15.: Erfassen der relativen Position des Grabsteins (REQ-009) Zwar wäre die Benutzeroberfläche für diese Variante einfach zu implementieren und hätte durch das statische 9-Felder-Raster eine einfache Bedienung, bei der durch den Klick auf ein leeres Feld eine Liste mit allen verfügbaren Grabsteinen geöffnet wird und der benachbarte Grabstein durch einen Klick in das 9-Felder-Raster übernommen werden kann. Allerdings gäbe es keine Möglichkeit die Entfernung zwischen den benachbarten Grabsteinen zu visualisieren und die Auswahlliste könnte mit steigender Zahl der erfassten Grabsteine unübersichtlich werden. Abbildung 16.: Orientierung in einem 9-Felder-Raster erfassen Der Implementierung eines 9-Felder-Rasters steht ein weiterer großer Nachteil entgegen. Der Benutzer erhält durch das statische 9-Felder-Raster keine unmittelbare Rückmeldung, welche Auswirkungen seine Eingaben auf die später generierte Karte haben. Daher ist die Gefahr gegeben, dass menschliche Fehler bei der Eingabe zu- 38

48 3. Entwicklung nächst unentdeckt bleiben oder aufgrund der abstrakten Darstellung die Aktzeptanz beim Anwender fehlt. Abbildung 17.: Positionsbestimmung mit GPS Der zweite Entwurf verwendet anstatt eines 9-Felder Rasters ein vollständiges Koordinatensystem, das auf dem Bildschirm dargestellt wird. Die Mitte der Zeichenfläche repräsentiert den über GPS ermittelten, aktuellen Standpunkt des Smartphones. Auf die umgebende Zeichenfläche werden die bereits erfassten Grabsteine in der Umgebung des Smartphones eingezeichnet. Da im Prototyp noch keine Karte oder Satellitenbild zum Einsatz kommt, wird zur Orientierung ein Raster sowie dessen aktueller Maßstab eingezeichnet. Der Umfang des dargestellten Umkreises um die aktuelle Position und die Rasterauflösung lässt sich über zwei Lupen-Symbole verändern. Zur Information des Benutzers erscheinen die derzeit aktiven technischen Werte aktuelle Himmelsrichtung, Breite der dargestellten Fläche, aktueller Breitengrad, aktueller Längengrad sowie die Ungenauigkeit der Positionsangabe in der Kopfzeile. Bereits erfasste Grabsteine werden als kleine Kreise mit ihrer lokalen ID-Nummer eingezeichnet. Der gerade bearbeitete Grabstein erscheint als etwas fingergroßer grüner Punkt in der Mitte, also auf der derzeit ermittelten GPS-Koordinate. (Abbildung 17) 39

49 3. Entwicklung Dieser Bildschirm ermöglicht dem Nutzer, sämtliche Informationen über die bereits erfasste Umgebung des Grabsteines auf einen Blick zu sehen. Sind bereits mehrere Grabsteine in der Nähe erfasst und bilden diese eine Reihe, oder optimalerweise eine markante geometrische Form, so sollte es möglich sein, diese Form auf dem Bildschirm zu erkennen. Durch die Zentrierung auf die aktuelle GPS-Koordinate entspricht die dargestellte Umgebung im Rahmen einer Genauigkeit von 5-10 Meter der realen Umgebung des Benutzers. Mit den Daten aus dem, in den meisten Android Smartphones integrierten, elektronischen Kompass wird die Ausrichtung des Gerätes gemessen und die Grabsteine werden auf der Zeichenfläche entsprechend rotiert, sodass die im oberen Bereich gezeigten Objekte wie in der Realität vor dem Benutzer liegen. Abbildung 18.: Positionsbestimmung mit Verbesserung durch den Nutzer Stimmt die automatisch durch das GPS bestimmte Koordinate nicht mit der Realität überein, so hat der Benutzer die Möglichkeit durch ein längeres Verweilen mit dem Finger auf dem grünen Punkt, signalisiert durch eine kurze Vibration, die Position des erfassten Grabsteins beliebig zu ändern. Bei einer passenden Zoomstufe lässt sich der Grabstein somit mit einer Genauigkeit von unter einem Meter auf der Zeichenfläche platzieren. Als Platzierungshilfe beim Verschieben wird während der Grabstein mit dem Finger verschiebbar ist, ein größerer Kreis um die aktuelle Position auf der Zeichenfläche angezeigt. Während des Verschiebens eines Grabsteines ist 40

50 3. Entwicklung sowohl die Rotation durch den Kompass, als auch die Positionsbestimmung durch das GPS pausiert, damit der Benutzer das Objekt besser an der gewünschten Stelle platzieren kann. (Abbildung 18) Berechnung Für die technische Umsetzung dieses Entwurfs war der Zugriff auf die GPS- und Kompass-Daten aus dem Android-Framework sowie die Umrechnung der GPS-Koordinaten aus dem dreidimensionalen WGS-84 Koordinatensystem in das zweidimensionale Koordinatensystem der Zeichenfläche nötig. Weiterhin wurde die Berechnung der Rotation um die vom Kompass gelieferten Daten implementiert. Der folgende Quelltext 13 enthält einen Auszug der notwendigen Mercator Projektion, mit der eine winkeltreue Umrechnung möglich ist, die aber auf einer großen Skala gesehen nicht flächentreu abbildet. Die Verzerrung der Fläche auf einer großen Skala und insbesondere in der Nähe des Nord- und Südpols ist für den Anwendungsbereich von MAEBO aber irrelevant. private s t a t i c double [ ] mercatorprojection ( double longitude, double l a t i t u d e ) { double [ ] t r a n s f o r m e d P o i n t = new double [ 2 ] ; transformedpoint [ 0 ] = Math. toradians ( longitude ) EARTH_RADIUS_A; transformedpoint [ 1 ] = gudermannfunctioninverse ( l a t i t u d e ) EARTH_RADIUS_B; return transformedpoint ; } public s t a t i c double gudermannfunctioninverse ( double l a t i t u d e ) { double s i n = Math. s i n ( Math. toradians ( l a t i t u d e ) ) ; return Math. l o g ( ( 1 + s i n ) / ( 1 s i n ) ) / 2 ; } Quelltext 13: Mathematische Grundlagen der Positionsbestimmung Der Längengrad (Longitude) wird mit dem Erdradius am Äquator multipliziert. Der Breitengrad (Latitude) wird zuerst mit dem Inversen der Gudermann-Funktion projiziert und das Ergebnis mit dem Erdradius in Polrichtung multipliziert. 7 Außerhalb des gezeigten Quelltextauschnittes wird das Ergebnis anschließend noch auf die aktuelle Zoomstufe skaliert und der Mittelpunkt des Koordinatensystems in die Mitte des Bildschirms verschoben. Wird der grüne Punkt, also der aktuell erfasste Grabstein, verschoben, so wird, solange der Benutzer den Punkt verschiebt, im lokalen Koordinatensystem gerech- 7 Vgl. Mercator Projection. 41

51 3. Entwicklung net. Platziert der Benutzer den Grabstein durch Loslassen des Punktes neu, wird automatisch die Position im WGS-84 Referenzsystem mit der inversen Formel neu berechnet. Zusätzlich zur Transformation von WGS-84 Koordinaten in das lokale Koordinatensystem auf den Bildschirm werden alle dargestellten Grabsteine nach der aktuellen Himmelsrichtung rotiert. Das Android Framework liefert vom elektronischen Kompass Werte von 0 bis 360. Der folgende Quelltext 14 berechnet die Rotation eines Punktes auf dem Bildschirm für den übergebenen Winkel. private s t a t i c double [ ] rotatebyazimuth ( double xonview, double yonview, double azimuthradians ) { double [ ] r o t a t e d P o i n t = new double [ 2 ] ; rotatedpoint [ 0 ] = xonview Math. cos ( azimuthradians ) + yonview Math. s i n ( azimuthradians ) ; r o t a t e d P o i n t [ 1 ] = xonview Math. s i n ( azimuthradians ) + yonview Math. cos ( azimuthradians ) ; return rotatedpoint ; } Quelltext 14: Rotation um Himmelsrichtung Grafische Umsetzung Für zweidimensionale grafische Darstellungen, die mit den Standard Komponenten von Android nicht realisierbar sind, gibt es zwei Möglichkeiten Die Verwendung der Klasse SurfaceViews, wenn es nötig ist, die Zeichenoperation von einem zweiten Thread aus durchzuführen. 2. Das Erstellen einer von View abgeleiteten Klasse und Zeichnen im UI-Thread über die überschriebene View.onDraw() Methode. Um die in der Klasse View enthalteten Methoden für die Erkennung von Benutzereingaben verwenden zu können und weil keine umfangreichen Zeichenoperationen durchgeführt werden müssen, wurde die zweite Option realisiert. Damit die Instanzen der von View abgeleiteten Klassen auf dem Bildschirm frei positioniert werden können, musste zusätzlich ein neuer Layout Manager von der Klasse FrameLayout abgeleitet werden. 9 Diese Klasse verzichtet auf eine bestimmte Anordnung der enthaltenen Views und zeichnet diese alle in der Reihenfolge des Einfügens in die obere 8 Vgl. Graphics. 9 Vgl. How Android Draws Views. 42

52 3. Entwicklung linke Ecke des Bildschirms. Daher ist FrameLayout ein guter Ausgangspunkt für eine eigene Implementierung. Abbildung 19.: Klassendiagramm UI der Positionsbestimmung Wie in Abbildung 19 ersichtlich ist, gibt es in MAEBO mit CurrentGravestoneView und SavedGravestoneView zwei neue View Klassen die über das neue LocationFrameLayout gezeichnet werden. Die beiden weiteren von View abgeleiteten Klassen LocationAwareView sowie MovableLocationAwareView sind abstrakt und dienen der objektorientierten Kapselung der neu eingeführten Eigenschaften. Die Positionierung der Views geschieht in der onlayout Methode des LocationFrameLayout abhängig von der Klasse und dem Zustand des Views. Dies wird im Aktivitätsdiagramm in der Abbildung 20 gezeigt. 43