Fachbereich Informatik -...

Projektarbeit

Implementierung eines webbasierten

Fahrzeugmarktes

cand. Wirtsch.-Ing. Martin Hoffmann

August 2002

Betreuer: Prof. Dr. Paul Müller

Dipl. Inform. Markus Hillenbrand

Fachbereich Informatik

AG Integrierte Kommunikationssysteme

Universität Kaiserslautern • Postfach 3049 • 67653 Kaiserslautern

Inhaltsverzeichnis Seite I

Inhaltsverzeichnis

INHALTSVERZEICHNIS .................................................................................................. I

1 KLINFORM UND BEGRÜNDUNG DER NOTWENDIGKEIT EINES FAHRZEUGMARKTES..............................................................................................1

1.1 KLINFORM – PORTAL FÜR DIE REGION KAISERSLAUTERN..........................1

1.2 ZIEL UND STATISTISCHE BEGRÜNDUNG DER PROJEKTARBEIT ..................3

2 ANFORDERUNGSANALYSE ....................................................................................5

2.1 ERWARTUNGEN DER BENUTZER........................................................................5

2.2 ANALYSE EXISTIERENDER WEBBASIERTER AUTOMÄRKTE........................6

2.3 BENUTZERANFORDERUNG..................................................................................8

2.4 ZUSAMMENFASSUNG..........................................................................................18

3 UMGEBUNGSSTRUKTUR ......................................................................................20

3.1 DAS MVC-DESIGN PATTERN..............................................................................20

3.2 WERKZEUGE ZUR UMSETZUNG DES PROBLEMS ..........................................21

3.3 USE-CASE-DIAGRAMM ALS HANDLUNGS- UND UMGEBUNGSBESCHREIBUNG ...........................................................................23

4 SYSTEMENTWURF AUF BASIS DES MVC-DESIGN PATTERN.......................25

4.1 OBJEKTORIENTIERTE SYSTEM- UND DATENBANKSTRUKTUR (MODELL- KOMPONENTE)......................................................................................................27

4.2 REPRÄSENTATIONSSTRUKTUR (VIEW- KOMPONENTE) ..............................36

4.3 STRUKTUR DER ABLAUFSTEUERUNG (CONTROLLER- KOMPONENTE) ...39

4.4 INTEGRATION DES MARKTES FÜR KRAFTRÄDER ........................................41

5 AUSGEWÄHLTE IMPLEMENTIERUNGSLÖSUNGEN ......................................44

5.1 INTERAKTIONSMÖGLICHKEITEN DES BENUTZERS MIT DEM SYSTEM....44

5.2 EINGRIFFSMÖGLICHKEITEN DES ADMINISTRATORS IN DAS SYSTEM.....52

6 ABSCHLIEßENDE BEWERTUNG UND AUSBLICK............................................56

Inhaltsverzeichnis Seite II

QUELLENVERZEICHNIS...............................................................................................59

ABBILDUNGSVERZEICHNIS ........................................................................................60

ANHANG............................................................................................................................61

KLinform und Begründung der Notwendigkeit eines Fahrzeugmarktes Seite 1

1 KLinform und Begründung der Notwendigkeit ei-nes Fahrzeugmarktes

Seit seiner Einführung Ende der 60-iger Jahre hat sich das Internet zu einem mehr und mehr

unüberschaubaren Massenmedium entwickelt. Anfänglich als Hilfsmittel des Militär entwi-

ckelt, erhielt es zunehmend Einfluss in nahezu allen Bereichen des öffentlichen, wirtschaftli-

chen und vermehrt auch privaten Lebens. Doch eine immer größer werdende Zahl von Anbie-

tern von Dienstleistungen, Informationen oder Produkten erschwert es dem Nutzer zuneh-

mend, die für ihn notwendigen und interessanten Angebote herauszufiltern.

Eine Eigenschaft, auf die sich das rasante Wachstum des Internet begründen lässt, ist seine

Unabhängigkeit von Ort und Zeit. Doch in jüngster Zeit erhebt sich zunehmend die Erkennt-

nis, dass zur optimalen Nutzung diverser Angebote und Informationen ein gewisser Bezug auf

das geographische Umfeld des Nutzers vorteilhaft und notwendig ist. Das folgende Szenario

aus dem Bereich des Electronic Retailing soll dies verdeutlichen. Ein Anwender sucht auf

einem der zahlreich angebotenen Portale, die sich als Vermittler zwischen Käufern und Ver-

käufern auf dem Fahrzeugmarkt verstehen, nach dem günstigsten Angebot für einen bestimm-

ten Gebrauchtwagen. Fündig wird er dabei bei einem Verkäufer in Berlin, der das Auto auch

sofort anmelden kann und als Bezahlungsmittel nur Kreditkarten akzeptiert. Unglücklicher-

weise wohnt der Interessent in Kaiserslautern und verfügt über keine Kreditkarte. Er stellt

sich nun die Frage, wie er in seiner unmittelbaren Umgebung das günstigste Angebot für die-

ses Fahrzeug ausfindig machen kann. Diese Arten von Erfahrungen und Probleme waren ein

Ausgangspunkt für die Idee zu ‚Kaiserslautern inform’ oder kurz ‚KLinform’ [KLinform

2000].

1.1 KLinform – Portal für die Region Kaiserslautern Hinter KLinform steht ein Projekt, dass sich mit der Konzeption, Implementierung und Reali-

sierung einer Portal-Site beschäftigt, deren Schwerpunkte vor allem unter dem Aspekt des

regionalen Fokus am Beispiel der Region Kaiserslautern gesetzt werden. „Eine Portal-Site

bietet ein weites Spektrum an Content und Diensten an, z.B. Suchmaschinen, Email, Home-

banking usw. Die Intention ist es, eine breite Masse an Nutzern zu überzeugen, das Portal als

Homepage zu nutzen, und so an sich zu binden, um möglichst hohe Werbeeinnahmen zu er-

zielen.“ [News 2002] Unterstützt wird das Projekt durch eine Vielzahl von Konsortialpart-

nern, die sich entweder durch geldwerte oder finanzielle Beiträge beteiligen.


Ziel ist eine umfassende Vernetzung wichtiger Bereiche des öffentlichen Lebens. Die innova-

tiven und attraktiven Dienste und Dienstleistungen sollen jedem Bürger über den regionalen

Online-Dienst zugänglich gemacht werden. Schwerpunkt ist dabei eine einfache und leicht

verständliche Strukturierung und Kategorisierung der Informationen sowie die Generierung

und Pflege des Inhalts.

1999 erhielt das Projekt den Multimediapreis des Landes Rheinland-Pfalz.

Nachfolgend werden zwei Konzepte näher erläutert, durch die sich KLinform von anderen

Portal-Sites abheben will: das Lebenslagenkonzept und das Personalisierungskonzept [Klein-

form 2000].

Lebenslagenkonzept

Die Idee des Lebenslagenkonzeptes ist eine intelligente und übersichtliche Aufbereitung und

Präsentation der vielfältig verteilten und teilweise unübersichtlich verzahnten Informationen,

die in der Region angeboten werden. Eine Lebenslage stellt dabei eine komplexe Situation

dar, in der sich der Anwender befindet, und die er zu lösen sucht. Die Aufbereitung der Daten

und Informationen erfolgt in Anlehnung an den alltäglichen Ablauf in den entsprechenden

Situationen. Der Benutzer findet die jeweilige Lebenslage betreffend alle notwendigen Infor-

mationen in zeitlicher und logischer Abfolge klar strukturiert vor. Die Information- und

Kommunikationstechnologie ermöglicht ihm das Problem schneller und effizienter zu lösen,

als er dazu auf dem herkömmlichen Weg in der Lage gewesen wäre.

Anhand der Lebenslage „Eheschließung“ soll das Konzept exemplarisch dargestellt werden.

Ein möglicher Einstiegspunkt in diese Lebenslage ist die Verlobung. Den Kauf des Verlo-

bungsringes erleichtert eine Übersicht der ansässigen Juweliere und deren Angebot. Informa-

tionen über Standesämter und die benötigten Unterlagen folgen. Weiterhin werden Kirchen

aufgelistet bzw. Informationen über alternative Plätze zur Eheschließung angeboten. Bei der

Auswahl eines geeigneten Speisesaals hilft eine Übersicht über Gaststätten und Hotels, die

auch das Hotelzimmer für die Hochzeitsnacht anbieten. Floristen und Kleidungsgeschäfte mit

Brautkleidern gehören ebenso zum Angebot wie Partyservices für den Polterabend oder

Mietwagenfirmen für die Limousine mit Chauffeur. Abschließend helfen Reiseangebote und

Reiseveranstalter bei der Auswahl der Hochzeitsreise.

Personalisierungskonzept

Das Personalisierungskonzept beschreibt die Möglichkeit der Anpassung und Abstimmung

des Portals auf den jeweiligen Nutzer. Es geht dabei nicht um die allgemeine Strukturierung

der zur Verfügung stehenden Daten wie beim Lebenslagenkonzept, sondern darum, den Kom-


fort für einen ganz spezifischen Nutzer zu erhöhen. Der Anwender soll die Möglichkeit erhal-

ten, sich sein persönliches Portal zu schaffen. Dazu kann er aus einer Vielzahl von Lebensla-

gen und Diensten die für ihn interessanten auswählen und somit eine Flut an Informationen

vermeiden. Damit steht dem Anwender nach Anmeldung jeweils die gleiche und gewohnte

Seite zur Verfügung. Weiterhin ist geplant, die Personalisierung durch eine automatische Su-

che von auf das Benutzerprofil abgestimmten Angeboten zu erweitern. Persönliche Präferen-

zen sollen gespeichert werden, um eine erneute Eingabe von Formulardaten zu vermeiden.

Zurzeit (Stand November 2001) bietet KLinform folgende Personalisierungsmöglichkeiten:

• Auswahl verschiedenere Lebenslagen für einen schnelleren Zugriff

• Auswahl verschiedener Dienste von KLinform zum Schnellzugriff

• Auf den Wohnort des Anwenders abgestimmte Wettervorhersage

• Pflege des eigenen Datenbestandes über ein Web-Interface

• Newsletter verschiedener Bausteine

1.2 Ziel und statistische Begründung der Projektarbeit Im Rahmen der Projektarbeit soll die bestehende Funktionalität von KLinform um einen web-

basierten Fahrzeugmarkt erweitert werden. Dabei sollen das Lebenslagen- und das Personali-

sierungskonzept auf die Anforderungen dieses Bausteines adaptiert werden. Die Notwendig-

keit der Integration eines Fahrzeugmarktes in das Portal liegt in einer rasant steigenden Zahl

von Internetnutzern, welche ihren Autokauf durch dieses Medium vorbereiten oder sogar aus-

führen.

Die Anzahl der Europäer, die Auto-Sites im Internet besucht haben, hat sich von April 2000

bis März 2001 mehr als verdoppelt. Dies zeigen die neuesten Ergebnisse von Jupiter MMXI

[Jup 2001].

Immer mehr Europäer nutzen das Internet, um sich vor dem Kauf des nächsten Autos zu in-

formieren, die kürzeste Reiseroute ausfindig zu machen, aktuelle Verkehrsinformationen ab-

zurufen oder sich über Leasingmöglichkeiten und Autoversicherungen zu informieren.

Die Reichweite von Auto-Sites hat sich in den größten Internetmärkten Europas in der Zeit

von April 2000 bis März 2001 verdoppelt. In Großbritannien erhöhte sich die Reichweite von

6,9% auf 12,6% (1.724.000 Unique Visitors im März 2001), in Frankreich von 3,8% auf

10,3% (809.000 Unique Visitors) und in Deutschland von 6,8% auf 15,3% (1.926.000 Unique

Visitors). Die Nutzer der Auto-Angebote waren in diesen Ländern zu mehr als 70% männlich

und im Alter von 25-34 Jahren.


15,3% der deutschen Surfer, das entspricht 1,926 Millionen Unique Visitors, haben im März

2001 mindestens einmal eine Webseite der Kategorie „Auto“ besucht. Dieses Marktsegment

konnte demzufolge seit April 2000 ein Plus von rund 1,3 Millionen Besuchern erzielen. Auf

Rang eins der Hitliste befindet sich die Fahrzeugdatenbank autoscout24.de mit einer Besu-

cherzahl von 642.000 Personen und einer Reichweite von 5,1%, gefolgt von der Autobörse

mobile.de (3,3% Reichweite), 413.000 Unique Visitors). Rang 3 belegte mit 2,0% Reichweite

die Website von Volkswagen, wo neben reinen Produktinformationen auch eine Gebraucht-

wagenbörse zu finden ist. Unter den Auto-Websites in Deutschland erzielte autoscout24.de

seit April 2000 den höchsten absoluten Bucherzuwachs: Während im April vergangenen Jah-

res 184.000 Surfer dieses Online-Angebot nutzten, waren es im März 2001 bereits 642.000.

Anforderungsanalyse Seite 5

2 Anforderungsanalyse Inhalt dieses Kapitels ist die Abstimmung der Benutzeranforderungen und der Umgebungspa-

rameter von KLinform auf die neue Komponente. Ausgangspunkt ist eine umfassende Analy-

se der bereits existierenden Systeme. Besonderer Augenmerk wurde dabei auf Möglichkeiten

der Personalisierung, auf benutzerfreundliche Anwendung und auf innovative Lösungen ge-

legt.

2.1 Erwartungen der Benutzer Der webbasierte Fahrzeugmarkt versteht sich als ein integraler Bestandteil der Lebenslage

Autokauf der Portal-Site KLinform. Um einen Überblick über das zu implementierende Funk-

tionsangebot zu bekommen, soll zunächst dargelegt werden, was Benutzer von einer Online-

Plattform im Automobilbereich erwarten, also welche Funktionen von der gesamten Lebens-

lage abgedeckt werden müssen. Daraus lassen sich die Anforderungen an den webbasierten

Fahrzeugmarkt ableiten. Die folgende Abbildung beschreibt die Wichtigkeit von acht ver-

schiedenen Funktionen. Die Daten basieren auf einer weltweiten Befragung von Haushalten.

3%

5%

18%

26%

27%

56%

80%

89%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

Percentage of Households

Buy a car

Sell old car

Read Classification

Request price quota

Locate Dealer

Look up value of old car

Find and Compare Prices

Get make and model info

Abbildung 1 Erwartung der Benutzer an eine Online-Plattform im Automobilbereich;

Quelle: [Namics 2001]

89% sind demnach daran interessiert, Informationen über das gesuchte Fahrzeug zu bekom-

men. 80% interessieren sich vorrangig für Preise. Lediglich 3% wollen tatsächlich ein Fahr-


zeug online kaufen. Ein Fahrzeugmarkt im Internet sollte sich demnach zunächst als eine In-

formationsplattform verstehen. Es ist nicht das vorrangige Ziel, den eigentlichen Tauschvor-

gang zu vollziehen. Dieser Sachverhalt ist Grundlage der weiteren Ausführungen.

2.2 Analyse existierender webbasierter Automärkte Beispielhaft für Fahrzeugmärkte sollen im folgenden Automärke im Internet einer Analyse

unterzogen werden. In die Analyse wurden alle großen deutschen webbasierten Fahrzeug-

märkte (siehe auch 1.2) aber auch Autohäuser und regional begrenzte Anbieter eingebunden:

u.a. autoscout24.de, mobile.de, car4you.de, faircar.de. Zu einer besseren Vergleichbarkeit im

internationalen Rahmen fließen auch Ergebnisse aus Analysen von nordamerikanischen und

anderen europäischen Fahrzeugmärkten ein, z.B. carmax.com, auto bytel.uk.

Benutzerfreundlichkeit

Um die Benutzerfreundlichkeit zu überprüfen galt es möglichst schnell und einfach einen ge-

brauchten AUDI A4 Avant 2,5 TDI zu finden, der nicht älter als 2 Jahre ist. Auf den Websei-

ten in Nordamerika wurde ein entsprechendes Modell mit Benzinmotor gewählt.

Die deutschen Seiten zeichnen sich funktional gesehen durch ein weitgehend gleiches Layout

aus. Häufig besteht schon auf der Startseite die Möglichkeit Marke, Modell, Erstzulassung

und Leistung des gesuchten Autos zu wählen. Unterschiede bestehen nur im Detail. Während

einige Anbieter eine sehr genaue Einschränkung bzgl. gewünschter Extras und Sonderausstat-

tungen zulassen, besteht bei anderen Anbietern nur eine sehr geringe Auswahlmöglichkeit.

Vor allem kleinere Anbieter verzichten darauf, allerdings ist das Angebot häufig so be-

schränkt, dass eine stärkere Einschränkung eventuell zu keinem Ergebnis mehr führt. Der

größte gefundene Anbieter, autoscout24.de, hat beispielsweise ca. 480.000 (Stand November

2001) Gebrauchtwagen im Angebot, während vor allem regional beschränkte Anbieter (z.B.

Autohäuser) oft nur vereinzelte Angebote haben und die Korrektheit der Daten erhöht.

Weitere Unterschiede bestehen in der Führung des Benutzers durch die auszuwählenden Fel-

der. Die meisten großen Anbieter bieten nach Auswahl der Marke nur noch die Modelle zur

Auswahl an, die von dem entsprechenden Hersteller jemals produziert wurden. Gleiches gilt

im Anschluss für die Auswahl der Motorisierung. Dadurch werden Verwechselungen und

Verwirrung bei der Beschreibung des Fahrzeuges vermieden.

Die angebotenen Informationen sind bei nahezu allen Anbietern identisch. Je nach Umfang

der Angaben des jeweiligen Verkäufers sind die meisten Sonderausstattungen aufgeführt,

häufig wird auch ein Bild des Fahrzeuges angeboten.


Innovative Lösungen

Innovative und außergewöhnliche Lösungen sind bei allen getesteten Seiten Mangelware.

Angenehm für den Benutzer ist die Möglichkeit, die Suchergebnisse nach bestimmten Krite-

rien zu sortieren, beispielsweise nach Laufleistung oder Preis. Leider fehlt diese Funktion

auch bei einigen der großen Anbietern, obwohl gerade bei der sich ergebenden Vielzahl von

Suchergebnissen diese Funktion eine wesentliche Erleichterung darstellen würde.

Alle getesteten amerikanische Anbieter, z.B. carmax.com und einige der deutschen Vertreter

bieten einen Vergleich mehrerer Modelle an. Vor allem im Gebrauchtwagenmarkt erleichtert

eine solche direkte Gegenüberstellung die Entscheidungsfindung.

Car4you.de offeriert vor allem Händlern, die häufig Inserate aufgeben, einen Fotoservice.

Sollte der Händler kein Foto des angebotenen Autos vorliegen haben, so stellt car4you.de ein

entsprechendes Bild aus einer Fotodatenbank zur Verfügung. Ein Foto des angebotenen Mo-

dells erhöht die Verkaufschancen drastisch.

Personalisierung

Keine der analysierten Seiten bietet die Möglichkeit einer umfassenderen Personalisierung.

