Bachelorarbeit - glk.uni-mainz.de · erste Teil des Namens „Audience Interaction Network“ lehnt dabei stark an den Ursprung der App, nämlich einem Audience Response System, an

Bachelorarbeit Zum Thema

Autor: Alessa Groß

Betreuer: Dr. Hans-Jürgen Schröder

Abgabedatum: 04. Juni 2014

Ein modernes Audience Response System

Persönliche Danksagung

II

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.

Inhaltsverzeichnis

III

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 Konzept .......................................................................................................................... 14

2.3.1 Benutzer und ihre Rollen ........................................................................................ 14

2.3.2 Aufbau einer Umfrage ............................................................................................ 15

3 Anforderungen an das System ....................................................................................... 17

3.1 Funktionale Anforderung ............................................................................................... 17

3.1.1 Muss-Kriterien ........................................................................................................ 17

3.1.2 Kann-Kriterien ........................................................................................................ 18

3.2 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

4 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

Inhaltsverzeichnis

IV

4.3.2 Lokale SQLite-Datenbank ....................................................................................... 37

4.3.3 Synchronisation ...................................................................................................... 39

4.3.4 XML-Datentypen .................................................................................................... 39

5 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

Abbildungsverzeichnis

V

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

Tabellenverzeichnis

VI

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

Quellcodeverzeichnis

VII

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

1 Einleitung

1

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 Software-

Entwicklung 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.

2 Grundlagen

2

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 Grundlagen

3

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 Gutenberg-

Universitä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.

2 Grundlagen

4

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

2 Grundlagen

5

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.

2 Grundlagen

6

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 (UI-

Elemente) 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.

2 Grundlagen

7

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 Feedback-

Statistik, 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-Response-

System 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

2 Grundlagen

8

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 „eduVote-

show“ 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

2 Grundlagen

9

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-Choice-

Fragen, 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]

2 Grundlagen

10

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.

2 Grundlagen

11

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 Quadrant-

Diagramm6 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.

2 Grundlagen

12

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]

2 Grundlagen

13

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

2 Grundlagen

14

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]

2 Grundlagen

15

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.

2 Grundlagen

16

Frage-Typ Erklärung geeignetes Diagramm zur Ergebnisdarstellung

Lösung möglich

Single-Choice

Der Teilnehmer hat eine Auswahl an Antwortmöglichkeiten und kann genau eine auswählen.

Balken- oder Kreisdiagramme

Ja

Multiple-Choice

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 Wert zwischen einem minimalen und einem maximalen Wert. Minimaler, maximaler Wert und Einheit der Werte müssen vom Autor angegeben werden.

Liniendiagramm Ja

Schätzen Der Teilnehmer schätzt eine Zahl als Antwort. Der Autor stellt ein, wie viele (Nachkomma-) Stellen möglich sind.

Liniendiagramm 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.

3 Anforderungen an das System

17


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).


18

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.


19

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 Kann-

Kriterien 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.


20

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


21

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 Fragen in einer Umfrage beantworten

ID #05

Beschreibung 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.


22

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.


23

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 Umfragedetails einsehen

ID #06a

Beschreibung 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 Benutzer-Rollen.

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.


24

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 Einloggen

ID #09a

Beschreibung Der Benutzer loggt sich im System ein und hat Zugriff auf alle Funktionen.


Vorbedingung Der Benutzer muss registriert und ausgeloggt sein, um sich einloggen zu können.

Trigger 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.

Nachbedingung 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.

Komplexität Hoch: Die GUI zum Einloggen ist simpel. Jedoch das Synchronisieren der Daten auf dem Gerät mit der Datenbank beim Einloggen ist komplex.

Priorität Hoch: essentielle Funktion

GUI Abbildung 3.4 Tabelle 3.3: Use Case #09a


25

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.


26

Use Case Einladungen zu Umfragen annehmen

ID #13

Beschreibung Ein Benutzer wird von anderen Benutzern zu Umfragen eingeladen, um an diesen Umfragen teilzunehmen.


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.

4 Planung und Design

27


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 Android-

Gerä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


28

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,


29

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


30

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 php-

Webservice, 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.


31

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 Umfrage-Editor 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 Android-

Benutzern 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.


32

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


33

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 App-

Komponenten 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 Top-

Level-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


34

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


35

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 Android-Gerä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 SQLite-

Datenbank 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.


36

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


37

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


38

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


39

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.


40

<singlechoice>

<option nr="0" correct="true" counter="2">Option 0</option>

<option nr="1" counter="6">Option 1</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>



</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.


41

<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 ResultXML-

Werte 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.

5 Entwicklung

42

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 Diagramm-

Zeichenprogramm 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 Web-

Adresse erreichbar. In draw.io kann der Benutzer ähnlich wie bei Balsamiq Mockups per Drag-and-

Drop 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]

5 Entwicklung

43

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 Gutenberg-

Universitä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

5 Entwicklung

