<Thesis>

5 Implementierung in Java

In Kapitel 4 sind die zahlreichen Ideen vorgestellt worden, welche ausgehend von grundlegenden Entwurfsmustern in CoCuSe eingebracht worden sind. Insbesondere die Darstellung der CoCuSe-eigenen Seitentypen bietet eine Sicht auf den Funktionsumfang aus den Augen des Anwenders.

Dieses Kapitel beschreibt nun die verschiedenen Komponenten von CoCuSe aus einem technischeren Blickwinkel in Bezug auf die Realisierung der Implementierung, jedoch ohne auf den Quellcode zeilenweise eingehen zu wollen. Der Programmierer mag bei Bedarf die Quellen direkt anschauen - f r eine Pr sentation der Konzepte hinter CoCuSe ist dies an dieser Stelle jedoch nicht erforderlich, vielmehr dient ein gewisses Mindestma an Abstraktion dem besseren Verst ndnis des Gesamtzusammenhanges.

5.1 Systemspezifische Daten

Die vorliegende Version von CoCuSe ist vollst ndig in der objekt-orientierten Programmiersprache Java 2 Version 1.4.2_06, welche von Sun [Sun 2004] entwickelt wird, mit Hilfe der integrierten Entwicklungsumgebung Eclipse Version 3.0 [Eclipse 2001] unter Windows XP Professional [Microsoft 2001] geschrieben. Als Funktionsbibliothek zur Verarbeitung von HTML-Quelldaten wird HTMLparser Version 1.5 [Raha 2005] verwendet. Die Fenstertechnik f r Awareness-Informationen basiert auf DHTML tip message Version 1.5.4 [Gamal 2003] und die Idee zur Umsetzung von ein- und ausblendbaren Textbl cken ist technisch abgewandelt von [Microsoft 2005].

Die Basisinstallation von CURE, welche als Ausgangspunkt der Entwicklung dient, ist auf dem Stand vom 31. Januar 2005. Dementsprechend ist auch CURE in Java programmiert, es nutzt das relationale Datenbankmanagementsystem HSQLDB [Hsqldb 2001] als persistente Datenbasis, wobei aus Java mittels Hibernate [Hibernate 2002], welches f r das objekt-relationale Mapping (O/R-Mapping) zust ndig ist, darauf zugegriffen wird. Die gesamte Java-Applikation wird wie blich innerhalb einer virtuellen Maschine ausgef hrt. F r die Servlet-Technologie kommt Apache Tomcat [Apache 1999], die Referenzimplementation der Java Servlet Technologie, als Servlet-Container zum Einsatz.

5.2 MVC-Modell - Model, View, Controller

Die Struktur von CURE - und somit auch von CoCuSe - folgt dem sog. MVC-Modell. Es handelt sich dabei um eine Programmarchitektur, welche sich aus drei Bereichen zusammensetzt. Das Modell (englisch Model) modelliert die Datenobjekte und bietet Zugriffsmethoden darauf an. Die Sicht (englisch View) k mmert sich um die Repr sentation der Daten. Die Steuerung (englisch Controller) koordiniert Ein- und Ausgaben, Abl ufe und nderungen der Datenbest nde. Diese Aufteilung in mehrere Bereiche dient der bersichtlichen Trennung, Flexibilit t des Programms und Unterst tzung von Wiederverwendbarkeit der Teilkomponenten. Im Allgemeinen wird es als vorteilhaft angesehen, dass hierdurch z.B. Anpassungen einer View-Komponente nicht zwangsl ufig auch nderungen in anderen Bereichen erfordern, auch lassen sich leicht verschiedene Views f r ein und dasselbe Model verwenden. [Krasner 1988].

5.3 Model

Das Datenmodell von CoCuSe in Form des UML-Diagrammes in Abbildung 5.3.a zeigt, leicht vereinfacht dargestellt, die wichtigsten Objekte und ihre Beziehungen untereinander. Neben den Objekten und ihren Klassen im Einzelnen gibt es logische Einheiten, die in einem engeren Zusammenhang stehen - entsprechend orientiert sich der Rundgang durch die Komponenten von CoCuSe daran und stellt sie demgem vor. Alle Namen der CoCuSe-Klassen beginnen konsistent mit dem Namen CoCuSe, so dass auch au erhalb des Paketes de.fuh.csclportal.cocuse immer eine eindeutige Zuordnung erfolgen kann.

5.3.1 CoCuSe und globale Einstellungen

5.3.1.1 Klasse CoCuSe

Die Instanz von CoCuSe ben tigt grundlegend die Klasse CoCuSe. Sie erweitert die Klasse PersistentObject und sorgt daf r, dass jedes einzelne CoCuSe ber eine eindeutige Kennung zur Unterscheidung verf gt und ein Besitzer zugeordnet werden kann. Insbesondere hat die Kennung eine weitreichende Bedeutung f r den gesamten Betrieb, da sie von vielen anderen Teilen quasi als Filter eingesetzt wird - hierdurch wird u.a. sichergestellt, dass ein Lesezeichen im richtigen Kontext der zugeh rigen Web-Recherche behandelt wird.