Lediglich car4you.de und autoscout24.de erwarten vor dem Inserieren eines Verkaufsangebo-

tes eine Registrierung. Allerdings dient diese im Fall von autoscout24.de nur dazu bei mehr-

facher Nutzung eine erneute Eingabe der Daten zu vermeiden. Gleichfalls besteht hier die

Möglichkeit, bestehende Inserate zu verändern.

Aus der Sicht des Käufers besteht weder auf den deutschen noch auf den nordamerikanischen

oder britischen Seiten die Möglichkeit einer Personalisierung. Dies gilt sowohl für eine mög-

liche Anpassung des Layout als auch für die Speicherung von persönlichen Präferenzen bei

der Suche nach Gebrauchtwagen. Im Falle einer erneuten Suche nach dem selben Modell

müssen die Daten wiederholt eingegeben werden. Sowohl bereits betrachtete als auch neue

Angebote werden aufgelistet. Der Kunde hat keine Möglichkeit, neue Angebote sofort zu er-

kennen und von bereits gelesenen zu unterscheiden.

Bewertung existierender Automärkte

Das Angebot an webbasierten Automärkten ist sehr umfangreich. Leider fehlen häufig inno-

vative Lösungen oder Möglichkeiten, auf den Kunden abgestimmte Angebote zu generieren.

Vor allem die großen Anbieter solcher webbasierten Märkte beschränken sich nicht auf die

Vermittlung gebrauchter oder neuer Fahrzeuge, sondern sie bieten ein umfangreiches Service-


angebot rund ums Auto. Dieses umfasst Zusatzinformationen über Versicherungen, Finanzie-

rungen oder Bewertungen von Fahrzeugen. Im Bezug auf das beschriebene Lebenslagenkon-

zept decken die großen Portale bereits die Lebenslage Autokauf nahezu komplett ab. Aller-

dings bieten nicht alle Portale die Möglichkeit, das Angebot auf eine bestimmte Region ein-

zuschränken.

2.3 Benutzeranforderung Ziel ist die Implementierung eines webbasierten Fahrzeugmarktes für die Region Kaiserslau-

tern, der sich außer seiner regionalen Beschränkung durch innovative Lösungen und Mög-

lichkeiten der Personalisierung von bereits existierenden Lösungen absetzt und dem Benutzer

einen merklichen Mehrwert bietet.

Die bereits existierenden webbasierten Fahrzeugmärkte bieten dafür eine relativ umfangreiche

Grundlage. Diese Lösungen sollen übernommen und um das Konzept der Personalisierung zu

erweitert werden. Innovative Lösungen sollen gebündelt und vervollständigt werden.

Unter einem webbasierten Fahrzeugmarkt soll im folgenden verstanden werden: Ein webba-

sierter Fahrzeugmarkt besteht aus Webseiten über die potentielle Käufer und Verkäufer von

Fahrzeugen zusammengeführt und Austauschprozesse vollständig abgewickelt werden.

Besucher eines webbasierten Fahrzeugmarktes, die sich über Angebote informieren wollen

werden im folgenden Käufer genannt, die Angebotsseite wird mit Verkäufer oder Anbieter

beschrieben. Die Menge aller Besucher wird über den Begriff Benutzer definiert.

In die Kategorie der Fahrzeuge fallen im folgenden Kraftfahrzeuge sowie alle Arten von An-

hänger. Ein Kraftfahrzeug ist ein mit Maschinenkraft angetriebenes Straßenfahrzeug, das

nicht an Schienen gebunden ist: Kraftwagen, Kraftrad, Zugmaschine. Zulassung und Betrieb

der Kraftfahrzeuge unterliegen gesetzlichen Vorschriften (Straßenverkehrs- und Straßenver-

kehrszulassungs-Ordnung). [Xipolis 2002].

Aufbauend auf die gegebene Definition soll der Fahrzeugmarkt nicht nur Pkw Angebote ver-

walten können, sondern auch ein Portal für Krafträder (Motorräder, Mofas, etc.) und Wohn-

mobile darstellen. Da Wohnmobile und Pkws in den meisten Eigenschaften übereinstimmen,

können sie über eine gemeinsame Oberfläche verwaltet werden. Krafträder und andere Fahr-

zeugtypen besitzen unterschiedliche spezifische Eigenschaften und werden deshalb jeweils

separat behandelt.

Der Fahrzeugmarkt soll folgende Basisfunktionen bieten:

1) Suche nach einem Fahrzeug

2) Aufgabe eines Inserates


3) Verwaltung eines Verkaufangebots

Die erste Basisfunktion deckt sich mit den Erwartungen, die Benutzer an webbasierte Fahr-

zeugmärkte stellen. Nach [Namics 2001] sammeln bereits 48% der Käufer von Autos mit Hil-

fe des Internets Informationen über ihren Wunschwagen. Dagegen werden nur 3% der Autos

online verkauft und diese Zahl wird bis ins Jahr 2005 auch nicht über einen Anteil von 10%

steigen. Ziel dieses Fahrzeugmarktes ist eine Positionierung als Mittler zwischen Händlern

und Kunden. Der Online -Autoverkauf ist nicht prioritär.

Bereits 83% der Autohändler sind online im Internet vertreten, 93% bieten einen gewissen

Grad von Interaktivität auf den Webseiten an [Namics 2001]. Basisfunktion 2) führt diese

Masse für den Raum Kaiserslautern auf einer einzigen Seite zusammen und vereinfacht somit

die Interaktion zwischen Käufern und Verkäufern. Aus den Aussagen, dass der online Auto-

verkauf nicht prioitär ist ergibt sich die Forderung an die Anbieter, dass die abgegebenen An-

gebote dem tatsächlichen Angebot entsprechen und nicht falsche Angaben gemacht werden,

um Kunden zu ungewollten Handlungen zu bewegen.

Abbildung 2 beschreibt den Aufbau des webbasierten Fahrzeugmarktes anhand der oben ge-

gebenen Definitionen.

Webbasierter Fahrzeugmarkt

Fahrzeugsuche

Inserate verwalten

Inserate aufgeben

Basisfunktionen

PKW/ Wohnmobil

Kraftrad

Fahrzeuge

Käufer

Benutzer

Verkäufer

Daten abrufen, bearbeiten, pflegen

Aufruf Suchen/ Bieten


Fließen ein

Personalisierung

Authentifizierung

Spezifi-zierung

Abbildung 2 Zusammensetzung des webbasierten Fahrzeugmarktes


Aufbauend auf die Basisfunktionen müssen geeignete Lösungen gefunden werden, die dem

Benutzer einerseits größere Spielräume und andererseits intelligente Verfahren zur Zielerrei-

chung bieten. Ziel dabei ist es, die Basisfunktionalität jederzeit zu gewährleisten. Das Layout

muss auf dieses Ziel abgestimmt werden. Der Benutzer, also sowohl der Käufer als auch der

Anbieter, muss jederzeit in der Lage sein, schnell und komfortabel die Basisfunktionen auszu-

führen. Innovative Lösungen und Konzepte der Personalisierung sollten soweit integriert sein,

dass ihre Benutzung intuitiv, beziehungsweise weitestgehend automatisiert möglich wird.

Im folgenden sollen die Basisfunktionen spezifiziert und zusätzliche Lösungen eruiert wer-

den.

2.3.1 Funktionale Benutzeranforderungen Die funktionalen Benutzeranforderungen leiten sich aus den im vorangegangenen Abschnitt

beschriebenen Basisfunktionen ab. Anforderungen von seiten des Projekts KLinform fließen

ebenfalls ein. Beschrieben werden allgemeine Anforderungen, Anforderungen, die sich aus

der Definition von „Fahrzeug“ ergeben, Anforderungen an die Basisfunktionen sowie innova-

tive Lösungen und Personalisierungsmöglichkeiten.

Allgemeine Anforderungen

BA-F Beschreibung der Anforderung

BA-F1 Aufgegebene Inserate müssen in einem geographisch begrenzten Raum um Kaisers-

lautern liegen, um die regionale Konzentration des Portals zu wahren.

BA-F2

Alle Eingaben, außer in Freitexten, werden auf syntaktische und soweit möglich,

auf semantische, Korrektheit überprüft. Im Falle einer Fehleingabe wird ein ent-

sprechender Hinweis mit möglichst exakter Hilfestellung ausgegeben.

BA-F3 Eine kontextsensitive Hilfefunktion zu allen Eingabefeldern und eine Hilfsfunktion

zur Beschreibung der Basisfunktionen und weiterer Features ist zu implementieren.

Abbildung 3 Allgemeine Benutzeranforderungen

Spezifische Anforderungen der Fahrzeugtypen

Die in 2.3 gegebene Definition des Begriffes „Fahrzeug“ verlangt nach einer genaueren Spe-

zifikation der Informationen, die für ein Fahrzeug der jeweiligen Klasse abgefragt und ange-

boten werden. Tabelle 1 gibt einen Überblick über die Eingabefelder, mit denen Käufer ihre

Suche einschränken können bzw. über die Attribute, die bei der Aufgabe eines Inserates ge-


pflegt werden müssen. Zusätzlich steht für jede Fahrzeugkategorie ein Textfeld zur Verfü-

gung, in dem noch nicht abgedeckte Eigenschaften eingetragen werden können.

Alle Fahrzeuge • Marke, Modell, Erstzulassung, Laufleistung, Preis

PKW/ Wohnmo-

bil

• Fahrzeugtyp, Leistung, Treibstoff, Karosserie

1. Erweiterte Optionen

- Verbrauch

- Getriebeart

- Außenfarbe

- Sonderausstattungen/ Sonderleistungen

§ ABS, Alarmanlage, Allrad, Alufelgen, Anhänger-

kupplung, Behindertengerecht, Beifahrer Airbag,

CD, Dachträger, Elektrische Fensterheber, Elekt-

rische Sitzverstellung, Elektrische Außenspiegel,

Fahrerairbag, Katalysator, Klima, Lederausstat-

tung, Navigationssystem, Nebelscheinwerfer, Ra-

dio, Schiebedach, Seitenairbags, Servolenkung,

Sitzheizung, Sportausstattung, teilbare Rücksitz-

bank, Tempomat, Traktionskontrolle, Tuning,

Wegfahrsperre, Winterreifen, Zentralverriegelung

§ Mehrwertsteuer ausweisbar, Garantie, TÜV

Motorrad/ Mofa/

Kraftrad

• Fahrzeugtyp, Motorleistung, Hubraum

• Erweiterte Optionen

- Farbe

- Verbrauch

- Sonderausstattungen/ Sonderleistungen

§ ABS, Alarmanlage, Heizgriffe, Katalysator, Kof-

fer/Topcase, Scheibe, Sturzbügel, Tuning, Ver-

kleidung

§ Mehrwertsteuer ausweisbar, Garantie, TÜV

Abbildung 4 Fahrzeugspezifische Attribute


Die Marke eines Fahrzeuges beschreibt den Hersteller, die Ausprägung des Modells ist ab-

hängig von der Marke. Eine entsprechende Zuordnung ist aber sehr aufwendig. Deshalb soll

eine entsprechende Zuordnung vorerst nicht implementiert werden.

Mit dem Eingabefeld „Fahrzeugtyp“ soll eine Einteilung des Fahrzeuges in die Kategorien

Neufahrzeug, Gebrauchtfahrzeug, Jahresfahrzeug oder Unfallfahrzeug getroffen werden. Die

Analyse bestehender Systeme hat ergeben, dass eine überdurchschnittlich hohe Zahl an Un-

fallwagen über webbasierte Fahrzeugmärkte angeboten werden. Dem Käufer muss die Mög-

lichkeit gegeben werden Suchergebnisse ohne derartige Angebote zu erhalten.

Anforderungen der Basisfunktion „Inserat suchen“

Die Suchfunktion bietet dem Käufer die Möglichkeit, sich über die Angebote im Raum Kai-

serslautern zu informieren. Dabei muss dem Käufer die Möglichkeit gegeben werden, die

Suche möglichst optimal auf seine Bedürfnisse einzustellen, ohne das dabei die Übersicht-

lichkeit verloren geht. Der Suchvorgang muss möglichst schnell ablaufen, um vorzeitige Ab-

brüche zu vermeiden. Die Suchergebnisse müssen ansprechend aufbereitet werden, dem Käu-

fer müssen Funktionen zur Verfügung stehen, welche die Arbeit mit den gefundenen Fahr-

zeugen erleichtern. Die folgende Tabelle beschreibt die funktionalen Anforderungen an die

Suchfunktion.

BA-F BESCHREIBUNG DER ANFORDERUNG

BA-F4 Die Suchoptionen sind standardmäßig auf den allgemeinsten Fall eingestellt und

können schrittweise vom Benutzer spezialisiert werden.

BA-F5

Die Eingabefelder müssen so weit wie möglich Auswahlfelder mit vordefinierten

Werten sein, um die Korrektheit der Angaben zu erhöhen. Beinhaltet ein Eingabe-

feld Datumswerte, so werden diese beginnend mit dem höchsten Wert aufgelistet.

Numerische Werte beginnen mit dem kleinsten Wert, einige Angaben erfolgen in

Form von Intervallen.

BA-F6 Die Anzahl der in der Datenbank vorhandenen Angebote wird angezeigt.

BA-F7 Die Auflistung der Suchergebnisse erfolgt in Tabellenform

BA-F8 Sortiermöglichkeit nach den wichtigsten Attributen

BA-F9 Maximale Spaltenanzahl je Tabelle/Webpage kann variable eingestellt werden

BA-F10

Die detaillierte Anzeige eines speziellen Fahrzeuges enthält alle vorhandenen In-

formationen in Textform. Falls vorhanden, erfolgt die Darstellung des Bildes. In-

formationen über den Verkäufer und entsprechende Kontaktmöglichkeiten werden


aufgelistet. Zur detaillierten Anzeige gelangt der Benutzer über einen Link in der

Ergebnistabelle.

Abbildung 5 Funktionale Benutzeranforderungen – Suchfunktion

Anforderungen der Basisfunktion „Inserat aufgeben“

Die Anbieter sind mit der Aufgabe von Inseraten für den Umfang und die Vollständigkeit der

im webbasierten Fahrzeugmarkt vorhandenen Informationen verantwortlich. Eine vollständi-

ge Kontrolle aller neu aufgegebenen Inserate ist aufgrund begrenzter (menschlicher) Ressour-

cen nicht möglich. Das System muss den Verkäufer dabei unterstützen, möglichst korrekte

und ausführliche Werte einzugeben, ohne dabei den notwendigen Spielraum zu stark einzu-

schränken. Eine Möglichkeit dabei ist die Vorgabe möglicher Attributausprägung und die

Definition von Eingabefeldern, die ausgefüllt werden müssen. Offene Textfelder geben dem

Verkäufer die Freiheit auf zusätzliche, ihm wichtig erscheinende Eigenschaften des angebote-

nen Fahrzeuges hinzuweisen. Im folgenden sind die funktionalen Anforderungen an die be-

schriebene Basisfunktion aufgelistet.

BA-F BESCHREIBUNG DER ANFORDERUNG

BA-F11

Das Inserieren eines Fahrzeuges ist nur nach Registrierung bei KLinform und im

eingeloggten Zustand möglich. Bereits vorhandene Daten aus der Registrierung

werden verwendet und müssen nicht neu eingegeben werden.

BA-F12

Alle Felder, die in den Abschnitten über die Fahrzeugspezifischen Informationen

nicht unter den Punkt „Erweiterte Optionen“ fallen, müssen eingegeben werden,

ansonsten erfolgt kein Eintrag in die Datenbank. Erweiterte Optionen haben bezüg-

lich der Eingabe einen optionalen Charakter.

BA-F13

Die Eingabefelder müssen so weit wie möglich Auswahlfelder mit vordefinierten

Werten sein, um Missbrauch zu verhindern und die Korrektheit der Angaben zu

erhöhen. Beinhaltet ein Eingabefeld Datumswerte, so werden diese beginnend mit

dem höchsten Wert aufgelistet. Numerische Werte beginnen mit dem kleinsten

Wert.

BA-F14

Ein Bild kann, muss aber nicht übergeben werden. Falls bereits ein Fahrzeug der

selben Marke und des selben Typs in der Datenbank mit Bild existiert, steht dem

Nutzer frei, dieses Bild für sein Inserat zu verwenden. Es wird das Bild mit der

größten Übereinstimmung der angegebenen Merkmale vorgeschlagen. Der Anbieter

kann zur genaueren Darstellung seines Angebotes ein Bild hochladen.


BA-F15 Vor dem Eintrag in die Datenbank wird dem Inserat ein eineindeutiger Schlüssel in

Form einer Nummer zugeordnet.

BA-F16

Dem Administrator wird nach erfolgreicher Aufgabe des Inserates eine Email mit

allen gemachten Angaben geschickt. Des weiteren erhält er mit der Email die er-

stellte Nummer des Inserates.

Abbildung 6 Funktionale Benutzeranforderungen – Inserat aufgeben

Anforderungen der Basisfunktion „Inserat verwalten“

Nach der Aufgabe eines Inserates muss dem Verkäufer die Möglichkeit gegeben werden, sein

Inserate zu löschen oder innerhalb des definierten Spielraumes abzuändern. Damit ist er in der

Lage ein wenig ansprechendes Angebot in eine für beide Parteien positive Richtung zu verän-

dern.

BA-F Beschreibung der Anforderung

BA-F17

Während der Laufzeit des Inserates können alle Daten nach vorherigem Login ge-

ändert, gelöscht oder erweitert werden. Bei der Suche nach dem zu ändernden Inse-

rat hilft die zugeteilte Nummer. Das Inserat kann auch komplett gelöscht werden.

BA-F18

Nach Speicherung der Änderungen wird dem Anbieter automatische eine Email mit

den geänderten Daten zugesandt. Die bei der Erstellung zugewiesene Nummer

bleibt unverändert

Abbildung 7 Funktionale Benutzeranforderungen - Inserat verwalten

Aktualität und Korrektheit des Angebotes

Wie bereits im obigen Punkt erwähnt liegt die vorrangige Verantwortung für die Korrektheit

und Vollständigkeit des Angebotes bei den Anbietern. Um Missbrauch zu vermeiden muss

der Webmaster in der Lage sein, unseriöse und falsche Angebote aus der Datenbank zu ent-

fernen. Da solche Angebote häufig erst bei der Suche nach einem Fahrzeug auffallen, wird

der webbasierte Fahrzeugmarkt um eine Funktion erweitert, die es den Käufern erlaubt, sol-

che Angebote zu sperren. In der Detailansicht eines Angebots steht ihnen dazu ein entspre-

chender Link zur Verfügung. Der Administrator erhält daraufhin eine Mitteilung über die ge-

wünschte Sperrung und kann dann nach erneuter Prüfung diese durchführen.

Um die Aktualität des Angebotes zu wahren, werden die Inserate nach Ablauf einer festgeleg-

