// N o r m a l i z e the sum of s c o r e and ran k i t e m I t = i t e m s . i t e r a t o r () ;
w h i l e ( i t e m I t . h a s N e x t () ) {
S e a r c h R e s u l t I t e m it em = ( S e a r c h R e s u l t I t e m ) i t e m I t . n ext () ; it em . s e t S c o r e (( it em . g e t S c o r e () - m i n C o m b S u m ) /
( m a x C o m b S u m - m i n C o m b S u m ) ) ; }
}
r e t u r n i t e m s ; }
Code 6.9:NormalisedCombSumAlgorithm: Berechnung der kombinierten Relevanzen
Die so neu berechneten Relevanzen k¨onnen wie zuvor als Wahrscheinlichkeiten des Interesses an dem jeweiligen Ergebnis interpretiert werden. Das erstgereihte Ergebnis hat durch den abschließenden Normalisierungsschritt eine Relevanz von 1, das letztgereihte die Relevanz 0. F¨ur ein und das selbe Ergebnis kann aufgrund der Normalisierung bei unterschiedlichen Suchen je nach originaler Reihung der Relevanzwert schwanken. Aus diesem Grund wird in der Benutzeroberfl¨ache weiterhin die von Prospector berechnete Relevanz angezeigt. Es kann dadurch zwar vorkommen, dass diese im Laufe der Ergebnisliste nicht monoton ansteigt, doch sie spiegelt die wahren Interessen des Benutzers auf Basis der Modelle besser wider.
6.5 System¨ uberwachung
Bereits in Version 2 verf¨ugte Prospector ¨uber einige Funktionen, die das System in seinem Lauf beobachten und relevante Daten mitprotokollieren. Diese Daten zur Benutzung des
Sys-tems durch die Benutzer, der Suchen und Bewertungen, die diese ausgef¨uhrt haben und der Anderungen der Modelle wurden auch teilweise in der Evaluierung verwendet. F¨¨ ur die neue Version sollte die System¨uberwachung erweitert und verbessert werden.
Bisher wurden die protokollierten Daten in einfache Textdateien geschrieben. Um diese nach der Evaluierung in den Niederlanden auszuwerten, wurden sie von einem Parser eingelesen und in eine Datenbank geschrieben. Dank der M¨oglichkeiten von SQL-Abfragen konnten sie so gefiltert, aggregiert und f¨ur weitere Analysen aufbereitet werden. F¨ur die Weiterentwicklung der System¨uberwachung wurde daher die Entscheidung getroffen, gleich in eine Datenbank zu protokollieren. Im Folgenden wird zuerst das Objektmodell der zu protokollierenden Ereig-nisse und ihrer Daten vorgestellt. Anschließend wird beschrieben, wie diese EreigEreig-nisse in die Datenbank persistiert werden. Zum Schluss werden die Mechanismen zum Erzeugen, Sammeln und Abspeichern der Ereignisse erl¨autert.
6.5.1 Objektmodell
Die Basis des Objektmodells bildet eine Vererbungshierarchie von Ereignistypen. Jeder Typ verwaltet gewisse Daten und tritt bei bestimmten Aktionen auf. Dar¨uber hinaus gibt es noch Hilfsklassen zum Speichern der Ergebnislisten. Alle Klassen und ihre Beziehungen sind in Abbildung 6.13 auf der n¨achsten Seite dargestellt. Die grauen Notizen geben f¨ur ein Ereignis jeweils die m¨oglichen Aktionen an, bei denen dieses auftreten kann. Die weißen Notizen zeigen m¨ogliche Werte f¨ur bestimmte Datenfelder eines Ereignisses.
Folgende Ereignisse werden von Prospector unterst¨utzt:
• AuditEvent: ist die abstrakte Basisklasse und definiert eine automatisch generierte ID id, einen Zeitstempel timestamp, den genauen Typ type (entspricht der Unterklasse und wird f¨ur die Persistierung ben¨otigt), eine Identifikation des BenutzersuserIdund, welche Aktion action(z. B. login,search,rate, . . . ) ausgef¨uhrt wurde.
• UserAuditEvent: die Oberklasse all jener Ereignisse, die direkt vom Benutzer ausgel¨ost werden. Die Klasse definiert keine weiteren Datenfelder, und das Ereignis tritt beim Einloggen (login), Ausloggen (logout) und Registrieren (register) auf.
• ResultAuditEvent: wird verwendet, wenn das Ereignis ein Suchergebnis in seiner Ge-samtheit wie beim Suchen (search) oder Umreihen (rerank) betrifft. Es besitzt einen Verweis auf der entsprechende Ergebnis resultund kennt dessen Reihung order.
• ResultItemAuditEvent: tritt bei Ereignissen auf, die ein einzelnes Suchergebnis be-treffen. Dies ist das Betrachten des Ergebnisses (follow), das ¨Offnen in einem neuen Fenster/Tab (open), das ¨Offnen der Voransicht (preview) und das
”Zur¨uckkehren“ von einer der zuvor genannten Ansichten zum Ergebnis (return). Der Rang index des je-weiligen Ergebnisses in der Liste wird gespeichert.
• RateAuditEvent: wird durch das Bewerten (rate) eines Ergebnisses ausgel¨ost. Gespei-chert wird die vom Benutzer gew¨ahlte Bewertungbias.
id :Long {readOnly}
Abbildung 6.13:Klassenmodell der Ereignisse zur System¨uberwachung
• CategoryAuditEvent: wird f¨ur das Protokollieren von Benutzeraktionen in der The-menhierarchie verwendet. Wenn dieser ein Thema/eine Kategorie ausklappt (unfold), einklappt (fold) oder anw¨ahlt (filter), so wird der Pfad in categorygespeichert.
• BrowseAuditEvent: dieses Ereignis tritt bei der Navigation in der Benutzeroberfl¨ache (browse) auf und protokolliert das Ziel targetder Benutzeraktion.
• ProfileAuditEvent: tritt auf, wenn der Benutzer seine Affinit¨at zu einer Gruppe ¨andert (modify_affinity). Gespeichert werden der Name der Gruppegroupund die alte und neue Affinit¨atoldAffinityund newAffinity.
• ModelAuditEvent: bei Ver¨anderungen in Modellen, die explizit (modify_model) oder durch eine Bewertung (rate) hervorgerufen wurden. Protokolliert werden der Grup-penname groupName (bei einem Gruppenmodell), der alte Pfad mit den Gewichten oldPath, der neue Pfad newPathund, ob sich eine ¨Anderung der Struktur ergeben hat.
In structureChange steht, ob ein Teilbaum entfernt wurde (pruned), welche Modelle f¨ur die Ableitung eines Gewichts konsultiert wurden (bootstrap_(user|group|both)), oder ob der Standardwert verwendet wurde (default_prob).
• SystemAuditEvent: wird bei Systemereignissen wie Start (startup) oder Herunterfah-ren (shutdown) erzeugt. Vorgesehen sind auch periodische Statusmeldungen (status) mit Information zur aktuellen Systembenutzung in den Datenfeldern.
6.5.2 Persistenz
F¨ur die Persistierung der Ereignisobjekte wurde derobjekt-relationale Persistenz- und Abfrage-Dienst Hibernate7 verwendet. Dieser erm¨oglicht die Abildung von Objekten und ihren Bezie-hungen (Vererbung, Objektreferenzen, . . . ) auf relationale Datenbankstrukturen. Ohne daten-bankspezifische Structured Query Language (SQL)-Befehle schreiben zu m¨ussen, k¨onnen so die Objekte mit einfachen Java-Befehlen in die Datenbank gespeichert und aus ihr gelesen werden. Hibernate kapselt den Zugriff zu den unterschiedlichsten Datenbankmanagement-Systemen, k¨ummert sich um das Anlegen des Datenbankschemas unter Verwendung der defi-nierten Objekte und Beziehungen und bietet transaktionsorientierten Datenzugriff.
ZumEinrichten von Hibernate m¨ussen neben einer allgemeinen Konfigurationsdatei mit Ver-bindungseinstellungen (Datenbank, Benutzer, Passwort, Cache-Optionen, . . . ) auch die Ab-bildungen der Objekte und Beziehungen auf Tabellen, Schl¨ussel und Constraints angelegt werden. Code 6.10 zeigt diese Konfiguration f¨ur die Klasse AuditEvent. Es wird festgelegt, dass die Daten in der Tabelleeventmit einer automatisch generierten ID gespeichert werden sollen. Die Datenfelder werden als Spalten mit ihrem Typ (so er nicht automatisch erkannt wird), L¨angen und Einschr¨ankungen (NOT NULL) definiert. Das Feldtype wird außerdem als jenes bestimmt, welches in der Datenbank die Unterscheidung zwischen den konkreten Unter-klassen vonAuditEvent erm¨oglicht.
< ?xml v e r s i o n=" 1.0 "? >
< !D O C T Y P E h i b e r n a t e - m a p p i n g P U B L I C
" -// H i b e r n a t e / H i b e r n a t e M a p p i n g DTD 3 . 0 / / EN "
" h t t p : // h i b e r n a t e . s o u r c e f o r g e . net / h i b e r n a t e - mapping - 3 . 0 . dtd ">
< h i b e r n a t e - m a p p i n g p a c k a g e =" at . jku . fim . p r o s p e c t o r . a u d i t i n g . e v e n t ">
< c l a s s na me =" A u d i t E v e n t " t a b l e =" e v e n t ">
< id nam e =" id " c o l u m n =" id ">
< g e n e r a t o r c l a s s =" n a t i v e " / >
< / id >
< d i s c r i m i n a t o r c o l u m n =" t ype " typ e =" s t r i n g " l e n g t h =" 20 " / >
< p r o p e r t y na me =" t i m e s t a m p " c o l u m n =" t i m e _ s t a m p " not - nul l =" tr ue " / >
< p r o p e r t y na me =" u s e r I d " c o l u m n =" u s e r _ i d " / >
< p r o p e r t y na me =" a c t i o n " typ e =" s t r i n g " l e n g t h =" 20 " not - nul l =" t rue " / >
< / c l a s s >
< / h i b e r n a t e - m a p p i n g >