Bachelorarbeit. Zum Thema. Ein modernes Audience Response System

Transkript

1 Bachelorarbeit Zum Thema Ein modernes Audience Response System Autor: Alessa Groß Betreuer: Dr. Hans-Jürgen Schröder Abgabedatum: 04. Juni 2014

2 Persönliche Danksagung Persönliche Danksagung An dieser Stelle möchte ich mich bei all denjenigen bedanken, die mich bei der Erstellung dieser Arbeit unterstützt haben. Ein besonderer Dank gilt Herrn Dr. Hans-Jürgen Schröder für die Betreuung meiner Arbeit sowie für die konstruktiven Fachgespräche, durch die er mir immer wieder den nötigen Aufschwung gegeben hat. Mein besonderer Dank gilt auch Herrn André Runge, der mir geduldig mit allen meinen Anforderungen und Fragen an die Serverseite geholfen hat und immer schnell eine Lösung parat hatte. II

3 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis... III Abbildungsverzeichnis... V Tabellenverzeichnis... VI Quellcodeverzeichnis... VII 1 Einleitung Grundlagen Problemstellung Konkurrenzprodukte Eine Analyse ARSnova eduvote PINGO FreeQuizDome Konsequenzen für die Entwicklung von Mainzel Konzept Benutzer und ihre Rollen Aufbau einer Umfrage Anforderungen an das System Funktionale Anforderung Muss-Kriterien Kann-Kriterien Nicht-funktionale Anforderungen Muss-Kriterien Kann-Kriterien Use Case Diagramm Use Cases Planung und Design Systemarchitektur Globale Systemarchitektur Architektur eines Mainzel-Clients App-Architektur Frontend-Design Datenbanken-Design Globale MS SQL Datenbank III

4 Inhaltsverzeichnis Lokale SQLite-Datenbank Synchronisation XML-Datentypen Entwicklung Entwicklungssoftware Balsamiq Mockups draw.io Gimp Android Developer Tools Bundle SQL Server Management Studio und MS SQL Server Verwendete Technologien und Bibliotheken Java Android SDK und Android Support v4-bibliothek AChartEngine SQLSRV JSON Android Holo Colors Umsetzung der App mit Java, XML und den verwendeten Bibliotheken Klassen XML-Dateien Das Produkt Fazit Einsatzfähigkeit Umgesetzte Anforderungen Ausblick Anhang A - Use Cases... VIII Erklärung der Selbstständigkeit... XVII IV

5 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 2.1: Die Hardware des bisherigen ARS des Instituts für Informatik... 4 Abbildung 2.2: Dozentenbereich von ARSnova... 5 Abbildung 2.3: Beantwortung einer Frage in ARSnova... 6 Abbildung 2.4 Beantwortung einer Frage in EduVote... 8 Abbildung 2.5: Die Autorenansicht einer vergangenen Frage in PINGO... 9 Abbildung 2.6: Beantwortung einer Frage in PINGO Abbildung 2.7: Desktopsoftware von FreeQuizDome Abbildung 2.8: Beantwortung einer Frage in FreeQuizDome Abbildung 3.1: Use-Case Diagramm Abbildung 3.2: Benutzeroberfläche zum Beantworten einer Frage Abbildung 3.3: Detailansicht von Umfragen Abbildung 3.4: Benutzeroberfläche zum Einloggen in die App Abbildung 3.5: Benutzeroberfläche zum Einsehen der Einladungen Abbildung 4.1: Globale Client-Server-Architektur von Mainzel Abbildung 4.2: Architektur eines Clients im Schichten-Model Abbildung 4.3: Vereinfachte Architektur der Mainzel-App Abbildung 4.4: Umfrage-Übersicht Abbildung 4.5: Frontend-Komponenten der App Abbildung 4.6: Detailansicht einer Frage Abbildung 4.7: Umfragen-Editor Abbildung 4.8: Globales Datenbankdiagramm Abbildung 4.9: Diagramm der lokalen Datenbank Abbildung 5.1: Klassendiagramm.47 Abbildung 6.1: Login-Ansicht Abbildung 6.2 Nach dem Einloggen in die Mainzel-App Abbildung 6.3: Ansicht zum Beantworten einer Single-Choice-Frage Abbildung 6.4: Auswertung drei vergangener Fragen Abbildung 6.5: Umfrage-Editor Abbildung A.1: Benutzeroberfläche zum Bearbeiten von Umfragen... IX Abbildung A.2: Ansicht zum Einsehen der eigenen Ergebnisse in bereits geschlossenen Fragen.. XI Abbildung A.3: GUI zum Einloggen in die App und zum Erstellen eines neuen Accounts... XII Abbildung A.4: GUI für die Einsicht der eigenen Account-Daten eines Benutzers... XIII V

6 Tabellenverzeichnis Tabellenverzeichnis Tabelle 2.1: Auflistung aller Frage-Typen von Mainzel Tabelle 3.1: Use Case # Tabelle 3.2: Use Case #06a Tabelle 3.3: Use Case #09a Tabelle 3.4: Use Case # Tabelle A.1: Use Case #01... VIII Tabelle A.2: Use Case #02... VIII Tabelle A.3: Use Case #03... IX Tabelle A.4: Use Case #04... X Tabelle A.5: Use Case #06b... X Tabelle A.6: Use Case #07... XII Tabelle A.7: Use Case #08... XIII Tabelle A.8: Use Case #09b... XIV Tabelle A.9: Use Case #10... XIV Tabelle A.10: Use Case #11... XIV Tabelle A.11: Use Case #12... XV VI

7 Quellcodeverzeichnis Quellcodeverzeichnis Quellcode 4.1: Beispiel für ein AnswerXML-Wert einer Single-Choice-Frage Quellcode 4.2: Beispiel für ein AnswerXML-Wert einer Schätzfrage Quellcode 4.3: Beispiele für ResultXML-Werte einer Datum- und einer Position-Frage VII

8 1 Einleitung 1 Einleitung Im Rahmen dieser Arbeit wurde eine Android App entwickelt, die ein modernes Audience Response System (ARS) darstellt. Die Schritte und Besonderheiten bei der Durchführung der Planung, Entwicklung und Implementation der App werden auf den folgenden Seiten behandelt. Ein ARS ermöglicht dem Publikum eines Vortrags die Fragen des Vortragenden mit Hilfe von Fernbedienungen digitalisiert zu beantworten. Es wertet daraufhin die Ergebnisse aus und stellt sie in angemessener Weise für die Einsicht durch den Vortragenden bereit. Ein solches System motiviert und aktiviert das Publikum und gibt gleichzeitig eine Rückmeldung an den Vortragenden, in wie weit das Publikum ihm folgen kann. Um ein solches klassisches ARS mit spezieller Hardware durch moderne, hardwareunabhängige Technologien am Institut für Informatik der Johannes Gutenberg-Universität in Mainz zu ersetzen, wurde die Idee einer Android App als ARS entwickelt. Die App stellt die Funktionen zum Erstellen von Fragen, Beantworten durch die Teilnehmer und sowohl zum Auswerten, als auch zum Einsehen der Ergebnisse bereit. Es kombiniert dadurch die modernen Möglichkeiten einer App mit dem klassischen Nutzen eines ARS. Die entwickelte App trägt den Namen Mainzel. Auf die Herkunft Bezug nehmend, ist der Name eine Abkürzung für Mainzer Audience Interaction Network for large-sized Learning groups. Der erste Teil des Namens Audience Interaction Network lehnt dabei stark an den Ursprung der App, nämlich einem Audience Response System, an. Er erweitert allerdings die Bedeutung um die Neuerungen von Mainzel, die es gegenüber einem klassischen ARS mitbringt. Im Gegensatz zum klassischen ARS, bietet Mainzel nicht allein die Möglichkeit in eine Richtung Antworten ( Response ) zu verschicken, vielmehr können alle Benutzer in Interaktion miteinander treten. Die Rollenverteilung des Vortragenden und der Zuhörerschaft innerhalb des ARS verwischt unter Mainzel und kann von Mal zu Mal neu verteilt werden. Weiterhin wird der Typ des Systems von Mainzel näher als Netzwerk ( Network ) beschrieben. Damit wird der Charakter einer vernetzten Mainzel-Community hervorgehoben, in der alle Benutzer auf gleicher hierarchischer Ebene stehen und alle zu jeder Zeit in alle Rollen schlüpfen können, um miteinander in Kontakt zu treten. Außerdem ist Mainzel durch verschiedene Faktoren wie dem Community-Charakter und der Verwendung moderner Technologien, die beispielsweise keinen physischen Empfänger, wie im klassischen ARS, mehr benötigen, für große Gruppen ( large-sized groups ) geeignet. Beispielsweise müssen in großen Lehrveranstaltungen nicht einmal alle Beteiligten im selben Raum sein, um einander Fragen und Antworten zu liefern. Schließlich wurde Mainzel zum Einsatz in einer Universität entwickelt und daher wurde der Nutzen beim Lernen ( Learning groups ) mit Mainzel stets im Auge behalten. Zur Aufarbeitung des Themas wird in Kapitel 2 zunächst ein Überblick über den Markt und später eine Einführung in die Begrifflichkeiten und das Konzept von Mainzel gegeben. Im darauf folgenden Kapitel 3 werden alle Anforderungen an das System nach den Regeln der 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. 1

9 2 Grundlagen 2 Grundlagen Dieses Kapitel widmet sich den Grundlagen der Thematik, indem zunächst die Problemstellung definiert wird. Darauf folgt eine Analyse bereits bestehender ähnlicher Systeme und schließlich wird das Konzept des Produkts erklärt, das dieser Arbeit zu Grunde liegt. 2.1 Problemstellung Jeder kennt das Problem: Bereits in der Schule kämpft der Schüler mit langweiligen Unterrichtsstunden und trockenem Stoff. Schon lange ist bekannt, dass der klassische Frontalunterricht für die meisten Lerntypen nicht geeignet ist und so nur wenige Schüler davon profitieren können. Um dem entgegen zu wirken, wurden und werden alternative Unterrichtsmethoden entwickelt, die den Schüler mehr in die Vermittlung und Erarbeitung des Lernstoffes einbinden und bei denen Lehrer öfter Rückmeldung über den Wissensstand der Schüler erhalten. Trotz der Veränderungen der Unterrichtsmethoden steht in späteren Ausbildungsabschnitten schließlich mehr die Wissensvermittlung als die didaktische Methode im Mittelpunkt. Vor allem Vorlesungen im akademischen Bereich, in denen ein Dozent zumeist im klassischen Vortrag an der Tafel oder mit vorbereiteter Beamer-Präsentation das Wissen vermittelt, treffen auf diese Beschreibung zu. Das mag seine Richtigkeit in der akademischen Ausbildung haben, in der es vor allem um die effiziente Weiterbildung geht und die Eigeninitiative der Lernenden notwendig ist. Dennoch können die Grundgedanken aus den neuen Lernmethoden, nämlich den Lernenden mit einzubeziehen und die Rückmeldungen an den Lehrenden zu erhöhen, auch an der Hochschule von Vorteil sein. Sicherlich gibt es bereits Empfehlungen und Tipps, die diese Erkenntnisse allgemein für Vorträge aller Art umsetzen. Beispielsweise ist es für den Vortragenden am einfachsten den Wissenstand des Publikums in Erfahrung zu bringen und gleichzeitig das Publikum während des Vortrags zu aktivieren, indem er von Zeit zu Zeit Fragen an die Zuhörer stellt. Durch das zufällige Auftreten der Interaktion zwischen Dozent und Zuhörerschaft wird die Aufmerksamkeit erhöht und der Vortrag wirkt kurzweiliger. Auf diese Weise erreichen den Dozenten allerdings bei jeder Frage nur eine oder zumindest wenige Antworten und diese sind zumeist aus den ersten paar Reihen des Hörsaals. Oft genug kommt es in dieser Situation vor, dass ein Teil des Publikums die Frage nicht einmal gehört hat, weil er abgelenkt war. Auch das Problem solcher Ablenkungen ist jedem bekannt. Vielleicht ist man als Zuhörer im Allgemeinen unkonzentriert oder der Sitznachbar lenkt durch Gesprächigkeit ab oder moderne Ablenkungen wie Laptop, Tablet und Handy sorgen dafür, dass auch der beste Vortrag ausgeblendet wird. Allerdings können genau diese Geräte die Ablenkung in eine Aktivierung der Zuhörerschaft umkehren: Ein Szenario wäre beispielsweise ein auf seinem Smartphone im Internet surfender, abgelenkter Student, der in dem Moment für den Vortrag reaktiviert wird, wenn auf seinem Smartphone eine Nachricht aufklappt, die ihm mitteilt, dass es eine neue Frage in dieser Vorlesung gibt, für die beispielsweise nur noch 60 Sekunden zum Beantworten zur Verfügung stehen. Der Student hat zwar verpasst, dass der Dozent diese Frage gestellt hat, mit Klick auf die Nachricht auf seinem Smartphone kann er sie aber trotzdem einsehen und seine Antwort sofort eingeben und 2

