Projektarbeit Fachbereich Informatik

Projektarbeit
Implementierung eines
webbasierten
Fahrzeugmarktes
cand. Wirtsch.-Ing. Martin Hoffmann
August 2002
Betreuer:
Prof. Dr. Paul Müller
Dipl. Inform. Markus Hillenbrand
Fachbereich Informatik
AG Integrierte Kommunikationssysteme
Universität Kaiserslautern · Postfach 3049 · 67653 Kaiserslautern
Inhaltsverzeichnis
Seite I
Inhaltsverzeichnis
INHALTSVERZEICHNIS .................................................................................................. I
1
KLINFORM UND BEGRÜNDUNG DER NOTWENDIGKEIT EINES
FAHRZEUGMARKTES..............................................................................................1
1.1
KLINFORM – PORTAL FÜR DIE REGION KAISERSLAUTERN ..........................1
1.2
ZIEL UND STATISTISCHE BEGRÜNDUNG DER PROJEKTARBEIT ..................3
2
ANFORDERUNGSANALYSE ....................................................................................5
2.1
ERWARTUNGEN DER BENUTZER........................................................................5
2.2
ANALYSE EXISTIERENDER WEBBASIERTER AUTOMÄRKTE ........................6
2.3
BENUTZERANFORDERUNG ..................................................................................8
2.4
ZUSAMMENFASSUNG..........................................................................................18
3
UMGEBUNGSSTRUKTUR ......................................................................................20
3.1
DAS MVC-DESIGN PATTERN ..............................................................................20
3.2
WERKZEUGE ZUR UMSETZUNG DES PROBLEMS ..........................................21
3.3
USE-CASE-DIAGRAMM ALS HANDLUNGS- UND
UMGEBUNGSBESCHREIBUNG ...........................................................................23
4
SYSTEMENTWURF AUF BASIS DES MVC-DESIGN PATTERN.......................25
4.1
OBJEKTORIENTIERTE SYSTEM- UND DATENBANKSTRUKTUR (MODELLKOMPONENTE)......................................................................................................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 eines 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 entwickelt, erhielt es zunehmend Einfluss in nahezu allen Bereichen des öffentlichen, wirtschaftlichen und vermehrt auch privaten Lebens. Doch eine immer größer werdende Zahl von Anbietern von Dienstleistungen, Informationen oder Produkten erschwert es dem Nutzer zunehmend, 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 Erkenntnis, 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 Verkäufern auf dem Fahrzeugmarkt verstehen, nach dem günstigsten Angebot für einen bestimmten 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ücklicherweise 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 dieses 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 Realisierung 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, Homebanking 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 erzielen.“ [News 2002] Unterstützt wird das Projekt durch eine Vielzahl von Konsortialpartnern, 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 innovativen 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 [Kleinform 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 Informationen 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 Verlobungsringes erleichtert eine Übersicht der ansässigen Juweliere und deren Angebot. Informationen ü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 erhalten, sich sein persönliches Portal zu schaffen. Dazu kann er aus einer Vielzahl von Lebenslagen 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 Suche von auf das Benutzerprofil abgestimmten Angeboten zu erweitern. Persönliche Präferenzen 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 webbasierten Fahrzeugmarkt erweitert werden. Dabei sollen das Lebenslagen- und das Personalisierungskonzept auf die Anforderungen dieses Bausteines adaptiert werden. Die Notwendigkeit der Integration eines Fahrzeugmarktes in das Portal liegt in einer rasant steigenden Zahl
von Internetnutzern, welche ihren Autokauf durch dieses Medium vorbereiten oder sogar ausfü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 informieren, die kürzeste Reiseroute ausfindig zu machen, aktuelle Verkehrsinformationen abzurufen 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 Besucherzahl 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 Gebrauchtwagenbö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 Jahres 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 Umgebungsparameter von KLinform auf die neue Komponente. Ausgangspunkt ist eine umfassende Analyse der bereits existierenden Systeme. Besonderer Augenmerk wurde dabei auf Möglichkeiten
der Personalisierung, auf benutzerfreundliche Anwendung und auf innovative Lösungen gelegt.
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 Funktionsangebot zu bekommen, soll zunächst dargelegt werden, was Benutzer von einer OnlinePlattform im Automobilbereich erwarten, also welche Funktionen von der gesamten Lebenslage abgedeckt werden müssen. Daraus lassen sich die Anforderungen an den webbasierten
Fahrzeugmarkt ableiten. Die folgende Abbildung beschreibt die Wichtigkeit von acht verschiedenen Funktionen. Die Daten basieren auf einer weltweiten Befragung von Haushalten.
89%
Get make and model info
80%
Find and Compare Prices
56%
Look up value of old car
27%
Locate Dealer
26%
Request price quota
18%
Read Classification
Sell old car
Buy a car
0%
5%
3%
10%
20%
30%
40%
50%
60%
70%
80%
Percentage of Households
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 bekommen. 80% interessieren sich vorrangig für Preise. Lediglich 3% wollen tatsächlich ein Fahr-
90%
Anforderungsanalyse
Seite 6
zeug online kaufen. Ein Fahrzeugmarkt im Internet sollte sich demnach zunächst als eine Informationsplattform verstehen. Es ist nicht das vorrangige Ziel, den eigentlichen Tauschvorgang 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 Fahrzeugmä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 gebrauchten AUDI A4 Avant 2,5 TDI zu finden, der nicht älter als 2 Jahre ist. Auf den Webseiten 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 Sonderausstattungen zulassen, besteht bei anderen Anbietern nur eine sehr geringe Auswahlmöglichkeit.
Vor allem kleinere Anbieter verzichten darauf, allerdings ist das Angebot häufig so beschrä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 Felder. 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 Kriterien 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 Modells 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 Verkaufsangebotes eine Registrierung. Allerdings dient diese im Fall von autoscout24.de nur dazu bei mehrfacher 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ögliche 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 erkennen und von bereits gelesenen zu unterscheiden.
Bewertung existierender Automärkte
Das Angebot an webbasierten Automärkten ist sehr umfangreich. Leider fehlen häufig innovative 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, Finanzierungen oder Bewertungen von Fahrzeugen. Im Bezug auf das beschriebene Lebenslagenkonzept decken die großen Portale bereits die Lebenslage Autokauf nahezu komplett ab. Allerdings bieten nicht alle Portale die Möglichkeit, das Angebot auf eine bestimmte Region einzuschränken.
2.3 Benutzeranforderung
Ziel ist die Implementierung eines webbasierten Fahrzeugmarktes für die Region Kaiserslautern, der sich außer seiner regionalen Beschränkung durch innovative Lösungen und Möglichkeiten 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 webbasierter 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 Anhä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ßenverkehrszulassungs-Ordnung). [Xipolis 2002].
Aufbauend auf die gegebene Definition soll der Fahrzeugmarkt nicht nur Pkw Angebote verwalten können, sondern auch ein Portal für Krafträder (Motorräder, Mofas, etc.) und Wohnmobile darstellen. Da Wohnmobile und Pkws in den meisten Eigenschaften übereinstimmen,
können sie über eine gemeinsame Oberfläche verwaltet werden. Krafträder und andere Fahrzeugtypen 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 Fahrzeugmärkte stellen. Nach [Namics 2001] sammeln bereits 48% der Käufer von Autos mit Hilfe 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 Autoverkauf nicht prioitär ist ergibt sich die Forderung an die Anbieter, dass die abgegebenen Angebote 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 gegebenen Definitionen.
Webbasierter Fahrzeugmarkt
Benutzer
Käufer
Verkäufer
Aufruf
Suchen/ Bieten
Authentifizierung
Basisfunktionen
Fahrzeuge
Personalisierung
Fahrzeugsuche
Spezifizierung
PKW/ Wohnmobil
Inserate aufgeben
Fließen ein
Inserate verwalten
Innovative
Lösungen
Kraftrad
Daten abrufen, bearbeiten, pflegen
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 Zielerreichung 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 auszufü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 werden.
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 innovative Lösungen und Personalisierungsmöglichkeiten.
Allgemeine Anforderungen
BA-F
BA-F1
Beschreibung der Anforderung
Aufgegebene Inserate müssen in einem geographisch begrenzten Raum um Kaiserslautern liegen, um die regionale Konzentration des Portals zu wahren.
Alle Eingaben, außer in Freitexten, werden auf syntaktische und soweit möglich,
BA-F2
auf semantische, Korrektheit überprüft. Im Falle einer Fehleingabe wird ein entsprechender 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 Spezifikation der Informationen, die für ein Fahrzeug der jeweiligen Klasse abgefragt und angeboten 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
·
Fahrzeugtyp, Leistung, Treibstoff, Karosserie
1. Erweiterte Optionen
-
Verbrauch
-
Getriebeart
-
Außenfarbe
-
Sonderausstattungen/ Sonderleistungen
§
ABS, Alarmanlage, Allrad, Alufelgen, Anhängerkupplung, Behindertengerecht, Beifahrer Airbag,
PKW/ Wohnmo-
CD, Dachträger, Elektrische Fensterheber, Elekt-
bil
rische Sitzverstellung, Elektrische Außenspiegel,
Fahrerairbag, Katalysator, Klima, Lederausstattung, Navigationssystem, Nebelscheinwerfer, Radio, Schiebedach, Seitenairbags, Servolenkung,
Sitzheizung, Sportausstattung, teilbare Rücksitzbank, Tempomat, Traktionskontrolle, Tuning,
Wegfahrsperre, Winterreifen, Zentralverriegelung
§
Motorrad/ Mofa/
Kraftrad
Mehrwertsteuer ausweisbar, Garantie, TÜV
·
Fahrzeugtyp, Motorleistung, Hubraum
·
Erweiterte Optionen
-
Farbe
-
Verbrauch
-
Sonderausstattungen/ Sonderleistungen
§
ABS, Alarmanlage, Heizgriffe, Katalysator, Koffer/Topcase, Scheibe, Sturzbügel, Tuning, Verkleidung
§
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 abhä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 Unfallwagen über webbasierte Fahrzeugmärkte angeboten werden. Dem Käufer muss die Möglichkeit 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 Kaiserslautern 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 Übersichtlichkeit verloren geht. Der Suchvorgang muss möglichst schnell ablaufen, um vorzeitige Abbrüche zu vermeiden. Die Suchergebnisse müssen ansprechend aufbereitet werden, dem Käufer müssen Funktionen zur Verfügung stehen, welche die Arbeit mit den gefundenen Fahrzeugen erleichtern. Die folgende Tabelle beschreibt die funktionalen Anforderungen an die
Suchfunktion.
BA-F
BA-F4
BESCHREIBUNG DER ANFORDERUNG
Die Suchoptionen sind standardmäßig auf den allgemeinsten Fall eingestellt und
können schrittweise vom Benutzer spezialisiert werden.
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-
BA-F5
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
Die detaillierte Anzeige eines speziellen Fahrzeuges enthält alle vorhandenen In-
BA-F10 formationen in Textform. Falls vorhanden, erfolgt die Darstellung des Bildes. Informationen ü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ändige Kontrolle aller neu aufgegebenen Inserate ist aufgrund begrenzter (menschlicher) Ressourcen 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 einzuschrä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 angebotenen Fahrzeuges hinzuweisen. Im folgenden sind die funktionalen Anforderungen an die beschriebene Basisfunktion aufgelistet.
BA-F
BESCHREIBUNG DER ANFORDERUNG
Das Inserieren eines Fahrzeuges ist nur nach Registrierung bei KLinform und im
BA-F11 eingeloggten Zustand möglich. Bereits vorhandene Daten aus der Registrierung
werden verwendet und müssen nicht neu eingegeben werden.
Alle Felder, die in den Abschnitten über die Fahrzeugspezifischen Informationen
BA-F12
nicht unter den Punkt „Erweiterte Optionen“ fallen, müssen eingegeben werden,
ansonsten erfolgt kein Eintrag in die Datenbank. Erweiterte Optionen haben bezüglich der Eingabe einen optionalen Charakter.
Die Eingabefelder müssen so weit wie möglich Auswahlfelder mit vordefinierten
Werten sein, um Missbrauch zu verhindern und die Korrektheit der Angaben zu
BA-F13 erhöhen. Beinhaltet ein Eingabefeld Datumswerte, so werden diese beginnend mit
dem höchsten Wert aufgelistet. Numerische Werte beginnen mit dem kleinsten
Wert.
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
BA-F14 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
BA-F15
Seite 14
Vor dem Eintrag in die Datenbank wird dem Inserat ein eineindeutiger Schlüssel in
Form einer Nummer zugeordnet.
Dem Administrator wird nach erfolgreicher Aufgabe des Inserates eine Email mit
BA-F16 allen gemachten Angaben geschickt. Des weiteren erhält er mit der Email die erstellte 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ändern.
BA-F
Beschreibung der Anforderung
Während der Laufzeit des Inserates können alle Daten nach vorherigem Login ge-
BA-F17 ändert, gelöscht oder erweitert werden. Bei der Suche nach dem zu ändernden Inserat hilft die zugeteilte Nummer. Das Inserat kann auch komplett gelöscht werden.
Nach Speicherung der Änderungen wird dem Anbieter automatische eine Email mit
BA-F18 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 entfernen. 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, solche Angebote zu sperren. In der Detailansicht eines Angebots steht ihnen dazu ein entsprechender Link zur Verfügung. Der Administrator erhält daraufhin eine Mitteilung über die gewü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 festgelegten Zeit automatisch aus der Datenbank entfernt, vorausgesetzt es wurde während dieser Zeit
keine anbieterseitig Aktualisierung vorgenommen werden. 14 Tage vor Ablauf dieser Zeitspanne 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öglichst gering bleibt. Selbstverständlich wird der Anbieter über die erfolgte Löschung benachrichtigt.
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 Suchergebnisse 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 differenzierten Auswahlkriterien der Käufer Rechnung. Die beim Autokauf entscheidenden Eigenschaften des gesuchten Wagens sind stark geschlechtsabhängig. Während Männer die Schwerpunkte eher im Bereich der Technik setzten, steht für Frauen Form und Farbe des Wagens im Vordergrund. Eine geschlechtsspezifisch gestaltete Oberfläche erhöht die Anwenderfreundlichkeit. 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 beschriebenen Auswahlmöglichkeiten ist damit bereits eine automatische Personalisierung erfolgt.
Registrierte Käufer können ebenfalls ein persönliches Fahrzeugprofile erstellen. Bei wiederholten 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 Detailansicht des jeweiligen Inserates aufrufen. Eine solche Funktion soll in das Angebot des webbasierten 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 darauf 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 überdurchschnittlichen Niveau, so handelt es sich eventuell um ein besonders günstiges Angebot.
Die Möglichkeiten der Personalisierung sollten intuitiv einsetzbar sein. Sie sollten dem Benutzer 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üssen ohne vorherige Einstellungen ausführbar sein.
Innovative Lösungen
Bei der Analyse existierender Fahrzeugmärkte ist aufgefallen, dass eine Suchoption zum Auffinden 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 Funktion 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 Wunschfahrzeug nur unzureichend beschrieben werden kann. Häufig hat der Suchende nur ungenaue Vorstellungen 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 beispielsweise 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 optisch nicht in vollem Umfang zusagt.
Anforderungsanalyse
Seite 17
2.3.2 Nichtfunktionale Benutzeranforderungen
BA-NF
BESCHREIBUNG DER ANFORDERUNG
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önBA-NF1
nen und ein annährend identisches Layout besitzen. Dazu ist vor allem die Darstellung auf den beiden meistgenutzten Browsern - Microsoft Internet Explorer
und Netscape Communicator (beide ab Version 4.0 oder höher) – im Zusammenspiel 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.
Die Gestaltung der Seiten sollte weitestgehend identisch und möglichst klar und
BA-NF3
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
BA-Inv1
Beschreibung der Anforderung
Die Daten in der Datenbank dürfen nicht verloren gehen. Die Konsistenz muss
auch nach einem Systemabsturz gewahrt bleiben.
Es dürfen keine Inhalte in der Datenbank gespeichert werden, die nicht in Bezug
BA-Inv2
zu dem angebotenem Fahrzeug oder zu dem webbasierten Fahrzeugmarkt allgemein stehen
Abbildung 9 Inverse Benutzeranforderungen
2.3.4 Entwurfsentscheidungen
EE
EE1
EE2
Beschreibung der Anforderung
Implementierungssprache ist Java (Java 2 SDK 1.3)
Die zu erstellenden Webseiten werden mit JSP implementiert; der verwendete JSPContainer 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- Inhalten 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.
Client (Benutzer)
Server
JSP
HTML-Datei
mit Formular
Internet
Browser
Formular
abschicken
übertragen
Automatisch
erzeugte
HTML-Datei
An Appl.-Server
weiterleiten
Apache
Web
Server
HTML-Datei
übertragen
ApplikationsServer
(Tomcat)
HTMLDatei
erzeugen
Automatisch
erzeugte
HTML-Datei
DB Ab- und
Anfrage
PoolManager
DBMS
PostgreSQL
Firewall
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 Fahrzeugmarkt. Erschwert wird diese Anforderung durch eine Vielzahl bereits auf dem Markt vorhandener webbasierter Fahrzeugmärkte, die auf den Handel mit gebrauchten und neuen Fahrzeugen 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 Fahrzeugen 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 geringem 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 strukturgebendes Element fungiert das Model- View- Controller Design Pattern. Jede der drei Komponenten 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 konkretisiert werden.
3.1 Das MVC-Design Pattern
Programme mit graphischer Benutzeroberfläche werden schnell kompliziert und unübersichtlich. Um zu verhindern, dass solche Programme ab einer bestimmten Größe unwartbar werden, ist es erforderlich, sie mit einer Architektur zu versehen [Tataryn 2002]. Das ModelView- Controller Design Pattern beschäftigt sich damit, wie sich Programme mit graphischen
Benutzeroberflächen besonders gut organisieren lassen. Es handelt sich hierbei um eine Technik zur Trennung der Businesslogik (Model), vom User Interface (View) und Ablaufsteuerung (Controller).
User
View
Controller
Model
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 Kontrolle 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.
Controller
(=Servlet, JSP)
Client
Model
(=Java Bean,
SQL)
DB
(=SQL)
stellt Daten bereit
View
(=JSP)
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 Verarbeitungslogik (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 Softwarekomponente JavaBeans an [Turau 2000, S.103]. Mit Software-Komponenten versucht man
wiederverwendbare Bausteine zu realisieren, die man anschließend mit speziellen Werkzeugen 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 Plattformunabhängigkeit.
JDBC
Java-Anwendungen greifen auf SQL- Datenbanken über einen JDBC- Treiber zu (Java Database 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 Varianten [Bücker 2002, S.12]. Abbildung 14 zeigt den prinzipiellen Aufbau des Treibers, wie er
von KLinform genutzt wird.
Java-Applikation
JDBC-API
JDBC-Treibermanager
JDBC-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 Datenbanken benutzt. SQL ist nach dem American National Standards Institute (ANSI) Standard
genormt und damit auf vielen relationalen Datenbank Management Systemen (RDBMS) anwendbar. 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 Umgebungsbeschreibung
Als Grundlage und grobe Richtlinie für die Implementierung des Systems dient die Beschreibung 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. Dabei führen die meisten Aktionen sowohl der Benutzer, als auch des Administrators zu Veränderungen 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 Personenkraftwagen. Die Komponente der Krafträder ist sowohl strukturell als auch inhaltlich identisch. 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 Pattern beschrieben werden. Einen ersten Überblick über die Umsetzung in dem Gesamtsystem
gibt Abbildung 16. Zur besseren Veranschaulichung sind die Dateien den jeweiligen Komponenten farblich zugeordnet.
Die im Abschnitt 2.3 beschriebenen Basisfunktionen sind in jeweils separaten Unterverzeichnissen 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 ControllerKomponente 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 gewä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 ControllerKomponente 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
$klinform
/html/bs/
fahrzeugmarkt/
admin
bild_
hochladen
suchen/
index.
jsp
beans.
jsp
index.
jsp
formular.
jsp
index.
jsp
index2.
jsp
inserat_
bearbeiten
detail
formular_
ein_
inserat.
jsp
formular_
inserat_
sperren.
jsp
formular_
bild_
hochladen.
jsp
index.
jsp
index_
suchergebnis.
jsp
index_
suchergebnis_
expertensuche.
jsp
formular.
jsp
formular_
suchanfrage.
jsp
formular_
suchanfrage_
geloescht.
jsp
formular_
suchergebnis_
expertensuche.
jsp
inserieren
Seite 26
formular_
speichern_
bestaetigen.
jsp
index.
jsp
formular1.
jsp
index.
jsp
index_
suchergebnis.
jsp
formular_
aendern_
bestaetigen.
jsp
formular2.
jsp
formular1.
jsp
formular2.
jsp
formular3.
jsp
formular_
loeschen_
bestaetigen.
jsp
formular_
keine_
berechtigung.
jsp
formular_
statistik.
jsp
index.
jsp
formular_
suchergebnis.
jsp
formular3.
jsp
ok.
jsp
formular.
jsp
bilddatei
/WEB-INF/
classes/de/
klinform/bs/fama
Model-Komponente
DBConnection.
class
Benutzer.
class
Fahrzeug.
class
Interne_
Abarbeitung.
class
Formular_
Detail.
class
File
Upload
Bean.
class
View-Komponente
Controller-Komponente
Abbildung 16 Struktur des Bausteines Fahrzeugmarkt
PKW.
class
formular_
inserat_
sperren.
jsp
ok.
jsp
Systementwurf auf Basis des MVC-Design Pattern
Seite 27
4.1 Objektorientierte System- und Datenbankstruktur (Modell- Komponente)
Wie bereits in Abschnitt 3.1 beschrieben wurde, repräsentiert das Modell die Daten im System, 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- Diagramm 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.
Suchprofil
[1,1]
Inserat
[1,1]
[1,1]
hat
ist Inserator
von
Inserat enthält
[0,1]
[0,n]
[1,1]
[1,1]
Fahrzeug
is_a
[0,n]
is_a
[1,1]
PKW
Benutzer
hat
[0,n]
Marke
hat
[0,n]
Ausstattung
hat
[0,n]
Aufbauart
hat
[0,n]
Typ
Kraftrad
[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 Datenbank 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 Tabelle fama_benutzer wird lediglich der Primärschlüssel von perso_benutzer referenziert.
Aus diesem Grund kann ein Inserat, beziehungsweise ein Suchprofil nur dann gespeichert 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 weder ein Suchprofil noch ein Inserat, so wird er in der Tabelle fama_benutzer nicht geführt.
·
Entität Fahrzeug:
Hier werden alle Attribute gespeichert, die unabhängig von der jeweiligen Fahrzeugkategorie 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 Inserat 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 ansprechbar. 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 Suchprofile 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 Inserates ü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 Inseraten und Suchprofilen vorzunehmen.
-
Mangelnde Übersichtlichkeit durch Vermengung von Inseraten und Suchprofilen
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 referenziert, um die Konsistenz der Daten zu gewährleisten und die existenzielle Abhängigkeit 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 bekannten 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 Krafträdern.
Die Entitäten Aufbauart und Typ werden entsprechend in den Tabellen fama_aufbauart und fama_typ verwaltet. Dabei beschreibt Aufbauart die Karosserieform des PKW beziehungsweise die Aufbauart des Kraftrades. Die Entität Typ unterscheidet beispielsweise zwischen Neuwagen und Gebrauchtwagen.
·
Entität Ausstattung
Gekapselt werden ebenfalls mögliche Sonderausstattungen gespeichert. Doch im Gegensatz zu der Entität Marken sollen hier keine Attributsausprägungen, sondern die
Attribute selber gespeichert werden. Die Ausstattungen der Fahrzeuge unterliegen einem dauerndem Wechsel und die gewünschten Sonderausstattungen auf dem Gebrauchtwagenmarkt passen sich diesen Änderungen an. Standen noch vor wenigen
Jahren ABS und Fahrerairbag nur in gehobenen Preissegmenten zur Verfügung, so gehören Sie heute zur Serienausstattung in beinahe jedem PKW. Eine dezentrale Verwaltung 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 dynamischen 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 Wahrscheinlichkeit einer zukünftigen Änderung dieser Attribute erscheint gering. Des weiteren sind
diese Attribute in ihrer Typausprägung zu unterschiedlich, eine gemeinsame Verwaltung 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ätzen. 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 Sinnhaltigkeit 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 dortigen 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öschvorgang, 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 Klassen, welche Entitäten beschreiben die auch als Tabelle in der Datenbank enthalten sind, verfügen über die gleichen Attributsbezeichnungen und Typspezifikationen. Auf diese Weise
können die Werte der Datenbank mühelos von den jeweiligen Objekten der Klassen aufgenommen 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 Javadoc und die Kommentierung des Codes verwiesen.
Fahrzeug
Benutzer
-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()
+Fahrzeug(in db)
+setFahrzeug() : void
+setFahrzeug() : void
+reset() : void
+MarkenToMarkenwerte() : void
+MarkenwerteToMarken() : void
+validate() : Boolean
-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()
+setBenutzer() : void
+setBenutzer() : void
+reset() : void
PKW
-typ : String
-treibstoff : String
-karosserie : String
-getriebe : String
-farbe : String
-leistung : int
-leistungvon : int
-leistungbis : int
-verbrauch : float
-verbrauchvon : int
-verbrauchbis : int
+PKW()
+PKW(in db)
+reset() : void
+setPKW() : void
+setPKW() : void
+validate() : Boolean
-hat
*
-Inserat von
1
AbstractDatabase
DBConnection
-typ : String
+DBConnection()
+AnzahlDerEintraege() : int
Eintrag
+BenutzerExist() : Boolean
-Benutzer : Benutzer
+Bild_Bearbeiten() : void
-PKW : PKW
+DatumCheck() : Benutzer[]
-typ : String
+ExpertensuchePKW() : Eintrag[]
+getEintrag() : Eintrag
+Eintrag()
+GetIdFromTable() : int
+getPrintRepresentation()
+HatInserat() : Boolean
+getId() : int
+HatSuchanfrage() : Boolean
+getLongRepresentation()
+holeAusstattung() : String[]
+getRepresentationTitle() : String
+holeAufbauart() : String[][]
+getShortRepresentationColumns() : String[]
+holeMarke() : String[][]
+compareTo() : int
+holeTyp() : String[][]
+getEintrag() : Eintrag
+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
AbstractFormHandler
Thread
Formular_Detail
-id : int
-von : String
+validate() : Boolean
FileUploadBean
-savePath : String
-filepath : String
-filename : String
-contentType : String
-filenamefromoutside : String
-fields
+FileUploadBean()
+delete() : void
+doUpload() : void
Interne_Abarbeitung
-db
-email
-pkw : PKW
-benutzer : Benutzer[]
-aktion : String
-to : String
-sbj : String
-msg : String
+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
Zuzüglich enthält jede Klasse für alle Attribute Get- und Set-Methoden.
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 entsprechende 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 geschrieben, 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 Attribute ü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 Methode reset().
·
setFahrzeug(): Der Versuch zwei Objekte gleich zu setzen, scheitert an der internen
Speicherverarbeitung von Java. Die Folge davon sind Datenverlust und schwer kalkulierbare Verhaltensweisen. Ein korrektes Ergebnis kann nur durch attributsweißes Zuweisen 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 zugewiesen.
Um die Struktur der Klasse DBConnection zu vereinfachen, existiert eine weiter Methode setFahrzeug(), diese erwartet aber einen Übergabewert vom Typ ResultSet. Dadurch ist die Zuweisung der Inhalte des ResultSet der Datenbank an das Objekt Fahrzeug 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 Fahrzeug 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 AbstractFormHandler.
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 werden. Die Aufgabe der Verarbeitung dieser Daten kommt ebenfalls der Klasse Fahrzeug zu.
Dazu verfügt die Klasse über die Variablen ausstattung, austattungswerte, marke und markenwerte. 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 beinhaltet 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 markenwerte 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 werden die Markennamen durch eindeutige IDs gespeichert. Um eine Zuweisung des tatsächlichen 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 Verwendung. 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 Konstruktoren 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 weiterhin die Attribute für das Leistungsintervall und das Verbrauchsintervall gespeichert. Die
PKW- spezifischen Ausstattungen werden ebenfalls zentral von der Klasse Fahrzeug behandelt, 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 optimal gekapselt.
Klasse Benutzer
In dieser Klasse werden die Daten des Benutzers des Fahrzeugmarktes verwaltet. Dazu verfü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 Austausch 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 gespeichert, 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 Verbindung zur Datenbank herstellen kann, benötigt es ein Objekt vom Typ Connection. Dieses
wird über die Methode getConnection() der Klasse AbstractDatabase bereitgestellt. Wird diese 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 ablaufen. 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 benachrichtigt. 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 filenamefromoutside. Diese Variable wird vor dem eigentlichen Speichervorgang gesetzt und hat folgende 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 Applikation. Zur optimalen Umsetzung dieser Anforderung müssen eine Reihe von Bedingungen
erfüllt werden:
·
Ansprechendes Design: Neben dem repräsentierten Inhalt und einer logischen Benutzerführung ist ein gelungenes Design Grundvoraussetzung für den Erfolg einer Webseite. Entscheidend dafür ist die Verbindung einer ansprechenden graphischen Oberfläche mit einer möglichste intuitiven Bedienbarkeit. Die Gestaltungsfreiheit beschränkt sich in den einzelnen Bausteinen jedoch auf die Anordnung der jeweiligen
Kommunikationsfelder. Durch die vorgegebenen Stylesheets und dem damit verfolgten Ziel einer einheitlichen Oberfläche, werden Attribute wie Farbe, Form und Hintergrund 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, beispielsweise 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 Detailansicht eines Fahrzeuges. Diese Seite überzeugt durch die Darstellung aller Fahrzeugdaten auf übersichtliche Art. Das optionale Bild bietet einen zusätzlichen Handlungsanreiz.
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 konkretes Sitzungsobjekt, X für ein konkretes Attribut.
Bereits mehrfach wurde die Kapselung der möglichen Sonderausstattungen in der Datenbank 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 definiert. 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 Werte des Benutzers müssen durch den View erfasst werden und an den Controller, beziehungsweise 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-FormTag fasst die Eingabefelder zu einer Einheit zusammen. Wechselt der Benutzer, beispielsweise 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. Problematisch 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 Ablaufsteuerung 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ührende 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 bearbeiten. 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
Neue Suche -- Wert werden zurückgesetzt
zurück
Suchmaske ausfüllen
Neue Suche -- Wert werden zurückgesetzt
Suchergebnisse der
booleschen Suche
Suche
Aktion wählen
Suchergebnisse des
Vektorraummodells
Freie Suche
Aktion wählen
abbrechen
Suchprofil anlegen
nein
Suchprofil öffnen
abbrechen
Aktion wählen
eingeloggt
Details
nein
Detailansicht
Benutzer-Login
Aktion wählen
abbrechen
Benutzer hat
Suchprofil
eingeloggt
Benutzer-Login
ja
ja
Benutzer hat
Suchprofil
Speichern
bestätigt
nein
Inserat sperren
ja
ja
Grund angeben
nein
Suchprofil geöffnet
Email an
Administrator
Aktion wählen
Suchprofil löschen
nein
Löschen
bestätigt
ja
Suchprofil löschen
Abbildung 21 Ablaufsteuerung der Basisfunktion Suchen
Suchprofil
gespeichert
ja
Systementwurf auf Basis des MVC-Design Pattern
Seite 41
Aktion
wählen
Neues Inserat
Inserat bearbeiten
eingeloggt
eingeloggt
nein
nein
ja
Benutzer-Login
Benutzer-Login
Daten eingeben
ja
Inserate auflisten
Nicht ok
Daten
validieren
ok
Daten
ansehen
Suchprofile auf
Übereinstimmung
durchsuchen
Email an
Administrator
Daten speichern
ja
Detailansicht
nein
Daten laden
zurück
Bild bearbeiten
Bild löschen
Bild gelöscht
Aktion
wählen
Bild hochladen
Bild gespeichert
Aktion
wählen
Aktion
wählen
Inserat bearbeiten
Löschen
Löschen
bestätigt
Statistik ansehen
ja
Statistik
Inserat gelöscht
nein
Detailansicht
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 eingebunden ist. Dazu sind lediglich bezüglich der Model- Komponente einige Anmerkungen notwendig. 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 hinzugefü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 Fahrzeug 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“ zugeordnet. Die Methoden in DBConnection sind in zwei Mengen unterteilbar. Es existieren Methoden, die von allen Fahrzeugtypen mit den selben Attributen aufgerufen werden. Die Unterscheidung 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 gemeinsamen Menü heraus zu verwalten, unabhängig von dem zugrundeliegenden Fahrzeugtyp. Dieses Menü wird aus dem Hauptmenü heraus aufgerufen. Die Ergebnisse werden in zwei Tabellen 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 Methode getLongRepresentation() der Klasse Eintrag festgelegt und differiert natürlich zwischen
den Fahrzeugtypen. Zur Unterscheidung wird diese Methode aus zwei verschiedenen Formularen 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 zugehörigen index- Datei zwischen den Fahrzeugtypen zu unterscheiden. So erfolgt beispielsweise 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 Schnittstellen 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 „Personalisierung 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öglichkeiten des Administrators und kann damit als Handbuch für eine spätere Wartung des Systems angesehen werden.
5.1 Interaktionsmöglichkeiten des Benutzers mit dem System
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 Inserate zu überprüfen. Dazu wird er automatisch per Email über neue Einträge informiert. Zeitmangel 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 Entscheidungsfindung 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 abspeichert, 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 gesperrt 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. Selbstverständlich stellt sich der eigentliche Erfolg erst mit dem abgeschlossenem Verkauf des Fahrzeuges 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 denkbar bereits jede Suchanfrage zu zählen, deren Ergebnismenge das entsprechende Inserat enthä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 gemacht. 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 überdurchschnittlich 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 Verhältnis zu dem Informationsgewinn für den Benutzer steht.
Umsetzung der Suchfunktion durch nicht- probabilistische Information Retrieval Modelle
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 Vorstellungen über das gesuchte Fahrzeug. So ist beispielsweise ein bestimmtes Set von Eigenschaften durch die Wünsche des Käufers determiniert. Dem gegenüber steht aber häufig ein weiteres 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 werden. 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 ungenauer 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 unterschiedliche Arbeitsweise verdeutlicht werden.
Information Retrieval
Als kennzeichnend für das Gebiet des Information Retrieval werden vage Anfragen und unsicheres 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 einfaches Grundmodell des Information Retrieval vor.
Ausgewählte Implementierungslösungen
beruht auf
Seite 47
Information Retrieval
Semantische Modellierung eines
Weltausschnittes
Fakten eines Weltausschnittes
durch
anhand von
Zuweisen von Attributen zu
gegebenen Einheiten
gespeichert in
liefert
Kombination elementarer
Operationen auf Datenstrukturen
Datenbankstrukturen
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 Inseraten, vorhanden. Dem gegenüber steht eine Menge von Anfragen an des System. Die Retrievalfunktion vergleicht Frage- Dokumente- Paare und berechnet das Retrievalgewicht. Die
Definition der Retrievalfunktion hängt dabei von dem jeweils zugrundegelegten Retrievalmodell ab.
Bezogen auf den Fahrzeugmarkt ist der Vorgang der Eingabe syntaktisch durch die vorgegebene Suchmaske für den Benutzer relativ stark festgelegt. Diese Kenntnis des Modells erleichtert den eigentlichen Suchvorgang und kann zu genaueren Ergebnissen führen. Allerdings 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 beschrä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 Dokumente 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, beziehungsweise 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 folgendermaßen interpretiert:
·
eine gesetzte Checkbox erfordert das Vorhandensein dieses Attribut
·
eine ungesetzte Checkbox wird nicht in die Suchanfrage aufgenommen, sie bewirkt also 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 Inseraten.
·
Es gibt keine Möglichkeit zur Gewichtung von Fragetermen oder zur Berücksichtigung von gewichteter Indexierung. Dadurch hat beispielsweise die Übereinstimmung
der Marke in Frage und Antwort dasselbe Gewicht, wie die Übereinstimmung der Eigenschaft „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 gesucht, so wird das Fahrzeug mit einem Preis von 10.001 Euro bereits nicht mehr ausgegeben.
Eine Reihe dieser Nachteile können durch die Anwendung des Vektorraummodells überwunden 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 Dokumenten gesucht, deren Vektoren ähnlich (im Sinne einer vorgegebenen Metrik) zum Fragevektor sind.“ [Fuhr 2000, S.90] Der zugrundeliegende Vektorraum wird als orthonormal angenommen. Um die Ähnlichkeit zweier Vektoren zu berechnen existieren eine Vielzahl von
Retrievalfunktionen, beispielsweise das Skalarprodukt, das Cosinus- Maß, das Pseudo- Cosinus- 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
cos(d i , q ) =
åd
i, j
×qj
j =1
n
å di, j
j =1
2
n
åq
j =1
2
j
Dabei bezeichnet D die Menge der Dokumente in der Datenbasis und Q die Menge der Anfragen.
Die Umsetzung des Vektorraummodells erfolgt in der Methode ExpertensuchePKW, welche
ebenfalls Teil der Klasse DBConnection ist. Die verwendete Retrievalfunktion ist das Cosinus- Maß. Um dem Benutzer die Bedienung des Fahrzeugmarktes zu erleichtern, wird die
Suchanfrage über dieselbe Suchmaske aufgerufen, die bereits im obigen Modell des Booleschen Retrieval beschrieben wurde. Diese komplexe Suchanfrage muss zunächst auf die Anforderungen 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 d i , j und q j werden mit den entsprechenden 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 d i , j und q j mit 1. Stimmen die Werte nicht überein, so wird nur die
Variable q j 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 Informationen 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 q j
wird nun mit dem Wert dieser Klassenmitte belegt, die Variable d i , j mit dem eigentlichen 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 jeweiligen Inserates ab.
Der bisher beschriebene Programmablauf beinhaltet eine ganz wesentliches Problem – jedes
Attribut ist bezüglich dem Einfluss in der Relevanzberechnung gleich gewichtet. Dieses Problem des Booleschen Retrieval soll aber gerade durch das Vektorraummodell überwunden
werden. Dazu ist ein notwendig, Gewichtungen für die einzelnen Attribute einfließen zu lassen. Folgende subjektive Gewichtungen sind implementiert:
·
Die booleschen Werte der Fahrzeugausstattung (das sind diejenigen, die durch Checkboxen 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 Ergebnistabelle 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, entspricht. 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 DBConnection die Methode InseratAufSuchprofilCheck der Klasse Interne_Abarbeitung aufgerufen. Diese 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 entsprechenden Suchprofilen. Die Schwierigkeit besteht in dem umgekehrten Durchlauf der Suche. Normalerweise 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 solchen umgekehrten Suche ist sehr aufwendig. Aus diesem Grund wurde das gesamte Problem
auf das Ursprungsproblem der Standardsuche reduziert. Dabei durchläuft das Programm folgende 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 ausgeführt. Dabei dienen die Werte des jeweiligen Suchprofils als Basis. Neben der Standardsuche 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 Suchschritt 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 Benutzer[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 verarbeitet. Für jeden Benutzer wird eine Email generiert und versendet. Diese enthält einen Link auf die Detailansicht des neu eingegebenen Inserates.
5.2 Eingriffsmöglichkeiten des Administrators in das System
Die Wünsche der Kunden von KLinform zu befriedigen ist oberstes Ziel des gesamten Projektes. 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 Systems, 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 Auswahl 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, automatische 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 Interene_Abarbeitung und die Methode DatumCheck() der Klasse DBConnection bereit. Der gesamte Vorgang läuft in einem eigenen Thread ab, so dass die zeitliche Belastung des Administrator 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=false
last_change=today
Inserat geändert
Differenz zwischen last_change
and today> klinform.properties
Loeschen_vorgemerkt=true
ja
ja
Loeschen_vorgemerkt=true
mahnung=today
Differenz zwischen mahnung and
today > 14
ja
Inserator wird benachrichtigt
Inserat wird gelöscht
Inserator wird benachrichtigt
Abbildung 25 Administrator - Überprüfung der Aktualität der Inserate
Die Steuerung erfolgt durch die drei Attribute last_change, mahnung und loeschen_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 klinform.properties gespeicherte Zeitraum zurück, so wird der Verkäufer gemahnt und die Variable loeschen_vorgemerkt wird auf „true“ gesetzt. Damit wird bei einem erneuten Programmdurchlauf 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 Administrator 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 Bedeutung 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 direkt integriert, sondern werden zentral verwaltet. Diese Aufgabe übernimmt die Konfigurationsdatei $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önnen 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 formatierte String in die zugewiesen Stelle eingefügt.
Mittels der Konfigurationsdatei kann der Administrator folgende Attribute verändern:
Attribut
fama_admin
Variable Felder Beschreibung
-
fama_detail_link
-
Email- Adresse des Administrator für den
Fahrzeugmarkt
Beschreibt den Link auf die Detailansicht, wie
er in die versendeten Emails eingebunden
wird.
Beim Umgang mit Bildern muss auf der Server-Seite zwischen zwei Pfaden unterschieden
werden:
·
·
fama_ort_bild_upload
fama_ort_bild_upload_relativ
fama_suchprofil_subject
fama_suchprofil_message
Anrede
Vorname
Name
Link Detailansicht
Dateipfad bezogen auf die Webserver-Root und
Dateipfad bezogen auf das ServerDateisystem.
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.
Betreff und Nachrichtentext der Email, die
versendet wird, wenn ein neues Fahrzeug
entsprechend den Angaben in dem gespeicherten Suchprofil gefunden wird.
Ausgewählte Implementierungslösungen
fama_inserieren_subject
fama_inserieren_message
ID des Inserates
Anrede
Vorname
Name
Link Detailansicht
ID des Inserates
-
fama_gueltigkeit_inserat_in_tagen
fama_datum_subject
fama_datum_message
fama_loeschen_subject
fama_loeschen_message
fama_datum_admin_subject
fama_datum_admin_message
fama_loeschen_admin_message
Anrede
Vorname
Name
Link Detailansicht
ID des Inserates
Anrede
Vorname
Name
ID des Inserates
Anzahl der gesendeten Mahnungen
Anzahl der gelöschten Inserate
Link Detailansicht
ID des Inserates
Grund der Sperrung
Anrede
Vorname
fama_inserat_sperren_admin_subject Name
fama_inserat_sperren_admin_message Link Detailansicht
ID des Inserates
Grund der Sperrung
fama_inserat_sperren_subject
fama_inserat_sperren_message
Seite 55
Betreff und Nachrichtentext der Email, durch
die der Administrator über neue Inserate informiert wird.
Hier wird festgelegt, wie viele Tage ein Inserat
unverändert online geschaltet bleiben soll,
ohne dass der Inserator aufgefordert wird,
dieses zu aktualisieren.
Betreff und Nachrichtentext der Email, durch
die der Verkäufer aufgefordert wird, sein Inserat zu aktualisieren.
Betreff und Nachrichtentext der Email zur
Information des Verkäufers, dass ein Inserat
gelöscht wurde.
Betreff und Nachrichtentext der Email an den
Administrator über die Anzahl der, im Rahmen der Administration gesendeten, Mahnungen.
Nachrichtentext der Email an den Administrator über die Anzahl der, im Rahmen der Administration gelöschten, Inserate.
Betreff und Nachrichtentext der Email an den
Administrator, mit der begründeten Aufforderung zur Sperrung des Inserates.
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-, beziehungsweise 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 Verkäufer eine Schnittstelle zu den regional ansässigen Printmedien angeboten werden.
Damit wird er in die Lage versetzt, ein aufgegebenes Inserat an Zeitungen oder Zeitschriften 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öglicht, 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 identifizieren, 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 Fahrzeugkategorien zu handeln stellt eine horizontale Erweiterung dar. Folgende Fahrzeugkategorien 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ützrad
o Mehrwertsteuer ausweisbar, Garantie, TÜV
-
Lastkraftwagen
-
Baumaschinen
-
Fahrräder
Die Integration ist relativ einfach und erfordert nur geringen Zeitaufwand. Die Vorgehensweise 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 eines Bausteines „Online Shop“ sollte die notwendige Funktionalität bereitgestellt 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. Denkbar 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 integrierte 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 Motorisierung 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 gewissem 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, Dortmund, 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_IEXw11_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
leistung
treibstoff
karosserie
verbrauch
getriebe
farbe
abs
alarmanlage
allrad
alufelgen
anhaengerkupplung
behindertengerecht
beifahrerairbag
cd
dachtraeger
efensterheber
esitzverstellung
fahrerairbag
kat
klima
leder
VARCHAR(15),
INTEGER,
VARCHAR(15),
VARCHAR(15),
FLOAT(4),
VARCHAR(15),
VARCHAR(15),
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
Anhang
navisystem
nebelscheinwerfer
radio
schiebedach
seitenairbag
servo
sitzheizung
sportausstattung
trueckbank
tempomat
traktionskontrolle
tuning
wegfahrsperre
winterreifen
zentral
ust
garantie
tuev
Seite 62
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
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
inserator
marke
modell
typ
treibstoff
karosserie
getriebe
farbe
leistungvon
leistungbis
verbrauchvon
verbrauchbis
erstzulassungvon
erstzulassungbis
laufleistungvon
laufleistungbis
preisvon
preisbis
abs
alarmanlage
allrad
alufelgen
anhaengerkupplung
INTEGER
VARCHAR(20)
VARCHAR(25)
VARCHAR(25)
VARCHAR(15),
VARCHAR(15),
VARCHAR(15),
VARCHAR(15),
VARCHAR(15),
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
INTEGER,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
NOT NULL,
NOT NULL,
NOT NULL,
NOT NULL,
Anhang
behindertengerecht
beifahrerairbag
cd
dachtraeger
efensterheber
esitzverstellung
fahrerairbag
kat
klima
leder
navisystem
nebelscheinwerfer
radio
schiebedach
seitenairbag
servo
sitzheizung
sportausstattung
trueckbank
tempomat
traktionskontrolle
tuning
wegfahrsperre
winterreifen
zentral
ust
garantie
tuev
Seite 63
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
BOOL,
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
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));
Seite 64
Anhang
Seite 65
Installationshinweise
·
Aufbau der Datenbank
Für den Aufbau und die Verwaltung der Datenbank existieren vier Textdateien, welche aus dem PostgreSQL- Kommandozeileninterpreter aufgerufen werden können:
-
fama_tabellen_fahrzeug_benutzer_pkw_erstellen.txt
Erstellt
die
Tabellen
ma_suchanfrage_pkw,
fama_fahrzeug,
fama_marke,
fama_pkw,
fama_benutzer,
fama_aufbauart,
fama_typ,
fafa-
ma_ausstattung. Diese Tabellen müssen zuerst in der Datenbank angelegt werden. Außerdem werden die Sequenzen fama_fahrzeug_id_zaehler und fama_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 Datenbank
·
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 Beschreibungen richtig zuzuordnen.
PKW
Kraftrad
Komfort
101-199
501-599
Sicherheit und Umwelt
201-299
601-699
Weitere
301-399
-
Specials
401-499
701-799