Mechanismen zur synchronen und asynchronen Kollaboration in Digitalen Bibliotheken. David Kretschmer

Transkript

1 Mechanismen zur synchronen und asynchronen Kollaboration in Digitalen Bibliotheken David Kretschmer 24. November 2005

2 Inhaltsverzeichnis 1 Einleitung Motivation Thema dieser Arbeit Überblick über die Folgekapitel Grundlagen Das Daffodil-System Kommunikationsmechanismus Interaktion und Kommunikation Kollaboration und Kooperation Groupware Awareness Das Overlay-Modell Verwandte Arbeiten Mehrbenutzer-Werkzeuge in Daffodil Überblick Motivation Anwendungsgebiete Kategorisierung Die Raum-/Zeit-Matrix Das Co-Triangle Anwendungsorientierte Funktionsklassen Tauglichkeit des Daffodil-Frameworks Erweiterbarkeit Einschätzung Untersuchung bestehender Werkzeuge Das Such-Werkzeug Die Handbibliothek Autorennetzwerk Thesaurus ACM Klassifikationshierarchie Browsen in Konferenzen/Journalen Referenzen und Zitatsuche Extraktionswerkzeug Kategorisierung Ausblick auf weitere mögliche Werkzeuge Direkte Kommunikation

3 3.7.2 Werkzeuge zur gemeinsamen Wissensbildung Wissensmanagement und Diskussionen Tutor-Werkzeug Organisation der Kollaboration Sitzungsinitiierung Zugriffsregelung Awareness Modell & Persistenz Fehlererkennung Direkte Kommunikatioin per Chat-Werkzeug Überblick Motivation Grundlagen Anforderungen Wahl der Chat-Technologie Umsetzung Kommunikation Anmeldevorgang Der Roster Mutual Subscription Erhalt neuer Nachrichten Grafische Umsetzung des Chat-Tools Persistenz und Logging Austausch von Daffodil-Objekten Administration Das WhiteBoard-Werkzeug Überblick Motivation Existierende Werkzeuge Szenario Anforderungen Implementierung der Werkzeugs Der JGraph MatchMaker Integration Das Daffodil-Reference-Frame Das WhiteBoard-Tool von Daffodil Awarenessfunktionen Persistenz der Sessions Speichern Laden Metainformationen Implementationsdetails Chat Tool Klassendiagramme Chat Das Jabber-Protokoll XML-Nachrichten des Chat

4 6.1.4 Möglichkeiten des IJabberClient Whiteboard-Tool Klassendiagramme Whiteboard-Tool Klassendiagramme Whiteboard-Palette Zusammenfassung & Ausblick Erreichte Ziele Verbleibende Arbeit Ausblick JabberUserManager Palette für Dokumenterstellung Einladen zu einer Sitzung Öffnen mehrerer Whiteboards Anhang 91 Literaturverzeichnis Abbildungsverzeichnis Listings Eidesstattliche Erklärung

5 Kapitel 1 Einleitung 1.1 Motivation Reale Bibliotheken bieten neben ihrem Informationsangebot Besuchern auch die Möglichkeit, sozial mit anderen Personen zu interagieren. Diese Interaktion reicht von Fragen an den Bibliothekar über Gespräche in einer Kantine oder der Warteschlange bis hin zur Gruppenarbeit in speziell hierfür eingerichteten Räumen, in denen Benutzer gefundenes Wissen diskutieren und gemeinsam auswerten können. Eine solche Art der Interaktion und des Austausches von Informationen kann nach Ackerman als Kleber für die Gemeinschaft [1] bezeichnet werden. Mit dem Aufkommen Digitaler Bibliotheken wird dem Benutzer eine Unmenge an Wissen direkt zugänglich gemacht, ohne dass er seinen Arbeitsplatz verlassen muss. Die bisher vorhandenen Interaktionsmöglichkeiten fehlen jedoch zumeist in aktuellen Umsetzungen Digitaler Bibliotheken, sodass der aus ihnen bisher entstandene Mehrwert verloren geht. Die Frage ist, worin dieser Mehrwert genau besteht und welche Vorteile die Integration von Mechanismen zur Unterstützung von Benutzerinteraktion, vor allem im Rahmen von Gruppenarbeit, mit sich bringt. Außerdem ist zu klären, wie diese Mechanismen implementiert werden können, um sie möglichst umfassend und intuitiv nutzen zu können. 1.2 Thema dieser Arbeit Die Aufgabe dieser Diplomarbeit ist es, Einsatzmöglichkeiten für synchrone Interaktions- und Kollaborations-Werkzeuge in Daffodil, einem Zugangssystem zu Digitalen Bibliotheken, zu finden und sie auf ihre Durchführbarkeit und Verwendbarkeit hin zu untersuchen. Die Kollaboration (siehe Abschnitt 2.2.1) soll dabei über einen rein asynchronen Austausch von Dokumenten und Annotationen, wie er bisher meist genutzt wird [2, 3], hinausgehen und auch synchrone Kommunikation und Zusammenarbeit erlauben. 4

6 Dies soll den in Abschnitt 2.2 beschriebenen Mehrwert, der durch die Nutzung synchroner Interaktion entsteht, auch im Umfeld der Digitalen Bibliotheken nutzbar machen. Somit lässt sich das Thema dieser Arbeit wie folgt in drei Aufgaben aufteilen: Zuerst bleibt zu klären, welche Vorteile generell durch Unterstützung von Interaktion gewonnen werden können und wie die bestehenden Daffodil-Werkzeuge im Hinblick auf diese Interaktion erweitert werden können. Um grundlegende Möglichkeiten direkter, informeller Kommuniktaion zu schaffen, ist der synchrone Austausch von Wissen und Informationen durch die Implementierung eines Werkzeuges zur direkten Kommunikation (Chat) zu ermöglichen. Als Letztes soll eine konkrete Implementierung eines synchronen Mehrbenutzer-Werkzeugs (MUT) zur Wissensbildung in Daffodil vorgenommen werden. Zu diesem Zweck wird ein WhiteBoard-Werkzeug erstellt. 1.3 Überblick über die Folgekapitel Bevor die oben genannten Aufgaben in den Folgekapiteln der Reihe nach behandelt werden, sind zuerst einige Grundlagen im Zusammenhang mit Daffodil und Interaktion in Arbeitsgruppen aufgeführt. Details zur Implementierung, sowie Diagramme und Codebeispiele sind im Kapitel 6 zusammengefasst. In Kapitel 7 wird dann eine Zusammenfassung der erreichten Ziele und ein kurzer Ausblick auf die möglichen weiteren Schritte gegeben. 5

7 Kapitel 2 Grundlagen 2.1 Das Daffodil-System Durch die Entstehung Digitaler Bibliotheken (im Folgenden DL genannt) ist das in ihnen gespeicherte Wissen zwar weltweit abrufbar, dennoch ergeben sich bei der Suche in ihnen eine Reihe von Problemen. So existiert zum Beispiel kein allgemein verwendeter Aufbau der Sucheingabe oder eine von allen Anfrageinterfaces gleichermaßen unterstützte Anfragesprache, was das parallele Arbeiten mit mehreren DLs erschwert. Wünschenswert wäre außerdem die Möglichkeit, die Ergebnislisten mehrerer DLs zu kombinieren und so einen besseren Überblick über die verfügbaren Dokumente zu erhalten. Oft fehlen Unterstützungsmechanismen, die dem Benutzer bei der strategischen Suche helfen, indem sie Vorschläge für die Verbesserung der Suchanfrage liefern oder die Informationen vorangegangener Suchen nutzen. Ebenso gibt es kaum DLs, die Möglichkeiten zur Bildung von Benutzer- oder Gruppenprofilen oder Ablage von gefundenen Dokumenten in einer persönliche Handbibliothek bieten. Hier setzt das Projekt Daffodil an, welches ein plattformunabhängiges, nutzerorientiertes Zugangssystem für die Arbeit mit heterogenen Digitalen Bibliotheken darstellt. Der Benutzer arbeitet hierbei auf dem Daffodil-Desktop, der grafischen Benutzerschnittstelle, die als Ablagefläche für die einzelnen Werkzeuge dient. Die Grundfunktion des Desktops ist die gleichzeitige Suche nach Publikationen in verschiedenen Digitalen Bibliotheken und anderen Informationsquellen im Internet. Hierbei bietet Daffodil strategische Unterstützung, zum Beispiel durch proaktive Dienste, welche eine automatische Vervollständigung von Begriffen oder Rechtschreibprüfung während der Eingabe vornehmen, oder Hilfsmittel wie dem Thesaurus-Werkzeug, welches zu einem Wort artverwandte Suchbegriffe liefert. Für jede Suchanfrage generiert das System mit Hilfe von Agenten passende Anfragen für die gewählten Quellen, sammelt die Ergebnisse und führt eine erste Aufbereitung (Ranking und Elimination von Duplikaten) durch. Dies ermöglicht einen gleichbleibenden und benutzerfreundlichen Zugang zu den Quellen. 6

8 Abbildung 2.1: Ansicht des Daffodil-Desktop Für die Eingabe der Anfrage und die Anzeige des Ergebnisses ist das Suchwerkzeug zuständig (Abbildung 2.1 (2)). Das Ergebnis einer Suche wird dem Benutzer als Liste der gefundenen Dokumente geliefert. Zu jedem Eintrag kann eine Detailansicht geöffnet werden, die alle wichtigen Informationen enthält. Jeder Benutzer besitzt außerdem eine Handbibliothek (PLib oder Personal Library, Abbildung 2.1 (3)), in der er die gefundenen Dokumente in einer Ordnerstruktur ablegen und für eine spätere Weiterbearbeitung aufbewahren kann. Des weiteren bietet Daffodil eine Reihe von Werkzeugen, die es ermöglichen, die gefundenen Daten weiter zu bearbeiten (Abbildung 2.1 (1)). Auch kann der Benutzer in der Handbibliothek abgelegte Dokumente durch Annotationen um Metadaten erweitern. Zur Personalisierung kann der Benutzer die Anzahl der Werkzeuge, sowie das generelle Aussehen des Daffodil-Desktops auf seine Bedürfnisse anpassen. Durch das Erstellen von Arbeitsgruppen und das Zuordnen von Benutzern entsteht eine Basis für Gruppenarbeit. Jede Gruppe erhält, analog zu den Einzelbenutzern, eine Gruppenbibliothek, in welcher mit Hilfe des Annotationswerkzeugs in einer Thread-Struktur, ähnlich der eines Forums, auf asynchronem Weg Kommunikation und Gruppenarbeit stattfinden kann. 7

9 2.1.1 Kommunikationsmechanismus Daffodil liegt eine Client-Server-Struktur zu Grunde, in der der Client (Frontend) auf dem Rechner des Benutzers gestartet wird und mit dem Server (Backend) über XML-Nachrichten kommuniziert. Die grundlegende Kommunikationsstruktur ist in Abbildung 2.2 dargestellt. Der blau umrandete Bereich (1) ist das Daffodil-Backend. Die hier eingesetzten, internen Agenten kommunizieren mittels CORBA [4] untereinander, sowie mit den Wrappern, welche für die Weitergabe der Anfragen an die Digitalen Bibliotheken und Datenbanken zuständig sind. Die hierbei verwendeten Nachrichten sind in XML verfasst und basieren auf KQML [5]. Sie haben, je nach Verwendungszweck, unterschiedliche Typen (Performatives), die ihren Zweck (z.b. Suchanfrage des Suchtools oder Bitte um Ablage eines Dokumentes in der PLib) beschreiben und lassen sich dem Versender über eine eindeutige ID zuordnen. Diese ID bestimmt eindeutig die Instanz des Daffodil-Clients und ist somit nicht alleine an die ID des Benutzers gebunden. Daher ist es möglich, dass ein Benutzer mit mehreren Frontends gleichzeitig im Daffodil-System arbeitet. Die Agenten des Daffodil-Clients werden auch als externe Agenten bezeichnet und sind in der Grafik rot umrandet (3). Die Kommunikation zwischen externen und internen Agenten geschieht über HTTP (2). Abbildung 2.2: Die grundlegende Struktur der Kommunikation in Daffodil Meldet sich ein Benutzer am System an, so erzeugt der UserAgent eine User- 8

10 AgentRequest, welcher den Benutzer im Backend repräsentiert. Alle Werkzeuge des Daffodil-Desktops stellen ihre Anfragen an einen entsprechenden im Backend laufenden Service. So schickt das Such-Werkzeug seine Anfrage zum Beispiel an den DocumentAgent, welcher für die Bearbeitung der Metadatensuche und die Aufteilung der Anfrage auf die einzelnen Agenten zuständig ist. Alle Ereignisse, welche durch einen Benutzer oder das System ausgelöst werden (z.b. Werkzeuganfragen, Systemantworten, PLib-Einträge, Annotationen), werden in entsprechenden Tabellen einer Datenbank abgelegt und stehen dort zu einem späteren Zeitpunkt für eine Auswertung zur Verfügung. 2.2 Interaktion und Kommunikation Die in einer realen Bibliothek gegebenen Interaktionsmöglichkeiten wurden 1994 von Ackerman [1] aufgegriffen, der sie im Hinblick auf ihren Nutzen untersucht und dabei folgende Feststellungen gemacht hat. Die Informationssuche vieler Perosnen beginnt meist mit einer direkte Fragen um Hilfe. Ein Suchender stellt an einen Experten (z.b. einen Bibliothekar) eine Anfrage um Informationen zu Dokumenten eines Themenbereiches und erhält als Antwort eine Liste mit möglicherweise passendem Material. Wenn der Experte sogar direkt relevante Materialien liefern kann, wird die Anzahl zu lesender Dokumente eventuell stark verringert. Somit kann der Zugriff auf gesuchte Materialien vereinfacht und die Zeit für die Informationssuche reduziert werden. Direkte Kommunikation fördert aber vor allem den Austausch informeller Informationen (z.b. technische Kniffe, organisatorische Feinheiten oder persönliche Gespräche), welche selten schriftlich festgehalten werden und daher meist ausschließlich direkt von anderen Personen erfahren werden können. Die Suche nach Informationen ist außerdem häufig an eine aktuelle Situation (Kontext) gebunden. Es ist jedoch schwer, in einer Suche genau die Informationen in Dokumenten zu finden, die direkt zum aktuellen Sachverhalt passen. Fragt man hingegen andere Benutzer, die möglicherweise ähnliche Situationen erlebt haben, so sind diese häufig in der Lage, ihr Wissen an den aktuellen Kontext anzupassen und direkt an den Nachfragenden weiterzugeben. Die so erhaltenen Informationen sind hilfreicher, als die bei einer Suche gefundenen Dokumenten, die nicht direkt auf das vorliegende Problem eingehen. Hier muss der Benutzer die Information zuerst einmal extrahieren, verstehen und dann auf Problem anwenden. Reale Bibliotheken dienen als Platz des gemeinsamen Lernens. Studenten treffen andere Studenten und bilden Lerngruppen, eventuell trifft man auf einen Dozenten und erhält von diesem wichtige Informationen und oft bieten öffentliche Bibliotheken soziale Ereignisse wie Lesungen eines Autors, Ausstellungen oder Themenabende, die über das reine Angebot niedergeschriebener Informa- 9

11 tionen hinaus gehen. Diese sozialen Funktionen existieren als Nebenprodukte, bereichern jedoch das Informationsangebot nicht unerheblich. Ackerman bezeichnete daher direkte Kommunikation zwischen Personen als glue for communities, also als ein Mittel, das eine (Arbeits-) Gemeinschaft zusammenhält Kollaboration und Kooperation Digitale Bibliotheken werden häufig von Arbeitsgruppen genutzt, um Informationen zur Lösung einer Aufgabe zu finden. Das verteilte Lösen von Problemen kann dabei nach Schlichter [6] wie folgt beschrieben werden: Distributed problem solving can be defined as the cooperative activity of several decentralized and loosely coupled problem-solvers that act in seperate environments. Diese Art der losen Zusammenarbeit lässt sich auch mit dem Begriff Kollaboration umfassen, welcher von Hall [7], [8] wie folgt definiert wurde: Collaboration is broadly defined as the interaction among two or more individuals and can encompass a variety of behaviors, including communication, information sharing, coordination, cooperation, problem solving, and negotiation Erweitert man die Definition, welche nur auf die Art der Interaktion eingeht, um folgende Definition des Oxford Dictionary von 1998: collaborate (with sb) - work together (with sb), esp. to create or produce sth, so wird deutlich, dass die Zusammenarbeit in der Regel erfolgt, um eine Aufgabe zu lösen oder ein Ziel zu erreichen. Dieses gemeinsame Ziel steht bei einem sehr ähnlichen Begriff, Cooperation im Vordergrund. Dieser wird im Oxford Dictionary [9] wie folgt umschrieben: The action of co-operating, i.e. of working together towards the same end, purpose, or effect; joint operation. Wichtig ist also in diesem Zusammenhang, dass die Arbeit auf ein gemeinsames Ziel hin gerichtet ist. Dies ist die Voraussetzung für die Nutzung des Begriffes Kooperation und grenzt diesen gegenüber einer reinen Arbeitsteilung im Rahmen von Kollaboration ab. Dass die beiden Begriffe allerdings häufig synonym gebraucht werden, sieht man am aktuellen Eintrag für den Begriff collaborate im Oxford Dictionary: collaborate, v: To work in conjunction with another or others, to co-operate; esp. in a literary or artistic production, or the like. Schlichter erwähnte in seiner Definition die Notwendigkeit, dass die individuell geleistete Arbeit mit der Gruppe im Zusammenhang steht: Collaboration requires two or more participants who contribute a common task. A crucial point of successfull collaboration is the manner in which individual work is related to the group as whole. [6] 10

12 Im folgenden wird diese Definition nach Schlichter zu Grunde gelegt. Im weiteren Verlauf schreibt Schlichter außerdem: Co-workers make autonomous descissions when working alone, under changing and unpredictable conditions, which the group cannot forsee or plan for. To enable a seperated group of co-workers to collaborate, they need to coordinate themselves. Koordination der gemeinsamen Arbeit ist also eine wichtige Voraussetzung für das Erreichen des Ziels Groupware Es werden somit Werkzeuge oder Mechanismen benötigt, die die Arbeit der einzelnen Co-Worker koordinieren und synchronisieren, also eine Planung, Aufteilung und (Re-)Kombination der Tätigkeiten erlauben. Solche Mehrbenutzer- Werkzeuge (oder MUT ) lassen sich am besten mit dem Begriff Groupware aus dem Bereich des Computer Supported Cooperative Work (CSCW) [10] beschreiben. Johansen definierte 1988 [11, 12] Groupware wie folgt: Groupware is a generic term for specialised computer aids that are designed for the use of collaborative work groups. Typically, these groups are small projectoriented teams that have important tasks and tight deadlines. Groupware can involve software, hardware, services and/or group process support. Ellis fasste dies in Groupware Some issues and experiences [13] noch weiter zusammen: Groupware are computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment. Diese Definition beschreibt recht gut die unterstützenden Aufgaben von Groupware im Zusammenhang mit der Lösung einer Aufgabe. Sie fordert außerdem eine passende Schnittstelle zu der gemeinsamen Arbeitsumgebung Awareness Eine wichtige Aufgabe dieser Schnittstelle ist, neben der Darstellung der eigentlichen Aufgabe, die Unterstützung von Mechanismen der Awareness, also dem Gewahrsein der am Geschehen beteiligten Benutzer untereinander (User und Group Awareness). Diese beiden Mechanismen lassen sich wie folgt beschreiben: Das Gewahrsein anderer Benutzer, die User Awareness beschreibt das Wissen des Benutzers um das Vorhandensein aller anderen Benutzer im System. Dieses Wissen kann zum Beispiel durch die Anzeige einer Liste erzeugt werden, wie sie von den meisten Instant Messengern genutzt wird. Das Vorhandensein von User Awareness regt zur spontanen, teils informellen Kommunikation mit anderen Gruppenmitgliedern an [10], wodurch Informationen auf direktem Weg ausgetauscht werden. So können zum Beispiel Einladun- 11

13 gen zur Teilnahme an Gruppenarbeit [14] direkt an alle verfügbaren Benutzer einer Arbeitsgruppe verteilt werden. Group Awareness ist nach Dourish [15] wie folgt definiert: Group Awareness as an understanding of the activities of others which provides a context for own activity. Sie umfasst also das Gewahrsein über die Aktivitäten (z.b. das Verhalten, die aktuelle Arbeit oder die Rolle) der mit einem Benutzer im Zusammenhang stehenden Teilnehmer im System. Nach [16] lassen sich vier verschiedene Arten von Gruppengewahrsein unterscheiden: Informal Awareness, also das generelle Wissen über die Verfügbarkeit anderen Gruppenmitglieder (ähnlich der generellen User Awareness). Structural Awareness, nach Schlichter [6] definierte als:... awareness (that) involves knowledge about such things as people s roles and responsibilities, their positions on an issue, their status, and group processes. Diese Form des Gewahrseins beinhaltet Informationen über die Zusammensetzung von Arbeitsgruppen und die Rollen oder Verantwortlichkeiten, welche die an ihr beteiligten Benutzer einnehmen. Social Awareness: Welches Interesse und welche speziellen Fähigkeiten hat der einzelne Benutzer im Zusammenhang mit der Gruppe und dem zu erreichenden Ziel. Dies setzt das Erstellen eines genaueren Benutzerprofiles voraus. Work Space Awareness: Diese Art des Gewahrseins definiert Schlichter [6] als:... the up-to-the minute knowledge a person requires about another group member s interaction with a shared workspace if they are to collaborate effectively. Sie umfasst also das Wissen darum, welcher Benutzer auf welche Weise Änderungen an Gruppendokumenten vollzogen hat und ist ein wichtiger Bestandteil der meisten Mehrbenutzer-Werkzeuge. Das Gruppengewahrsein erweitert somit das System um die Kenntnis der Funktion der anderen Benutzer. Mögliche Ansprechpartner zu einem Thema werden schnell erkannt. Auch lässt sich der Verlauf einer Gruppenarbeit durch die Verknüpfung von Änderungen mit Benutzern besser nachvollziehen. Gruppendynamische Vorgänge können erkannt und diskutiert werden. Dies alles ermöglicht eine bewusstere Entscheidung über die eigenen zukünftigen Aktivitäten Das Overlay-Modell Nach Hoppe [17] ist das Wissen von Personen additiv. Die Verknüpfung der einzelnen Wissensbereiche von Mitgliedern einer Arbeitsgruppe lässt sich durch 12

14 das Overlay Model wie folgt beschreiben: Jede Person hat eine Gedächtniskapazität von n Wissenselementen, welche kein falsches Wissen enthält. Zwei Personen können außerdem ihr Wissen vereinen, während sie zusammen eine Aufgabe lösen. Voraussetzung hierfür ist jedoch, dass sich ihre Wissensmengen überlappen (siehe Abbildung 2.3). Dies führt zu einer gemeinsamen Menge an Wissenelementen, eben der Schnittmenge der beiden Grundmengen, mittels welcher die Personen miteinander kommunizieren können. Bei der gemeinsamen Arbeit steht ihnen dann jedoch die Vereinigungsmenge ihrer Wissensmengen zur Verfügung, da sie ihr Wissen kombinieren können. Abbildung 2.3: Darstellung des Overlay Model für zwei Personen Unter der Voraussetzung, dass sich die geteilte Wissensmenge K zweier Personen A und B aus der Vereinigung der einzelnen Wissensmengen K A und K B genau dann ergibt, wenn die Schnittmenge dieser Mengen nicht Null, also q > 0 ist, ergibt sich folgende allgemeine Formel: K 1 = K({A}) = K A mit K 1 = n K 2 = K({A, B}) = K A K B mit K 2 = n p+n q+n p = n q+2 n p = n (1 p)+2 n p = n (1+p) K 3 = K({A, B, C}) = K A K B K C mit K 3 = n + n p + n q 2 = n(1 + p + p 2 ) Somit ergibt sich für eine beliebige Anzahl von Personen x K x = n(1 + p p x 1 ) Dies entspricht der Partialsumme der geometrischen Reihe S i = x 1 i=0 n pi, welche für p<0 konvergiert mit: lim i S i = i=0 n pi = n 1 p Diese Formel lässt erwarten, dass die Zunahme des Wissens um so größer ist, je kleiner die gemeinsame Menge von Wissenselementen und damit q ist. Ausserdem zeigt sie, dass mit zunehmender Personenzahl der Beitrag der einzelnen Personen geringer wird und es somit eine vernünftige Grenze für eine 13