10 2 Grundlagen abschicken. Im vom Student verpassten Teil des Vortrags hat der Dozent diese Frage in einem speziellen Umfragesystem für die Beantwortung für 60 Sekunden freigegeben und somit die Benachrichtigung des Studenten durch sein Smartphone ausgelöst. Nachdem die 60 Sekunden abgelaufen sind, projiziert der Dozent die Auswertung der Antworten an die Leinwand und der Student sieht dort oder auf seinem Smartphone, auf dem ein ähnliches Diagramm erscheint, ob seine Antwort richtig war. Ein solches Umfragesystem, in dem es einen Auswertungsknoten gibt, der mit mehreren Empfängern zum Beantworten der Fragen kommuniziert, und zur automatisierten Kommunikation zwischen Vortragendem und Publikum dient, wird Audience Response System oder kurz ARS genannt. Das wohl bekannteste ARS kommt bei der Auswertung des Publikumsjokers in der Fernsehsendung Wer wird Millionär zum Einsatz. Hier stellt der Moderator die Frage und gibt deutlich an, welche Antwortmöglichkeiten welchem Buchstaben zugeordnet werden. Daraufhin drücken die Zuschauer im Publikum den Buchstaben ihrer Wahl auf einer Art Fernbedienung und geben auf diese Weise ihre Antwort ab. Die Daten werden nach Ablauf der Zeit im Computer ausgewertet und als das bekannte Diagramm auf den Bildschirmen der Zuschauer zu Hause angezeigt. Die Anschaffung eines solchen Systems und der Hardware ist sicherlich teuer für eine Hochschule und letztendlich werden nie genug Fernbedienungen für eine Vorlesung zur Verfügung stehen. Aber wie bereits im Szenario dargestellt, ist es eine Möglichkeit ein ARS als Software anzubieten, das die Hardware nutzt, die bereits im Hörsaal vorhanden ist. Darüber hinaus kann eine solche Software noch weitere vorteilhafte Funktionen implementieren, die durch die festgelegte Hardware der klassischen ARS beschränkt wird. Beispielweise das Anzeigen der Fragetexte und der Antwortmöglichkeiten oder die Erweiterbarkeit der Fragetypen, die bei den meisten klassischen ARS auf Single-Choice Fragen mit fester Anzahl an Antwortmöglichkeiten beschränkt sind. Auch die strikte Trennung zwischen Auswertungsmaschine und Antwort-Fernbedienungen kann aufgehoben werden, sodass alle Beteiligten in der Position des Fragenden und des Antwortenden zur selben Zeit sein können. Schließlich ist auch eine Auswertung und Archivierung der Ergebnisse nicht nur für den Fragenden denkbar, sodass die Zuhörer auch im Nachhinein einen Überblick über die eigene Leistung einsehen können. In dieser Arbeit wird ein solches, modern interpretiertes ARS vorgestellt. Das System Mainzel wurde aus der Idee heraus geboren, ein klassisches, wie oben beschriebenes ARS unter Zuhilfenahme moderner Technologien am Institut für Informatik der Johannes 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. 3

11 2 Grundlagen Abbildung 2.1: Die Hardware des bisherigen ARS des Instituts für Informatik - Das ARS besteht aus mehreren Fernbedienungen (grau dargestellt), die durch Identifikationsnummern gekennzeichnet sind, dem Empfänger(lila dargestellt), der per Ethernet-Kabel an einen Computer angeschlossen wird und einer Auswertungssoftware, die auf demselben Computer installiert wird. Zum Abschicken seiner Antwort drückt der Student einen der Knöpfe A bis F auf einer Fernbedienung. Ein Prototyp wurde bereits im Rahmen des Datenbanken-Praktikums im Wintersemester 2013/2014 als Web-App entwickelt. Diese Version von Mainzel implementierte bereits viele Grundgedanken des in dieser Arbeit vorgestellten Produkts. Als Web-App ist es beispielsweise von den meisten in einer Vorlesung vorhandenen Geräten schnell erreichbar. Es stellt Ergebnisse in Kuchen- und Balkendiagrammen dar, sodass sie dem Publikum ohne großen Aufwand anschaulich präsentiert werde können. Weiterhin können Teilnehmer nach dem Beenden einer Frage die eigene Antwort und die richtige Antwort einsehen. Auch konzeptionell beeinflusst der Prototyp das im Rahmen dieser Arbeit entwickelte System. Beispielsweise wurden sowohl die in Kapitel 2.3 angesprochenen Begrifflichkeiten und Beziehung als auch das Datenbankmodel weitestgehend übernommen. Alle Veränderungen, Weiterentwicklungen und Anpassungen zwischen dem genannten Prototypen und dem Mainzel, das dieser Arbeit zu Grunde liegt, sind mit dem Hintergrund gemacht worden, Mainzel so offen wie möglich zu gestalten, sodass sein Einsatz nicht allein auf den akademischen Bereich beschränkt ist, sondern sich für Vorträge und Fragerunden aller Art eignet. 2.2 Konkurrenzprodukte Eine Analyse Oft wird auf unterschiedliche Weise versucht Vorträge oder Unterrichtsstunden in der Schule und im universitären Umfeld anschaulicher, spannender und kurzweiliger zu gestalten. Aus diesem Grund ist es selbstverständlich, dass das Mainzel-System nicht das einzige seiner Art auf dem Markt sein wird. Es verfolgt zwar durch seinen mobilen Einsatz und den offen gehaltenen Fragetypen nicht zwangsläufig das Ziel ausschließlich im Frontalunterricht eingesetzt zu werden, aber es muss sich dennoch dem Vergleich mit bereits bestehenden Produkten stellen, die für diesen Einsatz konzipiert wurden. Es gibt bereits eine Reihe von ARS auf Basis von Web- und mobilen Technologien, die genau wie Mainzel, für den akademischen Bereich entwickelt wurden. Im Folgenden werden vier Produkte dieser Art vorgestellt und ein Vergleich mit Mainzel gezogen ARSnova Das kostenlose Produkt ARSnova der Technischen Hochschule Mittelhessen ist Mainzel vielleicht noch am ähnlichsten, da es vorwiegend durch Bachelor- und Master-Arbeiten entwickelt und weiterentwickelt wird. Es ist ein typisches Produkt aus der Hochschule für die Hochschule und 4

12 2 Grundlagen lädt mit dem Slogan Feedback im Hörsaal auf der Startseite, auf der man sich als Zuhörer/in oder Dozent/in anmeldet, einzig zur Benutzung im universitären Bereich ein. Dennoch ist das Konzept, das sich hinter der kategorisierenden Startseite verbirgt, offen für viele andere Anwendungsbereiche. Abbildung 2.2: Dozentenbereich von ARSnova - Dargestellt ist die Ansicht zum Erstellen von vorbereiteten Fragen. [1] In ARSnova werden mehrere Fragen in einer Session zusammengefasst. Es gibt die Fragetypen Multiple-Choice, Single-Choice, Ja-Nein-Frage, Freitext, Rating 1, Schulnote und Lernkarte 2. Als einziges Produkt unter den in dieser Arbeit vorgestellten Konkurrenzprodukten von Mainzel, kann der Dozent für jede Frage angeben, ob eine Enthaltung möglich sein soll. Die Fragen können entweder als Hörsaal-Fragen angelegt werden und sie dadurch erst in der Vorlesung zu beantworten oder als Vorbereitungsfrage eingetragen werden, sodass Teilnehmer sie vorher schon zur Vorbereitung nutzen können. Die Übersicht über bereits erstellte Vorbereitungsfragen ist in Abbildung 2.2 dargestellt. Aktive Teilnehmer an einer Session, werden in Form von einem Zähler auf dem Startbildschirm auf die Anzahl unbeantworteter Fragen hingewiesen. Ebenfalls als einziges System, der hier analysierten Konkurrenzprodukte von Mainzel, hat der Dozent hier die Möglichkeit mehrere Fragen parallel zu stellen. Die Ansicht zur Beantwortung einer Frage wird in Abbildung 2.3 dargestellt. 1 Im Rating-Frage-Typ von ARSnova werden fünf vorgefertigte Antwortmöglichkeiten von trifft voll zu bis trifft nicht zu angeboten. 2 Lernkarten in ARSnova sind zum Selbst-Studium ausgelegt und können wie digitale Kartei-Lernkarten angesehen werden. 5

13 2 Grundlagen Mit einem Swipe 3 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. 6

14 2 Grundlagen Weiterhin existiert die Desktop-Erweiterung ARSnova Overlay, die auf einem PC installiert wird und sich als kleines Widget auf dem Bildschirm über die Präsentationsfolien des Dozenten legt. Es zeigt auf einen Blick die Ergebnisse des Feedbacks als Smiley und informiert über eingegangene Zwischenfragen. Mit Klick auf das Widget öffnet sich ein größeres Fenster, in dem die 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 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 -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 -Adresse des Dozenten eingeben. Mit Klick auf Vote kann der Teilnehmer die laufende Frage beantworten. Bei erneutem Klick auf den Abstimmungs-Button wird erkannt, dass der Teilnehmer bereits abgestimmt hat. Es ist allerdings wie bei den klassischen Hardware-Buzzern für den Teilnehmer 7

15 2 Grundlagen nicht ersichtlich, wann eine neue Frage beantwortet werden kann. Auch der Fragetext wird wie beim klassischen Vorbild nicht angezeigt, sofern der Dozent diese Option nicht ausdrücklich einstellt. Die Anzeige der Antwortmöglichkeiten ist gar nicht möglich. Diese werden lediglich mit A, B, C, D, E, je nach Anzahl der Antwortmöglichkeiten, benannt. Ein Beispiel für diese Darstellung ist in Abbildung 2.4 zu sehen. Abbildung 2.4 Beantwortung einer Frage in EduVote - Da es nur den Single-Choice Frage-Typ gibt, sieht die Ansicht zum Beantworten immer wie oben dargestellt aus und unterscheidet sich lediglich in der Anzahl der Abstimmungs-Buttons. [2] Der Dozent hat außerdem die Möglichkeit sogenannte Sofortfragen zu stellen, bei denen er mit wenigen Klicks während der Vorlesung und ohne Eingabe des Fragetexts eine Frage starten kann. Der Fragetext und die Antwortmöglichkeiten müssen hier über ein anderes Medium, wie beispielsweise die Präsentationsfolien des Dozenten, für die Teilnehmer ersichtlich sein. Für Dozenten stellt eduvote das auf Windows- und Apple-Geräten zu installierende eduvoteshow zur Verfügung, in dem alle oben beschriebenen Funktionen verfügbar sind. Weiterhin gibt es eduvote für Dozenten als Webseite, im Rahmen derer allerdings keine Fragen vorbereitet und gespeichert werden können. Für die Teilnehmer bietet eduvote eine breite Auswahl von Anwendungen für verschiedene Plattformen. Es wurden sowohl Apps für Android, ios, das Windows Phone 8, Software für Windows-Rechner und Mac OS als auch eine Browseranwendung entwickelt. Zusammengefasst bildet eduvote sehr genau die Handhabung eines klassischen ARS mit speziellen Hardware-Buzzern und einem Auswertungsgerät auf moderne Technologien ab. Es stellt dabei Applikationen für jede gängige Plattform bereit, sodass das System sowohl für Teilnehmer als auch Dozenten schnell und vor allem im gewohnten System zugänglich ist. Abgesehen von der Verfügbarkeit auf verschiedenen Plattformen, nutzt es allerdings nicht die Vorteile der modernen Technologien, auf denen es installiert wird. Die Fragetypen etwa sind genauso eingeschränkt, wie auf Hardware-Buzzern, auf denen es nur eine festgelegte Anzahl an Knöpfen geben kann. Weiterhin werden aus Gründen des Datenschutzes [2], wie die Entwickler schreiben, die Fragen ausschließlich auf dem Rechner des Dozenten gespeichert, sodass der Teilnehmer die Frage- und Antworttexte auf dem eigenen Gerät nicht nachlesen kann und keine Möglichkeit zur späteren Selbstkontrolle hat. Das ist ein großer Nachteil von eduvote aus studentischer Sicht, denn vor allem in der Vorbereitung auf die Klausuren möchte ein Teilnehmer einer Vorlesung sicherlich noch einmal einen Überblick über die gestellten Fragen und die eigenen Antworten erhalten. Diese Funktion kann auch mit Blick auf den Datenschutz einfach implementiert werden und ist 8

16 2 Grundlagen bereits durch die Konzeption von Mainzel als Community, die später noch detaillierter besprochen wird, grundsätzlich vorgesehen 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] 9