5.3.1.2 Schnittstelle CoCuSeStatics

Wie in vielen anderen Projekten blich, so gibt es auch bei CoCuSe die eine oder andere Konstante, die immer wieder in weiten Teilen zur Anwendung kommt. Diese Konstanten sind zentral in dem Interface CoCuSeStatics zusammengefasst. Des weiteren finden sich hier auch gewisse Konfigurationsparameter wie z.B. die Einstellungen f r einen vorgelagerten Proxy-Server innerhalb des lokalen Netzwerkes. Neben der Verbesserung der bersichtlichkeit bietet diese Vorgehensweise auch den Vorteil, dass bei Bedarf Anpassungen nur an einer Stelle durchgef hrt werden m ssen. Vor allem aber wird die Lesbarkeit des Programms erh ht - ein Bezeichner wie Indexseitentyp ist allgemein verst ndlicher als ein Wert 1.

5.3.2 Seiten

5.3.2.1 Abstrakte Klasse CoCuSePage

Die abstrakte Klasse CoCuSePage erweitert die Klasse PlainTextPage und stellt damit einen Seitentyp f r CoCuSe bereit. PlainTextPage modelliert die Datenstrukturen eines einfachen standardisierten Seitentyps in CURE. Die Objekte der Klasse CoCuSePage werden nicht direkt verwendet, vielmehr dient diese Klasse als Basis f r die konkreten Seitentypen, welche im Folgenden beschrieben werden. Es werden hier also lediglich die gemeinsamen Grundlagen aller Seitentypen zentral festgelegt.

5.3.2.2 Klasse CoCuSeIndexPage

Wie der Name bereits vermuten l sst, wird in der Klasse CoCuSeIndexPage der Seitentyp Index als Erweiterung der abstrakten Klasse CoCuSePage konkretisiert. Die Index-Seite nimmt eine zentrale Rolle ein, da sie wie weiter oben ausgef hrt aus Sicht des Anwenders die erste Anlaufstelle einer kooperativen Web-Recherche darstellt. Dementsprechend weitreichend sind die Methoden, welche in dieser Klasse angegeben sind. So wird beispielsweise beim Anlegen einer CoCuSe-Indexseite eine neue Instanz von CoCuSe erzeugt, d.h. neben der Index-Seite selbst entsteht ein neues CoCuSe-Objekt und der zugeh rige Navigator. Im umgekehrten Fall des L schens einer Index-Seite wird folgerichtig auch alles andere, was damit verbunden ist, ebenfalls gel scht. Dies umfasst sodann neben der Index-Seite auch CoCuSe, Navigator, sowie s mtliche Lesezeichen und weiter unten aufgef hrte Hintergrundobjekte. F r diesen und andere Zwecke werden entsprechende Methoden bereitgestellt, um z.B. die zu einem Index geh renden Favoriten und Ergebnisse zur ckzuliefern.

5.3.2.3 Klasse CoCuSeNavigatorPage

Eine weitere konkrete Implementierung der abstrakten Klasse CoCuSePage ist die Klasse CoCuSeNavigatorPage. Hierdurch wird die zu jedem Index geh rende Navigator-Seite abgebildet. Da der Navigator von der Idee her lediglich ein universelles Werkzeug zum Navigieren im Internet darstellt und nicht speziell auf eine Internetseite fixiert ist, werden an dieser Stelle nur wenige Informationen, wie z.B. die Kennung der Index-Seite, ben tigt.

5.3.2.4 Klasse CoCuSeBookmarkPage

Lesezeichen werden mit Hilfe der Klasse CoCuSeBookmarkPage implementiert, welche ebenfalls die Klasse CoCuSePage erweitert. Eine Bookmark-Seite steht in einem komplexeren Zusammenhang, da sie einerseits in Beziehung zum Index steht, andererseits aber auch eine zugeordnete Internetseite in Form einer CoCuSeURL (siehe nachfolgende Abschnitte) und weiterer damit verbundener Objekte besitzt. Ein Bookmark-Objekt muss entsprechend daf r Sorge tragen, dass etwa beim Anlegen bzw. L schen auch die Objekte im Hintergrund erzeugt bzw. entfernt und Verkn pfungen aktualisiert werden. Die Interpretation eines Lesezeichens als Favorit oder Ergebnis wird mit Hilfe des Lesezeichentyps definiert - es braucht daher nur eine CoCuSeBookmarkPage f r beide Arten, was etwa eine Aufteilung in CoCuSeFavouritePage und CoCuSeResultPage berfl ssig macht. Vorteilhaft ist diese Vorgehensweise speziell beim Wechsel zwischen den Arten. Das Anlegen eines Ergebnisobjektes, die bergabe der verkn pften Internetadresse und das anschlie ende L schen des Favoritobjektes entf llt damit v llig. Besonders kostspielige Programmaktivit ten werden vermieden.

5.3.3 Internetadressen, Links und Bewertungskommentare