15 Gruppengröße gibt. Dieses Verhalten lässt sich schnell an Hand einer Tabelle verdeutlichen, deren Werte nach obiger Formel berechnet wurden. Hier gibt p die Anzahl der Wissenselemente an, die nicht geteilt sind, i ist die Anzahl der Gruppenmitglieder: p \ i Es zeigt sich recht deutlich, dass bei einem geringen Unterschied in der Wissensmenge ein maximaler Wissenszuwachs schon in Kleingruppen erreicht werden kann. Es bleibt zu bemerken, dass der Aufwand des miteinander Arbeitens für sehr kleine q, also für eine sehr geringe Menge gemeinsamen Wissens, recht schnell ansteigt, da die Mitglieder einer solchen Arbeitsgruppe einen Großteil der Zeit mit dem Erklären des eigenen Wissens beschäftigt sein werden. Dieser Aspekt wird im Overlay Model nicht abgebildet. Die Grundidee jedoch stützt die Annahme, dass durch Nutzung des gemeinsamen Wissens gefundene Dokumente umfassender bearbeitet werden können, da sich die Wissensbasis zum Umgang mit dem Dokument aus der Vereinigung der Wissensmengen aller beteiligten Benutzer ergibt. Dies ermöglicht den einzelnen Personen neue Sichtweisen auf die zu bearbeitenden Informationen. 2.3 Verwandte Arbeiten Es gibt eine Reihe von Projekten, die sich mit Shared Workspace Applications und Werkzeugen zur Kollaboration befassen. Shared Workspace Applications sind hierbei Groupware Anwendungen, die Mechanismen zum Erzeugen, Verwalten und Benutzen einer Reihe von virtuellen geteilten Arbeitsplätzen anbieten, auf denen mehrere Benutzer gleichzeitig die zur Verfügung stehenden Werkzeuge nutzen können. Beispielhaft hierfür sind unter Anderem die folgenden Projekte: ANTS [18], das IGLOO Projekt [19] und das Projekt Habanero [20], bieten Frameworks für kollaborative Arbeitsplätze an und liefern teilweise fertig implementierte Beispiele für Mehrbenutzerwerkzeuge. Zwei verwandte Shared Workspace Applications sind die Projekte Free Styler & CoolModes [21] der Collide Gruppe, deren grafische Schnittstellen den Collide JGraph [22] nutzten. Dieser ermöglicht die Arbeit mit einer Reihe frei kombinierbarer Werkzeug-Paletten zu verschiedenen Themen (z.b. Diskussionen, Modellierung von Systemen, Wissensmanagement). Im Zusammenhang mit der MatchMaker Technologie [23] wird das Koppeln von Teilen des Arbeitsbe- 14

16 reichs mit anderen Benutzern und somit das verteilte Arbeiten ermöglicht. Eine Reihe weiterer Systeme für verteiltes Arbeiten findet man unter grantbow/groupware.html. Kollaboratives Arbeiten in Digitalen Bibliotheken hingegen ist bisher weniger im Fokus des Interesses. Dennoch gibt es auch hier eine Reihe interessanter Arbeiten. Masinter & Ostrom versuchten bereits 1993 mit ihrem Projekt Gopher from MOO eine Digitale Bibliothek in einem virtuellen Umfeld, analog zur realen Bibliothek, zu präsentieren [24]. Eine eher grafisch orientierte Anwendung ist QueryKids [25], welche Kindern die kollaborative Informationssuche in einem virtuellen Zoo erlaubt. Grundlagen zum kollaborativen Sammeln von Informationen wurden 1997/98 von Borghoff et al. [26] untersucht. Sie unterteilten die Vorgehensweisen des Sammelns von Informationen in zwei disjunkte Teile. Zum einen das aktive Suchen nach Informationen ( pull ), zum anderen das passive Empfangen ( push ), wobei in beiden Fällen die Informationen aus sozialer oder arbeitsbedingter Interaktion resultieren. Analog hierzu beschreiben sie zwei unterschiedliche Informations-Technologien, die Knowledge Pump und den Knowledge Broker und untersuchen ihren Einsatz in kollaborativen Sitzungen, sowie eine mögliche Kombination beider Technologien. So sollen sowohl Anfragen als auch Resultate verteilt nutzbar gemacht werden. In ihrer aktuellen Arbeit [27] untersuchen die Autoren Dion, Lin und Schubert die Frage, ob Anfragen als Ausdruck der Suche nach Informationen dazu genutzt werden können, anderen Benutzern mit ähnlichen Inforationsbedürfnissen zu helfen. Hierfür erstellen sie eine Umgebung für die Sammlung und Kategorisierung von Suchanfragen und ein Werkzeug zur Visualisierung der hieraus gebildeten Anfragenetze, den Query Graph Visualizer. Stellt ein Benutzer eine Anfrage mit diesem Werkzeug, so wird diese in das Anfragenetz eingebaut. Der Benutzer erhält eine Darstellung des die Anfrage umgebenden Teilnetzes und hat somit artverwandte Anfragen, also solche, die ihn bei der Suche wahrscheinlich weiterbringen, direkt vor Auge. Neben der Sammlung und Analyse von Anfragen bietet sich jedoch auch die Auswertung der Mitschnitte von Daffodil-Sitzungen an. Diese können auf häufig auftretende Muster im Suchverhalten hin untersucht werden, wobei erfolgreiche Muster zur Generierung von Hilfsfunktionen genutzt werden können. Einen Ansatz hierzu beschreiben McLaren et al. in ihrer Arbeit über semiautomatische Tutorensysteme [28]. Das Projekt Agora [14] beschreibt an Hand einer floristischen DL recht ausführlich die Nützlichkeit von User- und Group Structure Awareness im Zusammenhang mit Expertenwissen. Hier hat jeder Benutzer unter Anderem die Möglichkeit, sich als Experte für gewisse Pflanzenarten zu deklarieren. Das System unterstützt einen Informationssuchenden, indem es ihm die gerade die für seinen Suchbereich relevanten Ansprechpartner anbietet. 15

17 Im Rahmen des Projekts DEBORA [2] wird die Nützlichkeit und Implementierbarkeit kollaborativer Funktionalität mittels asynchroner Kommunikation in Digitalen Bibliotheken an Hand eines Annotationswerkzeugs beschrieben. Renda und Straccia beschrieben, an Hand der personalisierbaren DL Umgebung CYCLADES, einen ähnlichen Ansatz [3], der sich mit der Kollaboration durch die Bereitstellung von Gruppenordnern auseinandersetzt. 16

18 Kapitel 3 Mehrbenutzer-Werkzeuge in Daffodil 3.1 Überblick In diesem Kapitel wird zuerst der Mehrwert von Mehrbenutzerwerkzeugen betrachtet. Danach wird der Prozess des Wissensmanagement genauer unterteilt, sowie die Unterstützung der einzelnen Teile durch Daffodil untersucht. Hierauf folgt eine Darstellung gängiger Kategorisierungsmethoden für Groupware Tools und die Einordnung der bisher existierenden Werkzeuge, sowie die mögliche Nutzung an Hand eines Beispieles. Als letztes werden noch wichtige Fragen im Hinblick auf die Organisation von Zusammenarbeit betrachtet. 3.2 Wozu Mehrbenutzer-Werkzeuge? Bei Arbeitsgruppen, welche mit digitalen Medien und Bibliotheken arbeiten, kann nicht davon ausgegangen werden, dass sie sich am selben Ort befinden und miteinander kommunizieren können. Vielmehr muss davon ausgegangen werden, dass sie räumlich getrennt arbeiten. Der Einfluss von physikalischer Nähe auf die beiden Faktoren Häufigkeit und Qualität von Kommunikation und gemeinsamer Arbeit wurden bereits 1988 von Kraut und Egido [29] untersucht. Sie stellten dabei fest, dass sich diese Faktoren bei steigender Entfernung stark verringern. Als Lösung schlugen sie den Einsatz von Videokonferenzen und Multimedia Meeting Tools vor, um die Einflüsse der Entfernung bestmöglich zu verringern und ein verteiltes Lösen von Problemen zu ermöglichen. Solche Werkzeuge fallen in die Kategorie der Groupware und sind in Abschnitt beschrieben. Durch die Schaffung von synchronen Interaktionsmöglichkeiten zwischen Benutzern wird der Einfluss der räumlichen Trennung also verringert. Gruppendynamische Prozesse und der aus ihnen resultierende Mehrwert können somit besser nutzbar gemacht werden. Mögliche Anwendungsgebiete für Groupware- Tools werden im Folgenden beschrieben. 17

19 3.3 Anwendungsgebiete Um die Anwendbarkeit von Mehrbenutzer-Werkzeugen im Bereich der Informationssuche und Wissensbildung genauer zu untersuchen, betrachten wir folgende Abbildung (nach Paepcke [30]). Sie stellt den Arbeitsablauf beim Umgang mit Wissen als Zyklus dar. Abbildung 3.1: Wissensmanagement nach Paepcke [30] Dieser Kreislauf lässt sich wie folgt beschreiben: Discover: Die Auswahl von geeigneten Wissensquellen bildet den Anfang eines Bearbeitungszyklus. Die Fragestellung ist, in welcher Bibliothek sich mit hoher Wahrscheinlichkeit ein geeignetes Dokument finden lässt. Retrieve: Um eine Hier möglichst große Zahl relevanter Dokumente zu erhalten muss eine geeignete Anfrage an das System gestellt werden. Das System muss die Anfrage richtig ausgewerten können. Auch müssen die Suchbegriffe geeignet gewählt werden. Colate: In diesem Abschnitt sollen die gefundenen Dokumente in geeigneter Weise abgelegt und dem Benutzer zugänglich gemacht werden können. Dokumente können automatisch, z.b. nach Aktualität oder Relevanz geordnet werden. Interprete: Dieser Schritt umfasst die Auswertung der Dokumente durch den Benutzer im Hinblick auf die Aufgabenstellung. Re-present: Während dieser Phase fasst der Benutzer die gefundenen Informationen zusammen, formuliert eine Antwort auf die Fragestellung und erzeugt somit neues Wissen. 18

20 Daffodil unterstützt den Benutzer im Einzelbenutzerbetrieb bei allen fünf Arbeitsphasen. Auch ermöglicht die Handbibliothek bereits die Zusammenarbeit mehrerer Benutzer in Daffodil durch das gemeinsame Sammeln von Informationen und die Ablage in Form eines Verzeichnis-Baumes. Hier können die einzelnen Objekte mit Annotationen versehen werden, was eine Gruppe beim Auswerten des gefundenen Wissens unterstützt. Diese asynchrone Kommunikation in Form eines Annotations-Threads ersetzt jedoch nur unzureichend einen synchronen Austausch von Wissen im Rahmen eines Gespräches oder eine synchrone Zusammenarbeit der Gruppe per geteiltem Arbeitsplatz. Die Reaktionszeiten auf getätigte Annotationen sind im allgemeinen wesentlich höher als auf eine Frage in einem Gespräch per Chat oder die direkt sichtbare Veränderung an einem Objekt auf der gemeinsamen Arbeitsfläche. Für das Erzeugen neuen Wissens ist die Kommunikation alleine über den Annotationsmechanismus somit nicht geeignet. Um gefundene Informationen produktiv in einer Gruppe zu bewerten und im Anschluss daran neues Wissen zu erschaffen, benötigt man somit weitere Werkzeuge, die direkte Kommunikation ermöglichen und eine verteilte Diskussion von Wissen zulassen. Zu diesem Zweck werden zwei Werkzeuge implementiert, zum einen ein Chat (Kapitel 4), um synchrone Kommunikation zu ermöglichen, zum anderen ein WhiteBoard-Werkzeug (Kapitel 5), welches einen geteilten Arbeitsbereich und grafische Elemente für eine Diskussion liefert (synchrone Kollaboration). Durch die Erweiterung der bereits existierenden Werkzeuge um Mehrbenutzer- Funktionen ließe sich außerdem eine bessere Unterstützung, vor allem für die Bearbeitung der ersten beiden Punkte, erreichen, was im Abschnitt 3.6 verdeutlicht wird. Bevor jedoch die Erweiterbarkeit der bisher existierenden Werkzeuge untersucht wird, werden als erstes drei Möglichkeiten zur Kategorisierung von Mehrbenutzer-Werkzeugen eingeführt. Diese sollen zum einen zur Einordnung der Erweiterungen der bisherigen Werkzeuge genutzt werden. Außerdem sollen sie veranschaulichen, warum gerade die beiden oben genannten Werkzeuge (Chat und WhiteBoard) implementiert werden. 3.4 Kategorisierung Die einfachste Art der Kategorisierung von Mehrbenutzerwerkzeugen ist die durch Robert Johansen 1988 beschriebene Einordnung in die Raum-/Zeit-Matrix [31]. Eine weitere Möglichkeit ist die Platzierung auf dem so genannten Co- Triangle [31]. Außerdem lassen sich die Mehrbenutzer-Werkzeuge in anwendungsorientierte Funktionsklassen einordnen[13]. So können auch potentielle Mehrbenutzertools von Daffodil in die Welt der Groupware Tools eingeordnet werden. 19

21 3.4.1 Die Raum-/Zeit-Matrix Diese einfache Einteilung eines Werkzeugs in die beiden Kategorien Raum (räumlich getrenntes Arbeiten oder Arbeiten an einem Ort) und Zeit (synchrones oder asynchrones Arbeiten) führt zur Bildung von vier unterschiedlichen Situationstypen [31]. In Abbildung 3.2 sind einige Beispielanwendungen in eine solche Matrix eingeordnet. Abbildung 3.2: Die Raum-/Zeit-Matrix nach Johansen [31] Die bereits existierende geteilte Handbibliothek lässt sich zum Beispiel klar in den ersten Sektor (verschiedene Zeit und verschiedener Ort) einordnen Das Co-Triangle Bei dieser Art der Kategorisierung werden die verteilt nutzbaren Werkzeuge nach Grad ihrer Unterstützung in Hinsicht auf Kommunikation, Koordination und Kooperation (Communication, Coordination, Cooperation) in ein Dreieck eingeordnet [31]. Die drei Begriffe Kooperation, Koordination und Kommunikation sind nach Teufel hierbei wie folgt zu verstehen: Unter Kommunikation versteht man den Austausch von Informationsobjekten. Um möglichst hohen Nutzen zu bringen, sollte dieser Austausch möglichst zeitnah und verlässlich erfolgen. Auch ist eine Ablage der versendeten Informationen wünschenswert, um auf diese zu einem späteren Zeitpunkt erneut zugreifen zu können. Werkzeuge in diesem Bereich unterstützen den informellen Austausch von Informationen und stellen damit die Basis der Zusammenarbeit dar. Werkzeuge mit Kommunikationsunterstützung können dabei entweder alleine genutzt werden oder als Kommunikationskanal zusammen mit anderer 20

22 Abbildung 3.3: Das Co-Triangle Groupware. Hierzu gehören unter anderem , Chat und Dateitransfer. Werkzeuge, welche die Koordination einer Gruppe unterstützen, sollen einen möglichst effizienten und reibungslosen Verlauf der kollaborativen Tätigkeiten ermöglichen. Dies setzt gemeinsame Interessen und eine organisatorische Zusammengehörigkeit der Beteiligten voraus. Hierbei können diese Werkzeuge lediglich eine geeignete Plattform für die Koordination bieten (z.b. ein Gruppenkalender), oder aber aktiv in das Geschehen eingreifen, indem sie den Koordinationsvorgang auf Grund vorhandener Kriterien automatisieren. Beispiele für koordinationsunterstützende Werkzeuge sind Werkzeuge zur Termin- und Ressourcenplanung, sowie Workflow-Management-Systeme und Systeme zur Arbeitsteilung. Werkzeuge zur Kooperation ermöglichen es einem Benutzer, im Rahmen seiner Rolle und seiner Fähigkeiten, mit anderen Benutzern zusammen effizient an der Erreichung gemeinsamer Ziele zu arbeiten. Im synchronen Fall werden Änderungen am gemeinsam bearbeiteten Objekt sofort auf allen beteiligten Plattformen sichtbar und das System schafft ein Gewahrsein hinsichtlich Aktivität und Aktionen der beteiligten Benutzer. Im asynchronen Fall unterstützt ein solches Werkzeug zumeist das konfliktfreie Zusammenführen von Änderungen an einem von einer Gruppe bearbeiteten Objekt. Ein gutes Groupware-System unterstützt den Benutzer in den unterschiedlichen Phasen der Zusammenarbeit jeweils mit geeigneten Werkzeugen. Beispiele für kooperationsunterstützende Werkzeuge sind Gruppeneditoren und Diskussionswerkzeuge. Abbildung 3.3 zeigt die Einordnung einiger Werkzeuge. Durch eine solche 21

23 Darstellung wird schnell deutlich, in welchen Bereichen diese Werkzeuge gemeinsames Arbeiten unterstützen können und welche Werkzeuge sich geeignet ergänzen, indem sie möglichst alle Ecken des Dreiecks abdecken. Da die geteilte Handbibliothek in erster Linie dazu dient, gefundenes Wissen zu teilen und Informationen und Gedanken zu einem gemeinsam betrachteten Dokument auszutauschen, der Aspekt der Koordination jedoch im Hintergrund steht, würde die Einteilung in etwa wie im obigen Bild beschrieben erfolgen Anwendungsorientierte Funktionsklassen Eine weitere Möglichkeit der Kategorisierung von Mehrbenutzer-Werkzeugen beschrieb Ellis 1991 [13] durch die Einordnung von Werkzeugen in eine der folgenden Klassen: Nachrichtensysteme bieten den Anwendern die Möglichkeit des asynchronen Austauschs von Nachrichten oder Objekten, welche sie um Metadaten erweitern können. Hierbei sind die Nachrichten klar strukturiert (z.b. Baumstruktur, eindeutiger Betreff, Datum der letzten Änderung) und können beim Empfänger durch Filtermechanismen passend durchsucht oder aufbereitet werden. ist somit ein klassisches Nachrichtensystem. Gruppeneditoren sind Werkzeuge, die ein gemeinsames, meist synchrones Editieren von Objekten erlauben. Hierbei implementieren sie wichtige Funktionen zur Erzeugung von Awareness (siehe Abschnitt 2.2.3) und unterstützen entweder multiple Einfügepunkte, sodass alle Benutzer gleichzeitig arbeiten können [32], oder implementieren Vergabestrategie für Schreibrechte. Gruppenunterstützende Systeme sind Sitzungsräume für so genannte face-toface-sitzungen, die mit vernetzten Rechnern (Group Support Systems (GSS)) ausgestattet sind. Die Mitglieder einer Arbeitsgruppe müssen sich also am selben Ort befinden. Konferenzsysteme ermöglichen die Kommunikation zweier oder mehrerer Benutzer in Realzeit (Chat, Videokonferenz) oder Nichtrealzeit (Forum). Agentensysteme ersetzen als Teilnehmer menschliche Gruppenmitglieder durch Software-Agenten, also Programme, die im Auftrag eines Benutzers bestimmte Aufgaben ausführen und bestimmte Rollen (z.b. Protokollierung, Rechtschreibprüfung) übernehmen. Sie agieren dabei normalerweise autonom. Ein Beispiel für ein Agentensystem ist im Projekt Gopher from Moo [24] implementiert, welches dem Benutzer mit der Figur des Bibliothekars einen Agenten zur Seite stellt, der für diesen auf Anfragen selbsttätig Informationen aus der Gopher Datenbasis zusammenstellt. Hierbei verläuft die Interaktion mit dem Bibliothekar ebenso, wie die mit anderen Benutzern des Systems. Als Koordinations- und Workflow-Management-Systeme bezeichnet man Systeme zur Koordination der Arbeit einzelner Mitglieder im Hinblick auf die gemeinsame Aufgabe. Dies reicht vom Gruppenkalender, der benötigt wird, um 22

24 geeignete Zeitpunkte für Treffen zu finden, bis hin zu einem den Arbeitsablauf strukturierenden System, welches ankommende Aufgaben selbsttätig auf passende und freie Mitglieder verteilt. Gemeinsame Informationsräume bieten den Benutzern die Möglichkeit zur konsistenten Verwaltung gemeinsamer Informationen, wobei man folgende vier Alternativen unterscheiden kann: Es existieren getrennte Verantwortlichkeiten, wobei jedem Benutzer ein gewisser Teil der Gruppendokumente zugeordnet ist, die er, von den anderen unabhängig, bearbeitet oder verwaltet. Ein Beispiel hierfür ist das Studierendenbüro, in welchem jeder Mitarbeiter für einen Teil der Studenten zuständig ist, welche ihm alphabetisch über ihre Nachnamen zugeordnet werden. Bei wechselseitigem exklusiven (Schreib-) Zugriff kann zu jedem Zeitpunkt ein Dokument nur von einem Nutzer (schreibend) bearbeitet werden. Ein Beispiel hierfür ist die Arbeit mit Office-Dokumenten, welche mehreren Benutzern über einen Fileserver zur Verfügung gestellt werden. Öffnet ein Benutzer ein solches Dokument, so erhält er, wenn dieses im Moment nicht bearbeitet wird, alleiniges Schreibrecht. Andernfalls wird ihm per Nachricht mitgeteilt, dass er Leserechte auf dem Dokument besitzt und welcher Benutzer das Dokument gerade mit Schreibrechten bearbeitet. Ein weiteres, typisches Beispiel ist die Arbeit mehrerer Benutzer auf einer Datenbank. Hier existieren Mechanismen, die das ungestörte parallele Arbeiten mit wechselseitigem Zugriff garantieren (Locking und Transaktionen). Durch die Erstellung alternativer Versionen (Branching) wird einzelnen Personen oder Gruppenteilen zum Zeitpunkt des Branchings eine Kopie der Daten zugewiesen, welche parallel bearbeitet und weiterentwickelt werden können. Will man die einzelnen Zweige zu einem späteren Zeitpunkt wieder zusammenfügen, so muss sichergestellt werden, das Änderungen, die zueinander im Konflikt stehen, gelöst werden können. Möglich ist auch ein synchroner, gekoppelter Zugriff auf Daten. Dies setzt jedoch eine gemeinsame Sicht auf die Daten, sowie Mechanismen zur Konsistenzhaltung voraus. Auf Grund dieser Klassifizierung ist der Annotationsmechanismus der geteilte Handbibliothek als Nachrichtensystem einzuordnen. Nutzer können Objekte, zum Beispiel gefundene Dokumente, in Ordnern der Bibliothek ablegen und per Annotation mit Metadaten versehen. Diese Metadaten können im weiteren Verlauf von anderen Benutzern annotiert werden, wodurch Kommuniktaion stattfindet. Um weitere Werkzeuge des Daffodil-Systems auf die Erweiterbarkeit zu Mehrbenutzerwerkzeugen zu untersuchen, muss zuerst einmal die Tauglichkeit des Daffodil-Frameworks im Hinblick auf die Unterstützung synchroner Mehrbenutzerinteraktion hin untersucht werden. 23