ten Zeit automatisch aus der Datenbank entfernt, vorausgesetzt es wurde während dieser Zeit

keine anbieterseitig Aktualisierung vorgenommen werden. 14 Tage vor Ablauf dieser Zeit-

spanne wir der Inserator darüber informiert, dass er sein Inserat verlängern kann. Damit wird


sichergestellt, dass der Anteil an bereits verkauften, aber noch angebotenen Fahrzeugen mög-

lichst gering bleibt. Selbstverständlich wird der Anbieter über die erfolgte Löschung benach-

richtigt.

Personalisierung der Funktionen

Entsprechend den Projektanforderungen liegt ein Hauptaugenmerk auf den Möglichkeiten der

Personalisierung. Die Personalisierung setzt voraus, dass der Benutzer bereits registriert und

auch eingeloggt ist.

Registrierte Käufer können in einem vordefinierten Rahmen Art und Umfang der Suchergeb-

nisse einstellen. Darunter fallen die Anzahl der pro Website angezeigten Treffer (vgl. BA-F9)

sowie die in der Ergebnistabelle aufgeführten Spalten. Diese Funktion trägt den differenzier-

ten Auswahlkriterien der Käufer Rechnung. Die beim Autokauf entscheidenden Eigenschaf-

ten des gesuchten Wagens sind stark geschlechtsabhängig. Während Männer die Schwerpunk-

te eher im Bereich der Technik setzten, steht für Frauen Form und Farbe des Wagens im Vor-

dergrund. Eine geschlechtsspezifisch gestaltete Oberfläche erhöht die Anwenderfreundlich-

keit. Die auf der Startpage gezeigten Eingabefelder sollen abhängig von dem Geschlecht der

angemeldeten Person gewählt werden. Diese Unterscheidung wird auch bei der Wahl der in

der Ergebnistabelle angezeigten Standardfelder fortgesetzt. Unabhängig von den oben be-

schriebenen Auswahlmöglichkeiten ist damit bereits eine automatische Personalisierung er-

folgt.

Registrierte Käufer können ebenfalls ein persönliches Fahrzeugprofile erstellen. Bei wieder-

holten Suchvorgängen nach dem selben Fahrzeugtyp entfällt somit die erneute Eingabe der

Daten. Weiterhin wird dem User angeboten, seine Profile zur automatischen Suche nach neu

eintreffenden Inseraten freizuschalten. Die Datenbank wird periodisch auf entsprechende

Angebote hin durchsucht. Sollte ein neues Inserat dem gewünschten Profil entsprechen, wird

der Nutzer automatisch per Email benachrichtigt. Zur genauen Identifizierung und zum

schnellen Auffinden des entsprechenden Inserates wird der Hyperlink auf die Detailansicht

des Inserates mit übermittelt.

Vor allem für professionelle Verkäufer dürfte interessant sein, wie viele Benutzer die Detail-

ansicht des jeweiligen Inserates aufrufen. Eine solche Funktion soll in das Angebot des web-

basierten Fahrzeugmarktes integriert werden. Mit Hilfe dieser Funktion kann der Verkäufer

Rückschlüsse auf das Interesse seines Inserates innerhalb der Käufermenge erhalten und dar-

auf aufbauend Änderungen vornehmen. So lässt beispielsweise ein gut besuchtes Inserat, dass

aber nur wenige direkte Anfragen generiert, den Schluss zu, dass den Käufern der Preis für


die gebotene Ausstattung zu hoch ist. Liegt dagegen die Konversionsrate auf einem über-

durchschnittlichen Niveau, so handelt es sich eventuell um ein besonders günstiges Angebot.

Die Möglichkeiten der Personalisierung sollten intuitiv einsetzbar sein. Sie sollten dem Be-

nutzer dann vorgeschlagen werden, wenn dieser sich in einer Situation befindet, in der die

Vorteile der Personalisierung verstehen und die Funktionen annehmen wird. Die Realisierung

dieser Funktion darf zu keiner Belästigung des Benutzers führen. Alle Basisfunktionen müs-

sen ohne vorherige Einstellungen ausführbar sein.


Bei der Analyse existierender Fahrzeugmärkte ist aufgefallen, dass eine Suchoption zum Auf-

finden eines möglichst ökonomischen Angebotes nicht bereitgestellt wird. Die marken- und

typübergreifende Suche nach einem günstigen Wagen mit einer geringen Steuerklasse und

geringem Verbrauch hilft vor allem Käufern mit geringem finanziellen Spielraum. Da die

Eingabe der Steuerklassen für private Anbieter zu aufwändig ist, beschränkt sich diese Funk-

tion auf die Suche über die zusätzliche Verbrauchsangabe. Dieser Zusatznutzen wird in die

Standardeingabe integriert und kann damit vom Käufer direkt ohne weitere Auswahl genutzt

werden.

Die Suche nach einem neuen Fahrzeug gestaltet sich dann schwierig, wenn das Wunschfahr-

zeug nur unzureichend beschrieben werden kann. Häufig hat der Suchende nur ungenaue Vor-

stellungen des gesuchten Fahrzeuges. Deshalb liefert eine Suchfunktion, die nur genau nach

den eingegebenen Werten in der Suchmaske sucht, unbefriedigende, weil nicht vollständige

Ergebnisse. Aus diesem Grund sollen Methoden aus der künstlichen Intelligenz, besonders

aus dem Bereich des Information Retrieval genutzt werden, um auch mit ungenauen Daten

befriedigende Suchergebnisse zu erhalten. Denkbar wäre in diesem Zusammenhang bei-

spielsweise das Vektorraummodell, welches auch bei vielen Suchmaschinen im Internet zum

Einsatz kommt.

Bereits bei der Spezifizierung der Basisfunktionen wurde darauf verwiesen, dass pro Inserat

ein Bild des Fahrzeuges von dem Verkäufer gespeichert werden können. Dadurch erhält der

Käufer bereits online einen sehr guten Eindruck der tatsächlichen Optik des Fahrzeuges. Er

erspart sich dadurch zeitaufwändige Besuche bei dem Verkäufer, falls ihm das Fahrzeug op-

tisch nicht in vollem Umfang zusagt.


2.3.2 Nichtfunktionale Benutzeranforderungen

BA-NF BESCHREIBUNG DER ANFORDERUNG

BA-NF1

Um dem Benutzer ein unkompliziertes Arbeiten auf dem Portal unabhängig von

dem gewählten Internetzugang zu ermöglichen, muss das Programm von allen

gängigen Internetbrowser - Betriebssystemkombinationen angezeigt werden kön-

nen und ein annährend identisches Layout besitzen. Dazu ist vor allem die Dar-

stellung auf den beiden meistgenutzten Browsern - Microsoft Internet Explorer

und Netscape Communicator (beide ab Version 4.0 oder höher) – im Zusammen-

spiel mit den meistverbreiteten Betriebsystemen – Microsoft Windows Familie,

MacOs, Unix und Linux – zu testen.

BA-NF2 Das Laden der Seiten sollte auch bei langsamen Internetverbindungen sehr schnell

gehen.

BA-NF3

Die Gestaltung der Seiten sollte weitestgehend identisch und möglichst klar und

selbsterklärend sein. ‚Weiter’, ‚Zurück’ und ‚Abbrechen’ Buttons sind auf jeder

Seite zur schnellen Navigation darzustellen.

BA-NF4 Einträge und Änderungen in die Datenbank sind nur im authentifizierten Zustand

erlaubt.

Abbildung 8 Nichtfunktionale Benutzeranforderungen

2.3.3 Inverse Benutzeranforderungen

BA-Inv Beschreibung der Anforderung

BA-Inv1 Die Daten in der Datenbank dürfen nicht verloren gehen. Die Konsistenz muss

auch nach einem Systemabsturz gewahrt bleiben.

BA-Inv2

Es dürfen keine Inhalte in der Datenbank gespeichert werden, die nicht in Bezug

zu dem angebotenem Fahrzeug oder zu dem webbasierten Fahrzeugmarkt allge-

mein stehen

Abbildung 9 Inverse Benutzeranforderungen

2.3.4 Entwurfsentscheidungen

EE Beschreibung der Anforderung

EE1 Implementierungssprache ist Java (Java 2 SDK 1.3)

EE2 Die zu erstellenden Webseiten werden mit JSP implementiert; der verwendete JSP-

Container ist tomcat.


EE3 Die verwendete Datenbank ist PostgreSQL Version 7.

EE4 Die Datenbankanbindung erfolgt mittels JDBC.

EE5 Auf die Verwendung von JavaScript und dem Setzten von weiteren Cookie- Inhal-

ten außer der Session-ID muss verzichtet werden.

Abbildung 10 Entwurfsentscheidungen

Die folgende Abbildung gibt einen Überblick über die Architektur der Systemumgebung. Au-

ßerdem wird der Datenfluss durch das System beschrieben.

Firewall

Apache Web

Server

Applikations - Server

( Tomcat )

Automatisch erzeugte

HTML - Datei DBMS PostgreSQL

Server Client (Benutzer)

Internet Browser

Automatisch erzeugte

HTML - Datei

HTML - Datei mit Formular

übertragen

HTML - Datei übertragen

HTML - Datei

erzeugen

JSP

PoolManager

An Appl . - Server weiterleiten

Formular abschicken

DB Ab - und Anfrage

Abbildung 11 Hard- und Software- Plattform

2.4 Zusammenfassung Ziel des Projektes KLinform ist es, einen erheblichen Mehrwert für den Benutzer gegenüber

anderen Portal-Sites zu bieten. Diese Anforderung gilt auch für den webbasierten Fahrzeug-

markt. Erschwert wird diese Anforderung durch eine Vielzahl bereits auf dem Markt vorhan-

dener webbasierter Fahrzeugmärkte, die auf den Handel mit gebrauchten und neuen Fahrzeu-

gen spezialisiert sind. Diese Märkte sind in der Lage durch ihre Spezialisierung beständige

Verbesserungen und Erweiterungen vorzunehmen. Gleichzeitig konzentrieren sie ein großes

Angebot mit einer großen Nachfrage.


Einen entscheidenden Vorteil bietet das Konzept der Personalisierung. Besonders die großen,

sich bereits auf dem Markt befindlichen Anbietern bieten eine sehr große Auswahl an Fahr-

zeugen an, und es gestaltet sich als sehr aufwändig, auf der Suche nach einem Wunschwagen

regelmäßig des komplette Angebot zu durchsuchen. Die automatische Durchsuchung neuer

Angebote auf der Basis eines eingegebenen Wunschprofils stellt einen erheblich geringeren

Aufwand für den Benutzer dar.

Die regionale Beschränkung des Angebots ermöglicht dem Käufer eine schnelle und mit ge-

ringem Zeitaufwand verbundene Abwicklung des Kauf- und Übergabevorganges. Außerdem

erhält er dadurch die Möglichkeit, interessante Produkte direkt vor Ort zu begutachten.

Die Konzentration möglichst vieler, bereits auf anderen Portalen vorhandener innovativer

Lösungen, suggeriert dem Benutzer einen weiteren Mehrwert.

Umgebungsstruktur Seite 20

3 Umgebungsstruktur In den Entwurfsentscheidungen in Kapitel 2 wurde bereits ein kurzer Überblick über die zu

verwendenden Werkzeuge zur Umsetzung des Systems gegeben. Als zentrales strukturgeben-

des Element fungiert das Model- View- Controller Design Pattern. Jede der drei Komponen-

ten kann durch eine Auswahl an Werkzeugen umgesetzt werden. Im folgenden Kapitel soll

zunächst die Model- View- Controller- Architektur näher beschrieben werden. Im Anschluss

daran soll der Überblick über die zu verwendenden Werkzeuge vervollständigt und konkreti-

siert werden.

3.1 Das MVC-Design Pattern Programme mit graphischer Benutzeroberfläche werden schnell kompliziert und unübersicht-

lich. Um zu verhindern, dass solche Programme ab einer bestimmten Größe unwartbar wer-

den, ist es erforderlich, sie mit einer Architektur zu versehen [Tataryn 2002]. Das Model-

View- Controller Design Pattern beschäftigt sich damit, wie sich Programme mit graphischen

Benutzeroberflächen besonders gut organisieren lassen. Es handelt sich hierbei um eine Tech-

nik zur Trennung der Businesslogik (Model), vom User Interface (View) und Ablaufsteue-

rung (Controller).

Controller

Model

View

User

Abbildung 12 MVC Design Pattern im Überblick

Abbildung 12 gibt einen allgemeinen Überblick über das MVC Design Pattern. Die einzelnen

Komponenten übernehmen dabei folgende Funktionen:

• Der View definiert wie Daten dem Benutzer präsentiert werden. Der View muss dabei

auf Veränderungen des Modells reagieren können.

• Das Model repräsentiert die Daten im System, die von dem Programm in Form von

Objekten verarbeitet werden.

• Der Controller ist der Kitt zwischen Model und View. Er ist zuständig für die Kontrol-

le des Programmablaufs und steuert Aktualisierungen zwischen Model und View und

umgekehrt.


Diese recht allgemeine Definition soll nun auf das vorliegende Problem adaptiert werden. Die

Trennlinie, vor allem zwischen Model und Controller, verläuft dabei nicht immer scharf. Die

folgende Abbildung dient als Übersicht, welche Implementierungswerkzeuge in den einzelnen

Komponenten zum Einsatz kommen.

Client Controller(=Servlet, JSP)

View(=JSP)

Model(=Java Bean,

SQL)DB

(=SQL)

stellt Daten bereit

Abbildung 13 MVC - Komponenten und Werkzeuge

3.2 Werkzeuge zur Umsetzung des Problems JavaServer Pages (JSP)

JavaServer Pages sind im Aufbau vergleichbar mit HTML-Dokumenten. Sie bestehen jedoch

aus zwei Teilen: einem HTML-Text sowie beliebig vielen, darin eingebetteten Anweisungen

an den JSP-Server [Turau 2000, S.22]. Die Technologie der JSP versetzt den Anwender daher

in die Lage, reguläres, statisches HTML mit dynamisch generierten Inhalten von Servlets zu

mischen [Hall 2001, S.31]. Zum Einfügen der JSP-Anweisungen dienen spezielle, jedoch

HTML-ähnliche Tags.

JavaBeans

Die Einbettung von Java-Quelltext in HTML-Dokumente schafft leider immer noch keine

befriedigende Trennung der Darstellung (HTML) von der zugrundeliegenden Verarbeitungs-

logik (Java). Man kann allerdings durch die Verwendung von Beans die Trennung deutlich

verbessern.

Um eine über den Umfang von JavaServer Pages hinausgehende Funktionalität zur Verfü-

gung zu haben, bietet sich die Verwendung der konfigurierbaren und adaptierbaren Software-

komponente JavaBeans an [Turau 2000, S.103]. Mit Software-Komponenten versucht man

wiederverwendbare Bausteine zu realisieren, die man anschließend mit speziellen Werkzeu-

gen verknüpfen und zu neuen Anwendungen zusammenstecken kann (Lego-Prinzip). Ziel ist


es, die Entwicklungszeit, durch die Wiederverwendung und den Einsatz von Werkzeugen,

drastisch zu verkürzen.

Mit der Aktion jsp:useBean kann ein Bean für die Benutzung in einer JSP-Seite geladen

werden. JavaBeans nutzen dabei die entscheidende Attraktivität von Java – die Plattformu-

nabhängigkeit.

JDBC

Java-Anwendungen greifen auf SQL- Datenbanken über einen JDBC- Treiber zu (Java Data-

base Connectivity). Dadurch kann der Java Sourcecode weitgehend datenbankunabhängig

gehalten werden, so dass ein späterer Wechsel der SQL- Datenbank leicht möglich ist [Horn

2002]. JDBC 1.0 wurde 1997 speziell für den Einsatz in relationalen Datenbank Management

Systemen (DBMS) entwickelt [Bücker 2002, S.13]. In JDBC existieren vier Treiberarten. Zur

Implementierung von KLinform kommt dabei der sogenannte Typ 4 Treiber zum Einsatz. Er

wandelt JDBC Aufrufe direkt in datenbankspezifische Netzwerkbefehle um. Diese Befehle

werden von der Datenbank-API direkt auf dem Server ausgeführt, so dass kein Laden von

Binärcode auf der Seite des Client erforderlich ist. Dieser Treibertyp wird von nahezu allen

Datenbanken unterstützt und ist zugleich die schnellste, effektivste und sicherste der vier Va-

rianten [Bücker 2002, S.12]. Abbildung 14 zeigt den prinzipiellen Aufbau des Treibers, wie er

von KLinform genutzt wird.

Java-Applikation

JDBC-API

JDBC-TreibermanagerJDBC-Treiber-API

Treiber PostgreSQL

PostgreSQL

Abbildung 14 JDBC Typ 4 – Treiber; Quelle [Bücker 2002]

1998 wurde der Funktionsumfang durch JDBC 2.0 erweitert. Bei Multiuser-Anwendungen,

wie im Fall von KLinform, greifen oft viele Benutzer gleichzeitig auf eine Datenbank zu. Um

ressourcenschonend mit nur einer Datenbankverbindung auskommen zu können, wird Con-


nection Pooling eingesetzt. Während hierfür sonst externe Erweiterungen notwendig wären,

ist die inzwischen Teil der JDBC 2.0 Spezifikation.

PostgreSQL

SQL steht für Structured Query Lanquage und wird als Schnittstelle zu relationalen Daten-

banken benutzt. SQL ist nach dem American National Standards Institute (ANSI) Standard

genormt und damit auf vielen relationalen Datenbank Management Systemen (RDBMS) an-

wendbar. SQL Anweisungen werden sowohl zu Daten-Abfrage als auch zur Daten-Definition

verwendet [Müller 2002].

PostgreSQL ist ein objektrelationales DBMS, dessen Sourcecode frei erhältlich ist und auf

verschiedenen Plattformen läuft. Das Ziel von PostgreSQL ist es, vollkommen kompatibel zu

dem ANSI Standard von SQL zu werden.

3.3 Use-Case-Diagramm als Handlungs- und Umgebungs-beschreibung

Als Grundlage und grobe Richtlinie für die Implementierung des Systems dient die Beschrei-

bung der umzusetzenden Use-Cases. Diese leiten sich weitestgehend aus den in Abschnitt 2.3

beschriebenen Basisfunktionen ab. Das folgende Use-Case-Diagramm beschreibt neben den 3

Basisfunktionen auch noch weitere Interaktionsmöglichkeiten der Aktoren untereinander.


Abbildung 15 Use-Case-Diagramm

Als Aktoren werden dabei der Benutzer, der Administrator und auch die Datenbank gesehen.

Der Benutzer kann nach einem Fahrzeug suchen, ein Inserat anlegen und dieses verwalten.

Daneber ist er in der Lage ein Suchprofil anzulegen und dieses zu bearbeiten, also zu ändern

beziehungsweise zu löschen. Um die Aktualität der Angebote zu waren, Missbrauch des

Fahrzeugmarktes zu verhindern und um Fehler seitens der Benutzer zu korrigieren, muss der

