Download - Entwurf und Implementierung eines anpassbaren Fahrtenbuch-Dienstes für Gruppen

Entwurf und Implementierung eines anpassbaren Fahrtenbuch-

Dienstes für Gruppen

DiplomarbeitCarola Korn

2/30

Gliederung• Einleitung• Analyse• Konzept• Funktionalitäten• Komponenten• Ontologie-Modell• Schlussbetrachtungen

• Einleitung– Motivation– Nutzungsszenario

3/30

Motivation• Kooperation zwischen

– IT Transfer Office und – OnStar Europe, General Motors Europe GmbH

• Telematik: soll das Fahren sicherer und effizienter machen

• Telematikplattform OTF – offene Plattform für anpassbare Anwendungen– Einsatz unterschiedlichster Ein-/Ausgabegeräte

• flexibles Fahrtenbuch: Potential für Flottenkunden

4/30

Nutzungsszenario• Fahrer tritt neue Fahrt an

– Startdaten sind zu erfassen,– Zwischenstopp, – Weiterfahrt

• Fahrtende– Enddaten

sind zu erfassen• weitere Fahrten ...• Auswertung/Ausdruck

Fahrzeug: DA-AB 123Fahrt-Nr.

Fahrer Tacho-AB

Tacho-EB

Strecke Typ Beschreibung

23 Bauer T. 12000 12050 50 Geschäftlich Kunde ABC GmbH24 Bauer T. 12050 12075 25 Privat ---------25 Klein I. 12075 12080 5 Geschäftlich Post abholen

5/30


• Analyse– Anforderungen– Konkurrenzprodukte– Entwicklungsziele

6/30

Anforderungen (1)• Dienstekunden:

– Fahrtenbuch-Kosten << Steuerersparnis– Verwaltung mehrerer Fahrzeuge und Fahrer– Auswertungsmöglichkeiten

• Fahrer (Fahrverhalten, Benzinverbrauch, Durchschnittsgeschwindigkeit, Arbeitszeiten, ...)

• Fahrzeug (Auslastung, Standzeiten bei Kunden ...)

• Fahrer: – wenig Eingabeaufwand, – Schutz der Privatsphäre, – Fehleingaben-Korrektur

7/30

Anforderungen (2)• Finanzbehörden: (ordnungsgemäßes Fahrtenbuch)

– zeitnah, – wahrheitsgemäß, – genaue Zweckangabe,– nachprüfbare Form, – lückenlose Erfassung, – zu erfassende Daten:

• Kilometerstand zu Beginn und am Ende der Fahrt,• Reiseziel, Reisezweck, gefahrene Kilometer

• Diensteanbieter: – In-/Exportmöglichkeiten,– anpassbares System, – Gruppenfahrtenbuch,– austauschbare Benutzerschnittstelle

8/30

Konkurrenzprodukte (1)• PC-Programme

– V: günstig– N: keine zeitnahe Erfassung– N: Doppelte Erfassung (Papier + PC)

• aufwändig, fehlerträchtig, manipulierbar

• PDA-Programme– V: günstig und zeitnah– N: manuelle Eingabe

