Sie sind auf Seite 1von 64

Bachelorarbeit

Entwicklung mobiler
Anwendungslsungen fr
Diensttauglichkeitstests
Zur Erlangung des akademischen Grades eines
Bachelor of Science
- Informatik-
Fakultt Informatik
Referent: Prof. Dr. rer. nat. Martin Golz
Koreferent: Dipl. Inf. Thomas Schnupp
eingereicht von:
Fabian Markert
Matr.-Nr. 250697
Frankenheimer Strae 20
98634 Oberweid
Schmalkalden, den 17.12.2011
Danksagung
Zunchst bedanke ich mich bei Prof. Dr. Golz, dass er mir die Mglichkeit gegeben
hat, dieses Thema zu bearbeiten. Bei Thomas Schnupp mchte ich mich fr die aus-
gezeichnete Betreuung bedanken. Meinen Eltern danke ich fr ihre Untersttzung
und Geduld mit mir. Franziska Zimmermann danke ich fr das Design des Icons der
App sowie fr das Testen. Ganz besonders bedanke ich mich bei Franziska Ehms
fr ihre tatkrftige Untersttzung beim Erstellen des schriftlichen Teils dieser Ar-
beit und ihrer Geduld beim Testen der mobilen Anwendung. Insbesondere fr seine
Geduld beim testen der App bedanke ich mich bei Martin Beier. Groes dank gilt
auch Dr. David Sommer, fr seine Hilfe bei meinen Recherchen und der Visualisie-
rung der Datenstze. Fr seine sehr kurzfristige und auch intensive Hilfe kurz vor
Abgabe dieser Arbeit mchte ich Dipl. Inf. Adolf Schenka meinen dank aussprechen.
Bedanken mchte ich mich auch bei Prof. Dr. Braun fr seine L
A
T
E
X-Vorlage, welche
beim Erstellen dieser Arbeit zum Einsatz kommt.
Inhaltsverzeichnis
Abbildungsverzeichnis V
Tabellenverzeichnis VI
Listingverzeichnis VII
Glossar VIII
1 Einleitung 1
2 Erfassungsmethoden 3
2.1 Psychomotor Vigilance Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Number Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 n-Back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Compensatory Tracking Task . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5 Visual Analogue Scales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Marktanalyse der Plattformen 6
3.1 Verteilung der Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3 Windows Phone 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4 Bada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.5 BlackBerry OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Auswahl der Zielplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Konzept des Softwaresystems 11
4.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Allgemeine Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Konzept der mobilen Anwendung . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Konzept des n-back Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Konzept der Server-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 Konzept der graschen Oberche . . . . . . . . . . . . . . . . . . . . . . . 15
4.7 Konzept der Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Umsetzung 17
5.1 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Vigilanz App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1 Nutzerbenachrichtigung . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.2 Einbindung neuer Tests . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3 Umsetzung des Number Pairs Test . . . . . . . . . . . . . . . . . . . 22
5.2.4 Umsetzung des Psychomotor Vigilance Task . . . . . . . . . . . . . . 23
Fabian Markert
III
Inhaltsverzeichnis Fachhochschule Schmalkalden WS 2011
5.2.5 Umsetzung des n-back-Test . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.6 Umsetzung der Visual Analogue Scales . . . . . . . . . . . . . . . . . 25
5.3 Vigilanz Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4 Vigilance Server GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.5 Oene Punkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 Pilotexperiment 31
6.1 Ziele des Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Ablauf des ersten Experimentes . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.1 Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.3 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 Ablauf des zweiten Experimentes . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.1 Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.3 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4 Auswertung des Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Fazit 42
8 Ausblick 43
Literaturverzeichnis IX
Anhang XII
A Android-Applikation XII
B Server-Anwendung XIII
C grasche Oberche XIV
D Fragebogen des Pilotexperiments XVI
Eidesstattliche Erklrung XX
Fabian Markert
IV
Abbildungsverzeichnis
3.1 Lebenszyklus einer Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Aufbau eines Panels in der GUI . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Screenshot einer Nutzerbenachrichtigung, aufgenommen von einem HTC
Wildre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Screenshot des Number Pairs Tests, aufgenommen von einem HTC Wildre 22
5.3 Ausschnitt einer Ergebnisdatei des Number Pairs Test . . . . . . . . . . . . 22
5.4 Beispiel des PVT, aufgenommen von einem HTC Wildre . . . . . . . . . . 23
5.5 Ausschnitt einer Ergebnisdatei des Number Pairs Test . . . . . . . . . . . . 24
5.6 Screenshot des n-back Test, aufgenommen von einem HTC Wildre . . . . . 24
5.7 Ausschnitt einer Ergebnisdatei des n-back Test . . . . . . . . . . . . . . . . 25
5.8 Screenshot des Visual Analogue Scales, aufgenommen von einem HTC Wild-
re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.9 Ausschnitt einer Ergebnisdatei der Visual Analogue Scales . . . . . . . . . . 26
6.1 Ergebnisse der ersten Studie . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Vergleich der Akzeptanz des PVT . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 Ergebnisse des Fragebogens zum PVT-Test. . . . . . . . . . . . . . . . . . . 35
6.4 Ergebnisse des n-Back - Test in der zweiten Studie . . . . . . . . . . . . . . 38
6.5 Ergebnisse des PVT in der zweiten Studie . . . . . . . . . . . . . . . . . . . 38
A.1 Klassendiagramm der Android-Applikation . . . . . . . . . . . . . . . . . . XII
B.1 Klassendiagramm der Server-Anwendung . . . . . . . . . . . . . . . . . . . XIII
C.1 Anmeldebildschirm der graschen Oberche . . . . . . . . . . . . . . . . . XIV
C.2 Screenshot des Hauptfensters der graschen Oberche . . . . . . . . . . . . XV
Fabian Markert
V
Tabellenverzeichnis
3.1 Verteilung der Smartphone-Betriebssysteme. . . . . . . . . . . . . . . . . . . 6
3.2 Auswahlkriterien zur Plattformwahl . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Parameter des Number Pairs Test . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Parameter des Psychomotor Vigilance Task . . . . . . . . . . . . . . . . . . 23
5.3 Parameter des n-back Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4 Erluterung des question-Parameters der VAS . . . . . . . . . . . . . . . . . 26
5.5 Komponenten eines Anzeigedialoges . . . . . . . . . . . . . . . . . . . . . . 28
6.1 Auistung des ersten Funktionstests der Probanden. . . . . . . . . . . . . . 32
6.2 Parameter der VigilanzApp im ersten Versuch . . . . . . . . . . . . . . . . . 32
6.3 Parameter der PC-Umsetzungen im ersten Versuch . . . . . . . . . . . . . . 33
6.4 Parameter der VigilanzApp im zweiten Versuch . . . . . . . . . . . . . . . . 37
6.5 Parameter der PC-Umsetzungen im zweiten Versuch . . . . . . . . . . . . . 37
6.6 Gegenberstellung der Umfrageergebnisse zum PVT . . . . . . . . . . . . . 40
6.7 Gegenberstellung der Umfrageergebnisse zum n-Back . . . . . . . . . . . . 40
6.8 Antworten zu den Benachrichtigungen . . . . . . . . . . . . . . . . . . . . . 41
6.9 Antworten zum Number Pairs Test . . . . . . . . . . . . . . . . . . . . . . . 41
6.10 Antworten zum VAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Fabian Markert
VI
Listings
5.1 Quellcode der Netzwerkkommandos . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Erzeugen der Benachrichtigung . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3 Beispiel einer Enum-Konstante . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4 Beispiel einer Konguration eines Tests . . . . . . . . . . . . . . . . . . . . 21
5.5 Kongurationsdaten der graschen Oberche . . . . . . . . . . . . . . . . . 27
5.6 Registrierung der Controller-Klassen . . . . . . . . . . . . . . . . . . . . . . 29
5.7 Registrierung der Felder im Model . . . . . . . . . . . . . . . . . . . . . . . 29
Fabian Markert
VII
Glossar Fachhochschule Schmalkalden WS 2011
Glossar
App Kurzform fr das englische Wort application, es wird im Bezug auf Anwendungen,
die auf Smartphones oder Tablet-Computern laufen, verwendet.
getter Kurzform fr eine get-Methode eines Objektes.
Handheld Ein Tragbares elektronisches Gert mit unabhngiger Stromversorgung.
Open Handset Alliance Konsortium, bestehend aus 80 Firmen zur Schaung oener Stan-
dards fr mobile Endgerte.
PDA Personal Digital Assistant.
PVT Psychomotor Vigilance Task.
setter Kurzform fr eine set-Methode eines Objektes.
VAS Visual Analogue Scales.
Fabian Markert
VIII
1 Einleitung
An der Fachhochschule Schmalkalden existiert eine Forschungsgruppe, die sich mit
Vigilanztests beschftigt. Vigilanz ist ein Begri aus der Psychologie und Physio-
logie und bedeutet Daueraufmerksamkeit. Vigilanztests dienen der Einstufung der
Diensttauglichkeit. Es soll anhand von einfachen Tests bestimmt werden, ob eine
Person im Stande ist, eine vorgegebene Ttigkeit auszufhren, ohne Ausfallerschei-
nungen, wie zum Beispiel bermdung, zu erleiden. Diese Tests gewinnen im Alltag
eine immer grer werdende Bedeutung. Ein gesteigertes Interesse besteht beispiels-
weise in der Logistikbranche. So mchte man bei einem Fernfahrer wissen, ob dieser
in der Lage ist, den Stress, den diese Ttigkeit mit sich bringt, zu bewltigen.
Es ist auch im Interesse des Betroenen, dass eine dienstuntaugliche Person aus
dem Verkehr gezogen wird, insbesondere, wenn im ungnstigsten Falle Menschen
deswegen sterben knnten. Daher gewinnt die Integration von Vigilanztests in den
Alltag immer mehr an Bedeutung. Der Alkoholtest wurde bereits erfolgreich in die
Gesellschaft integriert, denn jeder versteht dessen Notwendigkeit.
Eine hnliche Form von Diensttauglichkeitstest existiert bereits durch die sogenann-
te Totmanneinrichtung. Diese soll verhindern, dass in gefhrlichen Berufen durch Un-
achtsamkeit Menschenleben gefhrdet werden. Diese Vorrichtung kommt beispiels-
weise in Zgen zum Einsatz. Die dort bezeichnete Sicherheitsfahrschaltung bendet
sich im Triebwagen. Der Triebfahrzeugfhrer ist angewiesen, innerhalb eines festen
oder variablen Intervalls ein Pedal oder Knopf zu bettigen. Wird dies unterlassen
gibt es zunchst eine visuelle, danach eine akustische Warnung. Werden diese igno-
riert, wird der Triebfahrzeugfhrer als dienstuntauglich eingestuft und das System
leitet eine Zwangsbremsung ein um, die Sicherheit aller Insassen zu gewhrleisten
1
.
In der Vergangenheit gab es bereits Umsetzungen von Vigilanztests auf PDAs und ei-
nigen mobilen Endgerten. Die Schwierigkeit mit PDA-Implementierungen bestand
darin, Probanden mit Testgerten auszustatten. Bei den mobilen Endgerten war
die Hardware sehr unterschiedlich und es war schwer, Software zu schreiben, die her-
stellerunabhngig einsatzfhig war. In den letzten Jahren haben Smartphones eine
immer grere Verbreitung erfahren. Diese mobilen Endgerte haben alle Fhigkei-
ten der PDAs, auf denen ein hnliches Betriebssystem zum Einsatz kommt. Daher
lautet die Fragestellung dieser Arbeit:
Ist es mglich, Vigilanztests auf Smartphones alltagstauglich umzuset-
zen? Eignet sich die mobile Testlsung zum Nachweis des Biorhyth-
mus?
1
Vgl. [Wik11h, Wik11g]
Fabian Markert Seite 1 von 44
1. Einleitung Fachhochschule Schmalkalden WS 2011
Zielsetzung ist es, einen funktionierenden Prototypen zu erstellen, welchen die FH
Schmalkalden fr Studien nutzen kann. Mit den Ergebnissen dieser Arbeit soll es
mglich sein, Daten zu erheben, um so Erfahrungswerte zu generieren anhand derer
die Diensttauglichkeit eingeschtzt werden kann.
Es folgt ein mgliches Anwendungsszenario:
Ein LKW-Fahrer, der schon mehrere Stunden unterwegs ist, erhlt von seinem
Smartphone die Benachrichtigung Vigilanzests durchzufhren. Er fhrt auf einen
Rastplatz und arbeitet seine Testreihe durch. Er erzielt die notwendigen Resultate
fr Diensttauglichkeit nicht. Anschlieend weist ihn die Anwendung darauf hin, ei-
ne Pause einzulegen, da er ein erhhtes Unfallrisiko besitzt. Der Fahrer setzt seine
Reise somit erst dann fort, wenn er wieder im Stande ist, normal auf den Verkehr
zu reagieren.
Es ergeben sich auch Anwendungsmglichkeiten fr weitere Berufszweige. Ein Ar-
beitgeber ist auf diese Weise im Stande, den Biorhythmus seiner Angestellten zu
erfassen, um so herauszunden, wann sie ihre maximale Konzentrationsfhigkeit be-
sitzen. So ist es mglich, den Dienstplan zu optimieren. Der Arbeitnehmer erhlt
den Vorteil, dass er nicht mehr gegen seinen eigenen Biorhythmus arbeiten muss.
Dadurch gibt es weniger krankheitsbedingte Ausflle.
Fabian Markert Seite 2 von 44
2 Erfassungsmethoden
Zunchst gilt es, eine Auswahl von Erfassungsmethoden zu treen, welche im Alltag
mglichst leicht durchzufhren sind. Anhand dieser Methoden soll eine Aussage
ber die Diensttauglichkeit eines Probanden getroen werden knnen. Dieses Kapitel
stellt die einzelnen Methoden vor.
2.1 Psychomotor Vigilance Task
Der Psychomotor Vigilance Task (nachfolgend PVT genannt) wurde 1985 von Dinges
& Powell bekannt gemacht, die ursprngliche Version ist von 1982.
Zu Beginn dieses Tests ist der Bildschirm dunkel. Nach Ablauf einer zuflligen Zeit
erscheint eine Anzeige, welche die Verzgerungszeit in Millisekunden darstellt. Auf-
gabe des Probanden ist es, so schnell wie mglich auf die Anzeige zu reagieren. Dies
muss jedoch innerhalb von maximal fnf Sekunden geschehen, bevor sie verschwin-
det. Dieser Vorgang wiederholt sich solange, bis die Testzeit abgelaufen ist und die
Daten gespeichert werden. Es wird erwartet, dass sich mit sinkender Konzentration
des Probanden die Reaktionszeit verschlechtert.
Im Bereich der Labortests haben sich 10 Minuten als Testdauer etabliert. Studi-
en belegten, dass Umsetzungen auf Handheld mit 5 Minuten ebenfalls brauchbare
Ergebnisse erzeugen
1
.
2.2 Number Pairs
Dieser Test basiert auf dem Paradigma aus dem Jahr 1985, welches von Barbara A.
Eriksen und Charles W. Eriksen verentlicht wurde. Dieses besagt, dass Probanden
mit nachlassender Konzentrationsfhigkeit mehr Zeit bentigen, um aus eine Reihe
angezeigter Buchstaben ein bestimmtes Element zu xieren
2
.
Beim Number Pairs Test bekommt der Proband eine Zahlenreihe angezeigt, welche
aus fnf Stellen besteht. Er muss innerhalb von fnf Sekunden entscheiden, ob das
1
Vgl. [TRSB05, RDL06, LDR05, LJD
+
08]
2
Vgl. [EE74]
Fabian Markert Seite 3 von 44
2. Erfassungsmethoden Fachhochschule Schmalkalden WS 2011
zweite mit dem vierten Element dieser Reihe bereinstimmt. Es werden somit zwei
Gren erfasst. Zum einen die Reaktionszeit und zum anderen ob die Antwort des
Probanden korrekt ist. Es wird erwartet, dass bei niedriger Konzentration sowohl
die Reaktionszeit als auch die Anzahl richtiger Antworten verschlechtert.
Eine durchschnittliche Testreihe besteht aus 28 Fragen
3
.
2.3 n-Back
Dieser Test wurde im Jahr 1958 von W. K. Kirchner vorgestellt
4
. Dem Probanden
werden dabei nacheinander einzeln Zeichen fr jeweils eine Sekunde prsentiert. Sei-
ne Aufgabe ist es, whrend jedes Zeichen angezeigt wird, das Element zu benennen,
welches n-Elemente vorher angezeigt wurde. Das n ist eine frei whlbare Zahl. Es
werden Reaktionszeit und Antwort des Probanden erfasst.
Es ist zu erwarten, dass mit sinkender Konzentrationsfhigkeit die Anzahl korrekter
Antworten geringer und die Reaktionszeiten lnger werden.
In der Praxis wird meistens der 1-Back fr jngere und der 2-Back fr Erwachsene
Probanden mit jeweils 20 versuchen angewendet
5
.
2.4 Compensatory Tracking Task
Der Compensatory Tracking Task wurde 1996 von Scott Makeig und Keith Jolle
vorgestellt.
Auf dem Bildschirm des Endgertes wird ein Punkt, im nachfolgenden Cursor ge-
nannt, dargestellt, welchen der Proband ber einen Trackball steuert. Diesen muss
der Proband in einen festgelegten Zielmarke manvrieren. Der Cursor wird mit zu-
flliger Richtung und Geschwindigkeit vom Ziel abgestoen. Aufgabe des Nutzers
ist es, trotz dieser Ablenkungen, den Cursor so nahe wie mglich an die Zielmarke
zu steuern und dort fr die Testdauer zu halten
6
.
Erwartet wird, dass sich mit sinkender Konzentration des Probanden der durch-
schnittliche Abstand des Cursors zum Ziel vergrert. Im Normalfall dauert eine
Session 10 Minuten.
Problematisch fr die Umsetzung ist allerdings, dass der bentigte Trackball nicht
in jedem Smartphone verbaut ist. Somit ist nicht jeder Teilnehmer einer Studie in
3
Vgl. [Wat85, LKT09]
4
Vgl. [Wik11e]
5
Vgl. [Sch09]
6
Vgl. [MJ95]
Fabian Markert Seite 4 von 44
2. Erfassungsmethoden Fachhochschule Schmalkalden WS 2011
der Lage, diesen Test durchzufhren. Daher wird dieser Test in der Umsetzung nicht
bercksichtigt.
2.5 Visual Analogue Scales
Visuelle Analogskalen, im Englischen als Visual Analogue Scales (VAS) bekannt,
wurden erstmalig 1921 von Hayes & Patterson unter dem Namen grasche Ratings-
kala vorgestellt. Sie dienen der Erfassung von subjektiven Eindrcken eines Pro-
banden. Dazu wird eine Frage gestellt und eine meist 100 Millimeter lange Linie
prsentiert. Der Proband soll die Stelle markieren, die seiner subjektiven Wahrneh-
mung entspricht
7
. An den Enden der Linie sind zwei Extremzustnde, welche sich
auf die Frage beziehen, verbal beschrieben. Dies soll die Interpretation im Zusam-
menhang mit anderen Tests erleichtern.
7
Vgl. [Fun04]
Fabian Markert Seite 5 von 44
3 Marktanalyse der Plattformen
Da es viele unterschiedliche Smartphone-Hersteller gibt, verfgen die modernen Han-
dys ber verschiedene Betriebssysteme, wie Android, iOS und Windows Phone 7.
Fr jedes dieser Betriebssysteme wird ein anderes Konzept genutzt, wie eine App
auf der jeweiligen Plattform aufgebaut, bedient und umgesetzt wird. Zudem gibt
es fr jede Plattform eigene Entwicklungstools. Da die App auf vielen Endgerten
eingesetzt werden soll, gilt es zu entscheiden, welche Plattform fr die Entwicklung
genutzt werden soll. Mit dieser Entscheidung beschftigt sich Kapitel 3.
3.1 Verteilung der Plattformen
Um eine hohe Verbreitung einer App zu ermglichen, gilt es, die Plattform auszu-
whlen, welche die hchsten Marktanteile besitzt.
Betriebs-
system
Gerte im
Q3 2011
Marktanteil
in Q3 2011
Gerte in
Q3 2010
Marktanteil
in Q3 2010
Android 60.490.000 52,5 % 20.544.000 25,3 %
Symbian 19.500.100 16,9 % 29.480.100 36,3 %
iOS 17.295.300 15,0 % 13.484.400 16,6 %
RIM 12.701.100 11,0 % 12.508.300 15,4 %
Bada 2.478.500 2,2 % 920.600 1,1 %
Microsoft 1.701.900 1,5 % 2.203.900 2,7 %
Andere 1.018.100 0,9 % 1.991.300 2,5 %
Gesamt 115.185.400 100 % 81.132.600 100 %
Tabelle 3.1: Verteilung der Smartphone-Betriebssysteme. Quelle: [Gar11]. Zu sehen ist
die Anzahl und der Marktanteil der verkauften Gerte des dritten Quartals von 2010
und 2011. Es ist zu erkennen, dass Android den derzeit grten Marktanteil besitzt.
Im Vergleich mit den Werten des Vorjahres lsst sich der Trend erkennen, dass es diese
Position in nchster Zeit behalten wird.
An zweiter Stelle folgt Symbian. Die Entwicklung dieses Betriebssystems wurde aller-
dings 2010 eingestellt, daher ist davon auszugehen, dass dessen Verbreitung in Zukunft
abnehmen wird.
iOS, Research in Motion (RIM) und Microsoft haben im Vergleich zum Vorjahr Markt-
anteile verloren. Lediglich Bada konnte seinen Marktanteil steigern.
Fabian Markert Seite 6 von 44
3. Marktanalyse der Plattformen Fachhochschule Schmalkalden WS 2011
3.1.1 Android
Android ist ein quelloenes Betriebssystem fr mobile Endgerte, welches von der
Firma Google gemeinsam mit der Open Handset Alliance entwickelt und gepegt
wird.
1
Es wurde ursprnglich von der Firma Android inc. entwickelt, 2005 wurde sie
von Google aufgekauft
2
. Die erste Version wurde 2007 verentlicht. Als Program-
miersprache ist Java vorgesehen, es ist allerdings auch mglich, Scala zu verwenden
3
.
Google stellt alle ntigen Entwicklertools in Form des Android SDK in Verbindung
mit Eclipse-plugins bereit
4
.
Jede App verfgt ber ein Datei namens AndroidManifest.xml, welche einen der
wichtigsten Bestandteile der Anwendung darstellt. Darin enthalten sind Informa-
tionen ber das Programm, zum Beispiel welche Berechtigungen die Anwendung
bentigt oder aus welchen Aktivitten (Activity) sie besteht. Eine Activity kommt
einer graschen Oberche gleich und unterliegt einem vorgegebenen Lebenszyklus;
dieser ist in Abbildung 3.1 zu sehen.
Abbildung 3.1: Lebenszy-
klus einer Activity, Quelle:
http://developer.android.
com/reference/android/
app/Activity.html Stand
14.11.2011.
Wenn eine Activity eine andere Activity aufrufen soll, so geschieht dies ber eine
Intent, eine Intention. Diese besitzt Informationen ber die aufrufende Activity sowie
1
Vgl. [Wik11f]
2
Vgl. [Wik11a]
3
Vgl. [Sta11]
4
Vgl. [Lin11]
Fabian Markert Seite 7 von 44
3. Marktanalyse der Plattformen Fachhochschule Schmalkalden WS 2011
diejenige, die gestartet werden soll. Eine Intention kann dabei an eine konkrete
Klasse gerichtet sein um beispielsweise innerhalb der Anwendung ein neues Men zu
nen. Es ist aber ebenfalls mglich, einen allgemeinen Aufruf an das Betriebssystem
starten. Dadurch lsst sich zum Beispiel einen QR-Code-Scanner starten und das
Ergebnis des Scans in der eigenen Anwendung weiter zu verarbeiten. Die Intention
kann ber sogenannte Extras der aufgerufenen Aktivitt Parameter bergeben.
Zustzliche Ressourcen sind in einem Android-Projekt im Unterordner res gespei-
chert. Darin enthalten sind Lokalisierung, Icons, Graken und das Layout. Von der
Entwicklungsumgebung wird im Ordner gen eine Klasse R generiert. Diese besitzt
fr jede Ressource eine eigene ID und kann somit im Programm fr einen leichten
Zugri verwendet werden.
Apps knnen ber den Android Market bezogen werden. Fr das Einstellen ist
eine kostenpichtige Entwicklerlizenz notwendig, welche ber eine einmalige Zahlung
erworben werden kann. Es ist dem Nutzer allerdings auch erlaubt, Anwendungen
auch aus anderen Quellen zu installieren. Diese Mglichkeit ist zum Umsetzen der
in dieser Bachelorarbeit vorgestellten Tests von Vorteil.
3.1.2 iOS
Das Betriebssystem iOS kommt auf Apple-Produkten, wie dem iPhone 4S oder dem
iPad2, zum Einsatz. Die erste Version wurde 2007 vorgestellt
5
. Das dazugehrige
SDK ist kostenlos, erfordert allerdings eine Registrierung. Des Weiteren ist es nur
mit Mac OS X und einer x86-CPU nutzbar. Im SDK enthalten ist auch die Ent-
wicklungsumgebung Xcode 3; wer die aktuelle Version Xcode 4 nutzen mchte, kann
diese ber den Mac App Store fr 3,99 Euro beziehen
6
. Als Programmiersprache ist
Objective-C vorgesehen. Das Testen einer Anwendung auf dem eigenen Endgert
ist erst nach der Freigabe fr den App-Store mglich. Davor kann nur der im SDK
enthaltene Emulator genutzt werden.
Normale Nutzer knnen ihre Apps ausschlielich ber Apples App-Store beziehen,
nachdem die jeweilige Anwendung freigegeben wurde. Das Einstellen von Anwen-
dung in den App Store erfordert eine kostenpichtige Entwicklerlizenz.
3.1.3 Windows Phone 7
Um den Einstieg in seine Plattform zu erleichtern, richtet sich Microsoft an Entwick-
ler, die bereits mit den hauseigenen Tools und Sprachen zur Anwendungsentwicklung
vertraut sind. Daher kommt als Entwicklungsumgebung Visual Studio zum Einsatz.
Zum Arbeiten werden die Windows Phone Developer Tools bentigt
7
.
5
Vgl. [Wik11b]
6
Vgl. [Bei11]
7
Vgl. [Sch11b]
Fabian Markert Seite 8 von 44
3. Marktanalyse der Plattformen Fachhochschule Schmalkalden WS 2011
Der Erstellungsprozess ist hnlich einer Silverlight-Anwendung. Als Standardspra-
che wird C# verwendet. Es ist allerdings auch, mglich andere .NET-Sprachen zu
verwenden
8
.
Als Bezugsquelle fr neue Apps dienen ein eigener App-Store sowie der Windows-
Marketplace.
3.1.4 Bada
Das Betriebssystem Bada wurde von Samsung entwickelt und kommt auf einigen
Modellen zum Einsatz. Das erste Endgert mit Bada wurde Ende 2010 vorgestellt
9
.
Als Entwicklungssprache wird C++ verwendet. Als Entwicklungsumgebung wird
eine angepasste Version von Eclipse genutzt, welche dem kostenfreien SDK beiliegt.
Das SDK ist nur auf Windows basierten Betriebssystemen lauhig. hnlich wie
bei Android besitzt jede App ein Manifest, welches sicherstellt, dass die Anwendung
auf alle bentigten Rechte und Services des Betriebssystems Zugri erhlt
10
.
Normale Nutzer beziehen neue Apps aus einem eigenen App-Store namens Samsung-
Apps.
3.1.5 BlackBerry OS
Das erste BlackBerry Endgert wurde 1999 von Research in Motion (RIM) verf-
fentlicht
11
. Zum Erstellen von Anwendungen wird Java in Verbindung mit Eclipse
sowie dem Java Development Enviroment verwendet. Es handelt sich dabei um eine
Zusatzbibliothek, welche dazu dient, die Schnittstellen des Betriebssystems korrekt
anzusprechen.
Neue Anwendungen knnen ber einen eigenen App-Store oder ber den eigenen
PC installiert werden.
3.2 Auswahl der Zielplattform
An dieser Stelle geht es um die endgltige Festlegung der Zielplattform fr mobile
Endgerte. In Tabelle 3.2 ist zu sehen, dass sowohl Android als auch BlackBerry
OS als Zielplattform geeignet sind. Das Kriterium Verbreitung wird von Android
allerdings besser erfllt. Dies kann man in Tabelle 3.1 erkennen. Zudem lsst sich
8
Vgl. [Sch11a]
9
Vgl. [Wik11c]
10
Vgl. [Gra11]
11
Vgl. [Wik11d]
Fabian Markert Seite 9 von 44
3. Marktanalyse der Plattformen Fachhochschule Schmalkalden WS 2011
im Vergleich mit den Zahlen des Vorjahres der Trend erkennen, das die Marktanteile
von RIM in Zukunft fallen drften.
Da fr die Alltagsintegration der Tests eine hohe Verbreitung des Betriebssystems
von Vorteil ist, empehlt es sich, die meist verwendete Plattform zu nutzen. Dar-
ber hinaus ist die Entwicklung bei iOS, Bada und Microsoft an spezielle Desktop-
Betriebssysteme gebunden und die Bezugsquellen stark eingeschrnkt. Beides ist bei
Android nicht der Fall. Daher wird eine App fr Android entwickelt.
Android iOS Windows
Phone 7
Bada BlackBerry
OS
Verbreitung sehr gut mittel schlecht schlecht mittel
kostenfreie
Entwickler-
werkzeuge
sehr gut mittel sehr gut sehr gut sehr gut
Plattformun-
gebundene
Entwicklung
sehr gut schlecht mittel mittel sehr gut
Zielsprache
frei whlbar
gut schlecht sehr gut schlecht gut
frei whlbare
Bezugsquel-
len fr
Apps
sehr gut schlecht schlecht schlecht sehr gut
Tabelle 3.2: Auswahlkriterien zur Plattformwahl. Hierbei handelt es sich um sub-
jektive Einschtzungen des Autors. Die grte Gewichtung besitzen Verbreitung,
frei whlbare Bezugsquellen und kostenfreie Entwicklerwerkzeuge. Man erkennt,
das Android und Blackberry OS in allen Punkten am besten abschneiden.
Fabian Markert Seite 10 von 44
4 Konzept des Softwaresystems
Fr die Umsetzung werden drei einzelne Anwendungen implementiert. Die App, wel-
che auf dem mobilen Endgert luft, ein Server, welcher die Kongurationsdateien
sowie eventuell notwendige Zusatzdaten bereitstellt sowie eine grasche Oberche,
welche die einfache Erstellung einer Kongurationsdatei und das Hochladen von
zustzlichen Daten ermglicht.
Es ist ebenfalls mglich, die Serveranwendung durch einen Application-Server, wie
beispielsweise Tomcat, zu realisieren. Dies hat den Vorteil, dass die grasche Ober-
che ebenfalls integriert werden kann und die Realisierung durch ein Webinterface
mglich ist. Allerdings wurde der Entwicklungsaufwand fr diese Bachelorarbeit als
zu hoch eingestuft.
Eine marktreife Umsetzung ist nicht vorgesehen, sondern lediglich die Erstellung
dreier funktionsfhiger Prototypen.
4.1 Anforderungen
Fr die Aufgabenstellung ergeben sich fr die mobile Applikation folgende Anfor-
derungen:
die App muss extern vollstndig kongurierbar sein
der Nutzer darf keine Mglichkeit zur Konguration besitzen
eventuell notwendige Daten mssen extern bezogen werden knnen
einmal konguriert, soll die App unabhngig von einem Server nutzbar sein
sollte eine Internetverbindung vorhanden sein, mssen die Ergebnisse hochge-
laden werden knnen
sollte sich die Konguration des Servers gendert haben, muss die aktuelle
Version heruntergeladen werden knnen
sollten sich Daten auf dem Server verndern, mssen alte verworfen und neue
heruntergeladen werden knnen
leichte Bedienbarkeit
Fabian Markert Seite 11 von 44
4. Konzept des Softwaresystems Fachhochschule Schmalkalden WS 2011
leichte Erweiterbarkeit
Mehrsprachigkeit
jeder Nutzer soll eine eindeutige ID bekommen
das Ausgabeformat der Ergebnisdaten soll verarbeitungsfreundlich fr Pro-
gramme, wie zum Beispiel MATLAB, sein
Da das mobile Endgert seine Kongurationsdaten extern beziehen soll, ist es not-
wendig, noch einen passenden Server zu implementieren. Dieser muss die folgenden
Anforderungen erfllen:
die Anwendung muss in der Lage sein, mehrere Clients gleichzeitig zu verwalten
die Anwendung muss im Stande sein, die Anfragen des Clients zu verstehen
und richtig zu beantworten
es muss ein separates Interface fr Administratoren angeboten werden
der Port muss frei whlbar sein
Plattformunabhngigkeit
Speichern von Ergebnissen
Bereitstellen der Kongurationsdaten
Bereitstellen von zustzlichen Daten
Fr die grasche Oberche ergeben sich die nachfolgenden Anforderungen:
Anmelden auf dem Server
Port frei whlbar
Plattformunabhngigkeit
Erstellen und Lschen von Studien
Hochladen von Zusatzdateien
Mehrsprachigkeit
Fabian Markert Seite 12 von 44
4. Konzept des Softwaresystems Fachhochschule Schmalkalden WS 2011
4.2 Allgemeine Struktur
Grundstzlich sind die Anwendungen dafr gedacht, Studien zu verwalten und durch-
zufhren.
Jeder Proband nimmt an einer Studie teil und nutzt dafr die App. Eine Studie
besteht aus einem oder mehreren Tests, die in einer festen Reihenfolge mit unter-
schiedlicher Konguration beliebig oft vorkommen knnen. Die App wei, in welcher
Studie der Proband ist.
Auf dem Server liegen die Kongurationsdaten fr diese Studien. Diese beschreiben,
welcher Test in welcher Form und Reihenfolge durchgefhrt wird.
Die Ergebnisse der mobilen Anwendung werden auf den Server hochgeladen und
nach ihren Studien unterteilt.
Die grasche Oberche dient dazu, eine Konguration fr eine Studie anzulegen
und bestehende zu bearbeiten. ber die Oberche soll es auch mglich sein, zu-
stzliche Dateien, die eventuell fr Tests bentigt werden, hochzuladen.
4.3 Konzept der mobilen Anwendung
Der Ablauf der mobilen Anwendung gestaltet sich folgendermaen: Der Proband
bekommt innerhalb eines festgelegten Intervalls die Benachrichtigung Tests durch-
zufhren. Danach wird die fr ihn vorgesehene Testreihe durchgefhrt. Anschlieend
beendet sich die Anwendung bis zum nchsten Testzeitpunkt.
Fr die Umsetzung der App gibt es zwei Mglichkeiten. Zum einen kann man ei-
ne Hauptanwendung schreiben, welche die Konguration auswertet. Die Tests sind
eigene Anwendungen, man kann auch Komponenten sagen, die jedoch nicht vom
Nutzer direkt gestartet werden knnen. Das hat den Vorteil, das die Tests unabhn-
gig voneinander entwickelt werden knnen und die Anwendung leicht erweiterbar
ist. Der Nachteil dieser Mglichkeit ist, dass der Endnutzer im Extremfall beispiels-
weise zehn bis zwanzig Apps installieren muss, bevor die Tests beginnen knnen.
Das stellt einen groen Zeitaufwand dar. Darber hinaus ist es problematisch, wenn
sich im Nachhinein herausstellt, dass eine Komponente vergessen wurde, da der Pro-
band sein Endgert zur Installation erneut zur Verfgung stellen muss. Dazu kommt
ein hoher Wartungsaufwand, da immer sichergestellt werden muss, dass von allen
Teilapplikationen immer die neueste Version zur Verfgung steht.
Die zweite Mglichkeit ist, alles in einer Anwendung zu vereinen. In der Anwendung
ist somit jeder Test integriert, egal ob er genutzt wird oder nicht. Der Vorteil dieses
Ansatzes ist die einfache Installation, da nur eine App installiert wird, die sofort
benutzbar ist. Des Weiteren ist sichergestellt, dass die Tests immer zur aktuellen
Fabian Markert Seite 13 von 44
4. Konzept des Softwaresystems Fachhochschule Schmalkalden WS 2011
Version der App passen. Der Nachteil ist, das die Gre des Programms im sp-
teren Verlauf erheblich wachsen kann und ein Nutzer Tests in der App hat, die er
selbst nie benutzt, da sie fr seine Studie nicht vorgesehen sind und somit unntigen
Speicherplatz belegen.
Da beim zweiten Ansatz die Vorteile berwiegen, wird in dieser Bachelorarbeit diese
Variante betrachtet. Da eine permanente Internetverbindung nicht gegeben ist, wer-
den die Ergebnisse auf der SD-Karte zwischengespeichert. Sobald eine Verbindung
zum Server mglich ist, werden die Daten hochgeladen. Die Android-Applikation
ist in mehrere Aktivitten aufgeteilt. Beim Starten der App soll eine Actitvity
entscheiden, welche Aktivitten danach gestartet werden. Jeder Test ist eine eige-
ne Aktivitt, liest selbststndig seine Kongurationsparameter und schreibt seine
eigene Antwortdatei.
In Abbildung A.1, welche sich im Anhang dieser Arbeit bendet, ist das Klassen-
diagramm der Anwendung abgebildet. Die VigilanzTestActivity ist der Einstiegs-
punkt der App. Sie soll sich ber eine Implementierung des Interfaces IFServer-
Communication mit der Serverapplikation verbinden, um die aktuelle Version der
Konguration und zustzliche Dateien herunterzuladen. Welche Tests abgearbeitet
werden knnen, wird mit Hilfe des Enums ETestTypes bestimmt. Die Klasse Au-
tostartReceiver sorgt dafr, dass die Anwendung beim Neustart des Endgertes
automatisch im Hintergrund gestartet wird und den Nutzer zu gegebener Zeit be-
nachrichtigt.
Da die Anwendung im Alltag nutzbar sein soll, ist davon auszugehen, dass der
Proband nicht immer die Mglichkeit besitzt, die Tests durchzufhren. Der Nutzer
muss informiert werden, dass neue Tests anstehen. Fr den Fall, dass der Proband
die Benachrichtigung nicht mitbekommt, muss diese Benachrichtigung nach einer
gewissen Zeit erneut stattnden. Wenn der Proband berhaupt nicht reagiert, ist
davon auszugehen, dass der Nutzer schlft oder es die Situation nicht zulsst, sofort
zu antworten. In diesem Fall gibt es keine weitere Wiederholung, allerdings wird ein
Hinweis angezeigt, dass der Nutzer seine Tests durchfhren soll.
4.4 Konzept des n-back Test
In den meisten Umsetzungen dieses Tests wird dem Probanden der Wert akustisch
prsentiert und das Ergebnis vom Nutzer gesprochen. Die Tests sollen allerdings
alltagstauglich sein, also so, das jeder Mensch sie nebenher machen kann, was mit
der akustischen Variante, beispielsweise im Bro, nicht mglich ist.
Die Verarbeitung gestaltet sich mit Audiodateien ebenfalls kompliziert, da davon
auszugehen ist, dass im Alltag der Probanden eine groe Anzahl an Strgeruschen
auftreten. Obwohl sie zwar nicht Bestandteil dieser Arbeit ist, sollen die Ergebnis-
se aber in einem fr die Verarbeitung freundlichen Format vorliegen. Audiodateien
belegen ebenfalls mehr Speicherplatz als Textdaten auf der SD-Karte des Smartpho-
Fabian Markert Seite 14 von 44
4. Konzept des Softwaresystems Fachhochschule Schmalkalden WS 2011
nes.
Da sich Textdaten in allen Belangen als die bessere Variante etabliert haben, wird
die Bearbeitung des Problems ber textbasierte Mittel gelst.
4.5 Konzept der Server-Anwendung
Der Aufgabenbereich des Servers beschrnkt sich im Kern darauf, Dateien zu ber-
tragen. Fr das Administrator-Interface ist es hilfreich, einen HTTP-Auth zur Nut-
zeranmeldung zu verwenden und die Anmeldedaten in einer Datenbank zu hinter-
legen. Aus Zeitgrnden wurde dieser Ansatz jedoch verworfen. Die Anmeldedaten
werden in einer Properties-Datei im root - Verzeichnis des Servers als MD5 Summe
hinterlegt. Ein Nutzer, der sich ber das Administrator-Interface auf dem Server
anmelden will, muss Name und Passwort als MD5 Summe zusenden. Die Struktur
der Anwendung ist in Abbildung B.1 verdeutlicht. Da die Anwendung plattformun-
abhngig sein soll, wurde als Implementierungssprache Java gewhlt.
Die Anwendung soll auf zwei Ports lauschen, einer fr die Kommunikation mit mo-
bilen Endgerten und ein anderer fr das Administrator-Interface. Jede Verbindung
luft eigenstndig in einem eigenen Thread und bearbeitet die unterschiedlichen
Anfragen.
4.6 Konzept der graschen Oberche
Fr die Benutzeroberche wird das Entwurfsmuster Model - View - Controller
angewendet, da es ermglicht, die Aufgaben klar zu trennen und sich der Quellcode
auf diese Weise leichter warten lsst.
Jedes Panel implementiert das Interface IFView, jedes Model IFModel. Die Zu-
sammengehrigkeit der Daten aus dem Model mit den Darstellungsfeldern der View
wird ber eine Enumeration, welche das Markerinterface IFIDEnum implemen-
tiert, realisiert. Fr den Datenaustausch ist die Klasse Connector verantwortlich.
Eine Darstellung dieses Prinzips wird in Abbildung 4.1 dargestellt. Der Connector
bendet sich im Controller der jeweiligen Anzeige.
Ein Panel besteht somit immer aus den folgenden Komponenten: Das Model zur
Speicherung der Daten, die View zur Darstellung und einem Control ler, welcher
sich um die Initialisierung und das Eventhandling kmmert.
Die Realisierung der Mehrsprachigkeit erfolgt ber Properties-Dateien, welche sich
in einem Unterverzeichnis der Anwendung benden; je nach Sprache werden den
entsprechenden keys, welcher einer Programminternen ID entspricht, andere values,
welche die konkrete bersetzung darstellen, zugeordnet. Das Laden erfolgt ber
Fabian Markert Seite 15 von 44
4. Konzept des Softwaresystems Fachhochschule Schmalkalden WS 2011
