Administrator in der Lage sein, die Inserate zu prüfen und gegebenenfalls zu bearbeiten. Da-

bei führen die meisten Aktionen sowohl der Benutzer, als auch des Administrators zu Verän-

derungen in der Datenbank.

Systementwurf auf Basis des MVC-Design Pattern Seite 25

4 Systementwurf auf Basis des MVC-Design Pattern Die Umsetzung des MVC-Design Pattern ist Inhalt des folgenden Kapitels. Dieser Teil der

Ausarbeitung beschränkt sich dabei auf die Implementierung des Fahrzeugmarktes für Perso-

nenkraftwagen. Die Komponente der Krafträder ist sowohl strukturell als auch inhaltlich iden-

tisch. Eine Integration in diese Arbeit erhöht lediglich die Unübersichtlichkeit der gesamten

Struktur im Allgemeinen und der Abbildungen im Speziellen. Im Folgenden sollen sowohl

die Funktionalität als auch die Strukturierung der drei Komponenten des MVC- Design Pat-

tern beschrieben werden. Einen ersten Überblick über die Umsetzung in dem Gesamtsystem

gibt Abbildung 16. Zur besseren Veranschaulichung sind die Dateien den jeweiligen Kompo-

nenten farblich zugeordnet.

Die im Abschnitt 2.3 beschriebenen Basisfunktionen sind in jeweils separaten Unterverzeich-

nissen des Verzeichnisses ‚$klinform/html/bs/fahrzeugmarkt/' umgesetzt. Außerdem existiert

ein Verzeichnis zur Umsetzung der Eingriffsmöglichkeiten des Administrator (‚admin/’), zur

Steuerung des Uploads von Bildern (‚bild_hochladen/’- die Speicherung der Bilder erfolgt in

dem Verzeichnis ‚bilddatei/’) und für die Detailansicht des Fahrzeuges (‚detail/’). Der grobe

Ablauf ist dabei in allen Teilbereichen gleich strukturiert. Die Funktionalität der Controller-

Komponente wird durch eine oder mehrere index- Dateien übernommen. Durch sie wird der

Programmfluss gesteuert, indem, entsprechend der Eingaben des Benutzers, die gewünschten

Aktionen ausgeführt werden. Die Kommunikationsschnittstelle mit dem Benutzer übernimmt

dabei die View- Komponente. Hierfür existiert für annährend jede Webseite, die der Benutzer

aufrufen kann, eine jsp-Datei. Dabei wird die Funktionalität zumeist durch Formulare ge-

währleistet. Aus diesen Formularen heraus werden dann die index- Dateien aufgerufen, die

die übergebenen Werte verarbeiten.

Die Speicherung der Daten erfolgt in den JavaBeans. Sie werden in der Datei ‚beans.jsp’

angelegt und initialisiert. Die zugehörigen class-Dateien befinden sich in dem Verzeichnis

‚$klinform/WEB_INF/classes/de/klinform/bs/fama’. Durch sie wird die Model-Komponente

umgesetzt. Genaugenommen ist hierin auch noch eine Teil der Funktionalität der Controller-

Komponente enthalten. So wird beispielsweise die Reihenfolge zum Löschen oder Speichern

eines Inserates festgelegt. Es handelt sich also um die Steuerung des Programmablaufs auf

einer detaillierteren Ebene. Hauptaufgabe aber ist, die Daten in der Datenbank zu speichern,

beziehungsweise von dort auszulesen und die dauernde Konsistenz der Daten zu überwachen

und zu gewährleisten.


$klinform index.jsp

/html/bs/fahrzeugmarkt/

suchen/

inserieren

inserat_bearbeiten

bild_hochladen

admin index.jsp

formular.jsp

formular_ein_

inserat.jsp

index.jsp

index2.jsp

formular_bild_

hochladen.jsp

index.jsp

index_suchergebnis.

jsp

index_suchergebnis_expertensuche.

jsp

formular.jsp

formular_suchanfrage.

jsp

formular_suchergebnis.

jsp

formular_suchanfrage_

geloescht.jsp

formular_suchergebnis_expertensuche.

jsp

formular_speichern_

bestaetigen.jsp

formular_aendern_

bestaetigen.jsp

index.jsp

formular1.jsp

formular2.jsp

formular3.jsp

ok.jsp

index.jsp

formular1.jsp

formular2.jsp

formular3.jsp

ok.jsp

index_suchergebnis.

jsp

formular_loeschen_

bestaetigen.jsp

formular_keine_

berechtigung.jsp

/WEB-INF/classes/de/

klinform/bs/famaDBConnection.

classBenutzer.

classFahrzeug.

classPKW.class

Interne_Abarbeitung.

class

Formular_Detail.class

FileUploadBean.class

bilddatei

Model-Komponente

Controller-Komponente

View-Komponente

detail index.jsp

formular.jsp

beans.jsp

formular_statistik.

jsp

formular_inserat_sperren.

jsp

formular_inserat_sperren.

jsp

Abbildung 16 Struktur des Bausteines Fahrzeugmarkt


4.1 Objektorientierte System- und Datenbankstruktur (Mo-dell- Komponente)

Wie bereits in Abschnitt 3.1 beschrieben wurde, repräsentiert das Modell die Daten im Sys-

tem, die von dem Programm in Form von Objekten verarbeitet werden. Die Daten sind dabei

dauerhaft in der Datenbank gespeichert. Zur Verarbeitung im System werden diese Daten in

Objekte der Klassen geladen, welche über dieselbe Struktur verfügen, wie die entsprechende

Tabelle in der Datenbank.

Datenbankstruktur

Als Spezifikationsgrundlage für das Datenbankschema dient das Entity- Relationship- Dia-

gramm in Abbildung 17. Bis auf „Inserat“ sind alle hier dargestellten Entitäten, weitestgehend

mit identischen Namen, als Tabellen in der Datenbank vorhanden. Die Entität „Inserat“ ist

obsolete, weil Inserate in den jeweiligen Tabellen „PKW“ und „Kraftrad“ gespeichert werden.

Fahrzeug

PKW Kraftrad

is_a is_a

Inserat Benutzerist Inseratorvon[1,1] [0,n]

Inserat enthält

[1,1]

[1,1]

Suchprofil hat [0,1][1,1]

Marke

Ausstattung

hat

hat

[0,n]

[0,n]

Aufbauarthat [0,n]

Typhat [0,n][1,1]

[1,1]

[0,n]

[1,1]

Abbildung 17 Entity- Relationship- Diagramm

Im folgenden sollen die Entitäten kurz erläutert werden:

• Entität Benutzer:

Die Informationen über den Benutzer des Fahrzeugmarktes sind bereits in der Daten-

bank vorhanden, da es sich hierbei um den bei KLinform angemeldeten User handelt.


Aus diesem Grund werden diese Daten nicht erneut gespeichert, sondern in der Tabel-

le fama_benutzer wird lediglich der Primärschlüssel von perso_benutzer referenziert.

Aus diesem Grund kann ein Inserat, beziehungsweise ein Suchprofil nur dann gespei-

chert werden, wenn der Benutzer eingeloggt ist und somit die Identifikationsnummer

bekannt ist. In der Tabelle werden nur die Attribute hatinserat und hatsuchanfrage

verwaltet. Diese werden auf den Wert „true“ gesetzt, sobald der Benutzer mindestens

ein Inserat, beziehungsweise ein Suchprofil gespeichert hat. Besitzt ein Benutzer we-

der ein Suchprofil noch ein Inserat, so wird er in der Tabelle fama_benutzer nicht ge-

führt.

• Entität Fahrzeug:

Hier werden alle Attribute gespeichert, die unabhängig von der jeweiligen Fahrzeug-

kategorie verwaltet werden müssen. Diese Tabelle wird nur dann direkt angesprochen,

wenn Aktionen ausgeführt werden, die keine direkten Veränderungen in den erbenden

Tabellen vornehmen. Ansonsten beziehen sich die SQL- Statements auf die erbenden

Tabellen fama_pkw und fama_kraftrad. Das Attribut ID kann dabei als die eindeutige

Nummer des Inserates verstanden werden da, wie beschrieben, nur durch ein neues In-

serat ein neuer Eintrag in der Tabelle gemacht wird. Das Feld Inserator hat wiederum

eine Referenz auf den Primärschlüssel von perso_benutzer. Inserate können nur durch

angemeldete KLinform User angelegt werden. Gleichzeitig ist diese Entität existentiell

abhängig von perso_benutzer. Wird der zugehörige Inserator gelöscht, wird auch der

entsprechende Eintrag aus der Tabelle entfernt.

• Entität PKW

Alle PKW-typischen Attribute werden in der Tabelle fama_pkw gespeichert. Durch

den SQL- Befehl ‚INHERITS (fama_fahrzeug)’ erbt diese Tabelle von fama_fahrzeug.

Alle Attribute der vererbenden Tabelle sind somit über die erbende Tabelle ansprech-

bar. Gleichzeitig sind gemeinsame Daten gekapselt, Informationen über den Benutzer

und die ID des Inserates müssen nicht erneut verwaltet werden.

• Entität Suchprofil

Eine erste Betrachtung des System lässt die Frage aufkommen, ob gespeicherte Such-

profile von den Inseraten separiert werden müssen, oder ob sie in einer gemeinsamen

Tabelle verwaltet werden sollten. Gegen eine Zusammenlegung sprechen folgende

drei Punkte:

- Die Attribute des Suchprofil stimmen nicht vollständig mit denen eines Insera-

tes überein. So werden von einigen Attributen „von“ und „bis“ Werte gespei-


chert, um die Suche nach Inseraten zu vereinfachen. Eine gemeinsame Tabelle

würde daher eine Vielzahl überflüssiger Attribute enthalten.

- Eine weiteres Attribut wäre notwendig, um eine klare Unterscheidung von In-

seraten und Suchprofilen vorzunehmen.

- Mangelnde Übersichtlichkeit durch Vermengung von Inseraten und Suchprofi-

len

Daher werden Suchprofile in einer eigenen Tabelle verwaltet. Diese Tabelle erbt nicht

von fama_fahrzeug oder fama_pkw, sondern die notwendigen Attribute werden separat

gepflegt. Eine Vererbung würde auch hier zwangsläufig zu überflüssigen Attributen

führen. Dagegen wird auch hier wieder der Primärschlüssel von perso_benutzer refe-

renziert, um die Konsistenz der Daten zu gewährleisten und die existenzielle Abhän-

gigkeit zu implementieren.

• Entitäten Marke, Aufbauart, Typ

Auf dem Fahrzeugmarkt existieren eine Vielzahl von Marken. Um diese zu kapseln

und den verschiedenen Anwendungen zur Verfügung zu stellen, werden alle bekann-

ten Marken in der Tabelle fama_marken verwaltet. Dabei wird zwischen der ID der

Marke und dem eigentlichen Markennamen unterschieden. Erstere wird verwendet um

Inserate in den Entitäten Suchprofil und Fahrzeug zu speichern. Der Markenname

dient nur zur Kommunikation mit dem Benutzer. Bei den Identifikationsnummern 0

bis 200 handelt es sich um Marken für PKW, 200-300 beschreiben Marken von Kraft-

rädern.

Die Entitäten Aufbauart und Typ werden entsprechend in den Tabellen fa-

ma_aufbauart und fama_typ verwaltet. Dabei beschreibt Aufbauart die Karosserie-

form des PKW beziehungsweise die Aufbauart des Kraftrades. Die Entität Typ unter-

scheidet beispielsweise zwischen Neuwagen und Gebrauchtwagen.

• Entität Ausstattung

Gekapselt werden ebenfalls mögliche Sonderausstattungen gespeichert. Doch im Ge-

gensatz zu der Entität Marken sollen hier keine Attributsausprägungen, sondern die

Attribute selber gespeichert werden. Die Ausstattungen der Fahrzeuge unterliegen ei-

nem dauerndem Wechsel und die gewünschten Sonderausstattungen auf dem Ge-

brauchtwagenmarkt passen sich diesen Änderungen an. Standen noch vor wenigen

Jahren ABS und Fahrerairbag nur in gehobenen Preissegmenten zur Verfügung, so ge-

hören Sie heute zur Serienausstattung in beinahe jedem PKW. Eine dezentrale Verwal-

tung solcher Attribute würde die Wartbarkeit dieses Bausteins erheblich aufwendiger


machen. Die Tabelle fama_ausstattung enthält für jede Sonderausstattung eine ID, ein

Kürzel der Ausstattung und den vollständigen Namen. Die Umsetzung dieses dynami-

schen Konzepts in der Implementierung wird detailliert in Abschnitt 4.2 beschrieben.

In diesem Zusammenhang stellt sich auch die Frage, warum nicht alle Attribute auf

diese Art verwaltet werden. Eine solche Lösung wäre sehr aufwendig und der Nutzen

ist vergleichsweise gering. Der Grund hierfür ist, dass die abgefragten Eigenschaften

wie Erstzulassung, Preis, Laufleistung oder Leistung schon seit mehreren Jahrzehnten

zur Bewertung von gebrauchten Fahrzeugen verwendet werden. Die Wahrscheinlich-

keit einer zukünftigen Änderung dieser Attribute erscheint gering. Des weiteren sind

diese Attribute in ihrer Typausprägung zu unterschiedlich, eine gemeinsame Verwal-

tung ist, verglichen mit den Attributen der Sonderausstattung, welche alle vom Typ

„boolean“ sind, äußerst aufwendig.

Das vollständige Datenbankschema befindet sich im Anhang. Für die Wartung der Datenbank

sind stets sichere Schemata anzustreben. Für die Tabellen des Fahrzeugmarktes wird daher

die Löschregel Cascade verwendet. Diese Operation „kaskadiert“ zu allen zugehörigen Sät-

zen. Wird beispielsweise ein Eintrag in der Tabelle fama_fahrzeug gelöscht, so wird auch der

Eintrag in fama_pkw entfernt. Noch deutlicher zeigt sich dieser Vorgang und seine Sinnhal-

tigkeit dann, wenn ein Benutzer aus dem Gesamtsystem KLinform gelöscht wird. Zunächst

wird der Benutzer aus fama_perso gelöscht. Die Tabelle fama_benutzer referenziert den dor-

tigen Primärschlüssel, also wird auch hier der Eintrag gelöscht. Da die ID von fama_benutzer

von dem Attribut inserator in fama_fahrzeug referenziert wird, erfolgt auch hier ein Lösch-

vorgang, der dann fortgesetzt wird in fama_pkw. Logisch bedeutet dies, dass ein Benutzer des

Fahrzeugmarktes nicht existiert, wenn der Benutzer nicht auch bei KLinform angemeldet ist.

Ein Fahrzeug, beziehungsweise das Inserat, ist existenziell abhängig von dem Inserator.

Systemstruktur

Die objektorientierte Systemstruktur ist ebenfalls an das ER- Diagramm angelehnt. Die Klas-

sen, welche Entitäten beschreiben die auch als Tabelle in der Datenbank enthalten sind, ver-

fügen über die gleichen Attributsbezeichnungen und Typspezifikationen. Auf diese Weise

können die Werte der Datenbank mühelos von den jeweiligen Objekten der Klassen aufge-

nommen und verarbeitet, beziehungsweise weitergegeben werden. Eingebunden werde diese

Klassen durch das Werkzeug JavaBeans. Gleichzeitig kapselt eine Bean die Struktur und den

aktuellen Zustand eines konkreten Eingabeformulars. Zu einem Eingabefeld, Auswahlliste,

Checkbox, usw. des Formulars existiert ein entsprechendes gleichnamiges Attribut, um die


Benutzereingaben temporär speichern zu können. Standardmäßig verfügt jede Bean über eine

Reihe von Methoden, um diese Attribute setzen und lesen zu können (set- und get-Methoden).

Abbildung 18 zeigt das vollständige Klassendiagramm. Die einzelnen Klassen werden im

Anschluss daran beschrieben. In diesem Zusammenhang sei auch auf die ausführliche Java-

doc und die Kommentierung des Codes verwiesen.

+Fahrzeug()+Fahrzeug(in db)+setFahrzeug() : void+setFahrzeug() : void+reset() : void+MarkenToMarkenwerte() : void+MarkenwerteToMarken() : void+validate() : Boolean

-id : int-marke : String-modell : String-erstzulassungjahr : int-erstzulassungmonat : int-erstzulassungvon : int-erstzulassungbis : int-laufleistung : int-laufleistungvon : int-laufleistungbis : int-preis : int-preisvon : int-preisbis : int-freitext : String-foto : String-last_change : Date-ausstattung : Boolean[]-ausstattungswerte : String[][]-order : String-reihenfolge : String-markenwerte : String[][]-marken-db

Fahrzeug

+PKW()+PKW(in db)+reset() : void+setPKW() : void+setPKW() : void+validate() : Boolean

-typ : String-treibstoff : String-karosserie : String-getriebe : String-farbe : String-leistung : int-leistungvon : int-leistungbis : int-verbrauch : float-verbrauchvon : int-verbrauchbis : int

PKW

Zuzüglich enthält jede Klasse für alle Attribute Get- und Set-Methoden.

+Benutzer()+setBenutzer() : void+setBenutzer() : void+reset() : void

-id : String-anrede : String-vorname : String-nachname : String-strasse : String-plz : String-ort : String-land : String-telefon : String-telefax : String-email : String-url : String-hatsuchanfrage : Boolean-hatinserat : Boolean

Benutzer

+FileUploadBean()+delete() : void+doUpload() : void

-savePath : String-filepath : String-filename : String-contentType : String-filenamefromoutside : String-fields

FileUploadBean

AbstractDatabase

+Interne_Abarbeitung()+Interne_Abarbeitung(in dbc)+Interne_Abarbeitung(in dbc, in arg : String)+Interne_Abarbeitung(in dbc, in pkwarg : PKW, in akt : String)+reset() : void+InseratAufSuchprofilCheck() : void+InseratAufDatumCheck() : void+run() : void

-db-email-pkw : PKW-benutzer : Benutzer[]-aktion : String-to : String-sbj : String-msg : String

Interne_Abarbeitung

Thread

+validate() : Boolean

-id : int-von : String

Formular_Detail

AbstractFormHandler

-Inserat von

1

-hat *

+DBConnection()+AnzahlDerEintraege() : int+BenutzerExist() : Boolean+Bild_Bearbeiten() : void+DatumCheck() : Benutzer[]+ExpertensuchePKW() : Eintrag[]+getEintrag() : Eintrag+GetIdFromTable() : int+HatInserat() : Boolean+HatSuchanfrage() : Boolean+holeAusstattung() : String[]+holeAufbauart() : String[][]+holeMarke() : String[][]+holeTyp() : String[][]+InseratLoeschen() : void+InsertPKW() : int+MakeDetailString() : String+MakeSqlString() : String+MakeSuchprofilString() : String+ReturnInserat() : PKW+ReturnInseratTyp() : String+ReturnSuchanfrage() : PKW+SuchanfrageLoeschen() : void+SuchanfragespeicherPKW() : void+SucheInserat() : Eintrag[]+SuchePKW() : Eintrag[]+SuchprofilDurchsuchen() : Benutzer[]+UpdateBenutzer() : void+UpdatePKW() : void