17 2 Grundlagen Mit Klick auf die Session-ID sieht der Dozent die Ansicht der Teilnehmer. Zum Teilnehmer an einer Session wird man über die Eingabe dieser Session-ID, eines Session-Links oder eines QR-Codes. Sobald eine Frage freigegeben wird, aktualisiert sich automatisch die Ansicht des Teilnehmers, sodass er die Frage mit allen Antwortmöglichkeiten sofort lesen und beantworten kann. Abbildung 2.6 zeigt diese Ansicht zum Beantworten einer Frage. Bei der Beantwortung der Frage ist der Teilnehmer sowohl für den Dozenten als auch für das System anonym und kann die Frage zu einem späteren Zeitpunkt nicht mehr einsehen. Abbildung 2.6: Beantwortung einer Frage in PINGO - Gezeigt wird eine Single-Choice-Frage, zu der der Benutzer mit Klick auf Abstimmen! seine Antwort abgibt. [4] Als einziges Produkt in dieser Runde sind sowohl eine Session als auch der Fragenkatalog teilbar mit anderen registrierten PINGO-Benutzern, sodass ein Dozent auch seine Mitarbeiter an seiner Arbeit zu einer Vorlesung beteiligen kann und umgekehrt. Weiterhin kann PINGO TeX-Formeln in Fragen- und Antworttexten darstellen, sodass es sich besonders für Fragen aus dem Bereich der Naturwissenschaften eignet. Es besteht ebenfalls eine Schnittstelle für den Import und Export der Fragen zu Moodle 4. 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 Design 5 auf verschiedene Bildschirmgrößen reagiert, sodass der Service sowohl in Browsern auf mobilen Geräten als auch beispielsweise am PC nichts an Handhabung verliert. 4 Moodle ist eine Lernplattform für akademische Einrichtungen, die als Open-Source-Software vertrieben wird. Durch die offene Konzeption sind eigene Weiterentwicklungen möglich. 5 Eine auf einem responsive Design basierende Webseite antwortet auf die Eigenschaften des Geräts, auf dem sie geöffnet wird, wie Größe und Orientierung des Bildschirms. Ändern kann sich beispielsweise die Anordnung oder die Größe, aber auch die Sichtbarkeit der Elemente der Webseite. 10

18 2 Grundlagen Somit ist PINGO eine moderne Interpretation eines ARS, das viele Vorteile einer Web-Anwendung ausreizt. Das Design und der Aufbau sind schnell zugänglich, leicht verständlich und haben den Vorteil, auf jedem Gerät mit Browser auf die gleiche Weise verfügbar zu sein. Es wurde sehr viel Wert darauf gelegt, dass die Daten eines PINGO-Accounts auf verschiedenen Wegen exportiert und mit anderen PINGO-Nutzern geteilt werden können. Allerdings ist es auch in diesem System nicht auf direktem Weg vorgesehen, dass Studenten noch im Nachhinein von der Befragung profitieren können. Durch die Schnittstelle zu Moodle ist diese Funktion zwar grundsätzlich möglich, doch der Dozent muss zunächst bereit sein diesen Export zu leisten und die Studenten müssen sich zudem in Moodle anmelden 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- Diagramm 6 mit der Antwort ab. Für den Frage-Typ Image Answer kann der Teilnehmer entweder ein Bild hochladen oder selbst eines auf einem HTML5-Canvas 7 malen. Die Ergebnisse einer Rating Scale -Frage können ausführlich über die Angaben Median, Modalwert, arithmetisches Mittel, Varianz, Standardabweichung und die Möglichkeit zum Clustern der Ergebnisse analysiert werden. Der Dozent kann immer nur eine Frage nach der anderen stellen. In diesem Produkt kann der Dozent Fragen einzeln oder zusammen mit anderen Fragen als Quiz abspeichern. Auch Ergebnisse können gespeichert und exportiert werden, um sie zu einem späteren Zeitpunkt weiterzuverwenden oder einen Ausdruck zu machen. Dabei können geladene Ergebnissätze in einer erneuten Umfrage erweitert werden. 6 In einem Quadrant-Diagramm im FreeQuizDome-System kann der Teilnehmer ein Wort oder eine Phrase zu den vier Standardkategorien Stärke, Schwäche, Chancen und Gefahr abschicken. Die Kategorien können vom Fragesteller angepasst werden. 7 Das <canvas>-tag von HTML 5 ist zur Darstellung von Grafiken und vor allem Zeichnungen vorgesehen. Es kann dazu verwendet werden, um Grafiken mit Hilfe Javascript darzustellen oder um dem Benutzer eine digitale Leinwand, wie es in FreeQuizDome der Fall ist, zur Verfügung zu stellen. 11

19 2 Grundlagen Abbildung 2.7: Desktopsoftware von FreeQuizDome - In der Darstellung ist die Auswertung für den Autor einer vergangenen Single-Choice-Frage zu sehen. [5] Als Teilnehmer an einer FreeQuizDome Frage muss man sich ebenfalls nicht registrieren. Der Teilnehmer scannt lediglich den QR-Code der Frage ein oder gelangt durch einen Link direkt auf die in Abbildung 2.8 gezeigte Webseite zum Abgeben seiner Antwort. Jede Frage hat einen zuvor vom Dozenten eingestellten Countdown. In diesen Countdown muss der Dozent allerdings die Zeit einberechnen, die der Teilnehmer braucht, um auf die Antwortseite zu gelangen, da für jede Frage ein neuer QR-Code und Link generiert wird, sobald die Frage startet. Abbildung 2.8: Beantwortung einer Frage in FreeQuizDome - Da es sich bei der Frage um eine Single-Choice-Frage handelt, wird mit Klick auf die jeweilige Antwortmöglichkeit diese direkt als eigene Antwort abgegeben. [5] 12

20 2 Grundlagen Die Software für die Dozentenrolle wird sowohl für Windows, Mac OS als auch für Linux Distributionen angeboten, sodass eines der Betriebssysteme zusammen mit der Runtime Adobe Air Voraussetzung für die Benutzung ist. Auch eine ständige Internetverbindung wird ausdrücklich benötigt. Ein Teilnehmer findet über jedes Gerät mit Browser Zugang zum Weblink, dazu reicht sogar der integrierte Browser, der manchmal bei QR-Code-Scannern mitgeliefert wird, aus. Auf Nachfrage branded das Team die FreeQuizDome-Software mit einem individuellen Design und installiert die Komponenten auf den Servern einer Hochschule, sodass sie die Anwendung als hauseigenes Tool benutzen kann. Offensichtlich wurde in dieser Software viel Wert darauf gelegt, dass sie für alle Beteiligten schnell zugänglich ist und dabei die bestmögliche didaktische Hilfestellung geleistet wird. Weiterhin sind die bereits erarbeiten Fragen und Ergebnisse erneut abrufbar und erweiterbar, sowie exportierbar, sodass man einfach zu verschiedenen Zeiten an einer Umfrage arbeiten kann. Leider gilt dies nur für die Rolle des Dozenten. Ein Teilnehmer einer Umfrage kann auch hier von den Umfragen im Nachhinein nicht profitieren. Schließlich ist es ein Vorteil von FreeQuizDome, dass sein Image nicht von vorneherein auf den akademischen Bereich festgelegt wurde, sondern für alle Anwendungen eines ARS offen gehalten ist Konsequenzen für die Entwicklung von Mainzel Ein breites Wissen über die Angebote der Konkurrenzprodukte bringt keinen Nutzen, wenn man daraus keine Konsequenzen für das eigene Produkt zieht. Natürlich verfolgt Mainzel ein weniger auf den akademischen Bereich beschränktes Image, dennoch soll es alle Annehmlichkeiten, die andere Produkte für Dozenten und Studenten bereithalten, nicht missen, denn die Anwendung in Vorlesungen wird auch für Mainzel die Hauptaufgabe darstellen. Wie diese Anforderungen im Detail aussehen, wird im nächsten Kapitel besprochen, im Folgenden soll lediglich ein Überblick über die Besonderheiten von Mainzel gegeben werden, die es von den oben angegebenen Produkten hervorhebt. Mainzel hat den Charakter einer Community, in der die Abgrenzung zwischen Dozenten- und Teilnehmerrolle verwischen. Das bedeutet, dass in Mainzel jeder angemeldete Benutzer alle Umfragen auf einen Blick sehen kann, in denen er involviert ist, sei es als Teilnehmer oder als Autor. Zu den Umfragen, in denen er Autor ist, lädt er andere Mitglieder der Community als Teilnehmer ein und wird umgekehrt zu anderen Umfragen als Teilnehmer eingeladen. Dadurch ist jeder Benutzer gleichgestellt und ein Student kann beispielsweise seinerseits eigene Umfragen zum Lernen mit anderen Studenten nutzen. Weiterhin wird durch die Einladung ermöglicht, dass Teilnehmer nicht zwangsweise mit dem Autor in Kontakt treten müssen, um zum Beispiel eine Umfrage-ID auszutauschen. Das ist im universitären Bereich von Vorteil, in dem der Dozent alle Anmeldungen zu einer Vorlesung zur Verfügung hat und auf diese Weise sehen kann, wer die Einladung annimmt und wer aktiv an den Umfragen teilnimmt. Weiterhin bietet Mainzel sowohl anonyme als auch nicht anonyme Umfragen an, sodass der Autor die Möglichkeit hat, einen Einblick über die Leistung einzelner Teilnehmer zu erhalten. Alle oben genannten Konkurrenzprodukte erlauben bisher ausschließlich anonyme Fragen. Die Möglichkeit, dass sich Teilnehmer enthalten, wird ebenfalls einstellbar sein, sodass eine genaue Aussage darüber getroffen werden kann, wenn Teilnehmer sich bewusst nicht äußern wollen oder einfach keine Antwort abgeben. Der Autor hat zudem die Möglichkeit einen Start- und einen Endzeitpunkt 13

21 2 Grundlagen für Umfragen und Fragen anzugeben, sodass diese automatisch zum Beantworten freigegeben oder beendet werden. Ein weiterer wesentlicher Vorteil von Mainzel gegenüber den oben betrachteten Produkten begründet sich in der Natur einer nativen App, die auf dem Endgerät installiert wird. Mainzel kann Teilnehmer über neue unbeantwortete Fragen mittels Notifications 8 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 Benutzer und ihre Rollen Um Benutzer von Mainzel zu werden, muss man sich zunächst mit einer -Adresse und einem Passwort registrieren. Wenn im Folgenden von einem Benutzer die Rede ist, ist damit ausschließlich ein registrierter Benutzer gemeint. Die -Adresse des Benutzers dient als Identifikationsmerkmal. Benutzerbezogene Daten, wie erstellte Umfragen und Umfrageergebnisse können somit nur eindeutig zu einer bestimmten -Adresse gehören. Jeder Benutzer kann selbst Umfragen erstellen und erhält dadurch die Autoren- und Administrator-Rolle dieser Umfragen. Zu diesen Umfragen kann er andere Benutzer zur Teilnahme einladen oder sie zu Autoren ernennen. Autoren von Umfragen können diese einsehen, editieren und starten, aber lediglich der Umfrageadministrator kann die Umfrage löschen. Wenn im Folgenden auf die Autoren einer Umfrage Bezug genommen wird, ist damit immer auch der Administrator der Umfrage gemeint, da er zusätzlich zu seinen Administrator-Rechten auch alle Rechte eines Autors an einer Umfrage hat. Nimmt ein Benutzer die Einladung zur Teilnahme an einer Umfrage an, ist er Teilnehmer dieser Umfrage und kann, sobald ein Autor die Umfrage startet, Antworten abgeben. Er wird auch die Ergebnisse zu dieser Umfrage erhalten. 8 Notifications sind kurze Nachrichten an den Benutzer außerhalb der App, die die Notification sendet. Unter Android werden Notifications zunächst als kleines Symbol in der Notification-Area (siehe dazu auch Kapitel 4.2) im linken oberen Teil des Displays angezeigt. Der Benutzer kann sie sich näher betrachten, wenn er die Notification-Area vergrößert und auf den Eintrag der Notification klickt. Notifications sollen ausschließlich in Situationen verschickt werden, in denen ein zeitnahes Handeln durch den Benutzer benötigt wird oder wenn andere Benutzer auf eine Antwort warten. [7] 14