25 3.5 Tauglichkeit des Daffodil-Frameworks Um synchron Informationen oder Ereignisse zwischen Werkzeugen mehrerer Benutzer auszutauschen, benötigt man einen Mechanismus, der die eintreffenden Ereignisse auf alle beteiligten Clients weiterleitet. Ein solcher Mechanismus wird Multicasting genannt und ist unter anderem durch die Wikipedia-Enzyklopedie [33] wie folgt definiert: Multicast bezeichnet in einem Computernetzwerk eine Übertragungsart von einem Punkt zu einer Gruppe (auch Mehrpunktverbindung genannt). Der Vorteil von Multicast besteht darin, dass gleichzeitig Nachrichten an mehrere Teilnehmer oder an eine geschlossene Teilnehmergruppe übertragen werden Erweiterbarkeit Der in Abschnitt beschriebene Kommunikationsmechanismus des Daffodil-Systems kann dahingehend erweitert werden, dass er Multicasting unterstützt. Hierfür benötigt man einen neuen Nachrichtentyp, der dem System mitteilt, dass zwei oder mehr Clients gemeinsam ein Werkzeug benutzen wollen. Durch eine solche Nachricht wird dann vom jeweiligen Service eine Gruppensitzung initiiert und der Beitritt der Clients geregelt. Eine bestehende Unicast-Struktur lässt sich multicastingfähig machen, indem der zum Werkzeug gehörende Agent die von einem Mitglied der Sitzung eintreffende Nachricht wie gewohnt verarbeitet. Außerdem wird die Anfragenachricht an alle Clients der Sitzung weitergeleitet, um die grafische Anzeige des Werkzeuges aktuell zu halten und wenn nötig weitere Anfragen an das System zu unterdrücken, so lange die aktuelle Anfrage nicht bearbeitet wurde. Dies garantiert die Synchronität aller Clients. Die aus der Anfrage resultierende Systemantwort wird ebenfalls an alle Mitgleider der Session verschickt und somit eventuelle Sperren wieder aufgehoben Einschätzung Durch die Offenheit des Nachrichtensystems ist eine wie oben beschriebene Interaktion von Clients untereinander möglich. Hier spielt der Service im Backend die Rolle des Vermittlers und muss ankommende Nachrichten und Systemantworten auf die Ausführbarkeit im Hinblick auf die Konsistenz des Arbeitsvorgangs überprüfen und im Falle von Gültigkeit an alle anderen an der Session beteiligten Clients weiter geben. Durch den Logging-Mechanismus von Daffodil ergibt sich eine weitere Nutzungsmöglichkeit. Jeder Service legt den Informationsgrad der von ihm erstellten Mitschrift (Logging) selber fest, das Logging selber erfolgt durch Anlegen von Einträgen in einer Datenbank. Somit kann man durch Abspeichern der wesendlichen Event-Nachrichten das nachträgliche Auswerten von Gruppensitzungen oder den Beitritt zu einer Sitzung zu einem beliebigen Zeitpunkt realisieren. Auch ist ein Wiedergabe-Werkzeug für eine so gespeicherte Gruppensitzung denkbar. Hierzu müssen die zu einer Sitzung gehörenden Event-Nachrichten nur in der richtigen Reihenfolge aus der Datenbank entnommen werden (Replay). 24

26 Die so erweiterte Architektur entspräche einer traditionellen Client-Server- Architektur, wie sie in Abbildung 3.4 dargestellt ist. Die Konsistenzkontrolle und Datenreplikation, sowie Speicherung erfolgt auf der Serverseite. Abbildung 3.4: Die Client-Server-Architektur Im Folgenden werden bereits existierende Werkzeuge in Daffodil auf ihre Nützlichkeit und Umsetzbarkeit im Mehrbenutzer-Betrieb hin überprüft. 3.6 Untersuchung bestehender Werkzeuge Das Such-Werkzeug Das Such-Werkzeug ist das wesendliche Werkzeug des Daffodil-Desktops und ist in Abbildung 3.5 dargestellt. Im Eingabefeld (2) kann der Benutzer eine Suchanfrage formulieren, wobei ihm ein Formular bei der Erstellung unterstützt. Die zu durchsuchenden Bibliotheken, sowie die Typen der Antwortobjekte können im Filterbereich des Werkzeuges (1) festgelegt werden. Die Suchresultate werden dann in der Ergebnisliste (3) dargestellt, wobei das System sie nach erwarteter Relevanz ordnet. Die gemeinsame Nutzung dieses Werkzeugs brächte eine Reihe von Vorteilen mit sich. Suchanfragen könnten gemeinsam erstellt werden, was eine Kombination des Benutzerwissens schon bei der Fragestellung ermöglicht. In der Antwortliste könnte nun, zum Beispiel durch farbliche Markierungen, kenntlich gemacht werden, wer welches Objekt bereits untersucht hat. Dies ermöglicht eine effiziente Bearbeitung der gefundenen Ergebnisse, da sich die Arbeit der Informationssichtung bequem aufteilen lässt. Auch könnte von einem Benutzer direkt eine Bewertung der gefundenen Informationen (z.b. auf einer Skala von 25

27 Abbildung 3.5: Das Search Tool 1-10) erfolgen. Werden alle Dokumente von einem oder mehreren Benutzern bewertet, so kann man sie nachträglich auf Grund dieser Bewertung neu ordnen. Dies ist vor allem für größere Arbeitsgruppen interessant. Jedes Dokument muss nur von einem kleinen Teil der Gruppenmitglieder bewertet werden, jedes Mitglied bewertet daher auch nur einen Teil der gefundenen Objekte. Werden die Objekte anschließend sortiert, so ergibt sich ihre Relevanz aus dem Urteil der Gruppe und nicht mehr aus dem System. Auch erscheint es auf Grund der Untersuchungsergebnisse der Arbeitsgruppe um Dion und Fu [27] sinnvoll, gestellte Suchanfragen zu sammeln, sie geeignet zu gruppieren und einem Benutzer dann zur Verfügung zu stellen, wenn er mit seiner ursprünglichen Anfrage nicht weiter kommt. Die von anderen Benutzern gestellten Suchanfragen bieten dann einen schnellen Zugriff auf alternative Formulierungen, welche der aktuell suchende Benutzer alleine so wahrscheinlich nicht genutzt hätte. Diese Art der Nutzung des Expertenwissens und der Sucherfahrung anderer Benutzer wird von Fu als collaborative querying bezeichnet. Die Arbeitsgruppe hat zu diesem Zweck mit dem Qery Graph Visualizer einen grafischen Betrachter entwickelt, der die Zusammenhänge von Suchanfragen in einem Netzwerk darstellt. Abbildung 3.6 zeigt einen Ausschnitt eines solchen Netzwerkes. Die vom Benutzer gestellte Anfrage bildet dabei den Mittelpunkt, artverwandte Fragen sind mit dieser direkt verbunden. Ebenso haben auch diese wieder verwandte Anfragen als direkte Nachbarn. Somit bildet sich ein Netz aus Anfra- 26

28 Abbildung 3.6: Ein Anfragennetz im QGV gen, dessen einzelne Anfrageebenen zur besseren Unterscheidung farblich voneinander getrennt sind. Der Benutzer kann der Reihe nach die nächstgelegenen Anfragen zur Lösung seines Problemes nutzen. Das Netzwerk stellt dabei die kollektive Erfahrung im Umgang mit Informatonssuche und bei der Formulierung von Anfragen dar Die Handbibliothek Die Hanbibliothek (Auch PLib oder Personal Library genannt) bietet dem benutzer die Möglichkeit, gefundene Dokumente oder andere Daffodil-Objekte strukturiert abzulegen. Der Inhalt der PLib wird in einer Datenbank im Backend gespeichert und ist dem Benutzer somit in jeder Daffodil-Sitzung zugänglich, unabhängig vom Computer, an dem er gerade arbeitet. Die in Abbildung 3.7 dargestellte PLib besteht aus zwei Bereichen. Der erste Bereich (1) beinhaltet den Verziechnisbaum der Bibliothek mit allen abgelegten Objekten. Zu jedem dieser Objekte könne im unteren Bereich des Werkzeuges (2) Detailinformationen angzeigt werden. Durch die Möglichkeit der Annotation an Objelkte anzubringen (3) ist dieses Werkzeug schon mit Mitteln der asynchronen Kommunikation ausgestattet. Es gibt die Möglichkeit, Gruppenordner einzuführen, die einer gesamten Arbeitsgruppe zugänglich sind. Die hier enthaltenen Objekte können von jedem Mitglied mit Annotationen versehen werden, welche wiederum von anderen Benutzern annotiert werden können. So kann ein Diskussionsbaum aufgebaut werden. Um einem Benutzer Veränderungen am Annotationsbaum eines Objektes gewahr zu machen, wird dieses mit einem stilisierten Auge gekennzeichnet. Von Interesse wäre noch, dieses Werkzeug um eine Liste aller Benutzer, die dieses Objekt in dem privaten Teil ihrer Handbibliothek haben, zu erweitern. So kann ein Benutzer auf Grund ähnlicher Dokumente auf verwandte Interessen bei 27

29 Abbildung 3.7: Die Personal-Library (PLib) einer anderen Person schließen oder das System könnte eine Zusammenarbeit dieser Benutzer vorschlagen Autorennetzwerk Das Autorennetzwerk-Werkzeug stellt die Zusammenhänge zwischen publizierenden Personen grafisch dar (siehe Abbildung 3.8). In einem Formular (1) wird hierzu der Name des zu betrachtenden Autors und eine Suchtiefe vorgegeben. Die mit diesem Autor publizierenden Personen werden dann in einer Liste, sortiert nach Häufigkeit der gemeinsamen Publikationen aufgelistet (2). Zusätzlich wird, ausgehend vom Autor, ein Graph aller Co-Autoren (3) erstellt. Durch Anklicken eines der Autoren wird dieser zum Mittelpunkt des Grafen. Interessant für kollaboratives Arbeiten wäre hier die Möglichkeit, den Mitgliedern einer Arbeitsgruppe jeweils eine Menge von Co-Autoren zur weiteren Bearbeitung zuzuweisen. Bearbeitete Autoren könnten wieder farbig gekennzeichnet und ihre Relevanz bewertet werden. 28

30 Abbildung 3.8: Ein Netzwerk von Coautoren Thesaurus Dieses Werkzeug (siehe Abbildung 3.9) liefert zu einem Suchwort (1) eine Liste bekannter Synonyme (2). Zu jedem dieser Begriffe lässt sich außerdem beschreibender Text (3) anzeigen. Diese Liste könnte auch wieder gemeinsam bearbeitet werden, indem die mögliche Relevanz der Begriffe im Vorfeld diskutiert wird. Einzelne Gruppenmitglieder könnten dann die als relevant befundenen Worte in weiteren Suchanfragen benutzen und die Ergebnissmenge getrennt bearbeiten. Interessant wäre auch eine Funktion, die es ermöglicht, aus dem Werkzeug heraus für jedes Synonym eine eigene Anfrage zu starten und die Ergebnismengen zu vereinen ACM Klassifikationshierarchie Dieses Werkzeug stellt den Klassifikationsbaum nach ACM Computing Classification System von 1998 grafisch dar (siehe Abbildung 3.10). Eine verteilte Nutzung des Classification Browsers könnte zum Beispiel der Diskussion über die Einordnung bisher nicht klassifizierter Dokumente dienen. Allerdings kann hier jeder Diskussionsteilnehmer den Browser auch bei Bedarf als Einzelanwendung öffnen. Dieses Werkzeug ist also weniger für eine geteilte Nutzung geeignet. 29

31 Abbildung 3.9: Der Thesaurus-Browser Abbildung 3.10: Der Classification-Browser 30

32 3.6.6 Browsen in Konferenzen/Journalen Diese beiden identisch aufgebauten Werkzeuge ermöglichen das Durchsuchen von Beiträgen in Konferenzbänden oder Journalen. Abbildung 3.11 zeigt die Resultate einer Beispielanfrage im Konferendbrowser. Der Begriff digital wurde hierzu im Anfragefeld (1) eingegeben. Das System liefert eine Liste mit Konferenzen zurück (2), in denen der Suchbegriff behandelt wurde. Die in einem Band der Konferenz vorhandenen Dokumente werden in der Dokumentliste (3) dargestellt und können wie von der Resultatliste des Suchwerkzeuges gewohnt behandelt werden. Abbildung 3.11: Der Conference-Browser Im Mehrbenutzer-Kontext ist eine gemeinsame Bearbeitung einer solchen Dokumentsammlung durch Aufteilung auf die einzelnen Gruppenmitglieder, sowie eine Bewertung der Dokumente denkbar. Diese Werkzeuge können somit, ähnlich dem allgemeinen Such-Werkzeug, zum verteilten Auffinden von Wissen genutzt werden Referenzen und Zitatsuche Die Referenz- und Zitatsuche soll den Zusammenhang zwischen einzelnen Dokumenten verdeutlichen. Zu einem eingegebenen Dokument wird sowohl die Menge aller Zitate in diesem Dokument, als auch eine Liste aller Dokumente, die dieses referenzieren, angezeigt. Dies kann zum Beispiel genutzt werden, um andere Arbeiten zum selben Thema zu finden. 31

33 Im Mehrbenutzer-Kontext ist, wie bei den Such-Werkzeugen, die Aufteilung der gefundenen Ergebnisse auf die einzelnen Gruppenmitglieder sowie eine Bewertung der Dokumente denkbar Extraktionswerkzeug Dieses Werkzeug erzeugt Listen von Attributwerten (Journal Liste, Autoren, Keywords oder Konferenzbeiträge) der bei einer Suche gefundenen Dokumente und stellt sie dar (siehe Abbildung 3.12). Die Elemente der Liste sind nach Häufigkeit des Auftretens sortiert. Abbildung 3.12: Attribut-Werkzeug mit Liste der Autoren Auch hier ist eine Aufteilung des zu durchsuchenden Bereiches auf mehrere Benutzer denkbar Kategorisierung An Hand der oben beschriebenen Kategorisierungsmethoden werden die möglichen Mehrbenutzererweiterungen aktueller Werkzeuge eingeordnet. Auf der Raum-/Zeit-Matrix nehmen alle besprochenen Werkzeuge einen Platz im zweiten Sektor (räumlich verteilt, zeitsynchron) ein und erweitern damit Daffodil um die Möglichkeit der zeitgleichen Zusammenarbeit von Benutzern. 32

34 Betrachtet man die Einordnung an Hand des Co-Triangles, so ergibt sich folgendes Bild: Abbildung 3.13: Einordnung der Daffodil-Tools im Co-Triangle Ein erweitertes Such-Werkzeug erlaubt die gemeinsame Erstellung von Anfragen und das Strukturieren der gefundenen Dokumente und lässt sich somit sowohl in den Bereich Koordination & Workflowmanagement, als auch als Gruppeneditor im weiteren Sinne einordnen, da eine gemeinsame Erstellung einer Suchanfrage möglich ist. Alle anderen, für die verteilte Nutzung geeigneten, Werkzeuge lassen sich mehr oder weniger komplett dem Bereich Koordination & Workflowmanagement zuordnen, da sie eher der Koordination und Verteilung der Arbeit, als dem gemeinsamen Erstellen oder Verwalten von Informationen dienen. Der Klassifikationsbrowser hingegen ist für eine verteilte Nutzung eher ungeeignet und dient lediglich als Informationsquelle bei der Nutzung anderer Werkzeuge. Hieraus ergibt dich die Tatsache, dass die bisher implementierten Tools zwar zum großen Teil kollaborativ nutzbar gemacht werden können, an Hand der Einordnung im Co-Triangle wird jedoch deutlich sichtbar, dass sich diese Erweiterungen fast ausschließlich auf den Bereich der Koordination konzentrieren. Um eine möglichst umfassende Unterstützung aller drei Bereiche des Dreiecks zu ermöglichen, ist also die Implementierung von Werkzeugen, welche die anderen Bereiche des gemeinsamen Arbeitens abdecken, von Interesse. Diese 33

35 würden in die Kategorien Nachrichtensysteme und Konferenzsysteme oder Gemeinsame Informationsraum und Gruppeneditor passen und auf dem Co- Triangle eher den Spitzen Communication und Cooperation zugeordnet werden. Ein Ausblick auf solche Werkzeuge wird im Folgenden gegeben. 3.7 Ausblick auf weitere mögliche Werkzeuge Direkte Kommunikation Ein wichtiges Mittel der Zusammenarbeit ist möglichst zeitnahe Kommunikation, wie sie in einem Chatsystem stattfindet, da sie direkte Absprachen und somit eine flexible Strukturierung der Arbeit und gegenseitige Hilfestellung ermöglicht. Außerdem fördert sie informelle Gespräche und ermöglicht neben sozialen Kontakten den unkomplizierten Austausch von Informationen [10]. So können in einem Chat Strategien zum Auswerten der gefundenen Dokumente erarbeitet werden und die Kombination von Benutzerwissen, zum Beispiel durch Frage-Antwort-Dialoge, beschleunigt die Wissensbildung. In einer Diskussion kann gefundenes Wissen aufbereitet und anderen mitgeteilt werden. Dieses Wissen lässt sich sammeln und nach einem Gespräch geeignet aufbereiten und führt somit zur Schaffung eines neuen Dokumentes. Daher ist es sinnvoll, den Daffodil-Desktop um ein Chat-Werkzeug zu erweitern, welches den direkten Austausch von Nachrichten zwischen zwei Benutzern oder in einer Arbeitsgruppe ermöglicht. Der obere Bereich des Co-Triangles kann durch dieses Werkzeug geeignet besetzt werden. Auch erweitert das Chat-Werkzeug durch den synchronen Austausch von Informationen im Prinzip die Mehrbenutzerfunktionalität auf den gesamten in 3.3 vorgestellten Kreislauf der Wissensschaffung. Im Rahmen dieser Arbeit wird ein solcher Chat-Mechanismus in Daffodil integriert. Dieser Vorgang ist in Kapitel 4 und Abschnitt 6.1 genauer beschrieben Werkzeuge zur gemeinsamen Wissensbildung Es ist durchaus denkbar, mit dem Chat-Werkzeug den gesamten Kreis der Wissensbildung abzudecken. Da die Hauptaufgabe des Chat jedoch in der Kommunikation besteht, ist es sinnvoll, ein weiteres Multi-User-Tool zu erstellen, welches ein gemeinsames Arbeiten an Dokumenten und somit die Kooperation auf einfachere Weise ermöglicht. Ein Beispiel hierfür sind kollaborative Text-Editoren, in denen mehrere Benutzer gleichzeitig, eventuell sogar an unterschiedlichen Stellen, arbeiten können. Wichtig ist hierbei, dass Änderungen sofort für alle mitarbeitenden Benutzer sichtbar werden, damit diese geeignet reagieren können. Auch ist es wichtig zu 34

36 wissen, wer welche Änderungen vorgenommen hat. Eine gelungene Implementierung eines kollaborativen Text-Editors ist Sub- EthaEdit [32]. Abbildung 3.14: Eine Sitzung in SubEthaEdit [32] Diese Software unterstützt die oben genannten Awarenessmechanismen vorbildlich. Eine Benutzerliste zeigt alle verfügbaren Personen an und ermöglicht es, diesen eine Einladung zur Mitarbeit auszusprechen. Eine zweite Liste gibt Auskunft über Benutzer, die gerade am gleichen Dokument arbeiten. Die Position aller Einfügepunkte, jeweils einer pro Mitarbeiter, wird in der Scroll-Bar des Textfensters angezeigt, aktuelle Änderungen farblich unterlegt Wissensmanagement und Diskussionen Werkzeuge, die Diskussionen oder Brainstorming unterstützen dienen, dem strukturierten Erfassen und Kombinieren von Wissen, sowie dem Erstellen eines Lösungsansatzes oder dem Projektmanagement. Dies kann auf mehr oder weniger rein textuellem Weg über sogenannte Thread Discussions [34, 35] oder auf grafischem Weg, z.b. mit einigen Paletten in CoolModes [36], geschehen. Bei letzterem repräsentieren geometrische Symbole die verschiedenen Elemente einer Diskussion, welche von den Benutzern hinzugefügt, bearbeitet oder gelöscht werden können. Zusammengehörige Objekte werden mit Linien unterschiedlicher Bedeutungen verbunden. Die Integration eines solchen Werkzeugs in Daffodil ist Teil dieser Diplomarbeit und 35

37 wird in Kapitel 5 behandelt. Es existieren bereits diverse Modelle zur Organisation und Visualisierung von Wissen und zur Unterstützung von Diskussionen. Im folgenden wird auf einige dieser Methoden näher eingehen: QOC - Question Option Criterion Beim Wissensmanagement mittels Question Option Criterion gibt es neben der zu klärenden Frage noch Repräsentanten für die einzelnen Lösungsmöglichkeiten (Optionen), sowie für die Kriterien, denen das fertige Produkt genügen soll. Diese Objekte werden mit Kanten verbunden. Für die Verbindungskanten zwischen Kriterium und Option gibt es hierbei bewertende Kanten. In der Basisversion des QOC, beschrieben unter Anderem in [37], sind dabei folgende Bewertungen vorgesehen: ++ = sehr gut, + = gut, O = neutral, - = schlecht, = extrem schlecht Die jeweiligen Bewertungen einer Option werden addiert und so die beste Alternative ermittelt. QOC findet vor allem im Design Rational, einer Methode der Softwareentwicklung, Einsatz. Eine Erweiterung des QOC sieht zwei Arten von Bewertungskanten (positiv und negativ) vor, welche dann mit ganzen Zahlen gewichtet werden. Ein Beispiel hierfür ist die QOC-Palette der Collide Gruppe für CoolModes [36], welche in näher beschrieben wird. Abbildung 3.15: Ein QOC-Diagramm, erstellt mit CoolModes [36] 36

38 Concept Maps Joseph D. Novak definierte den Begriff der Concept Maps, zu Deutsch etwa Wissens- oder Begriffslandkarten, wie folgt [38]: Concept maps are tools for organizing and representing knowledge. They include concepts, usually enclosed in circles or boxes of some type, and relationships between concepts or propositions, indicated by a connecting line between two concepts. Words on the line specify the relationship between the two concepts. Concept Maps dienen also eher der Strukturierung von Wissen und nicht, wie QOC, der Lösungsfindung. Sie finden ihren Einsatz vor allem im Bereich der Lehre, wo sie für das Erkennen, Prüfen und Zusammenfassen von Wissensgebieten und zum Wiederholen und Anwenden von Wissen genutzt werden. Ein Sammlung von Werkzeugen zur Generierung von Concept Maps sind die IHMC CmapTools [39]: Abbildung 3.16: Eine Concept Map der CMapTools [39] System Dynamics System Dynamics dient der Modellierung komplexerer Systeme wie Bevölkerungswachstum, Wettervorhersage oder ökonomischer Vorgänge. Sie wurden in den 60er Jahren von Jay W. Forrester [40] am MIT entwickelt und führten zur Gründung der MIT System Dynamics Group. System Dynamics nutzt, im Unterschied zu anderen Systemen, sogenannte feedback loops. Diese Betrachtung der Rückkopplungen des Systems ermöglicht ein realitätsnahes Verhalten des Modells und hilft bei der Beschreibung des nichtliniaren Verhaltens. Durch Computersimulationen lassen sich Szenarien erstellen, bei denen sich Unterschiede im Verlauf und im Ergebnis beobachten lassen, welche durch kleine Änderungen 37