Abbildung 4.1: Aufbau eines Panels in der GUI
eine Utility Klasse namens UICongurator. Da auch hier Plattformunabhngigkeit
gefordert wird, erfolgt die Realisierung ebenfalls in Java.
4.7 Konzept der Kommunikation
Jeder Client, sowohl mobiles Endgert als auch Administrator-Interface, stellt eine
Anfrage - REQUEST - und bekommt darauf eine Antwort - RESPONSE - vom
Server zugeschickt. Als Antwort kommen verstanden - OK - und nicht verstanden -
ERROR - in Frage. Sofern die Anfrage verstanden wurde, erfolgt anschlieend die
Verarbeitung auf dem Server. Bei Dateibertragungen mssen von Server und Client
Prfsummen generiert und verglichen werden, eine fehlerhafte Datei wird verworfen
und neu angefordert.
Fabian Markert Seite 16 von 44
5 Umsetzung
Dieses Kapitel beschftigt sich mit Besonderheiten, die whrend der Erstellung der
drei Programme aufgetreten sind und geht auf die Schritte ein, welche notwendig
sind, um die einzelnen Anwendungen zu erweitern.
Es existiert fr jedes Programm ein eigenes Projekt. Das Projekt SharedClasses
beinhaltet Klassen, die in mehreren Projekten Verwendung nden.
5.1 Kommunikation
Die Kommunikation der drei Anwendungen untereinander wird ber eine Enumera-
tion realisiert. Jedes Kommando ist eine Konstante und wird entsprechend interpre-
tiert. Die Konstanten werden in Strings umgewandelt und danach an den Kommu-
nikationspartner geschickt. Die Gegenseite wandelt den String mit der Methode va-
lueOf, ber welche jede Enumeration in Java verfgt, wieder in eine Enum-Konstante
um.
1 public enum ENetworkCommads {
2 REQUEST_CLOSE_CONNECTION,
3 REQUEST_GET_CONFIG,
4 RESPONSE_OK,
5 RESPONSE_ERROR,
6 REQUEST_GET_FILELIST,
7 RESPONSE_NO_FILES,
8 REQUEST_GET_FILE,
9 REQUEST_GET_MD5,
10 REQUEST_UPLOAD_FILE,
11 REQUEST_GET_CONFIG_VERION,
12 REQUEST_GET_STUDIES,
13 REQUEST_CREATE_CONFIG,
14 REQUEST_DELETE_CONFIG,
15 REQUEST_UPLOAD_CONFIG,
16 REQUEST_CHANGE_PASSWORD,
17 REQUEST_CREATE_USER;
18 }
Listing 5.1: Quellcode der Netzwerkkommandos
Jede der drei Anwendungen verfgt ber die im Listing 5.1 dargestellten Konstanten,
nutzt jedoch nur diejenigen, welche fr die jeweilige Anwendung ntig sind. Sollte
ein nicht vorhergesehenes Kommando geschickt werden, wird mit Fehlerbehandlung
reagiert.
Fabian Markert Seite 17 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
Bei Dateibertragungen berechnen beide Parteien jeweils die MD5 Summe und ver-
gleichen diese. Sollten die Werte nicht bereinstimmen, bedeutet dies, es ist ein
Fehler aufgetreten und die Datei wird neu angefordert.
5.2 Vigilanz App
Die Anwendung fr mobile Endgerte trgt den Namen Vigilanz App. Beim Start
der App wird zunchst die Klasse SDCardCongurator benutzt, um festzulegen,
in welcher Studie der Proband ist und welchen Server und Port die App ansprechen
soll. Zu diesem Zweck versucht die Anwendung auf eine Properties-Datei in einem
Unterordner auf der SD-Karte zuzugreifen. Sofern die passenden Kongurationen in
der Datei vorhanden sind, werden diese in die Einstellungen der Anwendung ber-
nommen.
Sollte dies misslingen, wird versucht, die notwendigen Daten aus dem internen Spei-
cherplatz der App zu laden. Falls dies ebenfalls fehlschlgt, bedeutet dies, dass die
Anwendung nicht richtig konguriert wurde. Dem Nutzer wird eine Fehlermeldung
prsentiert und das Programm beendet.
Sofern die Verbindungsdaten mit dem Server erfolgreich ausgelesen wurden, ver-
sucht die Anwendung diesen zu erreichen. Bei erfolgreicher Kontaktaufnahme wird
beim Server die aktuelle Version der Konguration angefragt und mit der internen
verglichen. Sollten diese nicht bereinstimmen, wird die Version des Servers herun-
tergeladen und verwendet. Anschlieend wird eine Dateiliste vom Server angefragt
und mit der eigenen verglichen, sollten sich Daten gendert haben, werden diese neu
angefordert.
Fr den Fall, dass keine Kontaktaufnahme mit dem Server mglich ist, wird die Kon-
guration im internen Speicher der App genutzt. Ist diese nicht vorhanden, kann die
Anwendung nicht genutzt werden. Daher bekommt der Nutzer eine Fehlermeldung
prsentiert und die App wird beendet.
Nach erfolgreichem Laden der Konguration wird begonnen, diese auszuwerten. Es
wird ein Stack gebaut. Dieser enthlt die Information, welcher Test in welcher Rei-
henfolge zu starten ist und was aus der Konguration verwendet werden soll. Nach
Beendigung eines Tests wird das nchste Element vom Stack geholt und gestartet.
Am Ende wird versucht, die Ergebnisse an den Server zu senden. Bei erfolgreichem
Upload werden die Ergebnisdateien gelscht.
Fabian Markert Seite 18 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
5.2.1 Nutzerbenachrichtigung
Die Klasse BackgroundService ist fr die Planung der Benachrichtigungen zu-
stndig. Sie lsst den nchsten Zeitpunkt fr eine Notication ermitteln. In der
Konguration ist dies in dem Propertie interval in Minuten festgelegt. Besonder-
heit ist die Bestimmung des Zeitpunktes. Es wird ein Datumsobjekt erzeugt, dessen
Minuten und Sekunden auf Null gesetzt werden. Danach wird das Intervall so lan-
ge dazu addiert, bis der Zeitstempel des Datumsobjektes grer ist als die aktuelle
Systemzeit.
Wird beispielsweise als Intervall 20 eingestellt, kmen unter anderem folgende Zeit-
punkte zustande:
1. 13:00 Uhr
2. 13:20 Uhr
3. 13:40 Uhr
4. 14:00 Uhr
Fr das Anzeigen der Benachrichtigung wurde ursprnglich die Klasse Handler be-
nutzt, sie gehrt zu den Standardklassen der Android-API und dient unter anderem
dazu, zeitversetzt Code auszufhren; sie ist vergleichbar mit einem Executor Service
von Java. Es stellte sich allerdings heraus, dass der Handler fr grere Intervalle
nicht geeignet ist.
Daher wird der AlarmManager verwendet. Der AlarmManager ist ein System-
dienst in Android. Um einen neuen Alarm zu registrieren, muss ein PendingIntent
erzeugt werden, welcher die Information enthlt, welche Klasse auf den Alarm rea-
gieren soll, sowie der Zeitstempel des Zeitpunktes, wann der Alarm stattnden soll.
Des Weiteren kann eingestellt werden, dass sich der Alarm in einem bestimmten
Intervall wiederholen soll, dies ist in der Anwendung auch nach 30 Sekunden jeweils
der Fall.
Die Klasse RepeatingAlarmReceiver reagiert auf den Alarm, auerdem erzeugt
sie die Notication.
Fabian Markert Seite 19 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
1 I nt ent newIntent = new I nt ent ( context , Vi g i l a nz t e s t Ac t i vi t y . cl ass ) ;
2
3 St r i ng ns = Context . NOTIFICATION_SERVICE;
4 f i nal Not i f i cat i onManager mNoti f i cati onManager =
5 ( Not i f i cat i onManager ) cont ext . get Sys t emSer vi ce ( ns ) ;
6
7 i nt i con = R. drawabl e . i con ;
8 CharSequence t i cker Text = "Time for Tests" ;
9 CharSequence t i c k e r Ti t l e = "Vigilanz App" ;
10
11 Pendi ngI ntent cont ext I nt ent =
12 Pendi ngI ntent . ge t Ac t i vi t y ( context , 0 , newIntent , 0) ;
13 f i nal No t i f i c a t i o n n o t i f i c a t i o n =
14 new No t i f i c a t i o n ( i con , t i cker Text , System . cur r ent Ti meMi l l i s ( ) ) ;
15 n o t i f i c a t i o n . s et Lat es t Event I nf o ( cont ext . get Appl i cat i onCont ext ( )
16 , t i c ke r Ti t l e , t i cker Text , cont ext I nt ent ) ;
17 n o t i f i c a t i o n . de f a ul t s |= No t i f i c a t i o n .DEFAULT_VIBRATE;
18 n o t i f i c a t i o n . de f a ul t s |= No t i f i c a t i o n .DEFAULT_SOUND;
19
20 n o t i f i c a t i o n . vi br at e = VIBRATE;
21 n o t i f i c a t i o n . f l a g s |= No t i f i c a t i o n .FLAG_NO_CLEAR;
22
23 mNoti f i cati onManager . not i f y (HELLO_ID, n o t i f i c a t i o n ) ;
Listing 5.2: Erzeugen der Benachrichtigung
Abbildung 5.1: Screenshot einer Nutzerbenachrichtigung, aufgenommen von einem
HTC Wildre. Die Benachrichtigung ist im unteren Teil der Grak zu erkennen.
In Listing 5.2 wird gezeigt, welche Parameter der Notication bergeben werden.
Sie darf nicht gelscht werden, spielt einen Ton ab und lsst das Smartphone vi-
brieren. Wenn der Proband die Benachrichtigung fnfmal hintereinander ignoriert,
gibt es keine weitere, die Meldung bleibt allerdings angezeigt. Ein Beispiel fr eine
solche Benachrichtigung ist in Abbildung 5.1 zu sehen.
Damit der Proband auch nach einem Neustart des Smartphones eine Benachrichti-
gung erhlt, existiert die Klasse AutostartReceiver, diese wird beim Systemstart
ausgefhrt und startet den BackgroundService.
Fabian Markert Seite 20 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
5.2.2 Einbindung neuer Tests
Jeder neue Test muss in die Enumeration ETestTypes in Form einer Konstante
registriert werden. Als Bezeichner ist der Name des Tests zu whlen. Jede dieser
Konstanten verfgt ber zwei Attribute: zum einen den Namen, nach dem in der
Konguration gesucht werden soll, zum anderen die Klasse, die zum Durchfhren
des Tests angesprochen werden soll, dies kann man in Listing 5.3 sehen:
1 NumberPairsTest ( "numberPairs" , NumberPai rsTestActi vi ty . cl ass )
Listing 5.3: Beispiel einer Enum-Konstante
Der Name entspricht einem Prx, der jedem Attribut, welches sich auf diesen Test
bezieht, vorangestellt ist. Da ein Test mehrfach in unterschiedlicher Konguration
vorkommen kann, folgt dem Prx eine Zahl. Diese sagt aus, auf welche Variante
sich dieses Attribut bezieht. Des Weiteren muss der Test eingeschaltet sein. Zum
Vergleich dient Listing 5.4. ber das Attribut order wird die Reihenfolge festgelegt,
in der die Tests ablaufen. Diese entspricht der von links nach rechts, als Trennzeichen
ist ein ; anzugeben.
1 numberPai rs0=true #enabl e t e s t
2 numberPai rs0 . conf us i on=true
3 numberPai rs0 . l engt h=5
4 numberPai rs0 . ti meout =5060
5 numberPai rs0 . pos Fi r s t Val ue=2
6 numberPai rs0 . posSecondVal ue=4
7 numberPai rs0 . roundCounts=2
8 or der=vas0 ; numberPai rs0 ; nback0 ; pvt0 ; numberPai rs1 ; vas1
Listing 5.4: Beispiel einer Konguration eines Tests
Jede Klasse, die einen Test implementiert, muss die abstrakte Klasse
AbstractCognitiveTest erweitern und ist im Android Manifest der Anwendung
als Activity zu registrieren. Als Name ist der Testname mit dem Zusatz Activity
zu whlen
1
.
Die Klasse AbstractCognitiveTest beinhaltet den Instanznamen (activityName),
zum Beispiel numberPairs0, sowie den Ausgabedatenstrom fr die Ergebnisdatei. Je-
de Ergebnisdatei verfgt ber eine einheitliche Header-Zeile, bestehend aus userid,
activityName, version der Konguration und dem Zeitpunkt der Erstellung der Da-
tei. Jede Unterklasse ist selbst dafr verantwortlich, die Ergebnisse zu schreiben und
den Ausgabestrom am Ende zu schlieen. Der activityName ist dazu zu benutzen,
um die zugehrigen Attribute aus der Kongurationsinstanz herauszultern. Alle
Attribute sind als optional anzusehen, daher muss immer mit Default-Werten gear-
beitet werden knnen.
Fr jeden neuen Test ist im Projekt SharedClasses eine neue Enumeration an-
zulegen, welche die einzelnen Parameter desselbigen beschreibt. Dieser ist fr alle
Zugrie auf die Kongurationsinstanz in allen Projekten zu verwenden.
1
Zu sehen in Listing 5.3
Fabian Markert Seite 21 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
5.2.3 Umsetzung des Number Pairs Test
Fr den Number Pairs Test sind folgende Parameter vorgesehen:
Parameter Bedeutung
length Lnge des dargestellten Strings
timeout Zeit in ms, in der ein Proband antworten muss
posFirstValue Position des ersten Elementes
posSecondValue Position des zweiten Elementes
roundCounts Anzahl der Durchlufe
confusion erhht die Wahrscheinlichkeit, dass mehrere Elemente identisch sind
Tabelle 5.1: Parameter des Number Pairs Test
Abbildung 5.2: Screenshot des Number Pairs Tests, aufgenommen von einem HTC
Wildre
Abbildung 5.2 zeigt die Umsetzung des Tests. In Abbildung 5.3 ist eine Ergebnisdatei
dieses Tests zu sehen, die erste Zeile entspricht dem Format, welches bereits in
Abschnitt 5.2.2 beschrieben wurde. Danach folgt eine Kopfzeile, die alle Parameter
erklrt. Die weiteren Zeilen entsprechen den Ergebnissen. Die erste Spalte besagt,
ob die Nutzerantwort korrekt war, die nchste beschreibt die Zeit in Millisekunden,
welche der Nutzer zum Antworten bentigt hat und die letzte zeigt den String, der
sichtbar war.
435d3734-8078-454a-91a5-d2700118d717 numberPairs numberPairs0 version=1318703565816 24.10.2011
03:17:01
answer correct, time, numString
true, 2045, 8 3 1 0 5
true, 1643, 0 0 0 7 0
Abbildung 5.3: Ausschnitt einer Ergebnisdatei des Number Pairs Test
Fabian Markert Seite 22 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
5.2.4 Umsetzung des Psychomotor Vigilance Task
Fr die Anzeige der Millisekunden sollte ursprnglich ein Chronometer verwendet
werden. Dieses Widget ist speziell fr Zeitanzeige gedacht, allerdings lsst sich das
Aktualisierungsintervall nicht einstellen. Daher wird die Millisekundenanzeige ber
eine TextView realisiert, deren Text zufllig alle zehn bis zwanzig Millisekunden
aktualisiert wird und anklickbar ist.
Bei Antippen des Textes wird die aktuelle Zeit in die Ausgabedatei geschrieben.
Der angezeigte Text wird ermittelt, indem vom aktuellen Zeitstempel der Wert des
Zeitstempels abgezogen wird, der beim Sichtbarmachen der TextView aktuell war.
Allerdings ist ungeklrt wie genau diese Methode zur Ermittlung der Reaktionszeit
ist, da nicht bekannt ist, wie viel Zeit bis zum ermitteln der Dierenz whrend der
des Eventhandlings vergeht.
Um den Quellcode bersichtlicher zu gestalten, ist die Klasse PVTRunner erstellt
worden. Sie kmmert sich um den Ablauf des Tests, die Hauptklasse Psychomotor-
VigilanceTaskActivity ist lediglich fr die Initialisierung und fr das Schreiben
der Ergebnisse zustndig.
Die Kongurationsparameter des Tests sind in Tabelle 5.2 beschrieben. Die Umset-
zung ist in Abbildung 5.4 zu sehen. Abbildung 5.5 zeigt das Ausgabeformat, die erste
Zeile entspricht dem allgemeinen Header, welcher in Abschnitt 5.2.2 beschrieben ist.
Die nachfolgende Zeile beschreibt die Bedeutung der Ergebnisse. Alle weiteren Zeilen
entsprechen den Messwerten.
Parameter Bedeutung
testTime Dauer des Tests
timeout Zeit in ms, in der ein Proband antworten muss
minWaitTime Zeit, die der Nutzer mindestens warten muss
maxWaitTime Zeit, die der Nutzer maximal warten muss
Tabelle 5.2: Parameter des Psychomotor Vigilance Task
Abbildung 5.4: Beispiel des PVT, aufgenommen von einem HTC Wildre
Fabian Markert Seite 23 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
435d3734-8078-454a-91a5-d2700118d717 pvt pvt0 version=1318703565816 24.10.2011 03:17:41
reactionTime
482
528
572
687
532
484
647
1002
887
Abbildung 5.5: Ausschnitt einer Ergebnisdatei des Number Pairs Test
5.2.5 Umsetzung des n-back-Test
Im oberen Abschnitt des Displays erkennt der Nutzer einen Buchstaben oder ei-
ne Zahl. Darunter bendet sich die Aufgabenstellung fr den Nutzer. Im unteren
Abschnitt sind mehrere Buttons zu sehen, deren Anzahl variabel ist. Aufgabe des
Nutzers ist es, den Button zu drcken, welcher das Element anzeigt, dass dem n
Elemente vorher entspricht. Die Position der angezeigten Elemente ist jedesmal
eine andere. Fr diesen Test ist der Portrait-Anzeigemodus festgelegt, da es im
Landscape-Modus dazu kommen kann, dass nicht alle Buttons auf dem Display
dargestellt werden knnen. In Abbildung 5.6 sieht man die Umsetzung des Tests.
Da die Buttons auf manchen Modellen sehr klein dargestellt werden, vibriert das
Gert beim Antippen, um dem Nutzer eine Rckmeldung zu geben. Reagiert der
Proband nicht rechtzeitig, werden die entsprechenden Ergebnisattribute auf -1 ge-
setzt.
Abbildung 5.6: Screenshot des n-back Test, aufgenommen von einem HTC Wildre
Daraus ergeben sich die Parameter, die in Tabelle 5.3 beschrieben sind. Abbildung
5.7 zeigt das Ergebnisformat der Umsetzung. Die erste Zeile entspricht dem allge-
meinen Header aus Abschnitt 5.2.2. In der zweiten steht das aktuelle n und alle
angezeigten Werte hintereinander. Die dritte erklrt die Parameter und alle weite-
ren sind Messwerte. Das Attribut date time entspricht dem Zeitstempel im Format
yyyyMMdd HHmmss. Die presentation ist das aktuell angezeigte Element, lag
die Reaktionszeit des Nutzers, answer die Antwort des Probanden und correctAns-
wer entspricht der erwarteten Antwort.
Fabian Markert Seite 24 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
Parameter Bedeutung
n Anzahl der Elemente vorher, auf die sich die Aufgabenstellung bezieht
displayTime Anzeigedauer des dargestellten Wertes
length Anzahl der Werte, die prsentiert werden
displayValues Anzahl der Buttons, die sichtbar gemacht werden sollen
numberDigets legt fest, ob Zahlen statt Buchstaben gezeigt werden sollen
Tabelle 5.3: Parameter des n-back Test
435d3734-8078-454a-91a5-d2700118d717 nback nback0 version=1320593118618 09.11.2011 14:28:48
n=1 values=35061433346
date time presentation lag answer correctAnswer
20111109 142854 3 -1 -1 -1
20111109 142857 5 1345 3 3
20111109 142900 0 1396 5 5
20111109 142903 6 1799 0 0
20111109 142906 1 1157 6 6
20111109 142909 4 916 1 1
20111109 142912 3 1032 4 4
20111109 142915 3 1201 3 3
20111109 142918 3 855 3 3
20111109 142921 4 1127 3 3
20111109 142924 6 1788 5 4
Abbildung 5.7: Ausschnitt einer Ergebnisdatei des n-back Test
5.2.6 Umsetzung der Visual Analogue Scales
Bei Visual Analogue Scales handelt es sich nicht direkt um einen Test, sondern um
eine Einschtzung des aktuellen Zustands des Probanden. Die Integration in Form
eines Adapters stellte sich aber als geringerer Arbeitsaufwand heraus.
Der Proband soll hierbei seinen persnlichen Zustand auf einer Skala von 0 bis
100 beschreiben, wobei 0 fr mde und 100 fr wach steht. Der Adapter besitzt
einen Parameter namens question. Dieser entspricht einer Zahl, die besagt, welche
Frage dem Probanden gestellt werden soll. Der Nutzer kann gefragt werden, wie sein
allgemeines Benden ist, wie wach er sich fhlt oder wie konzentriert er gerade ist.
Abbildung 5.8 zeigt die Umsetzung. Als problematisch gestaltete sich die Anzeige-
Skala. Diese sollte eigentlich vertikal sein, da es aber nicht ohne weiteres mglich ist,
die verwendete SeekBar als vertikal zu kongurieren, ist die Anzeige horizontal. Als
Anzeigemodus wurde Landscape eingestellt, da dieser in der Breite mehr Platz bietet
und der Proband dadurch genauere Angaben zu seinem Zustand machen kann.
Abbildung 5.9 zeigt das Ergebnisformat. Die erste Zeile entspricht dem allgemeinen
Header aus Abschnitt 5.2.2. Die zweite erklrt die Bedeutung des Ergebniswertes
und die letzte entspricht der persnlichen Einschtzung des Probanden ber seinen
Wachzustand.
Fabian Markert Seite 25 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
Zahlwert Frage negative
Antwort
positive
Antwort
0 Wie ist Ihr
allgemeines
Benden?
schlecht gut
1 Wie wach fhlen
Sie sich?
mde wach
2 Wie konzentriert
fhlen Sie sich?
unkonzen-
triert
konzentriert
Tabelle 5.4: Erluterung des question-Parameters der VAS. Der Parameter ist ein
Zahlenwert. Je nach Einstellung werden dem nutzer andere Frage und Antwort-
mglichkeiten zur Auswahl gestellt.
Abbildung 5.8: Screenshot des Visual Analogue Scales, aufgenommen von einem
HTC Wildre
435d3734-8078-454a-91a5-d2700118d717 vas vas1 version=1318703565816 26.10.2011 00:16:34
answer
52
Abbildung 5.9: Ausschnitt einer Ergebnisdatei der Visual Analogue Scales
5.3 Vigilanz Server
Der Server dient dem bereitstellen der Konguration und dem sammeln der Ergeb-
nisdaten der Vigilanz App. Eine Besonderheit des Servers ist die Ordnerstruktur,
welche vom Programm automatisch angelegt wird. Im root-Verzeichnis sind vier
Ordner angelegt mit den Namen les, results, studies und users.
Das Verzeichnis les beinhaltet Daten, welche die VigilanzApp zur Durchfhrung
von Tests bentigen kann. Als Unterverzeichnis ist der Name der Studie zu verwen-
den, fr die diese Daten vorgesehen sind. Alle Dateien innerhalb dieses Unterver-
zeichnisses werden von den Clients, die in dieser Studie sind, angefordert.
Im Unterordner results benden sich die Ergebnisdaten der mobilen Anwendung.
Beim Hochladen teilt der Client dem Server mit, in welcher Studie er sich bendet
und die individuelle Kennung des Probanden. Falls notwendig legt die Anwendung
Fabian Markert Seite 26 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
Unterverzeichnisse an in der Form <studie>/<userid>. Je nach Ergebnisformat
werden die empfangenen Dateien in einen weiteren Unterordner einsortiert, welcher
den Namen der jeweiligen Testart trgt (zum Beispiel nback0). Diese Sortierung soll
das Verarbeiten erleichtern.
Der Ordner studies beinhaltet die Kongurationen der Studien. Die Kongurations-
daten mssen den selben Namen haben, wie die jeweilige Studie und im Properties-
Dateiformat vorliegen. Sollte ber das Administrationsinterface eine neue Version
empfangen werden, wird von der alten Konguration ein Backup im Unterverzeichnis
backup angelegt.
Im Verzeichnis users bendet sich eine Properties-Datei. Sie beinhaltet die Anmel-
dedaten fr Nutzer, die sich ber den Administrationsport anmelden, in Form von
MD5-Summen.
Der Standardport der Anwendung ist 42123, ber den Konsolenparameter port
kann ein benutzerdenierter Port eingestellt werden.
Der Administrationsport lauscht immer eine Portnummer ber dem eingestellten
Port. Zustzlich bentigt der Server weitere 98 Ports, die fr Dateibertragung
genutzt werden.
5.4 Vigilance Server GUI
hnlich der Server-Anwendung verfgt die grasche Oberche ber eine spezielle
Ordnerstruktur. Im Ordner settings benden sich die Informationen in Form einer
Properties Datei namens defaults.properties darber, welche Sprache als Letztes ver-
wendet wurde, wie Dateien heien und welche Strings fr diese Sprache zu benutzen
sind.
Listing 5.5 zeigt den Ausschnitt einer solchen defaults-Datei. Zeile eins besagt, dass
die Lokalisierung aus der Datei geladen wird, welche mit DE gekennzeichnet ist.
In Zeile drei steht der passende Dateiname. Der Nutzer hat die Mglichkeit, im
Programm die aktuelle Sprache ber ein Men zu ndern, der Inhalt dieses Mens
steht in Zeile vier. Die Sprachdaten benden sich innerhalb des settings-Ordners im
Unterverzeichnis lang. Um eine neue Sprache einzufhren, muss die defaults Datei
angepasst und eine neue Properties Datei im Unterordner lang angelegt werden.
1 l ang=DE
2 l ang .ENG=e ngl i s h . pr o pe r t i e s
3 l ang .DE=deutsch . pr o pe r t i e s
4 l ang . menu=Deutsch ,DE; Engl i sh ,ENG
Listing 5.5: Kongurationsdaten der graschen Oberche
Wie schon im Konzept erwhnt, wird das Entwurfsmuster Model-View-Controller
verwendet; der allgemeine Aufbau ist in Abbildung 4.1 zu sehen. Um das Kon-
gurationsmen fr einen neuen Test mit einzubinden, ist ein neues Package unter
Fabian Markert Seite 27 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
com.fhs.vigilance.gui.propertiegenerator.congpanel zu erstellen. Diese muss
denselben Namen tragen wie der Test, den es kongurieren soll.
In diesem neuen Package sind vier Klassen anzulegen. Jeder einzelnen ist ein Prx
vorangestellt, welcher die Aufgabe der Klasse kennzeichnet, danach folgt der Name
des Panels.
Art Prx Typ implementiert Interface erweitert Klasse
Controller C class IFPropertieController AbstractController
Model M class IFModel AbstractModel
View V class IFView, IFPropertiePanel JPanel
IDEnum EID enum IFIDEnum
Tabelle 5.5: Komponenten eines Anzeigedialoges
Im nachfolgenden Abschnitt werden die Komponenten aus Tabelle 5.5 genauer er-
lutert.
Der Controller kmmert sich um die Initialisierung von Model und View. Er er-
zeugt die beiden Objekte und befllt das Model mit Daten. Jeder Controller verfgt
ber einen Connector. Der Connector ist eine Hilfsklasse, die einen erleichterten
Datentransfer zwischen Model und View ermglicht. Verbunden werden die beiden
Komponenten ber den Befehl connect. Damit werden die beiden Objekte beim
Connector registriert. Nach Abschluss der Initialisierung ist die Methode load auf-
zurufen. Diese ruft aus dem Model alle getter und aus der View alle setter auf.
Nachdem der Nutzer den Speicher-Button gedrckt hat, ist die Methode save auf-
zurufen. Diese schreibt die aktuellen Werte aus der View zurck in das Model.
Der Controller implementiert das Interface IFPropertieController, dieses beinhal-
tet die Methoden loadProperties, getCurrentCong und getView. Die Metho-
de loadProperties dient dem Laden der aktuellen Konguration fr einen Test.
Es werden zwei Parameter bergeben namens settings und prex. Der Parameter
settings ist eine Kopie der aktuellen Konguration, aus der das Model seine Daten
herausltern muss. Der prex ist der Name des Tests aus der Konguration, bei-
spielsweise nback0. Beim Abrufen der Daten aus settings ist mit Default-Werten
zu arbeiten fr den Fall, dass ein neuer Test angelegt wurde und somit noch keine
Konguration fr diesen existiert.
Die Methode getCurrentCong dient dem Speichern der aktuellen Konguration
eines Tests. An dieser Stelle sind die Daten aus dem Model wieder zurck in die
settings zu schreiben und an das Hauptprogramm zurckzugeben. Mittels getView
muss die aktuelle View zurckgegeben werden.
Fr jeden Controller ist eine Konstante in der Enumeration EPanels anzulegen.
Diese beinhaltet eine Referenz auf die Controller-Klasse, ein Beispiel hierfr ist in
Listing 5.6 zu sehen.
Fabian Markert Seite 28 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
1 / enum c ons t ant /
2 NumberPairs ( CNumberPairs . cl ass ) ,
3 / enum c ons t ant /
4 PVT( CPvt . cl ass ) ,
5 / enum c ons t ant /
6 NBack(CNBack. cl ass ) ,
7 / enum c ons t ant /
8 Vi s ual Anal ogueScal es ( CVi sual Anal ogueScal es . cl ass ) ;
Listing 5.6: Registrierung der Controller-Klassen
Der Controller hat smtliche Aufgaben des Eventhandlings zu bernehmen.
Um die Zusammengehrigkeit der Felder aus Model und View festzulegen ist ei-
ne Enumeration anzulegen, der IDEnum. Dieser implementiert das Interface IFI-
DEnum. Es verfgt ber keine Methoden, sondern dient lediglich als Markierung,
dass diese Enumeration fr ID-Vergabe genutzt wird. Die Enum-Konstanten knnen
ebenfalls zum Laden von Lokalisierungsstrings genutzt werden.
Das Model dient der Datenspeicherung. Fr jedes Feld ist ein setter und ein getter
anzulegen. Die Felder mssen mittels der Methode addToModel registriert werden.
1 addToModel (EIDNBack . ID_DISPLAY_TIME, "DisplayTime" ) ;
2 addToModel (EIDNBack . ID_NVALUE, "N" ) ;
3 addToModel (EIDNBack . ID_STRING_LENGTH, "StringLength" ) ;
4 addToModel (EIDNBack . ID_DISPLAY_VALUES, "displayValues" ) ;
5 addToModel (EIDNBack .ID_NUMBER_DIGETS, "numberDigetsEnabled" ) ;
Listing 5.7: Registrierung der Felder im Model
Ein Beispiel ist in Listing 5.7 zu sehen. Als Parameter ist die jeweilige IDEnum-
Konstante und der Name des Feldes als String zu bergeben. Hierbei spielt die
Gro- und Kleinschreibung keine Rolle.
Die View dient der Darstellung der Parameter. Jede View muss die Klasse JPanel
erweitern. hnlich dem Model sind hier alle darzustellenden Felder setter und getter
anzulegen und ber die Methode addToModel zu registrieren.
ber die Methode getPrex ist der Bezeichner an das Hauptprogramm zurckzu-
geben, welcher sowohl in der Anzeige als auch in der Kongurationsdatei der Studien
verwendet werden soll, beispielsweise nback.
5.5 Oene Punkte
Da es sich bei allen drei Programmen lediglich um Prototypen handelt, gibt es
noch einige Probleme, die in der Zukunft zu beseitigen sind. Eine Marktreife ist
nicht gefordert, daher wurde der Aspekt des Testens vernachlssigt. Um eine sptere
Funktionsfhigkeit der Programme zu garantieren, ist es zwingend notwendig JUnit
Tests zu erstellen.
Aus Sicherheitsgrnden ist es sinnvoll, den Datenverkehr zwischen Server und Clients
Fabian Markert Seite 29 von 44
5. Umsetzung Fachhochschule Schmalkalden WS 2011
zu verschlsseln, um eine Manipulation durch Dritte zu verhindern.
Es ist mglich, die Tests der VigilanzApp abzubrechen. Dazu muss der Proband
lediglich die zurck-Taste des Smartphones drcken, dann wird der aktuelle Test
abgebrochen und mit dem nchsten begonnen. Dieser Eekt konnte bisher nicht
unterbunden werden, da es dem normalem Bedienkonzept von Android widerspricht.
Dieses sieht vor, dass der Nutzer jederzeit die Mglichkeit hat, eine Aktivitt zu
beenden.
Der Number-Pairs- und der n-back-Test sollen im Stande sein, statt eines Strings
Bilder anzuzeigen, auf denen die jeweiligen Zeichen zu erkennen sind. Auf diese Weise
soll es mglich sein, ein Rauschen in den Test mit einzubringen. Beim n-back-Test
kann es vorkommen, dass auf allen Buttons die gleiche Antwortmglichkeit steht
und der Proband somit keine falsche Antwort geben kann.
In vereinzelten Fllen kommt es vor, dass das Smartphone neu startet, wenn eine
Nutzerbenachrichtigung angezeigt werden soll.
Gelegentlich wird das eingestellte Zeit-Intervall von der App nicht eingehalten.
Es kann vorkommen, dass der Stack der App nicht abgearbeitet wird.
Wenn die graschen Oberche geschlossen oder ein anderer Einstellungsdialog auf-
gerufen wird, werden die aktuellen Daten verworfen, sofern nicht vorher auf Spei-
chern geklickt wurde. Es ist daher noch notwendig, den Nutzer darber zu informie-
ren, dass Einstellungen gespeichert oder hochgeladen werden mssen, sollte er dies
vergessen haben. Wenn neue Tests zu einer Studie hinzugefgt werden, muss derzeit
immer sofort gespeichert werden, da es sonst zu Fehlern in der Anzeige kommt.
Fabian Markert Seite 30 von 44
6 Pilotexperiment
Um die Stabilitt der mobilen Anwendung und die Qualitt der Erfassungsmethoden
einschtzen zu knnen, wurden zwei Versuche gestartet. Bei diesen Versuchen ging
es vorrangig um die Funktionsfhigkeit von Server und App. Ein wissenschaftliches
Anspruch ist zwar gegeben, jedoch lie sich aus zeitlichen und technischen Grnden
keine komplexe Studie erstellen. Daher sind ihre Ergebnisse nicht reprsentativ.
6.1 Ziele des Experiments
Ziel ist es, zu berprfen, ob sich der Biorhythmus eines Probanden mit der Android
Umsetzung erfassen lsst. Mit Hilfe eines Umfragebogens sollen zudem subjektive
Auswirkungen und die Eignung der Umsetzung erfasst werden. Zudem sollen die
Erfassungsmethoden mit etablierten Umsetzungen verglichen werden.
6.2 Ablauf des ersten Experimentes
In der ersten Studie sollen die Probanden eine Testreihe auf ihrem Smartphone
in einem Zeitraum von einer Woche abarbeiten. Dies soll die Zuverlssigkeit und
Schwachstellen der Software aufzeigen. Zum Vergleich sollten die Probanden hnliche
Umsetzungen der Tests am PC durchfhren. Die Studie wurde im Zeitraum vom
16.11.2011 bis 26.11.2011 mit drei Probanden durchgefhrt. Die PC Tests fanden
im Zeitraum vom 10.12.2011 bis 12.12.2011 statt. Zustzlich fllten alle Probanden
ber PC- und Android-Umsetzung einen Fragebogen aus; dieser ist in Anhang D zu
sehen.
6.2.1 Versuchsaufbau
Die Tests wurden auf dem Smartphone alle 150 Minuten durchgefhrt. Jede Erfas-
sungsmethode sollte genutzt werden um die Durchfhrbarkeit im Alltag, die Ak-
zeptanz und die Auswirkungen auf die Probanden festzustellen. Am PC sollen ver-
gleichbare Tests durchgefhrt werden um die Ergebnisse validieren zu knnen.
Fabian Markert Seite 31 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Beginn der
Messung
Ende der
Messung
Testgert Android
Version
Proband 1 16.11.2011 24.11.2011 HTC Wildre 2.3.7
Proband 2 16.11.2011 24.11.2011 Samsung
Galaxy Ace
2.3.3
Proband 3 22.11.2011 26.11.2011 HTC Desire 2.3.7
Tabelle 6.1: Auistung des ersten Funktionstests der Probanden.
Erfassungs-
methode
Parameter Wert
vas3 question 2
vas2 question 0
vas0 question 1
numberPairs0 length 5
timeout 5000
posFirstValue 2
posSecondValue 4
roundCounts 28
confusion true
n-back0 n 1
displayTime 1500
length 20
displayValues 20
numberDigets true
pvt0 testTime 5
timeout 5000
minWaitTime 3
maxWaitTime 10
vas4 question 2
vas1 question 1
Tabelle 6.2: Parameter der VigilanzApp im ersten Versuch. Die Parameter sind an
bliche Versuchsablufe, wie sie in Kapitel 2 beschrieben sind angelehnt. Der
Parameter der vas ist in Tabelle 5.4 erlutert. Die des numberPairs sind in Tabelle
5.1 zu nden. Die Bedeutung der Einstellungen des n-back ist in Tabelle 5.3 zu
sehen und die des pvt benden sich in Tabelle 5.2. Die Anordnung der Zeilen
entspricht der Reihenfolge, in der die Erfassungsmethoden durchlaufen wurden.
Die Probanden wurden sowohl vor, als auch nach einer Versuchsreihe ber ihren
aktuellen Zustand befragt.
Fabian Markert Seite 32 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Erfassungs-
methode
Parameter Wert
pvt Testdauer 5 Minuten
Dual-n-Back n 1
Anzahl der
Versuche
20
Tabelle 6.3: Parameter der PC-Umsetzungen im ersten Versuch. Die Parameter sind
an die der VigilanzApp angelehnt, um eine Vergleichbarkeit der Auswirkungen der
PC-Tests mit denen der Android-Umsetzung zu ermglichen.
Als erste Schwierigkeit stellte sich heraus, dass fr den Number-Pairs Test zu diesem
Zeitpunkt keine Referenzimplementierung fr den PC verfgbar war. Zudem war nur
eine Umsetzung des Dual-n-Back Test verfgbar. Diese beinhaltet zwei Gedchtnis-
aufgaben, die umgesetzte Smartphone - Variante jedoch nur eine. Darber hinaus
erfasst sie die Daten nicht so umfangreich wie die Smartphone - Implementierung.
Somit ist kein direkter Vergleich mglich, sondern lediglich, ob die beiden Tests die
hnliche Resultate bei den Probanden zeigen.
6.2.2 Ergebnisse
In den Abbildungen 6.1, 6.2 und 6.3 sind die Ergebnisse der Studie zu sehen.
6.2.3 Interpretation
Anhand von Abbildung 6.1 ist zu erkennen, dass alle Probanden keinen klar erkenn-
baren Biorhythmus besitzen. Abbildung 6.2 zeigt, dass die Aufgabenstellung des n-
back auf dem Smartphone als verstndlicher empfunden wurde, als die PC-Version.
Der Schwierigkeitsgrad jedoch hher lag. Eine mgliche dafr ist Erklrung ist, dass
es sich bei der PC-Variante um den Dual-n-Back handelt und die zustzliche Ge-
dchtnisaufgabe einen hheren Schwierigkeitsgrad als die Smartphone-Umsetzung
besitzt.
In der Android-Umsetzung sind bei einem Probanden verstrkt Fehler aufgetreten,
da es sich um einen Prototypen handelt war dies zu erwarten. Ungeklrt ist jedoch,
was Fehler auftraten und ob diese das Testgerte oder das darauf installierte Be-
triebssystem als Ursache haben. Auf die Motivation hatten beide Varianten die selbe
Auswirkung.
In Abbildung 6.3 ist zu sehen, dass die Aufgabenstellungen in beiden Umsetzung
gleich gut Verstanden wird. In der Smartphone Umsetzung traten gelegentlich Fehler
auf, jedoch nicht so hug wie beim n-back-Test. Der Schwierigkeitsgrad wurde auf
dem PC geringfgig schwieriger empfunden als auf dem Smartphone, dafr konnte
keine Ursache ermittelt werden.
Fabian Markert Seite 33 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Abbildung 6.1: Ergebnisse der ersten Studie. Jede Teilgrak zeigt die VAS vor den
Tests sowie die Resultate des n-Back und des Dual-n-Back Test. Die VAS ist in
grn, der n-back in rot und der Dual-n-Back in schwarz dargestellt. Zudem sind
alle Resultate Rechts unten zusammengefasst zu sehen. Die X-Achse zeigt die
Tageszeit in Stunden und die Y-Achse die Anzahl korrekter Antworten in Pro-
zent. Die Daten des PVT und Number Pairs wurden nicht Visualisiert, da diese
einen hnlichen verlauf besitzen. In den VAS ist bei keinem Probanden ein kla-
rer Trend zu erkennen. Die meisten Ergebnisse des Dual-n-Back sind besser als
die der Android-Version. Bei Proband 3 gibt es groe Lcken in den Datenst-
zen der Smartphone Tests auf. Er hat am PC ebenfalls am wenigsten Testreihen
durchgefhrt.
Fabian Markert Seite 34 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Abbildung 6.2: Ergebnisse des Fragebogens zum n-Back-Test.
Abbildung 6.3: Ergebnisse des Fragebogens zum PVT-Test.
Fabian Markert Seite 35 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Gravierende Unterschiede gab es bei der Auswirkung auf die Motivation. Der Test
wurde von allen Probanden auf dem Smartphone als extrem Demotivieren einge-
stuft. Hierfr gibt es keine Erklrung. Die Testdauer wurde von allen Probanden in
beiden Umsetzungen als zu lang Empfunden. Eine mgliche Ursache ist, dass sich
die Probanden aufgrund des geringen Schwierigkeitsgrades unterfordert fhlen.
6.2.4 Fazit
Im Bezug auf die Ermittlung des Biorhythmus mittels der Smartphone - Implemen-
tierung konnte die Studie nicht die erhoten Ergebnisse erzielen. Mgliche Ursachen
dafr sind, dass die Probanden einen unregelmigen Tagesrhythmus besitzen und
zu wenig Daten erhoben wurden.
Als Funktionstest war die Studie jedoch ein Erfolg. Auf den meisten Testgerten
funktionierte die App stabil. Sie oenbarte Schwachstellen in der Umsetzung des
PVT. Dieser bedarf einer berarbeitung, da sich herausstellte, dass Fehleingaben des
Benutzers nicht ermittelt werden. Durch diesen Fehler ist es dem Probanden mglich
durch ununterbrochenes Antippen des Displays die Ergebnisse zu verflschen und
erzielt dadurch beispielsweise eine Reaktionszeit von 75 ms. Diese Zeit ist fr einen
normalen Menschen unmglich zu erreichen.
6.3 Ablauf des zweiten Experimentes
Diese Studie soll primr die Vergleichbarkeit mit bestehenden PC - Implementie-
rungen prfen. Hierzu haben zwei Probanden am 13.12.2011 sowohl am PC als auch
auf ihrem Smartphone vergleichbare Tests zehn Stunden lang durchgefhrt.
6.3.1 Versuchsaufbau
Erfasst werden sollten hierbei der Wachzustand und ob sich anhand der Testresultate
ein Biorhythmus erkennen lsst. Jeder Test wurde einmal pro Stunde erst am PC
und direkt danach auf dem Smartphone durchgefhrt.
6.3.2 Ergebnisse
Die Abbildungen 6.4 und 6.5 sind die Ergebnisse der zweiten Studie zu sehen.
Fabian Markert Seite 36 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Erfassungs-
methode
Parameter Wert
vas0 question 1
n-back0 n 2
displayTime 1500
length 20
displayValues 20
numberDigets true
pvt0 testTime 5
timeout 5000
minWaitTime 3
maxWaitTime 10
Tabelle 6.4: Parameter der VigilanzApp im zweiten Versuch. Der Number Pairs Test
wurde in diesem versuch weg gelassen, da keine vergleichbare PC - Implementie-
rung zur Verfgung stand. Beim n-Back Test wurde der Parameter n auf zwei
gesetzt, da diese Variante meist bei Erwachsenen genutzt wird.
Erfassungs-
methode
Parameter Wert
pvt Testdauer 5 Minuten
Dual-n-Back n 2
Anzahl der
Versuche
20
Tabelle 6.5: Parameter der PC-Umsetzungen im zweiten Versuch. Die zweite Auf-
gabe des Dual-n-Back wurde ignoriert um eine bessere Vergleichbarkeit von PC-
und Smartphone - Umsetzung zu ermglichen.
Fabian Markert Seite 37 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Abbildung 6.4: Ergebnisse des n-Back - Test der zweiten in Studie. Zu sehen ist der
n-Back der PC Variante in schwarz, die Smartphone Umsetzung in rot sowie die
VAS in grn.
Abbildung 6.5: Ergebnisse des PVT in der zweiten Studie.
Fabian Markert Seite 38 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
6.3.3 Interpretation
Es ist ein klarer verlauf in der VAS bei beiden Probanden zu erkennen. In Abbildung
6.4 ist bei beiden Probanden sieht man, dass sowohl PC- als auch Smartphone -
Varianten einen hnlichen Verlauf zu besitzen.
Allerdings werden bei der Android - Umsetzung bei allen Probanden bessere Re-
sultate erreicht werden knnen. Eine mgliche Ursache ist, dass der Test auf dem
Smartphone zu leicht ist. Allerdings wurden Tests kurz hintereinander durchgefhrt,
mglicherweise wurden die Probanden auf den zweiten Test vorbereitet, weil sie kurz
vorher eine hnliche Aufgabe bewltigen mussten.
Anhand des Verlaufs beider Kurven lsst sich kein Rckschluss auf den Biorhythmus
der Probanden treen. Hierzu ist eine lngere Erhebung von Messdaten erforderlich.
In Abbildung 6.5 kann man sehen, dass Proband 1 am PC immer sehr hnliche
Ergebnisse erzielen konnte, unabhngig von seinem Wachzustand. Auf dem Smart-
phone verschlechterten sich seine Werte jedoch kontinuierlich. Es ist mglich, dass
die Smartphone Variante aus noch unbekannten Grnden hier bessere Ergebnisse
erzielt. Eine weitere Ursache ist jedoch ebenfalls denkbar, die Konzentrationsfhig-
keit des Probanden lsst nach, weil er vorher schon die PC Variante durchlaufen
hat.
Beide Probanden erreichen in der Smartphone - Umsetzung schlechtere Ergebnisse
als auf dem PC. Es lsst sich sogar der Biorhythmus erahnen. Bei allen Probanden
steigt die Reaktionszeit auf dem Smartphone whrend der Wachzustand abnimmt.
Allerdings sind auch hier nicht genug Daten vorhanden um eine Qualitative Aussage
treen zu knnen.
6.3.4 Fazit
In Bezug auf Vergleichbare Ergebnisse zwischen Android- und PC - Umsetzung kann
dies beim n-Back mit Ja beantwortet werden. Bei allen Probanden zeigten sich auf
beiden Plattformen hnliche Ergebnisse. Beim PVT ist dies noch unklar, da bei
einem Probanden die Ergebnisse stark von einander abweichen.
ber den Biorhythmus lsst sich allerdings keine Aussage treen, da die Datenmenge
nicht ausreicht um Rckschlsse darauf zu ziehen.
Fabian Markert Seite 39 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
6.4 Auswertung des Fragebogen
Whrend der ersten Studie wurden den Probanden Fragen gestellt, wie sie die Arbeit
mir der App empfunden haben. An dieser Stelle werden die Ergebnisse aus dieses
Fragebogens vorgestellt.
PVT - Smartphone PVT - PC
Frage Proband
1
Proband
2
Proband
3
Proband
1
Proband
2
Proband
3
Verstndlich-
keit
100 100 100 100 100 100
Fehlerfreiheit 100 100 100 100 100 90
Schwierigkeit 100 80 95 100 100 100
Motivation 90 40 90 15 5 5
Versuchsdauer 20 50 35 30 5 45
Tabelle 6.6: Gegenberstellung der Umfrageergebnisse zum PVT. Die dargestellten
Werte wurden bereits in Abbildung 6.3 erlutert.
n-Back - Smartphone n-Back - PC
Frage Proband
1
Proband
2
Proband
3
Proband
1
Proband
2
Proband
3
Verstndlich-
keit
50 20 70 70 100 75
Fehlerfreiheit 100 100 100 100 25 100
Schwierigkeit 50 50 20 45 100 55
Motivation 70 60 50 60 20 80
Versuchsdauer 100 100 70 90 100 75
Tabelle 6.7: Gegenberstellung der Umfrageergebnisse zum n-Back. Die dargestell-
ten Werte wurden bereits in Abbildung 6.2 erlutert.
Fabian Markert Seite 40 von 44
6. Pilotexperiment Fachhochschule Schmalkalden WS 2011
Benachrichtigung - Smartphone
Frage Proband
1
Proband
2
Proband
3
Ausfallsicherheit 100 100 100
Wiederholungshugkeit 85 100 80
Neustart 100 50 100
Aufmerksamkeit 100 100 70
Tabelle 6.8: Antworten zu den Benachrichtigungen. Bei keinem der Probanden viel
eine Benachrichtigung aus. Die Anzahl der Wiederholungen wurde von zwei Pro-
banden als zu hoch angesehen. Nach einem Neustart des Smartphones wurden bei
Proband 2 Benachrichtigungen nicht immer fortgesetzt. Proband 3 hat Benach-
richtigungen nicht immer bemerkt.
Number Pairs - Smartphone
Frage Proband
1
Proband
2
Proband
3
Verstndlichkeit 100 100 100
Fehlerfreiheit 100 100 85
Schwierigkeit 75 100 85
Motivation 55 40 50
Versuchsdauer 95 100 90
Tabelle 6.9: Antworten zum Number Pairs Test. Alle Probanden fanden die Auf-
gabenstellung Verstndlich. Bei Proband 3 Traten gelegentlich Fehler auf und
es erschien ihm etwas zu schwer vom Schwierigkeitsgrad. Die Probanden fanden
den Test leicht Demotivierend. Alle Befragten empfanden die Versuchsdauer als
angenehm.
VAS - Smartphone
Frage Proband
1
Proband
2
Proband
3
Verstndlichkeit 100 100 100
Fehlerfreiheit 100 100 100
Schwierigkeit 100 100 100
Motivation 100 100 100
Versuchsdauer 100 100 100
Tabelle 6.10: Antworten zum VAS. Wie erwartet schnitt diese Erfassungsmethode
in allen belangen sehr Positiv ab, da sie sehr einfach in ihrem Ablauf und ihrer
Verstndlichkeit ist. Die kurze Dauer ist sehr motivierend.
Fabian Markert Seite 41 von 44
7 Fazit
Abschlieend lsst sich sagen, dass die Integration in den Alltag mit dieser Umset-
zung mglich ist. Das Politexperiment zeigte, dass die mobile Anwendung in den
meisten fllen stabil luft und es nur in Ausnahmefllen Strungen gab. Die Pro-
banden konnten ohne grere Probleme die Tests durchfhren.
Die Frage, ob der Biorhythmus erfasst werden kann, konnte jedoch nicht geklrt
werden. Die Probanden der ersten Studie nicht geeignet und die Datenmenge der
zweiten reichten nicht fr aus um die Frage zu beantworten. Es ist daher erforderlich,
weitere Studien mit mehr Probanden durchzufhren, um aussagekrftige Ergebnisse
ber die Stabilitt der App und der Erfassungsmethoden zu erhalten.
Es besteht noch Klrungsbedarf, ob die bisherigen Erfassungsmethoden ausreichend
sind, um die Diensttauglichkeit einschtzen zu knnen. Zudem gibt es noch keine
Erkenntnisse darber, wie eine Studie aufgebaut sein muss, die das beweisen soll.
Es ist ebenfalls nicht bekannt, ob fr alle Berufszweige die gleichen Gewichtungen
der Erfassungsmethoden gelten.
Fabian Markert Seite 42 von 44
8 Ausblick
Um die Anwendungen sinnvoll fortzufhren, ist es sinnvoll, Testflle zu erstellen und
die oenen Punkte zu beseitigen, um so Marktreife zu erreichen.
Im Pilotexperiment stellte sich heraus, dass es zur besseren Unterscheidung zwischen
den Probanden von Vorteil ist, wenn die grasche Oberche sowie der Server da-
hingehend erweitert werden, dass IDs von Nutzern mit einem eigenen Label getaggt
werden knnen.
Eine Umsetzung des Compensatory Tracking Task ist denkbar, sofern die Steue-
rung auf Smartphones angepasst wird. Hierzu kann ein fest denierter Bereich des
Displays genutzt werden, in dem beispielsweise ein Kreis zu sehen ist. Durch Wisch-
Gesten kann das Verhalten eines Trackballs nachempfunden werden.
Es ist ebenfalls mglich, den Server sowie die grasche Oberche in Form eines
Application-Servers neu zu implementieren und zu vereinen. Die grasche Oberche
ist in diesem Fall ein Webinterface. Ein bereits installiertes Verarbeitungsprogramm,
wie beispielsweise MATLAB, kann die Ergebnisdaten direkt bergeben bekommen,
um so Visualisierungen zu generieren und direkt im Browser darzustellen.
Ein weiterer Ansatz, der erst nach Fertigstellung der Anwendungen dem Autor be-
kannt wurde, ist die Implementierung mit Hilfe der Bibliothek Xamarin.Mobile wel-
che von der Firma Xamarin entwickelt wird. Diese erlaubt es, Apps in C#, be-
ziehungsweise dessen Open Source Pendant Mono, zu schreiben. Die Besonderheit
ist hierbei, dass Binarys fr Android, iOS und Windows Phone 7 aus dem selben
Quellcode generiert werden knnen. Dies erlaubt hhere Abstraktion und somit eine
plattformbergreifende Entwicklung der mobilen Anwendung. Damit ist eine weit
grere Verbreitung einer App mglich als eine reine Android Applikation. Geht
man von den Zahlen von Tablle 3.1 aus, einsprche einem Marktanteil von 69 % der
auf diese Weise abgedeckt werden kann, statt 52,5 % von Android.
Fabian Markert Seite 43 von 44
8. Ausblick Fachhochschule Schmalkalden WS 2011
Allerdings ist die Bibliothek noch nicht fertiggestellt und bietet daher noch keinen
Zugang zu allen Komponenten der drei mglichen Zielplattformen; beispielsweise
sind Benachrichtigungen derzeit noch nicht mglich. Zudem sind die notwendigen
Bibliotheken zur Untersttzung der jeweiligen Plattformen kostenpichtig und ms-
sen separat erworben werden. Die Kosten belaufen sich dabei je nach Lizenz auf
399 $ bis 2499 $ pro Plattform
1
. Dennoch bietet diese Bibliothek ein enormes Po-
tential um eine grere Verbreitung zu ermglichen
2
.
1
Quelle: [Xam11]
2
Vgl. [mig11]
Fabian Markert Seite 44 von 44
Literaturverzeichnis
[Bei11] Beier, Andreas: iOS-Programmierung. In: ct kompakt Programmieren
(02/2011)
[EE74] Eriksen, Barbara ; Eriksen, Charles: Eects of noise letters upon
the identication of a target letter in a nonsearch task. In: Attention,
Perception, & Psychophysics 16 (1974), 143-149. http://dx.doi.org/
10.3758/BF03203267. ISSN 19433921. 10.3758/BF03203267
[Fun04] Funke, Frederik: Vergleich Visueller Analogskalen mit Kategorialskalen
in Oine- und Onlinedesign, Justus-Liebig-Universitt Gieen, Magis-
terarbeit, 2004
[Gar11] Gartner, Inc.: Gartner Says Sales of Mobile Devices Grew 5.6 Percent
in Third Quarter of 2011; Smartphone Sales Increased 42 Percent. http:
//www.gartner.com/it/page.jsp?id=1848514. Version: November
2011
[Gra11] Graf, Oliver: Wasser in Sicht. http://www.smart-developer.
de/Online/Artikel/Grundlagen-zur-Bada-Entwicklung.
Version: November 2011
[LDR05] Lamond, Nicole ; Dawson, Drew ; Roach, Gregory D.: Fatigue As-
sessment in the Field: Validation of a Hand-Held Electronic Psychomotor
Vigilance Task. Paper, 2005
[Lin11] Linke, Andreas: Einstieg in Android. In: ct kompakt Programmieren
(02/2011)
[LJD
+
08] Lamond, Nicole ; Jay, Sara M. ; Dorrian, Jillian ; Ferguson, Sally A.
; Roach, Gregory D. ; Dawson, Drew: The sensitivity of a palm-based
psychomotor vigilance task to severe sleep loss. Paper, 2008
[LKT09] Ling, Jonathan ; Kritikos, Minos ; Tiplady, Brian: Cognitive eects
of creatine ethyl ester supplementation. In: Behavioural Pharmacolo-
gy 20 (2009), Nr. 8, 673679. http://www.ncbi.nlm.nih.gov/pubmed/
19773644
[mig11] migueldeicaza: Introducing the Xamarin Mobile API. http://blog.
xamarin.com/2011/11/22/introducing-the-xamarin-mobile-api/.
Fabian Markert
IX
Literaturverzeichnis Fachhochschule Schmalkalden WS 2011
Version: November 2011
[MJ95] Makei, Scott ; Jolle, Keith: COMPTRACK A Compensatory Tracking
Task for Monitoring Alertness. 1995
[RDL06] Roach, Gregory D. ; Dawson, Drew ; Lamond, Nicole: Can A Shorter
Psychomotor Vigilance Task Be Used As A Reasonable Substitute For
The Ten-Minute Psychomotor Vigilance Task? Paper, 2006
[Sch09] Schoofs, Daniela: Psychosozialer Stress, die endokrine Stressreakti-
on und ihr Einuss auf Arbeitsgedchtnisprozesse, Ruhr-Universitt Bo-
chum, Diss., 07 2009
[Sch11a] Schleicher, Ronny: Entwicklung einer Windows Phone 7 Applikation
unter Verwendungmoderner imperativer und funktionaler Sprachelemen-
te, Fachhochschule Schmalkalden, Masterarbeit, 2011
[Sch11b] Schulz, Hajo: Entwickeln fr Windows Phone 7. In: ct kompakt Pro-
grammieren (02/2011)
[Sta11] Stallenberger, Sebastian: Entwicklung einer auf Scalabasierenden
Android-Applikation fr das Hochschul-Informationssystem Spirit der Fa-
kultt Informatik an der Fachhochschule Schmalkalden, Fachhochschule
Schmalkalden, Masterarbeit, 2011
[TRSB05] Thorne, David R. ; Redmond, Dagny E. Johnson Daniel P. ; Sing,
Helen C. ; Belenky, Gregory: The Walter Reed palm-held psychomotor
vigilance test. Paper, 2005
[Wat85] Watanabe, I: Eects of noise letters upon selective identication of
letters. In: Shinrigaku kenkyu The Japanese journal of psychology 56
(1985), Nr. 3, S. 125131
[Wik11a] Wikipedia: Android (Betriebssystem) Wikipedia, Die freie En-
zyklopdie. http://de.wikipedia.org/w/index.php?title=Android_
(Betriebssystem)&oldid=92745675. Version: 2011. [Online; Stand
24. August 2011]
[Wik11b] Wikipedia: Apple iOS Wikipedia, Die freie Enzyklopdie. http://
de.wikipedia.org/w/index.php?title=Apple_iOS&oldid=95835671.
Version: 2011. [Online; Stand 14. November 2011]
[Wik11c] Wikipedia: Bada (Betriebssystem) Wikipedia, Die freie En-
zyklopdie. http://de.wikipedia.org/w/index.php?title=Bada_
(Betriebssystem)&oldid=96000992. Version: 2011. [Online; Stand
18. November 2011]
[Wik11d] Wikipedia: BlackBerry Wikipedia, The Free Encyclopedia.
Fabian Markert
X
Literaturverzeichnis Fachhochschule Schmalkalden WS 2011
http://en.wikipedia.org/w/index.php?title=BlackBerry&oldid=
461278256. Version: 2011. [Online; accessed 18-November-2011]
[Wik11e] Wikipedia: N-back Wikipedia, Die freie Enzyklopdie. http:
//de.wikipedia.org/w/index.php?title=N-back&oldid=96860730.
Version: 2011. [Online; Stand 10. Dezember 2011]
[Wik11f] Wikipedia: Open Handset Al liance Wikipedia, Die freie Enzyklop-
die. http://de.wikipedia.org/w/index.php?title=Open_Handset_
Alliance&oldid=89708116. Version: 2011. [Online; Stand 24. August
2011]
[Wik11g] Wikipedia: Sicherheitsfahrschaltung Wikipedia, Die freie
Enzyklopdie. http://de.wikipedia.org/w/index.php?title=
Sicherheitsfahrschaltung&oldid=92991999. Version: 2011. [Onli-
ne; Stand 9. Dezember 2011]
[Wik11h] Wikipedia: Totmanneinrichtung Wikipedia, Die freie En-
zyklopdie. http://de.wikipedia.org/w/index.php?title=
Totmanneinrichtung&oldid=94982200. Version: 2011. [Online;
Stand 9. Dezember 2011]
[Xam11] Xamarin: Store / Xamarin. https://store.xamarin.com/.
Version: November 2011
Fabian Markert
XI
A Android-Applikation

























































