I. Abbildungsverzeichnis
1 Einleitung
1.1 Motivation
1.2 Aufbau der Arbeit
2 Aufgabenstellung
2.1 Beispielszenario
2.2 Die Aufgabe
2.3 Anforderungen
2.3.1 Technische Anforderungen
2.3.2 Anforderungen bezüglich des Funktionsumfangs
2.3.3 Anforderungen der Zielgruppe
2.4 Abgrenzung
3 Grundlagen und Technologien
3.1 Aktuelle Werkzeuge zur Fahrzeugverwaltung im Automobilhandel
3.1.1 Dealer-Management-Systeme
3.1.2 Stand-Alone-Lösungen für die Online-Fahrzeugvermarktung
3.2 Java Plattformen für mobile und stationäre Endgeräte
3.2.1 Java 2 Micro Edition (J2ME)
3.2.2 Java 2 Standard Edition (J2SE)
3.3 Bluetooth und Java
4 Konzeption
4.1 Der Gesamtprozess
4.2 Grundsatzentscheidungen
4.2.1 Programmiersprache
4.2.2 Datenbank
4.2.3 Anforderungen an das Mobiltelefon
4.3 Anwendungsteil Mobiltelefon
4.3.1 Funktionen
4.3.2 Grundstruktur
4.3.3 Benutzeroberfläche
4.3.4 Datenverwaltung
4.3.5 Kommunikation
4.4 Anwendungsteil Personal Computer
4.4.1 Funktionen
4.4.2 Grundstruktur
4.4.3 Benutzeroberfläche
4.4.4 Datenverwaltung
5 Implementierung
5.1 Anwendungsteil Mobiltelefon
5.1.1 Klassenstruktur
5.1.2 Funktionsübergreifende Eigenschaften und Strukturen
5.1.3 Fahrzeug erfassen
5.1.4 Datenübertragung
5.1.5 Einstellungen
5.2 Anwendungsteil Personal Computer
5.2.1 Klassenstruktur
5.2.2 Datenbankzugriffe
5.2.3 Systemstart, Konfiguration, Logging
5.2.4 Benutzeroberfläche
5.2.5 Das Fahrzeug-Objekt
5.2.6 Die Fahrzeugliste
5.2.7 Das Fahrzeugformular
5.2.8 Mobiltelefonimport
5.2.9 Datenexport
6 Evaluierung der Ergebnisse
6.1 Anwendungsteil Mobiltelefon
6.2 Anwendungsteil Personal Computer
7 Schlussbetrachtung und Ausblick
7.1 Fazit
7.2 Ausblick
Literaturverzeichnis
A. Anhang
A.1. Beispiel für einen XML-Fragenkatalog:
A.2. Beispiel für die XML-Fahrzeugdaten eines Fahrzeugs:
A.3. Beispiel für die Logdatei des Anwendungsteils Personal Computer:
A.4. Beispiel Konfigurationsdatei
A.5. Beispiel Schnittstellenbeschreibung autoscout24.de:
Abbildung 1: Übersicht Java 2 Plattformen
Abbildung 2: Der Gesamtprozess
Abbildung 3: Diagramm: Neues Fahrzeug (Mobiltelefon)
Abbildung 4: Datenübertragung in logischen Einheiten
Abbildung 5: Grundstruktur Mobiltelefon
Abbildung 6: Client-Server-Architektur für die Bluetooth-Umgebung
Abbildung 7: Phasen des Datenexports
Abbildung 8: Grundstruktur Personal Computer
Abbildung 9: Konzeptioneller Aufbau der Benutzeroberfläche
Abbildung 10: Datenbankmodell
Abbildung 11: Klassendiagramm Mobiltelefon
Abbildung 12: Der Mediator und die Kollegenobjekte
Abbildung 13: Interaktionsdiagramm für die Funktion: "Neues Fahrzeug"
Abbildung 14: Vereinfachtes Interaktionsdiagramm für den Verbindungsaufbau (Mobiltelefon)
Abbildung 15: MVC-Architektur am Beispiel Fahrzeugübersicht
Abbildung 16: Klassendiagramm der Hauptklassen (PC)
Abbildung 17: Beteiligte Klassen bei der Funktion "Neues Fahrzeug"
Abbildung 18: Beteiligte Klassen beim Mobiltelefonimport
Abbildung 19: Beteiligte Klassen beim Datenexport
Abbildung 20: Taskleistensymbol mit Kontextmenü
Abbildung 21: Screenshot Anwendungshauptfenster
Abbildung 22: Screenshot TabFolder Fahrzeugformular
Abbildung 23: Eclipse Forms Section
Abbildung 24: Das MobileFahrzeugeData-Objekt
Abbildung 25: Erste Seite des Wizards "Übernommene Fahrzeuge"
Abbildung 26: Wizard "Fragenkatalog verwalten"
Abbildung 27: Wizard „Datenexport“
Das Internet gewinnt im professionellen Fahrzeugvertrieb zunehmend an Bedeutung, insbesondere die Vermarktung von Gebrauchtwagen kann durch eine Publikation in den einschlägigen Online-Fahrzeugbörsen positiv unterstützt werden. Der Vertriebskanal Internet wird jedoch von vielen Autohäusern und Gebrauchtwagenhändlern nicht ausreichend beachtet, Fahrzeugangebote sind oft nicht auf dem aktuellen Stand oder enthalten nur ein Minimum an Informationen. Dies liegt zum einen an der Unterschätzung des Potentials des Mediums, zum anderen an der zeitaufwändigen Pflege des Online-Fahrzeugbestands.
Die Diplomarbeit setzt an letztgenanntem Punkt an: der zeitaufwändigen Pflege des Online- Fahrzeugbestands. Der Gesamtprozess soll mit Hilfe einer neuen Anwendung vereinfacht und beschleunigt werden. Dort, wo aktuell Fahrzeugdaten für eine spätere Veröffentlichung im Internet mit einem Notizblock festgehalten werden und Fahrzeugbilder mit Hilfe einer Digitalkamera erstellt werden, soll in Zukunft ein Mobiltelefon als mobiles Datenerfassungsgerät den Prozess der Datenerfassung erleichtern.
Die auf dem Mobiltelefon gespeicherten Fahrzeuginformationen können dann zur weiteren Bearbeitung drahtlos auf einen Arbeitsplatzrechner übertragen werden. Der Personal Computer bildet die Schnittstelle zu den Online-Fahrzeugbörsen. Durch einen Knopfdruck kann der gesamte Fahrzeugbestand im Rahmen einer Fahrzeugbörse im Internet veröffentlicht werden.
Zur Entwicklung dieser Anwendung erfolgen zunächst eine Analyse der Ist-Situation und eine klare Definition der Anforderungen. Nach der Festlegung der Ziele folgt eine Auseinandersetzung mit aktuell verfügbaren Technologien und Grundlagen, die für die weitere Konzeption der Anwendung berücksichtigt werden müssen.
Die Konzeption unterteilt sich nach der genauen Definition des Gesamtprozesses in zwei elementare Anwendungsteile. Die Trennung des Systems erfolgt aufgrund der Verteilung der Anwendung auf zwei verschiedene Endgeräte, zum einem das Mobiltelefon, zum anderen der Personal Computer.
Wie schon bei der Konzeption erfolgt bei der Implementierung ebenfalls eine individuelle Betrachtung der beiden Anwendungsteile. Das Mobiltelefon stellt aufgrund der begrenzten Systemressourcen spezielle Anforderungen an die Architektur und Vorgehensweisen. Der Schwerpunkt des nicht mobilen Anwendungsteils liegt hingegen bei der Umsetzung der Anforderungen bezüglich der Benutzerfreundlichkeit. Durch den Einsatz von innovativen Bedienelementen und Methoden soll der Umgang mit der Anwendung auch einem weniger versierten Benutzer ermöglicht werden.
Die Diplomarbeit enthält zudem eine Evaluation der Ergebnisse und einen Ausblick auf die Weiterentwicklung und zukünftige Vermarktungsmöglichkeiten der Anwendung.
Seit dem Jahr 2000 hat sich die Internetnutzung in Deutschland verdoppelt. Mittlerweile sind 55% der deutschen Bevölkerung online1, eine ähnliche Erfolgsgeschichte erlebte das Automobil im 20. Jahrhundert. Im Jahre 2004 belief sich der Fahrzeugbestand (PKW) laut dem statistischen Bundesamt in Deutschland auf über 54 Millionen Fahrzeuge2.
Es dauerte nicht lange, bis Ende der neunziger Jahre des vergangenen Jahrhunderts die ersten Online-Fahrzeugbörsen ihre virtuellen Pforten öffneten. Online-Fahrzeugbörsen wie Autoscout24.de, Mobile.de oder aber auch eBay-Motors spielen heute eine große Rolle in der Online-Landschaft.
Auch der klassische Fahrzeugeinzelhandel reagierte im Laufe der Jahre auf die neuen Rahmenbedingungen, so gibt es mittlerweile kaum ein Autohaus ohne einen eigenen Internetauftritt. Die interne Kommunikation zwischen Automobilherstellern und -händlern wurde ebenfalls durch das neue Medium revolutioniert. Markengebundene Fahrzeughändler bestellen ihre Fahrzeuge und Ersatzteile online. Hierfür bietet beinahe jeder Automobilhersteller eine eigene Online-Plattform bzw. ein eigenes Extranet.
Das Internet spielt demnach eine bedeutende Rolle in der Automobilbranche. Es mangelt teilweise jedoch noch an der Medienkompetenz und Akzeptanz. Zudem sind die Internetseiten häufig schlecht umgesetzt und die Benutzerfreundlichkeit lässt zu wünschen übrig. Die im Internet präsentierten Inhalte sind oft qualitativ ungenügend und zudem sehr oft veraltet. Die Aktualität der Inhalte ist ein sehr großes Problem, da das Zeitmanagement oft noch nicht an die neue Situation angepasst wurde. Im Tagesablauf eines Automobilverkäufers bleibt kaum Zeit für die Aktualisierung der Internetseite bzw. der Datenbestände bei den Fahrzeugbörsen. In der Praxis werden oft bereits verkaufte Autos noch wochenlang über das Internet zum Verkauf angeboten. Diesen Missstand gilt es zu beseitigen; zum einen durch eine Verbesserung des Zeitmanagements und zum anderen durch eine Optimierung der Prozesse.
Diese Diplomarbeit beschäftigt sich mit dem Prozess, wie ein Fahrzeughändler ein Auto mit Hilfe eines Mobiltelefons einfach und schnell in eine Online-Fahrzeugbörse einstellen kann. Das Mobiltelefon dient dabei zur Dateneingabe, aber auch zur visuellen Darstellung, d.h. es werden Fahrzeugfotos mit Hilfe der integrierten Digitalkamera erstellt. Als überragenden Vorteil gegenüber bisherigen Lösungen ist die direkte elektronische Datenerfassung am Fahrzeug und die drahtlose Übertragung der Daten auf den Personal Computer des Verkäufers zu erwähnen.
Die Datenerfassung mit einem Mobiltelefon stößt jedoch schnell an ihre Grenzen: Es wird nur wenige Anwender geben, die einen Beschreibungstext für ein Fahrzeug mit Hilfe einer Mobiltelefontastatur eingeben möchten. Genau diese Anforderungen und Einschränkungen gilt es bei der Konzeption ebenso zu berücksichtigen, wie diverse technische Einschränkungen und Gegebenheiten. Insbesondere die Leistungsfähigkeit des Mobiltelefons stößt hinsichtlich Batterieleistung, Prozessorleistung und Speicherkapazität schnell an ihre Grenzen.
Die Zielsetzung der Diplomarbeit besteht darin, eine Anwendung für die Bedürfnisse der Anwender zu konzeptionieren und dabei die technischen Rahmenbedingungen optimal auszunutzen. Die prototypische Umsetzung dient hierbei als Beweis der Realisierbarkeit, der Prototyp wird jedoch nur den Grundprozess abbilden können, Zusatzfunktionen wie z.B. die Bildbearbeitung oder die automatisierte Erstellung von Preisschildern für das erfasste Fahrzeug können im zeitlich begrenzten Rahmen einer Diplomarbeit nicht verwirklicht werden.
Die Arbeit folgt der chronologischen Abfolge der Bearbeitung des Themas. Durch die Besonderheit, dass die zu entwickelnde Anwendung sich auf zwei Anwendungsteile, die jeweils auf einem eigenen Endgerät betrieben werden, verteilt, spiegelt sich diese Zweiteilung auch im Aufbau der einzelnen Kapitel wieder, d.h. es wird grundsätzlich zwischen dem „Anwendungsteil Mobiltelefon“ und dem „Anwendungsteil Personal Computer“ unterschieden, da sich die Konzeption und Implementierung der einzelnen Anwendungsteile gänzlich unterscheiden.
Die Aufgabenstellung wird im zweiten Kapitel erläutert, dabei dient ein Beispielszenario zur Einordnung der Arbeit. Die Anforderungen werden anschließend anhand des Beispielszenarios abgeleitet. Die direkte Ableitung der Anforderungen soll deren Legitimation festigen. Da der Bearbeitungszeitraum der Diplomarbeit begrenzt ist, wird der Umfang der zu entwickelnden Anwendung im Gliederungspunkt Abgrenzung genau festgelegt.
Der tatsächliche Einstieg in die Thematik erfolgt im dritten Kapitel. Zu Beginn werden aktuelle Softwareprodukte des Automobilhandels vorgestellt. Dies dient zur Einschätzung der gegenwärtigen Marktsituation im Bereich der spezifischen Softwareangebote für den professionellen Fahrzeugvertrieb. Des Weiteren erfolgt im selben Kapitel ein Überblick über die zum Einsatz kommenden Technologien, wobei sich diese Grundtechniken wiederum in die zwei Hauptbereiche, mobiltelefonspezifische Techniken und Desktopanwendungen, unterteilen lassen.
Das vierte Kapitel beinhaltet den konzeptionellen Teil der Diplomarbeit. Das Kapitel beginnt mit einer genauen Beschreibung des Gesamtprozesses und der Festlegung einiger Grundsatzentscheidungen. Nach diesen grundsätzlichen Überlegungen erfolgt die Aufteilung in die zwei Hauptanwendungsteile. Dabei wird jeder Anwendungsteil bezüglich der Grundstruktur, der geforderten Funktionen, der Benutzeroberfläche, der Datenverwaltung und der Kommunikation untersucht.
Die Beschreibung und das Vorgehen der Implementierung erfolgen im fünften Kapitel, in welchem die zwei Hauptanwendungsteile getrennt voneinander betrachtet werden. Für jeden Anwendungsteil wird zu Beginn eine Klassenstruktur entwickelt. Im Folgenden wird die Implementierung der einzelnen Objekte, Funktionen und Datenstrukturen erörtert.
Nach der Implementierung erfolgt im sechsten Kapitel eine Evaluation der erreichten Ziele. Es werden Stärken, aber auch Schwächen der Anwendung beleuchtet.
Das siebte und letzte Kapitel beinhaltet ein persönliches Fazit des Autors sowie einen Ausblick darauf, wie sich das entworfene System erweitern und vermarkten ließe.
Im folgenden Beispielszenario wird die aktuelle Situation eines Automobilverkäufers beschrieben, dies dient der Veranschaulichung des Ist-Prozesses, der resultierenden Probleme und Rahmenbedingungen.
Herr Mustermann aus Musterstadt arbeitet als Automobilverkäufer bei einem CITROËN- Autohaus, er ist für den Verkauf von Neu- und Gebrauchtwagen zuständig. Ihm ist die Verantwortung für die Internetaktivitäten des Autohauses übertragen worden. Im Laufe der letzten Jahre konnte er eine zunehmende Bedeutung des Internets feststellen. Viele Kaufinteressenten haben sich vor dem Besuch im Autohaus im Internet informiert. Auch konnte er schon einige Gebrauchtwagen über Fahrzeugbörsen nach ganz Europa verkaufen. Im Augenblick ist das Autohaus bei zwei Online-Fahrzeugbörsen registriert: Mobile.de und Autoscout24.de. Eine Erweiterung ist jedoch geplant, der Zeitmangel verbietet Herrn Mustermann jedoch seine Fahrzeuge in weiteren Fahrzeugbörsen anzubieten. Im Augenblick verwaltet Herr Mustermann die Fahrzeuge manuell, d.h. wenn ein neues Fahrzeug in den Bestand kommt führt er folgende Arbeitsschritte aus:
- Mit einem Stift, einem Notizblock und der Digitalkamera begibt er sich auf den Hof des Autohauses und fotografiert den Neuzugang. Er schreibt sich sämtliche Fahrzeuginformationen auf seinen Notizblock. Insbesondere notiert er Informationen die nicht aus den Fahrzeugpapieren ersichtlich sind wie der aktuelle Kilometerstand und besondere Ausstattungsmerkmale.
- Er legt das Fahrzeug im Fahrzeugstamm des Dealer-Management-Systems (siehe Abschnitt 3.1.1) an. Hierzu benötigt er sämtliche Fahrzeugdaten wie Fahrgestellnummer, Kilometerstand, Ausstattungsmerkmale usw. Diese Informationen erhält er zum einen aus den Fahrzeugpapieren, zum anderen dienen ihm dabei seine Notizen.
- Da das Dealer-Management-System keinen Export der Daten zu einer Online- Fahrzeugbörse unterstützt, muss Herr Mustermann das Fahrzeug manuell bei den Online-Börsen eintragen, d.h. er gibt die Daten erneut ein.
- Herr Mustermann schließt mit Hilfe eines USB-Kabels die Digitalkamera an seinen Arbeitsplatzrechner an und überträgt die erstellten Fahrzeugbilder.
- Herr Mustermann passt die Größe der Bilder mit Hilfe eines Bildbearbeitungsprogramms an.
- Die bearbeiteten Bilder werden auf den Server der ersten Fahrzeugbörse übertragen.
- Herr Mustermann loggt sich nun bei der zweiten Fahrzeugbörse ein, und wiederholt den Vorgang der Dateneingabe und des Bilduploads.
- Durch Zufall kann Herr Mustermann das Fahrzeug am nächsten Tag an einen Kunden verkaufen.
- Eine Woche später erhält er eine Email aus Schweden, ein Kaufinteressent möchte weitere Informationen, er hatte das Fahrzeugangebot bei einer Online-Fahrzeugbörse gesehen.
- Herr Mustermann schickt eine Email in der er sich entschuldigt, und teilt dem Interessent auf Englisch mit, dass das Fahrzeug bereits verkauft wurde.
- Herr Mustermann löscht das Fahrzeug aus den Fahrzeugbörsen, hierzu muss er sich bei jeder einzelnen Börse einloggen und den Eintrag manuell löschen.
Ziel dieser Diplomarbeit ist die Konzeption und prototypische Realisierung einer Anwendung für den professionellen Online-Fahrzeugvertrieb mit Hilfe eines Mobiltelefons. Die Anwendung soll Fahrzeughändlern die Einstellung ihrer Fahrzeuge in Online-Fahrzeugbörsen erleichtern. Dies wird in erster Linie durch die Verwendung des Mobiltelefons zur Datenerfassung erreicht. Dem Benutzer soll es ermöglicht werden, Fahrzeugdaten und Fahrzeugfotos mit Hilfe des Mobiltelefons zu erfassen bzw. zu erstellen. Die Daten sollen anschließend drahtlos auf den Personal Computer des Verkäufers übertragen werden können. Der Personal Computer dient dann zur Ergänzung und Verwaltung der Daten, denn letztendlich soll ein Export der Daten zu verschiedensten Fahrzeugbörsen ermöglicht werden.
Das zu entwickelnde System sollte die im Folgenden beschriebenen Anforderungen berücksichtigen und erfüllen.
Die grundsätzlichen Anforderungen an ein System zur Online-Fahrzeugvermarktung können vergleichsweise einfach aus dem Beispielszenario abgeleitet werden, wobei eine Klassifizierung der verschiedenen Erfordernisse in zwei Gruppen erfolgen kann. Zum einen gibt es Anforderungen die auf technischen Gegebenheiten beruhen, zum anderen spezielle Anforderungen der Anwender. Insbesondere die spezifischen Anforderungen der zukünftigen Nutzer des Systems sind schwer einzugrenzen, da die Mitglieder der Zielgruppe keine typischen gemeinsamen Merkmale wie Alter, Bildung und Vorkenntnisse haben.
Das System stellt durch seinen Aufbau und die verwendete Hard- und Software spezielle Anforderungen, dies sind bei dem Anwendungsteil des Mobiltelefons in erster Linie Performance bezogene Einschränkungen, wie:3
- Geringer Speicherbedarf
- Geringer Stromverbrauch
- Vermeidung von rechenintensiven Prozessen
- Berücksichtigung der beschränkten Ein- und Ausgabemöglichkeiten
Diese Anforderungen gilt es bei der Konzeption und Implementierung zu beachten, nur so können störende Nebeneffekte wie kurze Akkulaufzeiten, lange Wartezeiten zwischen den einzelnen Aktionen und Speicherüberläufe vermieden werden.
Wenn gleich die Ressourcen eines Personal Computers die eines Mobiltelefons um ein Vielfaches übersteigen, müssen auch hier folgende Anforderungen erfüllt werden:
- Eine möglichst plattformunabhängige Realisierung
- Keine Blockierung des Betriebssystems bzw. anderer Arbeitsabläufe
- Eine strukturierte Programmierung durch den Einsatz von Entwurfsmustern und vorgefertigten Klassen und Methoden.
Um den Gesamtprozess abbilden zu können müssen die folgenden Funktionen realisiert werden:
- Datenerfassung mit Hilfe des Mobiltelefons, d.h. sowohl Fahrzeugdaten als auch Fahrzeugfotos.
- Kabellose Übertragung der Daten vom Mobiltelefon zum Personal Computer
- Einfache Fragenkatalogverwaltung für das Mobiltelefon, d.h. welche Daten sollen per Mobiltelefon eingegeben werden.
- Einfache Konfiguration des Mobiltelefons, d.h. Festlegung des Speicherorts, der BluetoothServiceID, usw.
- Einfache Ergänzung der Fahrzeugdaten mit Hilfe des Personal Computers
- Alternative Fahrzeugerfassung ohne Mobiltelefon
- Fahrzeugdaten bearbeiten und löschen
- Datenexport an Fahrzeugbörsen
- Intelligente Exportschnittstellenverwaltung
Der Beruf des Automobilverkäufers ist ein relativ junger Beruf, erst in den letzten Jahren werden fundierte und anerkannte Ausbildungen für diese Tätigkeit angeboten. Die Zielgruppe ist daher sehr schwer zu beschreiben, die Vorkenntnisse im IT-Umfeld reichen von „IT-Neuling“ bis zu „ITProfi“. Das zu entwickelnde System sollte daher folgende grundsätzliche Anforderungen bezüglich der Benutzerfreundlichkeit erfüllen:
- Einfache Handhabung. Das Wesentliche muss intuitiv erkennbar sein. Dies erleichtert den Einstieg für den „IT-Neuling“ und ermöglicht eine sehr kurze Einarbeitungsphase für den „IT-Profi“.
- Gewohnte Elemente einbinden. In den vergangenen Jahren haben sich de Facto Standards für Automobilsoftware entwickelt. D.h. dass beispielsweise der Aufbau eines Formulars zur Fahrzeugdatenerfassung nicht mit dem etablierten Aufbau brechen sollte. Diese Wiedererkennung dient ebenfalls dem leichten Einstieg und einer kurzen Einarbeitungsphase.
- Übersichtlichkeit. Die sichtbaren Elemente sollten auf das Wesentliche reduziert werden. Selten benötigte Funktionen müssen nicht immer sichtbar sein. Die Übersichtlichkeit trägt entscheidend zur Benutzerfreundlichkeit bei.
- Zeitintensive Prozesse müssen für den Nutzer so angenehm wie möglich gestaltet werden. D.h. im besten Fall erfolgt eine nebenläufige Ausführung im Hintergrund, oder es erscheint eine aussagekräftige Information über den aktuellen Berechnungsfortschritt.
Der Bearbeitungszeitraum dieser Diplomarbeit ist beschränkt. Es muss daher eine klare Abgrenzung des Themas bzw. des Funktionsumfanges erfolgen. Im Rahmen dieser Arbeit wird ein Prototyp entwickelt, der ausschließlich der Veranschaulichung der Funktionen und als Beweis der Realisierbarkeit dient. Der Prototyp wird aufgrund des beschränkten Funktionsumfanges nicht für den Einsatz in der Praxis tauglich sein. Der Funktionsumfang beschränkt sich auf die Abbildung des Gesamtprozesses (siehe Abschnitt 4.1). Wünschenswerte Zusatzfunktionen wie z.B. die automatische Erstellung von Preisschildern können im Rahmen dieser Diplomarbeit nicht verwirklicht werden.
Das Hauptaugenmerk liegt auf der Realisierung und Darstellung der Kernfunktionen. Wichtige administrative und programmierspezifische Details, wie z.B. die Fehlerbehandlung werden lediglich im notwendigen Umfang bearbeitet.
Alternative Lösungswege werden grundsätzlich aufgezeigt, eine ausführliche Evaluation der Alternativen kann jedoch nicht realisiert werden. Bei der Verwendung externer Software zur Erfüllung einer bestimmten Teilaufgabe erfolgt eine Betrachtung der Alternativen. Eine fundierte wissenschaftliche Evaluation wird jedoch auch in diesem Fall grundsätzlich nicht möglich sein.
Im Rahmen dieser Diplomarbeit wird eine Vielzahl von Techniken eingesetzt. Dieses Kapitel gibt einen Überblick über die aktuelle Situation und den Stand der Technik. Die eingesetzten Techniken lassen sich in drei Hauptbereiche unterteilen. Zum einen spielen die Techniken und Prozesse des Automobilhandels eine wichtige Rolle, da diese als Grundlage für die Konzeption und Entwicklung einer neuen Anwendung berücksichtigt werden müssen. Zum anderen erfolgt die Realisierung der Anwendung auf zwei verschiedenen Endgeräten, die den Einsatz individueller Techniken erfordern. Die Techniken und Möglichkeiten des Mobiltelefons sind dabei ebenso von Bedeutung wie die Techniken moderner Desktopanwendungen mit Java.
Als Dealer-Management-System (DMS) bezeichnet man Anwendungen die speziell auf die Anforderungen eines Autohauses ausgerichtet sind. Der Funktionsumfang eines DMS variiert in der Praxis sehr. Folgende Grundfunktionen werden von der Mehrzahl der verfügbaren Systeme angeboten:
- Lagerhaltung
- Werkstattabwicklung (Auftrags-/Rechnungsstellung)
- Fahrzeughandel (Neu-/Gebrauchtwagen)
- Statistische Auswertungen (Werkstattauslastung, Verkaufsstatistik, usw.)
Zusätzlich zu den Grundfunktionen bieten viele Softwarehersteller Funktionen wie, Kassenabrechnung, Zeiterfassung, Finanzbuchhaltung und erweiterte Export-/Importfunktionen an. Die Branchenzeitschrift „Kfz-Betrieb“ stellte im Jahr 20044 24 DMS in einem Vergleichstest gegenüber. Unter dem Punkt "Schnittstellen" wurden die jeweiligen Schnittstellen der Programme aufgelistet. Nur drei der gelisteten Produkte erwähnten explizit die Integration von Online- Fahrzeugbörsen. Die anderen bieten laut dem Artikel zwar auch kompatible Schnittstellen, jedoch keinen direkten Export.
Diese Marktübersicht zeigt, dass die Einbindung des Online-Fahrzeugvertriebs in den Softwarelösungen der Automobilwirtschaft noch in den Kinderschuhen steckt, obwohl der Anteil der Internetverkäufe stetig steigt.
Nicht zuletzt die mangelnde Integration des Online-Fahrzeugvertriebs in den DMS führte dazu, dass sich ein Markt für eigenständige Programme für den Online-Vertrieb entwickeln konnte. Es existiert mittlerweile eine Fülle an sogenannten Stand-Alone-Lösungen. Diese bieten in der Regel folgende Funktionen:
- Datenimport und Datenexport
- Fahrzeugverwaltung mit Bildern
- Preisschilderstellung
- Statistik (Standzeiten, Standkostenrechner, usw.)
Die Anwendungen lassen sich dabei noch in zwei Systemarchitekturen unterscheiden, zum einen die klassischen Softwarepakete die auf einem PC im Autohaus installiert werden müssen, zum anderen komplette Online-Lösungen. Ein Beispiel für die klassische Softwareanwendung stellt Auto2Web™ der adEvents cross media AG5 dar, AutoDo! der AutoDo GmbH6 setzt hingegen auf eine reine Online-Applikation.
Die Realisierung des Prototypen wird unter Einsatz der Programmiersprache Java verwirklicht. Dieser Abschnitt bietet einen Einstieg in die Grundlagen der zum Einsatz kommenden Versionen der Java 2 Plattform. Die folgende Abbildung stellt die zurzeit verfügbaren Versionen der Java Plattform dar.
Abbildung 1: Übersicht Java 2 Plattformen7
Abbildung in dieser Leseprobe nicht enthalten
Im Folgenden werden die Java 2 Standard Edition (J2SE) und die Java 2 Micro Edition (J2ME) vorgestellt. Die Standard Edition wurde für den Einsatz auf Personal Computern entwickelt. Die Micro Edition wurde für Geräte mit sehr beschränkten Hardwareressourcen entwickelt und kommt unter anderem bei Mobiltelefonen zum Einsatz.
Mobiltelefone der aktuellen Generation bieten mittlerweile Funktionen die mit denen eines klassischen Telefons nichts mehr gemein haben. Die Geräte bieten MP3-Player, Videowiedergabe, Spiele uvm. Eine Vielzahl der Mobiltelefone verfügt über eine mobile Version der "Java Virtual Machine", die sogenannte „Kilobyte Virtual Machine“ (KVM). Diese wurde speziell auf die Anforderungen mobiler Endgeräte angepasst.8
Die Java Plattform für mobile Geräte nennt sich Java 2 Micro Edition, sie beruht auf folgenden Grundbausteinen:
- Konfigurationen
- Profile
- Optionale Pakete („Optional Packages“)
Die Kombination der verschiedenen Bausteine ermöglicht den Einsatz in den verschiedensten Geräten. Jedes Anforderungsprofil einer bestimmten Gerätekategorie kann durch eine Kombination der Bausteine optimal erfüllt werden.
Als Fundament dienen die Konfigurationen. Es existieren im Moment zwei Hauptkonfigurationen, zum einen die Connected Device Configuration (CDC) und zum anderen die Connected Limited Device Configuration (CLDC). Die Voraussetzungen der verschiedenen Konfigurationen unterscheiden sich wie folgt9:
CDC (Connected Device Configuration)
- Mindestens 512 Kilobyte zur Verfügung stehender Speicher für die Java-Umgebung
- Mindestens 256 Kilobyte Speicher für die Java-Laufzeitumgebung
- Gerät basiert auf einem 32-Bit-Prozessor
- Eine Netzwerkverbindung muss vorhanden sein
CLDC (Connected Limited Device Configuration)
- Mindestens 128 Kilobyte zur Verfügung stehender Speicher für die Java-Umgebung
- Mindestens 32 Kilobyte Speicher für die Java-Laufzeitumgebung
- Eine Netzwerkverbindung muss vorhanden sein
Diese Aufzählung zeigt, dass der Hauptunterschied der zwei Konfigurationen in den Hardwareanforderungen, insbesondere der Speicherkapazität und der Prozessorleistung, liegt. Mobiltelefone verfügen in der Regel nicht über einen 32-Bit-Prozessor, es wird daher grundsätzlich die CLDC verwendet.
Profile bauen auf den Konfigurationen auf und erweitern den Funktionsumfang.10 Die grundsätzliche Einteilung der Gerätegruppen wird von den Konfigurationen implementiert, wobei auch die Geräte einer Kategorie sehr unterschiedliche Merkmale haben. Diese Unterschiede werden mit Hilfe von Profilen abgedeckt.
Das Mobile Information Device Profile (MIDP), ist dabei das am weitesten verbreitete Profil. MIDP ist speziell für mobile Endgeräte entwickelt worden. Es stellt die Kernfunktionalität, die Anwendungen auf mobilen Geräten benötigen, zur Verfügung.
Folgende Anforderungen muss ein mobiles Gerät mindestens erfüllen (MIDP 2.0):11
- Displaygröße min. 96x54 Pixel (Square)
- 1 Bit Farbtiefe
- Eine der folgenden Eingabemöglichkeiten: Ein-Hand-Tastatur, Zwei-Hand-Tastatur oder Touchscreen.
- 8 Kilobyte Speicher für persistente Speicherung
- 128 Kilobyte Speicher für die Laufzeitumgebung
- 256 Kilobyte für die Speicherung der MIDP Implementierung
- Drahtlose Netzwerkverbindung
- Die Möglichkeit der Audiowiedergabe
Neben MIDP existieren noch weitere Profile, wie beispielsweise das Foundation Profile und das Personal Profile. Diese Profile basieren jedoch auf einer CDC-Konfiguration und kommen daher bei Mobiltelefonen nicht zum Einsatz.
Mobiltelefone weisen eine sehr individuelle Ausstattung auf. Daher gibt es noch eine weitere Möglichkeit den Funktionsumfang der KVM zu erweitern. Durch sogenannte "Optional Packages" können Gerätehersteller ihre Telefone individuell mit Funktionen erweitern. Da optionale Pakete modular aufgebaut sind, können Gerätehersteller deren Einsatz frei wählen, um so die Besonderheit von jedem Gerät wirksam ausschöpfen zu können. Inzwischen sind folgende "Optional Packages" weit verbreitet:
Abbildung in dieser Leseprobe nicht enthalten12
Tabelle 1: Übersicht gängiger MIDP Optional Packages
Diese Version der Java Plattform wurde im Gegensatz zur Java 2 Micro Edition speziell für Personal Computer entwickelt, d.h. für Geräte mit hoher Prozessorleistung, ausreichend Speicherplatz und einer umfassenden Darstellungsmöglichkeit der Benutzeroberfläche.
Anwendungen, die mit Hilfe der J2SE entwickelt wurden, sind in der Regel völlig plattformunabhängig. Spezielle Verknüpfungen mit dem Betriebssystem sind jedoch in bestimmten Situationen notwendig. Um eine Plattformunabhängigkeit auch in diesen Fällen zu erreichen, müssen für sämtliche Betriebssysteme Alternativimplementierungen eingebunden werden. Bei der GUI13 -Programmierung kommt es mitunter zu betriebssystemspezifischen Implementierungen. Dies geschieht durch die Verwendung von sogenannten Native-Widgets, d.h. grafische Benutzerelemente, die das jeweilige Betriebssystem zur Verfügung stellt.
Die J2SE besteht aus den verschiedensten Java-APIs14 für eine Vielzahl von Aufgaben. Für die Entwicklung von Benutzeroberflächen werden die folgenden GUI-APIs von Java bereitgestellt:
- AWT: Abstract Window Toolkit
- Swing: Eine Weiterentwicklung von AWT, seit 1998 fester Java-Bestandteil
- SWT: Standard Widget Toolkit
Die verschiedenen Bibliotheken unterscheiden sich in erster Linie im Einsatz von native und non-native Widgets, sowie der Anzahl der verfügbaren Widgets.
Das Abstract Window Toolkit besitzt eine sehr einfache Architektur, Komponenten und grafische Elemente bilden einfache Kopien der Elemente der nativen Widget-Bibliothek des verwendeten Betriebssystems15, wodurch der Umfang der verfügbaren Widgets auf essentielle Elemente begrenzt ist.
Swing wurde auf AWT aufbauend entwickelt, die verfügbaren Komponenten von Swing unterscheiden sich jedoch grundlegend gegenüber AWT, insbesondere die zugrunde liegende Implementierung der Widgets. Swing-Widgets sind alle samt non-native, d.h. es besteht keine Verknüpfung zur betriebssystemeigenen Widget-Bibliothek. Dies hat den Vorteil, dass die Benutzeroberfläche auf den verschiedenen Plattformen ein identisches Erscheinungsbild besitzt, jedoch den Nachteil, dass dem Benutzer nicht das Ihm gewohnte Look and Feel des Betriebssystems geboten werden kann. Die meisten AWT-Komponenten besitzen in Swing ein direktes Ebenbild. Swing bietet jedoch auch zusätzliche Elemente wie Bäume und Tabellen, wodurch die Anzahl der Elemente in Swing doppelt so groß ist, wie die des AWTs16.
Die jüngste Java-GUI-API ist SWT, das im Jahr 2001 von IBM für die Entwicklungsumgebung Eclipse entwickelt wurde17. Das Standard Widget Toolkit versucht die Vorteile von AWT und Swing in sich zu vereinen, d.h. es besteht keine Festlegung auf ausschließlich native- bzw. non-native Widgets, SWT bietet beides. Wenn möglich versucht SWT native Widgets des Betriebssystems zu verwenden. Bietet das Betriebssystem kein entsprechendes Widget an, wird ein non-native Widget implementiert. Beispielsweise verwendet SWT auf Microsoft Windowssystemen das native Tree- Widget. Die Motif-Widget-Bibliothek bietet dagegen kein eigenes Tree-Widget. In diesem Fall emuliert SWT dieses automatisch, der Programmierer verwendet jedoch immer dieselbe Schnittstelle. Durch die Verwendung sämtlicher native-Widgets enthält die SWT-Library auch plattformspezifischen Programmcode. Dies bedeutet, dass für jede Plattform eine eigene SWT- Library benötigt wird. Im Gegensatz zu AWT und Swing ist SWT nicht Bestandteil der Standard Edition, d.h. die Bibliotheken müssen explizit mit der Anwendung ausgeliefert werden. Die SWTLibrary wird für eine Vielzahl von Plattformen angeboten.
Eine weitere interessante Entwicklung stellt JFace dar. Hierbei handelt es sich jedoch nicht um eine eigenständige GUI-API. JFace stellt vorgefertigte Lösungen für Standardszenarien zur Verfügung und verwendet dabei die Möglichkeiten der SWT-Library. Klassische JFaceKomponenten sind Dialog-Boxen und sogenannte Wizards. Wie auch SWT ist JFace ebenfalls ein Nebenprodukt der Eclipse-Entwicklung.
Ein wichtiger Bestandteil der zu entwickelnden Anwendung wird die Datenübertragung via Bluetooth darstellen. Bluetooth wurde im Rahmen einer Studie des schwedischen Telekommunikationsunternehmen Ericsson mit dem Ziel entwickelt, Kabelverbindungen zwischen Mobiltelefonen und Personal Computern, Headsets usw. zu eliminieren. Die Ergebnisse des Projekts machten eine Reihe von Konkurrenten auf Bluetooth aufmerksam, im Mai 1998 gründeten die Unternehmen Ericsson, IBM, Intel, Nokia und Toshiba die Bluetooth Special Interest Group (SIG)18. Im Juli 1999 wurde schließlich die Bluetooth 1.0 Spezifikation veröffentlicht. Der Namen Bluetooth (dänisch: Blatand) stammt von einem Vikinger-König, welcher in den Jahren 940-985 Dänemark regierte, er vereinte das bis dahin gespaltene Land. Die Bluetooth-Technologie will ebenfalls vereinen, wodurch sich diese passende Verbindung ergibt.19
Die Bluetooth-Technologie ist im Bereich der Mobiltelefone sehr verbreitet. Personal Computer mit einem integrierten Bluetooth-Chip stellen dagegen Ausnahmen dar, Anwender, die ihren PC mit Bluetooth ausstatten möchten, müssen meist spezielle, externe Bluetooth-Adapter erwerben.
Wie bereits unter Abschnitt 3.2.1.3 beschrieben, können Mobiltelefonhersteller den Funktionsumfang der KVM bzw. der Java 2 Micro Edition mit Hilfe von „Optional Packages“ erweitern. Mobiltelefone mit Bluetooth-Schnittstelle werden in der Regel mit dem „Optional Package“ Bluetooth-API (JSR 82) ausgestattet. Die Bluetooth-API ermöglicht der Java Plattform den Zugriff auf die Bluetooth-Hardware. Dadurch ist es möglich, Java-Anwendungen zu entwickeln, die eine drahtlose Kommunikation via Bluetooth realisieren.
Der Zugriff auf die Bluetooth-Hardware stellt sich bei der Java 2 Standard Edition als nicht einfach dar. Die Hersteller der Bluetooth-Adapter bieten keine vordefinierten Schnittstellen für den Zugriff mit Java. Es existiert daher eine Vielzahl von sogenannten Bluetooth-Stacks für Java. Diese Produkte bieten eine J2SE-Implementierung der Bluetooth-API für bestimmte Hardware. Die Stacks sind aufgrund der Hardwarenähe nicht plattformunabhängig. Die bekanntesten Bluetooth- Stacks sind die Folgenden:
- Atinav - aveLink20
- Avetana - avetanaBluetooth21
- BlueCove22
- Javabluetooth.org23
- Rococo24
Es existieren noch weitere Stacks, eine umfassende wissenschaftliche Analyse bzw. Evaluierung der verschiedenen Softwareprodukte kann jedoch im Rahmen dieser Diplomarbeit aufgrund der Zeit- und Umfangsbeschränkung nicht erfolgen.
Wie bereits erwähnt, versuchen die verschiedenen Stacks die Bluetooth-API abzubilden. D.h. ein späterer Umstieg auf einen anderen Stack sollte keine Auswirkung auf die Programmierung haben, da die Schnittstelle gleich bleibt.
Die Bluetooth Spezifikation beschreibt einige Protokolle zur Datenübertragung via Bluetooth. Wie aus dem OSI-Modell25 bekannt, werden auch die Bluetooth-Protokolle in einer Schichtarchitektur organisiert. Die folgende Tabelle dient der Veranschaulichung der verschiedenen Schichten und deren zugehörigen Protokolle.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Bluetooth Protokolle26
Bluetooth-Anwendungen müssen nicht alle Protokolle verwenden. Stattdessen verwenden sie eines oder mehrere. Die Protokolle an sich sind jedoch teilweise voneinander abhängig. So verwenden beispielsweise die Protokolle L2CAP und TCS BIN das Link Manager Protokoll zur Verbindungskontrolle.
Es wird deutlich, dass Bluetooth eine Menge Möglichkeiten zur Kommunikation bietet. Daher bleibt nun, die für die Anforderungen passenden Protokolle auszuwählen und dadurch eine intelligente drahtlose Kommunikation zwischen Personal Computer und Mobiltelefon, also J2SE und J2ME zu entwickeln.
Im folgenden Abschnitt wird der durch die Anwendung abzubildende Gesamtprozess beschrieben. Dies dient der Veranschaulichung der einzelnen Anwendungsbereiche und Teilaufgaben. Die Anwendung wird sich in zwei Anwendungsteile gliedern. Zum einen der Anwendungsteil, der auf dem Mobiltelefon zum Einsatz kommen wird, zum anderen dem Anwendungsteil für den Arbeitsplatz-PC des Automobilverkäufers. Die nachstehende Abbildung veranschaulicht den Gesamtprozess.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Der Gesamtprozess
Es gilt nun die einzelnen Module zu entwerfen und den Gesamtprozess in Form eines Prototypen darzustellen. Die Konzeption und Implementierung gliedert sich dabei in die zwei Hauptanwendungsbereiche auf. Wie in Abbildung 2 zu erkennen ist, können die ersten und letzten beiden Teilaufgaben jeweils eindeutig einem der Hauptanwendungsteile zugeordnet werden. Die Datenübertragung (Schritt 3) betrifft hingegen beide Anwendungsteile.
Die Aufgabenstellung und die Anforderungen an das System erfordern einige Grundsatz- entscheidungen. Diese Bestimmungen beziehen sich sowohl auf die technischen Rahmen- bedingungen, als auch auf Gegebenheiten und Anforderungen bezüglich der Benutzerfreundlichkeit.
Die gesamte Anwendung wird in der Programmiersprache Java realisiert. Insbesondere der Teil des Systems, welcher auf dem Mobiltelefon zum Einsatz kommt, ist für die Verwendung von Java geradezu prädestiniert.
Wie Eingangs erwähnt, findet die Java Plattform für mobile Endgeräte - Java 2 Micro Edition - enorme Akzeptanz seitens der Mobiltelefonhersteller und Anwender. In einem einführenden Text zur Java-Technologie heißt es auf der deutschen Nokia-Internetseite: „Nokia Mobiltelefone, die Java™ unterstützen - das sind im Übrigen fast alle zur Zeit erhältlichen Nokia Modelle - verfügen über eine Java Virtual Machine, eine Umgebung, in der Java™-Anwendungen direkt ausgeführt werden können.“27 Die mittlerweile weite Verbreitung der Technik ist eines der Hauptargumente für den Einsatz von Java, wobei auch die Architektur der Plattform entscheidende Vorteile bietet. Die mögliche Anpassung der Plattform durch „Optional Packages“ gestattet den Zugriff auf die integrierte Hardware, d.h. Digitalkamera, Bluetooth und externe Speicherkarte können von Java aus verwendet werden. Eine einfache Installation von J2ME-Anwendungen auf Mobiltelefonen stellt ein weiteres Argument für den Einsatz der Java-Technologie dar. Der Mechanismus des „Over The Air Provisioning“ erlaubt eine drahtlose Installation der Anwendung. Diese erfolgt üblicherweise über eine Internetverbindung, wobei die Installationsdateien dann via http auf das Mobiltelefon übertragen und vom sogenannten „Application Management System“ des Geräts installiert werden.
Der Anwendungsteil für den Personal Computer wird ebenfalls mit Java realisiert, die Gründe hierfür sind jedoch weniger die Verbreitung und einfache Installation, dies bieten andere Technologien ebenso. Die Entscheidung für Java 2 Standard Edition beruht auf den Folgenden Entscheidungskriterien:
- Plattformunabhängigkeit, durch den Einsatz der Java Virtual Machine kann der sogenannte Java-Bytecode Plattformunabhängig ausgeführt werden.
- J2SE bietet mit AWT, Swing und insbesondere SWT/JFace umfangreiche Möglichkeiten für die Umsetzung der Benutzeroberfläche. Die Anwendung soll mit Hilfe von Wizards die Anwender durch die zu bewerkstelligen Aufgaben führen, JFace bietet hierfür unter anderem ein vorgefertigtes Wizard-Framework.
- Auch der betriebswirtschaftliche Aspekt spielt bei dieser Entscheidung eine wichtige Rolle. Die Java-Plattform ist sowohl für Entwickler als auch für Anwender völlig kostenlos.
Eine persistente Speicherung der Daten erfolgt seitens des Mobiltelefons mit Hilfe des integrierten RMS28. Seitens des Personal Computers bieten sich dagegen zahlreiche Datenbanksysteme an. Die Anwendung stellt keinerlei besondere Ansprüche an die angeschlossene Datenbank, die Anzahl der Datensätze ist sehr begrenzt. Der Fahrzeugbestand eines Autohauses liegt in der Regel zwischen 20 bis 1000 Fahrzeuge, wobei einen Bestand von 1000 Fahrzeugen nur sehr große Händler und Werksniederlassungen aufweisen können. Die technischen Anforderungen an die Datenbank spielen demnach bei der Entscheidung eine untergeordnete Rolle. Die Aspekte Verbreitung und Kosten sind daher ausschlaggebend. Es existiert eine Vielzahl von freien Datenbanksystemen, das wohl zurzeit bekannteste ist MySQL29. MySQL ist für die gängigen Betriebssysteme verfügbar und kann via JDBC30 in Verbindung mit dem Connector/J einfach aus einem Java-Programm angesprochen werden.
Grundsätzlich wird der Einsatz von Standard SQL präferiert. Dies erleichtert einen problemlosen Austausch des Datenbanksystems zu einem späteren Zeitpunkt. Die Entscheidung für MySQL ist daher eine Grundsatzentscheidung, welche jedoch zu einem späteren Zeitpunkt revidiert werden kann.
Der Markt für Mobiltelefone bietet eine Vielzahl von verschiedenen Modellen. Die folgenden Anforderungen werden jedoch für den Betrieb der Software zwingend erforderlich sein:
- Hardwareausstattung:
- Digitalkamera
- Bluetooth
- Speicherkarte (für die Speicherung der Bilddateien)
- Softwareausstattung:
- Java 2 Micro Edition, MIDP 2.0 mit folgenden „Optional Packages“
- MultiMedia API - für den Zugriff auf die Digitalkamera
- Bluetooth API - für den Zugriff auf die Bluetooth-Hardware
- FileConnection API - für den Zugriff auf die Speicherkarte
- Nokia UI API31 - für interne Bildverarbeitung
Als Testgerät wird bei der Entwicklung das Mobiltelefon SonyEricsson K750i zum Einsatz kommen, das Gerät besitzt eine 2.0 MegaPixel Digitalkamera, Bluetooth und erlaubt die Verwendung von MemoryStickDuo-Speicherkarten.
Grundsätzlich dient das Mobiltelefon zur Datenerfassung und der Erstellung von Fahrzeugbildern mit Hilfe der integrierten Digitalkamera. Zusätzlich zu diesen Grundfunktionen bietet das Gerät noch eine Fülle von Zusatz- und Hilfsfunktionen an. Es folgt nun eine detaillierte Beschreibung der einzelnen Funktionen:
Diese Funktion bildet den Hauptbestandteil des Anwendungsteils. Innerhalb dieser Funktion werden die Unterfunktionen „Erstellung der Fahrzeugfotos“ und „Datenerfassung“ abgearbeitet. Die Unterfunktionen sollten vom Benutzer automatisch durchgearbeitet werden können. D.h. dass z.B. nach Erfassung der wesentlichen Daten automatisch in den Kameramodus gewechselt wird. Diese automatische Führung des Benutzers erfolgt aufgrund der heterogenen Zielgruppe. Die Handhabung sollte daher so einfach wie möglich gestaltet werden. Da bei der Erfassung eines neuen Fahrzeugs mit Hilfe des Mobiltelefons sowohl die Datenerfassung als auch die Erstellung der Bilder abgearbeitet werden müssen, bietet sich hier eine strikte Nutzerführung an. Es folgt nun die Beschreibung der Unterfunktionen der Funktion „Neues Fahrzeug“.
- Funktion: Erstellung der Fahrzeugfotos
Die Funktion ermöglicht das Erstellen von Fahrzeugbildern mit Hilfe der integrierten Digitalkamera. Die Erstellung der Fotos sollte wenn möglich dem Fotografieren mit einer normalen Digitalkamera ähnlich sein, d.h. das Fotografieren sollte im Querformat ermöglicht werden, dabei sollte das Display des Mobiltelefons als Sucher dienen (wenn möglich Vollbildmodus). Der Auslöser sollte durch sämtliche Tasten betätigt werden können, da kein klassischer „Auslöser“ wie bei einer normalen Kamera existiert.
Nach Betätigung des Auslösers sollte dem Anwender ein Vorschaubild des erstellten Fotos angezeigt werden. Der Anwender sollte dann entscheiden können, ob er das Bild speichern oder verwerfen möchte. Sollte der Anwender das Bild nicht speichern, so sollte automatisch wieder in den Kameramodus gewechselt werden. War der Anwender mit dem Bild zufrieden, sollte ihm die Auswahl gestellt werden, ob er ein weiteres Foto für das Fahrzeug erstellen möchte, oder mit der Eingabe der Daten beginnen möchte.
Je nach dem, ob ein weiteres Fahrzeugfoto erstellt werden, oder mit der Eingabe der Fahrzeugdaten begonnen werden soll, wird entweder wieder der Kameramodus aktiviert oder das Foto auf der Speicherkarte gespeichert und die Datenerfassung gestartet.
- Funktion: Datenerfassung
Da die Eingabe von Fahrzeugdaten mit einem Mobiltelefon nicht für jeden Nutzer in gleichem Umfang praktikabel ist, muss eine Lösung für eine individuelle Verwaltung der Datenerfassung gefunden werden. Ein Benutzer sollte wenn möglich selbst konfigurieren können, welche Fahrzeugdaten er mit Hilfe des Mobiltelefons erfassen möchte.
Folgende Grundtypen von Fragen sollten möglich sein:
- Boolsche-Fragen: d.h. Fragen die entweder mit Ja oder Nein beantwortet werden können.
- Text-Fragen: d.h. Fragen die mit der Eingabe von Text bzw. Zahlen beantwortet werden können.
- Datums-Fragen: d.h. Fragen die mit der Eingabe eines Datums beantwortet werden können.
Die Fragen sollten automatisch nacheinander abgearbeitet werden, d.h. nach der Beantwortung einer einzelnen Frage wird die nächste Frage eingeblendet.
Nach der Beantwortung aller Fragen ist die Funktion „Neues Fahrzeug“ abgeschlossen. Zur Verbesserung der Benutzerfreundlichkeit könnte nach dem Abschluss die Möglichkeit angeboten werden, ein weiteres Fahrzeug zu erfassen. Dies würde dem Anwender die erneute Auswahl der Funktion ersparen. In der Regel wird ein Fahrzeugverkäufer mehrere Fahrzeuge nacheinander mit dem Mobiltelefon erfassen. Erst danach wird er die Daten auf den Personal Computer übertragen, wodurch er sich unnötige Wege zwischen dem PC und der Verkaufsfläche erspart.
Die folgende Abbildung dient zur Veranschaulichung der Gesamtfunktion:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Diagramm: Neues Fahrzeug (Mobiltelefon)
Nach der Erfassung neuer Fahrzeuge stellt die Übertragung der Fahrzeugdaten und Fahrzeugbilder eine weitere Grundfunktion dar. Die Datenübertragung muss drahtlos erfolgen, da dies ein weiteres Alleinstellungsmerkmal gegenüber herkömmlichen Lösungen (Digitalkamera) ist. Dem Anwender soll letztendlich der Anschluss einer Digitalkamera via USB-Kabel erspart bleiben.
Die Datenübertragung sollte für den Anwender so einfach wie möglich gestaltet werden. Daher wird der gesamte Datenbestand ohne weitere Eingaben seitens des Benutzers automatisch übertragen. Da die Speicherkapazität des Mobiltelefons begrenzt ist, sollten erfolgreich übertragene Daten automatisch gelöscht werden. Aufgrund dessen muss ein Mechanismus zur Fehlerkontrolle implementiert werden. Der Empfänger der Daten muss den Empfang der Daten quittieren. Nach erfolgreicher Quittierung kann der Sender dann die Daten löschen.
Da die Funkverbindung störungsanfälliger als eine Kabelverbindung ist, muss mit Fehlern bei der Übertragung gerechnet werden. Diese Störungsanfälligkeit sollte bei der Datenübertragung berücksichtigt werden. Die Daten sollten daher in einer logischen Reihenfolge übertragen werden, d.h. sollte die Funkverbindung abbrechen, sollten bereits übertragene Daten autonom von der fehlenden Datenmenge sein.
[...]
1 Quelle: Studie (N)ONLINER Atlas 2005, TNS Infratest, S. 10. Die Studie befindet sich im PDF-Format auf der beiliegenden CD.
2 Quelle: http://www.destatis.de (23.11.2005) Die Internetseite befindet sich im PDF-Format auf der beiliegenden CD 1
3 Vgl. White, James/Hemphill, David A: Java 2 Micro Edition. Greenwich: Manning Publications, 2002, S. 25 4
4 vgl. Branchenzeitschrift: Kfz-Betrieb. Ausgabe 10-11/2004. Würzbug: Vogel Auto Medien, 2004, S. 41ff (siehe CD)
5 Auto2web: http://www.auto2web.com (18.09.2005)
6 AutoDo: http://www.autodo.de (18.09.2005)
7 Quelle: Sun J2ME Datasheet: Das Datenblatt (j2me-ds.pdf) befindet sich auf der beiliegenden CD. 8
8 Vgl. Eschweiler, Sebastian: Java 2 Micro Edition. 1. Auflage. Landsberg: moderne industrie Buch, 2003, S. 23f
9 Vgl. Eschweiler, S. (2003), S. 21
10 Vgl. White, J./Hemphill, D. A. (2002), S. 31
11 Quelle: Midp 2.0 Spezifikation: Die Spezifikation (midp_2_0_spec.pdf) befindet sich auf der beiliegenden CD.
12 JSR: Java Specification Request, www.jcp.org/en/home/index
13 GUI - Graphical User Interface (Grafische Benutzeroberfläche): http://de.wikipedia.org/wiki/Grafische_Benutzeroberfl%C3%A4che (22.02.2006) (siehe CD)
14 API - Application Programming Interface (Programmierschnittstelle): http://de.wikipedia.org/wiki/Programmierschnittstelle (22.02.2006) (siehe CD)
15 Vgl. Guojie, Jackwind Li: Java Native Interfaces with SWT/JFace. Indianapolis: Wiley & Sons, 2005, S. 4
16 Vgl. Guojie, J.L. (2005), S. 5
17 Vgl. Wikipedia.de SWT: http://de.wikipedia.org/wiki/Standard_Widget_Toolkit, 2005, Zugriff 18.02.2006 (siehe CD) 11
18 Vgl. Muller, Nathan J.: Bluetooth Demystified. New York: McGraw-Hill, 2001, S.14
19 Vgl. Muller, N.J. (2001), S.15
20 Atinav: http://www.atinav.com (21.02.2006)
21 Avetana: http://www.avetana-gmbh.de (21.02.2006)
22 BlueCove: http://sourceforge.net/projects/bluecove (21.02.2006)
23 Javabluetooth.org: http://www.javabluetooth.org (21.02.2006) 12
24 Rococo: http://rococosoft.com (21.02.2006)
25 OSI - Open Systems Interconnection: http://de.wikipedia.org/wiki/OSI-Modell (22.02.2006) (siehe CD)
26 Vgl. Muller, N.J. (2001), S.102f
27 Quelle: http://www.nokia.de/de/mobiltelefone/technologie/java/4904.html (15.12.2005) Die Internetseite befindet sich auf der beiliegenden CD.
28 RMS - Record Management System: http://en.wikipedia.org/wiki/Record_Management_System (22.02.2006) (siehe CD)
29 MySQL: http://www.mysql.org (10.11.2005)
30 JDBC - Java Database Connectivity: http://de.wikipedia.org/wiki/JDBC (22.02.2006) (siehe CD)
31 Die Nokia UI API wurde von Nokia entwickelt, sie wird jedoch mittlerweile auch von vielen anderen Herstellern implementiert.