-typ : StringDBConnection

+Eintrag()+getPrintRepresentation()+getId() : int+getLongRepresentation()+getRepresentationTitle() : String+getShortRepresentationColumns() : String[]+compareTo() : int+getEintrag() : Eintrag

-Benutzer : Benutzer-PKW : PKW-typ : String-

Eintrag

Abbildung 18 Klassendiagramm


Klasse Fahrzeug

Die vorrangige Aufgabe der Klasse Fahrzeug ist die Speicherung der Attribute, die in allen

Fahrzeugtypen anzufinden sind. Sie ist damit die Oberklasse der Klassen PKW und Krafträ-

der. Zur Speicherung der Daten und zum späteren Abruf stehen für jedes Attribut entspre-

chende set- und get-Methoden zur Verfügung. Ebenfalls verfügt die Klasse Fahrzeug über die

Variablen, die für die Speicherung von Suchprofilen und die Suchanfrage benötigt werden.

Eine Hauptaufgabe dieser Klasse ist die Speicherung der Fahrzeugdaten aus den JSP-Seiten

heraus und die Bereitstellung dieser für die weitere Verarbeitung in der Klasse DBConnection

und umgekehrt. Die hier gespeicherten Daten werden unverändert in die Datenbank geschrie-

ben, beziehungsweise die Daten aus der Datenbank werden in dem Objekt gespeichert. Um

die Anzahl der verschiedenen Klassen gering zu halten, werden auf diesem Weg auch Attribu-

te übergeben, die nicht direkt im Zusammenhang mit dem eigentlichen Fahrzeug stehen. Die

Variablen order und reihenfolge sind beispielsweise für die Reihenfolge der Ausgabe der

Suchergebnisse verantwortlich.

Neben den set- und get-Methoden verfügt die Klasse Fahrzeug über ein Reihe von weiteren

Methoden:

• reset(): Der Aufruf einer neuen Seite in JSP macht es teilweise erforderlich, die Werte

in den Beans auf einen Ausgangswert zurückzusetzen, um die Logik und die Semantik

des Programmablaufes zu bewahren. Das Attribut "session" in der Bean- Deklaration

verhindert aber, dass ein neues Bean angelegt werden kann. Aus diesem Grund ist es

notwendig, das bestehende Bean zurückzusetzen. Diese Aufgabe übernimmt die Me-

thode reset().

• setFahrzeug(): Der Versuch zwei Objekte gleich zu setzen, scheitert an der internen

Speicherverarbeitung von Java. Die Folge davon sind Datenverlust und schwer kalku-

lierbare Verhaltensweisen. Ein korrektes Ergebnis kann nur durch attributsweißes Zu-

weisen der jeweiligen Werte erhalten werden. Diese Aufgabe übernimmt die Methode

setFahrzeug(), die als eine Instanz von Typ Fahrzeug als Übergabewert erwartet. Die

Attribute der übergebenen Instanz werden ausgelesen und der eigenen Instanz zuge-

wiesen.

Um die Struktur der Klasse DBConnection zu vereinfachen, existiert eine weiter Me-

thode setFahrzeug(), diese erwartet aber einen Übergabewert vom Typ ResultSet. Da-

durch ist die Zuweisung der Inhalte des ResultSet der Datenbank an das Objekt Fahr-

zeug gekapselt und dadurch die Kommunikation zwischen Datenbank und JSP-Seiten

erleichtert.


• validate(): Wie bereits schon erwähnt, werden die Daten direkt aus dem Objekt Fahr-

zeug an die Datenbank übertragen. Die Methode validate() übernimmt die Aufgabe,

die eingetragenen Werte auf syntaktische und semantische Korrektheit zu überprüfen.

Treten Fehler auf, so werden diese an die entsprechende JSP- Seite übertragen. Um

diese Funktionalität zu gewährleisten, erbt die Klasse Fahrzeug von AbstractForm-

Handler.

Bereits bei der Beschreibung der Entitäten des ER-Diagramms wurde erwähnt, dass sowohl

die verschiedenen Marken als auch Sonderausstattungen über die Datenbank verwaltet wer-

den. Die Aufgabe der Verarbeitung dieser Daten kommt ebenfalls der Klasse Fahrzeug zu.

Dazu verfügt die Klasse über die Variablen ausstattung, austattungswerte, marke und mar-

kenwerte. Die Bedeutung dieser Variablen ist jedoch unterschiedlich.

Das Attribut ausstattung ist ein eindimensionales Array von Typ boolean. Hierin werden die

Werte der jeweiligen Attribute gespeichert. Die zugehörigen Namen, Kürzel und die ID bein-

haltet das zweidimensionale Array ausstattungswerte vom Typ String. Die erste Dimension

steht dabei für die Spalten der Tabelle fama_ausstattung, die zweite Dimension für die Zeilen.

Eine vergleichbare Funktion, wie der Variable ausstattungswerte, kommt der Variable mar-

kenwerte zu. Auch hier repräsentiert das zweidimensionale Array vom Typ String die Spalten

und Zeilen der Tabelle fama_marken. In den Tabellen fama_pkw und fama_suchanfrage wer-

den die Markennamen durch eindeutige IDs gespeichert. Um eine Zuweisung des tatsächli-

chen Namens zu der gefundenen ID zu erleichtern, werden alle Informationen separat in der

Hashtable marke gespeichert. Eine solche Zuweisung ist immer dann erforderlich, wenn die

Fahrzeugdaten an die jeweiligen Ausgabegeräte ausgegeben werden sollen.

Erwähnt werden sollen auch noch die beiden verschiedenen Konstruktoren und ihre Verwen-

dung. Wird ein neues Objekt der Klasse außerhalb der Klasse DBConnection angelegt, so

wird der Standard- Konstruktor verwendet. Legt diese Klasse ein neues Objekt an, so wird

dem Konstruktor das eigene Objekt mit übergeben. Der einzige Unterschied der beiden Kon-

struktoren besteht darin, dass im Standardfall ein neues Objekt von der Klasse DBConnection

angelegt wird, im Falle des anderen Konstruktors nicht. Dadurch werden Endlosschleifen

vermieden.

Klasse PKW

Die Klasse PKW stellt das Objekt Personenkraftwagen dar. Dazu erbt sie von der Klasse

Fahrzeug alle diejenigen Methoden, die allen Fahrzeugen gemein sind. In der Klasse PKW

werden konkret die Attribute Fahrzeugtyp, Treibstoff, Karosserieform, Getriebeart, Farbe,


Verbrauch und Leistung gespeichert. Um auch Suchprofile speichern zu können, werden wei-

terhin die Attribute für das Leistungsintervall und das Verbrauchsintervall gespeichert. Die

PKW- spezifischen Ausstattungen werden ebenfalls zentral von der Klasse Fahrzeug behan-

delt, da diese über die Datenbank eingelesen und verarbeitet werden.

Die Klasse PKW verfügt über die gleichen zusätzlichen Methoden wie die Klasse Fahrzeug.

Die Implementierung des Gesamtsystems ist so gestaltet, dass immer nur die Methoden in den

jeweiligen Unterklassen aufgerufen werden. Diese rufen dann wiederum die Methode in der

Oberklasse auf. Auf diese Weise ist die Struktur sehr überschaubar und die Attribute sind op-

timal gekapselt.

Klasse Benutzer

In dieser Klasse werden die Daten des Benutzers des Fahrzeugmarktes verwaltet. Dazu ver-

fügt die Klasse über die Attribute, die in den Tabellen perso_benutzer und fama_benutzer

vorkommen. Auch hier liegt die Hauptaufgabe in der Speicherung der Daten und dem Aus-

tausch zwischen den JSP-Seiten und der Datenbank. Der Umfang der Methoden ist erneut

weitestgehend identisch mit der Klasse Fahrzeug, lediglich die Methode validate() entfällt, da

keine kritischen Benutzerdaten in die Datenbank geschrieben werden. Alle Informationen

über die Adresse, die Email und die Telefonnummer sind in der Tabelle perso_benutzer ge-

speichert, auf welche dieser Baustein nur lesend zugreift. Die Klasse benutzer verfügt nur

über den Standard- Konstruktor, da Endlosschleifen wie im vorherigen Fall nicht auftreten

können.

Klasse DBConnection

Die Funktion der Klasse DBConnection liegt in der Kommunikation mit der Datenbank. Alle

Methode, die während der Laufzeit auf die Datenbank zugreifen, sind hierin enthalten. Dabei

bieten die Methoden teilweise viel mehr Funktionalität als das reine Schreiben in und Lesen

aus der Datenbank. So werden häufig auch die Daten ausgewertet und nur erwünschte Einträ-

ge werden an das aufrufende Bean zurückgeliefert. Die Datenbankanbindung erfolgt über den

von der PoolMan-API bereitgestellten virtuellen JDBC-Treiber. Damit ein Objekt eine Ver-

bindung zur Datenbank herstellen kann, benötigt es ein Objekt vom Typ Connection. Dieses

wird über die Methode getConnection() der Klasse AbstractDatabase bereitgestellt. Wird die-

se Verbindung nicht mehr verwendet, so muss sie mit close() wieder geschlossen werden. Da

die Klasse AbstractDatabase abstrakt ist, muss DBconnection von ihr erben, um auf die Me-


thoden zugreifen zu können. Zum Absetzen von SQL- Befehlen wird das Objekt Statement

aus dem Package java.sql verwendet.

Als innere Klasse enthält DBConnection die Klasse Eintrag. Der zugrundeliegende Gedanke

dieser Lösung ist die einfache Darstellung der Suchergebnisse sowohl in Tabellenform, als

auch in der Detailansicht. Dazu werden die gefundenen Einträge aus der der Datenbank in ein

Set von Objekten der Klasse Eintrag geschrieben. Das Interface KLinformSearchResult stellt

dann die Methoden zur Erzeugung von Tabellen in HTML aus diesen Daten zur Verfügung.

Die Oberklasse Comparable übernimmt die Steuerung der Reihenfolge, in der die Ergebnisse

ausgegeben werden. Diese Funktionalität wird allerdings nur im Falle der Suche auf Basis des

Vektorraummodells verwendet. In den anderen Fällen wird die Reihenfolge schon in den

SQL- Statements festgelegt.

Klasse Interne_Abarbeitung

Die Klasse Interne_Abarbeitung verwaltet die Vorgänge, die in einem separaten Thread ab-

laufen. Die Methode InseratAufSuchprofilCheck() durchsucht die gespeicherten Suchprofile

auf Übereinstimmung mit neuen Inseraten. Im Falle einer gefundenen Übereinstimmung, wird

der Benutzer per Email darüber informiert. Mit der Methode InseratAufDatumCheck() steht

dem Administrator ein Werkzeug zur Verfügung, um die Aktualität der Inserate zu überprü-

fen. Übersteigt ein Inserat ein bestimmtes Alter, so wird zunächst der Inserator darüber be-

nachrichtigt. Erfolg innerhalb von 14 Tagen keine Aktualisierung, wird das Inserat gelöscht.

Die genauen Funktionen dieser Klasse werden in Kapitel 5 genauer beschrieben.

Klasse FileUploadBean

Den Upload eines Bildes vom Client auf den Server übernimmt die Klasse FileUploadBean.

Die zentrale Methode ist doUpload(), durch welche der eigentliche Vorgang des Hochladens

abläuft. Dazu sind eine Reihe von Hilfsvariablen notwendig. Einerseits muss der Pfad des zu

speichernden Bildes auf dem Client gespeichert werden (filepath). Der Server muss daneben

den Pfad zu dem Verzeichnis kennen, in das Bild gespeichert werden soll (savePath). Der

Name der Datei, wie sie auf dem Server abgespeichert wird, enthält die Variable filenamefro-

moutside. Diese Variable wird vor dem eigentlichen Speichervorgang gesetzt und hat folgen-

de Struktur: inserat + Nummer des Inserates. Für den eigentlichen Speichervorgang wird die

Datei zeilenweise ausgelesen und dann wieder zeilenweise in die Zieldatei geschrieben.

Zugrundeliegendes Element der Datenübertragung ist das HTTP Request.


4.2 Repräsentationsstruktur (View- Komponente) Die View – Komponente realisiert die Schnittstelle zwischen dem Anwender und der Appli-

kation. Zur optimalen Umsetzung dieser Anforderung müssen eine Reihe von Bedingungen

erfüllt werden:

• Ansprechendes Design: Neben dem repräsentierten Inhalt und einer logischen Benut-

zerführung ist ein gelungenes Design Grundvoraussetzung für den Erfolg einer Web-

seite. Entscheidend dafür ist die Verbindung einer ansprechenden graphischen Ober-

fläche mit einer möglichste intuitiven Bedienbarkeit. Die Gestaltungsfreiheit be-

schränkt sich in den einzelnen Bausteinen jedoch auf die Anordnung der jeweiligen

Kommunikationsfelder. Durch die vorgegebenen Stylesheets und dem damit verfolg-

ten Ziel einer einheitlichen Oberfläche, werden Attribute wie Farbe, Form und Hinter-

grund der einzelnen Felder zentral festgelegt. Die subjektive Betrachtung, sowie die

Erfahrungen von Testpersonen führt jedoch zu dem Ergebnis, dass an einigen Stellen

noch Defizite liegen. Beispielsweise ist das Layout der Seiten häufig zu sachlich

gehalten und dadurch nur wenig ansprechend. Das Brechen mit Standards, beispiels-

weise durch die Definition eigener Buttons, führt zu häufigen Missverständnissen in

der Benutzerführung.

Eine übersichtliche Benutzerführung und ein ansprechendes Design ist gerade für den

Erfolg von E-Commerce Anwendungen unbedingt erforderlich. Diese Details sind

ausschlaggebend für die Entscheidungen der Benutzer. Abbildung 19 zeigt die Detail-

ansicht eines Fahrzeuges. Diese Seite überzeugt durch die Darstellung aller Fahrzeug-

daten auf übersichtliche Art. Das optionale Bild bietet einen zusätzlichen Handlungs-

anreiz.


Abbildung 19 Detailansicht des Fahrzeugmarktes

• Anpassung an den Inhalt der Model- Komponente: Die View- Komponente muss

auf Änderungen innerhalb der Model- Komponente regieren und den Inhalt adäquat

darstellen können. Vor allem muss der jeweilige Zustand der Beans ausgelesen und

projiziert werden. Es ist also zu unterscheiden zwischen einer dynamisch generierten

Oberfläche und der dynamisch angepassten Darstellung des Inhaltes. Die Darstellung

der Inhalte geschieht sowohl in Tabellenform, als auch in Form einer Vorbelegung

von Eingabefeldern. Dazu werden die in den Sitzungsobjekten enthaltenen Attribute

mittels des Befehls <%= bean.getX %> ausgelesen. Bean steht dabei für ein konkre-

tes Sitzungsobjekt, X für ein konkretes Attribut.

Bereits mehrfach wurde die Kapselung der möglichen Sonderausstattungen in der Da-

tenbank thematisiert. Der View muss auf die Änderungen dieser Daten reagieren. Die

strukturelle Anordnung wird dabei bereits durch die ID der Einträge in der Tabelle de-

finiert. Für Personenkraftwagen werden die Sonderausstattungen in die Kategorien

Komfort, Sicherheit und Umwelt, Weitere und Specials eingeteilt. Der Kategorie

Komfort zugeordnete Werte besitzen eine ID größer 100 und kleiner 200, Sicherheit

und Umwelt wird durch die Spanne zwischen 200 und 300 beschrieben, Weiter mit

Werten zwischen 300 und 400 und Specials durch die Spannbreite 400 bis 500. Die


folgende Abbildung zeigt das erzielte Ergebnis am Beispiel der Suchmaske für einen

PKW.

Abbildung 20 Formular der Suchmaske

• Übergabe der eingegebenen Werte an die Model- Komponente: Eingegebene Wer-

te des Benutzers müssen durch den View erfasst werden und an den Controller, bezie-

hungsweise das Model weitergeben werden. Dazu deckt jede View, repräsentiert

durch eine JSP-Datei, einen eindeutigen Bereich der Eingabemasken ab. Der Aufbau

der einzelnen Dateien ist dabei weitestgehend identisch gehalten. Das HTML-Form-

Tag fasst die Eingabefelder zu einer Einheit zusammen. Wechselt der Benutzer, bei-

spielsweise durch Betätigung eines Buttons, die Ansicht, so werden alle eingegebenen

Werte an die Controller- Komponente übergeben. Die dort erwarteten Werte werden

durch den Befehl

<jsp:setProperty name=bean property =“*“ /> an das Sitzungsobjekt übergeben. Die

entsprechenden set- Methoden müssen dafür in dem Bean enthalten sein. Problema-

tisch gestaltet sich das Einlesen der Werte nach dem beschriebenen Muster, wenn es

sich um Checkboxen handelt. Diese können entweder gesetzt (true) oder nicht gesetzt

sein (false). Die Schwierigkeit besteht darin, dass das Attribut zwar gesetzt wird, wenn

der Wert true anliegt, wird der Wert jedoch wieder auf false gesetzt, so wird die Ände-


rung nicht direkt in das Bean übernommen. Zur Lösung müssen diese Attribute separat

gesetzt werden. Dazu wird folgender Befehl verwendet, welcher abhängig von dem

vorliegendem Zustand das Bean entsprechend setzt.

<% if (request.getParameter(X) != null) bean.setX(true); else bean.setX(false); %>

4.3 Struktur der Ablaufsteuerung (Controller- Komponente) Unter dem Aspekt der strukturierten und intuitiven Benutzerführung kommt der Ablaufsteue-

rung eine zentrale Rolle im Gesamtsystems zu. Annährend die gesamte Business-Logik ist in

den index – Seiten der jeweiligen Unterverzeichnisse enthalten. Hierin wird sowohl festgelegt

in welcher Reihenfolge die Views aufgerufen werden, aber auch wann, welche Daten an die

Model- Komponente übertragen und dort gespeichert werden und umgekehrt. Die auszufüh-

rende Aktion richtet sich dabei nach den Angaben des Benutzers. Dieser steuert über die zur

Verfügung stehenden Buttons den Ablauf. Dabei ist jeder Button durch einen eindeutigen

Namen identifiziert. Durch Abfragen der Form

<% if request.getParameter(„name_des_button.x“) !=null) %> wird die zugehörige Aktion

ausgeführt. Dabei wird in der Variable nextPage die aufzurufende View festgelegt.

Die beiden folgenden Abbildung stellen die Ablaufsteuerungen in den drei Basisfunktionen

Suchen, Inserieren und Inserat bearbeiten überblicksartig graphisch dar. Alle Basisfunktionen

können von der Startseite des Fahrzeugmarktes aufgerufen werden.

Eine zentrale Aufgabe kommt der Seite der Detailansicht zu. Abhängig von der aufrufenden

