fachbereich informatik -...
Post on 18-Sep-2018
214 Views
Preview:
TRANSCRIPT
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.
KLinform und Begründung der Notwendigkeit eines Fahrzeugmarktes Seite 2
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-
KLinform und Begründung der Notwendigkeit eines Fahrzeugmarktes Seite 3
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.
KLinform und Begründung der Notwendigkeit eines Fahrzeugmarktes Seite 4
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-
Anforderungsanalyse Seite 6
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.
Anforderungsanalyse Seite 7
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-
Anforderungsanalyse Seite 8
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
Anforderungsanalyse Seite 9
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
Innovative Lösungen
Fließen ein
Personalisierung
Authentifizierung
Spezifi-zierung
Abbildung 2 Zusammensetzung des webbasierten Fahrzeugmarktes
Anforderungsanalyse Seite 10
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-
Anforderungsanalyse Seite 11
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
Anforderungsanalyse Seite 12
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
Anforderungsanalyse Seite 13
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.
Anforderungsanalyse Seite 14
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
Anforderungsanalyse Seite 15
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
Anforderungsanalyse Seite 16
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.
Innovative Lösungen
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.
Anforderungsanalyse Seite 17
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.
Anforderungsanalyse Seite 18
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.
Anforderungsanalyse Seite 19
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.
Umgebungsstruktur Seite 21
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
Umgebungsstruktur Seite 22
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-
Umgebungsstruktur Seite 23
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.
Umgebungsstruktur Seite 24
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.
Systementwurf auf Basis des MVC-Design Pattern Seite 26
$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
Systementwurf auf Basis des MVC-Design Pattern Seite 27
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.
Systementwurf auf Basis des MVC-Design Pattern Seite 28
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-
Systementwurf auf Basis des MVC-Design Pattern Seite 29
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
Systementwurf auf Basis des MVC-Design Pattern Seite 30
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
Systementwurf auf Basis des MVC-Design Pattern Seite 31
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
Systementwurf auf Basis des MVC-Design Pattern Seite 32
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.
Systementwurf auf Basis des MVC-Design Pattern Seite 33
• 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,
Systementwurf auf Basis des MVC-Design Pattern Seite 34
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-
Systementwurf auf Basis des MVC-Design Pattern Seite 35
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.
Systementwurf auf Basis des MVC-Design Pattern Seite 36
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.
Systementwurf auf Basis des MVC-Design Pattern Seite 37
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
Systementwurf auf Basis des MVC-Design Pattern Seite 38
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-
Systementwurf auf Basis des MVC-Design Pattern Seite 39
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:
Systementwurf auf Basis des MVC-Design Pattern Seite 40
• 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
Systementwurf auf Basis des MVC-Design Pattern Seite 41
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-
Systementwurf auf Basis des MVC-Design Pattern Seite 42
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
Systementwurf auf Basis des MVC-Design Pattern Seite 43
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.
Ausgewählte Implementierungslösungen Seite 45
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
Ausgewählte Implementierungslösungen Seite 46
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.
Ausgewählte Implementierungslösungen Seite 47
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-
Ausgewählte Implementierungslösungen Seite 48
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,
Ausgewählte Implementierungslösungen Seite 49
• 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
Ausgewählte Implementierungslösungen Seite 50
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.
Ausgewählte Implementierungslösungen Seite 51
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-
Ausgewählte Implementierungslösungen Seite 52
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-
Ausgewählte Implementierungslösungen Seite 53
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
Ausgewählte Implementierungslösungen Seite 54
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.
Ausgewählte Implementierungslösungen Seite 55
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
Abschließende Bewertung und Ausblick Seite 57
§ 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.
Abschließende Bewertung und Ausblick Seite 58
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
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
top related