22 2 Grundlagen Aufbau einer Umfrage Eine Umfrage besteht aus mehreren Fragen und erhält beim Erstellen vom Administrator einen Namen. Dieser kann im Nachhinein von einem Autor editiert werden. Zusätzlich kann ein Autor eine Beschreibung angeben und einstellen, ob die Ergebnisse anonym gespeichert werden und weiterhin, ob die Teilnehmer vor der Beantwortungszeit bereits Einsicht in die Fragen haben. Eine Umfrage kann drei Zustände einnehmen: kommend, laufend oder vergangen. Ein Autor kann durch Angabe eines Start- und Endzeitpunkt oder durch manuelles Starten und Beenden den Status einer Umfrage bestimmen. In den verschiedenen Status gibt es dabei verschiedene Funktionen für die Teilnehmer. Für kommende und vergangene Umfragen handelt es sich dabei vor allem um lesende Funktionen, wie die Einsicht der Fragen und Antwortmöglichkeiten oder der Ergebnisse. Laufende Umfragen hingegen bieten auch die Möglichkeit, dass Teilnehmer einzelne Fragen beantworten können. Aus Autorensicht können Umfragen im vollen Umfang lediglich im kommenden Zustand bearbeitet werden. Umfragen im laufenden Zustand können abhängig der einzelnen Status der Fragen bearbeitet werden und Umfragen, die bereits beendet wurden, bieten nur eingeschränkte Bearbeitungsmöglichkeiten. Wie bereits erwähnt, gehören zu einer Umfrage mehrere Fragen, die ihrerseits den Status kommend, laufend oder vergangen einnehmen können. Kommende und vergangene Fragen können von Teilnehmern lesend eingesehen werden, während laufende Fragen die Möglichkeit zum Abgeben einer Antwort bieten. Autoren können lediglich kommende Fragen bearbeiten. So wird sichergestellt, dass bereits gestellte Fragestellungen nicht verändert werden können und die Ergebnisse verfälscht werden. Eine Frage erhält beim Erstellen einen Frage-Typ. Die in Tabelle 2.1 aufgelisteten Frage-Typen Single-Choice, Multiple-Choice, Freitext, Begriff, Slider, Schätzen, Datum, Foto und Standort sind im Rahmen dieser Arbeit erarbeitet worden. Für die Frage-Typen Single- und Multiple-Choice stellt der Autor mehrere Antwortmöglichkeiten bereit. Weiterhin kann der Autor zu allen Fragen, außer vom Typ Freitext und Foto, eine oder mehrere richtige Antworten angegeben, sodass eine automatische Auswertung der Leistung der Teilnehmer durch das System ermöglicht wird. Ein Autor erhält nach dem Beenden einer Frage Einsicht in die Ergebnisse als Diagramm, dessen Gestalt vom Frage-Typ abhängt. Je nachdem, ob eine Umfrage anonym ausgewertet wird, erhält ein Autor auch Einsicht in die Antworten der einzelnen Teilnehmer. Falls richtige Antwortmöglichkeiten angegeben wurden, sind in der Darstellung der Ergebnisse Aussagen über richtige und falsche Abgaben einsehbar. Ein Teilnehmer kann eine ähnliche Auswertung einsehen, natürlich ohne eine Auflistung der Antworten der anderen Teilnehmer und er kann zusätzlich nachverfolgen, welche Antwort er selbst eingereicht hat. 15

23 2 Grundlagen 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 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. Ja 16

24 3 Anforderungen an das System 3 Anforderungen an das System Um den Aufwand für Planung und Implementierung einschätzen zu können, ist eine genaue Analyse der Anforderung an das System notwendig. Die Analyse muss umfassend und detailliert genug sein, sodass es keine Missverständnisse oder Interpretationsmöglichkeiten während der Entwicklung gibt. Eine gute Analyse ist der Grundstein für ein realistisches Zeitmanagement und - in großen Projekten - für eine realistische Kosteneinschätzung. [6] In diesem Abschnitt werden aus diesem Grund alle Anforderungen an die Mainzel-App und das gesamte System detailliert beschrieben, wobei zwischen funktionalen und nicht-funktionalen Anforderungen unterschieden wird. Weiterhin wird das Use Case Diagramm der App anhand einiger beispielhafter Use Cases erläutert. 3.1 Funktionale Anforderung Funktionale Anforderungen beschreiben die Funktionalität des Systems. Analysiert wird, was das System leisten soll und welche Interaktionen mit dem Benutzer zur Verfügung stehen sollen. Hierbei gibt es die Muss-Kriterien, das heißt Kriterien, die auf jeden Fall umgesetzt werden müssen. Sie beschreiben vor allem für den Einsatz des Systems essentielle Funktionen. Weiterhin formuliert man die Kann-Kriterien, die umgesetzt werden, wenn es die Ressourcen des Projekts zulassen und die nicht die Einsatzfähigkeit des Systems beeinträchtigen, wenn sie nicht umgesetzt werden können. [6] Muss-Kriterien Benutzerbereich F010: Die App muss einem Benutzer ermöglichen sich mit seiner -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 Umfrageverwaltung F060: Die App muss nach dem Öffnen die wichtigsten Informationen zu den laufenden Umfragen in einer Ansicht zusammenstellen. F070: Die App muss auch eine Übersicht mit den wichtigsten Informationen zu den kommenden und den vergangenen Umfragen bereitstellen. F080: Die App muss eine Detailansicht mit allen Informationen zu jeder Umfrage anbieten, die sich dem Status der Umfrage und der Rolle des Benutzers anpasst (Vorschau bei kommenden Umfragen, Fragen beantworten bei laufenden Umfragen, Ergebnisdarstellung bei vergangenen Umfragen). 17

25 3 Anforderungen an das System F090: Die App muss das Editieren von allen Informationen einer Umfrage durch einen Autor ermöglichen. F100: Die App muss das Löschen einer Umfrage durch den Umfrageadministrator ermöglichen. F110: Die App muss einem Autor die Möglichkeit geben die Vorschau für die Teilnehmer für jede Frage einzeln abzuschalten. F120: Die App muss einem Autor die Möglichkeit bieten, eine Frage anonym zu stellen. F130: Die App muss einem Autor die Möglichkeit bieten, die Enthaltungsoption für eine Frage einzuschalten. F140: Die App muss es einem Autor ermöglichen, eine Umfrage wieder zu verwenden. F150: Die App muss die Funktion anbieten, eine vergangene Frage in einer geschlossenen Umfrage erneut zu öffnen, sodass weitere Antworten abgegeben werden können. F160: Die App muss bereits bekannte andere Benutzer beim Hinzufügen von Autoren oder Teilnehmern zu Umfragen zur Auswahl stellen. F170: Die App muss den Benutzer darauf aufmerksam machen, wenn er zu neuen Umfragen eingeladen ist 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 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 Kann-Kriterien F270: Die App kann eine Über Uns -Ansicht bereitstellen. F280: Die App kann die Ergebnisdarstellung für einen Autor live aktualisieren. 18

26 3 Anforderungen an das System F290: Die App kann eine Schnittstelle zum Übertragen der Ergebnisdarstellung in eine Microsoft Powerpoint-Präsentation bereitstellen. F300: Die App kann eine Funktion zum Umstellen der Sprache auf Englisch enthalten. 3.2 Nicht-funktionale Anforderungen Die Nichtfunktionalen Anforderungen an das System beschreiben Rahmenbedingungen und Einschränkungen, die das System befolgen soll. Diese Anforderungen können Einfluss auf die gesamte Softwarearchitektur nehmen. Auch hier werden die Anforderungen in Muss- und in Kann- Kriterien aufgeteilt. [6] 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 Kann-Kriterien NF050: Die App kann in Google-Play zur Verfügung gestellt werden. 3.3 Use Case Diagramm Ein Use Case Diagramm zeigt anschaulich alle Situationen auf, die beim regulären Benutzen eines Systems auftreten. In Abbildung 3.1 ist das Use Case Diagramm der Mainzel-App dargestellt. Es hilft die Funktionalität der App besser zu erfassen. Die Anwendungsfälle werden allerdings nur sehr einfach dargestellt. Für ein besseres Verständnis der Zusammenhänge werden daher im weiteren Verlauf dieses Kapitels ausgewählte Anwendungsfälle näher erläutert. [6] In Abbildung 3.1 ist zu sehen, wie die Benutzer in ihren verschiedenen Rollen auf die Umfragen und die App im Ganzen auf unterschiedliche Weise einwirken. Dabei hat ein allgemeiner Benutzer die meisten Belange an das System. Unabhängig von seiner Rolle möchte er beispielsweise den Überblick über alle Umfragen oder die Details einer bestimmten Umfrage einsehen. Weiterhin kann es vorkommen, dass er Änderungen an seinem Account vornehmen möchte oder diesen ganz aus dem System löschen muss. Als Teilnehmer einer Umfrage geht er in der Regel zwei Aktionen nach: Er beantwortet regelmäßig die Fragen der Umfragen, an denen er teilnimmt oder nimmt Einladungen zu weiteren Umfragen an. Als Autor von Umfragen hingegen benötigt der Benutzer die Möglichkeit, die Umfragen zu bearbeiten und sie starten oder stoppen zu können. Und schließlich hat jeder Benutzer als Umfrage-Administrator die Möglichkeit eigene Umfragen zu erstellen und diese auch wieder zu löschen. 19

27 3 Anforderungen an das System Abbildung 3.1: Use-Case Diagramm - Die Akteure, die auf das Mainzel-System Einfluss nehmen, sind die Benutzer. Es gibt Benutzer, die die Autoren-Rolle einer Umfrage einnehmen und andere, die als Teilnehmer involviert sind. Jede Umfrage hat außerdem einen Administrator. Er hat diese erstellt und ist somit selbst ein Autor. Nur der Administrator kann die Umfrage auch wieder löschen. 3.4 Use Cases Im Folgenden werden ausgewählte Use Cases aus dem Diagramm näher erläutert. Use Cases oder Anwendungsfälle beschreiben ein Szenario, in dem ein Benutzer Erwartungen an das System stellt und mit ihm interagiert. Primär wurde ein Tabellenformat zur Darstellung der Anwendungsfälle gewählt, um sie in eine schnell erfassbare Form zu bringen und ihre Vergleichbarkeit zu erhöhen. Auf diese Weise wurde für jeden Use Case eine Art Steckbrief erstellt, der eine detaillierte Beschreibung bereit hält und über die beteiligten Akteure, die Bedingungen zum Eintreten des Use Cases, das auslösende Ereignis und die nachfolgenden Bedingungen informiert. Weiterhin wird eine Komplexitätseinschätzung gemacht, die für diese Arbeit lediglich auf dem geschätzten Zeitaufwand der Implementierung basiert. In größeren Projekten wirken weitere Faktoren wie die Kosten auf diese Einschätzung ein. Schließlich wird eine Priorisierung vorgenommen, um anzugeben, welche Use Cases für einen Prototyp des Systems unabdingbar sind. Außerdem wird jeder Use Case in einer kurzen textuellen Beschreibung erläutert und dabei die jeweilige Skizze der grafischen Benutzeroberfläche mit einbezogen. Sie wurden erstellt, um den jeweiligen Use Case aus Sicht des Benutzers zu veranschaulichen. Es wurden nicht alle Use Cases behandelt, da auf sie in anderer Form in Kapitel 4 im Rahmen der Darstellung von Planung und Design des Systems eingegangen wird. Alle nicht angesprochenen Use Cases können in Anhang A eingesehen werden. [6] Zunächst ist wohl einer der wichtigsten Anwendungsfälle die Möglichkeit, dass Teilnehmer eine Frage beantworten können. Wie in Use Case #05 beschrieben, betrifft dieser Anwendungsfall 20

28 3 Anforderungen an das System einzig die Teilnehmer, die zuvor in das System eingeloggt sein müssen. Zu jeder laufenden Frage gibt es, wie in Abbildung 3.2 zu sehen ist, eine Ansicht, die an den Frage-Typ angepasst ist. Use Case 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 s 9 zum Beantworten der verschiedenen Frage-Typen sind komplex. Die Eintragungen in die Datenbank sind einfach. Priorität Hoch: Das Beantworten von Fragen ist ein essentieller Use-Case. GUI Abbildung 3.2 Tabelle 3.1: Use Case #05 Nachdem der Teilnehmer seine Antwort abgeschickt hat, muss sie vom System in die globale Datenbank eingetragen werden, sodass die Geräte der anderen beteiligten Benutzer diese Information auslesen können. Das Umsetzen dieses Anwendungsfalles im System ist sehr wichtig, da es sich um eine essentielle Funktion handelt. Gleichzeitig ist das Umsetzen aber auch zeitaufwendig, da für jeden Frage-Typ eine eigene Ansicht implementiert werden muss. 9 Graphical User Interface (GUI), engl. für grafische Benutzeroberfläche. 21

29 3 Anforderungen an das System Abbildung 3.2: Benutzeroberfläche zum Beantworten einer Frage - Der Benutzer sieht verschiedene Ansichten für die verschiedenen Frage-Typen. Dargestellt sind die bisher geplanten Frage-Typen. 22

30 3 Anforderungen an das System Das Einsehen der Umfragedetails, um sich als Autor oder als Teilnehmer über Inhalt, Startzeitpunkt, Fragen oder Ähnliches informieren zu können, ist ein weiterer wichtiger Anwendungsfall. Dieser ist in Use Case #06a beschrieben. Auch hierfür muss der Teilnehmer oder der Autor einer Umfrage im System eingeloggt sein. Er öffnet die Detailansicht mit Klick auf den Listeneintrag der jeweiligen Umfrage in der Umfrage-Übersicht. Use Case 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. 23