39 der Funktionsparameter entstehen. System Dynamics liefern also eine gute Darstellung der Veränderungen eines Systems zur Laufzeit und seiner Abhängigkeit von den Ausgangsparametern [41]. Die Vorgehensweise zur Erstellung eines solchen dynamischen Systems lässt sich wie folgt gliedern [42]: Identifizierung eines Problems Erstellung einer dynamischen Hypothese um die Ursache des Systemverhaltens zu erklären. Aufbau einer Computersimulation des Systems Testen, ob das Modell das Verhalten des Systems hinreichend nachbildet Überprüfung weiterer erdachter Testfälle an Hand des Modells Findung einer geeigneten Lösung für das reale System an Hand dieser Testfälle System Dynamics dienen somit der Modellierung eines Systems und seines dynamischen Verhaltens. Es gibt eine Vielzahl an Programmen, die System Dynamics unterstützen, unter anderem Simile[43], SyntheSim, PowerSim und CoolModes [36] mit der SystemDynamics Palette. Abbildung 3.17: Ein Beispiel für die Modellierung eines Jäger-Beute Systems in Simile[43] Tutor-Werkzeug Eine weitere interessante Idee ist die Nutzung von Daffodil im Rahmen von Tutoring. Ein Lehrer oder Experte kann seinen Desktop für andere Benutzern sichtbar machen und diesen so den Umgang mit Daffodil und der Suche nach Informationen schnell vermitteln. Diese können gezielt, z.b. per Chat, Fragen stellen oder sogar direkt durch Nutzung der Werkzeuge des geteilten Desktops interagieren. Ähnlich dem von McLaren et al. [28] beschriebenen semiautomatischen Tutorensystem können die während einer Suche in Daffodil getätigten Arbeitsabläufe analysiert und erfolgreiche Vorgehensmuster extrahiert werden. Diese 38

40 Muster können dann genutzt werden, um ein Hilfesystem für unerfahrene Benutzer zu erstellen, welches sowohl Vorschläge für das weitere Vorgehen machen, als auch eine Bewertung des bisherigen Verhaltens vornehmen kann. Die zur Mustersuche verwendeten Arbeitsvorgänge spiegeln dabei, ähnlich dem im Ansatz von Dion et al. [27] verwendeten Netzwerk von Suchanfragen, das kollektive Wissen und die Erfahrung im Umgang mit einer Informationssuche wieder. Viele der oben genannten Werkzeuge werfen jedoch eine Reihe weitere Fragen auf. Wie soll die Zusammenarbeit organisiert werden, wer darf wann mit welchem Teil eines Werkzeugs interagieren und gibt es zum Beispiel mehrere Telepointer, einen für jeden Teilnehmer an einer Session? Diese Fragen sollen im folgenden diskutiert werden. 3.8 Organisation der Kollaboration Nun bleiben noch einige wichtige Fragen im Zusammenhang mit Mehrbenutzer- Werkzeugen offen, die die Organisation der Zusammenarbeit betreffen und im folgenden behandelt werden Sitzungsinitiierung Im Gegensatz zur Benutzung eines Werkzeuges durch einen Benutzer ergibt sich im Fall der Benutzung durch mehrere Anwender die Notwendigkeit, dass ein Benutzer eine Arbeitssitzung (auch Session genannt) initialisiert und alle anderen Benutzer dieser beitreten. Der Benutzer, der die Sitzung initialisiert, legt dabei die sitzungsspezifischen Daten (Name der Sitzung, Art des Werkzeuges, Ort der Speicherdaten, Art des Sitzungsbeitritts, Laden einer schon begonnenen Sitzung) fest und kann die Rolle eines Moderators einnehmen, der Sonderrechte besitzt und kontrollierend und strukturierend in den Verlauf der Sitzung eingreift oder aber die selben Rechte haben, wie alle anderen Sitzungsmitglieder. Es ist zu klären, wie eine Einladung der anderen Teilnehmer erfolgt und ob dieser Folge zu leisten ist oder ob man die Teilnahme ablehnen kann. Eventuell ist es sogar sinnvoll, einem beliebigen Benutzer den Beitritt zu erlauben, eine Session also öffentlich verfügbar zu machen. Auch bleibt zu überlegen, ob alle Benutzer der Sitzung vor dem eigentlichen Beginn der Gruppenarbeit beigetreten sein müssen oder ob der Beitritt eines Benutzers auch während einer laufenden Sitzung erfolgen kann. Sitzungskontrolle In einer Mehrbenutzerumgebung müssen eine Reihe neuer Entscheidungen getroffen werden, z.b.: 39

41 Wer darf der Sitzung beitreten? Wann soll ein Benutzer die Sitzung verlassen? Wann ist die Sitzung beendet und was geschieht mit den Daten? Man kann sich vorstellen, dass all diese Entscheidungen von allen Benutzern gleichermassen getroffen werden können, sodass für jede Entscheidung eine Abstimmung erfolgen muss. Für eine solche Wahl gibt es geeignete Algorithmen, welche unter Anderem in dem Buch Verteilte Systeme [44] von Coulouris et al. beschrieben sind. Eine Wahl führt jedoch meist zu einer Unterbrechung des Arbeitsverlaufes und bringt Unruhe mit sich. Auch nimmt der Aufwand mit steigender Anzahl von Gruppenmitgliedern zu. Daher ist es, vor allem bei Gruppen, die eine gewisse Mitgliederzahl überschreiten oder ansonsten recht wenig miteinander arbeiten, sinnvoll einem Benutzer die Rolle des Moderators zu geben. Dies kann zum Beispiel automatisch der Initiator einer Sitzung sein. Der Moderator übernimmt die wichtigen Entscheidungen, was den anderen Mitgliedern die Arbeit erleichtert. Allerdings nimmt hierdurch der Grad der Gleichberechtigung der Gruppenmitglieder stark ab, da ein Benutzer alle Fäden in der Hand hat. Gewisse gruppendynamische Prozesse werden eingeschränkt. Sollte außerdem der Moderator, zum Beispiel bedingt durch einen Fehler, die Sitzung verlassen, stehen den anderen Mitgliedern wichtige Funktionen, wie das Abspeichern oder kontrollierte Beenden der Sitzung, eventuell nicht mehr zur Verfügung. Sitzungsbeitritt Vorstellbar sind vier Arten des Beitritts zu einer existierenden Sitzung. Eine vollkommen offene Sitzung: Jeder Benutzer des Systems kann eine Liste laufender Mehrbenutzersitzungen erhalten und beliebig an diesen Sitzungen teilnehmen. Dies entspräche einer Vorlesung oder einer öffentlichen Diskussion und ist die generelle Politik im IRC [45] (öffentliche Chatrooms). Freier Beitritt ist immer dann von Vorteil, wenn keine feste Gruppe zu einem Thema existiert, da Interessenten so jeder Zeit zu einer laufenden Sitzung hinzustoßen können. Solche Sitzungen können also dazu dienen, neue Ideen zu erhalten oder Arbeitsgruppen vorzubereiten, bedürfen aber einem hohen Verantwortungsbewusstsein seitens der Teilnehmer. So könnte zum Beispiel ein Teilnehmer gezielt Diskussionen stören. Dem könnte man durch einen Bann-Mechanismus, ähnlich dem des IRC, entgegenwirken, durch den unerwünschten Besuchern das Betreten einer Sitzung untersagt wird. Weiterhin ist es wichtig, dem Benutzer im Auswahldialog geeignete Informationen über das Thema der Session oder eine Liste der an ihr beteiligten Personen zur Verfügung zu stellen, damit dieser nicht unnötig Sitzungen betritt, die ihn nicht interessieren. Eventuell können zu diesem Zweck auch Filtermechanismen integriert werden. Eine sichtbare Sitzung mit Bitte um Einlass: Es existiert ebenfalls eine Liste aller laufenden Diskussionen und interessierte Benutzer können um die Erlaubnis bitten, dieser Sitzung beizutreten. Die Anfrage kann dann für alle Teilnehmer 40

42 der Sitzung oder nur für den Moderator sichtbar werden, je nachdem, für welche Art der Sitzungskontrolle man sich entschieden hat. Dies entspricht dem Anklopf-Mechanismus im IRC [45], mit dem man in geschlossenen Chatrooms um Eintritt bitten kann. Auch hier sind Mechanismen zur Sitzungsbeschreibung vorteilhaft. Unverbindliche Einladung: Durch ein Mitglied der Sitzung (je nach Sitzungskontrolle Initiator, Moderator oder beliebiges Mitglied) wird einem anderen Benutzer eine Einladung ausgesprochen. Dieser kann durch Akzeptieren der Anfrage der Sitzung beitreten. Hat er im Moment jedoch keine Zeit, so kann er die Anfrage auch ignorieren oder ablehnen. Dies entspricht dem Invite Mechanismus des IRC [45], mit dem ein Benutzer einen anderen zum Betreten eines Chatrooms auffordern kann. Verbindliche Einladung: Hier wird der eingeladene Benutzer gezwungen, der Sitzung beizutreten, in dem zum Beispiel direkt eine Instanz des Werkzeuges auf seinem Arbeitsplatz geöffnet wird. Diese Art der Einladung ist vor allem in Lehr-Lern Szenarien denkbar, in denen ein Lehrer Schüler auf Gruppen aufteilt, kann jedoch in anderen Situationen von Seiten des Benutzers als störend empfunden werden, da sein Recht auf Entscheidung eingeschränkt ist. Je nach Anwendungsbereich des Werkzeuges ist jede Art des Sitzungsbeitritts, sowie eine Mischung verschiedener Beitrittsarten denkbar. So würden zum Beispiel die zweite und dritte Art des Sitzungsbeitritts eine sehr flexibele Benutzergruppe zulassen, deren Mitgliederfluktuation jedoch immer noch einer gewissen Kontrolle unterliegt und die aktiven Mitglieder kaum in ihrer Arbeit unterbricht. Ein weiterer Punkt ist der Beitritt zu einem späteren Zeitpunkt. Hier muss das System dafür sorgen, dass der neu beigetretene Benutzer die selben Informationen (das selbe Datenmodell) erhält, wie die schon an der Sitzung teilnehmenden Benutzer. Hierzu mehr unter Zugriffsregelung Ein weiterer Punkt, der in verteilten Systemen zu beachten ist, ist der gleichzeitige Zugriff auf Objekte. Hier sind im Grunde die folgenden Zugriffsarten denkbar. Bei parallelem Zugriff kann ein Objekt von mehreren Benutzern gleichzeitig geändert werden. Um mögliche auftretende Konflikte zu vermeiden, gibt es zwei Möglichkeiten: Vorgenommene Änderungen müssen vor dem Eintrag im System vom Benutzer bestätigt werden, daraufhin prüft das System, ob die Konsistenz des Objektes erhalten bleibt und verlangt vom Benutzer gegebenenfalls manuelle Nachbesserung, falls dies nicht der Fall ist. Ein solches Verfahren findet zum Beispiel beim Concurrent Versions System (CVS) [46] oder bei der Arbeit in einem Wiki [47] Anwendung. 41

43 Die zweite Möglichkeit ist die permanente Aktualisierung. Änderungen werden sofort bei allen Benutzern sichtbar und das System führt eine andauernde Konfliktüberprüfung durch. Hierzu unterteilt es ein Objekt in viele Unterobjekte und lässt an diesen Änderungen durch jeweils einen Anwender zu. Ein solches Vorgehen eignet sich zum Beispiel zur gemeinsamen Arbeit mit Texten, das Hauptobjekt Text wird in mehrere Unterobjekte (Angefangen beim Abschnitt, möglicherweise bis hin zum Buchstaben) unterteilt. Dieses Verfahren wird zum Beispiel bei [32] eingesetzt. Es entlastet den Benutzer, fordert aber eine hohe Beteiligung des Servers oder Systems. Beim verteilten wechselseitigen Ausschluss ( Mutual Exclusion ) [44] darf ein Objekt jeweils zu einem Zeitpunkt von maximal einer Person verändert werden, allerdings dürfen mehrere Personen gleichzeitig unterschiedliche Objekte bearbeiten. Änderungen werden sofort oder nach Beendigung der Arbeit an dem Objekt im System sichtbar. Durch diese Aufteilung wird erreicht, dass keine Konflikte auf einem einzelnen Objekt entstehen können. Allerdings muss das System regelmäßig für gesperrte Objekte überprüfen, ob der Benutzer, der das Objekt gerade verändert, noch im System angemeldet ist, um im Falle eines Fehlers (z.b. Absturz des Clients des Benutzers) Objekte wieder frei zu geben und das Verhungern wartender Personen zu vermeiden. Ein weiteres Problem des Sperrens sind Verklemmungen ( Deadlocks ). Sie treten dann auf, wenn zwei Benutzer sich gegenseitig Ressourcen sperren und so beide ihre Arbeit nicht vollenden können. Für die Erkennung, Vermeidung und Behebung von Deadlock-Situationen gibt es eine Reihe von Algorithmen und Designpattern (z.b. das Mutex-Pattern), welche sowohl im Bereich der verteilten Systeme [44], als auch im Bereich der Betriebssysteme [48] Anwendung finden. Eine weitere Vermeidungstechnik ist das in Datenbanken im Zusammenhang mit Transaktionen angewendete Preclaiming -Verfahren [49]. Eine Möglichkeit des Auflösens eines Konfliktes ist die Vergabe von Zeitstempeln, welche im Falle doppelt angeforderter Ressourcen dazu genutzt werden, eine der in Konflikt stehenden Transaktionen zu beenden [49]. Eine weitere Möglichkeit ist der alleinige verändernde Zugriff eines Benutzers auf das System, der einem wechselseitigen Auschluss mit einem Objekt, nämlich dem gesamten Arbeitsbereich, entspricht. Zu einem Zeitpunkt darf also nur ein Benutzer Änderungen am gesamten System vornehmen. Dies setzt zum einen eine vernünftige Vergabestrategie für den Zugriff auf das System (z.b. Round Robin oder das Einreihen in einer Warteschlange [48]) oder einen Moderator voraus, zum anderen fordert es mit steigender Gruppengröße mehr Disziplin und Geduld von den Benutzern, die Änderungen vornehmen wollen. Auf der anderen Seite liegt der Fokus aller Benutzer immer auf dem gerade geänderten Teil der Arbeit. Ein solches System eignet sich besonders für eine strukturierte textuelle Diskussion. Die letzte Möglichkeit ist die, dass vorhandene Objekte nicht mehr verändert, jedoch beliebig neue erzeugt werden dürfen. Alle Einträge erscheinen dabei in der Reihenfolge ihres Eintreffens und werden sofort für alle Benutzer sichtbar. Dies setzt eine lineare zeitliche Abfolge des gemeinsamen Arbeitsverlaufs voraus und ist am ehesten für Gruppengespräche geeignet. Daher findet diese Art der Zugriffsregelung auch fast ausschließlich in Chat-Umgebungen Anwendung. 42

44 3.8.3 Awareness In verteilten Systemen zur Unterstützung von Gruppenarbeit spielen neben der User Awareness noch weitere Formen des Gewahrseins eine Rolle. Ein gutes Groupware-Werkzeug sollte die folgenden Gewahrseinsformen unterstützen. User Awareness (Abschnitt 2.2.3) beschreibt das Gewahrsein der anderen Benutzer im System, oder in diesem Fall der Teinehmer an der aktuellen Sitzung. Ein Werkzeug kann diese Form des Gewahrseins schaffen, indem es eine Liste der teilnehmenden Personen anzeigt. Ein einfacher Weg, Group Structural Awareness (siehe Abschnitt 2.2.3) zu schaffen, ist die Erweiterung der Benutzerliste um die Möglichkeit, nicht mehr an der Sitzung teilnehmende Personen auszugrauen und aktuell aktive Personen, zum Beispiel durch Fettschreiben oder farbliches Hinterlegen des Namens, hervorzuheben. Workspace Awareness - Hier ist der Zusammenhang zwischen Objekt und Benutzer angesprochen (siehe Abschnitt 2.2.3). So können zum einen gerade bearbeitete Objekte mit dem Namen des bearbeitenden Benutzers gekennzeichnet werden. Außerdem ist es denkbar, jedem Objekt eine History-Funktion mitzugeben, welche die letzten Änderungen samt Zeit und Benutzer speichert. Somit lässt sich der Lebenslauf eines Objektes rasch verfolgen. Telepresenz [17] - Dies ist die eindeutige Representierung der einzelnen Benutzer im System zu jedem Zeitpunkt und somit ein Mittel die oben genannten Arten der Awareness zu steigern. Hierbei wird die aktuelle Position des Eingabegerätes jedes Benutzers (zum Beispiel Cursor oder Mauspfeil) allen anderen Benutzern, zum Beispiel durch eindeutige Farbgebung, kenntlich gemacht. Somit sieht man schnell, auf welchen Teil der Arbeit das Augenmerk der anderen Benutzer gerichtet ist. Man erhält außerdem ein einfaches Mittel, um über Entscheidungen abzustimmen, indem jeder Benutzer sein Eingabewerkzeug über die von ihm bevorzugte Alternative führt Modell & Persistenz Um allen Teilnehmer einer Sitzung die aktuellen Änderungen mitzuteilen, muss das System für ein ständig aktuelles Modell der Daten sorgen. Dies kann, je nach Architektur (Peer-to-Peer oder Client-Server) auf verschiedene Arten geschehen. Für Peer-to-Peer Systeme existieren dabei eine Reihe von Algorithmen, die hier jedoch nicht näher beschrieben werden, da das in dieser Arbeit zu betrachtende System (Daffodil) eine client-server-basierte Struktur hat. In Client-Server basierenden Systemen existieren hingegen drei grundlegende Varianten [17]: Shared application - Hier erhält jeder Benutzer die gleiche Ansicht auf ein gemeinsam genutztes Modell der Daten, welches vom Server verwaltet wird. Dies ist zum beispiel bei Microsoft NetMeeting [50] der Fall. 43

45 Multiple view but shared model - Bei dieser Art der Sitzung wird das Aussehen der grafischen Anzeige vom Benutzer mitbestimmt. Jeder Benutzer kann also seine Ansicht der Daten den eigenen Bedürfnissen anpassen und zum Beispiel eigene Schriftarten oder Farben für den angezeigten Text wählen oder grafische Objekte in einem ihm beliebigen Design darstellen. Auch kann er, abhängig von seinem Status, eventuell nur einen Bereich des vorhandenen Modells einsehen oder verändern. Das Modell hingegen wird weiterhin auf dem Server verwaltet und von diesem synchronisiert. Beispielhaft hierfür stehen Datenbanksysteme. Hier werden die Daten auf einem Server verwaltet und alle Änderungen und Anfragen werden von diesem bearbeitet. Welche Daten jedoch ein Nutzer einsehen und verändern kann, hängt von seinen Rechten auf den Tabellen ab. Multiple Models - Bei diesem Ansatz besitzt jeder Client ein Abbild des Modells und kann dort Daten verändern. Um diese den anderen Benutzern publik zu machen, müssen die Daten dann mit den auf dem Server vorhandenen Daten synchronisiert werden, wobei eventuell auftretende Konflikte, wie etwa das Überschreiben von mittlerweile im System eingetragenen Änderungen einer anderen Person, entweder automatisch gelöst werden können, verworfen werden oder aber vom Benutzer zu entfernen sind. Ein solches System eignet sich jedoch eher für asynchrone Colaboration und findet Anwendung in Techniken wie CVS [46] oder BSCW [51]. Eine leicht abgewandelte Version dieses Vorgehens, welche serverlos, also mit einer Peer-to-Peer-Struktur arbeitet, propagiert Änderungen am Modell automatisch an alle vorhandenen Clients. Die Synchronisation erfolgt hierbei zum Beispiel durch die Nutzung von Clock-Algorithmen (Lamport- und Vector- Clock-Algorithm) [44]. Während die ersten beiden Varianten, auf Grund des serverseitig vorhandenen Modells, bei einem Ausfall der Verbindung zum Servers zwangsläufig zum Stop der Arbeit auf den Clients führt, ermöglicht der dritte Ansatz das autarke Arbeiten der Clients. Das System kann sogar, je nach Aufbau, eine erneute Zusammenführung der getrennten Sitzungen zu einem späteren Zeitpunkt ermöglichen. Allerdings ist der Aufwand für Synchronisation höher, als der der ersten beiden Varianten. Des weitern ist es wünschenswert, die Ergebnisse einer Gruppenarbeit für die Auswertung zu einem späteren Zeitpunkt abzuspeichern. Dabei ist es sinnvoll, eine vorhandene Objektstruktur mit allen Daten und die Entwicklung eines Objektes über die Zeit hinweg abzuspeichern, um eventuell eine automatische Auswertung oder Mustererkennung anzuwenden oder die Sitzung zu Präsentationszwecken später erneut abzuspielen. Hierfür eignet sich eine stark strukturierte Speicherung, zum Beispiel mittels des XML-Formats. So können alle Ereignisse zusammen mit einer Referenz auf die betroffenen Objekte zeitlich sortiert abgelegt werden. Unter dieser Voraussetzung lässt sich eine Sitzung in allen Einzelheiten rekonstruieren und sogar zu einem späteren Zeitpunkt wieder fortführen. Dieser Mechanismus wird unter Anderem im MatchMaker-Projekt [28, 23] genutzt. Der Server legt zu jeder Session und zu jedem Benutzer eigene Log-Dateien an, welche dann im Nachhinein untersucht werden können. In den Dateien werden, je nach Loglevel, die in der Session auftretenden Ereignisse ge- 44

46 speichert (z.b. das Erzeugen, Ändern und Löschen von Knoten und Kanten oder der Beitritt von Clients). Das Listing 3.1 zeigt zum Beispiel die Systemaktionen, die erfolgen, wenn ein neuer Benutzer an einer Session teilnimmt. Jede neue Zeile beginnt hierbei mit dem Typ der Log-Nachricht, hier entweder INFO oder DEBUG. Danach kommt eine genauere Beschreibung des Ereignisses, sowie eventuell die Adresse des Clients, von dem die Aktion ausgelöst wurde. Auf ähnliche Weise werden auch Änderungen am Inhalt des JGraph protokolliert. Listing 3.1: Ausschnit einer MatchMaker-Server Logdatei INFO MmServerSession. T e s t s e s s i o n 1. addclient ( _, AuxInfo [ s e s s i o n L a b e l=t e s t s e s s i o n 1, c l i e n t L a b e l=unknown, ip = , user=v i s i t o r ] ) # DEBUG MmServerSession. T e s t s e s s i o n 1. addclient : i n t e r n a l unique id=5 INFO MmServerSession. T e s t s e s s i o n 1. PingThread. run : Thread i s running for c l i e n t 5 INFO MmServerSession. T e s t s e s s i o n 1. readsynctree ( /, AuxInfo [ s e s s i o n L a b e l=t e s t s e s s i o n 1, c l i e n t L a b e l =5, ip = , user=v i s i t o r ] ) # INFO MmServerSession. T e s t s e s s i o n 1. writesynctree ( <// 6, i n f o. c o l l i d e. xml. h e l p e r s. Point@10dc656 ( class i n f o. c o l l i d e. xml. h e l p e r s. Point )>, AuxInfo [ s e s s i o n L a b e l=t e s t s e s s i o n 1, c l i e n t L a b e l =5, ip = , user=v i s i t o r ] ) # Fehlererkennung Eine wichtige Aufgabe eines verteilten Systems ist die Vermeidung, Erkennung und Behebung von möglicherweise auftretenden Fehlern. Neben der Konsistenz des Modells, welche durch das System zu garantieren ist (siehe 3.8.2), können eine Reihe weiterer Fehler auftreten, die einen oder mehrere Clients aus der laufenden Sitzung entfernen, ohne diese ordnungsgemäß abzumelden. Dies sind zum einen Softwarefehler auf der Seite des Clients (Absturz des Clients oder des Betriebssystems), als auch Fehler bei der Übertragung, bedingt durch den Ausfall von Netzwerkkomponenten. In einem solchen Fall muss das System das Wegfallen des Clients erkennen und eventuell von diesem gesperrte Objekte freigeben. Außerdem muss eine etwaige Liste der Benutzer aktualisiert werden. In einem Client-Server-System könnte der Server hierfür in einem bestimmten Intervall Anfragen an Clients stellen, welche über einen gewissen Zeitraum hinaus inaktiv sind. Sollten diese innerhalb eines gewissen Zeitraums nicht ant- 45

