Entwicklung und Evaluation einer Android-Applikation zur Optimierung der Vertragsverwaltung

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Zusammenfassung

1 Einleitung
1.1 Motivation und Problemstellung
1.2 Zielsetzung
1.3 Vorgehensweise
1.4 Projektmanagement

2 Grundlagen
2.1 Funktionsweise einer Android-App
2.2 iText-Bibliothek zur Generierung des Kündigungsschreibens
2.3 SQLite-Datenbanksystem
2.4 GUI
2.5 XML
2.6 Software-Usability
2.7 DIN EN ISO 9241
2.8 Think Aloud - lautes Denken

3 Methodik
3.1 Softwareentwicklung
3.1.1 Anforderungen an den Prototyp
3.1.2 Marktanalyse bzw. Analyse bestehender Lösungen
3.1.3 Systeme, die für die Entwicklung benötigt werden
3.1.4 Konzeption und Design
3.1.5 Roadmap
3.2 Software-Evaluation
3.2.1 Forschungsdesign
3.2.2 Klassifikation der Erhebungsmethoden
3.3 Umsetzung und Implementierung der Applikation
3.3.1 Die Klassen „Category“, „Contract“, „Partner“ und „User“
3.3.2 Klasse „DatabaseHelper“
3.3.3 Klasse „DatabaseAdapter“
3.3.4 Klasse „MainActivity“
3.3.5 Klasse „Home“
3.3.6 Die Klassen „PartnerInsert“, „CategoryInsert“, „UserInser“ und
„ContractInsert“
3.3.7 Klasse „DatePickerFragment“
3.3.8 Die Klassen „PartnerChange“, „CategoryChange“, „UserChange“ und „ContractChange“
3.3.9 Die Klassen „CategoryList“, „PartnerList“, „UserList“ und „ContractList“
3.3.10 Klassen „CategoryListViewAdapter“, „PartnerListViewAdapter“, „UserListViewAdapter“ und „ContractListViewAdapter“
3.3.11 Die Klassen „PartnerSpinnerAdapter“ und „CategorySpinnerAdapter“ ..
3.3.12 Die Klassen „InputDialogCategory“, „InputDialogPartner“ und „InputDialogPartner“
3.3.13 Klasse „ITextService“
3.4 Evaluation
3.4.1 Usability-Test
3.4.2 Kontrolle von Störvariablen
3.4.3 Vorbereitung der Prüfung
3.4.4 Durchführung der Untersuchung
3.4.5 Auswertung der Untersuchung

4 Ergebnisse der Arbeit
> 4.1 Ergebnisse der Entwicklung
4.2 Ergebnisse der quantitativen Evaluation
4.3 Ergebnisse der qualitativen Evaluation

5 Fazit

6 Anhang
6.1 Ereignisgesteuerte Prozesskette (EPK)
6.2 USE-Case-Diagramm
6.3 Aufgaben - Fragebogen
6.4 Quellcode

Literaturverzeichnis