Abbildung A.1: Klassendiagramm der Android-Applikation
Fabian Markert
XII
B Server-Anwendung







































Abbildung B.1: Klassendiagramm der Server-Anwendung
Fabian Markert
XIII
C grasche Oberche
Abbildung C.1: Anmeldebildschirm der graschen Oberche. Der Nutzer muss
Adresse und Port des Servers sowie Benutzername und Passwort angeben.
Fabian Markert
XIV
C. grasche Oberche Fachhochschule Schmalkalden WS 2011
Abbildung C.2: Screenshot des Hauptfensters der graschen Oberche. Abschnitt
1 zeigt die Studien, die auf dem Server liegen. An dieser Stelle knnen neue Stu-
dien erstellt oder gelscht werden. Sobald eine Studie angeklickt wird, wird die
aktuelle Konguration ausgelesen und in Abschnitt 2 dargestellt. In diesem Ab-
schnitt knnen neue Tests hinzugefgt oder entfernt werden. Die Reihenfolge von
oben nach unten entspricht auch derjenigen, welche die Smartphones danach ab-
arbeiten. In Abschnitt 3 wird festgelegt, um welche Testart es sich handelt. Je
nach dem, welcher Tab ausgewhlt ist, ndern sich die Anzeigen in Abschnitt 2
und 4.
Abschnitt 4 ist der Anzeigebereich, der fr das Einstellen der Parameter der jewei-
ligen Tests gedacht ist. Sollten fr einen Test noch Zusatzdaten bentigt werden,
knnen diese ber Abschnitt 5 ausgewhlt werden. Nach dem Auswhlen ms-
sen die aktuellen nderungen gespeichert (Abschnitt 7) und die aktuelle Version
hochgeladen werden (Abschnitt 8).
In Abschnitt 6 kann eingestellt werden, wie viel Zeit zwischen einer Testserie ver-
gehen soll. Nach jeder nderung an der Konguration muss diese mit Hilfe von
Abschnitt 7 gespeichert werden. Wenn alle nderungen abgeschlossen wurden,
knnen sie mittels Abschnitt 8 hochgeladen werden.
Die Sprache, das Benutzerpasswort und das Anlegen neuer Nutzer ist ber Ab-
schnitt 9 mglich.
Fabian Markert
XV
D Fragebogen des Pilotexperiments
Fabian Markert
XVI
Benachrichtigungen
Sind Benachrichtigungen ausgefallen?
Immer Nie
Die Anzahl der Wiederholungen war angemessen.
Trit nicht
zu
Trit zu
Nach einem Neustart Ihres Smartphones wurden die Benachrichtigungen fortgesetzt?
Trit nicht
zu
Trit zu
Ich habe die Benachrichtigungen bemerkt.
nie bemerkt
immer
bemerkt
Number Pairs
Die Aufgabenstellung ist verstandlich.
Trit nicht
zu
Trit zu
Traten haug Fehler auf?
nie immer
Wie fordernd war der Schwierigkeitsgrad des Testablaufs?
sehr
fordernd
Kinderspiel
Welche Auswirkung hatte der Testablauf auf ihre Motivation?
demoti-
vierend
auerst
motivierend
Die Versuchsdauer war angemessen.
zu lang angenehm
1
PVT
Die Aufgabenstellung ist verstandlich.
Trit nicht
zu
Trit zu
Traten haug Fehler auf?
nie immer
Wie fordernd war der Schwierigkeitsgrad des Testablaufs?
sehr
fordernd
Kinderspiel
Welche Auswirkung hatte der Testablauf auf ihre Motivation?
demoti-
vierend
auerst
motivierend
Die Versuchsdauer war angemessen.
zu lang angenehm
n-back
Die Aufgabenstellung ist verstandlich.
Trit nicht
zu
Trit zu
Traten haug Fehler auf?
nie immer
Wie fordernd war der Schwierigkeitsgrad des Testablaufs?
sehr
fordernd
Kinderspiel
Welche Auswirkung hatte der Testablauf auf ihre Motivation?
demoti-
vierend
auerst
motivierend
Die Versuchsdauer war angemessen.
zu lang angenehm
2
VAS
Die Aufgabenstellung ist verstandlich.
Trit nicht
zu
Trit zu
Traten haug Fehler auf?
nie immer
Wie fordernd war der Schwierigkeitsgrad des Testablaufs?
sehr
fordernd
Kinderspiel
Welche Auswirkung hatte der Testablauf auf ihre Motivation?
demoti-
vierend
auerst
motivierend
Die Versuchsdauer war angemessen.
zu lang angenehm
Sonstige Anregungen:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Eidesstattliche Erklrung
Ich versichere an Eides Statt durch meine eigenhndige Unterschrift, dass ich die
vorliegende Arbeit selbststndig und ohne fremde Hilfe angefertigt habe. Alle Stel-
len, die wrtlich oder dem Sinn nach auf Publikationen oder Vortrgen anderer
Autoren beruhen, sind als solche kenntlich gemacht. Ich versichere auerdem, dass
ich keine andere als die angegebene Literatur verwendet habe. Diese Versicherung
bezieht sich auch auf alle in der Arbeit enthaltenen Zeichnungen, Skizzen, bildlichen
Darstellungen und dergleichen.
Die Arbeit wurde bisher keiner anderen Prfungsbehrde vorgelegt und auch noch
nicht verentlicht.
Oberweid,
den 17.12.2011
Ort, Datum Fabian Markert
Fabian Markert
XX