47 worten, gelten sie als nicht erreichbar und werden aus dem System entfernt. Wenn man noch das Fehlverhalten von Benutzern (unabsichtliches Löschen oder Ändern von Objekteigenschaften oder Objekten) kompensieren möchte, bietet sich eine UNDO-Funktion an, die die letzten Änderungen an der Sitzung Schritt für Schritt rückgängig machen kann. Hierzu ist jedoch eine genaue Dokumentation der Änderungen notwendig, wie sie in Abschnitt beschrieben wird. Zusammenfassung In diesem Kapitel wurden die grundlegenden Kategoriesierungsmethoden von Mehrbenutzerwerkzeugen besprochen. Daneben wurde das Daffodil-Kommunikationsmechanismus auf die Erweiterbarkeit zu einem multicastfähigen System hin überprüft und die Möglichkeiten des Systemes aufgezeigt. Die vorhandenen Einbenutzerwerkzeuge wurden dann auf ihre Nutzug im Mehrbenutzerbetrieb hin untersucht und Kategorisiert. Dann wurden, ausgehend von den nicht abgedeckten Bereichen des Co-Triangles, drei Ideen zu möglichen neuen Mehrbenutzerwerkzeuge vorgestellt. Am Ende wurden noch grundlegende Verfahren zur Organisation der Gruppensitzungen besprochen. 46

48 Kapitel 4 Direkte Kommunikatioin per Chat-Werkzeug 4.1 Überblick In diesem Kapitel wird die Erweiterung von Daffodil um die Möglichkeit direkter Kommunikation mittes Chat beschrieben und auf die konkrete Implementierung eines solchen Werkzeuges eingegangen. 4.2 Motivation Der ungezwungene Austausch von Informationen in einem Gespräch ist ein wichtiger Bestandteil sozialer Interaktion. Menschen, die direkt miteinander arbeiten, benutzen Gespräche, um ihre Arbeit zu organisieren, aufzuteilen oder strukturiert zusammenzufassen. In vielen Situationen erweitern sie durch Frage- Antwort-Dialoge gegenseitig ihr Wissen. Zum Beispiel baut das Erteilen von Nachhilfeunterricht fast außschließlich auf dieser Art der Kommunikation auf. Nicht zuletzt aber finden Gespräche zwischen Gruppenmitgliedern statt, um Informationen außerhalb des aktuellen Kontexts zu tauschen, die jedoch den Gruppenzusammenhalt positiv beeinflussen und daher nicht unwichtig für die Zusammenarbeit im Allgemeinen sind. Die Nutzung dieser positiven Effekte wird durch den Ausbau der Vernetzung von Arbeitsplatzrechnern auch für dezentralisierte Arbeitsgruppen möglich. Es existieren eine Reihe von Chat- und Instant-Messenger-Systemen, die ein direktes Gespräch der Mitglieder ermöglichen und häufig weitere Funktionen (z.b. Filetransfer oder Terminkalender) enthalten. Daher liegt es nahe, einen solchen Kommunikationsmechanismus auch in das Daffodil-System zu integrieren und somit den Funktionsumfang der Anwendung zu erweitern. Dies ist im folgenden Teil dieser Arbeit beschrieben. 47

49 4.3 Grundlagen Die Grundfunktionalität des Chats ist der direkte Austausch von Nachrichten mit anderen Benutzern aus Daffodil heraus. Hierbei werden dem Benutzer mögliche Kommunikationspartner in einer Liste präsentiert. Durch diese synchrone Kommunikation wird eine Reihe von neuen Interaktionsmöglichkeiten geschaffen, welche die Nutzung des in 2.2 beschriebenen Mehrwertes möglich macht. So wird durch die Liste der anwesenden Personen die Schwelle für informelle Kommunikation herabgesetzt und das Gewahrsein anderer Benutzer regt zur Interaktion an [10, 1]. Der Mehrwert von Kommunikation in Hinsicht auf die gemeinsame Suche nach Dokumenten wird durch Gross [52], sowie Masinter und Ostrom [24] genauer untersucht. Sie sehen DLs als virtuelle Treffpunkte zum Austausch von informellen Informationen. Masinter und Ostrom gehen in ihrem Ansatz dabei sogar so weit, dass sie eine meist für Spiele genutzte Technik, den Multi User Dungeon, als Basis für eine virtuelle Bibliothek nehmen, in der man sich mittels eines virtuellen Ichs wie in einer realen Bibliothek bewegen kann. Informationen sind hierbei auf verschiedene Räume aufgeteilt und in Regalen zu finden. Benutzer können sich mit anderen Benutzern direkt von Angesicht zu Angesicht unterhalten. Externe Informationen (in diesem Fall vom Informationsdienst Gopher) können vom System angefordert werden, welches in die Rolle eines virtuellen Bibliothekars schlüpft und wie eine Person ansprechbar ist. Durch den direkten Austausch von Nachrichten ist eine Kombination des Wissens der einzelnen Benutzer, wie es im Overlay-Modell (Abschnitt 2.2.4) beschrieben wird, möglich. Der hieraus entstehende Mehrwert wird nutzbar. Die Kommunikation im Rahmen der Arbeit in einer DL kann außerdem zur Koordination von Gruppenarbeit genutzt werden. Bei einer gemeinsamen Suche in der Bibliothek kann zum Beispiel eine Suchanfrage im Vorfeld von mehreren Benutzern erstellt und diskutiert werden. Jeder Benutzer kann hierbei sein Wissen einfließen lassen. Somit ist eine effizientere Bildung von Suchanfragen möglich. Bei der Durchsicht der Ergebnisse einer Anfrage kann dann die zurückgelieferte Menge an Dokumenten auf alle beteiligten Benutzer aufgeteilt und somit schneller durchsucht werden. Auch ermöglicht der Austausch von Daffodil-Objekten wie Suchanfragen oder Dokumenten eine schnelle Verteilung von Informationen, die von mehreren Benutzern direkt diskutiert werden können. Bei Problemen mit dem System oder der Suche kann per direkter Kommunikation auf einfachem Weg Kontakt zu einem Experten aufgenommen werden. Somit wird eine schnelle Unterstützung für weniger erfahrene Benutzer ermöglicht und der Einsatz von Daffodil in Lehr-Lern-Szenarien ist denkbar. 48

50 Die persistente Ablage eines Gespräches in der PLib ermöglicht es, ein Gespräch nachträglich anzuschauen und somit den Verlauf und die Ideen gemeinsamer Arbeit zu strukturieren und festzuhalten. Aus den hier aufgeführten Ideen ergeben sich eine Reihe von Anforderungen, die im folgenden aufgelistet sind. 4.4 Anforderungen Aus den Vorüberlegungen lassen sich folgende Anforderungen an das Chat-Tool ableiten: Das Chat-Tool soll im Daffodil-Desktop integriert sein. Beginnt ein Benutzer eine Daffodil-Sitzung, so soll er ebenfalls direkt am Chat-System angemeldet werden. Um den Administrationsaufwand am Einsatzort gering zu halten, soll der Chat über die Grenzen von Servern hinaus und durch Firewalls hindurch funktionieren. So muss nicht in jedem Netz ein eigener Server aufgesetzt werden und Benutzer, welche in unterschiedlichen Teilnetzen angemeldet sind, können dennoch miteinander kommunizieren. Zur Entlastung der Administratoren soll außerdem für neu angelegte Benutzer automatisch ein Chat-Account erstellt werden. In Daffodil bestehende Arbeitsgruppen sollen hierbei auf Gruppen im Chat abbildbar sein. Der Subscription Mechanismus, also die Bekundung der Bereitschaft zur Kommunikation, soll für die Mitglieder einer Arbeitsgruppe ebenfalls automatisch durchlaufen werden (automatic mutual subscription, Abschnitt 6.1.4). Auch soll der Benutzer einen Überblick über alle angemeldeten Mitglieder seiner Arbeitsgruppe, sowie deren Status und Rolle erhalten. Meldet sich ein Benutzer an oder ab, so soll sein Status und seine Rolle allen anderen angemeldeten Benutzern seiner Gruppe bekannt gegeben werden. Dies erhöht die in Abschnitt beschriebenen Awarenessformen. Beim Erhalt einer neuen Nachricht soll der Benutzer auf diese aufmerksam gemacht werden, unabhängig davon, ob er das Chat-Werkzeug geöffnet hat oder nicht. Wünscht ein Benutzer keine Gespräche, so soll er gezielt einzelne oder alle anderen Benutzer ignorieren können. Geführte Chat-Sitzungen sollen in der Handbibliothek des Benutzers abgespeichert werden können. Dies ermöglicht eine Auswertung und Weiterverarbeitung der Informationen zu einem späteren Zeitpunkt. Neben reinen Textnachrichten soll auch der Austausch von Daffodil-Objekten per Drag and Drop über den Chat ermöglicht werden. Somit existiert ein Weg, interessante Objekte direkt an einen Gesprächspartner zu übermitteln. 49

51 4.5 Wahl der Chat-Technologie Die synchrone Kommunikation mittels Chat existiert beinahe so lange, wie es vernetzte Rechner gibt. Ihre Bedeutung nahm jedoch mit dem Entstehen des Internet und der hieraus folgenden Vernetzung der Heimrechner stark zu. Daher gibt es mittlerweile eine Vielzahl von Chat-Protokollen, die sich jedoch meist im Hinblick auf Funktionsumfang und Benutzung ähneln. Dennoch gibt es, besonders im Hinblick auf die Offenheit und Erweiterbarkeit der Protokolle, gravierende Unterschiede. Die am häufigsten verwendeten Protokolle sind meist nicht offiziell veröffentlicht und werden durch Privatpersonen analysiert und so offengelegt (z.b. das Oscar-Protokoll [53]). Andere bieten einen geringeren Funktionsumfang (z.b. das Protokoll des IRC [45]). Daher bietet sich als Protokoll zur Nachrichtenübertragung Jabber [54] an, welches seit 1998 als Client-Server basierte Technologie entwickelt wird. Jabber nutzt XML-Streams, um die Kommunikation zwischen Clients zu ermöglichen, was es sehr flexibel macht (siehe hierzu Abschnitt 6.1.2). Es ist außerdem auf die Nutzung im Bereich des Instant Messaging zugeschnitten, das Protokoll ist frei verfügbar und ist formal im XMPP Standard für XML-Streaming Protokolle beschrieben, der durch das ITEF festgelegt ist. Näheres zu diesem Protokoll ist im Abschnitt zu finden. Jabber ist, im Gegensatz zum von AIM/ICQ benutzten Protokoll Oscar [53], offen und ermöglicht die Nutzung eigener Server. Auch existieren eine Vielzahl von Messenger-Clients für die gängigen Betriebssysteme, die Jabber beherrschen. Gegenüber dem ebenfalls offenen IRC-Protokolls bringt Jabber hingegen mit dem Roster-Mechanismus (einer Liste von Kontakten), der Benachrichtigungsfunktion und der Möglichkeit, Nachrichten für nicht angemeldete Benutzer zu speichern, eine Reihe komfortabler Eigenschaften mit. Auch ist das unter beschriebene, klar strukturierte XML-Format der Nachrichten ein weiterer Vorteil. Da Jabber OpenSource ist, stehen Libraries für die Nutzung in verschiedenen Programmiersprachen und somit auch unter Java zur Verfügung. Im Falle dieser Arbeit wird der IJabberClient von Jonathan Paulson [55] verwendet. Somit ist die Erstellung eines eigenen Clients in Java und eine nahtlose Integration in Daffodil möglich. Das Format der Nachrichten ermöglicht außerdem die Erweiterung des Chat- Mechanismus um neue Funktionalität, durch Nutzung spezieller Nachrichten kann somit neben der Kommunikation mittels Textnachrichten der Austausch von Daffodil-Objekten oder die Nutzung als eine Art RPC erfolgen. Die erweiterten Nachrichtentypen werden im Abschnitt beschrieben. Die Architektur von Jabber ist dezentral angelegt und das Aufsetzen eines eigenen Jabber-Servers ist möglich. Das Jabber-Protokoll unterstützt außerdem durch sein Adressschema eine Kommunikation über Servergrenzen hinaus. Auch 50

52 ist eine Kommunikation aus Daffodil heraus mit einem externen Client möglich. Die 2002 veröffentlichten Jabber Base Protocols beinhalten die Grundlagen der XML-Streaming Technologie zuzüglich erweiterter Sicherheitsfunktionen wie SASL und TLS, sowie die Unterstützung von Internationalisierung. Dies ermöglicht den Austausch von einfachen Nachrichten und beinhaltet Erweiterungen wie Kontaktlisten (Roster), Benachrichtigungs- und Ignore-Mechanismen und die Verwahrung von Nachrichten an nicht angemeldete Benutzer (Offline- Nachrichten). Der Roster-Mechanismus von Jabber unterstützt außerdem die Zuordnung von Kontakten zu Gruppen. 4.6 Umsetzung Im folgenden wird auf die Kommunikation der Chatclients, sowie den Anmeldevorgang am System eingegangen. Danach wird das Verhalten des Clients während einer Sitzung beschrieben. Am Ende wird auf den JabberUserManager, ein Werkzeug für Administrationszwecke eingegangen Kommunikation Die Überwindung von Servergrenzen und Kommunikation mit anderen Jabber Benutzern außerhalb von Daffodil ist auf Grund der dezentral angelegten Technologie von Jabber ohne weiteres Zutun möglich, da Jabber-Server auch untereinander kommunizieren können. Eine direkte Anmeldung des Daffodil-Desktops am Jabber-Server ist jedoch auf Grund von eventuell existierenden Firewalls nicht immer möglich. Daher wird Daffodil um einen neuen Service erweitert, der die Kommunikation mit dem Jabber-Server über die existierende Daffodil-Kommunikation tunnelt und somit Gespräche über Firewall-Grenzen hinweg ermöglicht. Der neue Service, DaffodilJabberRequest genannt, in welchem der eigentliche Jabber-Client implementiert ist, übernimmt die Vermittlung zwischen Jabber- Server und Daffodil-User. Der Request läuft hierzu als Thread auf dem Daffodil-Server und somit im gleichen Netz wie der Jabber-Server. Da beide Dienste auf derselben Seite der Firewall laufen, ist eine Kommunikation zwischen Request und Jabber-Server über den für Jabber verwendeten Port möglich. Die Kommunikation zwischen Request und Daffodil-Client läuft wie gewohnt über Daffodil-Nachrichten. Der genauere Vorgang der Kommunikation wird im folgenden beschrieben. 51

53 Abbildung 4.1: Kommunikation im Chat Anmeldevorgang Meldet sich ein Benutzer am Daffodil-System an, so wird im ChatAgent eine Instanz des DaffodilJabberRequest erzeugt, der den Benutzer im Jabber- Netzwerk repräsentiert. Dieser Vorgang geschieht analog zur Erzeugung eines UserAgentRequest, der den Benutzer in Daffodil repräsentiert, durch den UserAgent. Benutzt ein Anwender das Chat-Tool, welches clientseitig läuft, so schickt dieses spezielle Daffodil-Nachrichten an das Backend. Der zum Benutzer gehörige DaffodilJabberRequest führt die entsprechende Aktion, zum Beispiel das Senden einer Nachricht oder die Abfrage des Rosters, auf dem Jabber-Server aus. Andersherum kommuniziert der Jabber-Server mit dem JabberUserRequest, der die entsprechenden Nachrichten für das Chat-Werkzeug erzeugt. Auf diese Weise lassen sich An- und Abmeldung am Server und Interaktion mit diesem, sowie jegliche Kommunikation zwischen Benutzern realisieren und sämtliche Dienste des Jabber-Servers (Roster, Subscription, Offline- Nachrichten) lassen sich nutzen. Ein Diagramm der an der Kommunikation beteiligten Klassen ist im Abschnitt im Bild 6.1 dargestellt. 52

54 4.6.3 Der Roster Der Roster ist eine Liste der Jabber-Kontakte eines Benutzers, wobei die im Roster eingetragenen Benutzer Mitglieder in unterschiedlichen Gruppen sein können. Somit lässt sich die Struktur verschiedener Arbeitsgruppen aus Daffodil auf den Chat übertragen, indem die entsprechenden Gruppenstrukturen in den Roster übernommen werden. Der Roster eines Benutzers wird bei jeder Anmeldung am Daffodil-System durch den UserJabberRequest mit den Einträgen in der Tabelle der Gruppenzugehörigkeiten abgeglichen, neue Mitglieder in einer der für den Benutzer relevanten Gruppe werden dann automatisch dem eigenen Roster hinzugefügt Mutual Subscription Der Subscriptionmechanismus von Jabber regelt die mögliche Richtung der Kommunikation. Im Falle von Daffodil soll eine gegenseitige Übermittlung von Nachrichten möglich sein, somit muss auch eine gegenseitige Berechtigung (Mutual-Subscription) erfolgen. Mehr hierzu ist unter Abschnitt zu finden Erhalt neuer Nachrichten Über den Erhalt einer Nachricht kann ein Benutzer auf zwei Arten aufmerksam gemacht werden: 1. Hat der Benutzer das Chat-Tool in diese Sitzung noch nicht geöffnet oder wieder geschlossen und es trifft eine Nachricht für ihn ein, so verändert sich das Icon in der Werkzeug-Leiste. Die beiden stilisierten Köpfe tauschen im Sekundentakt die Plätze. Diese Methode ist unauffälliger als ein Popup-Window und der Benutzer kann zuerst ungehindert seiner aktuellen Aufgabe nachgehen, bevor er sich um die Nachricht kümmert. 2. Hat der Benutzer das Chat-Tool mit einem einzelnen Dialog geöffnet oder erhält eine Nachricht auf dem aktuell sichtbaren Dialog, so wird diese umgehend angezeigt. 3. Hat der Benutzer mehrere Chat-Dialoge gleichzeitig geöffnet, so werden überdeckte Dialoge durch ein * vor dem Namen gekennzeichnet, wenn für diese neue Nachrichten eingetroffen sind. 53

55 4.6.6 Grafische Umsetzung des Chat-Tools Abbildung 4.2: Daffodil Chat Tool Hier werden die einzelnen Elemente der grafischen Oberfläche des Chat- Werkzeugs besprochen. Die grafische Anzeige des Werkzeugs lässt sich in zwei Bereiche aufteilen. Der obere Bereich enthält die Liste aller angemeldeten Benutzer, die dem Benutzer bekannten sind. Der untere Bereich enthält die geöffneten Chat-Dialoge. Die Benutzerliste Liste (1) zeigt folgende Informationen an: Das kleine Symbol ganz links beschreibt die Rolle des Benutzers im System. Die eigene Rolle wird dabei beim Erhalt einer Presence Message dem Absender dieser Nachricht mitgeteilt. Die grobe Unterteilung der Benutzer soll bei der Kontaktaufnahme helfen und erfahrene Benutzer direkt kennzeichnen und entspricht einer der folgenden drei Alternativen: - Novice: Der Benutzer ist Daffodil Neuling oder seine Rolle ist nicht bekannt (z.b. ein anderer Jabber-Client) - Expert: Der Benutzer ist erfahrener im Umgang mit Daffodil - Librarian: Der Benutzer hat den Status eines Bibliothekars in einer Bibliothek und kann für Fragen zu einem Thema angesprochen werden Danach folgt der Name, unter dem der Benutzer im eigenen Roster steht. Im Normalfall ist es der Anmeldename aus der JavaID (siehe Listing 6.1). Ist der Name ausgegraut, so ist er vom System als nicht verfügbar gekennzeichnet. Beim Eintreffen einer Presence Message (siehe Abschnitt 6.1.2) wird die Liste 54

56 automatisch angepasst. Durch Anwählen eines Benutzernamens per Maus wird ein entsprechender Chatdialog geöffnet oder in den Vordergrund gebracht. Das stilisierte Ohr symbolisiert den Zustand der Ignore-Funktion für den entsprechenden Benutzer. Ist es grün unterlegt, so werden Nachrichten von diesem Benutzer entgegengenommen. Ist der Hintergrund hingegen rot und das Ohr durchgestrichen, so wird dieser Benutzer ignoriert. Dies verhindert die Anzeige von neuen Nachrichten und das Öffnen von neuen Chat-Dialogen. Außerdem erhält der Versender der Nachricht einen Hinweis, dass der gewählte Benutzer nicht zu sprechen ist. Durch Betätigung des Ohr-Symbols rechts oben über der Liste wird die globale Ignore-Funktion eingeschaltet. Ignoriert der Benutzer alle ankommenden Nachrichten, so wird sein Status durch eine Nachricht an den Jabber-Server generell auf nicht verfügbar gesetzt. Der Server propagiert diese Statusänderung an alle angemeldeten Chat-Tools derselben Gruppe, welche den Namen des Benutzers ausgrauen. Die Aufteilung der Kontakte in verschiedene Benutzergruppen, sowie die Bekanntgabe der Benutzerrolle (Novice, Expert, Librarian) und des aktuellen Status erhöhen die in Abschnitt beschriebene GroupAwareness. Im Feld der Dialogfenster (2) entspricht jeweils ein Tab einem Dialog mit einem anderen Benutzer. Hat ein Benutzer eine neue Nachricht geschickt und das Dialogfenster befindet sich nicht an oberster Stelle, so erhält der Name ein * als Markierung. Nicht aktive Benutzer werden hier ebenfalls ausgegraut. Jedes Dialogfenster beinhaltet außerdem zwei Knöpfe, einen zum Schließen des Dialoges und einen zum Abspeichern. Darunter folgt das Dialogtextfeld, in dem das Gespräch dargestellt wird, und das Eingabetextfeld für die eigenen Beiträge zum Gespräch. Im Ausgabefeld wird jeder Textbeitrag durch den Namen des Teilnehmers gekennzeichnet, der ihn gesendet hat. Der Name ist dem Beitrag vorangestellt und zur schnelleren Unterscheidung farbig markiert Persistenz und Logging Generell wird jeder Dialog zwischen zwei Benutzern vom UserJabberRequest, also serverseitig, in einer XML-Datei gespeichert. Diese ist jedoch für den Benutzer im Normalfall nicht zugänglich. Daher erhält er die Möglichkeit, ein Gespräch mittels des Knopfes Save Session im aktuell angewählten Ordner der PLib zu speichern. Dieser Eintrag enthält den gesamten im Ausgabefenster angezeigten Text Austausch von Daffodil-Objekten Eine weitere Funktion ist der Austausch von Daffodil-Objekten im Rahmen eines Dialoges. So können diese Objekte direkt in den Kontext eines Gespräches eingebettet werden. Dadurch findet ein schneller Austausch von wichtigen Dokumenten oder Informationen wie zum Beispiel einer Suchanfrage statt. Diese 55

