Ein Orientierungssystem für Menschen mit Sehbehinderung auf Java ME: Konzeption und Implementierung (eBook)

Daniel Hänßgen, geboren 1987 in Heidelberg. Bereits als Jugendlicher begeisterte sich der Autor sowohl für Technik als auch für Musik und besuchte ein technisches Gymnasium. Nach dem Abitur eröffnete er das STANZA-Tonstudio und begann sein Studium der Angewandten Informatik an der Fachhochschule Hannover, das er 2010 erfolgreich mit dem akademischen Grad Bachelor of Science abschloss und zurzeit im Masterstudiengang fortsetzt. Er wohnt auf 24 Quadratmetern irgendwo in Hannover, kocht mit Wasser und ersteigerte jüngst einen roten Pullover bei einem Internetauktionshaus.

Inhaltsverzeichnis 3
Abbildungsverzeichnis 5
Kapitel 1 Einleitung 7
1.1 Erläuterungen zur Gliederung 8
1.2 Typografische Konventionen 8
Kapitel 2 Anforderungsanalyse 9
2.1 Motivation 9
2.2 Zielsetzung 10
2.2.1 Abgrenzung 10
2.2.2 Funktionale Anforderungen 10
2.2.3 Informationsquellen 11
2.2.4 Technische Anforderungen 11
2.2.5 Nichtfunktionale Anforderungen 12
2.3 OpenStreetMap 12
2.3.1 Geschichte 12
2.3.2 Lizenz 13
2.3.3 Technik 13
2.3.4 Datenquellen und Quellformate 14
2.3.5 Details zum Datenformat 15
2.3.6 Informationsdichte 18
2.4 GPS 19
2.4.1 NMEA-Protokoll 19
2.5 Begriffserklärung: Kurs, Sollkurs und Peilung 22
2.6 Richtungsabhängige Vibration 23
Kapitel 3 Analyse 25
3.1 Paketstruktur 25
3.2 Klassendiagramme 28
3.2.1 View-Klassen 28
3.2.2 Main-Klasse 32
3.2.3 GPS-Paket 33
3.2.4 OSM-Paket 34
3.2.5 Util-Paket 36
3.2.6 Datastore-Paket 38
3.2.7 Entity-Paket 40
3.3 Sequenzdiagramme 42
3.3.1 Starten der Anwendung 42
3.3.2 GPS-Daten lesen 43
3.3.3 Umgebungssuche 44
3.3.4 Stichwortsuche 45
3.3.5 Favoriten speichern 46
3.3.6 Punkt als Favoriten speichern 47
3.3.7 Einfaches Beispiel für die Verwendung von SimpleInput-View 48
Kapitel 4 Entwurf 49
4.1 Exkurs: Java ME 49
4.1.1 MIDlet 50
4.1.2 Erschwerte Bedingungen durch Signierung 51
4.1.3 Screenreader-freundlich mit Java ME 51
4.2 Beziehungen zwischen den Klassen 53
4.3 Zustandsdiagramme 55
4.3.1 Zustandsdiagramm – GPSCheck 55
4.3.2 Zustandsdiagramm – Favoriten hinzufügen 57
4.4 Zerlegung in Teilsysteme 58
Kapitel 5 Implementierung 59
5.1 Binäres Kartenformat 59
5.1.1 Format 60
5.1.2 Tags-Tabelle 60
5.1.3 Erstellung und Benutzung der binär-codierten Datei 61
5.2 Implementierungsdetails 62
5.2.1 Klasse FavoriteStore 62
5.2.2 Klasse ActualPosition 63
5.2.3 Klasse AlertManager 63
5.2.4 Klasse NodeManager 65
Kapitel 6 Zusammenfassung und Ausblick 69
6.1 Zusammenfassung 69
6.2 Ausblick 72
Kapitel 7 Anhang 73
Anhang A Anwendungsfälle 75
A.1 Lizenzbedingungen 75
A.2 Favoriten-Verwaltung 76
A.3 GPS-Status anzeigen 80
A.4 Wo bin ich? (Nächstgelegene Adresse und Ort) 81
A.5 Umgebungssuche 82
A.6 Stichwortsuche 85
A.7 Einstellungen 86
A.8 Sonstiges 89
Literaturverzeichnis 91

