Entwicklung einer Mobilen Applikation für die Präsentation tunnelbauspezifischer Daten in einer dokumentenbasierten Datenbank

Entwicklung einer Mobilen Applikation für die Präsentation tunnelbauspezifischer Daten in einer dokumentenbasierten Datenbank Schriftliche Prüfungsarbeit für die Bachelor-Prüfung des Studiengangs Angewandte Informatik an der Ruhr-Universität Bochum vorgelegt von Schemberg, Sebastian 108 009 201 418 Abagebdatum 17.04.2013 Pr. Dr. Markus König Dr. Karlheinz Lehner

Erklärung Ich erkläre, dass das Thema dieser Arbeit nicht identisch ist mit dem Thema einer von mir bereits für ein anderes Examen eingereichten Arbeit. Ich erkläre weiterhin, dass ich die Arbeit nicht bereits an einer anderen Hochschule zur Erlangung eines akademischen Grades eingereicht habe. Ich versichere, dass ich die Arbeit selbstständig verfasst und keine anderen als die angegeben Quellen benutzt habe. Die Stellen der Arbeit, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen sind, habe ich unter Angabe der Quellen der Entlehnung kenntlich gemacht. Dies gilt sinngemäß auch für gelieferte Zeichnungen, Skizzen und bildliche Darstellungen und dergleichen. Datum Unterschrift 2

Inhaltsverzeichnis 1Einleitung...4 1.1Motivation...4 1.2Problemstellung...4 1.3Zielsetzung...4 2Hintergrund...5 2.1CouchDB...5 2.1.1Allgemeines...5 2.1.2JSONDokument...6 2.1.3MapReduce Prozedur...7 2.1.4Struktur der in der Arbeit verwendeten CouchDB Dokumente...8 2.1.5Beispiel...9 2.2Android-SDK...13 2.2.1Eigenschaften des Android SDK...13 2.2.2Layouts...13 2.2.3Beispiel...15 3Konzept...16 3.1Grundidee...16 3.2Anforderungen : Lastenheft...17 3.3Systemarchitektur : UML...18 4Implementierung...19 4.1Applikation Design...19 4.2Klassenarchitektur...20 4.2.1Util...21 4.2.2StartActivity...21 4.2.3AdminMainActivity...23 4.2.4UserMainActivity...24 4.2.5Bodeninformationen...25 4.2.6MaterialDocumentView...27 5Anwendungsbeispiel...29 6Schlussbetrachtung...31 7Literaturverzeichnis...32 8Bildquellen...32 9Abbildungsverzeichnis...33 10Listingverzeichnis...33 3

1 Einleitung 1.1 Motivation Der Tunnelbau ist ein komplexer Vorgang, der sich vielfach die jahrtausendealten Erkenntnisse des Bergbaus zu Nutze macht [1]. Um einen Tunnel bauen zu können, werden viele verschiedene Daten benötigt. Es müssen Daten zur Materialumgebung vorhanden sein. Ohne diese Daten kann das Bauvorhaben und die Sicherung des Tunnels nicht gewährleistet werden [1]. Weitere Daten beschäftigen sich mit den einzelnen Tunnelsegmenten, der Geometrie der Umgebung oder mit der Tunnelbohrmaschine. Es fallen demnach eine ganze Menge an Daten an, die zur Planung und Ausführung des Tunnelbaus benötigt werden. Diese Daten werden in einer Datenbank gespeichert. Bei diesen speziellen Daten bieten sich dokumentenbasierte Datenbanken an. In diesen können gezielt Attribute gesetzt werden ohne Speicherplatz zu verschwenden. 1.2 Problemstellung Die Problematik besteht nun darin, dass von überall auf diese Daten zugegriffen können werden muss. Der Ingenieur muss demnach entweder alles auf Papier dabei haben oder es im Laptop nachschauen. Und dies wenn der Ingenieur zum Beispiel mitten auf der Baustelle ist. Eine weitere Möglichkeit ist der Zugriff auf die Datenbank via Internet des Smartphones. Es könnte also über die Browserobefläche auf die Daten zugegriffen werden. Das Laden der Seiten und die Bedienung könnte jedoch zu umständlich sein und demnach zu lange dauern. Eine Lösung ist also eine Applikation für ein mobiles Endgerät wie ein Smartphone oder ein Tablet. 1.3 Zielsetzung Diese Bachelorarbeit befasst sich demnach mit dem Thema der Entwicklung einer Mobilen Applikation zur Präsentation tunnelbauspezifischer Daten in einer dokumentenbasierten Datenbank. Als Plattform für die Applikation wird das Android Betriebssystem gewählt. Es wird eine Applikation geschrieben, die auf die CouchDB Daten zugreift und diese visuell wiedergibt. Um dies zu erreichen stellt die Applikation eine Verbindung zum CouchDB Server her. Diese Verbindung läuft über das Internet. Damit die Daten auch schnell zu finden und leicht zu lesen sind, werden verschiedene Layouts für verschiedene Daten verwendet. Diese Layouts sind in Views der Datenbank vordefiniert. 4