Seite stehen folgende Handlungsoptionen zur Auswahl.

Aufruf durch Inserat Suchen

• Zurück – Benutzer gelangt zurück zu den Suchergebnissen

• Neue Suche – Zurücksetzen der Werte und erneuter Aufruf der Suchmaske

• Abbrechen – Rückkehr zur Startseite

• Inserat sperren - Für den Fall, dass der Benutzer ein Inserat mit unzulässigen Inhalt

vorfindet, kann er dieses dem Administrator mitteilen.

•

Aufruf durch Inserieren und Inserat Bearbeiten

Die Detailansichten für Inserieren und Inserat bearbeiten sind identisch. Nach erfolgreichem

Inserat muss der Benutzer in der Lage sein, das aufgegebene Inserat sofort weiter zu bearbei-

ten. Schutzverletzungen sind nicht zu befürchten. Folgende Optionen stehen hier zur Verfü-

gung:


• Inserat bearbeiten – Daten des Inserates werden in die Eingabemasken geladen

• Löschen – Löscht das Inserat

• Bild bearbeiten - Hochladen, löschen und ändern eines Bildes

• Statistik ansehen – Statistische Auswertung der Aufrufe des Inserates

• Zurück – Zurück zur Übersicht über die Inserate

Aufruf durch Administrator

• Selbe Auswahloptionen wie beim Aufruf durch Inserat bearbeiten, aber keine Ansicht

der Statistik möglich

Aktion wählen

Suchmaske ausfüllen

Suchergebnisse desVektorraummodells

Suchergebnisse derbooleschen Suche Suche

Freie Suche Aktion wählen

Suchprofilgespeichert

abbrechen

Benutzer-Login

eingeloggt

nein

ja

Suchprofil anlegen

Detailansicht

Aktion wählen

Detailsabbrechen

Neue Suche -- Wert werden zurückgesetztzurück

Benutzer hatSuchprofil

nein

Speichernbestätigt

ja

jaSuchprofil geöffnet

Benutzer-Login

eingeloggt

nein

ja

Benutzer hatSuchprofil

ja

nein

Suchprofil öffnen

Aktion wählen

Löschenbestätigt

Suchprofil löschen

Suchprofil löschen

ja

nein

Grund angeben

Email anAdministrator

Aktion wählen

Inserat sperren

abbrechen

Neue Suche -- Wert werden zurückgesetzt

Abbildung 21 Ablaufsteuerung der Basisfunktion Suchen


Benutzer-Login

eingeloggt

Daten eingeben

Datenvalidieren

neinja

Daten speichern

Nicht ok

Datenansehen

ok

nein

Detailansichtja

Aktionwählenzurück

Benutzer-Login

eingeloggt

neinja

Inserat bearbeiten

AktionwählenNeues Inserat Inserat bearbeiten

Daten laden

Aktionwählen

Inserat gelöscht

LöschenbestätigtLöschen

ja

Inserate auflisten

nein

Aktionwählen

Bild bearbeiten

Bild gespeichertBild gelöscht

Bild löschen Bild hochladen

Statistik

Statistik ansehen

Detailansicht

Email anAdministrator

Suchprofile aufÜbereinstimmung

durchsuchen

Abbildung 22 Ablaufsteuerung der Basisfunktionen Inserieren und Inserat bearbeiten

4.4 Integration des Marktes für Krafträder An dieser Stelle soll kurz erläutert werden, wie der Markt für Krafträder in das System einge-

bunden ist. Dazu sind lediglich bezüglich der Model- Komponente einige Anmerkungen not-

wendig. Controller und View werden identisch übernommen, lediglich die Schnittstellen zu

der Model- Komponente werden angepasst. Diese Umsetzung erfolgt im Unterverzeichnis

„Kraftrad“

Der Datenbank werden die Tabellen fama_kraftrad und fama_suchanfrage_kraftrad hinzuge-

fügt. Die Tabelle fama_benutzer erhält das zusätzlichen Attribut hatsuchanfragekraftrad. Um

den Fahrzeugtypen verwalten zu können, wird die Klasse Kraftrad hinzugefügt. Das Haupt-


problem besteht in der Anpassung der Klasse DBConnection. Doch an dieser Stelle kommt

der Vorteil der JavaBeans zum Tragen. Um der Klasse mitzuteilen, welcher Typ von Fahr-

zeug bearbeitet werden soll, wird der aufrufende Teil des Fahrzeugmarktes in der Variable typ

gespeichert. Auf diese Art existieren zwei JavaBeans, welche alle vom Typ DBConnection

sind. Durch den Befehl

<jsp: setproperties name=“db“ value=“pkw“/> wird der Bean “db” der Typ „pkw“ zuge-

ordnet. Die Methoden in DBConnection sind in zwei Mengen unterteilbar. Es existieren Me-

thoden, die von allen Fahrzeugtypen mit den selben Attributen aufgerufen werden. Die Unter-

scheidung wird innerhalb der Methode anhand der Variable typ vorgenommen. Es existieren

aber auch Methoden, die als Argument einen speziellen Fahrzeugtyp erwarten. So erwartet

beispielsweise die Methode SuchePKW() als Übergabewert ein Objekt vom Typ PKW. Die

Suche nach einem Kraftrad wird dann durch die Methode SucheKraftrad() übernommen, es

werden also separate Methoden angelegt. Einige Methoden sind völlig unabhängig von dem

zu bearbeitenden Fahrzeugtyp. Die Methode InseratLoeschen() operiert zum Beispiel nur auf

der Tabelle fama_fahrzeug, und nutzt damit den Vorteil des kaskadenartigen Löschen in der

Datenbank.

Das Zusammenspiel zwischen Controller und View wird an zwei Stellen besonders erschwert.

In die Lage des Benutzers versetzt, erscheint es als sinnvoll, alle Inserate aus einem gemein-

samen Menü heraus zu verwalten, unabhängig von dem zugrundeliegenden Fahrzeugtyp. Die-

ses Menü wird aus dem Hauptmenü heraus aufgerufen. Die Ergebnisse werden in zwei Tabel-

len dargestellt, eine Tabelle listet die Inserate vom Typ PKW, die zweite die Inserate vom

Typ Kraftrad. Folgende Abbildung gibt diesen Sachverhalt anschaulich wieder.

Abbildung 23 Oberfläche zur Darstellung eigener Inserate


Eine Unterscheidung der zu bearbeitenden Fahrzeugtypen erfolgt erst in der Detailansicht.

Und genau hierin liegt die zweite Schwierigkeit. Der Inhalt der Detailansicht wird in der Me-

thode getLongRepresentation() der Klasse Eintrag festgelegt und differiert natürlich zwischen

den Fahrzeugtypen. Zur Unterscheidung wird diese Methode aus zwei verschiedenen Formu-

laren heraus aufgerufen, es existieren also verschieden View – Komponenten. Der Aufruf

dieser View- Komponenten wird auch hier von einer Controller- Komponente gesteuert. Es

existieren aber eine Reihe von Fällen, in denen es nicht möglich ist, schon bei Aufruf der zu-

gehörigen index- Datei zwischen den Fahrzeugtypen zu unterscheiden. So erfolgt beispiels-

weise die Überprüfung der Inserate auf Aktualität unabhängig vom Typ. Die Email mit der

der Benutzer darüber informiert wird, erhält demnach immer den gleichen Verweis auf die

Detailansicht. Aus diesem Grund existiert nur eine index- Datei, welche die Steuerung aller

Detailansichten verwaltet. Die Methode ReturnInseratTyp() in DBConnection() liefert den

Typ des abgefragten Inserates zurück. Abhängig davon wird der View aufgerufen.

Die sonstigen View- und Controller- Komponenten für die Basisfunktionen sind annährend

identisch übernommen und im Unterverzeichnis Kraftrad gespeichert. Lediglich die Schnitt-

stellen zur Model- Komponente ist angepasst. Die Funktionen zur Verwaltung der Bilder und

die Werkzeuge für den Administrator sind unabhängig vom Fahrzeugtyp.

Ausgewählte Implementierungslösungen Seite 44

5 Ausgewählte Implementierungslösungen Eine Vielzahl der verwendeten Lösungen des Fahrzeugmarktes entsprechen dem Standard

und kommen, angepasst, auch in allen anderen Bausteinen zum Einsatz. Viele Vorgänge, vor

allem die Umsetzung des MVC- Design Pattern, sind in mehreren Bausteinen identisch. Aus

diesem Grund soll das folgende Kapitel einen Überblick über Lösungen geben, die in dieser

Form nicht in allen Komponenten zum Einsatz kommen. Es handelt sich dabei vor allem um

Anforderungen, die im Abschnitt 2.3.1 unter den Punkten „Innovative Lösungen“ und „Per-

sonalisierung der Funktionen“ aufgeführt wurden. Dabei soll sowohl eine Motivation dieser

Lösungen gegeben werden, als auch die Probleme der Implementierung diskutiert werden.

Das Kapitel unterteilt sich dabei in zwei Abschnitte. Zunächst soll die Seite des Benutzers des

Fahrzeugmarktes betrachtet werden, der zweite Teil beschreibt dagegen die Eingriffsmöglich-

keiten des Administrators und kann damit als Handbuch für eine spätere Wartung des Sys-

tems angesehen werden.

5.1 Interaktionsmöglichkeiten des Benutzers mit dem Sys-tem

Administrator über ein Inserat mit unzulässigen Inhalt informieren

Wird Benutzern des Internet die Möglichkeit gegeben, Bilder auf eine Webseite zu laden, so

besteht immer die Gefahr eines Missbrauchs. Selbiges trifft auf Eingaben in freie Textfelder

zu. Vor allem pornographische und gewaltverherrlichende Inhalte gilt es zu unterdrücken. Ein

erster Punkt setzt dabei beim Administrator an. Seine Aufgabe ist es, die Inhalte neuer Insera-

te zu überprüfen. Dazu wird er automatisch per Email über neue Einträge informiert. Zeit-

mangel und eine große Menge täglicher Inserate können es jedoch unmöglich machen, alle

Inserate vollständig zu überprüfen. Aus diesem Grund besteht für die Benutzer selber die

Möglichkeit, auf Inserate mit genannten Inhalten aufmerksam zu machen. Die entsprechende

Auswahloption steht in der Detailansicht der Suchergebnisse zur Verfügung. In den übrigen

Detailansichten ist eine entsprechende Funktionalität nicht erforderlich. Der Benutzer muss

lediglich eine kurze Begründung abgeben, warum dieses Inserat gesperrt werden sollte. Dies

verhindert zum einen den Missbrauch der Funktion, zum anderen erleichtert es die Entschei-

dungsfindung des Administrator. Hat der Benutzer die Begründung eingegeben, so braucht er

diese nur abzusenden und der Administrator wird per Email benachrichtigt. Dieser kann dann

entscheiden, ob das Inserat gesperrt werden soll, oder nicht.


Wird ein Inserat gesperrt, so wird es nicht mehr in den Suchergebnissen angezeigt. Auch in

anderen Funktionen, wie etwa dem Counter der Startseite, findet es keine Berücksichtigung

mehr. Eine Sperrung kann nur aufgehoben werden, wenn der Inserator sein Inserat erneut ab-

speichert, beziehungsweise das Bild neu speichert. Beide Möglichkeiten sind unabhängig

voneinander und ermöglichen dem Benutzer somit eine leichte Korrektur.

Wird ein Benutzer mehrfach auffällig, so sollte sein Profil auf allen Seiten von KLinform ge-

sperrt werden. Als Vorstufe wäre eine dauerhafte Sperrung seines Profils in den Seiten des

Fahrzeugmarktes denkbar.

Statistische Auswertung eines Inserates

Vor allem für professionelle Händler, aber auch für andere interessierte Verkäufer ist es von

großem Interesse eine Rückmeldung über den Erfolg eines Inserates zu bekommen. Selbstver-

ständlich stellt sich der eigentliche Erfolg erst mit dem abgeschlossenem Verkauf des Fahr-

zeuges ein, aber auch die Zugriffe auf das Inserat lassen diesbezügliche Rückschlüsse zu. Die

entscheidende Frage ist, an welcher Stelle die Zugriffe erfasst werden sollen. So ist es denk-

bar bereits jede Suchanfrage zu zählen, deren Ergebnismenge das entsprechende Inserat ent-

hält. Allerdings ist damit noch nicht sichergestellt, dass das Inserat auch von dem Benutzer

wahrgenommen wird. Aus diesem Grund verfolgt die Implementierung eine andere Lösung.

Ein Zugriff wird erst dann gezählt, wenn die Detailansicht des Inserates aufgerufen wird.

Damit ist sichergestellt, dass, zu mindestens kurzfristig, die Aufmerksamkeit des Suchenden

auf dieses Inserat konzentriert war. Die Problematik besteht nun darin, dass die Detailansicht

auch dann aufgerufen wird, wenn der Inserator sein eigenes Inserat anschaut beziehungsweise

die Daten bearbeiten will. Daher wurde hier eine Unterscheidung im Methodenaufruf ge-

macht. Wird die Detailansicht aus den Suchergebnissen sowohl der „Standardsuche“, als auch

der „Freien Suche“ heraus aufgerufen, so wird die Variable counter des betrachteten Inserates

in der Tabelle fama_fahrzeug um eins erhöht. Nicht gezählt werden die Zugriffe aus anderen

Basisfunktionen heraus.

Die Auswertung dieser Daten steht dem Benutzer dann in der Detailansicht seiner Inserate zur

Verfügung. Neben den absoluten Zugriffen auf das eigene Inserat ist auch von Interesse, wie

oft im Durchschnitt ein Inserat überhaupt aufgerufen wird. Aus diesem Grund wird durch das

SQL-Statement SELECT AVG(counter) FROM fama_fahrzeug auch der Durchschnitt über

alle Inserate ausgegeben. Der Benutzer kann dadurch selbst bewerten, ob sein Inserat über-

durchschnittlich oft aufgerufen wird oder eher nur selten Interesse weckt. Wird ein Inserat

beispielsweise überdurchschnittlich oft aufgerufen, aber die Anzahl der Kontaktaufnahmen


mit dem Verkäufer ist eher gering, dann kann eine Ursache hierfür in einem unzureichenden

Preis- Leistungs- Verhältnis liegen. Der Verkäufer sollte dann entsprechende Maßnahmen

ergreifen. Denkbar wäre auch noch die Ausgabe des besten und des schlechtesten Inserates, es

bleibt aber zu bedenken ob die Belastung der Datenbank in einem ausreichend gutem Ver-

hältnis zu dem Informationsgewinn für den Benutzer steht.

Umsetzung der Suchfunktion durch nicht- probabilistische Information Retrieval Mo-

delle

Die Suche, vor allem nach einem gebrauchten Fahrzeug, stellt einen sehr komplexen Vorgang

dar. Die Komplexität besteht dabei in einer unzureichend genauen Spezifikation der Vorstel-

lungen über das gesuchte Fahrzeug. So ist beispielsweise ein bestimmtes Set von Eigenschaf-

ten durch die Wünsche des Käufers determiniert. Dem gegenüber steht aber häufig ein weite-

res Set an gewünschten, aber nicht unbedingt erforderlichen Eigenschaften. Ein weiteres Set

an Attributen des Wunschfahrzeuges fliest überhaupt nicht in die Entscheidungsfindung ein.

Dieser Komplexität muss eine flexible, aber leicht zu benutzende Suchfunktion gerecht wer-

den. Einerseits muss der Käufer in der Lage sein, alle Fahrzeuge entsprechend der Eingabe in

der Suchmaske zu finden. Andererseits muss aber auch die Möglichkeit bestehen, bei unge-

nauer Suchanfrage logische Ergebnisse zu liefern. Diese beiden Anforderungen wurden durch

zwei unterschiedliche Suchverfahren aus dem Bereich des Information Retrieval umgesetzt.

Der theoretische Ansatz der beiden Modelle soll im folgenden vorgestellt und die unterschied-

liche Arbeitsweise verdeutlicht werden.

Information Retrieval

Als kennzeichnend für das Gebiet des Information Retrieval werden vage Anfragen und unsi-

cheres Wissen angesehen [Fuhr 2000, S.16]. Vage Anfragen sind dadurch gekennzeichnet,

dass die Antwort a priori nicht eindeutig definiert ist. Die folgende Abbildung stellt ein ein-

faches Grundmodell des Information Retrieval vor.


Information Retrieval

Semantische Modellierung eines Weltausschnittes

Zuweisen von Attributen zu gegebenen Einheiten

Fakten eines Weltausschnittes

Kombination elementarer Operationen auf Datenstrukturen

Datenbankstrukturen

beruht auf

gespeichert in

durch anhand von

liefert

auf

Abbildung 24 Grundmodell des Information Retrieval; Quelle: [Fuhr 2000]

Dabei repräsentiert die linke Seite den Vorgang der Eingabe, während der Retrievalprozess

auf der rechten Seite dargestellt ist. In einem nächsten Schritt wird dieses Modell verfeinert.

In der Datenbasis sind eine Menge von Dokumenten, in diesem Fall von gespeicherten Insera-

ten, vorhanden. Dem gegenüber steht eine Menge von Anfragen an des System. Die Retrie-

valfunktion vergleicht Frage- Dokumente- Paare und berechnet das Retrievalgewicht. Die

Definition der Retrievalfunktion hängt dabei von dem jeweils zugrundegelegten Retrievalmo-

dell ab.

Bezogen auf den Fahrzeugmarkt ist der Vorgang der Eingabe syntaktisch durch die vorgege-

bene Suchmaske für den Benutzer relativ stark festgelegt. Diese Kenntnis des Modells er-

leichtert den eigentlichen Suchvorgang und kann zu genaueren Ergebnissen führen. Aller-

dings ist durch die einheitliche Suchmaske auch die Gefahr gegeben, persönliche Kriterien

und Anforderungen an das gesuchte Fahrzeug nicht angeben zu können. Das Problem der

vagen Anfrage wird daher auf das Problem der mangelnden Flexibilität der Suchmaske be-

schränkt.

Boolesches Retrieval

Boolesches Retrieval ist historisch als erstes Retrievalmodell entwickelt und einsetzt worden

[Fuhr 2000, S.86].

Im eigentlichen Sinne handelt es sich dabei um eine direkte Anfrage an die Datenbank. Die

Frage- Beschreibung ist hier ein boolescher Ausdruck, die in einer Zweiteilung der Dokumen-

te in der Datenbasis in gefundene und nicht gefundene Dokumente resultiert. Im konkreten

Fall bedeutet dies, dass die eingegebenen Attribute durch „AND“ zu booleschen Ausdrücken

zusammengefasst werden. Die Ausgabe der gefundenen Fahrzeuge beinhaltet nur solche, die

alle gewünschten Attribute erfüllen. Die Umsetzung des Booleschen Retrieval erfolgt in der

Methode SuchePKW der Klasse DBConnection. Um dem Sachverhalt der vagen Suchanfrage