31 3 Anforderungen an das System Abbildung 3.3: Detailansicht von Umfragen - Dargestellt ist die Ansicht für Teilnehmer, die eine Auswertung der Richtigkeit der Antworten von vergangenen Fragen beinhaltet. Die Autoren und Administratoren der Umfrage sehen dieselbe Ansicht, nur vergangene Fragen haben keinen Indikator für richtig oder falsch. Eine weitere essentielle Funktion der App ist das Einloggen, um den Zugang für registrierte Benutzer zu gewährleisten. Use Case #09a beschreibt diesen Anwendungsfall. Loggt sich ein Benutzer in die App ein, wird der Zeitstempel seiner letzten Aktivität in der globalen Datenbank aktualisiert. Außerdem wird die Synchronisation der lokalen mit der globalen Datenbank eingeleitet und der Benutzer gelangt auf die Übersicht über all seiner Umfragen. Use Case Einloggen ID #09a Beschreibung Der Benutzer loggt sich im System ein und hat Zugriff auf alle Funktionen. Beteiligte Akteure Benutzer Vorbedingung Der Benutzer muss registriert und ausgeloggt sein, um sich einloggen zu können. Trigger Zum Einloggen gibt der Benutzer seine -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 24

32 3 Anforderungen an das System Die Implementation der Ansicht, wie sie in Abbildung 3.4 dargestellt wird, ist wegen der wenigen UI-Elemente wenig komplex, jedoch ist die Kommunikation mit der globalen Datenbank, vor allem für die Synchronisation, aufwendig, weshalb dieser Anwendungsfall als zeitaufwendig eingeschätzt wird. Abbildung 3.4: Benutzeroberfläche zum Einloggen in die App. Schließlich muss jeder Benutzer die Einladungen zu einer Umfrage zunächst annehmen können, um daran teilzunehmen. Daher ist der in Use Case #13 beschriebene Anwendungsfall ebenfalls sehr wichtig für das System. Um eine Einladung zu einer Umfrage annehmen zu können, muss der Benutzer zunächst eingeloggt sein und außerdem zuvor von einem Autor der Umfrage eingeladen worden sein. In der in Abbildung 3.5 dargestellten Skizze der App findet der Benutzer eine Auflistung über alle Einladungen und kann eine bestimmte mit Klick auf den Daumen hoch -Button annehmen. Daraufhin wird in der globalen Datenbank eingetragen, dass der Benutzer von nun an Teilnehmer der Umfrage ist und die Daten werden in die lokale Datenbank des Benutzers synchronisiert. 25

33 3 Anforderungen an das System Use Case Einladungen zu Umfragen annehmen ID #13 Beschreibung Ein Benutzer wird von anderen Benutzern zu Umfragen eingeladen, um an diesen Umfragen teilzunehmen. Beteiligte Akteure Benutzer Vorbedingung Der Benutzer ist eingeloggt und wurde von einem anderen Benutzer zu einer Umfrage eingeladen. Trigger Der Benutzer klickt auf Annehmen. Nachbedingung Der Benutzer ist nun Teilnehmer an der Umfrage, deren Einladung er gerade angenommen hat. Komplexität Niedrig: Sowohl die GUI als auch die Kommunikation mit der Datenbank sind wenig komplex. Priorität Hoch: essentielle Funktion der App. GUI Abbildung 3.5 Tabelle 3.4: Use Case #13 Sowohl die Implementierung der benötigten UI-Elemente, als auch der Datenbankkommunikation ist wenig komplex und wird daher nicht als zeitaufwendig eingeschätzt. Abbildung 3.5: Benutzeroberfläche zum Einsehen der Einladungen - Mit Klick auf den "Daumen hoch"-button kann der Benutzer die Einladung zu den Umfragen annehmen. 26

34 4 Planung und Design 4 Planung und Design Dieses Kapitel erläutert den Prozess der Planung und des Designs des Mainzel-Systems aus verschiedenen Blickwinkeln. Betrachtet werden zunächst die Architektur des Systems, darauffolgend das Design der Benutzeroberfläche der App und zum Schluss die beiden Datenbanken. 4.1 Systemarchitektur Die Planung der Systemarchitektur wird durch zwei Hauptmerkmale beeinflusst. Zum Ersten soll jede Komponente im System alle benötigten Informationen erreichen und weitergeben können. Zum Zweiten soll das System gegen Gefahren von außen bestmöglich abgesichert werden. In diesem Abschnitt wird die Systemarchitektur von Mainzel unter der Berücksichtigung dieser zwei Punkte anhand von drei Abbildungen besprochen, die das System oder nur Teilsysteme in unterschiedlichen Detaildichten zeigen. Zunächst wird die globale Systemarchitektur mit allen Komponenten des Systems in Abbildung 4.1 besprochen. Danach wird eine erste Verfeinerung der Architektur in Abbildung 4.2 durchgenommen, die den Aufbau des Teilsystems auf einem Android- Gerät zeigt. Schließlich wird mit Hilfe von Abbildung 4.3 die Kommunikation innerhalb der Mainzel-App veranschaulicht Globale Systemarchitektur Die globale Systemarchitektur von Mainzel lässt sich als Client-Server-Architektur, wie in Abbildung 4.1 zu sehen ist, darstellen. Dieses Design-Pattern wird häufig zur Erstellung von Systemarchitekturen, die Datenzugriffe von unterschiedlichen Orten abbilden sollen, herangezogen. Im Mainzel-System stellt die auf einem Android-Gerät installierte App zusammen mit der lokalen Datenbank, die auf jedem Android-Gerät durch eine SQLite-Datenbank abgedeckt wird, einen Client dar. Im Späteren wird noch näher auf die Architektur eines Clients eingegangen. Abbildung 4.1: Globale Client-Server-Architektur von Mainzel - Mehrere Instanzen der Android-App stellen die Clients dar, die mit einem Server kommunizieren. Der Server stellt die Schnittstelle zur globalen Datenbank dar. Die Clients einer Client-Server-Architektur kommunizieren üblicherweise über Internetprotokolle mit einer Reihe von Servern, die für einen bestimmten Dienst bereitstehen. In Mainzel gibt es nur einen Dienst, nämlich die Aufbereitung der Datenbankinhalte und folglich gibt es nur einen Server im Architekturplan. Diese Seite setzt sich aus einem php-webservice und der globalen Datenbank, die auf einem MS-SQL Server umgesetzt wurde, zusammen. Auf die globale Datenbank haben somit alle Clients im System Zugriff, sodass hier alle Informationen, die im System produziert und 27

35 4 Planung und Design benötigt werden, zentral gelagert sind. Die SQLite-Datenbänke der Clients enthalten lediglich für den Benutzer des Clients interessante, schlankere Kopien der Datensätze der globalen Datenbank. Auf diese Verteilung wird in Abschnitt 4.3 weiter eingegangen. Der Webservice hingegen dient als Aufbereiter der Daten in der Datenbank und hat die Fähigkeit mit dieser über SQL-Anfragen zu kommunizieren. Er erhält für die verwendete php-extension, die in Kapitel angesprochen wird, typische php statement resources. Die Werte aus der Datenbank codiert der Webservice im JSON-Format, auf das in Kapitel 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 Architektur eines Mainzel-Clients Zu der Systemarchitektur eines Clients im Mainzel-System gehören sowohl Komponenten, die in der App selbst implementiert sind, als auch die lokalen Speichermöglichkeiten. In Abbildung 4.2 sind alle Komponenten eines Clients in einem Schichtenmodell dargestellt. Üblicherweise werden die Schichten in einem Schichtenmodel übereinander gezeigt. In dieser Abbildung sind die Schichten aus Platzgründen und um die Orientierung zur vorherigen Abbildung beizubehalten, nebeneinander aufgereiht. Die Datenschicht ganz links stellt dabei die unterste Schicht dar, darauf folgt die Anwendungsschicht in der Mitte und schließlich stellt die Schnittstelle ganz rechts die oberste Schicht im Schichtenmodell dar. [6] Die Datenschicht setzt sich aus zwei Speichern zusammen, nämlich der bereits angesprochenen lokalen Datenbank des Clients und einer Menge an Konfigurationsdaten. Die Konfigurationsdaten enthalten die Informationen des Benutzers des Clients, sodass sie für alle Komponenten direkt zugänglich und unabhängig vom Stand der lokalen Datenbank sind. In der Abbildung wurden die Kommunikationswege zwischen den Konfigurationen und allen anderen Komponenten außer der Login-Komponente, die die Konfigurationen schreibt und liest, im Sinne der Übersicht weggelassen. Die lokale Datenbank ist, wie weiter oben erwähnt, ein abgespecktes Abbild der globalen Datenbank, die alle Daten enthält, die für den Benutzer interessant sind. Die Anwendungsschicht beinhaltet alle Implementationen der App, die zur Darstellung und Verarbeitung der Daten vorgesehen sind. Sie erhält alle Daten aus der lokalen Datenbank über die Klasse LocalDatabaseHelper (Helper). Diese nimmt, ähnlich wie der php-webservice, 28

36 4 Planung und Design vordefinierte Anfragen an, stellt die dazugehörigen SQL-Anfragen an die SQLite-Datenbank und erhält gegebenenfalls einen Android-spezifischen Cursor zurück. Ein Cursor kann als Zeiger auf die ausgewählten Daten angesehen werden. Die Werte auf die der Cursor zeigt, wandelt der Helper in geeignete Datentypen um und gibt die Information in dieser Form an die Anfrageschicht zurück. Abbildung 4.2: Architektur eines Clients im Schichten-Model - Ein Client teilt sich in drei Schichten auf. Dazu zählen die Datenschicht, die Anwendungsschicht und die Schnittstelle zum Server. Jede Schicht kommuniziert mit den benachbarten Schichten und sichert so den Datenfluss im Client selbst und mit dem ganzen System. Im Detail bekommt beispielsweise die Komponente der App, die für die Verwaltung der Einladungen zu Umfragen zuständig ist, alle aktuell vorliegenden Daten zu ausstehenden Einladungen. Falls der Benutzer eine Einladung bestätigt, gibt die Komponente diese Bestätigung unter anderem an die lokale Datenbank weiter. Einige Komponenten haben nur die Aufgabe 29

37 4 Planung und Design Informationen darzustellen, wie die Übersicht über alle Umfragen, in die der Benutzer involviert ist. Auch diese Komponenten bekommen ihre Werte vom Helper, liefern allerdings keine Informationen zurück. Die Anwendungsschicht kann ebenfalls mit der darüber liegenden Schicht, die lediglich aus der Schnittstelle zum Server besteht, kommunizieren. Die Schnittstelle ist eine ähnliche Klasse wie der LocalDatabaseHelper und heißt DBAccess. Sie stellt Methoden für alle Anfragen, die der Webservice annimmt, zur Verfügung, bereitet die POST-Anfragen an diesen vor und dekodiert die in JSON verpackten Antworten des Webservices. Erhält die Einladungen-Komponente beispielsweise eine Antwort auf eine offene Einladung, schickt sie die Antwort nicht nur an die lokale Datenbank, sondern ruft auch die passende Methode der DBAccess-Klasse auf. Es gibt lediglich eine Verbindung, die nicht den Prinzipien eines Schichtenmodells folgt, die besagen, dass es keine Kommunikation zwischen Schichten gibt, die nicht benachbart sind. [6] Die Synchronisation der lokalen mit der globalen Datenbank wird zwar von der Anwendungsschicht angestoßen, sobald es notwendig ist, sie wird allerdings durch eine direkte Kommunikation zwischen Helper und DBAccess realisiert, in der der Helper wie eine Komponente der Anwendungsschicht agiert und eine passende Methode in der DBAccess-Klasse aufruft. In diesem Fall verwischen in einem Mainzel-Client die klaren Strukturen eines Schichtenmodells. An den zahlreichen, eindeutigen Kommunikationswegen zwischen den Schichten erkennt man den Grundgedanken hinter dem Design der Architektur eines Mainzel-Clients. Innerhalb des Clients ist es die Hauptaufgabe alle benötigten Daten an die richtigen Komponenten zu liefern und im Sinne eines begrenzten Arbeitsspeichers auf einem mobilen Endgerät keine unnötigen Daten zu versenden. Durch den Einsatz des LocalDatabaseHelpers ist, ähnlich wie bei dem 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 App-Architektur Die Komponenten der Anwendungsschicht in Abbildung 2 werden in Abbildung 3 noch einmal aus einer detaillierteren Perspektive gezeigt. Zu sehen sind die Kommunikationswege der Anwendungskomponenten untereinander. Ein unbekannter Benutzer wird zunächst durch die Login-Komponente registriert oder eingeloggt. Bekannte Benutzer erhalten sofort Zugang zum Überblick über die Umfragen, in die sie involviert sind. Die Überblick-Komponente wiederum kann durch Übergabe einer Umfrage-ID an die Umfrage-Detail-Komponente abgeben und diese wiederum durch Übergabe einer Umfrage- und einer Frage-ID an die Frage-Detail-Komponente. Alle Komponenten außer der Login-Komponente können mit dem Umfrage-Editor kommunizieren und dabei optional eine Umfrage-ID weitergeben. Ohne Umfrage-ID bereitet der Umfragen-Editor eine neu zu erstellende Umfrage vor. Im Falle einer Übergabe, lädt er alle Informationen zum Editieren. Weiterhin können alle Komponenten den Benutzer zur Komponente zum Verwalten der Einladungen und des eigenen Accounts weiterleiten. 30

