Pflichtenheft Kartenloser Datenaustausch der LSVA

Transcrição

Eidgenössisches Finanzdepartement EFD
Eidgenössische Zollverwaltung EZV
Oberzolldirektion
Sektion LSVA 1
Pflichtenheft
Kartenloser Datenaustausch der
LSVA-Deklarationsdaten (BLUDEC)
Version:
1.0 vom 04.04.2007
Diplomarbeit B37.07 / Klasse B37 / Software Schule-Schweiz
Betreuer:
Christian Hennecke
Oberzolldirektion, Sektion LSVA 1
Gutenbergstrass 50, 3003 Bern
Tel. 031 323 07 81
Experte:
Andres Scheidegger
GLUE Software Engineering AG
Zieglerstrasse 34, 3007 Bern
Tel. 031 385 30 32
Diplomand:
Paolo Dünner
Oberzolldirektion, Sektion LSVA 1
Gutenbergstrass 50, 3003 Bern
Tel. 031 323 17 55
Abstract:
Es wird eine Applikation für Standard-Mobilgeräte (Handy, PDA) für den Datenaustausch zwischen einem Erfassungsgerät mit Bluetooth-Schnittstelle und
einer PC-Applikation mit Internetschnittstelle entwickelt.
Das Programm wird als MIDlet realisiert, so dass es in einer Java MIDP2.0
Laufzeitumgebung ausgeführt werden kann.
Keywords:
J2ME, Bluetooth, FTP, HTTP, SOAP
Pfh_BLUDEC_V1.0_20070404_2.doc
S LSVA 1
1 Inhaltsverzeichnis
1
Inhaltsverzeichnis..................................................................................................... 2
2
2.1
2.2
2.3
Übersicht.................................................................................................................. 3
Sinn und Zweck ................................................................................................... 3
Struktur des Dokuments ...................................................................................... 3
Leserkreis............................................................................................................ 3
3
3.1
3.2
Werdegang des Dokuments..................................................................................... 3
Referenzen.......................................................................................................... 3
Begriffe und Abkürzungen ................................................................................... 4
4
Erster Teil: Beschreibung des Produkts ................................................................... 5
4.1
Umfang und Anwendungsgebiet, Einsatzgebiet................................................... 5
4.2
Systemübersicht .................................................................................................. 5
4.3
Kommunikationsschnittstellen.............................................................................. 7
4.3.1
Protokollstack.................................................................................................. 8
4.3.2
Meldungen auf den Kommunikationsschnittstellen .......................................... 8
4.3.3
LSVA-Datenimage ........................................................................................ 11
4.3.4
Datensicherheit ............................................................................................. 11
4.3.5
Kenngrössen................................................................................................. 11
4.4
Benutzereigenschaften ...................................................................................... 12
4.5
Hardware des BLUDEC Demonstrators............................................................. 12
4.5.1
Zielhardware ................................................................................................. 12
4.6
Software ............................................................................................................ 12
4.6.1
Zielsystem..................................................................................................... 12
4.7
Anforderungen aufgrund der Benutzereigenschaften......................................... 13
4.8
Benutzerfunktionen............................................................................................ 14
4.8.1
Funktionsverfügbarkeitsmatrix ...................................................................... 18
4.9
Datenmodell ...................................................................................................... 19
4.10
Einschränkungen............................................................................................... 19
4.11
Nicht funktionale Anforderungen........................................................................ 20
4.11.1
Installation..................................................................................................... 20
4.11.2
System Setup................................................................................................ 20
4.11.3
Benutzeroberfläche ....................................................................................... 20
4.11.4
Benutzermeldungen ...................................................................................... 20
4.11.5
Handbücher .................................................................................................. 20
4.11.6
Tutorial.......................................................................................................... 20
4.11.7
Hilfesystem ................................................................................................... 20
4.11.8
Simulatoren, Testeinrichtungen..................................................................... 21
4.11.9
Logging ......................................................................................................... 21
4.11.10
Sprachen ...................................................................................................... 21
4.11.11
Verwendete Technologie............................................................................... 21
4.12
Benutzeroberfläche............................................................................................ 21
4.12.1
Allgemeine Bemerkungen ............................................................................. 24
4.13
Entwicklungssystem .......................................................................................... 25
4.13.1
Architekturübersicht ...................................................................................... 25
4.13.2
Entwicklungshardware .................................................................................. 26
4.13.3
Softwarekonfiguration ................................................................................... 27
5
5.1
5.2
5.3
5.3.1
5.3.2
5.3.3
5.4
Zweiter Teil: Beschreibung der Durchführung der Arbeit ........................................ 29
Herausforderung................................................................................................ 29
Ziele der Diplomarbeit........................................................................................ 29
Vorgehen........................................................................................................... 29
Einführung .................................................................................................... 29
Iterationsschritte............................................................................................ 30
Reihenfolge der Iterationsschritte.................................................................. 35
Testen der Applikation ....................................................................................... 35
2/36
S LSVA 1
A
A.1
A.2
Anhang .................................................................................................................. 36
Abbildungsverzeichnis ....................................................................................... 36
Projektplan ........................................................................................................ 36
2 Übersicht
2.1 Sinn und Zweck
Zweck dieses Pflichtenheftes ist die Beschreibung der Rahmenbedingungen und grundlegenden Anforderungen der - im Rahmen einer Diplomarbeit der Software Schule Schweiz zu entwickelnden mobilen Applikation für die „kartenlose Deklaration“ der LSVA Erfassungsdaten.
Die Applikation ermöglicht den Austausch von Daten im Auftrags- / Meldungsverfahren zwischen dem LSVA Erfassungsgerät im Fahrzeug und dem Hintergrundsystem der LSVA bei
der Oberzolldirektion über ein Netzwerk.
Die Applikation ist das Herzstück eines Bluetooth Deklarations Systems und wird nach seinem Umfeld und seiner Verwendung „BLUDEC Demonstrator“ (BLUDEC = Bluetooth Declaration System) benannt. Als Kurzform wird BLUDEC ohne nachgestelltes Demonstrator
verwendet.
2.2 Struktur des Dokuments
Das Pflichtenheft besteht aus zwei Hauptteilen. Der erste Teil (Kapitel 4) beschreibt das zu
entwickelnde Produkt, den BLUDEC Demonstrator. Der zweite Teil (Kapitel 5) beschreibt das
Vorgehen bei der Entwicklung.
2.3 Leserkreis
Dieses Dokument richtet sich an Softwareentwickler und das Technikteam des Systembetreibers der LSVA, wobei für das Technikteam der LSVA der erste Teil des Pflichtenheftes
im Vordergrund steht. Für das Verständnis dieses Pflichtenheftes werden keine LSVA spezifischen Kenntnisse vorausgesetzt.
3 Werdegang des Dokuments
Ver.
Datum
Änderung
Autor
0.8
25.03.07
Aufteilung des Dokuments in zwei Teile.
Komplette Überarbeitung. Umbenennung der
Applikation in BLUDEC Demonstrator. Input
von Hr. Hennecke eingearbeitet. Bereit für
Review mit Experte.
Paolo
Dünner
0.9
02.04.07
Reviewbefunde eingearbeitert
Paolo
Dünner
1.0
04.04.07
Kommentare von Hr. Scheidegger eingearbeitet
Paolo
Dünner
Freigabe
04.04.2007 /
Christian Hennecke
/ Andres Scheidegger
3.1 Referenzen
Dokumententitel
Version
[1]
JSR 75, FileConnection Optional Packages, http://jcp.org/en/jsr/detail?id=75
07.06.2004
[2]
JSR 82, Java APIs for Bluetooth, http://jcp.org/en/jsr/detail?id=82
28.06.2006
[3]
JSR 118, Mobile Information Device Profile 2.0,
http://jcp.org/en/jsr/detail?id=118
20.06.2006
3/36
S LSVA 1
[4]
JSR 139, Connected Limited Device Configuration 1.1,
http://jcp.org/en/jsr/detail?id=139
27.03.2003
[5]
JSR 172, J2ME Web Services Specification, http://jcp.org/en/jsr/ detail?id=172
03.03.2004
[6]
Bluetooth Core Specification, www.bluetoth.org/spec
05.11.2003
3.2 Begriffe und Abkürzungen
Nachfolgende Begriffe und Abkürzungen werden gemäss der Beschreibung in diesem Dokument verwendet:
Begriff
Beschreibung
BLUDEC
Bluetooth Declaration System, wird auch als Kurzform für BLUDEC Demonstrator verwendet
CLDC
CLDC (engl. Connected Limited Device Configuration) definiert die
kleinstmöglichste Konfiguration einer J2ME-Laufzeitumgebung.
LSVA
Leistungsabhängige Schwerverkehrsabgabe
LSVA-Datenimage
Der gesamte Datenaustausch zwischen Hintergrundsystem und OBU
wird über in LSVA-Datenimages verpackte Aufträge und Meldungen realisiert.
OBU
On Bord Unit: Erfassungsgerät im Fahrzeug
OTA Provisioning
OTA (over the air) Provisioning: Installation über Funkschnittstelle mittels
HTTP ab einem Webserver
OZD
Kurzform für Oberzolldirektion
Oberzolldirektion
Betreiberin des LSVA-Systems
Fahrzeughaltersoftware
Software des Fahrzeughalters für die Datenübermittlung und –einsicht
FZHSW
Kurzform für Fahrzeughaltersoftware
Image
Kurzform für das LSVA-Datenimage
Imageserver
FTP- oder Web-Server auf der FZHSW für den Imageaustausch mit der
OBU
MIDP
MIDP (engl. Mobile Information Device Profile) Ein Softwareprofil für die
virtuelle Maschine (Java) eines mobilen Gerätes. Spezifiziert die Grundmenge von Funktionen und Zugriffsmöglichkeiten auf die Hardware des
Gerätes. MIDP ist die softwarenahe Spezifikation, CLDC die hardwarenahe.
KVM
KVM (engl. Kilobyte Virtual Machine) ist Teil der kleinsten
Laufzeitumgebung und in der Java 2 Plattform, Micro Edition (J2MEPlattform) für den Einsatz auf Geräten mit beschränkter Speicherkapazität und CPU-Leistung enthalten. Auf Handys, Pagern und PDAs wird
häufig eine KVM für allgemeine Rechnerfunktionen ausgeführt.
4/36
S LSVA 1
4 Erster Teil: Beschreibung des Produkts
Dieser Teil des Pflichtenheftes beschreibt die Basisanforderungen der zu entwickelnden Applikation BLUDEC Demonstrator und seiner Kommunikationsschnittstellen. Es wird also das
„Was“ der Diplomarbeit definiert.
4.1 Umfang und Anwendungsgebiet, Einsatzgebiet
Mit Hilfe des BLUDEC und einem Mobilgerät mit Internetzugang und Bluetoothschnittstelle
kann der Fahrzeugführer die Erfassungsdaten1 aus dem Erfassungsgerät im Fahrzeug auslesen und zur Fahrzeughaltersoftware am Standort des Fahrzeughalters übermitteln. Der
Fahrzeughalter hat die Möglichkeit über die Fahrzeughaltersoftware Einsicht in die Erfassungsdaten zu nehmen um die Daten anschliessend über Internet an das Hintergrundsystem
der LSVA zu übermitteln. Der Vorgang des Datentransfers vom Erfassungsgerät zum Hintergrundsystem nennt sich Deklarieren und gehört zu den Pflichten der Halter aller im Inland
immatrikulierten LSVA pflichtigen LKWs2.
Der BLUDEC Demonstrator stellt eine Referenzimplementation der Bluetooth Deklarationsschnittstelle auf dem Erfassungsgerät und den Deklarationsschnittstellen der Fahrzeughaltersoftware dar. Die Betreiberin des LSVA Systems bietet den Fahrzeughaltern die Deklarationsschnittstellen für die kartenlose Deklaration als optionale Dienstleistung an. BLUDEC
stellt einen sekundären Deklarationsdatenkanal dar. Als primärer Deklarationsdatenkanal
dient eine Speicherchipkarte, welche mittels der Fahrzeughaltersoftware oder auf dem Postweg zur Oberzolldirektion übertragen werden kann. Es ist dem freien Markt überlassen solche Tools für die kartenlose Deklaration zu entwickeln, respektiv bestehende fahrzeugseitige
Entwicklungen (z.B. Flottenmanagementsystem) um diese Funktionalität zu erweitern. Die
Oberzolldirektion beabsichtig nicht, den Fahrzeughalten ein solches Tool anzubieten.
Der BLUDEC Demonstrator dient der Systembetreiberin zu Test- und Demonstrationszwecken. Es wird beabsichtigt - z.B. auf Nutzfahrzeugmessen - den interessierten Kreisen
mit Hilfe dieses Tools die kartenlose Deklaration vorzuführen. Während dem Abnahmetest
der neuen Erfassungsgerätegeneration und der neu entwickelten Fahrzeughaltersoftware
dient BLUDEC der Systembetreiberin für Schnittstellentests.
4.2 Systemübersicht
Der Datenaustausch zwischen der OBU und dem Hintergrundsystem erfolgt mittels - in sogenannte LSVA-Datenimages (Images) verpackten - Aufträgen und Meldungen. Die Images
sind mit LSVA-spezifischen digitalen Signaturen gegen unbemerkte Veränderungen (Manipulationen) geschützt. Das Auftragsimage hat einen begrenzten Gültigkeitszeitraum und
kann nebst dem Auftrag zur Datenauslesung auch Aufträge zur Aktualisierung der in der
OBU hinterlegen Daten enthalten. Aus diesen Gründen müssen die Auftragsimages regelmässig bei der Oberzolldirektion (OZD) auf ihre Aktualität überprüft und gegebenenfalls von
der OZD neu bezogen werden.
1
Die LSVA berechnet sich nach den im Inland gefahren Kilometern, dem Gesamtzugsgewicht und
einem nach Emissionskategorie abgestuften Tarif. Im Erfassungsgerät werden die dazu benötigten
Daten in einem Logfile aufgezeichnet. Die geschuldete Abgabe wird im Hintergrundsystem der LSVA
unter Berücksichtigung weiterer Eingangsgrössen berechnet.
2
Im Inland immatrikulierte Motorfahrzeuge zum Gütertransport mit einem Gesamtgewicht von mehr
als 3,5 Tonnen sind der LSVA unterstellt und müssen mit einem Erfassungsgerät im Fahrzeug ausgerüstet sein.
5/36
S LSVA 1
SOLL - System
Internet
Internet
Mobilgerät
Bluetooth
CH-OBU-2
Fahrzeughalter-
Erfassungsgerät
software
Hintergrundsystem
Chipkarte
IST - System
Abbildung 1
Systemübersicht
IST – System
Als Datenaustauschkanal zwischen dem Erfassungsgerät (OBU) und der Fahrzeughaltersoftware (FZHSW) wird eine 16kB Speicher-Chipkarte (Chipkarte) verwendet. Die Chipkarte
dient als Transportmedium für die LSVA Aufträge und Meldungen.
SOLL – System
Als Datenaustauschkanal zwischen dem Erfassungsgerät (OBU) und der Fahrzeughaltersoftware (FZHSW) soll eine Netzwerkverbindung dienen. Zu diesem Zweck sind die OBU mit
einer Funkdatenschnittstelle und die FZHSW mit einem Imageserver als Datenschnittstelle
ausgestattet. Die in Images verpackten Aufträge an die OBU und Meldungen von der OBU
sollen über eine zwischen OBU und der FZHSW aufgebauten Netzwerkverbindung ausgetauscht werden können. Als Gateway soll ein Mobilgerät dienen, welches mit den entsprechenden Schnittstellen ausgerüstet ist.
6/36
S LSVA 1
4.3 Kommunikationsschnittstellen
Für den Imageaustausch werden vom BLUDEC zwei externe Kommunikationsschnittstellen
zur Verfügung gestellt - eine Bluetooth Schnittstelle zur OBU und eine Internet Schnittstelle
zur FZHSW. Die Kommunikationspartner können verschiedene Rollen einnehmen:
•
Die OBU kann die Rolle eines FTP Servers oder eines FTP Clients einnehmen. Von
der Rolle der OBU ist abhängig, wo der Datenaustausch initiiert wird. Der Datenaustausch wird immer clientseitig initiiert.
•
Die FZHSW kann die Rolle eines Web- oder FTP Servers einnehmen.
Abhängig von den eingenommenen Rollen der Kommunikationspartner OBU und FZHSW
ergeben sich zwei verschiedene Übermittlungsmethoden und somit zwei Betriebsarten für
BLUDEC:
a) Betriebsart FTP-Proxy: BLUDEC fungiert als Proxyserver zwischen der OBU und
der FZHSW. In dieser Betriebsart wird der Datenaustausch auf der OBU initiiert.
b) Betriebsart FTP-Gateway: BLUDEC fungiert als Gateway zwischen der OBU und
der FZHSW. In dieser Betriebsart wird der Datenaustausch durch BLUDEC initiiert.
Nachfolgendes Übersichtsdiagramm zeigt die Auslegeordnung:
Betriebsart FTP-Proxy
Betriebsart FTP-Gateway
OBU
OBU in der Rolle
eines FTP Clients
OBU in der Rolle eines
FTP Servers
OBU
Bluetooth
Bluetooth
Mobilgerät in der Rolle
eines FTP Proxy
Mobilgerät in der Rolle eines
FTP / SOAP Gateway
Internet
Internet
FZHSW
FTP Server
Abbildung 2
Web-Service
(IIS)
Auslegeordnung der Schnittstellen
7/36
S LSVA 1
4.3.1
Protokollstack
Nachfolgende Abbildungen zeigen die Protokollstacks der zwei Betriebsarten von BLUDEC.
Betriebsart FTP-Proxy
OBEX
FTP
Bluetooth
Bluetooth
OBU
Abbildung 3
FTP
FTP
OBEX
FTP
TCP/IP
Internet
Mobilgerät
TCP/IP
FZHSW
Protokollstack der Betriebsart FTP-Proxy
Betriebsart FTP-Gateway
Webservice
-
Webservice
OBEX
FTP
Bluetooth
4.3.2
Server
(HTTP / SOAP)
(HTTP / SOAP)
OBEX
FTP
Bluetooth
TCP/IP
TCP/IP
Internet
Mobilgerät
OBU
Abbildung 4
Client
FZHSW
Protokollstack der Betriebsart FTP-Gateway
Meldungen auf den Kommunikationsschnittstellen
Die Meldungen auf der Kommunikationsschnittstelle zur OBU und auf der Kommunikationsschnittstelle zur FZHSW werden auf der Applikationsebene (End to End) in Form von Telegrammen ausgetauscht. Dabei wird zwischen den Meldungstypen LSVA-Datenimage [Kapitel 4.3.3] und Status unterschieden. Das LSVA-Datenimage beinhaltet die eigentlichen Nutzdaten in Form von Auftrags- und Meldungsimages.
8/36
S LSVA 1
sd Imageaustausch mit OBU, an OBU ausgelöst
OBU
Mobilgerät
User
deklarieren
get Auftrag(Stammnummer)
Auftrag
Meldung
Status
anzeigen (Status)
Abbildung 5
Sequenzdiagramm Imageaustausch mit der OBU,
an der OBU ausgelöst
sd Imageaustausch mit OBU, am Mobilgerät ausgelöst
Mobilgerät
OBU
User
deklarieren(Stammnummer)
Auftrag
Meldung
anzeigen(status)
Abbildung 6
Sequenzdiagramm Imageaustausch mit der OBU,
am Mobilgerät ausgelöst
9/36
S LSVA 1
sd Image aktualisieren
Mobilgerät
FZHSW
User
Images aktualisieren
Meldung
Status
Auftrag
anzeigen(Status)
Abbildung 7
Sequenzdiagramm Images mit der FZHSW aktualisieren
sd Meldung übermitteln
Mobilgerät
FZHSW
User
übermitteln(Meldung)
Meldung
Status
anzeigen(Status)
Abbildung 8
Sequenzdiagramm Meldungsimage übermitteln
10/36
S LSVA 1
sd Auftrag beziehen
Mobilgerät
FZHSW
User
Auftrag beziehen
Auftrag
anzeigen(Status)
Abbildung 9
4.3.3
Sequenzdiagramm Auftragsimage beziehen
LSVA-Datenimage
Das LSVA-Datenimage (kurz Image) ist das einheitliche Format zum Austausch von Daten
zwischen den verschiedenen Instanzen im LSVA-System. Innerhalb des Images werden
entweder (ein oder mehrere) Aufträge oder eine Meldungen verpackt.
Die Struktur und der Inhalt des Image ist unabhängig vom für die Übertragung verwendeten
Datenkanal / -medium.
Das Image ist mit einer digitalen Signatur gegen Manipulationen geschützt.
4.3.4
Datensicherheit
Es sind keine zusätzlichen Anforderungen an die Datensicherheit gestellt. Im Fall von Datenverlust können die Daten jederzeit wieder neu beschafft werden. Die vertraulichen Daten
sind in verschlüsselter Form im Image abgelegt.
4.3.5
Kenngrössen
Es gelten folgende Kenngrössen:
a) Grösse des Image: Im Betrieb werden 16kBytes verwendet, wobei das System für
Imagegrössen bis zu max. 128kBytes ausgelegt ist.
b) Häufigkeit der Datenübertragung: nach Benutzerwunsch, in der Regel einmal pro
Monat.
c) Imageverarbeitungszeit auf der OBU: weniger als 10 Sekunden für 16kByte. (Diese
Kenngrösse ist für die Bestimmung von Timeouts relevant und stellt Anforderungen
an die Benuteroberfläche.)
11/36
S LSVA 1
4.4 Benutzereigenschaften
Die Benutzer können in drei Gruppen eingeteilt werden:
Benutzergruppe
Ausbildungsstand
Erfahrung
Technisches
ständnis
Anfänger (Messebesucher)
Tief
Wenig
gering
Gelegenheitsbenutzer
(Messestandbetreuer)
Tief
Mässig
Gering bis gut
Experte (Testingenieur)
gut
viel
gut
Ver-
4.5 Hardware des BLUDEC Demonstrators
Der Einsatz des Tools ist auf Handys und PDAs vorgesehen
4.5.1
Zielhardware
Als Zielhardware für den Betrieb des BLUDEC Demonstrators kommen handelsübliche
CLDC 1.1 [4] / MIDP 2.0 [3] kompatible Geräte in Frage.
Eingabemedien
Als Eingabemedien dienen die CLDC 1.1 [4] / MIDP 2.0 [3] konforme Standardtastaturen und
Touchscreens.
Ausgabemedien
An die Ausgabemedien sind folgende Mindestanforderungen gestellt:
•
Auflösung: 240x160 Pixel
•
256 Farben
Speichermedien
Dem BLUDEC Demonstrator stehen mindestens 256kByte nichtflüchtiger Speicher zur Verfügung.
Kommunikationsschnittstellen
Als Kommunikationsschnittstellen werden benötigt:
•
Bluetooth 2.0, OBEX Profil [6]
•
Mobiler Internetzugang, HTTP 1.1
4.6 Software
4.6.1
Zielsystem
Auf dem Zielsystem wird eine CLDC 1.1 [4] / MIDP 2.0 [3] kompatible KVM vorausgesetzt.
Die KVM muss die zusätzlichen Komponenten „Java API for Bluetooth“ [2], „Web Services“
[5] und „FileConnection Optional Package“ [1] zur Verfügung stellen.
12/36
S LSVA 1
4.7 Anforderungen aufgrund der Benutzereigenschaften
Aus den Eigenschaften der drei Benutzergruppen [Kapitel 4.4] lassen sich folgende Anforderungen ableiten:
a) Die Applikation muss einen möglichst automatischen Modus (wenig Benutzerinteraktion,
wenig Konfigurationsbedarf) für den Standard Anwendungsfall „Datenauslesen“ zur Verfügung stellen.
b) Nebst dem Benutzerhandbuch führt eine Kurzbeschreibung den Anfänger durch die wichtigsten Funktionen und dient dem Gelegenheitsbenutzer als Gedankenstütze.
c) Ein Expertenmodus soll eine möglichst flexible Konfiguration erlauben. Mit Hilfe dieses
Modus können die OBU Bluetooth Schnittstelle und die Imageserver Schnittstelle getestet werden. Es kann konfiguriert werden in wie vielen Teilschritten der Imageaustausch
abläuft. Zu Testzwecken lassen sich auch betrieblich nicht sinnvolle Abläufe durchführen;
z.B. kann eine Meldung mehrmals gesendet werden oder Images können manuell gelöscht werden. Die Kommunikations- und Verbindungstimeouts des BLUDEC können
eingestellt werden.
13/36
S LSVA 1
4.8 Benutzerfunktionen
In diesem Kapitel werden die verschiedenen Benutzerfunktionen beschrieben.
Anmerkung zu den Begriffen „Speichern“ und „Ablegen“: Es wird der Begriff „Ablegen“ verwendet, wenn der Benutzer eine Kopie einer bereits (durch die Applikation) gespeicherten
Information zu seiner Verwendung im Filesystem speichert.
Funktion
Priorität3
Beschreibung
Konfigurationen
a) Konfiguration
der Betriebsmodi
b) Konfiguration
On- / Offlinebetrieb
c) Konfiguration
zu verwendende Schnittstellen
d) Konfiguration
Webclient für
FZHSW
e) Konfiguration
FTP-Client für
FZHSW
3
Es kann zwischen den Betriebsmodi Deklarationsmodus und Testmodus gewählt werden.
Es kann zwischen den Betriebsarten Online und
Offline gewählt werden. Im Onlinebetrieb wird
eine Verbindung zur FZHSW vorausgesetzt
damit die Images direkt zwischen der OBU und
der FZHSW ausgetauscht werden können. Im
Offlinebetrieb können Images zwischen der OBU
und dem Mobilgerät und auch zwischen dem
Mobilgerät und der FZHSW in einzelnen Schritten ausgetauscht werden.
Es kann zwischen einem FTP- und einem Webserver als Imageserver der FZHSW gewählt
werden und ob auf der OBU deren FTP Client
oder deren FTP bedient werden soll.
Konfiguriert die Zugangsparameter und die URL
für den FZHSW Webservers.
Konfiguriert die Zugangsparameter und die URL
für den FZHSW FTP Servers.
Anmerkung: Es könnte sehr aufwändig werden
diese Schnittstelle zu unterstützen, weil J2ME
kein FTP unterstützt.
Eingaben:
Betriebsmodus
Verarbeitung:
Persistentes Speichern
und Übernehmen der
Einstellung
Ausgaben:
Erfolgs- oder Fehlermeldung
Eingaben:
Betriebsart
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
Eingaben:
Konfiguration zu verwendende Schnittstellen
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
Eingaben:
Zugangsparameter
(username und password) und die URL
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
Eingaben:
Zugangsparameter
(username und password) und die URL
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
muss
soll
soll
muss
nice to
have
muss:
die Funktion muss zwingend implementiert werden
soll:
die Funktion gibt der Applikation einen deutlichen Mehrwert und sollte wenn möglich implementiert werden
nice to have:
die Funktion gibt der Applikation einen Mehrwert welcher über das Ziel hinaus geht.
Die Implementierung wird zwar honoriert, ist aber nicht nötig.
14/36
S LSVA 1
f)
Konfiguration
der Fahrzeuge
g) Konfiguration
FTP-Client für
OBU
h) Konfiguration
FTP-Server für
OBU
i)
Konfiguration
Timeouts4
Es können die Fahrzeuge eingestellt werden,
welche beim Auftragsimagebezug berücksichtigt
werden. Optional kann zusätzlich das Kennzeichen angegeben werden.
Konfiguriert die Zugangsparameter zum FTP
Servers der OBU.
Konfiguriert die Zugangsparameter zum FTP
Client der OBU.
Kommunikations- und Verbindungstimeouts
können zu Testzwecken geändert werden.
Eingaben:
Stammnummer, Kennzeichen (optional)
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
Eingaben:
Zugangsparameter
(username und password) und URL
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
Eingaben:
Zugangsparameter
(username und password) und URL
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
Eingaben:
Diverse Timeoutwerte
Verarbeitung:
und Übernehmen der
Einstellung
Ausgaben:
Eingaben:
Gespeicherte Verbindungskonfigurationsdaten
Verarbeitung:
Kommunikationsversuch mit OBU
Ausgaben:
Eingaben:
Gespeicherte Verbindunskonfigurationsdaten
Verarbeitung:
Request an den Konfigurierten FZHSW
Server
Ausgaben:
Eingaben:
Stammnummer(n)
Verarbeitung:
Request an FZHSW
Server, Image speichern
Ausgaben:
Image auf Filesystem,
Erfolgs- oder Fehlermeldung am Display
Eingaben:
Image(s) aus Filesystem
Verarbeitung:
Senden an FZHSW
Ausgaben:
muss
soll
muss
nice to
have
Verbindungstest
j)
Verbindungstest OBU
k) Verbindungstest FZHSW
Die Verbindung zur OBU Schnittstelle wird getestet. Es wird die Erreichbarkeit und das Login
überprüft
Die Verbindung zur FZHSW wird gestestet. Es
wird die Erreichbarkeit und das Login überprüft.
muss
muss
Imageaustausch
l)
Aufträge von
FZHSW beziehen
m) Meldungen an
FZHSW senden
Es werden die Auftragsimages für alle konfigurierten Fahrzeuge von der FZHSW bezogen und
im Filesystem gespeichert.
Bereits vorhandene Auftragsimages werden
überschrieben. Es ist immer nur ein Auftragsimage pro Fahrzeug gespeichert.
Gespeicherte Meldungen werden an die FZHSW
gesendet und danach gelöscht.
muss
muss
15/36
S LSVA 1
n) Images aktualisieren
o) Auftrag an
OBU senden
p) Meldung empfangen
q) Deklaration
ausführen
Gespeicherte Meldungen werden an die FZHSW
gesendet und die Auftragsimages werden aktualisiert.
Anmerkung: Die Funktion setzt sich aus l) und m)
zusammen.
Gespeicherter Auftrag wird an die OBU gesendet.
Sind mehrere Fahrzeuge konfiguriert und aktiv,
so muss das Fahrzeug gewählt werden.
Meldung der OBU wird empfangen und gespeichert.
Der OBU wird ein Auftrag gesendet und die
Meldung empfangen. Im Onlinemodus wird die
Meldung direkt an die FZHSW gesendet.
Anmerkung: Abhängig von der Schnittstellenkonfiguration ist die Auslösung der Deklaration auf der OBU. In diesem Fall wird Funktion
p) ausgeführt.
Eingaben:
Image(s), Stammnummer(n)
Verarbeitung:
Send und Request an
Imageserver
Ausgaben:
Eingaben:
Image
Verarbeitung:
Senden an OBU
Ausgaben:
Eingaben:
Image
Verarbeitung:
Image speichern
Ausgaben:
Eingaben:
Stammnummer
Verarbeitung:
Senden an OBU, danach Empfangen und
im Onlinemodus an
FZHSW senden
Ausgaben:
Eingaben:
--
Verarbeitung:
Übermittlungsprotokoll
anzeigen
Ausgaben:
Eingaben:
Verarbeitung:
löschen
Ausgaben:
Eingaben:
Verarbeitung:
speichern
Ausgaben:
Eingaben:
Stammnummer
Verarbeitung:
Auftragsimage löschen
Ausgaben:
Eingaben:
Stammnummer
Verarbeitung:
Meldungsimage löschen
Ausgaben:
Eingaben:
Image
Verarbeitung:
Meldung speichern
Ausgaben:
Erfolgs- oder Nichterfolgsmeldung
muss
muss
muss
muss
Hilfsfunktionen
r)
Übermittlungsprotokoll anzeigen
s) Übermittlungsprotokoll löschen
t)
Übermittlungsprotokoll ablegen
u) Gespeicherte
Aufträge löschen4
v) Gespeicherte
Meldungen
löschen4
w) Meldungen
ablegen4
4
Übermittlungsprotokoll löschen
Das Übermittlungsprotokoll wird (als Kopie) im
Dateisystem gespeichert.
Zu Testzwecken können die auf dem Mobilgerät
gespeicherten Aufträge gelöscht werden.
Zu Testzwecken können die auf dem Mobilgerät
gespeicherten Meldungen gelöscht werden.
Auf dem Mobilgerät gespeicherte Meldungen
werden (als Kopie) im Dateisystem gespeichert.
muss
muss
soll
soll
soll
soll
Ausschliesslich für den Betriebsmodus Test benötigte Funktion
16/36
S LSVA 1
x) Aufträge ablegen4
y) Meldung laden4
z) Auftrag laden4
Auf dem Mobilgerät gespeicherte Aufträge werden (als Kopie) im Dateisystem gespeichert.
Im Dateisystem gespeicherte Meldung wird in
den „normalen“ Meldungsspeicher zurückgeholt
und ersetzen die allenfalls bereits vorhandene
Meldung.
Im Dateisystem gespeicherter Auftrag wird in den
„normalen“ Auftragsspeicher zurückgeholt und
ersetzt den allenfalls bereits vorhandenen Auftrag.
Eingaben:
Image
Verarbeitung:
Auftrag speichern
Ausgaben:
Eingaben:
Image
Verarbeitung:
Auftrag speichern
Ausgaben:
Eingaben:
Image
Verarbeitung:
Auftrag im Auftragsspeicher speichern
Ausgaben:
soll
soll
soll
17/36
S LSVA 1
4.8.1
Funktionsverfügbarkeitsmatrix
Offlinebetrieb
Onlinebetrieb
Funktion
Testmodus
Konfiguration
Deklarationsmodus
Die nachfolgende Matrix zeigt die verfügbaren Funktionen in Abhängigkeit der Konfiguration
von BLUDEC. Eine Funktion ist verfügbar, wenn sich kein „--„ in aus der Matrix ergibt.
a)
Konfiguration der Betriebsmodi
X
X
X
X
b)
Konfiguration On- / Offlinebetrieb
X
X
X
X
c)
Konfiguration zu verwendende Schnittstellen
X
X
X
X
d)
Konfiguration Webclient für FZHSW
X
X
X
X
e)
Konfiguration FTP-Client für FZHSW
X
X
X
X
f)
Konfiguration der Fahrzeuge
X
X
X
X
g)
Konfiguration FTP-Client für OBU
X
X
X
X
h)
Konfiguration FTP-Server für OBU
X
X
X
X
i)
Konfiguration Timeouts
--
X
X
X
j)
Verbindungstest OBU
X
X
X
X
k)
Verbindungstest FZHSW
X
X
X
X
l)
Aufträge von FZHSW beziehen
--
X
X
X
m)
Meldungen an FZHSW senden
--
X
X
X
n)
Images aktualisieren
X
X
--
X
o)
Auftrag an OBU senden
--
X
X
X
p)
Meldung empfangen
--
X
X
X
q)
Deklaration ausführen
X
X
X
X
r)
X
X
X
X
s)
Übermittlungsprotokoll löschen
--
X
X
X
t)
Übermittlungsprotokoll ablegen
X
X
X
X
u)
Gespeicherten Aufträge löschen
--
X
X
X
v)
Gespeicherten Meldungen löschen
--
X
X
X
w)
Meldungen ablegen
--
X
X
X
x)
Aufträge ablegen
--
X
X
X
y)
Meldung laden
--
X
X
X
z)
Auftrag laden
--
X
X
X
18/36
S LSVA 1
4.9 Datenmodell
Der Applikation BLUDEC liegt die Idee des unten abgebildeten konzeptionellen Datenmodells zugrunde.
class Datenmodell
<<Entity>>
<<Entity>>
bufferStatus
bufferTyp
dateiname
timestampLetzterEintrag
timtestampLetzteLeerung
<<Entity>>
Bludec
ImageBuffer
4
1
Fahrzeug
betriebsart
betriebsmodus
1
1
kontrollschild
1..* obuNummer
stammnummer
1
1
0..1
0..*
<<Entity>>
1
Image
1..2
<<Entity>>
dateiname
image
imagegrösse
imageNummer
imageTyp
stammnummer
timestamp
Protokoll
dateiname
protokollgrösse
status
timestamp
1
Imagetransfer
transferTyp
Schnittstellenkonfiguration
password
schittstellenTyp
1..* url
username
1
1
<<Entity>>
<<Entity>>
0..*
<<Entity>>
Protokolleintrag
eintragsNummer
schnitttstellenTyp
stammnummer
statusCode
timestamp
Abbildung 10 Konzeptionelles Datenmodell
4.10 Einschränkungen
Die Imageverarbeitung in der OBU ist nicht in allen Betriebszuständen der OBU möglich.
Während der Fahrt und im Standby-Betrieb der OBU ist die Imageverarbeitung nicht verfügbar.
19/36
S LSVA 1
4.11 Nicht funktionale Anforderungen
4.11.1 Installation
Die Applikation kann von einem Webserver über die OTA Schnittstelle, als File über Bluetooth oder ein Datenkabel übertragen und installiert werden.
Für die Installation über OTA werden vom Nutzer keine Vorkenntnisse vorausgesetzt. Der
Installationsvorgang ist im Benutzerhandbuch (siehe Kap. 4.11.5) anhand des Handy Sony
Ericsson K800 zu beschreiben. Die Applikation wird durch den Nutzer installiert.
4.11.2 System Setup
Die Applikation wird durch den Benutzer konfiguriert. Alle Konfigurationen können während
dem Betrieb der Applikation über das GUI geändert werden.
4.11.3 Benutzeroberfläche
Die Benutzeroberfläche muss intuitiv bedienbar und übersichtlich sein. Die Darstellung ist auf
¼ VGA Displayauflösungen im Hochformat zu optimieren.
4.11.4 Benutzermeldungen
Der Benutzer muss mittels leicht verständlicher Meldungen vor kritischen Aktionen gewarnt
und nach durchgeführten Aktionen über den Erfolg oder Fehler informiert werden.
Es werden die Meldungskategorien Warnung, Fehler und Erfolg unterschieden.
4.11.5 Handbücher
Es sind ein Benutzerhandbuch und eine Kurzbeschreibung zu erstellen. Das vorausgesetzte
Fachwissen richtet sich nach den Anwendergruppen (siehe Kapitel 4.3) und unterscheidet
sich nach den zwei Betriebsmodi (Deklaration und Test) der Applikation. Die zwei Betriebsmodi müssen adressatengerecht erklärt sein.
4.11.6 Tutorial
Für die Benutzergruppen Anfänger und Gelegenheitsbenutzer (Kap. 4.3) ist ein Tutorial zu
erstellen.
4.11.7 Hilfesystem
In jedem Konfigurationsmenu ist eine Hilfefunktion für die Kurzbeschreibung der Konfigurationsparameter vorzusehen.
20/36
S LSVA 1
4.11.8 Simulatoren, Testeinrichtungen
Zum Testen des BLUDEC sind folgende Testumgebungen aufzubauen:
a) OBU Simulation
b) FZHSW Simulation
c) Webserver für OTA Provisioning
4.11.9
Logging
Es ist ein Logging zur Protokollierung des Datenaustausches vorzusehen.
4.11.10 Sprachen
Das Bendienerinterface sowie die Benutzerdokumentationen sind in deutscher Sprache auszuführen.
4.11.11 Verwendete Technologie
Um ein möglichst breites Spektrum an unterstützten modernen Mobilgeräten abzudecken
wurde die Java Micro Edition als Plattform / Laufzeitumgebung für die Realisierung gewählt.
Das BLUDEC wird als CLDC 1.1 [4] MIDP 2.0 [3] MIDlet realisiert. Die Anforderungen an das
Zielsystem sind in Kapitel 4.6.1 definiert.
Auf geräteherstellerspezifische Erweiterungen muss grundsätzlich verzichtet werden. Falls
sich während der Designphase herausstellen sollte, dass für den Expertenmodus nicht auf
herstellerspezifische Erweiterungen verzichtet werden kann, so müssen zwei verschiedene
Versionen erstellt werden. Eine herstellerunabhängige Version für den reinen Deklarationsmodus und eine herstellerabhängige Version für den Testmodus.
4.12 Benutzeroberfläche
Damit die Benutzeroberfläche intuitiv [Kapitel 4.11.3] und ergonomisch bedient werden kann,
ist es von zentraler Bedeutung, wie sie sich in die gewohnte Umgebung des Benutzers integriert. Das Look and Feel muss der Benutzergewohnheit möglichst entsprechen. Um diese
Anforderung zu erfüllen wird das GUI auf Basis der High-Level API der LCDUI Kassenbibliothek entwickelt.
Die High-Level API der LCDUI Kassenbibliothek abstrahiert die Bendienelemente von der
Zielpattform. Dadurch können die abstrakten Bedienelemente auf dem Zielsystem durch ihre
nativen Bedienelemente ersetzt werden. Das GUI unterscheidet sich dadurch im Look and
Feel möglichst wenig von den Anwendungen der jeweiligen Gerätehersteller.
21/36
S LSVA 1
Untenstehende Abbildungen stellt eine grobe Idee einer Benutzeroberfläche dar:
Hauptmaske im Deklarationsmodus mit der Betriebsart Online. In der Betriebsart Offline ist zusätzlich der Eintrag „Images Übermitteln“ vorhanden. Im Testmodus sind folgende zusätzliche
Einträge vorhanden: „Aufträge beziehen“, „Auftrag senden“, „Meldungen übermitteln“, „Meldungen empfangen“, „Hilfsfunktionen“ (für die Verwaltung der Images).
Maske Fahrzeug zur Deklaration wählen: Das zu
deklarierende Fahrzeug kann ausgewählt werden. Wenn nur ein Fahrzeug konfiguriert ist wird
diese Maske übersprungen.
Maske Deklarationsausführung. Ein Lauftext
bittet den Benutzer um Geduld.
22/36
S LSVA 1
Maske Einstellungen. Im Testmodus ist ein weiterer Eintrag „Timeouts“ vorhanden.
Maske Einstellung des Betriebsmodus
Maske Einstellung der Betriebsart
Maske Fahrzeuge: Die OBU Schnittstelle kann
eingestellt werden und die konfigurierten Fahrzeuge werden aufgelistet. Es kann in die Untermasken zur Fahrzeugverwaltung (Fahrzeug erfassen, Fahrzeug bearbeiten und Fahrzeug löschen) gewechselt werden.
23/36
S LSVA 1
Maske Fahrzeugerfassung
Abbildung 11 Benutzeroberfläche
4.12.1 Allgemeine Bemerkungen
a) Durch das Java Sicherheitskonzept ist immer eine Benutzerbestätigung für den Verbindungsaufbau erforderlich und der Zugriff auf Speicher ist stark eingeschränkt.
b) Die Verfügbarkeit des Internets ist vom Standort des Mobilgerätes (Fahrzuge) abhängig.
Nicht alle Arten des Zugangs (GPRS, UMTS, EDGE, WLAN…) sind überall verfügbar.
c) Die Kosten für die Datenübertragung sind je nach Art des Internetzugangs sehr unterschiedlich.
24/36
S LSVA 1
4.13 Entwicklungssystem
4.13.1 Architekturübersicht
Für die Entwicklung der Applikation werden folgende Systemarchitekturen verwendet:
a) Architektur mir realem Mobilgerät
Abbildung 12 Architekturübersicht des Entwicklungssystems mit realem Mobilgerät
25/36
S LSVA 1
b) Architektur mir emuliertem Mobilgerät
Imageaustausch als Datei über
Bluetooth mittels OBEX-FTP
Entwicklungs-PC
Imageaustausch über
Internet mittels Webservice
(SOAP)
OBU Simulation
FZHSW Simulation
Entwicklungs-PC
FZHSW Webserver
mit Webservice (SOAP)
OBU FTP-Server
Emuliertes Mobilgerät
OBU FTP-Client
Imageaustausch als Datei über
Bluetooth mittels OBEX-FTP
Imageaustausch als Datei
über Internet mittels FTP
FZHSW FTP-Server
Abbildung 13 Architekturübersicht des Entwicklungssystems mit emuliertem Mobilgerät
4.13.2 Entwicklungshardware
Als Entwicklungshardware werden folgende Geräte eingesetzt:
a. Entwicklungs-PC
Handelsüblicher PC mit Bluetooth Schnittstelle und Internetzugang für Entwicklung
und Test.
b. OBU Simulations-PC
Handelsüblicher PC mit Bluetooth Schnittstelle als OBU Simulation für End to End
Testes.
c. FZHSW Simulations-PC
Handelsüblicher PC mit Internetzugang als Imageserver Simulation für End to End
Testes.
d. Webserver
Handelsüblicher PC mit Internetzugang als Webserver für das OTA Provisioning für
Tests.
e. Handy
Sony Ericsson K800 für Tests
f.
PDA
Ein PDA HP iPAQ hx2190 für Tests
26/36
S LSVA 1
4.13.3 Softwarekonfiguration
Die Softwarekonfigurationen der in Kapitel 4.13.2 aufgeführten Geräte ist in diesem Kapitel
aufgeführt. Die Konfigurationen sind als Grundidee zu verstehen und können bei Bedarf erweitert werden.
Entwicklungs-PC
Version
Hersteller
Betriebsystem
Windows
XP Professional
Microsoft
Programmiersprache
Java
Java ME
sun
Entwicklungsumgebung
Eclipse
3.2.2
Eclipse Foundation
http://www.eclipse.org
EclipseME
1.6.6
Craig Setera
http://eclipseme.org
Java Runtime Environment
(JRE)
1.5.0
Java Development Kit (JDK)
1.5.0
J2ME Wireless Toolkit
2.2
ProGuard
3.8
Eric P.F. Lafortune
http://proguard.sourceforge.net/
Enterprise Architect
6.5
Sparx Systems
Plug-ins
Produkt
Java
Tools
Office
sun
Total Commander
6.56
C. Ghisler & Co. (KG)
Wireshark
0.99.5
http://www.wireshark.org/
Office
XP Professional
Visio
2003
Professional
Project
2003 Professional
Microsoft
Adobe Acrobat
Adobe
Adobe Arcobat Reader
Adobe Photoshop
OBU Simulations-PC
Produkt
Version
Hersteller
Betriebsystem
Windows
XP Professional SP2
Microsoft
Java
(JRE)
1.6.0
1.6.0
sun
27/36
S LSVA 1
Webserver
Produkt
Version
Hersteller
Betriebsystem
Ubuntu Linux
Kernel 2.6.12
Ubuntu Foundation
Webserver
Apache
2.0
Apache Software Foundation
FTP-Sever
Vsftp
2.0.5
http://vsftpd.beasts.org/
Produkt
Version
Hersteller
Betriebsystem
Windows
XP Professional SP2
Microsoft
Webserver
IIS
Java
(JRE)
1.5.0
1.5.0
Produkt
Version
FZHSW Simulations-PC
Microsoft
sun
Handy
MIDP 2.0 [3]/ CLDC 1.1[4],
JSR 75 [1], JSR 82 [2], JSR
172 [5]
Java
Hersteller
Sony Ericsson
PDA
Produkt
Java
5
Version
Hersteller
MIDP 2.0 [3]/ CLDC 1.1[4],
JSR 75 [1], JSR 82 [2], JSR
172 [5]
5
Da der PDA ohne JAVA ausgeliefert wird, muss die Laufzeitumgebung inkl. den benötigten JSRs
erst beschafft und installiert werden. Die Wahl der Herstellers der Laufzeitumbebung ist Bestandteil
der ersten Entwicklungsiteration (Iterationsschritt 0).
28/36
S LSVA 1
5 Zweiter Teil: Beschreibung der Durchführung der Arbeit
In diesem Teil des Pflichtenheftes wird die Durchführung der Entwicklung des BLUDEC Demonstrators spezifiziert. Es werden das Entwicklungsvorgehen, die Rahmenbedingungen der
Entwicklung und der Entwicklungsprozess beschrieben.
5.1 Herausforderung
Das Umfeld der Kommunikationsapplikation mit zwei grundsätzlich verschiedenen Kommunikationsschnittstellen mit jeweils grundlegend verschiedenen Protokollstacks bietet viele
Variablen und Unsicherheiten. Dieses Umfeld stellt die Herausforderung dar, welchen bei der
Entwicklung des BLUDEC Demonstrators begegnet werden muss.
Das Thema Bluetooth und das Umfeld der Mobilgeräte sind für den Entwickler neu. Es muss
das benötigte Wissen aufgebaut und zielführend in die Entwicklung eingebracht werden.
Das Umsystem der Entwicklung (die OBU und die FZHSW) ist momentan noch in der Realisierungsphase und steht noch nicht für Systemtests zur Verfügung. Die Kommunikationsschnittstellen können also nur simuliert werden.
Die für den BLUDEC Demonstrator benötigten Schnittstellendefinitionen sind zum heutigen
Zeitpunkt weder erprobt, noch finalisiert. Die Finalisierung dieser Schnittstellen findet in etwa
zur selben Zeit wie die BLUDEC Demonstrator Entwicklung statt. Es muss also während der
gesamten Dauer der Entwicklung mit Änderungen gerechnet werden.
Es muss möglichst flexibel auf neue Erkenntnisse reagiert werden können.
5.2 Ziele der Diplomarbeit
Das Ziel der Diplomarbeit ist die Herausforderung der Entwicklung des BLUDEC Demonstrators, unter Berücksichtigung der im vorhergehende Kapitel 5.1 aufgeführten Sachverhalte.
Die Wahl des Entwicklungsvorgehens und die Definition der Rahmenbedingungen sollen so
definiert werden, dass den Herausforderungen wirksam begegnet werden kann und die in
Kapitel 4 beschriebene Applikation erfolgreich realisiert wird.
5.3 Vorgehen
5.3.1
Einführung
Um der Herausforderung aus Kapitel 5.1 möglichst zielgerichtet zu begegnen, wird ein iteratives Entwicklungsvorgehen gewählt. Im Vordergrund der einzelnen Iterationen stehen die
einzelnen Kommunikationsschnittstellen. Durch dieses stufenweise Vorgehen lassen sich zu
einem relativ frühen Zeitpunkt neue methodische und technisch Erkenntnisse gewinnen,
welche in die Detailanalyse und den Design des nächsten Iterationsschritts einfliessen.
Die Reihenfolge der Iterationsschritte richtet sich dabei nach den Prioritäten der einzelnen
Funktionen des BLUDEC und dem mit diesen Funktionen verbundenen Unsicherheitsgrad.
Die Anzahl der Iterationsschritte wird hauptsächlich durch den Zeitrahmen begrenzt.
Der eigentlichen Entwicklungs-Iterationen ist ein vorgelagerter Iterationsschritt für den Aufbau und die Konfiguration des Entwicklungssystems vorangestellt. Der Systemtest findet in
einem nachgelagerten Iterationsschritt statt.
29/36
S LSVA 1
Die Analyse wird auf Basis einer verfeinerten UseCase Betrachtung gemacht. Der Design
wird parallel zur Implementierung, vor den jeweiligen Iterationsschritten, erstellt und mit Hilfe
von Komponenten- und Klassendiagrammen dokumentiert.
5.3.2
Iterationsschritte
Dies Kapitel beschreibt die einzelnen Iterationsschritte während der Entwicklung.
Iterationsschritt 0
In diesem vorgelagerten Iterationsschritt wird die Entwicklungsumgebung eingerichtet, sowie
das Entwicklungssystem aufgebaut.
Ziele des Iterationsschritts
•
Die Entwicklungsumgebung steht für die Entwicklung bereit
•
Das Entwicklungssystem steht für Versuche und Tests bereit
Überprüfungskriterium für die Zielerreichung
Als Überprüfungskriterium für die Zielerreichung dient die Ausführung eines ersten BLUDEC
Demonstrators (ohne Funktionalität). Sobald der BLUDEC Demonstrator erfolgreich auf dem
Emulator ausgeführt werden kann, ist das Ziel erreicht.
Dokumentation während des Iterationsschritts
Der Weg der Zielerreichung und die gewonnnen Erkenntnisse werden dokumentiert.
Iterationsschritt A
Der Iterationsschritt A behandelt die Kommunikationsschnittstelle mit dem OBU FTP Server.
Folgende Funktionen sind implementiert und mittels einer OBU Simulation getestet:
a) Auftrag an OBU senden, Kap. 4.8, o) (nur Teilimplementation, es wird ausschliesslich
die Kommunikationsschnittstelle mit dem OBU FTP Server berücksichtigt!)
b) Meldung von OBU empfangen, Kap. 4.8, p) (nur Teilimplementation, es wird ausschliesslich die Kommunikationsschnittstelle mit dem OBU FTP Server berücksichtigt!)
c) Konfiguration des FTP Client für Kommunikation mit OBU FTP-Server, Kap. 4.8, g)
d) Verbindungstest OBU, Kap. 4.8, j) (nur Teilimplementation, es wird ausschliesslich
die Kommunikationsschnittstelle mit dem OBU FTP Server berücksichtigt!)
Als Überprüfungskriterium für die Zielerreichung dient der Datenaustausch zwischen dem
OBU FTP Server und dem Mobilgerät. Sobald dieser mit dem emulierten Mobilgerät zufriedenstellend funktioniert, ist das Ziel erreicht.
30/36
S LSVA 1
Während des Iterationsschritts werden die folgenden Punkte dokumentiert:
•
Weg der Zielerreichung
•
Verfeinerung und Überprüfung der Analyse
•
methodische Erkenntnisse
•
technische Erkenntnisse
Iterationsschritt B
Der Iterationsschritt B behandelt die Kommunikationsschnittstelle des Webservers der
FZHSW.
Folgende Funktionen sind implementiert und mittels einer FZHSW Simulation getestet:
a) Auftrag von FZHSW beziehen, Kap. 4.8, l) (nur Teilimplementation, es wird ausschliesslich die Kommunikationsschnittstelle mit dem Webserver der FZHSW berücksichtigt!)
b) Meldung an FZHSW senden, Kap. 4.8, m) (nur Teilimplementation, es wird ausschliesslich die Kommunikationsschnittstelle mit dem Webserver der FZHSW berücksichtigt!)
c) Konfiguration des Webclient für Kommunikation mit FZHSW Webserver, Kap. 4.8, d)
d) Vebindungstest FZHSW, Kap. 4.8, k) (nur Teilimplementation, es wird ausschliesslich
die Kommunikationsschnittstelle mit dem Webserver der FZHSW berücksichtigt!)
Webserver der FZHSW und dem Mobilgerät. Sobald dieser mit dem emulierten Mobilgerät
zufriedenstellend funktioniert, ist das Ziel erreicht.
•
•
•
•
31/36
S LSVA 1
Iterationsschritt C
Der Iterationsschritt C behandelt die Kommunikation zwischen dem OBU FTP Server und
dem Webserver der FZHSW über das Mobilgerät.
Folgende Funktionen sind implementiert und mittels einer OBU Simulation und FZHSW Simulation getestet:
a) Deklaration ausführen, Kap. 4.8, q) (nur Teilimplementation, es werden nur die
Schnittstellen OBU FTP Server und Webserver FZHSW berücksichtigt!)
b) Image aktualisieren, Kap. 4.8, 0 (nur Teilimplementation, es werden nur die Schnittstellen OBU FTP Server und Webserver FZHSW berücksichtigt!)
c) Konfiguration On- / Offlinebetrieb, Kap. 4.8, b)
Webserver der FZHSW und dem OBU FTP Server. Sobald dieser im Onlinebetrieb mit dem
emulierten Mobilgerät zufriedenstellend funktioniert, ist das Ziel erreicht.
•
•
•
•
Iterationsschritt D
Der Iterationsschritt D behandelt die alternativen Kommunikationsschnittstellen auf der OBU
(OBU in der Rolle als FTP Client) und der FZHSW (als FTP-Server), sowie die möglichen
Kombinationen der Schnittstellenverwendung. In diesem Iterationsschritt werden die nicht
zwingend erforderlichen Funktionen behandelt.
Es ist vom Verlauf der vorhergehenden Iterationsschritte abhängig, welche Ziele mit diesem
Schritt erreicht werden können. Dieser Schritt dient quasi als Buffer und ist als Chance zu
betrachten, die gewonnenen Erkenntnisse optimal in das Produkt einfliessen zu lassen.
Folgende Funktionen sind implementiert und mittels einer OBU Simulation und einer FZHSW
Simulation getestet:
a) Konfiguration des Betriebmodus, Kap. 4.8, a)
b) Konfiguration der Fahrzeuge, Kap. 4.8, 0
32/36
S LSVA 1
c) Verwalten der Images (Funktion: Kap. 4.8: u) bis z)
d) Auftrag an OBU senden, Kap. 4.8, o)
e) Meldung von OBU empfangen, Kap. 4.8, p)
f)
Konfiguration FTP-Client für FZHSW, Kap. 4.8, e)
g) Konfiguration FTP Server für OBU, Kap. 4.8, h)
h) Konfiguration der zu verwendenden Schnittstellen, Kap. 4.8, c)
i)
Konfiguration Timeouts, Kap. 4.8, i)
j)
Übermittlungsprotokoll anzeigen, Kap. 4.8, r)
k) Übermittlungsprotokoll löschen, Kap. 4.8, s)
l)
Übermittlungsprotokoll ablegen, Kap. 4.8, t)
Als Überprüfungskriterium für die Zielerreichung dient der Datenaustausch zwischen der
FZHSW und der OBU. Die OBU kann dabei beide Rollen (FTP Client oder Server) und die
FZHSW beide Ausprägungen (Webservice oder FTP Server) einnehmen. Sobald der Datenaustausch im On- und Offlinebetrieb mit dem emuliertem Mobilgerät zufriedenstellend funktioniert, ist das Ziel erreicht.
•
•
•
•
Iterationsschritt Z
In diesem nachgelagerten Iterationsschritt Z findet der Systemtest anhand von End to End
Tests mit emulierten und wenn möglich mit realen Mobilgeräten statt.
•
Es kann der Nachweis erbracht werden, dass die Applikation ihre Anforderungen erfüllt.
•
Allfällige Mängel sind aufgedeckt worden.
33/36
S LSVA 1
Als Überprüfungskriterium für die Zielerreichung dient der Nachweis, dass die Applikation
ihre Anforderungen erfüllt. Dieser Nachweis wird anhand des durchlaufenen Testdrehbuchs
erbracht.
•
•
Testresultate
•
•
34/36
S LSVA 1
5.3.3
Reihenfolge der Iterationsschritte
Entwicklungsphasen
Übergang
Konstruktion
Ausarbeitung
Auf Grund der Abhängigkeiten und Prioritäten der einzelnen Funktionalitäten ergibt sich die
nachfolgend dargestellte partielle Ordnung der Iterationsschritte. Die Ordnung setzt den
Rahmen für chronologische Abfolge der Iteration. Es wird ersichtlich, dass die Schritte A und
B einander zeitlich gleichgestellt sind und daher parallel ausgeführt werden können.
Abbildung 14 Partielle Ordnung der Iterationsschritte
5.4 Testen der Applikation
Zu jedem Iterationsschritt gehören auch die entsprechenden Tests. Während der Hauptiteration wird in jedem Schritt der dazugehörende Modultest durchgeführt. Das Ziel der Modultests ist das Auffinden von Implementierungsfehlern. Der im Iterationsschritt Z durchgeführte Systemtest hat zum Ziel mit Hilfe von End to End Tests die Erfüllung der Anforderungen nachzuweisen.
35/36
S LSVA 1
A
Anhang
A.1 Abbildungsverzeichnis
Abbildung 2
Abbildung 3
Abbildung 4
Abbildung 5
Abbildung 6
Abbildung 7
Abbildung 8
Abbildung 9
Abbildung 10
Abbildung 11
Abbildung 12
Abbildung 13
Abbildung 14
Auslegeordnung der Schnittstellen ................................................................................ 7
Protokollstack der Betriebsart FTP-Proxy...................................................................... 8
Protokollstack der Betriebsart FTP-Gateway................................................................. 8
Sequenzdiagramm Imageaustausch mit der OBU, an der OBU ausgelöst.................. 9
Sequenzdiagramm Imageaustausch mit der OBU, am Mobilgerät ausgelöst ............... 9
Sequenzdiagramm Images mit der FZHSW aktualisieren........................................... 10
Sequenzdiagramm Meldungsimage übermitteln ......................................................... 10
Sequenzdiagramm Auftragsimage beziehen ............................................................... 11
Konzeptionelles Datenmodell................................................................................... 19
Benutzerobefläche ................................................................................................... 24
Architekturübersicht des Entwicklungssystems mit realem Mobilgerät.................... 25
Architekturübersicht des Entwicklungssystems mit emuliertem Mobilgerät............. 26
Partielle Ordnung der Iterationsschritte.................................................................... 35
A.2 Projektplan
Nr.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Vorgangsname
2. Qtl, 2007
April 2007
Mai 2007
Jun
01. 04. 07. 10. 13. 16. 19. 22. 25. 28. 01. 04. 07. 10. 13. 16. 19. 22. 25. 28. 31.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0
0
00
00
Vorabklärungen
KickOff
00
00
Erstellung Pflichtenheft
00
00
Zwischenreview
00
00
Abstract
00
00
Abgabe genehmigtes Pflichte
00
00
Bewertungskriterien festlege
0
0
Ausarbeitung
00 00 00 00 00 00 00 00 00 00 00
00
00
Iterationsschritt 0
00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Iterationsschritt A
00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Iterationsschritt B
00
00
Konstruktion
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Iteratisschritt C
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000000 0 0 0 0 0 0 0 0 0 0 0 000 0 0 0 0 0 0 0 0
00
Iteratisschritt D
000000000000000000000
0
00
00 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Übergang
000000000000000000000000000000000
0
Iteratisschritt Z
00 00 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
laufende Dokumentation
00
00
Abgabe Diplomarbeit
00
Präsentation der Arbeit
0
00
00
Diplomarbeit B37.7
00
0
00
00
00
00
0
000
0
00
0
000
00
00
00
00
00
00
00
0
00
31
36/36

Pflichtenheft Kartenloser Datenaustausch der LSVA

Transcrição

Documentos relacionados

"online vertrag" aus

S. Bollmann, Dr. J. Pyrgiel

#1#90003#2#2015_70_45 I#3#020

0713 j2 Präsentation

Einführung der Emissionsklasse 6 bei der Maut Tschechien

Mercedes-Benz Lkw 1.390,00

Diplombericht Kartenloser Datenaustausch der LSVA

DRK Klinikum Westerwald - DRK

Anleitung Netzwerk und Settings DBOX 2\374