44

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 Dalvik-

Executables (.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]

5 Entwicklung

45

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 v4-

Bibliothek 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 Support-

Bibliothek 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 SQL-Anfragen 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 Javascript-

Anwendungen zu verschicken. Es ist eine leicht leserliche Notation, die in mehreren Name/Wert-

Paaren 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“

5 Entwicklung

46

[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 Ressourcen-

Verwaltung 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 Android-

Paket 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

5 Entwicklung

48

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 Singleton-

Pattern 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

5 Entwicklung

49

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 UI-

Element 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.

6 Das Produkt

50

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.

6 Das Produkt

51

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.

6 Das Produkt

52

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

6 Das Produkt

53

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 Single-

Choice- 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 Multiple-Choice-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

6 Das Produkt

54

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.

6 Das Produkt

55

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.

7 Fazit

56

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.

7 Fazit

57

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 VBA-

Basis 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 Powerpoint-

Plugin 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 Android-

Notifications 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

7 Fazit

58

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 Gutenberg-

Universitä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.

Anhang A - Use Cases

VIII


Use Case Umfrage erstellen

ID #01

Beschreibung 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.


GUI Abbildung 4.7 Tabelle A.1: Use Case #01

Use Case Umfrage löschen

ID #02

Beschreibung Ein Benutzer kann eine Umfrage löschen.

Beteiligte Akteure Umfrage-Administrator, (Autor, Teilnehmer)

Vorbedingung 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.)

Trigger Der Benutzer klickt auf die Lösch-Option der Umfrage.

Nachbedingung 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.)

Komplexität 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.

Priorität Niedrig: gehört nicht zu den häufig auftretenden Use-Cases und ist nicht essentiell für die Abläufe im System

GUI Abbildung A.1 Tabelle A.2: Use Case #02


IX

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 Umfrage bearbeiten

ID #03

Beschreibung 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 Start- und 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.



X

Use Case Umfrage starten (/stoppen)

ID #04

Beschreibung 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.


Use Case Umfrageergebnisse einsehen

ID #06b

Beschreibung 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.


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 Datenbank-Kommunikation.

Priorität Hoch: Das Einsehen der Details ist eine wichtige Funktion für alle Benutzer-Rollen. 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


XI

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


XII

Einblick in die Fragen. Sofern die Fragen nicht anonym gestellt wurden, sehen sie allerdings auch die Ergebnisse eines jeden Teilnehmers.

Use Case Account erstellen

ID #07

Beschreibung 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.


Abbildung A.3: GUI zum Einloggen in die App und zum Erstellen eines neuen Accounts.


XIII

Use Case Account löschen

ID #08

Beschreibung 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.



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.


Abbildung A.4: GUI für die Einsicht der eigenen Account-Daten eines Benutzers - Hier kann der Benutzer sowohl E-Mail-Adresse 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.


XIV

Use Case Ausloggen

ID #09b

Beschreibung Der Benutzer loggt sich aus dem System aus, um alle Aktivitäten im System zu beenden und den Zugriff durch Dritte zu unterbinden.


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.


GUI Abbildung A.1 + Abbildung A.4 (jeweils Eintragungen im Options-Menü) Tabelle A.8: Use Case #09b

Use Case E-Mail-Adresse ändern

ID #10

Beschreibung Der Benutzer kann zu jeder Zeit seine E-Mail-Adresse ändern.


Vorbedingung Der Benutzer ist eingeloggt und die neue E-Mail-Adresse ist im System noch nicht vorhanden.

Trigger Der Benutzer gibt die neue E-Mail-Adresse an und schickt sie mit Betätigen des „Speichern“-Buttons ab.

Nachbedingung Die E-Mail-Adresse wird in der Datenbank aktualisiert.


Priorität Mittel: Das Ändern der E-Mail-Adresse ist nicht essentiell für die Abläufe im System.


Use Case Passwort ändern

ID #11

Beschreibung Der Benutzer kann zu jeder Zeit sein Passwort ändern.



Trigger Der Benutzer gibt ein neues Passwort an und schickt es mit Betätigen des „Speichern“-Buttons ab.

Nachbedingung Das Passwort wird verschlüsselt in der Datenbank aktualisiert.


Priorität Mittel: Das Ändern des Passworts ist nicht essentiell für die Abläufe im System.



XV

Use Case Umfrage-Überblick einsehen

ID #12

Beschreibung 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



Trigger Der Benutzer startet die App oder navigiert zurück zu dieser Übersicht.

Nachbedingung -


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

Literaturverzeichnis

XVI

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/peer-

instruction-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://android-

holo-colors.com/. [Zugriff am 20 05 2014].

Erklärung der Selbstständigkeit

XVII

[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ß

Documents

Bachelorarbeit - glk.uni-mainz.de · erste Teil des Namens „Audience Interaction Network“ lehnt dabei stark an den Ursprung der App, nämlich einem Audience Response System, an