Hinter jedem Lesezeichen, also einem Objekt der Klasse CoCuSeBookmarkPage, verbirgt sich exakt eine Internetadresse und beliebig viele diesbez gliche Links und Bewertungskommentare. Diese drei Objektarten werden wie folgt umgesetzt.

5.3.3.1 Klasse CoCuSeURL

Die Klasse CoCuSeURL repr sentiert Internetadressen (Uniform Resource Locator, kurz URL), welche in Beziehung zu Lesezeichen stehen. Ein Lesezeichen steht dabei mit genau einem Objekt vom Typ CoCuSeURL in Verbindung. Neben der verwalteten Internetadresse stellt CoCuSeURL auch einen Bezug zu eventuell vorhandenen Links und Bewertungskommentaren. Von daher stehen Methoden bereit, welche neben dem Zugriff auf die hinterlegte Adresse auch Informationen zu Links und Bewertungen bieten. Auch hier ergibt sich durch die komplexeren Verbindungen eine Verwaltungsverantwortung z.B. beim L schen einer CoCuSeURL derart, dass ebenfalls existierende Links und Bewertungen entfernt werden.

5.3.3.2 Klasse CoCuSeLink

Ein Link wird ber die Klasse CoCuSeLink implementiert. hnlich einer CoCuSeURL ist ein Link im Prinzip eine Internetadresse, jedoch wird ein Link nicht isoliert, sondern vielmehr im Bezug zu einer weiteren Internetadresse, hier CoCuSeURL, interpretiert. Gem der Vorstellung eines gerichteten Graphen hat ein Link eine Richtung. Diese wird erneut mit Hilfe eines Wertes gespeichert, der entweder eine Interpretation der Verkn pfung als eingehenden bzw. ausgehenden Link erlaubt. Hierdurch kann ein universelles Link-Objekt f r beide Arten verwendet werden. Jeder CoCuSeLink kennt seine zugeh rige CoCuSeURL, dies ist erforderlich, da sich mehrere Links auf eine URL beziehen k nnen.

5.3.3.3 Klasse CoCuSeRating

Jede CoCuSeURL kann von den Gruppenmitgliedern einen oder mehrere Bewertungskommentare erhalten, welche sich hinter der Klasse CoCuSeRating verbergen. Eine Bewertung (englisch Rating) setzt sich aus einer hinterlegten Bewertungszahl (Note) und einem Bewertungstext (Kommentar) zusammen - diese beiden bilden eine Einheit. Im Falle der Bewertung ist der Bezug zum Autor nat rlich von besonderer Bedeutung. Dieser wird f r weitere Zwecke entsprechend vermerkt, ebenso wird das Erstellungsdatum der Bewertung festgehalten. Diverse bereitgestellte Methoden bieten den Zugriff auf diese Informationen an.

5.3.4 Langzeitged chtnis

5.3.4.1 Klasse CoCuSeActivity

Zur Implementierung des Elephant’s Brain aus Kapitel 4.2.2 dient die Klasse CoCuSeActivity als Erweiterung der Klasse Activity. Benutzeraktivit ten werden mit Hilfe dieser Klassen persistent vorgehalten. In der Erweiterung werden spezielle Aspekte von CoCuSe ber cksichtigt wie z.B. Zugriffsart und Internetadresse. Dar ber hinaus stehen Methoden bereit, welche ber den letzten Zugriff auf ein Artefakt ausf hrlich Auskunft geben.

5.4 View

Nachdem nun die Datenstruktur von CoCuSe mit Hilfe des Modells abgebildet ist, geht es im weiteren Verlauf um die Repr sentation bzw. Visualisierung der Daten durch passende Sichten in Form von View-Komponenten.

5.4.1 Seitendarstellungen

5.4.1.1 Klasse CoCuSePageHTMLRenderer

Die Klasse CoCuSePageHTMLRenderer ist eine Erweiterung des PageHTMLRenderer. In Analogie zur Seitenmodellierung dient diese Klasse als gemeinsame Basis der jeweiligen Renderer der Seitentypen. Es werden Methoden bereitgestellt, die mehrfach ben tigt werden. Hierzu z hlen unter anderem die Darstellung der Index-Schaltfl che, des iFrame f r externe Inhalte oder einer Zugriffsliste. Bei Bedarf brauchen nderungen also nur zentral an dieser Stelle durchgef hrt zu werden.

5.4.1.2 Klasse CoCuSeIndexPageHTMLRenderer