Die Applikation mach sich die Views zu Nutze um Filter zu implementieren, die die Suche nach den Daten vereinfacht. 2 Hintergrund 2.1 CouchDB 2.1.1 Allgemeines CouchDB ist eine dokumentenbasierte Datenbank, welche die angelegten Daten in Dokumenten im JSON Format speichert [2]. Diese Dokumente werden als.couch Dateien auf dem Server oder Rechner, auf dem die CouchDB installiert ist hinterlegt. Es können demnach Datenbanken importiert oder gelöscht werden, ohne auf die CouchDB direkt zugreifen zu müssen. Der Vorteil dieser Art der Speicherung ist eine variable Gestaltung der Dokumente ohne festes Schema. In relationalen Datenbanken, wie mysql, werden Daten in Tabellen, Zeilen und Spalten in der Datenbank angelegt [2]. Soll ein Attribut bei einem Dokument der Datenbank hinzugefügt werden, muss es demnach auch bei allen hinzugefügt werden. Dieser Null Eintag der bei manchen Dokumenten dann entstehen kann verbraucht Speicher. Dieser Speicherverlust fällt bei den dokumentenbasierten Datenbanken nicht an. CouchDB verwendet zudem die MapReduce Prozedur von Google [2],[3]. Genauere Informationen zu dieser Prozedur folgen im Kapitel 2.1.3. Der Zugriff auf die CouchDB erfolgt über die REST-HTTP Schnittstelle. Dieser Zugriff kann direkt oder indirekt ausgeführt werden. Der indirekte Zugriff läuft über Bibliotheken und Clients, die für viele klassische Programmiersprachen vorhanden sind. PHP und Java Script sind solche Sprachen, die den Zugriff auf die Daten standardisieren. Die Daten können aber auch direkt ohne einen zusätzlichen Webserver an den Browser gesendet werden. Dazu stellt CouchDB die Benutzeroberfläche Futon zur Verfügung. Dieser Absatz bezieht sich auf die Quelle [2] auf die Informationen über Zugriff und Schnittstellen. Ein weiteres Merkmal der CouchDB ist die Multiversion Concurrency Control. Diese verhindert Lese-Schreibblockaden, indem sie alte Versionen beim Speichern nicht überschreibt. Jedes JSON Dokument bekommt beim speichern einen rev String. Dieser ändert sich beim erneuten Speichern an der ersten Stelle. Ein Vorteil dieser Methode ist, dass ältere Versionen anhand des rev Strings identifiziert und wiederhergestellt werden können [2]. Laut Quelle [2] werden beim Replizieren die alten Versionen nicht weitergegeben, was eine Versionsverwaltung ausschließt. 5

