Projektarbeit Ausarbeitung.sxw

Entwurf und Realisierung
eines webbasierten
Stellenmarktes für KLinform
Heiko Ulbrich
UNIVERSITÄT KAISERSLAUTERN
Fachbereich Informatik
AG Integrierte Kommunikationssysteme
Prof. Dr. P. Müller
Projektarbeit
Entwurf und Realisierung eines
webbasierten Stellenmarktes für KLinform
Kaiserslautern, Dezember 2002
Vorgelegt von:
Betreuer:
Heiko Ulbrich
Prof.
Dr. Paul Müller
Dipl.
Inform. Markus Hillenbrand
ABSTRACT
Diese Ausarbeitung beschäftigt sich mit der Erstellung eines webbasierten
Stellenmarktes im Portal KLinform. Der Stellenmarkt ermöglicht es, im Internet
Stellen aller Art zu inserieren und zu suchen.
Der Analyse der Anforderungen und Rahmenbedingungen für den zu
erstellenden Baustein schliesst sich die Vorstellung der zugrunde liegenden
Techniken Java, Java Server Pages und relationale Datenbanken an. Dem
konzeptuellen Entwurf folgt dann, teilweise anhand ausgewählter Beispiele, die
Vorstellung
der
Implementierung
einzelner
Aufgabengebiete
des
Stellenmarktes.
Eine Zusammenfassung aller wichtigen Punkte schliesst die Ausarbeitung ab.
Inhaltsverzeichnis
1 Überblick.........................................................................................................1
1.1 Das Portal KLinform.................................................................................1
1.2 Das Projekt Stellenmarkt.........................................................................3
2 Analyse...........................................................................................................4
2.1 Erste Anforderungsfeststellung................................................................4
2.2 Bestehende Angebote.............................................................................5
2.3 Attribute einer Anzeige.............................................................................8
2.4 Funktionalität..........................................................................................10
2.5 Zusammenfassung................................................................................12
3 Komponenten und Techniken.......................................................................14
3.1 Datenbanksysteme................................................................................14
3.2 MVC-Konzept.........................................................................................18
3.3 Java Server Pages.................................................................................19
3.4 Java - Beans..........................................................................................20
3.5 Apache Jakarta Project - Tomcat...........................................................21
3.6 Ablauf.....................................................................................................22
4 Konzeptioneller Entwurf................................................................................23
4.1 Datenbank Schema...............................................................................23
4.2 Benutzerführung....................................................................................24
4.3 Beans, Cronjobs....................................................................................27
4.4 Sicherheit...............................................................................................27
5 Implementierung...........................................................................................29
5.1 Datenbank..............................................................................................29
5.2 Realisierung des MVC Konzepts...........................................................30
5.3 Personalisierung....................................................................................37
5.4 Gültigkeitsüberprüfung...........................................................................39
6 Zusammenfassung........................................................................................40
Quellenverzeichnis...........................................................................................42
A Anhang.........................................................................................................43
v
Abbildungsverzeichnis
Abbildung 2.1 Suchmaske - www.stellenmarkt.de..............................................6
Abbildung 2.2 Suchmaske - www.berlin-job.de...................................................7
Abbildung 2.3 Komponenten des Stellenmarktes.............................................13
Abbildung 3.1 Beispiel zu Relationen ...............................................................16
Abbildung 3.2 SQL Beispiel .............................................................................16
Abbildung 3.3 JDBC Verbindung zur Datenbank..............................................18
Abbildung 3.4 MVC Konzept (konkretisiert)......................................................19
Abbildung 3.5 JSP Beispiel ..............................................................................20
Abbildung 3.6 Beispiel einer Bean ...................................................................21
Abbildung 4.1 Entity Relationship Diagramm....................................................23
Abbildung 4.2 Ablauf "Suche"...........................................................................25
Abbildung 4.3 Ablauf "Inserieren"......................................................................26
Abbildung 4.4 Ablauf "Verwaltung"....................................................................26
Abbildung 4.5 Sicherheitsebenen......................................................................28
Abbildung 5.1 SQL Beispiel zum Einfügen (Methode in DB-Bean)...................31
Abbildung 5.2 SQL Beispiel zum Verändern (Methode in DB-Bean)................32
Abbildung 5.3 Auto-Commit Abschaltung..........................................................32
Abbildung 5.4 View - Beispiel............................................................................33
Abbildung 5.5 Controller - Beispiel....................................................................35
Abbildung 5.6 Suchprofile - Suchmethode........................................................38
Abbildung A.1 Einstiegsseite - KLinform ..........................................................43
Abbildung A.2 Relationenmodell ......................................................................44
Abbildung A.3 UML-Klassendiagramm.............................................................45
vi
1 Überblick
1 Überblick
Spätestens seit Mitte der Neunziger Jahre des letzten Jahrhunderts ist das Internet in
aller Munde. Für viele Menschen anfangs als Informationsquelle verstanden,
entwickelte sich das Internet zunehmend hin zu einem großen Angebot
verschiedenster Dienste. Ein Großteil des Erfolges des Internets beruht auf der
Möglichkeit, ortsungebunden Angebote wahrzunehmen. So kann der vernetzte
Nutzer von zu Hause aus ein webbasiertes Angebot wahrnehmen. In dem hier
betrachteten Fall handelt es sich um das Szenario eines Arbeitssuchenden. Er kann
ohne Zeitverzögerung nach Anzeigen suchen, ist nicht auf herkömmliche
Printmedien angewiesen und kann Zusatzmöglichkeiten ausschöpfen, die ihm das
Auffinden einer Arbeitsstelle erleichtern sollen. Dieses Angebot wird in einem Portal
zur Verfügung gestellt.
1.1 Das Portal KLinform
Ein Portal im Internet versucht, bestimmten Nutzergruppen und Informations- sowie
Angebotsbedarfen entgegenzukommen, indem es einen auf diese Gruppe
zugeschnittenen Internetauftritt realisiert.
KLinform realisiert als Portal für die Region Kaiserslautern einen großen Katalog an
Angeboten unter einem Dach. So finden sich Angebote aus den Bereichen Märkte,
Dienstleistung, Service, Information, Multimedia und Lebenslagen.
KLinform hat sich das Lebenslagenkonzept zu eigen gemacht. Es versucht anhand
von Lebenslagen ein speziell auf den Benutzer zugeschnittenes Angebot zu
präsentieren. So werden Informationen und Dienste zusammengestellt, die für einen
Menschen in einer bestimmten Lebenslage oder Situation von Belang sein könnten.
Der Betrachter spart sich somit den Aufwand, eine Vielzahl von Angeboten einzeln
zu suchen, anzusteuern und eventuell als nicht relevant erachten zu müssen. Diese
Vorauswahl wird von KLinform vorgenommen. Verflechtungen einzelner Lebenslagen
sind beabsichtigt und von KLinform zu berücksichtigen. So wird beispielhaft einem
Sportler eine Ansammlung von Informationen über Vereine, Clubs, Umgebung, und
gewerblichen Fitnesseinrichtungen präsentiert werden.
1
1 Überblick
Ein
weiteres
Augenmerk
von
KLinform
ist
das
Personalisierungskonzept.
Personalisierung bezeichnet für ein Internetportal den Vorgang, das Angebot den
Bedürfnissen eines Benutzers anzupassen, indem dessen Verhalten analysiert oder
explizite Angaben zu seinen Präferenzen eingeholt werden. Missbrauch ist leider
vielmals auf der Seite der automatisierten Analyse von Benutzerverhalten zu finden.
Durch Verfolgung eines Benutzers innerhalb eines oder mehrerer vernetzter
Angebote werden Rückschlüsse über dessen Bedürfnisse und Gewohnheiten
gezogen, um ihn zum Beispiel gezielt mit Informationen zu versorgen, die er nicht
explizit angefordert hat. Jeder Internetbenutzer, der Email zur Kommunikation mit
anderen Menschen benutzt, wird früher oder später feststellen, dass seine EmailAdresse Dritten zugänglich gemacht für deren Zwecke missbraucht wurde. Dem
Schutz der Benutzerdaten muß also ein hohes Maß an Aufmerksamkeit gewidmet
werden. In diesem Zusammenhang wird die explizite Aufforderung zu Angaben,
seitens des Benutzers von einem System, als die vom Konzept her bessere Form
angesehen.
Dem Benutzer, der auf KLinform zugreift, wird eine strukturierte Übersicht der
Angebote gezeigt, von der aus er dann zu den einzelnen Unterpunkten weiter
navigieren kann.3
Um eine verständliche Benutzerführung zu gewährleisten, wurde bei KLinform darauf
geachtet, alle Bedienelemente in Aussehen und Funktion gleich zu gestalten. Dies
erleichtert dem unerfahrenen Benutzer die Navigation und sollte eines der primären
Ziele eines jeden Internetauftritts sein. KLinform realisiert dies durch Stylesheets. Sie
sind Vorlagen für Elemente einer Internetseite. So wird zum Beispiel für eine Tabelle
das Aussehen von Rahmen, Hintergrund und Schriftausrichtung festgelegt. Diese
Festlegung ermöglicht es, das Aussehen des gesamten Portals an einer zentralen
Stelle zu verändern. Bei der Realisierung einzelner Seiten muss nur noch dieses
Stylesheet eingebunden werden. Das Aussehen von Tabellen bedarf so nicht in
jedem Fall einer neuen Festlegung, was den Erstellungsaufwand erheblich
vereinfacht und beschleunigt.
KLinform liegt eine relationale Datenbank (PostgreSQL) zugrunde, in der die
anfallenden Daten abgelegt und aus der sie wieder extrahiert werden können, sowohl
3 Abbildung A.1
2
1 Überblick
von Benutzern des Portals als auch dessen Administratoren.
1.2 Das Projekt Stellenmarkt
KLinform ist über einen längeren Zeitraum gewachsen und verfügt mittlerweile über
eine Vielzahl von Komponenten. Ziel der hier vorliegenden Projektarbeit ist es, einen
Stellenmarkt zu implementieren, der sich nahtlos in den Verbund der übrigen
Komponenten von KLinform einfügt. Benutzern soll das Auffinden von zuvor
geschalteten Anzeigen für einen Kontakt zwischen Arbeitgeber und Arbeitnehmer
ermöglicht werden. Dazu muss den Arbeitgebern die Möglichkeit gegeben werden
Stellen zu inserieren, die der Benutzer über eine Suchfunktion auffinden kann.
Im Folgenden wird eine Analyse der Anforderungen an eine Komponente
Stellenmarkt durchgeführt, um daraus die Rahmenbedingungen für Entwurf und
Implementierung des Systems festzulegen. Es soll weiter auf bestehende Angebote
eingegangen und eine Einschätzung der benötigten Funktionalität für einen
regionalen Stellenmarkt getroffen werden.
3
2 Analyse
2 Analyse
Beim Aufsuchen eines bestehenden Stellenmarkts im Internet ist es für den Benutzer
zuerst einmal wichtig, wie bekannt dieser ist. Ist ein Stellenmarkt wenig bekannt, so
kann er bei aller Funktionalität sein größtes Problem erst einmal nicht ablegen: Sein
vorhandener Datenbestand ist klein und zieht somit nicht viele Arbeitssuchende an.
Hier ist festzustellen, dass ein integriertes Portal wie KLinform möglicherweise den
Vorteil bietet, dass die Vielzahl von Angeboten auf Dauer eine größere Menge an
Interessierten anziehen wird als viele einzelne, unabhängige Angebote. Der
Benutzer, der erst einmal nur ein Angebot von KLinform aufgesucht hat und durch
die Einstiegsseite einen Überblick über die Vielfalt von Angeboten bekommen hat,
wird in Zukunft im Idealfall für andere Interessen wieder auf KLinform zurückgreifen.
Dennoch ist durch die regionale Ausrichtung des Portals auch die Begrenzung des
Stellenmarktes auf die Region gegeben.
2.1 Erste Anforderungsfeststellung
Grundsätzlich gibt es im Leben eines Menschen verschiedene Phasen, in denen er
Arbeit sucht.
Während seiner Schulzeit ist er nicht unbedingt bezüglich seines Berufswunsches
festgelegt und möchte eventuell ein Praktikum absolvieren, um einen Einblick in
einen Berufszweig zu bekommen. Gleiches kann für Studenten gelten, die
verpflichtend oder aus persönlichem Interesse ein Praktikum ablegen möchten. Im
Anschluss an die Schulzeit schließt sich für die meisten Menschen die Phase der
Ausbildung an, die ebenfalls als Arbeitsverhältnis für einen Stellenmarkt in Betracht
zu ziehen ist. Den größeren Anteil der Angebote werden Arbeitsstellen aller
Berufsfelder umfassen, die nach erfolgter Ausbildung aufgenommen werden.
Somit ist die erste Unterscheidung nach Jobtyp in Praktikumsplatz, Ausbildungsplatz
und Arbeitsstelle festzuhalten.
Gegeben durch die verschiedenen Berufsfelder und Aufgabengebiete ist eine
Unterteilung in Rubriken notwendig. Dies dient der Bündelung von Angeboten zu
Mengen gleich ausgerichteter Angebote.
In den einzelnen Berufsfeldern sind verschiedene Arbeitsstellen anzutreffen, die
weiter
nach
Stellentitel,
gewünschter
Ausbildung
und
Arbeitsverhältnis,zu
4
2 Analyse
unterscheiden sind.
Somit lässt sich zusammenfassend die Grundmenge der Merkmale eines Angebots
innerhalb eines Stellenmarktes festhalten:
–
Jobtyp (Praktikum, Ausbildungsplatz, Arbeitsstelle)
–
Rubriken (Berufsfelder)
–
Stellentitel (Bezeichnung der Stelle)
–
Ausbildung (Titel, Ausbildungsgrad eines potentiellen Bewerbers)
–
Arbeitsverhältnis ("Vollzeit", "Teilzeit", "Nebenjob" und "Freie Mitarbeit")
2.2 Bestehende Angebote
Anhand einiger Beispiele von bereits bestehenden Stellenmärkten sollen bestimmte
Aspekte aufgegriffen werden, die für das konkrete Projekt von Belang sind. Auch
eine allgemeine Analyse dieser Angebote folgt in dieser Arbeit. Mittels verschiedener
Suchmaschinen konnte eine Vielzahl bestehender Stellenmärkte aufgefunden
werden. Hierbei ist eine Unterteilung in verschiedene Kategorien von Angeboten
festzuhalten.
2.2.1 Allgemeine Stellenmärkte
Sie versuchen eine Universallösung für Arbeitgeber und Arbeitnehmer zu realisieren.
Sie sind landesweit, branchenunabhängig, für Arbeitgeber je nach Popularität des
Angebots kostenpflichtig und bieten Suchfunktionen, Anlegen von Angeboten,
Lebensläufen und Registrierung von Benutzern. Durch ihre universelle Auslegung
verfügen sie über eine Vielzahl von Angeboten, aus denen ein Benutzer auswählen
kann. Hier spielt sicherlich der Aspekt der Mobilität eines Arbeitssuchenden eine
große Rolle. Auf ortsgebundene Arbeitssuchende wird eingegangen, indem der
Suchbereich regional oder ortsspezifisch eingegrenzt werden kann. Als Beispiele
großer Stellenmärkte (definiert über die Anzahl der Einträge) seien Monster
[Monster.de], jobpilot [Jobpilot.de] und Stellenmarkt Online [Stellenmarkt Online]
genannt. Bei der Arbeitssuche wird dort meistens eine Einschränkung des Angebots
über
Berufsfeld,
verschiedene
Jobtypen,
Zeitraum,
Ort
und
Eingabe
von
Suchbegriffen vorgenommen. Einen Ausschnitt einer Suchmaske zeigt beispielhaft .
Je mehr einschränkende Suchmöglichkeiten über verschiedene Attribute eines
Angebots angeboten werden, desto größer sollte das bereits vorhandene Angebot
5
2 Analyse
sein, um eine ausreichende Treffermenge für typische Anfragen zu erhalten.
Abbildung 2.1 Suchmaske - www.stellenmarkt.de
2.2.2 Regionale Stellenmärkte
Regionen werden hier als Einzugsgebiet einer Großstadt, eines Landkreises oder gar
eines ganzen Bundeslandes verstanden. Diese Märkte beinhalten typischerweise
weniger Angebote als überregionale Angebote. So hat ein Berliner Stellenmarkt4 zum
Beispiel etwa 2000 Stellenangebote in seinen Datenbeständen. Die Suche gestaltet
sich einfach und unkompliziert. Eine Einschränkung der Suche über viele Attribute
bietet sich bei 2000 Angeboten nicht mehr an. Bei angenommener Gleichverteilung
einer Suche über einer Menge an Berufsfeldern, die für den Stellenmarkt angegeben
wurden, werden noch überschaubar viele Ergebnisse geliefert. Dennoch gibt es auch
dort eine Möglichkeit zur Volltextsuche, um speziellere Anfragen zuzulassen. (vgl. )
Da KLinform ebenfalls zu den regionalen Angeboten gehört, ist mit einem
Angebotsvolumen zu rechnen, das sich mit einer einfacher gestalteten Suche
ausreichend durchsuchen lässt.
4 http://www.berlin-job.de
6
2 Analyse
Abbildung 2.2 Suchmaske - www.berlin-job.de
2.2.3 Branchenspezifische Stellenmärkte
Ihre Spezialisierung liegt auf dem Gebiet der Berufsrubriken. So könnte sich zum
Beispiel im Raum Frankfurt ein Stellenmarkt für Fachkräfte aus der Finanzwirtschaft
anbieten. Für KLinform ist dieser Aspekt nicht interessant, da der Stellenmarkt zwar
nach verschiedenen Rubriken unterscheiden könnte, sich aber keinesfalls auf eine
Sparte festlegen darf. Ein Blick in eine Suchmaschine offenbart auf Anhieb einige
solcher Angebote.5
2.2.4 Informationsbereitstellung
Viele Unternehmen, Institutionen und Einrichtungen stellen Angebote für Stellen
direkt in ihre eigenen Webpräsenzen ein. Dies ist allerdings nicht mehr als
Stellenmarkt in dem hier zu betrachteten Fall zu verstehen. Die Suche nach solchen
Angeboten gestaltet sich aufwändig und führt meist nur bei gezielten Wünschen zum
Ziel.
2.2.5 Ausrichtung
Von nun an soll, wenn von einem Stellenmarkt gesprochen wird, der zu
5 http://www.jobperspektive.de/branchen.html
7
2 Analyse
implementierende Stellenmarkt in KLinform gemeint sein. KLinform als regional
ausgerichtetes Portal impliziert einen regionalen Stellenmarkt. Aus diesem Grund
kann eine Suchfunktion für den Stellensuchenden nur über wichtige Bereiche
gestaltet werden. Der Benutzer soll dennoch die Möglichkeit erhalten, alle wichtigen
Angaben zu einem Stellenangebot angeben zu können (Arbeitgeber), sowie auch
anzuschauen (Arbeitssuchender).
2.3 Attribute einer Anzeige
Eine grundlegende Orientierung für ein Internet-Stellenangebot im Portal bietet die
Analyse von Stellenanzeigen herkömmlicher Printmedien.
Ein solches Angebot kann in drei Bereiche aufgeteilt werden.
2.3.1 Stellenbeschreibung
Grundsätzlich ist der Typ des Angebots von Interesse. Hierbei handelt es sich um die
Angabe einer der drei Arten Praktikumsplatz, Ausbildungsplatz oder Arbeitsstelle
(s.2.1). Diese Angabe ist notwendig.
Das Berufsfeld und die Branche sind zusammen für die Mengenbildung von
Angeboten wichtig, da eine Vorauswahl aus den Angeboten vorgenommen werden
kann. Im Folgenden soll dies als Rubrik bezeichnet werden. Ihre Angabe ist
erforderlich. Für nicht einzuordnende Stellen ist eine Rubrik "Sonstige" vorzusehen.
Weiter charakterisierend ist eine Klassifizierung nach der Arbeitszeit, bzw. dem
Arbeitsverhältnis. Viele Menschen nehmen ihre Tätigkeit nicht mehr nur als
klassischen Vollzeitjob wahr, sondern oftmals bedingt durch familiäre Gründe nur als
Teilzeitarbeitende oder freie Mitarbeiter. Nebenjobs sind zahlreich vorzufinden und
können somit als eigenständige Gruppe angesehen werden.
Die Stellenbezeichnung ist von zentraler Bedeutung, da sie auf den ersten Blick eine
vorläufige Bewertung der Relevanz einer Stelle zulässt. Ihre Angabe ist ebenfalls
erforderlich.
Die Beschreibung der Aufgabengebiete des Arbeitnehmers ist von großem Interesse,
da es den Beruf in der Tätigkeit konkretisiert. Dies kann vom Benutzer frei
angegeben werden, da sehr differenzierte Angaben gemacht werden können. Ihre
Angabe sollte jedoch als zwingend erachtet werden, da eine Konkretisierung der
Stelle in den meisten Fällen sehr hilfreich für den Arbeitssuchenden ist.
8
2 Analyse
Weitergehende
Arbeitnehmer
Informationen
am
können
Arbeitsplatz
Weiterbildungsmöglichkeiten,
das
trifft
Umfeld
oder
Arbeitszeiten,
die
betreffen,
auf
Vergütung
Einsatzorte,
das
der
der
Arbeit,
Aufstiegschancen,
Vergünstigungen und Dauer der Arbeit. Kurzum alles, was der Arbeitgeber an
Beschreibungen
zur
Stelle
Ausgestaltungsmöglichkeiten
Zusammenfassung
all
dieser
angeben
möchte.
solcher
Informationen
Informationen
Aufgrund
als
der
wird
"Weitere
vielfältigen
hier
eine
Informationen"
vorgenommen. Diese Angaben sind optional.
2.3.2 Informationen zum Arbeitgeber
Sofern sie nicht den Tätigkeitsbereich des Arbeitnehmers umfassen, lassen sich hier
noch Ansprechpartner, die in großen Betrieben für bestimmte Personalbereiche
zuständig sind, die Identifikation des Arbeitgebers (Anschrift und Name der Firma),
Telefon, Telefax, E-Mail und Web-Adresse nennen, wovon lediglich die Identifikation
des Arbeitgebers zwingend für die Kontaktaufnahme erforderlich ist und die übrigen
Angaben als optional zu betrachten sind.
2.3.3 Angaben zum Arbeitnehmer
In erster Linie ist die Ausbildung oder der Schulabschluss von Interesse. Weitere
Angaben betreffen Anforderungen verschiedenster Art an den Kandidaten, die
soziale Fähigkeiten, fachbezogenes Spezialwissen, Motivation, Einsatzwillen und
weitere
Aspekte
umfassen,
die
der
Arbeitgeber
für
ein
reibungsloses
Zustandekommen und Vollziehen des Arbeitsverhältnisses als erforderlich erachtet.
Auch dieser Bereich wird zusammengefasst, da er viel Spielraum zu Ausgestaltung
durch den Inserenten zulässt.
Die Attribute eines Stellenangebotes, die teilweise sehr spezifisch, teilweise aber
auch
optional
oder
nicht
weiter
festgelegt
sind,
also
dem
Benutzer
Wahlmöglichkeiten hinsichtlich der Angaben lassen, sind somit festgelegt.
2.4 Funktionalität
Nun werden für das in 2.3 aufgespannte Feld von Attributen die operativen
Möglichkeiten angegeben werden. Es handelt sich um Aspekte der Benutzerführung
durch das Angebot, der Suchfunktion für die Angebote, Verwaltungsmöglichkeiten
9
2 Analyse
des Benutzers und Administrators, internen Datenmanagements und Funktionen, die
im Rahmen der Personalisierung möglich sind.
2.4.1 Vorgaben durch KLinform
Dem Benutzer ist durch Dateien, die in allen Seiten einzufügen sind, ein Rahmen
bezüglich umgebender Menüstruktur, Erscheinungsbild und benutzerspezifischer
Funktionalität gegeben. Unter Menüstruktur ist die Auswahlmöglichkeit des
Benutzers für die verschiedenen Bausteine von KLinform zu verstehen. Das
Erscheinungsbild ist zum Beispiel durch eine Kopfleiste und insbesondere den
Stylesheets geprägt. Hier muss erwähnt werden, dass KLinform Vorraussetzungen
an den Browser eines Besuchers der Seite stellt. Dies ist momentan Netscape in
Version 6 und, bezüglich des Standes der Implementierung von Web-Standards,
ähnliche Browser.
KLinform bietet bereits Funktionen, die für einen Stellenmarkt benötigt werden. Die
Registrierung von Benutzern, Verwaltung ihrer Daten und ein Schnellzugriffsmenü
sind bereits integriert, so dass der Stellenmarkt insbesondere auf die Login- und
Registrierungsfunktion zurückgreifen kann. Die Identifizierung eines Benutzers ist
nötig, damit ein Angebot einem Benutzer zugeordnet werden kann. Eine Firma, die
eine Stellenanzeige schalten möchte, muss sich vorher bei KLinform registrieren.
2.4.2 Benutzerführung
Der Stellenmarkt soll folgende Funktionen besitzen:
–
Inserieren von Angeboten
–
Verwaltung von Angeboten
–
Suche im Datenbestand
–
Personalisierung
–
Administration
2.4.3 Suchfunktion
Ausgehend von der These, dass es sich aufgrund der Regionalität um einen
Stellenmarkt
von
begrenztem
Angebotsaufkommen
handelt,
werden
dem
Arbeitssuchenden vier Möglichkeiten zur Einschränkung einer Suche angeboten. Er
grenzt das Gesamtangebot anhand von Jobtyp, Rubrik, Arbeitsverhältnis und einer
Suche mittels eingegebenem Begriff ein. Die Präsentation der Suchangabe erfolgt
10
2 Analyse
zweistufig. Es wird bei Treffern zuerst nur eine Übersicht anhand wichtiger Merkmale
angeboten. Über Verweise erfolgt dann die eigentliche Detailansicht aller Angaben
zu einem ausgewählten Eintrag.
2.4.4 Verwaltung
Ein Benutzer kann hier seine eigenen Einträge verwalten. Dazu gehört das
Verändern von Attributen, Löschen von Einträgen und eine Verlängerungsmöglichkeit
seitens des Inserenten, falls sich zum Beispiel kein geeigneter Kandidat für die Stelle
gefunden hat. Das Verändern der Attribute erfolgt innerhalb der gleichen
Eingabemaske wie bei einem Neueintrag, um die Bedienbarkeit zu erleichtern.
Löschen und Verlängern sind mittels zweier Icons zu realisieren, die beim Anklicken
die gewünschte Aktion starten.
2.4.5 Administration
Ein dem System als Administrator des Stellenmarktes angegebener Benutzer erhält
die Möglichkeit, einzelne Einträge direkt per Web-Interface zu löschen. Er soll hierbei
selektiv nach Rubrik und/oder Benutzer gefundene Einträge angezeigt bekommen.
Komplexere Möglichkeiten der Verwaltung werden nicht implementiert, das einfache
Löschen dient in erster Linie der Elimination von Einträgen, die ein Benutzer ohne
ernste Absichten eingefügt hat.
2.4.6 Datenmanagement
Alle Einträge sind mit einem Enddatum zu versehen, das vom System mittels einer
Systemvariablen, die in einer Konfigurationsdatei abgelegt ist, ermittelt wird. Das
System überprüft regelmäßig, ob ein Eintrag bald ausläuft und informiert den
Inserenten rechtzeitig per Email. Er erhält die Möglichkeit, den Eintrag um eine
gewisse Zeitspanne zu verlängern, die ebenfalls in einer Systemvariablen abgelegt
ist. Das System überprüft bei der Eingabe von Daten deren Plausibilität und
Korrektheit unter einigen Gesichtspunkten. Nicht-optionale Attribute müssen
angegeben werden. E-Mail Adressen und Webadressen werden auf syntaktische
Korrektheit
geprüft.
Nur
registrierte
Benutzer
erhalten
die
Möglichkeit,
Veränderungen jedweder Form an den Daten vorzunehmen. Dies stellt sicher, dass
kein Dritter die Einträge anderer ändern kann.
2.4.7 Personalisierung
Der Arbeitssuchende erhält die Möglichkeit, ein Stellenprofil anzugeben. Anhand
11
2 Analyse
dieses Stellenprofils wird zu fest gegebenen Zeitintervallen der Datenbestand
durchsucht. Suchtreffer werden dann dem Benutzer per Email zugesandt, woraufhin
er sich die betreffenden Angebote anschauen kann. Der Benutzer muss hierzu
registriert sein und eine Email-Adresse angegeben haben. Angebote, über die der
Benutzer bereits informiert wurde, werden ihm nicht erneut zugeschickt. Für die
Stellenprofile sind wie für die Stellenangebote Möglichkeiten zur Verlängerung,
Veränderung
und
Löschung
vorzusehen.
Ebenso
erfolgt
auch
hier
eine
Benachrichtigung über bald ablaufende Profile, die ebenfalls alle mit einem
Gültigkeitsstempel per Systemvariablen versehen werden.
2.5 Zusammenfassung
Nachdem ein grober Überblick über bestehende Stellenmärkte gewonnen werden
konnte,
sowohl
wichtige,
als
auch
optionale
Attribute
zu
einer
Anzeige
zusammengestellt und schließlich die Fähigkeiten des Stellenmarktes konkretisiert
wurden, wird nun auf die Konzepte, Techniken und Komponenten eingegangen, mit
denen der Stellenmarkt realisiert wird.
zeigt noch einmal die Komponenten des Stellenmarktes.
Suchfunktion
Angebot inserieren
Angebote verwalten
Arbeitgeber
Suchprofil angeben
Suchprofile Verwalten
Personalisierung
Arbeitssuchender
Administration
Administrator
Abbildung 2.3 Komponenten des Stellenmarktes
12
3 Komponenten und Techniken
3 Komponenten und Techniken
Sie bilden die Grundlage, um den Entwurf in die Praxis umzusetzen. Alle
verwendeten Techniken und Komponenten sind von KLinform vorgegeben und
werden nun in Vorbereitung der Entwurfsphase vorgestellt. Auf konkrete Entwürfe
und Implementierungen aus dem Stellenmarkt soll hier noch nicht eingegangen
werden.
3.1 Datenbanksysteme
Ein Datenbanksystem (DBS), gemeinhin als Datenbank bezeichnet, besteht aus der
Datenbank (DB) und dem Datenbankmanagementsystem (DBMS). Hierbei enthält
Erstere die eigentlichen Daten. Das DBMS realisiert die Verwaltung und den Zugriff
auf die Daten, die langfristig gespeichert werden sollen. [HÄRDER 1999] Das
Datenbanksystem soll einen hohen Grad der Datenunabhängigkeit aufweisen. Dies
bedeutet, dass unabhängig von der Art der Daten die Handhabung gleich ablaufen
soll. Ein DBS gewährleistet einen sicheren Mehrbenutzerbetrieb. Dies umfasst
sowohl die Kontrolle über die Zugriffsrechte auf Daten, wie auch die Absicherung
gegen mögliche Fehlerquellen wie gleichzeitiges Lesen und Schreiben eines
Datensatzes. Dies wird durch das Transaktionskonzept gewährleistet.
3.1.1 Transaktionsparadigma
Das Transaktionsparadigma definiert sich nach [HÄRDER 1999](7-2) wie folgt:
"Das Transaktionsparadigma befreit den DB-Anwendungsprogrammierer
von allen Aspekten des Fehlerfalls (failure transparency) und der
Nebenläufigkeit (concurrency transparency). Es erlaubt also eine
fehlerfreie Sicht auf die Datenbank im logischen Einbenutzerbetrieb."
Logischer Einbenutzerbetrieb heißt, dass keine nebenläufigen Transaktionen auf
gleichen Datensätzen konkurrierend operieren. Alle Aktionen, die als Transaktion
gekapselt sind, unterliegen weiterhin dem ACID-Prinzip. Es beschreibt die
Eigenschaften:
–
Atomicity: Eine Transaktion wird entweder ganz oder gar nicht durchgeführt;
niemals teilweise (selbst im Fehlerfall nicht)
13
3 Komponenten und Techniken
–
Consistency: Eine durchgeführte Transaktion beeinträchtigt nicht die Konsistenz
der
Datenbank.
(Konsistenz
bezeichnet
das
Einhalten
aller
definierten
Integritätsbedingungen)
–
Isolation: Ergebnisse einer Transaktion sind erst nach erfolgreicher Durchführung
sichtbar, keinesfalls aber Zwischenergebnisse.
–
Durability:
Nach
erfolgreich
durchgeführter
Transaktion
bleibt
diese
im
Datenbanksystem bestehen, unabhängig von dort auftretenden Fehlern.
Das Transaktionskonzept gewährleistet für Datenbanken, dass im vorliegenden Fall
des Stellenmarktes beim zu erwartenden Mehrbenutzerbetrieb stets eine korrekte
Sicht auf die Daten gewährleistet ist und keine inkonsistenten Zustände auftreten
können. Abgefangen wird auch der Fall, dass nebeläufige Transaktionen eines
Benutzers in Konflikt treten. Dies tritt durch die Anwendungslogik nur dann auf, wenn
ein Benutzer in zwei Sitzungen gleichzeitig DB-Operationen durchführt.
3.1.2 Relationales Datenmodell
Der Umsetzung von Daten in relationalen Datenbanksystemen liegt das relationale
Datenmodell zugrunde. Es basiert einzig auf der Datenstruktur der Relation. Sie wird
in Form einer Tabelle repräsentiert. Alle Informationen sind durch Werte dargestellt.
So sind zeilenweise die einzelnen Datensätze zu finden und spaltenweise die Werte
aller Datensätze zu einem Attribut. Um die Eindeutigkeit von Einträgen zu
gewährleisten, muss ein Primärschlüssel existieren. Er ist die kleinste Menge an
Attributen, die zusammen eine eindeutige Identifizierung eines Tupels (Datensatz)
gewährleisten. Gegebenenfalls muss ein künstlicher Schlüssel eingeführt werden. In
der Praxis sind dies sogenannte ID's, oft als fortlaufender Zähler realisiert. Soll eine
Beziehung zwischen mehreren Relationen realisiert sein, so wird ein Fremdschlüssel
in der Relation angegeben, der sich auf den Primärschlüssel einer anderen oder der
gleichen Relation bezieht.
zeigt
das
Beispiel
einer
Relation
mit
Primärschlüssel,
Attributen
und
Fremdschlüsseln.
14
3 Komponenten und Techniken
Firma
ID Name
Finanzamt
Amt ID
Ort
Name
1 Maurer Schmidt
1 München
1 München West
2 Maier Netzwerke
2 Augsburg
2 Augsburg
3 Maurer Schmidt
2 München
Primärschlüssel
Fremdschlüssel
Abbildung 3.1 Beispiel zu Relationen
3.1.3 SQL
Um mit Datenbanksystemen und den Daten in einer Datenbank arbeiten zu können,
bedarf es einer Datenmanipulations- und Datendefinitionssprache. Die weiteste
Verbreitung hat heute der in erster Version 1986 von ANSI akzeptierte
Sprachstandard SQL (Structured Query Language) für relationale Datenbanken. SQL
bietet umfangreiche Möglichkeiten zur Erstellung und Manipulation von Objekten.
Umfangreiche Dokumentationen lassen sich zum Beispiel auf den Internetseiten des
für die Projektarbeit verwendeten Datenbankmanagementsystems PostgreSQL
finden [POSTGRESQL]. Beispielhaft seien hier die Anweisungen für die Erstellung
zweier Tabellen mit Fremdschlüssel-Beziehung und einer Anfrage auf beide Tabellen
in SQL gegeben.
CREATE TABLE Student (
id INT NOT NULL,
name TEXT NOT NULL,
PRIMARY KEY (id) );
CREATE TABLE Projekt (
id INT NOT NULL,
kandidat INT NOT NULL,
betreuer INT NOT NULL,
projektname TEXT NOT NULL,
beschreibung TEXT NOT NULL,
bemerkungen TEXT,
beginn DATE NOT NULL,
guelt DATE,
PRIMARY KEY (id),
FOREIGN KEY (kandidat) REFERENCES Student(id),
FOREIGN KEY (betreuer) REFERENCES Student(id) );
SELECT Student.name
FROM Student, Projekt
WHERE Projekt.kandidat=Student.id;
Abbildung 3.2 SQL Beispiel
Die Tabelle
Student
speichert einen Namen, der später ausgegeben werden soll. Die
Ausgabe sucht den Namen aus
Student,
dessen zugehörige
id
gleich dem
15
3 Komponenten und Techniken
Fremdschlüssel (kandidat) von
die Datenbank, ob
kandidat
Projekt
als
id
ist. Beim Eintragen eines Tupels in
in
Student
überprüft
bereits vorhanden ist, sonst gibt sie eine
Fehlermeldung zurück. Alle Spalten, die als
Eintragen mit einem Wert belegt sein.
Projekt
NOT NULL
PRIMARY KEY
und
definiert sind, müssen beim
SECONDARY KEY
sind sogenannte
Constraints. Weitere Constraints können Einschränkungen von Definitionsbereichen
oder zum Beispiel Vergleiche zweier Spalten beinhalten.
3.1.4 Schnittstelle - JDBC, Poolmanager
Grundsätzlich besteht die Durchführung einer Datenbankoperation aus drei Schritten.
Es wird eine Verbindung zu einer lokalen oder entfernten Datenbank geöffnet, die
Befehle (in SQL) abgegeben und die Verbindung wieder geschlossen. Der Zugriff auf
die Datenbank kann über ein Kommandozeilentool geschehen, eine eigene
graphische Oberfläche oder Schnittstellen für verschiedenste Programmiersprachen.
Für Java ist dies das JDBC-API aus dem Paket
java.sql
(seit Version 1.1). Da Java
plattformunabhängig ist, ist dies auch JDBC. Um eine Verbindung per JDBC auf die
Datenbank zu erlauben, muss sie über einen entsprechenden JDBC-Treiber
verfügen.
KLinform setzt weiter einen sogenannten Poolmanager ein. Das Öffnen und
Schließen einer Verbindung für je eine Anfrage an die Datenbank erzeugt einen
erheblich größeren Aufwand als ständig je nach Bedarf einen "Pool" von
Verbindungen offen zu halten, die mehrfach benutzt werden können. Eine
Verbindung von einer Java-Applikation herunter bis zu einer Datenbank zeigt
in
Anlehnung an [Java pro 1999].
Ein Verbindungsaufbau zur Datenbank besteht schließlich aus dem schlichten Aufruf
getConnection();.
Die zu implementierende Klasse erweitert eine in KLinform bereits
bestehende Klasse AbstractDatabase, die diese Funktionalität gewährleistet.
16
3 Komponenten und Techniken
Java Applikation
mit Poolmanager
JDBC−API
DriverManager
Poolman JDBC−Driver
ohne Poolmanager
Connection Pool
JDBC−Treiber
DBMS
DB
JDBC−Treiber
DBMS
DB
DB
DB
Abbildung 3.3 JDBC Verbindung zur Datenbank
3.2 MVC-Konzept
Das Model-View-Controller Konzept (MVC) beschreibt eine Aufsplittung eines
Teilsystems in 3 Komponenten, die interagieren und wurde ursprünglich mit
Smalltalk80 eingeführt [Turau 2001]. Das Model-Objekt beinhaltet den internen
Zustand einer Komponente, sowie alle Informationen über die Anwendung und alle
darzustellenden Daten [Java pro 1999]. Die View ist für die Darstellung der Daten
aus dem Model-Objekt zuständig. Der Controller reagiert auf Eingaben des
Benutzers.
Er
leitet
Daten
an
das
Modelobjekt
und
informiert
es
über
vorzunehmende Änderungen. Somit sind Daten, Präsentation und Bearbeitung
voneinander getrennt. Durch die Trennung von Daten und Präsentation ist
gewährleistet, dass das Erscheinungsbild an nur einer Stelle verändert werden muß.
Gleiches gilt für den Controller, der zentral die Abläufe steuert. Änderungen am
Ablauf können an ihm vorgenommen werden. Sofern sich die Schnittstellen des
Model-Objektes nicht ändern, kann die interne Repräsentation der Daten verändert
werden, ohne dass View oder Controller verändert werden müssten. So lässt sich
zum Beispiel die Umstellung auf eine effizientere Datenstruktur oder schnellere
17
3 Komponenten und Techniken
Methode an einer Stelle realisieren. Dies ist bei der Verflechtung der drei
Komponenten oder einer Erweichung des Konzepts meist nicht mehr möglich.
Das MVC Konzept wird in KLinform auf Seiten des Models mittels Java-Beans
umgesetzt. Die Controller und View-Objekte sind mit Java Server Pages (JSP)
realisiert. Sie werden im Servlet Container Tomcat des Apache Jakarta Projects
eingesetzt. In der View werden HTML-Formulare benutzt, die Benutzereingaben
entgegennehmen. Sie sind als die Präsentation der Tastatureingabe anzusehen,
während die Bearbeitung der eingegebenen Daten dem Controller Objekt obliegen,
welches die Daten übermittelt bekommt. Auf diese Weise ist eine Trennung der
Objekte gewährleistet und das MVC Konzept realisiert. veranschaulicht noch einmal
das zugrunde liegende MVC Konzept.
View
JSP
Controller
JSP
Model
Java Bean
Abbildung 3.4 MVC Konzept (konkretisiert)
3.3 Java Server Pages
Sie sind, wie der Name schon sagt, auf Seiten des Webservers zu finden. Java
Server Pages (JSP) integrieren Java Beans als Komponenten in Webseiten und sind
syntaktisch Java-Code in Verbindung mit HTML.
Eine Seite hat die Struktur einer HTML Seite mit eingebetteten JSP Anweisungen,
wobei kein HTML-Code vorhanden sein muß. Diese Anweisungen kontrollieren oder
beeinflussen die Ausgabe, wie auch die ablaufenden Aktionen. Eine JSP Seite wird
übersetzt in den Bytecode eines Java-Servlets. Sie laufen als Service auf einem Web
Server ab; im vorliegenden Fall in Tomcat. Ihre Ausgabe wird an den Client
weitergeleitet. Eine JSP-Seite könnte beispielhaft so aussehen:
18
3 Komponenten und Techniken
<html>
<head>
<title>Hello World</title>
</head>
<body bgcolor="#FFFFFF">
<jsp:useBean id="mytestclass" scope="page" class="test.class">
<jsp:setProperty name="mytestclass" property="text" value="Hello World"/>
</jsp:useBean>
<% String myString = mytestclass.getText();
if (mystring.length() > 0)
out.print("<h1>"+mystring+"</h1>");
else out.print("Hello World not found!");
%>
</body>
</html>
Abbildung 3.5 JSP Beispiel
In diesem Beispiel wird die Verwendung einer Bean gezeigt, die über eine getMethode für die Property text verfügt. Eine Dokumentation zu JSP ist auf den
Dokumentationsseiten der Firma Sun Microsystems zu finden [JSP Docs]. Java
Server Pages sind portabel, insofern sich Entwickler an einen Standard halten und
die betroffenen JSP Server diesen Standard einhalten und implementieren.
3.4 Java - Beans
Java Beans ist die Realisierung einer Software-Komponententechnologie
für Java. ... definiert Sun Beans als wiederverwendbare Software-Einheiten,
die mit einem visuell arbeitenden Tool zu größeren Software-Paketen oder
Programmen zusammengesetzt werden können.
[Java pro 1999](S.799)
Es existieren lediglich Anforderungen an Java Beans, die als Anweisungen
verstanden werden, um mit visuellen Tools zusammenarbeiten zu können. Für die
vorliegenden Zwecke in Bezug auf die Verknüpfung von Beans mit JSP ist es primär
von Interesse, dass es zu jeder Property (Attribut) ein Paar von public-Methoden gibt.
Properties sind nach außen sichtbare Eigenschaften. Dies können primitive
Datentypen oder Klassen sein. Für jede solche Property gibt es eine get- und eine
set- Methode, über die die Properties abgefragt werden können. Die einfachste Form
einer Bean könnte so aussehen:
19
3 Komponenten und Techniken
package own.beans;
public class MyId {
int id=0;
public void setId(int x) {
this.id=x;
}
public int getId() {
return this.id;
}
public boolean validate() {
return true;
}
}
Abbildung 3.6 Beispiel einer Bean
In den Java Server Pages wird auf eben diese Methoden zurückgegriffen. Dies
geschieht nach der Einbindung mittels useBean über zwei äquivalente Konstrukte:
<jsp:useBean id="testbean" scope="page" class="own.beans.MyId.class" />
<jsp:getProperty name="testbean" property="id"/>
oder <%= testbean.getId() %>
Somit ist das Grundkonzept und die Verknüpfung von JSP und Java Beans in den
wichtigsten Zügen dargestellt.
3.5 Apache Jakarta Project - Tomcat
Tomcat ist der verwendete Servlet Container. Er steht unter der Apache Software
License [Apache License] und ist somit ein Open Source Projekt, an dem jeder
partizipieren kann. Er stellt die offizielle Referenzimplementierung der Java Servlet
und Java Server Pages Spezifikationen von Sun Microsystems dar [Jakarta-Tomcat].
Tomcat läuft als selbstständiger Webserver oder als Modul eines anderen
Webservers (Apache, IIS, Netscape Server). Als Modul liefert der Webserver die
statischen Seiten an den Client und leitet Servlet Requests an Tomcat weiter.
Tomcat liegt mittlerweile in Version 5 vor. KLinform setzt momentan Version 4 ein,
während die Entwicklung dieser Projektarbeit auf Tomcat-3.2.4 entstand.
3.6 Ablauf
Zusammenfassend sei noch einmal der Ablauf, der mit den vorgestellten
20
3 Komponenten und Techniken
Komponenten durchgeführt werden soll, dargestellt.
Die abzubildenden Daten werden mit dem Relationenmodell modelliert. Dieses wird
mit SQL-Anweisungen in die Datenbank übertragen. Die entstandenen Tabellen sind
evtl. noch mit festen Einträgen zu versehen. Die für den Benutzer zu bearbeitenden
Daten
sind
mit
Beans
über
JDBC
und
den
Poolmanager
für
den
anwendungsgerechten Zugriff aufzubereiten. Abgesehen von den get- und setMethoden sind je nach Anwendungszweck weitere Methoden zu implementieren, auf
die aus den JSP-Seiten heraus zugegriffen werden kann. Die Präsentation ist in View
Komponenten zu gestalten, die Anwendungslogik in Controller-Objekten. Es gibt
mehrere
Controller-Objekte,
die
für
jeweils
einen
Anwendungsfall
des
Gesamtsystems zuständig sind.
Im folgenden Kapitel wird nun der Entwurf des Stellenmarktes für KLinform
durchgeführt und anhand wichtiger Teile diskutiert.
21
4 Konzeptioneller Entwurf
4 Konzeptioneller Entwurf
In diesem Kapitel wird die Struktur auf den verschiedenen Ebenen festgelegt werden,
ohne auf Details der Implementierung einzugehen.
4.1 Datenbank Schema
Anhand eines Entity-Relationship Diagramms wird das Datenschema entworfen.
–
Entity "Rubrik": Enthält die Berufsfelder und -branchen
–
Entity "Jobtyp": Enthält die verschiedenen Jobtypen (s.S. 4)
–
Entity "Arbeitsverhältnis": Enthält die Beschäftigungsverhältnisse
–
Entity
"Angebot":
Enthält
ein
komplettes
Angebots-Objekt,
Relationships
(Beziehungen) zu den Personen zur Identifizierung des Inserenten, zur Rubrik für
das Berufsfeld und zum Jobtyp zur Charakterisierung
–
Entity "Suche": Enthält die Suchprofile zur Durchführung einer benutzerorientierten
Datenbestandsanalyse; Referenzen auf den zu informierenden Benutzer, sowie
den Jobtyp
–
Entity "Person": Bereits in KLinform vorhanden, Beziehungen von Angebot und
Suche auf Person vorhanden
KLinform
Stellenmarkt
inseriert
1
1
Person
inseriert
n
n
Suche
ist
n
Angebot
1
n
n
n
Rubrik
1
Arbeitsverhältnis
ist
1
Jobtyp
ist
1
ist
Abbildung 4.1 Entity Relationship Diagramm
Einem Angebot sind je genau ein Benutzer, eine Rubrik, ein Arbeitsverhältnis und ein
22
4 Konzeptioneller Entwurf
Jobtyp zugeordnet. Gleiches gilt für die Entity Suche, der nur je ein Benutzer und
Jobtyp zuzuordnen sind. Von Rubrik, Arbeitsverhältnis und Jobtyp können je 0..n
Beziehungen zu Angeboten oder Suchprofilen bestehen. Somit ergibt sich das ERDiagramm aus Abbildung 4.1.
4.2 Benutzerführung
Die Umsetzung des MVC Konzeptes gestaltet sich durch einen Ablauf von
Controllern und Views. Alle Beans, die für eine Sitzung benötigt werden können,
sollen per
<useBean...>
<...scope="session"...>
eingefügt werden. Die angeforderten Beans werden per
für die ganze Session eines Benutzers zur Verfügung gestellt.
Meldet sich der Benutzer ab, erlischt seine Session. Ausnahme bildet eine separate
Bean für alle Datenbankoperationen, sie wird mit dem Attribut
<...scope="application"...>
geladen und steht somit, einmal geladen, für alle JSP-Seiten des Stellenmarktes zur
Verfügung. Alle notwendigen Java Pakete werden per
in einer
include-Datei
<%@ page import="paket.*" %>
zur Verfügung gestellt, wie etwa im Header der Seite. Der
Einstieg in den Stellenmarkt geschieht mit der Präsentation der verschiedenen
Aufgabenbereiche "Profile inserieren und verwalten", "Suche", "Angebote inserieren
und verwalten", sowie der "Administration". In Abhängigkeit davon, ob der Benutzer
angemeldet ist, wird nur die Suche und Verweise auf die weiteren Möglichkeiten
angeboten. Hat der Benutzer bereits Einträge vorgenommen, erscheinen die
Verweise auf die Verwaltungsseiten seiner Einträge. Ist der Benutzer Administrator
des
Stellenmarktes,
erscheint
auch
der
Verweis
auf
die
entsprechende
Administrationskomponente. Dies kann als Aspekt der Personalisierung nach
Benutzerklassen betrachtet werden, da bestimmte Angebote nur nach Bedarf
beziehungsweise Autorisation eingeblendet werden. Die Hauptseite gestaltet das
Menü für den Umgang mit dem Stellenmarkt. Von jedem der Punkte wird ein
Wechsel von Controller und View-Seiten begonnen, die jeweils Möglichkeiten der
Benutzereingabe präsentieren (View) und diese bearbeiten bzw. auswerten
(Controller). Im Controller wird die eigentliche Logik eines Anwendungsteils
implementiert. Er verzweigt je nach Situation auf weitere Controller, eine
Erfolgsmeldung bei einer Datenbankänderung und zurück zum Hauptmenü. Sofern
der Benutzer Angaben in einer Maske machen muss, überprüft der Controller diese
nach Möglichkeit auf Plausibilität oder Vorhandensein bei Pflichtangaben.
23
4 Konzeptioneller Entwurf
Nun soll in einer Übersicht für jeden der Anwendungspunkte der Ablauf skizziert
werden.
4.2.1 Suche
Die Suche erfolgt mittels Eingabe von Jobtyp, Rubrik, Arbeitsverhältnis oder
Suchbegriff und ihrer Bearbeitung. In der View soll eine Übersicht mit Kurzeinträgen
präsentiert werden, sowie jeweils ein Verweis auf detailliertere Informationen:
Menü
Controller
Eingabe von
Typ/Rubrik/Begriff
View
detail
Controller
Abbildung 4.2 Ablauf "Suche"
4.2.2 Angebot, Suchprofil inserieren/verwalten
Der Controller gibt Rückmeldungen nach schon erfolgten Eingaben über falsche oder
fehlende Eingaben an die View zurück. Wurden Verbesserungen an ihnen
vorgenommen und der Eintrag validiert, kann der Datensatz in die Datenbank
übernommen werden. Daraufhin wird an eine "OK-Seite" verwiesen, die dem
Benutzer die erfolgreiche Datenaufnahme mitteilt. Von dort gelangt der Benutzer
wieder ins Hauptmenü.
24
4 Konzeptioneller Entwurf
Menü
Controller
OK−Seite
evtl. Rückmeldung
falscher Angaben
Eingabe der
Attribute
View
Abbildung 4.3 Ablauf "Inserieren"
4.2.3 Einträge verwalten
In der View werden alle Einträge des angemeldeten Benutzers angezeigt. Dies gilt
(getrennt) für Suchprofile, wie auch für Stellenangebote. Für jeden Eintrag erhält der
Benutzer die Möglichkeit, ihn zu löschen (der Controller ruft eine Methode aus dem
Datenbank-Bean auf), oder den Eintrag zu editieren (es wird auf die Inserieren-Seite
mit vordefinierten Werten verwiesen), oder den Eintrag zu verlängern, falls (und nur
dann) er innerhalb einer per Systemvariablen vorgegebenen Zeit abläuft. Zusätzlich
wird die Möglichkeit der Detailansicht der angezeigten Angebote, sowie auch eines
Neueintrags geboten, um den Komfort zu steigern.
Menü
Controller
(wieder) anzeigen
detail
Controller
Anweisung für
Löschen oder
Editieren
Link zu Details
View
inserieren
Controller
Link auf Inserieren−
Seite
Abbildung 4.4 Ablauf "Verwaltung"
25
4 Konzeptioneller Entwurf
4.2.4 Administration
Die Administration steht nur dem Administrator zur Verfügung. Er kann alle Angebote
nach Benutzer oder Rubrik sortiert auflisten. Diese Einträge stehen ihm dann zum
Löschen zur Verfügung. Der Ablauf ist der gleiche wie bei der Suche, da Einträge
nach Kriterien sortiert angezeigt werden, lediglich die Möglichkeit des Löschens
unterscheidet sich hier prinzipiell von der normalen Suche.
4.3 Beans, Cronjobs
Es existieren drei Arten von Beans für die Realisierung. Zum einen gibt es das
Applikations-Bean (scope="application") für alle Datenbankoperationen und Objekte.
Zum zweiten existiert für jeden Anwendungsteil eine Bean, die alle Attribute des
jeweiligen Teils in Form von Properties bereit hält.
Weiter soll eine Klasse existieren, die, täglich aufgerufen, die Benutzer über Treffer in
der Datenbank bezüglich ihrer Suchprofile informiert.
Alle Einträge sind mit einem Gültigkeitsdatum per Addition einer Systemvariablen
zum momentanen Datum zu versehen. Ablaufende Einträge sind wenige Tage vor
Ablaufen dem Inserenten mitzuteilen und im Falle der Nicht-Verlängerung seitens
des Benutzers aus der Datenbank zu entfernen. Hierauf wird nicht weiter
eingegangen, da diese Funktionalität bereits in KLinform vorhanden ist und somit
direkt genutzt werden kann.
4.4 Sicherheit
Sicherheit spielt bei der Entwicklung eines Portals eine große Rolle. Java Server
Pages an sich bilden eine erste Sicherheitsinstanz. Da alle dynamischen Teile des
Angebots serverseitig ausgeführt werden, hat der Benutzer keine Möglichkeit, in den
vorgegebenen Ablauf einzugreifen. Da der Ablauf zwischen den einzelnen JSPSeiten oftmals über URL-Rewriting erfolgt, müssen seitens der Datenbank-Bean
Sicherheitsmaßnahmen ergriffen werden, um unbefugtes Eintragen von Angeboten
oder Profilen zu verhindern. Eine Prüfung des Benutzers seitens des Controllers und
der Bean ist immer dann sinnvoll, wenn Daten manipuliert werden sollen. Der
Benutzer kann und darf nur dann Veränderungen an seinen eigenen Datensätzen
durchführen, wenn er sich dem System gegenüber durch die Login-Komponente
26
4 Konzeptioneller Entwurf
identifiziert hat. Gleiches gilt für die Aufbereitung von Daten auf der View-Seite. Es
dürfen bei der Verwaltung nur Daten präsentiert werden, die der Benutzer selbst
eingestellt hat. Weitere Sicherheitsmaßnahmen betreffen das Überschreiben
vorhandener Einträge, insofern es die Identifikation eines Eintrages betrifft. Realisiert
wird dies durch einen fortlaufenden Zähler auf Seiten der Datenbank, der neue IDs
für neue Einträge erzeugt (ID ist Primärschlüssel für Angebot und Suchprofil).
verdeutlicht die Schichten des Schutzkonzeptes noch einmal.
Wichtig ist die Benutzerprüfung seitens der Logik, die die Controller implementieren.
Es existiert im System implizit ein Objekt user, es wird verwendet, um die Identität
des per Client angebundenen Benutzers festzustellen.
evtl. Benutzerprüfung
Plausibilitäts und Benutzerprüfung
View X
Controller Y
DB−Bean
Benutzerprüfung
bei DB−Änderung
Abgleich mit
eingetragenen
Benutzern
DBS
Abbildung 4.5 Sicherheitsebenen
27
5 Implementierung
5 Implementierung
In diesem Kapitel sollen wichtige Implementierungsbereiche, teilweise anhand von
ausgesuchten Beispielen, erörtert werden.
5.1 Datenbank
Das Entity Relationship Diagramm wird in das Relationenmodell, welches als direkte
Grundlage für das Datenschema in der Datenbank zu benutzen ist, überführt. Die
von
der
Entität
Angebot
ausgehenden
Beziehungen
zu
Person,
Rubrik,
Arbeitsverhältnis und Jobtyp sind n:1 Beziehungen (ein Jobtyp kann in mehreren
Angeboten auftreten; ein Angebot hat genau einen Jobtyp). Sie werden als Attribut in
Angebot umgesetzt. In der Datenbank sind sie dann als Fremdschlüssel auf die
entsprechenden Attribute anderer Tabellen realisiert. Die übrigen Attribute sind
Kapitel 2.3 zu entnehmen. Als Datentyp wird meist TEXT verwendet, da dies die
Möglichkeiten der Datenaufnahme nicht mit einer fest vorgegebenen Länge für die
Eingabe einschränkt und im Zusammenhang mit mehrzeiligen Eingabefeldern diese
als einzelnes Attribut abgelegt werden können.
Die IDs bilden die Primärschlüssel zu den Relationen und werden mit der bereits in
KLinform vorhandenen Methode getNextID() generiert. Diese Realisierung gewährleistet,
dass eindeutige IDs für die einzutragenden Tupel vergeben werden.
Alle Suchprofile und Angebote sind mit einem Gültigkeitsstempel versehen. Dieser
wird nicht datenbankseitig überprüft, sondern von einer per Cronjob aufgerufenen
Methode. Dies ist erforderlich, da die Benutzer die Möglichkeit erhalten sollen,
Einträge zu verlängern und dies mit einer Java-Methode leichter durchzuführen ist.
Nicht zuletzt bietet KLinform bereits entsprechende Methoden, die nur für den
Stellenmarkt erweitert werden müssen.
Das Relationenmodell ist im Anhang in Abbildung A.2 detailliert aufgeführt.
Die Tabellen in der Datenbank sind mit dem Präfix "stma_" versehen, um Konflikte
mit anderen Bausteinen zu vermeiden und die Zuordnung unter allen Tabellen, die
die Datenbank für KLinform beinhaltet, zu erleichtern.
Die Tabellen Rubrik, Jobtyp und Arbeitszeit werden mit Werten gefüllt, die als feste
Parameter im System bestehen bleiben sollen. Eine spätere Veränderung z.B. der
Rubriken für eine Anpassung an aktuelle Bedürfnisse der Inserenten ist möglich,
erfordert jedoch eine Überführung der dann bestehenden Datensätze für Angebote
28
5 Implementierung
und Suchprofile in einen neuen konsistenten Zustand bezüglich Fremdschlüssel
seitens des Administrators.
Den Rubriken wurde eine Vereinbarung zugrunde gelegt, um Rubriken zu Kategorien
zusammenzufassen. Dies geschieht mittels Vergabe von speziellen IDs für
Kategorien (konkret: Teilbarkeit durch 100). In den Views, die Rubriken zur Auswahl
bringen, wird dies zur besseren Übersichtlichkeit verwendet, so dass der Benutzer
einfacher und schneller die gewünschte Rubrik finden kann.
Alle Fremdschlüsselbeziehungen wurden mit dem Attribut
"ON DELETE CASCADE"
versehen.
Dies gewährleistet, dass beispielsweise Einträge von nicht mehr dem System
bekannten Benutzern und Angebote, deren zugehörige Rubrik entfernt wurde, vom
DBMS entfernt werden. Wird ein Benutzer aus dem System KLinform entfernt, so
existiert in allen Tabellen des Stellenmarktes nach seiner Löschung automatisch
keiner seiner Einträge mehr.
In einer für alle KLinform-Bausteine angelegten DB-Tabelle wird der Administrator
des Bausteins Stellenmarkt festgelegt, um ihm per Browserzugriff unter Abprüfung
des Administratorstatus gesonderte Operationen zu ermöglichen.
Um den Zugriff auf die Daten später datenbankseitig zu beschleunigen, werden
Indizes eingeführt. Diese erlauben einen schnelleren Zugriff auf angegebene
Einträge. Das verwendete Datenbanksystem PostgreSQL führt solche Indizes jedoch
schon automatisch für die Primary- und Foreign Keys ein.
5.2 Realisierung des MVC Konzepts
Für
jede
der
Komponenten
Model,
View
und
Controller
sollen
wichtige
Gesichtspunkte betrachtet werden.
5.2.1 Model Objekte
Im Anhang zeigt Abbildung A.3 die erstellten Klassen.
Die zentrale Rolle spielt hier die Klasse
aus dem Paket
de.klinform.db.
StmaDB
StmaDB.
Sie erweitert die Klasse
AbstractDatabase
ist für alle Datenbankoperationen, die im
Stellenmarkt benötigt werden, zuständig. Sie beinhaltet Klassen für Einträge,
Jobtypen, Rubriken, Arbeitsverhältnissen und Suchprofile nebst Konstruktoren. Jede
dieser Klassen implementiert
Comparable.
Einmal, um Objekte mit anderen vergleichen
zu können, zum anderen wird intern häufig Gebrauch von
java.util.TreeSet
gemacht,
29
5 Implementierung
welches Datentypen voraussetzt, die
Comparable
Klassen hat der Bean-Konvention zufolge
get-
implementiert haben. Jede dieser
und
set-Methoden
für ihre nach außen
sichtbaren Properties.
Die Klasse
Eintrag
implementiert
KlinformSearchResult.Data
Implementierung umfasst die Methoden
getPrintRepresentation(), getRepresentationTitle()
aus dem Paket
de.klinform.bs.
Die
getShortRepresentationColumns(), getLongRepresentation(),
und , die bei der Suche für die Anzeige der
Übersicht, Detailansicht, Druckversion und Titel zur Verwendung kommen. Sie
werden von
de.klinform.bs.KLinformSearchResult
zur Darstellung benutzt. Hier ist lediglich die
Implementierung der Methoden nötig. Die Darstellung ist dann mit einer Zeile im
View-Objekt der Suche / Detailansicht und einem
<useBean...>
Eintrag in der global in
allen JSP-Seiten des Stellenmarktes eingelinkten "beans.jsp" (lädt alle nötigen Beans
für eine Session) realisiert.
Die Methoden zum Einfügen und Ändern von Einträgen benötigen zwei Parameter:
Beispiel:
public int einfuegen(FormularSuchProfil formular, Benutzer benutzer)
formular
ist eine Instanz der Klasse FormularSuchProfil. Sie ist eine Bean, die beim Eintragen
und Verändern eines Suchprofils als Model-Objekt für die Properties benutzt wird und
schließlich an
StmaDB.einfuegen
den Aufruf von
einfuegen
übergeben wird. Zusätzlich übergibt der Controller, der
tätigt, ein Objekt vom Typ
Benutzer.
Es wird benötigt, um die
Zuordnung (beim Einfügen) bzw. die Überprüfung (beim Verändern) in der SQLAnweisung zu gewährleisten. Das Einfüge-SQL-Statement sieht dann wie folgt aus:
statement.executeUpdate("INSERT INTO stma_suche VALUES ('"
+id+"','"+SQL(benutzer.getLogin())+"','"+formular.getJobtyp()+"','"
+SQL(formular.getStelle())+"','"+SQL(formular.getTitel())+"','"
+ablaufdatum+"')");
Abbildung 5.1 SQL Beispiel zum Einfügen (Methode in DB-Bean)
Hier wird die Methode getLogin() verwendet, um den Inserenten, der angemeldet das
Angebot eingetragen hat, zu identifizieren und ihn für dieses Suchprofil als
Inserenten einzutragen.
Das entsprechende SQL Beispiel aus der Bean für das Verändern eines Datensatzes
sieht folgendermaßen aus:
30
5 Implementierung
statement.executeUpdate("UPDATE stma_suche SET jobtyp='"
+formular.getJobtyp()+"', stelle='"+SQL(formular.getStelle())+"', titel='"
+SQL(formular.getTitel())+"' WHERE insid='"+benutzer.getLogin()+"' AND id='"+formular.getId()+"'");
Abbildung 5.2 SQL Beispiel zum Verändern (Methode in DB-Bean)
Hier wird überprüft, ob der Benutzer tatsächlich der ursprüngliche Inserent ist, der
das Suchprofil eingestellt hat.
Um Absicherung gegen Nebenläufigkeit zu gewährleisten, wurden alle DBOperationen in Transaktionen gekapselt. Hierzu wurde jeweils das Auto-Commit
ausgeschaltet, das jede DB-Operation einzeln ausführen lassen würde:
Connection conn = getConnection();
conn.setAutoCommit(false);
"SQL-Anweisung 1;"
"SQL-Anweisung 2;"
conn.commit();
Abbildung 5.3 Auto-Commit Abschaltung
Alle Textsuchen (Suche nach einem Begriff über Spalten einer DB-Tabelle) wurden
mit der in KLinform im Paket de.klinform.db realisierten Methode
findInTable(java.lang.String suchBegriff, java.sql.Statement statement,
java.lang.String tableName, java.lang.String[] tableColumns,
java.lang.String primaryKey, int schwellwert)
durchgeführt. Sie gibt ein Objekt vom Typ
de.klinform.db.AbstractDatabase.Suchergebnis
Suchergebnis []
zurück, welches durch
gegeben ist. Über den Schwellwert wird die
Genauigkeit der Suche angegeben.
Für die Aktionen Verlängern und Löschen sind Methoden implementiert, die ebenfalls
die Identität des per Parameter mit übergebenen Benutzers überprüfen.
Für verschiedene Views werden Methoden implementiert, die alle Rubriken,
Jobtypen, Arbeitszeiten oder alle Einträge eines Benutzers zurückgeben. Diese
können sodann je in einer Auswahl präsentiert werden. Für die Administration
existieren Methoden, um nach Benutzer (oder in Verbindung mit einer angegebenen
Rubrik) sortiert entsprechende Einträge anzuzeigen.
Für jede der Funktionalitäten Suchen, Inserieren, Administration und Verwaltung sind
Beans implementiert, die die Properties enthalten und für jeden Benutzer in
"beans.jsp" für die Gültigkeitsdauer einer Session geladen werden. Beim Inserieren
enthält so die zugehörige Instanz der Klasse
FormularInserieren
alle Attribute, die für eine
Stelle seitens des Benutzers angegeben werden, um einen mehrmaligen Durchlauf
31
5 Implementierung
Controller-View-Controller zu ermöglichen, falls Fehlangaben gemacht wurden. Die
Angaben werden mit einer
validate()-Methode
im Controller untersucht, so dass zum
Beispiel eine fehlende Angabe eines Pflichtfeldes als Fehlermeldung an die View
zurück übergeben wird.
5.2.2 View Objekte
Die Views stellen für einen Bereich Eingabefelder und/oder Ergebnisse dar
(Verwaltung und Suche). Stehen für den Benutzer Auswahlmöglichkeiten zur
Verfügung, so werden die Auswahlfelder am Anfang der JSP-Seite aus der
Datenbank abgefragt, um beispielsweise bei den Jobtypen in einer "select-Form"
präsentiert zu werden:
<% StmaDB.Jobtyp [] jobtypen = stma_db.getJobtypen(); %>
...
<select class="suchen_aktion" name="jobtyp" size="1">
<% for (int i=0; i< jobtypen.length;i++) { %>
<%if ((i+1)==stma_suchprofil.getJobtyp()) {%>
<option selected value="<%= jobtypen[i].getId() %>">
<%= jobtypen[i].getName() >
</option>
<% } else {%>
<option value="<%= jobtypen[i].getId() %>">
<%= jobtypen[i].getName() %>
</option>
<% } %>
<% } %>
</select>
Abbildung 5.4 View - Beispiel
Zu erkennen ist hier auch die Verzahnung von HTML-Fragmenten mit operativem
JSP-Code.
In der select-Anweisung wird mit name="..." die Variable festgelegt, die an die nächste
Seite übergeben wird (an den Controller) Dort erfolgt dann die Auswertung dieser
Werte und die Properties in den Beans werden gesetzt. class="..." legt die
Formatierung des select-Elementes fest und ist im KLinform-weiten Stylesheet
festgelegt. Dies kann zum Beispiel Hintergrundfarben, Schriftgrößen, Schriftarten und
-auszeichnungen umfassen oder bei Tabellen beispielsweise die Rahmendicke.
stma_suchprofil
ist der Name, der für die Bean beim Anlegen eines Suchprofiles
verwendet wird. stma_suchprofil.getJobtyp() holt aus der Bean den Wert der Variablen
Jobtyp.
32
5 Implementierung
Die Weitergabe der Variablen geschieht mittels <form action="folgeseite.jsp" method="POST">.
Diese HTML-Anweisung bewirkt, dass die zu übergebenden Werte über
Standardausgabe an die nächste Seite übermittelt werden. Der Vorteil gegenüber der
ebenfalls möglichen Methode "GET" liegt in der nicht vorhandenen
Längenbeschränkung der zu übergebenden Daten, die von Browser zu Browser
unterschiedlich sein kann.
Die Views verfügen über weiterführende Buttons, und solche, die eine Navigation zur
vorherigen Seite ermöglichen. Weiterführend meint zum Beispiel den Befehl zum
Abspeichern einer Eingabe.
In der Suche und den Verwaltungsseiten von Suchprofilen und Angeboten existieren
jeweils noch Verweise auf die Detailinformationen, die auf einer eigenen Seite mittels
einer Instanz der Klasse
de.klinform.bs.DetailInformation
präsentiert werden. Von dort ist
auch eine aufbereitete Druckansicht zu erhalten.
5.2.3 Controller
Die Controller legen die Anwendungslogik des Stellenmarktes fest. Sie steuern die
Abfolge
der
dem
Benutzer
zu
präsentierenden
Views,
stoßen
die
Datenbankoperationen an, belegen die Beans mit den von der View übergebenen
Daten und fragen ggf. validate()-Methoden ab.
Für das Eintragen eines Suchprofils soll der komplette Aufbau des betreffenden
Controllers erläutert werden:
<%@ include file="/klinform.inc" %>
<%@ include file="/bs/stellenmarkt/beans.jsp" %>
<% if ((request.getParameter("stelle") == null) ||
(request.getParameter("stelle").length() == 0)) stma_suchprofil.setStelle("");
if ((request.getParameter("titel") == null) ||
(request.getParameter("titel").length() == 0)) stma_suchprofil.setTitel("");%>
<jsp:setProperty name="stma_suchprofil" property="*" />
<% String nextpage = "/bs/stellenmarkt/suchprofil/formular.jsp";
if (user.getLoggedIn()) {
if (stma_suchprofil.getId() == 0) {
if (request.getParameter("speichern.x")!=null && stma_suchprofil.validate()) {
if (stma_db.einfuegen(stma_suchprofil, user) > 0)
nextpage = "/bs/stellenmarkt/suchprofil/ok.jsp";
else nextpage="/fehler.jsp?nextpage=/bs/stellenmarkt/index.jsp
&errortext=Angaben nicht übernommen!";
}
}
else {
33
5 Implementierung
if (request.getParameter("speichern.x")!=null && stma_suchprofil.validate()) {
if (stma_db.veraendern(stma_suchprofil, user) > 0)
nextpage = "/bs/stellenmarkt/suchprofil/ok.jsp";
else nextpage = "/fehler.jsp?nextpage=/bs/stellenmarkt/index.jsp
&errortext=Angaben nicht übernommen!";
}
}
}
else nextpage="/einloggen.jsp?nextpage=/bs/stellenmarkt/suchprofil/index.jsp"; %>
<jsp:forward page="<%= nextpage %>" />
Abbildung 5.5 Controller - Beispiel
Wie auf jeder JSP-Seite des Stellenmarktes werden zu Beginn die Beans geladen
(falls nicht schon geladen) und die systemweite include-Datei eingefügt. Sie enthält
Import-Anweisungen für andere Klassen und Pakete, sowie
useBean-Anweisungen
für
wichtige Beans (z.B. Benutzerverwaltung).
Mit
setProperty
werden die Properties aus dem zugehörigen Sitzungsobjekt
einmal initialisiert. Die Abfrage nach den Parametern
vorhandenen Objektes
request
stelle
und
titel
stma_suchprofil
des implizit
widmet sich der Eigenheit von HTML-Formularen,
Felder, deren Inhalt nicht belegt wurden, nicht in der URL an die nächste Seite als
leer gekennzeichnet zu übergeben, sondern schlicht nicht anzugeben. Dies ist für
den Spezialfall, dass ein Benutzer in einem Feld der View eine Angabe gemacht hat,
die Eingabe dem Controller übergibt, dieser Fehler mittels validate() feststellt und an die
View zurückverweist, von Bedeutung. Denn löscht der Benutzer dann dieses Feld
und lässt es leer, wird es nicht übergeben und das Sitzungsobjekt würde ohne obige
Abfrage den vorherigen Inhalt für dieses Feld bestehen lassen. Somit würde die erste
Eingabe übernommen. Der Controller überprüft also das Vorhandensein der
Variablen und setzt diese gegebenenfalls explizit im Sitzungsobjekt auf den
Leerstring.
Als nächstes wird der String
nextpage
als Link auf die View festgelegt. Er wird je nach
Anwendungsfall vom Controller umgesetzt auf eine Fehlerseite (Fehler bei der DBTransaktion), Erfolgsseite (Eintrag in DB eingefügt/verändert), oder die KLinformSeite zum Einloggen eines Benutzers, falls dieser nicht eingeloggt ist. Nur
angemeldete Benutzer dürfen Einträge in der Datenbank vornehmen. Der Controller
kann aus verschiedenen Szenarien heraus aufgerufen werden:
–
Von der Hauptseite des Stellenmarktes
34
5 Implementierung
Dann wurde ihm keine Variable übergeben und der Controller verzweigt, falls der
Benutzer angemeldet ist, auf die View zum Eintrag der Daten.
–
Von der View mit erstmals eingegebenen Daten
Der Controller verzweigt auf die Erfolgsmeldungsseite, falls die Eingaben korrekt
(validate()), der Parameter
speichern.x
werden konnten;
wird von der Form mit der x-Koordinate versehen, auf
speichern.x
gesetzt ist und die Daten sodann eingefügt
die der Benutzer innerhalb des Absendebuttons geklickt hat. Diese werden nicht
ausgewertet, sondern lediglich auf Vorhandensein überprüft, damit der Controller
als von der View aufgerufen abläuft. Die Einfügemethode übergibt einen Wert > 0,
falls sie die Daten einfügen konnte.
–
Von der Verwaltungsseite mit übergebener ID des zu editierenden Datensatzes
Der Vorgang ist der gleiche wie beim erstmaligen Einfügen, nur werden die Daten
schon mit der aufrufenden URL übergeben und sind somit im Sitzungsobjekt auf
Werte gesetzt, wenn die View zum Editieren aufgerufen wird.
–
Von der View mit zu verändernden Daten
Da die ID beim Aufruf aus der Verwaltungsseite mit übergeben wurde, wird jetzt
die Methode zum Verändern eines Datensatzes in der DB-Bean aufgerufen,
sofern die Daten den Vorgaben entsprechen.
Der Controller für das Inserieren von Angeboten unterscheidet sich von dem der
Suchprofileingabe prinzipiell nicht.
Der Controller der Suche leitet nur die Variablen aus der URL an die Instanz der
Klasse
de.klinform.bs.KLinformSearchResult
weiter, die in der View der Suche für die
Darstellung der Ergebnisse verantwortlich ist.
Die Controller der Verwaltungsseiten der Suchprofile und Angebote eines Benutzers
leiten je nur Lösch- und Verlängerungsoperationen in der DB-Bean ein und
verweisen wieder zurück auf die betreffende View.
5.3 Personalisierung
Die Eingabe von Suchprofilen, die dem Benutzer ermöglicht wird, bildet den Kern der
Personalisierung des Stellenmarktes. Die wichtigste Funktion des Bausteins ist für
den Arbeitssuchenden die Suche. Hat der Benutzer eines oder mehrere Suchprofile
angegeben, kann das System die Suche selbstständig regelmäßig durchführen.
35
5 Implementierung
Hierzu ist eine Java-Applikation vorgesehen, die eigenständig aufrufbar ist, oder in
die bereits systemweit vorhandene Klasse
de.klinform.cronjobs.Daily
eingebunden werden
kann, um zu festgelegten Zeitpunkten ausgeführt zu werden. Als eigenständige
Applikation kann sie auf einem separaten System ausgeführt werden, um eine hohe
Last auf dem eigentlichen KLinform-Server zu vermeiden. Die Datenbankoperationen
generieren in jedem Fall eine hohe Last. Dies könnte eventuell durch ein vorheriges
Kopieren der relevanten Datenbestände in eine Datenbank eines anderen Systems
verbessert werden, um die DB-Operationen auf eine Auslese-Operation zu
beschränken.
In der Suchprofileingabe ist dem Benutzer die Möglichkeit gegeben, die Bezeichnung
der Arbeitsstelle (Position) oder/und seinen Ausbildungstitel anzugeben. Anhand
dieser Information sucht die Klasse
findInTable(...)
StmaMailControl
in der Datenbank mit der Methode
Treffer. An dieser Stelle soll für den Fall der Angabe von Position und
Ausbildungstitel die entsprechende Methode, die in Teilen den anderen DBMethoden aus der Stellenmarkt-DB-Bean entsprechen, genauer betrachtet werden:
private Integer[] allcheck(String titel, String stelle) {
TreeSet mengeA = new TreeSet();
TreeSet mengeB = new TreeSet();
/* Die Verwendung von TreeSet ermöglicht mittels einfacher Mengenoperationen die
Aufnahme eines Datenbestandes, der automatisch sortiert ist.*/
try {
Connection conn = getConnection();
Statement statement1=conn.createStatement();
Statement statement2=conn.createStatement();
Suchergebnis[] ergebnisStellen = findInTable(stelle,statement1,
"stma_angebot","stelle", "id", 70);
Suchergebnis[] ergebnisTitel = findInTable(titel,statement2,
"stma_angebot","titel","id",70);
/* Auf zwei separaten Statements wird für die übergebenen Parameter stelle und
titel die Suche durchgeführt.*/
for (int i=0;i < ergebnisStellen.length; i++) {
Integer k = new Integer(ergebnisStellen[i].getKey());
mengeA.add(k);
}
for (int i=0;i < ergebnisTitel.length;i++) {
Integer j=new Integer(ergebnisTitel[i].getKey());
if (mengeA.contains(j)) mengeB.add(j);
}
/* mengeB enthält die IDs, die für beide Suchanfragen Treffer sind. Anschließend
wird diese Menge in ein Array vom Typ Integer umgewandelt und zurückgegeben.*/
conn.close();
}
catch (Exception oops) {
36
5 Implementierung
KLinform.perror(this,oops);
}
Object [] object = mengeB.toArray();
Integer[] rueckgabe = new Integer[object.length];
System.arraycopy(object,0,rueckgabe,0,object.length);
return rueckgabe;
}
Abbildung 5.6 Suchprofile - Suchmethode
Der Benutzer wird per E-Mail über alle IDs benachrichtigt, die Treffer anhand seines
Suchprofils darstellen. Dies geschieht durch Einbettung von HTML-Code in der EMail in Form eines HTML-Links, den die meisten grafische E-Mail Clients
interpretieren, sofern es der Benutzer zulässt, anderenfalls muß er den Link aus der
E-Mail in den Browser kopieren. Für jedes Suchprofil wird eine Mail generiert, die aus
Textbausteinen zusammengesetzt wird, die in systemweiten Variablen abgelegt sind.
Da die Suche täglich abläuft, werden die bereits per Mail versendeten Treffer in einer
separaten Tabelle der Datenbank vermerkt, die vor dem Verschicken überprüft wird,
um zu vermeiden, einem Benutzer Treffer erneut zu präsentieren.
5.4 Gültigkeitsüberprüfung
Alle Angebote und Suchprofile sind mit einem automatisch per Systemvariablen
berechneten Gültigkeitsstempel versehen. Um dem Eintragenden die Möglichkeit zu
bieten, Einträge zu verlängern und nicht alle Gültigkeiten merken zu müssen, nimmt
der Stellenmarkt ihm diese Aufgabe ab, indem er auf die in KLinform bereits
vorhandene
Klasse
de.klinform.cronjobs.OutdateControl
zurückgreift.
Ergänzt
um
die
entsprechenden Einträge für den Stellenmarkt, führt diese Klasse, ebenfalls
regelmäßig ausgeführt, Checks auf den Tabellen des Stellenmarktes über die
Gültigkeitsstempel durch. Per Parameter wird vorgegeben, wie viele Tage vor
Ablaufen der für den Eintrag verantwortliche Benutzer darauf aufmerksam gemacht
werden soll, dass sein Datensatz in wenigen Tagen aus der Datenbank entfernt wird.
Dies geschieht auch per Mail, in der ein HTML-Link auf die entsprechende
Verwaltungsseite führt. Benutzt er diesen Link, wird durch einen übergebenen
Parameter automatisch der Eintrag (Suchprofil oder Angebot) verlängert. Ist nach
Ablauf dieser Frist der betreffende Datensatz nicht verlängert worden, löscht
KLinform diesen schlussendlich.
37
6 Zusammenfassung
6 Zusammenfassung
Diese Projektarbeit hat sich mit der Analyse, Vorstellung der Techniken, Entwurf und
Betrachtung von wichtigen Aspekten der Implementierung des Stellenmarktes für das
Portal KLinform beschäftigt.
Einige Punkte sollen noch einmal hervorgehoben und gesondert betrachtet werden.
–
MVC Konzept
Als bemerkenswert hervorzuheben sei das Model-View-Controller Konzept, das
eine saubere Trennung von Präsentation, Logik und Schnittstelle zu den Daten
gewährleistet. Es erleichtert durch die generelle Trennung der Aufgaben die
Erstellung und Wartung der Komponenten. Dies ist in einem größeren Projekt, wie
es KLinform darstellt, von zentraler Bedeutung, da kleinere Veränderungen am
System keine allzu großen Nachwirkungen mit sich bringen.
–
Erweiterungen
Der Baustein Stellenmarkt ist in der jetzigen Form mit ausreichender Funktionalität
versehen, die aber gegebenenfalls noch erweitert werden könnte. Besonders auf
Seiten des Administrators ergibt sich mit steigendem Angebotsaufkommen ein
erhöhter Bedarf an Werkzeugen zur Datenverwaltung. Dies ist einerseits für den
Stellenmarkt zutreffend, jedoch auch für weitere Bausteine zutreffend, da große
Datenmengen
effiziente
Verwaltung
erfordern.
Ein
zentrales
Tool
zur
Datenverwaltung bietet sich hier gegebenenfalls eher an.
–
Ausblick
Umfang der Suchfunktion, Änderung von voreingetragenen Rubriken, Jobtypen
und Arbeitsverhältnissen und möglichen Attributen der Angebote können sich im
Betrieb eines solchen Portals ständig ändern. Eine sorgfältige Analyse des
aufkommenden Datenbestandes ist somit auch immer entscheidend für die
Akzeptanz eines solchen Angebots. Hier müssen Aspekte des Datenschutzes
immer berücksichtigt bleiben.
–
Zukunftsfähigkeit
38
6 Zusammenfassung
JSP und Java als plattformunabhängige Technologien tragen zur Wartbarkeit des
Systems bei, da sie offen zugängliche Standards darstellen und keine
angepassten Speziallösungen darstellen. Auch eine Portierung der Daten auf ein
anderes Datenbanksystem stellt eine lösbare Aufgabe dar, da nur wenige
Speziallösungen
eingesetzt
werden
durchschaubaren
Beziehungen
Zukunftsfähigkeit
von
und
zueinander
solchermaßen
die
Daten
stehen.
angelegten
in
Dies
einfachen
spricht
Systemen,
und
für
die
wobei
die
Schnelllebigkeit des Internet und die Vielfältigkeit der Angebote immer wieder
neue Ansätze entwickelt und auch die Vorlieben des Anwenders einem steten
Wandel unterliegen.
39
Quellenverzeichnis
[Monster.de]: Monster, http://www.monster.de, 2002,
[Jobpilot.de]: Jobpilot, http://www.jobpilot.de, 2002,
[Stellenmarkt Online]: Stellenmarkt Online, http://www.stellenmarkt.de, 2002,
[Härder 1999]: Theo Härder, Vorlesung Datenbanksysteme I, 1999
[PostgreSQL]: , http://www.de.postgresql.org/users-lounge/docs, 2002,
[Java pro 1999]: Gerhard Wilhelms, Markus Kopp, Java professionell, 1999
[Turau 2001]: Volker Turau, Java Server Pages: dynamische Generierung von WebDokumenten, 2001
[JSP Docs]: , http://java.sun.com/products/jsp/docs.html, 2002,
[Apache License]: , http://www.apache.org/licenses, 2002,
[Jakarta-Tomcat]: , http://jakarta.apache.org/tomcat, 2002,
Anhang
A Anhang
Abbildung A.1 Einstiegsseite - KLinform
Relation
Attribute
Typ
Zusatz
41
Anhang
Rubrik
Jobtyp
Arbeitszeit
Suche
Angebot
id
int not null
primary key
name
text not null
id
int not null
name
text not null
id
int not null
name
text not null
id
int not null
primary key
insid
text not null
foreign key, references Benutzer(id)
jobtyp
int not null
foreign key, references Jobtyp(id)
stelle
text
titel
text
guelt
date not null
primary key
primary key
id
int not null
primary key
insid
text not null
foreign key, references Benutzer(id)
jobtypid
int not null
foreign key, references Jobtyp(id)
rubrikid
int not null
foreign key, references Rubrik(id)
arbeitszeitid
int not null
foreign key references Arbeitszeit(id)
stelle
text not null
titel
text
anf
text not null
aufg
text not null
insinf
text not null
allg
text
datum
date not null
guelt
date not null
anspr
text
tel
text
fax
text
mail
text
url
text
Abbildung A.2 Relationenmodell
42
+compareTo(object:Object) : int
+Rubrik(in id:int, name:String) : Rubrik
+getId() : int
+getName() : String
+setId(in x:int)
+setName(x:String)
~rubrik : int
~jobtyp : int
~arbeitszeit : int
~stelle : String
~titel : String
~anf : String
FormularInserieren
~url : String = ""
+getRubrik() : int
+getJobtyp() : int
+getArbeitszeit() : int
+Arbeitszeit(in id:int, name:String) : Arbeitszeit
+getId() : int
+getName() : String
+setId(in x:int)
+setName(x:String)
~tel : String
~fax : String
~mail : String
~url : String
+zuVerlaengern() : boolean
+getShortRepresentationColumns() : String[]
+getRepresentationTitle() : String
+getPrintRepresentation()
+getLongRepresentation()
+setUrl(x:String)
+setMail(x:String)
+setFax(x:String)
+setTel(x:String)
+setAnspr(x:String)
+setGuelt(x:Date)
+setDatum(x:Date)
+setAllg(x:String)
+setInsinf(x:String)
+setAufg(x:String)
+setAnf(x:String)
+setTitel(x:String)
+setStelle(x:String)
+setArbeitszeit(in x:int)
+setRubrik(in x:int)
+setJobtyp(in x:int)
+setInsid(x:String)
+setId(in x:int)
+getUrl() : String
+getMail() : String
+getFax() : String
+getTel() : String
+getAnspr() : String
Profil
+setGuelt(x:Date)
+getGuelt() : String
+setInsid(x:String)
+getInsid() : String
+setTitel(x:String)
+getTitel() : String
+setStelle(x:String)
+setJobtyp(in x:int)
+setId(in x:int)
+getStelle() : String
+getJobtyp() : int
+getId() : int
+Profil(rs:ResultSet) : Profil
+zuVerlaengern() : boolean
+compareTo(o:Object) : int
~guelt : Date
~stelle : String
~titel : String
~insid : String
~jobtyp : int
~id : int
+validate() : boolean
+getId() : int
+setId(in x:int)
~id : int = 0
FormularDetail
+validate() : boolean
+setUrl(x:String)
+setMail(x:String)
+setFax(x:String)
+setTel(x:String)
+setAnspr(x:String)
+setAllg(x:String)
+setInsinf(x:String)
+setAufg(x:String)
+setAnf(x:String)
+setTitel(x:String)
+setStelle(x:String)
+setArbeitszeit(in x:int)
+setRubrik(in x:int)
+setJobtyp(in x:int)
+getGuelt() : String
+getDatum() : String
+getAllg() : String
+getUrl() : String
+getMail() : String
+getFax() : String
+getTel() : String
+getAnspr() : String
+getAllg() : String
+getInsinf() : String
+setId(in x:int)
+setName(x:String)
+setId(in x:int)
+getName() : String
+getId() : int
+Jobtyp(in id:int, name:String) : Jobtyp
+compareTo(object:Object) : int
~name : String
+getAufg() : String
+getInsinf() : String
+getAufg() : String
+getAnf() : String
+getTitel() : String
+getStelle() : String
+getArbeitszeit() : int
+getRubrik() : int
+getJobtyp() : int
+getInsid() : String
+getAnf() : String
+getTitel() : String
+Eintrag(rs:ResultSet) : Eintrag
+getId() : int
+getStelle() : String
+compareTo(o:Object) : int
Jobtyp
~mail : String = ""
+compareTo(object:Object) : int
~anspr : String
~id : int
~fax : String = ""
~name : String
~guelt : Date
+getId() : int
~tel : String = ""
~id : int
~datum : Date
~anspr : String = ""
~allg : String = ""
~insinf : String
~allg : String
~insinf : String = ""
~aufg : String = ""
~anf : String = ""
~titel : String = ""
~stelle : String = ""
~arbeitszeit : int = 1
~rubrik : int = 1001
~jobtyp : int = 1
~id : int = 0
~aufg : String
Arbeitszeit
~name : String
Rubrik
~id : int
~insid : String
Eintrag
~id : int
FormularAdminVerwalten
+validate() : boolean
+setPage(in x:int)
+setSuchBegriff(x:String)
+getPage() : int
+getSuchBegriff() : String
+setArbeitszeit(in x:int)
+getArbeitszeit() : int
+setRubrik(in x:int)
+getRubrik() : int
+setJobtyp(in x:int)
+getJobtyp() : int
~arbeitszeit : int = 1
~jobtyp : int = 0
~rubrik : int = 0
~page : int = 0
~suchBegriff : String = ""
FormularSuchen
+validate() : boolean
+setTitel(x:String)
+setStelle(x:String)
+setJobtyp(in x:int)
+setJobTyp(in x:int)
+getTitel() : String
+getStelle() : String
+getJobtyp() : int
+setId(in x:int)
+getId() : int
~titel : String = ""
~stelle : String = ""
~id : int = 0
~jobtyp : int = 1
FormularSuchProfil
+validate() : boolean
+getId() : int
+setId(in x:int)
~id : int = 0
FormularProfilVerwalten
+validate() : boolean
+getId() : int
+setId(in x:int)
~id : int
FormularUserVerwalten
+validate() : boolean
+getId() : int
+setId(in x:int)
+getRubrik() : int
+setRubrik(in x:int)
+getBenutzer() : String
+setBenutzer(x:String)
~benutzer : String = "ALLE"
~rubrik : int = 0
~id : int = 0
StmaDB
+main(args:String[])
+check()
-allcheck(titel:String, stelle:String) : Integer[]
-stellencheck(stelle:String) : Integer[]
-titelcheck(titel:String) : Integer[]
+StmaMailControl() : StmaMailControl
StmaMailControl
+verlaengernAngebot(tabelle:String, in id:int, beanUser:)
+countBenutzerEintraege(benutzer:) : int
+getJobtypen() : Jobtyp[]
+getArbeitszeiten() : Arbeitszeit[]
+getRubriken() : Rubrik[]
+getBenutzerRubrikEintraege(benutzer:String, in ruid:int) : Eintrag[]
+getEingetrageneBenutzer() : String[]
+getProfile(benutzer:) : Profil[]
+getEintraege(benutzer:) : Eintrag[]
+loescheProfil(in id:int, benutzer:)
+loescheEintrag(in id:int, benutzer:)
+getEintrag(in id:int) : Eintrag
+suchen(in jobid:int, in ruid:int, in arbeitszeitid:int, suchBegriff:String) : Suchergebnis[]
+veraendern(formular:FormularSuchProfil, benutzer:) : int
+veraendern(formular:FormularInserieren, benutzer:) : int
+einfuegen(formular:FormularSuchProfil, benutzer:) : int
+einfuegen(formular:FormularInserieren, benutzer:) : int
+StmaDB() : StmaDB
-ANGEBOTROWS : int = 17
Anhang
Abbildung A.3 UML-Klassendiagramm
43