F r die Darstellung einer Seite vom Typ CoCuSe-Index ist die Klasse CoCuSeIndexPageHTMLRenderer zust ndig, welche den CoCuSePageHTMLRenderer erweitert. Zum Einen wird eine Vorlage bereitgestellt, welche f r nderungen wie z.B. Name oder Beschreibung der Seite durch den Anwender genutzt wird und Eingabefelder bietet, die mit eventuell vorhandenen Daten aufgef llt sind. Zum Anderen sorgt eine weitere Vorlage f r die Anzeige der regul ren Seite. Gem Kapitel 4.3 besteht eine Index-Seite, abgesehen von der CURE-Umgebung, im Wesentlichen aus den beiden Bereichen f r Favoriten und Ergebnisse. Es gibt hierf r Listendarstellungen, welche die Lesezeichen alphabetisch nach ihrem Namen geordnet auflisten. Jeder Name eines Lesezeichens ist mit der Funktion eines Links ausgestattet, so dass durch Anklicken eine zugeh rige Bookmark-Seite angesteuert werden kann. Die Zusammenstellung der Liste wird mit Hilfe eines zu bergebenen Parameters wahlweise auf Favoriten oder Ergebnisse beschr nkt, so dass keine spezialisierten Methoden f r jeden Lesezeichentyp erforderlich sind. F r die Eingabe einer neuen Internetadresse steht im oberen Teil des Fensters, genauer gesagt in der sog. PageToolBar (Seitenfunktionsleiste), ein entsprechendes Eingabefeld bereit, das die URL entgegennimmt - es wird entweder eine Standardinternetadresse, welche in CoCuSeStatics festgelegt wird, oder die zuletzt besuchte Internetadresse voreingetragen. Der Anwender kann daran auch ablesen, in welchem Format eine Adresse erwartet wird. Vielfach bewegt man sich auf hnlichen Adressen, so dass der vorgegebene Eintrag lediglich entsprechend ge ndert werden braucht - dies reduziert die Zahl der einzugebenden Zeichen und beschleunigt dadurch den Navigationsprozess.

5.4.1.3 Klasse CoCuSeNavigatorPageHTMLRenderer

Die Anzeige des Navigator wird von der Klasse CoCuSeNavigatorPageHTMLRenderer bernommen, die ebenfalls CoCuSePageHTMLRenderer erweitert. Auch die Navigator-Seite bietet ber die Anzeigevorlage im oberen Bereich ein Eingabefeld f r eine neue Internetadresse - der Standardeintrag erfolgt gem dem im vorhergehenden Abschnitt beschriebenen Verfahren. Links davon erscheint die in Kapitel 5.4.1.1 bereits erw hnte Index-Schaltfl che in Form eines blauen Symbols mehrerer Personen, wor ber der Navigator verlassen und zum zugeh rigen Index gewechselt werden kann. Darunter steht ein weiteres Eingabefeld f r die Aufnahme des Namens f r das neu anzulegende Lesezeichen bereit. Die Schaltfl che aktiviert das Erzeugen einer Bookmark-Seite mit diesen Daten. In der n chsten Zeile wird die aktuelle Internetadresse angezeigt und darunter schlie t sich der iFrame an, in dem eine externe Internetseite zu dieser Adresse dargestellt wird. Die eigentliche Darstellung dieser Internetseite ist nicht Aufgabe des Navigators. Per Definition im Standard HTML 4.0 wird dem iFrame [W3C 1999] eine anzuzeigende Quelle bergeben, welche jedoch technisch einer separaten Internetseite bzw. -adresse entspricht. Im Falle von CoCuSe ist dies ein direkter Verweis auf ein Servlet von CoCuSe, wobei die gew nschte externe Quelle als Parameter bergeben wird - f r den korrekten Betrieb von CoCuSe ist es zwingend erforderlich die Kontrolle zu behalten, um etwa auf einer Seite enthaltene Links zu verarbeiten. Unterhalb des iFrame folgen Bl cke mit Informationen ber eventuell anwesende Mitglieder oder fr here Besucher der Internetseite - liegen keine Informationen diesbez glich vor, so fehlt der entsprechende Textblock. Der Benutzername wird mit einem Link versehen, so dass die sog. Minihomepage des Benutzers erreicht und dort etwa vorhandene Kommunikationswege genutzt werden k nnen. Jeder Block widmet sich einem Informationsthema, hier also Anwesenden und Besuchern. Bei aktiviertem JavaScript sind die Bl cke eingeklappt und der Anwender sieht eine kurze Zusammenfassung, d.h. Icons f r Anwesende bzw. Namen f r Besucher. Durch Anklicken des Blocktitels kann jeder Block separat ausgeklappt werden, so dass erweiterte Zusatzinformationen sichtbar werden. Alternativ existiert rechts direkt unterhalb des iFrame die M glichkeit das Ein- bzw. Ausklappen aller Bl cke gleichzeitig zu schalten. Ist JavaScript deaktiviert, so werden die Bl cke ausgeklappt angezeigt, lassen sich dann jedoch nicht einklappen. Somit erhalten alle Benutzer die vollen Informationen, unabh ngig von der jeweiligen JavaScript-Konfiguration im Browser.

5.4.1.4 Klasse CoCuSeBookmarkPageHTMLRenderer

