Die Bedeutung von Awareness für kollaborative Arbeitsprozesse

Diplomarbeit
Die Bedeutung von Awareness für kollaborative Arbeitsprozesse
Konzeption und prototypische Implementierung einer Komponentenarchitektur für Place-based Awareness als Composite Application
vorgelegt bei
Prof. Dr. Ludwig Nastansky
betreut durch
Dipl.-Wirt.-Inf. Holger Ploch
Dezember 2007
vorgelegt von
Heiko Strathkötter
Augustastraße 15, 33649 Bielefeld
Studiengang Wirtschaftsinformatik
I
Danksagung
Für die Betreuung meiner Diplomarbeit möchte ich mich an dieser Stelle herzlich bei
Holger Ploch bedanken.
Meine schöne und lehrreiche Zeit am Groupware Competence Center werde ich in guter
Erinnerung behalten. Ich bedanke mich diesbezüglich bei Prof. Dr. Ludwig Nastansky
und seinen Mitarbeitern.
Des Weiteren danke ich Frank Wiele für die konstruktiven Gespräche in Bezug auf die
Eclipse-Plugin-Entwicklung mittels Java und allen, die mich beim Review der Arbeit
unterstützt haben: Christian Niediek, Kerstin Schmidt, Benjamin Schnell und Vera
Strathkötter.
Besonders bedanke ich mich bei meinen Eltern für ihre Unterstützung.
II
Inhaltsverzeichnis
1
2
Einleitung.................................................................................................................1
1.1
Szenario.............................................................................................................1
1.2
Zielsetzung ........................................................................................................2
1.3
Aufbau der Arbeit .............................................................................................2
Grundlagen ..............................................................................................................4
2.1
Kollaborative Arbeitsumgebungen ...................................................................4
2.1.1
Computer Supported Cooperative Work...................................................4
2.1.2
Groupware.................................................................................................4
2.1.3
Unterstützungsfunktionen .........................................................................6
2.2
Awareness .........................................................................................................9
2.2.1
Motivation und thematische Einordnung ..................................................9
2.2.2
Definition ................................................................................................11
2.2.3
Erzeugung von Awareness-Informationen und Kategorisierung............13
2.2.4
Bedeutung von Awareness......................................................................15
2.2.4.1
Vorteile durch Bereitstellung von Awareness-Informationen ............16
2.2.4.2
Problematik der Bereitstellung von Awareness-Informationen..........18
2.2.4.3
Zusammenfassung...............................................................................20
2.2.5
3
Modelle und Konzepte ............................................................................22
2.2.5.1
Workspace Awareness ........................................................................23
2.2.5.2
Place-based Presence ..........................................................................26
Konzept für Place-based Awareness in kollaborativen Arbeitsumgebungen .32
3.1
Ziel ..................................................................................................................32
3.2
Das Modell Place-based Awareness ...............................................................33
3.2.1
Place-based Awareness als raumbasiertes Modell..................................34
3.2.2
Place-based Awareness als ereignisbasiertes, hierarchisches Modell.....37
3.2.3
Zusammenfassung...................................................................................41
3.3
Anforderungen an eine Architektur für Place-based Awareness ....................43
3.3.1
Organisatorische Sicht ............................................................................43
3.3.2
Funktionale Sicht ....................................................................................46
3.3.3
Technische Sicht .....................................................................................48
3.4
Instant Messaging als Awareness-System ......................................................50
III
3.5
Architekturentwurf für Place-based Awareness..............................................53
3.5.1
Authentifizierung (Phase I) .....................................................................55
3.5.2
Initialisierung (Phase II)..........................................................................56
3.5.3
Bereitstellung, Verteilung und Präsentation (Phase III) .........................58
3.5.4
Anfrage an Historie und Konfiguration ..................................................59
3.6
4
Zusammenfassung...........................................................................................61
Prototypische Implementierung einer Place-based-Awareness-Komponente 62
4.1
4.1.1
Lotus Notes/Domino ...............................................................................62
4.1.2
Composite Applications ..........................................................................63
4.1.3
Lotus Sametime.......................................................................................64
4.2
Architektur der Komponente ..........................................................................66
4.3
Schnittstelle zwischen Applikation und Komponente ....................................69
4.4
Internes Objektmodell.....................................................................................70
4.5
Benutzeroberfläche der Komponente..............................................................71
4.6
Funktionen der Komponente...........................................................................74
4.6.1
Filter ........................................................................................................74
4.6.2
Historie....................................................................................................74
4.6.3
Abonnement ............................................................................................75
4.7
5
Systemumgebung ............................................................................................62
Zusammenfassung...........................................................................................77
Fallstudie GCC Grading Management System..................................................78
5.1
Szenario...........................................................................................................78
5.2
Einsatz der Place-based-Awareness-Komponente..........................................79
5.3
Bewertung .......................................................................................................80
6
Ausblick..................................................................................................................82
7
Zusammenfassung.................................................................................................84
8
Literaturverzeichnis..............................................................................................86
9
Anhang .................................................................................................................100
9.1
Bereitstellung von Awareness-Informationen...............................................100
9.2
Verteilung von Awareness-Informationen....................................................102
9.3
Präsentation von Awareness-Informationen .................................................112
9.4
PBA-Management-DB..................................................................................113
9.5
Klassenübersicht der PBA-Komponente.......................................................116
IV
Abbildungsverzeichnis
Abbildung 1 - Direkte vs. indirekte Kommunikation .......................................................7
Abbildung 2 - Prozesse innerhalb der Gruppenarbeit .......................................................9
Abbildung 3 - Awareness im Hinblick eines gemeinsamen Arbeitskontextes ...............13
Abbildung 4 - Phasen bei der Erzeugung von Awareness-Informationen......................13
Abbildung 5 - Presence scope und awareness scope ......................................................30
Abbildung 6 - Screenshot CoCoBrowse .........................................................................30
Abbildung 7 - Place-Modell von Place-based Awareness (im engeren Sinn) ................34
Abbildung 8 - Place-Modell von Place-based Awareness (im weiteren Sinn) ...............35
Abbildung 9 - Place-Modell von Place-based Awareness (dynamischer Aspekt)..........36
Abbildung 10 - Ereignisbasierte Awareness-Erzeugung ................................................37
Abbildung 11 - Konzept der Place-Hierarchie................................................................39
Abbildung 12 - Place-based Awareness als Entity-Relationship-Modell .......................41
Abbildung 13 - Konzept von Place-based Awareness ....................................................43
Abbildung 14 - Aufbau der Architektur für Place-based Awareness .............................54
Abbildung 15 - Authentifizierungsphase ........................................................................55
Abbildung 16 - Initialisierungsphase ..............................................................................56
Abbildung 17 - Bereitstellung, Verteilung und Präsentation von Awareness-Daten......58
Abbildung 18 - Anfrage an Historien-Dienst und Konfiguration ...................................60
Abbildung 19 - Wiring von Komponenten im Composite Application Editor...............63
Abbildung 20 - IBM Lotus Sametime Connect Client....................................................64
Abbildung 21 - Places-Modell von Lotus Sametime ......................................................65
Abbildung 22 - Architektur der prototypischen Implementierung .................................67
Abbildung 23 - Benutzeroberfläche (Gliederung nach Places).......................................71
Abbildung 24 - Benutzeroberfläche (Gliederung nach User) .........................................72
Abbildung 25 - Place-Kontextmenü (links) und User-Kontextmenü (rechts) ................ 73
Abbildung 26 - Filteroptionen.........................................................................................74
Abbildung 27 - Anfrage an Historie über Auswahldialog ..............................................74
Abbildung 28 - Darstellung des Resultats einer Anfrage an die Historie .......................75
Abbildung 29 - Modifikation einer Abonnement-Einstellung ........................................75
Abbildung 30 - Baumdarstellung nach Abbestellung eines Abonnements.....................76
Abbildung 31 - Kollaboration im Kontext eines Bewertungsmanagements...................78
Abbildung 32 - Grading Management System und Place-based-Awareness .................80
V
Abbildung 33 - Die Methode PBAStart in der PBA-LotusScript-Library....................101
Abbildung 34 - Wires zwischen Anwendungs- und PBA-Komponente.......................101
Abbildung 35 - Code zum Empfangen eines PBAStart-Property.................................102
Abbildung 36 - startAction-Methode des Main-Threads (1) ........................................104
Abbildung 37 - startAction-Methode des Main-Threads (2) ........................................105
Abbildung 38 - run()-Methode des Management-Threads ...........................................106
Abbildung 39 - Methoden zum Füllen/Leeren des Management-Thread-Puffers ........107
Abbildung 40 - Objektbeziehungen in den beiden Baumstrukturen.............................108
Abbildung 41 - entered-Methode des Sametime-Threads ............................................109
Abbildung 42 - handleAttributeActionEvent-Methode des Sametime-Threads (1) .....110
Abbildung 43 - handleAttributeActionEvent-Methode des Sametime-Threads (2) .....111
Abbildung 44 - Liste der aktiven Places in der PBA-Management-DB .......................113
Abbildung 45 - Ein Place-Dokument in der PBA-Management-DB............................113
Abbildung 46 - Liste der Mitgliedschafts-Dokumente in der PBA-Management-DB .114
Abbildung 47 - Ein Mitgliedschafts-Dokument in der PBA-Management-DB............114
Abbildung 48 - Liste der Log-Einträge in der PBA-Management-DB......................... 115
Abbildung 49 - Ein Log-Eintrag in der PBA-Management-DB ...................................115
Abbildung 50 - Übersicht über alle Java-Klassen der PBA-Komponente....................116
VI
Tabellenverzeichnis
Tabelle 1 - Raum-Zeit-Matrix mit Groupware-Systemen.................................................6
Tabelle 2 - Koordinationsphasen ......................................................................................7
Tabelle 3 - Kategorisierung nach Bereitstellungskriterien..............................................14
Tabelle 4 - Kategorisierung nach Verteilungskriterien...................................................14
Tabelle 5 - Kategorisierung nach Präsentationskriterien ................................................15
Tabelle 6 - Gegenwartsbezogene Elemente von Workspace Awareness........................24
Tabelle 7 - Vergangenheitsbezogene Elemente von Workspace Awareness..................25
Tabelle 8 - Unterstützungspotential durch Workspace Awareness.................................26
Tabelle 9 - Aspekte im „trust model“ von IM-Systemen................................................28
Tabelle 10 - Entwurf des Datenmodells im Management-Repository............................57
Tabelle 11 - Entwurf des Datenmodells im History-Repository.....................................59
Tabelle 12 - Event-Klassen in der PBA-Eclipse-Komponente .....................................103
Tabelle 13 - Zentrale Aufgaben der Threads in der PBA-Eclipse-Komponente ..........103
Tabelle 14 - Eingesetzte Icons und ihre Bedeutung......................................................112
VII
Abkürzungsverzeichnis
API
Application Programming Interface
BDSG
Bundesdatenschutzgesetz
BetrVG
Betriebsverfassungsgesetz
CSCW
Computer Supported Cooperative Work
ECSCW
European Conference on Computer Supported Cooperative Work
ERM
Entity-Relationship-Modell
FIFO
First in-First out
GCC
Groupware Competence Center
GIA
Grundlagen des Informationsmanagements am Arbeitsplatz
GMS
Grading Management System
GUI
Graphical User Interface
HTTP
Hypertext Transfer Protocol
IBM
International Business Machines (Corporation)
IM
Instant Messaging
IT
Informationstechnologie
LTPA
Light Third-Party Authentication
NRPC
Notes Remote Procedure Call
NSF
Notes Storage Facility
PBA
Place-based Awareness
PIM
Personal Information Management
PKI
Public-Key-Infrastruktur
POLIAwaC
POLITeam Awareness Client
RCP
Rich Client Platform
SOA
Service Oriented Architecture
SSO
Single Sign-On
SWT
Standard Widget Toolkit
UI
User Interface
UML
Unified Modeling Language
UNID
Universal ID
URL
Uniform Resource Locator
WebDAV
Web-based Distributed Authoring and Versioning
WSDL
Web Service Description Language
VIII
WWW
World Wide Web
XML
Extensible Markup Language
1
1 Einleitung
1.1 Szenario
Die Arbeitswelt ist seit jeher einem ständigen Wandel unterworfen. Ein Trend der heutigen Zeit, der bereits Realität geworden ist, bildet die Ermöglichung neuer Formen der
Zusammenarbeit. Obwohl sich Menschen schon immer im Kontext ihrer Arbeit zur
Erreichung gemeinsamer Ziele durch Koordination von Arbeitsinhalten und -abläufen
abstimmen mussten, stehen sie in der Gegenwart diesbezüglich vor neuen Chancen aber
auch Herausforderungen.
Die Vernetzung der Welt durch das Internet gestattet nicht nur einen nahezu grenzenlosen Austausch von Informationen, sondern erlaubt es Kooperationspartnern auch, mit
Computerunterstützung auf neue Art virtuell zusammenzuarbeiten.
„Virtuelle Teamarbeit bezeichnet den interdependenten und zweckgebundenen
Arbeitsprozess einer Gruppe von Individuen, die ein gemeinsames Ziel verfolgen
und dabei räumliche und/oder zeitliche Hindernisse mit Hilfe von Kommunikationsmedien überwinden.“ ([Senst 2001], S. 17)
Zusätzliche Merkmale virtueller Teams bilden eine fehlende Zuordnung der Teammitglieder auf feste Arbeitsplätze, eine temporäre Zusammenarbeit und ein hohes Maß
an Selbstorganisation (vgl. [Isermann 2004], S. 43).
Für den Erfolg virtueller Teamarbeit und die Effizienz virtueller Teams ist eine Unterstützung der Kommunikations-, Koordinations- und Kooperationsprozesse der Teammitglieder unerlässlich. Computersysteme und Software, die diese Unterstützungsfunktionen leisten, werden als Groupware bezeichnet. Dazu gehören weit verbreitete
und bekannte Beispiele wie E-Mail und Instant Messaging, aber auch spezielle Projektmanagement- oder Workflow-Systeme. Ein Großteil dieser Systeme basiert auf dem
Ansatz, dass die Anwender dieser Applikationen entweder Inhalte bzw. Informationen
explizit für andere Personen bereitstellen oder aber explizit abrufen müssen.
Im Rahmen dieser Arbeit wird der Fokus dagegen auf Groupware-Systeme gelegt, die
Informationen kontextabhängig sowohl automatisch generieren als auch präsentieren.
Dabei handelt es sich um Awareness-Systeme, die die Kooperationspartner bei der
gegenseitigen Wahrnehmung ihrer Aktivitäten unterstützen.
2
1.2 Zielsetzung
Wenn Teammitglieder virtuell kooperativ zusammenarbeiten bedeutet dies auch, dass
sie zum Teil auf gleiche Daten zugreifen bzw. auch identische Informationsobjekte
parallel oder sequentiell modifizieren müssen. Fragestellungen wie „Wer hat vor mir
bereits ein Informationsobjekt bearbeitet?“ können im Kontext von GroupwareSystemen bereits in Form einer Objekthistorie beantwortet werden.
Andere Fragestellungen können jedoch über Groupware-Systemen derzeit nicht bzw.
nur unzureichend beantwortet werden. Dazu gehört beispielsweise die Frage „Wer ist
aktuell neben mir im System aktiv und arbeit an einem bestimmten Aspekt einer gemeinsamen Gesamtaufgabe?“
Bei der Beantwortung derartiger Fragestellungen helfen die durch Awareness-Systeme
bereitgestellten Informationen. Die Unterstützung der Gruppenwahrnehmung durch
Präsentation von Informationen über die Aktionen anderer Akteure im Kontext kooperativer Zusammenarbeit bietet eine Reihe von Vorteilen. So können beispielsweise
verfügbare und richtige Ansprechpartner schnell identifiziert und Fragen direkt besprochen werden. Auf der anderen Seite bergen derartige Systeme die Gefahr der
Informationsüberflutung, der Arbeitsablenkung und ein erhöhtes Potential für eine
Arbeitsstörung.
Das Ziel dieser Arbeit ist aufbauend auf diesen und weiteren Vorüberlegungen zunächst
ein tragfähiges Awareness-Modell zu entwerfen und es anschließend auf Basis eines
konzeptionellen Entwurfs als Prototyp zu realisieren.
1.3 Aufbau der Arbeit
Im anschießenden Kapitel erfolgt zunächst die Vorstellung von Grundlagen hinsichtlich
kollaborativer Arbeitsumgebungen. Dazu wird zunächst in Form einer thematischen
Abgrenzung das Forschungsgebiet Computer Supported Cooperative Work näher dargestellt und die Bedeutung von Groupware hinsichtlich der Unterstützungsfunktionen
für kollaborative Arbeit erläutert.
Daran anschließend erfolgt die Einordnung und
Definition von Awareness und eine Diskussion in Bezug auf Chancen und Risiken
durch Bereitstellung von Awareness-Informationen. Der Schluss des Kapitels bildet die
Vorstellung zweier Forschungsergebnisse aus dem Bereich Awareness.
3
Im dritten Kapitel werden aufbauend auf diesen Forschungsergebnissen ein AwarenessModell entworfen und Anforderungen an eine Implementierung dieses Modells als
System formuliert. Dabei werden organisatorische, funktionale und technische Gesichtspunkte berücksichtigt. Auf Grundlage des Modells und der Anforderungen erfolgt
danach der konzeptionelle Entwurf einer Architektur.
Der entwickelte Prototyp wird im Rahmen des vierten Kapitels vorgestellt. Dazu erfolgt
nach einer Betrachtung der Systemumgebung die Beschreibung der realisierten Architektur. Besondere Leistungs- und Funktionsmerkmale des als Komponente implementierten Prototyps werden dabei hervorgehoben.
Der Einsatz des Prototyps wird in Form eines Szenarios im fünften Kapitel dargestellt.
Die Systemumgebung bildet dabei das am Groupware Competence Center entwickelte
Grading Management System.
Ein Ausblick auf potentielle Verbesserungen und Erweiterungen des Prototyps wird im
sechsten Kapitel gegeben.
Das letzte Kapitel der Arbeit beinhaltet eine abschließende Zusammenfassung.
4
2 Grundlagen
2.1 Kollaborative Arbeitsumgebungen
2.1.1 Computer Supported Cooperative Work
Computer Supported Cooperative Work (CSCW), dt. „Computerunterstützung für die
Gruppenarbeit” ([Teufel et al. 1995], S. 14), bezeichnet ein Forschungsgebiet, das sich
mit der „Rechnerunterstützung kooperativen Arbeitens“ ([Hasenkamp/Syring 1994], S.
15) auseinandersetzt.
„Ziel ist es, die Zusammenarbeit von Menschen durch den Einsatz von Informations- und Kommunikationstechnik zu verbessern, d. h. effizienter und flexibler,
aber auch humaner und sozialer zu gestalten.“ ([Hasenkamp/Syring 1994], S. 15)
Als interdisziplinäres Forschungsgebiet beinhaltet die CSCW-Forschung Beiträge verschiedener Disziplinen, wie z. B. der Wirtschaftsinformatik, der Informatik, der Soziologie, der Psychologie und der Organisationslehre (vgl. [Nastansky et al. 2002], S. 238;
[Teufel et al. 1995], S. 16ff.; [Greenberg 1991], S. 1; [Burger 1997], S. 8).
Historisch geprägt wurde der Begriff „Computer Supported Cooperative Work“ 1984
durch Greif und Cashman, die ihn als Titel für einen Workshop wählten. Seit 1986
findet im 2-jährigen Turnus eine „Conference on Computer Supported Cooperated
Work“ in den USA bzw. Kanada statt und seit 1989 tagt – als europäisches Pendant –
die „European Conference on Computer Supported Cooperative Work“ (ECSCW) in
den ungeraden Jahren (vgl. [Riemer/Arendt/Wulf 2005], S. 4; [Teufel et al. 1995], S.
17f.; [Nastansky et al. 2002], S. 238).
2.1.2 Groupware
Während CSCW das Forschungsgebiet des kooperativen Arbeitens beschreibt, wird die
Software bzw. auch die Hardware, die im Rahmen von CSCW eingesetzt und entwickelt wird, als Groupware bezeichnet (vgl. [Burger 1997], S. 7; [Teufel et al. 1995],
S. 21).
5
Genauer definiert wurde der Begriff von Johansen, durch den die Bezeichnung seit 1988
populär geworden ist:
„Groupware is a generic term for specialized 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.” ([Johansen 1988],
S. 1)
Mittlerweile existieren eine ganze Reihe weiterer Definitionen (vgl. u. a. [BornscheinGrass 1995], S. 12), von denen einige schon spezielle Aspekte der computerunterstützten Gruppenarbeit betonen. Ellis et al. berücksichtigen in ihrer Begriffsbestimmung
– neben der Betonung einer gemeinsamen Arbeitsaufgabe – die Bereitstellung einer
gemeinsamen Arbeitsumgebung und definieren Groupware als
„computer-based systems that support groups of people engaged in a common
task (or goal) and that provide an interface to a shared environment.” ([Ellis/Gibbs/Rein 1991], S. 40)
Andere Autoren definieren den Begriff Groupware hingegen weniger restriktiv:
„Groupware bzw. CSCW-Applikationen sind aus Software und eventuell spezifischer Hardware bestehende Systeme, durch die Gruppenarbeit unterstützt oder
ermöglicht wird.“ ([Teufel et al. 1995], S. 22)
Aufgrund einer fehlenden einheitlichen Definition soll im Rahmen dieser Arbeit unter
dem Begriff Groupware bzw. CSCW-Applikation Software verstanden werden, die das
kooperative Arbeiten einer Gruppe ermöglicht und unterstützt (vgl. [Nastansky et al.
2002], S. 239).
Eine eindeutige Abgrenzung und Klassifikation von Groupware-Applikationen kann
ebenso wenig wie eine einheitliche Definition getroffen werden, weil diese Systeme
häufig mehrere potentielle Unterscheidungskriterien gleichzeitig erfüllen und oft für
spezielle Anwendungsfälle entworfen werden (vgl. [Burger 1997], S. 19).
Eine bekannte, häufig zitierte und angewandte Kategorisierung von GroupwareSystemen bildet die sogenannte Raum-Zeit-Matrix (bzw. Any-Time-Any-Place-Matrix),
mit der Johansen eine Einteilung nach der zeitlichen Nähe (Grad der Synchronität) und
der räumlichen Nähe der unterstützten Zusammenarbeit vornimmt (vgl. [Johansen
1988], S. 44; [Koch 1997], S. 3).
6
Zusammenarbeit der
Zur gleichen Zeit
Zu verschiedenen Zeiten
Teammitglieder
(synchron)
(asynchron)
Am gleichen, geo-
ƒ Systeme zur computerunterstützten
ƒ Systeme zum Terminkalender-
graphischen Ort
(lokal, face-to-face)
Sitzungsmoderation
ƒ Präsentationssysteme
management für Gruppen
ƒ Projektmanagement-Systeme
ƒ Group Decision Support Systeme
An verschiedenen Orten
ƒ Audio- und Videokonferenzsysteme
ƒ E-Mail-Systeme
(verteilt)
ƒ Screen-Sharing-Systeme
ƒ Voice-Mail-Systeme
ƒ Mehrautorensysteme
ƒ Systeme für Electronic Conferencing
ƒ Bulletin Board-Systeme
ƒ Shared Information Systems
ƒ Workflow-Systeme
Tabelle 1 - Raum-Zeit-Matrix mit Groupware-Systemen (vgl. [Nastansky et al. 2002], S. 240)
Die Verwendung der Raum-Zeit-Matrix als Klassifikationsschema für GroupwareSysteme (siehe Tab. 1) ist allerdings aus mehreren Gründen kritisch zu betrachten. Zum
einen ist eine Einordnung von Systemen in die Quadranten der Matrix aufgrund der
fehlenden Trennungsschärfe der Dimensionen schwierig. Zum anderen führt die Diversifizierung und die Ausweitung des Funktionsumfangs bestehender Groupware-Systeme
in der heutigen Zeit dazu, dass sich Applikationen gleich mehreren Quadranten zuordnen lassen (vgl. [Borghoff/Schlichter 1998], S. 121).
Somit sollte die Raum-Zeit-Matrix weniger als Gliederungsinstrument für GroupwareProdukte herangezogen werden, sondern eher zur Veranschaulichung der Unterstützungssituationen bzw. der Verwendung von Groupware-Applikationen eingesetzt
werden (vgl. [Koch 1997], S. 5; [Nastansky et al. 2002], S. 239f.).
2.1.3 Unterstützungsfunktionen
Ein weiterer Ansatz Groupware-Systeme zu gliedern ist – neben der Raum-Zeit-Matrix
– der Grad, inwiefern Interaktionsprozesse zwischen den Gruppenmitgliedern unterstützt werden. Hierbei wird zwischen Kommunikations-, Koordinations- und Kooperationsprozessen unterschieden (vgl. [Riemer/Arendt/Wulf 2005], S. 21).
Kommunikation beschreibt die Übermittlung und den Austausch von Informationen
zwischen Personen, zwischen Personen und Computersystemen sowie zwischen Computersystemen untereinander und bildet die Basis für vertiefende Formen der Zusammenarbeit wie Koordination und Kooperation (vgl. [Nastansky et al. 2002], S. 240).
7
Im Gegensatz zu face-to-face-Situationen bildet die effiziente Unterstützung von Kommunikationsprozessen im Rahmen von Groupware eine große Herausforderung, da
sowohl zeitliche als auch räumliche Distanzen überwunden werden müssen. Im asynchronen Fall kann eine Kommunikation beispielsweise nur über die temporäre Speicherung der Nachricht in einem Informationsobjekt bzw. Artefakt erfolgen. Daher weist
Kommunikation im Kontext von Groupware-Systemen einen indirekten Charakter auf
(siehe Abb. 1).
direkte
Kommunikation
indirekte
Kommunikation
Modifizierung
gemeinsamer Artefakte
Artefakt
Abbildung 1 - Direkte vs. indirekte Kommunikation
(in Anlehnung an [Schlichter/Koch/Bürger 1998], S. 201)
Neben der zeitlichen und räumlichen Struktur (siehe Tab. 1, S. 6) lässt sich Kommunikation auch bezüglich der Kommunikationsbeziehungen (1:1, 1:n, n:1 oder n:m), der
eingesetzten Datentypen (Text, Ton, Bild, Video) oder der Adressierung (direkte vs.
anonym) gliedern (vgl. [Burger 1997], S. 51ff.; [Nastansky et al. 2002], S. 241).
Wenn im Rahmen der Gruppenarbeit kommuniziert wird und sich diese Kommunikation auf die Abstimmung aufgabenbezogener Tätigkeiten bezieht, so entspricht diese
Form der Kommunikation der Koordination (vgl. [Teufel et al. 1995], S. 12).
Burger unterscheidet hierzu die drei Koordinationsphasen „Vorbereitung“, „Abstimmung“ und „Realisierung“ (vgl. [Burger 1997], S. 45):
Auslöser
Vorbereitung
Abstimmung
Realisierung
Bedarf an Zu-
Abstimmungsbedarf
Team- und Auf-
sammenarbeit
Aktionen / Interaktionen
Partnersuche
gabenzuordnung
Verhandlung
Geplante Aufgaben
und Interaktionen
Tabelle 2 - Koordinationsphasen (in Anlehnung an [Burger 1997], S. 45)
8
Jede der drei Phasen wird durch ein bestimmtes Ereignis initiiert, erfordert bestimmte
Aktionen bzw. Interaktionen und liefert ein Resultat, das wiederum als Auslöser für die
nächste Phase dient. Bezüglich der einzelnen Phasen ist festzuhalten, dass diese mehrmals durchlaufen werden können, falls beispielsweise Konflikte auftreten oder sich die
Teamzusammensetzung ändert.
Der Beginn der ersten Koordinationsphase besteht in einem Bedarf nach Zusammenarbeit zur Erreichung eines Ziels und dem damit verbundenen Teambildungsprozess.
Daran anschließend muss eine Abstimmung hinsichtlich der Verteilung und der zeitlichen Strukturierung der Aufgaben getroffen werden. In der letzten Phase erfolgt die
Umsetzung der Teilaufgaben (vgl. [Burger 1997], S. 43ff.).
Hiermit beginnt der Prozess, der im Rahmen dieser Arbeit als Kooperation bezeichnet
werden soll, d. h. der zielgerichtete Austausch von Informationen innerhalb eines
Teams. Zur Bedeutung von Kommunikation und Koordination für die kooperative
Zusammenarbeit schreibt Bornschein-Grass:
„Kooperative Arbeit beruht auf Kommunikation und Koordination. Die Phänome
[sic] Koordination und Kommunikation können als konstituierend für Kooperation betrachtet werden.“ ([Bornschein-Grass 1995], S. 74)
In der englischsprachigen Literatur wird anstelle des Begriffs Kooperation meistens der
Begriff „collaboration“ verwendet. Dagegen wird dem Begriff „Kollaboration“ hierzulande eher eine negative Bedeutung beigemessen. So bedeutet das Verb „kollaborieren“
„mitarbeiten, mit dem Feind zusammenarbeiten“ ([Duden 2006], S. 589) und das Substantiv „Kollaboration“ sogar „aktive Unterstützung einer feindlichen Besatzungsmacht
gegen die eigenen Landsleute“( [Duden 2007], S. 535).
Trotz der historisch bedingten, negativen Bedeutung im deutschen Sprachraum wird der
Begriff aufgrund seiner Bedeutung in der englischsprachigen Fachwelt und Literatur in
dieser Arbeit verwendet. Anstatt die Begriffe Kooperation und Kollaboration synonym
zu gebrauchen, wird Kollaboration in dieser Arbeit als Oberbegriff gelten, der sämtliche
Interaktionsprozesse hinsichtlich Kommunikation, Koordination und Kooperation beinhaltet (siehe Abb. 2, S. 9).
9
Kommunikation
Austausch von Informationen
Koordination
Abstimmung aufgabenbezogener Tätigkeiten
Kooperation
Realisierung gemeinsamer Ziele
Kollaboration
Interaktionen, die Kommunikation, Koordination und
Kooperation beinhalten
Abbildung 2 - Prozesse innerhalb der Gruppenarbeit
(in Anlehnung an [Teufel et al. 1995], S. 11)
2.2 Awareness
2.2.1 Motivation und thematische Einordnung
Neben vielen Vorteilen und Potentialen wie z. B. „die Erleichterung und Verbesserung
von Zusammenarbeit und Informationsbeschaffung“ ([Burger 1997], S. 240) sowie die
„Überwindung zeitlicher und räumlicher Distanz“ ([Burger 1997], S. 241) bergen
Groupware-Applikationen auch Risiken in Bezug auf die kooperative Arbeit über computergestützte Systeme.
In einem Artikel über Media Spaces, d. h. Systeme, die eine ständige Verbindung verschiedener Orte über Video- und Audioverbindungen aufbauen (vgl. [Prinz 2001], S.
344), beschreibt Mackay einige der Herausforderungen bei der Entwicklung von
Groupware-Systemen für verteilte Umgebungen:
„People who are co-located benefit from chance encounters in hallways or chats
before and after meetings, resolving problems before they become critical. Working in the same physical environment helps people discover shared interests and
develop a sense of community. Implicit knowledge about the state of each other’s
work can prevent misunderstandings or resentment: If I see that my colleague’s
report is sitting in her ‘out’ basket, ready to send, I can avoid asking her about it
and thus avoid offending her. When people are separated geographically, much of
10
their informal knowledge about each other disappears and communication becomes much more formal.” ([Mackay 1999], S. 56)
Neben dem hier beschriebenen Verlust informellen Wissens und informeller Kommunikation existieren weitere potentielle Risiken, wie z. B. der Verlust der unmittelbaren
Wahrnehmung bei der Bearbeitung von gemeinsamem Material, der Verlust nonverbaler Kommunikation sowie einer externen Kontrolle bzw. Beobachtung der eigenen
Arbeit (vgl. [Oberquelle 2001], S. 93).
Gemein ist diesen Risiken das Hauptproblem, das computergestützte kooperative Arbeit
birgt; den Verlust oder zumindest die Einschränkung der Wahrnehmung des gemeinsamen Arbeitskontextes. (vgl. [Oberquelle 2001], S. 93).
Dabei soll zum Begriff Kontext die Definition von Dey und Abowd gelten:
„Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications
themselves.” ([Dey/Abowd 1999], S. 3f.)
Im Rahmen des CSCW-Forschungsgebietes wird die Bildung bzw. Wiederherstellung
der Wahrnehmung über den gemeinsamen Arbeitskontext unter dem Begriff Awareness
behandelt und diskutiert.
In Bezug auf die Bedeutung des Aspekts Awareness im CSCW-Kontext weisen Gross
et al. darauf hin, dass die Forschungsaktivität in diesem Bereich seit den 1990er Jahren
zwar weiterverfolgt wurde, aber seitdem weniger bedeutend und herausragend sei (vgl.
[Gross/Stary/Totter 2005], S. 328f.). Dagegen betont Schmidt die weiterhin zentrale
Rolle des Konzepts Awareness in der CSCW-Forschung (vgl. [Schmidt 2002], S. 285);
und Cadiz et al. schreiben in Bezug auf die gestiegene Anzahl der Forschungsbeiträge
auf den CSCW-Konferenzen zum Thema Awareness:
„The word ‘awareness’ did not appear in a paper title in the first five CSCW conferences, but appeared eight times in the next five and eleven times in the most recent five conferences. Papers focusing on awareness and notification have increased from one or two in early conferences to a quarter of all papers more recently.” ([Cadiz et al. 2002], S. 314)
11
2.2.2 Definition
Bei einer näheren Auseinandersetzung mit dem Thema Awareness im Rahmen der
CSCW-Forschung liegt es nahe, zunächst eine Übersetzung des Begriffs „Awareness“
ins Deutsche hinzuzuziehen. Eine direkte Übersetzung des Begriffs mit „Bewusstsein“
(vgl. [Duden 1999], S. 939) liefert zunächst jedoch kein zufriedenstellendes Ergebnis
für ein vielschichtiges sowie komplexes Forschungsgebiet.
Mehr noch existiert auch im englischen Sprachraum kontextabhängig Raum für verschiedene Interpretationen des Begriffs Awareness. Eine intensive Auseinandersetzung
dieser Thematik findet sich in einem Beitrag von Schmidt mit dem Titel „The Problem
with ‚Awareness’“ (vgl. [Schmidt 2002]). Er schreibt bezüglich der Begrifflichkeit von
Awareness:
„The very word ‘awareness’ is one of those highly elastic English words that can
be used to mean a host of different things. Depending on the context it may mean
anything from consciousness or knowledge to attention or sentience, and from
sensitivity or apperception to acquaintance or recollection.” ([Schmidt 2002], S.
287)
Daher fordert Schmidt, Awareness im Kontext von CSCW weniger als unabhängigen
mentalen Zustand, sondern immer im direkten Zusammenhang zu der bewusstseinsbildenden Aktion bzw. Wahrnehmung zu betrachten und zu untersuchen (vgl. [Schmidt
2002], S. 287f.). Zur Bedeutung des Begriffs im Rahmen kooperativer Arbeit schreibt
Schmidt u. a.:
„The term ‘awareness’ here denotes taking heed of unfolding events and of possibly unfolding events; of things being done, of things done, and of things in need
of being done; of developments within the joint effort that may be advantageous,
detrimental, hazardous, etc. for one’s own work; of occurrences that makes one’s
own work more urgent or less so, that require action or inaction, that necessitate
changes to the intended course of action, etc. – all of it directly motivated by the
actors’ being interdependent in their work and hence by the unavoidable requirements of coordinating and integrating their various actions.” ([Schmidt 2002], S.
290)
12
Eine erste und oft zitierte Definition von Awareness im Rahmen von CSCW gaben
1992 Dourish und Bellotti:
„(…) awareness is an understanding of the activities of others, which provides a
context for your own activity.” ([Dourish/Bellotti 1992], S. 107)
Dourish und Bellotti betonen damit das Verstehen von Handlungsabläufen anderer
Personen, das die eigene zielgerichtete und sinnvolle Handlung in der Gruppe ermöglicht bzw. beeinflusst (vgl. [Fuchs 1998], S. 7).
Eine Reihe weiterer Definitionen von Awareness listen die Autoren Hoffmann, Sohlenkamp und Schmidt auf (vgl. [Hoffmann 2004], S. 15; [Sohlenkamp 1999], S. 40f.;
[Schmidt 2002]). Darin zeigt sich, dass die allgemeine Definition von Dourish und
Bellotti von den Wissenschaftlern der verschiedenen Forschungsgruppen im Bereich
Awareness oftmals erweitert oder durch eine speziellere Definition ersetzt wurde. Der
Begriff Awareness ist einzeln in der CSCW-Forschung eher als Oberbegriff anzusehen,
der hinsichtlich unterschiedlicher und teilweise spezifischer Gesichtspunkte und Fragestellungen interdisziplinär diskutiert wird.
Eine im Kontext dieser Arbeit treffende Definition liefert beispielsweise Prinz:
„Awareness is an understanding of the presence and activities of others within a
shared hybrid environment, which provides a context for mutual orientation and
opportunities for situative reactions.” ([Prinz 2001], S. 350)
Damit betont Prinz, dass Awareness auf „eine Wahrnehmung des kooperativen Geschehens und der Aktivitäten in der Gruppe“ abzielt und übersetzt Awareness daher
auch mit „Gruppenwahrnehmung“ oder „Geschehenswahrnehmung“ ([Prinz 2001], S.
335). Andere Autoren im deutschsprachigen Raum verwenden stattdessen die
Formulierungen „Gewärtigkeit“ ([Pankoke-Babatz/Prinz/Schäfer 2004a], [Hoffmann
2004]) oder „Gewahrsein“ ([Holmer/Haake/Streitz 2001]).
Statt eine der Übersetzungsmöglichkeiten zu verwenden, wird in dieser Arbeit weiter
der englische Begriff Awareness benutzt, für den folgende Definition gelten soll:
Awareness beschreibt die Wahrnehmung der Präsenz und Aktivitäten von Akteuren in einem gemeinsamen Arbeitskontext im Rahmen kooperativer Arbeit.
13
Awareness
Artefakt
Individueller
Arbeitskontext
Individueller
Arbeitskontext
Gemeinsamer
Arbeitskontext
Abbildung 3 - Awareness im Hinblick eines gemeinsamen Arbeitskontextes
Im Fall der Bearbeitung eines Informationsobjekts wird beispielsweise thematisiert, ob
zeitgleich bzw. zeitversetzt eine Bearbeitung durch einen weiteren Akteur stattfindet
bzw. stattgefunden hat, sowie die Frage, um wen es sich dabei handelt (siehe Abb. 3).
2.2.3 Erzeugung von Awareness-Informationen und Kategorisierung
Der Prozess zur Erzeugung von Awareness-Informationen gliedert sich in drei Phasen
(vgl. [Sohlenkamp 1999], S. 48f.):
ƒ Bereitstellung von Awareness-Informationen
ƒ Verteilung von Awareness-Informationen
ƒ Präsentation von Awareness-Informationen
Verteilung von
Informationen
Bereitstellung von
Informationen
Präsentation von
Informationen
Präsentation von
Informationen
Bereitstellung von
Informationen
Abbildung 4 - Phasen bei der Erzeugung von Awareness-Informationen
(in Anlehnung an [Sohlenkamp 1999], S. 49)
14
Die drei Phasen können auf Basis verschiedener Kategorien und Kriterien voneinander
abgegrenzt werden:
Phase 1: Bereitstellung von Awareness-Informationen
Kategorie
Kriterien
Auslöser
explizit
implizit
Filterung
gefiltert
ungefiltert
Empfängerkreis
identifiziert
anonym
Tabelle 3 - Kategorisierung nach Bereitstellungskriterien
Die Bereitstellung von Awareness-Informationen kann entweder explizit (der Anwender
muss Informationen aktiv zur Verfügung stellen) oder implizit (Aktionen des Anwenders werden automatisch passiv gesammelt bzw. protokolliert) erfolgen (vgl. [Steinfield/Jang/Pfaff 1999], S. 84f.; [Dourish/Bellotti 1992], S. 107).
Des Weiteren ist zu unterscheiden, ob und inwiefern der Anwender die Informationen,
die über ihn und seine Aktionen erzeugt werden, mittels Filterregeln einschränken kann
und ob er einen Empfängerkreis für die Informationen festlegen muss (identifiziert)
oder nicht (anonym) (vgl. [Otjacques et al. 2006], S. 95f.).
Phase 2: Verteilung von Awareness-Informationen
Kategorie
Kriterien
Zeitlicher Bezug
synchron
asynchron
Verteilungskonzept
push
pull
Tabelle 4 - Kategorisierung nach Verteilungskriterien
Die Verteilung der Awareness-Informationen kann synchron (zwischen Bereitstellung
und Präsentation der Informationen liegt nur ein minimaler zeitlicher Verzug) oder
asynchron (die Informationen werden temporär zwischengespeichert) erfolgen (vgl.
[Fuchs 1998], S. 31ff.). Zusätzlich kann unterschieden werden, ob die Empfänger die
Informationen direkt zugestellt bekommen (Push-Modell) oder ob sie diese selektiv
abrufen können (Pull-Modell) (vgl. [Nastansky et al. 2002], S.240ff.).
15
Phase 3: Präsentation von Awareness-Informationen
Kategorie
Kriterien
Individualisierbarkeit
individuell
fixiert
Benachrichtigung
visuell
akustisch
Wahrnehmungsintensität
zentral
periphär
Anzeige
ursprungsgetreu
symbolisch
Platzierung
kontextbezogen
separat
Tabelle 5 - Kategorisierung nach Präsentationskriterien
Die Präsentation der Awareness-Informationen kann anhand fester Regeln erfolgen
(fixiert) oder durch den Empfänger, z. B. nach Typ der Awareness-Information oder
Aktualisierungsfrequenz konfiguriert werden (individuell) (vgl. [Steinfield/Jang/Pfaff
1999], S. 84). Zudem kann die Benachrichtigung über das Vorliegen einer neuen Awareness-Information durch visuelle oder akustische Signale unterstützt werden und die
Aufmerksamkeit des Adressaten direkt auf das neue Ereignis gelenkt werden (zentral)
oder ihm nur periphär visualisiert werden (vgl. [Steinfield/Jang/Pfaff 1999], S. 84;
[Fuchs 1998], S. 39).
Dabei kann die Anzeige der Awareness-Information entweder in gleicher Form erfolgen, wie sie bereitgestellt wurde (ursprungsgetreu), oder nur einzelne Bestandteile der
Originalinformation beinhalten (vgl. [Gutwin 1997], S. 78). Hinsichtlich der Platzierung
kann die Information kontextbezogen im Arbeitsbereich des Empfängers oder in einem
separaten Bereich dargestellt werden.
2.2.4 Bedeutung von Awareness
Nachdem in den vorangehenden Kapiteln das Konzept von Awareness im Rahmen des
CSCW-Forschungsgebiets vorgestellt wurde, ist an dieser Stelle festzuhalten, dass es
sich, auf den ersten Blick betrachtet, bei Awareness nicht um einen fundamental neuen
Bereich der Wissenschaft handelt. Sohlenkamp betont in diesem Zusammenhang:
„Perceiving, recognizing, and understanding the activities of others is a basic requirement for human interaction and communication in general.” ([Sohlenkamp
1999], S. 42)
Das Erfassen und Verstehen von Informationen ist ein elementarer Bestandteil kooperativer Zusammenarbeit. Ein Novum im Hinblick auf Awareness als Teilgebiet der
16
CSCW-Forschung besteht allerdings darin, dass hier Kollaboration über zeitliche und
räumliche Grenzen hinweg durch Einsatz von Groupware unterstützt wird. Das bedeutet, dass es Aufgabe des Groupware-Systems ist, den Kooperationsprozess dahingehend effektiv zu unterstützen und zu begleiten, dass wichtige Informationen zum
richtigen Zeitpunkt dem richtigen Adressaten bereitgestellt und auch derart präsentiert
werden, dass diese Informationen korrekt interpretiert werden können.
Die Vorteile des Einsatzes von Awareness-Systemen sowie die mit der Generierung und
Bereitstellung von Awareness-Informationen verbundene Problematik sind Bestandteile
der folgenden beiden Kapitel.
2.2.4.1 Vorteile durch Bereitstellung von Awareness-Informationen
Die Bereitstellung von Awareness-Informationen bildet eine Schlüsselfunktion für
CSCW-Anwendungen (vgl. [Dourish/Bellotti 1992], S. 112). Das Erzeugen und die
Übermittlung von Informationen über aktuell und in der Vergangenheit im GroupwareSystem anwesende Personen, die von ihnen durchgeführten Aktivitäten sowie die von
ihnen generierten und modifizierten Informationsobjekte tragen zur Koordination und
Strukturierung der eigenen Arbeit und Aufgaben bei (vgl. [Berlage/Sohlenkamp 1999],
S. 207).
Die Bildung eines gemeinsamen Bewusstseins über den derzeitigen Stand der kooperativen Arbeit hat dabei nicht nur Auswirkungen auf die gegenwärtige Zusammenarbeit. Darüber hinaus können auf Basis gemeinsamer Ziele und eines vorhandenen
Verständnisses der Aufgabenbereiche die Aktivitäten anderer Akteure prognostiziert
und die eigene Arbeit daran abgestimmt werden. Im Gegensatz dazu wäre ohne eine
Berücksichtigung von Awareness in Groupware-Anwendungen kooperatives Arbeiten
nahezu unmöglich (vgl. [Sohlenkamp/Prinz/Fuchs 2000], S. 31).
Stattdessen können durch die Miteinbeziehung der durch Awareness-Systeme gesammelten und verbreiteten Informationen in die Entscheidungs- und Arbeitsprozesse
der einzelnen Kooperationspartner Doppelarbeiten und kontradiktorische Arbeiten
vermieden
bzw.
reduziert
werden
(vgl.
[Dourish/Bellotti
1992],
S.
112;
[Berlage/Sohlenkamp 1999], S. 207).
Anstelle von Missverständnissen, Abstimmungs- und Synchronisationsproblemen (vgl.
[Prinz 2001], S. 335) tritt die Aussicht – basierend auf der Wahrnehmung aktueller
Vorgänge und Aktionen im gemeinsamen Arbeitsbereich – zielgerichtet und zeitnah
17
eine kontextspezifische Konversation zu initiieren oder in Problemsituationen eine
flexible Hilfestellung anbieten zu können (vgl. [Gutwin/Greenberg 1999], S. 245).
Gerade im Hinblick auf schwach- bis unstrukturierte Aufgaben, bei denen sich die
einzelnen Schritte nicht in einem vordefinierten Prozess abbilden lassen, ist ein hohes
Maß an Awareness für eine effektive Zusammenarbeit ausschlaggebend (vgl. [Schlichter/Koch/Bürger 1998], S. 209). Bei regelgebundenen Abläufen im Zusammenhang mit
kooperativer Arbeit lassen sich – auch anhand der Prozessdefinitionen – retrospektiv
Rückschlüsse auf die involvierten Akteure und Informationsobjekte ziehen. Im Gegensatz dazu ist die bewusste Erfassung von Awareness-Informationen bei unstrukturierten
Tätigkeiten von essentieller Bedeutung, um im Nachhinein die durchgeführten Aktionen
über eine Historie darstellen zu können.
Daraus ergeben sich weitere Vorteile des Einsatzes eines Awareness-Systems. Der
Wechsel in der Bearbeitung gemeinsamer Objekte ist zwar mit einem erhöhtem Koordinationsaufwand
verbunden,
aber
durch
Bereitstellung
von
Awareness-
Informationen kann die Nachvollziehbarkeit der Vorarbeiten für den nachfolgenden
Bearbeiter erleichtern werden (vgl. [Fuchs 1998], S. 31f.). Die Option zur Anzeige von
in der Vergangenheit gewonnenen Informationen ermöglicht zudem Neu- bzw. Wiedereinsteigern eine schnellere Orientierung im System und kann bei der Auflösung von
Versionskonflikten hilfreich sein (vgl. [Fuchs 1998], S. 32; [Heerwagen et al. 2004], S.
514).
Bei synchroner Kollaboration können im Gegenzug Versionskonflikte schon direkt
während ihrer Entstehung durch Visualisierung oder akustische Signale wahrnehmbar
gemacht und somit vermieden werden.
Ein weiterer Vorteil von Awareness-Systemen liegt darin, dass über die Bereitstellung
von Awareness-Informationen die Anreize und Wahrscheinlichkeit einer spontanen,
opportunistischen Interaktion erhöht werden. In Bezug auf die Bedeutung informeller
Kommunikation im Kontext von Groupware-Applikationen sei an dieser Stelle exemplarisch auf Johansen und Gutwin verwiesen (vgl. [Johansen 1988], S. 36f.; [Gutwin et
al. 2005], S. 2).
Die Bereitstellung von Awareness-Informationen über die Aktivitäten und Akteure in
einem System bietet auch unterschwellige Potentiale. Ein Beispiel hierfür ist die Herausbildung eines Verantwortungsbewusstseins. Grundlage hierfür kann die Tatsache
sein, dass einem Akteur bewusst ist bzw. sein muss, dass seine Kooperationspartner
18
seine Aktivitäten über das System einsehen und nachvollziehen können (vgl. [Erickson/Kellogg 2000], S. 61f.; [ter Hofte et al. 2002], S. 12).
Auf der anderen Seite können sich durch das Fehlen von Awareness-Informationen
auch Probleme ergeben wie z. B., dass bei den Nutzern von Groupware ein Gefühl der
Isolation entstehen kann (vgl. [Pedersen/Sokoler 1997], S. 52) oder dass die Nutzer die
Arbeitsaktivität ihrer Kollegen falsch interpretieren. Hierzu bemerken Steinfiel et. al:
„At worst, the lack of information about others' activities can actually harm group
morale, such as when team members assume their colleagues are inactive when
they have not heard from them.” ([Steinfield/Jang/Pfaff 1999], S. 82)
Awareness-Systeme können aber auch dabei unterstützen, neue Kooperationsbeziehungen aufzubauen. Die Identifikation eines geeigneten Ansprechpartners kann
beispielsweise über dessen Gruppenzugehörigkeit (vgl. [Yee/Park 2005]) oder anhand
seiner Tätigkeiten erfolgen, die sich mit den eigenen Aufgaben überschneiden.
Ein weiterer Vorteil ist, dass sich der Verlust nonverbaler Kommunikation wie Gestik
oder Mimik in computergestützten Kooperationssystemen durch ein hohes Maß an
Bereitstellung von Awareness-Information teilweise ausgleichen lässt. Während in einer
realen Büroumgebung Signale wie Körpersprache, das Verhalten oder auch Blickkontakte als Indikatoren dienen, inwieweit eine andere Person gerade mit einer
individuellen Aufgabe beschäftigt ist, kann in Groupware-Systemen die Bereitstellung
von Verfügbarkeitsinformationen bei der Wahl eines passenden Konversationszeitpunktes unterstützen (vgl. [Heerwagen et al. 2004], S. 514; [Dabbish/Kraut 2004], S.
182ff.; [Godefroid et al. 2000], S. 59f.). Davis und Gutwin schreiben hierzu in Anlehnung an eine Studie von Dabbish und Kraut (vgl. [Dabbish/Kraut 2004]):
„People who saw more information interrupted less often, because they were better able to determine that the person was busy. The problem is that less information gives the observer the ‘benefit of ignorance:’ since they do not have enough
information to determine availability, they cannot be blamed for interrupting at a
bad time.” ([Davis/Gutwin 2005], S. 151)
2.2.4.2 Problematik der Bereitstellung von Awareness-Informationen
Neben den im letzten Kapitel genannten Vorteilen und Chancen durch Einsatz von
Awareness-Systemen existieren auch Risiken. Ein Hauptproblem liegt dabei in der
richtigen Ausbalancierung des Detaillierungs- und Granularitätsgrades der zu bereit-
19
stellenden Informationen. Hudson und Smith weisen auf die Diskrepanz hin, dass zwar
einerseits die Bereitstellung vieler Informationen über den eigenen Arbeitsbereich zu
einem höheren Maß an Awareness bei den Kollegen führen könne, auf der anderen Seite
jedoch die Gefahr bestehe, dass der Erhalt detaillierter Informationen beim Empfänger
selbst als Informationsüberladung und damit als Belästigung und arbeitsstörend empfunden würde (vgl. [Hudson/Smith 1996], S. 248f. u. S. 256).
Nicht nur auf Seiten der Empfänger, sondern auch mit Blick auf die Sender bzw. Bereitsteller ist das Erzeugen detaillierter Awareness-Informationen kritisch zu betrachten.
Hierbei kann zwischen der expliziten Generierung und der automatischen Sammlung
von Informationen unterschieden werden.
Bei der expliziten Generierung von Awareness-Informationen ergibt sich zum einen die
Problematik, dass das manuelle Bereitstellen von Informationen über den eigenen aktuellen Arbeitskontext für einen Sender zunächst zusätzlichen Arbeitsaufwand bedeutet,
ohne dass er davon direkt profitiert (vgl. [Khoshafian/Buckiewicz 1995], S. 314; [Dourish/Bellotti 1992], S. 109). Gleichzeitig stellt sich die Frage, inwieweit eine sendergesteuerte Verbreitung von Awareness-Informationen die Bedürfnisse des Empfängers
befriedigen und für ihn relevante Informationen hervorbringen kann. Dies ist insbesondere bei unterschiedlichen Prämissen in Bezug auf einzelne Aspekte der kooperativen Arbeit oder einer inkongruenten Erwartungshaltung der Akteure von Bedeutung (vgl. [Khoshafian/Buckiewicz 1995], S. 314; [Dourish/Bellotti 1992], S. 109).
In Bezug auf das einfache, direkte „off-loading“ automatisch generierter AwarenessInformationen bei Kollegen existiert nach Heath et al. eine vergleichbare Problematik:
„(i) it may not be clear what others know or need to know,
(ii) it may not be clear how they require information (in what form and when),
(iii) and it may not be clear whether people are themselves too busy to receive
particular information” ([Heath et al. 2002], S. 320)
Das automatische Publizieren von personenbezogenen Informationen über Arbeitsstatus
und -inhalte birgt zudem weitere Risiken: Alle Autoren, die sich im Rahmen von
CSCW kritisch mit Awareness und Awareness-Systemen auseinandersetzen, betonen
den Aspekt eines Verlusts an „privacy“, d. h. die Problematik einer Einschränkung der
Privatsphäre und eines potentiellen Datenmissbrauchs (vgl. [Hudson/Smith 1996],
[Godefroid et al. 2000], [Patil/Lai 2005]).
20
In Deutschland befasst sich das Bundesdatenschutzgesetz (BDSG) mit dem Schutz personenbezogener Daten, die in IT-Systemen verarbeitet werden. Der Zweck des BDSG
ist jedoch nicht direkt persönliche Daten zu schützen, sondern „den Einzelnen davor zu
schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem
Persönlichkeitsrecht beeinträchtigt wird“ (vgl. [BDSG 1990], § 1). In Bezug auf Awareness spielt dabei „der Grundsatz der Datenvermeidung und -sparsamkeit“ sowie der
im Rahmen des so genannten Volkszählungsurteils geprägte Begriff des „Rechts auf
informationelle Selbstbestimmung“ eine Rolle (vgl. [Stahlknecht/Hasenkamp 2005], S.
495f.).
Sobald in einem Awareness-System personenbezogene Daten automatisch erzeugt und
weitergeleitet werden, entsteht ein Konflikt in Bezug auf das aus dem Grundgesetz
abgeleiteten Grundrecht, dass jeder über „Preisgabe und Verwendung seiner persönlichen Daten“ bestimmen kann (vgl. [Stahlknecht/Hasenkamp 2005], S. 495f.).
Aufgrund
mangelnder
Einflussnahme
bei
der
Generierung
von
Awareness-
Informationen, einem fehlenden oder unzureichenden Wissen über den Adressatenkreis
und die Verwendung der übermittelten Informationen, kann sich daher bei Anwendern
eine Furcht vor Überwachung bzw. externer Kontrolle bilden (vgl. [Prinz 2001], S. 337;
[Schmalzl/Imbery/Merkl 2004], S. 527). Da Awareness-Informationen es ermöglichen
Arbeitsaktivitäten von Personen – z. B. in Bezug auf das geleistete Arbeitspensum in
einem bestimmten Zeitintervall – miteinander zu vergleichen, können sich zudem Konkurrenzgedanken bilden, die zu einem gegenseitigen Verbergen oder bewusstem Boykott oder Missbrauch des Systems führen können (vgl. [Schmalzl/Imbery/Merkl 2004],
S. 527).
Dabei ist gerade die Akzeptanz der Anwender von Awareness-Systemen von großer
Bedeutung, da für Einzelne die Teilnahme am System erst Nutzen bringend wird, wenn
eine „kritische Masse“, d. h. eine bestimmte Zahl von Anwendern, erreicht und überschritten wird (vgl. [Ackerman/Starr 1995], S. 160; [Koch 1997], S. 64).
2.2.4.3 Zusammenfassung
Bei dem Einsatz von Awareness-Systemen gilt es Chancen und Risiken gegeneinander
abzuwägen. Einerseits ermöglicht eine Bereitstellung von Awareness-Informationen den
Akteuren ihre kooperative Arbeit effektiver und effizienter zu gestalten und die räumlichen und zeitlichen Distanzen ihrer Arbeitswelt mit Computerunterstützung zu über-
21
winden. Andererseits können die Risiken wie z. B. der Verlust von Privatsphäre, potentieller Datenmissbrauch und Störung bzw. Ablenkung von der eigenen Arbeit, sowie der
aus diesen Punkten resultierenden Gefahr der Systeminakzeptanz seitens der Nutzer
nicht ignoriert werden.
Bei der Konzeption von Awareness-Systemen gilt es, einen adäquaten Kompromiss
zwischen den Bedürfnissen und Vorbehalten der späteren Anwender zu finden. Studien
belegen hierbei, dass Anwender durchaus dazu bereit sind, Awareness-Informationen
über sich und ihre Tätigkeiten preiszugeben, wenn sie dabei Vorteile für sich und die
gemeinsame Arbeit mit ihren Kooperationspartnern erkennen (vgl. [Yee/Park 2005], S.
557; [Patil/Lai 2005], S. 109). Dies gilt auch, wenn sie im Vorfeld bezüglich der Einführung eines Awareness-Systems eine ablehnende Haltung eingenommen haben (vgl.
[Fuchs 1998], S. 153ff.).
Daher sollte beim Entwurf von Awareness-Systemen nicht nur hinsichtlich der Kollektion und der Präsentation von Awareness-Informationen auf die Wahl eines angemessenen Detaillierungs- und Granularitätsgrades sowie einer angemessenen Positionierung geachtet werden, sondern auch weitere Kriterien zur Steigerung der Benutzerfreundlichkeit berücksichtigt werden. Diesbezüglich werden im Folgenden die
Aspekte Konfigurierbarkeit und Reziprozität vorgestellt.
Unter Konfigurierbarkeit soll hierbei das Maß verstanden werden, inwieweit die Anwender des Systems die Bereitstellung eigener Awareness-Informationen als auch den
Empfang von Awareness-Informationen anderer Personen mittels Filterregeln oder
Einstellungsoptionen individualisieren und steuern können.
Reziprozität beschreibt im Zusammenhang mit Awareness dagegen das Prinzip eines
wechselseitigen Zugangs zu Awareness-Informationen. Das bedeutet beispielsweise im
Hinblick auf die kooperative Arbeit an einem gemeinsamen Informationsobjekt, dass
die beteiligten Akteure ihre Anwesenheit und Aktionen gegenseitig wahrnehmen können. Prinz versteht unter dem Prinzip der Reziprozität, dass „wenn Benutzer A die
Aktivitäten von Benutzer B vermittelt bekommt, dann wird Benutzer B darüber informiert, bzw. Benutzer A kann nur dann die Aktivitäten von B sehen, wenn dies auch
umgekehrt gilt“ ([Prinz 2001], S. 337).
Beide Ansätze verfolgen das Ziel, Risiken wie den Verlust von Privatsphäre, der ungewollten Arbeitsstörung sowie mangelnder Einflussnahme des Anwenders auf den
22
Erzeugungsprozess von Awareness-Informationen durch ein erhöhtes Maß an Transparenz entgegen zu wirken.
Die Bedeutung der Aspekte Konfigurierbarkeit und Reziprozität für den Erfolg und die
Akzeptanz von Awareness-Systemen wird von verschiedenen Autoren diskutiert (vgl.
[Prinz 2001], S. 337; [Yee/Park 2005], S. 557; [Hudson/Smith 1996], S. 250; [Godefroid et al. 2000], S. 60; [Patil/Lai 2005], S. 109; [Pankoke-Babatz/Syri 1997], S. 193).
In diesem Zusammenhang weist Prinz darauf hin, dass die beiden Aspekte zwar wichtige Maßnahmen seien, sie allerdings den Schutz der Privatsphäre in CSCW-Systemen
nicht definitiv gewährleisten könnten. Entscheidend für die Akzeptanz und den Erfolg
eines Awareness Systems seien nach Prinz auch immer das soziale und organisatorische
Umfeld und das Risiko-Nutzen-Verhältnis für jeden Anwender und die Gruppe (vgl.
[Prinz 2001], S. 338).
2.2.5 Modelle und Konzepte
Bereits in Kapitel 2.2.2 wurde darauf hingewiesen, dass der Begriff Awareness im
Rahmen der CSCW-Forschung weitestgehend unter spezifischen Gesichtspunkten
diskutiert wird. Aufgrund der fehlenden Eindeutigkeit des Begriffs weist Schmidt darauf hin, dass Forschungsgruppen in diesem Teilgebiet von CSCW den Begriff Awareness häufig in Kombination mit unterschiedlichen Adjektiven verwenden (vgl. [Schmidt
2002], S. 286).
Einige Beispiele hierfür werden im Folgenden genannt, wobei die behandelten Aspekte
von Awareness nicht klar voneinander abzugrenzen sind und es hinsichtlich der wissenschaftlichen Fragestellungen innerhalb der Teilgebiete durchaus zu Überschneidungen
kommt:
ƒ Action Awareness (u. a. [Carroll et al. 2003])
ƒ Activity Awareness (u. a. [Convertino et al. 2004], [Neale/Carroll/Rosson 2004])
ƒ Change Awareness (u. a. [Tam/Greenberg 2006])
ƒ Group Awareness (u. a. [Hill/Gutwin 2005], [Gutwin/Penner/Schneider 2004])
ƒ Peripheral Awareness (u. a. [Cadiz et al. 2002])
ƒ Presence Awareness (u. a. [Christein/Schulthess 2002])
ƒ Social Awareness (u. a. [Bardram/Hansen/Soegaard 2006], [Prinz 2002])
ƒ Spatial Awareness (u. a. [Bardram/Hansen/Soegaard 2006])
23
ƒ Workspace Awareness (u. a. [Gutwin/Greenberg 2002], [Schlichter/Koch/Bürger
1998], [Gutwin 1997])
Zwei dieser Ansätze werden in den folgenden beiden Kapiteln kurz vorgestellt. Dabei
handelt es sich zum einen um „Workspace Awareness“ nach Gutwin und Greenberg
(vgl. [Gutwin 1997], [Gutwin/Greenberg 1996], [Gutwin/Greenberg 1999], [Gutwin/Greenberg 2002], [Gutwin/Greenberg 2004]) und zum anderen – in Anlehnung an
Presence Awareness – um „Place-based Presence“ nach ter Hofte et al. (vgl. [ter Hofte
et al. 2002], [ter Hofte/Mulder/Verwijs 2005]).
2.2.5.1 Workspace Awareness
Gutwin und Greenberg entwickelten ihr Konzept „Workspace Awareness” auf Basis
von Beobachtungen und Studien realer, physischer Arbeitsumgebungen und -situationen
(vgl. [Gutwin/Greenberg 1996], S. 208). Dabei stellen sie fest, dass in diesem Umfeld
eine effektive Zusammenarbeit möglich sei. Ein Kooperationspartner wüsste, mit wem
er zusammenarbeitet, mit welchen Aufgaben die Anderen beschäftigt sind, wo sie arbeiten und welche Abläufe existieren (vgl. [Gutwin/Greenberg 2002], S. 420). Dieses
Phänomen bezeichnen sie als Workspace Awareness:
„Workspace awareness is the up-to-the-moment understanding of another person’s interaction with a shared workspace.” ([Gutwin/Greenberg 2002], S. 412)
Gutwin und Greenberg verfolgen daher in ihrem Ansatz nicht den Zweck ein Bewusstsein über den Arbeitsbereich (Workspace) selbst zu schaffen, sondern vielmehr eine
Wahrnehmung der Akteure und ihrer Interaktionen im und mit dem Workspace (vgl.
[Gutwin/Greenberg 2002], S. 417).
Im Vergleich zwischen realer und virtueller Welt kommen sie zu dem Ergebnis, dass in
Groupware-Systemen Workspace Awareness nicht adäquat unterstützt sei (vgl. [Gutwin/Greenberg 1996], S. 208). Die Ursachen hierfür sehen sie zum einen darin, dass
Groupware-Systeme nur einen Bruchteil der Awareness-Informationen einer face-toface-Arbeitsumgebung erzeugen würden. Zum anderen lieferten die Aktionen von
Akteuren in Groupware-Applikationen nur einen Teil der Informationen, die diese
Aktionen in der Realwelt verursachen würden. Zudem blieben auch oft die wenigen
vorhandenen Awareness-Informationen in Groupware-Anwendungen ungenutzt (vgl.
[Gutwin/Greenberg 2002], S. 415; [Gutwin/Greenberg 2004], S. 180).
24
Daher betonen sie die Bedeutung, die Systementwicklern bei dem Entwurf von Groupware beikomme, um Workspace Awareness effektiv zu unterstützen (vgl. [Gutwin/Greenberg 1996], S. 208) und entwerfen ein Framework, in dem sie drei Fragestellungen bezüglich Workspace Awareness analysieren.
Im ersten Teilabschnitt des Frameworks gehen sie der Frage nach, auf Basis welcher
Fragestellungen eine Gliederung von Workspace-Awareness-Informationen erfolgen
kann. Anschließend beschreiben sie, auf welche Weise diese Informationen erfasst
werden können und im letzten Teilabschnitt, inwieweit Workspace Awareness kollaboratives Arbeiten unterstützt.
Abgeleitet von Fragestellungen – mit denen sich eine Person im Rahmen kollaborativer
face-to-face-Zusammenarbeit konfrontiert sehen könnte – schlagen Gutwin und Greenberg die folgende Kategorisierung vor, um die zu präsentierenden AwarenessInformationen zu identifizieren (vgl. [Gutwin/Greenberg 1996], S. 209).
Kategorie
Element
Fragestellung
Wer
Anwesenheit
Ist jemand im Workspace aktiv?
Identität
Wer ist im Workspace aktiv?
Zuständigkeit
Wer ist für eine Aufgabe zuständig?
Aktion
Was machen die Personen im Workspace momentan?
Intention
Welches Ziel verfolgen die Personen mit ihrer Aktion?
Artefakt
Welche Objekte bearbeiten die Personen?
Ort
Von wo aus wird gearbeitet?
Fokus
Was wird betrachtet?
Sichtweite
Wohin kann eine Person sehen?
Reichweite
Bis wohin reicht der Einflussbereich einer Person, um
Was
Wo
beispielsweise Änderungen vornehmen zu können?
Tabelle 6 - Gegenwartsbezogene Elemente von Workspace Awareness
(in Anlehnung an [Gutwin/Greenberg 2002], S. 421)
Gutwin und Greenberg unterscheiden zwischen gegenwartsbezogenen und vergangenheitsbezogenen Informationen. Letztere berücksichtigen die Autoren in Form von Historien (siehe Tab. 7, S. 25).
25
Kategorie
Element
Fragestellung
Wie
Aktionshistorie
Wie wurde die Aktion ausgeführt?
Artefakthistorie
Welche Änderungen wurden am Artefakt durchgeführt?
Wann
Ereignishistorie
Wann trat ein Ereignis auf?
Wer
Anwesenheitshistorie
Wer war im Workspace wann aktiv?
Wo
Ortshistorie
An welchen Orten war eine Person?
Was
Aktionshistorie
Was für Aktionen und Änderungen hat eine Person im
Workspace durchgeführt?
Tabelle 7 - Vergangenheitsbezogene Elemente von Workspace Awareness
(in Anlehnung an [Gutwin/Greenberg 2002], S. 422)
Als Quellen für die Bereitstellung von Workspace-Awareness-Informationen identifizieren sie im zweiten Teilabschnitt ihres Frameworks:
ƒ „consequential communication“ (d. h. der nicht explizit gesteuerte Informationsfluss durch Sehen und Hören Anderer im gemeinsamen Arbeitsumfeld) (vgl. [Gutwin/Greenberg 2002], S. 422f.)
ƒ „feedthrough“ (d. h. Informationen, die beim Bearbeiten von Artefakten erzeugt
werden) (vgl. [Gutwin/Greenberg 2002], S. 423f.)
ƒ „intentional communication“ (d. h. Informationen auf Basis von Konversation und
Gestik Anderer im gemeinsamen Arbeitsumfeld) (vgl. [Gutwin/Greenberg 2002],
S. 424f.).
Das Unterstützungspotential für kooperative Arbeiten durch Berücksichtigung von
Workspace Awareness stellen Gutwin und Greenberg im letzten Teilabschnitt ihres
Frameworks anhand von fünf Szenarien dar (siehe Tab. 8, S. 26).
26
Szenario
Ziel
„management of coupling“
Effektivere Wechsel zwischen individueller
und kooperativer Arbeit
„simplification of communication“
Verbesserte Kommunikation durch Miteinbeziehung des Workspaces und der darin
enthaltenen Artefakte
„coordination of actions“
Vereinfachte Koordinierung von Tätigkeiten
„anticipation“
Verringertes Konfliktpotential aufgrund Antizipation der Tätigkeiten anderer Personen
„assistance“
Unterstützung bei Tätigkeiten ohne vorherige
explizite Aufforderung dazu
Tabelle 8 - Unterstützungspotential durch Workspace Awareness
(vgl. [Gutwin/Greenberg 2002], S. 425ff; [Gutwin/Greenberg 2004], S. 186ff.)
Mit ihrem konzeptionellen Framework verfolgen Gutwin und Greenberg das Ziel, Entwickler bei der Berücksichtigung von Awareness in Groupware-Applikationen zu unterstützen (vgl. [Gutwin/Greenberg 2002], S. 441).
2.2.5.2 Place-based Presence
Ter Hofte et al. untersuchen im Rahmen ihrer Forschungstätigkeit am „Telematica
Instituut“ in Enschede die Auswirkungen des Einsatzes von „presence applications“ wie
z. B. Instant Messaging (IM) am Arbeitsplatz (vgl. [ter Hofte et al. 2002], S. 10).
Dabei gehen sie der Frage nach, inwieweit derartige Anwendungen mehr Informationen
aus dem Arbeitsplatzkontext adaptieren könnten, so dass nicht nur personenzentrierte
Fragestellungen wie „Wer ist online?“, sondern auch platzorientierte Fragestellungen
wie „Wer ist in der Nähe?“ beantwortet werden können (vgl. [ter Hofte et al. 2002], S.
5). Unter „Nähe“ fassen ter Hofte et al. in diesem Zusammenhang nicht die reale, räumliche Nähe mehrerer Personen zueinander auf, sondern vielmehr eine virtuelle Nähe, die
über den Arbeitskontext bestimmt ist.
Zunächst betonen sie in ihrem Bericht die Bedeutung von IM (vgl. [ter Hofte et al.
2002], S. 9f.) und erläutern dessen Verwendung (vgl. [ter Hofte et al. 2002], S. 11).
Anschließend kritisieren sie die Ausgestaltung von IM-Systemen auf Basis von Beobachtungen bezüglich des Unterstützungspotentials für kollaborative Arbeit in
mehreren Punkten.
27
Einer dieser Kritikpunkte bildet das so genannte „trust model“ von IM-Systemen (beide
Anwender müssen gegenseitig dem Hinzufügen zur Kontaktliste des Anderen zustimmen). Ter Hofte et al. stellen hierbei die Problematik fest, dass es keine projektgebundenen Differenzierungsmöglichkeiten gibt. Das bedeutet, dass wenn ein Anwender „online“ ist, dies alle Personen auf der Kontaktliste des Anwenders sehen
können und nicht nur beispielsweise der Personenkreis, der auch in dem Projekt involviert ist, an dem der betreffende Anwender gerade arbeitet (vgl. [ter Hofte et al.
2002], S.15).
Einen weiteren Kritikpunkt bilden Status-Informationen wie „online“, „offline“, „busy“,
„away“ oder auch „out-to-lunch“, die ungeeignet wären, um die Erreichbarkeit bei
dienstlicher Verwendung von IM zu charakterisieren (vgl. [ter Hofte et al. 2002], S. 15).
Daher stellen ter Hofte et. al das folgende Konzept für eine sog. „place-based presence“
auf:
„We set out to explore presence mechanisms that allow exchange of presence information with a certain subset of one’s buddies (e.g., a particular project team
from work) not always, but only sometimes, depending on context. In particular,
we focused on context information that can be derived from the virtual places
people visit during their work (such as websites, files on shared network drives,
etc.), which gives rise to a new model for presence information we coined placebased presence.” ([ter Hofte et al. 2002], S. 15)
Im Rahmen ihres Modells unterscheiden ter Hofte et al. hinsichtlich des „trust models“
vier Aspekte mit verschiedenen Ausprägungen (siehe Tab. 9, S. 28).
28
Kriterium
Beschreibung
opt-in
Eigene Status-Informationen sind für andere Personen erst nach expliziter
Freigabe sichtbar
opt-out
Eigene Status-Informationen sind für andere Personen immer sichtbar,
außer bei expliziter Einschränkung
fixed
Der System Administrator entscheidet anstelle des Endbenutzers über die
Sichtbarkeit der Status-Informationen
bilateral
Für jede einzelne Person können gegenseitig Rechte vergeben bzw.
entzogen werden
group-wise
Die Rechteregelung ist gruppenbezogen
reciprocal
Wenn eine Person (bzw. Gruppe) die Status-Informationen eines Anwenders sehen kann, dann kann dieser im Gegenzug auch die StatusInformationen der betreffenden Person (bzw. aller Gruppenmitglieder)
sehen
non-reciprocal
Eine zwangsläufige gegenseitige Sichtbarkeit der Status-Informationen ist
nicht gegeben
permanent
Berechtigungen werden permanent gewährt oder entzogen
blockable
Berechtigungen können temporär blockiert werden
place-based
Berechtigungen werden auf Basis virtueller Plätze vergeben
Tabelle 9 - Aspekte im „trust model“ von IM-Systemen
(in Anlehnung an [ter Hofte et al. 2002], S. 17f.)
Zusätzlich zum „trust model“ berücksichtigen ter Hofte et al. in ihrem Ansatz auch die
virtuelle Nähe der Personen zueinander. Dabei könne die virtuelle Distanz zwischen
Personen mittels der Verwendung von Graphen, kartesischen Koordinatensystemen
oder topologischen Räumen bestimmt werden. Über Letztere ließe sich nach ter Hofte et
al. eine Hierarchie virtueller Räume schaffen (vgl. [ter Hofte et al. 2002], S. 18f.).
Beispielsweise wäre die URL „http://www.microsoft.com/net/whatis.asp“ in dem virtuellen Raum der URL „http://www.microsoft.com/net/“ enthalten, und diese wiederum in
dem virtuellen Raum von „http://www.microsoft.com/“ (vgl. [ter Hofte et al. 2002], S.
19).
Des Weiteren berücksichtigen ter Hofte et al. Sichtbarkeiten und unterscheiden hierbei
in Anlehnung an das Focus/Nimbus-Modell von Benford und Fahlén (vgl. [Benford/Fahlén 1993]) „presence scope“ und „awareness scope“.
29
Der presence scope (ähnlich dem Nimbus im Modell nach Benford und Fahlén) beschreibt die virtuelle Distanz, in der die „presence information“ eines Anwenders für
andere Personen sichtbar ist (vgl. [ter Hofte et al. 2002], S. 19).
Der awareness scope (ähnlich dem Focus im Modell nach Benford und Fahlén) beschreibt dagegen die virtuelle Distanz, in der für einen Anwender die „presence information“ anderer „trusted user“ sichtbar ist (vgl. [ter Hofte et al. 2002], S. 19).
Da beide Beschreibungen und der Begriff „virtuelle Distanz“ sehr abstrakt sind, soll
anhand eines Beispiels aus der Realwelt verdeutlicht werden, was gemeint ist:
Wenn sich in einem erleuchteten und einem abgedunkelten Raum – die über ein kleines
Sichtfenster verbunden sind – jeweils eine Person pro Raum befindet und die Frage
beantwortet werden soll, ob sich die Personen gegenseitig sehen können, kann diese
Frage durch das Modell überprüft werden. Der presence scope, d. h. inwieweit ist die
eine Person für die andere Person wahrnehmbar, und der awareness scope, d. h. inwieweit kann jemand den Raum einsehen und andere Personen wahrnehmen, wird
durch die Tatsache beeinflusst, dass ein Raum abgedunkelt (Raum mit Person A) und
der andere erleuchtet (Raum mit Person B) ist. Der presence scope von B ist durch das
Sichtfenster größer als der Raum von B selbst. Gleichzeitig befindet sich der Raum von
B auch im awarness scope – Wahrnehmungsbereich – von A und daher ist B für A
sichtbar. Auf der anderen Seite ist der presence scope von A durch den abgedunkelten
Raum minimal und daher kann B aufgrund einer fehlenden Überlagerung von presence
und awareness scope A nicht sehen.
In einem place-based presence System nach ter Hofte et al. wird ein Anwender B daher
nur auf der Kontaktliste eines Anwenders A gelistet, wenn die folgenden formalen
Bedingungen erfüllt sind (vgl. [ter Hofte et al. 2002], S. 20):
ƒ B erlaubt A seine presence information zu sehen
ƒ Der virtuelle Aufenthaltsort von A liegt im presence scope von B
ƒ Der virtuelle Aufenthaltsort von B liegt im awareness scope von A
In der folgenden Abbildung ist diese Beispielkonstellation dargestellt. Dabei bedeutet
„in Reichweite“ in der Legende, dass ein Anwender sich im awareness scope eines
anderen Anwenders (A) befindet und „trusted“ bzw. „untrusted“, ob zwischen Anwender A und dem jeweiligen Akteuer ein „trust model“ existiert.
30
Legende:
in Reichweite + „trusted“
außer Reichweite + „trusted“
„untrusted“
A
B
presence scope
awareness scope
Abbildung 5 - Presence scope und awareness scope
(in Anlehnung an [ter Hofte/Mulder/Verwijs 2005], S. 161)
Auf Basis ihrer konzeptionellen Arbeit entwickelten ter Hofte et al. einen Prototyp
(„CoCoBrowse“), der als Erweiterung für den Microsoft Internet Explorer eine Liste der
Personen liefert, die gemeinsam zeitgleich eine Website bzw. URL besuchen.
Auf der folgenden Abbildung eines Screenshots besuchen Livia, Martin und Christina
parallel eine bestimmte URL.
Abbildung 6 - Screenshot CoCoBrowse (vgl. [ter Hofte/Mulder/Verwijs 2005], S. 162)
Alle drei Personen sind für den aktuellen Anwender, der die gleiche URL aufgerufen
hat, sichtbar. Zudem liefert der Prototyp weitere Informationen: Beispielsweise ist nur
bei Christina das Browserfenster aktuell im Fokus (Brillen-Symbol). Livia und Martin
fokussieren das Browserfenster dagegen momentan nicht, d. h. das Fenster befindet sich
nicht im Vordergrund ihres Desktops. Des Weiteren hält Livia auf die Website eine
Sperre (Schloss-Symbol). Letzteres ist möglich, da die Website im Beispiel auf dem
31
Standard WebDAV (Web-based Distributed Authoring and Versioning) basiert, der es
als Erweiterung des HTTP-Protokolls u. a. gestattet, Dokumente auf einem Web-Server
zu sperren (vgl. [Jehøj/Bouvin/Grønbæk 2005], S. 181).
Anhand der Studienergebnisse von zwei Versionen ihres Prototyps „CoCoBrowse“
kommen ter Hofte et al. zu folgendem Fazit (vgl. [ter Hofte et al. 2002], S. 29):
ƒ Place-based presence Anwendungen sollten als Erweiterung existierender „Presence and Instant Messaging“-Systeme entwickelt werden.
ƒ Der Start einer Place-based-Presence-Anwendung sowie die Bereitstellung von
„presence information“ sollten nur einen minimalen Aufwand für den Nutzer erfordern.
ƒ Der Geltungsbereich eines virtuellen Platzes sollte dahingehend erweitert werden,
dass nicht nur die Nutzer aufgelistet werden, die exakt die gleiche URL aufgerufen
haben.
32
3 Konzept für Place-based Awareness in kollaborativen Arbeitsumgebungen
3.1 Ziel
In den vorangegangenen Kapiteln wurden die Grundlagen kollaborativer Arbeitsumgebungen und der Bereich Awareness im Rahmen der CSCW-Forschung vorgestellt.
Dazu wurde neben der Abgrenzung des Begriffs Awareness der Bereitstellungsprozess
von Awareness-Informationen erläutert sowie Chancen und Risiken eines AwarenessSystems diskutiert.
Auf Basis des Workspace-Awareness-Frameworks nach Gutwin und Greenberg und des
Place-based-Presence-Konzepts nach ter Hofte et al. wird in den folgenden Unterkapiteln ein neues Awareness-Modell vorgestellt. Dabei werden zwei Ziele verfolgt:
Einerseits soll eine Wahrnehmung der Präsenz und Aktivitäten von Akteuren untereinander geschaffen werden, die einen direkten gemeinsamen Arbeitskontext haben, d.
h. die beispielsweise parallel an einem Dokument arbeiten oder Mitglieder einer bestimmten Gruppe sind. Andererseits soll auch Awareness zwischen Akteuren vermittelt
werden, zwischen denen keine direkte Beziehung über ihre Aktivitäten oder Gruppenangehörigkeit besteht. Diese Personen arbeiten somit nur indirekt kooperativ zusammen. Ein Beispiel hierfür wären zwei Sachbearbeiter einer Versicherung, die an
zwei verschiedenen Versicherungsfällen derselben Person arbeiten.
Über diese Zielsetzung wird ein Aspekt des Fazits der Studienergebnisse von ter Hofte
et al. im Rahmen ihres Prototypen „CoCoBrowse“ aufgegriffen (siehe Kapitel 2.2.5.2):
Die Grenzen eines virtuellen Bereichs, in dem Awareness über die anwesenden Akteure
und ihre Tätigkeiten geschaffen wird, sollten nach Möglichkeit nicht derart fixiert und
unflexibel definiert sein, dass relevante Elemente einer tieferen oder höheren Abstraktionsebene nicht berücksichtigt werden bzw. werden können.
Eine spezielle Zielsetzung bei dem Entwurf des Awareness-Modells ist es daher nicht
nur bei einer vorliegenden direkten Beziehung Awareness-Informationen zugänglich zu
machen, sondern auch indirekte Abhängigkeiten strukturiert darstellen zu können.
Die beiden weiteren Studienergebnisse von ter Hofte et al. – Applikationsentwicklung
auf Basis existierender Systeme sowie minimaler Aufwand für Bereitstellung von Awa-
33
reness-Informationen für die Anwender – sollen bei der Konzeption des Modells ebenfalls als Leitgedanken berücksichtigt werden.
3.2 Das Modell Place-based Awareness
In Kapitel 2.2 wurde bereits die Bedeutung von Awareness für die kooperative Zusammenarbeit in Groupware-Systemen herausgearbeitet. Während in face-to-faceSituationen, in denen die beteiligten Personen an physisch benachbarten Arbeitsplätzen
tätig sind, eine Kollaboration effektiv und effizient erfolgen kann, sind bei Einsatz von
Groupware die beteiligten Akteure oft räumlich von einander getrennt. Zudem arbeiten
die Akteure nicht zwangsläufig parallel, so dass zusätzlich eine zeitliche Distanz zu
überwinden ist. Awareness-Systeme unterstützen in diesem Zusammenhang die beteiligten Akteure durch Bereitstellung von Awareness-Informationen bei der gegenseitigen Wahrnehmung von Präsenz und Aktivitäten.
In Bezug auf den Entwurf von Awareness-Systemen und -Architekturen werden an
dieser Stelle zwei abstrakte Modelltypen vorgestellt, die im Kontext von Awareness
diskutiert werden. Dabei handelt es sich um raumbasierte und ereignisbasierte Modelle
(vgl. [Prinz 2001], S. 338ff.).
In raumbasierten Modellen wie z. B. dem Fokus/Nimbus-Modell nach Benford und
Fahlén kann den Interaktionen bzw. Beziehungen zwischen Objekten eine räumliche
Metrik zugrunde gelegt werden; beispielsweise über die Bestimmung von Orientierungen und Distanzen (vgl. [Benford/Fahlén 1993], S. 109f.). Eine Anwendung dieses
abstrakten Modelltyps findet sich im Modell Place-based Presence von ter Hofte et al.
(vgl. [ter Hofte et al. 2002]) und eine Erweiterung im Awareness-Modell nach Rodden
(vgl. [Rodden 1996]).
In einem ereignisbasiertem Modell führt die Ausführung von Aktionen auf Datenobjekten zur Erzeugung von Ereignissen, die über die Relationen zwischen den
Objekten weitergeleitet werden (vgl. [Prinz 2001], S. 338). Ein ereignisbasiertes Modell
stellt beispielsweise das GroupDesk-Modell nach Fuchs, Pankoke-Babatz und Prinz dar
(vgl. [Fuchs/Pankoke-Babatz/Prinz 1995]) und eine Anwendung bildet der POLITeam
Awareness Client (POLIAwaC) im Rahmen des Projekts POLITeam (vgl. [Sohlenkamp/Prinz/Fuchs 2000]).
Das im Rahmen dieser Arbeit entwickelte Modell Place-based Awareness enthält sowohl Aspekte eines raumbasierten als auch eines ereignisbasierten Modells.
34
3.2.1 Place-based Awareness als raumbasiertes Modell
Im Rahmen von CSCW-Anwendungen werden Metaphern eingesetzt, um die Funktionalitäten der Anwendungen verständlicher und anschaulicher darstellen zu können (vgl.
[Fuchs 1998], S. 40). Eine Gruppe bilden dabei die räumlichen Metaphern, die über das
Konzept der räumlichen Nähe elektronische Arbeitskontexte abbilden (vgl. [Fuchs
1998], S. 42). Mittels einer Raummetapher kann der gemeinsame virtuelle Arbeitsbereich beispielsweise in Gebäude, Räume und Tische gegliedert werden. AwarenessInformationen können dann in Abhängigkeit davon präsentiert werden, ob sich Anwender im gleichen virtuellen Raum befinden oder am selben virtuellen Tisch arbeiten.
Ein Beispiel, das auf diesem Konzept beruht, bildet der Prototyp DIVA einer virtuellen
Büroumgebung von Sohlenkamp und Chwelos (vgl. [Sohlenkamp/Chwelos 1994],
[Berlage/Sohlenkamp 1999]).
Im Rahmen dieser Arbeit wird anstelle der Raum- eine Platzmetapher verwendet, da die
Metapher eines Raums implizit suggeriert, dass Türen und Raumgrenzen existieren. Im
Rahmen von Place-based Awareness soll ein Place aber weder nur durch vordefinierte
Türen oder Kanäle betreten oder verlassen werden können, noch durch vordefinierte
Grenzen hinsichtlich seiner Ausdehnung fixiert sein.
Stattdessen soll im Hinblick auf Place-based Awareness als Modell ein Place zunächst
eine kontextspezifische Gliederungsebene für Informationsobjekte bzw. Artefakte bieten. Das bedeutet, dass Informationsobjekte über einen Place strukturiert werden können
ähnlich einer Ordnerstruktur eines Dateisystems (siehe Abb. 7). Es können dabei beliebig viele Informationsobjekte in einem Place erfasst sein und es können sowohl neue
Artefakte hinzugefügt als auch vorhandene entfernt werden.
Artefakt
Artefakt
Place
Artefakt
Artefakt
Artefakt
Abbildung 7 - Place-Modell von Place-based Awareness (im engeren Sinn)
35
Die Place-Artefakt-Beziehungen bilden die Grundlage des Modells. Das Ziel von Placebased Awareness ist es allerdings weniger die Strukturen und Abhängigkeiten zwischen
Places und Artefakten abzubilden, sondern stattdessen die Aktionen von Anwendern auf
den Informationsobjekten zu einem bestimmten Zeitpunkt darzustellen.
Fuchs, Pankoke-Babatz und Prinz berücksichtigen beim Entwurf ihres GroupDeskModells einer Arbeitsumgebung eine Repräsentation des Arbeitskontextes als semantisches Netz (vgl. [Fuchs/Pankoke-Babatz/Prinz 1995]). Dabei bilden Artefakte, Anwender und organisatorische Entitäten wie z. B. Departments oder Rollen die Knoten
des Netzes. Die Kanten stellen die Relationen zwischen diesen Objekten dar und beschreiben beispielsweise Gemeinsamkeiten zwischen Artefakten oder aktuell stattfindende Aktivitäten in der Arbeitsumgebung. Dieses Netz wird somit durch die
normalen Interaktionen von Benutzern mit dem System geformt und fortlaufend modifiziert (vgl. [Fuchs/Pankoke-Babatz/Prinz 1995], S. 248).
Dieser Ansatz wird im Rahmen dieser Arbeit im Modell Place-based Awareness ebenfalls verwendet. Allerdings wird auf die Miteinbeziehung von organisatorischen Entitäten verzichtet. Darüber hinaus existieren im semantischen Netz von Place-based Awareness als zentrale Knotenpunkte Places (siehe Abb. 8).
Artefakt
Artefakt
Artefakt
Artefakt
Place
Artefakt
Artefakt
Place
Artefakt
Artefakt
Artefakt
Place
Artefakt
Artefakt
Artefakt
Abbildung 8 - Place-Modell von Place-based Awareness (im weiteren Sinn)
Artefakt
36
Während das Modell Place-based Awareness im engeren Sinn nur eine Gliederungsebene für Artefakte darstellt, beinhaltet es im weiteren Sinn auch die Aktionen von
Akteuren auf Artefakten. Der Zweck von Place-based Awareness ist weniger, die Frage
nach der Zusammenstellung von Artefakten in einem Place zu beantworten. Vielmehr
stehen Fragestellungen in Bezug auf die Aktionen von Anwendern im Kontext eines
Place zu einem bestimmten Zeitpunkt im Fokus des Interesses.
Das Modell beinhaltet somit als statischen Aspekt die Strukturierung von Artefakten in
Places und als dynamischen Aspekt die wechselnden Aktionen von Anwendern im
Kontext eines Place. Im Zentrum der Betrachtung letzterer Sichtweise steht hinsichtlich
der Anwender-Place-Beziehungen allerdings weniger das Artefakt, sondern vielmehr
eine konkrete Aktion (siehe Abb. 9).
Artefakt
Artefakt
Artefakt
Aktion
Aktion
Aktion
Place
Place
Place
Aktion
Artefakt
Aktion
Artefakt
Aktion
Aktion
Aktion
Artefakt
Abbildung 9 - Place-Modell von Place-based Awareness (dynamischer Aspekt)
Ein Artefakt kann zwar an einer Aktion beteiligt sein, aber eine Aktion kann auch unabhängig von Artefakten existieren. In diesem Fall übt ein Anwender im System eine
Aktivität aus, die nicht an ein bestimmtes Informationsobjekt gebunden ist. Des Weiteren kann ein Artefakt zeitgleich mehreren Aktionen zugeordnet sein, beispielsweise
wenn mehrere Personen parallel ein Dokument editieren.
37
Place-based Awareness lässt sich als raumbasiertes Modell zusammengefasst daher aus
zwei Sichten betrachten:
ƒ Ohne Einbeziehung von Anwendern stellt das Modell eine Gliederungsebene für
Artefakte in Places dar.
ƒ Unter Berücksichtigung von Anwendern stellt das Modell die von ihnen durchgeführten Aktionen im Kontext zugeordneter Places dar.
3.2.2 Place-based Awareness als ereignisbasiertes, hierarchisches
Modell
Das Modell Place-based Awareness beinhaltet auch Aspekte eines ereignisbasierten
Modells (siehe Abb. 10). Die Aktionen eines Anwenders in einem System lösen interne
Ereignisse aus und verursachen Zustandsänderungen. Durch die Visualisierung dieser
Informationen kann im Rahmen kooperativer Arbeit Awareness ermöglicht werden.
Beispielsweise kann nach dem Editieren das abschließende Speichern eines Dokuments
in einer Groupware-Anwendung ein Save-Event auslösen.
Ziel
A
führt
zu
Plan
führt
zu
Verteiltes
System
Aktion
erzeugt
zeigt
erzeugt
Zustand
beeinflusst
beeinflusst
Zustandsänderung
beschreibt
Ereignis
zeigt
löst
aus
Wahrnehmung
B
ermöglicht
ermöglicht
Visualisierung
Awareness
Abbildung 10 - Ereignisbasierte Awareness-Erzeugung (in Anlehnung an [Berlage/Sohlenkamp 1999], S. 221)
Im Rahmen von Place-based Awareness erfolgt die Verbreitung von Events über die
zentralen Place-Knoten. Allerdings können an der Weiterleitung von Ereignissen mehrere Place-Knoten beteiligt sein. Dies resultiert aus der Tatsache, dass Place-based
Awareness zusätzlich einem hierarchischen Modell zugrunde liegt und daher Be-
38
ziehungen zwischen einzelnen Places existieren können. Es gelten die folgenden
Regeln:
ƒ Jeder Place kann mit maximal einem übergeordneten Place verbunden sein.
ƒ Jeder Place kann mit mehreren untergeordneten Places verbunden sein.
Durch die Wahl der beschriebenen Place-Struktur können zum einen hierarchische
Beziehungen im Modell berücksichtigt werden und zum anderen die Aktionen von
Anwendern auf unterschiedlichen Abstraktionsebenen dargestellt werden.
Hierarchische Strukturen bzw. Abhängigkeitsbeziehungen können beispielsweise im
Kontext von Place-based Awareness vorliegen, wenn sowohl mit einer Anwendung als
auch mit einer oder mehreren ihrer Teilanwendungen gearbeitet wird. Die Aktionen
eines Nutzers in den Teilanwendungen würden somit in Places stattfinden, denen ein
Place für die Aktivitäten in der zentralen Anwendung übergeordnet ist.
Neben einer Strukturierung der eingesetzten Systeme lässt sich über das Modell auch
eine Gliederung der Tätigkeiten von Systemnutzern im Rahmen eines Aufgabenspektrums abbilden. Aktionen, die im Zusammenhang einer Teilaufgabe ausgeführt
werden, finden analog im Kontext eines Place statt, der einem anderen Place untergeordnet ist. Der übergeordnete Place beinhaltet dementsprechend die Aktionen der
Hauptaufgabe.
Die hierarchische Struktur ermöglicht es zudem, die über Aktionen in einem Place
ausgelösten Ereignisse an alle unter- bzw. übergeordneten Places oder auch an alle
Places auf der gleichen Hierarchieebene weiterzuleiten. Im Rahmen von Place-based
Awareness werden Events allerdings nur an übergeordnete Places übermittelt. Dadurch
können die Aktionen aus untergeordneten Places auch in übergeordneten Places abgebildet werden.
39
hoch
niedrig
niedrig
hoch
Potentielle
Mitgliederzahl
Potentieller Bedarf
an Kollaboration
Place
1
Place
11
Place
111
Place
12
Place
112
Abbildung 11 - Konzept der Place-Hierarchie
Das Abbilden von Aktionen aus untergeordneten Places in übergeordneten Places führt
im Rahmen von Place-based Awareness dazu, dass sich die Place-Mitglieder jeweils aus
den Mitgliedern des betreffenden Place und den Mitgliedern aller untergeordneter Places zusammensetzen. Ein Place-Mitglied ist hierbei ein Anwender, der zu dem gegebenen Zeitpunkt mindestens eine Aktion in dem Place ausführt. Die potentielle Mitgliederzahl eines Place ist auf Basis dieses Konzepts daher größer, je höher die
Hierarchieebene des Place ist (siehe Abb. 11).
Bezüglich der Abbildung von Aktionen und Akteuren in übergeordneten Places ist
allerdings anzumerken, dass diese Miteinbeziehung durch einen geringeren Detaillierungsgrad gekennzeichnet ist. Das bedeutet, dass nicht alle Informationsbestandteile
einer Aktion aus einem untergeordneten Place auch in einem übergeordneten Place
berücksichtigt werden. Dadurch soll eine Informationsüberladung der Mitglieder dieses
Place vermieden werden. Während die genauen Details einer Aktion nur im Kontext des
direkt zugeordneten Place ersichtlich sind, wird in den übergeordneten Places – abgesehen von den hier zugehörigen Aktionen – nur ein undetaillierter Überblick über die
Aktionen der untergeordneten Places gegeben.
40
Orthogonal zu der potentiellen Mitgliederzahl eines Place verhält sich der potentielle
Kollaborationsbedarf der Place-Mitglieder (siehe Abb. 11, S. 39).
Places auf höheren Hierarchieebenen bilden in erster Linie lediglich die allgemeine
Systemumgebung bzw. die ausgeführte Aktion auf einem abstrakten Level ab. Der
Zweck übergeordneter Places liegt darin, eine Übersicht über den Kontext bzw. das
Umfeld zu geben, in dem speziellere Aktionen untergeordneter Places stattfinden und
die betreffenden Aktionen in abstrakterer Form für andere Place-Mitglieder darzustellen. Je höher die Hierarchieebene desto genereller bzw. allgemeiner ist der Charakter
des betreffenden Place.
Die Places auf den unteren Hierarchieebenen sind dagegen durch sehr spezielle Aufgaben und Tätigkeiten der Mitglieder gekennzeichnet. Sobald in diesen Places Aktivitäten im Rahmen kooperativer Arbeit ausgeübt werden, entsteht ein erhöhter
Kollaborationsbedarf und die Bereitstellung von Awareness-Informationen wird zu
einem entscheidenden Faktor für den Erfolg der Zusammenarbeit.
Abschließend wird das Hierarchiekonzept von Place-based Awareness anhand eines
Beispiels erläutert.
Wenn ein Sachbearbeiter A einer Versicherung einen Schadensfall im Rahmen eines
größeren Versicherungsfalls mit Computerunterstützung über ein spezielles Versicherungssystem bearbeitet, sind im Kontext dieser Aktion drei Places denkbar:
ƒ Place „Versicherungssystem X“
(obere Hierarchieebene)
ƒ Place „Versicherungsfall Y“
(mittlere Hierarchieebene)
ƒ Place „Schadensfall Z“
(untere Hierarchieebene)
Eine Aktion im Kontext des „Schadensfall Z“ führt dazu, dass auch die Places der
übergeordneten Ebenen betreten werden. Der Detaillierungsgrad der AwarenessInformationen ist auf der Ebene des Schadensfalls am höchsten. Dagegen würde auf der
Ebene des Versicherungsfalls nur ein eingeschränktes Informationsspektrum abgebildet
werden. Für andere Sachbearbeiter im Place „Versicherungsfall Y“ würde somit beispielsweise nur dargestellt werden, dass Sachbearbeiter A zu dem Zeitpunkt an dem
Schadensfall Z arbeitet, ohne die genauen Details dieser Aktion abzubilden.
Noch abstrakter würde der Detaillierungsgrad im Place „Versicherungssystem X“ aussehen. Im Kontext dieses Place würde es für andere Mitglieder beispielsweise nur er-
41
kennbar sein, dass Sachbearbeiter A gerade aktiv ist und an irgendeinem – nicht näher
spezifizierten – Versicherungsfall arbeitet.
3.2.3 Zusammenfassung
Das Modell Place-based Awareness beinhaltet sowohl Aspekte raumbasierter Modelle
als auch ereignisbasierter Modelle. Als raumbasiertes Modell werden zunächst Artefakte bzw. Informationsobjekte kontextbezogen gegliedert und mit Hilfe von Places
strukturiert. Bei Einbeziehung von Akteuren stehen deren Aktionen bzw. artefaktgebundene Aktionen im Hinblick auf einen zugeordneten Place im Fokus der Betrachtung.
Die folgende Abbildung stellt die Entitäten und Relationen dieses Sachverhalts als
Entity-Relationship-Modell (ERM) dar. Für die Kardinalitäten wurde die UMLNotation gewählt.
Place
(übergeordnet)
0..1
hat
0..*
Mitgliedschaft
0..*
gehört zu
1..1
Place
1..*
1..1
gehört zu
beinhaltet
1..1
0..*
Mitglied
führt aus
1..1
0..*
Aktion
beinhaltet
0..*
0..*
gehört zu
0..*
0..1
Artefakt
Abbildung 12 - Place-based Awareness als Entity-Relationship-Modell
Die dunkelgrau markierten Elemente in der Abbildung 12 stellen die permanenten
Entitäten und Relationen des Modells dar. Der bisher unberücksichtigte Aspekt einer
„Mitgliedschaft“ wird in Kapitel 3.5.2 näher erläutert. Das Gesamtmodell von Placebased Awareness berücksichtigt zusätzlich Anwender bzw. Place-Mitglieder und ihre
Aktionen. Letztere Elemente sind im ERM hellgrau markiert.
42
Die hierarchische Struktur der Places ist in Bezug auf eine ereignisbasierte Betrachtung
des Modells von Bedeutung. Die im Kontext eines Place erzeugten Ereignisse können
zum einen über andere Places weitergeleitet werden und zum anderen auch Einfluss auf
die Bereitstellung von Awareness-Informationen anderer Places haben. Eine Aktion in
einem Place hat beispielsweise auch Konsequenzen auf übergeordnete Places, in denen
die generierte Awareness-Information der betreffenden Aktion in einem niedrigeren
Detaillierungsgrad ergänzt und dargestellt werden kann.
Durch das hierarchische Konzept von Place-based Awareness wird ein zentraler Aspekt
aus dem Fazit von ter Hofte et al. in Zusammenhang mit den Studienergebnissen ihres
Prototyps berücksichtigt. Ter Hofte et al. fordern, bei dem Entwurf von AwarenessSystemen die Grenzen des Geltungsbereichs eines virtuellen Platzes nicht zu eng zu
wählen (siehe Kapitel 2.2.5.2).
Diesbezüglich wird im Rahmen von Place-based Awareness über die hierarchische
Struktur der Places sichergestellt, dass Awareness-Informationen auf unterschiedlichen
Abstraktionsebenen in einem jeweils angepassten Detaillierungsgrad verschiedenen
Anwendern zugänglich gemacht werden können. Akteure, die an sehr ähnlichen Aufgaben arbeiten, agieren in den gleichen Places und können ihre kooperative Arbeit auf
Basis der bereitgestellten Awareness-Informationen besser koordinieren. Im Gegenzug
profitieren Akteure, die nur indirekt an vergleichbaren Aufgaben arbeiten, durch die
Bereitstellung von weniger detaillierten Awareness-Informationen im Rahmen eines
Place auf einer höheren Hierarchieebene.
Die folgende Definition für Place-based Awareness bildet eine Erweiterung der Awareness-Definition aus dem Grundlagenkapitel (siehe Kapitel 2.2.2):
Place-based Awareness beschreibt die Wahrnehmung der Präsenz und Aktivitäten
von Akteuren in einem direkten bzw. indirekten gemeinsamen Arbeitskontext im
Rahmen kooperativer Arbeit.
Place-based Awareness ermöglicht einem Akteur somit die Anwesenheit und Tätigkeiten anderer Personen als auch dadurch betroffene Informationsobjekte wahrzunehmen. Ein Place repräsentiert im Zusammenhang mit der Definition den indirekten
gemeinsamen Arbeitskontext mehrerer Personen (siehe Abb. 13, S. 43).
43
Place-based Awareness
Aktion
Aktion
Artefakt
Place
Indirekter gemeinsamer
Arbeitskontext
Abbildung 13 - Konzept von Place-based Awareness
3.3 Anforderungen an eine Architektur für Place-based Awareness
Nachdem im vorangegangenen Kapitel 3.2 das Modell Place-based Awareness vorgestellt wurde, werden in diesem Kapitel Anforderungen an eine Realisierung des
Modells spezifiziert. Die Anforderungsanalyse bildet die erste Phase im Hinblick auf
den Prozess zum Entwurf eines Architekturmodells (vgl. [Posch/Birken/Gerdom 2004],
S. 57ff.). Dabei werden im Rahmen dieser Arbeit organisatorische, funktionale und
technische Anforderungen unterschieden und formuliert.
3.3.1 Organisatorische Sicht
Vertrauen
In Bezug auf die Bedeutung von Vertrauen auf die virtuelle Teamarbeit schreibt Senst:
„Vertrauen ist die Grundlage aller Teamarbeit. Kann ein Team kein Vertrauen
aufbauen, werden die Mitglieder weniger offen, weniger engagiert und weniger
kooperativ zusammenarbeiten.“ ([Senst 2001], S. 85)
Auch Isermann sieht in dem Vertrauen der Teammitglieder untereinander einen zentralen Erfolgsfaktor für virtuelle Teamarbeit (vgl. [Isermann 2004], S. 77). Im Hinblick auf
44
die Gestaltung eines Awareness-Systems kann der Aspekt Vertrauen aus mehren Sichten betrachtet werden:
ƒ Vertrauen als Grundlage
Bei der Einführung eines Awareness-Systems ist das Vertrauen der Anwender in
die korrekte Funktionsweise Basis für die Akzeptanz des Systems.
ƒ Vertrauensbewahrung
Furcht vor gegenseitiger Überwachung und Kontrolle in einem Awareness-System
kann die Vertrauensbasis der Kooperationspartner negativ beeinträchtigen.
ƒ Vertrauensbildung als Ziel
Die Schaffung von Vertrauen untereinander durch Bereitstellung von Informationen
über Anwesenheit und Tätigkeiten ist im Gegenzug ein Teilziel eines AwarenessSystems.
Wechsel der Kooperationspartner
Ein Awareness-System sollte Wiedereinsteigern bzw. Neueinsteigern in einer Gruppe
oder einem Team die Teilnahme an existierenden Kooperationsbeziehungen erleichtern.
Dazu sollten nicht nur aktuelle und vergangene Aktivitäten in einem Place benutzerspezifisch dargestellt werden, sondern auch Informationen über die beteiligten Akteure
vermittelt werden, um ein umfassendes Bild des zeitbezogenen Stands der kooperativen
Arbeit zu bieten.
Keine Arbeitsunterbrechung
Im Rahmen seiner individuellen Arbeit sollte der Nutzer eines Awareness-Systems
weder behindert noch eingeschränkt werden. Bei der Erzeugung von AwarenessInformationen sollte daher ein automatisiertes Verfahren angewendet werden. Dadurch
kann zum einen die zeitnahe Verteilung der Awareness-Informationen gewährleistet
werden. Zusätzlich wird aber auch sichergestellt, dass alle Beteiligten auf Basis vordefinierter Regeln in gleicher Frequenz, Struktur und Detaillierungsgrad AwarenessInformationen in Bezug auf ihre kooperative Arbeit erhalten.
Des Weiteren sollte das Generieren und Präsentieren von Awareness-Informationen die
normalen Antwortzeiten der Anwendung nicht negativ beeinflussen.
Keine Informationsüberlastung
Hinsichtlich der Präsentation von Awareness-Informationen sollte ein geeignetes Maß
zwischen Darstellungsmethoden mit hoher Wahrnehmbarkeit und hoher Ablenkungsgefahr bzw. geringer Wahrnehmbarkeit und geringer Ablenkungsgefahr berücksichtigt
45
werden (vgl. [Berlage/Sohlenkamp 1999] 229f). Die Anwender des Systems sollten
weder durch zu viele noch durch irrelevante Informationen überfordert werden. Stattdessen sollten die Informationen kontextbezogen, prägnant und aufgabenangemessen
detailliert dargestellt werden. Des Weiteren sollte das System über optionale Konfigurationsmöglichkeiten die Wahl individueller Präferenzen ermöglichen.
Sicherheitsstrategie
Die gegenseitige Bereitstellung von Awareness-Informationen ist im Rahmen einer
Architektur für Place-based Awareness an das Vorhandensein eines indirekten gemeinsamen Arbeitskontextes über eine Place-Beziehung gebunden. Dabei wird sowohl
die synchrone als auch die asynchrone kooperative Arbeit berücksichtigt.
Außerhalb eines Place bzw. einer hierarchischen Kette von Places sind die betreffenden
Awareness-Informationen für andere Akteure im System nicht sichtbar. Somit kann
niemand auf diese Informationen zugreifen, der nicht selbst in dem jeweiligen Arbeitskontext involviert ist.
Eine vergleichbare Sicherheitsstrategie findet sich im Rahmen der „Arbeitsbereiche“
von POLIAwaC (vgl. [Fuchs 1998], 138ff.)
Mitbestimmungsrecht
Da ein Awareness-System auch als technische Einrichtung zur Überwachung des Verhaltens oder der Leistung der Mitarbeiter interpretiert werden kann, unterliegt es den im
Betriebsverfassungsgesetz (BetrVG) beschriebenen Mitbestimmungsrechten der Mitarbeitervertretungen (Personalrat bzw. Betriebsrat) (vgl. [Fuchs 1998], S. 50; [Schaar
2002], S. 240f.). Dabei ist der Tatbestand einer Mitbestimmung nach Rechtssprechung
des Bundesarbeitsgerichts schon dann gegeben, „wenn die Einrichtung zur Kontrolle
geeignet ist“ ([Schaar 2002], S. 241). Da der letzte Punkt bei Awareness-Systemen
erfüllt ist, sollten die Interessen der Mitarbeitervertretungen im organisatorischen Umfeld berücksichtigt werden; beispielsweise falls die Systementwicklung gezielt für ein
bestimmtes Unternehmen erfolgt.
Reziprozität
Der Aspekt Reziprozität wurde bereits in Kapitel 2.2.4.3 vorgestellt. Er beschreibt das
Prinzip eines wechselseitigen Zugangs zu Awareness-Informationen und bildet im
Rahmen dieser Arbeit eine wichtige Anforderung im Hinblick auf den Entwurf einer
Architektur für Place-based Awareness.
46
Die gegenseitige Wahrnehmung der Präsenz und Aktionen anderer Akteure wird im
Kontext von Place-based Awareness über das Place-Modell sichergestellt. Nur zwischen
Mitgliedern eines Place werden Awareness-Informationen geteilt. Akteure, die nicht
Mitglied in dem betreffenden Place sind, erhalten somit weder Informationen über die
Präsenz und Aktionen von Place-Mitgliedern noch allgemeine Informationen über den
Status des Place, wie z. B. die aktuelle Anzahl aktiver Mitglieder.
3.3.2 Funktionale Sicht
Filter
Auf die Bedeutung von Filterregeln wurde bereits in Kapitel 2.2.4.3 unter dem Aspekt
der Konfigurierbarkeit hingewiesen. Filterregeln sind sowohl bei der Erzeugung als
auch beim Empfang von Awareness-Informationen von Bedeutung.
Hinsichtlich der Generierungsphase kann über Filterregeln der Detaillierungsgrad von
Awareness-Informationen individuell festgelegt werden. Ein Anwender kann somit
gezielt entscheiden, wer welche Informationen über seine Anwesenheit und Aktionen
im System erhalten darf. Das Konfigurieren von Filtern bedeutet aber im Gegenzug
auch einen erhöhten Arbeitsaufwand für die Anwender eines Awareness-Systems. Um
diesen Aufwand minimal zu gestalten, sollten vordefinierte aber individualisierbare
Regeln vorgesehen werden.
In diesem Zusammenhang zeigen die Ergebnisse von Studien, dass Anwender einfache
und klare Filterregeln – beispielsweise auf Basis einer Gruppe oder eines Arbeitsbereichs – bevorzugen (vgl. [Patil/Lai 2005], S. 105ff.; [Fuchs 1998], S. 160). In einem
System für Place-based Awareness sollten diese Ergebnisse dahingehend einbezogen
werden, dass die Konfigurationsmöglichkeit von Filterregeln zunächst auf Place-Ebene
beschränkt ist.
In Bezug auf den Aspekt Reziprozität hat dies nicht nur die Konsequenz, dass jeder
Anwender auf Place-Ebene entscheiden kann, inwieweit er Awareness-Informationen
über seine Person und Aktionen anderen Personen bereitstellen möchte. Des Weiteren
beeinflusst seine Entscheidung gleichzeitig auch den für ihn erzeugten Detaillierungsgrad der Darstellung von Awareness-Informationen anderer Akteure. Das bedeutet, dass
jedem Akteur im Awareness-System genau das Maß an Awareness-Informationen
anderer Personen zugänglich gemacht wird, das der betreffende Akteur mittels Filterregeln auch bereit ist anderen Akteuren über seine Aktivitäten preiszugeben.
47
Die Wahl einer Filtereinstellung für ausgehende Awareness-Informationen hat somit zur
Folge, dass diese Regel auch für eingehende Awareness-Informationen zwangsläufig
Anwendung findet. Bei der Wahl einer restriktiven Einstellung wird somit automatisch
das Prinzip der Reziprozität wiederhergestellt.
Neben der Erzeugung sollten auch beim Empfang von Awareness-Informationen Konfigurationsmöglichkeiten existieren. Über diese Einstellungen könnte jeder Akteur
entscheiden, ob und inwiefern die für ihn bestimmten Awareness-Informationen in
ihrem Detaillierungsgrad weiter eingeschränkt werden sollen. Diese Filterregeln würden
somit ein Mittel bilden, um der Gefahr einer Informationsüberladung der Akteure entgegenzuwirken.
Historie
Die Erstellung einer Historie ist eine grundlegende Anforderung an ein AwarenessSystem, das kooperative Arbeit über einen größeren Zeithorizont als eine Sitzung unterstützen soll. Durch die Bereitstellung von protokollierten Informationen über vergangene Aktivitäten im Arbeitsbereich können zurückliegende Arbeitsschritte nachvollzogen und – bei Kenntnis von Arbeitszielen – auch zukünftige Aktionen prognostiziert
werden. Des Weiteren können Konflikte in Zusammenhang mit der Bearbeitung von
Informationsobjekten durch mehrere Anwender identifiziert und aufgelöst werden.
Durch die Funktion einer Historie profitieren nicht nur asynchron kooperierende Akteure, sondern auch Personen, die neu oder nach längerer Abwesenheit an einer existierenden Kooperationsbeziehung teilnehmen. Anwender, die auf Informationen über zurückliegende Ereignisse und Aktivitäten im Rahmen ihrer Arbeit angewiesen sind, beurteilen daher einen Historiendienst durchaus positiv (vgl. [Fuchs 1998], S. 154).
In Bezug auf den Historiendienst in einem Awareness-System sind aber auch Risiken zu
beachten (siehe Kapitel 2.2.4.2). Diese resultieren daraus, dass in einem entsprechenden
System sehr viele personenbezogene Informationen über Aktionen gesammelt werden
können.
Auf der anderen Seite bietet eine detaillierte Historie den Vorteil, dass die Anfragen von
Anwendern an einen Historiendienst auch detaillierte Ergebnisse liefern. Anwender sind
allerdings weniger an einer einfachen Auflistung vergangener Ereignisse interessiert,
sondern an aussagekräftigen Übersichten und Zusammenfassungen (vgl. [PankokeBabatz/Prinz/Schäfer 2004b], S. 28).
48
Dabei können allgemeine Fragestellungen vorliegen – z. B. ob überhaupt in der Vergangenheit Aktivitäten in einem Arbeitskontext stattfanden (vgl. [Tam/Greenberg
2006], S. 592) – oder konkrete Fragestellungen, bezogen auf ein Artefakt, einen Akteur,
eine Aktion oder einen Zeitraum (vgl. [Pankoke-Babatz/Prinz/Schäfer 2004b], S. 37).
Im Rahmen von Place-based Awareness sollte ein Historiendienst daher entsprechende
Konfigurationsmöglichkeiten für Anwenderanfragen bieten. Neben der Auswahl eines
bestimmten Zeithorizonts könnte eine Anfrage Place-, Person- oder Aktion-bezogen
erfolgen. Dabei sollte der Historiendienst die Place-Mitgliedschaften der Anwender
berücksichtigen. Dadurch kann ausgeschlossen werden, dass ein Anwender bei einer
Recherche nach einer bestimmten Person Awareness-Informationen über Aktivitäten
erhält, die in einem Place stattfanden, in denen die anfragende Person momentan nicht
Mitglied ist.
Zudem existieren Ansätze um die Daten in Historien zu aggregieren („aggregation“)
oder altern zu lassen („aging“) (vgl. [Pankoke-Babatz/Syri 1997], S. 193). Diese Ansätze werden im Rahmen von Place-based Awareness nicht verfolgt werden.
3.3.3 Technische Sicht
Sicherheit
Um die Funktionen eines Awareness-Systems nutzen zu können, sollte eine Authentifizierung der Benutzer erforderlich sein, um sicherzustellen, dass keine unberechtigten
Personen Zugriff auf Awareness-Informationen erhalten. Zudem muss im Rahmen eines
Sicherheitskonzepts garantiert werden, dass ein Anwender nur auf Informationen zugreifen kann, die seinen Arbeitskontext betreffen.
Stabilität und Korrektheit
Ein Awareness-System sollte auch bei temporären Verbindungsunterbrechungen eine
korrekte Verteilung der Awareness-Informationen gewährleisten. Um Inkonsistenzen
bezügliche der zu einem gegebenen Zeitpunkt präsentierten Informationen zu vermeiden und Informationsbrüche in der Historie auszuschließen, sollte ein Konzept
entwickelt werden, dass eine korrekte Verteilung und Protokollierung von AwarenessInformationen sicherstellt.
Wiederverwendbarkeit
Ein Awareness-System sollte modular entworfen werden, so dass es an unterschiedliche
Anwendungen angebunden werden kann. Je mehr Anwendungen als Informations-
49
quellen an das System angeschlossen sind, desto umfassender ist das Bild, das über die
Bereitstellung von Awareness-Informationen den beteiligten Akteuren über ihre kooperative Arbeit vermittelt werden kann. Dies spielt insbesondere eine Rolle, wenn mit
einer großen Zahl unterschiedlicher Anwendungen gearbeitet wird.
Erweiterbarkeit
Das Awareness-System sollte nachträgliche Anpassungen ermöglichen. Die Struktur der
Awareness-Datensätze sollte modifizierbar sein, um anwendungsspezifische Aktionen
erfassen und einbinden zu können.
Kurze Antwortzeiten
Ein Awareness-System sollte einem Anwender direkte Rückmeldungen über eigene
Aktionen bieten und eine synchrone Verbreitung der erzeugten AwarenessInformationen sicherstellen. Bei der Generierung und Präsentation der AwarenessInformationen sollten die normalen Antwortzeiten der Applikationen, in denen die
Awareness-Information bereitgestellt wird, nur minimal beeinträchtigt werden. Zudem
soll das User Interface (UI) der Anwendung bei Anfragen an die Historie nicht blockiert
werden.
Integration
Awareness-Systeme sollten in existierende Groupware-Systeme integriert bzw. an diese
gekoppelt werden. Während Awareness-Systeme Informationen über die Präsenz und
Aktivitäten von Anwendern generieren und präsentieren, ermöglichen GroupwareApplikationen Unterstützungsfunktionalitäten bei Kollaborationsprozessen. Eine Kombination der beiden Systemklassen bietet den Vorteil, dass Informationen nicht nur
visualisiert, sondern auch im Kontext dieser Informationen direkt Interaktionen zwischen Anwendern stattfinden können. Bei der Kopplung von Place-based Awareness an
eine Groupware-Anwendung könnte beispielsweise durch einen Anwender mit allen
weiteren Akteuren in einem Place eine elektronische Konferenz gestartet werden. Des
Weiteren könnten auf Basis der Awareness-Informationen über einen Akteur direkt
Chats initiiert oder E-Mails versendet werden.
50
3.4 Instant Messaging als Awareness-System
Bevor im folgenden Kapitel ein Architekturentwurf für ein Place-based AwarenessSystem dargestellt wird, erfolgt in diesem Kapitel zunächst die Vorstellung eines weit
verbreiten und erfolgreichen Awareness-Systems: Instant Messaging (IM).
„Instant messaging systems are the most successful version of awareness servers,
and possibly the most successful real-time groupware application ever.” ([Gutwin
et al. 2005], S. 8)
In Hinblick auf die Bedeutung von IM in der Zukunft heißt es bei Gartner – einem der
weltweit führenden Unternehmen im Bereich von Marktforschung und -analyse sowie
Beratung im IT-Sektor – in einem Pressebericht:
„Gartner predicts that by the end of 2011, IM will be the de facto tool for voice,
video and text chat with 95 percent of workers in leading global organisations using it as their primary interface for real-time communications by 2013. The
worldwide market for enterprise IM is forecast to grow from $267 million in 2005
to $688 million in 2010.” ([Goasduff/Forsling 2007])
Der Erfolg und die Bedeutung von IM basiert auf den unterschiedlichen Funktionen zur
Unterstützung von informeller Kommunikation (vgl. [Gutwin et al. 2005], S. 8; [Isaacs
et al. 2002], S. 1). Nardi, Whittaker und Bradner stellen in diesem Zusammenhang fest,
dass IM-Interaktionen viele Charakteristika mit informeller face-to-face-Kommunikation teilen würden, da sie opportunistisch, kurz und kontextreich wären (vgl. [Nardi/Whittaker/Bradner 2000], S. 82). Hinsichtlich der durch IM unterstützen Kommunikationsprozesse unterscheiden diese Autoren zwischen „interaction“ und „outeraction“
(vgl. [Nardi/Whittaker/Bradner 2000], S. 79):
Mit „interaction“ bezeichnen sie im Rahmen von IM informelle Kommunikationsprozesse in Form von textbasierter Konversation zur Formulierung und Beantwortung
von
Fragen,
Koordinierung
und
Absprache
von
Terminen
(vgl.
[Nar-
di/Whittaker/Bradner 2000], S. 79).
Dagegen beschreiben sie mit „outeraction“ unerwartete Verwendungsmöglichkeiten
von IM, die sich weniger auf den direkten Austausch von Informationen, sondern auf
die abstrakteren Kommunikationsprozesse zur Initiierung und Steuerung von IMKonversationen beziehen (vgl. [Nardi/Whittaker/Bradner 2000], S. 79).
51
Zunächst wird im Kontext dieser Arbeit in Bezug auf den Aspekt „interaction“ auf die
Verwendung von IM am Arbeitsplatz eingegangen. Nardi, Whittaker und Bradner
kommen auf Basis einer Studie mit 20 Arbeitnehmern bezüglich der kommunikativen
Funktion von Instant Messaging zu dem folgenden Ergebnis:
„A central use of IM was to support quick questions and clarifications about ongoing work tasks.” ([Nardi/Whittaker/Bradner 2000], S. 81)
Die These, dass in Bezug auf den Einsatz von IM am Arbeitsplatz Aspekte der Kollaboration im Vordergrund stehen, wird von einer weiteren, größeren Studie bestätigt. Hierbei analysierten Isaacs et al. eine repräsentative Auswahl an Datensätzen auf Basis von
21.000 IM-Konversationen von 437 Arbeitnehmern bei AT&T Labs (vgl. [Isaacs et al.
2002], S. 13). Diese Autoren kommen ebenfalls zu dem Schluss, dass der Hauptverwendungszweck von IM am Arbeitsplatz Gespräche über Arbeit darstellen würde (vgl.
[Isaacs et al. 2002], S. 18). 62% aller Konversationen per IM seien dieser Kategorie
zuzuordnen – zu der sie Gespräche über Arbeitsinhalte, Gespräche zur Koordinierung
paralleler kooperativer Arbeit und Gespräche über arbeitsverwandte Themen zählen
(vgl. [Isaacs et al. 2002], S. 18).
Neben der computergestützten, textbasierten Konversation bietet Instant Messaging als
Groupware-System noch weitere Funktionalitäten im Hinblick auf die Unterstützung
von Kollaborationsprozessen. Dazu zählen die Bereitstellung von Informationen über
Präsenz (presence awareness), Aktivitäten und Verfügbarkeit von IM-Anwendern (vgl.
[Gutwin et al. 2005], S. 8). Im Vordergrund stehen dabei im Rahmen von IM-Systemen
Präsenz- und Verfügbarkeitsinformationen (vgl. [Tran/Yang/Raikundalia 2005], S. 2).
Die Bereitstellung von Präsenzinformationen erfolgt im Kontext von IM in der Regel
durch eine Kontaktliste (buddy list), über die Kontakte verwaltet und die Online-Status
von Kontakten (buddies) abgebildet werden. Durch die Visualisierung der StatusInformationen kann über einen opportunistischen Zeitpunkt für eine Konversation mit
einem Kontakt entschieden und diese initiiert werden.
Nardi, Whittaker und Bradner beschreiben noch einen weiteren Aspekt in Bezug auf
den Zweck einer Kontaktliste: Die Erzeugung und Aufrechterhaltung eines Gefühls der
sozialen Verbundenheit unter den Kontakten (vgl. [Nardi/Whittaker/Bradner 2000], S.
84).
52
„While not involved in direct information exchange, participants often used IM in
indirect ways to create and maintain a sense of connection to others by monitoring
the buddy list. Somewhat to our surprise, we found that people found value in
simply knowing who else was ‘around’ as they checked the buddy list, without
necessarily wanting to interact with buddies.” ([Nardi/Whittaker/Bradner 2000],
S. 84f.)
Die Funktion einer Kontaktliste ist somit nicht nur auf den Prozess zur Initiierung einer
Konversation beschränkt, sondern kann auch ein Verbundenheitsgefühl zwischen Personen bestärken.
Auf einer Kontaktliste werden Präsenzinformationen in der Regel mit Verfügbarkeitsinformationen kombiniert dargestellt. Letztere sind beispielsweise Status-Informationen
wie „online“, „offline“ oder „away“ sowie Status-Icons oder spezifische, individualisierbare Status-Nachrichten. Die Vorteilhaftigkeit dieser Verfügbarkeitsinformationen
ist allerdings gerade im Hinblick auf den Einsatz von IM am Arbeitsplatz umstritten.
Einerseits weisen Autoren auf die Bedeutung dieser Informationen bei der Wahl eines
geeigneten Zeitpunkts für informelle Konversation hin (vgl. [Tran/Yang/Raikundalia
2005], S. 1f.; [Tee/Greenberg/Gutwin 2006], S. 100), andererseits wird ein fehlender
Bezug zum Arbeitskontext kritisiert:
„… however, IM is completely disconnected from work activities, and so cannot
support informal collaboration about tasks.” ([Gutwin et al. 2005], S. 8)
Im Rahmen dieser Arbeit wird die kritische Betrachtung in Bezug auf die Ausgestaltung
von Verfügbarkeitsinformationen bei Einsatz von IM am Arbeitsplatz geteilt. Das Problem ist, dass Status-Informationen von IM derzeit zu ungenau sind, um die Verfügbarkeit eines Anwenders an seinem Arbeitsplatz korrekt darstellen zu können. Zum einen
bieten Status-Informationen wie „online“, „away“ oder „busy“ nur eine grobe Beschreibung der Verfügbarkeit eines Anwenders, zum anderen bietet die Festlegung des
Status Fehlerpotential. Die Auswahl der Status-Information kann manuell durch den
Anwender oder automatisch auf Basis von Regeln und dem eingesetzten System erfolgen, z. B. bei Systeminaktivität über einen gewissen Zeitraum (vgl. [Fogarty/Lai/Christensen 2004], S. 300).
Die Folge von ungenauen Verfügbarkeitsinformationen ist einerseits, dass das Risiko
einer Arbeitsstörung steigt, weil ein Anwender die Arbeitssituation eines Kontakts auf
53
Basis der bereitgestellten Status-Informationen nicht richtig interpretieren kann. Andererseits erfolgt in vielen IM-Sessions trotz vorliegender Status-Information zu Beginn
durch den Initiator eine Rückfrage nach der Anwesenheit bzw. der aktuellen Verfügbarkeit des Gesprächspartners (vgl. [Nardi/Whittaker/Bradner 2000], S. 83; [Fogarty/Lai/Christensen 2004], S. 300; [Voida/Newstetter/Mynatt 2002], S. 192).
Im Rahmen von Awareness als CSCW-Forschungsgebiet befasst sich eine ganze Reihe
von Autoren und Forschungsgruppen mit der Erweiterung von IM-Systemen um neue
Funktionen ([Fogarty/Lai/Christensen 2004], [Tran/Yang/Raikundalia 2005], [Yee/Park
2005]). Dabei sind die Grenzen zwischen einem IM-System mit erweiterten AwarenessFunktionen und einem Awareness-System mit integrierten Chat-Funktionen fließend.
Als Fazit dieses Kapitels ist festzuhalten, dass der Verwendungszweck von Instant
Messaging am Arbeitsplatz in erster Linie darauf abzielt, um über Arbeit zu sprechen,
diese gegenseitig abzustimmen und gemeinsam durchzuführen. Trotz dieses – durch
Studien nachgewiesenen – Sachverhalts werden die jeweiligen Arbeitskontexte von
Akteuren bei der Zusammenstellung von Präsenz- und Verfügbarkeitsinformationen nur
unzureichend miteinbezogen. Dadurch können als Konsequenz Missverständnisse und
Gesprächsanbahnungen in ungeeigneten Situationen resultieren.
3.5 Architekturentwurf für Place-based Awareness
Auf Basis des Fazits aus dem letzten Kapitel (3.4) und der Anforderung hinsichtlich
einer Integration zwischen Awareness- und IM-System (siehe Kapitel 3.3) erfolgt an
dieser Stelle der Entwurf einer Client-Server-Architektur für Place-based Awareness
(PBA). Die Wahl einer Client-Server-Umgebung erfolgt dabei aufgrund der organisatorischen, funktionalen und technischen Anforderungen, die in Kapitel 3.3 spezifiziert
sind.
Eine Client-Server-Architektur gewährleistet zum einen, dass Awareness-Daten zentral
verwaltet und persistent gespeichert werden. Zum anderen wird sichergestellt, dass die
Clients Zugriff auf konsistente Awareness-Informationen erhalten – unter Berücksichtigung von Sicherheitskonzepten bzw. Zugriffsrechten zwischen Client und Server.
Die folgende Abbildung zeigt die Erweiterung einer Client-Server-Architektur um ein
Place-based-Awareness-System, das sich aus einer PBA-Komponente und einem PBAServer zusammensetzt. Dabei orientiert sich der Entwurf an einer losen Kopplung des
54
Awareness-Systems mit der Umwelt über die Spezifikation weniger schmaler Schnittstellen (vgl. [Dunkel/Holitschke 2003], S. 4ff.).
Client
PBA Server
IM Server
Workspace
PBA Component
Application A
Authentication
Service
PBA
GUI
PBA Services
Authentication
Service
Authentication
Service
Awareness
Service
Community
Service
Place
Service
History
Service
Management
Repository
History
Repository
Abbildung 14 - Aufbau der Architektur für Place-based Awareness
Während die PBA-Komponente in den Workspace eines Software-Systems auf einem
Client integriert wird, stellt der PBA-Server die Dienste für Place-based Awareness und
Datenbanken zur Sicherung von Awareness- und Verwaltungsdaten bereit.
Der Ansatz des Entwurfs baut auf einer „Drei-Schichten-Architektur“ auf (vgl. [Dunkel/Holitschke 2003], S. 17ff.):
Das „Graphical User Interface“ (GUI) bildet als Benutzeroberfläche die Präsentationsschicht der Architektur. Im Rahmen des GUI werden Awareness-Daten visualisiert.
Zudem kann ein Anwender durch Selektion von Menüeintragen z. B. Filtereinstellungen
vornehmen oder eine kontext-sensitive Anfrage an die Historie starten.
Die Anwendungslogik in Form von Diensten ist auf einem eigenen PBA-Server hinterlegt und bildet die Anwendungsschicht der Architektur. Die PBA-Dienste steuern Authentifizierungsprozesse, die Verarbeitung eingehender Awareness-Daten (z. B. in Form
von Log-Einträgen) und die Bereitstellung von Awareness-Daten.
55
Die beiden Repositories bilden als Datenbanken die Persistenzschicht der Architektur.
Im Management-Repository sind Places-Hierarchien und Mitgliedschafts-Daten abgelegt. Das History-Repository umfasst die Historie in Form von Log-Einträgen.
In den folgenden Kapiteln werden die Dienste, die Schnittstellen und die Elemente im
Rahmen der Architektur für Place-based Awareness näher vorgestellt. Die Reihenfolge
der Kapitel orientiert sich dabei an den verschiedenen Phasen, die bezüglich einer späteren Realisierung der Architektur als Awareness-System identifiziert werden können.
3.5.1 Authentifizierung (Phase I)
In der ersten Phase von Place-based Awareness als Awareness-System ist eine Authentifizierung des Anwenders an den beteiligten Servern der Architektur vorgesehen. Voraussetzung dafür sind zwei Aspekte. Zum einen muss eine PBA-Komponente in das
System des Client-Rechners eingebunden sein und zum anderen muss ein Server die
Dienste für Place-based Awareness bereitstellen.
Die PBA-Komponente stellt – neben der Steuerung des Authentifizierungsprozesses
eines Anwenders am System – Awareness-Daten über eine Benutzeroberfläche dar. Bei
der Anbindung der Komponente in den Workspace eines Anwenders auf dessen ClientRechner sollte eine permanente Sichtbarkeit der Komponente gewährleistet sein. Das
bedeutet, dass die im Rahmen der Arbeit mit Applikationen erzeugten Awareness-Daten
parallel zur Programmausführung wahrgenommen werden können.
Client
PBA Server
IM Server
Workspace
PBA Component
Authentication
Service
PBA Services
1
Authentication
Service
3
Awareness
Service
Abbildung 15 - Authentifizierungsphase
2
Authentication
Service
56
Des Weiteren erfolgt die Integration der PBA-Komponente derart, dass die Authentifizierung eines Anwenders am Client-Rechner bzw. am Workspace direkt für eine
automatische Authentifizierung der Person am PBA-Server verwendet werden kann
(siehe Abb. 15, S. 55, Punkt 1). Der Authentication-Service des PBA-Servers nimmt auf
Basis dieser Daten eine Anmeldung des Anwenders an einem Instant-MessagingSystem vor (siehe Abb. 15, S. 55, Punkt 2). Die Anbindung an ein IM-System ist dabei
im Rahmen der Architektur für Place-based Awareness optional – aber vorgesehen
(siehe Kapitel 3.3.3 und 3.4). Als letzter Schritt erfolgt die Anmeldung des Anwenders
am Awareness-Service, der den zentralen Dienst des Awareness-Systems bildet (siehe
Abb. 15, S. 55, Punkt 3).
3.5.2 Initialisierung (Phase II)
Client
PBA Server
IM Server
Workspace
PBA Component
PBA Services
3
PBA
GUI
Awareness
Service
1
Place
Service
2
Management
Repository
Abbildung 16 - Initialisierungsphase
Nach erfolgreicher Authentifizierung und Anmeldung des Anwenders werden von dem
Place-Service Informationen über existierende Places und über die Mitgliedschaften des
Anwenders in konkreten Places angefordert (siehe Abb. 16, Punkt 1). Die diesbezüglichen Daten sind persistent in einer Datenbank – dem Management-Repository –
hinterlegt und werden von dem Place-Service ausgelesen (siehe Abb. 16, Punkt 2).
Die Daten im Management-Repository bestehen aus Definitionen von Places und Mitgliedschaften von Anwendern in diesen Places. Die Definition eines Place setzt sich
dabei zusammen aus einer PlaceID, die einen Place eindeutig im Rahmen eines PBASystems identifiziert, und einem Namen. Hinzu kommt ein Status, über den festgelegt
werden kann, ob ein Place aktiv oder inaktiv ist. Aktiv bedeutet in diesem Zusammen-
57
hang, dass eingehende Awareness-Daten vom PBA-System berücksichtigt werden und
Akteure einen Place somit betreten können. Die temporäre Inaktivität eines Place bedeutet das entsprechende Gegenteil.
Optional ist bei der Einrichtung eines Place die Verknüpfung zu einem übergeordneten
Place durch Erfassung der betreffenden PlaceID. Durch diese Beziehung kann eine
hierarchische Struktur zwischen Places erzielt werden (siehe auch Kapitel 3.2.2).
Entität
Attribute
Place
PlaceID
Name
Status
upper PlaceID
UserID
Membership
PlaceID
Status (des Abonnements)
Tabelle 10 - Entwurf des Datenmodells im Management-Repository
Zusätzlich zu den Place-Definitionen sind im Management-Repository auch Mitgliedschaftsdaten erfasst. Eine Mitgliedschaft wird im Rahmen eines Place angelegt, sobald
ein Anwender zum ersten Mal eine Aktion im Kontext des betreffenden Place ausübt.
Ein entsprechender Datensatz wird automatisch generiert und gesichert. Somit existiert
aus Nutzersicht jeweils eine Mitgliedschaft für jeden betretenen Place.
Der Zweck von Mitgliedschaftsdatensätzen besteht darin, die individuellen Einstellungen eines Anwenders für einen Place zu sichern.
Ein Konfigurationsmerkmal für einen Place bildet das so genannte Abonnement. Durch
die Wahl einer Abonnement-Einstellung kann ein Anwender die Sichtbarkeit seiner
Aktionen für andere Akteure im entsprechenden Place temporär oder dauerhaft einschränken. Das Abonnement-Konzept bildet somit eine individuelle Place-basierte
Filtermöglichkeit und stellt einen wichtigen Aspekt in Bezug auf die Konfigurierbarkeit
des Awareness-Systems (siehe Kapitel 2.2.4.3) und die diesbezügliche funktionale
Anforderung (siehe Kapitel 3.3.2) dar.
Nach der Bereitstellung von Daten über existierende Places und Mitgliedschaften des
Anwenders wird der Abschluss der Initialisierung des Awareness-Systems auf der
Benutzeroberfläche der PBA-Komponente visualisiert (siehe Abb. 16, S. 56, Punkt 3).
58
3.5.3 Bereitstellung, Verteilung und Präsentation (Phase III)
Nach Abschluss der Initialisierung können dem Awareness-System Daten in Bezug auf
die Aktionen des Anwenders im Umfeld einer Applikation bereitgestellt werden. Die
Aktionen eines Anwenders können zeitraum- oder zeitpunktbezogen sein. Zeitraumbezogene Aktivitäten bilden im Kontext der Arbeit mit Informationsobjekten in einer
Anwendung beispielsweise Lese- oder Editierphasen. Eine zeitpunktbezogene Aktion
ist im Gegenzug beispielsweise die Speicherung eines Informationsobjekts.
Während zeitraumbezogene Aktionen gestartet und beendet werden müssen und in der
Zwischenzeit gewechselt werden können, sind zeitpunktbezogene Aktionen durch ein
singuläres Auftreten eines Ereignisses gekennzeichnet. Das bedeutet, dass in der Applikation in den Routinen zur Ereignisbehandlung die Bereitstellung von Daten für das
Awareness-System berücksichtigt werden muss. Ein auf Basis einer Aktion in einer
Applikation generierter Datensatz enthält neben der Angabe einer Place- und AktionsID auch eine Beschreibung der Aktion und gegebenenfalls auch einen Link auf das in
die Aktion involvierte Informationsobjekt. Eine genauere Betrachtung hierzu erfolgt auf
Basis eines Prototyps in Kapitel 4.3.
Im Rahmen des konzeptionellen Entwurfs ist lediglich festzuhalten, dass eine Applikation Awareness-Datensätze für jede Aktion eines Anwenders im Kontext der betreffenden Anwendung generiert und an den Awareness-Service übermittelt (siehe Abb.
17, Punkt 1).
Client
PBA Server
IM Server
Workspace
PBA Component
PBA Services
Application A
5
1
PBA
GUI
Awareness
Service
4
Community
Service
2
History
Service
3
History
Repository
Abbildung 17 - Bereitstellung, Verteilung und Präsentation von Awareness-Daten
59
Nach dem Empfang eines durch eine Applikation generierten Awareness-Datensatzes
wird auf Basis der übermittelten Place- und Aktions-ID geprüft, ob der Anwender bereits eine Aktion in dem entsprechenden Place ausübt. Wenn dies nicht der Fall ist, wird
der Place betreten und die entsprechende Aktion gestartet. Im Gegenzug wird ein Place
verlassen, wenn der Anwender seine letzte Aktion im Kontext des Place beendet.
Entsprechende Log-Einträge werden über den History-Service im History-Repository
archiviert (siehe Abb. 17, S. 58, Punkt 2 und 3).
Entität
Attribute
HistoryItem
Date
PlaceID
Placename
UserID
Username
EventType
Modus
Description
Link
Tabelle 11 - Entwurf des Datenmodells im History-Repository
Falls eine Schnittstelle zu einem IM-System existiert, werden die Daten einer Aktion
mit zusätzlichen Informationen über die Präsenz und Verfügbarkeit des Urhebers der
Aktion kombiniert (siehe Abb. 17, S. 58, Punkt 4).
Im Anschluss erfolgt die Übermittlung der Daten der Aktion an alle Clients von Akteuren, die in dem Place der betreffenden Aktion Mitglied und aktiv sind (siehe Abb. 17, S.
58, Punkt 5). Dabei werden zusätzlich noch übergeordnete Places sowie Filtereinstellungen wie Abonnements berücksichtigt. Falls beispielsweise der Urheber der
Aktion den Place nicht abonniert hat, wird die Darstellung seiner Aktion für alle
anderen Akteure unterbunden.
3.5.4 Anfrage an Historie und Konfiguration
Anfragen an die Historie und Einstellungen werden über die Benutzeroberfläche der
PBA-Komponente vorgenommen. Zum einen sollte eine Auswahl an unterschiedlichen
Darstellungsformen bestehen und zum anderen sollten sich die Anzahl der präsentierten
Awareness-Informationen filterbasiert einschränken lassen (siehe Abb. 18, S. 60, Punkt
1).
60
Client
PBA Server
Workspace
PBA Component
PBA Services
Application A
1
Awareness
Service
4
PBA
GUI
2
Place
Service
3
Management
Repository
7
5
History
Service
6
History
Repository
Abbildung 18 - Anfrage an Historien-Dienst und Konfiguration
Des Weiteren existiert im Rahmen von Place-based Awareness zum Schutz der Privatsphäre das Abonnement-Konzept (siehe Kapitel 3.5.2). Der Anwender sollte über die
Benutzeroberfläche Places abonnieren oder abbestellen können (siehe Abb. 18, Punkt
2). Der Place-Service nimmt die Änderung der Abonnement-Einstellung entgegen und
sichert sie – falls die Modifikation über den Zeitraum der Session hinaus gelten soll – in
dem entsprechenden Mitgliedschaftsdatensatz im Management-Repository (siehe Abb.
18, Punkt 3). Zudem wird über den Awareness-Service sichergestellt, dass die Aktionen
des Anwenders in Abhängigkeit seiner Abonnementeinstellung für andere Akteure im
Place dargestellt bzw. ausgeblendet werden (siehe Abb. 18, Punkt 4).
Außerdem können über die Benutzeroberfläche Anfragen an einen History-Service
gestellt werden (siehe Abb. 18, Punkt 5), die dieser auf Basis der Einträge im HistoryRepository beantwortet (siehe Abb. 18, Punkt 6). Das Stellen von Historienanfragen
sollte dabei kontextgebunden erfolgen und Konfigurationsoptionen bieten (siehe Kapitel
3.3.2).
Der letzte noch nicht vorgestellte Aspekt in der Abbildung 18 beschreibt den Vorgang
zur Definition eines Place (siehe Abb. 18, Punkt 7). Hierbei ist zu beachten, dass dieser
Vorgang im Gegensatz zu den bereits erläuterten Prozessen nicht über die Benutzeroberfläche der PBA-Komponente gesteuert werden kann. Die Ursache hierfür liegt
darin, dass im Rahmen von Place-based Awareness der Ansatz verfolgt wird, die Defi-
61
nition von Places und die Zuordnung von Informationsobjekten zu Places durch die an
das Awareness-System angebundenen Applikationen zu steuern.
Vorgesehen sind daher zwei Schnittstellen zwischen den Applikationen und dem Awareness-System: Über die erste Schnittstelle können automatisch generierte AwarenessDaten von den angeschlossenen Applikationen an das Awareness-System gesendet
werden (siehe Abb. 17, S. 58, Punkt 1). Die zweite Schnittstelle ermöglicht das Einlesen, Hinzufügen und Editieren von Place-Definitionen (siehe Abb. 18, S. 60, Punkt 7).
Die Logik zur Definition von Places, Verknüpfung von Objekten mit Places und Erzeugung von Awareness-Daten auf Basis der durch die Arbeit eines Anwenders ausgelösten Ereignisse ist somit Bestandteil der angebundenen Applikationen und nicht
der Awareness-Dienste.
3.6 Zusammenfassung
Unter Berücksichtigung der Forschungsergebnisse von Gutwin und Greenberg (siehe
Kapitel 2.2.5.1) sowie ter Hofte et al. (siehe Kapitel 2.2.5.2) erfolgte in dem Kapitel 3
zunächst der Entwurf eines eigenen Awareness-Modells. Place-based Awareness beinhaltet als Resultat sowohl Charakteristika eines raumbasierten, als auch eines ereignisbasierten Modells (siehe Kapitel 3.2). Gliederungsebenen für die im Kontext
kollaborativer Arbeit generierten Awareness-Informationen bilden dabei Places, die
hierarchisch strukturiert sein können.
Bei der Formulierung von Anforderungen hinsichtlich einer prototypischen Realisierung des Modells wurden die Ergebnisse der Chancen-Risiken-Gegenüberstellung
hinsichtlich der Bereitstellung von Awareness-Informationen explizit berücksichtigt
(siehe Kapitel 2.2.4 und 3.3). Dabei wurde ein Schwerpunkt auf die Einbeziehung kritischer Problemstellungen gesetzt (siehe Kapitel 2.2.4.2).
Die Analyse von Instant Messaging als Awareness-System führte zu dem Ergebnis, dass
eine Integration von Place-based Awareness und Instant Messaging in den Entwurf
einer Architektur Vorteile aufweist (siehe Kapitel 3.4). Ein entsprechender Architekturentwurf erfolgte in Kapitel 3.5.
Im folgenden Kapitel erfolgt die Vorstellung des realisierten Prototyps, dessen Architektur in einigen Punkten von dem konzeptionellen Entwurf aufgrund der Wahl einer
speziellen Systemumgebung abweicht.
62
4 Prototypische Implementierung einer Place-basedAwareness-Komponente
4.1 Systemumgebung
4.1.1 Lotus Notes/Domino
Lotus Notes/Domino ist ein client-server-basiertes, dokumentenorientiertes, verteiltes
Datenbanksystem der IBM Software Group. Lotus Notes bildet als Produkt dabei die
clientseitige und Lotus Domino die serverseitige Software.
Lotus Notes/Domino ist eines der führenden und am weitesten verbreiteten GroupwareProdukte (vgl. [Stahlknecht/Hasenkamp 2005], S. 423; [Alpar et al. 2005], S. 408);
[Böttger et al. 2007], S. 151). Weltweit sind über 125 Millionen Lotus-Notes-Clients im
Einsatz, davon in Deutschland allein über 12 Millionen (vgl. [Böttger et al. 2007], S.
153).
Als Groupware bietet es nicht nur klassische Funktionalitäten des Personal Information
Managements (PIM) wie Messaging, Aufgaben- und Kalenderverwaltung, sondern
ermöglicht auf Basis einer integrierten Anwendungsentwicklungsumgebung – dem
Lotus Domino Designer – die Entwicklung eigener Applikationen.
Besondere Merkmale von Lotus Notes/Domino bilden u. a. die Synchronisation (Replikation) einer Lotus-Notes-Datenbank zwischen Lotus-Notes-Client und LotusDomino-Server bzw. zwischen Lotus-Domino-Servern (vgl. [Böttger et al. 2007], S.
162f.) sowie die integrierte Public-Key-Infrastruktur (PKI) (vgl. [Böttger et al. 2007], S.
169f.).
Seit der im Sommer 2007 erschienenen Version 8.0 von Lotus Notes basiert die Software auf der Plattform von Lotus Expeditor, die wiederum auf der Eclipse Rich Client
Platform (RCP) basiert (vgl. [Daum 2007], S. 11ff.). Über die offenen Standards des
Eclipse Frameworks und die Integration von Eclipse-Plugins können neue Arten von
Applikationen im Lotus-Notes-Umfeld entworfen werden, die sich an dem Konzept
einer Service Oriented Architecture (SOA) orientieren. Ein neues Paradigma im Rahmen der Entwicklung von Lotus-Notes-Applikationen bilden diesbezüglich die so genannten Composite Applications.
63
4.1.2 Composite Applications
Composite Applications bilden im Rahmen von Lotus Notes 8 ein neues Muster zum
Entwurf von Lotus-Notes-Applikation. Eine Composite Application kann sich aus
unterschiedlichen Komponenten zusammensetzen. Dabei kann es sich um Lotus-NotesDatenbanken, Eclipse-Plugins, Portlets oder Web-Applikationen handeln (vgl. [Rodriguez et al. 2007], S. 69ff.).
Der Gedanke hinter dem Konzept von Composite Applications besteht darin, BusinessAnwendungen aus einzelnen, wiederverwendbaren Bausteinen bzw. Komponenten, die
jeweils nur einen speziellen Teil der Business-Logik enthalten, zusammenzusetzen.
Dabei erfolgt die Verbindung einzelner Komponenten zu einer Composite Application
in Form einer losen Kopplung auf Basis der Web Service Description Language
(WSDL), einer XML-basierten Sprache zur Beschreibung der Schnittstellen von WebServices (vgl. [Dustdar/Gall/Hauswirth 2003], S. 120).
Nach der Definition der Input- und Outputparameter einer Komponente in Form von
WSDL-Dateien kann eine Komponente mit einer anderen verknüpft werden. Dies geschieht im Composite Application Editor durch das so genannte Wiring (siehe Abb. 19).
Abbildung 19 - Wiring von Komponenten im Composite Application Editor
64
Jede Komponente kann hinsichtlich des Wiring sowohl Werte (properties) veröffentlichen (publish) als auch konsumieren (consume). Im Rahmen einer Lotus-NotesKomponente können properties beispielsweise über die LotusScript API veröffentlicht
werden (vgl. [Rodriguez et al. 2007], S. 559).
Die Kommunikation zwischen den Komponenten wird während der Ausführung einer
Composite Application über den Property Broker gesteuert (vgl. [Rodriguez et al.
2007], S. 45ff.).
4.1.3 Lotus Sametime
Lotus Sametime ist eine Plattform für Echtzeit-Kollaboration von IBM. Sie beinhaltet
Funktionen wie Presence Awareness, Chat, Instant Messaging und unterstützt neben der
text- auch audio/video-basierte Kommunikation. Als Web-Conferencing-Software bietet
Sametime zudem Applikation- und Desktop-Sharing sowie ein Whiteboard und ein
Voting-Tool (vgl. [Böttger et al. 2007], S. 178; [Bergland et al. 2003], S. 5).
IBM-intern nutzen ca. 98 Prozent der Mitarbeiter Lotus Sametime und verschicken
darüber jeden Werktag fast fünf Millionen Nachrichten (vgl. [Reppesgaard/Bialluch
2007]).
Abbildung 20 - IBM Lotus Sametime Connect Client
Seit der Version 7.5 basiert die Architektur von Lotus Sametime – wie Lotus Notes 8 –
auf der Lotus-Expeditor-Plattform und somit auf der Eclipse RCP. Im Wesentlichen
65
besteht der Lotus-Sametime-Client (siehe Abb. 20, S. 64) daher aus einem Paket von
Eclipse-Plugins (vgl. [Attardo et al. 2007], S. 23ff.) und kann über bereitgestellte Toolkits in andere Anwendungen integriert werden (vgl. [Attardo et al. 2007], S. 38). Im
Rahmen dieser Arbeit sind die APIs des Sametime 7.5.1 Connect Toolkits (vgl. [Attardo
et al. 2007], S. 39) und des Sametime 7.5.1 Java Toolkits (vgl. [Nielsen et al. 2002], S.
7ff.) verwendet worden.
Einen zusätzlichen wichtigen Aspekt von Lotus Sametime im Kontext dieser Arbeit
bildet die Unterstützung von Single Sign-On (SSO) durch Generierung eines Tokens in
Form von Light Third-Party Authentication (LTPA). Dadurch können Anwender automatisch am Lotus-Sametime-Server authentifiziert werden, wenn sie bereits in der
Lotus-Notes/Domino-Umgebung angemeldet sind (vgl. [Böttger et al. 2007], S. 178;
[Bergland et al. 2003], S. 341f.)
Ein Vorteil bezüglich der Implementierung eines Prototypen auf Basis von Lotus Notes/Domino und Lotus Sametime ist die Tatsache, dass in Sametime das Konzept einer
Place-Architektur und eines Place-Service bereits realisiert ist (vgl. [Bergland et al.
2003], S. 183ff.; [Nielsen et al. 2002], S. 33 und S. 49ff.).
Place
Attributes
Stage
Activities
Sections
Attributes
Users
Attributes
Attributes
Users
Attributes
Attributes
Abbildung 21 - Places-Modell von Lotus Sametime (vgl. [Nielsen et al. 2002], S. 52)
66
Im Kontext des Places-Modell von Lotus Sametime bildet ein Place einen virtuellen
Raum, den Nutzer betreten können, um als Platzmitglied gegenseitig den Online-Status
einsehen zu können und auf verschiedene Arten zu kommunizieren (vgl. [Nielsen et al.
2002], S. 52). Ein Place setzt sich dabei aus Räumen (Sections) zusammen, wobei die
so genannte Stage einen besonderen Raum bildet, der sich hinsichtlich der Berechtigungen von anderen Sections unterscheidet (vgl. [Nielsen et al. 2002], 53ff.).
Im Rahmen von Place-based Awareness erfolgt jedoch keine Aufteilung der Platzmitglieder in Sections. Des Weiteren werden auch keine Activities berücksichtigt. Dabei
handelt es sich um serverseitige Applikationen („servlets for places“), die die Kollaborationsmöglichkeiten von Place-Mitgliedern erweitern (vgl. [Nielsen et al. 2002], S. 53).
Eine Schlüsselrolle im Kontext des Prototypen von Place-based Awareness bilden
dagegen die Attribute im Places-Modell von Lotus Sametime. Jedes Mitglied eines
Place kann hierbei eine Liste von Attributen haben. Dabei handelt es sich um Schlüssel/Wert-Paare, die dynamisch generiert und modifiziert werden können (vgl. [Nielsen
et al. 2002], S. 54). Änderungen von Attributen lösen in Lotus Sametime Ereignisse im
Rahmen des Place-Service aus und bewirken eine Form der Backend-Kommunikation
zwischen den Mitgliedern eines Place.
Die Verteilung von Informationen über Aktionen eines Anwenders im Rahmen des
Prototyps von Place-based Awareness erfolgt auf Basis dieser Kommunikationsbeziehung durch Hinzufügen, Modifizieren und Löschen von User-Attributen.
4.2 Architektur der Komponente
Im Rahmen dieses Kapitels erfolgt die Vorstellung der Architektur einer Place-basedAwareness-Komponente auf Basis von Lotus Notes/Domino und Lotus Sametime.
Aufgrund der Besonderheiten der Systemumgebung in Form eines neuen Entwicklungsparadigma – den Composite Applications – und eines in Lotus Sametime
integrierten Places-Modell weicht die Architektur vom konzeptionellen Entwurf in
einigen Gesichtspunkten ab (siehe Kapitel 3.5). Die grundlegenden Aspekte sind jedoch
identisch. Dazu gehören u. a. die Berücksichtigung einer losen Kopplung, eines
Historiendienstes, einer Place- und Abonnementverwaltung, eines Authentifizierungsverfahrens und einer Benutzeroberfläche mit Einstellungsoptionen wie z. B. Filtern.
67
Die folgende Abbildung stellt die Architektur des Prototyps dar und beinhaltet dessen
wichtigste Elemente und Beziehungen:
Lotus Notes 8 Client
Sametime Client
Property Broker
Composite Application A
Application B
PBA Eclipse-Plugin
Eclipse View (GUI)
UI-Thread
History-Thread
Main-Thread
ManagementThread
SametimeThread
NRPC-Protokoll
Lotus Domino 7 Server
Lotus Sametime 7 Server
Composite
Application A
NSF
Community-Service
Application B
NSF
Place-Service
Update Site
NSF
People-Service
PBA
Management
NSF
Livename-Service
Abbildung 22 - Architektur der prototypischen Implementierung
Die Systemumgebung des Prototyps setzt sich zusammen aus den Lotus-Notes-8Clients der Anwender und zwei zentralen Servern, einem Lotus-Domino-7-Server und
einem Lotus-Sametime-7-Server. Des Weiteren gehören vier Datenbanken – auf Basis
des Notes/Domino-Formats „Notes Storage Facility“ (NSF) – zu den Grundbestandteilen des realisierten PBA-Prototyps. Dabei handelt es sich um eine PBA-ManagementDatenbank, die eine Kombination aus Management-Repository und History-Repository
bildet (siehe Kapitel 3.5), sowie um eine Composite Application A. Diese enthält abgesehen von den Spezifikationen der eingebundenen Komponenten und deren Schnitt-
68
stellen in Form einer XML-Datei keine weiteren Daten. Komponenten der Composite
Application A bilden eine NSF-basierte Lotus-Notes-Applikation B und das PBA Eclipse-Plugin.
Das Eclipse-Plugin ist dabei in einer Update-Site-NSF-Datenbank auf dem LotusDomino-Server hinterlegt und wird beim ersten Aufruf der Composite Application A in
den Lotus-Notes-Client des Anwenders installiert. Das Konzept einer NSF-basierten
Update-Site ermöglicht im Kontext von Composite Applications eine zentrale Ablage
und Verwaltung eines oder mehrerer Eclipse-Plugins auf einem Lotus-Domino-Server.
Über das Protokoll des Notes Remote Procedure Calls (NRPC) werden Daten zwischen
den Applikations-Datenbanken auf dem Server und dem Client übermittelt. Die Kommunikation zwischen den Komponenten der Composite Application erfolgt über den
Property Broker des Lotus-Notes-Clients. Diese Schnittstelle wird im Rahmen des
Kapitels 4.3 näher dargestellt.
Die durch den Property Broker übermittelten Daten über die Aktionen eines Anwenders
in der Applikation B werden durch den UI-Thread – der Thread in dem das EclipsePlugin ausgeführt wird – entgegengenommen und in den Puffer des Main-Thread geschrieben. Bei allen Puffern handelt es sich im Kontext der PBA-Komponente um
Puffer nach dem FIFO-Prinzip (First in-First out).
Der Main-Thread übernimmt die Aufgabe der Verwaltung der Aktionen eines Anwenders durch Zuordnung dieser Daten auf die entsprechenden Place-Objekte. Dabei
werden gegebenenfalls auch übergeordnete Places berücksichtigt. Anschließend werden
die Aktionsdaten in Kombination mit dem zugehörigen Place-Objekt in den Puffer des
Management-Threads und den Puffer des Sametime-Threads geschrieben (siehe Kapitel
4.4).
Der Management-Thread steuert die Zugriffe auf die PBA-Management-Datenbank. Er
liest Daten in Bezug auf Definitionen von aktiven Places und Abonnements von PlaceMitgliedern aus (siehe Kapitel 3.5.2) und erstellt Log-Einträge auf Basis der Anwenderaktionen. Der Sametime-Thread steuert dagegen den Datenverkehr mit dem LotusSametime-Server. Zunächst erfolgt dabei die Authentifizierung durch ein LTPA-Token
am Community-Service (siehe Kapitel 4.1.3). Nach erfolgreicher Anmeldung kann der
Anwender über den Place-Service von Sametime in einen Place als User eingetragen
werden. Jede Aktion des Anwenders im Kontext des Place bildet dann ein UserAttribute im betreffenden Place (siehe Kapitel 4.1.3).
69
Hierbei ist zu bemerken, dass es sich bei Places auf dem Lotus-Sametime-Server im
Rahmen von Place-based Awareness nicht um persistente Places handelt. Die Places
existieren auf dem Sametime-Sever stattdessen nur temporär. Sollte ein Place zum Zeitpunkt des Betretens durch einen Anwender nicht existieren, wird er auf Basis der PlaceID – aus der Place-Definition in der PBA-Management-Datenbank – erstellt. Nachdem der letzte Anwender seine Aktion/en im Kontext eines Place beendet und ihn dadurch verlassen hat, wird der Place dementsprechend auf dem Server gelöscht.
Neben der Verbreitung von Informationen über die eigenen Aktionen erfolgt im Kontext des Sametime-Threads auch ein ereignisgesteuerter Empfang der Aktionen anderer
Place-Mitglieder über einen Event-Handler des Lotus-Sametime-Place-Service. Dabei
werden zusätzlich auch Presence-Awareness-Informationen des betreffenden Akteurs
miteinbezogen. Die Änderung des Online-Status im Kontext von Place-based Awareness erfolgt über den im Lotus-Notes-Client integrierten Lotus-Sametime-Client.
Im Gegensatz zu den bisher vorgestellten Threads wird der History-Thread nur auf
Basis einer Anfrage des Anwenders an die Historie gestartet.
Durch Strukturierung der Anwendungslogik von Place-based Awareness in unterschiedliche Threads wird sichergestellt, dass Verzögerungen in Bezug auf die Hintergrundprozesse zur Verarbeitung und Verteilung von Aktionsdaten nicht zu einer Blockierung
des Plugin-GUI bzw. der gesamten Anwendung führen (siehe Kapitel 3.3.3).
4.3 Schnittstelle zwischen Applikation und Komponente
Im Rahmen des konzeptionellen Architekturentwurfs wurde bereits über die Unterscheidung in zeitraum- und zeitpunktbezogene Aktionen auf die zwischen Applikation
und Awareness-System zu übermittelnden Daten hingewiesen (siehe Kapitel 3.5.3). Auf
Basis der im Kontext von Composite Applications eingesetzten Auszeichungssprache
WSDL (siehe Kapitel 4.1.2) erfolgt in diesem Kapitel eine genauere Beschreibung der
Schnittstelle zwischen der Applikation und der PBA-Eclipse-Komponente. Dabei handelt es sich um insgesamt vier Properties, die über die folgenden Methoden einer PBALotusScript-Library in einer Anwendung veröffentlich werden können:
PBAStart
Das Property „PBAStart“ kennzeichnet den Beginn einer zeitraumbezogenen Aktion
und beinhaltet eine eindeutige ActionID sowie die PlaceID des Place. Hinzu kommen
eine Beschreibung der Aktion und eine Angabe über den Modus (z. B. Lese- oder Edi-
70
tiervorgang). Des Weiteren können die ReplicaID der Applikations-Datenbank und die
Universal ID (UNID) eines Lotus-Notes-Dokuments im Kontext der Aktion als Parameter übergeben werden. Die ReplicaID identifiziert dabei eine Lotus-Notes-Datenbank
innerhalb einer Lotus-Domino-Serverumgebung eindeutig und eine UNID ein Dokument in einer Lotus-Notes-Datenbank.
PBAChange
Das Property „PBAChange“ beschreibt den Wechsel einer zeitraumbezogenen Aktion.
Das bedeutet, dass im Vorfeld ein PBAStart-Property mit identischer ActionID veröffentlicht wurde und sich der Status einer Aktion geändert hat, beispielsweise durch
Übergang von einer Lese- in eine Editieroperation. Als Paramter enthält das PBAChange-Property die gleichen Bestandteile wie das PBAStart-Property.
PBAStop
Das Property „PBAStop“ kennzeichnet das Beenden einer zeitraumbezogenen Aktion.
Als Parameter sind dabei die Angabe von PlaceID und ActionID ausreichend.
PBASingle
Im Gegensatz zu den anderen Properties charakterisiert das PBASingle-Property eine
zeitpunktbezogene Aktion, wie z. B. das Speichern eines Dokuments. Als einziger
Parameter variiert im Vergleich zum PBAStart-Property die Angabe des Modus. Dieser
klassifiziert im Kontext eines PBA-Single-Property die zugrunde liegende Aktion.
4.4 Internes Objektmodell
Im Rahmen des internen Objektmodells der PBA-Komponente des Prototyps bilden
ActionOfUserInPlace-Objekte eine zentrale Schlüsselrolle. Dabei handelt es sich um
Objekte, die sich jeweils aus einem Place-, User- und Action-Objekt zusammensetzen
und somit eine bestimmte Aktion eines bestimmten Anwenders im Kontext eines bestimmten Place beschreiben.
Des Weiteren existieren intern PBAEvent-Objekte. Dazu gehören PropertyEvent-,
PlaceActionEvent- und PlaceSubscriptionEvent-Objekte, die als Ereignis-Objekte in die
Puffer der verschiedenen Threads geschrieben werden.
Das PropertyEvent-Objekt wird aus den Daten eines Property, d. h. den erhaltenen
Daten über eine Aktion des Anwenders, vom UI-Thread generiert und in den Puffer des
Main-Thread geschrieben. Der Main-Thread erzeugt auf Basis dieser Event-Objekte
Action-Objekte und kombiniert diese mit dem jeweils zugehörigen Place-Objekt zu
71
PlaceActionEvent-Objekten, die in die Puffer des Management- und Sametime-Threads
geschrieben werden (siehe Abb. 22, S. 67).
Einen weiteren Typ eines Event-Objekts bildet das PlaceSubscriptionEvent-Objekt, das
auf Grundlage einer Abonnements-Modifikation eines Anwenders über die Benutzeroberfläche erstellt wird (siehe Kapitel 4.6.2).
4.5 Benutzeroberfläche der Komponente
Aufgrund des hierarchischen Strukturkonzepts von Place-based Awareness (siehe Kapitel 3.2.2) basiert die Visualisierung der Awareness-Informationen auf einer Baumstruktur, die mittels der Bibliotheken des Standard Widget Toolkits (SWT) von Eclipse
und JFace realisiert wurde. Dazu wurden zwei Bäume implementiert, die auf der TreeViewer-Klasse von JFace basieren (vgl. [Assisi 2004], S. 720).
Das Konzept der Viewer in JFace bildet den View-Aspekt des MVC-Design-Patterns
(Model-View-Controller) (vgl. [Daum 2007], S. 156). Der Entwurf des PBA-EclipsePlugins orientiert sich an diesem Entwurfmuster, das eine interaktive Applikation in die
drei Teile Datenhaltung (Model), Darstellung (View) und Ablaufsteuerung (Control)
gliedert (vgl. [Dustdar/Gall/Hauswirth 2003], S. 105ff.).
In den folgenden beiden Abbildungen wird die Benutzeroberfläche der PBAKomponente anhand eines kurzen Beispiels vorgestellt. Das Beispiel zeigt dabei aus
Sicht des Anwenders Heiko die graphische Visualisierung seiner Lese-Aktion A in einer
an das System angeschlossenen Applikation im Kontext des Place „Place 3“.
Abbildung 23 - Benutzeroberfläche (Gliederung nach Places)
72
Bei „Place 1“ und „Place 2“ handelt es sich um übergeordnete Places, die durch rekursive Methodenaufrufe im Rahmen des Main-Threads ebenfalls betreten worden sind
(siehe Abb. 23, S. 71). Parallel übt eine weitere Anwenderin Anna eine Editier-Aktion
B im „Place 3“ aus und ist somit auch Mitglied in den übergeordneten Places. Der
Anwender Thomas ist hingegen für den Anwender Heiko nur im „Place 1“ sichtbar. Im
Gegenzug hat der Anwender Thomas keine genauen Informationen über die Aktionen
von Heiko oder Anna in den Places „Place 2“ bzw. „Place 3“.
Das blaue Icon vor dem Place-Namen symbolisiert, dass der Anwender Heiko zu dem
Zeitpunkt nicht über einen Lotus-Sametime-Client am Lotus-Sametime-Server angemeldet ist und somit einen Offline-Status besitzt. Die Zahl in den Klammern hinter
dem Place-Namen zeigt die Zahl der aktiven Mitglieder zum aktuellen Zeitpunkt im
entsprechenden Place (siehe Abb. 23, S. 71).
Abbildung 24 - Benutzeroberfläche (Gliederung nach User)
In der zweiten Baumdarstellung der Benutzeroberfläche erfolgt die Kategorisierung
nach User anstatt nach Places (siehe Abb. 24). Der Anwender Heiko ist im Kontext
dieser Abbildung über einen Lotus-Sametime-Client angemeldet; visualisiert durch ein
grünes Icon vor den Place-Namen. Zusätzlich erfolgt eine Kombination der aus der
Aktion gewonnenen Awareness-Informationen mit dem Presence-Awareness-Status der
jeweiligen Anwender im Rahmen der Lotus-Sametime-Community; visualisiert durch
das Lotus-Sametime-Status-Icon vor den Namen der Anwender.
Bei Selektion eines Elements in einer der beiden Baumstrukturen kann per MausRechtsklick ein spezielles Kontextmenü aufgerufen werden. Dieses Kontextmenü erweitert das Standard-Sametime-Kontextmenü um spezielle Funktionen im Rahmen von
Place-based Awareness (siehe Abb. 25, S. 73). Die Funktionsvielfalt des Menüs variiert
73
in Abhängigkeit davon, ob ein Place-Element oder ein User-Element gewählt wurde.
Streng genommen bilden die Elemente in den Bäumen dabei sowohl Place-, als auch
User- und ActionOfUserInPlace-Objekte ab (siehe Kapitel 4.4). Letztere Objekte bilden
in den Baumstrukturen immer die Blattebene.
Abbildung 25 - Place-Kontextmenü (links) und User-Kontextmenü (rechts)
Einen besondere Funktion bildet der Eintrag „Kontext-Dokument öffnen“ im UserKontextmenü (siehe Abb. 25). Dieser Eintrag ist aktiv, sobald einer Aktion ein LotusNotes-Dokument zugrunde liegt – die Aktionsdaten somit eine ReplicaID und UNID
beinhalten (siehe Kapitel 4.3). Falls ein Anwender über die nötigen Rechte in der ZielApplikation verfügt, kann er durch diesen Eintrag das Dokument im Kontext einer
bestimmten Aktion eines anderen Akteurs öffnen.
Die Funktionalitäten der Einträge „Filter“, „Historie“ und „Mitgliedschaft“ werden in
den folgenden Kapiteln vorgestellt.
74
4.6 Funktionen der Komponente
4.6.1 Filter
Die Filteroptionen gestatten es jedem Anwender die ihm präsentierte Vielfalt an Awareness-Informationen individuell zu begrenzen (siehe Abb. 26).
Abbildung 26 - Filteroptionen
4.6.2 Historie
Anfragen an die Historie können auf Basis eines User, Place oder Dokuments gestellt
werden. Im Kontextmenü sind die entsprechenden Einträge in Abhängigkeit des selektierten Elements in den Darstellungsbäumen aktiv oder inaktiv (siehe Abb. 27). Die
Abfrage einer Dokumenthistorie ist beispielsweise aktiv, wenn einer Aktion ein konkretes Lotus-Notes-Dokument zugrunde liegt (siehe Kapitel 4.3).
Abbildung 27 - Anfrage an Historie über Auswahldialog
In Form eines Auswahldialogs kann der Zeithorizont der gewünschten Abfrage spezifiziert werden (siehe Abb. 27).
75
Das Resultat einer Anfrage wird in Form einer Tabelle dargestellt. Im Beispiel in der
Abbildung 28 ist eine vollständige Auflistung der zurück gelieferten Log-Einträge im
Kontext einer bestimmten Aktion A des Anwenders Heiko abgebildet. Den Anfang
bilden dabei die Einträge, die das Betreten des Place bzw. der übergeordneten Places
beschreiben (grüner Pfeil). Der Beginn (grün), der Wechsel (blau) und das Ende (rot)
einer Aktion wird durch einen farbigen Punkt visualisiert. Im Anschluss an das Beenden
der letzten Aktion im Kontext eines Place wird dieser verlassen (roter Pfeil).
Abbildung 28 - Darstellung des Resultats einer Anfrage an die Historie
Auch in Bezug auf die Einträge in der Tabelle der Historienabfrage steht das PBAKontextmenü uneingeschränkt zur Verfügung (siehe Kapitel 4.5).
4.6.3 Abonnement
Das Abonnement-Konzept von Place-based Awareness wurde bereits in Kapitel 3.5.2
vorgestellt. Im Kontext des Prototyps kann ein Place temporär oder dauerhaft abonniert
bzw. abbestellt werden (siehe Abb. 29).
Abbildung 29 - Modifikation einer Abonnement-Einstellung
76
Nachdem das Abonnement einer Mitgliedschaft im Place „Place 1“ im Beispiel der
Abbildung 29 temporär abbestellt worden ist, sind weder die Informationen über die
eigene Anwesenheit noch die Daten über die eigenen Aktionen im „Place 1“ für andere
Akteure des Place sichtbar (siehe Abb. 30). Auf Basis des Reziprozität-Konzepts (siehe
Kapitel 2.2.4.3, 3.3.1 und 3.3.2) werden im Gegenzug die Awareness-Informationen
über andere Place-Mitglieder für den betreffenden Anwender (Heiko) ausgeblendet.
Abbildung 30 - Baumdarstellung nach Abbestellung eines Abonnements
Nicht-abonnierte Places – durch ein rotes Icon gekennzeichnet – gewährleisten somit
für einen Anwender eine Form des Schutzes der Privatsphäre, da sie die Sichtbarkeit
eigener Awareness-Informationen unterbinden. Des Weiteren wird der betreffende
Anwender auch nicht mehr in der GroupChat-Funktion des Place berücksichtigt und er
kann im Gegenzug keine GroupChats im entsprechenden Place initiieren (siehe Abb.
25, S. 73).
Nichtsdestotrotz wird weiterhin die Gesamtzahl der aktiven Mitglieder in einem Place
hinter dem Place-Namen in Klammern dargestellt und es werden auch ebenso noch
Log-Einträge über die Aktionen des Anwenders in die Historie geschrieben.
Dieser Ansatz stellt daher sicher, dass ein Anwender zwar das Recht hat, seine Sichtbarkeit und Erreichbarkeit im Awareness-System einzuschränken, aber trotzdem auf der
anderen Seite die Historie konsistent alle Aktionen im Kontext eines Place abbildet.
77
4.7 Zusammenfassung
Die prototypische Implementierung der Awareness-Komponente, die im Rahmen des
Kapitel 4 vorgestellt wurde, basiert auf dem Konzept für Place-based Awareness in
kollaborativen Arbeitsumgebungen (siehe Kapitel 3) und erfüllt die diesbezüglichen
Architekturanforderungen (siehe Kapitel 3.3).
Die Realisierung der PBA-Komponente erfolgte zudem unter Berücksichtigung eines
konzeptionellen Architekturentwurfs (siehe Kapitel 3.5). In diesem Zusammenhang
stellt die Komponente als Eclipse-Plugin nur einen Teilaspekt einer IT-Infrastruktur dar,
die sich aus einer Umgebung auf Basis von Lotus Notes/Domino und Lotus Sametime
zusammensetzt. Dabei handelt es sich um sehr weit verbreitete und erfolgreiche Groupware-Systeme (siehe Kapitel 4.1.1 und 4.1.3).
Bei der Implementierung wurde durch die Verknüpfung einer exemplarischen Applikation und der PBA-Komponente über eine Composite Applications auf ein modernes
Entwurfskonzept im Bereich Lotus Notes/Domino zurückgegriffen (siehe Kapitel
4.1.2).
Die Anbindung der Komponente an eine Lotus-Sametime-Infrastruktur bietet den Vorteil, dass der Informationsgehalt der Daten im Kontext von Place-based Awareness um
weitere Awareness-Informationen auf Basis von Lotus Sametime erweitert werden
kann. Zudem stellt Lotus Sametime eine stabile und sichere Lösung in Bezug auf die
Verteilung der Awareness-Informationen dar und beinhaltet bereits ein PlaceArchitektur, auf die über einen Place-Service als Schnittstelle zugegriffen werden kann.
Die Kombination aus PBA-Komponente und Lotus-Sametime-Infrastruktur berücksichtigt mehrere Punkte, die Gutwin und Greenberg im Kontext ihres Frameworks im
Kontext kollaborativer Zusammenarbeit identifizieren (siehe Kapitel 2.2.5.1). Dazu
gehören gegenwarts- als auch vergangenheitsbezogene Fragestellungen in Bezug auf die
Anwesenheit und Identität von Akteuren sowie deren Aktionen und ihre verwendeten
Artefakte (siehe Tab. 6 und 7, S. 24f.).
78
5 Fallstudie GCC Grading Management System
5.1 Szenario
Das GCC Grading Management System (GMS) bildet eine Applikation zum Management und zur Koordination von Prüfungen und Prüfungsleistungen auf Basis von Lotus
Notes/Domino. Seit mehr als 10 Jahren wird das GMS kontinuierlich vom Groupware
Competence Center an der Universität Paderborn weiterentwickelt. Verschiedene Lehrund Forschungseinheiten der Fakultät für Wirtschaftswissenschaften nutzen das System
im Bereich des Bewertungsmanagements ihres Prüfungsangebots (vgl. [Ploch 2007]).
Dabei unterliegen sowohl Lehre als auch Prüfungsangebote und –formen einem ständigen Wandel. Im Rahmen des Bologna-Prozesses erfolgte mit der Bildung von Bachelorund Masterstudiengängen auch eine Neustrukturierung und Modularisierung bestehender Lehrangebote mit neuen semesterbegleitenden und lehrstuhlübergreifenden
Prüfungsformen (vgl. [Ploch 2007]).
Eine Konsequenz der modularisierten und lehrstuhlübergreifenden Prüfungsstrukturen
ist eine größere Personenzahl, die in die Bewertungsprozesse involviert ist. Des Weiteren nehmen die Kollaborationsprozesse zwischen den beteiligten Modulkoordinatoren,
Gutachtern und Prüfern zu (siehe Abb. 31).
Modul
Teilmodulprüfung 1
Teilmodulprüfung 2
Prüfer
Gutachter
Gutachter
Gutachter
Prüfer
Teilmodulprüfung 3
Modulkoordinator
Gutachter
Prüfer
Prüfer
Gutachter
Abbildung 31 - Kollaboration im Kontext eines Bewertungsmanagements (vgl. [Ploch 2007])
79
5.2 Einsatz der Place-based-Awareness-Komponente
Im Rahmen des Kollaborationsbedarfs hinsichtlich des Managements von Prüfungen
und Prüfungsleistungen wurde prototypisch eine Composite Application realisiert, die
als Komponenten das GMS und das PBA-Eclipse-Plugin enthält. Das Ziel ist dabei das
Funktionsspektrum des Grading Management Systems als Groupware- und Unterstützungssystem um zusätzliche Funktionen aus dem Bereich Awareness zu erweitern.
Das Konzept von Place-based Awareness bietet in diesem Zusammenhang ein hierarchisches Place-Modell, auf das sich die modulorientierten Prüfungsstrukturen des GMS
übertragen lassen. Die oberste Place-Ebene könnte hierbei das GMS als Applikation
bilden und die Modulprüfungs- und Teilmodulprüfungsdokumente bzw. die Modulbewertungs- und Teilmodulbewertungsdokumente könnten die untergeordneten PlaceEbenen darstellen.
Im Kontext des Bewertungsprozesses für die Veranstaltung „Methoden der Wirtschaftsinformatik“ kann ein exemplarischer Einsatz des Systems veranschaulicht werden. Das
betreffende Modul setzt sich aus insgesamt 4 Teilmodulen zusammen, die von verschiedenen Wirtschaftsinformatik-Lehrstühlen der Universität Paderborn angeboten und
betreut werden.
Die Abbildung auf der folgenden Seite zeigt aus der Sicht von Holger Ploch – einem
Mitarbeiter des Wirtschaftsinformatik-2-Lehrstuhls – die Ausübung einer Aktion hinsichtlich einer Bewertung für einen Studenten im Kontext des Teilmoduls „Grundlagen
des Informationsmanagements am Arbeitsplatz“ (GIA). Parallel dazu ist auch Markus
Spiekermann – ein Mitarbeiter des Wirtschaftinformatik-1-Lehrstuhls – im Grading
Management System aktiv. Im Beispiel führt Herr Spiekermann Bewertungen im Kontext einer anderen Veranstaltung durch, die ebenfalls als Teilmodul zu „Methoden der
Wirtschaftsinformatik“ gehört. Diese Aktionen sind jedoch für Herrn Ploch im Detail
nicht sichtbar, da er nicht an dem Bewertungsprozess des betreffenden Teilmoduls
beteiligt ist.
Auf der Ebene des Moduls sowie des GMS befinden sich allerdings beide Mitarbeiter in
den gleichen Places.
80
Abbildung 32 - Grading Management System und Place-based-Awareness
5.3 Bewertung
Der Einsatz eines Awareness-Systems ist insbesondere vor dem Hintergrund kollaborativer Arbeit über zeitliche und räumliche Distanzen als sinnvoll zu erachten (siehe
Kapitel 2.2). Hinsichtlich der Bewertungsprozesse im Rahmen des Einsatzes des Grading Management Systems ist dieser Faktor gegeben. Bei der Erfassung der Prüfungsleistungen im Modul „Methoden der Wirtschaftsinformatik“ bilden beispielsweise die
finalen Modulbewertungsdokumente von Studenten das Ergebnis einer Kollaboration
zwischen den Mitarbeitern und Professoren unterschiedlicher Lehrstühle.
In der exemplarischen Situation, die die Abbildung 32 skizziert, würde ohne den Einsatz der PBA-Komponente keine gegenseitige Wahrnehmung der Präsenz des Anderen
im System existieren. Aufgrund der Tatsache, dass im Kontext des GMS ein erhöhter
81
Koordinations- und Abstimmungsbedarf vorliegt, entstünde somit der Nachteil, dass
opportunistische Kommunikationszeitpunkte ungenutzt blieben.
Im Gegenzug ermöglichen die durch die PBA-Komponente visualisierten Informationen, dass parallele Aktivität im System wahrgenommen werden kann. Diese Awareness-Informationen können bei der Anbahnung informeller, ungeplanter Konversationen zur Diskussion über Fragestellungen in einem Bewertungsvorgang unterstützen.
Rückfragen können beispielsweise direkt angesprochen werden, wenn die Anwesenheit
des Anderen im System für den Fragesteller sichtbar ist. Zwar liegt auch hier die Gefahr
einer potentiellen Arbeitsstörung vor, allerdings befinden sich beide Akteure zu dem
entsprechenden Zeitpunkt indirekt in einem gemeinsamen Arbeitskontext. Es ist daher
anzunehmen, dass die Kontaktaufnahme in der betreffenden Situation als weniger störend empfunden wird als in anderen Situation.
Ein weiterer Vorteil des Einsatzes von Place-based Awareness im Kontext des GMS
ergibt sich daraus, dass alle Beteiligte einer Modulprüfung dynamisch auf Basis ihrer
Aktionen im System einem Place zugeordnet werden. Dies erleichtert auch Mitarbeitern, die nur kurzfristig in Prüfungsvorgänge eingebunden sind, die für sie
richtigen Ansprechpartner zu identifizieren und sich einfacher im System zu orientieren.
Unter Berücksichtigung der Historienfunktion und des Abonnement-Konzepts bildet die
PBA-Komponente daher ein sinnvolles Werkzeug zur Unterstützung der Managementund Koordinationsprozesse im Kontext des Grading Management Systems.
82
6 Ausblick
Im Rahmen dieser Arbeit erfolgte die Vorstellung einer prototypischen Implementierung eines Eclipse-Plugins (siehe Kapitel 4). Dieses Plugin bildet als Komponente eine
Realisierung des Modellentwurfs für Place-based Awareness. Es orientiert sich diesbezüglich an einem konzeptionellen Entwurf und den in diesem Zusammenhang aufgestellten Anforderungen (siehe Kapitel 3).
Obwohl viele Funktionen erfolgreich implementiert werden konnten, bietet der Prototyp
noch Potential für Erweiterungen und Verbesserungen. Bevor jedoch näher auf einzelne
Vorschläge eingegangen wird, muss noch eine andere Problematik in Bezug auf den
aktuellen Stand der Implementierung genannt werden: Trotz funktionaler Korrektheit
der Komponente und vorhandener Schnittstellen ist eine befriedigende und sinngerechte
Integration der Komponente in die Umgebung einer Applikation wie das Grading Management System bisher nicht erfolgt.
Dabei handelt es sich allerdings um ein technisches Problem, das sich anhand der Abbildung 32 auf Seite 80 beschreiben lässt. Im Kontext dieser Darstellung übt Herr Ploch
eine Lese-Aktion auf einem Bewertungsdokument aus, obwohl kein entsprechendes
Dokument in seinem Lotus-Notes-Client geöffnet ist. Das Problem hierbei ist, dass das
entsprechende Dokument in einem neuen Tab geöffnet werden würde. Damit wäre das
Dokument allerdings außerhalb der Composite Application geöffnet und es gäbe keine
Verbindung mehr zum Eclipse-Plugin in der Composite Application. Mit dem nächsten
Release von Lotus Notes (Version 8.0.1) wird allerdings die Voraussetzung geschaffen
werden, Dokumente sowohl in einem Tab als auch parallel im Kontext der entsprechenden Composite Application zu öffnen.
Neben dieser technischen Einschränkung existieren im Kontext des Prototypen auch
noch zwei ungelöste Probleme. Das erste Problem bildet das Sicherheitskonzept für die
PBA-Management-Datenbank, die die Historie des Systems in Form von Log-Einträgen
abbildet. Momentan verfügen alle Personen, die mit der PBA-Komponente arbeiten, in
dieser Datenbank über Lese- und Schreibrechte, um Log-Einträge auszulesen und automatisch unter ihrem Namen erstellen zu können. Während die Historienfunktion der
Komponente jedoch sicherstellt, dass nur Abfragen an die Historie im Rahmen des
eigenen Arbeitskontextes gestellt werden können, ist dies bei einem Öffnen der Datenbank im Lotus-Notes-Client nicht der Fall. Beim Zugriff auf die PBA-Management-
83
Datenbank über den Lotus-Notes-Client können derzeit sämtliche Log-Einträge eingesehen werden. Da diese Situation datenschutzrechtlich äußerst unbefriedigend ist,
muss ein Sicherheitskonzept für die betreffende Datenbank erarbeitet werden. Eine
einfache Lösung des Problems ist jedoch vor dem Hintergrund, dass im Rahmen von
Place-based Awareness die Akteure in einem Place im Vorfeld unbekannt sind, nicht zu
erzielen.
Die zweite Problemstellung betrifft den Definitionsprozess von Places. Ein Dialog, über
den Places in einer Anwendung definiert und Artefakte mit einem Place verknüpft
werden können, existiert in der aktuellen Version des Prototyps noch nicht. Stattdessen
erfolgt das Management der Places im Rahmen der PBA-Management-Datenbank.
Neben den vorgestellten Problemstellungen bzw. fehlenden Funktionen birgt der Prototyp auch Verbesserungspotentiale. So kann beispielsweise das visualisierte Informationsangebot der Komponente noch um eine farbliche Hervorhebung ergänzt werden,
falls mehrere Akteure das gleiche Dokument lesen oder editieren.
Des Weiteren können den Filtereinstellungen noch weitere Funktionen hinzugefügt und
die Maske für die Historienanfrage um weitere Einstellungsoptionen erweitert werden,
um eine speziellere Auswahl vergangener Aktionen zu erhalten.
Die zum Zeitpunkt der Abgabe dieser Arbeit startende Weiterentwicklung des Prototyps
in Form einer Projektarbeit wird vor dem Hintergrund der in diesem Kapitel behandelten Aspekte als sinnvoll und lohnenswert erachtet.
84
7 Zusammenfassung
Das Ziel dieser Arbeit war die Analyse und Bewertung der Bedeutung von Awareness
für kollaborative Arbeitsprozesse sowie die Konzeption und prototypische Implementierung eines Awareness-Systems.
Diesbezüglich erfolgte zunächst eine Eingrenzung des Themas auf das Umfeld des
Forschungsgebiets Computer Supported Cooperative Work (siehe Kapitel 2.1.1). Anschließend wurden über den Begriff Groupware Systeme und Anwendungen vorgestellt,
die im Kontext von CSCW entwickelt werden (siehe Kapitel 2.1.2). Die Unterstützungsfunktionen
von
Groupware-Applikationen
in
Hinblick
auf
Kollaborationsbeziehungen wurden im nachfolgenden Kapitel erläutert (siehe Kapitel
2.1.3).
Im Anschluss wurde eine thematische Einordnung von Awareness in den Kontext der
CSCW-Forschung und die Definition des Begriffs (siehe Kapitel 2.2.1 und 2.2.2) vorgenommen. Als zentrales Ziel wurde diesbezüglich die Bildung einer gegenseitigen
Wahrnehmung der Anwesenheit und Aktivitäten von Akteuren im Zusammenhang
computerunterstützter, kooperativer Arbeit identifiziert. Des Weiteren wurden Chancen
und Risiken im Rahmen der Erzeugung, Verteilung und Bereitstellung von AwarenessInformationen gegenübergestellt und diskutiert (siehe Kapitel 2.2.4).
Als Grundlage für einen eigenen Modellentwurf erfolgte danach die Vorstellung eines
Awareness-Frameworks nach Gutwin und Greenberg sowie des Konzepts Place-based
Presence nach ter Hofte et al. (siehe Kapitel 2.2.5.1 und 2.2.5.2). Einen wichtigen Aspekt des eigenen Modellkonzepts mit der Bezeichnung Place-based Awareness bildete
die Definition von Places zur Strukturierung von Anwenderaktionen in Arbeitskontexten (siehe Kapitel 3.2).
Nach der Formulierung von organisatorischen, funktionalen und technischen Anforderungen an eine Realisierung des Modells (siehe Kapitel 3.3), erfolgte der
konzeptionelle Entwurf einer Architektur für Place-based Awareness in Kombination
mit einer Instant-Messaging-Architektur (siehe Kapitel 3.5).
Die Entwicklung des realisierten Prototyps erfolgte in einer Lotus-Notes/Domino- und
Lotus-Sametime-Umgebung (siehe Kapitel 4.1). Die Implementierung bildete dabei ein
Eclipse-Plugin, das in Form einer Komponente mit bestehenden Lotus-Notes-
85
Applikationen im Rahmen einer Composite Application durch lose Kopplung verknüpft
werden kann (siehe Kapitel 4.2 und 4.3).
Nach Vorstellung ausgewählter Funktionen des Prototyps (siehe Kapitel 4.6) wurde am
Beispiel des GCC Grading Management Systems ein potentielles Einsatz-Szenario
skizziert (siehe Kapitel 5).
Trotz einiger existierender Einschränkungen (siehe Kapitel 6) wurde das beabsichtigte
Ziel dieser Diplomarbeit erreicht. Der Entwurf von Place-based Awareness als Modell
und die prototypische Implementierung der PBA-Komponente ermöglichen eine neue
Form der kollaborativen Arbeit in Lotus-Notes-Anwendungen. Es können AwarenessInformationen in Abhängigkeit des jeweiligen Arbeitskontextes automatisch generiert,
verteilt und präsentiert werden und Anwender effizient in spezifischen Fragestellungen
unterstützt werden (siehe Kapitel 1.2).
86
8 Literaturverzeichnis
[Alpar et al. 2005]
Alpar, Paul; Grob, Heinz Lothar; Weimann, Peter; Winter, Robert: Anwendungsorientierte Wirtschaftsinformatik - Strategische Planung, Entwicklung und Nutzung
von Informations- und Kommunikationssystemen, 4. Auflage, Friedr. Vieweg &
Sohn Verlag / GWV Fachverlage GmbH, Wiesbaden 2005
[Assisi 2004]
Assisi, Ramin: Eclipse - Einführung und Referenz - Java-Entwicklung mit der OpenSource-Plattform, Carl-Hanser-Verlag, München 2004
[Attardo et al. 2007]
Attardo, David; Barrow, John; Brooks, Robert; Cummins, John; Godby, Paul; Kantor, Katinka; Martens, Jon; Smiles, Elyzabeth; Womack, Travis: Extending Sametime 7.5: Building Plug-ins for Sametime, IBM International Technical Support Organization, Poughkeepsie 2007. Aus:
http://www.redbooks.ibm.com/abstracts/sg247346.html?Open am 09.10.2007
[Bardram/Hansen/Soegaard 2006]
Bardram, Jakob E.; Hansen, Thomas R.; Soegaard, Mads: AwareMedia: a shared interactive display supporting social, temporal, and spatial awareness in surgery, in:
CSCW '06: Proceedings of the 2006 20th anniversary conference on Computer supported cooperative work, ACM Press, New York 2006, S. 109-118
[BDSG 1990]
o. V.: Bundesdatenschutzgesetz, Bundesministerium der Justiz, Berlin 1990. Aus:
http://www.gesetze-im-internet.de/bdsg_1990/ am 16.11.2007
[Benford/Fahlén 1993]
Benford, Steve; Fahlén, Lennart: A spatial model of interaction in large virtual environments, in: De Michelis, G.; Simine, C.; Schmidt, K. (eds.): ECSCW '93 - Proceedings of the thirs 3rd European conference on computer supported cooperative
work, Kluwer Academic Publishers, Norwell 1993, S. 109-124
87
[Bergland et al. 2003]
Bergland, John; Barrow, John; Covey, Jonas; Cabral, Washington; Tyler, Carl; Novak, Rob; Sami, Yafit: Lotus Instant Messaging/Web Conferencing (Sametime):
Building Sametime-Enabled Applications, IBM International Technical Support Organization, Poughkeepsie 2003. Aus:
http://www.redbooks.ibm.com/abstracts/sg247037.html?Open am 09.10.2007
[Berlage/Sohlenkamp 1999]
Berlage, Thomas; Sohlenkamp, Markus: Visualizing Common Artefacts to Support
Awareness in Computer-Mediated Cooperation, in: Computer Supported Cooperative Work (CSCW), Volume 8, Number 3, Springer Netherlands, Dordrecht 1999,
S. 207-238
[Böttger et al. 2007]
Böttger, Christian (Hrsg.); Detken, Kai-Oliver; Erbe, Andreas; Grunwald, Lukas;
Mönikes, Klaus; Schommer, Christian; Wagner, Michael P.: iX-Studie "Groupware"
- Kommerzielle und Open-Source-Groupware-Systeme im Vergleich, Heise Zeitschriften Verlag, Hannover 2007
[Borghoff/Schlichter 1998]
Borghoff, Uwe M.; Schlichter, Johann H.: Rechnergestützte Gruppenarbeit - Eine
Einführung in Verteilte Anwendungen, Springer, Berlin / Heidelberg 1998
[Bornschein-Grass 1995]
Bornschein-Grass, Carin: Groupware und computergestützte Zusammenarbeit - Wirkungsbereiche und Potentiale, Deutscher Universitäts-Verlag, Wiesbaden 1995
[Burger 1997]
Burger, Cora: Groupware - Kooperationsunterstützungen für verteilte Anwendungen,
dpunkt.verlag, Heidelberg 1997
[Cadiz et al. 2002]
Cadiz, Jonathan J.; Venolia, Gina; Jancke, Gavin; Gupta, Anoop: Designing and deploying an information awareness interface, in: CSCW '02: Proceedings of the 2002
ACM conference on Computer supported cooperative work, ACM Press, New York
2002, S. 314-323
88
[Carroll et al. 2003]
Carroll, John M.; Neale, Dennis C.; Isenhour, Philip L.; Rosson, Mary Beth;
McCrickard, D. Scott: Notification and awareness: synchronizing task-oriented collaborative activity, in: International Journal of Human-Computer Studies, Volume
58, Issue 5, Elsevier, Amsterdam 2003, S. 605-632
[Christein/Schulthess 2002]
Christein, Holger; Schulthess, Peter: A General Purpose Model for Presence Awareness, in: Distributed Communities on the Web: 4th International Workshop, DCW
2002, Sydney, Australia, April 3-5, 2002. Revised Papers, Springer, Berlin / Heidelberg 2002, S. 24-34
[Convertino et al. 2004]
Convertino, Gregorio; Neale, Dennis C.; Hobby, Laurian; Carroll, John M.; Rosson,
Mary Beth: A laboratory method for studying activity awareness, in: NordiCHI '04:
Proceedings of the third Nordic conference on Human-computer interaction, ACM
Press, New York 2004, S. 313-322
[Dabbish/Kraut 2004]
Dabbish, Laura; Kraut, Robert E.: Controlling interruptions: awareness displays and
social motivation for coordination, in: Proceedings of the 2004 ACM conference on
Computer supported cooperative work, ACM Press, New York 2004, S. 182-191
[Daum 2007]
Daum, Berthold: Rich-Client-Entwicklung mit Eclipse 3.2 - Anwendungen entwickeln mit der Rich Client Platform, 2. Auflage, dpunkt.verlag, Heidelberg 2007
[Davis/Gutwin 2005]
Davis, Scott; Gutwin, Carl: Using relationship to control disclosure in Awareness
servers, in: GI '05: Proceedings of Graphics Interface 2005, Canadian HumanComputer Communications Society, Waterloo, Ontario 2005, S. 145-152
[Dey/Abowd 1999]
Dey, Anind K.; Abowd, Gregory D.: Towards a Better Understanding of Context and
Context-Awareness, Carnegie Mellon University, School of Computer Science, Pittsburgh 1999. Aus: ftp://ftp.cc.gatech.edu/pub/gvu/tr/1999/99-22.pdf am 14.10.2007
89
[Dourish/Bellotti 1992]
Dourish, Paul; Bellotti, Victoria: Awareness and Coordination in Shared Workspaces, in: CSCW '92: Proceedings of the 1992 ACM conference on Computersupported cooperative work, ACM Press, New York 1992, S. 107-114
[Duden 1999]
o. V.: Duden Oxford - Großwörterbuch Englisch, 2. Auflage, Dudenverlag (Bibliographisches Institut & F.A. Brockhaus AG), Mannheim 1999
[Duden 2006]
o. V.: Duden - Die deutsche Rechtschreibung, 24. Auflage, Dudenverlag (Bibliographisches Institut & F.A. Brockhaus AG), Mannheim 2006
[Duden 2007]
o. V.: Duden - Das Fremdwörterbuch, 9. Auflage, Dudenverlag (Bibliographisches
Institut & F.A. Brockhaus AG), Mannheim 2007
[Dunkel/Holitschke 2003]
Dunkel, Jürgen; Holitschke, Andreas: Softwarearchitektur für die Praxis, Springer,
Berlin / Heidelberg 2003
[Dustdar/Gall/Hauswirth 2003]
Dustdar, Schahram; Gall, Harald; Hauswirth, Manfred: Software-Architekturen für
Verteilte Systeme, Springer, Berlin / Heidelberg 2003
[Ellis/Gibbs/Rein 1991]
Ellis, Clarence A.; Gibbs, Simon J.; Rein, Gail: Groupware: some issues and experiences, in: Communications of the ACM, Volume 34, Issue 1, ACM Press, New York
1991, S. 39-58
[Erickson/Kellogg 2000]
Erickson, Thomas; Kellogg, Wendy A.: Social translucence: an approach to designing systems that support social processes, in: ACM Transactions on ComputerHuman Interaction (TOCHI), Volume 7, Issue 1, ACM Press, New York 2000,
S. 59-83
90
[Fogarty/Lai/Christensen 2004]
Fogarty, James; Lai, Jennifer; Christensen, Jim: Presence versus availability: the design and evaluation of a context-aware communication client, in: International Journal of Human-Computer Studies, Volume 61, Issue 3, Elsevier, Amsterdam 2004,
S. 299-317
[Fuchs 1998]
Fuchs, Ludwin: Situationsorientierte Unterstützung von Gruppenwahrnehmung, in:
GMD Research Series, 1998, No. 3, GMD - Forschungszentrum Informationstechnik
GmbH, Sankt Augustin 1998
[Fuchs/Pankoke-Babatz/Prinz 1995]
Fuchs, Ludwin; Pankoke-Babatz, Uta; Prinz, Wolfgang: Supporting cooperative
awareness with local event mechanisms: the groupdesk system, in: ECSCW'95: Proceedings of the fourth conference on European Conference on Computer-Supported
Cooperative Work, Kluwer Academic Publishers, Norwell 1995, S. 247-262
[Goasduff/Forsling 2007]
Goasduff, Laurence; Forsling, Carina: Gartner Predicts Instant Messaging Will Be
De Facto Tool for Voice, Video and Text Chat by The End of 2011, Gartner Press
Release, Egham 21.06.2007. Aus: http://www.gartner.com/it/page.jsp?id=507731 am
20.11.2007
[Godefroid et al. 2000]
Godefroid, Patrice; Herbsleb, James D.; Jagadeesany, Lalita Jategaonkar; Li, Du: Ensuring privacy in presence awareness: an automated verification approach, in: CSCW
'00: Proceedings of the 2000 ACM conference on Computer supported cooperative
work, ACM Press, New York 2000, S. 59-68
[Greenberg 1991]
Greenberg, Saul: Computer-supported cooperative work and groupware, in: Greenberg, Saul (ed.): Computer-supported Cooperative Work and Groupware, Academic
Press, London 1991
91
[Gross/Stary/Totter 2005]
Gross, Tom; Stary, Chris; Totter, Alex: User-Centered Awareness in ComputerSupported Cooperative Work-Systems - Structured Embedding of Findings from Social Sciences, in: International Journal of Human-Computer Interaction, Vol. 18, No.
3, Lawrence Erlbaum Associates, Inc., Mahwah 2005, S. 323-360
[Gutwin 1997]
Gutwin, Carl: Workspace Awareness in Real-Time Distributed Groupware, Ph.D.
Dissertation, Department of Computer Science, University of Calgary, Calgary 1997.
Aus: http://hci.usask.ca/publications/1997/gutwin-phd.pdf am 24.10.1997
[Gutwin/Greenberg 1996]
Gutwin, Carl; Greenberg, Saul: Workspace Awareness for Groupware, in: Conference companion on Human factors in computing systems: common ground, ACM
Press, New York 1996, S. 208-209
[Gutwin/Greenberg 1999]
Gutwin, Carl; Greenberg, Saul: The effects of workspace awareness support on the
usability of real-time distributed groupware, in: ACM Transactions on ComputerHuman Interaction (TOCHI), Volume 6, Issue 3, ACM Press, New York 1999, S.
243-281
[Gutwin/Greenberg 2002]
Gutwin, Carl; Greenberg, Saul: A Descriptive Framework of Workspace Awareness
for Real-Time Groupware, in: Computer Supported Cooperative Work (CSCW),
Volume 11, Numbers 3-4, Spinger Netherlands, Dordrecht 2002, S. 411-446
[Gutwin/Greenberg 2004]
Gutwin, Carl; Greenberg, Saul: The Importance of Awareness for Team Cognition in
Distributed Collaboration, in: Salas, Eduardo; Fiore, Stephen M. (eds.): Team Cognition: Understanding the Factors that Drive Process and Performance, APA Press,
Washington 2004, S. 177-201
[Gutwin/Penner/Schneider 2004]
Gutwin, Carl; Penner, Reagan; Schneider, Kevin: Group awareness in distributed
software development, in: CSCW '04: Proceedings of the 2004 ACM conference on
Computer supported cooperative work, ACM Press, New York 2004, S. 72-81
92
[Gutwin et al. 2005]
Gutwin, Carl; Greenberg, Saul; Blum, Roger; Dyck, Jeff: Supporting Informal Collaboration in Shared-Workspace Groupware, Technical Report HCI-TR-05-01,
Computer Science Department, University of Saskatchewan, 2005. Aus:
http://hci.usask.ca/publications/2005/hci-tr-05-01.pdf am 04.07.2007
[Hasenkamp/Syring 1994]
Hasenkamp, Ulrich; Syring, Michael: CSCW - Computer Supported Cooperative
Work in Organisationen - Grundlagen und Probleme, in: Hasenkamp, Ulrich; Kirn,
Stefan; Syring, Michael (Hrsg.): CSCW - Computer Supported Cooperative Work Informationssysteme für dezentralisierte Unternehmensstrukturen, Addison-Wesley,
Bonn 1994
[Heath et al. 2002]
Heath, Christian; Svensson, Marcus Sanchez; Hindmarsh, Jon; Luff, Paul; vom
Lehm, Dirk: Configuring Awareness, in: Computer Supported Cooperative Work
(CSCW), Volume 11, Numbers 3-4, Springer Netherlands, Dordrecht 2002,
S. 317-347
[Heerwagen et al. 2004]
Heerwagen, Judith H.; Kampschroer, Kevin; Powell, Kevin M.; Loftness, Vivian:
Collaborative knowledge work environments, in: Building Research and Information, Vol. 32, No. 6, Spon Press, London 2004, S. 510-528
[Hill/Gutwin 2005]
Hill, Jason; Gutwin, Carl: The MAUI Toolkit: Groupware Widgets for Group
Awareness, in: Computer Supported Cooperative Work (CSCW), Volume 13, Numbers 5-6, Springer Netherlands, Dordrecht 2005, S. 539-571
[Hoffmann 2004]
Hoffmann, Marcel: Awareness und Adoption kooperativer Wissensmedien im Kontext informeller Zusammenarbeit, Dissertation, Fachbereich Informatik der Universität Dortmund, Dortmund 2004. Aus: https://eldorado.unidortmund.de/bitstream/2003/19663/1/MarcelHoffmannunt.pdf am 23.10.2007
93
[Holmer/Haake/Streitz 2001]
Holmer, Torsten; Haake, Jörg; Streitz, Norbert: Kollaborationsorientierte synchrone
Werkzeuge, in: Schwabe, Gerhard; Streitz, Norbert; Unland, Rainer (Hrsg.): CSCWKompendium - Lehr- und Handbuch zum computerunterstützten kooperativen Arbeiten, Springer, Berlin / Heidelberg 2001, S. 180-193
[Hudson/Smith 1996]
Hudson, Scott E.; Smith, Ian: Techniques for addressing fundamental privacy and
disruption tradeoffs in awareness support systems, in: CSCW '96: Proceedings of the
1996 ACM conference on Computer supported cooperative work, ACM Press, New
York 1996, S. 248-257
[Isaacs et al. 2002]
Isaacs, Ellen; Walendowski, Alan; Whittaker, Steve; Schiano, Diane J.; Kamm, Candace: The character, functions, and styles of instant messaging in the workplace, in:
CSCW '02: Proceedings of the 2002 ACM conference on Computer supported cooperative work, ACM Press, New York 2002, S. 11-20
[Isermann 2004]
Isermann, Oliver: Traditionelle und virtuelle Teams - Theoretischer Vergleich und
empirische Analyse traditioneller und virtueller Kooperationsformen, Verlag D.
Kovač, Hamburg 2004
[Jehøj/Bouvin/Grønbæk 2005]
Jehøj, Henning Qin; Bouvin, Niels Olof; Grønbæk, Kaj: AwareDAV: A Generic
WebDAV Notification Framework and Implementation, in: Proceedings of the 14th
international conference on World Wide Web, ACM Press, New York 2005,
S. 180-189
[Johansen 1988]
Johansen, Robert: Groupware - Computer Support for Business Teams, The Free
Press, New York 1988
[Khoshafian/Buckiewicz 1995]
Khoshafian, Setrag; Buckiewicz, Marek: Introduction to Groupware, Workflow, and
Workgroup Computing, John Wiley & Sons, New York 1995
94
[Koch 1997]
Koch, Michael: Unterstützung kooperativer Dokumentenbearbeitung in Weitverkehrsnetzen, Dissertation, Fakultät für Informatik der Technischen Universität München, München 1997. Aus: http://www.communixx.de/files/Koch1997.pdf am
20.11.2007
[Mackay 1999]
Mackay, Wendy E.: Media Spaces: Environments for Informal Multimedia Interaction, in: Beaudouin-Lafon, Michel (ed.): Trends in Software - Computer Supported
Co-operative Work, John Wiley & Sons Ltd, Chichester 1999, S. 55-82
[Nardi/Whittaker/Bradner 2000]
Nardi, Bonnie A.; Whittaker, Steve; Bradner, Erin: Interaction and outeraction: instant messaging in action, in: CSCW '00: Proceedings of the 2000 ACM conference on Computer supported cooperative work, ACM Press, New York 2000,
S. 79-88
[Nastansky et al. 2002]
Nastansky, Ludwig; Bruse, Thomas; Haberstock, Philipp; Huth, Carsten; Smolnik,
Stefan: Büroinformations- und Kommunikationssysteme: Groupware, Workflow
Management, Organisationsmodellierung und Messaging-Systeme, in: Fischer, Joachim; Herold, Werner; Dangelmaier, Wilhelm; Nastansky, Ludwig; Suhl, Leena:
Bausteine der Wirtschaftsinformatik - Grundlagen, Anwendungen, PC-Praxis, 3. Auflage, Erich Schmidt Verlag, Berlin 2002, S. 235-322
[Neale/Carroll/Rosson 2004]
Neale, Dennis C.; Carroll, John M.; Rosson, Mary Beth: Evaluating computersupported cooperative work: models and frameworks, in: CSCW '04: Proceedings of
the 2004 ACM conference on Computer supported cooperative work, ACM Press,
New York 2004, S. 112-121
[Nielsen et al. 2002]
Nielsen, Søren Peter; Jürgensen, Volker; Menashes, Rami; Patton, Tony; Schejter,
Marjorie: Working with the Sametime Client Toolkits, IBM International Technical
Support Organization, Poughkeepsie 2002. Aus:
http://www.redbooks.ibm.com/abstracts/sg246666.html?Open am 09.10.2007
95
[Oberquelle 2001]
Oberquelle, Horst: Softwareergonomie, in: Schwabe, Gerhard; Streitz, Norbert; Unland, Rainer (Hrsg.): CSCW-Kompendium - Lehr- und Handbuch zum computerunterstützten kooperativen Arbeiten, Springer, Berlin / Heidelberg 2001, S. 87-97
[Otjacques et al. 2006]
Otjacques, Benoît; Noirhomme, Monique; Gobert, Xavier; Feltz, Fernand: Cooperation Indexes to Support Workspace Awareness, in: Groupware: Design, Implementation, and Use - 12th International Workshop, CRIWG 2006, Medina del Campo,
Spain, September 17-21, 2006, Springer, Berlin / Heidelberg 2006, S. 94-101
[Patil/Lai 2005]
Patil, Sameer; Lai, Jennifer: Who gets to know what when: configuring privacy permissions in an awareness application, in: CHI '05: Proceedings of the SIGCHI conference on Human factors in computing systems, ACM Press, New York 2005,
S. 101-110
[Pankoke-Babatz/Syri 1997]
Pankoke-Babatz, Uta; Syri, Anja: Collaborative workspace for time deferred electronic cooperation, in: GROUP '97: Proceedings of the international ACM SIGGROUP conference on Supporting group work, ACM Press, New York 1997,
S. 187-196
[Pankoke-Babatz/Prinz/Schäfer 2004a]
Pankoke-Babatz, Uta; Prinz, Wolfgang; Schäfer, Leonie: Was gibt's Neues? Asynchrone Gewärtigkeit, in: Keil-Slawik, Reinhard; Selke, Harald; Szwillus, Gerd
(Hrsg.): Mensch & Computer 2004 - Allgegenwärtige Interaktion, Oldenbourg,
München 2004, S. 271-280
[Pankoke-Babatz/Prinz/Schäfer 2004b]
Pankoke-Babatz, Uta; Prinz, Wolfgang; Schäfer, Leonie: Stories about Asynchronous Awareness, in: Darses, Francoise; Dieng, Rose; Simone, Carla; Zacklad,
Manuel (eds.): Cooperative Systems Design - Scenario-Based Design of Collaborative Systems, IOS Press, Amsterdam 2004, S. 23-38
96
[Pedersen/Sokoler 1997]
Pedersen, Elin Rønby; Sokoler, Tomas: AROMA: abstract representation of presence
supporting mutual awareness, in: CHI '97: Proceedings of the SIGCHI conference on
Human factors in computing systems, ACM Press, New York 1997, S. 51-58
[Ploch 2007]
Ploch, Holger: Projekt-Homepage - GCC Grading Management Homepage, Groupware Competence Center, Paderborn 2007.
Aus: http://gcc.upb.de/K-Pool/GradingManagement am 30.11.2007
[Posch/Birken/Gerdom 2004]
Posch, Torsten; Birken, Klaus; Gerdom, Michael: Basiswissen Softwarearchitektur Verstehen, entwerfen, bewerten und dokumentieren, dpunkt.verlag, Heidelberg 2004
[Prinz 2001]
Prinz, Wolfgang: Awareness, in: Schwabe, Gerhard; Streitz, Norbert; Unland, Rainer
(Hrsg.): CSCW-Kompendium - Lehr- und Handbuch zum computerunterstützten kooperativen Arbeiten, Springer, Berlin / Heidelberg 2001, S. 335-350
[Prinz 2002]
Prinz, Wolfgang: NESSIE: An Awareness Environment for Cooperative Settings, in:
ECSCW'99: Proceedings of the sixth conference on European Conference on Computer Supported Cooperative Work, Springer Netherlands, Dordrecht 2002,
S. 391-410
[Reppesgaard/Bialluch 2007]
Reppesgaard, L.; Bialluch, M.: Gedankenaustausch per Computer, Handelsblatt.com
(ECONOMY.ONE GmbH), Düsseldorf 10.08.2007. Aus:
http://www.handelsblatt.com/news/Technologie/IT-TrendsInternet/_pv/_p/204016/_t/ft/_b/1307103/default.aspx/gedankenaustausch-percomputer.html am 25.11.2007
[Riemer/Arendt/Wulf 2005]
Riemer, Kai; Arendt, Patrick; Wulf, Andreas: Marktstudie Kooperationssysteme Von E-Mail über Groupware zur Echtzeitkooperation, Cuvillier Verlag, Göttingen
2005
97
[Rodden 1996]
Rodden, Tom: Populating the application: a model of awareness for cooperative applications, in: Proceedings of the 1996 ACM conference on Computer supported cooperative work, ACM Press, New York 1996, S. 87-96
[Rodriguez et al. 2007]
Rodriguez, Juan R.; Coqueiro, Alex Barbosa; Agudo, Belen Gonzalez; Patel, Sunil;
Ricardo, Rossi; Sanchez, Rafael; Schneider, Robert; Villavicencio, Guillermo;
Whorley, Art; Zink, Michael: Building Composite Applications, IBM International
Technical Support Organization, Poughkeepsie 2007. Aus:
http://www.redbooks.ibm.com/abstracts/sg247367.html am 10.10.2007
[Schaar 2002]
Schaar, Peter: Datenschutz im Internet - Die Grundlagen, Verlag C.H. Beck, München 2002
[Schlichter/Koch/Bürger 1998]
Schlichter, Johann; Koch, Michael; Bürger, Martin: Workspace awareness for distributed teams, in: Conen, Wolfram; Neumann, Gustaf (eds.): Coordination Technology for Collaborative Applications - Organizations, Processes, and Agents, Springer,
Berlin / Heidelberg 1998, S. 199-218
[Schmalzl/Imbery/Merkl 2004]
Schmalzl, Bernhard; Imbery, Holger; Merkl, Andreas: Virtuelle Teams - So fern und
doch so nahe, in: Schmalzl, Bernhard (Hrsg.): Arbeit und elektronische Kommunikation der Zukunft - Methoden und Fallstudien zur Optimierung der Arbeitsplatzgestaltung, Springer, Berlin / Heidelberg 2004, S. 523-539
[Schmidt 2002]
Schmidt, Kjeld: The Problem with 'Awareness' - Introductory Remarks on 'Awareness in CSCW', in: Computer Supported Cooperative Work (CSCW), Volume 11,
Numbers 3-4, Springer Netherlands, Dordrecht 2002, S. 285-298
[Senst 2001]
Senst, Erik: Virtuelle-Teamarbeit - Ein Lernprogramm im Medienverbund zur Einrichtung und Betreuung virtueller Teams, Sensed-Media, Kiel 2001
98
[Sohlenkamp 1999]
Sohlenkamp, Markus: Supporting Group Awareness in Multi-User Environments
through Perceptualization, in: GMD Research Series, 1999, No. 6, GMD - Forschungszentrum Informationstechnik GmbH, Sankt Augustin 1999
[Sohlenkamp/Chwelos 1994]
Sohlenkamp, Markus; Chwelos, Greg: Integrating communication, cooperation, and
awareness: the DIVA virtual office environment, in: CSCW '94: Proceedings of the
1994 ACM conference on Computer supported cooperative work, ACM Press, New
York 1994, S. 331-343
[Sohlenkamp/Prinz/Fuchs 2000]
Sohlenkamp, Markus; Prinz, Wolfgang; Fuchs, Ludwin: PoliAwac: design and
evaluation of an awareness-enhanced groupware client, in: AI & Society, Volume
14, Number 1, Springer, London 2000, S. 31-47
[Stahlknecht/Hasenkamp 2005]
Stahlknecht, Peter; Hasenkamp, Ulrich: Einführung in die Wirtschaftsinformatik, 11.
Auflage, Springer, Berlin / Heidelberg 2005
[Steinfield/Jang/Pfaff 1999]
Steinfield, Charles; Jang, Chyng-Yang; Pfaff, Ben: Supporting virtual team collaboration: The TeamSCOPE system, in: GROUP '99: Proceedings of the international
ACM SIGGROUP conference on Supporting group work, ACM Press, New York
1999, S. 81-90
[Tam/Greenberg 2006]
Tam, James; Greenberg, Saul: A framework for asynchronous change awareness in
collaborative documents and workspaces, in: International Journal of HumanComputer Studies, Volume 64, Issue 7, Elsevier, Amsterdam 2006, S. 583-598
[Tee/Greenberg/Gutwin 2006]
Tee, Kimberly; Greenberg, Saul; Gutwin, Carl: Providing artifact awareness to a distributed group through screen sharing, in: CSCW '06: Proceedings of the 2006 20th
anniversary conference on Computer supported cooperative work, ACM Press, New
York 2006, S. 99-108
99
[ter Hofte et al. 2002]
ter Hofte, G. Henri; Mulder, Ingrid; Grootveld, Marjan; Slagter, Robert: Exploring a
design space for place-based presence, Telematica Instituut, Enschede 2002
[ter Hofte/Mulder/Verwijs 2005]
ter Hofte, G. Henri; Mulder, Ingrid; Verwijs, Carla: Close encounters of the virtual
kind: a study on place-based presence, in: AI & Society, Volume 20, Number 2,
Springer London, London 2005, S. 151-168
[Teufel et al. 1995]
Teufel, Stephanie; Sauter, Christian; Mühlherr, Thomas; Bauknecht, Kurt: Computerunterstützung für die Gruppenarbeit, Addison-Wesley, Bonn 1995
[Tran/Yang/Raikundalia 2005]
Tran, Minh Hong; Yang, Yun; Raikundalia, Gitesh K.: Supporting awareness in instant messaging: an empirical study and mechanism design, in: ACM International
Conference Proceeding Series (Vol. 122) - Proceedings of the 19th conference of the
computer-human interaction special interest group (CHISIG) of Australia on Computer-human interaction: citizens online: considerations for today and the future,
Computer-Human Interaction Special Interest Group (CHISIG) of Australia, Narrabundah 2005, S. 1-10
[Voida/Newstetter/Mynatt 2002]
Voida, Amy; Newstetter, Wendy C.; Mynatt, Elizabeth D.: When conventions collide: the tensions of instant messaging attributed, in: Proceedings of the SIGCHI conference on Human factors in computing systems: Changing our world, changing ourselves, ACM Press, New York 2002, S. 187-194
[Yee/Park 2005]
Yee, Susan; Park, Kat S.: StudioBRIDGE: using group, location, and event information to bridge online and offline encounters for co-located learning groups, in: CHI
'05: Proceedings of the SIGCHI conference on Human factors in computing systems,
ACM Press, New York 2005, S. 551-560
100
9 Anhang
An dieser Stelle werden einzelne, zentrale Aspekte des realisierten Prototyp vorgestellt.
Dazu gehören wichtige Fragmente des Quellcodes, Beispiele der Thread-Interaktionen
und Objektbeziehungen, eine kurze Darstellung der PBA-Management-Datenbank
sowie eine Klassenübersicht der PBA-Komponente. Als Grundlage dient dabei eine
vorhandene und konfigurierte Infrastruktur, wie sie in der Installationsanleitung der
beiliegenden CD beschrieben ist (siehe Installation-Ordner der Begleit-CD).
Die folgenden Ausführungen orientieren sich einerseits an dem Einsatzszenario
„Grading Management System“ (siehe Kapitel 5.2) und andererseits an den drei Phasen
– Bereitstellung, Verteilung und Präsentation – zur Erzeugung von AwarenessInformationen (siehe Kapitel 2.2.3 und 3.5.3).
Einen vollständigen Überblick über alle realisierten Klassen und Funktion im PBAEclipse-Plugin bietet eine entsprechende API (siehe Prototyp\doc-Ordner der BegleitCD).
9.1 Bereitstellung von Awareness-Informationen
Obwohl eine sachgerechte Integration des PBA-Systems in eine Anwendungsumgebung
wie das Grading Management System im Rahmen dieser Arbeit nicht erfolgt ist (siehe
Kapitel 6), wurden allerdings die notwendigen Schnittstellen hierzu realisiert und auf
ihre funktionale Korrektheit überprüft. Dazu gehört eine LotusScript-Library, die in die
entsprechende Anwendungs-Datenbank eingebunden werden muss (siehe Installationsanleitung).
Die Methoden der PBA-LotusScript-Library stellen sicher, dass AwarenessInformationen, die beispielsweise durch das Öffnen der Grading-ManagementDatenbank oder bei der Durchführung von Modulbewertungen entstehen, an den
Property Broker übergeben werden können. Die folgende Abbildung zeigt eine dieser
Methoden für den Fall des Starts einer zeitraumbezogenen Aktion, wie z. B. dem
Editieren einer Modulbewertung.
101
Abbildung 33 - Die Methode PBAStart in der PBA-LotusScript-Library
Über entsprechende Wires und den Property Broker erfolgt im Rahmen einer Composite
Application die Übermittlung der generierten Awareness-Daten von der AnwendungsKomponente (GMS) an die PBA-Komponente (Eclipse-Plugin).
Abbildung 34 - Wires zwischen Anwendungs- und PBA-Komponente
102
9.2 Verteilung von Awareness-Informationen
In diesem Kapitel wird neben dem Aspekt der Verteilung von Awareness-Daten
zwischen mehreren Anwendern der Fokus auf die Verarbeitung dieser Daten und die
Abhängigkeiten und Strukturen innerhalb der PBA-Komponente gelegt.
In Kapitel 4.3 wurden bereits die unterschiedlichen Properties vorgestellt, die über die
entsprechenden Schnittstellen und den Property Broker von der jeweiligen Applikation
an die PBA-Komponente übertragen werden. Die folgende Abbildung zeigt in diesem
Zusammenhang wie in diesem Fall das PBAStart-Property in der PBA-Komponente
entgegen genommen wird.
Abbildung 35 - Code zum Empfangen eines PBAStart-Property
Die vorangehende Abbildung zeigt bereits zwei wesentliche Aspekte der Architektur
des realisierten Prototyp. Zum einen werden eingehende Awareness-Daten in Form von
Properties in Event-Objekten (hier: PBAPropertyEvent) gekapselt, zum anderen
existieren unterschiedliche Threads mit jeweils eigenen Puffern (hier: EventVectors),
die Verteilungs-, Archivierungs- und Präsentationsaufgaben übernehmen und steuern.
Die folgende Tabelle zeigt eine Übersicht über die unterschiedlichen Event-Klassen
(siehe auch Kapitel 4.4).
103
Event-Klasse
Funktion
PBAProperty
Kapselt die Awareness-Daten von eingehenden Properties
PBAPlaceAction
Setzt Action-Objekte und Place-Objekte in einen gemeinsamen
Kontext
PBAPlaceSubscription
Enthält Informationen über Abonnements-Änderungen
Tabelle 12 - Event-Klassen in der PBA-Eclipse-Komponente
Die folgende Tabelle gibt einen Überblick über die realisierten Threads und ihre
zentralen Aufgaben (siehe auch Kapitel 4.2).
Thread
Zentrale Aufgaben
UI
ƒ Grafische Darstellung der Awareness-Daten
ƒ Benutzerschnittstelle
ƒ Entgegennahme von Properties, Erzeugung von PBAPropertyEvents und
Ablage dieser im Puffer des Main-Thread
ƒ Erzeugung von PBAPlaceSubscriptionEvents und Ablage dieser im Puffer
des Main-Thread
Main
ƒ Entgegennahme von PBAPropertyEvents und Erzeugung von ActionObjekten
ƒ Kombination von Action- und Place-Objekten zu PBAPlaceAction-Events
ƒ Verteilung der PBAPlaceAction-Events (bzw. auch
PBAPlaceSubscriptionEvents) in die Puffer des Management- und
Sametime-Threads (ggfs. hierarchische Beziehungen über rekursive Aufrufe sicherstellen)
Management
ƒ Einlesen der Place-Informationen aus PBA-Management-DB
ƒ Einlesen/Schreiben von Mitgliedschafts-Informationen in/aus PBAManagement-DB
ƒ Entgegennahme von PBAPlaceActionEvents (bzw. auch
PBAPlaceSubscriptionEvents)
ƒ Schreiben von Log-Einträgen in PBA-Management-DB
Sametime
ƒ Entgegennahme von PBAPlaceActionEvents (bzw. auch
PBAPlaceSubscriptionEvents)
ƒ Erzeugen von Places in Lotus-Sametime-Umgebung
ƒ Auslösen und Entgegennahme von Lotus-Sametime-Events, um
Awareness-Daten zwischen Anwendern auszutauschen
ƒ Erzeugung und Modifikation von zwei Baumstrukturen (gegliedert nach
Places bzw. nach Usern)
Tabelle 13 - Zentrale Aufgaben der Threads in der PBA-Eclipse-Komponente
104
Die folgende Abbildung zeigt wie im Main-Thread nach Erhalt eines neuen PBAPropertyEvents, das ein PBAStart-Property beschreibt, neue PBAPlaceActionEvents
generiert und in die Puffer der anderen Thread geschrieben werden. Hierarchische
Place-Beziehungen werden in Form von rekursiven Aufrufen überprüft und aktualisiert.
Abbildung 36 - startAction-Methode des Main-Threads (1)
105
Abbildung 37 - startAction-Methode des Main-Threads (2)
106
Die folgenden beiden Abbildungen zeigen, wie die PBAPlaceActionEvents und die
PBAPlaceSubscriptionEvents – am Beispiel des Management-Threads – entgegen
genommen werden. Der entsprechende Code befindet sich in der while-Schleife am
Ende der run()-Methode.
Abbildung 38 - run()-Methode des Management-Threads
107
Die Methoden zum Füllen bzw. Leeren des Event-Puffers des Management-Threads
sind in der folgenden Abbildung dargestellt.
Abbildung 39 - Methoden zum Füllen/Leeren des Management-Thread-Puffers
108
Über den Sametime-Thread werden Awareness-Daten verschiedener Anwender in Form
von Events über den PlacesService von Lotus Sametime verbreitet bzw. empfangen. Die
eingehenden Daten (bzw. die daraus generierten Objekte) werden in zwei Baumstrukturen verwaltet (siehe auch Kapitel 4.5).
Die folgende Abbildung zeigt die Objekt-Typen, denen die Bäume zugrunde liegen. In
einem PBAActionOfUserInPlace-Objekt ist beispielsweise eine bestimmte Aktion eines
bestimmten User im Kontext eines bestimmten Place erfasst. Es werden somit zugehörige PBAAction-, PBAUser- und PBAPlace-Objekte gekapselt.
Abbildung 40 - Objektbeziehungen in den beiden Baumstrukturen
109
Die folgende Abbildung zeigt den Code, über den ein neuer Place-Knoten in den
TreePlaces hinzugefügt wird. Ausgelöst wird dies über ein entsprechendes Event des
PlacesServices von Lotus Sametime, nachdem der aktuelle Anwender einen entsprechenden Place in der Lotus-Sametime-Umgebung betreten möchte.
Abbildung 41 - entered-Methode des Sametime-Threads
110
In Kapitel 4.1.3 wurde bereits darauf hingewiesen, dass die Verteilung von Informationen
über Aktionen zwischen Anwendern durch Hinzufügen, Modifizieren und Löschen von
User-Attributen über das Places-Modell von Lotus Sametime erfolgt. Die folgende Abbildung zeigt die Auswirkungen eines Changed-Events eines User-Attributes in Form von
Modifikationen der Knoten- und Blattelemente der beiden Baumstrukturen.
Abbildung 42 - handleAttributeActionEvent-Methode des Sametime-Threads (1)
111
Abbildung 43 - handleAttributeActionEvent-Methode des Sametime-Threads (2)
112
9.3 Präsentation von Awareness-Informationen
Auf die Benutzeroberfläche und die zur Verfügung stehenden Funktionen wurde bereits
in den Kapiteln 4.5 und 4.6 näher eingegangen. Eine Ergänzung hierzu bildet die
folgende Auflistung der verwendeten Icons und ihrer Bedeutung.
Icon
Erläuterung
Einsatz in der/den Ansicht(en)
Place-Icon bei Offline-Status des aktuellen Anwenders (d. h. der
Plätze, Benutzer
Anwender besitzt in Lotus Sametime den Status „offline“)
Folge:
Keine gegenseitige Sichtbarkeit von Awareness-Informationen.
Place-Icon bei Online-Status des aktuellen Anwenders (d. h. der
Plätze, Benutzer
Anwender besitzt in Lotus Sametime nicht den Status „offline“,
sondern beispielsweise „online“ oder „away“)
Folge:
Gegenseitige Sichtbarkeit von Awareness-Informationen.
Place-Icon, falls der aktuelle Anwender einen Place explizit nicht
Plätze, Benutzer
abonniert hat.
Folge:
Weder sind die eigenen Aktionen für andere Anwender sichtbar,
noch die Aktionen der Anderen für den aktuellen Anwender. Eine
Protokollierung findet allerdings trotzdem statt.
Ein Place wird betreten.
Historie
Ein Place wird verlassen.
Historie
Eine Action wird gestartet.
Historie
Eine Action wird gewechselt.
Historie
Eine Action wird beendet.
Historie
Bei der Action handelt es sich um einen Lesevorgang.
Plätze, Benutzer, Historie
Bei der Action handelt es sich um einen Editiervorgang.
Plätze, Benutzer, Historie
Bei der Action handelt es sich um einen Speichervorgang.
Plätze, Benutzer, Historie
Die betreffende Spalte ist aufsteigend sortiert.
Historie
Die betreffende Spalte ist absteigend sortiert.
Historie
Die betreffende Spalte bildet nicht das Sortierkriterium.
Historie
Tabelle 14 - Eingesetzte Icons und ihre Bedeutung
113
9.4 PBA-Management-DB
In der PBA-Management-DB sind sowohl Place- und Mitgliedschafts-Informationen als
auch Abonnementseinstellungen und Log-Einträge zentral gespeichert.
Die folgende Abbildung zeigt für das beschriebene Szenario „Grading Management
System“ (siehe Kapitel 5) eine Auflistung der Dokumente von aktiven Places.
Abbildung 44 - Liste der aktiven Places in der PBA-Management-DB
Die folgende Abbildung zeigt ein geöffnetes Place-Dokument.
Abbildung 45 - Ein Place-Dokument in der PBA-Management-DB
In Mitgliedschafts-Dokumenten, die automatisch beim erstmaligen Betreten eines Place
angelegt werden, können anwenderspezifische Einstellungen für einen Place gespeichert
werden (siehe Kapitel 3.5.2).
114
Abbildung 46 - Liste der Mitgliedschafts-Dokumente in der PBA-Management-DB
Im konkreten Beispiel ist für den Anwender Heiko Strathkötter der Place „W2301-2
GIA“ dauerhaft abonniert (Standardeinstellung). Die Referenz auf das zugehörige
Place-Dokument erfolgt über die entsprechende DocumentUNID.
Abbildung 47 - Ein Mitgliedschafts-Dokument in der PBA-Management-DB
115
Des Weiteren sind in der PBA-Management-DB auch Log-Einträge gespeichert.
Abbildung 48 - Liste der Log-Einträge in der PBA-Management-DB
Abbildung 49 - Ein Log-Eintrag in der PBA-Management-DB
116
9.5 Klassenübersicht der PBA-Komponente
Abbildung 50 - Übersicht über alle Java-Klassen der PBA-Komponente
117
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbständig und nur
unter Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Paderborn, den 05.12.2007
___________________________
Heiko Strathkötter