gerecht zu werden, ist die Suchmaske so gestaltet, dass der Benutzer nicht alle Attribute ge-


nau spezifizieren muss. Dazu müssen Textfelder nicht unbedingt ausgefüllt werden, bezie-

hungsweise besteht bei Auswahloptionen die Möglichkeit, durch Auswahl der „Alle..“ Option

die Suche in diesem Attribut nicht einzuschränken. Angaben die in den numerischen Bereich

fallen, beispielsweise Laufleistung oder Verbrauch, können in Spannbreiten durch „von“ und

„bis“ Werte gemacht werden. Des weiteren werden die Angaben in den Checkboxen folgen-

dermaßen interpretiert:

• eine gesetzte Checkbox erfordert das Vorhandensein dieses Attribut

• eine ungesetzte Checkbox wird nicht in die Suchanfrage aufgenommen, sie bewirkt al-

so keine Einschränkung des Suchergebnisses.

Dadurch können schon durch das Boolesche Retrieval gute Suchergebnisse erzeugt werden.

Allerdings beinhaltet dieses Modell eine Reihe von Nachteilen, die auch in dieser speziellen

Anwendung zum tragen kommen [Fuhr 2000, S.87]:

• Es erfolgt keine Ordnung der Antwortmenge nach mehr oder weniger relevanten Inse-

raten.

• Es gibt keine Möglichkeit zur Gewichtung von Fragetermen oder zur Berücksichti-

gung von gewichteter Indexierung. Dadurch hat beispielsweise die Übereinstimmung

der Marke in Frage und Antwort dasselbe Gewicht, wie die Übereinstimmung der Ei-

genschaft „Beifahrerairbag“.

• Die Trennung in gefundene und nicht gefundene Dokumente ist oftmals zu streng.

Wird nach einem Fahrzeug in einer Preislage zwischen 8.000 und 10.000 Euro ge-

sucht, so wird das Fahrzeug mit einem Preis von 10.001 Euro bereits nicht mehr aus-

gegeben.

Eine Reihe dieser Nachteile können durch die Anwendung des Vektorraummodells überwun-

den werden.

Das Vektorraummodell

Im Vektorraummodell werden Dokumente und Fragen in einem Vektorraum aufgefasst, der

durch die Terme der Datenbasis aufgespannt wird. „Beim Retrieval wird nach solchen Doku-

menten gesucht, deren Vektoren ähnlich (im Sinne einer vorgegebenen Metrik) zum Frage-

vektor sind.“ [Fuhr 2000, S.90] Der zugrundeliegende Vektorraum wird als orthonormal an-

genommen. Um die Ähnlichkeit zweier Vektoren zu berechnen existieren eine Vielzahl von

Retrievalfunktionen, beispielsweise das Skalarprodukt, das Cosinus- Maß, das Pseudo- Cosi-

nus- Maß oder das Dice- Maß. Die gewünschten Kriterien

• Winkel- Monotonie,

• Radial- Monotonie,


• Komponenten- Monotonie,

• 1-Komponenten- Monotonie und

• Beschränktheit von Ähnlichkeitswerten

erfüllt dabei das Cosinus- Maß am besten. Es ist wie folgt definiert:

∑∑

∑

==

=

⋅=

n

jj

n

jji

n

jjji

i

qd

qdqd

1

2

1

2,