Der letzte verbleibenden Seitentyp Bookmark wird durch die Klasse CoCuSeBookmarkPageHTMLRenderer als Erweiterung der Klasse CoCuSePageHTMLRenderer repr sentiert. Wie schon bei der Index-Seite kann auch im Falle der Bookmark-Seite ber eine Vorlage dem Anwender die M glichkeit zur nderung von Name und Beschreibung gegeben werden. Die Darstellung der Bookmark-Seite bietet oben in der Mitte erneut links die Index-Schaltfl che, sowie rechts davon das Eingabefeld f r eine neue Internetadresse. Darunter folgt der Name des Lesezeichens, sowie dessen Beschreibung, Art und die referenzierte Internetadresse. Erstere Informationen stammen aus den Bookmark-Daten, die Internetadresse hingegen wird aus dem verkn pften URL-Objekt ausgelesen. Wie beim Navigator in Kapitel 5.4.1.3 folgt der iFrame mit dem Verweis ber CoCuSe auf die eigentliche Internetadresse, welche innerhalb des iFrame angezeigt wird. Unter dem iFrame folgt optional ein Informationsblock zu aktuell anwesenden Personen. Des weiteren kommt ein Block zu fr heren Besuchern, welcher trivialerweise immer vorhanden ist, da eine Internetseite nur als Bookmark abgelegt werden kann, falls sie zuvor mit Hilfe des Navigator besucht worden ist. Die Zusammenfassung zeigt lediglich den letzten Besucher, w hrend durch Ausklappen der erweiterten Informationen eine Liste aller Besucher erscheint. Der n chste Block der Bewertungskommentare gibt sodann das Bewertungsprofil wieder. Hierzu wird ermittelt, wie viele Mitglieder die Gruppe hat und welche davon eine Bewertung hinterlassen haben. Des weiteren wird au erdem berechnet, wie viel Prozent aller Bewertungen positiv sind. Unterhalb des Profils folgt im ausgeklappten Zustand des Blocks eine tabellarische Aufstellung abgegebener Bewertungen bestehend aus Note - diese wird in Form einer graphischen Repr sentation als +,- oder * dargestellt - , Kommentar, Autor und Datum, welche aus den Rating-Objekten gewonnen werden. Hat der Anwender selber noch keine Bewertung f r dieses Lesezeichen abgegeben, so wird eine entsprechende Schaltfl che auf der rechten Seite eingeblendet, welche den Bewertungsschritt (siehe weiter unten) einleiten kann. Ist jedoch bereits eine Bewertung abgegeben worden, so fehlt die Schaltfl che, da Mehrfachbewertungen eines Gruppenmitgliedes nicht erw nscht sind.

5.4.2 Bewertungsformular

5.4.2.1 Klasse CoCuSeRatingAttributesRequestRenderer

Bevor ein neuer Bewertungskommentar zu einem Lesezeichen angelegt werden kann, m ssen die notwendigen Daten erfasst werden. Hierzu bedarf es der Eingaben durch den Anwender. Da Bewertungen (englisch Ratings) aber nicht als eigenst ndige Seitentypen, sondern als Hintergrundobjekte einer URL modelliert sind, kommen die bisher gezeigten Methoden zur Erfassung bzw. Erstellung nicht in Betracht. Die Klasse CoCuSeRatingAttributesRequestRenderer bernimmt die Aufgabe der Eingabeaufforderung, wozu die Klasse ComponentHTMLRenderer erweitert wird. Eingebettet in die bliche CURE-Umgebung besteht der Inhaltsbereich aus zwei Teilbereichen, welche insgesamt ein Formular zur Datenerfassung bilden. Das obere gro e Eingabefeld bietet viel Platz f r die Eingabe des Bewertungskommentars. Darunter kann der Anwender seinen Kommentar als Bewertungsnote zusammenfassend auf den Punkt bringen. Die Note wird zum Einen graphisch mittels Symbolen f r +,- und *, sowie zum Anderen als den Notenwert beschreibenden Text f r positiv, negativ und neutral repr sentiert. Durch den Einsatz von Kn pfen, sog. Radio-Buttons [W3C 1999], wird die exklusive Auswahl eines Notenwertes erm glicht - im Gegensatz zu ankreuzbaren Quadraten, den sog. Checkboxen [W3C 1999], wird somit die gleichzeitige Auswahl mehrerer Notenwerte durch den Anwender mit Hilfe des HTML-Sprachstandards verhindert. Unterhalb eines kurzen Hinweistextes zur Benutzung des Bewertungsformulars befinden sich abschlie end die Schaltfl chen zum Absenden der Formulardaten an CoCuSe und zum Abbrechen dieser Aktion, wodurch entweder die Erzeugung der Bewertung und nachfolgende Bindung an das Lesezeichen angesto en oder aber zur Darstellung des unver nderten Lesezeichens zur ckgekehrt werden kann.

5.4.3 Proxyfehlermeldungen

5.4.3.1 Klasse CoCuSeProxyErrorHTMLRenderer