Textprobe: Kapitel 2.2.2, Funktionale Anforderungen: Beim Starten der Anwendung muss ein Hinweis auf die verwendete Lizenz der Kartendaten angezeigt werden. Diese Funktion darf nicht abschaltbar sein. Das System soll speziell für die Bedürfnisse von Menschen mit Sehbehinderung entwickelt werden. Daher ist es erforderlich, dass keine Grafiken verwendet werden. Die Ausgabe darf nur aus Text bestehen, der von einem Screenreader gelesen werden kann. Ein Screenreader ist eine Anwendung, die im Hintergrund läuft und vorliest, was auf dem Display eines Gerätes als Text dargestellt wird. Für eine solche Software ist die Erkennung von Text in Bildern nicht möglich. Zum einen ist der rechnerische Aufwand zu groß, als dass ein mobiles Endgerät eine Texterkennung durchführen könnte. Zum anderen ist die Auflösung der Grafiken aufgrund des kleinen Displays zu gering, um eine hohe Erkennungsrate der Buchstaben zu erzielen. Konkret wird vorausgesetzt, dass mindestens der Screenreader 'Talks' der Firma Nuance unterstützt wird. Es soll die Möglichkeit bestehen, sich ausgeben zu lassen, wo man sich gerade befindet. Dies soll mittels Angabe von Straße und Hausnummer sowie Ort bzw. Stadtteil geschehen. Falls keine Hausnummer vorhanden ist, soll die nächste Kreuzung oder Einmündung angegeben werden. Mindestens für Testzwecke soll es möglich sein, sich die Koordinaten ansagen zu lassen, die gerade vom GPS Empfänger kommen. Es soll möglich sein, persönliche Favoriten sowohl über die direkte Eingabe von Name und geografischen Koordinaten als auch durch einen vorhanden Punkt aus den Kartendaten abzulegen. Es soll möglich sein, sowohl die Distanz zu einem Punkt aus den Kartendaten als auch die Richtung, in der er sich befindet, berechnen zu lassen. Dies gilt auch für persönliche Favoriten. Die Richtung soll dabei in Himmelsrichtungen oder auf der Uhr, also relativ zur Bewegungsrichtung, ansagbar sein. Bei Verlust eines gültigen GPS Signals soll dies mit einstellbarer Verzögerung ausgegeben werden. Auch das Wiedererlangen eines gültigen GPS Signals soll ausgegeben werden. Die OpenStreetMap Karte liefert weltweite Daten. Daher ist es erforderlich, dass auch die Anwendung weltweit agieren kann. Das bedeutet, dass eine Schrift und Sprachenunabhänigkeit zu den Kernanforderungen gehört. Obschon das System speziell für Menschen mit Sehbehinderung entwickelt wird, soll eine Bedienung durch sehende Menschen ebenso möglich sein. So sollen beispielsweise TrainerInnen, Familienmitglieder oder FreundInnen in der Lage sein, den Nutzer beziehungsweise die Nutzerin beim Erlernen der Bedienung des Systems zu unterstützen. 2.2.3, Informationsquellen: Als Informationsquellen standen mir folgende Personen und Dokumente zur Verfügung: Die Initiatorin des LoroDux Projektes, Annette Thurow. Die deutsche Mailingliste BlindNaviOSM, die sich speziell mit Navigation für Menschen mit Sehbehinderung befasst beziehungsweise deren angemeldete und fleißig Anforderungen aufnehmende NutzerInnen. Durch diese Mailingliste konnte ich viel über die besonderen Bedürfnisse von Menschen mit Sehbehinderung in Erfahrung bringen. Ein Dokument des Deutschen Blinden und Sehbehindertenverbandes e.V. (DBSV). In diesem Dokument hat der DBSV im Jahr 2008 umfassende Informationen über die Anforderungen, die an ein Orientierungssystem für Menschen mit Sehbehinderung gestellt werden, und die Bedürfnisse, die diese Menschen haben, sehr detailliert zusammengetragen. Da das Dokument aber von Menschen verfasst wurde, die über keine umfassenden Kenntnisse der technischen Möglichkeiten verfügen, finden sich in diesem auch sehr unrealistische Anforderungen. Beispielsweise soll die Positionierungsbestimmung auf einen Meter genau sein, was mit handelsüblichem GPS nicht realisierbar ist. Zu diesen Quellen kommt noch das Wiki von LoroDux hinzu. Es war zu großen Teilen bereits zu Beginn der Bachelorarbeit sehr umfangreich und wurde während der Entwicklung des Systems sogar noch erweitert. Allerdings ist eine weitreichende Fehlerfreiheit bislang noch nicht vorhanden, sodass die dort gemachten Angaben nur unter Vorbehalt verwendet werden sollten. 2.2.4, Technische Anforderungen: An das zu entwickelnde mobile System werden folgende technischen Anforderungen gestellt: Die Programmiersprache muss Java ME sein. Die Begründung hierfür ist, dass Java ME plattformunabhängig ist. Das bedeutet, dass theoretisch das gleiche Programm auf verschiedenen mobilen Plattformen ohne Anpassung an das verwendete Betriebssystem lauffähig ist auch auf älteren Geräten. Somit bietet sich Java ME auch für die Verwendung in so genannten Dritte Welt Ländern an. Außerdem existiert für Java ME eine Entwicklungsumgebung (IDE), die für Menschen mit Sehbehinderung gut bedienbar ist. Damit eröffnet sich auch für die Zielgruppe des Systems die Möglichkeit der Weiterentwicklung. Das zur Verwendung kommende mobile Endgerät muss über eine Bluetooth Schnittstelle verfügen, um sich mit Bluetooth GPS Empfängern verbinden zu können. Die logische Konsequenz aus dieser Anforderungen ist, dass ein GPS Empfänger ebenfalls über eine Bluetooth Schnittstelle verfügen muss. Wie bereits erwähnt, stammen die Begründungen und Entscheidungen in diesem Kapitel nicht von mir, sondern sind aus den oben genannten Informationsquellen entnommen.