<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