Einen besonderen Zweck erf llt die Klasse CoCuSeProxyErrorHTMLRenderer, welche die Klasse SimpleHTMLRenderer erweitert. Dieser steht im Zusammenhang mit einer speziellen Situation, welche sich in m glichen Fehlersituationen innerhalb der iFrame-Darstellungen ergeben kann. Wie bereits beschrieben bettet der iFrame eine andere Internetseite in eine CoCuSe-Seite ein. Hierdurch ist gew hrleistet, dass die CURE-Umgebung immer vorhanden ist und weitere Schaltfl chen und Funktionen im direkten Zugriff des Anwenders bleiben. Innerhalb des iFrame werden von CoCuSe angepasste Inhalte von Internetseiten angezeigt, entsprechend unerw nscht sind in diesem Bereich Elemente der CURE-Umgebung. Kommt es nun beim Versuch der Bearbeitung bzw. Anzeige einer Internetseite innerhalb des iFrame zu einer Fehlersituation, welche nicht automatisch aufgel st werden kann, so sind die von CURE bereitgestellten Methoden nicht optimal. Es kann z.B. bei einer nicht mehr existierenden Internetseite vorkommen, dass CURE zwar eine typische Fehlermeldung anzeigt, diese aber mehr oder weniger viele Elemente der CURE-Umgebung enth lt. W hlt der Anwender darin beispielsweise die Schaltfl che zum Wechsel auf die Homepage des Raumes, so entsteht eine CURE-Umgebung innerhalb der CURE-Umgebung, welche den iFrame enth lt. Dies ist verst ndlicherweise nicht erw nscht und w rde den Benutzer in seiner T tigkeit nicht unterst tzen. Nebenbei k nnen nicht alle Fehlersituationen, wie sie etwa im Betrieb des CoCuSe-Proxy auftreten, von CURE abgefangen werden - eine externe Internetseite liegt beispielsweise au erhalb des blichen Zust ndigkeitsbereiches. In einigen speziellen Situationen bliebe ein iFrame auch m glicherweise v llig leer. Um diese unterschiedlichen F lle zusammenzufassen und eine weitgehend universelle L sung f r Fehlersituationen anzubieten stellt CoCuSeProxyErrorHTMLRenderer einen praktikablen Kompromiss dar. Fehler werden als solche visualisiert und auf das Wesentliche beschr nkt. Dem Anwender wird die Nummer des Fehlers und wenn m glich ein Zusammenhang zum Artefakt bzw. der beteiligten Komponente mitgeteilt - insbesondere wird ein leerer iFrame oder eine rekursive Darstellung der CURE-Umgebung weitm glich verhindert.

5.4.4 Gruppenbewusstsein

Zur Darstellung von Informationen bzgl. des Gruppenbewusstseins kommt eine spezielle Klasse zum Einsatz, welche durch ihre Dienste andere Klassen unterst tzt.

5.4.4.1 Klasse CoCuSeLocalAwarenessView

Der Presence Indicator f r Local Awareness wird durch die Klasse CoCuSeLocalAwarenessView bereitgestellt, welche die Klasse PresenceIndicatorView erweitert. Das Channel-Konzept von CURE kommt hierbei zum Einsatz und wird in den Klassen CoCuSePage und CoCuSePageHTMLRenderer verwendet.

5.5 Controller

Nachdem die Daten modelliert und die Sichten darauf beschrieben sind, fehlt noch der Blick auf die Steuerungslogik von CoCuSe, um das Bild der Implementierung zu vervollst ndigen.

5.5.1 Steuerung allgemeiner Abl ufe

5.5.1.1 Klasse CoCuSeServlet

Die erste Controller-Einheit bildet die Klasse CoCuSeServlet, welche die Klasse StatefullServletWithIDs erweitert. Sie bettet sich nahtlos in CURE ein und ist in CoCuSe f r die grundlegende Koordination zust ndig - man k nnte CoCuSeServlet auch als Steuerzentrale bezeichnen. Eine der wesentlichen Aufgaben ist es dabei f r die passende Darstellung zu sorgen. Die Darstellung einer CoCuSe-Seite wird, wie bereits gesehen, nicht von diesem Controller bernommen, vielmehr werden Benutzeranfragen interpretiert und delegiert. In der Praxis wirkt sich dies aus Sicht des Anwenders so aus, dass bei der Navigation durch das WWW durchaus zwischen der Darstellung einer Internetseite im Rahmen einer Navigator- oder einer Bookmark-Seite gewechselt wird. CoCuSe berechnet bei der Anwahl der n chsten anzuzeigenden Internetseite, ob und in welcher Form diese Adresse bereits in der Web-Recherche vorliegt. Um ein eventuell bereits existierendes Lesezeichen nicht unn tig mehrfach anzulegen, wird die Internetseite sodann direkt ber die Bookmark-Seite angezeigt und nicht die Navigator-Seite verwendet. Umgekehrt kann es vorkommen, dass innerhalb der Bookmark-Seite ein Link angew hlt wird, welcher zu einer bisher nicht gespeicherten Seite f hrt. In diesem Fall wird die Bookmark-Darstellung verlassen und auf den Navigator umgeschaltet. Dar ber hinaus k mmert sich dieses Servlet auch um Aspekte wie das Bewertungsformular oder das Anlegen von Bewertungen und die Aktualisierung der Bewertungsprofildaten, sowie der Ergebnis-Seite. Ferner werden gewisse Aufgaben, die im Zusammenhang mit externen Inhalten stehen, an den CoCuSe-Proxy bergeben, welcher im n chsten Abschnitt n her betrachtet wird.

