zum - Gutenberg Lehrkolleg (GLK)

Bachelorarbeit
Zum Thema
Ein modernes Audience Response System
Autor: Alessa Groß
Betreuer: Dr. Hans-Jürgen Schröder
Abgabedatum: 04. Juni 2014
Persönliche Danksagung
Persönliche Danksagung
An dieser Stelle möchte ich mich bei all denjenigen bedanken, die mich bei der Erstellung dieser
Arbeit unterstützt haben.
Ein besonderer Dank gilt Herrn Dr. Hans-Jürgen Schröder für die Betreuung meiner Arbeit sowie
für die konstruktiven Fachgespräche, durch die er mir immer wieder den nötigen Aufschwung
gegeben hat.
Mein besonderer Dank gilt auch Herrn André Runge, der mir geduldig mit allen meinen
Anforderungen und Fragen an die Serverseite geholfen hat und immer schnell eine Lösung parat
hatte.
II
Inhaltsverzeichnis
Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................................. III
Abbildungsverzeichnis ........................................................................................................... V
Tabellenverzeichnis .............................................................................................................. VI
Quellcodeverzeichnis ........................................................................................................... VII
1
Einleitung ....................................................................................................................... 1
2
Grundlagen .................................................................................................................... 2
2.1
Problemstellung ............................................................................................................... 2
2.2
Konkurrenzprodukte – Eine Analyse ................................................................................ 4
2.2.1
ARSnova.................................................................................................................... 4
2.2.2
eduVote .................................................................................................................... 7
2.2.3
PINGO ....................................................................................................................... 9
2.2.4
FreeQuizDome........................................................................................................ 11
2.2.5
Konsequenzen für die Entwicklung von Mainzel ................................................... 13
2.3
3
2.3.1
Benutzer und ihre Rollen........................................................................................ 14
2.3.2
Aufbau einer Umfrage ............................................................................................ 15
Anforderungen an das System .......................................................................................17
3.1
Funktionale Anforderung ............................................................................................... 17
3.1.1
Muss-Kriterien ........................................................................................................ 17
3.1.2
Kann-Kriterien ........................................................................................................ 18
3.2
4
Konzept .......................................................................................................................... 14
Nicht-funktionale Anforderungen .................................................................................. 19
3.2.1
Muss-Kriterien ........................................................................................................ 19
3.2.2
Kann-Kriterien ........................................................................................................ 19
3.3
Use Case Diagramm ....................................................................................................... 19
3.4
Use Cases........................................................................................................................ 20
Planung und Design .......................................................................................................27
4.1
Systemarchitektur .......................................................................................................... 27
4.1.1
Globale Systemarchitektur ..................................................................................... 27
4.1.2
Architektur eines Mainzel-Clients .......................................................................... 28
4.1.3
App-Architektur ...................................................................................................... 30
4.2
Frontend-Design............................................................................................................. 31
4.3
Datenbanken-Design ...................................................................................................... 35
4.3.1
Globale MS SQL Datenbank ................................................................................... 36
III
Inhaltsverzeichnis
5
4.3.2
Lokale SQLite-Datenbank ....................................................................................... 37
4.3.3
Synchronisation ...................................................................................................... 39
4.3.4
XML-Datentypen .................................................................................................... 39
Entwicklung ..................................................................................................................42
5.1
Entwicklungssoftware .................................................................................................... 42
5.1.1
Balsamiq Mockups ................................................................................................. 42
5.1.2
draw.io ................................................................................................................... 42
5.1.3
Gimp ....................................................................................................................... 43
5.1.4
Android Developer Tools Bundle ........................................................................... 43
5.1.5
SQL Server Management Studio und MS SQL Server............................................. 43
5.2
Verwendete Technologien und Bibliotheken................................................................. 44
5.2.1
Java ......................................................................................................................... 44
5.2.2
Android SDK und Android Support v4-Bibliothek .................................................. 44
5.2.3
AChartEngine .......................................................................................................... 45
5.2.4
SQLSRV ................................................................................................................... 45
5.2.5
JSON ....................................................................................................................... 45
5.2.6
Android Holo Colors ............................................................................................... 45
5.3
Umsetzung der App mit Java, XML und den verwendeten Bibliotheken ...................... 46
5.3.1
Klassen.................................................................................................................... 46
5.3.2
XML-Dateien ........................................................................................................... 49
6
Das Produkt ..................................................................................................................50
7
Fazit ..............................................................................................................................56
7.1
Einsatzfähigkeit .............................................................................................................. 56
7.2
Umgesetzte Anforderungen ........................................................................................... 56
7.3
Ausblick .......................................................................................................................... 57
Anhang A - Use Cases .......................................................................................................... VIII
Erklärung der Selbstständigkeit .......................................................................................... XVII
IV
Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung 2.1: Die Hardware des bisherigen ARS des Instituts für Informatik ............................... 4
Abbildung 2.2: Dozentenbereich von ARSnova ............................................................................... 5
Abbildung 2.3: Beantwortung einer Frage in ARSnova .................................................................... 6
Abbildung 2.4 Beantwortung einer Frage in EduVote ..................................................................... 8
Abbildung 2.5: Die Autorenansicht einer vergangenen Frage in PINGO ......................................... 9
Abbildung 2.6: Beantwortung einer Frage in PINGO ..................................................................... 10
Abbildung 2.7: Desktopsoftware von FreeQuizDome.................................................................... 12
Abbildung 2.8: Beantwortung einer Frage in FreeQuizDome ........................................................ 12
Abbildung 3.1: Use-Case Diagramm............................................................................................... 20
Abbildung 3.2: Benutzeroberfläche zum Beantworten einer Frage .............................................. 22
Abbildung 3.3: Detailansicht von Umfragen .................................................................................. 24
Abbildung 3.4: Benutzeroberfläche zum Einloggen in die App. ..................................................... 25
Abbildung 3.5: Benutzeroberfläche zum Einsehen der Einladungen. ............................................ 26
Abbildung 4.1: Globale Client-Server-Architektur von Mainzel ..................................................... 27
Abbildung 4.2: Architektur eines Clients im Schichten-Model ...................................................... 29
Abbildung 4.3: Vereinfachte Architektur der Mainzel-App ........................................................... 31
Abbildung 4.4: Umfrage-Übersicht ................................................................................................ 32
Abbildung 4.5: Frontend-Komponenten der App .......................................................................... 33
Abbildung 4.6: Detailansicht einer Frage ....................................................................................... 34
Abbildung 4.7: Umfragen-Editor .................................................................................................... 35
Abbildung 4.8: Globales Datenbankdiagramm .............................................................................. 37
Abbildung 4.9: Diagramm der lokalen Datenbank ......................................................................... 38
Abbildung 5.1: Klassendiagramm……………………………………………………………………………………………….47
Abbildung 6.1: Login-Ansicht ......................................................................................................... 50
Abbildung 6.2 Nach dem Einloggen in die Mainzel-App ................................................................ 51
Abbildung 6.3: Ansicht zum Beantworten einer Single-Choice-Frage ........................................... 52
Abbildung 6.4: Auswertung drei vergangener Fragen ................................................................... 53
Abbildung 6.5: Umfrage-Editor ...................................................................................................... 54
Abbildung A.1: Benutzeroberfläche zum Bearbeiten von Umfragen ............................................. IX
Abbildung A.2: Ansicht zum Einsehen der eigenen Ergebnisse in bereits geschlossenen Fragen .. XI
Abbildung A.3: GUI zum Einloggen in die App und zum Erstellen eines neuen Accounts ............. XII
Abbildung A.4: GUI für die Einsicht der eigenen Account-Daten eines Benutzers ....................... XIII
V
Tabellenverzeichnis
Tabellenverzeichnis
Tabelle 2.1: Auflistung aller Frage-Typen von Mainzel .................................................................. 16
Tabelle 3.1: Use Case #05 .............................................................................................................. 21
Tabelle 3.2: Use Case #06a............................................................................................................. 23
Tabelle 3.3: Use Case #09a............................................................................................................. 24
Tabelle 3.4: Use Case #13 .............................................................................................................. 26
Tabelle A.1: Use Case #01 ............................................................................................................. VIII
Tabelle A.2: Use Case #02 ............................................................................................................. VIII
Tabelle A.3: Use Case #03 ............................................................................................................... IX
Tabelle A.4: Use Case #04 ................................................................................................................ X
Tabelle A.5: Use Case #06b .............................................................................................................. X
Tabelle A.6: Use Case #07 .............................................................................................................. XII
Tabelle A.7: Use Case #08 ............................................................................................................. XIII
Tabelle A.8: Use Case #09b ........................................................................................................... XIV
Tabelle A.9: Use Case #10 ............................................................................................................. XIV
Tabelle A.10: Use Case #11 ........................................................................................................... XIV
Tabelle A.11: Use Case #12 ............................................................................................................ XV
VI
Quellcodeverzeichnis
Quellcodeverzeichnis
Quellcode 4.1: Beispiel für ein AnswerXML-Wert einer Single-Choice-Frage ............................... 40
Quellcode 4.2: Beispiel für ein AnswerXML-Wert einer Schätzfrage............................................. 40
Quellcode 4.3: Beispiele für ResultXML-Werte einer Datum- und einer Position-Frage............... 41
VII
1 Einleitung
1 Einleitung
Im Rahmen dieser Arbeit wurde eine Android App entwickelt, die ein modernes Audience
Response System (ARS) darstellt. Die Schritte und Besonderheiten bei der Durchführung der
Planung, Entwicklung und Implementation der App werden auf den folgenden Seiten behandelt.
Ein ARS ermöglicht dem Publikum eines Vortrags die Fragen des Vortragenden mit Hilfe von
„Fernbedienungen“ digitalisiert zu beantworten. Es wertet daraufhin die Ergebnisse aus und stellt
sie in angemessener Weise für die Einsicht durch den Vortragenden bereit. Ein solches System
motiviert und aktiviert das Publikum und gibt gleichzeitig eine Rückmeldung an den Vortragenden,
in wie weit das Publikum ihm folgen kann.
Um ein solches klassisches ARS mit spezieller Hardware durch moderne, hardwareunabhängige
Technologien am Institut für Informatik der Johannes Gutenberg-Universität in Mainz zu ersetzen,
wurde die Idee einer Android App als ARS entwickelt. Die App stellt die Funktionen zum Erstellen
von Fragen, Beantworten durch die Teilnehmer und sowohl zum Auswerten, als auch zum
Einsehen der Ergebnisse bereit. Es kombiniert dadurch die modernen Möglichkeiten einer App mit
dem klassischen Nutzen eines ARS.
Die entwickelte App trägt den Namen „Mainzel“. Auf die Herkunft Bezug nehmend, ist der Name
eine Abkürzung für „Mainzer Audience Interaction Network for large-siZEd Learning groups“. Der
erste Teil des Namens „Audience Interaction Network“ lehnt dabei stark an den Ursprung der App,
nämlich einem Audience Response System, an. Er erweitert allerdings die Bedeutung um die
Neuerungen von Mainzel, die es gegenüber einem klassischen ARS mitbringt. Im Gegensatz zum
klassischen ARS, bietet Mainzel nicht allein die Möglichkeit in eine Richtung Antworten
(„Response“) zu verschicken, vielmehr können alle Benutzer in Interaktion miteinander treten. Die
Rollenverteilung des Vortragenden und der Zuhörerschaft innerhalb des ARS verwischt unter
Mainzel und kann von Mal zu Mal neu verteilt werden. Weiterhin wird der Typ des Systems von
Mainzel näher als Netzwerk („Network“) beschrieben. Damit wird der Charakter einer vernetzten
Mainzel-Community hervorgehoben, in der alle Benutzer auf gleicher hierarchischer Ebene stehen
und alle zu jeder Zeit in alle Rollen schlüpfen können, um miteinander in Kontakt zu treten.
Außerdem ist Mainzel durch verschiedene Faktoren wie dem Community-Charakter und der
Verwendung moderner Technologien, die beispielsweise keinen physischen Empfänger, wie im
klassischen ARS, mehr benötigen, für große Gruppen („large-siZEd groups“) geeignet.
Beispielsweise müssen in großen Lehrveranstaltungen nicht einmal alle Beteiligten im selben
Raum sein, um einander Fragen und Antworten zu liefern. Schließlich wurde Mainzel zum Einsatz
in einer Universität entwickelt und daher wurde der Nutzen beim Lernen („Learning groups“) mit
Mainzel stets im Auge behalten.
Zur Aufarbeitung des Themas wird in Kapitel 2 zunächst ein Überblick über den Markt und später
eine Einführung in die Begrifflichkeiten und das Konzept von Mainzel gegeben. Im darauf
folgenden Kapitel 3 werden alle Anforderungen an das System nach den Regeln der SoftwareEntwicklung analysiert. Kapitel 4 bespricht im Anschluss die Überlegungen zum Design des
Systems und der Benutzeroberfläche der App. Daraufhin werden die Entwicklungswerkzeuge und
deren Einfluss auf das System in Kapitel 5 vorgestellt. Kapitel 6 stellt nachfolgend die App als
Produkt vor und abschließend wird in Kapitel 7 ein Fazit über die Umsetzung der Anforderungen
und den Ausblick auf Weiterentwicklungsmöglichkeiten von Mainzel gezogen.
1
2 Grundlagen
2 Grundlagen
Dieses Kapitel widmet sich den Grundlagen der Thematik, indem zunächst die Problemstellung
definiert wird. Darauf folgt eine Analyse bereits bestehender ähnlicher Systeme und schließlich
wird das Konzept des Produkts erklärt, das dieser Arbeit zu Grunde liegt.
2.1 Problemstellung
Jeder kennt das Problem: Bereits in der Schule kämpft der Schüler mit langweiligen
Unterrichtsstunden und trockenem Stoff. Schon lange ist bekannt, dass der klassische
Frontalunterricht für die meisten Lerntypen nicht geeignet ist und so nur wenige Schüler davon
profitieren können. Um dem entgegen zu wirken, wurden und werden alternative
Unterrichtsmethoden entwickelt, die den Schüler mehr in die Vermittlung und Erarbeitung des
Lernstoffes einbinden und bei denen Lehrer öfter Rückmeldung über den Wissensstand der
Schüler erhalten.
Trotz der Veränderungen der Unterrichtsmethoden steht in späteren Ausbildungsabschnitten
schließlich mehr die Wissensvermittlung als die didaktische Methode im Mittelpunkt. Vor allem
Vorlesungen im akademischen Bereich, in denen ein Dozent zumeist im klassischen Vortrag an der
Tafel oder mit vorbereiteter Beamer-Präsentation das Wissen vermittelt, treffen auf diese
Beschreibung zu. Das mag seine Richtigkeit in der akademischen Ausbildung haben, in der es vor
allem um die effiziente Weiterbildung geht und die Eigeninitiative der Lernenden notwendig ist.
Dennoch können die Grundgedanken aus den neuen Lernmethoden, nämlich den Lernenden mit
einzubeziehen und die Rückmeldungen an den Lehrenden zu erhöhen, auch an der Hochschule
von Vorteil sein.
Sicherlich gibt es bereits Empfehlungen und Tipps, die diese Erkenntnisse allgemein für Vorträge
aller Art umsetzen. Beispielsweise ist es für den Vortragenden am einfachsten den Wissenstand
des Publikums in Erfahrung zu bringen und gleichzeitig das Publikum während des Vortrags zu
aktivieren, indem er von Zeit zu Zeit Fragen an die Zuhörer stellt. Durch das zufällige Auftreten der
Interaktion zwischen Dozent und Zuhörerschaft wird die Aufmerksamkeit erhöht und der Vortrag
wirkt kurzweiliger. Auf diese Weise erreichen den Dozenten allerdings bei jeder Frage nur eine
oder zumindest wenige Antworten und diese sind zumeist aus den ersten paar Reihen des
Hörsaals.
Oft genug kommt es in dieser Situation vor, dass ein Teil des Publikums die Frage nicht einmal
gehört hat, weil er abgelenkt war. Auch das Problem solcher Ablenkungen ist jedem bekannt.
Vielleicht ist man als Zuhörer im Allgemeinen unkonzentriert oder der Sitznachbar lenkt durch
Gesprächigkeit ab oder moderne Ablenkungen wie Laptop, Tablet und Handy sorgen dafür, dass
auch der beste Vortrag ausgeblendet wird.
Allerdings können genau diese Geräte die Ablenkung in eine Aktivierung der Zuhörerschaft
umkehren: Ein Szenario wäre beispielsweise ein auf seinem Smartphone im Internet surfender,
abgelenkter Student, der in dem Moment für den Vortrag reaktiviert wird, wenn auf seinem
Smartphone eine Nachricht aufklappt, die ihm mitteilt, dass es eine neue Frage in dieser Vorlesung
gibt, für die beispielsweise nur noch 60 Sekunden zum Beantworten zur Verfügung stehen. Der
Student hat zwar verpasst, dass der Dozent diese Frage gestellt hat, mit Klick auf die Nachricht auf
seinem Smartphone kann er sie aber trotzdem einsehen und seine Antwort sofort eingeben und
2
2 Grundlagen
abschicken. Im vom Student verpassten Teil des Vortrags hat der Dozent diese Frage in einem
speziellen Umfragesystem für die Beantwortung für 60 Sekunden freigegeben und somit die
Benachrichtigung des Studenten durch sein Smartphone ausgelöst. Nachdem die 60 Sekunden
abgelaufen sind, projiziert der Dozent die Auswertung der Antworten an die Leinwand und der
Student sieht dort oder auf seinem Smartphone, auf dem ein ähnliches Diagramm erscheint, ob
seine Antwort richtig war.
Ein solches Umfragesystem, in dem es einen „Auswertungsknoten“ gibt, der mit mehreren
„Empfängern“ zum Beantworten der Fragen kommuniziert, und zur automatisierten
Kommunikation zwischen Vortragendem und Publikum dient, wird Audience Response System
oder kurz ARS genannt. Das wohl bekannteste ARS kommt bei der Auswertung des
Publikumsjokers in der Fernsehsendung „Wer wird Millionär“ zum Einsatz. Hier stellt der
Moderator die Frage und gibt deutlich an, welche Antwortmöglichkeiten welchem Buchstaben
zugeordnet werden. Daraufhin drücken die Zuschauer im Publikum den Buchstaben ihrer Wahl
auf einer Art Fernbedienung und geben auf diese Weise ihre Antwort ab. Die Daten werden nach
Ablauf der Zeit im Computer ausgewertet und als das bekannte Diagramm auf den Bildschirmen
der Zuschauer zu Hause angezeigt.
Die Anschaffung eines solchen Systems und der Hardware ist sicherlich teuer für eine Hochschule
und letztendlich werden nie genug Fernbedienungen für eine Vorlesung zur Verfügung stehen.
Aber wie bereits im Szenario dargestellt, ist es eine Möglichkeit ein ARS als Software anzubieten,
das die Hardware nutzt, die bereits im Hörsaal vorhanden ist. Darüber hinaus kann eine solche
Software noch weitere vorteilhafte Funktionen implementieren, die durch die festgelegte
Hardware der klassischen ARS beschränkt wird. Beispielweise das Anzeigen der Fragetexte und
der Antwortmöglichkeiten oder die Erweiterbarkeit der Fragetypen, die bei den meisten
klassischen ARS auf Single-Choice Fragen mit fester Anzahl an Antwortmöglichkeiten beschränkt
sind. Auch die strikte Trennung zwischen Auswertungsmaschine und Antwort-Fernbedienungen
kann aufgehoben werden, sodass alle Beteiligten in der Position des Fragenden und des
Antwortenden zur selben Zeit sein können. Schließlich ist auch eine Auswertung und Archivierung
der Ergebnisse nicht nur für den Fragenden denkbar, sodass die Zuhörer auch im Nachhinein einen
Überblick über die eigene Leistung einsehen können.
In dieser Arbeit wird ein solches, modern interpretiertes ARS vorgestellt. Das System Mainzel
wurde aus der Idee heraus geboren, ein klassisches, wie oben beschriebenes ARS unter
Zuhilfenahme moderner Technologien am Institut für Informatik der Johannes GutenbergUniversität zu ersetzen. Es galt einen Nachfolger für das institutseigene ARS, das in Abbildung 2.1
gezeigt wird, zu entwickeln, das die Aufgaben eines klassischen ARS übernimmt und gleichzeitig
die Vorteile der verwendeten Technologien aufgreift, um Mainzel zu einem modernen,
erweiterten Kommunikationsmittel zwischen Vortragendem und Zuhörerschaft zu machen.
3
2 Grundlagen
Abbildung 2.1: Die Hardware des bisherigen ARS des Instituts für Informatik - Das ARS besteht aus mehreren
Fernbedienungen (grau dargestellt), die durch Identifikationsnummern gekennzeichnet sind, dem Empfänger(lila
dargestellt), der per Ethernet-Kabel an einen Computer angeschlossen wird und einer Auswertungssoftware, die auf
demselben Computer installiert wird. Zum Abschicken seiner Antwort drückt der Student einen der Knöpfe A bis F auf
einer Fernbedienung.
Ein Prototyp wurde bereits im Rahmen des Datenbanken-Praktikums im Wintersemester
2013/2014 als Web-App entwickelt. Diese Version von Mainzel implementierte bereits viele
Grundgedanken des in dieser Arbeit vorgestellten Produkts. Als Web-App ist es beispielsweise von
den meisten in einer Vorlesung vorhandenen Geräten schnell erreichbar. Es stellt Ergebnisse in
Kuchen- und Balkendiagrammen dar, sodass sie dem Publikum ohne großen Aufwand anschaulich
präsentiert werde können. Weiterhin können Teilnehmer nach dem Beenden einer Frage die
eigene Antwort und die richtige Antwort einsehen. Auch konzeptionell beeinflusst der Prototyp
das im Rahmen dieser Arbeit entwickelte System. Beispielsweise wurden sowohl die in Kapitel 2.3
angesprochenen Begrifflichkeiten und Beziehung als auch das Datenbankmodel weitestgehend
übernommen. Alle Veränderungen, Weiterentwicklungen und Anpassungen zwischen dem
genannten Prototypen und dem Mainzel, das dieser Arbeit zu Grunde liegt, sind mit dem
Hintergrund gemacht worden, Mainzel so offen wie möglich zu gestalten, sodass sein Einsatz nicht
allein auf den akademischen Bereich beschränkt ist, sondern sich für Vorträge und Fragerunden
aller Art eignet.
2.2 Konkurrenzprodukte – Eine Analyse
Oft wird auf unterschiedliche Weise versucht Vorträge oder Unterrichtsstunden in der Schule und
im universitären Umfeld anschaulicher, spannender und kurzweiliger zu gestalten. Aus diesem
Grund ist es selbstverständlich, dass das Mainzel-System nicht das einzige seiner Art auf dem
Markt sein wird. Es verfolgt zwar durch seinen mobilen Einsatz und den offen gehaltenen
Fragetypen nicht zwangsläufig das Ziel ausschließlich im Frontalunterricht eingesetzt zu werden,
aber es muss sich dennoch dem Vergleich mit bereits bestehenden Produkten stellen, die für
diesen Einsatz konzipiert wurden. Es gibt bereits eine Reihe von ARS auf Basis von Web- und
mobilen Technologien, die genau wie Mainzel, für den akademischen Bereich entwickelt wurden.
Im Folgenden werden vier Produkte dieser Art vorgestellt und ein Vergleich mit Mainzel gezogen.
2.2.1
ARSnova
Das kostenlose Produkt „ARSnova“ der Technischen Hochschule Mittelhessen ist Mainzel
vielleicht noch am ähnlichsten, da es vorwiegend durch Bachelor- und Master-Arbeiten entwickelt
und weiterentwickelt wird. Es ist ein typisches Produkt aus der Hochschule für die Hochschule und
4
2 Grundlagen
lädt mit dem Slogan „Feedback im Hörsaal“ auf der Startseite, auf der man sich als „Zuhörer/in“
oder „Dozent/in“ anmeldet, einzig zur Benutzung im universitären Bereich ein. Dennoch ist das
Konzept, das sich hinter der kategorisierenden Startseite verbirgt, offen für viele andere
Anwendungsbereiche.
Abbildung 2.2: Dozentenbereich von ARSnova - Dargestellt ist die Ansicht zum Erstellen von vorbereiteten Fragen. [1]
In ARSnova werden mehrere Fragen in einer Session zusammengefasst. Es gibt die Fragetypen
Multiple-Choice, Single-Choice, Ja-Nein-Frage, Freitext, Rating1, Schulnote und Lernkarte2. Als
einziges Produkt unter den in dieser Arbeit vorgestellten Konkurrenzprodukten von Mainzel, kann
der Dozent für jede Frage angeben, ob eine Enthaltung möglich sein soll. Die Fragen können
entweder als Hörsaal-Fragen angelegt werden und sie dadurch erst in der Vorlesung zu
beantworten oder als Vorbereitungsfrage eingetragen werden, sodass Teilnehmer sie vorher
schon zur Vorbereitung nutzen können. Die Übersicht über bereits erstellte Vorbereitungsfragen
ist in Abbildung 2.2 dargestellt. Aktive Teilnehmer an einer Session, werden in Form von einem
Zähler auf dem Startbildschirm auf die Anzahl unbeantworteter Fragen hingewiesen. Ebenfalls als
einziges System, der hier analysierten Konkurrenzprodukte von Mainzel, hat der Dozent hier die
Möglichkeit mehrere Fragen parallel zu stellen. Die Ansicht zur Beantwortung einer Frage wird in
Abbildung 2.3 dargestellt.
1
Im Rating-Frage-Typ von ARSnova werden fünf vorgefertigte Antwortmöglichkeiten von „trifft voll zu“ bis
„trifft nicht zu“ angeboten.
2
Lernkarten in ARSnova sind zum Selbst-Studium ausgelegt und können wie digitale Kartei-Lernkarten
angesehen werden.
5
2 Grundlagen
Mit einem Swipe3 nach rechts oder links kann der Benutzer die anderen Fragen der Session
einsehen und beantworten. Die Fragen müssen manuell freigegeben und gesperrt werden. Ein
Dozent kann die Beantwortung einer Frage pausieren und zu einem späteren Zeitpunkt fortsetzen.
Weiterhin kann Feedback zum Tempo der Vorlesung in Form von Smileys gegeben werden, das
mehrmals während einer Vorlesung vom Teilnehmer aktualisiert werden kann. Auch dieses
Feature wird durch die Beschreibung der Smileys mit „Kann folgen“, „Bitte schneller“, „Zu schnell“
und „Abgehängt“ als Vorlesungshelfer kategorisiert, obwohl es viel mächtiger ist und auch in
anderen Anwendungsbereichen Hilfestellung beim Einholen von Feedback leisten kann. Als
weitere Feedback-Funktion kann ein Teilnehmer seinerseits Zwischenfragen an den Dozent
stellen, der diese nach Erhalt mündlich beantworten kann, sobald es in den Vortrag passt.
ARSnova ist als Web-App entwickelt worden und daher auf allen Geräten über einen Browser
erreichbar. Benutzer melden sich entweder mit dem Uni-Account an oder geben den eigenen
Facebook- oder Google-Account an. Auch ein anonymer Gastzugang ist möglich, ohne dass
Umfrageergebnisse später einsehbar sind.
Sowohl die Bedienung als auch das Design und der Aufbau der User-Interface-Elemente (UIElemente) der Web-App sind auf die Benutzung mit kleinen Touchdisplays ausgelegt. Dabei sei
erwähnt, dass die Darstellung für Teilnehmer den erweiterten Platz auf einem großen Bildschirm
nicht ausnutzt. Zum Beispiel geschieht das Navigieren durch die einzelnen Fragen, wie sie in
Abbildung 2.3 dargestellt ist, durch eine horizontale Wischgeste, die auch bei der Benutzung mit
der Maus nachempfunden werden muss.
Abbildung 2.3: Beantwortung einer Frage in ARSnova - In der Abbildung ist die Ansicht zum Abgeben einer Antwort zu
einer Mehrfachauswahl-Frage, die einer Multiple-Choice-Frage in Mainzel entspricht, dargestellt. [1]
3
Ein Swipe ist eine Geste auf einem Touchdisplay. Der Benutzer wischt auf dem Bildschirm mit einem Finger
und gibt dabei eine Geschwindigkeit und eine Richtung vor, die eine App aufgreifen und entsprechend
darauf reagieren kann. Oft wird ein Swipe zum „Blättern“ durch verschiedene, aber hierarchisch gleiche
Ansichten genutzt.
6
2 Grundlagen
Weiterhin existiert die Desktop-Erweiterung „ARSnova Overlay“, die auf einem PC installiert wird
und sich als kleines Widget auf dem Bildschirm über die Präsentationsfolien des Dozenten legt. Es
zeigt auf einen Blick die Ergebnisse des Feedbacks als Smiley und informiert über eingegangene
Zwischenfragen. Mit Klick auf das Widget öffnet sich ein größeres Fenster, in dem die FeedbackStatistik, die Zwischenfragen und der QR-Code für den schnellen Zugang zur Session eingesehen
werden können.
Eine weitere Erweiterung für Dozenten ist der „ARSnova Presenter“, der ebenfalls als Webservice,
allerdings für große Bildschirme konzipiert ist. Hier kann jeder Dozent die Statistiken seiner
Sessions einsehen, die zur Präsentation vor Publikum durch Graphen und Diagramme aufbereitet
sind. Das Feedback wird hier sogar zeitgleich mit der Abgabe durch die Teilnehmer aktualisiert,
während die Antwortstatistiken mit Klick auf „Aktualisieren“ neue Ergebnisse anzeigen.
ARSnova steht als OpenSource Projekt zur Verfügung und kann auf Nachfrage für die Installation
auf anderen Hochschulservern personalisiert werden.
Alles in allem implementiert ARSnova alle nötigen Funktion eines modernen ARS und erweitert
das Angebot zusätzlich um durchdachte Funktionen und Details, die im Alltag einer Vorlesung
nützlich sind, wie beispielsweise der anschauliche Presenter oder das schnell zugängliche, auf
mobile Geräte ausgelegte Design. Es ist außerdem ersichtlich, dass bei diesem Produkt durch
Angebote wie das Feedbacksystem der Fokus auf den Dialog zwischen Dozent und Teilnehmer
einer Vorlesung gelegt wurde, der fast wie der persönliche Austausch in der Realität zwischen
Dozent und Teilnehmer abgebildet wurde. Dennoch ist es genau auf diesen akademischen Alltag
ausgelegt, obwohl die Funktionen von ARSnova sicherlich auch andere Anwendungsbereiche
interessieren könnten.
2.2.2
eduVote
EduVote ist das einzige kommerziell vertriebene ARS unter den in diesem Kapitel vorgestellten
Systemen. Es wurde von der Firma „SimpleSoft“ entwickelt, hinter der sich zwei ehemalige
Studenten der TU Braunschweig verbergen, die teilweise noch immer Lehraufträge an der TU
Braunschweig ausüben. EduVote ist aus diesem Grund anders als die anderen vorgestellten
Systeme. Es wurde zwar mit dem Hintergrund eines Lehrenden an einer Hochschule entwickelt,
ist aber dennoch kein freies System einer Hochschule, sondern wird als kostenpflichtiges Produkt
einer Softwarefirma vertrieben. Eine Einzellizenz für einen Dozenten kostet 299€ [2] im Jahr und
eine Hochschullizenz, die alle Dozenten der Hochschule gleichzeitig nutzen können, kostet 2800€
[2] im Jahr.
Dabei bietet das Produkt eine sehr genaue Abbildung eines klassischen Audience-ResponseSystem mit speziellen Hardware-Buzzern, wie man es aus der Sendung „Wer wird Millionär“ von
dem Publikumsjoker kennt. In eduVote kann der lizenzierte und mit einer E-Mail-Adresse
registrierte Dozent Fragen für seinen Vortrag vorbereiten, die alle vom Typ Single-Choice sind und
sich lediglich in der Anzahl der Antwortmöglichkeiten unterscheiden. Der Dozent gibt im Vortrag
die Frage manuell frei und stoppt sie nach einer gewissen Zeit manuell, woraufhin die Ergebnisse
im Balkendiagramm zusammengefasst werden. Erst danach kann der Dozent die nächste Frage
zur Beantwortung freigeben.
Die Teilnehmer können der Umfrage beiwohnen, indem sie die E-Mail-Adresse des Dozenten
eingeben. Mit Klick auf „Vote“ kann der Teilnehmer die laufende Frage beantworten. Bei
erneutem Klick auf den Abstimmungs-Button wird erkannt, dass der Teilnehmer bereits
abgestimmt hat. Es ist allerdings wie bei den klassischen Hardware-Buzzern für den Teilnehmer
7
2 Grundlagen
nicht ersichtlich, wann eine neue Frage beantwortet werden kann. Auch der Fragetext wird wie
beim klassischen Vorbild nicht angezeigt, sofern der Dozent diese Option nicht ausdrücklich
einstellt. Die Anzeige der Antwortmöglichkeiten ist gar nicht möglich. Diese werden lediglich mit
„A“, „B“, „C“, „D“, „E“, je nach Anzahl der Antwortmöglichkeiten, benannt. Ein Beispiel für diese
Darstellung ist in Abbildung 2.4 zu sehen.
Abbildung 2.4 Beantwortung einer Frage in EduVote - Da es nur den Single-Choice Frage-Typ gibt, sieht die Ansicht zum
Beantworten immer wie oben dargestellt aus und unterscheidet sich lediglich in der Anzahl der Abstimmungs-Buttons.
[2]
Der Dozent hat außerdem die Möglichkeit sogenannte „Sofortfragen“ zu stellen, bei denen er mit
wenigen Klicks während der Vorlesung und ohne Eingabe des Fragetexts eine Frage starten kann.
Der Fragetext und die Antwortmöglichkeiten müssen hier über ein anderes Medium, wie
beispielsweise die Präsentationsfolien des Dozenten, für die Teilnehmer ersichtlich sein.
Für Dozenten stellt eduVote das auf Windows- und Apple-Geräten zu installierende „eduVoteshow“ zur Verfügung, in dem alle oben beschriebenen Funktionen verfügbar sind. Weiterhin gibt
es eduVote für Dozenten als Webseite, im Rahmen derer allerdings keine Fragen vorbereitet und
gespeichert werden können. Für die Teilnehmer bietet eduVote eine breite Auswahl von
Anwendungen für verschiedene Plattformen. Es wurden sowohl Apps für Android, iOS, das
Windows Phone 8, Software für Windows-Rechner und Mac OS als auch eine Browseranwendung
entwickelt.
Zusammengefasst bildet eduVote sehr genau die Handhabung eines klassischen ARS mit speziellen
Hardware-Buzzern und einem „Auswertungsgerät“ auf moderne Technologien ab. Es stellt dabei
Applikationen für jede gängige Plattform bereit, sodass das System sowohl für Teilnehmer als auch
Dozenten schnell und vor allem im gewohnten System zugänglich ist. Abgesehen von der
Verfügbarkeit auf verschiedenen Plattformen, nutzt es allerdings nicht die Vorteile der modernen
Technologien, auf denen es installiert wird. Die Fragetypen etwa sind genauso eingeschränkt, wie
auf Hardware-Buzzern, auf denen es nur eine festgelegte Anzahl an Knöpfen geben kann.
Weiterhin werden aus Gründen des Datenschutzes [2], wie die Entwickler schreiben, die Fragen
ausschließlich auf dem Rechner des Dozenten gespeichert, sodass der Teilnehmer die Frage- und
Antworttexte auf dem eigenen Gerät nicht nachlesen kann und keine Möglichkeit zur späteren
Selbstkontrolle hat. Das ist ein großer Nachteil von eduVote aus studentischer Sicht, denn vor
allem in der Vorbereitung auf die Klausuren möchte ein Teilnehmer einer Vorlesung sicherlich
noch einmal einen Überblick über die gestellten Fragen und die eigenen Antworten erhalten.
Diese Funktion kann auch mit Blick auf den Datenschutz einfach implementiert werden und ist
8
2 Grundlagen
bereits durch die Konzeption von Mainzel als Community, die später noch detaillierter besprochen
wird, grundsätzlich vorgesehen.
2.2.3
PINGO
Hinter dem Namen „PINGO“ verbirgt sich das Projekt „Peer Instruction for very large groups“ der
Universität Paderborn. Hier handelt es sich ebenfalls um ein kostenloses Produkt aus der
Hochschule für die Hochschule, an dem seit 2011 auch durch die zweimalige Unterstützung des
Förderpreises für Innovation und Qualität in der Lehre entwickelt wird. [3]
In PINGO sind Fragen in „Sessions“ zusammengefasst, die der Dozent neu erstellen oder aus
seinem Fragenkatalog, der alle seine Fragen enthält, auswählen kann. Auch „Schnellstart“-Fragen
sind möglich, bei denen kein Fragetext und keine Antwortmöglichkeiten eingegeben werden
müssen. Es stehen die Fragetypen Single-Choice, Multiple-Choice, Freitext und Numerisch zur
Verfügung. Der Dozent kann daraufhin eine Frage manuell zum Beantworten starten, wobei eine
Dauer von einer Minute standardmäßig eingestellt ist, die aber angepasst werden kann. Die Frage
läuft mit dem Ablauf der Dauer aus oder wenn der Dozent sie manuell vorzeitig beendet.
Daraufhin werden die Ergebnisse der Frage als Balkendiagramm in Single- oder Multiple-ChoiceFragen, wie es in Abbildung 2.5 dargestellt ist, oder als Auflistung in Fragen von einem anderen
Frage-Typ dargestellt. PINGO zeigt außerdem das arithmetische Mittel, die Standardabweichung
und den Median der Ergebnisse für numerische Fragen. Danach erst kann der Dozent die nächste
Frage starten. Vergangene Fragen können wiederholt werden, dabei wird diese als eigenständige
Frage in die Historie der Session eingetragen, für die eigene Ergebnisse vorliegen. Die zuletzt
Gestellte kann zudem fortgesetzt werden, sodass die neuen Ergebnisse zu den Vorhanden dazu
gezählt werden.
Abbildung 2.5: Die Autorenansicht einer vergangenen Frage in PINGO - Hier hat der Autor einer Frage alle Ergebnisse im
Überblick und kann die Frage fortsetzen, um auf den vorhandenen Ergebnissen aufzubauen oder sie erneut stellen, um
einen neuen Ergebnissatz zu sammeln. [4]
9
2 Grundlagen
Mit Klick auf die Session-ID sieht der Dozent die Ansicht der Teilnehmer. Zum Teilnehmer an einer
Session wird man über die Eingabe dieser Session-ID, eines Session-Links oder eines QR-Codes.
Sobald eine Frage freigegeben wird, aktualisiert sich automatisch die Ansicht des Teilnehmers,
sodass er die Frage mit allen Antwortmöglichkeiten sofort lesen und beantworten kann. Abbildung
2.6 zeigt diese Ansicht zum Beantworten einer Frage. Bei der Beantwortung der Frage ist der
Teilnehmer sowohl für den Dozenten als auch für das System anonym und kann die Frage zu einem
späteren Zeitpunkt nicht mehr einsehen.
Abbildung 2.6: Beantwortung einer Frage in PINGO - Gezeigt wird eine Single-Choice-Frage, zu der der Benutzer mit Klick
auf „Abstimmen!“ seine Antwort abgibt. [4]
Als einziges Produkt in dieser Runde sind sowohl eine Session als auch der Fragenkatalog teilbar
mit anderen registrierten PINGO-Benutzern, sodass ein Dozent auch seine Mitarbeiter an seiner
Arbeit zu einer Vorlesung beteiligen kann und umgekehrt.
Weiterhin kann PINGO TeX-Formeln in Fragen- und Antworttexten darstellen, sodass es sich
besonders für Fragen aus dem Bereich der Naturwissenschaften eignet. Es besteht ebenfalls eine
Schnittstelle für den Import und Export der Fragen zu Moodle4. Außerdem kann der Fragenkatalog
als CSV-Datei exportiert und neue Fragen aus einer CSV-Datei importiert werden.
PINGO wird ausschließlich als Web-Anwendung angeboten, die durch ihr responsive Design5 auf
verschiedene Bildschirmgrößen reagiert, sodass der Service sowohl in Browsern auf mobilen
Geräten als auch beispielsweise am PC nichts an Handhabung verliert.
4
Moodle ist eine Lernplattform für akademische Einrichtungen, die als Open-Source-Software vertrieben
wird. Durch die offene Konzeption sind eigene Weiterentwicklungen möglich.
5
Eine auf einem responsive Design basierende Webseite antwortet auf die Eigenschaften des Geräts, auf
dem sie geöffnet wird, wie Größe und Orientierung des Bildschirms. Ändern kann sich beispielsweise die
Anordnung oder die Größe, aber auch die Sichtbarkeit der Elemente der Webseite.
10
2 Grundlagen
Somit ist PINGO eine moderne Interpretation eines ARS, das viele Vorteile einer Web-Anwendung
ausreizt. Das Design und der Aufbau sind schnell zugänglich, leicht verständlich und haben den
Vorteil, auf jedem Gerät mit Browser auf die gleiche Weise verfügbar zu sein. Es wurde sehr viel
Wert darauf gelegt, dass die Daten eines PINGO-Accounts auf verschiedenen Wegen exportiert
und mit anderen PINGO-Nutzern geteilt werden können. Allerdings ist es auch in diesem System
nicht auf direktem Weg vorgesehen, dass Studenten noch im Nachhinein von der Befragung
profitieren können. Durch die Schnittstelle zu Moodle ist diese Funktion zwar grundsätzlich
möglich, doch der Dozent muss zunächst bereit sein diesen Export zu leisten und die Studenten
müssen sich zudem in Moodle anmelden.
2.2.4
FreeQuizDome
Ein weiteres Beispiel für ein modern interpretiertes ARS ist die Software „FreeQuizDome“, die an
der Universität Bielefeld entwickelt wurde und noch immer weiter entwickelt wird. An diesem
kostenlosen Produkt haben bereits mehrere studentische Hilfskräfte unter Koordination eines
Diplom-Pädagogen gearbeitet. Das Angebot von FreeQuizDome ist mit dem Hintergrund seines
didaktischen Nährwertes geplant worden und bietet daher einige Funktionen, die von den bisher
Vorgestellten vor allem im Bereich der Fragetypen abweichen. Das ARS ist zwar im akademischen
Rahmen entwickelt worden, auf der Webseite weisen die Entwickler allerdings ausdrücklich auf
den Nutzen für Großgruppen im Allgemeinen, wie Tagungen und Festivals hin [5]. Auch das Design
und die Konzipierung lehnen nicht so stark an den akademischen Nutzen an, wie die bereits
vorgestellten Produkte.
Um FreeQuizDome zu benutzen, meldet sich der Dozent nicht an, sondern lädt eine Software, die
auf einem Rechner installiert wird, herunter. Das Produkt, dessen Oberfläche in Abbildung 2.7
abgebildet wird, ist sofort nach der Installation startklar und mit höchstens drei Klicks erstellt der
Benutzer bereits die erste Frage. Dabei hat er die Auswahl zwischen den Fragetypen „Yes/No“,
„One Word“, „Short Text“, „Rating Scale“, „Single-Choice“, „Multiple-Choice“ und „Image
Answer“. Weiterhin gibt es verschiedene Auswertungsmethoden abhängig vom Frage-Typ zur
Auswahl. So kann zum Beispiel eine „One Word“-Frage nach Häufigkeit der abgegeben Antworten
ausgewertet werden oder die Teilnehmer geben selbst eine Einordnung in ein QuadrantDiagramm6 mit der Antwort ab. Für den Frage-Typ „Image Answer“ kann der Teilnehmer entweder
ein Bild hochladen oder selbst eines auf einem HTML5-Canvas7 malen. Die Ergebnisse einer
„Rating Scale“-Frage können ausführlich über die Angaben Median, Modalwert, arithmetisches
Mittel, Varianz, Standardabweichung und die Möglichkeit zum Clustern der Ergebnisse analysiert
werden. Der Dozent kann immer nur eine Frage nach der anderen stellen.
In diesem Produkt kann der Dozent Fragen einzeln oder zusammen mit anderen Fragen als Quiz
abspeichern. Auch Ergebnisse können gespeichert und exportiert werden, um sie zu einem
späteren Zeitpunkt weiterzuverwenden oder einen Ausdruck zu machen. Dabei können geladene
Ergebnissätze in einer erneuten Umfrage erweitert werden.
6
In einem Quadrant-Diagramm im FreeQuizDome-System kann der Teilnehmer ein Wort oder eine Phrase
zu den vier Standardkategorien Stärke, Schwäche, Chancen und Gefahr abschicken. Die Kategorien können
vom Fragesteller angepasst werden.
7
Das <canvas>-Tag von HTML 5 ist zur Darstellung von Grafiken und vor allem Zeichnungen vorgesehen. Es
kann dazu verwendet werden, um Grafiken mit Hilfe Javascript darzustellen oder um dem Benutzer eine
„digitale Leinwand“, wie es in FreeQuizDome der Fall ist, zur Verfügung zu stellen.
11
2 Grundlagen
Abbildung 2.7: Desktopsoftware von FreeQuizDome - In der Darstellung ist die Auswertung für den Autor einer
vergangenen Single-Choice-Frage zu sehen. [5]
Als Teilnehmer an einer FreeQuizDome Frage muss man sich ebenfalls nicht registrieren. Der
Teilnehmer scannt lediglich den QR-Code der Frage ein oder gelangt durch einen Link direkt auf
die in Abbildung 2.8 gezeigte Webseite zum Abgeben seiner Antwort. Jede Frage hat einen zuvor
vom Dozenten eingestellten Countdown. In diesen Countdown muss der Dozent allerdings die Zeit
einberechnen, die der Teilnehmer braucht, um auf die Antwortseite zu gelangen, da für jede Frage
ein neuer QR-Code und Link generiert wird, sobald die Frage startet.
Abbildung 2.8: Beantwortung einer Frage in FreeQuizDome - Da es sich bei der Frage um eine Single-Choice-Frage
handelt, wird mit Klick auf die jeweilige Antwortmöglichkeit diese direkt als eigene Antwort abgegeben. [5]
12
2 Grundlagen
Die Software für die Dozentenrolle wird sowohl für Windows, Mac OS als auch für Linux
Distributionen angeboten, sodass eines der Betriebssysteme zusammen mit der Runtime „Adobe
Air“ Voraussetzung für die Benutzung ist. Auch eine ständige Internetverbindung wird
ausdrücklich benötigt. Ein Teilnehmer findet über jedes Gerät mit Browser Zugang zum Weblink,
dazu reicht sogar der integrierte Browser, der manchmal bei QR-Code-Scannern mitgeliefert wird,
aus.
Auf Nachfrage „branded“ das Team die FreeQuizDome-Software mit einem individuellen Design
und installiert die Komponenten auf den Servern einer Hochschule, sodass sie die Anwendung als
hauseigenes Tool benutzen kann.
Offensichtlich wurde in dieser Software viel Wert darauf gelegt, dass sie für alle Beteiligten schnell
zugänglich ist und dabei die bestmögliche didaktische Hilfestellung geleistet wird. Weiterhin sind
die bereits erarbeiten Fragen und Ergebnisse erneut abrufbar und erweiterbar, sowie
exportierbar, sodass man einfach zu verschiedenen Zeiten an einer Umfrage arbeiten kann. Leider
gilt dies nur für die Rolle des Dozenten. Ein Teilnehmer einer Umfrage kann auch hier von den
Umfragen im Nachhinein nicht profitieren. Schließlich ist es ein Vorteil von FreeQuizDome, dass
sein Image nicht von vorneherein auf den akademischen Bereich festgelegt wurde, sondern für
alle Anwendungen eines ARS offen gehalten ist.
2.2.5
Konsequenzen für die Entwicklung von Mainzel
Ein breites Wissen über die Angebote der Konkurrenzprodukte bringt keinen Nutzen, wenn man
daraus keine Konsequenzen für das eigene Produkt zieht. Natürlich verfolgt Mainzel ein weniger
auf den akademischen Bereich beschränktes Image, dennoch soll es alle Annehmlichkeiten, die
andere Produkte für Dozenten und Studenten bereithalten, nicht missen, denn die Anwendung in
Vorlesungen wird auch für Mainzel die Hauptaufgabe darstellen. Wie diese Anforderungen im
Detail aussehen, wird im nächsten Kapitel besprochen, im Folgenden soll lediglich ein Überblick
über die Besonderheiten von Mainzel gegeben werden, die es von den oben angegebenen
Produkten hervorhebt.
Mainzel hat den Charakter einer Community, in der die Abgrenzung zwischen Dozenten- und
Teilnehmerrolle verwischen. Das bedeutet, dass in Mainzel jeder angemeldete Benutzer alle
Umfragen auf einen Blick sehen kann, in denen er involviert ist, sei es als Teilnehmer oder als
Autor. Zu den Umfragen, in denen er Autor ist, lädt er andere Mitglieder der Community als
Teilnehmer ein und wird umgekehrt zu anderen Umfragen als Teilnehmer eingeladen. Dadurch ist
jeder Benutzer gleichgestellt und ein Student kann beispielsweise seinerseits eigene Umfragen
zum Lernen mit anderen Studenten nutzen. Weiterhin wird durch die Einladung ermöglicht, dass
Teilnehmer nicht zwangsweise mit dem Autor in Kontakt treten müssen, um zum Beispiel eine
Umfrage-ID auszutauschen. Das ist im universitären Bereich von Vorteil, in dem der Dozent alle
Anmeldungen zu einer Vorlesung zur Verfügung hat und auf diese Weise sehen kann, wer die
Einladung annimmt und wer aktiv an den Umfragen teilnimmt.
Weiterhin bietet Mainzel sowohl anonyme als auch nicht anonyme Umfragen an, sodass der Autor
die Möglichkeit hat, einen Einblick über die Leistung einzelner Teilnehmer zu erhalten. Alle oben
genannten Konkurrenzprodukte erlauben bisher ausschließlich anonyme Fragen. Die Möglichkeit,
dass sich Teilnehmer enthalten, wird ebenfalls einstellbar sein, sodass eine genaue Aussage
darüber getroffen werden kann, wenn Teilnehmer sich bewusst nicht äußern wollen oder einfach
keine Antwort abgeben. Der Autor hat zudem die Möglichkeit einen Start- und einen Endzeitpunkt
13
2 Grundlagen
für Umfragen und Fragen anzugeben, sodass diese automatisch zum Beantworten freigegeben
oder beendet werden.
Ein weiterer wesentlicher Vorteil von Mainzel gegenüber den oben betrachteten Produkten
begründet sich in der Natur einer nativen App, die auf dem Endgerät installiert wird. Mainzel kann
Teilnehmer über neue unbeantwortete Fragen mittels Notifications8 informieren, auch wenn die
App gerade nicht geöffnet ist. Durch die Entwicklung als native App ergeben sich noch weitere
Vorteile. So ist es beispielsweise möglich, Fragetypen, die die Hardware der Endgeräte nutzen, wie
Sensoren oder die Kamera, anzubieten.
Schließlich ist eine Schnittstelle zu Microsoft Powerpoint geplant, die das einfache Einbinden von
Start- und Stoppknöpfen, Umfrageergebnissen oder einem Link zum automatischen Beitreten zu
einer Umfrage, ermöglicht. Die Präsentation der Ergebnisse wird in den oben genannten Systemen
immer durch ein eigenes Tool ermöglicht, sodass der Vortragende von den Präsentationsfolien auf
das System umschalten muss. Durch die Automatisierung der Start- und Endzeiten der Fragen und
ein Plugin für Microsoft Powerpoint soll der Vortragende ganz ohne Umschalten eine Umfrage
durchführen können.
2.3 Konzept
Das Mainzel-System zeichnet sich durch ein einfaches Konzept mit flachen Hierarchien aus. Im
Groben gibt es zwei große Entitäten, nämlich die Umfrage und den Benutzer, die miteinander in
Beziehung stehen und sich aus kleineren Teilen zusammensetzen. Im Folgenden wird dieses
Konzept näher erklärt und damit die Begrifflichkeiten festgelegt, auf die in dieser Arbeit Bezug
genommen wird.
2.3.1
Benutzer und ihre Rollen
Um Benutzer von Mainzel zu werden, muss man sich zunächst mit einer E-Mail-Adresse und einem
Passwort registrieren. Wenn im Folgenden von einem Benutzer die Rede ist, ist damit
ausschließlich ein registrierter Benutzer gemeint. Die E-Mail-Adresse des Benutzers dient als
Identifikationsmerkmal. Benutzerbezogene Daten, wie erstellte Umfragen und
Umfrageergebnisse können somit nur eindeutig zu einer bestimmten E-Mail-Adresse gehören.
Jeder Benutzer kann selbst Umfragen erstellen und erhält dadurch die Autoren- und
Administrator-Rolle dieser Umfragen. Zu diesen Umfragen kann er andere Benutzer zur Teilnahme
einladen oder sie zu Autoren ernennen. Autoren von Umfragen können diese einsehen, editieren
und starten, aber lediglich der Umfrageadministrator kann die Umfrage löschen. Wenn im
Folgenden auf die Autoren einer Umfrage Bezug genommen wird, ist damit immer auch der
Administrator der Umfrage gemeint, da er zusätzlich zu seinen Administrator-Rechten auch alle
Rechte eines Autors an einer Umfrage hat.
Nimmt ein Benutzer die Einladung zur Teilnahme an einer Umfrage an, ist er Teilnehmer dieser
Umfrage und kann, sobald ein Autor die Umfrage startet, Antworten abgeben. Er wird auch die
Ergebnisse zu dieser Umfrage erhalten.
8
Notifications sind kurze Nachrichten an den Benutzer außerhalb der App, die die Notification sendet. Unter
Android werden Notifications zunächst als kleines Symbol in der Notification-Area (siehe dazu auch Kapitel
4.2) im linken oberen Teil des Displays angezeigt. Der Benutzer kann sie sich näher betrachten, wenn er die
Notification-Area vergrößert und auf den Eintrag der Notification klickt. Notifications sollen ausschließlich
in Situationen verschickt werden, in denen ein zeitnahes Handeln durch den Benutzer benötigt wird oder
wenn andere Benutzer auf eine Antwort warten. [7]
14
2 Grundlagen
2.3.2
Aufbau einer Umfrage
Eine Umfrage besteht aus mehreren Fragen und erhält beim Erstellen vom Administrator einen
Namen. Dieser kann im Nachhinein von einem Autor editiert werden. Zusätzlich kann ein Autor
eine Beschreibung angeben und einstellen, ob die Ergebnisse anonym gespeichert werden und
weiterhin, ob die Teilnehmer vor der Beantwortungszeit bereits Einsicht in die Fragen haben.
Eine Umfrage kann drei Zustände einnehmen: „kommend“, „laufend“ oder „vergangen“. Ein Autor
kann durch Angabe eines Start- und Endzeitpunkt oder durch manuelles Starten und Beenden den
Status einer Umfrage bestimmen. In den verschiedenen Status gibt es dabei verschiedene
Funktionen für die Teilnehmer. Für kommende und vergangene Umfragen handelt es sich dabei
vor allem um lesende Funktionen, wie die Einsicht der Fragen und Antwortmöglichkeiten oder der
Ergebnisse. Laufende Umfragen hingegen bieten auch die Möglichkeit, dass Teilnehmer einzelne
Fragen beantworten können. Aus Autorensicht können Umfragen im vollen Umfang lediglich im
kommenden Zustand bearbeitet werden. Umfragen im laufenden Zustand können abhängig der
einzelnen Status der Fragen bearbeitet werden und Umfragen, die bereits beendet wurden, bieten
nur eingeschränkte Bearbeitungsmöglichkeiten.
Wie bereits erwähnt, gehören zu einer Umfrage mehrere Fragen, die ihrerseits den Status
„kommend“, „laufend“ oder „vergangen“ einnehmen können. Kommende und vergangene Fragen
können von Teilnehmern lesend eingesehen werden, während laufende Fragen die Möglichkeit
zum Abgeben einer Antwort bieten. Autoren können lediglich kommende Fragen bearbeiten. So
wird sichergestellt, dass bereits gestellte Fragestellungen nicht verändert werden können und die
Ergebnisse verfälscht werden.
Eine Frage erhält beim Erstellen einen Frage-Typ. Die in Tabelle 2.1 aufgelisteten Frage-Typen
Single-Choice, Multiple-Choice, Freitext, Begriff, Slider, Schätzen, Datum, Foto und Standort sind
im Rahmen dieser Arbeit erarbeitet worden. Für die Frage-Typen Single- und Multiple-Choice stellt
der Autor mehrere Antwortmöglichkeiten bereit. Weiterhin kann der Autor zu allen Fragen, außer
vom Typ Freitext und Foto, eine oder mehrere richtige Antworten angegeben, sodass eine
automatische Auswertung der Leistung der Teilnehmer durch das System ermöglicht wird.
Ein Autor erhält nach dem Beenden einer Frage Einsicht in die Ergebnisse als Diagramm, dessen
Gestalt vom Frage-Typ abhängt. Je nachdem, ob eine Umfrage anonym ausgewertet wird, erhält
ein Autor auch Einsicht in die Antworten der einzelnen Teilnehmer. Falls richtige
Antwortmöglichkeiten angegeben wurden, sind in der Darstellung der Ergebnisse Aussagen über
richtige und falsche Abgaben einsehbar. Ein Teilnehmer kann eine ähnliche Auswertung einsehen,
natürlich ohne eine Auflistung der Antworten der anderen Teilnehmer und er kann zusätzlich
nachverfolgen, welche Antwort er selbst eingereicht hat.
15
2 Grundlagen
Frage-Typ Erklärung
geeignetes Diagramm
zur Ergebnisdarstellung
Lösung
möglich
SingleChoice
Der Teilnehmer hat eine Auswahl an
Antwortmöglichkeiten und kann genau eine
auswählen.
Balken- oder
Kreisdiagramme
Ja
MultipleChoice
Der Teilnehmer hat eine Auswahl an
Antwortmöglichkeiten und kann mehrere
auswählen.
Balken- oder
Kreisdiagramme
Ja
Freitext
Der Teilnehmer schreibt einen Text als
Antwort.
Auflistung der Texte
Nein
Begriff
Der Teilnehmer gibt ein Wort oder eine
Phrase als Antwort ab.
Auflistung der Begriffe
Ja
Slider
Der Teilnehmer wählt in einem Slider einen
Liniendiagramm
Wert zwischen einem minimalen und einem
maximalen Wert. Minimaler, maximaler Wert
und Einheit der Werte müssen vom Autor
angegeben werden.
Ja
Schätzen
Der Teilnehmer schätzt eine Zahl als Antwort. Liniendiagramm
Der Autor stellt ein, wie viele (Nachkomma-)
Stellen möglich sind.
Ja
Datum
Der Teilnehmer gibt ein Datum als Antwort
an.
Zeitleiste
Ja
Foto
Der Teilnehmer schießt ein Foto und lädt es
als Antwort in die App.
Galerie
Nein
Standort
Der Standort des Teilnehmers wird ermittelt
und stellt die Antwort dar.
Karte
Ja
Tabelle 2.1: Auflistung aller Frage-Typen von Mainzel - Einige Frage-Typen bieten die Möglichkeit an, dass der Autor
Antwortmöglichkeiten vorgibt, andere Frage-Typen stellen die Funktion bereit, dass der Autor richtige Lösungen vorgibt.
Für jeden Frage-Typ gibt es eine spezielle passende graphische Darstellung.
16
3 Anforderungen an das System
3 Anforderungen an das System
Um den Aufwand für Planung und Implementierung einschätzen zu können, ist eine genaue
Analyse der Anforderung an das System notwendig. Die Analyse muss umfassend und detailliert
genug sein, sodass es keine Missverständnisse oder Interpretationsmöglichkeiten während der
Entwicklung gibt. Eine gute Analyse ist der Grundstein für ein realistisches Zeitmanagement und in großen Projekten - für eine realistische Kosteneinschätzung. [6]
In diesem Abschnitt werden aus diesem Grund alle Anforderungen an die Mainzel-App und das
gesamte System detailliert beschrieben, wobei zwischen funktionalen und nicht-funktionalen
Anforderungen unterschieden wird. Weiterhin wird das Use Case Diagramm der App anhand
einiger beispielhafter Use Cases erläutert.
3.1 Funktionale Anforderung
Funktionale Anforderungen beschreiben die Funktionalität des Systems. Analysiert wird, was das
System leisten soll und welche Interaktionen mit dem Benutzer zur Verfügung stehen sollen.
Hierbei gibt es die Muss-Kriterien, das heißt Kriterien, die auf jeden Fall umgesetzt werden
müssen. Sie beschreiben vor allem für den Einsatz des Systems essentielle Funktionen. Weiterhin
formuliert man die Kann-Kriterien, die umgesetzt werden, wenn es die Ressourcen des Projekts
zulassen und die nicht die Einsatzfähigkeit des Systems beeinträchtigen, wenn sie nicht umgesetzt
werden können. [6]
3.1.1
Muss-Kriterien
3.1.1.1 Benutzerbereich
F010: Die App muss einem Benutzer ermöglichen sich mit seiner E-Mail-Adresse und seinem
Passwort anzumelden.
F020: Die App muss einem Benutzer ermöglichen sich aus der App wieder abzumelden.
F030: Die App muss einem Benutzer ermöglichen seinen Account aus dem System zu löschen.
F040: Die App muss eine Möglichkeit bereitstellen, durch die ein Benutzer seine Account-Daten
einsehen kann.
F050: Die App muss eine Möglichkeit zur Änderung der Account-Daten durch den Benutzer
bereitstellen.
3.1.1.2 Umfrageverwaltung
F060: Die App muss nach dem Öffnen die wichtigsten Informationen zu den laufenden Umfragen
in einer Ansicht zusammenstellen.
F070: Die App muss auch eine Übersicht mit den wichtigsten Informationen zu den kommenden
und den vergangenen Umfragen bereitstellen.
F080: Die App muss eine Detailansicht mit allen Informationen zu jeder Umfrage anbieten, die
sich dem Status der Umfrage und der Rolle des Benutzers anpasst (Vorschau bei
kommenden Umfragen, Fragen beantworten bei laufenden Umfragen,
Ergebnisdarstellung bei vergangenen Umfragen).
17
3 Anforderungen an das System
F090: Die App muss das Editieren von allen Informationen einer Umfrage durch einen Autor
ermöglichen.
F100: Die App muss das Löschen einer Umfrage durch den Umfrageadministrator ermöglichen.
F110: Die App muss einem Autor die Möglichkeit geben die Vorschau für die Teilnehmer für jede
Frage einzeln abzuschalten.
F120: Die App muss einem Autor die Möglichkeit bieten, eine Frage anonym zu stellen.
F130: Die App muss einem Autor die Möglichkeit bieten, die Enthaltungsoption für eine Frage
einzuschalten.
F140: Die App muss es einem Autor ermöglichen, eine Umfrage wieder zu verwenden.
F150: Die App muss die Funktion anbieten, eine vergangene Frage in einer geschlossenen
Umfrage erneut zu öffnen, sodass weitere Antworten abgegeben werden können.
F160: Die App muss bereits bekannte andere Benutzer beim Hinzufügen von Autoren oder
Teilnehmern zu Umfragen zur Auswahl stellen.
F170: Die App muss den Benutzer darauf aufmerksam machen, wenn er zu neuen Umfragen
eingeladen ist.
3.1.1.3 Umfragen beantworten
F180: Die App muss die Frage-Typen Single-Choice, Multiple-Choice, Freitext, Begriff, Slider,
Schätzen, Datum, Foto und Standort anbieten (siehe auch Tabelle 2.1).
F190: Die App muss für jeden Frage-Typ eine passende Darstellung zur Beantwortung der Frage
anzeigen (siehe auch Tabelle 2.1).
F200: Die App muss Notifications zu einer neuen laufenden Frage und zu neuen
Umfrageeinladungen an den Benutzer schicken, wenn die App geschlossen ist.
3.1.1.4 Ergebnisdarstellung
F210: Die App muss statistische Größen und graphische Darstellungen der Zahlen zu jeder
vergangenen Umfrage anzeigen.
F220: Die App muss für Autoren einen Überblick über die einzelnen Leistungen der Teilnehmer
zu einer Umfrage anzeigen, sofern die Umfrage nicht anonym war.
F230: Die App muss statistische Größen und graphische Darstellungen der Zahlen zu jeder
vergangenen Frage abhängig vom Typ der Frage anzeigen (siehe auch Tabelle 2.1).
F240: Die App muss für Autoren die einzelnen Leistungen der Teilnehmer zu einer Frage
anzeigen, sofern die Frage nicht anonym war.
F250: Die App muss einem Teilnehmer das eigene Ergebnis anzeigen.
F260: Die App muss einem Teilnehmer die richtigen Lösungen einer vergangene Frage anzeigen,
sofern welche von einem Autor angegeben wurden.
3.1.2
Kann-Kriterien
F270: Die App kann eine „Über Uns“-Ansicht bereitstellen.
F280: Die App kann die Ergebnisdarstellung für einen Autor live aktualisieren.
18
3 Anforderungen an das System
F290: Die App kann eine Schnittstelle zum Übertragen der Ergebnisdarstellung in eine Microsoft
Powerpoint-Präsentation bereitstellen.
F300: Die App kann eine Funktion zum Umstellen der Sprache auf Englisch enthalten.
3.2 Nicht-funktionale Anforderungen
Die Nichtfunktionalen Anforderungen an das System beschreiben Rahmenbedingungen und
Einschränkungen, die das System befolgen soll. Diese Anforderungen können Einfluss auf die
gesamte Softwarearchitektur nehmen. Auch hier werden die Anforderungen in Muss- und in KannKriterien aufgeteilt. [6]
3.2.1
Muss-Kriterien
NF010: Die App muss mindestens unter der Android-Version 4.0 Ice Cream Sandwich, Android API
Level 14, benutzbar sein.
NF020: Die App muss auch offline alle Informationen zu einer Umfrage zur Einsicht bereitstellen.
NF030: Die App muss beim Öffnen alle Benutzer-relevanten Daten aus der globalen Datenbank in
eine lokale Datenbank auf dem Endgerät laden, bzw. synchronisieren.
NF040: Die globale Datenbank muss mit dem Zugriff durch mehrere mobile Geräte gleichzeitig
umgehen können.
3.2.2
Kann-Kriterien
NF050: Die App kann in Google-Play zur Verfügung gestellt werden.
3.3 Use Case Diagramm
Ein Use Case Diagramm zeigt anschaulich alle Situationen auf, die beim regulären Benutzen eines
Systems auftreten. In Abbildung 3.1 ist das Use Case Diagramm der Mainzel-App dargestellt. Es
hilft die Funktionalität der App besser zu erfassen. Die Anwendungsfälle werden allerdings nur
sehr einfach dargestellt. Für ein besseres Verständnis der Zusammenhänge werden daher im
weiteren Verlauf dieses Kapitels ausgewählte Anwendungsfälle näher erläutert. [6]
In Abbildung 3.1 ist zu sehen, wie die Benutzer in ihren verschiedenen Rollen auf die Umfragen
und die App im Ganzen auf unterschiedliche Weise einwirken. Dabei hat ein allgemeiner Benutzer
die meisten Belange an das System. Unabhängig von seiner Rolle möchte er beispielsweise den
Überblick über alle Umfragen oder die Details einer bestimmten Umfrage einsehen. Weiterhin
kann es vorkommen, dass er Änderungen an seinem Account vornehmen möchte oder diesen
ganz aus dem System löschen muss. Als Teilnehmer einer Umfrage geht er in der Regel zwei
Aktionen nach: Er beantwortet regelmäßig die Fragen der Umfragen, an denen er teilnimmt oder
nimmt Einladungen zu weiteren Umfragen an. Als Autor von Umfragen hingegen benötigt der
Benutzer die Möglichkeit, die Umfragen zu bearbeiten und sie starten oder stoppen zu können.
Und schließlich hat jeder Benutzer als Umfrage-Administrator die Möglichkeit eigene Umfragen
zu erstellen und diese auch wieder zu löschen.
19
3 Anforderungen an das System
Abbildung 3.1: Use-Case Diagramm - Die Akteure, die auf das Mainzel-System Einfluss nehmen, sind die Benutzer. Es gibt
Benutzer, die die Autoren-Rolle einer Umfrage einnehmen und andere, die als Teilnehmer involviert sind. Jede Umfrage
hat außerdem einen Administrator. Er hat diese erstellt und ist somit selbst ein Autor. Nur der Administrator kann die
Umfrage auch wieder löschen.
3.4 Use Cases
Im Folgenden werden ausgewählte Use Cases aus dem Diagramm näher erläutert. Use Cases oder
Anwendungsfälle beschreiben ein Szenario, in dem ein Benutzer Erwartungen an das System stellt
und mit ihm interagiert. Primär wurde ein Tabellenformat zur Darstellung der Anwendungsfälle
gewählt, um sie in eine schnell erfassbare Form zu bringen und ihre Vergleichbarkeit zu erhöhen.
Auf diese Weise wurde für jeden Use Case eine Art Steckbrief erstellt, der eine detaillierte
Beschreibung bereit hält und über die beteiligten Akteure, die Bedingungen zum Eintreten des
Use Cases, das auslösende Ereignis und die nachfolgenden Bedingungen informiert. Weiterhin
wird eine Komplexitätseinschätzung gemacht, die für diese Arbeit lediglich auf dem geschätzten
Zeitaufwand der Implementierung basiert. In größeren Projekten wirken weitere Faktoren wie die
Kosten auf diese Einschätzung ein. Schließlich wird eine Priorisierung vorgenommen, um
anzugeben, welche Use Cases für einen Prototyp des Systems unabdingbar sind. Außerdem wird
jeder Use Case in einer kurzen textuellen Beschreibung erläutert und dabei die jeweilige Skizze
der grafischen Benutzeroberfläche mit einbezogen. Sie wurden erstellt, um den jeweiligen Use
Case aus Sicht des Benutzers zu veranschaulichen.
Es wurden nicht alle Use Cases behandelt, da auf sie in anderer Form in Kapitel 4 im Rahmen der
Darstellung von Planung und Design des Systems eingegangen wird. Alle nicht angesprochenen
Use Cases können in Anhang A eingesehen werden. [6]
Zunächst ist wohl einer der wichtigsten Anwendungsfälle die Möglichkeit, dass Teilnehmer eine
Frage beantworten können. Wie in Use Case #05 beschrieben, betrifft dieser Anwendungsfall
20
3 Anforderungen an das System
einzig die Teilnehmer, die zuvor in das System eingeloggt sein müssen. Zu jeder laufenden Frage
gibt es, wie in Abbildung 3.2 zu sehen ist, eine Ansicht, die an den Frage-Typ angepasst ist.
Use Case
ID
Beschreibung
Fragen in einer Umfrage beantworten
#05
Der Benutzer beantwortet eine Frage einer Umfrage, indem er seine
Antwort in die vorgesehenen Antwortfelder, die vom Frage-Typ abhängen,
einträgt und sie abschickt.
Beteiligte Akteure Teilnehmer
Vorbedingung
Der Benutzer ist eingeloggt und er ist Teilnehmer der Umfrage. Die zu
beantwortende Frage wurde durch den Startzeitpunkt der Frage oder
manuell durch einen Autor gestartet.
Trigger
Der Benutzer trägt seine Antwort in die Antwortfelder der Frage ein und
schickt seine Antwort durch Betätigen eines Absende-Buttons ab.
Nachbedingung
Die Antwort des Benutzers wird in die Datenbank geschrieben
Komplexität
Hoch: Die GUI‘s9 zum Beantworten der verschiedenen Frage-Typen sind
komplex. Die Eintragungen in die Datenbank sind einfach.
Priorität
Hoch: Das Beantworten von Fragen ist ein essentieller Use-Case.
GUI
Abbildung 3.2
Tabelle 3.1: Use Case #05
Nachdem der Teilnehmer seine Antwort abgeschickt hat, muss sie vom System in die globale
Datenbank eingetragen werden, sodass die Geräte der anderen beteiligten Benutzer diese
Information auslesen können. Das Umsetzen dieses Anwendungsfalles im System ist sehr wichtig,
da es sich um eine essentielle Funktion handelt. Gleichzeitig ist das Umsetzen aber auch
zeitaufwendig, da für jeden Frage-Typ eine eigene Ansicht implementiert werden muss.
9
Graphical User Interface (GUI), engl. für grafische Benutzeroberfläche.
21
3 Anforderungen an das System
Abbildung 3.2: Benutzeroberfläche zum Beantworten einer Frage - Der Benutzer sieht verschiedene Ansichten für die
verschiedenen Frage-Typen. Dargestellt sind die bisher geplanten Frage-Typen.
22
3 Anforderungen an das System
Das Einsehen der Umfragedetails, um sich als Autor oder als Teilnehmer über Inhalt,
Startzeitpunkt, Fragen oder Ähnliches informieren zu können, ist ein weiterer wichtiger
Anwendungsfall. Dieser ist in Use Case #06a beschrieben. Auch hierfür muss der Teilnehmer oder
der Autor einer Umfrage im System eingeloggt sein. Er öffnet die Detailansicht mit Klick auf den
Listeneintrag der jeweiligen Umfrage in der Umfrage-Übersicht.
Use Case
ID
Beschreibung
Umfragedetails einsehen
#06a
Der Benutzer kann zu jeder Zeit die Details, d.h. Name, Beschreibung, Start/Endzeitpunkt, Autoren oder die Details der Fragen, d.h. Frage-Typ,
Fragetext, Start-/Endzeitpunkt, Antwortmöglichkeiten oder richtige
Lösungen, einsehen. Die Details kommender Fragen können von
Teilnehmern nur eingesehen werden, wenn ein Autor die Vorschau
erlaubt. Richtige Lösungen kommender und laufender Fragen können nie
vom Teilnehmer eingesehen werden.
Beteiligte Akteure Benutzer
Vorbedingung
Der Benutzer ist eingeloggt und ein Teilnehmer oder mindestens ein Autor
der Umfrage.
Trigger
Der Benutzer öffnet die Detail-Ansicht einer Umfrage.
Nachbedingung
Komplexität
Hoch: Die GUI zum Anzeigen der Details ist komplex. Es gibt nur lesende
Datenbank-Kommunikation.
Priorität
Hoch: Das Einsehen der Details ist eine wichtige Funktion für alle BenutzerRollen.
GUI
Abbildung 3.3
Tabelle 3.2: Use Case #06a
Das Umsetzen dieses Anwendungsfalles ist zeitaufwendig durch den komplexen Aufbau der
Ansicht, die in Abbildung 3.3 zu sehen ist. In der Ansicht werden der Name, die Beschreibung, der
Start- und der Endzeitpunkt, die Autoren und ein Überblick über die Fragen gezeigt.
Der Überblick über Fragen verändert sich außerdem dynamisch mit dem Zustand der Umfrage und
der Frage. In kommenden Umfragen beispielsweise, wird angegeben zu welcher Frage eine
Vorschau zur Verfügung steht, während in vergangenen Umfragen eine kurze Auswertung, welche
Fragen richtig und falsch beantwortet wurden, gegeben wird. Das ist nur möglich, wenn ein Autor
richtige Antworten zu den Fragen angegeben hat. Für eine laufende Umfrage wird eine
Kombination der beiden vorherigen Ansichten erstellt. Fragen, die gerade zur Beantwortung
bereitstehen, zeigen einen Countdown an, der angibt wie lange die Frage noch beantwortet
werden kann, während kommende und vergangene Fragen wieder Angaben zur Vorschau und zur
Richtigkeit der Antworten machen.
23
3 Anforderungen an das System
Abbildung 3.3: Detailansicht von Umfragen - Dargestellt ist die Ansicht für Teilnehmer, die eine Auswertung der
Richtigkeit der Antworten von vergangenen Fragen beinhaltet. Die Autoren und Administratoren der Umfrage sehen
dieselbe Ansicht, nur vergangene Fragen haben keinen Indikator für richtig oder falsch.
Eine weitere essentielle Funktion der App ist das Einloggen, um den Zugang für registrierte
Benutzer zu gewährleisten. Use Case #09a beschreibt diesen Anwendungsfall. Loggt sich ein
Benutzer in die App ein, wird der Zeitstempel seiner letzten Aktivität in der globalen Datenbank
aktualisiert. Außerdem wird die Synchronisation der lokalen mit der globalen Datenbank
eingeleitet und der Benutzer gelangt auf die Übersicht über all seiner Umfragen.
Use Case
ID
Beschreibung
Beteiligte Akteure
Vorbedingung
Trigger
Nachbedingung
Komplexität
Priorität
GUI
Einloggen
#09a
Der Benutzer loggt sich im System ein und hat Zugriff auf alle Funktionen.
Benutzer
Der Benutzer muss registriert und ausgeloggt sein, um sich einloggen zu
können.
Zum Einloggen gibt der Benutzer seine E-Mail-Adresse und sein Passwort
in der Anmeldeansicht des Systems an und schickt diese Daten mit Klick auf
den „Einloggen“-Button ab.
Beim Einloggen wird der Zeitstempel der letzten Aktivität des Benutzers in
der Datenbank aktualisiert. Weiterhin werden die Daten der lokalen
Datenbank auf dem Gerät des Benutzers auf den neusten Stand der
globalen Datenbank gebracht.
Hoch: Die GUI zum Einloggen ist simpel. Jedoch das Synchronisieren der
Daten auf dem Gerät mit der Datenbank beim Einloggen ist komplex.
Hoch: essentielle Funktion
Abbildung 3.4
Tabelle 3.3: Use Case #09a
24
3 Anforderungen an das System
Die Implementation der Ansicht, wie sie in Abbildung 3.4 dargestellt wird, ist wegen der wenigen
UI-Elemente wenig komplex, jedoch ist die Kommunikation mit der globalen Datenbank, vor allem
für die Synchronisation, aufwendig, weshalb dieser Anwendungsfall als zeitaufwendig
eingeschätzt wird.
Abbildung 3.4: Benutzeroberfläche zum Einloggen in die App.
Schließlich muss jeder Benutzer die Einladungen zu einer Umfrage zunächst annehmen können,
um daran teilzunehmen. Daher ist der in Use Case #13 beschriebene Anwendungsfall ebenfalls
sehr wichtig für das System. Um eine Einladung zu einer Umfrage annehmen zu können, muss der
Benutzer zunächst eingeloggt sein und außerdem zuvor von einem Autor der Umfrage eingeladen
worden sein.
In der in Abbildung 3.5 dargestellten Skizze der App findet der Benutzer eine Auflistung über alle
Einladungen und kann eine bestimmte mit Klick auf den „Daumen hoch“-Button annehmen.
Daraufhin wird in der globalen Datenbank eingetragen, dass der Benutzer von nun an Teilnehmer
der Umfrage ist und die Daten werden in die lokale Datenbank des Benutzers synchronisiert.
25
3 Anforderungen an das System
Use Case
ID
Beschreibung
Einladungen zu Umfragen annehmen
#13
Ein Benutzer wird von anderen Benutzern zu Umfragen eingeladen, um an
diesen Umfragen teilzunehmen.
Beteiligte Akteure Benutzer
Vorbedingung
Der Benutzer ist eingeloggt und wurde von einem anderen Benutzer zu
einer Umfrage eingeladen.
Trigger
Der Benutzer klickt auf „Annehmen“.
Nachbedingung
Der Benutzer ist nun Teilnehmer an der Umfrage, deren Einladung er
gerade angenommen hat.
Komplexität
Niedrig: Sowohl die GUI als auch die Kommunikation mit der Datenbank
sind wenig komplex.
Priorität
Hoch: essentielle Funktion der App.
GUI
Abbildung 3.5
Tabelle 3.4: Use Case #13
Sowohl die Implementierung der benötigten UI-Elemente, als auch der Datenbankkommunikation
ist wenig komplex und wird daher nicht als zeitaufwendig eingeschätzt.
Abbildung 3.5: Benutzeroberfläche zum Einsehen der Einladungen - Mit Klick auf den "Daumen hoch"-Button kann der
Benutzer die Einladung zu den Umfragen annehmen.
26
4 Planung und Design
4 Planung und Design
Dieses Kapitel erläutert den Prozess der Planung und des Designs des Mainzel-Systems aus
verschiedenen Blickwinkeln. Betrachtet werden zunächst die Architektur des Systems,
darauffolgend das Design der Benutzeroberfläche der App und zum Schluss die beiden
Datenbanken.
4.1 Systemarchitektur
Die Planung der Systemarchitektur wird durch zwei Hauptmerkmale beeinflusst. Zum Ersten soll
jede Komponente im System alle benötigten Informationen erreichen und weitergeben können.
Zum Zweiten soll das System gegen Gefahren von außen bestmöglich abgesichert werden. In
diesem Abschnitt wird die Systemarchitektur von Mainzel unter der Berücksichtigung dieser zwei
Punkte anhand von drei Abbildungen besprochen, die das System oder nur Teilsysteme in
unterschiedlichen Detaildichten zeigen. Zunächst wird die globale Systemarchitektur mit allen
Komponenten des Systems in Abbildung 4.1 besprochen. Danach wird eine erste Verfeinerung der
Architektur in Abbildung 4.2 durchgenommen, die den Aufbau des Teilsystems auf einem AndroidGerät zeigt. Schließlich wird mit Hilfe von Abbildung 4.3 die Kommunikation innerhalb der
Mainzel-App veranschaulicht.
4.1.1
Globale Systemarchitektur
Die globale Systemarchitektur von Mainzel lässt sich als Client-Server-Architektur, wie in
Abbildung 4.1 zu sehen ist, darstellen. Dieses Design-Pattern wird häufig zur Erstellung von
Systemarchitekturen, die Datenzugriffe von unterschiedlichen Orten abbilden sollen,
herangezogen. Im Mainzel-System stellt die auf einem Android-Gerät installierte App zusammen
mit der lokalen Datenbank, die auf jedem Android-Gerät durch eine SQLite-Datenbank abgedeckt
wird, einen Client dar. Im Späteren wird noch näher auf die Architektur eines Clients eingegangen.
Abbildung 4.1: Globale Client-Server-Architektur von Mainzel - Mehrere Instanzen der Android-App stellen die Clients
dar, die mit einem Server kommunizieren. Der Server stellt die Schnittstelle zur globalen Datenbank dar.
Die Clients einer Client-Server-Architektur kommunizieren üblicherweise über Internetprotokolle
mit einer Reihe von Servern, die für einen bestimmten Dienst bereitstehen. In Mainzel gibt es nur
einen Dienst, nämlich die Aufbereitung der Datenbankinhalte und folglich gibt es nur einen Server
im Architekturplan. Diese Seite setzt sich aus einem php-Webservice und der globalen Datenbank,
die auf einem MS-SQL Server umgesetzt wurde, zusammen. Auf die globale Datenbank haben
somit alle Clients im System Zugriff, sodass hier alle Informationen, die im System produziert und
27
4 Planung und Design
benötigt werden, zentral gelagert sind. Die SQLite-Datenbänke der Clients enthalten lediglich für
den Benutzer des Clients interessante, schlankere Kopien der Datensätze der globalen Datenbank.
Auf diese Verteilung wird in Abschnitt 4.3 weiter eingegangen. Der Webservice hingegen dient als
Aufbereiter der Daten in der Datenbank und hat die Fähigkeit mit dieser über SQL-Anfragen zu
kommunizieren. Er erhält für die verwendete php-Extension, die in Kapitel 5.2.4 angesprochen
wird, typische „php statement resources“.
Die Werte aus der Datenbank codiert der Webservice im JSON-Format, auf das in Kapitel 5.2.5
eingegangen wird, sodass sie auf einfachem Weg innerhalb des Clients ausgelesen werden
können. Welche Werte benötigt werden oder welche in die globale Datenbank geschrieben
werden sollen, sodass andere Clients sie auch verwenden können, teilt ein Client dem Webservice
über POST-Anfragen mit. Durch diese Standardisierung der Schnittstellen zwischen Client und
Server können die Komponenten im System einfach ausgetauscht werden, sodass es möglich ist,
dass Mainzel auch über Webservices, die andere Technologien benutzen, mit anderen
Datenbankmanagementsystemen kommunizieren kann.
In dieser Client-Server Architektur ist es einfach die Sicherheit bei der Übertragung der Daten zu
gewährleisten, da es nur eine Schwachstelle, nämlich die Schnittstelle zwischen Client und Server,
gibt. Hier besteht zum einen die Gefahr, dass Daten unberechtigt ausgelesen werden können, was
leicht durch Benutzerauthentifizierung bei den POST-Anfragen und einer geeigneten
Verschlüsselungsmethode der Daten behoben werden kann. Die zweite Gefahr verbirgt sich in
veränderten Anfragen, die „bösartige“ SQL-Befehle enthalten, die der Datenbank und dem
Datenbestand schaden oder sie komplett löschen. Diese Anfragen nennt man „SQL-Injection“. Sie
werden in Mainzel durch den zwischen Client und globale Datenbank geschalteten Webservice
abgefangen, der nur vordefinierte POST-Anfragen zulässt und diese in sicheren SQL-Anfragen an
die Datenbank richtet.
4.1.2
Architektur eines Mainzel-Clients
Zu der Systemarchitektur eines Clients im Mainzel-System gehören sowohl Komponenten, die in
der App selbst implementiert sind, als auch die lokalen Speichermöglichkeiten. In Abbildung 4.2
sind alle Komponenten eines Clients in einem Schichtenmodell dargestellt. Üblicherweise werden
die Schichten in einem Schichtenmodel übereinander gezeigt. In dieser Abbildung sind die
Schichten aus Platzgründen und um die Orientierung zur vorherigen Abbildung beizubehalten,
nebeneinander aufgereiht. Die Datenschicht ganz links stellt dabei die unterste Schicht dar, darauf
folgt die Anwendungsschicht in der Mitte und schließlich stellt die Schnittstelle ganz rechts die
oberste Schicht im Schichtenmodell dar. [6]
Die Datenschicht setzt sich aus zwei Speichern zusammen, nämlich der bereits angesprochenen
lokalen Datenbank des Clients und einer Menge an Konfigurationsdaten. Die Konfigurationsdaten
enthalten die Informationen des Benutzers des Clients, sodass sie für alle Komponenten direkt
zugänglich und unabhängig vom Stand der lokalen Datenbank sind. In der Abbildung wurden die
Kommunikationswege zwischen den Konfigurationen und allen anderen Komponenten außer der
Login-Komponente, die die Konfigurationen schreibt und liest, im Sinne der Übersicht
weggelassen. Die lokale Datenbank ist, wie weiter oben erwähnt, ein abgespecktes Abbild der
globalen Datenbank, die alle Daten enthält, die für den Benutzer interessant sind.
Die Anwendungsschicht beinhaltet alle Implementationen der App, die zur Darstellung und
Verarbeitung der Daten vorgesehen sind. Sie erhält alle Daten aus der lokalen Datenbank über die
Klasse „LocalDatabaseHelper“ (Helper). Diese nimmt, ähnlich wie der php-Webservice,
28
4 Planung und Design
vordefinierte Anfragen an, stellt die dazugehörigen SQL-Anfragen an die SQLite-Datenbank und
erhält gegebenenfalls einen Android-spezifischen Cursor zurück. Ein Cursor kann als Zeiger auf die
ausgewählten Daten angesehen werden. Die Werte auf die der Cursor zeigt, wandelt der Helper
in geeignete Datentypen um und gibt die Information in dieser Form an die Anfrageschicht zurück.
Abbildung 4.2: Architektur eines Clients im Schichten-Model - Ein Client teilt sich in drei Schichten auf. Dazu zählen die
Datenschicht, die Anwendungsschicht und die Schnittstelle zum Server. Jede Schicht kommuniziert mit den benachbarten
Schichten und sichert so den Datenfluss im Client selbst und mit dem ganzen System.
Im Detail bekommt beispielsweise die Komponente der App, die für die Verwaltung der
Einladungen zu Umfragen zuständig ist, alle aktuell vorliegenden Daten zu ausstehenden
Einladungen. Falls der Benutzer eine Einladung bestätigt, gibt die Komponente diese Bestätigung
unter anderem an die lokale Datenbank weiter. Einige Komponenten haben nur die Aufgabe
29
4 Planung und Design
Informationen darzustellen, wie die Übersicht über alle Umfragen, in die der Benutzer involviert
ist. Auch diese Komponenten bekommen ihre Werte vom Helper, liefern allerdings keine
Informationen zurück.
Die Anwendungsschicht kann ebenfalls mit der darüber liegenden Schicht, die lediglich aus der
Schnittstelle zum Server besteht, kommunizieren. Die Schnittstelle ist eine ähnliche Klasse wie der
LocalDatabaseHelper und heißt DBAccess. Sie stellt Methoden für alle Anfragen, die der
Webservice annimmt, zur Verfügung, bereitet die POST-Anfragen an diesen vor und dekodiert die
in JSON verpackten Antworten des Webservices. Erhält die Einladungen-Komponente
beispielsweise eine Antwort auf eine offene Einladung, schickt sie die Antwort nicht nur an die
lokale Datenbank, sondern ruft auch die passende Methode der DBAccess-Klasse auf.
Es gibt lediglich eine Verbindung, die nicht den Prinzipien eines Schichtenmodells folgt, die
besagen, dass es keine Kommunikation zwischen Schichten gibt, die nicht benachbart sind. [6] Die
Synchronisation der lokalen mit der globalen Datenbank wird zwar von der Anwendungsschicht
angestoßen, sobald es notwendig ist, sie wird allerdings durch eine direkte Kommunikation
zwischen Helper und DBAccess realisiert, in der der Helper wie eine Komponente der
Anwendungsschicht agiert und eine passende Methode in der DBAccess-Klasse aufruft. In diesem
Fall verwischen in einem Mainzel-Client die klaren Strukturen eines Schichtenmodells.
An den zahlreichen, eindeutigen Kommunikationswegen zwischen den Schichten erkennt man
den Grundgedanken hinter dem Design der Architektur eines Mainzel-Clients. Innerhalb des
Clients ist es die Hauptaufgabe alle benötigten Daten an die richtigen Komponenten zu liefern und
im Sinne eines begrenzten Arbeitsspeichers auf einem mobilen Endgerät keine unnötigen Daten
zu versenden. Durch den Einsatz des LocalDatabaseHelpers ist, ähnlich wie bei dem phpWebservice, die lokale Datenbank gegen SQL-Injection abgesichert, die durch passende
Formulareingaben durch den Benutzer hätten ausgelöst werden können. Das Mitlesen der auf den
Kommunikationswegen übergebenen Daten ist innerhalb des Clients nicht möglich, da alle
Komponenten außer den zwei Speichern zur App selbst gehören. Auch die Kommunikation mit
den Speichern ist nicht einsehbar, da sowohl die SQLite-Datenbank als auch die
Konfigurationsdaten nur von der App, die sie erstellt hat, erreichbar sind.
4.1.3
App-Architektur
Die Komponenten der Anwendungsschicht in Abbildung 2 werden in Abbildung 3 noch einmal aus
einer detaillierteren Perspektive gezeigt. Zu sehen sind die Kommunikationswege der
Anwendungskomponenten untereinander.
Ein unbekannter Benutzer wird zunächst durch die Login-Komponente registriert oder eingeloggt.
Bekannte Benutzer erhalten sofort Zugang zum Überblick über die Umfragen, in die sie involviert
sind. Die Überblick-Komponente wiederum kann durch Übergabe einer Umfrage-ID an die
Umfrage-Detail-Komponente abgeben und diese wiederum durch Übergabe einer Umfrage- und
einer Frage-ID an die Frage-Detail-Komponente. Alle Komponenten außer der Login-Komponente
können mit dem Umfrage-Editor kommunizieren und dabei optional eine Umfrage-ID
weitergeben. Ohne Umfrage-ID bereitet der Umfragen-Editor eine neu zu erstellende Umfrage
vor. Im Falle einer Übergabe, lädt er alle Informationen zum Editieren.
Weiterhin können alle Komponenten den Benutzer zur Komponente zum Verwalten der
Einladungen und des eigenen Accounts weiterleiten.
30
4 Planung und Design
Diese Teilarchitektur lehnt stark an den Erwartungen des Benutzers an, auf schnellem Weg durch
die App zu navigieren und es wurde vor allem Wert auf die richtige und effiziente Verteilung der
Informationen gelegt. Das ganze Design ist darauf ausgelegt, die Benutzerfreundlichkeit hoch zu
halten. Sicherheit spielt innerhalb der Komponenten der App eine nebensächliche Rolle, da die
Kommunikationswege von außen nicht angreifbar sind.
Abbildung 4.3: Vereinfachte Architektur der Mainzel-App - Die flachen Hierarchien der Mainzel-App ermöglichen diese
vereinfachte Darstellung der App-Architektur. Gezeigt werden die Hauptkomponenten und ihre Kommunikationswege.
Einige Komponenten übergeben einander Informationen. In diesen Fällen wurde der zurückzeigende Pfeil zur
Vereinfachung weggelassen. Dennoch ist auch hier die Kommunikation in die entgegengesetzte Richtung, wie auf allen
Kommunikationswegen in dieser Abbildung, möglich. Die Informationen auf den Kommunikationswegen zum UmfrageEditor sind eingeklammert, weil sie nicht zwingend notwendig sind.
4.2 Frontend-Design
Bei der Planung des Frontends müssen nicht nur die in Kapitel 3 besprochenen Anforderungen
umgesetzt werden, sondern auch die Gewohnheiten der Android-App-Benutzer müssen beachtet
werden. Alle Vorgehensweisen und Richtlinien zum Design von Android-Apps sind in der
Entwicklerdokumentation „Android Developers“ [7] zusammengetragen. Im Folgenden wird das
Konzept des Frontends von Mainzel erklärt und dabei gezeigt, wie die Gewohnheiten von AndroidBenutzern adaptiert wurden. Zur Veranschaulichung werden ausgewählte Skizzen der einzelnen
Ansichten gezeigt. Eine vollständige Darstellung aller Ansichtsskizzen wurde dieser Arbeit
zusammen mit den Use-Cases in Anhang A hinzugefügt.
In Mainzel gibt es verschiedene Ansichten, die dem Benutzer die Informationen auf verschiedene
Art und Weise präsentieren und unterschiedliche Funktionen bereitstellen. Sie alle folgen
allerdings einem Grundaufbau, der sich an den Aufbau vieler anderer Apps auf dem Markt anlehnt.
31
4 Planung und Design
Der Aufbau der Mainzel-Ansicht nach diesem Prinzip folgt somit dem gewohnten Design einer
App, sodass Benutzer sich schnell zurechtfinden können.
In Abbildung 4.4 ist die Ansicht gezeigt, die ein Benutzer nach dem Starten der App erhält, sofern
er sich in Mainzel bereits einmal auf dem mobilen Gerät eingeloggt hat. Auf den Inhalt und den
Zweck dieser Ansicht wird später näher eingegangen. Hier soll der Fokus auf die einzelnen
Bereiche der Ansicht gelegt werden. Am oberen Bildschirmrand ist wie bei den meisten Apps die
Android Notification-Area zu sehen, die nicht Teil der entwickelten App ist. Sie hat die Aufgabe
den Benutzer über alles Wichtige im Android-System zu informieren. Hier wird beispielsweise die
Uhrzeit angezeigt oder auf Verbindungsprobleme hingewiesen. Jede App hat hier die Möglichkeit
selbst Nachrichten, genauer die weiter oben erwähnten Notifications, anzuzeigen, die den
Benutzer erreichen, auch wenn die App gerade nicht geöffnet ist. In Mainzel ist es vorgesehen,
dass der Benutzer auf diese Weise informiert wird, dass es eine neue Frage zum Beantworten gibt.
Abbildung 4.4: Umfrage-Übersicht - Nach dem Starten der App wird der bekannte Benutzer direkt auf diese UmfrageÜbersicht geleitet, damit er alle wichtigen Informationen auf den ersten Blick einsehen kann.
Unter der Notification-Area zeigt Mainzel die sogenannte Actionbar der App. Hier wird das Logo
von Mainzel gezeigt und eine Überschrift gibt Hinweis auf den betrachteten Inhalt. Am rechten
Rand der Actionbar findet der Benutzer alle Funktionen und Navigationslinks, die für die jeweilige
Ansicht zur Verfügung stehen. Dabei sind die Wichtigsten direkt anklickbar, während nicht häufig
gebrauchte Punkte hinter dem zusammenfassenden „Action overflow“-Button, der in Abbildung
4.4 in der Actionbar ganz rechts zu sehen ist, verschwinden. Bei Android-Geräten, die einen
physikalischen Actionbutton haben, taucht der simulierte Button aus Abbildung 4.4 nicht auf.
Unter der Actionbar von Mainzel wird als größter Abschnitt auf dem Bildschirm der Inhalt einer
Ansicht angezeigt. Der Aufbau dieser hängt stark von der Aufgabe der Komponente, zu der die
32
4 Planung und Design
Ansicht gehört, ab. Die Aufgaben, die Ansicht und die Stellung der einzelnen Komponenten
innerhalb der Hierarchie der App werden im Folgenden im Detail erklärt.
Abbildung 4.5: Frontend-Komponenten der App - Die Struktur des Frontends lehnt sehr stark an der Systemarchitektur
der App an und wurde durch die Richtlinien der Android Entwicklerdokumentation [7] beeinflusst.
Android Developers [7] schlägt vor die Struktur einer App in „Top Level“- und „Detail/Edit“Ansichten einzuteilen. Falls eine weitere Hierarchiestufe dazwischen benötigt wird, wird diese als
eine Kategorie-Ansicht betrachtet. Mit diesem Hintergrund und unter Einbeziehung der AppKomponenten der Systemarchitektur (siehe Abschnitt 4.1.3) sind die Komponenten, die das
Frontend von Mainzel umsetzen, geplant worden. Abbildung 4.5 zeigt diese Komponenten als App
auf einem stilisierten mobilen Telefon, um zu verdeutlichen, dass es für jede Komponente eine
eigene Ansicht gibt.
Wie bereits weiter oben beschrieben startet die App für einen bekannten Benutzer mit einer TopLevel-Ansicht, das heißt der Übersicht aller laufenden Umfragen, in die er involviert ist, die dort
als Liste angezeigt wird. Mit einem Swipe nach links wird eine ähnliche Übersicht für alle
33
4 Planung und Design
vergangenen Umfragen und mit einem Swipe nach rechts eine Übersicht über alle kommenden
Umfragen gezeigt. Diese Übersicht ist in Abbildung 4.4 skizziert worden.
Durch einen Klick auf eine Umfrage wechselt der Benutzer zur nächst unteren Hierarchie, einer
Kategorie-Ansicht, die die Details einer Umfrage zeigt. Hier wird neben allen Informationen, die
die Umfrage betreffen, auch eine der Umfrage-Übersicht ähnliche Liste der Fragen angezeigt. Mit
einem Klick auf eine Frage gelangt der Benutzer auf die unterste Ebene der Hierarchie, in die
Detailansicht der Frage. Eine solche Ansicht wurde in Abbildung 4.6 skizziert. Abhängig vom Satus
der Frage lässt sie sich beantworten, Diagramme, die die Abgaben auswerten stehen zur
Verfügung oder der Benutzer kann sie nur einsehen.
Abbildung 4.6: Detailansicht einer Frage - Die linke Abbildung zeigt eine laufende Single-Choice Frage, zu der noch eine
Antwort durch den Benutzer abgegeben werden muss. Die rechte Abbildung stellt eine vergangene Schätz-Frage, die
auch ein Diagramm zur Ansicht der allgemeinen Ergebnisse anbietet, dar.
Die Strukturierung des Frontends in Abbildung 4.5 zeigt weiterhin, dass der Benutzer die
hierarchieübergreifenden Ansichten zum Einsehen und Bearbeiten des eigenen Accounts und zum
Beantworten der Einladungen von allen Komponenten, außer der Login-Komponente, erreichen
kann. Zu beiden Ansichten kann durch Auswählen des jeweiligen Navigationspunktes in der
Actionbar von Mainzel navigiert werden.
Auch der Editor zum Erstellen von Umfragen steht von überall in der App zur Verfügung. Innerhalb
der Detailansicht einer Umfrage oder einer Frage, kann der Benutzer zwischen dem Bearbeiten
und dem neuen Anlegen einer Umfrage in der Actionbar wählen, wobei bei der Bearbeitung alle
Daten der ausgewählten Umfrage in den Editor geladen werden. Abbildung 4.7 zeigt eine Skizze
des Editors. Um alle Eintragungen für eine Umfrage tätigen zu können, muss der Benutzer durch
die Ansicht scrollen. Beim Erstellen einer neuen Frage erweitert sich das Formular abhängig vom
34
4 Planung und Design
ausgewählten Frage-Typ, damit alle charakteristischen Attribute eines Fragetyps angegeben
werden können.
Abbildung 4.7: Umfragen-Editor - In dieser Ansicht kann der Benutzer alle Änderungen an einer Umfrage vornehmen
oder eine neue erstellen. Das Formular des Editors ist zu lang für die Ansicht auf einer Bildschirmlänge eines AndroidGeräts, aber durch Scrollen nach unten kann der Benutzer auf alle Teile des Formulars zugreifen.
4.3 Datenbanken-Design
Im Mainzel-System gibt es mehrere Datenbanken. Zum einen hat jeder Client Zugriff auf die
globale Datenbank, die auf einem SQL Server von Microsoft umgesetzt wurde und in der alle
gemeinsam benutzen Daten des Systems abrufbar sind. Zum anderen steht jedem Client seine
eigene lokale SQLite Datenbank auf dem Gerät zur Verfügung. Auf den ersten Blick ist die lokale
Datenbank eine schlankere Kopie der globalen Datenbank, dennoch gibt es gravierende
Unterschiede zwischen den beiden. Eine SQLite Datenbank ist, wie der Name bereits verrät, eine
abgespeckte Datenbank mit deutlich weniger Datentypen als beispielsweise die MSSQL
Datenbank und auch Programmierbarkeit wie Funktionen oder Trigger sucht man in einer SQLiteDatenbank vergeblich.
Diese Einschränkungen auf der lokalen Datenbank und die Aufgabe der Synchronisation beider
Datenbanken haben das Datenbankdesign von Mainzel erheblich beeinflusst. Im Folgenden
werden beide Datenbankentwürfe erläutert und in Zusammenhang mit den Bedürfnissen des
Mainzel-Systems gestellt.
35
4 Planung und Design
4.3.1
Globale MS SQL Datenbank
In Abbildung 4.8 ist das Datenbankschema der globalen Datenbank abgebildet. Hier sind die fünf
Tabellen zum Speichern der Benutzerdaten „User“, der Umfrageinformationen „Survey“,
einzelner Fragen „Question“, der eingereichten Antworten „Result“ und der Rollenzuweisungen
zwischen Umfragen und Benutzer „IsInvolved“ zu sehen. Alle Tabellen stehen eng miteinander in
Beziehung, so gehört jede Frage in der Question-Tabelle zu genau einer Umfrage und jede Antwort
in der Result-Tabelle wurde von genau einem Benutzer zu einer bestimmte Frage abgegeben. Die
IsInvolved-Tabelle dient als Mapping-Tabelle, um die Zugehörigkeit eines Benutzers zu einer
bestimmten Rolle innerhalb einer Umfrage zuzuordnen.
Jede Tabelle speichert die Basisinformationen zu den „Objekten“, die sie enthält. Bei einer
Umfrage handelt es sich dabei beispielsweise um den Namen, die Beschreibung, der Start- und
Endzeitpunkt, ob die Umfrage bereits vor dem Startzeitpunkt für Teilnehmer einsehbar ist und ob
die Umfrage anonym gestellt wird. Allerdings ist diese Datenbank vor allem mit dem Hintergrund
alle verarbeiteten Informationen im Mainzel-System konsistent und schnell verfügbar
abzuspeichern, entworfen worden. Zu diesem Zweck speichert jede Tabelle weitere Attribute.
Beispielsweise findet man in der Survey-Tabelle drei Attribute, die zum Zweck der schnellen
Verfügbarkeit eingerichtet wurden. So speichert das Attribut „NumberParticipants“ die Anzahl
der Teilnehmer und es wird regelmäßig mit Hilfe eines Triggers aktualisiert, wenn neue
Eintragungen zur Umfrage in der IsInvolved-Tabelle gemacht werden. Durch angepasste Trigger
werden auch die beiden Attribute für die Beteiligung an der Umfrage „AverageParticipation“ und
für die Richtigkeit der Antworten „AverageCorrect“, die es auf Ebene einer Frage auch in der
Question-Tabelle gibt, aktuell gehalten. Alle drei genannten Felder werden zur Ansicht der
Ergebnisse einer Umfrage oder einer Frage auf den Clients gebraucht, eine Funktion die jedem
Benutzer in jeder Umfrage zur Verfügung steht, in die er involviert ist. Die Werte der Felder können
allerdings auf dem Client selbst nicht berechnet werden, da die meisten Clients die erforderlichen
Daten auf Grund der Wahrung der Anonymität der Teilnehmer nicht synchronisieren, es sei denn
der Benutzer des Clients ist ein Autor der Umfrage und die Umfrage wurde als nicht anonym
freigegeben. Damit die Synchronisationsanfrage der Clients keine zeitintensiven Berechnungen,
wie die dieser Werte, beinhaltet, wurden die drei Werte als selbstaktualisierende Attribute der
Survey- bzw. der Question-Tabelle implementiert.
Ein weiteres Feld mit besonderem Hintergrund, das in jeder der in Abbildung 4.8 gezeigten
Tabellen vorkommt, ist das Attribut „Version“ vom Typ timestamp. Es erhält seine besondere
Eigenschaft durch seinen Datentyp. Der Stand eines Datenbank-internen Zählers, der bei jeder
Änderung am Datenbestand hochgezählt wird, wird automatisch in das Feld vom Typ timestamp
eingetragen, wenn sich der Datensatz, zu dem das Feld gehört, ändert oder das erste Mal
eingetragen wird. Dadurch wurde eine automatische Versionskontrolle auf der globalen
Datenbank geschaffen, durch die ein jeder Client schnell herausfindet, welche Datensätze mit
seiner lokalen Datenbank synchronisiert werden müssen.
Es ist noch ein weiteres Attribut zu nennen, das Informationen über die Basisinformationen einer
jeden Tabelle hinaus speichert. Zu jedem Datensatz wird in den Tabellen das Attribut „IsDeleted“
gespeichert, das Aufschluss darüber gibt, ob der Datensatz gelöscht wurde. Das Löschen eines
Users beispielsweise, führt auf Ebene der globalen Datenbank dazu, dass seine persönlichen Daten
wie Name und E-Mail-Adresse, nicht aber seine ID, gelöscht werden. Das ist aus dem Grund nicht
möglich, da bereits seine Antworten in die Auswertung von Umfragen eingegangen ist und diese
nicht mehr verfälscht werden sollen. Das Löschen seiner persönlichen Daten führt zur
Anonymisierung seiner Antworten. Liest ein Client während der Synchronisation, die in Abschnitt
36
4 Planung und Design
4.3.3 erläutert wird, dass ein Datensatz gelöscht wurde, kann und wird dieser den kompletten
Datensatz aus seiner lokalen Datenbank löschen, da es sich bei den lokalen Datensätzen lediglich
um Kopien handelt und zum Schonen der Ressourcen des Clients keine unbrauchbaren Datensätze
gespeichert werden.
Abbildung 4.8: Globales Datenbankdiagramm - In der globalen MSSQL-Datenbank von Mainzel gibt es fünf Tabellen, die
Survey-, User-, Question-, Result- und die IsInvolved-Tabelle. Sie stehen durch Fremdschlüssel miteinander in Beziehung.
Die erste Spalte einer jeden Tabelle gibt an welche Attribute als Primärschlüssel (PK) und welche als Fremdschlüssel (FK)
deklariert wurden. Die zweite Spalte zeigt die Benennung des Attributs und die dritte Spalte gibt den Datentyp des
Attributs auf dem SQL-Server an.
4.3.2
Lokale SQLite-Datenbank
Das in Abbildung 4.9 gezeigte Diagramm der lokalen Datenbank eines Clients von Mainzel ähnelt
sehr stark dem Diagramm der globalen Datenbank und weist beispielsweise dieselben Tabellen
37
4 Planung und Design
auf. Hier werden ebenfalls die genannten Basisdaten zu Benutzern, Umfragen, Fragen, Antworten
und der Zuordnung zwischen Benutzern und Umfragen gespeichert.
Abbildung 4.9: Diagramm der lokalen Datenbank - Die lokale Datenbank eines Mainzel-Clients weist dieselben Tabellen
wie die globale Datenbank auf. Sie unterscheidet sich allerdings erheblich in ihren Attributen.
Da die Programmierbarkeit von Funktionen, Prozeduren und Triggern in einer SQLite-Datenbank
fehlt, werden hier fast alle Werte bei der Synchronisation aus der globalen Datenbank kopiert und
danach meist nicht mehr von der App verändert. Ein Versionsattribut wie in der globalen
Datenbank, ist daher für keine Tabelle nötig und alle Daten der lokalen Datenbank können als
Kopien angesehen werden, die nicht vom Client gepflegt werden müssen, sondern immer nach
der Synchronisation mit der globalen Datenbank automatisch auf den aktuellen Stand gebracht
werden.
Es gibt allerdings ein Feld, das in der globalen Datenbank nicht existiert und vom Client selbst
aktualisiert wird. Das NotAnswered-Attribut der Survey-Tabelle zählt individuell für den Benutzer
des Clients für jede Umfrage, in der er Teilnehmer ist, die Anzahl der unbeantworteten Fragen mit,
damit die App ihn auf diese Weise schnell und an verschiedenen Orten in der App darauf
38
4 Planung und Design
hinweisen kann. Der Wert des Attributs erhöht sich, wenn eine neue Frage zur Beantwortung
bereit steht und löst bei geschlossener App beispielsweise eine Notification aus, die den Benutzer
darüber informiert. Sobald eine Frage beantwortet wurde, wird der NotAnswered-Wert um eins
verringern.
4.3.3
Synchronisation
Es wurde bereits angedeutet, dass der Synchronisationsprozess in Mainzel nur in eine Richtung
läuft, um die Daten von der globalen auf die lokale Datenbank zu kopieren. Im Rahmen dieses
Prozesses, der außer beim ersten Starten der App im Hintergrund abläuft, übergibt die App dem
php-Webservice die ID des Users und den Stand des angesprochenen Versionszählers der globalen
Datenbank bei der letzten Synchronisation. Der Webservice stellt daraufhin eine Anfrage an die
globale Datenbank zum Feststellen aller für den Benutzer interessanten Datensätze, die eine
höhere Versionsnummer haben und gibt diese an die App zurück.
Ein solcher Synchronisationsmechanismus ist in die andere Richtung nicht möglich. Die ID’s
beispielsweise von Fragen und Umfragen werden beim Navigieren durch die App, wie es in Kapitel
4.1.3 erklärt wird, verschiedenen Komponenten der App übergeben und dürfen sich aus diesem
Grund während der Laufzeit der App nicht ändern. Bei einer automatischen Synchronisation der
globalen Datenbank mit einer lokalen Datenbank hätte aber beispielsweise eine neu erstellte
Frage kurzeitig bis zum Abschluss der Synchronisation in beide Richtungen keine ID oder
zumindest nicht die, die sie von der globalen Datenbank zugewiesen bekommt.
Einzig eine abgegebene Antwort könnte auf diesem Weg mit der globalen Datenbank
synchronisiert werden, da für einen neuen Datensatz der Result-Tabelle keine neuen ID’s erstellt
werden müssen. Diese Daten sind allerdings wohl die brisantesten im ganzen System und sollen
in Mainzel auf schnellstem Weg an alle beteiligten Clients kommuniziert werden. Das Warten auf
die nächste Synchronisation würde zu lange dauern.
Daher findet das Eintragen von Änderungen an Umfragen, abgegebenen Antworten oder
Ähnlichem in die globale Datenbank auf direktem Weg über den Webservice statt und löst eine
erneute Synchronisation der Clientdatenbank mit der globalen Datenbank aus.
4.3.4
XML-Datentypen
Die meisten Attribute, die die erwähnten Basisinformationen enthalten sind durch die
Kombination von Namen und Datentyp selbsterklärend. Lediglich bei den beiden Attributen
„AnswerXML“ und „ResultXML“ vom Typ xml in der Answer- und der Result-Tabelle kann nicht
direkt vom Datentyp auf die Gestalt des Inhalts geschlossen werden. Hier werden speziell für
Mainzel definierte XML-Daten erwartet, die von der App ausgelesen werden können.
Die Wurzel eines AnswerXML-Wertes gibt dabei Aufschluss über den Frage-Typ der Frage, welcher
der Wert zugeordnet ist. Der Wurzel folgen vom Frage-Typ abhängige Attribute und weitere
Elemente. In Quellcode 4.1 ist ein Beispiel für eine Single-Choice-Frage dargestellt. Wie zu sehen
ist, enthält ein typischer AnswerXML-Wert einer Single-Choice-Frage mehrere option-Elemente,
die jeweils die Nummer der Option als Attribut angeben. Die richtige Option erhält außerdem den
Wert „true“ im Attribut „correct“. Zusätzlich hat jedes Element ein Attribut namens „counter“. Es
gibt die Anzahl der Teilnehmer an, die die jeweilige Antwortmöglichkeit gewählt haben.
39
4 Planung und Design
<singlechoice>
<option nr="0" correct="true" counter="2">Option 0</option>
<option nr="1" counter="6">Option 1</option>
<option nr="2" counter="1">Option 2</option>
<option nr="3" counter="2">Option 3</option>
<abstentions>3</abstentions>
</singlechoice>
Quellcode 4.1: Beispiel für ein AnswerXML-Wert einer Single-Choice-Frage - Die option-Elemente innerhalb des
Wurzelelements geben Aufschluss über zur Verfügung stehenden Antwortmöglichkeiten.
Eine Schätz-Frage wiederum, zu der ein Beispiel in Quellcode 4.2 angegeben wurde, speichert
Elemente zur Anzahl der Vorkommastellen (digits), der Anzahl der Nachkommastellen (fractional),
der Einheit der Antworten (unit) und welcher Wert korrekt ist (correct). Weiterhin gibt es das
Element „results“, das für alle eingereichten Antwortmöglichkeiten die Anzahl der Teilnehmer, die
sie gewählt haben, angibt. Sowohl dieser Teil einer Schätz-Frage als auch das counter-Attribut der
Antwortmöglichkeiten von Single-Choice-Fragen stellen die Werte für die Überblicksdiagramme
der Antworten der einzelnen Fragen zur Verfügung. Auf diese Weise ist gewährleistet, dass alle an
einer Umfrage beteiligten, auch die Teilnehmer-Clients ein solches Diagramm darstellen können,
ohne dass alle Result-Tabelleneinträge herunter geladen werden müssen. Die Einträge werden mit
Hilfe eines Triggers, der auf Veränderungen in der Result-Tabelle reagiert, auf dem SQL-Server
bearbeitet.
<estimation>
<digits>3</digits>
<fractional>2</fractional>
<unit>cm</unit>
<correct>2.00</correct>
<results>
<result counter="5">2.00</result>
<result counter="2">3.14</result>
<result counter="4">1.74</result>
</results>
<abstentions>3</abstentions>
</estimation>
Quellcode 4.2: Beispiel für ein AnswerXML-Wert einer Schätzfrage - Es gibt Elemente mit Angaben zur Gestalt der
Antworten, der richtigen Antwort und den eingereichten Antworten.
Auch das Wurzelelement eines ResultXML-Wertes gibt Aufschluss über den Typ der Frage, zu der
der Result-Tabelleneintrag gehört. Das Beispiel für eine Datum-Frage (Wurzelelement „date“) in
Quellcode 4.3 zeigt, dass das abgegebene Datum als Inhalt des Wurzelelements gespeichert wird,
während die Antwort auf eine Position-Frage (Wurzelelement „position“) wesentlich komplexer
ist. Hier ist jeweils ein Element für den Längen-und den Breitengrad der Antwort eingetragen, die
jeweils Attribute mit Angaben zur Richtung, Minute und Sekunde besitzen.
40
4 Planung und Design
<date>21.08.1990</date>
<position>
<latitude direction="N" minute="49" second="59" />
<longitude direction="E" minute="8" second="14" />
</position>
Quellcode 4.3: Beispiele für ResultXML-Werte einer Datum- und einer Position-Frage - Auch hier unterscheiden sich die
Elemente innerhalb des Wurzelelements stark voneinander.
Die oben gezeigten Quellcodes sind nur Beispiele und es gibt spezielle Answer- und ResultXMLWerte für jeden Frage-Typ. Das Auslesen der Werte wird auf Seiten der Clients mit Hilfe von zwei
speziell dafür implementierten Klassen erledigt, die Methoden für jeden Frage-Typ anbieten.
Dieser zusätzliche Aufwand auf Seiten des Clients vereinfacht die Speicherung und die
Erweiterbarkeit auf Seiten der Datenbank sehr. Durch den Datentyp XML wird in der Datenbank
jeder Wert zugelassen, sodass hier keine Änderungen vorgenommen werden müssen, wenn ein
Datentyp erweitert werden soll oder neue hinzugefügt werden. Außerdem können auf diese
Weise mehrere Frage-typsiche Informationen in einem Datenbankfeld gespeichert werden.
Schließlich standardisiert XML durch den Baum-artigen Aufbau und das Konzept der Elemente und
Attribute stark die Gestalt dieser Informationen, sodass sie leicht auf dem Client ausgelesen
werden können.
41
5 Entwicklung
5 Entwicklung
Zur Entwicklung von Mainzel gehört sowohl die Programmierung der App mit allen ihren
Funktionen als auch eine vorherige gründliche Durchleuchtung aller Anforderungen und wie sie
umgesetzt werden sollen. Für beide Schritte wurden einige Werkzeuge benutzt, die das Planen
und Programmieren erleichtert und beschleunigt haben. Weiterhin wurden verschiedene
Technologien benötigt, die das Umsetzen der Funktionalität im System erst ermöglichen. In
diesem Kapitel werden diese Werkzeuge und Technologien vorgestellt. Im Anschluss wird die
Software selbst besprochen und daran aufgezeigt, wie die eingesetzten Technologien, diese
beeinflusst haben.
5.1 Entwicklungssoftware
In der Planungsphase des Mainzel-Systems wurden zunächst bildbearbeitende und
diagrammerstellende Software benötigt. Für die Entwicklung wurden daraufhin eine klassische
Entwicklungsumgebung und ein Datenbankmanagementsystem (DBMS) eingesetzt, die in den
folgenden Abschnitten vorgestellt werden.
5.1.1
Balsamiq Mockups
Zur Erstellung der Skizzen für die verschiedenen Ansichten innerhalb der App, wie sie
beispielsweise in Kapitel 4.2 zum Einsatz kommen, wurde das Wireframing10-Tool Balsamiq
Mockups in der Desktop-Version 2.2 verwendet. Die minimalistische Oberfläche von Balsamiq
Mockups stellt dem Benutzer eine Auswahl an vorgefertigten geometrischen Objekten, gängigen
UI-Elementen und weiteren Formen zur Verfügung, die er per Drag-and-Drop auf einem
großflächigen virtuellen Skizzenpapier zurecht rücken kann. Jede Form kann dabei auf
verschiedene Art und Weise angepasst und skaliert werden. Für das Aussehen der Formen, vor
allem deren Linien kann zwischen zwei Optionen gewählt werden. Mit der „Wireframe Skin“ sehen
alle Darstellungen sehr realitätsnah und nach Abbildungen bereits implementierter Oberflächen
aus. Die in dieser Arbeit verwendete „Sketch Skin“ stellt alle Formen wie mit dem Bleistift
gezeichnet dar, sodass dem Betrachter klar ist, dass es sich dabei um einen Entwurf handelt. [8]
5.1.2
draw.io
Nicht alle Entwürfe und Abbildungen für die Planung von Mainzel können als handgezeichnete
Skizzen dargestellt werden. Aus diesem Grund wurde neben Balsamiq Mockups das DiagrammZeichenprogramm draw.io zur Erstellung der Diagramme während der Designphase von Mainzel
verwendet. Es ist als Web-Anwendung online über alle Browser unter der gleichnamigen WebAdresse erreichbar. In draw.io kann der Benutzer ähnlich wie bei Balsamiq Mockups per Drag-andDrop Formen aus einer großen Auswahl auf einem digitalen Skizzenpapier platzieren. Dabei stehen
Formensätze für Datenbank-Design, UML-Diagramme und vielen andere Standards zur Verfügung.
Die Diagramme können als XML-Datei im Google-Drive, in der Dropbox, auf dem Gerät oder sogar
im Browser gespeichert werden, damit zu einem späteren Zeitpunkt mit draw.io daran
weitergearbeitet werden kann. Außerdem gibt es die Möglichkeit das Erstellte in gängigen
Bildformaten herunterzuladen. Mit draw.io wurden beispielsweise die Datenbankdiagramme in
Kapitel 4.3 erstellt.
10
Beim Wireframing wird die Benutzeroberfläche von Software, vornehmlich von Webseiten, oft unter
Zuhilfenahme von spezieller Designsoftware skizziert. [8]
42
5 Entwicklung
draw.io basiert auf der JavaScript Bibliothek mxGraph und wird als Beispiel-Anwendung für diese
Bibliothek von den Herstellern beworben. [9]
5.1.3
Gimp
Die Anwendung Gimp bietet anders als Balsamiq Mockups und draw.io keine großen Sätze an
vorgefertigten Formen an. Als Bildbearbeitungsprogramm ist sie vor allem zum Ausbessern von
bereits erstellten Bildmedien geeignet und bringt daher unter vielen anderen Möglichkeiten
Werkzeuge zum Verwischen, Kopieren oder Einfärben von Bildausschnitten mit. Auch neue
Bilddateien können mit Hilfe von Text, Linien und wenigen Formen erstellt werden.
Im Rahmen dieser Arbeit wurde die Version 2.8 verwendet. Mit Hilfe von Gimp sind das Logo und
die Icon-Bildmedien von Mainzel entstanden. Für den Einsatz in der App musste vor Allem das Icon
in verschiedenen Auflösungen zur Verfügung stehen, damit es auf verschiedenen Bildschirmen in
gleichbleibender Bildqualität angezeigt werden kann. Hier hat sich die Bild-skalieren Funktion von
Gimp als sehr nützlich hervorgetan.
5.1.4
Android Developer Tools Bundle
Die wohl wichtigste und am meisten eingesetzte Entwicklungssoftware für Mainzel ist das Android
Developer Tools (ADT) Bundle. Es liefert alle Komponenten, die zur Entwicklung von Android-Apps
benötigt werden, in einer Installation. Es beinhaltet die Version 4.3 „Kepler“ der
Entwicklungsumgebung Eclipse zusammen mit dem bereits integrierten Eclipse-Plugin zur
Android-Entwicklung, das dem Bundle seinen Namen gibt. Weiterhin gehört zu dem Bundle das
Android Software Development Kit (SDK) in verschiedenen Versionen, das beispielsweise die für
die Android-Entwicklung verwendeten Bibliotheken einschließt und das näher in Abschnitt 5.2.2
beschrieben wird.
Die Integrierung der ADT in Eclipse beschleunigt und erleichtert die Entwicklung der Apps sehr, da
ohne die Entwicklungsumgebung mit Hilfe einer Konsole gearbeitet wird. Eclipse wurde
ursprünglich als Entwicklungsumgebung für die Java-Implementierung geplant und basiert selbst
auf Java-Code. Mittlerweile sind unzählige Plugins für die Umgebung auf dem Markt, sodass die
Eclipse-Entwicklungsumgebung für fast alle Entwicklungsaufgaben eingesetzt werden kann.
Das ADT-Plugin im Speziellen integriert einen Java- und einen XML-Editor, da der funktionale Teil
einer App auf Java basiert und sowohl das Layout als auch andere Ressourcen in XML definiert
werden. Weiterhin ermöglich das Plugin aus Eclipse heraus Emulatoren für Android-Geräte zu
starten, auf denen das Entwickelte getestet werden kann. Auch eine Schnittstelle um auf per USB
an den Entwicklungs-Rechner angeschlossene Android-Geräte zuzugreifen und auf diesen zu
testen, wird bereit gestellt. Das logging-System von Android produziert bei jedem dieser Testläufe
Logs, die Aufschluss über die Vorgänge auf dem Gerät und in den laufenden Apps geben. In Eclipse,
das das ADT-Plugin integriert, können diese Logs in der logcat-Konsole angezeigt werden.
Die genannten Werkzeuge des ADT-Bundles sind nur einige des gesamten Angebots und wurden
Aufgrund ihrer Wichtigkeit bei der Entwicklung des Mainzel-Apps zur Beschreibung ausgewählt.
Es ist dabei zu erwähnen, dass das ADT-Plugin und damit das Bundle noch viele weitere nützliche
Werkzeuge liefern, die das Entwickeln von Apps sehr beschleunigen.
5.1.5
SQL Server Management Studio und MS SQL Server
Für den Zugriff auf die globale Datenbank, die auf einem MS SQL Server der Johannes GutenbergUniversität Mainz, läuft, kam das SQL Server Management Studio in der Version 12.0 zum Einsatz,
das im SQL Server 2014 Paket ausgeliefert wird. Das Studio, dessen Oberfläche ähnlich wie die
43
5 Entwicklung
einer Entwicklungsumgebung aufgebaut ist, lässt Verbindungen zu mehreren Datenbanken auf
unterschiedlichen SQL-Servern gleichzeitig zu, die in einem Objekt-Explorer wie ein Datei-System
angezeigt werden. Tabellen, Datensätze, Funktionen, Prozeduren oder Trigger können in einem
SQL-Editor erstellt und bearbeitet werden, der auch alle SELECT-Anfragen auswertet und das
Ergebnis in einer Tabelle darstellt. Auch eine grafische Darstellung der Tabelleneigenschaften ist
möglich, die Änderungen und Erweiterungen an den Tabellen zulässt. Weiterhin können die
Tabellen und Beziehungen zwischen diesen innerhalb der Datenbank in einem
Datenbankdiagramm dargestellt werden, über das man ebenfalls Änderungen an den Tabellen
vornehmen kann.
Das SQL Server Management Studio wurde während der Entwicklung von Mainzel hauptsächlich
zum Implementieren der Tabellen, Funktionen, Prozeduren und Trigger mit Hilfe von SQL-Skripten
genutzt. Aus diesem Grund können im Rahmen dieser Arbeit nur die Basis-Funktionen dieser
mächtigen Software genannt werden.
5.2 Verwendete Technologien und Bibliotheken
Neben der Entwicklungssoftware, die durch Alternativen hätten ersetzt werden können, kamen
einige Technologien und Bibliotheken in der Entwicklung des Systems zum Einsatz, die erst die
breite Funktionalität von Mainzel ermöglichen. Im Folgenden werden diese vorgestellt und dabei
erklärt, welche Aufgaben sie im System umsetzen.
5.2.1
Java
Die Programmiersprache in der Android-Apps vornehmlich geschrieben werden, ist Java, eine der
meist verbreitetsten Programmiersprachen derzeit. Java ist eine objektorientierte Sprache und
wurde mit Fokus auf die Plattformunabhängigkeit entwickelt. Diese wird vor allem durch das
Ausführen des in Java-Bytecode kompilierten Quellcodes auf einer virtuellen Maschine, der Java
Virtual Machine (JVM), erreicht. Die JVM wird von dem Java-Betreiber Oracle für verschiedene
Plattformen auf der Webseite [10] bereitgestellt. Sie kann für spezielle Hardware angepasst und
abgeändert werden, wie es im Falle von Android Geräten geschehen ist. Bis zur Android Version
4.3 wird der Quellcode einer App in Bytecode für die Dalvik Virtual Machine (DVM) kompiliert. Die
DVM ist speziell für den mobilen Einsatz unter Android entwickelt worden. Ab Version 4.4, für die
die App dieser Arbeit entwickelt wurde, wird neben der DVM die neue Android Runtime (ART) als
virtuelle Maschine eingesetzt. Der Benutzer kann in den Entwickleroptionen des Geräts wählen,
welche VM zum Ausführen der Apps verwendet werden soll. [11] [12]
Die Objektorientiertheit der Programmiersprache von Java hat maßgeblich die Planung und
Entwicklung von Mainzel beeinflusst. Einen Überblick über die erstellten Klassen und deren Rolle
in der Umsetzung der Funktionen von Mainzel wird ausführlich in Kapitel 5.3.1 behandelt.
5.2.2
Android SDK und Android Support v4-Bibliothek
Zum Entwickeln von Android-Apps wird das Android Software Development Kit (SDK) benötigt und
bringt alle Komponenten zum Bauen, Debuggen und Ausführen von Apps mit. Im SDK ist
beispielsweise der Compiler, der den für die eben erwähnte DVM benötigten Bytecode als DalvikExecutables (.dex) liefert. Weiterhin beinhaltet das Android SDK alle Kern-Bibliotheken für
Android. Für Mainzel wurde das zur Zeit der Entwicklung aktuelle SDK für die Android Version 4.4.2
verwendet, was einem API Level 19 für die Bibliotheken entspricht. Das Android SDK ist Teil des in
Kapitel 5.1.4 beschriebenen ADT Bundles, kann aber auch einzeln von Android Developer
heruntergeladen werden. [12] [13]
44
5 Entwicklung
Um die Ansichten der Mainzel-App dynamisch mit Hilfe von sogenannten Fragmenten aufbauen
zu können, wird neben den Standardbibliotheken des Android SDKs die Android Support v4Bibliothek benötigt. Da Fragmente bei ihrer Einführung im API Level 11 ursprünglich für die
Entwicklung für Tablets eingeführt wurden, ist der volle Umfang an Klassen für den Umgang mit
Fragmenten auf allen mobilen Geräten, das heißt auch auf Handys, später im Rahmen der SupportBibliothek ausgeliefert worden. Die Support-Bibliothek gehört nicht zum ADT Bundle und muss
extra von Android Developers heruntergeladen und in das Projekt der zu entwickelnden App
eingebunden werden. [13]
5.2.3
AChartEngine
Die von der Softwarefirma „The 4ViewSoft Company“ entwickelte Java-Bibliothek AChartEngine
für Android, stellt alle benötigten Klassen und Funktionen zum Darstellen von Diagrammen in
einer App zur Verfügung. [14] Für Mainzel wurden bisher Kreis- und Liniendiagramme für die
Darstellung der Ergebnisse einer Umfrage verwendet. Möglich sind auch Balken- und
Streudiagramme. Eine Vielzahl von Möglichkeiten die Diagramme selbst und ihre Beschriftung
optisch anzupassen, stehen ebenfalls zur Verfügung.
5.2.4
SQLSRV
Die SQLSVR-Extension für PHP wird benötigt, um eine MS SQL-Datenbank aus PHP heraus
anzusprechen. In Mainzel ist die Extension Teil des Webservers und ermöglicht somit die SQLAnfragen an die globale Datenbank. Die am häufigsten im Mainzel-System benutzte Methode von
SQLSRV ist die „sqlsrv_query“-Methode. Sie nimmt eine Anfragezeichenkette und eine
Parameterliste an. Sofern ein Parameter in der Anfrage genutzt wird, beispielsweise, um die ID
des Benutzers, der die Anfrage stellt, zu übergeben, wird anstelle des Parameters in der
Anfragezeichenkette ein „?“ gesetzt und der Parameter selbst in die Parameterliste eingetragen.
Auf diese Weise werden die Parameter auch als solche deklariert und das bereits angesprochene
SQL-Injection-Verfahren, bei dem beispielsweise über Benutzereingaben bösartige SQL-Befehle in
die Anfragen an die Datenbank injiziert werden, die den Datenbestand verändern oder sogar
löschen können, wird ausgeschlossen.
5.2.5
JSON
Bei der Arbeit in einer Client-Server-Architektur kommt man nicht um die Klärung der Frage, auf
welche Weise man Daten am geeignetsten vom Client zum Server und wieder zurück schickt. Eine
standardisierte Notation wie die JavaScript Objekt Notation (JSON), die beide Seiten beherrschen,
ist dabei die Lösung. JSON wird oft benutzt, um Zeichenketten innerhalb von JavascriptAnwendungen zu verschicken. Es ist eine leicht leserliche Notation, die in mehreren Name/WertPaaren Daten in wenigen gängigen Datentypen aufnehmen kann und als eine Zeichenkette
speichert. Diese Zeichenkette kann daraufhin verschickt werden und auf der Empfängerseite von
einem JSON-Parser, den es derzeit in fast jeder Programmiersprache gibt, automatisiert
ausgelesen werden. Aus diesem Grund kann JSON auch in Systemen, die andere Technologien als
JavaScript benutzen, verwendet werden.
In Mainzel werden die Ergebnisse einer Anfrage an die globale Datenbank vom Webservice als
JSON- Objekte verpackt und an den anfragestellenden Client geschickt. Dieser liest das Objekt mit
Hilfe des org.json-Pakets, das in Java standardmäßig enthalten ist, aus.
5.2.6
Android Holo Colors
Schließlich wurde ein weiteres Tool eingesetzt, das maßgeblich zum äußeren Erscheinungsbild der
Mainzel-App beiträgt. In dem online Generator für Android-UI-Elemente „Android Holo Colors“
45
5 Entwicklung
[15] ist es möglich alle im eigenen App verwendeten UI-Elemente farblich anzupassen und die
benötigten Ressourcen-Dateien herunterzuladen. Diese können dann in das eigene Projekt
eingebunden werden. Auf diese Weise wurde die standardmäßige hellblaue Farbe, die jedes
Android-UI-Element auf seine eigene Weise einsetzt, durch das Rot des Mainzel-Logos ersetzt. Die
Screenshots der App in Kapitel 6 zeigen einige Beispiel dafür.
5.3 Umsetzung der App mit Java, XML und den verwendeten Bibliotheken
Wie bereits erwähnt haben die benutzten Technologien, die zum Teil frei gewählt werden
konnten, wie die AChartEngine-Bibliothek oder der Android Holo Colors-Generator und zum Teil
durch die Problemstellung vorgegeben waren, wie Java, XML und das Android SDK, die
Entwicklung und das Endprodukt stark beeinflusst. Um einen Einblick in die Software selbst zu
geben und aufzuzeigen, wie sich diese Einflüsse äußern, wird im Folgenden das Klassendiagramm
von Mainzel besprochen und ein Überblick über die Rolle von XML-Dateien für die RessourcenVerwaltung von Mainzel gegeben.
5.3.1
Klassen
Zur Veranschaulichung der eigens für Mainzel erstellten und der aus der Android-Bibliothek
verwendeten Klassen wurde das Klassendiagramm in Abbildung 5.1 erstellt. Es zeigt das AndroidPaket in der Mitte, um das sich alle Klassen von Mainzel anordnen. Als Einstieg in das Diagramm
können alle „Activity“-Klassen angesehen werden. Sie repräsentieren jeweils eine Ansicht in der
App. Sicherlich startet man die App als User nicht in irgendeiner Ansicht, sondern entweder mit
der Ansicht zum Einloggen, der „LoginActivity“ oder mit der Übersicht über alle Umfragen, in die
der User involviert ist, der „AllSurveysActivity“. Dennoch kann man zwischen den Ansichten in der
App mit Hilfe des Optionsmenüs navigieren und für das Klassendiagramm bedeutet das, dass alle
Activities der obersten Hierarchieebene. Zur Übersicht wurden aus diesem Grund auch die
Verbindungen, die die Navigation repräsentieren, zwischen den Activities weggelassen.
Wie bereits angedeutet, wird eine Ansicht einer Android-App zunächst als Activity implementiert,
der man ein Layout zuweist. In ihrer „onCreate“-Methode, die aufgerufen wird, sobald das System
die Ansicht anzeigen soll, wird der Hauptteil der Funktionalität implementiert. In der Mainzel-App
wurden sowohl die Activity-Klasse der Basisbibliothek als auch die „FragmentActivity“-Klasse der
Support v4-Bibliothek, die zum Arbeiten mit den Listen von Mainzel benötigt werden, verwendet.
Die ganze Funktionalität, die Einfluss auf das Aufbauen und das dynamische Anpassen der
Ansichten hat, wird in Mainzel unter einem Thread ausgeführt. Das ist deshalb nötig, weil die
Kommunikation mit UI-Elementen nur auf dem Hauptthread, der der App vom Android-System
zugewiesen wird, möglich ist. Aus diesem Grund wird dieser Hauptthread auch „UI-Thread“
genannt. Manche Anweisungen, können mitunter zu lange dauern und den UI-Thread blockieren.
Um dies zu umgehen, muss diese Funktionalität in sogenannte Worker-Threads ausgelagert
werden. [16] Dieses Verfahren wurde zum Einloggen des Benutzers in das System im Rahmen der
„AsyncLogin“-Klasse umgesetzt, um den UI-Thread nicht durch das Warten auf die
Benutzerdetails, die von der globalen Datenbank geschickt werden, zu blockieren.
Weitere Funktionalität, die auch über das Beenden der App hinaus agieren kann, wird unter
Android als Service implementiert. Auch ein Service erhält einen eigenen Thread, dessen
Lebenszyklus gänzlich unabhängig vom UI-Thread der App ist. [16] Dennoch ist ein Service nicht
zum Auslagern aufwändiger Berechnungen geeignet, sondern muss als eigenständiger Teil des
Programms angesehen werden. In Mainzel gibt es den „QuestionStatusService“, der die Start- und
46
5 Entwicklung
Endzeiten der Fragen von Umfragen, in denen der Benutzer als Teilnehmer involviert ist,
überwacht. Sofern eine neue Frage gestartet wurde, schickt der Service eine Notification an den
Benutzer, die darauf hinweist, dass es eine neue unbeantwortete Frage im Mainzel-System gibt.
Außerdem aktualisiert dieser Service das in Kapitel 4.3.2 angesprochene Feld „NotAnswered“ der
Survey-Tabelle, das die Anzahl der unbeantworteten Fragen mitzählt. Dadurch fungiert es wie ein
Trigger für die lokale Datenbank. Diese Anweisungen werden in der „onStartCommand“-Methode
umgesetzt.
Für die Kommunikation mit den beiden Datenbanken wurden, wie bereits in Abschnitt 4.1.2
erklärt, die Klassen „DBAccess“ und „LocalDatabaseHelper“ (Helper) implementiert. Sie verfügen
über einen großen Satz an Methoden, um jegliche Datenbankabfrage, die im Mainzel-System
benötigt wird, zu realisieren. In Abbildung 5.1 sind nur wenige dieser Methoden eingetragen, da
eine komplette Liste den Rahmen des Diagramms überschreiten würde. Das Gleiche gilt für die
zahlreichen Zugriffe auf diese beiden Klassen durch andere Klassen, weshalb die DBAccess-Klasse
gänzlich ohne Verbindungen zum System dargestellt ist, auch wenn sie in der Realität eine sehr
zentrale Rolle innerhalb der App spielt. Die LocalDatabaseHelper-Klasse ist im Singleton-Pattern
erstellt worden. Hierbei gibt es die statische Klassenvariable „sInstance“ vom Typ der Klasse, die
die einzige Instanz der Klasse in der ganzen Anwendung darstellt. Sie kann über den statischen
Getter „getInstance()“ abgerufen werden. Der Getter erstellt eine neue Instanz, falls sInstance
„null“ sein sollte und gibt daraufhin sInstance zurück. Da allein der Getter benutzt werden soll und
keine neue Instanz über den Konstruktor der Klasse geschaffen werden soll, wird im SingletonPattern der Konstruktor häufig als „private“ ausgewiesen, wie es auch bei der Helper-Klasse
geschehen ist [11]. Durch das Singleton-Pattern wird sichergestellt, dass auf die lokale Datenbank
nur über den einen Helper zugegriffen wird. Das Transaktionsmanagement, das durch die
Elternklasse „SQLiteOpenHelper“ von android gegeben ist, die der Helper erweitert, wird auf diese
Weise nicht angetastet. Weiterhin sind über die geerbten Methoden „onCreate“ und „onUpgrade“
auch die Erstellung und die Versionsverwaltung der lokalen Datenbank über den
LocalDatabaseHelper erreichbar. Im Rahmen dieser beiden Methoden greift die Klasse auf die
Tabellen-Klassen „UserTable“, „SurveyTable“, „QuestionTable“, „ResultTable“ und
„IsInvolvedTable“ zu, die sowohl den CREATE-SQL-Befehl als auch die Bezeichnungen für Tabelle
und Spalten verwalten. Zum Auslesen der Bezeichnungen benutzen viele andere Mainzel-Klassen
die Tabellen-Klassen, doch zur Übersicht wurde auf das Eintragen dieser Beziehungen im
Diagramm verzichtet.
Alle anderen Mainzel-Klassen können als Helfer-Klassen zur Verarbeitung und Darstellung der
Datenbank-Daten angesehen werden. Beispielsweise wurden zur Erleichterung des Umgangs mit
den XML-Daten, die in Kapitel 4.3.4 angesprochen werden, die Klassen „AnswerXML“ und
„ResultXML“ erstellt. Sie bieten alle Methoden zum Auslesen und Bearbeiten der Werte innerhalb
der XML-Daten an. Ein weiteres Beispiel sind die von der Android-Klasse „Fragment“ und
„ListFragment“ abgeleiteten Klassen. Sie können als Teil, also als Fragment einer Activity,
angesehen werden und besitzen ähnliche Möglichkeiten. Dennoch können sie nicht ohne eine
Eltern-Activity zum Anzeigen von UI-Elementen verwendet werden. In der Mainzel-App kommen
die Fragmente in den dynamisch auszutauschenden Teilen der Ansichten zum Einsatz.
Beispielsweise müssen in der „QuestionDetails“-Activity, über die ein Benutzer eine Frage
beantworten und deren Ergebnisse einsehen kann, je nach Typ und Status der Frage, Teile der
Oberfläche ausgetauscht werden. Für die Darstellung des passenden Antwortformulars eines
jeden Frage-Typs gibt es daher jeweils ein Fragment, das das Interface „QuestionTypeFragment“
implementiert. In Abbildung 5.1 sind exemplarisch die beiden Fragmente für Multiple-Choice- und
48
5 Entwicklung
Freitext-Fragen dargestellt, es gibt allerdings für jeden implementierten Frage-Typ ein eigenes
Fragment, da diese Konstruktion frei erweiterbar ist. Fragmente wiederum, die die Klasse
ListFragment erweitern, stellen Listen dar. In Mainzel wird beispielsweise der Überblick über alle
Umfragen in der AllSurveysActivity in einem Listfragment umgesetzt. Um ein Listfragment
einbinden zu können, muss die Eltern-Activity die erwähnte Klasse FragmentActivity erweitern. Im
Falle der AllSurveysActivity wird außerdem noch vom Interface „TabListener“ abgeleitet, das es
ermöglicht mehrere Listen in Tabs aufzuteilen und die Interaktion des Benutzers mit den Tabs zu
kontrollieren. Zum Befüllen einer Liste mit Daten aus der Datenbank wird eine Instanz der
„CursorAdapter“-Klasse eingesetzt. Ein Cursor ist ein Zeiger auf eine Auswahl an Datenbankzeilen.
In einem CursorAdapter, wie dem AllSurveysCursorAdapter, ist genau angegeben, wie mit den
Daten, auf die ein auf den CursorAdapter angewendeter Cursor zeigt, umgegangen werden soll,
sodass sie in der List angezeigt werden können. Beispielsweise wird mit der „newView“-Methode
eines CursorAdapters ein eigenes View für eine Zeile der Liste angelegt und zurückgegeben und
dieses mit der „bindView“-Methode in den Kontext der Liste, der der CursorAdapter zugewiesen
ist, eingetragen. Ein View-Objekt unter Android ist ganz allgemein ein UI-Element. Es gibt Views,
die direkt ein UI-Element darstellen, beispielsweise eine Checkbox und es gibt Views, die als
Container für andere Views fungieren. Alle UI-Elemente und Container sind von der Klasse
android.view.View abgeleitet. Daher kann ein View sowohl als Container als auch als einzelnes UIElement in Erscheinung treten. [16]
Als Teile der UI werden auch die von der „Dialog“-Klasse abgeleiteten Klassen angesehen. Ein
Dialog wird in einem separaten Fenster angezeigt und fordert Informationen wie eine Bestätigung
oder im Falle des „DateTimeDialogs“ von Mainzel, ein Datum und eine Uhrzeit, bevor der Benutzer
die eigentliche Ansicht weiterbenutzen kann. Auch die vollständige Erstellung oder die Änderung
einer Frage wird in der „EditSurveyActivity“ durch den Einsatz des „EditQuestionDialog“ gelöst.
Sicherlich sind die Bibliotheken des Android-SDKs und das Angebot der Support v4-Bibliothek um
einiges größer als im Klassendiagramm von Mainzel dargestellt und im Rahmen der Mainzel-App
werden noch auf viele weitere zugegriffen. Im Diagramm sind lediglich die Klassen ausgearbeitet,
die von großen Nutzen für die App sind und von denen die Mainzel-Klassen abgeleitet wurden.
5.3.2
XML-Dateien
Unter Android werden alle Layouts einer App in XML-Strukturen abgelegt. Aufgrund der
Baumstruktur von XML-Daten lässt sich das Layout einer Ansicht schnell und einfach als
Verschachtelung von Container- und UI-Views strukturieren. Aber nicht nur die Layouts werden
auf diese Weise definiert. Es ist angeraten [7] alle verwendeten Zeichenketten, wie Bezeichnungen
und Labels, in ein „strings.xml“ auszulagern und die bereits vorimplementierten Methoden zum
referenzieren auf diese Ressource zu verwenden, um die Strings im Java-Code anzuwenden. Durch
diese Zentralisierung ist es im Nachhinein einfacher eine App in verschiedenen Sprachen
anzubieten, lediglich die strings.xml-Datei muss übersetzt und ausgetauscht werden. Auch
Änderungen an häufig verwendeten Zeichenketten kann hier ohne Suchaufwand zentral
vorgenommen werden.
Diese Methode des Auslagerns der Ressourcen lässt sich im Rahmen der Android-Entwicklung
beliebig auf andere Werte ausweiten. In der Mainzel-App werden beispielsweise die Abstände der
UI-Elemente zum Bildschirmrand in einer solchen Ressourcen-Datei gespeichert, sodass man sie
für alle Ansichten in einem Schritt anpassen kann. Auch die in Abschnitt 5.2.6 erwähnten
Ressourcen, wie beispielsweise die Farbdefinition selbst, der manuell designten UI-Elemente aus
dem Android Holo Colors-Generator werden unter anderem auch in XML-Daten ausgeliefert.
49
6 Das Produkt
6 Das Produkt
Die Güte einer Software kann man im Allgemeinen am besten einschätzen, wenn man sie benutzt.
Um einen Eindruck hier auf Papier festzuhalten werden in diesem Kapitel einige Screenshots der
Mainzel-App besprochen. Sicherlich ist die App nur ein Teil des Mainzel-Systems, dennoch ist es
der Teil, der mit allen anderen Komponenten des Systems in Verbindung steht und der einzige,
mit dem die Benutzer in Kontakt kommen.
Wie bereits erklärt, wird der Anwender bei der erstmaligen Benutzung der App zunächst auf die
Ansicht zum Einloggen geführt. Wie in Abbildung 6.1 gezeigt wird, hat der Benutzer hier die
Möglichkeit sich mit seiner E-Mail-Adresse und seines bei der Registrierung angegebenen
Passworts in das Mainzel-System einzuloggen. Sofern es sich um einen noch nicht registrierten
Benutzer handelt, wird er mit Klick auf „Registrieren“-Button zur einer weiteren Ansicht
weitergeleitet, die es ihm ermöglicht einen neuen Account anzulegen. Falls der Benutzer einen
Tippfehler macht oder die Verbindung zum Server nicht hergestellt werden kann, beispielsweise
durch eine fehlende Internetverbindung des Endgeräts, taucht ein sogenannter „Toast“11 auf dem
Bildschirm auf, der darauf hinweist, dass das Einloggen fehlgeschlagen ist.
Abbildung 6.1: Login-Ansicht - Zum Einloggen in das Mainzel-System muss der Benutzer zunächst seine E-Mail Adresse
und sein Passwort eingeben.
11
Ein Toast unter Android dient ähnlich wie die Notifications (siehe Abschnitt 2.2.5) zum Benachrichtigen
des Benutzers. Es ist allerdings auf den Einsatz während der Laufzeit der App ausgelegt. Ein Toast hat die
Form eines kleinen Blocks, der lediglich einen kurzen Satz enthalten soll. Er taucht für eine bestimmte Zeit
im unteren Drittel des Bildschirms auf und beeinträchtigt nicht die Bedienung der UI-Elemente in der
gezeigten Ansicht.
50
6 Das Produkt
Bei erfolgreichem Einloggen wird die Synchronisation mit der Datenbank gestartet, das beim
ersten Mal das Erscheinen des Fortschritt-Dialogs in Abbildung 6.2 auslöst. Wird die App nach
dieser ersten Synchronisation gestartet, läuft das Update der lokalen Datenbank im Hintergrund
ab, sodass der Benutzer zunächst mit den alten Daten weiterarbeiten kann. Sobald das Update
fertig ist, wird die Ansicht automatisch aktualisiert.
Nach dem Beenden der ersten Synchronisation und nach jedem weiteren Start der App wird die
Übersicht über alle Umfragen, in die der Benutzer involviert ist, gezeigt. Hier sind die Umfragen in
die drei Tabs „Vergangene Umfragen“, „Laufende Umfragen“ und „Kommende Umfragen“
eingeteilt und wie in Kapitel 4.2 geplant wurde, kann der Benutzer mit der Swipe-Geste zwischen
den einzelnen Tabs navigieren. Auch der Aufbau einer Ansicht in Mainzel, wie sie in Abschnitt 4.2
geplant wurde, ist hier umgesetzt worden. Am oberen Teil des Bildschirms ist die Notification-Area
von Android zu sehen, darunter folgt die Action-Bar von Mainzel, mit dem Icon von Mainzel, dem
Titel der App und den wichtigsten Navigationsbutton. In dieser Ansicht handelt es sich dabei um
den Button zum Erstellen einer neuen Umfrage. Alle weiteren Navigationsbuttons sind, wie in
Kapitel 4.2 erklärt, im „Action overflow“-Button zusammengefasst. Das Gerät auf dem die
Screenshots in diesem Abschnitt gemacht wurden, besitzt den angesprochenen Button als
Hardware unter dem Bildschirm. Aus diesem Grund wird kein virtueller Button in der Actionbar
von Mainzel in den Screenshots angezeigt, vielmehr gelangt der Benutzer in das Optionsmenü
über den Hardware-Button. Optionen, die dort zusammengefasst werden, ermöglichen
beispielsweise das Ausloggen aus der App, die Einsicht der unbeantworteten Einladungen zu
Umfragen oder die Account-Details.
Abbildung 6.2 Nach dem Einloggen in die Mainzel-App - Startet ein dem Gerät bekannter Benutzer die App gelangt dieser
sofort auf die Übersichtseite rechts im Bild, die alle Umfragen auflistet, in die der Benutzer involviert ist. Sofern der
Benutzer sich zum ersten Mal in der App einloggt, muss er erst die Synchronisation der App mit der globalen Datenbank
abwarten, wie man links im Bild sehen kann.
51
6 Das Produkt
Die in dieser Ansicht gezeigte Liste ist ein Überblick über die Umfragen. Jeder Eintrag enthält daher
die drei wichtigsten Informationen einer Umfrage, das heißt den Namen, die Rolle des Benutzers
in der Umfrage und den Startzeitpunkt. Laufende Umfragen zeigen zusätzlich die verbleibende
Zeit bis zum automatischen Beenden der Umfrage an. Mit Klick auf einen Eintrag der Liste gelangt
der Benutzer in die Detailansicht der Umfrage, in der er zusätzlich zu den bereits gezeigten
Information, den Endzeitpunkt, die Beschreibung, die Autoren und einen Überblick über die
Fragen einsehen kann, der ähnlich wie der Überblick über die Umfragen aufgebaut ist.
Von dort aus gelangt der Benutzer in die einzelnen Detailansichten der Fragen. In einer laufenden
Frage, wie sie in Abbildung 6.3 gezeigt wird, kann er den kompletten Fragetext lesen und ein
Countdown weist ihn auf die verbleibende Zeit zum Beantworten der Frage hin. Je nach Frage-Typ
stellt oder gibt der Benutzer hier seine Antwort ein und schickt sie mit Klick auf den „abschicken“Button an die globale Datenbank. Als Titel der Ansicht wird hier nicht der App-Name, sondern der
Name der Umfrage gezeigt und mit Klick auf den Pfeil links neben dem Mainzel Icon in der
Actionbar gelangt der Benutzer zurück in die Detailansicht der Umfrage. In Fragen, zu denen ein
Autor angegeben hat, dass Enthaltungen möglich sein sollen, wird weiterhin ein Button zum
Abgeben der Enthaltung angeboten.
Abbildung 6.3: Ansicht zum Beantworten einer Single-Choice-Frage - Der Benutzer sieht die Frage selbst und einen
Countdown. Zum Beantworten kann er einen Punkt aus der Radiobutton-Gruppe auswählen. Mit Klick auf „abschicken“
reicht er seine Antwort an die globale Datenbank.
In der Detailansicht einer Frage verschwinden der „abschicken“-Button und gegebenenfalls der
Button für die Enthaltungen, sobald die Beantwortungszeit der Frage vorbei ist. An ihre Stelle tritt
die Auswertung der Frage. Nun kann jeder Benutzer, der in die Umfrage der Frage involviert ist,
die richtige Antwort zu der Frage einsehen, falls eine angegeben wurde. Teilnehmer sehen
zusätzlich ihre eigene Antwort. Weiterhin wird die Teilnahme als Prozentwert des Quotienten aus
52
6 Das Produkt
der Anzahl der abgegebenen Antworten durch die Anzahl der eingetragenen Teilnehmer
angegeben. Darüber hinaus wird eine Aussage über die Anzahl der richtigen eingereichten
Antworten gemacht, falls eine richtige Antwort angegeben wurde.
Für die meisten Frage-Typen steht zudem ein Diagramm zur Darstellung der Ergebnisse zur
Verfügung. In Abbildung 6.4 werden Beispiele für die bereits umgesetzten Diagramme einer
Single-Choice-Frage, einer Multiple-Choice-Frage und einer Schätz-Frage gezeigt. Für SingleChoice- und die Multiple-Choice-Fragen werden die Ergebnisse in einem Kuchendiagramm
ausgewertet, während die Ergebnisse einer Schätz-Frage, wie dargestellt, in einem
Liniendiagramm, mit den eingereichten Zahlen auf der x-Achse und der Anzahl der Einreichungen
auf der y-Achse, veranschaulicht werden.
Abbildung 6.4: Auswertung drei vergangener Fragen - Dargestellt ist eine Single-Choice-Frage (links), eine MultipleChoice-Frage (Mitte) und eine Schätz-Frage (rechts). Für verschiedene Fragen werden verschiedene
Auswertungsdiagramme erstellt.
Die bisher gezeigten Screenshots zeigen die Funktionen für die häufigsten Anwendungsszenarien,
nämlich eine Umfrage und ihre Fragen einzusehen und zu beantworten. Essentiell für das System
ist aber auch die Möglichkeit, dass ein Benutzer eine Umfrage erstellen und im Nachhinein
editieren kann. In Abbildung 6.5 ist der Editor einer bereits erstellten Umfrage zu sehen. Beim
Erstellen einer neuen Umfrage gelangt der Benutzer in die gleiche Ansicht, allerdings sind alle
Formularfelder frei. Für die Bearbeitung des Namens und der Beschreibung sind Textfelder
vorgesehen. Mit Klick auf den Kalender-Button bei Start- und Endzeitpunkt öffnet sich ein Dialog
in dem der Benutzer in einem „Timepicker“ und einem „Datepicker“ sowohl Uhrzeit und Datum
des jeweiligen Zeitpunktes einstellen können. Weiterhin kann eingestellt werden, ob die Vorschau
der Fragen im Zustand „kommend“ für die Teilnehmer vorgesehen ist und ob die Ergebnisse für
die Autoren anonym angezeigt werden sollen. Bei einem Klick auf den ersten Plus-Button öffnet
53
6 Das Produkt
sich ein Dialog zum Erstellen einer neuen Frage, wobei der Typ durch den Spinner12 neben dem
Plus-Button bereits festgelegt wird. In dem Dialog werden der Fragetext, Start- und Endzeitpunkt,
ob die Frage eine Enthaltungsmöglichkeit bereitstellen soll und die vom Frage-Typ abhängigen
Attribute vom Benutzer eingegeben. Nach dem Speichern der neuen Frage wird sie der Frageliste
unter dem Spinner hinzugefügt und kann über die jeweiligen Buttons bearbeitet oder gelöscht
werden. Eine ähnliche Liste wird für die Autoren und die Teilnehmer der Umfrage geführt, hier
öffnet sich allerdings kein Dialog bei Klick auf die Plus-Buttons, da lediglich die E-Mail Adresse des
Benutzers, der hinzugefügt werden soll, benötigt wird. Sie kann in dem Textfeld neben dem
jeweiligen Plus-Button eingegeben werden.
Diese Ansicht ist die einzige, die nicht nach den Vorgaben aus Kapitel 4.2 umgesetzt wurde. In
Abbildung 4.7 ist der Teil zum Erstellen einer neuen Frage nicht in einem Dialog, sondern in der
Editor-Ansicht selbst umgesetzt. Das Befüllen der betroffenen Formularfelder für die
Bearbeitungsfunktion hat allerdings bei der Implementierung Probleme bereitet und war, im
Nachhinein betrachtet, nicht die erste logische Konsequenz. Das Einfügen einer neuen Ebene mit
Hilfe des Dialogs macht einen klaren Schnitt zwischen Umfrage- und Fragebearbeitung und
verunsichert den Benutzer auf diese Weise nicht durch ähnliche Felder und Buttons, wie
beispielsweise der UI-Elemente für Start- und Endzeitpunkt der Umfrage und der Fragen.
Außerdem ähneln sich auf diese Weise alle „Listen“ einer Umfrage im Aussehen, nämlich die Liste
der Fragen, der Autoren und der Teilnehmer.
Abbildung 6.5: Umfrage-Editor - Der Benutzer muss im Editor zum Erstellen und Anpassen einer Umfrage je nach Anzahl
der Fragen, der Autoren und der Teilnehmer scrollen, um alle Information einsehen und bearbeiten zu können. In der
Abbildung ist der Beginn einer langen Umfrage links und das Ende rechts dargestellt.
12
Spinner werden die Drop-Down UI-Elemente unter Android genannt. In dem einzigen Spinner in der
Mainzel-App wählt der Benutzer den Frage-Typ für eine neu zu erstellende Frage aus.
54
6 Das Produkt
Nicht zuletzt kann man an diesem letzten Screenshot zwei andere Optionsbuttons in der Actionbar
sehen. In den weiter oben gezeigten Ansichten war die wichtigste Option immer das Erstellen
einer neuen Umfrage, während alle anderen Optionen im „Action overflow“-Button
verschwanden. Eine Umfrage, die ohne Einschränkungen bearbeitbar ist, ist auch gleichzeitig im
Status „kommend“ und in einer solchen Umfrage ist es am wichtigsten, dass man die Umfrage mit
allen ihren Fragen auch von dort aus manuell starten kann. Diese Möglichkeit verbirgt sich hinter
dem Play-Button. Weiterhin wird in diesem Zustand häufig eine Umfrage wieder verworfen, daher
ist der Lösch-Button in diesem Zustand ebenfalls leicht zugänglich. Alle anderen Option
verschwinden auch in diese Ansicht im „Action overflow“-Button.
Gezeigt wurden nur einige Ausschnitte des Endprodukts, um einen Eindruck von den am
häufigsten vorkommenden Abläufen bei der Benutzung der App zu vermitteln. Alles in allem
entspricht aber auch der nicht dargestellte Teil des Produkts im Aussehen und in der Funktion dem
in der bisherigen Arbeit Besprochenen. Welche Punkte nicht umgesetzt werden konnten und auf
welche Zukunft das Produkt blicken kann, wird in Kapitel 7 näher erläutert.
55
7 Fazit
7 Fazit
Zum Abschluss dieser Arbeit soll ein Fazit über das Produkt gezogen werden. Die Fragen, ob die
App für den geplanten Einsatz geeignet ist, welche Anforderungen erfüllt wurden und welche
zukünftigen Möglichkeiten für das Mainzel-System bestehen, werden in diesem Kapitel geklärt.
7.1 Einsatzfähigkeit
In Kapitel 2.1 wurde bereits der geplante Einsatz des Mainzel-Systems in akademischen
Vorlesungen nahegelegt. Sicherlich wurde bei der Planung und Umsetzung der App darauf
geachtet, dass sie sich nicht ausschließlich auf diesen Bereich fokussiert, dennoch liegt hier der
Schwerpunkt. Der Aufbau des Editors für Umfragen erlaubt es dem Dozent einfach und schnell
neue Umfragen zu erstellen. Durch das Ernennen weiterer Autoren, ist es ein Einfaches für den
Dozent auch Übungsleiter daran mitarbeiten zu lassen. Die bereits umgesetzten Fragetypen bieten
eine Basis für die meisten Fragen während einer Vorlesung. Die Studierenden können auf
schnellem Weg die Fragen des Dozenten beantworten und bekommen genauso wie der Dozent
eine geeignete Rückmeldung über ihre Teilnahme und ihre Leistung. Aus dieser Sicht ist das
Produkt vollkommen geeignet für den Einsatz in akademischen Vorlesungen.
Um beispielsweise dem Dozenten das Einladen von neuen Teilnehmern für seine Umfragen und
die Präsentation der Ergebnisse vor Publikum zu erleichtern, ist es sicherlich von Vorteil für den
Einsatz der App in den nächsten Schritten der Entwicklung, Vorschläge aus Kapitel 7.3, wie dem
QR-Code-Editor oder dem Powerpoint-Plugin, umzusetzen.
7.2 Umgesetzte Anforderungen
Etwa zwei Drittel der funktionalen und nicht-funktionalen Anforderung an das Mainzel-System aus
Kapitel 3 konnten im vorliegenden Mainzel-System umgesetzt werden. Dadurch ist wie vorher
beschrieben ein funktionaler Prototyp entstanden, der durchaus seinen Einsatzzweck erfüllen
kann. Dennoch konnten aus Zeitgründen ein paar Funktionen, die zum angenehmen Arbeiten mit
Mainzel beitragen würden, noch nicht umgesetzt werden. Beispielsweise kann die Vorschau,
anders als in Anforderung F110 spezifiziert, nicht für alle Fragen einzeln aus- oder eingeschaltet
werden, sondern nur übergreifend für die ganze Umfrage. Umfragen können bisher nicht
weiterverwendet werden (Anforderung F140). Die in F160 vorgeschlagene Erleichterung beim
Eingeben von E-Mail-Adressen, sodass bereits bekannte E-Mail-Adressen bei der automatischen
Vervollständig vorgeschlagen werden, wurde noch nicht eingesetzt. Außerdem werden Benutzer
bei neuen Einladungen bisher nicht benachrichtigt, wie es die Anforderung F170 beschreibt.
Schließlich gibt es bisher keinen Unterschied zwischen anonymen und nicht anonymen Umfragen,
sodass die Ergebnisdarstellung aller Umfragen bisher anonym abläuft (Anforderungen F220
undF240).
Aus den Kann-Kriterien konnte die „Über uns“-Ansicht realisiert werden. Außerdem ist der
Grundstein für weitere Sprachenangebote der App gelegt und kann einfach wie in Abschnitt 5.3.2
erklärt, realisiert werden. Als Prototyp wurde die App bisher nicht in Google-Play, dem App-Shop
für Android, zur Verfügung gestellt, wie es in Anforderung NF050 spezifiziert wurde.
Der nächste Schritt im Entwicklungsprozess von Mainzel setzt die letzten fehlenden funktionalen
Anforderungen um und macht das System zu einer komfortablen Anwendung.
56
7 Fazit
7.3 Ausblick
Über die bereits geplanten und weiter entwickelten Ideen hinaus, kann der Prototyp von Mainzel
der Grundbaustein für viele weitere Einsatzbereiche sein. Naheliegend ist der Ausbau als
Werkzeug zum Motivieren und Aktivieren der Zuhörerschaft einer Vorlesung oder eines Vortrags
im Allgemeinen. Dazu ist das bereits erwähnte Plugin für Microsoft Powerpoint denkbar, auf das
in dieser Arbeit nicht eingegangen werden konnte. Da Powerpoint von vielen Vortragenden
genutzt wird, ist es ein Leichtes für diese ein Plugin, das Mainzel integriert, zu verwenden. Denkbar
wäre beispielsweise ein Button, über den der Dozent aus der Präsentation heraus eine bestimmte
Frage manuell starten kann. In diesem Fall ist der nächste logische Schritt, dass das Plugin auf der
nächsten Folie beispielsweise die Auswertung der Ergebnisse der Frage anzeigen kann. Auf VBABasis und in Kombination mit dem bereits verwendeten SQL-Server von Microsoft wäre ein solches
Plugin mit konventionellen Methoden umsetzbar.
Eine andere leicht umsetzbare Erweiterung für Mainzel als Präsentationswerkzeug wäre die
automatische Erstellung von QR-Codes für Fragen und Umfragen, die ebenfalls in das PowerpointPlugin integriert werden könnten, oder als eigenständiges Angebot umgesetzt werden. Über einen
solchen QR-Code wird ein Teilnehmer eigenständig einer Umfrage beitreten, ohne dass der
Dozent die E-Mail-Adresse des Benutzers in das System eingeben muss, um ihn als Teilnehmer
einzuladen.
Auch das Bereitstellen der App in verschiedenen Sprachen kann für den akademischen Bereich
eine nützliche Erweiterung sein, sodass sie nicht nur in deutschsprachigen Veranstaltungen Einsatz
finden kann. Dieser Schritt ist, wie in Abschnitt 5.3.2 beschrieben wurde, eine einfache
Implementierungsarbeit.
Vor allem für den Einsatz in akademischen Vorlesungen sind außerdem noch unzählige weitere
Frage-Typen denkbar, die ihren Einsatz in den unterschiedlichsten Fachbereichen finden können.
Die Integration eines TeX-Formelsatzes für Fragen- und Antworttexte beispielsweise, wie es im
Konkurrenzprodukt PINGO (Kapitel 2.2.3) umgesetzt wurde, käme sicherlich einigen
Naturwissenschaften sehr gelegen. Auch die Umsetzung eines Frage-Typs über den die Teilnehmer
eigene Skizzen auf dem Touch-Gerät zeichnen können, wie es bei dem in Kapitel 2.2.4
vorgestellten Produkt FreeQuizDome der Fall ist, wäre ein nützlicher Frage-Typ. Diese Idee ist
weiterhin erweiterbar auf das Einbinden von bereits bestehenden Zeichenangeboten wie dem in
Abschnitt 5.1.2 erläuterten draw.io, das auf der Open-Source JavaScript-Bibliothek mxGraph
basiert, die unter dem Namen JGraphX auch als Java-Bibliothek herausgegeben wird. [9]
Immer noch im Einsatzbereich der Studierenden, aber außerhalb der Vorlesungen kann Mainzel
als interaktives Hilfsmittel beim Lernen dienen. Man könnte Mainzel um die Möglichkeit
erweitern, dass ein Benutzer, ähnlich wie im Konkurrenzprodukt ARSnova aus Kapitel 2.2.1,
eigene, digitale Lernkarten anlegen kann. Mainzel könnte den Benutzer über AndroidNotifications unregelmäßig zum Lernstoff abprüfen, indem einzelne oder ganze Sätze an
Lernkarten abgefragt werden wie in einer Mainzel-Umfrage. Die Möglichkeit darüber hinaus diese
Lernkarten zu teilen oder daran zusammen zu arbeiten, vielleicht sogar beim Beantworten in
Konkurrenz zu treten, würde die Lernkreise der Studierenden unterstützen und sie motivieren sich
gegenseitig zu helfen.
Da Mainzel vielseitig einsetzbar konzipiert wurde, sind auch die möglichen Weiterentwicklungen
nicht nur auf den akademischen Anwendungsbereich beschränkt. Vorstellbar ist auch der Einsatz
als Werkzeug zum Planen und Organisieren mit Freunden oder in Teams. Man könnte Mainzel um
die Option erweitern, dass bereits von anderen Teilnehmern eingereichte Antworten angezeigt
57
7 Fazit
werden, wenn ein Teilnehmer auf die Ansicht zum Beantworten einer Frage wechselt. Auf diese
Weise können beispielsweise die Salat-Mitbringsel bei der nächsten Grillparty geplant werden
oder Uhrzeiten und Termine können abgesprochen werden.
Alles in allem ist aus der Idee ein altes ARS am Institut der Informatik an der Johannes GutenbergUniversität zu ersetzen, ein ausgereifter Prototyp einer Android-App entstanden. Nach weiterer
Implementierungsarbeit wird ein Produkt entstehen, das viele Möglichkeiten über das klassische
Audience Response System hinaus bietet und auf dem viele Erweiterungen aufbauen können.
58
Anhang A - Use Cases
Anhang A - Use Cases
Use Case
ID
Beschreibung
Umfrage erstellen
#01
Ein Benutzer kann zu jeder Zeit neue Umfragen erstellen, d.h. einer neuen
Umfrage einen Namen, eine Beschreibung, einen Startzeitpunkt, einen
Endzeitpunkt geben, Fragen zur Umfrage erstellen, weitere Autoren
ernennen und Teilnehmer einladen. Eine Frage zu erstellen bedeutet,
einen Frage-Typ auszuwählen, einen Frage-Text, einen Start- und
Endzeitpunkt und, je nach Frage-Typ, Antwortmöglichkeiten und richtige
Lösungen anzugeben.
Beteiligte Akteure Umfrage-Administrator
Vorbedingung
Der Benutzer ist eingeloggt.
Trigger
Der Benutzer klickt auf „neue Umfrage erstellen“.
Nachbedingung
Die eingetragenen Daten werden in die Datenbank geschrieben.
Komplexität
Hoch: Sowohl die GUI zum Erstellen von Umfragen als auch die
Eintragungen in die Datenbank sind komplex.
Priorität
Hoch: essentielle Funktion
GUI
Abbildung 4.7
Tabelle A.1: Use Case #01
Use Case
ID
Beschreibung
Beteiligte Akteure
Vorbedingung
Trigger
Nachbedingung
Komplexität
Priorität
GUI
Umfrage löschen
#02
Ein Benutzer kann eine Umfrage löschen.
Umfrage-Administrator, (Autor, Teilnehmer)
Der Benutzer ist eingeloggt und ist Umfrage-Administrator der zu
löschenden Umfrage. Keine Frage der Umfrage darf gestartet sein, sodass
es noch keine Ergebnisse zu dieser Umfrage gibt.
(Sofern der Benutzer nur ein Autor oder ein Teilnehmer und nicht der
Umfrage-Administrator ist, löscht er lediglich seine Rolle als Autor oder
Teilnehmer dieser Umfrage.)
Der Benutzer klickt auf die Lösch-Option der Umfrage.
Die Daten, d.h. die komplette Umfrage, alle Autor-Referenzen, alle Fragen,
alle Antwortmöglichkeiten, werden aus der Datenbank gelöscht, sofern der
Benutzer Umfrage-Administrator der Umfrage ist.
(Lediglich die Autor-Referenz/Teilnehmer-Referenz wird aus der
Datenbank gelöscht, sofern der Benutzer nur Autor-Rechte an der Umfrage
hat oder Teilnehmer der Umfrage ist.)
Niedrig: In der GUI ist lediglich ein Button / eine Option zu implementieren
und die Nachricht an die Datenbank enthält nur den Lösch-Befehl.
Niedrig: gehört nicht zu den häufig auftretenden Use-Cases und ist nicht
essentiell für die Abläufe im System
Abbildung A.1
Tabelle A.2: Use Case #02
VIII
Anhang A - Use Cases
Abbildung A.1: Benutzeroberfläche zum Bearbeiten von Umfragen - Der Editor ist dem „Umfrage erstellen“-Editor (siehe
Abbildung 4.7) sehr ähnlich, deshalb wurden hier die Ansichten nach dem Scrollen nicht wiederholt. Alle Details, die beim
Erstellen der Umfrage angegeben wurden können geändert werden. Weiterhin gibt es in der Actionbar der GUI die
Möglichkeit mit dem Play-Button alle Fragen auf einmal zu starten und im Menü findet man die Funktionen zum
Speichern der Änderungen und zum Löschen der Umfrage. Nachdem eine Umfrage gestartet wurde, kann eine Umfrage
nicht mehr gelöscht werden, da bereits Ergebnisse vorliegen können. Der Play-Button ist nun ein Stopp-Button.
Use Case
ID
Beschreibung
Umfrage bearbeiten
#03
Der Autor kann eine Umfrage fast zu jeder Zeit bearbeiten, d.h. den
Namen, die Beschreibung, den Start- und Endzeitpunkt, Autoren und
Teilnehmer ändern. Fragen, d.h. den Frage-Typ, den Fragetext, den Startund Endzeitpunkt, und die dazugehörigen Antwortmöglichkeiten können
nur geändert werden, falls die Frage noch nicht gestartet wurde.
Beteiligte Akteure Autor
Vorbedingung
Der Benutzer ist eingeloggt und hat mindestens Autoren-Rechte an der
Umfrage.
Trigger
Der Benutzer wählt die Bearbeiten-Funktion einer Umfrage aus.
Nachbedingung
Alle Änderungen an den Daten der Umfrage werden in die Datenbank
geschrieben.
Komplexität
Hoch: Die GUI zum Bearbeiten aller Daten einer Umfrage ist komplex. Auch
die Datenbank-Kommunikation beinhaltet komplexe Befehle.
Priorität
Mittel: Die Funktion wird häufig genutzt, ist aber für die Abläufe im System
nicht essentiell.
GUI
Abbildung A.1
Tabelle A.3: Use Case #03
IX
Anhang A - Use Cases
Use Case
ID
Beschreibung
Umfrage starten (/stoppen)
#04
Wenn eine Umfrage vom Status kommend in den Status laufend übergeht,
wird sie gestartet. Genauso wird eine Umfrage gestoppt, wenn sie vom
Status laufend in den Status vergangen übergeht. Im Gegensatz zu
kommenden und vergangenen Umfragen können Fragen in laufenden
Umfragen von Teilnehmern beantwortet werden.
Beteiligte Akteure Autor
Vorbedingung
Der Benutzer ist eingeloggt und hat mindesten Autoren-Rechte an der
Umfrage. (Zum Stoppen einer Umfrage muss sie zuvor gestartet worden
sein.)
Trigger
Der Benutzer startet eine Frage in einer Umfrage oder
er wählt die Starten-Funktion der Umfrage und startet somit alle Fragen.
(Er stoppt die letzte laufende Frage einer Umfrage oder
er wählt die Stoppen-Funktion der Umfrage und stoppt somit alle Fragen.)
Nachbedingung
Der Startzeitpunkt (bzw. der Endzeitpunkt) der Umfrage und der
dazugehörigen Fragen werden in der Datenbank aktualisiert.
Komplexität
Mittel: Für diesen Use-Case müssen in der GUI lediglich Start/Stoppbuttons eingebaut werden. Die Kommunikation mit der Datenbank
beinhaltet wenige Befehle, die allerdings auf jeden Fall während des Klicks
der Start-/Stoppbuttons stabil sein muss.
Priorität
Niedrig: Die Funktion Umfragen manuell durch Betätigen von Buttons zu
starten oder zu stoppen ist nicht essentiell für den Ablauf des System,
sofern Start- und Endzeitpunkt der Umfragen angegeben (Use-Case #01)
und geändert (Use-Case #03) werden können.
GUI
Abbildung A.1
Tabelle A.4: Use Case #04
Use Case
ID
Beschreibung
Umfrageergebnisse einsehen
#06b
Autoren können die Ergebnisse aller Teilnehmer zu vergangenen Fragen
einzusehen, sofern die Umfrage nicht anonym war, ansonsten sehen
sowohl Autoren als auch Teilnehmer Überblicksdiagramme, Durchschnitt,
Verteilung und weitere Größen der vorliegenden Ergebnisse.
Beteiligte Akteure Benutzer
Vorbedingung
Der Benutzer ist eingeloggt, Teilnehmer oder mindestens Autor der
Umfrage (und es liegen Ergebnisse zu der Umfrage vor).
Trigger
Der Benutzer öffnet die Detail-Ansicht einer Umfrage.
Nachbedingung
Komplexität
Hoch: Die GUI zum Anzeigen der Details (bzw. Ergebnisse) ist groß und soll
Echtzeit-Veränderungen anzeigen. Es gibt nur lesende DatenbankKommunikation.
Priorität
Hoch: Das Einsehen der Details ist eine wichtige Funktion für alle BenutzerRollen. Die Echtzeit-Darstellung der Ergebnisse ist nicht essentiell für die
Abläufe im System.
GUI
Abbildung A.2
Tabelle A.5: Use Case #06b
X
Anhang A - Use Cases
Abbildung A.2: Ansicht zum Einsehen der eigenen Ergebnisse in bereits geschlossenen Fragen - Der Teilnehmer sieht die
eigene Antwort, die richtigen Antworten, falls es welche gibt und er sieht außerdem einen Überblick über die Ergebnisse
der anderen Teilnehmer. Dieser Überblick hängt ganz vom Frage-Typ ab. Die Autoren der Umfrage haben einen ähnlichen
XI
Anhang A - Use Cases
Einblick in die Fragen. Sofern die Fragen nicht anonym gestellt wurden, sehen sie allerdings auch die Ergebnisse eines
jeden Teilnehmers.
Use Case
ID
Beschreibung
Account erstellen
#07
Ein nicht im System registrierter Benutzer gibt eine noch nicht im System
vorhandene E-Mail-Adresse und ein Passwort an.
Beteiligte Akteure (nicht registrierte) Benutzer
Vorbedingung
Der Benutzer ist im System noch nicht registriert.
Trigger
Der Benutzer gibt seine E-Mail-Adresse und ein Passwort ein und schickt
diese Daten ab.
Nachbedingung
Ein neuer Benutzer-Account wird in der Datenbank angelegt.
Komplexität
Mittel: Sowohl die GUI als auch die Datenbank-Kommunikation sind wenig
komplex.
Priorität
Hoch: Die Funktion, dass neue Benutzer in das System eintreten können ist
essentiell für den Erfolg des Systems.
GUI
Abbildung A.3
Tabelle A.6: Use Case #07
Abbildung A.3: GUI zum Einloggen in die App und zum Erstellen eines neuen Accounts.
XII
Anhang A - Use Cases
Use Case
ID
Beschreibung
Account löschen
#08
Ein Benutzer kann zu jeder Zeit seinen Account löschen. Dabei gehen seine
persönlichen Daten (E-Mail-Adresse, Passwort) im System verloren. Die
Ergebnisse, die zu diesem Benutzer gehören, werden anonymisiert.
Beteiligte Akteure Benutzer
Vorbedingung
Der Benutzer ist eingeloggt.
Trigger
Der Benutzer wählt die Löschen-Funktion seines Accounts.
Nachbedingung
Die zu dem Benutzer gehörende E-Mail-Adresse und das Passwort werden
aus der Datenbank gelöscht. Lediglich die ID-Nummer des Benutzers bleibt
bestehen, sodass alle Ergebnisse des Benutzers zumindest anonymisiert
konsistent bleiben.
Komplexität
Niedrig: Sowohl die GUI als auch die Datenbank-Kommunikation sind
wenig komplex.
Priorität
Hoch: Die Möglichkeit, dass Benutzer das System wieder verlassen können
ist essentiell.
GUI
Abbildung A.4
Tabelle A.7: Use Case #08
Abbildung A.4: GUI für die Einsicht der eigenen Account-Daten eines Benutzers - Hier kann der Benutzer sowohl E-MailAdresse als auch Passwort ändern und den eigenen Account löschen. Außerdem findet der Benutzer im Optionsmenü,
das hier geöffnet dargestellt ist, die Funktion zum Ausloggen aus dem eigenen Account.
XIII
Anhang A - Use Cases
Use Case
ID
Beschreibung
Ausloggen
#09b
Der Benutzer loggt sich aus dem System aus, um alle Aktivitäten im System
zu beenden und den Zugriff durch Dritte zu unterbinden.
Beteiligte Akteure Benutzer
Vorbedingung
Der Benutzer muss eingeloggt sein.
Trigger
Der Benutzer wählt die „Ausloggen“-Funktion im System.
Nachbedingung
Die App wechselt auf die Einloggen-Ansicht und zeigt diese auch beim
nächsten Starten der App.
Komplexität
Niedrig: Die GUI zum Ausloggen ist simpel.
Priorität
Hoch: essentielle Funktion
GUI
Abbildung A.1 + Abbildung A.4 (jeweils Eintragungen im Options-Menü)
Tabelle A.8: Use Case #09b
Use Case
ID
Beschreibung
Beteiligte Akteure
Vorbedingung
Trigger
Nachbedingung
Komplexität
Priorität
GUI
E-Mail-Adresse ändern
#10
Der Benutzer kann zu jeder Zeit seine E-Mail-Adresse ändern.
Benutzer
Der Benutzer ist eingeloggt und die neue E-Mail-Adresse ist im System
noch nicht vorhanden.
Der Benutzer gibt die neue E-Mail-Adresse an und schickt sie mit Betätigen
des „Speichern“-Buttons ab.
Die E-Mail-Adresse wird in der Datenbank aktualisiert.
Niedrig: Sowohl die GUI als auch die Kommunikation mit der Datenbank
sind wenig komplex.
Mittel: Das Ändern der E-Mail-Adresse ist nicht essentiell für die Abläufe
im System.
Abbildung A.4
Tabelle A.9: Use Case #10
Use Case
ID
Beschreibung
Beteiligte Akteure
Vorbedingung
Trigger
Nachbedingung
Komplexität
Priorität
GUI
Passwort ändern
#11
Der Benutzer kann zu jeder Zeit sein Passwort ändern.
Benutzer
Der Benutzer ist eingeloggt.
Der Benutzer gibt ein neues Passwort an und schickt es mit Betätigen des
„Speichern“-Buttons ab.
Das Passwort wird verschlüsselt in der Datenbank aktualisiert.
Niedrig: Sowohl die GUI als auch die Kommunikation mit der Datenbank
sind wenig komplex.
Mittel: Das Ändern des Passworts ist nicht essentiell für die Abläufe im
System.
Abbildung A.4
Tabelle A.10: Use Case #11
XIV
Anhang A - Use Cases
Use Case
ID
Beschreibung
Umfrage-Überblick einsehen
#12
Direkt nach dem Starten der App erhält der eingeloggte Benutzer einen
Überblick mit den wichtigsten Informationen zu den laufenden Umfragen.
Von hier kann er leicht zu den Übersichten für vergangene und kommende
Umfragen wechseln
Beteiligte Akteure Benutzer
Vorbedingung
Der Benutzer ist eingeloggt.
Trigger
Der Benutzer startet die App oder navigiert zurück zu dieser Übersicht.
Nachbedingung
Komplexität
Niedrig: Sowohl die GUI als auch die Kommunikation mit der Datenbank
sind wenig komplex.
Priorität
Hoch: Hier handelt es sich um die „Startseite“ der App für eingeloggte
Benutzer und um ein essentielles Navigationselement m App.
GUI
Abbildung 4.4
Tabelle A.11: Use Case #12
XV
Literaturverzeichnis
Literaturverzeichnis
[1] „ARSnova,“ Technische Hochschule Mittelhessen, [Online]. Verfügbar:
https://arsnova.eu/mobile/. [Zugriff am 21 05 2014].
[2] Buchholz Wengst GbR, „eduVote,“ 2012. [Online]. Verfügbar: http://www.eduvote.de/.
[Zugriff am 15 05 2014].
[3] Universität Paderborn, Fakultät für Wirtschaftswissenschaften, „PINGO-Projekt,“ 2014.
[Online]. Verfügbar: http://wiwi.uni-paderborn.de/dep3/winfo2/forschung/projekte/peerinstruction-for-very-large-groups/. [Zugriff am 15 05 2014].
[4] Universität Paderborn, Fakultät für Wirtschaftswissenschaften, „PINGO-Produkt,“ 2014.
[Online]. Verfügbar: http://pingo.upb.de/. [Zugriff am 15 05 2014].
[5] E. Senst, „FreeQuizDome,“ [Online]. Verfügbar: http://freequizdome.com/. [Zugriff am 15
05 2014].
[6] I. Sommerville, Software Engineering, München: Pearson Deutschland, 2012.
[7] „Android Developers Design,“ [Online]. Verfügbar:
http://developer.android.com/design/index.html. [Zugriff am 15 05 2014].
[8] Balsamiq Studios, „Balsamiq Mockups,“ 2014. [Online]. Verfügbar:
http://www.balsamiq.com/products/mockups/. [Zugriff am 23 05 2014].
[9] JGraph Ltd, „jgraph - connecing the dots,“ [Online]. Verfügbar: http://www.jgraph.com/.
[Zugriff am 27 05 2014].
[10] Oracle
Corporation, „Java
for Developers,“
2014.
[Online]. Verfügbar:
http://www.oracle.com/technetwork/java/javase/downloads/index.html. [Zugriff am 16 05
2014].
[11] C. Ullenboom, Java ist auch eine Insel, Galileo Computing, 2012.
[12] J. Liu und J. Yu, „Research on Development of Android Applications,“ in 2011 Fourth
International Conference on Intelligent Networks and Intelligent Systems, 2011.
[13] „Android Developers Develop,“ [Online]. Verfügbar:
http://developer.android.com/develop/index.html. [Zugriff am 16 05 2014].
[14] The 4ViewSoft Company, „AChartEngine,“ 2013. [Online]. Verfügbar:
http://www.achartengine.org/. [Zugriff am 16 05 2014].
[15] J. Van Der Linden und R. Nurik, „Android Holo Colors,“ [Online]. Verfügbar: http://androidholo-colors.com/. [Zugriff am 20 05 2014].
XVI
Erklärung der Selbstständigkeit
[16] T. Künneth, Android 4 - Apps entwickeln mit dem Android SDK, Bonn: Galileo Press, 2014.
Erklärung der Selbstständigkeit
Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbständig und ohne fremde Hilfe
verfasst und keine anderen als die in der Arbeit abgegebenen Quellen oder Hilfsmittel benutzt
habe. Diese Arbeit hat in gleicher Form oder in ähnlicher Form noch keinem Prüfungsamt
vorgelegen.
Mainz, 4. Juni 2014
………………..………………………………………………………….
Alessa Groß
XVII