57 einfache Möglichkeit, Wissen weiterzugeben, erleichtert die Zusammenarbeit. Ein zu versendendes Objekt muss vom Typ SimpleDataTransfer sein oder dieses erweitern (Siehe Abschnitt 6.1.1). Zieht der Benutzer dieses auf das Eingabefeld eines Dialogfensters, so wird die XML-Repräsentation des Objektes mittels einer für den Datentransfer eingeführten Nachricht (siehe Abschnitt 6.1.3) per Jabber an den Empfänger gesendet. Dieser kann das übertragene Objekt aus dem Ausgabefenster heraus auf das entsprechende Werkzeug oder seine PLib ziehen und wie gewohnt weiterverarbeiten Administration Um den Administrator zu entlasten, ist ein Werkzeug implementiert worden, welches die folgenden Aufgaben übernimmt: Aus der bestehenden Benutzerdatenbank soll für jeden Benutzer ein Jabber- Account generiert werden. Ausserdem sollen dem Roster alle Mitglieder seiner Arbeitsgruppen hinzugefügt werden. Es soll weiterhin einen einfachen Weg geben, Benutzer zu generieren und zu löschen, sowie sich deren Roster anzuschauen, um manuell Veränderungen vorzunehmen. Das Programm soll außerdem im Hintergrund des Daffodil-Systems als Jabberadministrator angemeldet sein. Dort soll es bei jedem Anmelden des Benutzers dessen Roster auf Aktualität prüfen und eventuell Kontakte hinzufügen oder entfernen. Diese drei Aufgaben sind im JabberUserManager umgesetzt, der für jede Aufgabe einen Funktionsmodus besitzt. Automatischer Modus : Die Hauptfunktion des JabberUserManager ist es, automatisch für jeden Daffodil-Benutzer einen passenden Jabber-Account zu erstellen. Hierzu wird der JabberUserManager mit dem Parameter -a aufgerufen und läuft im automatischen Modus. Die Benutzernamen und Passwörter erhält er hierbei aus der Daffodil-Datenbank. Er sucht alle Einträge in der Tabelle fs_users, deren Eintrag in der Spalte jabber den Wert 0 oder NULL hat und deren Passwort nicht NULL ist. Dann erstellt er für diese Benutzer aus Benutzername und Passwort einen Jabber-Account, trägt in der Benutzertabelle für diesen Benutzer im Feld jabber den Wert 1 ein und fügt den gerade erstellten Benutzer seinem Roster hinzu. In diesem Roster sind somit alle Benutzer des Systems vorhanden, weswegen es auch Systemroster genannt wird. Den gesamten Vorgang schreibt er außerdem in ein Logfile, um das Auffinden eventuell aufgetretener Fehler zu ermöglichen. 56

58 Interaktiver Modus : Die zweite Nutzungsmöglichkeit ist das Betrachten und Erstellen von Jabber-Accounts im interaktiven Modus. Dieser Modus ist dafür gedacht, Änderungen an Accounts einzelner Benutzer zu ermöglichen. Im Moment unterstützt es das Anlegen und Löschen von Benutzern, sowie das Einsehen des Benutzerrosters. Daemon-Modus : Außerdem wird im Backend eine Instanz des JabberUser- Managers gestartet, welche vom UserJabberRequest Anfragen bezüglich des Benutzer- und Systemrosters, sowie der Gruppenmitglieder entgegennehmen kann. Diese Informationen werden zur Aktualisierung des Benutzerrosters genutzt. Zusammenfassung In diesem Kapitel wurden die Vorteile der direkten Kommunikation, sowie ihr Nutzen im Rahmen von Daffodil besprochen. Die an ein Chat-System gestellten Antworten wurden analysiert und mit Jabber eine passende Technologie für die Implementierung gefunden. Außerdem wurden Implementierung, Aussehen und Funktion des während dieser Arbeit entstandenen Chat-Tools beschrieben und kurz auf den JabberUserManager als Administrator-Werkzeug eingegangen. 57

59 Kapitel 5 Das WhiteBoard-Werkzeug 5.1 Überblick Im folgenden Kapitel werden die Implementierung des Diskussions-Werkzeuges (Whiteboard-Tool) und die hierbei genutzten Technologien beschrieben. 5.2 Motivation Vor allem im Bereich Bewertung, Diskussion und Erzeugung von Wissen ist eine grafische Diskussion, zum Beispiel an Hand eines Whiteboards, ein gutes Mittel, um die in einer Arbeitsgruppe vorhandenen Ideen und Argumente zu erfassen, zu strukturieren und allen Mitgliedern zur Verfügung zu stellen. Daher finden sich in fast allen Seminar- und Besprechungsräumen Tafeln, Whiteboards oder FlipChart Lösungen. Auch gibt es für viele Anwendungsgebiete (z.b. Software Entwicklung, Moderation, Strategieentwicklung oder Produktions- oder Changemanagement) standardisierte grafische Darstellungen und Sprachen wie zum Beispiel Flow Charts, Question Option Criterion oder die Unified Modeling Language, sodass die Diskussionsergebnisse auch für Außenstehende leicht lesbar und nachvollziehbar sind. Daher liegt eine Integration eines verteilt nutzbaren Whiteboards zur grafischen Bearbeitung und Diskussion von Wissen in Daffodil nahe. Ein solches Werkzeug ermöglicht eine Erweiterung von Daffodil auf die Bereiche Bewertung der Ereignisse und Erzeugung von Wissen des in Abschnitt 3.3 beschriebenen Zyklus des Wissensmanagements und besetzt die letzte verbleibende Spitze ( Cooperation ) des Co-Triangles (siehe hierzu Abschnitt 3.6.9). 5.3 Existierende Werkzeuge Für Lern- und Arbeitsgruppen, deren Teilnehmer sich an verschiedenen Orten befinden, die jedoch nicht auf die Unterstützung durch ein grafisches Diskussionswerkzeug verzichten wollen, existieren schon eine Reihe von Produkten. 58

60 Das Projekt digalo[56] der Fraunhofer AIS ist eine Software, die grafische Diskussionen unter anderem in den Bereichen Abwägediskussionen, Argumentationskarten, Brainstorming, Ursache-Wirkungsmodelle und Priorisierungen ermöglicht. Die Projekte CoolModes und Free Styler der Collide Gruppe[57] ermöglichen grafische Diskussionen und gemeinschaftliche Entwicklungsprozesse in einer Vielzahl von Bereichen. Grafische Elemente (Knoten und Kanten) können auf einer Zeischenfläche positioniert werden. Diese Elemente beschreiben neben ihrem Aussehen auch die Semantik der einzelnen Symbolsprachen. Es können beliebige Symbolsprachen gleichzeitig auf einer Zeichenfläche genutzt werden können. Das Framework der Produkte ist über Symbolpaletten, sogenannte Reference Frames, flexibel um weitere Symbolsprachen erweiterbar. Breeze[58], ein kommerzielles Produkt der Firma Macromedia stellt einer Gruppe von Benutzern per Browser mit Flash-Plugin einen virtuellen Seminarraum zur Verfügung, der neben einem Text- und Videochat eine gemeinsame Zeichenfläche enthält und die Wiedergabe von Präsentationen ermöglicht. Einen weiteren Bereich stellen Anwendungen zur Kopplung des gesamten Arbeitsplatzes dar. Die Software NetMeeting von Microsoft [50] ermöglicht neben Video and Audio Conferencing, Chat, File Transfer, einem Whiteboard und Program Sharing eine solche Freigabe ( Remote Desktop Sharing ) und damit die Fernsteuerung des Rechners. Einen ähnlichen Ansatz verfolgt die Remote- Desktop-Software VNC der Firma RealVNC [59]. Hier können Experten direkt mit dem System des Benutzers interagieren, was die Auffindung von Fehlern vereinfacht. Daher werden Remote-Desktop-Lösungen häufig im Bereich des Usersupports eingesetzt. Diese Produkte können parallel zur Arbeit mir Daffodil genutzt werden. Eine Integration eines solchen Werkzuges in das Daffodil-System brächte jedoch Vorteile mit sich. Der Benutzer kann nun alle Arbeiten in der gewohnten Daffodil-Umgebung bearbeiten und muss nicht zwischen mehreren Anwendungen wechseln. Auch kann direkt auf die von Daffodil verwendeten Objekte zugegriffen werden. Der Nutzen eines solchen Werkzeuges soll an folgendem Szenaro verdeutlicht werden. 5.4 Szenario Im Rahmen eines Schulprojektes im Informatik-Unterricht hat eine Arbeitsgruppe von Schülern die Aufgabe erhalten, Informationen zum Thema Der Umgang mit Informationen im World Wide Web zu sammeln und für einen Vortrag geeignet aufzubereiten. Ein Teilbereich soll die Darstellung der Vor- und Nachteile der aktuellen Struktur des WWW sein. Da nicht immer alle Mitglieder der Arbeitsgruppe an einem Ort versammelt sind, erhalten die Schüler von ihrem Lehrer den Tip, Daffodil zu nutzen und neben der reinen Suchfunktion intensiv Gebrauch von den Mehrbenutzer- 59

61 Werkzeugen zu machen. Hierfür erhält jeder Schüler einen eigenen Daffodil Anmeldenamen mit zugehöriger Handbibliothek. Daneben wird eine Arbeitsgruppe mit geteilter PLib und einem Gruppenchat eingerichtet. Der Lehrer stellt sich außerdem als Experte für Rücksprachen zur Verfügung. Um eine verteilte Suche nach Informationen zu koordinieren, nehmen die Schüler zuerst einmal per Gruppenchat eine grobe Einteilung der Suchthemen vor. Dann macht sich jedes Mitglied der Arbeitsgruppe auf die Suche nach Informationen zu seinem Thema. Da die Schüler im Umgang mit Daffodil ungeübt sind, nutzen sie die Möglichkeit, per Chat Informationen bei ihrem Lehrer anzufordern. Die im Rahmen der Suche gefundenen Ergebnisse werden in der geteilten Handbibliothek in themenbezogenen Unterordnern abgelegt. Nachdem die Gruppenmitglieder mit ihrer Suche fertig sind, verschaffen sie sich jeweils grob einen Überblick über die zu den anderen Themenbereichen gefundenen Dokumente und machen gegebenenfalls Annotationen. Nun werden die einzelnen Teilbereiche der Aufgabe in der Gruppe besprochen. Hierzu erstellt der für den jeweils besprochenen Bereich verantwortliche Schüler eine neue Session im Diskussionstool und läd die anderen Gruppenmitglieder zu einer Besprechung und Diskussion der Ergebnisse seines Themenbereiches ein. Hier werden die Inhalte der einzelne Dokumente, sowie die Annotationen gemeinsam diskutiert und wichtige Informationen festgehalten und bewertet. Hierzu wird reger Gebrauch von den vorhandenen Elementen der einzelnen Diskussionssprachen gemacht. Auch sprechen sich die Schüler untereinander immer wieder per Chat ab. Die Ergebnisse einer jeden Sitzung werden dann vom Moderator im entsprechenden Verzeichnis der geteilten PLib abgelegt. In einer weiteren Sitzung kann mit der Planung des Vortrages begonnen werden. Die Schüler sind bei ihrer Suche häufig über den Begriff des Semantic Web gestoßen. Sie wollen diese Technologie dem aktuellen WWW gegenüberstellen und die Vor- und Nachteile an Hand einer QOC-Diskussion visualisieren. Das Diskussionsergebnis soll direkt im Abschlussvortrag verwendet werden. Zur Erstellung des Abschlussvortrages bedienen sich die Schüler einer weiteren Palette, die es ermöglicht, einzeln erstellte Textteile in eine strukturierte Reihenfolge zu bringen und hieraus automatisch ein zusammenhängendes Dokument zu erstellen. Der Lehrer soll zu jeder Zeit die Möglichkeit haben, den Gruppensitzungen per Whiteboard-Tool beizuwohnen, um einen groben Überblick über die Beteiligung der einzelnen Mitglieder zu erhalten. 5.5 Anforderungen Das zu erstellende Werkzeug soll also folgende Funktionalität liefern: 60

62 Es ist nahtlos in den Daffodil-Desktop integriert, das Erstellen oder Beitreten zu Sitzungen kann dabei ohne großen Aufwand erfolgen. Ebenso ist das Laden und Speichern von Gruppensessions in der PLib möglich. Daffodil-Objekte, wie Anfragen, Suchergebnisse oder Dokumente, lassen sich per Drag n Drop direkt in Diskussionen einfügen. Dabei wird ebenfalls ein Abrufen der Detailinformationen ermöglicht. Zur grafischen Diskussion stehen Standardsymbole und gängige Diskussionssprachen zur Verfügung. Eine Liste aller angemeldeten Benutzer wird angezeigt, um das Benutzergewahrsein zu erhöhen. Hierbei soll die direkte Interaktion unterstützt werden, indem bei Anwahl eines Benutzers automatisch ein Chat-Dialog zu diesem Benutzer geöffnet wird. Auch muss es möglich sein, zu jedem Objekt den Namen des Erzeugers und eine Liste der Bearbeiter zu erhalten, um im Nachhinein eine grobe Analyse der Beteiligung einzelner Benutzer zu ermöglichen. Eine History-Funktion zeigt die letzten Änderungen an der textuellen Beschreibung der eingefügten Objekte an. 5.6 Implementierung der Werkzeugs Der Aufwand der Neuentwicklung eines solchen Werkzeuges mit all seinen Mechanismen ist sehr hoch. Auch existieren mit den Produkten JGraph und Match- Maker der Collide Gruppe bereits zwei Technologien, die große Teile der Anforderung erfüllen. Diese lassen sich ohne hohen Aufwand in Daffodil integrieren. Daher werden diese Technologien bei der Implementierung des Werkzeuges genutzt. Im folgenden werden die Technoligien zuerst näher beschrieben. Danach wird näher auf die Integration dieser Technologien in das Whiteboard-Tool und auf die Erstellung des Daffodil-Reference-Frames (die Daffodil-Palette) eingegangen. Auch werden die Lösungen für die nicht direkt durch den JGraph erfüllten Anforderungen beschrieben. Am Ende wird das fertige WhiteBoard- Werkzeug vorgestellt Die JGraph Implementierung der Collide Gruppe Der JGraph ist eine von zwei Technologien der Collide Gruppe [57], die in dieser Arbeit Verwendung finden. Er ist, wie auch das MachtMaker-System in Java implementiert. Der JGraph stellt die Implementierung und Visualisierung einer zweidimensionalen Graphstruktur, bestehend aus Knoten und Kanten, dar. Die Implementierung von Knoten und Kanten des JGraphs folgt streng dem Model-View-Controller-Paradigma. Daten, Aussehen und Verhalten sind also jeweils in eigenen Klassen untergebracht. Dies macht die Objekte übersichtlicher 61

63 und außerdem flexibler, da die einzelnen Aspekte schnell gegen Alternativen getauscht werden können. In einer Arbeitssitzung oder Session können Knoten per Drag n Drop frei auf dem JGraph positioniert und später verschoben oder durch Herausziehen aus dem Graph gelöscht werden. Kanten können zwischen zwei Knoten gezogen werden und werden beim Verschieben eines Knotens auf der Zeichenoberfläche dynamisch angepasst. Alle verfügbaren Objekte des JGraphs sind in Paletten, sogenannten Reference Frames gruppiert und können als Plugins geladen und untereinander kombiniert werden. Sie können außerdem eigene Funktionen beinhalten. Auch können Regeln für die Interaktion und Kombination dieser Knoten untereinander erstellt werden. So ist es möglich Paletten zu erstellen, die Abläufe von Modellen nachstellen. Es existieren unter anderem Paletten für Petrinetze, System Dynamics oder QOC-Diskussionen. Per MatchMaker [23] lassen sich mehrere Instanzen des JGraphs koppeln und synchronisieren. Außerdem besitzt ein JGraph die Fähigkeit, seinen Inhalt in eine XML-Datei zu speichern oder sich aus einer solchen zu konfigurieren, was eine Wiederverwendung zu einem späteren Zeitpunkt ermöglicht. Der JGraph findet unter anderem konkrete Anwendung in den Collide Produkten CoolModes [36] und Free Styler Die MatchMaker Technologie Die Technologie des MatchMaker [23], welche ebenfalls von der Collide Gruppe entwickelt wird, ist eine Rahmenapplikation für kollaborative Java Anwendungen. Die Struktur von MatchMaker ist Client-Server basiert, wobei die Daten jedoch clientseitig repliziert werden und somit auch nach einem Ausfall der Verbindung zum Server weiterhin vorhanden sind. Ein MatchMaker-Server kann genutzt werden, um mehrere Instanzen eines JGraphs mittels MatchMaker-Clients zu koppeln. Dabei bindet er die einzelnen JGraphen in einen internen Synchronisationsbaum ein und ermöglicht den Clients die Koppelung des gesamten Baumes oder beliebiger Teilbäume ( partielles coupling ). Für das Erstellen und Betreten einer Sitzung stellt die MatchMaker-Technologie fertige Dialoge zur Verfügung Integration der Technologien in Daffodil JGraph und Matchmaker sind übersichtlich implementiert und lassen sich mit geringem Aufwand in das Daffodil-System einbinden. Hierbei können schon vorhandenen Reference Frames genutzt werden. Spezielle Anforderungen durch 62

64 Daffodil lassen sich hingegen durch die Erstellung einer eigenen Paletten erfüllen. Auch wird die Klasse JGraph durch die Klasse WhiteBoard um folgende Funktionen erweitert: Durch Überschreiben der Methode dropdata kann das WhiteBoard feststellen, ob das Ziel des Drops eventuell ein Knoten des Typs DaffodiObjectNode ist und das fallengelassene Objekt an diesen weitergeben. Dies ist für die Ablage von Dokumenten auf solchen Knoten notwendig. Im weiteren bestimmt dropdata auch, ob es sich bei dem fallengelassenen Objekt um eine in der PLib abgelegte WhiteBoardSession handelt und rekonstruiert diese gegebenenfalls. Dies ermöglicht das Öffnen einer gespeicherten Sitzung durch Drag n Drop. Durch Überschreiben der Methode actionexecuted lässt sich der Benutzer, welcher das Event auslöst, der Liste der Benutzer des Objektes hinzufügen. Hierzu muss das veränderte Objekt das Interface DaffodilModel implementieren. Dies steigert die GroupAwareness des WhiteBoards (siehe Abschnitt 2.2.3), da ersichtlich wird, welcher Benutzer Änderungen an dem Objekt vorgenommen hat. Mehr zu den speziellen Funktionen der Daffodil-Knoten finden sich in Abschnitt Die Darstellung des WhiteBoards erfolgt innerhalb eines LayeredContainers mit zwei Schichten. Die eine Schicht enthält das WhiteBoard direkt und ist für die Darstellung des WhiteBoards, sowie für die Platzierung der Knoten und die Interaktion mit diesen zuständig. Die zweite Schicht enthält einen TransparentLayer, der wiederum das WhiteBoard enthält. Dieser Layer ist immer dann aktiv, wenn Kanten gezeichnet oder entfernt werden sollen. Nun ist die eigentliche Zeichenfläche vorbereitet. Es folgt die Einbindung der genutzten Paletten in der Methode inittools. Hier werden die verwendeten Paletten dem Werkzeugbereich der GUI (siehe dazu 5.6.5) hinzugefügt und initialisiert. Dieser Vorgang ist recht ausführlich im JGraph Howto der Collide Gruppe [22] beschrieben. Im Prinzip sind alle Paletten, welche für den JGraph entwickelt wurden, auch mit dem WhiteBoard nutzbar. Daher werden folgende, für Diskussionen geeignete Paletten eingebunden: Die Palette für Question-Option-Criterion Diskussionen Diese Palette setzt das in beschriebene erweiterte Diskussionsmodell um, die Elemente sind in Abbildung 5.1 dargestellt. Es existieren drei Knotentypen in unterschiedlichen Farben, jeweils einer für die Elemente Question (rot), Option (blau) und Criterion (gelb). Die unterschiedliche Farbgebung lässt hierbei schnell die unterschiedlichen Funktionen erkennen. Jeder Knoten enthält ein Eingabefeld für Text. Der Option-Knoten enthält außerdem ein Feld für seine Bewertung, der Criterion-Knoten ein Feld für die Angabe der Relevanz. Außerdem enthält die Palette drei Kantentypen. Die Question Option Edge ist hierbei für die Verbindung von Frage und Option vorgesehen, die positive 63

65 (grün) und die negative (rot) Bewertungskante verbinden Optionen und Kriterien und können jeweils gewichtet werden, wobei sich die Farbintensität mit dem Wert ändert. Die Palette nimmt die Bewertung der Optionen automatisch vor und markiert die beste Option, bzw. die besten Optionen durch Ändern der Überschrift des Knotens. Abbildung 5.1: Die Elemente der QOC-Palette Die Palette EasyDiscuss Diese Palette enthält fünf einfache Textknoten (siehe Abbildung 5.2) für die Elemente Pro, Question, Contra, Fact und Text, sowie eine einfache ungerichtete Kante. Mit diesen Elementen ist sowohl die Diskussion, als auch die Erstellung von Wissen möglich. Abbildung 5.2: Die Elemente von EasyDiscuss Das Daffodil-Reference-Frame Ein weiteres Ziel des WhiteBoard-Tools ist es, Daffodil-Objekte, wie Dokumente oder Anfragen, in Diskussionen mit einzubringen. Hierfür bedarf es eines neuen Knotentyps, welcher solche Objekte entgegennehmen und den Benutzern der Diskussion geeignet zur Verfügung stellen kann. 64