Die CouchDB kann von Quelle [4] heruntergeladen werden. 2.1.2 JSONDokument Die Spezifikationen für das JSON Dokument sind der Quelle [5] entnommen. Zahlen double precision floating-point format in JavaScript, das hängt hauptsächlich von der Implementierung ab. Strings double-quoted Unicode, mit Backslash Endung Boolean true und false Werte Arrays eine sortierte Ansammlung von Werten, die durch Kommata getrennt und in eckigen Klammern eingeschlossen sind, die Werte müssen nicht vom selben Typ sein Objekte unsortierte Ansammlung von Schlüssel : Wert paaren, bei denen der : den Schlüssel von dem Wert trennt, Kommata trennen Objekte voneinander, sie sind in geschweifte Klammern gefasst und müssen Strings sein, die voneinader unterscheidbar sein sollten null für leere Dokumente Ein JSONDokument der CouchDB erhält beim Erstellen immer eine eindeutige und einzigartige ID. Diese ist ein String bestehend aus Zahlen und Buchstaben. Beim { Speichern eines Dokuments wird eine "_id": "12345abc56", "_rev": "1-12345abc56", "type": "adressdata", "firstname": "John", "lastname": "Smith", "address": { "streetaddress": "21 2nd Street", "city": "New York",, "phonenumbers": [ { "type": "home", "number": "212 555-1234", { "type": "fax", "number": "646 555-4567" ] Listing 1 : Beispielhaftes JSONDokument 6 dazu passende, einzigartige rev erstellt. Diese ist ebenfalls ein String aus Zahlen und Buchstaben. Der rev geht eine Zahl voran die mit einem vom Rest getrennt ist. Diese erste Zahl dient der Identifikation der Version der datei. Beim erneuten Speichern wird nur diese erste Zahl um eins inkrementiert. Zu den JSONDokumenten werden meist keys wie type hinzugefügt um Dokumente zu Kategorisieren. die

Listing 1 zeigt ein Beispielhaftes JSONDokument. Dieses Beispiel ist ein einzelnes JSONObjekt, indem andere JSONObjekte und JSONArrays verschachtelt sind. Ein weiteres JSONObjekt ist zum Beispiel address. Dieses JSONObjekt enthält String Felder zur Bestimmung der Straßen Adresse und der Stadt. _id und _rev werden durch die CouchDB generiert wenn das Dokument erstellt und gespeichert wird. Das String Feld für Type dient zur Kategorisierung des Dokuments und wird vom Ersteller des Dokumentes eingefügt. phonenumbers ist in diesem beispiel ein JSONArray, welches mehrere elemente vom Anschlusstyp und der dazugehörigen Nummer enthält. Über den _rev String können frühere Versionen des Dokuments wiederhergestellt werden. 2.1.3 MapReduce Prozedur Die MapReduce Prozedur wurde von Google Inc entwickelt. Dieses Framework wurde für die nebenläufige Berechnung über große Datenmengen in Computerclustern eingeführt. Das Framework wurde von den map und reduce Funktionen, die häufig in der funktionalen Programmierung verwendet werden, inspiriert. MapReduce Implementierungen sind für mehere Programmiersprachen wie C++ oder Java vorhanden. Die Zeichnung 1 zeigt den Datenfluss der MapReduce Prozedur. Intermediate Result D MAP A MAP T MAP A MAP Reduce Output Files Zeichnung 1: Datenfluss MapReduce (BQ 1) Die Eingabedaten (Ellipsen) D, A, T, A werden einer Reihe von Map-Prozessen (Rechtecke) zugeordnet. Diese berechnen die vom Benutzer bereitgestellten MapFunktionen. Die Map-Instanzen legen dann Zwischenergebnisse (Dreiecke) ab, die in der Benutzeroberfläche Futon angeschaut werden können. Für jedes der Zwischenergebnisse 7

berechnet genau ein Reduce-Prozesse (Rauten), die vom Benutzer vordefinierte ReduceFunktion. Diese liefern dann die Ausgabedaen (Achtecke) [3]. Beispiele einer Map und einer Reduce Funktion können in Listing 2 betrachtet werden. function(doc){ if(doc.material == reinforced_concrete ) { emit(doc.type, doc.concrete_volume); Die obige Map-Funktion durchsucht alle Dokumente einer Datenbank nach dem Field material. Dieses vergleicht die Funktion dann mit dem String reinforced_concrete. Wenn function(keys,values){ return sum(values); Dokumente mit diesem String im Feld material gefunden werden, gibt die Funktion den Type und das Volumen Listing 2 : Beispiele einer Map (oben) und Reduce des Dokumentes zurück. Type und Volumen sind vom Benutzer erstellte (unten) Funktion Attribute, die das Dokument beschreiben und Kategorisieren. Type könnte in diesem Fall zum Beispiel Wand sein und das Volumen 3m³. Die Werte Type und Volumen werden als key:value an die ReduceFunktion übergeben. Diese summiert alle values von identischen keys auf, und gibt die aufsummierten Ergebnisse zurück. 2.1.4 Struktur der in der Arbeit verwendeten CouchDB Dokumente In dieser Bachelorarbeit werden verschiedene Typen von Dokumenten verwendet. Diese Typen sind Material Daten, Geometrie Daten, Tunnel Daten, Tunnelsegment Daten und Daten zur Tunnelbohrmaschine. Die Daten der Tunnelbohrmaschine sind in einer separaten Datenbank abgelegt, wohingegen die anderen Daten alle in einer Datenbank aufgeführt werden. Die in dieser Arbeit hauptsächlich betrachteten Daten sind die Material Daten. Diese enthalten Informationen zu den Bodenbeschaffenheiten der Region, in welcher der Tunnel gebaut werden soll. Diese Dokumente besitzen alle die gleiche Grundstruktur zur Anordnung der Daten. Als erstes besitzen alle Daten eine eindeutige id, rev und Typ Bezeichnung. Id und rev werden automatisch erstellt, können aber geändert werden und der Typ wird vom Benutzer generiert. Dieser dient zur Kategorisierung. Ein weiteres Feld das alle Dokumente besitzen bezeichnet den kind des Dokumentes. Ist es die tbm, gehört zu zu den syntetic Models oder sind es layer Informationen? Diese Dinge beantwortet das Feld kind. Also haben alle Dokumente 4 Felder gemein, diese sind id, rev, 8

kind und type. Die Bodeninformationen besitzen jetzt noch ein Feld Material, in dem viele unterschiedliche Daten zur Bodenbeschaffenheit aufgelistet werden. Diese wären zum Beispiel density Daten, type Daten, cohesion Daten und viele mehr. Die weiteren Oberpunkte für die Daten sind in Abbildung 1 zu sehen. Abbildung 1: Beispiel zu Daten für die Bodeninformationen Die zu sehenden Oberpunkte sind im JSONDokument meist JSONObjekte, es können aber auch JSONArays dabei sein. Discontinuities ist in diesem Beispiel ein JSONArray. Die Dokumente der Geometrie Daten besitzen auch ein material Feld. In diesem steht allerdings die id eines Material Dokumentes. Tunnelsegmente, Tunnel und die Tunnelbohrmaschine besitzen noch andere Felder, um diese zu beschreiben. Da in dieser Arbeit jedoch hauptsächlich mit den Bodeninformationen gearbeitet wird, werden diese hier nicht genauer erläutert. 2.1.5 Beispiel In diesem Abschnitt wird ein einfaches Beispiel zu CouchDB Features vorgestellt. Dieses Beispiel behandelt eine Datenbank für ein Zoofachgeschäft. In dieser Datenbank liegen 9

mehrere Dokumente, die Tiere, die zum Verkauf stehen, beschreiben. Ein Dokument dieser Datenbank könnte wie in Listing 3 aussehen. Dieses JSONDokument ist { "_id": "0f637d20772ffc37d46489bbad000683", "_rev": "23b32efad4b1b07f5d0009d7c8c2fd632", "rasse": "0f637d20772ffc37d46489bbad000b74", "type": "Hund", "alter": "Welpe", "preis in ": 450 ein JSONObjekt mit verschiedenen Strings zur Beschreibung des Tieres. Die Rasse verweist auf ein anderes Dokument, in dem man mehr Informationen zu Listing 3 : Beispielhaftes JSONDokument dieser Rasse erhält. Dieses JSONDokument enthält keine JSONArrays oder weitere JSONObjekte. Wie die einzelnen Strings ausgelesen werden können wird in einem späteren Kapitel zur Implementierung im Android-SDK beschrieben. Um das Beispiel effektiv nutzen zu können, werden 10 Dokumente genutzt. 3 Dokumente zur Beschreibung einer Rasse und 7 um das Tier zu beschreiben. In diesem Beispiel 4 Hunde und 3 Katzen. Bei den Rassen werden Schaeferhund, Perser Katze und Dackel genutzt. Nun werden sogenannte Views erstellt, die bestimmte Dokumente herausfiltern sollen. Diese Views werden durch die Map und Reduce Funktionen, die mit CouchDB genutzt werden können, erstellt. Zunächst mal wird ein View erstellt, der alle unterschiedlichen Rassen auflistet. Zwei weitere Views sollen nach Hund bzw. Katze unterscheiden. Ein letzter View listet die Preise alle Hunde auf und summiert diese auf. 10

function(doc){ function(doc){ if(doc.type == Rasse ){ if(doc.type == Hund ){ emit(doc._id, doc.type); emit(doc._id, (doc.type, doc.rasse); function(doc){ if(doc.type == Katze ){ emit(doc._id, doc.type); function(doc){ function(keys, values){ if(doc.type == Hund ){ emit(doc.type, doc.preis); return sum(values); Listing 4 : Verscheidene Map und Reduce Funktionen zum Beispiel Listing 4 zeigt die Funktionen, welche die Views erstellen. Rechts unten ist eine Reduce Funktion. Die restlichen sind Map Funktionen. Abbildung 2: Dokumente der Datenbank In der Abbildung 2 werden alle Dokumente der Datenbank angezeigt. Wird nun ein View ausgewählt, können die Daten nach einem bestimmten Kriterium angezeigt werden. Abbildung 3 zeigt alle Daten nach dem Typ Hund und gibt dazu alle Preise mit an. 11

Abbildung 3: Dokumente nach einer Map Funktion 12

2.2 Android-SDK 2.2.1 Eigenschaften des Android SDK Das Android-SDK [16] erweitert Java um einige Funktionen. In Eclipse können durch das Android-SDK Emulatoren für ein Android Gerät erstellt werden. Des weiteren können Layouts per Drag & Drop in das graphische Interface eines Gerätes gezogen werden, um so einfach und schnell ein Design für eine Applikation zu erstellen. Eine erstellte Activity für Android beinhaltet automatisch die Basisfunktionen, damit eine App laufen kann. Eine weitere Erneuerung sind die XML Dateien für die Designs, die automatisch beim Generieren einer Activity erstellt werden. Eine Activity ist ein Fenster für eine App, das Funktionen ausführt und Widgets wiedergibt. Ohne eine Activity kann eine App für Android nicht laufen. Wisgets sind die einzelnen graphischen Elemente des Designs einer App. Eine Genauere Beschreibung dazu im nächsten Kapitel. 2.2.2 Layouts Das Android-SDK bringt von Haus aus viele verschiedene Möglichkeiten mit, die App graphisch zu gestalten. Zunächst einmal werden die verschiedenen Layouts erläutert, wie Relative Layout oder Linear Layout erläutert. Beim Relative Layout kann man die Widgets frei in der App anordnen. Die Abbildung 4 beschreibt einen schematischen Aufbau für ein relative Layout. Im Linear Layout werden alle Widgets Textfeld entweder horizontal oder vertikal zueinander Button Angeordnet. In der Abbildung 5 kann ein schematischer Aufbau für ein Linear Layout gesehen werden. Das Table Layout ordnet die Widgets in Table Rows an, die wiederum in Spalten angeordnet sind. Demnach kann Radio Button 1 Radio Button 2 man mehrere Table Rows einfügen, die eine unterschiedliche Anzahl an Spalten haben können. Die Abbildung 6 beschreibt einen schematischen Aufbau für Abbildung 4: Schematischer Aufbau ein Table Layout. eines relative Layouts 13

Um diese Layouts zu füllen gibt es eine gute Textfeld Textfeld Button Anzahl an verschiedenen Widgets. Zum einen gibt es Textfelder. Bei diesen gibt es ebenfalls eine Auswahl an verschiedenen Textfeldern. Die einen kann man gut für Button Adresszeilen nutzen, andere sind für einen längeren Text geeignet, wiederum andere sind für Passwörter geeignet. Weitere Widgets sind Knöpfe. Diese gibt es in Abbildung 5: Schematischer Aufbau eines Linear Aufbau Abbildung 6: unterschiedlichen Großen. Außerdem gibt Schematischer Aufbau es Checkboxen oder Radio Buttons. Eine eines Table Layout weitere Möglichkeit die App graphisch zu gestalten ist ein Grid View. Dieser eignet sich besonders gut zu einer Miniaturdarstellung von mehreren Fotos. Listen können Inhalte von Arrays einfach und sauber darstellen. Expandable Lists enthalten Oberpunkte die beim Klick aufgeklappt werden, um die darunterliegenden Informationen anzuzeigen. Weitere Views gibt es zur Datums- und Zeitanzeige, zur Wiedergabe von Medien, Inhalten fürs Web und noch einige andere. Eine liste aller Layout Möglichkeiten findet man auf [15]. Um diese Layouts zu implementieren wird ein XML Dokument für eine Activity benötigt. Diese enthält Informationen zu den einzelnen Widgets, die im Layout benutzt werden sollen. Das Listing 5 zeigt eine solche XML Datei. <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_height="fill_parent" android:orientation="vertical" > <TextView android:id="@+id/text" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="hello, I am a TextView" /> <Button android:id="@+id/button" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="hello, I am a Button" /> </LinearLayout> Listing 5 : Beispielhaftes XML Dokument für ein Layout (Quelle [14]) Dieses XML Dokument fügt ein TextView und einen Button in das Layout ein. Diesen sollte immer eine ID mitgegeben werden, damit später auf sie zugergriffen werden kann. In der Breite und Höhe sind diese so breit und hoch wie der Inhalt. 14

2.2.3 Beispiel In diesem Abschnitt wird ein kurzes Einführungsbeispiel zur App Entwicklung für Android beschrieben. Als erstes sollte ein Emulator eingerichtet werden, sofern kein reales Android Gerät zum Testen der Applikation zur Verfügung steht. Wie man einen solchen Emulator einrichtet kann bei [6] nachgelesen werden. Nachdem dies abgeschlossen ist, muss ein Android Application Project erstellt werden. Wie dies funktioniert steht auf [ 7]. Dieses Android Projekt bekommt den Namen HelloWorld. Nun wird die XML Datei activity_main.xml geöffnet. In dieser wird der HelloWorld textview entfernt. Als nächstes werden per Drag & Drop ein EditText Feld, ein Button und ein TextView in die graphische Oberfläche gezogen. Die IDs sollten zur Erkennung der einzelnen Widgets dienen. Ist dies abgeschlossen wird die Java Datei geöffnet. Das Grundgerüst für eine Android Activity ist in Listing 6 beschrieben. Dieses Grundgerüst wird automatisch beim Erstellen einer public class Classname extends Activity{ protected void oncreate(bundle savedinstancestate){ Android Activity generiert. Als nächstes super.oncreate(savedinstancestate); müssen der Button, der setcontentview(r.layout.activity_klassenname); textview und das EditText Feld erstellt und initialisiert werden. Die Listing 6 : Grundgerüst einer Android Activity Initialisierung erfolgt in der oncreate Methode und kann in Listing 7 betrachtet werden. Die Widgets werden als View über ihre ID Button = (Button)findViewById(R.id.ButtonIDausXMLDokument); initialisiert. Die App soll am Ende den Listing 7 : Beispiel zur Initialisierung von Widgets Text, der in das EditText Feld eingegeben wurde, nach einem Klick auf den Knopf, in den TextView übertragen. Dazu muss ein onclicklistener für den Button erstellt werden. Button.setOnClickListener(new View.OnClickListener(){ public void onclick(view v){ textview.settext(edittext.gettext()); ; Listing 8 : Beispielhafter onclicklistener Dieser kann überprüfen welcher Knopf gedrückt wurde und fügt dann den text in das TextView. Wie dies genau auszusehen hat, ist in Listing 8 beschrieben. Diese Applikation ist nun fertig geschrieben. Eine fertige Ansicht der App, ist in Abbildung 7 zu sehen. 15

Abbildung 7: Fertige Beispiel App 3 Konzept 3.1 Grundidee Diese Applikation soll als erstes ein Startmenü anzeigen. In diesem soll eine Unterscheidung zwischen einem Administrator und einem Benutzer erfolgen. Diese Unterscheidung soll gemacht werden, damit später der Bauherr oder der Chef der Baufirma Daten zu ändern, zu entfernen oder zu erstellen ohne an einem PC oder Laptop setzen zu müssen. Diese Änderungen sollen auch von der Baustelle aus mit einem Smartphone oder Tablet getätigt werden können. Um zwischen einem Administrator und Benutzer zu unterscheiden, wird beim Administrator Modus eine Benutzer und Passwort Abfrage getätigt. Der Administrator Modus soll die Views der Datenbank und dann die Dokumente im JSONFormat anzeigen. Des weiteren soll der Administrator Modus zunächst mal alle vorhandenen Datenbanken anzeigen. Diese können in einer Liste angezeigt werden. Es kann nun eine Datenbank aus der Liste ausgewählt werden. Danach soll eine Auswahl der verfügbaren Views angezeigt werden. Am besten auch in einer Liste oder etwas ähnlichem, damit man sie anklicken kann. Die nächste Activity soll dann eine Liste aller Dokument IDs anzeigen. Klickt man auf eines dieser Dokumente wird das JSONDokument angezeigt. Der Administrator Modus wird in dieser Arbeit aber nur bis zur Benutzer und Passwort Abfrage implementiert. Aus der zeitlichen Begrenzung für die Arbeit, wurde sich für den Benutzermodus als Hauptaufgabe der App entschieden. Der Benutzermodus zeigt zunächst eine Liste aller verfügbaren Filter. Diese wären zum Beispiel Bodeninformationen oder Tunnelbohrmaschine. Der Benutzer kann nun also einen der Filter auswählen. Im der nachfolgenden Activity werden dann alle Dokumente, passend zum Filter, mit ihrer ID oder einem key in einem GridView angezeigt. Nachdem 16

auf eines der Dokumente geklickt wurde, wird eine ExpandableList mit Oberbegriffen des Dokumentes angezeigt. Ein Klick auf so einen Oberpunkt klappt die Liste aus und zeigt alle darunterliegenden Informationen zu dem Oberbegriff an. Das Hauptaugenmerk dieser Arbeit liegt im Benutzermodus und den Bodeninformationen. 3.2 Anforderungen : Lastenheft 1 Visionen und Ziele /LV10/ Smartphone App erleichtert Arbeiten am Tunnel /LZ10/ Weniger Suchaufwand auf Papier 2 Rahmenbedingungen /LR10/ Anwendungsbereich im Tunnelbau /LR20/ Bauherr, Arbeiter, Systemadministrator 3 Kontext und Überblick /LK10/ Applikation für ein Android fähiges mobiles Endgerät /LK20/ Programmierung in Java via Android-SDK /LK30/ Minimales Android Betriebssystem Android Gingerbread 2.3 /LK40/ Endgerät muss Internetfähig sein 4 Funktionale Anforderungen /LF10/ Der Benutzer muss sich über alle Tunnelbauspezifischen Daten informieren können /LF20/ Der Benutzer muss leicht finden können was er sucht /LF30/ Die App muss Zugriff zur Datenbank haben /LF40/ Die App muss Internetzugang erlauben /LF50/ Die App muss in der Lage sein Änderungen an der Datenbank schnell zu übernehmen /LF50/ Die App muss erweiterbar sein /LF60/ Die App soll zwischen Benutzer und Administrator unterscheiden können 5 Qualitätsanforderungen Systemqualität Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Wartbarkeit Portabilität 17 sehr gut Gut X normal X X X X X nicht relevant

/LQB10/ Die App muss gut Bedienbar und Übersichtlich sein /LQE10/ Die App darf nicht zu viele Zwischenscreens besitzen, sonst dauert Suche nach Daten zu lange 3.3 Systemarchitektur : UML UserMainActivity AdminMainActivity Util AdminActivity2 StartActivity MaterialDocumentView LoadDocument Bodeninformationen LoadfilteredDocs ParentUtil DroidCouch MyCustomExpandableListAdapter Zeichnung 2: UML Klassendiagramm Diese Arbeit verwendet zehn verschiedene Klassen. In der nachfolgenden Zeichnung 2 sieht man alle verwendeten Klassen, mit ihren Verbindungen, in einem UML Diagramm.Die Klassen UserMainActivity, AdminMainActivity und MaterialDocumentView greifen auf Methoden aus der Util Klasse zu. Bodeninformationen und MaterialDocumentView importieren die inneren Klassen. Der MyCustomExpandableListAdapter und MaterialDocumentView importieren die ParentUtil Klasse. 18

4 Implementierung 4.1 Applikation Design In diesem Projekt wird ausschließlich das Linear Layout verwendet, welches die Widgets vertikal zueinander anordnet. Dieses erlaubt eine gleichmäßige Anordnung der Widgets. Auf dem Startbildschirm werden 2 RadioButtons und ein Button genutzt. Die RadioButtons dienen zur Auswahl eines Modus. Wohingegen der Button die Auswahl bestätigt und die entsprechende Activity öffnet. Zeichnung 3 zeigt schematisch den Aufbau des Startmenüs. Administrator Modus Benutzer Modus Wird hier nun der Administartor Modus ausgewählt gelangt man auf die AdministratorMainActivity. In dieser gibt es zwei EditText Textfelder. Das erste dient der Eingabe des Benutzernamens. Weiter Das zweite ist zur Eingabe des Passwortes. Das Benutzername Feld ist ein einfaches Zeichnung 3: Startmenü der App Textfeld. Für die Passwortabfrage wird ein Passwort Feld eingefügt, welches die eingegeben Zeichen verschlüsselt als Punkte anzeigt. Ein Button dient dann zur Bestätigung der Eingaben. Sind Username Benutzername Passwort Passwort Log IN diese korrekt, soll man auf eine Activity gelangen, in der Einloggen alle Datenbanken angezeigt werden. Eine Schematische Ansicht zu diesem Fenster zeigt Zeichnung 4. Der Administrator Modus wurde aus Zeitgründen Zeichnung 4: Schematischer zur Aufbau AdminmainActivity Bearbeitung des Projektes nicht weiter berücksichtigt. Wird im Startmenü der Benutzermodus ausgewählt, wird eine Activity mit einem ListView geöffnet. Die Elemente in diesem ListView repräsentieren die Views der CouchDB. 1 Zeichnung 5 zeigt diese Activity schematisch. In dieser List Item List Element 1 Activity kann einer der List Elemente angeklickt werden. Die Elemente repräsentieren Filter, wie Bodeninformationen, Tunnelbohrmaschine oder Tunnel. List Item 2 List Element 2 List Item 3 List Element 3 Nach Klick auf eines dieser Elemente wird die nächste List Item 4 List Element 4 Activity des Benutzer Modus gestartet. In dieser neu Zeichnung 5: UserMainActivity geöffneten Activity werden dann die Dokumente mit den schematisch keys in einem GridView wiedergegeben. In Zeichnung 6 wird diese Activity beschrieben. 19

In der Bodeninformationen Activity kann nun ein Dokument angeklickt werden. Die einzelnen Grids sind List Item 1 Sub Item 1 mit den keys des Dokumentes gefüllt. Nach einem Klick auf Zeichnung 6: Bodeninformationen Die MaterialDocumentView. List Item 2 Sub Item 2 ein Grid öffnet sich die letzte Activity des Benutzermodus. Diese Activity enthält List Item 3 eine Sub Item 3 ExpandableList. Diese Liste ist mit Oberbegriffen aus dem List Item 4 Sub Item 4 Material Feld des Dokumentes gefüllt. Einige von denen sind density, ucs, type, discontinuities und noch einige mehr. Die Zeichnung 7: ExpandableList kann angeklickt werden um die Informationen MaterialDocumentView zu den einzelnen Oberbegriffen anzuzeigen. Zeichnung 7 zeigt diese Activity. 4.2 Klassenarchitektur In dieser Appliaktion werden externe Klassen von Nutzern aus dem Internet verwendet. Die DroidCouch Klasse [13] implementiert Methode für die HTTP-Request, um auf die CouchDB Daten zugreifen zu können. Diese Klasse ist von der Seite [13]. Die nächste importierte Klasse ist die ParentUtil Klasse [8]. Diese implementiert Getter und Setter für Childarrays und für den Titel der Parents. Parents sind die Oberbegriffe der ExpandableList und die Children sind die Informationen zu diesen begriffen. Damit diese Klasse ExpandableListAdapter genutzt werden verwendet MycustomExpandableListAdapter Klasse kann, muss werden. implementiert. ein Dieser Diese selbstgeschriebener ist Klasse in wurde der von folgender Quelle [8] übernommen. Diese Klasse implementiert Methoden zur Wiedergabe von Parents und Children in einer ExpandableList. Diese Klassen benötigen dann noch Layouts. Also musste auch passende XMLDokumente dafür erstellt werden. Diese XML-Dokumente wurden von Seite [8] übernommen. 20

4.2.1 Util Diese Klasse macht alle vorab wichtigen Informationen, Util wie Host URL oder die Filter, für alle anderen Klassen addbodenersteebene() addbodenmaterial() addlogindata() addusermodefilter() getbodenersteebene() getbodenmaterial() getlogindata() getusermodefilter() gethosturl() setbodenersteebene() setbodenmaterial() setlogindata() setusermodefilter() sethosturl() Zeichnung 8: UML zur Util Klasse zugänglich. Des Methoden, um weiteren die enthält diese Applikation Klasse für eine Weiterentwicklung vorzubereiten. In dieser Klasse wird eine HashMap für die Log In Daten, für den Administrator Modus, verwendet. Diese HashMap muss später neue Log In Informationen aufnehmen können. Dazu wird eine Methode add implementiert die ein key:value paar in die AdministratorMainActivity HashMap muss aufnimmt. Zugriff auf Die die HashMap haben, deshalb sind ebenfalls Getter und Setter implementiert. Für alle anderen Objekte wie einer ArrayList für Filter sind ebenfalls eine add, eine Getter und eine Setter Methode implementiert. Die Zeichnung 8 zeigt alle implementierten Methoden der Util Klasse. Alle diese Methoden sind static, damit kein neues Objekt dieser Klasse erzeugt werden muss, um auf die Methoden zuzugreifen. Des weiteren werden die Listen und Strings im static Konstruktor initialisiert. 4.2.2 StartActivity Das Layout dieser Activity <RadioGroup android:layout_width="wrap_content" besteht aus 2 RadioButtons, android:layout_height="wrap_content" > angeordnet <RadioButton android:id="@+id/radiobuttonadmin" android:layout_width="wrap_content" einer RadioGroup, einem Button, und einem TextView. Das android:layout_height="wrap_content" XML-Dokument ist in Listing android:text="@string/radioadmin" /> 9 angebildet. <RadioButton android:id="@+id/radiobuttonuser" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/radiouser" /> </RadioGroup> 21 in