5.5.2 Steuerung externer Zugriffe

5.5.2.1 Klasse CoCuSeProxyServlet

Hinter der Klasse CoCuSeProxyServlet, welche die Klasse StatefullServletWithIDs erweitert, verbirgt sich der sog. CoCuSe-Proxy. Dieser ist f r alle koordinierenden Arbeiten im Zusammenhang mit externen Inhalten wie Internetseiten zust ndig. Da sich dieser Controller nur mit Aspekten au erhalb der urspr nglichen CURE-Funktionalit t besch ftigt, sieht der Anwender diese Komponente entsprechend nicht, sondern bekommt lediglich die sich ergebenen Auswirkungen pr sentiert. Optisch hei t dies vereinfacht gesprochen, dass es sich dabei um Inhalte des iFrame auf Navigator- bzw. Bookmark-Seite handelt. Eine Anfrage zur Beschaffung externer Inhalte wird dazu zun chst analysiert. Dies umfasst sowohl die Frage nach einem g ltigen Format der Anfrage als auch nach dem Typ des Inhaltes bezogen auf die Internetadresse. Beispielsweise kann ein Bild im GIF-Format direkt vom Browser angezeigt werden, w hrend eine HTML-Seite bearbeitet werden muss, bevor sie angezeigt wird. Bei ung ltigem Format oder einer nicht mehr vorhandenen Internetseite wird eine Fehlermeldung ausgegeben - die in Kapitel 5.4.3.1 beschriebene Komponente wird hierzu eingesetzt. Diese Tests sind erforderlich, da im Navigator/Bookmark verschiedenste Internetinhalte dargestellt werden k nnen - dies kann z.B. durchaus auch ein Adobe PDF-Dokument sein, ein entsprechendes Browser-Plugin vorausgesetzt - theoretisch kann jede URL und damit jeder unterst tzte Typ verarbeitet werden. Eine explizite Protokollierung der in diesem Zusammenhang stehenden Benutzeraktivit ten wird ebenfalls durchgef hrt.

Im besonderen Falle einer Internetseite vom Typ HTML folgen weitere Bearbeitungsschritte. Neben der Ermittlung des zugeh rigen Navigator und der Beschaffung der Quelldaten aus dem Internet, ist vor allem die bergabe der Daten und der Aufruf der im folgenden Abschnitt beschriebenen Komponente eine der wichtigsten Aufgaben dieses Servlet.

5.5.3 Verarbeitung externer Inhalte

5.5.3.1 Klasse CoCuSeUrlSourceLinkVisitor

Alle Verarbeitungsschritte in Bezug auf die Modifikation und Erfassung von HTML-Inhalten werden von der Klasse CoCuSeUrlSourceLinkVisitor als Erweiterung der Klasse NodeVisitor gesteuert. Der Quelltext der bergebenen HTML-Seite wird dabei vollst ndig durchlaufen und f r unsere Zwecke angepasst. Im Detail ist dies ein sehr umfangreicher Prozess, welcher vereinfacht gesprochen z.B. vorhandene Links durch andere ersetzt, so dass nicht mehr direkt die eigentliche Internetadresse angesteuert wird, sondern diese zur weiteren Verarbeitung an CoCuSe bermittelt wird.

Zur Vermeidung unn tiger Mehrfachverarbeitung werden die Links hier jedoch nicht einfach nur auf CoCuSe umgelenkt, sondern direkt in den passenden Kontext gestellt. Das hei t, dass ein in der Datenbank bereits vorhandenes Linkziel durch den Aufruf der zugeh rigen Bookmark-Seite oder ansonsten des passenden Navigator ersetzt und somit f r die Beibehaltung der CURE-Umgebung gesorgt wird. Des weiteren wird zu jedem Link bei Bedarf ein Presence Indicator f r Active Neighbours eingef gt, so dass der Anwender im Browserfenster rechts vom Link ein passendes Icon vorfindet, welches mit Hilfe eines kleinen PopUp-Fensterchens weitere Informationen anzeigt - ben tigtes JavaScript wird ebenfalls eingebunden. Am Ende der Seite kann zus tzlich noch Awareness-Information ber Anwesende auf anderen Seiten mit Link zu dieser Seite eingef gt werden.

Da zu diesem Zweck ohnehin alle Link-Informationen auf der Seite besucht werden m ssen, werden diese gleichzeitig mit dem Datenbestand an eingehenden und ausgehenden Links verglichen und aktualisiert. Auf diese Art und Weise k nnen f r die Lesezeichen nebenbei semantische Informationen aufbereitet werden, ohne dass hierzu ein zus tzlicher Arbeitsschritt erforderlich w re. Wie in Kapitel 4.2.7 ausf hrlich dargelegt, werden in dieser aktuellen Variante nur direkte Verkn pfungen ber cksichtigt, was die Komplexit t dieser Verarbeitungsfolgen erheblich vereinfacht und auch zu schneller vorliegenden Ergebnissen f hrt - anderenfalls m ssten die Links verfolgt, also die jeweiligen Zielinhalte aus dem Internet beschafft, und wiederum analysiert und bearbeitet werden. Im Falle des WWW kommt es nicht selten durch rekursive Verkn pfungen der Seiten zu potentiell unendlichen Link-Ketten, deren Erkennung und Umgehung weitergehende Technologie erfordern w rde - ganz abgesehen von der Tatsache, dass es ohne ad quate Begrenzungen zur Erfassung aller verbundenen Seiten des gesamten Internets kommen w rde, was in Bezug auf CoCuSe weder gew nscht, noch als sinnvoll erachtet ist.