66 Auch ist es von Interesse, zu einem fortgeschrittenen Zeitpunkt einer Diskussion Informationen über die Benutzer zu erhalten, welche Änderungen an einem Objekt vorgenommen haben. Daher implementieren alle Daffodil-Knoten eine Liste dieser Benutzer Um die neu erstellten Knoten zu nutzen ist mit dem WhiteBoardRefFrame eine neue Palette erstellt worden (siehe Abbildung 5.3. Sie enthält zwei weitere Knoten. Der SimpleWhiteBoard-Node kann zur Darstellung von einfachem Text genutzt werden. Der Knoten DaffodilObject hingegen ist in der Lage, Objekte des Daffodil-Systems in eine WhiteBoard-Sitzung einzubringen. Des weiteren existieren drei Kanten für generelle Verknüpfung, Zustimmung und Verneinung, die an die Kanten der QOC-Palette angelehnt sind, jedoch nicht über eine eigene Bewertung verfügen. Abbildung 5.3: Die Elemente der Daffodil-Palette Die Interfaces DaffodilNode und DaffodilModel Alle Knoten der Daffodil-Palette müssen die Interfaces DaffodilNode im Controller sowie DaffodilModel im Model implementieren. Die beiden Interfaces sind im folgenden kurz beschrieben: Das Interface DaffodilNode verpflichtet den Knoten die Methode setmetadata zu implementieren, durch welche die Metadaten eines Daffodil- Objektes an den Knoten übergeben werden. Das Interface DaffodilModel verpflichtet den Knoten die beiden Methoden addeditor und geteditors bereit zu stellen, um den Umgang mit der Liste der Editoren zu ermöglichen. Der Simple WhiteBoardNode Dieser Knoten ist eine erweiterte Kopie eines QOC-Knotens, der die Möglichkeit besitzt, eine Benutzerliste und eine History zu führen und somit um grundlegende Funktionen der Groupawareness erweitert ist. 65

67 Der Daffodil-Objekt-Knoten zur Interaktion mit Daffodil-Objekten Der Daffodil-Objekt-Knoten besitzt neben der Möglichkeit, eine Benutzerliste zu führen, eine weitere Erweiterung. Er kann Daffodil-Objekte auf zwei Arten entgegennehmen: per Drag n Drop: Daffodil-Objekte werden über den Knoten gezogen und fallen gelassen. per DropTarget: Durch anklicken des Knopfes Open Drop-Target öffnet sich ein kleines gelbes Fenster in der linken oberen Ecke des Bildschirmes, auf welches man ein Daffodil-Objekt ziehen kann. Ist einem Knoten ein Daffodil-Objekt übergeben worden, so ändert dieser die Beschriftung seines Knopfes in den Namen des Dokuments und zeigt auf Wunsch dessen Details in einem neuen Fenster an (siehe Abbildung 5.7). Diese Details sind jedoch nicht im Knoten selber gespeichert, sondern liegen im Backend vor. Der Knoten kennt jedoch die für die Anfrage notwendige ObjectID des Dokumentes und kann die Daten bei Bedarf anfordern. Die hierfür notwendie Verbindung zum Backend wird dabei über eine Singleton Instanz der Klasse DaffodilMediator hergestellt. Der Mediator fragt das zu einer ObjectID gehörige Metadata-Objekt deim Backend an, welches diese aus der Datenbank holt und zurücksendet. Dann liefert er die Informationen an den Knoten zurück Das WhiteBoard-Tool von Daffodil Funktion des Werkzeugs Das WhiteBoard-Tool wird, analog zu den anderen Werkzeugen von Daffodil über die Werkzeugleiste geöffnet. Beim Öffnen zeigt die grafische Anzeige des Werkzeuges das Formular für die Parameter der Serververbindung an (siehe Abbildung 5.4). Hier ist es möglich, einen lokalen Server zu starten oder sich mit einem existierenden Server zu verbinden. Danach kann auf dem entweder einer bestehenden Sitzung beigetreten oder eine neue erzeugt werden. Für diese beiden Schritte wird ein bereits vom Match- Maker-Client zur Verfügung gestellter Dialog genutzt. Dieser zeigt beim Beitritt zu einer Sitzung weitere Informationen, wie eine Liste aller Sessions auf dem Server und die an ihnen beteiligten Benutzer, an (siehe Abbildung 5.5). Nach dem Erzeugen oder dem Beitritt zu einer Session wird die Anzeige des Werkzeuges in den WhiteBoard-Modus geschaltet (siehe Abbildung 5.6). Eine neue Instanz der Klasse WhiteBoard, welche den Collide JGraph erweitert, wird mit der Session gekoppelt und im Fall einer bestehenden Session direkt mit den Daten auf dem Server synchronisiert. Somit erhält das WhiteBoard alle bereits vorhandenen Knoten und Kanten samt ihrer Daten. Nun können Knoten von den eingebundnen Paletten auf die Zeichenfläche gezogen und dort je nach ihrer Funktion bearbeitet werden. Zwischen den Knoten können Kanten erzeugt werden. Hierzu schaltet man die Palette durch Anwahl einer Kante in den Kantenmodus und selektiert nacheinander zwei Knoten durch 66

68 Anklicken. Zwischen diesen Knoten wird dann eine Kante erzeugt, wenn es keine Anwendungsregel gibt, die dies untersagt. Durch die Nutzung solcher Regeln, die vorschreiben, welcher Knotentyp mit welchem weiteren über eine gewählte Kante verbunden werden können, läßt sich die Semantik eines Systems abbilden. Im folgeden wird das WhiteBoard-Tool an Hand eines kleinen Szenarios genauer vorgestellt. Szenario Abbildung 5.4: Öffnen des WhiteBoard-Tools durch Simone Martin hat ein Dokument gefunden, über das er sich mit Simone unterhalten möchte und bereits eine Sitzung gestartet, in der er seine Frage formuliert. Simone möchte der Sitzung beitreten und ihm helfen. Beim Öffnen des WhiteBoard-Tools erscheint dabei zuerst ein Fenster mit Verbindungsparametern (Abbildung 5.4). Hier kann man einen Server auf dem lokalen Rechner starten, eine neue Sitzung beginnen oder einer existierenden Sitzung beitreten. Für die beiden Sitzungsoptionen wird der angegebene Name des Servers und Port als Voreinstellung genommen, wobei der Servername im weiteren Verlauf noch geändert werden kann. Simone klickt auf Join, ein Dialogfenster öffnet sich und auf dem voreingestellten Server wird nach bereits vorhandenen Sitzungen gesucht (Abbildung 5.5). Sie ändert den Servernamen (1) und gibt den Namen von Martins Rechner ein. Die dort existierende Sitzung wird im der Sitzungsliste (2) angezeigt. Diese kann durch Anwählen näher betrachtet werden. Der Fensterbereich mit den Sitzungsinformationen (3) gibt Auskunft über den Sitzungsinitiator, das Erstellungsdatum und die gerade angemeldeten Benutzer. Das Erstellen einer Sitzung verläuft ähnlich. Hier kann der Benutzer den 67

69 Abbildung 5.5: Simone möchte einer Sitzungs beitreten voreingestellten Servernamen ändern und der Sitzung einen beliebigen Namen geben. Der Umgang mit Sitzungen soll so einfach wie möglich erfolgen, um auch unerfahrenen Benutzern offen zu stehen. Daher wird auf die Einführung eines Moderators oder Superusers mit erweiterten Rechten verzichtet. Auch steht der Beitritt zu existierenden Sitzungen jedem Benutzer frei. Simone drückt OK, das WhiteBoard Fenster wird erstellt. Dieses Fenster besteht aus drei Teilen (Abbildung 5.6). Den größten Teil nimmt die Zeichenfläche des WhiteBoards ein (1). Betritt man eine Session, die bereits Daten enthält, so werden diese auch direkt auf der eigenen Zeichenfläche angezeigt. Am rechten Rand befinden sich die anderen beiden Teilbereiche. Der obere Bereich enthält eine TabbedPane mit den zur Verfügung stehenden Paletten (2). Der untere Bereich des Fensters enthält die Liste der angemeldeten Benutzer und die Knöpfe zum Abspeichern, Laden und Verlassen einer Sitzung (3). Alle Benutzer können mit den gegebenen Knoten und Kanten agieren und ihre Funktionen ausführen. Änderungen werden zeitgleich auf allen angemeldeten WhiteBoards sichtbar. Simone schaut zuerst die für das Dokument verfügbaren Detailinformationen an (Abbildung 5.7). Dazu klickt sie auf den Knopf des Daffodil-Objekt- Knotens (1). In dem sich öffnenden Fenster (2) erhält sie die Informationen in einer ähnlichen Darstellung, wie sie der Detail-Viewer der PLib liefert. 68

70 Abbildung 5.6: Der WhiteBoard-Modus Abbildung 5.7: Detailansicht eines Daffodil-Objektes 69

71 Simone sucht mit dem Suchwerkzeug nach Dokumenten mit einer ähnlichen Thematik und wird fündig. Abbildung 5.8: Verknüpfung von Daffodil-Objekten Sie legt einen neuen Daffodil-Objekt-Knoten an (Abbildung 5.8), indem sie die entsprechende Palette wählt und den Knoten auf die WhiteBoard Fläche zieht. Dann legt sie das gefundene Dokument per Drag n Drop auf dem Knoten ab und verbindet ihn mit einer positiven Kante mit dem von Martin erstellten Knoten. Im Textfeld des Knotens gibt sie die Begründung ein, warum sie dieses Dokument für geeignet hält. Auf diese Weise arbeiten die Beiden weiter, bis sie eine Reihe von Informationen gesammelt haben. 5.7 Awarenessfunktionen MatchMaker ermöglicht es jedem Client, eine Liste aller an einer Session angemeldeten Benutzer zu erhalten. Daher ist es einfach möglich, in der Anzeige eine grafische Repräsentation dieser Liste zu erstellen und sie durch regelmäßige Anfrage beim Server aktuell zu halten. Die Benutzerliste und die im Dialog zum Beitreten einer Session angezeigte Benutzerliste erhöhen die user awareness (siehe 3.8.3). Außerdem ist es möglich, durch Anklicken eines Benutzers in der Liste einen Chat-Dialog zu diesem Benutzer zu öffnen. Auch übergibt der MatchMaker Server im Rahmen des Synchronisationsvorganges den Namen des Benutzers, der diese Änderung durchgeführt hat. Dies gibt dem Knoten die Möglichkeit, eine Liste über die Benutzer zu führen, welche Veränderungen an ihm vorgenommen haben und erhöht die group-structural awareness, da sich so die Zusammenarbeit von Benutzern in Grundzügen nachvollziehen lässt. Diese Liste der Benutzer ist in den Knoten der Daffodil- 70

72 Palette realisiert. Um genauere Informationen über die Zusammenarbeit von Benutzern oder ihre Verhaltens- und Vorgehensmuster zu erhalten, ist außerdem eine Auswertung der kompletten Sitzung oder ein Replay an Hand der Log-Dateien des Servers möglich [23]. Diese Funktion wird unter anderem in einem Projekt zur Generierung semiautomatischer Tutorensysteme genutzt, welche Arbeitsmuster auf Grund der Logfiles bewerten und Studenten Hilfestellung geben können [28]. 5.8 Persistenz der Sessions Speichern Zwar wird jegliche Session serverseitig mitgeschnitten, diese Mitschnitte sind jedoch für die normalen Benutzer nicht oder nur schwer zugänglich. Es ist daher wünschenswert, dass Benutzer Sitzungen zu einem beliebigen Zeitpunkt speichern können, um sie clientseitig zur Verfügung zu haben. Hierfür gibt es zwei Möglichkeiten: Speichern als Datei auf der gerade vom Client verwendeten Hardware. Dies hat den Vorteil, dass die Sitzung auch nach einer Trennung vom Daffodil-System vorhanden ist. Sie könnte so offline analysiert und für weitere Arbeiten genutzt werden. Speichern im aktuell angewählten Ordner der PLib des Benutzers. Dies hat den Vorteil, dass die Sitzung auf jedem beliebigen Rechner verfügbar ist, an dem er sich anmeldet. Außerdem können, wie an allen anderen Elementen der PLib auch, Annotationen an der gespeicherten Session angebracht werden. Auch ist ihm die Arbeit mit der PLib im Zusammenhang mit Daffodil geläufiger als das Speichern auf einem lokalen Datenträger. Da beide Methoden ihre Vorteile haben, werden sie parallel implementiert und dem Benutzer im Dialog für das Abspeichern als Alternativen präsentiert. Der Dialog zum Speichern einer Session wird über das Anklicken des Save Knopfes unterhalb der Liste der an der Session beteiligten Benutzer geöffnet. Er besteht aus den zwei Auswahlknöpfen Save to File und Save to PLib, welche die Art der Speicherung angeben und in beliebiger Kombination ausgewählt werden können, sowie dem Knopf Save now, der den eigentlichen Speichervorgang initiiert. Hier wird zuerst eine XML-Repräsentation des aktuellen JGraphs erstellt. Dies geschieht mit der dem JGraph eigenen Methode writetoxmltree. Diese erzeugt einen XML-Baum und hängt ihm die XML-Representation der im JGraph enthaltenen Kanten und Knoten an, welche wiederum durch diese Objekte selber per writetoxmltree erzeugt werden. Dieses Dokument wird im folgenden zum Speichern des JGraphs genutzt. Wurde das Speichern in einer Datei angewählt, so öffnet sich ein Save Dialog des JFileChooser, in dem man den Ort und Namen der Datei angeben kann. Der hieraus resultierende Pfad wird einer Istanz der Klasse FileSystemDelivery übergeben, welche zum MatchMaker Paket gehört und die XML-Representation 71

73 eines JGraphs automatisch mittels der Methode deliver() in eine Datei schreibt. Diese Methode wird dann mit dem aktuellen JGraph als Parameter aufgerufen. Damit ist der JGraph im Filesystem des aktuellen Rechners gespeichert. Beim Speichern der Session in der PLib wird zuerst aus Benutzername und Datum eine eindeutige ObjectID generiert, welche zur Identifikation des Objektes in der Datenbank benötigt wird. Danach wird ein Content String aus dem aktuellen Dokument erzeugt. UserID, ObjectID und Content werden dann in einer Daffodil-Message des Typs MESSAGE_TELL_STORE_PROPERTY an das Backend übergeben. Diese Nachricht veranlasst den Server, mittels eines WhiteBoardRequest einen entsprechenden Eintrag in der Tabelle whiteboard- Sessions anzulegen. Der Inhalt dieses Eintrages ist über die OjectID abrufbar. Um einen Eintrag für dieses Objekt in der PLib zu generieren, wird die Methode adddatatolibtree des PaddleTools aufgerufen, wobei ihr ein neues SimpleDataTransfer Objekt übergeben wird, welches vom Typ DATACLASS_WHITE- BOARD ist und die ObjektID des gerade generierten Datenbankeintrages enthält Laden Um eine Session aus dem Dateisystem zu laden, betätigt der User den Knopf Load. Dies öffnet einen Open Dialog des JFileChooser, in dem der Benutzer eine vormals gespeicherte Session anwählen kann. Das Tool versucht nun, aus dem Inhalt der Datei ein XML Dokument zu erstellen. Ist dies erfolgreich abgeschlossen, so entnimmt es dem Baum das Element JGraph und übergibt es dem White Board in der Methode configurebyxml, welche dieses veranlasst, den im Element abgespeicherten Graphen darzustellen. Hierbei wird ein bereits vorhandener Graph gelöscht. Das Wiederherstellen einer Session aus einem in der PLib abgelegten WhiteBoard-Objekt geschieht hingegen wie gewohnt per Drag n Drop. Hierzu zieht der Benutzer einfach den PLib-Eintrag auf die Ablagefläche des White- Boards. Dieses überprüft, ob es sich um einen DATACLASS_WHITEBOARD- Objekt handelt und ruft dann die Methode des WhiteBoard-Tools zum Laden eines Objektes auf. Hier wird eine Nachricht vom Typ MESSAGE_ASK_- FETCH_PROPERTY generiert, die die ObjectID des zu holenden Eintrags enthält. Das Backend leitet diese Nachricht dann an einen WhiteBoardRequest weiter, welcher den entsprechenden Datenbankeintrag holt und an das WhiteBoard- Tool zurückliefert. Hier wird aus dem zurückgelieferten XML-String ein neues XML-Document erzeugt. Danach wird das in diesem enthaltene Element JGraph dem WhiteBoard per configutebyxml übergeben, welches den Inhalt der gespeicherten Sitzung dargestellt Metainformationen Wird eine in der PLib abgespeicherte Session angewählt, so öffnet sich ein Detailfenster, mit weiteren Informationen zur Session. Angezeigt werden hier eine Liste der beteiligten Benutzer und der eingesetzten Knotentypen. Dies bietet 72

74 Informationen über den Kontext der Sitzung und ermöglicht ein schnelleres Auffinden. Zusammenfassung In diesem Kapitel wurden eine Reihe existierender Mehrbenutzer-Werkzeuge zur Führung von grafischer Gruppenarbeit vorgestellt und die nützlichkeit eines solchen Werkzeuges an Hand eines Szenarios erläutert. Danach wurden die Anforderungen an ein solches Werkzeug im Rahmen des Daffodil-Projekts erarbeitet und die in der Implementierung der angewendeten Lösungen beschrieben. Hierbei wurde auf die integrierten Technologien JGraph und MatchMaker eingegangen. Aussehen und Funktion des Werkzeuges wurden anschließend an Hand eines weiteren Szenarios dargestellt. Zum Schluss wurde noch auf die Persistenz von Sitzungen eingegangen. 73

75 Kapitel 6 Implementationsdetails 6.1 Chat Tool Klassendiagramme Chat Die in Abbildung 6.1 abgebildeten Klassen enthalten aus Gründen der Übersicht nur die notwendigen Methoden und Attribute. Das Klassendiagramm soll neben der Klassendtruktur auch das Zusammenspiel zwischen Frontend und Backend verdeutlichen. Für die Kommunikation mit dem Jabber-Server ist die Klasse DaffodilJabber- Comm zuständig, die die Klasse JabberComm aus dem IJabberClient-Paket um einige Funktionen erweitert. Diese Klasse wird von den beiden Klassen Jabber- UserManager (Administration und Daemon) und UserJabberRequest (Kommunikation der Benutzer) genutzt. Die Erzeugung eines UserJabberManager übernimmt der ChatAgent bei der Anmeldung des benutzers im System. Er tielt dem ChatClient des Frontends auch die EmpfängerID mit, unter der der Request zu erreichen ist. Der dem Benutzer zugeordnete Request hingegen kennt die ID des ChatTools und kann so Nachrichten an das Frontend schicken. Nachrichten für den Benutzer werden der ChatView durch den ChatClient übergeben, der ebenfalls die Aktualisierung der Benutzerliste vornimmt Das Jabber-Protokoll Das Jabber Protokoll ist nach XMPP spezifiziert und die Grundlagen werden in RFC 3920 bis RFC 3923 [60] beschrieben. Sie ermöglichen die Nutzung der Instant Messaging Mechanismen wie Presence, End-to-End Signing, Object Encryption und Extensible Messaging. Die Basisspezifikation des XMPP [61] beschreibt den grundlegenden Aufbau der Kommunikationsstruktur und des Jabber-Protokoll-Kerns. 74

76 Abbildung 6.1: Klassen des Chat-Tools Die Architektur Die Struktur eines XMPP Netzwerkes ist allgemein als Server-Client Struktur implementiert (siehe Abbildung 6.2), wobei sie nicht hierauf festgelegt ist. Clients kommunizieren mittels des TCP-Protokolls mit einem Server, verschiedene Server wiederum kommunizieren per TCP untereinander. Dies ermöglicht die Anbindung beliebiger Geräte (Desktoprechner, Laptops, PDAs) unter allen TCP/IP-fähigen Betriebssystemen. Des weiteren ist es möglich, eine Software zu schreiben, die als Gateway zwischen einem XMPP-Netzwerk und einem anderen Netzwerk (z.b. IRC) fungiert, indem sie die Nachrichten geeignet übersetzt. Einem Server kommen im XMPP-Netzwerk dabei folgende Aufgaben zu: Regeln der Verbindungen zwischen an diesem Server authorisierten Clientoder Serverinstanzen per XML-Streams 75

77 Abbildung 6.2: Typische Netzwerkstruktur Routen von korrekt adressierten XML Nachrichten (og. Stanzas) zwischen solchen Instanzen Ablage von Daten der an diesem Server registrierten Clients, wie Roster oder Offline-Nachrichten Ein Client verbindet sich für gewöhnlich direkt mit dem für ihn zuständigen Server. Hierbei ist es möglich, dass mehrere Instanzen eines registrierten Client- Kontos zur selben Zeit angemeldet sind, wobei jede Instanz neben der Adresse eine sie qualifizierende Erweiterung (resource) tragen muss. Der für die Kommunikation vorgegebene und bei der IANA registrierte Port trägt die Nummer Das Adressschema Eine Instanz oder Entity im Sinne des XMPP ist jedes eindeutig per Netzwerk- ID adressierbare Gerät, wobei die Adressierung normalerweise nach RFC 2396 [URI] erfolgt. Die Adresse einer XMPP-Instanz wird JID (Jabber Identifier) genannt. Der Aufbau der Adresse ist in Listing 6.1 als EBNF-Schema dargestellt: Listing 6.1: Die Regeln des Jabber-Adressschemas in EBNF j i d = [ ] domain [ / r e s o u r c e ] domain = fqdn / address l i t e r a l fqdn = ( sub domain 1 (. sub domain ) ) sub domain = ( i n t e r n a t i o n a l i z e d domain label ) address l i t e r a l = IPv4address / IPv6address Node ist hierbei der Name, der bei der Registrierung am Server angegeben wird. 76

78 Resource beschreibt die angemeldete Instanz des Clients genauer und ermöglicht es, mehrere Client-Instanzen mit den selben Benutzerdaten parallel zu betreiben und sie an Hand der resource eindeutig zu identifizieren. Die JID definiert also eine Client-Instanz eines Benutzers eindeutig im Netzwerk, wobei die Angabe der Domain ein Routing im Netz ermöglicht. XML Streams und XML Stanzas Diese beiden Konzepte des XMPP lassen sich wie folgt beschreiben: Der XML-Stream ist ein Träger zum Austausch von XML-Elementen zwischen zwei Instanzen eines Netzwerkes. Er schließt diese Elemente in den Tags <stream> und </stream> ein und ermöglicht es dem Initiator fortlaufend XML Elemente zu senden. Diese Elemente können zur Steuerung des Streams dienen oder Daten (XML Stanzas) enthalten. Man unterscheidet zwei Arten von Streams. Der initial stream kann als Initialisierung einer Session angesehen werden und wird vom Initiator aufgebaut. Um jedoch bidirektionale Kommunikation zu ermöglichen, muss der Empfänger einen zweiten Stream zum Initiator hin, den response stream aufbauen. Ein XML Stanza Element ist eine wohlgeformte XML Einheit und enthält strukturierte Informationen, welche per XML Stream von einer XMPP Instanz zu einer anderen geschickt werden sollen. Eine Stanza ist dabei immer ein direktes Kind des Streams Root Element und kann von einem der folgenden Typen sein: <message/> - Message Stanzas dienen dem Austausch von Nachrichten per push Mechanismus. Jede Nachricht benötigt zumindest ein Attribut to, das eine gültige JID enthält und den Empfänger kennzeichnet. presence/ - Presence Stanzas geben die Änderung des Status eines Clients (z.b. beim An- und Abmelden) an. <iq/> - IQ oder Info/Query ist ein Anfrage-Antwort Mechanismus und kommt einem pull gleich und ermöglicht die Implementierung geläufiger Muster für strukturierten Datenaustausch wie get/result oder set/result. Jeder IQ Stanza benötigt ein Attribut id, welches angibt, zu welcher Sequenz sie gehört. Außerdem muss ein gültiger Typ ( get, set, result, error ) per type Attribut gesetzt werden. Desweiteren existieren eine Reihe von Regeln, die in RFC3920 [61] unter bis 9.2.7, sowie 9.3 definiert sind. Auf dieser Basis aufbauend werden folgende Mechanismen für Instant Messaging, Presence und Subscription genutzt[62]: 77

79 Die Message Stanza wird dahingehend erweitert, dass das Attribut type angegeben werden muss und einen der folgenden Werte annimmt: chat - Wird immer dann genutzt, wenn es sich um eine Nachricht in einem Dialog handelt. error - Tritt ein Fehler auf, der sich auf eine im Vorfeld empfangene Nachricht bezieht, so ist die Antwortnachricht diesen Typs. groupchat - Analog zum Chat, jedoch für Gruppenchats genutzt. headline - Wird bei automatisch generierten Nachrichten genutzt, wie sie zum Beispiel ein Börsen-Ticker oder Newsfeeder generiert. normal - Dieser Typ wird für Nachrichten genutzt, die ausserhalb eines Gespräches versendet werden und nach einer Reaktion des Empfängers verlangen. Nachrichten können außerdem folgende Kindelemente enthalten: <subject/> - Gibt das Thema der Nachricht an. <body/> - Enthält die zu übermittelnden Informationen. <thread/> - Gibt den Gesprächskontext zu einer Nachricht und dient dem Verfolgen eines Gesprächsverlaufes. Dies macht es möglich, mehrere Gespräche mit dem selben Partner gleichzeitig zu führen. Die Presence Stanza wird genauer spezifiziert und muss, analog zur Message Stanza, einem der folgenden Typen angehören: unavailable - Der Status der Chat-Bereitschaft des Senders hat sich geändert. subscribe - Der Sender der Nachricht möchte sich beim Empfänger anmelden. unsubscribe - Der Sender der Nachricht möchte sich beim Empfänger abmelden. 78

80 subscribed - Eine Antwort auf die Subscribe-Anfrage, der Empfänger ist angemeldet. unsubscribed - Eine Antwort auf die Unsubscribe-Anfrage, der Empfänger ist abgemeldet. probe - Diese vom Server zu generierende Anfrage ist eine Art ping, um zu testen, ob ein Client noch erreichbar ist. error - Analog zur Message Stanza. Presence Stanzas des Typs unavailable können folgende Kindelemente enthalten: <show/> - Gibt den Status an, er kann einen der folgenden Zustände annehmen: chat - Der Benutzer ist chatbereit away - Der Benutzer ist zeitweise abwesend dnd - Do Not Disturb, der Benutzer möchte nicht gestört werden xa - extended Away, der Benutzer ist länger abwesend <status/> - Enthält eine Beschreibung des Grundes für die Abwesenheit. <priority/> - Eine ganze Zahl zwischen -128 und +127, welche das Routing von Nachrichten beeinflusst. Näheres hierzu unter RFC 3921 Kapitel 11 [62]. Weiterhin werden die genauen Mechanismen zur Anmeldung am Server spezifiziert. Da die Anmeldung jedoch vom IJabberClient übernommen wird, wird hier nicht näher darauf eingegangen XML-Nachrichten des Chat Der Chatmechanismus in Daffodil nutzt einen eigenen Nachrichtentyp JabberTell, der die Klasse AgentEvent erweitert und wie ein normaler Tell - Event genutzt werden kann. Dennoch ist durch die Erzeugung einer eigenen Nachrichtenklasse jede Nachricht des Chatsystems direkt von jeder anderen Tell- Nachricht zu unterscheiden. Außerdem stehen für JabberTell-Nachrichten zwei Performatives zur Verfügung, welche in der Klasse de.unido.daffodil.core.message definiert sind. Das Performative JABBER_INIT wird allerdings nur während der Anmeldung genutzt, wo sie den im Backend laufenden ChatAgent dazu veranlasst, für den versendenden Benutzer eine Instanz der Klasse de.unido.daffodil.useragent.userjabberrequest 79

81 anzulegen. Diese Klasse erhält im Verlauf der Daffodil-Sitzung alle JTell- Nachrichten mit dem JABBER -Performative. Um alle Mechanismen des Chats mit diesem Nachrichtentyp zu implementieren, existieren eine Reihe von XML-Elementtypen, die in der Klasse de.izsoz.daffodil.tools.chat.chatclient definiert sind und die einzelnen JabberTell- Nachrichten unterscheidbar machen. So wird zum Anmelden des Benutzers am JabberServer zum Beispiel eine JabberTell-Nachricht mit dem JABBER_INIT-Performative und einem Element mit Namen JabberInit erzeugt und verschickt. Hierdurch wird das Backend veranlasst, alle nötigen Schritte zu unternehmen. Dieser Vorgang soll beispielhaft für die anderen Implementierungen an Hand eines Codebeispieles veranschaulicht werden. Die Nachricht für den Verbindungsaufbau wird im ChatClient in der run- Methode (siehe Listing 6.2) zusammengestellt und verschickt. Listing 6.2: Die Run-Methode des ChatClient public void run ( ) { chatagentid = getchatagentid ( ) ; JabberTell j T e l l = new JabberTell ( chattool ) ; j T e l l. s e t P e r f o r m a t i v e ( Message.JABBER_INIT ) ; j T e l l. s e t R e c e i v e r ( chatagentid ) ; j T e l l. s e t R e f e r s I d ( requestid ) ; j T e l l. setmsg ( "<" + JABBER_INIT + " userjabberid=\"" + userjabberid + "\"" +" username=\"" + daffodilname + "\"" + " passwd=\"" + password + "\" " + " s e r v e r =\"" + chattool. g e t S e r v e r ( ) + "\" " + ">" +"</" + JABBER_INIT + ">" ) ; Dispatcher. postevent ( j T e l l ) ; } Zuerst wird die ID des ChatAgents, der Empfänger aller Chat-Messages ist, vom System erfragt. Danach wird ein JabberTell-Element erstellt, sowie Performative, Empfänger und Betreff gesetzt. Der Betreff gibt im weiteren Nachrichtenverlauf an, für welchen UserJabberRequest die Nachricht gedacht ist. Nun wird die Nachricht aus Elementtyp und Inhalt zusammengesetzt, danach übernimmt der Dispatcher, der für die generelle Nachrichtenübermittlung vom Frontend (Client) zum Backend (Server) verantwortlich ist, den Versand der Nachricht. Im Backend nimmt der ChatAgent die Nachricht in der Methode receive(message message) entgegen (siehe Listing 6.3). Hier wird an Hand des Performatives entschieden, die entsprechende Routine zum Erzeugen eines neuen UserJabberRequest, der die Verbindung zum Jabber-Server mittels IJabberClient darstellt, zu starten und die aktuelle Nachricht an dessen Nachrichtenschlange zu übergeben. 80

82 i f } Listing 6.3: Start eines UserJabberRequest nach Initialisierungsnachricht ( message. p e rformative == Message.JABBER_INIT){ userjabberrequest = new UserJabberRequest ( message. request, this, message, jabberusermanager ) ; addrequest ( userjabberrequest ) ; Die in der Nachrichtenschlange abgelegten Nachrichten bearbeitet der JabberUserRequest sequentiell in der Methode work(message message). Die hierbei durchzuführende Aktion wird an Hand von Performative und Elementnamen bestimmt. Im Falle der JabberInit-Nachricht wird der Verbindungsaufbau mittels IJabberClient gestartet, welcher in Abschnitt genauer beschrieben ist. Der hier beschriebene Verlauf einer Nachricht vom Frontend zum Backend entspricht dem Daffodil-Standard. Bei der Kommunikation vom Backend zum Frontend spricht der im Backend laufende Service dann direkt mit dem Tool im Frontend, welches die Nachrichten mittels der Methode handleizevent(eventobject ev) entgegennimmt und verarbeitet. Weitere Elementtypen, die im Verlauf einer Jabber-Sitzung benutzt werden und generell in Nachrichten mit dem JABBER-Performative verschickt werden, sind: JabberExit - Veranlasst den UserJabberRequest, den IJabberClient vom Jabber-Server abzumelden und sich zu beenden JabberConnected - Hierdurch wird dem ChatTool mitgeteilt, das der IJabberClient erfolgreich initiert wurde JabberRosterMessage - Diese Nachricht enthält den Roster des Benutzers, der nach dem Anmelden vom Chat-Server angefordert wird JabberInMessage - Eine Textnachricht für diesen Client trifft ein JabberOutMessage - Eine Textnachricht wird von diesem Client gesendet JabberOwnStatus - Hiermit teilt der Client dem UserJabberRequest mit, dass sich der Status (erreichbar oder nicht erreichbar) geändert hat JabberPresenceMessage - Wird immer dann vom UserJabberRequest erzeugt, wenn ihn eine Presence-Nachricht des Servers erreicht (z.b. durch An-/und Abmelden eines Benutzers oder Ändern eines Status), das Gegenstück zu JabberOwnStatus JabberError - Wird vom UserJabberAgent genutzt, um die Fehlermeldungen des Jabber-Servers weiterzuleiten 81

83 JabberSimpleDataTransferOutMessage - Die übertragene Nachricht ist ein SimpleDataTransfer-Objekt. Diese Nachricht wird genutzt, um Daffodil- Objekte zu versenden. JabberHello - Wird für den Austausch der Benutzer-Rollen benötigt Die meisten dieser Nachrichten stellen eine direkte Implementierung der Jabber-Nachrichten im Nachrichtensystem von Daffodil dar. Die beiden letzten Nachrichten hingegen sind Erweiterungen des Jabber-Standarts Möglichkeiten des IJabberClient Der IJabberClient [55] liefert einfache Methoden zur Generierung von Nachrichten, die für das Instant Messaging notwendig sind und ermöglicht ein einfaches An- und Abmelden. Außerdem sind Methoden für die Registrierung an einem Server und den Subscription-Vorgang vorhanden. DaffodilJabberComm erweitert daher die Klasse JabberComm des IJabberClients und fügt einige Methoden zum Löschen von Accounts und zur automatischen gegenseitigen Subscription hinzu. Die wichtigten Methoden und ihre Nutzung im ChatClient von Daffodil sind hier aufgeführt. Registrierung Um einen neuen Account ( Client ) auf einem Jabber Server zu erstellen, lässt sich nach der Verbindung mittels connect() die Methode createnewaccount (String username, String password, String resource) nutzen. Sie nimmt dem Benutzer die Erstellung einer eigenen Nachricht ab. username ist hierbei der node Teil der JID, password das zukünftige Anmeldepasswort und resource ein beliebiger String, meist der Name des Clients. Die für Daffodil erstellte Klasse JabberUserManager kann für die Erstellung neuer Accounts genutzt werden. Dies geht zum einen im interaktiven Betrieb duch Auswahl des entsprechenden Knopfes, zum anderen kann im automatischen Modus eine Reihe von Accounts direkt aus der Userdatenbank von Daffodil erzeugt werden. Da eine Methode zum Abmelden von Accounts nicht vorhanden ist, vor allem zu Testzwecken jedoch wünschenswert war, wurde diese in der Klasse DaffodilJabberComm implementiert, welche den aktuell angemeldeten Account beim Server löscht (siehe Listing 6.4). Zu diesem Zweck wird die Möglichkeit genutzt, selbstverfasste Nachrichten ( rawxml ) zu versenden. Die Nachicht selber ist eine IQ Stanza, die den für das Entfernen des aktuellen Accounts vorgesehenen Befehlsstring enthält. Verbindungsaufbau Die Methode connect (String host, String hostname, int port, URL url) stellt eine Verbindung zum JabberServer her, der im Parameter hostname angegeben ist. Der Parameter host bezieht sich hierbei auf den host Teil der eigenen 82

84 Listing 6.4: Nachricht zum Löschen eines Jabber-Accounts public int deleteaccount ( S t r i n g s e r v e r ) { S t r i n g sxml =""+ "<i q type = s e t to = "+s e r v e r+" >"+ "<queryxmlns= jabber : i q : r e g i s t e r >"+ "<remove/>"+ "</query>"+ "</iq>" ; return sendrawxml(sxml) ; } JID. Als Port soll nach RFC3920 der Port 5222 angegeben werden, die URL kann null sein. Als Antwort erhält der Client eine streamid, die für die weitere Authentifizierung benötigt wird. Nachdem auf diese Weise eine Verbindung zum Server hergestellt ist, muss der Client sich authentifizieren, bevor er weitere Nachrichten verschicken kann. Dies geschieht mit der Methode logon (String username, String password, String resource, String streamid), welche die passende Anmeldenachricht generiert und an den Server weiterleitet. username ist der node Teil der JID, password das aktuelle Passwort und streamid die vom Server zugeteilte StreamID. Nach dieser Nachricht ist ein Versand weiterer Nachrichten möglich. Dies kann zum einen die Anfrage des eigenen Roster sein, zum anderen können Nachrichten an andere Clients versand werden. Außerdem überprüft der Server, ob Offlinenachrichten für den User vorhanden sind und stellt diese zu. Auch teilt er dem Benutzer durch Presence Nachrichten mit, welche ihm bekannten Clients ebenfalls online sind. Die Verbindung mit dem JabberServer wird in Daffodil automatisch im Backend durch eine Instanz des UserJabberRequest übernommen. Dieser erhält die notwendigen Parameter vom Chat-Tool. Der Benutzer hat hierbei die Möglichkeit, eigene Parameter in der Datei daffuser.properties anzulegen. Diese sind: tools.chat - yes macht das Chat-Tool im Daffodil-Desktop verfügbar chat.myname - Ermöglicht die Angabe eines vom Daffodil-Benutzernamen verschiedenen Anmeldenamen für den Chat chat.passwd - Ermöglicht die Angabe eines vom Daffodil-Passwort verschiedenen Passworts chat.myrole - Hier kann die Rolle des Benutzers angegeben werden, fehlt dieser Parameter, so setzt das Chat-Tool die Rolle auf novice chat.server - Ermöglicht die Angabe eines alternativen Jabber-Servers 83

85 Subscription Der Begriff der gegenseitigen Berechtigung (Mutual-Subscription) beschreibt die gegenseitige Erteilung einer Sendeerlaubnis, welche ein Benutzer einem anderen einmalig ausstellen muss, damit dieser Nachrichten an ihn senden kann. Dieser Vorgang ist im Chat von Daffodil automatisiert, um den Benutzer möglichst wenig mit Aufgaben der Organisation zu belasten. Abbildung 6.3: Ablauf der Mutual-Subscription Beim Eintrag eines neuen Benutzers in den eigenen Roster wird direkt auch eine Anfrage zur Subscription an diesen Benutzer gestellt. Eintreffende Anfra- 84

86 gen beantwortet der UserJabberRequest, welcher für die Kommunikation mit dem Jabber-Server zuständig ist (siehe hierzu Abschnitt 4.6, sowie Abschnitt 6.1.1), automatisch mit einer Zustimmung und überprüft nun, ob der anfragende Benutzer bereits im eigenen Roster vorhanden ist. Ist dies nicht der Fall, so aktualisiert er den eigenen Roster und bittet den anfragenden Benutzer ebenfalls um eine Berechtigung. Andernfalls wird der Vorgang unterbrochen. Somit wird eine Mutual-Subscription garantiert. Nachrichtenversand Da der IJabberClient die notwendigen Mechanismen für die Standartkommunikation mit dem JabberServer mitbringt, muss nur dieser Nachrichtenversand zwischen ChatTool und UserJabberRequest implementiert werden. Der Nachrichtenversand zwischen ChatTool und UserJabberRequest erfolgt über die im Abschnitt beschriebenen Nachrichten. Somit besteht die Hauptaufgabe des UserJabberRequests darin, die Nachrichten des einen Protokolls jeweils in das Format des anderen zu übersetzen. Dies geschieht ganz einfach dadurch, dass die Daffodil-Nachrichten ein Attribut für jeden Parameter der Jabber-Nachrichten enthalten und der Inhalt der Nachricht als Wert des Nachrichtenelements übergeben wird. Das ChatTool hingegen muss neben dem Erzeugen und Auswerten der Nachrichten die Liste der Benutzer nachbilden, was jedoch recht einfach möglich ist, da es hierzu die entsprechenden Presence-Nachrichten des Jabber-Servers nutzen kann, die vom UserJabberRequest übermittelt werden. Einzig der Versand der Benutzerrollen und Daffodilobjekte ist nicht Bestandteil des Jabberprotokolls. Somit müssen diese beiden Mechanismen implementiert werden. Hierfür reichen allerdings kleine Nachrichten. Im Fall der Übermittlung der Benutzerrolle wird einfach eine Nachricht vom Typ JabberHello erzeugt, welche als Attribute die Benutzerrolle, die eigene JID und den Zielbenutzer erhält. Eine solche Nachricht wird automatisch an alle Sender einer Presence-Nachricht verschickt. Somit wird die eigene Rolle an alle verfügbaren Gesprächspartner übermittelt. Das Versenden von Daffodil-Objekten ist ebenfalls gut zu realisieren, da jedes versendbare Objekt die Klasse de.unido.daffodil.dataclasses.simpledatatransfer erweitert. Diese besitzt eine Methode, mit der sie ihren Inhalt als XML-String ausgeben lässt, welcher als Nachricht übertragen werden kann. Auf der Gegenseite lässt sich dann aus dem String wieder ein SimpleDataTransfer-Objekt erstellen. Der Versand erfolgt über die in Abschnitt beschriebene JabberSimpleDataTransferOutMessage. 85

87 6.2 Whiteboard-Tool Klassendiagramme Whiteboard-Tool Da die Implementierung und die genutzten Technologien bereits in 5 besprochen wurden, ist hier nur die Struktur des Whiteboard-Tools an Hand von Klassendiagrammen aufgeführt. Abbildung 6.4: UML Klassen-Diagramm des WhiteBoard-Tools Klassendiagramme Whiteboard-Palette Das folgende Diagramm fasst das Zusammenspiel der erstellten Knoten mit der WhiteBoard-Palette und dem Daffodil-Backend zusammen. Der DaffodilMediator kommuniziert hierbei über den Dispatcher mit dem Backend und kann als EventReceiver im Gegenzug Nachrichten aus dem Backend annehmen und sie auf die Knoten verteilen. 86

88 Abbildung 6.5: UML Klassen-Diagramm der WhiteBoard-Palette 87

89 Kapitel 7 Zusammenfassung & Ausblick 7.1 Erreichte Ziele In Rahmen dieser Arbeit wurde die Funktionalität und der Mehrwert von direkter Kommunikation und Mehrbenutzerwerkzeugen für verteilte Arbeitsgruppen im Zusammenhang mit Daffodil untersucht, welche die Möglichkeiten der Gruppenarbeit, wie sie in real existierenden Bibliotheken vorhanden sind, nachbilden sollen. Hierbei wurden zuerst die aktuellen Möglichkeiten der Zusammenarbeit aufgezeigt. Danach wurde die Erweiterbarkeit der aktuellen Einbenutzerwerkzeuge auf ihren Nutzen im Mehrbenutzerkontext hin an Hand von Beispielen besprochen, sowie eine Einordnung in gängige Kategorisierungsschemata für Groupware vorgenommen. Hieraus ergab sich die Notwendigkeit der Neuimplementierung von Werkzeugen im Bereich synchroner Kommunikation sowie Kollaboration. Zur Unterstützung des ersten Bereiches wurde ein Chatwerkzeug, aufbauend auf dem Jabberprotokoll, implementiert, welches die direkte Kommunikation mit anderen Benutzern, sowie den Austausch von Daffodilobjekten zulässt. In diesem Zusammenhang wurde der Mehrwert direkter Kommunikation und der implementierten Awarenessmechanismen erläutert. Für Gruppenarbeit im Bereich der Kollaboration wurde ein WhiteBoard- Werkzeug implementiert, welches das grafische Erstellen von Dokumenten sowie Diskussionen ermöglicht. Hierbei wurden die Technologien Matchmaker und JGraph der Collide-Gruppe genutzt. Dem Benutzer wurden dabei zwei fertige Paletten für die grafische Diskussion und eine neue Palette, welche das Einfügen beliebiger Daffodilobjekte per Drag n Drop ermöglicht, zur Verfügung gestellt. Auch ist das Werkzeug durch weitere Paletten flexibel erweiterbar. Es wurden ebenfalls Mechanismen zur Steigerung der Awareness hinzugefügt und eine Möglichkeit erstellt, von diesem Werkzeug direkt einen neuen Dialog im Chat-Werkzeug zu öffnen und so Kollaboration und Kommunikation zu verzahnen. Beide Werkzeuge sollen dabei ein Abspeichern des aktuellen Inhalts und das Verarbeiten zu einem späteren Zeitpunkt ermöglichen. 88

90 7.2 Verbleibende Arbeit Einige der anvisierten Funktionalitäten des Chatwerkzeuges konnten auf Grund der fortgeschrittenen Zeit nicht mehr fertiggestellt werden. Daher stehen noch folgende Aufgaben an, die nach Abgabe dieser Arbeit zu vollenden sind. So ist das Abspeichern einer ChatSession bisher einzig als Mitschnitt auf der Serverseite implementiert. Für die Ablage in der PLib stehen jedoch schon die notwendigen Methoden bereit, sodass eine Fertigstellung dieses Teiles mit wenig Aufwand möglich sein wird. Die Abbildung der Benutzergruppen auf den Chat wird im Moment unzureichend unterstützt. Zum einen sollen bei der Erstellung eines neuen Accounts nur noch die Benutzer in den Roster aufgenommen werden, welche auch einen Platz in einer der Arbeitsgruppen des zu erstellenden Benutzers besitzen, zum anderen ist Abbildung dieser Benutzergruppen und das Öffnen von Gruppenchats noch nicht möglich. Die hier besprochenen Punkte werde ich nach Abgabe dieser Arbeit in Angriff nehmen. 7.3 Ausblick JabberUserManager Sinnvoll ist eine Erweiterung des JabberUserManagers um die Möglichkeit, Passwörter einzelner Benutzer zu ändern. Dies ist im Jabberprotokoll selber nicht vorgesehen und nur über den Umweg zu erreichen, dass der Benutzer gelöscht und mit dem alternativen Passwort erneut angelegt wird. Dieser Vorgang sollte aus Sicherheitsgründen nur von einem Administrator durchgeführt werden können, dort jedoch automatisiert sein. Auch ist es von Nutzen, einem Benutzer manuell die Berechtigung, mit einem anderen Benutzer zu kommunizieren (manuelle einseitige Subscription), geben zu können. Dies ermöglicht eine Kommunikation nach Außen, zu Benutzern, die keinen Daffodil-Account haben oder zu Benutzern anderer Arbeitsgruppen. Auch können so Fehler, die durch einen Abbruch der gegenseitigen Berechtigungsgabe (Mutual Subscription) aufgetretene können, behoben werden Palette für Dokumenterstellung Was in Daffodil noch fehlt, ist ein Werkzueg zum gemeinsamen, gleichzeitigen Erzeugen und Strukturieren neuer Dokumente. Hierzu kann eine weitere Palette für das WhiteBoard-Werkzeug erstellt werden, welche einen Knotentypen 89

91 für Textbausteine und einen für den Dokumenttitel enthält. Der Textbaustein- Knoten benötigt ein Eingabefeld für die Überschrift und ein Feld für den Textinhalt, welches entweder sein sollte, um einen beliebig langen Text aufzunehmen. Außerdem ist eine Kante notwendig, die einen Textknoten einem anderen unterordnet. So ist es möglich, ein Dokument zu generieren, indem man die einzelnen Dokumentteile als Knoten in einem Baum betrachtet, dessen Wurzel der Dokumenttitel ist. Dokumentteile auf der selben Ebene könnten durch Nummerierung der Kanten in eine Reihenfolge gebracht werden. Nimmt man noch zur Speicherung des Textes ein strukturierendes Format (z.b. L A TEXmit einem passenden Style), so lassen sich hieraus automatisch Dokumente im einer Reihe von Formaten (bei L A TEXz.B. Postscript, PDF oder DVI) erstellen. Durch einführen geeigneter anderer Knoten könnten nun, analog zu Textbausteinen, auch Grafiken, Bilder oder Tabellen eingefügt werden. Auch könnten Daffodil-Objekte durch das Einfügen von Daffodil-Knoten refferenziert werden. Eine Sitzung unter Zuhilfenahme dieses Werkzeuges könnte dann wie folgt aussehen: Abbildung 7.1: Dokumenterstellung mit dem WhiteBoard-Tool Einladen zu einer Sitzung Um andere Benutzer bequem zu einer erstellten Sitzung einzuladen, kann das WhiteBoard-Werkzeug um die Möglichkeit erweitert werden, an beliebige, im Chat sichtbare Benutzer auf Wunsch eine Einladung zu verschicken. Hierzu kann, nach dem Erstellen der Sitzung, automatisch ein Fenster mit der Liste aller Benutzer geöffnet werden. Durch Anwahl der Benutzer wird an diesen 90