38 4 Planung und Design Diese Teilarchitektur lehnt stark an den Erwartungen des Benutzers an, auf schnellem Weg durch die App zu navigieren und es wurde vor allem Wert auf die richtige und effiziente Verteilung der Informationen gelegt. Das ganze Design ist darauf ausgelegt, die Benutzerfreundlichkeit hoch zu halten. Sicherheit spielt innerhalb der Komponenten der App eine nebensächliche Rolle, da die Kommunikationswege von außen nicht angreifbar sind. Abbildung 4.3: Vereinfachte Architektur der Mainzel-App - Die flachen Hierarchien der Mainzel-App ermöglichen diese vereinfachte Darstellung der App-Architektur. Gezeigt werden die Hauptkomponenten und ihre Kommunikationswege. Einige Komponenten übergeben einander Informationen. In diesen Fällen wurde der zurückzeigende Pfeil zur Vereinfachung weggelassen. Dennoch ist auch hier die Kommunikation in die entgegengesetzte Richtung, wie auf allen Kommunikationswegen in dieser Abbildung, möglich. Die Informationen auf den Kommunikationswegen zum 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. 31

39 4 Planung und Design Der Aufbau der Mainzel-Ansicht nach diesem Prinzip folgt somit dem gewohnten Design einer App, sodass Benutzer sich schnell zurechtfinden können. In Abbildung 4.4 ist die Ansicht gezeigt, die ein Benutzer nach dem Starten der App erhält, sofern er sich in Mainzel bereits einmal auf dem mobilen Gerät eingeloggt hat. Auf den Inhalt und den Zweck dieser Ansicht wird später näher eingegangen. Hier soll der Fokus auf die einzelnen Bereiche der Ansicht gelegt werden. Am oberen Bildschirmrand ist wie bei den meisten Apps die Android Notification-Area zu sehen, die nicht Teil der entwickelten App ist. Sie hat die Aufgabe den Benutzer über alles Wichtige im Android-System zu informieren. Hier wird beispielsweise die Uhrzeit angezeigt oder auf Verbindungsprobleme hingewiesen. Jede App hat hier die Möglichkeit selbst Nachrichten, genauer die weiter oben erwähnten Notifications, anzuzeigen, die den Benutzer erreichen, auch wenn die App gerade nicht geöffnet ist. In Mainzel ist es vorgesehen, dass der Benutzer auf diese Weise informiert wird, dass es eine neue Frage zum Beantworten gibt. Abbildung 4.4: Umfrage-Übersicht - Nach dem Starten der App wird der bekannte Benutzer direkt auf diese Umfrage- Übersicht geleitet, damit er alle wichtigen Informationen auf den ersten Blick einsehen kann. Unter der Notification-Area zeigt Mainzel die sogenannte Actionbar der App. Hier wird das Logo von Mainzel gezeigt und eine Überschrift gibt Hinweis auf den betrachteten Inhalt. Am rechten Rand der Actionbar findet der Benutzer alle Funktionen und Navigationslinks, die für die jeweilige Ansicht zur Verfügung stehen. Dabei sind die Wichtigsten direkt anklickbar, während nicht häufig gebrauchte Punkte hinter dem zusammenfassenden Action overflow -Button, der in Abbildung 4.4 in der Actionbar ganz rechts zu sehen ist, verschwinden. Bei Android-Geräten, die einen physikalischen Actionbutton haben, taucht der simulierte Button aus Abbildung 4.4 nicht auf. Unter der Actionbar von Mainzel wird als größter Abschnitt auf dem Bildschirm der Inhalt einer Ansicht angezeigt. Der Aufbau dieser hängt stark von der Aufgabe der Komponente, zu der die 32

40 4 Planung und Design Ansicht gehört, ab. Die Aufgaben, die Ansicht und die Stellung der einzelnen Komponenten innerhalb der Hierarchie der App werden im Folgenden im Detail erklärt. Abbildung 4.5: Frontend-Komponenten der App - Die Struktur des Frontends lehnt sehr stark an der Systemarchitektur der App an und wurde durch die Richtlinien der Android Entwicklerdokumentation [7] beeinflusst. Android Developers [7] schlägt vor die Struktur einer App in Top Level - und Detail/Edit - Ansichten einzuteilen. Falls eine weitere Hierarchiestufe dazwischen benötigt wird, wird diese als eine Kategorie-Ansicht betrachtet. Mit diesem Hintergrund und unter Einbeziehung der 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 33

41 4 Planung und Design vergangenen Umfragen und mit einem Swipe nach rechts eine Übersicht über alle kommenden Umfragen gezeigt. Diese Übersicht ist in Abbildung 4.4 skizziert worden. Durch einen Klick auf eine Umfrage wechselt der Benutzer zur nächst unteren Hierarchie, einer Kategorie-Ansicht, die die Details einer Umfrage zeigt. Hier wird neben allen Informationen, die die Umfrage betreffen, auch eine der Umfrage-Übersicht ähnliche Liste der Fragen angezeigt. Mit einem Klick auf eine Frage gelangt der Benutzer auf die unterste Ebene der Hierarchie, in die Detailansicht der Frage. Eine solche Ansicht wurde in Abbildung 4.6 skizziert. Abhängig vom Satus der Frage lässt sie sich beantworten, Diagramme, die die Abgaben auswerten stehen zur Verfügung oder der Benutzer kann sie nur einsehen. Abbildung 4.6: Detailansicht einer Frage - Die linke Abbildung zeigt eine laufende Single-Choice Frage, zu der noch eine Antwort durch den Benutzer abgegeben werden muss. Die rechte Abbildung stellt eine vergangene Schätz-Frage, die auch ein Diagramm zur Ansicht der allgemeinen Ergebnisse anbietet, dar. Die Strukturierung des Frontends in Abbildung 4.5 zeigt weiterhin, dass der Benutzer die hierarchieübergreifenden Ansichten zum Einsehen und Bearbeiten des eigenen Accounts und zum Beantworten der Einladungen von allen Komponenten, außer der Login-Komponente, erreichen kann. Zu beiden Ansichten kann durch Auswählen des jeweiligen Navigationspunktes in der Actionbar von Mainzel navigiert werden. Auch der Editor zum Erstellen von Umfragen steht von überall in der App zur Verfügung. Innerhalb der Detailansicht einer Umfrage oder einer Frage, kann der Benutzer zwischen dem Bearbeiten und dem neuen Anlegen einer Umfrage in der Actionbar wählen, wobei bei der Bearbeitung alle Daten der ausgewählten Umfrage in den Editor geladen werden. Abbildung 4.7 zeigt eine Skizze des Editors. Um alle Eintragungen für eine Umfrage tätigen zu können, muss der Benutzer durch die Ansicht scrollen. Beim Erstellen einer neuen Frage erweitert sich das Formular abhängig vom 34

42 4 Planung und Design ausgewählten Frage-Typ, damit alle charakteristischen Attribute eines Fragetyps angegeben werden können. Abbildung 4.7: Umfragen-Editor - In dieser Ansicht kann der Benutzer alle Änderungen an einer Umfrage vornehmen oder eine neue erstellen. Das Formular des Editors ist zu lang für die Ansicht auf einer Bildschirmlänge eines 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. 35

43 4 Planung und Design 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 -Adresse, nicht aber seine ID, gelöscht werden. Das ist aus dem Grund nicht möglich, da bereits seine Antworten in die Auswertung von Umfragen eingegangen ist und diese nicht mehr verfälscht werden sollen. Das Löschen seiner persönlichen Daten führt zur Anonymisierung seiner Antworten. Liest ein Client während der Synchronisation, die in Abschnitt 36

44 4 Planung und Design 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 Lokale SQLite-Datenbank Das in Abbildung 4.9 gezeigte Diagramm der lokalen Datenbank eines Clients von Mainzel ähnelt sehr stark dem Diagramm der globalen Datenbank und weist beispielsweise dieselben Tabellen 37

45 4 Planung und Design auf. Hier werden ebenfalls die genannten Basisdaten zu Benutzern, Umfragen, Fragen, Antworten und der Zuordnung zwischen Benutzern und Umfragen gespeichert. Abbildung 4.9: Diagramm der lokalen Datenbank - Die lokale Datenbank eines Mainzel-Clients weist dieselben Tabellen wie die globale Datenbank auf. Sie unterscheidet sich allerdings erheblich in ihren Attributen. Da die Programmierbarkeit von Funktionen, Prozeduren und Triggern in einer SQLite-Datenbank fehlt, werden hier fast alle Werte bei der Synchronisation aus der globalen Datenbank kopiert und danach meist nicht mehr von der App verändert. Ein Versionsattribut wie in der globalen Datenbank, ist daher für keine Tabelle nötig und alle Daten der lokalen Datenbank können als Kopien angesehen werden, die nicht vom Client gepflegt werden müssen, sondern immer nach der Synchronisation mit der globalen Datenbank automatisch auf den aktuellen Stand gebracht werden. Es gibt allerdings ein Feld, das in der globalen Datenbank nicht existiert und vom Client selbst aktualisiert wird. Das NotAnswered-Attribut der Survey-Tabelle zählt individuell für den Benutzer des Clients für jede Umfrage, in der er Teilnehmer ist, die Anzahl der unbeantworteten Fragen mit, damit die App ihn auf diese Weise schnell und an verschiedenen Orten in der App darauf 38

46 4 Planung und Design hinweisen kann. Der Wert des Attributs erhöht sich, wenn eine neue Frage zur Beantwortung bereit steht und löst bei geschlossener App beispielsweise eine Notification aus, die den Benutzer darüber informiert. Sobald eine Frage beantwortet wurde, wird der NotAnswered-Wert um eins verringern 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 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 XML-Datentypen Die meisten Attribute, die die erwähnten Basisinformationen enthalten sind durch die Kombination von Namen und Datentyp selbsterklärend. Lediglich bei den beiden Attributen AnswerXML und ResultXML vom Typ xml in der Answer- und der Result-Tabelle kann nicht direkt vom Datentyp auf die Gestalt des Inhalts geschlossen werden. Hier werden speziell für Mainzel definierte XML-Daten erwartet, die von der App ausgelesen werden können. Die Wurzel eines AnswerXML-Wertes gibt dabei Aufschluss über den Frage-Typ der Frage, welcher der Wert zugeordnet ist. Der Wurzel folgen vom Frage-Typ abhängige Attribute und weitere Elemente. In Quellcode 4.1 ist ein Beispiel für eine Single-Choice-Frage dargestellt. Wie zu sehen ist, enthält ein typischer AnswerXML-Wert einer Single-Choice-Frage mehrere option-elemente, die jeweils die Nummer der Option als Attribut angeben. Die richtige Option erhält außerdem den Wert true im Attribut correct. Zusätzlich hat jedes Element ein Attribut namens counter. Es gibt die Anzahl der Teilnehmer an, die die jeweilige Antwortmöglichkeit gewählt haben. 39

47 4 Planung und Design <singlechoice> <option nr="0" correct="true" counter="2">option 0</option> <option nr="1" counter="6">option 1</option> <option nr="2" counter="1">option 2</option> <option nr="3" counter="2">option 3</option> <abstentions>3</abstentions> </singlechoice> Quellcode 4.1: Beispiel für ein AnswerXML-Wert einer Single-Choice-Frage - Die option-elemente innerhalb des Wurzelelements geben Aufschluss über zur Verfügung stehenden Antwortmöglichkeiten. Eine Schätz-Frage wiederum, zu der ein Beispiel in Quellcode 4.2 angegeben wurde, speichert Elemente zur Anzahl der Vorkommastellen (digits), der Anzahl der Nachkommastellen (fractional), der Einheit der Antworten (unit) und welcher Wert korrekt ist (correct). Weiterhin gibt es das Element results, das für alle eingereichten Antwortmöglichkeiten die Anzahl der Teilnehmer, die sie gewählt haben, angibt. Sowohl dieser Teil einer Schätz-Frage als auch das counter-attribut der Antwortmöglichkeiten von Single-Choice-Fragen stellen die Werte für die Überblicksdiagramme der Antworten der einzelnen Fragen zur Verfügung. Auf diese Weise ist gewährleistet, dass alle an einer Umfrage beteiligten, auch die Teilnehmer-Clients ein solches Diagramm darstellen können, ohne dass alle Result-Tabelleneinträge herunter geladen werden müssen. Die Einträge werden mit Hilfe eines Triggers, der auf Veränderungen in der Result-Tabelle reagiert, auf dem SQL-Server bearbeitet. <estimation> <digits>3</digits> <fractional>2</fractional> <unit>cm</unit> <correct>2.00</correct> <results> <result counter="5">2.00</result> <result counter="2">3.14</result> <result counter="4">1.74</result> </results> <abstentions>3</abstentions> </estimation> Quellcode 4.2: Beispiel für ein AnswerXML-Wert einer Schätzfrage - Es gibt Elemente mit Angaben zur Gestalt der Antworten, der richtigen Antwort und den eingereichten Antworten. Auch das Wurzelelement eines ResultXML-Wertes gibt Aufschluss über den Typ der Frage, zu der der Result-Tabelleneintrag gehört. Das Beispiel für eine Datum-Frage (Wurzelelement date ) in Quellcode 4.3 zeigt, dass das abgegebene Datum als Inhalt des Wurzelelements gespeichert wird, während die Antwort auf eine Position-Frage (Wurzelelement position ) wesentlich komplexer ist. Hier ist jeweils ein Element für den Längen-und den Breitengrad der Antwort eingetragen, die jeweils Attribute mit Angaben zur Richtung, Minute und Sekunde besitzen. 40