[http://www.gpsw.co.uk/acatalog/P_NAVMANgps350.htm]

V = Vorteil, N = Nachteil

9/30

Konkurrenzprodukte (2)• WAP-basiert (Handy)

– V: Daten sind stets aktuell– N: sehr hohe Datenübertragungskosten (pro Fahrt)

• Fahrzeugendgeräte– V: automatische Erfassung– N: Teile der Daten sind nach-

träglich zu erfassen– N: hohe Anschaffungskosten– N: inflexibel [http://www.wolf-hsw.de]

V = Vorteil, N = Nachteil

10/30

Entwicklungsziele• Konzept und Design eines Anwendungs-

Systems mit folgenden Eigenschaften:– Gruppenfahrtenbuch, – Änderungsprotokoll,– Konfigurationsmöglichkeiten

• Hinzufügen von Datenfeldern zur Laufzeit des Systems,

• Personalisierungen,– austauschbare Benutzerschnittstelle

• Implementierung eines Prototypen

11/30


• Konzept– Beispielsystem– 3-Schichten-

Architektur

12/30

Beispielsystem (1)

Peter Müller

Gruppe: FahrerABC GmbH

FahrtenbuchABC GmbH

DA-AB 123

Gruppe: DienstwagenABC GmbH

FahrtenbuchTop AG

Tina Kern

Frank Bauer

F-DE 456

Gruppe: Dienstwagen Top AG

Max Muster

Gruppe: Manager

Gruppe: FahrerTop AG

13/30

Beispielsystem (2)

FahrtenbuchABC GmbH

Liste mit Fahrteinträgen

Liste mit ArbeitszeitdatenGruppe: Fahrer

ABC GmbH

Gruppe: ManagerGruppe: Dienstwagen

ABC GmbH

14/30

3-Schichten-Architektur

15/30


• Funktionalitäten– Konfiguration– Gruppenkonzept– Änderungsprotokoll– Benutzerschnittstelle

16/30

Konfiguration• Mehrere Datensammlungen in einer

Anwendung • Neue Datenfelder zur Laufzeit definieren• Menüstruktur/Ablauf abhängig vom Akteurtyp• Personalisierung:

– Konfigurationsdaten des aktuellen Akteurs und der relevanten Gruppen verwenden

17/30

Gruppenkonzept (1)• Unterschiedliche Akteure:

Akteure führen Aktionen aus (= aktive Elemente)– Personen– Fahrzeuge => weitere Typen möglich

• Zusammenfassung zu Gruppen– eine Anwendung (= passives Element) kann

verschiedene Gruppen von Akteuren haben– ein Akteur kann Mitglied in verschiedenen

Gruppen sein

18/30

Gruppenkonzept (2)

Allgemeine EinstellungenMitgliedsliste:

- Gruppen- Individuen

Daten: (Anwendungseinst.)

- Logbook ABC GmbH

~ Fahrttypdef.

GruppeAllg. Einst.Mitglied von:

- Gruppen

Daten: (Anwendungseinst.)

- Logbook TopAG- Logbook ABC GmbH

~ Fahrttypdef.

PersonAllg. Einst.Benutzerlisten:

- Gruppen- Individuen

Daten: (Fahrtdaten)

- Fahrtenliste- Arbeitszeit- liste

Anwendung

19/30

Änderungsprotokoll (= Historie)• Protokollierung des Schreibzugriffs:

– Änderung von Feldwerten– Hinzufügen/Löschen von Datenfeldern

• Protokolldaten: Datum, Benutzer, Before-Image• Speicherung des Protokolls:

– als Liste von Protokolleinträgen – im Datensatz, zu dem das Protokoll gehört

(kein zentrales Protokollobjekt pro Datensammlung)

• Datenübermittlung inklusive Historie

20/30

• Auswechselbare Benutzerschnittstelle (= UI)• Trennung zwischen

– Verarbeitung der Daten– Kommunikation mit Benutzer

• Standardmethoden für Kommunikation• Standardobjekte zum Datenaustausch zwischen

Anwendung und Benutzer-schnittstelle

Benutzerschnittstelle

UIAnwen-dung

Daten

2

14

3

5 6

21/30


• Komponenten– BasicObject– ContentObject– DataSet

22/30

BasicObjectBasicObject

Identifier

Settings

Data

1

1

1

1

Collection

Collection

3

*

DataSet

DataSet

*

*

* = beliebig viele

23/30

ContentObjectContentObject

Identifier

Settings

Data

Gruppen

Fahrtliste

...EinstellungssetAllg. Einstellungen

Individuen

Arbeitszeitliste

Fahrteintrag

ContentObject = Anwendung, z. B. Fahrtenbuch

Arbeitszeiteintrag

FahrteintragGruppenreferenz

24/30

• Speichert– Identifikationsinformationen– Liste von Datenfeldern– Spezialliste mit Datenfeldern– Änderungsprotokoll

• Zugriff nur über Funktionen dieser Klasse– jeder Schreibzugriff wird protokolliert

DataSet

1

DataSet

Identifier

Fieldlist

DataSubset

Historylist

11

1

1

25/30


• Ontologie-Modell– MIX-Modell– Einsatz des

MIX-Modells

26/30

MIX-Modell• Metadata based Integration model for data

X-change (von Christof Bornhövd) • selbstbeschreibendes

Datenmodell• Einfache Objekte• Komplexe Objekte

– enthalten weitere (einfache und/oder komplexe) Objekte sowie eine Objektbeschreibung

• Definition im Programmcode

Objekt: <Kunde>Wert:„Müller AG“

Beschr.: {Abnehmer/ Käufer der eigenen

Erzeugnisse}

27/30

Einsatz des MIX-Modells• Problem:

– generische Klassen, – Datenfelder unterscheiden sich auf Instanzebene

• MIX-Modell zur Beschreibung der Komponenten– Übergabeparameter und Rückgabewerte– Dokumentierung des Programmcodes

pubic Collection getCollection(Session session, ObjectName objectName)

28/30


• Schlussbetrachtungen– Ergebnis– Ausblick

29/30

Ergebnis• Konzeptes eines Anwendungs-Systems für

Fahrtenbuch-Dienste– Gruppenkonzept– Konfigurationen während der Laufzeit des Systems

• neue Datenfelder• Personalisierungen

– Änderungsprotokoll– austauschbare Benutzerschnittstelle (zur Laufzeit)

• Prototyp zur Demonstration des Konzepts

30/30

Ausblick• Datenspeicherung in einer XML-Datenbank• Weiterentwicklung des Abstraktionskonzeptes

– Einsatz einer Ontologie, die zur Laufzeit ergänzt werden kann

– Zuordnung von Standardobjekten zu neu definierten Datenfeldern

• Beispiel: <Fahrer> = session.userID

• Katalog von Komponenten• Datenimport/-export sowie Replikation

Download - Entwurf und Implementierung eines anpassbaren Fahrtenbuch-Dienstes für Gruppen

Top Related