1,

),cos(

Dabei bezeichnet D die Menge der Dokumente in der Datenbasis und Q die Menge der An-

fragen.

Die Umsetzung des Vektorraummodells erfolgt in der Methode ExpertensuchePKW, welche

ebenfalls Teil der Klasse DBConnection ist. Die verwendete Retrievalfunktion ist das Cosi-

nus- Maß. Um dem Benutzer die Bedienung des Fahrzeugmarktes zu erleichtern, wird die

Suchanfrage über dieselbe Suchmaske aufgerufen, die bereits im obigen Modell des Boole-

schen Retrieval beschrieben wurde. Diese komplexe Suchanfrage muss zunächst auf die An-

forderungen des Vektorraummodells angepasst werden. Dazu werden die jeweiligen Eingaben

unterschiedlich behandelt.

Die Werte der Checkboxen werden ähnlich wie im Booleschen Retrieval bewertet. Es erfolgt

also keine besondere Umwandlung. Die Variablen jid , und jq werden mit den entsprechen-

den Werten 0 und 1 belegt. Eine positive Übereinstimmung, im dem Sinne, dass beide Werte

entweder mit „true“ oder mit „false“ belegt sind, führt zu einer Erhöhung des Cosinus- Maß,

während eine mangelnde Übereinstimmung zu einer Verringerung führt.

Ähnlich den Belegungen der Checkboxen werden auch die nicht numerischen Eingaben in

den Textfeldern oder den Auswahloptionen bewertet. Eine positive Übereinstimmung der

Anfrage mit dem entsprechenden Attribut in dem Inserat führt auch hier zu einer Belegung

der beiden Variablen jid , und jq mit 1. Stimmen die Werte nicht überein, so wird nur die

Variable jq mit 1 belegt, welches zu einer Verringerung der Relevanz des entsprechenden

Inserates führt. Wird in der Suchanfrage das entsprechende Attribut nicht bestimmt, sei es

durch fehlende Eingabe oder durch die Auswahl der Option „Alle..“, so werden ebenfalls

beide Variablen mit dem Wert 1 belegt. Jedes Inserat wird dadurch bezüglich der Relevanz

aufgewertet.

Wesentlich aufwendiger gestaltet sich die Behandlung der numerischen Eingabefelder. Ein

erstes Problem dabei ist die Angabe in der Suchanfrage in Form von Spannbreiten. Da eine


Eigenschaft nur eine Dimension des Vektorraumes definieren kann, müssen diese Informatio-

nen zunächst verdichtet werden. Dazu durchläuft das Programm folgende Schritte:

1. Liegt der Wert des Attributes des Inserates innerhalb der Spannbreite so werden hier,

analog zu den beiden oben beschriebenen Abläufen, beide Variablen mit dem Wert 1

belegt.

2. Liegt der Wert außerhalb der Spannbreite, so würde eine Belegung der Variablen mit

dem Wert 0 wieder zurück auf einige Probleme des Booleschen Retrieval führen. Aus

diesem Grund werden die Klassenmitten des Attributes berechnet. Die Variable jq

wird nun mit dem Wert dieser Klassenmitte belegt, die Variable jid , mit dem eigentli-

chen Wert des Inserates. Zusätzlich werden die verschiedenen Attributsausprägungen

normiert, um die Werte vergleichbar zu machen. Würde dieser Schritt ausgelassen, so

würde der Einfluss dieses Attributes auf des Gesamtergebnis zu hoch werden. Daher

erfolgt eine Projektion der Werte in das Intervall [0,1]. Der Normierungsfaktor ist das

Maximum der Werte in der Suchanfrage und der Werte in den Inseraten. Letztere

werden in einer, der eigentlichen Auswertung vorgeschalteten, Schleife berechnet. Mit

zunehmender Entfernung von der Klassenmitte nimmt dadurch die Relevanz des je-

weiligen Inserates ab.

Der bisher beschriebene Programmablauf beinhaltet eine ganz wesentliches Problem – jedes

Attribut ist bezüglich dem Einfluss in der Relevanzberechnung gleich gewichtet. Dieses Prob-

lem des Booleschen Retrieval soll aber gerade durch das Vektorraummodell überwunden

werden. Dazu ist ein notwendig, Gewichtungen für die einzelnen Attribute einfließen zu las-

sen. Folgende subjektive Gewichtungen sind implementiert:

• Die booleschen Werte der Fahrzeugausstattung (das sind diejenigen, die durch Check-

boxen abgefragt werden) erhalten einfaches Gewicht

• Farbe und Typ des Fahrzeuges werden doppelt gewichtet

• Form der Karosserie, Getriebeart werden dreifach gewichtet

• Die Attribute Treibstoff, Leistung, Laufleistung, Erstzulassung und Verbrauch gehen

vierfach in die Bewertung ein

• Das Attribut Preis wird 6-fach, Modell 7-fach und Marke 10-fach gewichtet.

Ausgegeben werden alle Inserate mit einer Relevanz bezüglich der Suchanfrage größer null.

Die Ausgabe erfolgt in absteigender Relevanz. Der Wert des Cosinus- Maßes wir in der Er-

gebnistabelle dargestellt.


Neues Inserat entspricht Suchprofil – Der Versand von Emails

Speichert ein Benutzer ein Suchprofil, so wird dieser automatisch benachrichtigt, sobald ein

Inserat aufgegeben wird, dass diesem Profil, dem Modell des Booleschen Retrieval nach, ent-

spricht. Um den Benutzer schnellstmöglich über solche Veränderungen zu informieren und

um gleichzeitig den Administrator zu entlasten, wird ein solcher Suchablauf gestartet, sobald

ein neues Inserat gespeichert wird. Der Ablauf soll ohne zeitliche Belastung für den Inserator

ablaufen. Aus diesem Grund, wird durch die Methode InsertPKW in der Klasse DBConnecti-

on die Methode InseratAufSuchprofilCheck der Klasse Interne_Abarbeitung aufgerufen. Die-

se startet einen neuen Thread, der „alte“ Thread steht damit dem Benutzer sofort wieder für

weitere Aktionen zur Verfügung. Bei dem Funktionsaufruf werden die Daten des Fahrzeuges

übergeben, sie sind die Grundlage für die anschließend stattfindende Suche nach entsprechen-

den Suchprofilen. Die Schwierigkeit besteht in dem umgekehrten Durchlauf der Suche. Nor-

malerweise bildet das Suchprofil die Basis für die Suche, es werden Inserate entsprechend den

jeweiligen Werte der Attribute gesucht. In diesem Fall müssen solche Suchprofile gefunden

werden, die bei Ablauf der Standardsuche, das übergebene Inserat als Ergebnis ausgeben

würden. Diese Umkehrung bereit vor allem an den Stellen Schwierigkeiten, an denen die

Werte im Suchprofil durch Spannbreiten beschrieben sind. Die Implementierung einer sol-

chen umgekehrten Suche ist sehr aufwendig. Aus diesem Grund wurde das gesamte Problem

auf das Ursprungsproblem der Standardsuche reduziert. Dabei durchläuft das Programm fol-

gende Schritte:

• In einer ersten Datenbankabfrage werden alle gespeicherten Suchprofile ausgelesen

und in einem Objekt der Klasse ResultSet gespeichert.

• Mit Hilfe der Schleife while rs.next() werden die gefundenen Suchprofile schrittweise

durchlaufen. In jedem Durchlauf wird nun das Verfahren der Standardsuche ausge-

führt. Dabei dienen die Werte des jeweiligen Suchprofils als Basis. Neben der Stan-

dardsuche muss der zu findende Eintrag nur eine zusätzliche Eigenschaft erfüllen: die

ID muss mit der ID des neu aufgegebenen Inserates identisch sein; es soll also gerade

das neu eingegebene Inserat gefunden werden. Ist dies der Fall, so liefert der Such-

schritt als Ergebnis die Daten des Benutzers zurück, dem das Suchprofil zugeordnet

ist.

• Das Suchergebnis wird in einer Instanz der Klasse Benutzer gespeichert und als neuer

Eintrag an einen Vektor angehängt.

• Wurden alle Suchprofile durchlaufen, wird mittels des Befehls v.toArray(new Benut-

zer[0]) ein Array vom Typ Benutzer zurückgeliefert. Der Befehl bewirkt die Um-


wandlung der Elemente des Vektors v in ein Array von dem Typ, der in der Klammer

übergeben wird.

• Dieses Array wird an die aufrufende Methode zurückgeben und dort schrittweise ver-

arbeitet. Für jeden Benutzer wird eine Email generiert und versendet. Diese enthält ei-

nen Link auf die Detailansicht des neu eingegebenen Inserates.

5.2 Eingriffsmöglichkeiten des Administrators in das Sys-tem

Die Wünsche der Kunden von KLinform zu befriedigen ist oberstes Ziel des gesamten Pro-

jektes. Aus diesem Grund muss das Angebot auf den Webseiten beständig aktualisiert und auf

Missbrauch überprüft werden. Diese Aufgabe kommt dem Administrator des gesamten Sys-

tems, beziehungsweise der einzelnen Bausteine zu. Um diese Arbeit zu erleichtern, verfügt

der Baustein Fahrzeugmarkt über einen eigenen Menüpunkt, welcher dann eingeblendet wird,

wenn der eingeloggte Benutzer als Administrator identifiziert wird. Die Inhalte der Inserate

kann der Administrator überprüfen und verändern, indem alle Inserate angezeigt werden, oder

über die ID ein ganz spezielles Inserat ausgewählt wird. Zur Bearbeitung eines ausgewählten

Inserates stehen dem Administrator alle Funktionen des Inserators zur Verfügung. Die Aus-

wahl einer speziellen ID ist dabei adäquat zu dem entsprechenden Link in der Email, welche

bei jeder Änderung der Inserate versendet wird.

Aktualität der Inserate

Erfolgt die oben beschriebene Änderung der Inserate auf manuelle Art, so muss die Überprü-

fung aller Inserate auf eine gewisse Aktualität, aufgrund der Quantität der Angebote, automa-

tische erfolgen. Über das genannte Menu muss der Vorgang manuell gestartet werden, die

notwendigen Änderungen werden vom System automatisch ausgeführt. Die dazu notwendige

Funktionalität stellen die Methoden InseratAufDatumCheck() in der Klassen Intere-

ne_Abarbeitung und die Methode DatumCheck() der Klasse DBConnection bereit. Der ge-

samte Vorgang läuft in einem eigenen Thread ab, so dass die zeitliche Belastung des Admi-

nistrator minimiert wird. Ziel ist die Identifikation von Inseraten, die seit einer bestimmten

Zeit nicht aktualisiert wurden. Wird ein solches Inserat gefunden, so wird der Inserator per

Email benachrichtigt und gebeten, sein Angebot zu aktualisieren oder zu löschen. Geschieht

dies nicht innerhalb von 14 Tagen, so wird nach Ablauf dieser Frist in einem erneuten Pro-


grammdurchlauf das Inserat gelöscht und der Benutzer wird erneut darüber benachrichtigt. In

Abbildung 25 ist der Programmablauf detailliert dargestellt.

Neues Inserat

Loeschen_vorgemerkt=falselast_change=today

Differenz zwischen last_changeand today> klinform.properties

Inserat geändert

Loeschen_vorgemerkt=truemahnung=today

ja

Differenz zwischen mahnung andtoday > 14

Loeschen_vorgemerkt=true

ja

Inserator wird benachrichtigt

Inserator wird benachrichtigt

Inserat wird gelöscht

ja

Abbildung 25 Administrator - Überprüfung der Aktualität der Inserate

Die Steuerung erfolgt durch die drei Attribute last_change, mahnung und loe-

schen_vorgemerkt. In last_change wird, dem Namen entsprechend, das Datum der letzten

Änderung des Inserates gespeichert. Liegt dieser Zeitpunkt länger als der in den klin-

form.properties gespeicherte Zeitraum zurück, so wird der Verkäufer gemahnt und die Vari-

able loeschen_vorgemerkt wird auf „true“ gesetzt. Damit wird bei einem erneuten Programm-

durchlauf nur die Differenz zwischen dem aktuellen Datum und dem Zeitpunkt der erfolgten

Mahnung berechnet. Ist diese größer als 14 Tage, wird das Inserat gelöscht. Der Administra-

tor wird nach vollständiger Überprüfung aller Inserate über die Anzahl der Mahnungen und

der Löschvorgänge benachrichtigt.

Inserat Sperren

Wird der Administrator durch einen Benutzer auf ein Inserat mit einem unzulässigen Inhalt

aufmerksam gemacht, oder stellt er dies bei routinemäßigen Untersuchungen fest, so steht im

mit diesem Menüpunkt ein Werkzeug zur Verfügung, solche Inserate zu sperren. Die Bedeu-

tung hinter dem Begriff „sperren“ ist bereits in Abschnitt 5.1 erläutert wurden. Zunächst wird

der Administrator aufgefordert, die ID des Inserates und eine Begründung für die Seprrung


einzugeben. Im Anschluss werden die Daten des zugehörigen Inserators aus der Datenbank

ausgelesen. Das Attribut gesperrt wird auf true gesetzt. Über den Vorgang wird der Inserator

per Email benachrichtigt. Diese Email beinhaltet sowohl den Grund für die Sperrung, als auch

die Anleitung, wie die Sperrung aufgehoben werden kann.

Konfigurationsdatei

Email-Adressen, Verzeichnis- und Servernamen sind nicht in den Code der Komponente di-

rekt integriert, sondern werden zentral verwaltet. Diese Aufgabe übernimmt die Konfigurati-

onsdatei $klinform/config/klinform.properties. Die jeweiligen Attribute werden hier mittels

folgender Syntax gespeichert:

<Name> = <Wert des Attributes>

Die Methode ‚getProperty(String)’ der Klasse ‚de.klinform.KLinform’ gibt den aktuellen

Wert des entsprechenden Attributs zurück. Durch die Definition von variablen Feldern kön-

nen die zurückgelieferten Werte mit dynamisch erzeugten Elementen vermengt werden. Die

notwendige Funktionalität stellt die Klasse ‚java.text.MessageFormat’ und die entsprechende

Methode ‚format’ zu Verfügung. Dabei wird ein Set von Objekten formatiert und der forma-

tierte String in die zugewiesen Stelle eingefügt.

Mittels der Konfigurationsdatei kann der Administrator folgende Attribute verändern:

Attribut Variable Felder Beschreibung fama_admin - Email- Adresse des Administrator für den

Fahrzeugmarkt

fama_detail_link - Beschreibt den Link auf die Detailansicht, wie

er in die versendeten Emails eingebunden wird.

fama_ort_bild_upload fama_ort_bild_upload_relativ

- Beim Umgang mit Bildern muss auf der Ser-ver-Seite zwischen zwei Pfaden unterschieden werden:

• Dateipfad bezogen auf die Webser-ver-Root und

• Dateipfad bezogen auf das Server-Dateisystem.

Ersterer wird zum Beispiel benötigt, wenn das Ergebnis als Bilddatei in eine HTML-Seite eingebettet werden soll. Zweiterer wird benötigt, um die Datei auf der Server-Seite zu speichern. Das zweite Attribut ist defaultmäßig auf ‚de/fahrzeugmarkt/bilddatei/’ gesetzt.

fama_suchprofil_subject fama_suchprofil_message

Anrede Vorname Name Link Detailansicht

Betreff und Nachrichtentext der Email, die versendet wird, wenn ein neues Fahrzeug entsprechend den Angaben in dem gespeicher-ten Suchprofil gefunden wird.


ID des Inserates

fama_inserieren_subject fama_inserieren_message

Anrede Vorname Name Link Detailansicht ID des Inserates

Betreff und Nachrichtentext der Email, durch die der Administrator über neue Inserate in-formiert wird.

fama_gueltigkeit_inserat_in_tagen

- Hier wird festgelegt, wie viele Tage ein Inserat unverändert online geschaltet bleiben soll, ohne dass der Inserator aufgefordert wird, dieses zu aktualisieren.

fama_datum_subject fama_datum_message

Anrede Vorname Name Link Detailansicht ID des Inserates

Betreff und Nachrichtentext der Email, durch die der Verkäufer aufgefordert wird, sein Inse-rat zu aktualisieren.

fama_loeschen_subject fama_loeschen_message

Anrede Vorname Name ID des Inserates

Betreff und Nachrichtentext der Email zur Information des Verkäufers, dass ein Inserat gelöscht wurde.

fama_datum_admin_subject fama_datum_admin_message

Anzahl der gesende-ten Mahnungen

Betreff und Nachrichtentext der Email an den Administrator über die Anzahl der, im Rah-men der Administration gesendeten, Mahnun-gen.

fama_loeschen_admin_message Anzahl der gelösch-ten Inserate

Nachrichtentext der Email an den Administra-tor über die Anzahl der, im Rahmen der Ad-ministration gelöschten, Inserate.

fama_inserat_sperren_subject fama_inserat_sperren_message

Link Detailansicht ID des Inserates Grund der Sperrung

Betreff und Nachrichtentext der Email an den Administrator, mit der begründeten Aufforde-rung zur Sperrung des Inserates.

fama_inserat_sperren_admin_subject fama_inserat_sperren_admin_message

Anrede Vorname Name Link Detailansicht ID des Inserates Grund der Sperrung

Betreff und Nachrichtentext der Email zur Information des Verkäufers, dass ein Inserat gesperrt wurde.

Abbildung 26 Steuergrößen in der Datei klinform.properties

Abschließende Bewertung und Ausblick Seite 56

6 Abschließende Bewertung und Ausblick Die Implementierung des Fahrzeugmarktes umfasst annährend alle Anforderungen, die in

Kapitel 2 aufgestellt wurden. Der Umfang der innovativen und personalisierten Lösungen

übersteigt damit den Umfang vieler anderer webbasierter Fahrzeugmärkte. Jedoch sind durch

die Einbindung in das Gesamtsystem von KLinform, besonders bezüglich der graphischen

Gestaltungsfreiheit, Grenzen gesetzt. An einigen Stellen bedarf es Verbesserungen, um den

Inhalt und die Funktionalität auch durch ein leicht zu bedienendes und benutzerfreundliches

Design dem Benutzer zugänglich zu machen. Um einen Wettbewerbsvorteil auf-, bezie-

hungsweise auszubauen ist es notwendig, den Fahrzeugmarkt zu erweitern und innovative

Konzepte zu ergänzen. Folgende Lösungen erscheinen dabei sinnvoll und überlegenswert:

• Anbindung an Printmedien

Aufbauend auf das breite Angebotsspektrum der Portal-Site KLinform kann dem Ver-

käufer eine Schnittstelle zu den regional ansässigen Printmedien angeboten werden.

Damit wird er in die Lage versetzt, ein aufgegebenes Inserat an Zeitungen oder Zeit-

schriften weiterzuleiten. Ein vergrößerter Empfängerkreis kann die Chance auf einen

erfolgreichen Abschluss eines Kaufgeschäftes zu erhöhen.

• Bilddatenbank

Die derzeitige Implementierung erlaubt es, pro Inserat nur ein Bild zu speichern.

Denkbar wäre hier eine Erweiterung auf drei oder noch mehr Bilder. Gleichfalls sollte

ein Gedanke der Anforderungsanalyse noch einmal aufgegriffen werden. Dort wurde

die Möglichkeit erwähnt, eine Bilddatenbank zu erstellen, die dem Inserator ermög-

licht, ein passendes Bild auszuwählen. Damit kann allen Anbietern die Möglichkeit

gegeben werden, das Inserat durch ein Bild interessanter zu machen. Eine vorstellbare

Lösung zur Implementierung ist, die Bilder nicht durch die ID des Inserates zu identi-

fizieren, sondern zusätzlich auch Informationen über Marke, Modell und Farbe mit zu

speichern.

• Erweiterung des Angebotes

Das Angebot des Fahrzeugmarktes kann sowohl horizontal als auch vertikal erweitert

werden. Die Möglichkeit auch andere, als die beiden implementierten Fahrzeugkate-

gorien zu handeln stellt eine horizontale Erweiterung dar. Folgende Fahrzeugkatego-

rien sind dabei vorstellbar:

- Anhänger/ Wohnwagen mit folgenden Attributen:

§ Fahrzeugtyp, Aufbauart, Gewicht, Zuladung, gebremst/ ungebremst


§ Erweiterte Optionen

• Außenfarbe

• Sonderausstattungen/ Sonderleistungen

o ABS, Antischlingerkupplung, CD, Klima, Radio, Stütz-

rad

o Mehrwertsteuer ausweisbar, Garantie, TÜV

- Lastkraftwagen

- Baumaschinen

- Fahrräder

Die Integration ist relativ einfach und erfordert nur geringen Zeitaufwand. Die Vorge-

hensweise aus Abschnitt 4.1 kann hierzu als Vorlage verwendet werden.

Die Anbindung an die Printmedien und die Bilddatenbank zeigen bereits Wege der

vertikalen Erweiterung auf. Um die Lebenslage Autokauf vollständig abdecken zu

können, sind jedoch auch im Fahrzeugmarkt eine ganze Reihe von Zusatzmodulen

notwendig. Beispielhaft seien genannt:

- in Abschnitt 2.3 wurde darauf hingewiesen, dass bei 3% der Autos auch der

tatsächliche Kaufvorgang online abgewickelt wird. Durch die Entwicklung ei-

nes Bausteines „Online Shop“ sollte die notwendige Funktionalität bereitge-

stellt werden, um auch diese Nachfrage zu befriedigen. Dieser Baustein sollte

die rechtlichen Rahmenbedingungen erfüllen und die notwendigen Werkzeuge

wie Kaufvertrag oder Zahlungsabwicklung bereitstellen.

- Integrierte Bewertungsmöglichkeit des angebotenen Fahrzeuges auf Basis der

Schwacke- Liste.

- Automatische Berechnung der Kosten für Steuern und der Versicherungen.

• Schnittstelle um Inserate einzulesen

Im vorherigen Punkt wurde die Schnittstelle zu den Printmedien angesprochen. Denk-

bar wäre auch eine Implementierung in die andere Richtung. Inserate können bis jetzt

nur über die Webseite eingetragen werden. Eine Offline – Schnittstelle würde es aber

auch ermöglichen, auf anderen Wegen Inserate in die Datenbank einzutragen. Eine in-

tegrierte Lösung mit anderen Bausteinen (z.B. Veranstaltungskalender) wäre denkbar.

• Modell und Motorisierung vorbestimmen

Um die Korrektheit eines Inserates zu erhöhen, und um mit einheitlichen Notationen

zu arbeiten, erscheint es sinnvoll, analog zu der Marke auch das Modell und die Moto-

risierung fest vorzugeben. Dabei muss es sich um einen dynamischen Prozess handeln.


Nach Eingabe der Marke stehen nur noch die Modelle zur Auswahl, die diese Marke

jemals hervorgebracht hat. Entsprechendes gilt im Anschluss für die Motorisierung.

Dadurch wird die Suche erleichtert und Missverständnisse beseitigt. Bis zu einer ge-

wissem Umfang stellt die derzeitige Implementierung keinerlei Probleme dar. Eine

große Menge an Inseraten erschwert aber erheblich die suche nach dem passenden

Fahrzeug, wenn unterschiedliche Angaben über das Modell und die Motorisierung

vorliegen.

Die Vorschläge zeigen, dass Verbesserungsmöglichkeiten in großem Umfang vorhanden sind.

Diese müssen genutzt werden, um KLinform in Kaiserslautern erfolgreich zu etablieren.

Quellenverzeichnis Seite 59

Quellenverzeichnis [Bücker 2002] Bücker, K.: Datenbankanbindung und Middleware für Java-Applikationen,

Münster, 2002

[Fuhr 2000] Fuhr, N.: Information Retrieval – Skriptum zu Vorlesung im WS 00/01, Dort-

mund, 2000

[Hall 2001] Hall, M: Servlets und JavaServer Pages, München, 2001

[Horn 2002] Horn, T.: http://www.thorsten-horn.de/techdocs/java-sql.htm, 10.07.2002

[Jup 2001] Jupiter MMXI: Europäische Surfer fahren auf Auto-Sites ab,

http://de.jupitermxi.com/xp/de/press/releases/pr_042501.xml, 25.04.2001

[KLinform 2000] Projektgruppe KLinform: KLinform Portal für die Region Kaiserslautern –

Tor zum Markt der Zukunft, Kaiserslautern 2000

[Müller 2002] Müller, G.: SQL-Tutorium, http://horatio.wiwi.uni-frankfurt.de/sql/intro.html

[Namics 2001] Namics: Redesign von Websites: Der Case car4you,

http://www.namics.com/namics/home.nsf/vFile/iex_2001/$FILE/09FFB_IEXw-

11_Redesign_car4you.pdf, Frankfurt, 2001

[News 2000] News.com: http://www.news.com, 2000

[Tataryn 2001] Tataryn, C. W.: Einführung in MVC und das Jakarta Struts Frameword,

www.computer-programmer.org/articles/ struts/de/StrutsMVC_de.ppt, 2001

[Turau 2000] Turau, V: Java Server Pages, Heidelberg, 2000

[Xipolis 2001] Xipolis.net: www.xipolis.net,

http://www.xipolis.net/suche/suche_treffer_detail.php?lemma=Kraftfahrzeug&werk_id=3&ar

tikel_id=20864400, 10.11.2001

http://www.thorsten-horn.de/techdocs/java-sql.htm

http://de.jupitermxi.com/xp/de/press/releases/pr_042501.xml

http://horatio.wiwi.uni-frankfurt.de/sql/intro.html

http://www.namics.com/namics/home.nsf/vFile/iex_2001/

http://www.news.com

http://www.computer-programmer.org/articles/

http://www.xipolis.net

http://www.xipolis.net/suche/suche_treffer_detail.php?lemma=Kraftfahrzeug&werk_id=3&ar

Abbildungsverzeichnis Seite 60

Abbildungsverzeichnis Abbildung 1 Erwartung der Benutzer an eine Online-Plattform im Automobilbereich; ...........5

Abbildung 2 Zusammensetzung des webbasierten Fahrzeugmarktes.......................................9

Abbildung 3 Allgemeine Benutzeranforderungen .................................................................10

Abbildung 4 Fahrzeugspezifische Attribute ..........................................................................11

Abbildung 5 Funktionale Benutzeranforderungen – Suchfunktion ........................................13

Abbildung 6 Funktionale Benutzeranforderungen – Inserat aufgeben ...................................14

Abbildung 7 Funktionale Benutzeranforderungen - Inserat verwalten...................................14

Abbildung 8 Nichtfunktionale Benutzeranforderungen .........................................................17

Abbildung 9 Inverse Benutzeranforderungen........................................................................17

Abbildung 10 Entwurfsentscheidungen ................................................................................18

Abbildung 11 Hard- und Software- Plattform.......................................................................18

Abbildung 12 MVC Design Pattern im Überblick.................................................................20

Abbildung 13 MVC - Komponenten und Werkzeuge ...........................................................21

Abbildung 14 JDBC Typ 4 – Treiber; Quelle [Bücker 2002] ................................................22

Abbildung 15 Use-Case-Diagramm......................................................................................24

Abbildung 16 Struktur des Bausteines Fahrzeugmarkt..........................................................26

Abbildung 17 Entity- Relationship- Diagramm.....................................................................27

Abbildung 18 Klassendiagramm...........................................................................................31

Abbildung 19 Detailansicht des Fahrzeugmarktes.................................................................37

Abbildung 20 Formular der Suchmaske................................................................................38

Abbildung 21 Ablaufsteuerung der Basisfunktion Suchen ....................................................40

Abbildung 22 Ablaufsteuerung der Basisfunktionen Inserieren und Inserat bearbeiten .........41

Abbildung 23 Oberfläche zur Darstellung eigener Inserate ...................................................42

Abbildung 24 Grundmodell des Information Retrieval; Quelle: [Fuhr 2000].........................47

Abbildung 25 Administrator - Überprüfung der Aktualität der Inserate.................................53

Abbildung 26 Steuergrößen in der Datei klinform.properties ................................................55

Anhang Seite 61

Anhang Definition des Schemata der Datenbank (enthält nicht die Tabellen für den Kraftrad - Markt) CREATE TABLE fama_fahrzeug ( id INTEGER NOT NULL, inserator VARCHAR(20) NOT NULL, marke VARCHAR(25) NOT NULL, modell VARCHAR(25) NOT NULL, erstzulassungmonat INTEGER, erstzulassungjahr INTEGER, laufleistung INTEGER, preis INTEGER, last_change DATE, foto VARCHAR(50), freitext VARCHAR(500), loeschen_vorgemerkt BOOL, mahnung DATE, gesperrt BOOL, counter INTEGER, PRIMARY KEY (id), FOREIGN KEY (inserator) REFERENCES perso_benutzer (id)

ON DELETE CASCADE ON UPDATE CASCADE); CREATE TABLE fama_pkw ( typ VARCHAR(15), leistung INTEGER, treibstoff VARCHAR(15), karosserie VARCHAR(15), verbrauch FLOAT(4), getriebe VARCHAR(15), farbe VARCHAR(15), abs BOOL, alarmanlage BOOL, allrad BOOL, alufelgen BOOL, anhaengerkupplung BOOL, behindertengerecht BOOL, beifahrerairbag BOOL, cd BOOL, dachtraeger BOOL, efensterheber BOOL, esitzverstellung BOOL, fahrerairbag BOOL, kat BOOL, klima BOOL, leder BOOL,

Anhang Seite 62

navisystem BOOL, nebelscheinwerfer BOOL, radio BOOL, schiebedach BOOL, seitenairbag BOOL, servo BOOL, sitzheizung BOOL, sportausstattung BOOL, trueckbank BOOL, tempomat BOOL, traktionskontrolle BOOL, tuning BOOL, wegfahrsperre BOOL, winterreifen BOOL, zentral BOOL, ust BOOL, garantie BOOL, tuev BOOL, PRIMARY KEY (id), FOREIGN KEY (inserator) REFERENCES perso_benutzer (id)

ON DELETE CASCADE ON UPDATE CASCADE) INHERITS (fama_fahrzeug); CREATE TABLE fama_suchanfrage_pkw ( id INTEGER NOT NULL, inserator VARCHAR(20) NOT NULL, marke VARCHAR(25) NOT NULL, modell VARCHAR(25) NOT NULL, typ VARCHAR(15), treibstoff VARCHAR(15), karosserie VARCHAR(15), getriebe VARCHAR(15), farbe VARCHAR(15), leistungvon INTEGER, leistungbis INTEGER, verbrauchvon INTEGER, verbrauchbis INTEGER, erstzulassungvon INTEGER, erstzulassungbis INTEGER, laufleistungvon INTEGER, laufleistungbis INTEGER, preisvon INTEGER, preisbis INTEGER, abs BOOL, alarmanlage BOOL, allrad BOOL, alufelgen BOOL, anhaengerkupplung BOOL,

Anhang Seite 63

behindertengerecht BOOL, beifahrerairbag BOOL, cd BOOL, dachtraeger BOOL, efensterheber BOOL, esitzverstellung BOOL, fahrerairbag BOOL, kat BOOL, klima BOOL, leder BOOL, navisystem BOOL, nebelscheinwerfer BOOL, radio BOOL, schiebedach BOOL, seitenairbag BOOL, servo BOOL, sitzheizung BOOL, sportausstattung BOOL, trueckbank BOOL, tempomat BOOL, traktionskontrolle BOOL, tuning BOOL, wegfahrsperre BOOL, winterreifen BOOL, zentral BOOL, ust BOOL, garantie BOOL, tuev BOOL, PRIMARY KEY (id), FOREIGN KEY (inserator) REFERENCES perso_benutzer (id)

ON DELETE CASCADE ON UPDATE CASCADE);

CREATE TABLE fama_benutzer ( id VARCHAR(20) NOT NULL, hatsuchanfrage BOOL, hatsuchanfragekraftrad BOOL, hatinserat BOOL, PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES perso_benutzer (id)

ON DELETE CASCADE ON UPDATE CASCADE); CREATE TABLE fama_marken ( id INTEGER NOT NULL, marke VARCHAR(25), PRIMARY KEY (id));

Anhang Seite 64

CREATE TABLE fama_aufbauart ( id INTEGER NOT NULL, aufbauart VARCHAR(35), PRIMARY KEY (id)); CREATE TABLE fama_typ ( id INTEGER NOT NULL, typ VARCHAR(25), PRIMARY KEY (id)); CREATE TABLE fama_ausstattung ( id INTEGER NOT NULL, ausstattung VARCHAR(25), tabellenname VARCHAR(25), PRIMARY KEY (id));

Anhang Seite 65

Installationshinweise

• Aufbau der Datenbank

Für den Aufbau und die Verwaltung der Datenbank existieren vier Textdateien, wel-

che aus dem PostgreSQL- Kommandozeileninterpreter aufgerufen werden können:

- fama_tabellen_fahrzeug_benutzer_pkw_erstellen.txt

Erstellt die Tabellen fama_fahrzeug, fama_pkw, fama_benutzer, fa-

ma_suchanfrage_pkw, fama_marke, fama_aufbauart, fama_typ, fa-

ma_ausstattung. Diese Tabellen müssen zuerst in der Datenbank angelegt wer-

den. Außerdem werden die Sequenzen fama_fahrzeug_id_zaehler und fa-

ma_suchanfrage_pkw_id_zaehler erzeugt.

- fama_tabellen_kraftrad_erstellen:

Erstellt die Tabellen fama_kraftrad und fama_suchanfrage_kraftrad. Erzeugt

außerdem die Sequenz fama_suchanfrage_kraftrad_id_zaehler.

- fama_tabellen_inhalt.txt

Füllt die Tabellen fama_marke, fama_aufbauart, fama_typ, fama_ausstattung

mit Werten.

- fama_tabellen_loeschen.txt

Löscht alle Tabellen und Sequenzen in der richtigen Reihenfolge aus der Da-

tenbank

• Intervalle in den Tabellen fama_marke, fama_aufbauart und fama_typ, um die

Werte den jeweiligen Fahrzeugtypen richtig zuzuordnen.

PKW Kraftrad

fama_marke 1-199 201-299

fama_aufbauart 1-99 101-199

fama_typ 1-99 101-199

• Intervalle in der Tabelle fama_ausstattung, um die Werte den jeweiligen Be-

schreibungen richtig zuzuordnen.

PKW Kraftrad

Komfort 101-199 501-599

Sicherheit und Umwelt 201-299 601-699

Weitere 301-399 -

Specials 401-499 701-799

Fachbereich Informatik -...

Documents

Transcript of Fachbereich Informatik -...