48 4 Planung und Design <date> </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. 41

49 5 Entwicklung 5 Entwicklung Zur Entwicklung von Mainzel gehört sowohl die Programmierung der App mit allen ihren Funktionen als auch eine vorherige gründliche Durchleuchtung aller Anforderungen und wie sie umgesetzt werden sollen. Für beide Schritte wurden einige Werkzeuge benutzt, die das Planen und Programmieren erleichtert und beschleunigt haben. Weiterhin wurden verschiedene Technologien benötigt, die das Umsetzen der Funktionalität im System erst ermöglichen. In diesem Kapitel werden diese Werkzeuge und Technologien vorgestellt. Im Anschluss wird die Software selbst besprochen und daran aufgezeigt, wie die eingesetzten Technologien, diese beeinflusst haben. 5.1 Entwicklungssoftware In der Planungsphase des Mainzel-Systems wurden zunächst bildbearbeitende und diagrammerstellende Software benötigt. Für die Entwicklung wurden daraufhin eine klassische Entwicklungsumgebung und ein Datenbankmanagementsystem (DBMS) eingesetzt, die in den folgenden Abschnitten vorgestellt werden 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 Wireframing 10 -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] 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] 42

50 5 Entwicklung draw.io basiert auf der JavaScript Bibliothek mxgraph und wird als Beispiel-Anwendung für diese Bibliothek von den Herstellern beworben. [9] 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 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 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 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 43

51 5 Entwicklung einer Entwicklungsumgebung aufgebaut ist, lässt Verbindungen zu mehreren Datenbanken auf unterschiedlichen SQL-Servern gleichzeitig zu, die in einem Objekt-Explorer wie ein Datei-System angezeigt werden. Tabellen, Datensätze, Funktionen, Prozeduren oder Trigger können in einem SQL-Editor erstellt und bearbeitet werden, der auch alle SELECT-Anfragen auswertet und das Ergebnis in einer Tabelle darstellt. Auch eine grafische Darstellung der Tabelleneigenschaften ist möglich, die Änderungen und Erweiterungen an den Tabellen zulässt. Weiterhin können die Tabellen und Beziehungen zwischen diesen innerhalb der Datenbank in einem Datenbankdiagramm dargestellt werden, über das man ebenfalls Änderungen an den Tabellen vornehmen kann. Das SQL Server Management Studio wurde während der Entwicklung von Mainzel hauptsächlich zum Implementieren der Tabellen, Funktionen, Prozeduren und Trigger mit Hilfe von SQL-Skripten genutzt. Aus diesem Grund können im Rahmen dieser Arbeit nur die Basis-Funktionen dieser mächtigen Software genannt werden. 5.2 Verwendete Technologien und Bibliotheken Neben der Entwicklungssoftware, die durch Alternativen hätten ersetzt werden können, kamen einige Technologien und Bibliotheken in der Entwicklung des Systems zum Einsatz, die erst die breite Funktionalität von Mainzel ermöglichen. Im Folgenden werden diese vorgestellt und dabei erklärt, welche Aufgaben sie im System umsetzen 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 behandelt 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 verwendet, was einem API Level 19 für die Bibliotheken entspricht. Das Android SDK ist Teil des in Kapitel beschriebenen ADT Bundles, kann aber auch einzeln von Android Developer heruntergeladen werden. [12] [13] 44

52 5 Entwicklung Um die Ansichten der Mainzel-App dynamisch mit Hilfe von sogenannten Fragmenten aufbauen zu können, wird neben den Standardbibliotheken des Android SDKs die Android Support 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] 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 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 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 Android Holo Colors Schließlich wurde ein weiteres Tool eingesetzt, das maßgeblich zum äußeren Erscheinungsbild der Mainzel-App beiträgt. In dem online Generator für Android-UI-Elemente Android Holo Colors 45

53 5 Entwicklung [15] ist es möglich alle im eigenen App verwendeten UI-Elemente farblich anzupassen und die benötigten Ressourcen-Dateien herunterzuladen. Diese können dann in das eigene Projekt eingebunden werden. Auf diese Weise wurde die standardmäßige hellblaue Farbe, die jedes Android-UI-Element auf seine eigene Weise einsetzt, durch das Rot des Mainzel-Logos ersetzt. Die Screenshots der App in Kapitel 6 zeigen einige Beispiel dafür. 5.3 Umsetzung der App mit Java, XML und den verwendeten Bibliotheken Wie bereits erwähnt haben die benutzten Technologien, die zum Teil frei gewählt werden konnten, wie die AChartEngine-Bibliothek oder der Android Holo Colors-Generator und zum Teil durch die Problemstellung vorgegeben waren, wie Java, XML und das Android SDK, die Entwicklung und das Endprodukt stark beeinflusst. Um einen Einblick in die Software selbst zu geben und aufzuzeigen, wie sich diese Einflüsse äußern, wird im Folgenden das Klassendiagramm von Mainzel besprochen und ein Überblick über die Rolle von XML-Dateien für die Ressourcen- Verwaltung von Mainzel gegeben 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 46

54 5 Entwicklung Endzeiten der Fragen von Umfragen, in denen der Benutzer als Teilnehmer involviert ist, überwacht. Sofern eine neue Frage gestartet wurde, schickt der Service eine Notification an den Benutzer, die darauf hinweist, dass es eine neue unbeantwortete Frage im Mainzel-System gibt. Außerdem aktualisiert dieser Service das in Kapitel 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 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 angesprochen werden, die Klassen AnswerXML und ResultXML erstellt. Sie bieten alle Methoden zum Auslesen und Bearbeiten der Werte innerhalb der XML-Daten an. Ein weiteres Beispiel sind die von der Android-Klasse Fragment und ListFragment abgeleiteten Klassen. Sie können als Teil, also als Fragment einer Activity, angesehen werden und besitzen ähnliche Möglichkeiten. Dennoch können sie nicht ohne eine Eltern-Activity zum Anzeigen von UI-Elementen verwendet werden. In der Mainzel-App kommen die Fragmente in den dynamisch auszutauschenden Teilen der Ansichten zum Einsatz. Beispielsweise müssen in der QuestionDetails -Activity, über die ein Benutzer eine Frage beantworten und deren Ergebnisse einsehen kann, je nach Typ und Status der Frage, Teile der Oberfläche ausgetauscht werden. Für die Darstellung des passenden Antwortformulars eines jeden Frage-Typs gibt es daher jeweils ein Fragment, das das Interface QuestionTypeFragment implementiert. In Abbildung 5.1 sind exemplarisch die beiden Fragmente für Multiple-Choice- und 48

55 5 Entwicklung Freitext-Fragen dargestellt, es gibt allerdings für jeden implementierten Frage-Typ ein eigenes Fragment, da diese Konstruktion frei erweiterbar ist. Fragmente wiederum, die die Klasse ListFragment erweitern, stellen Listen dar. In Mainzel wird beispielsweise der Überblick über alle Umfragen in der AllSurveysActivity in einem Listfragment umgesetzt. Um ein Listfragment einbinden zu können, muss die Eltern-Activity die erwähnte Klasse FragmentActivity erweitern. Im Falle der AllSurveysActivity wird außerdem noch vom Interface TabListener abgeleitet, das es ermöglicht mehrere Listen in Tabs aufzuteilen und die Interaktion des Benutzers mit den Tabs zu kontrollieren. Zum Befüllen einer Liste mit Daten aus der Datenbank wird eine Instanz der CursorAdapter -Klasse eingesetzt. Ein Cursor ist ein Zeiger auf eine Auswahl an Datenbankzeilen. In einem CursorAdapter, wie dem AllSurveysCursorAdapter, ist genau angegeben, wie mit den Daten, auf die ein auf den CursorAdapter angewendeter Cursor zeigt, umgegangen werden soll, sodass sie in der List angezeigt werden können. Beispielsweise wird mit der newview -Methode eines CursorAdapters ein eigenes View für eine Zeile der Liste angelegt und zurückgegeben und dieses mit der bindview -Methode in den Kontext der Liste, der der CursorAdapter zugewiesen ist, eingetragen. Ein View-Objekt unter Android ist ganz allgemein ein UI-Element. Es gibt Views, die direkt ein UI-Element darstellen, beispielsweise eine Checkbox und es gibt Views, die als Container für andere Views fungieren. Alle UI-Elemente und Container sind von der Klasse android.view.view abgeleitet. Daher kann ein View sowohl als Container als auch als einzelnes 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 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 erwähnten Ressourcen, wie beispielsweise die Farbdefinition selbst, der manuell designten UI-Elemente aus dem Android Holo Colors-Generator werden unter anderem auch in XML-Daten ausgeliefert. 49

56 6 Das Produkt 6 Das Produkt Die Güte einer Software kann man im Allgemeinen am besten einschätzen, wenn man sie benutzt. Um einen Eindruck hier auf Papier festzuhalten werden in diesem Kapitel einige Screenshots der Mainzel-App besprochen. Sicherlich ist die App nur ein Teil des Mainzel-Systems, dennoch ist es der Teil, der mit allen anderen Komponenten des Systems in Verbindung steht und der einzige, mit dem die Benutzer in Kontakt kommen. Wie bereits erklärt, wird der Anwender bei der erstmaligen Benutzung der App zunächst auf die Ansicht zum Einloggen geführt. Wie in Abbildung 6.1 gezeigt wird, hat der Benutzer hier die Möglichkeit sich mit seiner -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 Adresse und sein Passwort eingeben. 11 Ein Toast unter Android dient ähnlich wie die Notifications (siehe Abschnitt 2.2.5) zum Benachrichtigen des Benutzers. Es ist allerdings auf den Einsatz während der Laufzeit der App ausgelegt. Ein Toast hat die Form eines kleinen Blocks, der lediglich einen kurzen Satz enthalten soll. Er taucht für eine bestimmte Zeit im unteren Drittel des Bildschirms auf und beeinträchtigt nicht die Bedienung der UI-Elemente in der gezeigten Ansicht. 50

57 6 Das Produkt Bei erfolgreichem Einloggen wird die Synchronisation mit der Datenbank gestartet, das beim ersten Mal das Erscheinen des Fortschritt-Dialogs in Abbildung 6.2 auslöst. Wird die App nach dieser ersten Synchronisation gestartet, läuft das Update der lokalen Datenbank im Hintergrund ab, sodass der Benutzer zunächst mit den alten Daten weiterarbeiten kann. Sobald das Update fertig ist, wird die Ansicht automatisch aktualisiert. Nach dem Beenden der ersten Synchronisation und nach jedem weiteren Start der App wird die Übersicht über alle Umfragen, in die der Benutzer involviert ist, gezeigt. Hier sind die Umfragen in die drei Tabs Vergangene Umfragen, Laufende Umfragen und Kommende Umfragen eingeteilt und wie in Kapitel 4.2 geplant wurde, kann der Benutzer mit der Swipe-Geste zwischen den einzelnen Tabs navigieren. Auch der Aufbau einer Ansicht in Mainzel, wie sie in Abschnitt 4.2 geplant wurde, ist hier umgesetzt worden. Am oberen Teil des Bildschirms ist die Notification-Area von Android zu sehen, darunter folgt die Action-Bar von Mainzel, mit dem Icon von Mainzel, dem Titel der App und den wichtigsten Navigationsbutton. In dieser Ansicht handelt es sich dabei um den Button zum Erstellen einer neuen Umfrage. Alle weiteren Navigationsbuttons sind, wie in Kapitel 4.2 erklärt, im Action overflow -Button zusammengefasst. Das Gerät auf dem die Screenshots in diesem Abschnitt gemacht wurden, besitzt den angesprochenen Button als Hardware unter dem Bildschirm. Aus diesem Grund wird kein virtueller Button in der Actionbar von Mainzel in den Screenshots angezeigt, vielmehr gelangt der Benutzer in das Optionsmenü über den Hardware-Button. Optionen, die dort zusammengefasst werden, ermöglichen beispielsweise das Ausloggen aus der App, die Einsicht der unbeantworteten Einladungen zu Umfragen oder die Account-Details. Abbildung 6.2 Nach dem Einloggen in die Mainzel-App - Startet ein dem Gerät bekannter Benutzer die App gelangt dieser sofort auf die Übersichtseite rechts im Bild, die alle Umfragen auflistet, in die der Benutzer involviert ist. Sofern der Benutzer sich zum ersten Mal in der App einloggt, muss er erst die Synchronisation der App mit der globalen Datenbank abwarten, wie man links im Bild sehen kann. 51