Eidesstattliche Erklärung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1 Lebenszyklus einer Activity (Quelle: Android Developers. (kein Datum). The Activity Lifecycle. Abgerufen am 08. 01 2018 von Android Developers: https://developer.android.com/guide/components/activities/activity-lifecycle.html

Abbildung 2: Lebenszyklus eines Fragments (Quelle: Android Developers. (kein Datum). Fragments. Abgerufen am 08. 01 2018 von Android Developers: https://developer.android.com/guide/components/fragments.html

Abbildung 3 Übersicht Content Provider Quelle: eigene Darstellung in Anlehnung an Bleske, C. (2013). Java für Android. Haar bei München: Franzis Verlag GmbH

Abbildung 4 Relation eines Relationenmodells

Abbildung 5 Input Controls Quelle: Controls. (kein Datum). Abgerufen am 09. 01 2018 von Android Developers: https://developer.android.com/guide/topics/ui/controls.html 10

Abbildung 6 ANSI-Dreischichtenmodell Quelle: TH Köln, Campus Gummersbach. (kein Datum). ANSI-3-Ebenmodell. Abgerufen am 14. 01 2018 von Datenbanken Online Lexikon: http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/ANSI-3-Ebenenmodell ...

Abbildung 7 Datenbank - ER-Modell nach der Chen-Notation

Abbildung 8 Darstellung der Klasse Category und eines Objektes der Klasse Category

Abbildung 9: Quellcode der Klasse „Category“

Abbildung 10:Quellcodeausschnitt der Methode „sqlCreateTableCategory“

Abbildung 11:Quellcodeausschnitt der Methode „onCreate"

Abbildung 12:Quellcodeausschnitt der Methode „onUpgrade"

Abbildung 13: Quellcodeausschnitt der Methode „insertCategory"

Abbildung 14:Quellcodeausschnitt der Methode „getAllCategory"

Abbildung 15:Quellcodeausschnitt der Methode „updateCategory“

Abbildung 16: View - NavigationDrawer/ Hauptmenü

Abbildung 17: MainActivity - Methode "onNavigationSelected"

Abbildung 18:Quellcodeausschnitt der Methode „changeUser"

Abbildung 19: Quellcodeausschnitt der Methode „requestContactsPermissions"

Abbildung 20:Quellcodeausschnitt der Methode „insertEvent"

Abbildung 21: Kommunikation mit anderen Fragmenten

Abbildung 22: Quellcodeausschnitt der Methode „updateData"

Abbildung 23: View - Home

Abbildung 24:Home - Methode „onClick"

Abbildung 25:ContractInsert-Methode "loadUserData"

Abbildung 26:ContractInsert - Methode "loadNoticeInterval"

Abbildung 27:ContractInsert - Methode "showDatePickerDialog"

Abbildung 28:ContractInsert - Callback DatePickerDialog

Abbildung 29:ViewHolder - PartnerListViewAdapter

Abbildung 30: PartnerListViewAdapter - Methode „getView“

Abbildung 31: Quellcodeausschnitt - Methode „getView"

Abbildung 32: Quellcodeausschnitt - Methode „getDropDownView"

Abbildung 33: Quellcodeausschnitt der Methode „createPDF"

Abbildung 34: Diagramm - Durchschnittliche Bewertung der Gestaltungsgrundsätze .

Tabellenverzeichnis

Tabelle 1: Planung der Dauer der Arbeitspakete

Tabelle 2: Marktanalyse - Vollständigkeit der definierten Funktionalitäten

Tabelle 3: Roadmap für die Entwicklung der Applikation

Tabelle 4:Zuordnung der „Insert"-Klassen zum Layout

Tabelle 5: Zuordnung der „Change"-Klassen zum Layout

Tabelle 6: Zuordnung der „List"-Klassen zum Layout

Tabelle 7: Zuordnung der „ListView-Adapter"-Klassen zum Layout

Tabelle 8: Anforderungsabgleich

Tabelle 9: Mängel und Handlungsempfehlungen

Zusammenfassung

Verschiedene Unternehmen der Telekomunikations-, Gas- und Stromversorger-branche bieten für einen bestimmten Zeitraum eine günstigere Gebühr beziehungsweise eine Bo- nuszahlung an. Durch diese Vergünstigung erhoffen sie sich eine höhere Anzahl an Kon- sumenten. Nach Ablauf des Aktionszeitraumes wird der Vertrag meist teurer, die Kondi- tionen verschlechtern sich für den Kunden. Die Kündigungsfristen, die vertraglich fest- gelegt wurden, betragen meist mehrere Monate. Viele Verbraucher merken erst bei Erhalt der Abrechnung, dass sich der Vertrag verlängert beziehungsweise dass sich die Kondi- tionen verändert haben.

Das Ziel dieser Arbeit ist die Entwicklung einer prototypischen Android-Applikationslö- sung, mit der die Konsumenten die Möglichkeit haben, sich an bevorstehende Fristen erinnern zu lassen, um Verträge rechtzeitig zu kündigen.

Am Ende der Arbeit soll mit Hilfe einer Evaluierung geklärt werden, wie verständlich der Prototyp für den Konsumenten ist. Die Evaluation wird durch einen „Thinking-Aloud“- Test sowie einen Fragebogen mit fünf Testnutzern durchgeführt. Die Testergebnisse werden im Anschluss auf Anomalien beziehungsweise auf ähnliche Aussagen untersucht. Ein Ausblick auf eine mögliche Weiterentwicklung beschließt die Arbeit.

1 Einleitung

1.1 Motivation und Problemstellung

Verträge und die mit ihnen einhergehenden Kosten stellen in Haushalten und Unternehmen einen entscheidenden Fixkostenbeitrag dar. Daraus lässt sich schlussfolgern, dass für 41,0 Mill. private Haushalte¹ sowie für rund 3,5 Mio. Unternehmen² in Deutschland ein Vertragsmanagement unverzichtbar ist.

Das Thema der Vertragsverwaltung ist sehr komplex und stellt deshalb einige Verbraucher/ Verbraucherinnen vor eine Herausforderung. Gerade beim Versuch, sich einen Überblick über alle Verträge und deren Laufzeiten sowie über die jeweiligen Kündigungsfristen zu verschaffen, kommt es zu Schwierigkeiten. Durch den Verlust der Kontrolle kommt es häufig zu einer Überschreitung dieser Fristen.

Viele Unternehmen locken die Verbraucher/innen durch günstige Einstiegsangebote und definieren in ihren Verträgen gezielt eine Kündigungsfrist von bis zu 3 Monaten. Wird diese Kündigungsfrist überschritten, verlängert sich der Vertrag automatisch und die Konditionen ändern sich.- häufig zu Gunsten der Vertragsgeber/innen. Diese Methode findet sich in vielen Branchen, in denen längerfristige Verträge abgeschlossen werden, wie etwa bei Kfz- oder Rechtsschutz-Versicherungen sowie bei Mobilfunk-, Festnetz-, Strom- und Gasanbietern Anwendung. Über die Anzahl der Vertragsverlängerungen, die aufgrund eines Fristversäumnisses automatisch durch den Anbieter entstehen, gibt es keine Statistik.

Die Verbreitung von mobilen Endgeräten (2016: 43,05 Mio.)³ und die tägliche Nutzung von Anwendungen lassen die Schlussfolgerung zu, dass den Benutzern/ Benutzerinnen das richtige Tool fehlt, das sie in geeigneter Form in der Koordination der Tätigkeiten unterstützt.

Zum Zeitpunkt der Anfertigung der Thesis gibt es bereits Applikation, die bei der Erfül- lung dieser Aufgabe helfen. Sie basieren jedoch entweder auf einem Vergleichsportal o- der es fallen Kosten für die Erstellung einer Kündigung an. Weitere Probleme sind im Bereich des Datenschutzes zu finden. Eine spezifischere Betrachtung der gegenwärtig existierenden Lösungen wird in Kapitel 3.1.2 vorgenommen.

1.2 Zielsetzung

Die Zielsetzung dieser Bachelorarbeit ist die Entwicklung einer prototypischen AndroidApplikationslösung, mit der sich das Vertragsmanagement optimieren lässt.

Die Applikation soll dabei die folgenden Aufgaben des Vertragsmanagements abdecken:

- einfache Eingabe der erforderlichen Informationen, die für die Übersichtsliste und das jeweilige Kündigungsschreiben benötigt werden
- Übersichtsliste über alle aktuellen Verträge inklusive der Möglichkeit, diese zu filtern
- Übersichtsliste über zu kündigende Verträge inklusive der Möglichkeit, diese als erledigt zu markieren
- Fristenmanagement
- Generierung eines Standardkündigungsschreibens

Neben diesen Entwicklungszielen spielt die Prüfung der Usability eine entscheidende Rolle. Diese soll durch einen Fragebogen sowie einen „Thinking-Aloud“-Test geprüft und im Anschluss ausgewertet werden. Das Ziel der Evaluation besteht darin, die Funktionalität der oben ausgeführten Punkte zu kontrollieren, Schwachstellen aufzudecken sowie die Usability nach DIN ISO 9241 Teil 10 zu prüfen.

1.3 Vorgehensweise

Der erste Teil widmet sich der terminologischen Klärung. Dabei wird auf die Grundlage der Android-Programmierung und den grundlegenden Aufbau sowie spezifischer auf die Besonderheiten der genutzten Datenbank eingegangen. Zudem werden die bei der Untersuchung der Usability verwendeten Methoden erläutert.

Im Fokus des 3. Kapitels steht die Methodik der Softwareentwicklung und der Evaluation. Dabei werden vor dem Beginn der Programmierung Überlegungen zu den Anforderungen an die spätere Applikation sowie zu externen Komponenten angestellt. Danach werden das Forschungsdesign und die Klassifikation der Erhebungsmethoden näher beleuchtet.

Anschließend wird auf die Umsetzung und Implementierung der Applikation eingegan- gen. Dabei wird die Applikation klassenweise betrachtet. Im Rahmen der Evaluation werden Planung und Durchführung des Tests thematisiert.

Daran schließt die Auswertung der Ergebnisse an.

Ein Fazit und ein kurzer Ausblick auf eine mögliche Weiterentwicklung der Applikation beschließen die Arbeit.

1.4 Projektmanagement

Gutes Projektmanagement zählt zu den wichtigsten Aspekten bei der Umsetzung eines Projektes, denn es ermöglicht, die Projektziele in der geforderten Qualität, in der geplanten Zeit und mit optimalem Einsatz effizient zu gestalten.⁴ Die zu nutzenden Ressourcen mussten für dieses Projekt nicht näher betrachtet werden.

Insgesamt standen 123 Tage zur Verfügung (vom 12.10.2017 bis zum 12.02.2018). Da die Berechnung der Dauer jedoch auf einer Fünf-Tage-Woche basierte, umfasste die Planung lediglich 89 Tage.

Zu Beginn des Projektes wurde ein Zeitplan mit den durchzuführenden Arbeitspakten angelegt. Diese wurden später durch konkretere Aufgaben ergänzt.

Tabelle 1: Planung der Dauer der Arbeitspakete

Abbildung in dieser Leseprobe nicht enthalten

2 Grundlagen

In diesem Kapitel stehen die terminologische Klärung sowie die generelle Funktionsweise einer Android-Applikation und einer Datenbank im Fokus.

2.1 Funktionsweise einer Android-App

Bei der Entwicklung einer Applikation sind der grundsätzliche Aufbau beziehungsweise das Verhalten einer Anwendung von hoher Bedeutung.⁵ Die Programmierung einer Applikationslösung für ein Android-System unterscheidet sich von der Programmierung einer Softwareanwendung für ein Windows-System.

Eine App wird vom Android SDK kompiliert.⁶ Das Android SDK stellt ein Paket von Tools und allen relevanten Bibliotheken dar.⁷ Der Code wird in einem APK (Android package) archiviert und lässt sich anhand des Suffix „.apk“ identifizieren. Dieses Package enthält alle Informationen der App und dient der Installation.

In Android läuft jede App in einem eigenen isolierten Bereich, der durch unterschiedliche Features abgesichert wird. Zudem gewährt Android nur die notwendigsten Berechtigun- gen („principle of least privilege“). Dieses Prinzip erhöht die Sicherheit für den Benutzer/ die Benutzerin, da die Anwendung keinen direkten Zugriff auf die Inhalte seines Systems erhält. Es besteht jedoch die Möglichkeit, zusätzliche Berechtigungen über eine explizite Einwilligung des Benutzers zu erlangen. Auf die konkrete Umsetzung wird in Kapitel 3.3 eingegangen.

Die Android-App besteht aus vier verschiedenen Typen von Komponenten, die für deren Ausführung essenziell sind. Diese Komponenten sind Activities, Services, Broadcast Re- ceivers und Content Provider. Einige der Komponenten sind voneinander abhängig. Zur besseren Verständlichkeit der Entwicklung werden die Eigenschaften der Activities näher erläutert.

Activities

Die Activity stellt für den Benutzer/ die Benutzerin den Eintrittspunkt, Ausgangspunkt und Rückkehrpunkt einer App-Anwendung in Android dar.⁸ Eine Activity repräsentiert einen Screen mit einem Benutzerinterface. Während der Ausführung durchläuft die Activity einen Lebenszyklus, der unterschiedliche Phasen beinhaltet. Die Activity-Klasse stellt sechs verschiedene Callbacks zur Verfügung: onCreate(), onStart(), onResume(), onPause(), onStop() und onDestroy(). Das System ruft jeden dieser Callbacks auf, wenn die Activity einen neuen Zustand erreicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Lebenszyklus einer Activity

(Quelle: Android Developers. (kein Datum). The Activity Lifecycle. Abgerufen am 08. 01 2018 von Android Develo- pers: https://developer.android.com/guide/components/activities/activity-lifecycle.html

An dieser Stelle muss ein besonderer Fokus auf die onCreate()- und auf die onStart()Methode gelegt werden. Die onCreate()-Methode wird aufgerufen, wenn das System zum ersten Mal erstellt wird. Sie definiert die Initialwerte für Objekte und Variablen, legt die Benutzeroberfläche fest und konfiguriert einige Benutzerschnittstellen. Im Anschluss an die onCreate()-Methode wird die Methode onStart() aufgerufen. In ihr wird die Activity für den Benutzer/ die Benutzerin sichtbar gemacht.⁹

Die anderen Methoden definieren, was bei bestimmten Ereignissen geschieht, wie im Fol- genden erläutert:

- onResume() - Die Activity ist im Bildschirmvordergrund sichtbar.
- onPause() - Eine andere Activity ist im Benutzer-Fokus, die ursprüngliche Activity ist jedoch noch im Hintergrund sichtbar.
- onStop() - Die Activity ist für den Benutzer/ die Benutzerin nicht mehr sichtbar.
- onDestroy() - Die Activity soll verworfen/ beendet werden, es handelt sich um die letzte Methode im Lebenszyklus.¹⁰

Um ein spezifisches Verhalten der Methoden zu implementieren, müssen diese Methoden überschrieben werden.¹¹

Innerhalb der Activity können Fragmente eingegliedert werden. Fragmente sind ein Teil des Benutzer-Interfaces. Sie können genutzt werden, um ein bestimmtes Verhalten in die Activity zu integrieren.¹² Sie haben einen eigenen Lebenszyklus und enthalten - wie die Activities - folgende Callback-Methoden: onCreate(), onStart(), onPause() , onStop() und onDestroy(). Die genannten Methoden koordinieren den Lifecycle der Activity mit dem Lifecycle des Fragments.

Zusätzlich zu den genannten Methoden enthalten Fragmente folgende weitere Methoden: onAttach(), onCreateView(), onActivityCreated(), onDestroyView() und onDetach(). Diese sind unter anderem zuständig für das Erstellen und Beenden des User-Interfaces.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Lebenszyklus eines Fragments

(Quelle: Android Developers. (kein Datum). Fragments. Abgerufen am 08. 01 2018 von Android Developers: https://developer.android.com/guide/components/fragments.html

Services, Broadcast Receivers

Soll eine App eine Funktion im Hintergrund ausführen, muss dafür ein Service ausgeführt werden. Hauptsächlich werden Services verwendet, um lang andauernde Vorgänge oder Arbeiten für Remote-Prozesse auszuführen. Services unterstützen keine Benutzeroberflä- che. Für eine systemweite Broadcast-Meldung wird der Broadcast Receiver benötigt.¹³

Der Content Provider wird verwendet, um Inhalten zu verwalten. Indem er verschiedene Methoden zur Verfügung stellt, ermöglicht er es, Daten in ein anderes Dateisystem zu speichern, auf Daten zuzugreifen, die sich in einem anderen Dateisystem befinden, bzw. diese zu ändern.¹⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Übersicht Content Provider

Quelle: eigene Darstellung in Anlehnung an Bleske, C. (2013). Java für Android. Haar bei München: Franzis Verlag GmbH.

2.2 iText-Bibliothek zur Generierung des Kündigungsschreibens

Die Generierung des zukünftigen Kündigungsschreibens wird mittels einer Bibliothek mit dem Namen iText realisiert. Es ist eine der gängigsten Bibliotheken für die Erstellung von PDF-Dateien mittels der Programmiersprache Java. Sie steht unter der AGPL-Lizenz zur Verfügung.

2.3 SQLite-Datenbanksystem

Das Datenbanksystem stellt eine entscheidende Komponente für das zu entwickelnde System dar. Mit Hilfe des Systems können Daten strukturiert werden und Daten, die in- haltlich zusammengehören, gesammelt werden. Man spricht dann von einer Datenbank.¹⁵

Bei SQLite handelt es sich um ein spezielles Datenbanksystem, das das relationale Datenmodell verwendet. Daraus ist abzuleiten, dass es sich um ein relationales Datenbanksystem handelt. Neben dem relationalen Datenbanksystem gibt es weitere Datenmanagementsysteme (DBMS), wie zum Beispiel die objektorientierte DBMS. Auf diese wird im Rahmen der Arbeit jedoch nicht weiter eingegangen.

Eine relationale Datenbank besteht aus mindestens einer Relation. „Eine Relation ist eine zweidimensionale Tabelle mit einer festen Anzahl von Spalten und einer beliebigen An- zahl von Zeilen. Eine Relation entspricht einem Entitätstyp. Jede Zeile der Tabelle ent- spricht einer Entität des durch die Tabelle repräsentierten Entitätstyps. Die Spalten einer Tabelle entsprechen den Attributen.“¹⁶ Zudem benötigt jede Relation einen Primärschlüs- sel, der die Zeile eindeutig identifiziert. Enthält die Datenbank mehrere Relationen, deren Datensätze miteinander in Beziehung stehen, wird der Relation ein Fremdschlüssel zugewiesen. Dieser Fremdschlüssel wird über eine zusätzliche Spalte realisiert.¹⁷

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Relation eines Relationenmodells

Im Vergleich zu anderen Datenbanksystemen, wie MySQL, Microsoft SQL Server oder der Oracle Database, handelt sich bei SQLite um ein eingebettetes Datenbanksystem, das sich dadurch auszeichnet, dass es direkt in die Anwendung integriert werden kann.¹⁸ Es benötigt keine externen Bibliotheken oder Interfaces und unterstützt die Datenbankspra- che SQL.

Die Datei benötigt keine Einrichtungen oder Tools, um sich selbst zu erstellen/aufzu- bauen.¹⁹ Des Weiteren benötigt sie keinen Server oder zusätzliche Konfigurationen.²⁰ Darüber hinaus wird die gesamte Datenbank normalerweise in einer einzigen SourceCode-Datei gespeichert, die sämtliche Tabellen, Indizes, Views, Trigger sowie die SQLite-Bibliothek enthält.²¹

Aufgrund ihres „stand-alone“-Charakters besitzt die Datenbank nur geringe Abhängigkeiten und läuft auf jedem Betriebssystem.

Das Datenbanksystem hat die Aufgabe, alle anfallenden Daten, unabhängig vom Anwen- dungsprogramm, möglichst effizient zu speichern und die Abfragen zu optimieren.²²

2.4 GUI

Zu einem weiteren Grundmerkmal einer App zählt das GUI (Graphical User Interface). Es repräsentiert die Oberfläche, über die der Benutzer/ die Benutzerin mit der App interagiert. Die einzelnen Formulare bilden die Basis für die Gestaltung der App. In Android werden diese Formulare als Screens oder Views bezeichnet. Auf einem Screen können verschiedene Controls (Steuerelemente) positioniert werden.²³

Als Input Controls werden die interaktiven Komponenten bezeichnet, die Eingaben des Benutzers realisieren. Android bietet Steuerelemente, wie Buttons, Textfelder, Suchfelder, Checkboxen, Zoombuttons oder Toggle-Buttons, an.²⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 Input Controls

Quelle: Controls. (kein Datum). Abgerufen am 09. 01 2018 von Android Developers: https://developer.and- roid.com/guide/topics/ui/controls.html

2.5 XML

XML (Extended Markup Language) ist ein flexibel einsetzbares text-basiertes Format, das dem Austausch von strukturierten Information dient. Die Dateien können Dokumente, Konfigurationen, Bücher, Rechnungen oder Ähnliches beinhalten. Die Sprache leitet sich aus dem älteren Standard SGML (ISO 8879) für die Anwendung im Web ab.²⁵

In Android findet es Anwendung bei der Generierung von Views, bei der Manifest-Datei sowie bei der Speicherung von Strings, Farben, Grafiken und Layouts.

2.6 Software-Usability

Die Usability beschreibt die Nutzerfreundlichkeit eines Produktes. Der Begriff wird sowohl für die Mensch-Computer-Interaktion (MCI) bzw. Software-Ergonomie als auch für die Gebrauchstauglichkeit von Produkten in Bezug auf ihr Produktdesign und ihre Ergonomie verwendet. Die Usability untersucht bei beiden oben genannten Einsatzgebieten die benutzer- und aufgabenorientierte Konzeption hinsichtlich der drei Kriterien Effektivität, Effizienz und Zufriedenheit.

Da sich die vorliegende Untersuchung hauptsächlich auf die Prüfung der Softwareergo- nomie bezieht, wird nicht näher auf Produkt-Usability-Untersuchungen eingegangen.

Im Bereich der MCI erschien bereits im Jahr 1959 die erste Arbeit über die Ergonomie von Computern. Diese wurde von Brian Shackel mit dem Titel „Ergonomics for a Com- puter“ veröffentlicht. Daraufhin erfolgten in den 1960er Jahren entscheidende Innovatio- nen im Bereich der interaktiven grafischen Benutzeroberfläche, die zur Veröffentlichung der ersten Computer-Maus führten. Seit den 1970er Jahren bestehen „[…]Anforderungen an die ergonomische Gestaltung interaktiver Systeme“²⁶. Dazu zählen unter anderem die intuitive Gestaltung zur Minimierung des Lernaufwandes, optimierte Eingabemöglich- keiten mit der Ausgabe von Fehlermeldungen und die Möglichkeit, Fehler rückgängig zu machen.

Das Gebiet steht jedoch gerade in der heutigen Zeit in vielen Bereichen verstärkt im Mit- telpunkt des Interesses, unter anderem in der industriellen Praxis und im akademischen Bereich.²⁷ Diese beiden Bereiche verfolgen dabei häufig unterschiedliche Interessen. Universitäten und universitäre Forschungsverbände betreiben meist Grundlagenfor- schung, Markt- und Medienforschungsinstitute hingegen haben zumeist andere Ziele.²⁸ Zu den Zielen der Markt- und Medienforschungsinstitute zählt die Wirkung von Medien auf den Empfänger, um mit ihrer Hilfe zielgerichteter Werbung zu schalten.²⁹

2.7 DIN EN ISO 9241

Bei der DIN EN ISO 9241 handelt es sich um eine bereits etablierte Norm. Ursprünglich wurde der Internationale Standard für die Ergonomischen Anforderungen für Bürotätigkeiten mit Bildschirmgeräten entwickelt. Seit 2006 wurde die Einschränkung auf Bürotätigkeiten aufgehoben.

Die ISO Norm gliedert sich in 17 Abschnitte. Für die Prüfung der Usability sind der Abschnitte 10 - Grundsätze der Dialoggestaltung und der Abschnitt 11 - Anforderungen an die Gebrauchstauglichkeit - Leitsätze essentiell.³⁰

Sie thematisiert die oben beschriebene Usability eines Systems, das durch einen Benutzer/ eine Benutzerin getestet wird. Im Mittelpunkt steht das Erreichen der zuvor bestimmten Ziele hinsichtlich der Effektivität, der Effizienz und der Zufriedenstellung des Anwenders/ der Anwenderin.³¹

Die Norm beinhaltet sieben Gestaltungsgrundsätze:

- Aufgabenangemessenheit
- Selbstbeschreibungsfähigkeit
- Steuerbarkeit
- Erwartungskonformität
- Fehlertoleranz
- Individualisierbarkeit
- Lernförderlichkeit

Diese Grundsätze sollen dabei helfen, das System so zu gestalten, dass es für den Benutzer/ die Benutzerin einfach zu handhaben ist.

2.8 Think Aloud - lautes Denken

Das „laute Denken“ stellt eine Methode dar, durch die eine Person einen Einblick in die Gedanken, Gefühle und Absichten einer anderen Person erhält. Die Methode wird häufig auch Denke-Laut-Methode, Gedankenprotokoll, „Thinking Aloud Protocol“ (TAP), „Think-Aloud“ oder „Verbal Protocol“ genannt.

Das Verfahren ist angelehnt an die introspektiven Erhebungsmethoden. Die Erhebungs- methode wird häufig in strukturierten Kontexten verwendet, um Fehleinschätzungen zu vermeiden. In der Theorie wird zwischen drei verschiedenen Formen des lauten Denken unterschieden. Dabei handelt es sich um:

- die Introspektion (augenblickliche Verbalisierung)
- die unmittelbare Retrospektion (die zeitlich direkt an die Introspektion an- schließt)
- die verzögerte Retrospektion (die direkt nach der Bearbeitung aller Aufgaben, etwa nach der Textlektüre, der Erprobung einer Software oder sogar erst einige Tage später, stattfinden kann)

In der Praxis sind diese jedoch Formen nicht immer klar voneinander zu trennen. Sie werden bei der Auswertung der Ergebnisse nicht weiter beachtet.³²

3 Methodik

3.1 Softwareentwicklung

Im Prozess der Anforderungsfestlegung wurde zunächst die typische Abfolge vom Ver- tragsabschluss bis hin zur Vertragskündigung betrachtet und vereinfacht in Form einer ereignisgesteuerten Prozesskette (EPK) dargestellt (siehe Anlage 6.1 Ereignisgesteuerte Prozesskette (EPK)). Dabei wurde zunächst der Prozess ohne Hilfsanwendung betrachtet.

3.1.1 Anforderungen an den Prototyp

Zur Festlegung der Anforderungen wurden Anwendungsfälle verfasst.

Anwendungsfälle:

1. Anwendungsfall „Vertragsabschluss mit neuem Vertragspartner“

- Der Benutzer/ die Benutzerin unterzeichnet einen neuen Vertrag.
- Der Benutzer/ die Benutzerin legt einen neuen Vertragspartner an.
- Der Benutzer/ die Benutzerin wählte eine Kategorie.
- Der Benutzer/ die Benutzerin erstellt einen neuen Vertrag.
- Der Vertrag wird einer Kategorie zugewiesen.

2. Anwendungsfall „Neue Kategorie soll angelegt werden“

Der Nutzer/ die Nutzerin möchte seinen Vertrag einer Gruppe zuordnen, die noch nicht existiert.

3. Anwendungsfall „Vertragsdaten ändern sich“

- Der Nutzer/ die Nutzerin erhält ein Schreiben über eine bevorstehende Änderung an den Vertragsdaten.
- Die Änderungen betreffen den Vertrag oder den Vertragspartner/ die Vertragspartnerin.

4. Anwendungsfall „Der Vertrag soll gekündigt werden“

- Der Nutzer/ die Nutzerin erhält eine Mitteilung darüber, dass der Vertrag gekündigt werden muss.
- Der Benutzer/ die Benutzerin wählt die Funktion der Kündigung in der App.

5. Anwendungsfall „Der Vertrag soll sich automatisch verlängern“

- Der Benutzer/ die Benutzerin erhält eine Meldung darüber, dass der Vertrag gekündigt werden soll.
- Der Benutzer/ die Benutzerin wählt in der App die Option aus, dass sich der Vertrag verlängern soll.

6. Anwendungsfall „Der Benutzer/ die Benutzerin möchte seine/ihre Verträge und deren Restlaufzeit prüfen“

- Der Benutzer/ die Benutzerin geht in die Vertragsübersicht und überprüft die Restlaufzeit.

Use-Case-Diagramm

Zur Verdeutlichung der Funktionen ist ein Use-Case-Diagramm modelliert worden, das die Funktionen der zu entwickelnden App aus Sicht des Benutzers darstellt (siehe Anlage 6.2).

3.1.1.1 Anforderungsanalyse

Die funktionalen Anforderungen an den Prototypen wurden auf Grundlage des EVA- Prinzips und aufbauend auf den zuvor beschriebenen Anwendungsfällen konkretisiert.

Jene Anforderungen, die starke Ähnlichkeiten zueinander aufweisen, werden zusammengefasst betrachtet.

Anlegen oder ändern eines Datensatzes

Diese Anforderungen sind gültig für das Anlegen, sowie das Ändern einer Kategorie, eines Vertragspartners, eines Benutzers und Vertrags. Aufgrund der sich ändernden Felder bei der Eingabe, werden diese tabellarisch zu Beginn aufgeführt. Eingabe:

Abbildung in dieser Leseprobe nicht enthalten

Verarbeitungsschritte:

- Prüfe, ob alle Pflichtfelder einen Wert enthalten.
- Wenn ein Pflichtfeld keinen Wert enthält, zeige eine Meldung an, dass das Feld einen Wert enthalten muss.
- Wenn alle Pflichtfelder einen Wert enthalten, speichere ihn.
- Prüfe, ob der Datensatz in der Datenbank gespeichert wurde.
- Wenn die Speicherung erfolgreich war, zeige eine Meldung an, dass die Speicherung erfolgreich war.
- Wenn die Speicherung nicht erfolgreich war, zeige eine Meldung, dass die Speicherung nicht erfolgreich war.
- Wenn der Datensatz bereits existiert, speichere ihn nicht und zeigen eine entsprechende Meldung an.

Ausgabe:

Die Meldung erfolgt je nachdem welche Bedingungen erfüllt sich. Weitere funktionale Anforderungen, die das System erfüllen muss:

1. Es soll per Push-Nachricht an eine bevorstehende Kündigung erinnert werden bzw. soll ein Kalendereintrag mit Aufgabe bei der Anlage eines Vertrags generiert werden.
2. Bei Änderung eines Vertrages muss der Kalendereintrag bearbeitet werden, wenn es sich um eine für die Aufgabe relevante Änderung handelt. Dazu zählen Ände- rungen bei der Vertragslaufzeit, der Kündigungsfrist, dem Vertragsabschlussda- tum oder Änderungen am Partner.
3. Das Kündigungsanschreiben soll als PDF generiert werden.
4. Die Restlaufzeit des Vertrages soll angezeigt werden.
5. Die Verträge sollen sich nach Kategorien filtern und durchsuchen lassen.

Nichtfunktionale Anforderungen

Im Gegensatz zu den funktionalen Anforderungen, die auflisten, was das System leisten soll, beschreiben nicht-funktionale Anforderungen Qualitätsanforderungen und Usability-Aspekte des Systems.

Die Vertragsverwaltungsanwendung verfolgt folgende Ziele:

- Alle Benutzeroberflächen sind gleich aufgebaut. Das bedeutet, dass die Dialoge möglichst einheitlich dargestellt sind.
- Die App soll auf allen mobilen Geräten ab der Android-Version 5.0 funktionsfä- hig sein.
- Die App soll die Grundsätze der ISO 9241-11 einhalten.
- Die App soll für alle mobilen Geräte-Typen (Tablets und Smartphones) nutzbar sein. Jede Auflösung soll dargestellt werden können.

3.1.1.2 Analyse der Zielgruppe

Zur Verbesserung der Usability und zur Konkretisierung der Anforderungen an die App setzt sich das folgende Kapitel zunächst mit der Gruppe potenzieller User/innen auseinander. Dabei werden soziodemographische, verhaltensorientierte, psychologische, geografische und medienorientierte Merkmale bestimmt.³³

Die Benutzer/ Benutzerinnen werden zunächst nach demografischen und sozioökonomischen Merkmale, wie Geschlecht, Alter, Familienstand, Haushaltsgröße und die Anzahl der Kinder, unterteilt.

Aufgrund der gesetzlichen Bestimmung zur Geschäftsfähigkeit muss der potenzielle Kunde/ die Kundin das 18. Lebensjahr vollendet haben. Darüber hinaus kann jeder Mensch, ungeachtet des Familienstandes, der Haushaltsgröße und der Anzahl an Kindern, die App verwenden. Über Einkommen, Vermögen oder den Beruf der Benutzerinnen und Benutzer können in diesem Stadium keine Annahmen getroffen werden.

Da zuvor die Entscheidung getroffen wurde, die Applikation in der deutschen Sprache zu entwickeln, ist außerdem zunächst nur der deutschsprachige Raum (Deutschland, Österreich und Schweiz) Teil der Zielgruppe.

Im Gegensatz zu den zuvor definierten Merkmalen bestimmen die verhaltensorientierten Kriterien die produkt-, kommunikations-, preis- und einkaufsstättenbezogenen Ansatz- punkte.³⁴

Auf die produktbezogene Segmentierung wird in dieser Arbeit nicht weiter eingegangen, da sie keinen direkten Einfluss auf die Entwicklung und Evaluation hat.

Im Bezug darauf wie Mediennutzung, spielen die verhaltensorientierten Kriterien eine entscheidende Rolle. Der spätere Nutzer/ die spätere Nutzerin sollte bereits Erfahrungen mit einem mobilen Gerät, etwa einem Smartphone oder einem Tablet, auf dem Android installiert ist, besitzen und ein Grundverständnis für den Umgang mit Apps aufweisen.

Zudem kann angenommen werden, dass der spätere Nutzer/ die Nutzerin der App ein preisbewusster Konsument ist, der Sonderangebote wahrnimmt und sich bereits zuvor mit der Reduzierung von Fixkosten beschäftigt hat.

Die Produkteingrenzung, die bereits durch die Vorgabe des Betriebssystems Android, vorgenommen wird, hat auch einen entscheidenden Einfluss auf die Zielgruppe. Nutzer/ die Nutzerin eines Endgerätes mit dem Betriebssystem iOS können diese App nicht ver- wenden.

Zusammenfassend lässt sich die Zielgruppe wie folgt definieren: Die App richtet sich an Privatpersonen, die nach §2 BGB voll geschäftsfähig sind, im deutschsprachigen Raum leben und bereits Erfahrungen im Umgang mit mobilen Endgeräten, auf denen das Betriebssystem Android installiert ist, besitzen.

Zudem muss die Person ein mobiles Endgerät besitzen, auf dem das Betriebssystem Android ab der Version 5.0 verwendet wird.

3.1.2 Marktanalyse bzw. Analyse bestehender Lösungen

Ziel dieses Kapitels ist es, einen kurzen Überblick über die sich bereits auf dem Markt befindlichen Lösungen zu geben.

Die Lösungsalternativen sollen notwendige Handlungen, die nach Abschluss eines Vertrages durchgeführt werden müssen, vereinfachen. Es werden nur Apps betrachtet, die für mobile Endgeräte mit dem Betriebssystem Android publiziert wurden.

An dieser Stelle folgt eine Liste der Apps, die eine vergleichbare Lösung anbieten:

- AboAlarm
- Benchobox
- Verträge und Abonnements
- Abo Manager
- Volders - Vertragsassistent
- Kündigung - Verträge kündigen
- Vertrag im Blick
- Simplr
- Verivox Vertragspilot

Die Bewertung der Lösungsalternativen erfolgt in dieser Arbeit lediglich nach dem Funk- tionsumfang. Die Usability wird in diesem Zusammenhang nicht untersucht. Zur Veran- schaulichung der Apps und ihrer jeweiligen Funktionen und wurde die Form einer Matrix gewählt.

Vollständigkeit der definierten Funktionalitäten

Legende

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Marktanalyse - Vollständigkeit der definierten Funktionalitäten

Abbildung in dieser Leseprobe nicht enthalten

Die Analyse der Funktionen zeigt, dass einige Apps viele der Anforderungen bereits erfüllen. Jedoch weist keine App sämtliche der zuvor definierten Anforderungen auf.

3.1.3 Systeme, die für die Entwicklung benötigt werden

Bevor mit der Programmierung begonnen werden kann, muss neben den Anforderungen an die zu entwickelnde App auch die für die Programmierung benötigte Software und Hardware festgelegt werden.

Zur Programmierung einer App müssen die folgenden Voraussetzung erfüllt sein:

Software

- Android Studio - die offizielle IDE für Android
- Java-SDK und Android SDK

Hardware

- ein PC

- auf dem zumindest das Betriebssystem Microsoft Windows 7, MAC OS X 10.10 oder Linux GNOME installiert ist
- der über mindestens 4 GB RAM und mindestens 2 GB freien Festplatten- speicher verfügt

- ein Monitor, der eine Auflösung von mindestens 1280 x 800 Pixel aufweist³⁵

- ein Smartphone, auf dem mindestens das Betriebssystem Android 4.4 Kitkat auf dem API-Level 14 installiert ist

3.1.4 Konzeption und Design

Aus den zuvor definierten Anforderungen lassen sich klare Strukturen ableiten. Im Folgenden wird zunächst der Entwurf der Datenbank und anschließend der Entwurf der Software thematisiert.

3.1.4.1 Datenbank

Die Konzeption der Anwendung baut auf dem ANSI-Dreischichtenmodell auf.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 ANSI-Dreischichtenmodell

Quelle: TH Köln, Campus Gummersbach. (kein Datum). ANSI-3-Ebenmodell. Abgerufen am 14. 01 2018 von Daten- banken Online Lexikon: http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/ANSI-3-Ebenenmodell

Das Modell „[…] beschreibt den Schritt vom Fachkonzept über das DV-Konzept zur Implementierungsebene […]“³⁶. Es zeigt eine klare Trennung zwischen dem Anwendungssystem und dem Datenbanksystem.³⁷

Aufbauend auf den in der Anforderungsanalyse informell beschriebenen Informationen wurde zunächst das semantische Modell erstellt.³⁸ „Ziel des konzeptionellen Entwurfs ist die formalisierte Beschreibung des betrachteten Sachverhalts.“³⁹ Aufgrund der Verbrei- tung wurde die Form des ER-Modells nach der Chen-Notation gewählt. Es definiert die Datenelemente mit ihren Attributen. Zudem werden die Beziehungen der einzelnen Enti- täten geklärt.⁴⁰

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Datenbank - ER-Modell nach der Chen-Notation

Im nächsten Schritt wurde daraus ein relationales Datenmodell abgeleitet. Dabei wurde das konzeptionelle Schema (ER-Modell) in das Datenbankschema transformiert.⁴¹ Dieses Datenmodell wurde im Anschluss in der Datenbanksprache SQL generiert.

3.1.4.2 Anwendung

Um alle zur Verfügung stehenden Views darstellen zu können, wurde ein UML-Struk- turdiagramm erstellt. Aus Gründen der Übersichtlichkeit wurden die Fragmente zum Hinzufügen, Ändern eines Datensatzes, bis auf die zum Ändern und Hinzufügen einer Kategorie außer Acht gelassen. Des Weiteren wurden die InputDialoge nicht dargestellt. Zudem nur eine der ListViews und eine ListViewAdapter modelliert.

3.1.5 Roadmap

Um die Anforderungen zu strukturieren, zeigt die Roadmap, in welcher Reihenfolge die einzelnen Elemente implementiert werden müssen. Elemente mit der gleichen Reihenfolgennummerierung könnten dabei theoretisch gleichzeitig bearbeitet werden.

Beispielsweise ist es nicht möglich, ein neues Element zu speichern, wenn keine Datenbank existiert. Die Priorität der einzelnen Funktionen wurde auf einer Skala von 1-3 bewertet, wobei die Ziffer 1 der Bedeutung „sehr wichtig“ und 3 der Bedeutung „am wenigsten wichtig“ entspricht.

Tabelle 3: Roadmap für die Entwicklung der Applikation

Abbildung in dieser Leseprobe nicht enthalten

3.2 Software-Evaluation

Die Usability-Prüfung stellt einen wichtigen Aspekt bei der Erstellung einer SoftwareLösung dar. Sie dient im Bereich des Design-Science-Ansatzes der InformationssystemsForschung dazu, die Nützlichkeit, Qualität und Wirksamkeit der Anwendung zu bewerten.⁴² Dabei stehen die Wünsche und Erwartungen des Benutzers/ der Benutzerin in Bezug auf das Angebot im Fokus.⁴³

Das folgende Kapitel widmet sich der Usability-Prüfung des angefertigten Prototyps, insbesondere stehen der Usability-Test mit den Benutzern/ Benutzerinnen und die anschließende Beurteilung mithilfe des entwickelten Fragebogens nach ISO 9241/110 im Mittelpunkt der Betrachtung.

Andere Methoden, wie die Fokus Group oder eine Experten-Prüfung, wurden aus zeitlichen Gründen nicht durchgeführt und werden in dieser Arbeit nicht weiterverfolgt.

3.2.1 Forschungsdesign

Die Hauptaufgabe des Usability-Tests besteht darin, mögliche Schwachstellen aufzude- cken, um die Ursache für ein auftretendes Problem zu identifizieren. Bei der Untersu- chung handelt es sich nicht um eine empirische Untersuchung. Somit verfolgt der Test nicht das Ziel, eine repräsentative, allgemein gültige empirische Theorie zu bestätigen.⁴⁴ Die Anzahl an Probanden/Probandinnen für den Test ist aus diesem Grund deutlich ge- ringer.

Untersuchungsgegenstand

Der Untersuchungsgegenstand der Usability-Prüfung ist der im Rahmen der Bachelorar- beit entwickelte Prototyp zur Unterstützung der Vertragsverwaltung. Die für die Prüfung relevanten Funktionen umfassen den gesamten Umfang des entwickelten Prototyps.

Ziele

Durch die Erhebung soll die Qualität des Artefaktes verbessert werden. Dies soll durch die Analyse der Erwartungen der Benutzer/in an die Applikation sowie durch die an- schließende Nutzung des Artefakts erreicht werden. Die während der Nutzung auftreten- den Probleme sollen aufgezeigt werden und im Anschluss die Ursachen für das Auftreten der Schwierigkeiten analysiert werden. Abschließend sollen Maßnahmen zur Behebung des Problems entwickelt werden.

3.2.2 Klassifikation der Erhebungsmethoden

Die beschriebenen Ziele sollen durch die Durchführung eines Tests mit repräsentativen Nutzern verfolgt werden. Dabei werden den Probanden/Probandinnen typische Aufgaben gestellt, die diese mit Hilfe der Applikation lösen sollen. Sofern der Proband/ die Proban- din dem zustimmt, wird das Verhalten in den konkreten Situationen als Video aufgezeich- net.

Zusätzlich soll der Proband/ die Probandin am Ende des Tests seinen Eindruck schriftlich dokumentieren. Die Befragung wird über einen Fragebogen realisiert. Er soll den Benut- zer/ die Benutzerin dabei unterstützen, die subjektiven Wahrnehmungen zu strukturieren und ihm so die Bewertung erleichtern. Des Weiteren soll der Fragebogen verhindern, dass der Interviewer Einfluss auf den Probanden ausübt. Der Fragebogen enthält hauptsächlich geschlossene Fragen mit Vorgabe einer endpunktverbalisierten Skala von -3 bis 3.

3.3 Umsetzung und Implementierung der Applikation

Das folgende Kapitel beschreibt den in der Programmiersprache Java geschriebenen Code. Es gliedert sich nach den Klassen der Anwendung. Dabei wird zunächst auf die Klassen „Category“, „Contract“, „Partner“ und „User“ eingegangen, da diese für alle wei- teren Klassen relevant sind. Anschließend erfolgt die Darstellung der für die Erstellung, Änderung und Löschung der Datenbank zuständigen Klasse „Databasehelper“. Anschlie- ßend wird die Klasse „DatabaseAdapter“ erläutert, die die Organisation von Funktionen zum Abrufen, Speichern, Ändern und Löschen von Datensätzen übernimmt. Im Folgen- den werden die Fragmente beschrieben, wobei jene Fragmente, die starke Ähnlichkeiten zueinander aufweisen, zusammengefasst werden. Jedes Fragment verfügt über ein eige- nes Layout, die Zuordnung des Layouts zur Klasse wird in den einzelnen Abschnitten geschildert.

3.3.1 Die Klassen „Category“, „Contract“, „Partner“ und „User“

Die Klassen enthalten die für die Objekte „Category“, „Contract“, „Partner“ und „User“ festgelegten Eigenschaften. Die Objekte der Klasse werden über die Instanziierung abgeleitet und enthalten jeweils die gleichen Eigenschaften.

Jede Klasse enthält ausschließlich private Attribute mit primitiven Datentypen sowie öf- fentliche getter- und setter-Methoden, um die Werte des Attributes abzurufen (getter) o- der zu verändern (setter).

Zur Verdeutlichung der Thematik wird die Klasse „Category“ näher beschrieben. Sie wurde aufgrund ihres geringen Umfangs ausgewählt. Sie steht jedoch sinnbildlich für alle genannten Klassen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 Darstellung der Klasse Category und eines Objektes der Klasse Category

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Quellcode der Klasse „Category“

3.3.2 Klasse „DatabaseHelper“

Das Management der Datenbank übernimmt die „DatabaseHelper“-Sub-Klasse. Sie ist zuständig für die Erstellung und das Versionsmanagement. Durch das Implementieren der Methoden onCreate(SQLiteDatabase) und onUpgrade(SQLiteDatabase, int, int), der abstrakten Klasse SQLiteOpenHelper, überwacht die Klasse das Öffnen der Datenbank, die Erstellung und, sofern erforderlich, die Aktualisierung der Datenbank.⁴⁵

Zudem enthält die Klasse die Deklaration der Klassenvariablen. Die Variablen bestim- men nicht nur die Namen der Datenbank, der Datenbanktabellen (Relationen) und der Datenbankspalten (Attribute), sondern auch die SQL-Abfragen zur Generierung und Lö- schung der Datenbank sowie deren Tabellen anhand der zuvor im relationalen Datenmo- dell definierten Elemente.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10:Quellcodeausschnitt der Methode „sqlCreateTableCategory“

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11:Quellcodeausschnitt der Methode „onCreate"

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12:Quellcodeausschnitt der Methode „onUpgrade"

3.3.3 Klasse „DatabaseAdapter“

Das Abrufen, Ändern und Löschen der Daten aus der Datenbank wird von der Klasse „DatabaseAdapter“ übernommen. Dazu wird zunächst ein Objekt der Klasse „SQLData- base“, der Klasse „Context“ und der Klasse „DatabaseHelper“ erzeugt und ein Konstruk- tor festgelegt.

Anschließend werden die Methoden zum Hinzufügen eines Datensatzes in eine der Ta- bellen, die zuvor in der Klasse „DatabaseHelper“ definiert worden sind, durchgeführt. Zunächst wird die Methode „getWritableDatabase()“, die ein Objekt der Klasse „SQLi- teOpenHelper“ zurückgibt, aufgerufen. Diese ermöglicht das gleichzeitige Lesen und Schreiben in der Datenbank.⁴⁶ Darauf folgend werden die Attributwerte der Klasse „U- ser“ über ein „ContentValue“ - eine Klasse, die zum Speichern von Werten verwendet wird - gemeinsam mit der für den Wert vorgesehenen Spalte assoziiert. Zur physikali- schen Speicherung der Daten in der Datenbank wird die Methode „insert(String table, String nullColumnHack, ContentValues values)“ des Objekts der „SQLiteDatabase“- Klasse verwendet. Die „insert“-Methode sendet einen Wert des Datentyps „long“ zurück, der im Anschluss geprüft wird. Dadurch wird sichergestellt, dass der neue Datensatz in der Tabelle gespeichert wurde, beziehungsweise geprüft, ob die neue Zeile in der Tabelle existiert.

[...]

---

¹ (Statistisches Bundesamt, 2017)

² Vgl. (Statistische Ämter des Bundes und der Länder, 2016)

³ (IfD Allensbach)

⁴ Vgl. (Hobel & Schütte, kein Datum)

⁵ Vgl. (Android Developers, kein Datum)

⁶ Vgl. (Android Developers, kein Datum)

⁷ Vgl. (Bleske, 2013, S. 20)

⁸ (Android Developers, kein Datum)

⁹ Vgl. (Android Developers, kein Datum)

¹⁰ Vgl. (Wagner, kein Datum)

¹¹ Vgl. (Bleske, 2013, S. 139)

¹² Vgl. (Fragment, kein Datum)

¹³ Vgl. (Android Developers, kein Datum) Content Provider

¹⁴ Vgl. (Bleske, 2013, S. 126)

¹⁵ Vgl. (Abts & Mülder, 2017, S. 161)

¹⁶ (Abts & Mülder, 2017, S. 169)

¹⁷ Vgl. (Abts & Mülder, 2017, S. 169-170)

¹⁸ Vgl. (Abts & Mülder, 2017)

¹⁹ Vgl. (SQLite, kein Datum)

²⁰ Vgl. (SQLite, kein Datum)

²¹ Vgl. (SQLite, kein Datum)

²² Vgl. (Abts & Mülder, 2017, S. 162)

²³ Vgl. (Bleske, 2013, S. 141)

²⁴ Vgl. (Controls, kein Datum)

²⁵ Vgl. (SELFHTML e.V., 2017)

²⁶ (Gross, 2013)

²⁷ Vgl. (Gross, 2013)

²⁸ Vgl. (Woletz & Joisten, 2013)

²⁹ Vgl. (Smart News Fachverlag GmbH, 2008)

³⁰ Vgl. (Rampl, kein Datum)

³¹ Vgl. (Woletz & Joisten, 2013)

³² Vgl. (Konrad, 2010)

³³ Vgl. (Kirchgeorg, kein Datum)

³⁴ Vgl. (Haufe-Lexware GmbH & Co. KG, kein Datum)

³⁵ (Index Android Studio, kein Datum)

³⁶ (Hansen & Neumann, 2009, S. 296)

³⁷ Vgl. (Hansen & Neumann, 2009) ER-Modell

³⁸ Vgl. (Krypczyk, 2013)

³⁹ (Krypczyk, 2013)

⁴⁰ Vgl. (Hansen & Neumann, 2009)

⁴¹ (Krypczyk, 2013)

⁴² Vgl. (Däuble, et al., 2014)

⁴³ Vgl. (Fritz, Richter, Dynkowska, Kaltwasser, & Stührenberg, 2006)

⁴⁴ Vgl. (Fritz, Richter, Dynkowska, Kaltwasser, & Stührenberg, 2006)

⁴⁵ Vgl. (SQLiteOpenHelper, kein Datum)

⁴⁶ Vgl. (SQLiteOpenHelper, kein Datum)