5.6 bersicht der Funktionen und Abl ufe

Zum Abschluss der Betrachtungen zeigt Abbildung 5.6.a das grundlegende Schema der Funktionen. Es verdeutlicht die Abl ufe zwischen den wichtigsten Stationen im Verlauf einer kooperativen Web-Recherche in CURE. Neben den drei CoCuSe-Seitentypen werden die m glichen Aktivit ten darauf aus Sicht des Anwenders und die unmittelbar im Hintergrund beteiligten Komponenten pr sentiert.

Des weiteren veranschaulicht Abbildung 5.6.b die relevanten Vorg nge nach bergabe einer Internetadresse (URL) an CoCuSe-Proxy bis hin zur Darstellung des Inhaltes im Browser.

5.7 Anmerkungen zu Google

W hrend der Entwicklung von CoCuSe kam beim Testen der Applikation die Idee auch eine direkte Suche im Internet ber Google - der wohl popul rsten Suchmaschine unserer Zeit - anzubieten und somit den Gruppenprozess der kooperativen Web-Recherche in CURE zus tzlich zu unterst tzen. Bei n herer Auseinandersetzung mit der Google Web API [Google 2002], aber auch mit direkten Suchanfragen an die Suchmaschine, und den damit verbundenen Nutzungsbedingungen ist jedoch ganz bewusst eine Entscheidung gegen die Einbindung der Google-Suche gef llt worden.

Folgende Gr nde sprechen gegen eine sinnvolle Nutzung innerhalb von CoCuSe. Direkte Suchanfragen aus Java heraus, wie man sie in der Adresszeile eines Browsers nachlesen kann, gem dem Schema http://www.google.de/search?q=Suchbegriff&hl=de werden von Google herausgefiltert und mit einer Zugriffsverletzung quittiert. Diese Art der Nutzung will die Firma konsequent unterbinden, vermutlich auch um die Verwendung der API zu erzwingen.

Google beschr nkt die Nutzung der API gleich durch mehrere Begrenzungen. Der Zugriff auf den Suchdienst ist nur mit einem Schl ssel (englisch Key) m glich. Diesen kann man zwar gratis anfordern, jedoch wird dazu ein ebenfalls kostenfreies Benutzerkonto ben tigt - Google wei somit nicht nur, wer mit der API arbeitet, sondern auch was gesucht wird. Des weiteren werden im Zusammenhang mit diesem Schl ssel nur 1000 Anfragen pro Tag erlaubt - bei z.B. 250 Benutzern k nnen diese also lediglich 4 Anfragen stellen, was insbesondere durch die n chste Beschr nkung durchaus einen ernstzunehmenden Engpass darstellen kann. Zu jeder Anfrage liefert Google maximal 10 Treffer zur ck - jeder Anwender, der schon mal Suchanfragen gestellt hat, wird best tigen k nnen, dass man bei bestimmten Themen nicht innerhalb der ersten 10 Treffer f ndig wird. Eine sinnvolle Suche kann in der Praxis mit diesen Randbedingungen nicht durchgef hrt werden.

Aus Sicht der Implementierung innerhalb von CoCuSe kommt so dann ein erh hter Aufwand hinzu. Google liefert das Suchergebnis nicht als direkt darstellbare (HTML-)Internetseite zur ck. Dies mag f r gewisse Anwendungsf lle durchaus von Vorteil sein, allerdings hat dies f r CoCuSe einen entscheidenden Nachteil. Der CoCuSe-Proxy kann die Daten nicht einfach anfordern und wie alle anderen Internetseiten nachbearbeiten, also z.B. Links an die Umgebung anpassen. Vielmehr m sste speziell f r die Verarbeitung des Suchergebnisses weitere Programmlogik bereitgestellt werden, d.h. Controller- und View-Komponenten.

Die genannten Aspekte stehen im Widerspruch zum zu erwartenden praktischen Nutzen.

Start

0 Inhaltsverzeichnis

1 Einf hrung in die Aufgabenthematik

2 Analyse des Themenbereichs

3 Betrachtung von bestehenden Systemen

4 CoCuSe - Collaborative Cure Search

5 Implementierung in Java

6 Zusammenfassung und Ausblick

Anhang A: Verzeichnis der Abbildungen

Anhang B: Verzeichnis der Tabellen

Anhang C: Verzeichnis der Quellen und Referenzen

Anhang D: Softwaretechnische Anbindung an CURE

Anhang E: Inhalt der Begleit-CD