58 6 Das Produkt Die in dieser Ansicht gezeigte Liste ist ein Überblick über die Umfragen. Jeder Eintrag enthält daher die drei wichtigsten Informationen einer Umfrage, das heißt den Namen, die Rolle des Benutzers in der Umfrage und den Startzeitpunkt. Laufende Umfragen zeigen zusätzlich die verbleibende Zeit bis zum automatischen Beenden der Umfrage an. Mit Klick auf einen Eintrag der Liste gelangt der Benutzer in die Detailansicht der Umfrage, in der er zusätzlich zu den bereits gezeigten Information, den Endzeitpunkt, die Beschreibung, die Autoren und einen Überblick über die Fragen einsehen kann, der ähnlich wie der Überblick über die Umfragen aufgebaut ist. Von dort aus gelangt der Benutzer in die einzelnen Detailansichten der Fragen. In einer laufenden Frage, wie sie in Abbildung 6.3 gezeigt wird, kann er den kompletten Fragetext lesen und ein Countdown weist ihn auf die verbleibende Zeit zum Beantworten der Frage hin. Je nach Frage-Typ stellt oder gibt der Benutzer hier seine Antwort ein und schickt sie mit Klick auf den abschicken - Button an die globale Datenbank. Als Titel der Ansicht wird hier nicht der App-Name, sondern der Name der Umfrage gezeigt und mit Klick auf den Pfeil links neben dem Mainzel Icon in der Actionbar gelangt der Benutzer zurück in die Detailansicht der Umfrage. In Fragen, zu denen ein Autor angegeben hat, dass Enthaltungen möglich sein sollen, wird weiterhin ein Button zum Abgeben der Enthaltung angeboten. Abbildung 6.3: Ansicht zum Beantworten einer Single-Choice-Frage - Der Benutzer sieht die Frage selbst und einen Countdown. Zum Beantworten kann er einen Punkt aus der Radiobutton-Gruppe auswählen. Mit Klick auf abschicken reicht er seine Antwort an die globale Datenbank. In der Detailansicht einer Frage verschwinden der abschicken -Button und gegebenenfalls der Button für die Enthaltungen, sobald die Beantwortungszeit der Frage vorbei ist. An ihre Stelle tritt die Auswertung der Frage. Nun kann jeder Benutzer, der in die Umfrage der Frage involviert ist, die richtige Antwort zu der Frage einsehen, falls eine angegeben wurde. Teilnehmer sehen zusätzlich ihre eigene Antwort. Weiterhin wird die Teilnahme als Prozentwert des Quotienten aus 52

59 6 Das Produkt der Anzahl der abgegebenen Antworten durch die Anzahl der eingetragenen Teilnehmer angegeben. Darüber hinaus wird eine Aussage über die Anzahl der richtigen eingereichten Antworten gemacht, falls eine richtige Antwort angegeben wurde. Für die meisten Frage-Typen steht zudem ein Diagramm zur Darstellung der Ergebnisse zur Verfügung. In Abbildung 6.4 werden Beispiele für die bereits umgesetzten Diagramme einer Single-Choice-Frage, einer Multiple-Choice-Frage und einer Schätz-Frage gezeigt. Für 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 53

60 6 Das Produkt sich ein Dialog zum Erstellen einer neuen Frage, wobei der Typ durch den Spinner 12 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 Adresse des Benutzers, der hinzugefügt werden soll, benötigt wird. Sie kann in dem Textfeld neben dem jeweiligen Plus-Button eingegeben werden. Diese Ansicht ist die einzige, die nicht nach den Vorgaben aus Kapitel 4.2 umgesetzt wurde. In Abbildung 4.7 ist der Teil zum Erstellen einer neuen Frage nicht in einem Dialog, sondern in der Editor-Ansicht selbst umgesetzt. Das Befüllen der betroffenen Formularfelder für die Bearbeitungsfunktion hat allerdings bei der Implementierung Probleme bereitet und war, im Nachhinein betrachtet, nicht die erste logische Konsequenz. Das Einfügen einer neuen Ebene mit Hilfe des Dialogs macht einen klaren Schnitt zwischen Umfrage- und Fragebearbeitung und verunsichert den Benutzer auf diese Weise nicht durch ähnliche Felder und Buttons, wie beispielsweise der UI-Elemente für Start- und Endzeitpunkt der Umfrage und der Fragen. Außerdem ähneln sich auf diese Weise alle Listen einer Umfrage im Aussehen, nämlich die Liste der Fragen, der Autoren und der Teilnehmer. Abbildung 6.5: Umfrage-Editor - Der Benutzer muss im Editor zum Erstellen und Anpassen einer Umfrage je nach Anzahl der Fragen, der Autoren und der Teilnehmer scrollen, um alle Information einsehen und bearbeiten zu können. In der Abbildung ist der Beginn einer langen Umfrage links und das Ende rechts dargestellt. 12 Spinner werden die Drop-Down UI-Elemente unter Android genannt. In dem einzigen Spinner in der Mainzel-App wählt der Benutzer den Frage-Typ für eine neu zu erstellende Frage aus. 54

61 6 Das Produkt Nicht zuletzt kann man an diesem letzten Screenshot zwei andere Optionsbuttons in der Actionbar sehen. In den weiter oben gezeigten Ansichten war die wichtigste Option immer das Erstellen einer neuen Umfrage, während alle anderen Optionen im Action overflow -Button verschwanden. Eine Umfrage, die ohne Einschränkungen bearbeitbar ist, ist auch gleichzeitig im Status kommend und in einer solchen Umfrage ist es am wichtigsten, dass man die Umfrage mit allen ihren Fragen auch von dort aus manuell starten kann. Diese Möglichkeit verbirgt sich hinter dem Play-Button. Weiterhin wird in diesem Zustand häufig eine Umfrage wieder verworfen, daher ist der Lösch-Button in diesem Zustand ebenfalls leicht zugänglich. Alle anderen Option verschwinden auch in diese Ansicht im Action overflow -Button. Gezeigt wurden nur einige Ausschnitte des Endprodukts, um einen Eindruck von den am häufigsten vorkommenden Abläufen bei der Benutzung der App zu vermitteln. Alles in allem entspricht aber auch der nicht dargestellte Teil des Produkts im Aussehen und in der Funktion dem in der bisherigen Arbeit Besprochenen. Welche Punkte nicht umgesetzt werden konnten und auf welche Zukunft das Produkt blicken kann, wird in Kapitel 7 näher erläutert. 55

62 7 Fazit 7 Fazit Zum Abschluss dieser Arbeit soll ein Fazit über das Produkt gezogen werden. Die Fragen, ob die App für den geplanten Einsatz geeignet ist, welche Anforderungen erfüllt wurden und welche zukünftigen Möglichkeiten für das Mainzel-System bestehen, werden in diesem Kapitel geklärt. 7.1 Einsatzfähigkeit In Kapitel 2.1 wurde bereits der geplante Einsatz des Mainzel-Systems in akademischen Vorlesungen nahegelegt. Sicherlich wurde bei der Planung und Umsetzung der App darauf geachtet, dass sie sich nicht ausschließlich auf diesen Bereich fokussiert, dennoch liegt hier der Schwerpunkt. Der Aufbau des Editors für Umfragen erlaubt es dem Dozent einfach und schnell neue Umfragen zu erstellen. Durch das Ernennen weiterer Autoren, ist es ein Einfaches für den Dozent auch Übungsleiter daran mitarbeiten zu lassen. Die bereits umgesetzten Fragetypen bieten eine Basis für die meisten Fragen während einer Vorlesung. Die Studierenden können auf schnellem Weg die Fragen des Dozenten beantworten und bekommen genauso wie der Dozent eine geeignete Rückmeldung über ihre Teilnahme und ihre Leistung. Aus dieser Sicht ist das Produkt vollkommen geeignet für den Einsatz in akademischen Vorlesungen. Um beispielsweise dem Dozenten das Einladen von neuen Teilnehmern für seine Umfragen und die Präsentation der Ergebnisse vor Publikum zu erleichtern, ist es sicherlich von Vorteil für den Einsatz der App in den nächsten Schritten der Entwicklung, Vorschläge aus Kapitel 7.3, wie dem QR-Code-Editor oder dem Powerpoint-Plugin, umzusetzen. 7.2 Umgesetzte Anforderungen Etwa zwei Drittel der funktionalen und nicht-funktionalen Anforderung an das Mainzel-System aus Kapitel 3 konnten im vorliegenden Mainzel-System umgesetzt werden. Dadurch ist wie vorher beschrieben ein funktionaler Prototyp entstanden, der durchaus seinen Einsatzzweck erfüllen kann. Dennoch konnten aus Zeitgründen ein paar Funktionen, die zum angenehmen Arbeiten mit Mainzel beitragen würden, noch nicht umgesetzt werden. Beispielsweise kann die Vorschau, anders als in Anforderung F110 spezifiziert, nicht für alle Fragen einzeln aus- oder eingeschaltet werden, sondern nur übergreifend für die ganze Umfrage. Umfragen können bisher nicht weiterverwendet werden (Anforderung F140). Die in F160 vorgeschlagene Erleichterung beim Eingeben von -Adressen, sodass bereits bekannte -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 erklärt, realisiert werden. Als Prototyp wurde die App bisher nicht in Google-Play, dem App-Shop für Android, zur Verfügung gestellt, wie es in Anforderung NF050 spezifiziert wurde. Der nächste Schritt im Entwicklungsprozess von Mainzel setzt die letzten fehlenden funktionalen Anforderungen um und macht das System zu einer komfortablen Anwendung. 56

63 7 Fazit 7.3 Ausblick Über die bereits geplanten und weiter entwickelten Ideen hinaus, kann der Prototyp von Mainzel der Grundbaustein für viele weitere Einsatzbereiche sein. Naheliegend ist der Ausbau als Werkzeug zum Motivieren und Aktivieren der Zuhörerschaft einer Vorlesung oder eines Vortrags im Allgemeinen. Dazu ist das bereits erwähnte Plugin für Microsoft Powerpoint denkbar, auf das in dieser Arbeit nicht eingegangen werden konnte. Da Powerpoint von vielen Vortragenden genutzt wird, ist es ein Leichtes für diese ein Plugin, das Mainzel integriert, zu verwenden. Denkbar wäre beispielsweise ein Button, über den der Dozent aus der Präsentation heraus eine bestimmte Frage manuell starten kann. In diesem Fall ist der nächste logische Schritt, dass das Plugin auf der nächsten Folie beispielsweise die Auswertung der Ergebnisse der Frage anzeigen kann. Auf 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 -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 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 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 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 57

64 7 Fazit werden, wenn ein Teilnehmer auf die Ansicht zum Beantworten einer Frage wechselt. Auf diese Weise können beispielsweise die Salat-Mitbringsel bei der nächsten Grillparty geplant werden oder Uhrzeiten und Termine können abgesprochen werden. Alles in allem ist aus der Idee ein altes ARS am Institut der Informatik an der Johannes 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. 58

65 Anhang A - Use Cases Anhang A - Use Cases 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. Priorität Hoch: essentielle Funktion 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 VIII

66 Anhang A - Use Cases Abbildung A.1: Benutzeroberfläche zum Bearbeiten von Umfragen - Der Editor ist dem Umfrage erstellen -Editor (siehe Abbildung 4.7) sehr ähnlich, deshalb wurden hier die Ansichten nach dem Scrollen nicht wiederholt. Alle Details, die beim Erstellen der Umfrage angegeben wurden können geändert werden. Weiterhin gibt es in der Actionbar der GUI die Möglichkeit mit dem Play-Button alle Fragen auf einmal zu starten und im Menü findet man die Funktionen zum Speichern der Änderungen und zum Löschen der Umfrage. Nachdem eine Umfrage gestartet wurde, kann eine Umfrage nicht mehr gelöscht werden, da bereits Ergebnisse vorliegen können. Der Play-Button ist nun ein Stopp-Button. Use Case 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 Startund Endzeitpunkt, und die dazugehörigen Antwortmöglichkeiten können nur geändert werden, falls die Frage noch nicht gestartet wurde. Beteiligte Akteure Autor Vorbedingung Der Benutzer ist eingeloggt und hat mindestens Autoren-Rechte an der Umfrage. Trigger Der Benutzer wählt die Bearbeiten-Funktion einer Umfrage aus. Nachbedingung Alle Änderungen an den Daten der Umfrage werden in die Datenbank geschrieben. Komplexität Hoch: Die GUI zum Bearbeiten aller Daten einer Umfrage ist komplex. Auch die Datenbank-Kommunikation beinhaltet komplexe Befehle. Priorität Mittel: Die Funktion wird häufig genutzt, ist aber für die Abläufe im System nicht essentiell. GUI Abbildung A.1 Tabelle A.3: Use Case #03 IX