1 Computer Supported Cooperative Work (CSCW) – Kollaborative … · 2013. 9. 18. · „Computer...

1 Computer Supported Cooperative Work (CSCW) – Kollaborative Systeme und Anwendungen

Das folgende Kapitel geht auf das interdisziplinäre Forschungsgebiet Computer Supported Cooperative Work (CSCW) ein und beschreibt den Einsatz von CSCW Systemen in Bezug auf die Medieninformatik. Zunächst wird der Begriff „CSCW“ in diesem Zusammenhang definiert.

CSCW Systeme kann man in Anwendungsbereiche und Synchronisationstypen einordnen. Nach der Begriffsdefinition und der Einordnung der CSCW in die Medieninformatik werden die folgenden drei Anwendungsbereiche anhand einer Reihe von Beispielen vorgestellt. Neben dem Einsatzzweck des jeweiligen Systems wird auch auf die Prinzipien der technischen Realisierung solcher Systeme eingegangen. Dem/der Leser/-in soll damit ein grundsätzliches Verständnis für den technischen Aufbau und die Funktionsweise kollaborativer Systeme vermittelt werden:

1. Groupware und Workgroup Computing 2. Versionsverwaltung 3. Mehrbenutzer Editoren

Folgende Synchronisationstypen können dabei festgestellt

werden:

Eingruppierung der CSCW Systeme

1. Synchron 2. Asynchron 3. Multisynchron

1.1

1

Synchrone Systeme unterstützen das gleichzeitige Arbeiten mehrerer Personen im selben Bereich oder auf denselben Datenobjekten. Dies ist zum Beispiel bei Chat-Systemen oder den meisten Mehrbenutzer-Editoren der Fall. Bei asynchronen Systemen arbeiten mehrere Personen „nacheinander“ auf einem oder mehreren Datenobjekten. Es ist also kein gleichzeitiger Zugriff (z.B. lesend oder schreibend) auf eine Ressource oder einen Bereich möglich. wie zum Beispiel bei verschiedenen Versionsverwaltungs- oder Groupware Systemen. Multisynchrone Systeme erlauben das gleichzeitige Arbeiten auf einer Kopie desselben Datenobjekts, wobei das Datenobjekt im Nachhinein synchronisiert wird, also zwischen asynchronen und synchronen Modus umgeschaltet wird. Dieser Wechsel zwischen Synchronisationstypen geschieht meist automatisch, kann bei manchen Systemen aber auch manuell vorgenommen werden. Es gibt Multiuser-Editoren (wie z.B. SAMS[1]), die das manuelle Umschalten zwischen verschiedenen Synchronisationstypen erlauben.

Die Einordnung von CSCW Systemen in Groupware, Versionsverwaltung und Mehrbenutzer Editoren in diesem Kapitel, dient der Gliederung, ist aber in manchen Fällen nicht eindeutig möglich. Manche CSCW Systeme haben Eigenschaften, die zum Beispiel sowohl einer Groupware als auch einer Versionsverwaltung entsprechen. Manche Mehrbenutzer Editoren integrieren zum Beispiel eine Versionsverwaltung. Auch können innerhalb eines CSCW Systems verschiedene Synchronisationstypen festgestellt werden. Die Abbildung 1 zeigt die verschiedenen CSCW Anwendungsbereiche und Synchronisationstypen.

Abbildung 1: CSCW Anwendungsbereiche und

Synchronisationstypen in der Übersicht

1 CSys2

Synchron Asynchron Multisynchron

Versionsverwaltung

Groupware& Workgroup

Computing

Kollaborative Mehrbenutzer Editoren

omputer Supported Cooperative Work (CSCW) – Kollaborative teme und Anwendungen

Das Unterkapitel „Architektur kollaborativer Systeme“ ist ergänzend zum Kapitel „Verteilte Systeme“ zu sehen und soll dem/der Leser/-in einen Überblick über die Grundprinzipien der Architektur solcher CSCW Systeme geben, bei denen es sich um verteilte Systeme handelt.

Bei CSCW Systemen nimmt die Kommunikation von Menschen einen besonderen Stellenwert ein. Daher sollte hier besonderes Augenmerk auf die Software-Ergonomie und die Bewusstheit, die sogenannte „Awareness“ gelegt werden. Das Unterkapitel

Awareness in kollaborativen Systemen befasst sich damit. Zum Abschluss des Kapitels wird ein Ausblick auf mögliche zukünftige Entwicklungen und potenzielle neue Einsatzgebiete der CSCW gegeben.

1.1 Begriffsdefinition CSCW

Durch den technischen Fortschritt vor allem im Bereich der Computertechnologie, Netzwerktechnik und Telekommunikation wurden neue Möglichkeiten der Zusammenarbeit geschaffen. Heutzutage erlaubt die weltweite Vernetzung von Computern mehr Effizienz in der gemeinschaftlichen Bewältigung einer Aufgabe, selbst über weite Entfernungen hinweg.

Das Forschungsgebiet der computerunterstützten Zusammenarbeit (Computer Supported Cooperative Work) beschäftigt sich mit der Nutzung dieser Technologien, um die Arbeitsweise von Menschen an einer gemeinsamen Aufgabe zu verbessern und die Arbeit effizienter und einfacher zu gestalten. CSCW ist ein Forschungsgebiet das in vielen Disziplinen wie der Soziologie, Psychologie, Arbeits- und Organisationswissenschaften, Management, Ethnologie, Anthropologie, Wirtschaftswissenschaften und nicht zuletzt der Informatik behandelt wird.

CSCW ist ein multidisziplinäres Forschungsgebiet

In der Literatur findet man mehrere Definitionen für den Begriff „Computer Supported Cooperative Work“. Angeblich erstmals erwähnt von Irene Greif und Cashman (1984)1 wird der Begriff CSCW von Paul Wilson (1991) folgendermaßen beschrieben:

„CSCW is a generic term that combines the understanding of the way people work in groups with the enabling technologies of computer networking and associated hardware, software, services and techniques” [2]

1 Quelle: http://de.wikipedia.org/wiki/CSCW

1.1 Begriffsdefinition CSCW 3

Mit dieser Definition umfasst der Begriff CSCW verschiedenste Disziplinen wie Soziologie, Arbeitspsychologie, Ethnologie, aber auch die verschiedensten Bereiche der Informatik (z.B. Verteilte Systeme, Informationssysteme, Usability, Künstliche Intelligenz) und der Elektrotechnik. Grudin bestätigt dies (1994), mit der Aussage: „CSCW started as an effort by technologists to learn from economists, social psychologists, anthropologists, organizational theorists, educators and anyone else who could shed light on group activity.” [3]

CSCW ist also ein allgemeiner Begriff, der das „universelle Arbeitsgebiet und die dazugehörigen Forschungsfelder bezeichnet“ [4], die sich mit der computergestützten Zusammenarbeit von Menschen beschäftigen.

In der Literatur finden sich verschiedenste Definitionen von

Groupware und CSCW

Am häufigsten wird im Zusammenhang mit CSCW der Begriff „Groupware“ genannt. Ein oft verwendetes Zitat stammt von Clarence (Skip) Ellis. Er definiert dabei 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." [5]

Damit wäre Groupware also die Bezeichnung für Software-Lösungen und CSCW das allgemeine Forschungsgebiet. Greenberg allerdings definiert 1991 CSCW folgendermaßen:

„CSCW is a scientific discipline that guides the thoughtful and appropriate design and development of computer systems to support group work“ [6]

In der Literatur findet man daher den Begriff Groupware häufig in Verwendung als Synonym zu CSCW.

Dieses Kapitel bezeichnet mit Groupware spezielle Software-Systeme, welche die Zusammenarbeit von Menschen (Teilnehmern) an einer gemeinsamen Aufgabe unterstützen sollen und bei denen das Hauptaugenmerk auf der Kommunikation zwischen den Teilnehmern und der Koordination von Aufgaben liegt. Groupware Systeme sind hier also nur ein Teilbereich des verschiedenste Disziplinen umfassenden Forschungsgebiets CSCW.

Wir definieren CSCW wie folgt:

Mit Computer Supported Cooperative Work (CSCW) wird das verschiedenste Forschungsdisziplinen umfassende Forschungsgebiet bezeichnet, das sich mit der Unterstützung der Zusammenarbeit von

1 Computer Supported Cooperative Work (CSCW) – Kollaborative Systeme und Anwendungen 4

Menschen durch Computertechnologien (Software, Hardware, Infrastruktur) beschäftigt.

Teilbereiche der CSCW beschäftigen sich mit der Entwicklung von verschiedenen Software-Systemen, die diese Zusammenarbeit ermöglichen und verbessern sollen. Diese Teilbereiche sind unter anderem Groupware-, Versionsverwaltungssysteme und Mehrbenutzer Editoren.

Verwirrung stiftet in der Literatur oft die verschiedene Verwendung des Begriffs “Cooperation”. Dieser wird von vielen Autoren oft mit „Collaboration“ gleichgesetzt, andere dagegen unterscheiden die beiden Begriffe sehr wohl, wie zum Beispiel Dillenbourg, Baker et al. 1995:

Die Begriffe Cooperation und Collaboration stiften Verwirrung

“Cooperation and collaboration do not differ in terms of whether or not the task is

distributed, but by virtue of the way in which it is divided; in cooperation the task is split (hierarchically) into independent subtasks; in collaboration cognitive processes may be (heterarchically) divided into intertwined layers. In cooperation, coordination is only required when assembling partial results, while collaboration is“...“a coordinated, synchronous activity that is the result of a continued attempt to construct and maintain a shared conception of a problem.” [7]

In diesem Kapitel wird „Cooperation“ als Synonym zu

„Collaboration“ verwendet, da beide Begriffe ins Deutsche mit „Zusammenarbeit“ übersetzt werden können und um Begriffsverwirrungen zu vermeiden.

1.2 CSCW in der Medieninformatik

Digitale Medien spielen vor allem im Bereich der Groupware eine wichtige Rolle. Angefangen bei einfachen Text Nachrichten, wie sie bei Chats, Newsgroups, RSS Feeds, Email und anderen Diensten eingesetzt werden, über Hypermedia bei Wikis und Weblogs bis hin zu interaktiven Multimedia und Audio-/Video Datenströmen bei modernen Konferenzsystemen wie dem Virtual Conferencing.

Die Rolle der digitalen Medien in CSCW Systemen

Aber auch bei Versionsverwaltungssystemen spielen digitale Medien eine wichtige Rolle, wenn auch eher eine passive. Versionsverwaltungssysteme erlauben nicht nur die Verwaltung von Quellcode oder einfachen (z.B. ASCII) Textdokumenten, sondern verwalten auch den Zugriff mehrerer Personen auf multimediale Inhalte. Diese können z.B. in Form von XML basierten (wie z.B. XHTML, SVG, SMIL) oder binärkodierten (proprietären)

1.2 CSCW in der Medieninformatik 5

Dokumentenformaten vorliegen (z.B. versch. Video-/Audioformate, Flash, Real).

Mehrbenutzer-Editoren werden unter anderem zur Erstellung multimedialer Inhalte verwendet. Vor allem in der Forschung existieren Mehrbenutzer-Editoren, die gleichzeitiges Arbeiten mehrerer Personen auf einer Grafik, einem Textdokument oder einer Webseite erlauben. Auch wenn diese aktuell weniger als Groupware und Versionsverwaltungssysteme im produktiven Einsatz sind, so wird der Stellenwert von Mehrbenutzer-Editoren, vor allem im Multimedia Bereich, mit den immer schnelleren Datenleitungen und internationalen Projektteilnehmern zunehmen.

Das Gruppenbewusstsein spielt eine wichtige Rolle in CSCW

Systemen

Das Gruppenbewusstsein (engl.: Group Awareness) ist ein weiterer zentraler Punkt bei der Entwicklung von CSCW Systemen. Da Anwender eines CSCW Systems immer Teil einer Gruppe sind, erfordert dies eine Änderung ihrer gewohnten Arbeitsweise. Die Anwender müssen nun, im Gegensatz zu Ein-Benutzer-Systemen, auf Aktionen der Gruppe zielgerichtet und zeitnah reagieren können. Diese speziellen Anforderungen eines CSCW Systems in Bezug auf Usability und Software-Ergonomie können nur durch einen Paradigmenwandel und die Entwicklung spezieller Benutzerschnittstellen erfüllt werden.

Des Weiteren werden an CSCW Systeme, da es sich meist um verteilte Anwendungen handelt, besondere nicht-funktionale Anforderungen gestellt, die sie von lokalen Anwendungen unterscheiden:

1. Häufig sehr kurze Antwortzeiten (fast Echtzeit) über

Weitverkehrsnetze wie z.B. das Internet 2. Hohe Systemstabilität und hohe Fehlertoleranz bei

Netzwerkproblemen und –Verzögerungen Nichtfunktionale Anforderungen

an CSCW Systeme

3. Unterstützung heterogener Umgebungen Die Forschung an und die Entwicklung von modernen CSCW

Systemen erfordert aufgrund des intensiven Einsatzes, der Verwaltung und der Bearbeitung von Multimedialen Inhalten ein gutes Verständnis dieser und ist wie auch die Entwicklung verteilter Systeme und die Forschung im Bereich Usability und Software-Ergonomie ein Aufgabengebiet der Medieninformatik.


1.3 Groupware und Workgroup Computing Systeme

1.3.1 Zielsetzung der Groupware Systeme

Der Begriff Groupware ist ein aus den Begriffen Group (Gruppe) und Software zusammengesetztes Kunstwort. Workgroup Computing wird hier als Synonym zur Groupware betrachtet. Groupware Systeme dienen, im Gegensatz zu „Ein-Benutzer-Systemen“, unter anderem zur Kommunikation zwischen Personen und von Sachverhalten. Auch spielt die Koordination von Aufgaben und Prozessen eine Rolle. Obwohl traditionelle Technologien wie das Telefon sich auch als Groupware qualifizieren lassen, bezieht sich der Begriff Groupware auf eine spezielle Klasse von Technologien. Gemeint sind meist Technologien, die auf Computer-Netzwerken basieren, wie zum Beispiel E-Mail, Newsgroups, Videotelefonie oder Chat.

Kommunikation und Koordination sind zentrale Aufgaben

Wir definieren Groupware Systeme wie folgt: Der Begriff Groupware bezeichnet ein aus Software und eventuell spezifischer Hardware bestehendes System, das die Zusammenarbeit im Team durch die Schaffung von Kommunikations- und/oder Koordinationslösungen unterstützt oder ermöglicht.

Groupware Systeme bieten entscheidende Vorteile gegenüber

„Ein-Benutzer“-Systemen. Unter anderem wird Groupware aus folgenden Gründen eingesetzt:

1. Zur Verbesserung der Kommunikation innerhalb einer Gruppe.

Es soll schneller, klarer und überzeugender kommuniziert werden können

2. Um Kommunikation auch dort zu ermöglichen, wo es sonst nicht möglich wäre

3. Um Telearbeit zu ermöglichen (bei geographisch entfernten Benutzern)

Groupware Systeme bieten viele Vorteile gegenüber Ein-Benutzer-Anwendungen 4. Zur Einsparung von Reisekosten

5. Zur Bündelung von Fachwissen und dem Gedankenaustausch in der Gruppe

1.3 CSCW in der Medieninformatik 7

6. Um Gruppen mit gemeinschaftlichem Interesse zu bilden 7. Zur Zeit- und Kostenreduktion bei der Koordination von

Gruppenarbeit 8. Zur Problemlösung in der Gruppe 9. Zur Erlangung neuer Kommunikationsmöglichkeiten, wie zum

Beispiel dem anonymen oder strukturierten Informationsaustausch Die Entwicklung erfolgreicher Groupware Systeme ist dagegen

schwieriger, als die Entwicklung herkömmlicher Ein-Benutzer-Systeme. Das liegt nicht nur an den erschwerten technischen Voraussetzungen. Groupware “lebt” von der Gruppe. Daher ist die volle Akzeptanz der Groupware durch die Zielgruppe entscheidend für den Erfolg einer Groupware.

1.3.2 Werkzeuge und Anwendungen

Groupware Systeme werden oft mithilfe einer Raum-Zeit-Matrix klassifiziert, wie sie in der folgenden Tabelle dargestellt ist.

Zeit

Raum

Synchron Asynchron

Selber Ort

VerschiedeneOrte

Z.B. Wahlsysteme, Präsentations-unterstützung

Z.B. geteilte PC Arbeitsplätze

Z.B. Chats, Videotelefonie-

systeme

Z.B. E-Mail,Newsgroups

Tabelle 1: Raum-Zeit-Matrix der Groupware Systeme

Die erste Achse teilt die Systeme in synchrone und asynchrone Systeme ein. Asynchrone Systeme wie z.B. E-Mail, Weblogs oder elektronische schwarze Bretter, erlauben dabei den Zugriff


verschiedener Personen auf die Daten zu unterschiedlichen Zeiten. Synchrone Systeme dagegen erlauben die gleichzeitige Zusammenarbeit mehrerer Personen an einer Aufgabe. Die zweite Achse teilt die Systeme nach dem Ort der gemeinschaftlichen Arbeit ein. Dabei gibt es Systeme, die Gemeinschaftsarbeit am selben Ort unterstützen (Angesicht zu Angesicht) und Systeme zur Unterstützung der Arbeit von örtlich verteilten Personen. In diesem Kapitel werden nur Systeme, welche kollaboratives Arbeiten an verschiedenen Orten unterstützen betrachtet. Im Folgenden werden die wichtigsten Typen von Groupware Systemen beschrieben.

Es gibt synchrone, asynchrone und multisynchrone Systeme

1.3.2.1 Asynchrone Groupware

Im Folgenden werden verschiedene Beispiele für asynchrone Groupware vorgestellt. Dabei handelt es sich um Systeme, die keine Echtzeitanforderungen erfüllen müssen. Das heißt, der Zugriff der Gruppenmitglieder auf Daten und Informationen findet nacheinander bzw. zeitversetzt statt.

1.3.2.1.1 E-Mail E-Mail ist wohl eine der bekanntesten und meistgenutzten Groupware Anwendungen. Grundsätzlich dient E-Mail zur Übertragung von einfachen Textnachrichten zwischen zwei Benutzern. Schon einfache E-Mail Systeme erlauben heutzutage das Weiterleiten, Abspeichern, Sortieren, das Einrichten von Mailgruppen und das Anhängen von Dateien an Nachrichten. Das automatische Filtern und das Routen von Nachrichten gehört mittlerweile zum Standard der meisten E-Mail Systeme. Dabei können E-Mails anhand verschiedener Kriterien automatisch aussortiert, in andere E-Mail Ordner einsortiert oder an andere E-Mail Adressen weitergeleitet werden. Manche Systeme erlauben auch das Strukturieren und anreichern von Metadaten zu Nachrichten. Weit verbreitete E-Mail Systeme sind zum Beispiel Microsoft Exchange 2, Lotus Notes3 und Postfix 4.

E-Mail: eines der bedeutendsten Groupware Systeme

Für E-Mail existieren verschiedenste Client Anwendungen, auch Mail User Agents genannt, mit denen E-Mails versendet und

2 http:://www.microsoft.com 3 Der Lotus Domino Server dient dabei unter anderem als IMAP/POP3/SMTP Server. http://www-306.ibm.com/software/de/lotus/ 4 http://www.postfix.org/

0 CSCW in der Medieninformatik 9

empfangen werden können. Diese bieten unterschiedlichste Zusatzfunktionen (z.B. SPAM-Filter, Suchen, Sortierung, etc.) und unterstützen verschiedene Protokolle (z.B. POP3, IMAP, SMTP) für den E-Mail Transport. Zu den bekanntesten Clients zählen unter anderem Microsoft Outlook und Thunderbird. Gesendet werden E-Mails, in dem der E-Mail Client eine Verbindung zu einem SMTP (Simple Mail Transfer Protocol) Server (SMTP-Relay-Server oder Smarthost) aufbaut und die zu sendende Nachricht an diesen überträgt. Dieser leitet sie dann an den Empfänger weiter. Um E-Mails abzurufen, verbindet sich der Client mit einem Mail-Server über das Post Office Protokoll 3 (POP3 oder POP3S für eine sichere Verbindung). Alternativ kann ein Client sich über das Internet Message Access Protocol (IMAP oder IMAPS für eine sichere Verbindung) mit einem Mail-Server verbinden. Bei IMAP müssen (im Gegensatz zu POP3) Emails nicht vom Server heruntergeladen und somit dort gelöscht werden, um sie zu lesen zu können, sondern verbleiben auf dem Server. Neben den E-Mail Anwendungen, die auf der Zielplattform (z.B. Heim-PC) installiert werden müssen, sind sogenannte Webmail-Clients sehr beliebt. Diese erlauben den Zugriff auf E-Mails über einen Web-Browser. Verschiedene Dienstleiter haben sich darauf spezialisiert solche „Webmailer“ und den dazugehörigen E-Mail Dienst anzubieten. Weiterführende Literatur zum Thema E-Mail finden sie unter [8,9,10].

E-Mail Protokolle

1.3.2.1.2 Newsgroups und Mailing-Listen Diese Systeme dienen, im Gegensatz zu E-Mail, dem Nachrichtenaustausch in einer größeren Gruppe. Ansonsten sind sie dem E-Mail System aber sehr ähnlich. Der Hauptunterschied zwischen Newsgroups und Mailing-Listen besteht darin, dass Newsgroups nur Nachrichten anzeigen, wenn ein Benutzer diese auch direkt anfordert. Bei Mailing-Listen werden Nachrichten an alle Benutzer, welche die Liste abonniert haben, sofort weitergeleitet.

1.3.2.1.3 Arbeitsablauf-Management Systeme Aufgabe des Arbeitsablauf-Management (engl.: Workflow-Management) ist es, eine Spezifikation für die technische Ausführung von Arbeitsabläufen zu liefern. Das Workflow-Management kann damit als eine technische Umsetzung des Geschäftsprozess-Managements verstanden werden. Ein Workflow-Management-System (WfMS) dient der aktiven Steuerung


arbeitsteiliger Prozesse. Eine Workflow-Management-Anwendung ist eine implementierte Lösung zur Steuerung von Arbeitsabläufen (engl.: Workflows) auf der Basis eines Workflow-Management-Systems. Workflow-Systeme werden häufig der Groupware zugeordnet, da sie die Arbeit unterschiedlicher Personen innerhalb einer Organisation regeln. In diese Kategorie fallen auch sogenannte Anforderungs-Management- (engl.: Requirements-Management) und Änderungs-Management- (engl.: Change-Management) Systeme. Diese unterstützen die Kollaboration und Kommunikation bei der Erfassung von Anforderungen eines Systems. Hierbei soll eine strukturierte Vorgehensweise (durch Workflow-Management) bei der Anforderungserfassung und eine Verwaltung der erfassten Daten die Arbeit erleichtern. Ein Beispiel für ein führendes Anforderungs-Management System ist DOORS der Firma Telelogic. Beispiele für kommerzielle WfMS bzw. Änderungs-Management Systeme sind IBM Rational ClearCase5 und ClearQuest MultiSite6.

Groupware zur Steuerung von Arbeitsabläufen

Weiterführende Literatur zum Thema Workflow-Management finden sie unter [11].

1.3.2.1.4 Hypertext basierte Systeme Mit der Entwicklung des Hypertext Transfer Protokolls (HTTP)

und den ersten Web-Browsern wurde die Grundlage für eines der meistgenutzten Groupware Systeme geschaffen; Das World Wide Web (WWW) ist im Prinzip ein Groupware System, da viele Personen darüber Informationen computergestützt austauschen. Heutzutage existieren viele Groupware Systeme, die sich die Hypertext Technologie zu nutze machen. Die schon erwähnten webbasierten E-Mail Clients gehören noch zu den einfachen. Hypertext basierte Systeme nutzen das Internet bzw. Intranet und das HTTP Protokoll, um Zugang zu ihren Diensten über einen Web-Browser zu ermöglichen. Prinzipiell ist es möglich fast jede asynchrone Groupware Lösung auch mit einer Web-Schnittstelle auszustatten.

Wikis und Blogs sind sehr populär

Viele Systeme besitzen neben webbasierten Clients (auch Thin-Clients genannt) herkömmliche Clients, da nicht alle Funktionalitäten über einen Web-Client abgebildet werden können. Hingegen gibt es einige Groupware Systeme, die nur Web-Clients einsetzen. Dazu gehören neben den sogenannten Blogs oder Weblogs auch die Wiki Systeme (wie z.B. das MediaWiki) und viele weitere. Damit ist es möglich auf relativ einfache Weise

5 http://www-306.ibm.com/software/awdtools/clearcase/multisite 6 http://www-306.ibm.com/software/awdtools/clearquest/multisite/


Informationen einer großen Zahl an Personen (bestenfalls allen Internetnutzern) zur Verfügung zu stellen. Interessierte Benutzer müssen diese Informationen entweder aktiv abrufen, indem sie die entsprechende Webseite aufrufen, oder sogenannte RSS (Really Simple Syndication) Feeds für Blogs und andere Inhalte (z.B. Podcast Hypermedia) abonnieren. So abonnierte Inhalte werden automatisch zugestellt. Zusätzlich wurden Erweiterungen des Hypertext Transfer Protokolls entwickelt, die das Aufspielen und Ändern von Hypertext Inhalten auf einen Webserver erleichtern. Dazu gehört das sogenannte WebDAV (Web-based Distributed Authoring and Versioning). Gegenüber der Verbindung mit FTP (File Transfer Protocol) oder anderen Protokollen hat WebDAV verschiedene Vorteile. Es ist unter anderem leichter bedienbar, denn es wird von den gängigen Betriebssystemen standardmäßig unterstützt. Die Verwendung von WebDAV bereitet auch hinter Firewalls weniger Schwierigkeiten als z.B. FTP, da die Standard HTTP Ports genutzt werden. Ein Beispiel für ein kommerzielles webbasiertes asynchrones Groupware System welches unter anderem WebDAV einsetzt ist der Microsoft SharePoint Portal Server7. Dieses System dient zur Verwaltung und zum Bearbeiten von Dokumenten in einer Gruppe. Hypertext Systeme, die nicht nur textuelle sondern auch multimediale Inhalte verwalten, werden oft Hypermedia Systeme genannt. Hierzu zählen Groupware Systeme, die webbasiert arbeiten, aber neben Text auch Audio- und/oder Videostreams einsetzen. Oft handelt es sich dabei um Online-Konferenzsysteme oder Systeme für kooperatives Lernen. Computer-Supported-Cooperative-Learning (CSCL) Systeme arbeiten oft webbasiert, da der Zugang einer breiten Personengruppe möglich sein soll und die Installation einer speziellen Software nicht immer erwünscht ist. Mithilfe der sogenannten Web 2.0 Technologien wie Ajax (Asynchronous Javascript and XML) und den Web Service APIs wird es möglich auch „quasi synchrone“ kollaborative webbasierte Anwendungen zu realisieren. Dabei informieren sich die webbasierten Clients durch regelmäßige Anfragen beim Server (Polling) über Änderungen an den gemeinsamen Daten. Solche kollaborative Web 2.0 Dienste erlauben das gemeinsame Bearbeiten von Dokumenten im Team über einen Web-Browser, ähnlich der Wikis nur interaktiver und zeitnah. Beispiel für webbasierte Mehrbenutzer-Editoren sind Zoho Writer8 und Writely9. Web 2.0

Web 2.0 Dienste verbessern die Usability einer webbasierten

Anwendung

7 http://www.microsoft.com/office/sharepoint/prodinfo/default.mspx 8 http://www.zohowriter.com 9 http://www.writely.com


basierte Dienste zeichnen sich durch eine Benutzerinteraktivität aus, die herkömmlichen stand-alone Anwendungen sehr nahe kommt. Sie vereinen damit die Vorteile der Plattformunabhängigkeit mit größtmöglicher Benutzerfreundlichkeit und Funktionalität. Die Entwicklung von effizienten Hypermedia Protokollen und neuen Anwendungen ist ein Forschungsgebiet, das mit der ständig wachsenden Bandbreite der Datenleitungen stark zugenommen hat. Verschiedene Forschungsgruppen versuchen hier neue Standards im Bereich Hypermedia zu etablieren. Ein Beispiel dafür ist Annodex10; ein offener Standard für die Annotierung und Indexierung von Multimedia Inhalten im Internet. Ziel dabei ist es, das sogenannte Continuous Media Web (CMWeb) zu entwickeln: Eine extrem mehrbenutzerfähige verteilte Hypermedia Umgebung für das World-Wide-Web der übernächsten Generation.

1.3.2.1.5 Gruppenkalender Gruppenkalender erlauben die Terminplanung und die

Koordination von vielen Personen innerhalb einer Organisation. Oft unterstützen solche Systeme auch die Synchronisation von Terminen mit mobilen Endgeräten. Sie können automatisch Terminkonflikte erkennen und Termine finden, an denen jeder Teilnehmer einer Gruppe Zeit hat. Gruppenkalender sind oft integrierte Bestandteile anderer Groupware Systeme wie z.B. Microsoft Outlook11. Gruppenkalender leiden oft an fehlender Datenpflege, da nicht immer alle Benutzer ein Interesse an der Eingabe ihrer Daten haben. Daher sollten solche Systeme besonderen Wert auf die Privatsphäre von Benutzern legen und den Zugriff auf Informationen stark durch die Benutzer kontrollierbar machen. Jeder Benutzer sollte selbst bestimmen können, wem, welche Informationen über ihn, zugänglich sind.

Gruppenkalender wollen gepflegt werden

1.3.2.2 Synchrone Groupware

Bei Groupware Systemen, die den gleichzeitigen Zugriff der Gruppenmitglieder auf Daten und Informationen ermöglichen, handelt es sich um synchrone Groupware. Im Folgenden werden einige Beispiele dafür vorgestellt.

10 http://www.annodex.net/ 11 http://office.microsoft.com/de-de/FX010857931031.aspx


1.3.2.2.1 Elektronische Tafel Elektronische Tafeln (engl.: Electronic Whiteboard) erlauben es mehreren Personen zur selben Zeit, von unterschiedlichen Orten aus, auf eine für alle sichtbare Fläche zu zeichnen. Elektronische Tafeln können zum Beispiel dazu verwendet werden, während eines Telefonats Notizen zu machen, die dann von jeder Person kommentiert werden können, oder ein visuelles Problem zu besprechen. Die meisten dieser Systeme dienen informellen Zwecken, können aber auch für anspruchsvollere Aufgaben eingesetzt werden. Im Gegensatz zu grafischen Mehrbenutzer-Editoren besitzen sie allerdings meist keine Synchronisationsmöglichkeit und garantieren keine Datenkonsistenz. Einfache Systeme arbeiten sogar asynchron und erlauben zu einem Zeitpunkt nur einer Person den Zugriff auf die Zeichenfläche, während die anderen Personen die gemachten Änderungen nur betrachten können. Erst nach Freigabe der Zeichenfläche durch den Benutzer, kann dann der nächste Teilnehmer den „Zeichenstift“ ergreifen.

Elektronische Tafeln helfen bei der Visualisierung in

Teambesprechungen

Elektronische Tafeln sind häufig integraler Bestandteil anderer Groupware Anwendungen wie Audio- und/oder Videokonferenzsystemen oder Chats.

1.3.2.2.2 Application Sharing Systeme Application Sharing Systeme werden auch Systeme zur Anwendungsaufteilung genannt. Dabei handelt es sich um eine Software, die es ermöglicht eine Anwendung oder eine Betriebssystemoberfläche mit mehreren Benutzern zu teilen. Application Sharing Systeme sind Client-Server basiert. Der PC oder die Workstation, dessen Anwendungen anderen zugänglich gemacht werden sollen (das Host-System), betreibt den Server des Application Sharing Systems. Die Application Sharing Clients verbinden sich mit dem Host und übermitteln an diesen Informationen wie Mausbewegungen und Tastendrücke. Diese werden dann vom Host System direkt ausgeführt, als ob sie vom lokalen Benutzer stammen würden. Der Application Sharing Server übermittelt die grafische Darstellung der Anwendungen des Host Systems an die Clients. Das Application Sharing funktioniert dabei ähnlich einer elektronischen Tafel, nur dass dabei das Abbild einer Anwendung (ähnlich einem Screenshot) übertragen wird, anstatt der Zeichenfläche. Ein Beispiel für ein System, welches sowohl eine elektronische Tafel, als auch Videokonferenz, Chat und Application Sharing unterstützt ist Microsoft Netmeeting®12.

Enge Zusammenarbeit wird trotz räumlicher Trennung durch

Application Sharing möglich

12 http://www.microsoft.com/windows/netmeeting/


Application Sharing Systeme sind anwendungsunabhängig und kollaborationstransparent (engl. collaboration transparent). D.h. es können damit im Prinzip alle Arten von Anwendungen gemeinsam genutzt werden und die geteilte Anwendung bekommt davon nichts mit. Solche Systeme unterstützen striktes WYSIWIS (What You See Is What I See) und eignen sich damit besonders für die sehr enge Zusammenarbeit räumlich getrennter Benutzer. Application Sharing Systeme werden sinnvollerweise durch eine direkte Kommunikation aller Teilnehmer ergänzt, z.B. durch eine Telefonkonferenz, um die Aktionen der Teilnehmer zu koordinieren. Beispiele für Application Sharing Systeme sind VNC13 oder NetViewer14.

1.3.2.2.3 Video Konferenzsysteme Bei den Videokonferenzsystemen gibt es verschiedenste Ausführungen in Soft- und Hardware. Neben den Desktop-Systemen, die auf herkömmlichen PCs laufen, existieren Settop-Boxen, Raumsysteme und mobile Systeme, die zum Beispiel Videokonferenz über UMTS ermöglichen. Die meisten Videokonferenzsysteme basieren auf einer zentralistischen Architektur, bei dem sich die Teilnehmer an einem zentralen Server anmelden, um an der Konferenz teilzunehmen. Diese zentralen Instanzen werden Gatekeeper genannt und sind unter anderem für den Verbindungsaufbau zwischen den Endgeräten und der Multipoint Control Unit (MCU) zuständig.

MCUs sind Sternverteiler - auch als Reflector bezeichnet - für Gruppenkonferenzen. Sie sind immer dann notwendig, wenn mehr als zwei Teilnehmer an einer Konferenz teilnehmen wollen. Ein Gateway verbindet unterschiedliche Netze miteinander und konvertiert Protokolle ineinander oder koppelt Netzwerke. Bei gemeinsamer Nutzung von ISDN- und TCP/IP-Endgeräten ist der Einsatz eines Gateways zwingend notwendig.

Videokonferenzsysteme sind mittlerweile Standard in vielen größeren Unternehmen

Peer-to-Peer (P2P)- Videokonferenzsysteme stellen einen alternativen Ansatz zu den herkömmlichen zentralistischen Videokonferenzsystemen dar. Sie verzichten auf einen zentralen Gruppen- und Kommunikationsserver wie Gatekeeper und die MCU. Stattdessen wird die gesamte Intelligenz in die Endsysteme, d.h. die PCs und Workstations, verlagert. Es existieren verschiedene Protokolle für den Verbindungsaufbau und die Übertragung der Video- und Audiodaten. Die wichtigsten sind H.323 und das Session Initialisation Protocol (SIP).

13 http://www.vnc.com/ 14 http://www.netviewer.de/


1.3.2.2.4 Multimediale Konferenzsysteme Neben Videokonferenzsystemen gibt es auch Systeme, die außer Video- und Audiodaten auch multimediale Inhalte in eine Konferenz einfließen lassen. Diese werden unter anderem für Projektbesprechungen, Führungskräftemeetings, Kundenberatung und E-Learning eingesetzt. Teilnehmer einer Gruppe können sich dabei netzbasiert in einer virtuellen Umgebung treffen z.B. zum Koordinieren ihrer Aufgaben, Präsentieren von Lösungen und Diskutieren von Lösungsalternativen. Ein Beispiel für ein solches Multimediales Konferenzsystem ist VITERO (Virtual Tea Room)15.

1.3.2.2.5 Chat Systeme Chats sind ein äußerst beliebtes Mittel, sich im Internet zu treffen und auszutauschen. Sie erlauben vielen Personen, Nachrichten in „Echtzeit“ zu schreiben und zu veröffentlichen. Sobald eine Person eine Nachricht abschickt, erscheint diese sofort auf dem Bildschirm der anderen Teilnehmer. Es gibt verschiedenste Ausprägungen von Chat Systemen. Meist sind dies Anwendungen, die auf einem Endgerät installiert werden und sich mit einem zentralen Chat Server verbinden. Es gibt aber auch Peer-to-Peer Chat Systeme, die keinen zentralen Server benötigen und webbasierte Clients. Chat Server verwalten sogenannte Chat Räume, die meist nach Diskussionsthemen eingeteilt sind und entweder offen und für jedermann zugänglich, oder privat sind. Manche Chat Räume besitzen einen Moderator der die Diskussion leitet. Missbrauch verhindert dieser, indem er Benutzer aus dem Chat Raum verweist, die Regeln nicht einhalten. Chat Teilnehmer wählen zur Identifizierung meist einen anonymen Spitznamen (engl. Nickname).

Chats dienen nicht nur der Unterhaltung

Bekannteste PC basierte Chat Clients sind ICQ16, AOL Instant Messenger17, Microsoft Messenger (MSN)18, verschiedene IRC Chat Clients wie mIRC19 und verschiedene Jabber Clients. Auch für mobile Endgeräte existieren Chat Clients wie zum Beispiel Mjabber20 und andere, die das Chatten von überall und zu jederzeit ermöglichen.

Für Chat Systeme existieren keine einheitlichen Standards. Es gibt viele proprietäre nicht offen gelegte Protokolle und Systeme

15 http://www.vitero.de/ 16 http://www.icq.com 17 http://www.aim.com/ 18 http://messenger.msn.com/Xp/Default.aspx 19 http://www.mirc.com/ 20 http://www.mjabber.com/


zum Datenaustausch (ICQ, AOL etc.). Offene Systeme sind unter anderem das schon relativ alte Internet Relay Chat (IRC) System, von dem es viele Ausprägungen und Erweiterungen gibt. Ein neueres Protokoll und Chat Netzwerk ist zum Beispiel Jabber, das basierend auf XML zusammen mit sogenannten „Transports“ die Kommunikation mit den meisten der proprietären Chat Systemen wie ICQ, AOL und Microsoft unterstützt.

Neben dem Versenden von reinen Textnachrichten unterstützen viele Chat Systeme auch die Übertragung von Dateien und Audio-und/oder Videostreams. Eine relativ neue Entwicklung sind die sogenannten Voice-Over-IP (VoIP) Chat Systeme wie z.B. Skype. Diese erlauben die Gruppentelefonie über VoIP und zusätzlich das versenden von Textnachrichten und Dateien. Auch klassische Chat Systeme wie z.B. ICQ sind nachgezogen und bieten die Möglichkeit der Telefonkonferenz oder das sogenannte Push-to-Talk über das Internet. Beim Push-to-Talk werden beim Drücken eines Tasters (Mausklick) kurze Audio Dateien aufgezeichnet und danach an mehrere Teilnehmer versendet. Die Push-to-Talk Technologie ähnelt (in Bezug auf die Bedienung) der Funkgeräte Technik und wird auch im Mobilfunk (GPRS, UMTS) eingesetzt. Die VoIP Chat Systeme nutzen neben proprietären Protokollen auch klassische VoIP Protokolle wie SIP (Session Initialisation Protocol) und H.323.

Chats für Mobiltelefone anstatt SMS

1.3.2.2.6 Systeme zur Entscheidungsfindung Diese Systeme sollen Gruppen in der Entscheidungsfindung unterstützen und bieten dazu Werkzeuge für das Brainstorming, Ideensammlung und Kritik, Pro und Kontra Abwägung und zum Wählen. Sie sind oft integraler Bestandteil von Konferenzsystemen und dienen als zusätzliche Unterstützung in Besprechungen, um zur aktiven Teilnahme zu ermutigen, anonyme Teilnahme zu ermöglichen, oder die Teilname durch „Aufrufen“ zu erzwingen.

1.3.2.2.7 Mehrbenutzer Spiele Verteilte Mehrbenutzer bzw. Online Spiele sind komplexe, kollaborative Systeme. Die ersten Online Spiele waren nur Text basiert und ähnelten sehr stark Chats. Meist handelt es sich bei diesen „einfachen“ Spielen um sogenannte Rollenspiele. Ein bekanntes Beispiel dafür ist Unitopia21. Mit der größeren Bandbreite und den schnelleren PC Systemen wurden die grafischen Fähigkeiten der Online Spiele immer besser. Moderne Mehrbenutzer Spiele bieten sehr realitätsnahe „Echtzeit“ 3D Umgebungen, und werden durch andere Kommunikationsmittel wie Text-, Audio- oder

21 http://unitopia.uni-stuttgart.de/


sogar Video-Chat erweitert. Bei Echtzeit Mehrbenutzer Spielen (engl.: multi-player games), ist eine sehr zeitnahe Interaktion notwendig um das „Überleben“ der Spielfigur zu gewährleisten. Daher haben diese Mehrbenutzer Spiele sehr hohe Echtzeitanforderungen. Im Gegensatz zu z.B. Mehrbenutzer Editoren, spielt die Datensynchronität bei Mehrbenutzer Spielen oft eine untergeordnete Rolle. Gehen ein paar wenige Informationen verloren, so fällt dies oft nicht ins Gewicht. Wird z.B. eine abgeschossene Kugel von hunderten in einem Feuergefecht nicht an alle Teilnehmer übertragen, spielt das meist keine große Rolle. Wichtiger ist dabei die „grobkörnige“ Information wie z.B. „Spielfigur ist im Gefecht gefallen“ oder „Spielfigur hat 20 Lebenspunkte verloren“. Die Verbreitung und Vermarktung von Online Mehrbenutzer Spielen nimmt stark zu und der Online Spielmarkt ist zurzeit einer der am stärksten wachsenden Bereiche der Softwarebranche.

1.3.2.2.8 Kollaborative Betriebssysteme Das Croquet Projekt22 ist ein Beispiel für eine neuartige

kollaborative Betriebssystemarchitektur die mithilfe einer neuartigen Benutzeroberfläche und Netzwerkarchitektur ein intensives Zusammenarbeiten aller Benutzer des Systems ermöglichen soll. Croquet ist noch Gegenstand der Forschung, bietet aber sehr interessante Ansätze und einen Ausblick auf die Zukunft des kollaborativen Arbeitens.

1.4 Versionsverwaltungssysteme

1.4.1 Zielsetzung der Versionsverwaltungssysteme

Größere Softwareprojekte, aber auch das Erstellen umfangreicher Dokumente wie zum Beispiel Bücher, Kataloge und Handbücher erfordern die erfolgreiche Zusammenarbeit mehrer Personen. Dabei stellt sich automatisch die Frage nach der Verwaltung der sich in der Erstellung befindlichen Artefakte und der Kontrolle des Zugriffs auf diese. Unkontrollierter gleichzeitiger Zugriff auf die Artefakte kann Dateninkonsistenz zur Folge haben. Gerade bei Softwareprojekten,

22 http://www.opencroquet.org/


bei denen verschiede Quellcode Dateien von mehreren Personen gleichzeitig bearbeitet werden sollen, ist die Erhaltung der Quellcode Konsistenz essentiell, da ein Projekt ansonsten eventuell nicht mehr übersetzt werden kann.

Häufig werden Verfahren wie Turn-Taking, Split-Combine oder Copy-Merge zur Kontrolle der Zugriffe eingesetzt. Diese haben den Vorteil, dass sie keine Softwareinstallation erfordern, aber auch Nachteile in Bezug auf den Zeitaufwand und die Nachvollziehbarkeit von Änderungen (s. Abschn. 1.6.1).

Versionsverwaltungssysteme haben die Aufgabe die Teamarbeit zu unterstützen und die Konsistenz der Artefakte zu wahren. Zusätzlich sollen sie die Nachvollziehbarkeit von Änderungen zu jedem Zeitpunkt durch die Versionierung der zu verwaltenden Artefakte gewährleisten. Versionsverwaltungssysteme werden daher gerade im Bereich der Softwareentwicklung häufig eingesetzt. Sie sind aber prinzipiell nicht auf diesen Bereich beschränkt. Neben der Versionsverwaltung können diese Systeme auch für die Konfigurationsverwaltung eingesetzt werden. Dabei werden verschiedene Versionen von Artefakten zu einer Konfiguration zusammengestellt.

Versionsverwaltung ist nicht nur in der Softwareentwicklung wichtig

Beispiele für bekannte kommerzielle Versionsverwaltungssysteme sind Microsoft Visual Sourcesafe23 (VSS) Synergy/CM (ehem. Continuus/CM)24 und Perforce25. Die bekanntesten kostenlosen Systeme sind das Concurrent Versioning System26 (CVS) oder dessen Nachfolgesystem Subversion27 (SVN). All diese Systeme können im Prinzip für die Versionierung jedes Datentyps eingesetzt werden. Bei der Verwaltung der Versionen der verschiedenen Datentypen bestehen allerdings Unterschiede. Je nach Datentyp werden entweder nur die Änderungen zwischen den Versionen oder das komplette Artefakt in der neuen Version abgespeichert. Letzteres trifft z.B. bei Visual Sourcesafe oder Perforce auf Binärdateien zu. Subversion hingegen speichert auch bei Binärdateien nur die Unterschiede zwischen den Versionen ab und spart somit Speicherplatz.

Ein Versionsverwaltungssystem zeichnet jede Änderung an einem von ihm verwalteten Artefakt auf. Die Artefakte werden dabei üblicherweise in einem zentralen Datenspeicher (Projektarchiv) gehalten. Der Zugriff darauf wird vom System verwaltet und

23 http://msdn.microsoft.com/vstudio/previous/ssafe/ 24 http://www.telelogic.com 25 http://www.perforce.com/ 26 http://www.nongnu.org/cvs/ 27 http://subversion.tigris.org/

1.4 Versionsverwaltungssysteme 19

geschieht durch einen sogenannten Check-In/Check-Out Mechanismus. Jedes Teammitglied arbeitet dabei auf lokalen Kopien der Artefakte. Diese müssen zunächst vom Teammitglied durch ein Check-Out (Ausprüfung) als „in Bearbeitung“ markiert werden. Dabei werden die lokalen Kopien angelegt. Nun können Änderungen an den Artefakten vorgenommen werden. Nach Abschluss der Änderungen, werden die Artefakte wieder durch ein Check-In in das System übertragen, wodurch eine neue Artefakt-Version entsteht. Beim Check-In ist dabei oft das Kommentieren von Änderungen obligatorisch, um später einfacher Änderungen nachvollziehen zu können. Das System prüft bei jedem Check-In, ob die Änderungen überhaupt zurückspielbar sind, oder unlösbare Konflikte mit zwischenzeitlich von anderen Teammitgliedern vorgenommenen Änderungen bestehen. Versionsverwaltungssysteme arbeiten dabei mit Sperrverfahren (engl.: locking) um Konflikte zu erkennen und Inkonsistenzen zu vermeiden. Hierbei werden hauptsächlich zwei Verfahren eingesetzt: Das pessimistische und das optimistische Sperrverfahren (s. Abschn. 1.6)

1.4.2 Anforderungen an Versionsverwaltungssysteme

Neben der reinen Versionsverwaltung und der Konsistenzerhaltung durch Sperrverfahren, gibt es weitere Anforderungen an ein Versionsverwaltungssystem.

Ein wichtiger Aspekt beim Bearbeiten von Artefakten ist die Gruppierung zugehöriger Änderungen in so genannte Change Sets. Dies ermöglicht das einfache Erkennen eines Änderungskontexts. Die Evolution eines Projekts geht dabei nicht nur aus den Änderungen der einzelnen Artefakte hervor, sondern es bleiben durch die Definition eines Change Sets auch die Zusammenhänge der einzelnen Änderungen erhalten.

Beim Check-In von Änderungen sollten Systeme transaktionsorientiert arbeiten. Werden z.B. mehrere Dateien gleichzeitig eingecheckt, kann es dazu kommen, dass einige Änderungen konfliktfrei sind, andere aber hingegen konfliktbehaftet. Lässt ein System dabei das Check-In der konfliktfreien zu und ignoriert die konfliktbehafteten Änderungen, so kann dies zu Problemen führen, wenn zwischen den gleichzeitig eingecheckten Artefakten Zusammenhänge bestehen. Daher bieten einige Versionsverwaltungssysteme so genannte atomare Check-Ins: Eine


Menge von Änderungen werden entweder vollständig, oder gar nicht ausgeführt. Der Projektteilnehmer hat somit Versionskonflikte aufzulösen, bevor das Versionsverwaltungssystem seine Änderungen akzeptiert.

Die Rechtevergabe sollte bei Versionsverwaltungssystemen möglichst feinkörnig sein, um den Zugriff nicht nur für Verzeichnisse, sondern auch für Dateien regeln zu können. Dies macht vor allem dann Sinn, wenn Projektteilnehmer ihre Änderungen nicht direkt „einchecken“ können sollen, sondern erst nachdem mehrere andere Personen zugestimmt haben (Qualitätskontolle, Review).

Versionsverwaltungssysteme können mehr

Eine Versionsverwaltung sollte auch das Verzweigen von Projektversionen erlauben (engl.: Branching). Dies ermöglicht z.B. in Softwareprojekten das Arbeiten an Patches für eine Version unabhängig von den Arbeiten an der Nachfolgeversion. Solche einmal verzweigten Projektversionen sollten danach auch wieder zusammengeführt werden können (engl.: Merging). Zusätzlich sollte das Verwenden eines Artefakts in mehreren Projekten möglich sein (engl.: Sharing).

Eine recht hilfreiche Funktion ist es, Metadaten wie Kommentartexte frei vergeben zu können, um damit bestimmte Versionen von Artefakten leichter wiederfinden zu können (engl.: Tagging).

1.4.3 Architektur von Versionsverwaltungssystemen

Versionsverwaltungssysteme sind meist klassische Client/Server Systeme. Es gibt einen zentralen Server, der den Datenspeicher verwaltet und mehrere Clients, die über verschiedenste Protokolle mit dem Server kommunizieren.

Eine Ausnahme bildet hier Microsoft Visual Sourcesafe (VSS). Sourcesafe besitzt keine echte Client/Server Architektur. Der Datenspeicher (Projektarchiv) ist nur eine Freigabe im Netzwerk, welche eine Sourcesafe Datenbank in einem proprietären Format enthält. Die Clients greifen also auf den Datenspeicher über Filesharing zu. Dies setzt das SMB (Server Message Block) Protokoll voraus. Damit müssen sich VSS Clients zumindest im selben Virtuellen Netzwerk befinden und können nicht direkt über TCP/IP auf den Datenspeicher zugreifen. Auch laufen die VSS Clients nur unter Windows.

Andere Systeme unterstützen eine heterogene Umgebung, laufen auf verschiedensten Plattformen und erlauben den Zugriff auf den

1.4 Versionsverwaltungssysteme 21

Datenspeicher entweder direkt über TCP/IP oder andere höhere Protokolle. Subversion z.B. erlaubt den Zugriff zusätzlich über die HTTP Protokollerweiterung Web-DAV (Web-based Distributed Authoring and Versioning)

Die Clients der Versionsverwaltungssysteme gibt es in unterschiedlichsten Ausführungen und von unterschiedlichsten Herstellern. Es existieren Kommandozeilen basierte und grafische Clients. Viele Clients sind als Plug-In zu Entwicklungsumgebungen (z.B. Subclipse28) erhältlich. Eine von Microsoft entwickelte API (Application Programmers Interface) namens SCC-API (Source Code Control) ermöglicht die einfache Entwicklung und Integration von Clients in bestehende Entwicklungsumgebungen.

28 http://subclipse.tigris.org/


1.5 Kollaborative Mehrbenutzer-Editoren

1.5.1 Zielsetzung der Mehrbenutzer Editoren

Kollaborative Mehrbenutzer Editoren existieren für verschiedenste Dokumentenformate. Ähnlich wie die Versionsverwaltungssysteme sind viele der Editoren aus dem Bereich der Softwareentwicklung und zum Zweck der gemeinsamen Bearbeitung von Quellcode entstanden. Mittlerweile gibt es Mehrbenutzer Editoren für einfache Quellcode und Textdokumente, Grafiken, Hypertext Dokumente und weitere. Das Ziel beim Einsatz von Mehrbenutzer-Editoren ist es, die Produktivität durch gemeinsames Arbeiten mehrerer Personen an einem Dokument zu steigern. Die meisten der existierenden Mehrbenutzer Editoren unterstützen jeweils nur ein bestimmtes proprietäres Dokumentenformat und die Einsatzgebiete sind daher meist recht spezialisiert. Mehrbenutzer Editoren können synchron, asynchron oder multisynchronen Typs sein. Asynchrone Mehrbenutzer-Editoren (z.B. CES [12], DistEdit [13], Lotus Notes29) erlauben mehreren Personen nacheinander an einem Dokument zu arbeiten. Das komplette oder Teile des Dokuments werden z.B. mithilfe eines pessimistischen oder optimistischen Sperrverfahren (s. 1.6.) konsistent gehalten. Sie sind praktisch Editoren mit integrierter Versionsverwaltung und unterstützen die Gruppenarbeit zusätzlich z.B. durch eine gemeinsame Dokumentenablage, ein gemeinsames Objektrepository, verschiedene Awareness Mechanismen (z.B. um zu sehen wer gerade woran arbeitet) und zusätzliche Kommunikationsunterstützung durch z.B. Chats oder Videotelefonie. Diese Editoren erlauben es also Benutzern, am selben Dokument zu arbeiten, aber typischerweise in verschiedenen Abschnitten und zu verschiedenen Zeiten. Asynchrone Mehrbenutzer-Editoren basieren entweder auf einer zentralistischen oder einer replizierten Architektur (s. 1.7.).

Mehrbenutzer-Editoren kommen in verschiedensten Bereichen zum Einsatz

Multisynchrone Mehrbenutzer-Editoren erlauben das Umschalten zwischen asynchroner und synchroner Arbeitsweise. Diese Umschaltung geschieht entweder automatisch oder manuell (z.B. SAMS [1]). Beim gemeinsamen Arbeiten an einem Dokument ist es oft nicht erwünscht, dass andere sofort alle Änderungen eines

29 http://www.lotus.de/

1.5 Kollaborative Mehrbenutzer-Editoren 23

Benutzers mitbekommen (asynchron). Diese sollen erst zu einem, vom Benutzer bestimmten Zeitpunkt, allen zur Verfügung stehen. Zu einem anderen Zeitpunkt aber Arbeiten mehrere Personen gleichzeitig (synchron) am selben Bereich innerhalb eines Dokumentes (z.B. um die vorher gemachten Änderungen zu besprechen) und es ist erforderlich, dass sie die jeweiligen Änderungen sofort sehen können. In diesem Fall ist eine Umschaltung zwischen synchroner und asynchroner Arbeitsweise sinnvoll.

Synchron arbeitende Editoren werden auch als „Echtzeit“ (engl. „real-time“) Editoren bezeichnet. Das Forschungsgebiet des „Real-Time Collaborative Editing“ (RTCE) ist ein Teilgebiet des CSCW und untersucht Computersysteme zum gleichzeitigen und effektiven Bearbeiten eines Dokuments durch mehrere Personen in „Echtzeit“. Dazu zählen Systeme wie REDUCE [14], CoWord oder CoPowerPoint [15]. Bei der Entwicklung von Echtzeit-Editoren müssen verschiedene Probleme überwunden werden, die mit den Anforderungen dieser Systeme zusammen hängen. Die Lösung dieser Probleme ist teilweise noch Gegenstand der Forschung. In Folgenden werden die wichtigsten dieser Probleme beschrieben.

1.5.2 Probleme des „Echtzeit“ Editierens

Echtzeit Mehrbenutzer Editoren sind verteilte Systeme, die es ermöglichen sollen Dokumente in Echtzeit von mehreren Personen von verschiedenen Orten aus zu bearbeiten. Dies sollte möglichst so geschehen, dass die einzelnen Personen in Bezug auf die Performanz fast keinen Unterschied zu einem Ein-Benutzer-Editor feststellen können. Ein Benutzer soll nach einem Tastendruck nicht erst warten müssen, bis das System seine Eingabe geprüft hat. Daher erfordern diese Editoren im Vergleich zu den meisten anderen kollaborativen Systemen und Datenbanksystemen besonders schnelle Antwortzeiten.

Ein „verteiltes“ Dokument, das mithilfe eines Mehrbenutzer-Editors bearbeitet wird, muss bei allen Benutzern zu jeder Zeit denselben Inhalt tragen. Es muss also überall und zu jeder Zeit konsistent sein. Eine Voraussetzung für den Erhalt der Konsistenz ist die serielle Äquivalenz von Operationen. Wie auch in Datenbanksystemen ist daher in kollaborativen Editier Systemen der Erhalt der seriellen Äquivalenz eine zentrale Aufgabe. Die serielle Äquivalenz lässt sich folgendermaßen definieren:


Werden alle Paare von miteinander in Konflikt stehende Operationen zweier Transaktionen auf allen betroffenen Objekten in derselben Reihenfolge ausgeführt, so bezeichnet man diese Transaktionen als seriell äquivalent Um die serielle Äquivalenz zu erhalten, wurden verschiedene Nebenläufigkeitskontrollverfahren entwickelt, wie z.B. das Zeitstempel und das Sperrverfahren (s. Abschn. 1.6 Nebenläufigkeitskontrolle in CSCW Systemen). Die meisten Nebenläufigkeitskontrollverfahren, wie sie in Datenbanksystemen oder anderen kollaborativen Systemen zum Einsatz kommen, können die hohen Anforderungen der Echtzeit-Mehrbenutzer-Editoren in Bezug auf schnelle Antwortzeiten allerdings nicht erfüllen. Auch ist eine andere Systemarchitektur als die zentralistische für kollaborative Editoren notwendig.

Die meisten Echtzeit-Mehrbenutzer-Editoren (z.B. [16,17]) basieren daher auf der replizierten Architektur (s. Abschn.1.7), um gute Reaktionszeiten zu erreichen. Bei der replizierten Architektur besitzt jeder Teilnehmer der Gruppenarbeit eine lokale Kopie des Dokuments. Auf dieser lokalen Kopie führt jeder Teilnehmer seine Änderungen (allgemeiner: Operationen) durch. Dies kann gleichzeitig geschehen. Der jeweilige Teilnehmer sieht das Ergebnis seiner Operation sofort und erst danach wird die ausgeführte Operation an die anderen Teilnehmer der Sitzung übertragen. Ist die Operation bei den anderen Teilnehmern angekommen, wird sie dort auf den jeweiligen Kopien ausgeführt. Dabei können Probleme durch Verzögerungen bei der Datenübertragung und gleichzeitiges Ändern desselben Datenobjekts entstehen.

Konfliktlösung in Mehrbenutzer-Editoren

Die folgende Abbildung zeigt einen typischen Ablauf beim verteilten Editieren eines Dokuments durch mehrere Benutzer.

Benutzer 1 Benutzer 2 Benutzer 3

Zeit

O1 O2

O4

O3

Abbildung 2: Szenario einer Mehrbenutzer-Editor Sitzung


Im oben dargestellten Szenario werden vier verschiedene Operationen von drei Benutzern auf dem verteilten Dokument ausgeführt: O1,O2,O3 and O4.

Benutzer 1 führt die Operation O1 auf seiner lokalen Kopie des Dokuments gleichzeitig mit der Operation O2 von Benutzer 2 aus. Etwas zeitversetzt führt Benutzer 3 die Operation O4 aus und Benutzer 2 die Operation O3. Durch die Zeitverzögerungen bei der Übertragung der Operationen über das Netzwerk werden die Operationen auf den jeweiligen Dokumentkopien der Benutzer in unterschiedlichen Reihenfolgen ausgeführt. Auf der lokalen Kopie von Benutzer 1 werden die Operationen in der Reihenfolge: O1,O2,O4,O3 ausgeführt. Bei Benutzer 2 ist die Reihenfolge O2,O1,O3,O4 und bei Benutzer 3 O2,O4,O3,O1. Die serielle Äquivalenz der Operationen ist dadurch gefährdet. Probleme der Divergenz, Kausalitätsverletzung und Intentionsverletzung können auftreten. Diese werden im Folgenden beschrieben.

1.5.2.1 Divergenz

Sind die Operationen O1,O2,O4,O3 nicht kommutativ, können die Ergebnisse in den Dokumenten der drei Benutzer unterschiedlich aussehen. In diesem Fall besteht eine Divergenz der Dokumentkopien. Es wird zwischen der Divergenz innerhalb eines Datenobjekt (Intra-Objekt-Divergenz) und der Divergenz zwischen Datenobjekten (Inter-Objekt-Divergenz) unterschieden. Bei der Intra-Objekt-Divergenz entstehen für dasselbe Datenobjekt in verschiedenen Kopien des verteilten Dokuments unterschiedliche Ergebnisse. Betrachten wir als Beispiel einen kollaborativen Grafik-Editor. Die Operationen O1 und O2 seien dabei Operationen, welche dasselbe Grafikobjekt A (z.B. ein Rechteck) an verschiedene Positionen X und Y im Dokument verschieben. Diese Operationen werden konkurrierende Operationen genannt. Konkurrierende Operationen können in unterschiedlicher Reihenfolge an verschiedenen Orten ausgeführt werden und führen dort zu jeweils unterschiedlichen Ergebnissen.

Es wird zwischen Intra- und Inter-Objekt-Divergenz

unterschieden

Bei der Inter-Objekt-Divergenz entstehen unterschiedliche Ergebnisse an zwei oder mehreren Datenobjekten in den verschiedenen Kopien des verteilten Dokuments.

Ein Beispiel: In einem kollaborativen Grafikeditor werden zwei unterschiedliche Objekte zur selben Zeit von zwei Personen erzeugt. Die Objekte überlappen sich dabei. Je nachdem welche Operation für die Erzeugung eines Objektes zuerst ausgeführt wird, liegt


entweder das erste Objekt über dem zweiten oder umgekehrt. Die folgende Abbildung soll dies verdeutlichen.

Benutzer 1 Benutzer 2

Zeit

O1 O2

AB

AB

AB

Nach ausführenvon O1




Abbildung 3: Szenario Intra-Objekt-Divergenz

Die Operation O1 von Benutzer 1 erzeugt ein Objekt B. Relativ zeitnah wird durch die Operation O2 von Benutzer 2 ein Objekt A erzeugt. Nachdem die Operationen an den jeweils anderen Benutzer übertragen wurden und dort ausgeführt wurden zeigt sich eine Inter-Objekt-Divergenz der Dokumente.

1.5.2.2 Kausalitätsverletzung

Wie in der in der Abbildung 2 zu sehen ist, wird Operation O3 bedingt durch die nicht deterministische Netzwerkslatenz erst nach der Ankunft der Operation O1 bei Benutzer 2 erzeugt. Geht man davon aus, dass Benutzer 2 die Operation O3 als Reaktion auf O1 ausgeführt hat, besteht eine kausale Abhängigkeit, zwischen O3 und O1. Die Kausalordnung von Ereignissen gibt vor, ob diese kausal voneinander abhängig sind oder nicht. Kausal unabhängige Ereignisse werden auch als nebenläufige Ereignisse bezeichnet.

Werden Operationen, die kausal abhängig sind in falscher Reihenfolge ausgeführt, so liegt eine Kausalitätsverletzung vor.

1.5.2.3 Intentionsverletzung


Werden konkurrierende Operationen auf einem Datenobjekt ausgeführt, welche die Eigenschaften dieses Objektes ändern, so können die Änderungen einer Operation verloren gehen. Betrachten wir das gleiche Beispiel wie es beim Problem der Divergenz beschrieben wurde. Zwei konkurrierende Operationen verschieben dasselbe Objekt an unterschiedliche Positionen im Dokument. Dies führt zu unterschiedlichen Ergebnissen in den verschieden Dokumentkopien der zwei Benutzer und damit zu Divergenz. Wird nun auf irgendeine Weise eine Konvergenz hergestellt und das Objekt steht danach in beiden Dokumentkopien an derselben Position, so geht eine der beiden Änderungen verloren. Es gibt in diesem Fall keine Möglichkeit eine Konvergenz zu schaffen, die beide Intentionen der Benutzer integriert. Somit liegt hier eine Intentionsverletzung vor. Dabei handelt es sich um eine syntaktische Intentionsverletzung, die von einem System festgestellt werden kann. Es gibt auch den Fall einer semantischen Intentionsverletzung. Dabei wollen zwei Benutzer dasselbe semantisch korrekte Ergebnis erzielen, gehen aber gleichzeitig auf unterschiedliche Weise vor und es entsteht ein syntaktisch korrektes Ergebnis, das allerdings semantisch falsch ist. Ein Beispiel:

In einem Grafikdokument existieren zwei Körbe mit Äpfeln. Der eine Korb ist grün, der andere rot. Die Äpfel im roten Korb sind alle rot, die im grünen alle, bis auf einen roten Apfel, grün. Nun wollen zwei Benutzer, die gleichzeitig an diesem Dokument arbeiten, den roten Apfel aus dem grünen Korb entfernen. Der erste Benutzer verschiebt dazu den roten Apfel aus dem grünen Korb in den roten. Der zweite Benutzer färbt den roten Apfel grün. Das Endergebnis ist ein grüner Apfel im roten Korb. Die Lösung solcher semantischen Konsistenzprobleme ist noch Gegenstand der Forschung [18].

1.5.3 Mehrbenutzer Editoren in der Praxis

Mehrbenutzer-Editoren existieren für verschiedene Quellcode und Text Derivate, Word, UML, HTML, PowerPoint und verschiedene Grafikformate. Vor allem asynchrone Editoren sind häufig vertreten. Hier gibt es eine Vielzahl an Text und HTML Editoren, aber auch einige Grafikeditoren. Die meisten synchronen und asynchronen Mehrbenutzer-Editoren sind Teil eines Forschungsprojektes und basieren auf proprietären Datenformaten. In der Praxis sind die synchronen Editoren zurzeit noch weniger relevant. Dies könnte sich aber mit der rasanten Entwicklung der Netzwerk- und


Computertechnologien ändern. Es besteht allerdings noch Bedarf in der Forschung und der Entwicklung von Standards, um Mehrbenutzer Editoren so populär wie z.B. E-Mail und Chats zu machen. Oft liegen die Probleme neben der technischen Komplexität dieser Systeme in der Usability. Eine zentrale Rolle spielen allerdings auch psychologische Aspekte. Die Akzeptanz eines Echtzeit-Mehrbenutzer-Editors hängt stark vom Vertrauen der Benutzer untereinander ab. Die Benutzer müssen sich gut kennen, um sich von einem Kollegen freiwillig bei der Arbeit „über die Schulter“ blicken zu lassen. Dies kann auch wirtschaftliche Relevanz haben. Kann bei einem Echtzeit-Mehrbenutzer-Editor z.B. für die Entwicklung von Quellcode gesehen werden, was ein Entwickler wann erstellt, so könnte ein unbeliebter Chef seinen Mitarbeiter direkt nach der Anzahl der Quellcodezeilen pro Stunde bewerten und dementsprechend sein Gehalt anpassen. Wo es möglich ist, zu sehen, was und wann jemand arbeitet, so ist es auch möglich zu sehen, wann jemand nicht arbeitet. Dieser Eingriff in die Privatsphäre stellt ein großes Problem für die Akzeptanz eines Echtzeit-Mehrbenutzer-Editors dar, dem mithilfe von geeigneten Sicherheits- und Kontrollmechanismen begegnet werden muss. Im Folgenden werden Beispielhaft verschiedene Mehrbenutzer-Editoren kurz vorgestellt. Eine relativ umfassende Aufstellung asynchroner und synchroner Mehrbenutzer-Editoren findet man in [19].

� SAMS [1]: Synchronous/Asynchronous/Multisynchronous

Editor. Dieser erlaubt das Editieren von speziellen im Software-Design eingesetzten Objekt-Karten und einfachen HTML Dokumenten. Dabei kann zwischen den verschiedenen Synchronisationsmodi umgeschaltet werden. Es kann auf Knopfdruck synchronisiert werden, oder die Arbeit wird auf dem Dokument zunächst alleine durchgeführt und es wird zu einem späteren Zeitpunkt synchronisiert. Es handelt sich dabei um ein Forschungsprojekt.

Beispiele für Mehrbenutzer-Editoren

� MoonEdit30: Dies ist ein kooperativer synchroner Mehrbenutzer Texteditor, der die Mausbewegungen der anderen Teilnehmer sichtbar macht. Es handelt sich dabei um ein Freeware Projekt

� CoWord und CoPowerPoint [15]: Dies sind Anwendungen, die als Erweiterung (Plug-In) für das Microsoft Word31 Produkt installiert werden. Sie erlauben das synchrone Bearbeiten von Microsoft Word und PowerPoint Dokumenten. Forschungsprojekt

30 http://moonedit.com/ 31 http://office.microsoft.com/en-us/default.aspx


� Kollaborativer UML-Editor32: Im Rahmen des COAST Framework Projektes (1999) entstanden. Erlaubt das gemeinsame synchrone Editieren von UML Dokumenten. Forschungsprojekt

� REDUCE [14]: Kollaborativer Webbasierter Texteditor. Erlaubt das bearbeiten von einfachsten Texten in Echtzeit. Forschungsprojekt

� GRACE [18]: Kollaborativer synchroner Grafikeditor. Erlaubt das gleichzeitige Bearbeiten von einfachen Grafiken im Team. Forschungsprojekt

� SubEthaEdit33 ist ein Studentisches Projekt, das 2003 mit dem Apple Design Award ausgezeichnet wurde. Es handelt sich dabei um einen Texteditor mit dem auch so genanntes Extreme-Programming möglich ist. Freeware für Privatnutzer

� CoDraft [20]. Eine verteilte Architektur zur Unterstützung von Gruppenarbeit durch Multimediale Objekte. Forschungsprojekt

� SEPIA [21] Ein Editor für Hypertext Dokumente. Forschungsprojekt

32http://www.darmstadt.gmd.de/concert/activities/internal/umledit.html 33 http://www.subethaedit.de/collaborate.de.html


1.6 Nebenläufigkeitskontrolle in CSCW Systemen

Um inkonsistente Daten bei der Arbeit in der Gruppe zu vermeiden, werden Zugriffskontroll- bzw. Nebenläufigkeitskontrollverfahren (engl.: concurrency control methods) eingesetzt. Frei nach der Definition von Bernstein et al. [22] versteht man unter Nebenläufigkeitskontrolle die Koordination der Aktionen verschiedener Prozesse, die gleichzeitig auf gemeinsame Daten zugreifen und sich damit potentiell behindern. Es gibt prinzipiell zwei Funktionsweisen der Nebenläufigkeitskontrolle:

1. Konsistenzerhalt durch Konfliktprävention 2. Konsistenzerhalt durch Konfliktauflösung

Die am häufigsten eingesetzten Verfahren, sind das Turn-Taking,

das Split-Combine und das Copy-Merge Verfahren, bei denen der Zugriff durch Absprache der Teilnehmer oder durch andere Vorgaben zeitlich und/oder lokal begrenzt wird. Der Zugriff erfolgt entweder nacheinander oder auf Kopien des betreffenden Artefakts. Turn-Taking und Split-Combine sind Verfahren der Konfliktprävention, Copy-Merge ein Verfahren bei dem Konflikte nachträglich gelöst werden müssen. Diese Verfahren werden deshalb oft eingesetzt, da sie sehr einfach sind und häufig keine zusätzliche Installation einer Software erfordern. Sie bringen aber Nachteile in Bezug auf den Zeitaufwand und die Nachvollziehbarkeit von Änderungen mit sich.

Zu den Verfahren der Konfliktvorbeugung zählen unter anderem auch die, in der Datenbankwelt weit verbreiteten, Sperrverfahren, zum Beispiel das pessimistischen Sperrverfahren. Diese Sperrverfahren (engl. locking) sind softwaregestützt und werden in den meisten CSCW Systemen, wie Groupware, Versionsverwaltung und Mehrbenutzer Editoren eingesetzt. Eine zentrale Instanz (Server) regelt dabei den Zugriff der Teilnehmer (Clients) auf die Artefakte. Mit Hilfe eines sogenannten Check-In/Check-Out Mechanismus werden die Daten bereitgestellt.

Zum Konsistenzerhalt werden verschiedenste Verfahren eingesetzt

Daneben gibt es noch Verfahren, die vor allem in Mehrbenutzer Editoren zum Einsatz kommen, da sie deren besondere Anforderungen, wie echtzeitnahe Antwortzeiten und feingranulare Nebenläufigkeitskontrollen (z.B. auf Buchstabenebene) unterstützen. Dieser Abschnitt beschreibt die gängigsten Nebenläufigkeitskontrollverfahren.

1.6 Nebenläufigkeitskontrolle in CSCW Systemen 31

1.6.1 Nebenläufigkeitskontrolle ohne CSCW System

Beim Turn-Taking kann immer nur eine Person zu einer gegebenen Zeit auf ein Artefakt (z.B. ein Textdokument) zugreifen. Hat die Person ihre Arbeit an dem Artefakt abgeschlossenen, so wird das Artefakt an die nächste Person, „die an der Reihe ist“, weitergereicht. Wer wann „an der Reihe“ ist, wird entweder mithilfe einer technischen Lösung (z.B. Software) oder durch Absprache der Teilnehmer bestimmt. Nach der Übergabe kann nun die nächste Person ihrerseits Änderungen am Artefakt durchführen. Auf diese Art und Weise ist es möglich das Artefakt sehr einfach konsistent zu halten, da zu jedem Zeitpunkt immer nur eine gültige Artefaktversion existiert.

Eine andere Möglichkeit der Zusammenarbeit ist das Aufteilen der Arbeit in kleinere Arbeitspakete. Dabei bekommt jeder Teilnehmer ein Arbeitspaket zugeteilt. Nach Erledigung der Arbeit werden die einzelnen Ergebnisse an zentraler Stelle wieder zusammen geführt. Dieses sogenannte Split-Combine Verfahren erfordert neben dem aufwändigen nachträglichen Zusammenführen der Artefakte auch eine Aufteilbarkeit der Aufgabe in Arbeitspakete.

Turn-Taking, Split-Combine und Copy-Merge

Dies ist z.B. bei Quellcode nicht immer möglich, da eine Abhängigkeit der Quelldateien untereinander besteht. Daher wird hier oft das sogenannte Copy-Merge Verfahren eingesetzt. Dabei erhält jeder Teilnehmer eine Kopie aller vorliegenden Artefakte und kann nun selbständig Änderungen daran vornehmen. Am Schluss müssen alle Änderungen allerdings wieder zusammen geführt (engl.: to merge) werden. Dies kann unter Umständen sehr aufwendig sein. Die Nachvollziehbarkeit der Änderungen ist besonders bei größerer Personenzahl nur schwer möglich, da nach einem erfolgreichen Zusammenführen im Artefakt keine Informationen über die jeweils durchgeführten Änderungen gespeichert sind (keine Versions-informationen).

Trotz dieser Nachteile wird heute oft so gearbeitet - gerade bei der Erstellung von Dokumenten und der Umsetzung von Softwareprojekten in kleineren Teams, ohne Unterstützung durch ein CSCW System.


1.6.2 Sperrverfahren

Sperrverfahren werden besonders in Datenbanksystemen eingesetzt um den Erhalt der seriellen Äquivalenz zu gewährleisten und den parallelen Zugriff auf Daten zu synchronisieren. Das grundlegende Prinzip beim Sperren paralleler Zugriffe ist sehr einfach, aber nicht besonders geeignet für produktive Systeme. Daher wurden optimierte Sperrverfahren und –algorithmen entwickelt, die den Anforderungen produktiver Systeme gewachsen sind. Im Folgenden werden die zwei hauptsächlich verwendeten Verfahren, das pessimistische und das optimistische Sperren und verschiedene Varianten dieser besprochen.

1.6.2.1 Pessimistisches Sperren

Aus den Synchronisationstechniken der Betriebssysteme (wie z.B. Semaphore, Mutexe und Monitore) ist das sogenannte exklusive Sperren (engl.: exclusive locking) entstanden. Um auf ein Datenobjekt zuzugreifen, muss dabei zunächst eine exklusive Sperre für dieses Objekt besorgt werden. Diese Sperre verhindert den Zugriff aller anderen Transaktionen auf das gesperrte Datenobjekt. Wird zum Beispiel in einer Transaktion T2 versucht eine Sperre auf ein Datenobjekt zu erlangen, welches sich bereits im Zugriff einer anderen Transaktion T1 befindet, so muss T2 warten, bis T1 die Sperre wieder frei gibt. Für den Fall, dass viele parallele Transaktionen auf dieselben Datenobjekte zugreifen, kann allerdings eine schlechte Systemperformanz die Folge sein. Daher wurde, um die Performanz zu verbessern, die sogenannte Teil-Sperre (engl.: shared lock) oder Lese-Sperre (engl.: read lock) eingeführt. Für eine verbesserte Systemperformanz wird dabei davon ausgegangen, dass das Lesen von Datenobjekten weitaus öfter vorkommt, als das Schreiben dieser. Eine Lese-Sperre erlaubt dabei das Lesen eines Datenobjekts in parallelen Transaktionen, aber nicht das Ändern desselben. Um das Datenobjekt nun zu ändern wird weiterhin eine exklusive Sperre benötigt. Dieses Verfahren wird TX (Teil-, Exklusiv-) oder LX (Lese-, Exklusiv-) Sperren genannt (engl.: SX oder RX locking). Die Abbildung zeigt die Kompatibilität der zwei Sperrmodi (Lese- und Exklusive Sperre).

Pessimistisches Sperren kommt häufig in Datenbanksystemen zum Einsatz


Abbildung 4: Kompatibilitätsmatrix des LX

Sperrmechanismus

In TrDaTrauSpvokaDakeVezuso au(VTrveMepreallweNedaZeDi

Verfahren zur Lösung der Deadlock Problematik

ZwPheinScSpPh

1 CSy34

Aktuelle Sperre + kompatibel

--+X

-++L

XLKS

--+X

-++L

XLKS

Gew

ünsc

hte

Sper

re

- nicht kompatibel

KS - Keine Sperre

L – Lese Sperre

X – Exklusive Sperre

der Abbildung zeigt KS den Zustand an, in dem keine

ansaktion eine Sperre auf ein Datenobjekt hält. Ein Sperren dieses tenobjekts ist im diesem Fall immer gestattet. Hält eine andere ansaktion bereits eine Lese-Sperre, kann eine weitere Transaktion ch eine Lese-Sperre für dasselbe Datenobjekt erhalten. Lese-erren sind daher kompatibel, was bedeutet, dass ein Datenobjekt n beliebig vielen Transaktionen zur selben Zeit gelesen werden nn. Eine Anfrage nach einer exklusiven Sperre für ein tenobjekt wird allerdings nur gewährt, solange dieses Objekt mit iner Sperre durch eine weitere Transaktion belegt ist. rsucht eine Transaktion eine Exklusivsperre für ein Datenobjekt erhalten, welches bereits gesperrt ist (Lese- oder Exklusivsperre), wird diese solange blockiert, bis die entsprechende Sperre wieder fgehoben wurde. Dabei kann es zu einem so genannten Deadlock erklemmung) kommen. Bei einem Deadlock warten ansaktionen unendlich lange auf die Freigabe einer Sperre. Es gibt rschiedenste Methoden um Deadlocks zu vermeiden: Eine thode ist zum Beispiel das so genannte Vorbelegen (engl.: claiming) oder statisches Sperren (engl.: static locking), bei dem

e benötigten Sperren einer Transaktion gleich zu Beginn besorgt rden. Andere Methoden sind zum Beispiel das sofortige ustarten einer Transaktion (engl.: immediate restart, no waiting), s WDL (wait depth limited) Verfahren oder die Verwendung von itstempeln in Transaktionen (wait/die, wound/wait Verfahren). ese Verfahren werden näher von Härder et al. [23] besprochen. Ein weiteres pessimistisches Sperrverfahren ist das sogenannte ei-Phasen-Sperren (engl.: two phase locking). In der ersten

ase, der Wachstumsphase (engl.: growing phase), besorgt sich e Transaktion alle benötigten Sperren. In der zweiten Phase, der hrumpfphase (engl.: shrinking phase), gibt die Transaktion die erren wieder frei. Die Abbildung zeigt die Phasen der Zwei-asen-Sperrmethode.

omputer Supported Cooperative Work (CSCW) – Kollaborative steme und Anwendungen

Treten während der Schrumpfphase Probleme auf und die

Transaktion muss rückgängig gemacht werden (engl. rollback), so kann es zu einem so genannten “dirty read” (dreckiger Lesevorgang) kommen: Dabei wird in einer Transaktion mit Daten gearbeitet, die durch den „Rollback“ einer anderen Transaktion bereits ungültig sind. Man spricht dabei auch von sogenannten unbestätigten Abhängigkeiten (engl.: uncommited dependency).

Eine Möglichkeit einen „dirty read“ zu verhindern, ist das so genannte strikte Zwei-Phasen-Sperren (engl.: strict two phase locking). Dabei wird die komplette Schrumpfphase erst am Ende der Transaktion durchgeführt, wenn ein erfolgreicher Abschluss sicher ist. Die Abbildung zeigt den Ablauf einer strikten Zwei-Phasen-Sperre.

Beginn der Transaktion Commit

Wachstumsphase Schrumpfphase

Zeit

Abbildung 5: Zwei-Phasen Sperrmethode

Sperrstufen

Sperrstufen

Beginn der Transaktion Commit

Wachstumsphase

Zeit

Abbildung 6: Strikte Zwei-Phasen-Sperre


1.6.3 Optimistisches Sperren

Beim optimistischen Sperren wird davon ausgegangen, dass Zugriffskonflikte nur relativ selten auftreten (daher optimistisch) und das präventive Sperren von Datenobjekten unnötig hohen Aufwand und Leistungseinbußen bedeuten würde. Erst am Ende einer Transaktion wird geprüft, ob Konflikte aufgetreten sind. So sind parallele Transaktionen möglich und es entstehen keine Zeitverzögerungen durch das Warten auf freiwerdende Sperren.

Der Ablauf einer Transaktion ist beim optimistischen Sperren in drei Phasen aufgeteilt. In der Lesephase, werden die Datenobjekte gelesen und lokale Kopien angelegt, auf denen Änderungen durchgeführt werden.

Nachdem die Transaktion abgeschlossen (commited) wurde, beginnt die Validierungsphase. In dieser Phase wird geprüft, ob durch die Transaktion ein Integritätsverlust auftritt oder das gewünschte Ergebnis erzielt wird. Schlägt die Validierung fehl, wird die Transaktion rückgängig gemacht und beginnt von neuem. In diesem Fall, werden Konflikte durch das Rückgängigmachen und neue Starten von einer oder mehrere beteiligter Transaktionen gelöst. Dies bedeutet allerdings, dass mehr Rollbacks auftreten als beim pessimistischen Sperrverfahren. Dagegen ist das Auftreten von Deadlocks, im Gegensatz zum pessimistischen Sperren nicht möglich.

Falls sichergestellt werden kann, dass die Änderungen einer Transaktion nicht zu einem Integritätsverlust führen, werden die lokalen Kopien in der dritten Phase, der Schreibphase, als global gültig erklärt. Die Abbildung zeigt die drei Phasen einer Transaktion beim optimistischen Sperrverfahren.

Abbildung 7: Drei Phasen des optimistischen Sperrverfahrens

DDatAuf

1 CSys36

Lesen Valid ieren Schreiben

Com m it

Zeit

as Ausführen von Operationen auf lokalen Kopien von enobjekten hat Vor- und Nachteile. Ein Vorteil ist, dass das treten von „dirty-reads“ oder „dirty-writes“ verhindert wird. Ein


weiterer Vorteil ist die hohe Parallelität von Operationen, die durch das gleichzeitige Ändern und Lesen von Datenobjekten erzielt werden kann. Das Rückgängigmachen einer Transaktion wird einfach durch das Verwerfen der Änderungen auf den lokalen Kopien der Datenobjekte erreicht.

Ein Nachteil des optimistischen Sperrverfahrens ist der höhere Speicherverbrauch durch die lokalen Kopien und die benötigten komplexen Puffer-Mechanismen. Die Schreibphase kann in Bezug auf die Performanz des Gesamtsystems sehr teuer werden, falls eine große Anzahl von Schreiboperationen in einer Transaktion ausgeführt werden müssen. In diesem Fall besteht eine erhöhte Gefahr des „Verhungerns“ (engl.: starvation) einer Transaktion. Diese tritt auf, wenn die Validierung von Transaktionen ständig fehlschlägt. Dies tritt besonders bei sehr langen Transaktionen auf, das heißt bei Transaktionen, die sehr viele Leseoperationen beinhalten und damit gegen viele andere Transaktionen validiert werden müssen. Zusätzlich kann das erst relativ spät durchgeführte Rückgängigmachen (Rollback) einer Transaktion (im Falle eines Konfliktes) zu vielen unnötig durchgeführten Operationen führen, was wiederum Einbussen in der Systemperformanz zur Folge haben kann.

Es ist möglich pessimistische und optimistische Sperrverfahren zu kombinieren. Beispiele für solche „hybrid“-Ansätze findet man in Datenbanksystemen wie zum Beispiel IMS Fast Path34 oder GemStone35. Diese versuchen durch die Kombination beider Verfahren deren Vorteile zu nutzen, ohne die Nachteile in Kauf nehmen zu müssen. Das IMS Fast Path System verwendet zum Beispiel eine spezielle Kombination von pessimistischen und optimistischen Verfahren. Dabei werden Datenobjekte zunächst in der Lesephase wie beim optimistischen Verfahren behandelt. Erst in der Validierungs- und Schreibphase werden sie gesperrt. Durch die damit verbundene Reduzierung der Sperrzeit im Vergleich zu dem rein pessimistischen Verfahren, wird die Wahrscheinlichkeit eines Blockierens anderer Transaktionen stark reduziert.

Kombination pessimistischer und optimistischer Sperrverfahren

Ein ähnlicher Ansatz wird in verschiedenen Versionsverwaltungssystemen wie zum Beispiel CVS oder Subversion verwendet. Dabei werden Änderungen an Datenobjekten zunächst nur auf lokalen Kopien durchgeführt. Sobald die Änderungen bestätigt (engl.: commited) wurden, werden Sie zentral gesperrt. Nun wird geprüft, ob Konflikte mit anderen Transaktionen bestehen (Validierung). Mithilfe von Zeitstempeln wird dabei

34 http://www-306.ibm.com/software/data/ims/ 35 http://www.gemstone.com/


geprüft, ob Datenobjekte in der Zeit zwischen dem Erstellen der lokalen Kopie und dem Bestätigen der Änderungen geändert wurden. Schlägt die Validierung fehl, so wird entweder die Transaktion rückgängig gemacht oder der Teilnehmer, der die Transaktion ausgeführt hat, benachrichtigt. Dieser kann dann entscheiden, ob seine eigenen oder die Änderungen der anderen Teilnehmer verworfen, oder alle Änderungen zusammen geführt werden (engl.: merge). Das Zusammenführen der Änderungen kann dabei automatisch, halbautomatisch oder manuell geschehen. Ein Vorteil dieser Vorgehensweise ist die relativ kurze Zeit in der Validierungsphase, in der die Datenobjekte gesperrt werden und die damit geringere Wahrscheinlichkeit für Transaktionskonflikte und Rollbacks. Ein Nachteil ist die mit der Anzahl der Teilnehmer steigende Wahrscheinlichkeit von Konflikten (Validierungsfehlern). Die Wahrscheinlichkeit der Konflikte ist zusätzlich abhängig von der Granularität der Sperre (z.B. Dokumentebene oder Buchstabenenebene), der Größe und Anzahl der Artefakte und die Verteilung der gleichzeitigen Zugriffe auf diese. Ist die Granularität der Sperren klein (z.B. Sperren von einzelnen Buchstaben eines Dokumentes) und die Anzahl und Größe der Artefakte hoch, so sinkt die Wahrscheinlichkeit für Konflikte. Die Sperrgranularität bestimmt dabei die kleinste Einheit eines Sperrvorganges. Systeme wie VSS36 und CVS37 aber auch andere existierende CSCW Systeme zur Unterstützung der Arbeit im Team wie zum Beispiel Wikis38 oder die HTTP Protokollerweiterung WebDAV39 verwenden nur eine Sperrgranularität auf Dokumentebene. Das heißt es wird immer das komplette Dokument gesperrt, auch wenn tatsächlich nur ein kleiner Teil bearbeitet wird.

Die Wahrscheinlichkeit für Konflikte ist von

verschiedensten Parametern abhängig

1.6.4 Zeitstempelverfahren

Bei diesem Verfahren werden zum Erhalt der seriellen Äquivalenz Zeitstempel eingesetzt. Bei Beginn jeder Transaktion wird ein Zeitstempel gesetzt und dieser zugeordnet. Im Gegensatz zu den Sperrverfahren, steht hier die Serialisierungsreihenfolge der nebenläufigen Transaktionen und deren Operationen fest und wird

36 Microsoft Visual SourceSafe©: http://msdn.microsoft.com/vstudio/previous/ssafe/ 37 Concurrent Versioning System CVS: http://www.nongnu.org/cvs/ 38 Wiki Software: http://en.wikipedia.org/wiki/Wiki_software 39 Web-based Distributed Authoring and Versioning. WebDAV: http://www.webdav.org/


über die Zeitstempel ermittelt. Eine Transaktion muss dabei nur auf Konflikte mit Transaktionen, die zeitlich vor ihr liegen, geprüft werden. Transaktionen, die einen späteren Zeitstempel tragen werden nicht in Betracht gezogen. Tritt ein Konflikt auf, so wird die betreffende Transaktion rückgängig gemacht und mit einem neuen Zeitstempel wiederholt. Die Transaktionen werden also nach ihren Zeitstempeln geordnet, daher nennt man dieses Verfahren Zeitstempelordnungs- (engl.: timestamp ordering) oder Zeitstempelverfahren. Der Vorteil dieses Verfahrens liegt in der impliziten Verhinderung von Deadlocks[22]. Innerhalb einer Transaktion werden zur Konfliktprüfung für jeden Lese- und Schreibzugriff Zeitstempel gesetzt. Jedes Datenobjekt, auf das zugegriffen wurde erhält entsprechend einen Lese-Zeitstempel (Sr) bzw. einen Schreib-Zeitstempel (Sw). Eine Leseoperation mit Zeitstempel Sr(T) einer Transaktion T ist nicht erlaubt, wenn das zu lesende Datenobjekt X einen Schreib-Zeitstempel besitzt der neuer (>) ist als Sr(T). Gilt: Sr(T) < Sw (X),

so muss die Transaktion zurückgesetzt werden. Entsprechend

wird die Transaktion zurückgesetzt, falls auf ein Datenobjekt geschrieben werden soll, welches einen Lesestempel neueren Datums besitzt. Damit ist eine Transaktion nur gültig, solange keine andere Transaktion zu einem späteren Zeitpunkt als T dasselbe Datenobjekt X ändert. Generell ist eine Schreiboperation Sw(T) nicht erlaubt falls gilt: Sw(T) < Max(Sr(X), Sw (X))

Entweder wird die Transaktion zurückgesetzt (Sw(T)<Sr(T)), oder der Schreibbefehl ignoriert (Sw(T)<Sw(X)).

T1

T2

W(X) R(Y)

R(X)

W(Y)

Rollback von T1

T3

Schreiboperation: W(X)Leseoperation: R(X), R(Y)

Zeit

Abbildung 8: Szenario Zeitstempelverfahren


Die Abbildung zeigt ein Szenario, in dem die Transaktionen T1 und T2 auf dasselbe Datenobjekt X in der richtigen Transaktionsreihenfolge zugreifen. In dem Moment, in dem T1 auf das Datenobjekt Y zugreift, wurde es bereits durch Transaktion T3 geändert, was dazu führt, dass T1 zurückgesetzt wird. Das Beispiel zeigt, dass mit der Dauer einer Transaktion die Wahrscheinlichkeit für ein Zurücksetzen (Rollback) ansteigt. Es kann dabei in manchen Fällen zu einem so genannten „Verhungern“ (engl.: starvation) einer Transaktion kommen. Auch besteht bei diesem Verfahren die Gefahr eines „dirty writes“ durch unbestätigte Abhängigkeiten.

1.6.5 Operational Transformation

Das Ziel der Operational Transformation (OT) ist der Erhalt der Konsistenz durch Konfliktauflösung. Dabei werden Operationen sofort, d.h. ohne Verzögerung ausgeführt, wodurch eine sehr schnelle Reaktionszeit ermöglicht wird. Der Benutzer muss also, im Gegensatz zu Sperrverfahren, nicht warten, bis eine Sperre auf dem zu bearbeitenden Datensatz durchgeführt wurde. Operationen werden direkt auf einer lokalen Kopie des Dokuments durchgeführt und erst danach an die anderen Clients verteilt. Dort werden sie erneut durchgeführt. Eine Operation kann dabei, wenn sie von einem Client empfangen wurde, vor ihrer Durchführung zunächst transformiert werden. Die Transformation hat dabei das Ziel, die Intention der Benutzer beizubehalten und die auf allen Clients vorliegenden Dokumentkopien zu konvergieren [24]. Verschiedenste Vorschläge für Operational Transformation Algorithmen existieren. Die meisten sind für Dokumente, die auf einem linearen Datenformat (z.B. ASCII Textdokumente) basieren, geeignet. Einige davon sind unter anderem dOPT [25], adOPTed [26], GOT [27], GOTO [28], SOCT2 [29]. Zurzeit gibt es nur wenige Algorithmen für Operational Transformation, welche auf einem hierarchischen Datenformat (z.B. XML) basieren: Einer davon ist der treeOPT [24] Algorithmus. Die meisten dieser OT Algorithmen arbeiten nach demselben Prinzip der Konsistenzerhaltung.

Operational Transformation erfüllt die hohen Anforderungen

der Mehrbenutzer Editoren

Der Operational Transformation Algorithmus wurde ursprünglich entwickelt, um die Probleme der Divergenz (s. Abschn. 1.5.2.1), Intentionsverletzung (s. Abschn. 1.5.2.2) und der Kausalitätsverletzung (s. Abschn. 1.5.2.3) in kollaborativen Editiersystemen zu beheben. Ein kollaboratives Editiersystem wird


dabei als konsistent bezeichnet, wenn es immer den Erhalt von Konvergenz, Intention und Kausalität gewährleistet.

Bei der Operational Transformation wird zur Bewahrung der Kausalität ein Zeitstempel-Verfahren auf Basis der „Vector-Logical Clock“ [30, 29] verwendet. Dadurch kann sichergestellt werden, dass eine Operation A, die nach der Kausalordnung „vor“ einer Operation B liegt (A < B), auch vor dieser ausgeführt wird. dies geschieht unabhängig davon, in welcher Reihenfolge die Operationen jeweils beim entsprechenden Teilnehmer eintreffen. Zum Erhalt der Konvergenz und der Intention einer Operation wird eine totale Ordnungsrelation [24,31,32] (engl. total ordering relation) zwischen den Operationen definiert. Diese legt fest, in welcher Reihenfolge welche Operationen auf der jeweiligen lokalen Kopie eines Dokuments ausgeführt werden. In einem sogenannten History-Buffer werden zusätzlich alle ausgeführten Operationen gespeichert. Jede Operation wird basierend auf der Ordnungsrelation und den bereits ausgeführten Operationen im History-Buffer vor ihrer Ausführung transformiert, um auf die Änderungen zu reagieren, die durch die anderen Operationen hervorgerufen wurden. Um dies zu verdeutlichen zeigt die folgende Abbildung das Szenario eines Editiervorganges ohne Transformational Operation.

Zeitstempel zur Bewahrung der Kausalität

Dabei arbeiten zwei Benutzer an einem gemeinsamen Dokument, welches den Text „Schiffart“ enthält. Der Text kann durch die Operation Ins(p,c) modifiziert werden. Durch diese Operation wird ein Buchstabe c an Position p im Text eingefügt. Es wird angenommen, dass die Position des ersten Buchstaben im Text 0 ist. Die Benutzer generieren die Operationen O1 = Ins(4,f) und O2 = Ins(7,h). Wird die Operation O1 beim zweiten Benutzer empfangen und ausgeführt, so führt dies zu dem erwarteten Ergebnis „Schifffahrt“.

Der History-Buffer enthält alle ausgeführten Operationen


Abbildung 9: Szenario ohne Operational Transformation

I

wirwueineErgvonkanBenDoDieTra

1 CSys42

Schiffart Schiffart

Schifffart

Schifffhart

Schiffahrt

Schifffahrt

Ins(4,f) Ins(7,h)

Ins(4,f)Ins(7,h)

Operation O1 Operation O2

DokumentBenutzer 1

DokumentBenutzer 2

Zeit

m Dokument des ersten Benutzers sieht dies anders aus. Dort d nicht beachtet, dass die Operation O1 bereits zuvor ausgeführt rde und damit die Textlänge verändert wurde. Das Resultat ist Divergenz der beiden lokalen Dokumente. Um ein korrektes ebnis zu erhalten, muss die Operation O2 unter Einbeziehung O1 zuerst transformiert werden, bevor sie ausgeführt werden n. Wird nun zum Beispiel die Operation O2 im Dokument von utzer 1 in Ins(8,h) transformiert, so wird eine Konvergenz der

kumente erzielt. folgende Abbildung zeigt das Beispiel mit Operational nsformation.


Abbildung 10: Szenario mit

Schiffart Schiffart

Schifffart

Schifffahrt

Schiffahrt

Schifffahrt

Ins(4,f) Ins(7,h)

Ins(4,f)Ins(8,h)

Operation O1 Operation O2

DokumentBenutzer 1

DokumentBenutzer 2

Tra

nsf

orm

atio

n d

er O

per

atio

n

Zeit

Operational Transformation

1.7 Architektur kollaborativer Systeme

Ein CSCW System kann je nach Anforderung auf verschiedenste Weise aufgebaut sein. In diesem Abschnitt werden die wichtigsten Software-Architekturen von CSCW Systemen vorgestellt. Es wird dabei nur auf den abstrakten Aufbau und dessen Vor- und Nachteile eingegangen. Neben der Software-Architektur spielen die Netzwerkarchitektur und die Sicherheitsarchitektur eine wichtige Rolle bei der Entwicklung eines CSCW Systems. Oft kommen hier Standards zum Einsatz auf denen die CSCW Systeme aufsetzen. Zum Beispiel werden zur Übertragung von Daten zwischen CSCW Clients häufig ein VPN (Virtual Private Network) und entsprechende Verschlüsselungsverfahren eingesetzt, um eine sichere Datenübertragung über das Internet zu gewährleisten. Im Bereich der Netzwerkanbindung spielen immer mehr mobile

1.7 Architektur kollaborativer Systeme 43

Datennetze eine Rolle. Dabei werden Daten zum Beispiel über GPRS oder UMTS ausgetauscht. Hier müssen bei der Planung eines mobilen CSCW Systems die Eigenschaften des verwendeten Datennetzes in Betracht gezogen werden, wie z.B. geringe Bandbreite und Übertragungsausfall durch z.B. Funklöcher.

1.7.1 Zentralisierte Architektur

Die zentralisierte Architektur ist die am meisten verbreitete Client/Server Architektur bei verteilten Systemen. Dabei verwaltet ein zentraler Server die, sich im Zugriff mehrerer Clients befindlichen Daten. Die Clients können nicht direkt auf die Daten zugreifen. Der Zugriff wird vom Server geregelt.

Die zentralisierte Architektur ist oft bei Datenbank Management Systemen zu finden. Aber auch bei CSCW Systemen ist sie sehr beliebt. Vor allem Versionsverwaltungssysteme aber auch viele Groupware Systeme basieren auf dieser klassischen Client/Server Architektur. Bei Echtzeit Mehrbenutzer Editoren kommt sie seltener zum Einsatz, da hier besondere Anforderungen, wie geringe Antwortzeiten bestehen. Diese können durch eine zentralisierte Architektur nicht in allen Fällen erfüllt werden.

Die zentralisierte Architektur wird am häufigsten eingesetzt

Bei der zentralisierten Architektur besitzt der Server einen oder mehrere Server-Prozesse. In der einfachsten Variante besitzt ein Server nur einen Prozess. Somit ist ein gleichzeitiger Zugriff mehrerer Clients auf eine Ressource nicht möglich. Dadurch kann auf einfachste Weise eine Dateninkonsistenz vermieden werden. Ein Nachteil dabei ist allerdings die schlechte Performanz des Gesamtsystems, da der Datenzugriff solange blockiert wird, solange ein Client die Daten (wie zum Beispiel ein verteiltes Dokument) auf dem Server bearbeitet. Um dennoch die „Illusion“ des gleichzeitigen Zugriffs mehrer Clients auf die Datenobjekte zu schaffen, unterstützen Systeme dieser Art sehr feinkörnige Operationen, die in sehr kurzer Zeit durchgeführt werden können.

In der Regel werden aber bei modernen Systemen mehrere Server-Prozesse gestartet, um die Performanz des Gesamtsystems zu verbessern. Damit können gleichzeitig Anfragen von mehreren Clients entgegen genommen werden. Werden Datenobjekte nicht nur gelesen (wie z.B. bei Webservern der Fall) sondern auch geschrieben, so muss ein Nebenläufigkeitskontrollverfahren eingesetzt werden um Dateninkonsistenzen zu vermeiden. Will ein Client auf Datenobjekte des Servers zugreifen, muss zunächst eine Anfrage an den Server übertragen werden. Dort


entscheidet der Server mithilfe des eingesetzten Nebenläufigkeitskontrollverfahren (wie z.B. Sperrverfahren), ob ein Zugriff durch den Client zu diesem Zeitpunkt erlaubt ist. Je nach eingesetzten Verfahren kann es hierbei zu einer entsprechenden Verzögerung kommen (z.B. bei Blockierung durch Sperre). Wird der Zugriff erlaubt, so kann die gewünschte Operation der Clients (z.B. Lesen oder Schreiben eines Datenobjekts) ausgeführt werden und der Client erhält eine Antwort vom Server mit der Bestätigung seiner Anfrage. Dieser Ablauf kann relativ zeitaufwändig sein und hängt eventuell von vielen „äußeren“ Faktoren wie zum Beispiel der Netzwerkverbindung ab. Daher ist diese Architektur für sehr zeitkritische kollaborative Anwendungen unter Umständen weniger geeignet. Die folgende Abbildung zeigt den Aufbau einer zentralistischen Systemarchitektur.

ServerServer

DatenSpeicherDaten

Speicher

ClientClient

ClientClient

ClientClient

ClientClient

1.7.2 Replizierte Architektur

Bei der replizierten Architektur existiert keine zentrale Daund kein zentraler Server. Jeder Client besitzt eine Kopie ddie sich im gemeinsamen Zugriff befinden. Die Daten werdentweder komplett repliziert oder, je nach System, nur die Dfür den Client relevant sind. Jeder Client besitzt zusätzlichServer-Prozess, der den Zugriff auf die Daten Synchronisation dieser verwaltet. Dazu kommuniziert de

1.7 Architektur kollaborativer

Abbildung 11: Zentralisierte Architektur mit nur einem Server Prozess

tenquelle er Daten, en dabei aten, die

eine Art und die r Server-

Systeme 45

Prozess mit allen anderen Client Server-Prozessen. Die Abbildung zeigt einen Überblick der Architektur.

Abbildung 12: Replizierte

Systemarchitektur

EAwisdOwSloAInw

Mehrbenutzer-Editoren verwenden meist die replizierte

Architektur

InDDNO

sid

1S46

ClientClient

ServerServer DatenSpeicherDaten

Speicher

ClientClient

ServerServerDatenSpeicherDaten

Speicher

ClientClient


Speicher

ClientClient


Speicher

ine replizierte Architektur bietet den Vorteil schneller ntwortzeiten an der Benutzerschnittstelle. Lokale Operationen erden direkt vom lokalen Server-Prozess ausgeführt. Das Ergebnis t sofort sichtbar, da keine Netzwerkkommunikation und Prüfung er Anfrage benötigt wird. Erst nach der lokalen Ausführung eine peration, wird diese an alle anderen Teilnehmer der Kollaboration eitergegeben, die daran interessiert sind. Sobald die anderen erver-Prozesse die Operation empfangen, führen sie diese auf deren kalen Kopien der Daten aus. Ein weiterer Vorteil ist eine geringere usfallwahrscheinlichkeit des Gesamtsystems, da es keine zentrale stanz gibt, bei deren Ausfall das System zum Stillstand gebracht ird (kein „Single-Point-of-Failure“). Nachteil dieser Architektur ist das Problem der möglichen

konsistenzen, die bei der gleichzeitigen Bearbeitung eines atensatzes durch mehrere Server-Prozesse auftreten können. iesem Problem wird versucht mit verschiedenen ebenläufigkeitskontrollverfahren, wie zum Beispiel der perational Transformation zu begegnen. CSCW Systeme, die eine solche replizierte Architektur einsetzen

nd meist Mehrbenutzer Editoren, die besondere Anforderungen an ie clientseitigen Antwortzeiten haben. Dazu gehören zum Beispiel

Computer Supported Cooperative Work (CSCW) – Kollaborative ysteme und Anwendungen

das COAST Framework und darauf basierende Systeme (s. [33, 34, 35, 36, 37, 38, 39]).

Eine ähnliche Architektur wie diese wird auch von so genannten Peer-to-Peer (P2P) Systemen oder manchen online Spielen eingesetzt. Bei P2P Systemen liegt der Fokus allerdings nicht unbedingt auf schnellen Antwortzeiten, sondern auf möglichst geringen Ausfallwahrscheinlichkeiten durch die Unabhängigkeit von zentralen Datenspeichern (für weitere Informationen zu P2P Systemen s. Kap. Verteilte Systeme).

1.7.3 Hybrid-Architektur

Bei der so genannten Hybrid-Architektur gibt es einen zentralen Server, der immer eine aktuelle Version des zu bearbeitenden Datenobjekts (Artefakt), z.B. eines Dokuments, besitzt. Die verschiedenen Clients besitzen jeweils lokale Kopien der gemeinsam genutzten Datenobjekte (komplett oder teilweise). Die Clients besitzen zusätzlich, wie auch bei der replizierten Architektur einen eigenen Server-Prozess, der für die Verwaltung der Zugriffe auf die Daten und die Übertragung der Operationen an die anderen Clients zuständig ist. Mit der hybriden Architektur wird somit versucht, die Vorteile der zentralisierten und der replizierten Architekturen zu kombinieren. Die Abbildung zeigt einen Überblick einer Hybrid-Architektur.

Abbildung 13: Hybrid-

ClientClient


Speicher

ClientClient


Speicher

ClientClient


Speicher

ClientClient


Speicher

ServerServer

DatenSpeicherDaten

Speicher

Architektur

1.7 Architektur kollaborativer Systeme 47

Die meisten Systeme mit Hybrid-Architektur unterscheiden zwischen problematischen und unproblematischen Operationen. Problematische Operationen sind dabei Operationen, welche Dateninkonsistenzen herbeiführen können (z.B. Löschen und Ändern). Unproblematische Operationen führen nicht zu Dateninkonsistenzen (z.B. das Erstellen neuer Datenobjekte). Wie auch bei der replizierten Architektur, werden unproblematische Operationen sofort lokal ausgeführt und danach an die anderen Clients übertragen. Auf den anderen Clients werden die Operationen dann je nach Nebenläufigkeitskontrollverfahren und Datenstruktur sofort oder nur bei Bedarf ausgeführt (vgl. [14]). Dadurch werden schnelle Antwortzeiten erreicht. Problematische Operationen hingegen werden wie bei der zentralisierten Architektur zunächst nur an den Server übertragen, dort geprüft und danach lokal ausgeführt. Als Nebenläufigkeitskontrollverfahren kommen hier auch klassische Sperrverfahren (wie in Datenbanken) zum Einsatz. Alle Operationen – unproblematische und (falls möglich) problematische - werden immer auch auf dem Server ausgeführt. Dadurch wird sichergestellt, dass auf dem Server immer die kompletten aktuellen Versionen aller Datenobjekte vorliegen. Dies ist neben den schnellen Antwortzeiten beim Editieren, ein weiterer Vorteil der hybriden Systemarchitektur. Eine Kopie eines aktuellen Datenobjekts kann dadurch zum Beispiel immer abgerufen werden, sobald ein neuer Benutzer am kollaborativen Editier-Prozess teilnehmen will. Auch können die Datenobjekte auf dem Server für die Synchronisation genutzt werden. Arbeiten mehrere Personen zum Beispiel an einem sehr großen Dokument, so ist die Wahrscheinlichkeit, dass diese sich eventuell gegenseitig stören vergleichsweise gering. Betrachtet nun ein Benutzer einen Teil des Dokuments das von einem anderen Benutzer intensiv bearbeitet wurde, so muss zuvor die lokale Kopie des Dokuments synchronisiert werden. Dies kann nun entweder durch Ausführen der bereits empfangenen Operationen geschehen, oder durch Abrufen der benötigten Daten vom zentralen Server. In manchen Systemen mit hybrider Architektur werden auch problematische Operationen sofort lokal ausgeführt [40],[48]. Dies erfordert allerdings Nebenläufigkeitskontrollverfahren wie sie auch bei replizierter Architektur zum Einsatz kommen.

Die hybrid Architektur vereint die Vorteile der zentralisierten

und der replizierten Architektur

Außer in CSCW Systemen wird die hybride Architektur ähnlich der hier beschriebenen auch bei Online-Spielen und Peer-to-Peer Systemen eingesetzt.


1.8 Awareness in kollaborativen Systemen

Bei der Arbeit in einer Gruppe ist es wichtig, dass jeder Teilnehmer die Gruppe wahrnimmt, sich als Teil dieser Gruppe sieht und auf die Aktionen anderer reagieren kann um das gemeinsame Ziel effektiv erreichen zu können. Im Gegensatz zu Ein-Benutzer-Anwendungen muss bei CSCW Systemen daher eine Möglichkeit geschaffen werden, die Gruppe und deren Aktionen wahrzunehmen. Dies geschieht mit sogenannten Awareness (Bewußtheit) Mechanismen.

Das Ziel der Awareness-Mechanismen ist es, ein Gruppenbewusstsein zu schaffen und einen Teilnehmer an einer Guppenaktivität über die Aktionen anderer Teilnehmer aufzuklären. Dourish schrieb (1997) über Awareness:

Awareness ist wichtig für eine erfolgreiche Zusammenarbeit

“The primary role of awareness information is to make one's activity visible to others”[41]

Awareness-Mechanismen bieten die Möglichkeit für Individuen,

die Arbeit anderer Teilnehmer einer Gruppe besser zu verstehen und dann diese Information zu nutzen, um ihre und die Aktivitäten innerhalb der Gruppe zu koordinieren.

1.8.1 Workspace Awareness

Die Awareness spielt in allen CSCW Systemen eine Rolle, besonders jedoch in Systemen, die gleichzeitiges Arbeiten in “Echtzeit” unterstützen. So zum Beispiel in echtzeitbasierten Mehrbenutzer-Editoren. Bei diesen Systemen ist die wichtigste Art von Awareness die sogenannte Workspace Awareness (Bewusstsein des Arbeitsbereichs). Gutwin beschreibt diese (1996) folgendermaßen: “The up-to–the minute knowledge a person holds about another’s interaction with the workspace” [42]. Workspace Awareness bedeutet also Wissen darüber:

� Wer sich im selben Arbeitsbereich (Workspace) befindet � Wer woran gerade arbeitet � Was die anderen Personen machen

1.8 Awareness in kollaborativen Systemen 49

� Was als nächstes zu tun ist, bzw. was welche Personen als nächstes tun werden

Workspace Awareness soll dabei:

� Den Koordinationsaufwand von Aufgaben reduzieren � Das Wechseln von Teilnehmern zwischen Individueller- und

Gruppenarbeit erleichtern � Einen Kontext schaffen, in dem Äußerungen anderer interpretiert

und Aktivitäten anderer vorausgeahnt werden können

Während die meisten Nebenläufigkeitskontrollverfahren nur die syntaktische Konsistenz von Daten gewährleisten können, ermöglichen Awareness-Mechanismen zusätzlich durch die Schaffung eines Kontextes auch die Möglichkeit zur Interpretation und können dadurch zum Erhalt der semantischen Konsistenz der Daten beitragen. Hier ein Beispiel zur Erläuterung:

Zwei Personen arbeiten gemeinsam an einem Buch. Die erste Person bearbeitet z.B. Kapitel 5, während die zweite Person an Kapitel 1 arbeitet. Nun möchte die erste Person einen Abschnitt aus Kapitel 1 referenzieren, der gerade von der zweiten Person bearbeitet wird. Weiß die erste Person allerdings nicht, was die zweite Person gerade macht, so referenziert sie womöglich einen Abschnitt, der noch nicht fertig ist und mit evtl. einen anderen Inhalt als erwartet. Damit könnte die Referenz auf besagten Abschnitt semantisch inkorrekt sein. Weiß die erste Person allerdings mithilfe von Awareness Mechanismen über die Arbeit der zweiten Person Bescheid, so würde sie eventuell warten, bis die zweite Person den Abschnitt fertig gestellt hat und dann anders entscheiden. Awareness kann also helfen, andere über die eigenen Aktivitäten in Kenntnis zu setzen, um so effektivere Gruppenarbeit zu ermöglichen.

Bei der Arbeit in einer Gruppe sind Absprachen und Informationen über die Aktivitäten anderer sehr wichtig. Werden diese nicht durch Awareness Mechanismen ermöglicht, so kann man immer noch zum Telefonhörer greifen, eine Email schreiben oder Chatten. Diese Art von „Awareness-Mechanismen“ stört aber meist den Arbeitsablauf. Es wäre viel effektiver, wenn man auf einen Blick die für die Arbeit wichtigen „Awareness“ Informationen sehen könnte. Daher ist die Integration von Awareness-Mechanismen in ein CSCW System wichtig, um so den Arbeitsablauf effektiv zu unterstützen ohne ihn durch unnötige Informationen zu behindern.

Awareness schafft ein Bewusstsein für die Aktionen

der Anderen

Es gibt verschiedenste Arten von Awareness Informationen. Angefangen bei Informationen über Dokumente, Projekte und Aufgaben bis hin zu Informationen über den Ort und die Aktivitäten


von anderen Gruppenarbeitern. Diese Informationen werden mithilfe verschiedenster Techniken bereitgestellt.

In kollaborativen Systemen wie Mehrbenutzer-Editoren wird oft die Benutzeroberfläche mit neuen Komponenten, sogenannten „Widgets“ erweitert, welche die fehlenden Informationen über die anderen Teilnehmer bereitstellen. Beispiele dafür sind das “Teleporting”,“Telepointing”, Mehrbenutzer Scrollbalken, “What You See Is What I Do” (WYSIWID) Ansichten, Miniatur-Ansichten oder sogenannte Radaransichten.

Mit dem „Teleporting“ kann die Arbeitsumgebung einer anderen Person betrachtet werden. Dabei wird zum Beispiel ein Screenshot der Ansicht (z.B. Arbeitsbereich, Desktop) eines anderen Teilnehmers gezeigt. Beim „Telepointing“ werden die Mausbewegungen einer anderen Person sichtbar gemacht. Der Mehrbenutzer Scrollbalken zeigt die relative Position jedes Teilnehmers im Arbeitsbereich. Die WYSIWID Ansicht erlaubt es die Aktivitäten einer anderen Person direkt zu sehen. Die Miniaturansicht zeigt eine Übersicht, über den gesamten Arbeitsbereich und die Radaransicht zeigt Zusatzinformationen über die Position anderer im Arbeitsbereich. Weitere Möglichkeiten zur Bereitstellung von Awareness Informationen sind Bilder von Web-Kameras, Videoausschnitte und Hintergrundgeräusche.

Es existieren zahlreiche Awareness-Mechanismen

Die Entwicklung von Awareness-Mechanismen beschränkt sich nicht nur auf Softwarelösungen. Auch werden neuartige Geräte eingesetzt um die Awareness zu verbessern. Es gibt verschiedene Ansätze, Alltagsgegenstände mit „Intelligenz“ auszustatten, um unter anderem die Mensch-Computer-Interaktion zu verbessern, oder den Menschen auf andere Weise das Leben zu erleichtern. Aus den Forschungsgebieten Human Computer Interaction (HCI), Ubiquitous Computing und Ambient Intelligence entstehen zusätzlich neue Ansätze, wie die Awareness in CSCW Systemen verbessert werden kann. Zum Beispiel existieren in der Forschung spezielle Stühle mit Sensoren, die an ein Groupware Konferenzsystem automatisch übermitteln, sobald ein Teilnehmer von seinem Stuhl aufsteht und den Raum verlässt [43]. Damit wird ein aktives Abmelden durch den Benutzer unnötig und die anderen Teilnehmer der Konferenz sind nicht überrascht, dass der Teilnehmer nicht mehr antwortet, weil er vergessen hatte sich abzumelden.

1.8 Awareness in kollaborativen Systemen 51

1.8.2 Usability und Privatsphäre

Bei der Entwicklung der Awareness Unterstützung für ein CSCW System hat die Usability einen zentralen Stellenwert. Man sollte sich unter anderem überlegen, welche Information relevant ist und wie diese bereitgestellt wird. Ein „zu viel“ an Awareness Informationen, oder eine ungeschickte Aufbereitung und Darstellung dieser kann auch ablenkend bzw. hinderlich auf den Arbeitsablauf wirken. Auch ist eventuell relevant, was die Unterbrechung des Arbeitsablaufs für die Benutzer bedeutet.

Ein bewusster Umgang mit der Privatsphäre der Benutzer ist wichtig. Es sollte jedem Benutzer die Möglichkeit gegeben werden, selbst zu kontrollieren, welche Informationen über ihn und seine Arbeit preisgegeben werden und welche nicht. Besteht diese Möglichkeit der Kontrolle nicht, kann dies im einfachsten Fall zu einer Ablehnung des CSCW Systems durch die Benutzer führen. Bei kommerziell eingesetzten Systemen kann dies aber auch zur unfreiwilligen Offenlegung von Geschäftsrelevanten Informationen führen. Wenn jeder Benutzer eines CSCW Systems sehen kann, was ein anderer gerade tut (oder nicht tut) kann diese Information eventuell schädigend eingesetzt werden.

Privatsphäre und Benutzerfreundlichkeit sind

entscheidend für die Akzeptanz eines CSCW Systems

Anonymität der Benutzer kann daher bei manchen Systemen Voraussetzung und Ermutigung für eine faire und konstruktive Teilnahme am System (z.B. bei Diskussionsgruppen) sein und schützt Benutzer vor Belästigung. Auf der anderen Seite besteht ein Interesse an der Preisgabe persönlicher Daten, da dadurch Systeme sinnvoller individuelle Anpassungen wie z.B. der Benuteroberfläche vornehmen können und dadurch die Usability verbessert werden kann. Auch gibt es Fälle in denen Anonymität z.B. aus Abrechnungs- und Sicherheitstechnischen Gründen nicht erwünscht ist, um z.B. Missbrauch zu verhindern. Um den widersprüchlichen Anforderungen gerecht zu werden, ist eine Verfahrensweise die der Reziprozität (Wechselseitigkeit). Dabei muss ein Benutzer, der über einen anderen Benutzer etwas erfahren will, die gleiche Information über sich preisgeben. Diese Verfahrensweise ist allerdings nicht überall sinnvoll. Generell sollte bei CSCW Systemen Wert auf die Sicherheit und die Privatsphäre gelegt werden.


1.9 Fazit und Ausblick

Was wäre das Internet ohne das WWW und E-Mail? Wer heutzutage keine E-Mail Adresse besitzt gilt als veraltet. Auch Weblogs und Wikis gehören mittlerweile zum modernen Menschen der Informationsgesellschaft. CSCW Systeme sind daher schon fester Bestandteil des Alltags vieler, ohne dass sie es wahrnehmen, und nicht mehr aus diesem wegzudenken. Und der Trend geht weiter.

Aktuelle CSCW Systeme bieten in vielen Bereichen eine gute Unterstützung, doch gibt es noch viel zu verbessern. Die Integration der kollaborativen Systeme in den Arbeitsablauf lässt meist noch zu wünschen übrig. Es gibt zu viele kleine Projekte und proprietäre Systeme, die jeweils nur für eine Teillösung taugen. Oft will man aber mehr. Eine Integration verschiedener Systeme zu einem auf den Anwendungsfall abgestimmten Gesamtsystem sollte möglich werden. Dazu bedarf es neuer Standards, um zwischen Systemen Daten und Informationen austauschen zu können ohne dabei von einem System abhängig zu sein. Die Integration der CSCW Systeme in die Betriebssysteme und die Kompatibilität der Systeme untereinander sollte also auch besser werden, um unter anderem eine gute Usability und damit eine bessere Benutzerakzeptanz zu erreichen.

Usability, Awareness und Privatsphäre sind wichtige Punkte, die in aktuellen CSCW Systemen oft zu kurz kommen. Es besteht also noch großer Forschungsbedarf im Bereich CSCW.

Im mobilen Zeitalter will oder muss man jederzeit und überall

erreichbar sein. Ob per SMS, Mobiltelefon oder im Chat mit dem Laptop im Homeoffice, in der Bahn, im Flugzeug oder im Café sitzend. Dabei nimmt das kollaborative Arbeiten von Überall und zu jeder Zeit einen immer höheren Stellenwert ein. Nicht nur auf Flugplätzen und Bahnhöfen sind heute Hotspots verfügbar. Mit der Weiterentwicklung der Hardware und der Vernetzung wird sich auch die kollaborative Software immer weiter entwickeln. CSCW Systeme wie Groupware, Versionsverwaltung und Mehrbenutzer Editoren werden noch mehr miteinander verschmelzen. CSCW Systeme werden in Zukunft auf verschiedenste Weisen zusammen spielen und uns immer und überall begleiten.

Mobilität wird immer wichtiger

Das Mobiltelefon wird in Zukunft zur zentralen Kommunikationszentrale werden, mit der Leistungsfähigkeit eines PCs und ständiger Breitbandanbindung an das Internet oder das Firmennetzwerk. Mit neuen Displaytechnologien, neuartigen

1.9 Fazit und Ausblick 53

Eingabegeräten, und spezialisierten Betriebssystemen wird man immer und überall mit hohem Komfort im mobilen Büro arbeiten. Dabei unterstützen kollaborative Systeme und geben dem Benutzer den Eindruck als wäre man vor Ort beim Kunden oder beim Kollegen im Büro. Neben den drei "klassischen" mobilen Geschäftsanwendungen Surfen, E-Mail und Zugriff aufs Firmennetz wird die Internet-Zusammenarbeit z.B. als Desktop-Sharing oder als Web-Conferencing zu den Standard Anwendungen des mobilen Büros gehören40. Das spart Zeit und Reisekosten. Die Telearbeit wird durch immer bessere kollaborative Systeme und Hardware zur Normalität werden und nebenbei spart die Firma dadurch Büromiete. Entfernung spielt in der Zukunft keine Rolle mehr.

In der Zukunft könnte zum Beispiel ein japanischer 3D Designer von zu Hause aus mit seinem deutschen Kollegen gleichzeitig an einem 3D Modell für ein neues Automobil arbeiten. Dabei nutzen sie einen Echtzeit-Mehrbenutzer Editor mit integrierter Versionsverwaltung und ein Groupware System für die Kommunikation und die Besprechungen mit den anderen Teammitgliedern die auf der ganzen Welt verteilt arbeiten. Virtuelle Konferenzräume werden dabei die „echten“ Konferenzräume ersetzen. Sie werden in Zukunft eine Interaktivität bieten, die der Realität in nur wenigen Punkten nachsteht. Die dabei eingesetzte kollaborative Software wird äußerst benutzerfreundlich in das Betriebssystem integriert sein. Forschungsprojekte wie Croquet geben einen Hinweis darauf, wie ein kollaboratives Betriebssystem der Zukunft aussehen könnte.

CSCW Systeme machen die Welt zum Büro

Nicht allein die Zeitersparnis und der Wegfall der Reisekosten sind überzeugende Argumente für den Einsatz von CSCW Systemen. Auch bieten sie heute schon eine gute Unterstützung der gemeinschaftlichen Arbeit durch neue Kommunikationsmöglichkeiten und die Integration von Arbeitsabläufen. Gerade in Zeiten der Globalisierung sind CSCW Systeme nicht mehr wegzudenken.

40 Erste Trends setzen Anwendungen wie Netviewer. http://www.netviewer.de/


Literatur

[1] Molli, P. Skaf, H. Oster, G. Jourdain., S.: "SAMS : Synchronous,

Asynchronous, Multi-Synchronous Environments", Proceedings of CSCWD'02, Rio de Janeiro, Brazil, 2002.

[2] Wilson, P.: Computer supported cooperative work: an introduction. Oxford, England Norwell, MA, Intellect; Sold and distributed in the U.S.A. and Canada by Kluwer Academic Publishers, 1991

[3] Grudin, J.: Groupware and social dynamics: eight challenges for developers. Communications of the ACM, 37, 1994

[4] Koch, M.: Unterstützung kooperativer Dokumentenbearbeitung in Weitverkehr-snetzen. Dissertation an der Technischen Universität München, 1996

[5] Ellis, C.A. Gibbs, S.J., Rein. G.L.: Groupware – Some Issues and Experiences. Communications of the ACM, 34, 1991

[6] Greenberg, S.: Computer Supported Cooperative Work and Groupware. Aca-demic Press, London, 1991.

[7] Dillenbourg, P. et al.: The Evolution of Research on Collaborative Learning. Learning in humans and machines. Towards an interdisciplinary learning science. P. Reimann and H. Spada. London, Pergamon: 189-211, 1995

[8] Hildebrand, R. Koetter, P.: Postfix. Dpunkt Verlag, 2005

[9] Carius, F. Mantke, I.: Microsoft Exchange Server 2003, Hanser Fachbuchverlag, 2005

[10] Levine, J.: QMAIL. O’Reilly Media, 2004

[11] Riempp, G.: Wide Area Workflow Manangement, Springer, London 1998


[12] Greif, I. Seliger, A. Weihl, W.: A Case Study of CES: A Distributed Collabora-

tive Editing System Implemented in Argus. IEEE Transactions on Software Engineering, S. 827-839, 1992

[13] Knister, M.J. Prakash, A.: DistEdit: a distributed toolkit for supporting multiple group editors, Proceedings of the 1990 ACM conference on Computer-supported cooperative work, Los-Angeles, S. 343-355, 1990.

[14] D. Chen.: REDUCE – REal-time Distributed Unconstrained Collaborative Editing System.Research Project at the Griffith University, Brisbane. 2001.

[15] Sun, C. et al.: A consistency model and supporting schemes in real-time coop-erative editing systems, Proc. of the 19th Australian Computer Science Confer-ence, Melbourne, S. 582-591, Jan. 1996.

[16] Galli, R., Luo, Y.: MU3D: A Causal Consistency Protocol for a Collaborative VRML Editor. In Proceedings of the Web3D-VRML 2000 fifth symposium on Virtual Reality Modeling Language. ACM, February 2000.

[17] Ellis, C.A., Gibbs, S.J.: Concurrency Control in Groupware Systems. In Pro-ceedings of the 1989 ACM SIGMOD international conference on management of data. ACM, 1989.

[18] Chen, D.: Consistency Maintenance in Collaborative Graphics Editing Systems. Dissertation at the Griffith University Brisbane. 2001.

[19] Koch, M.: Unterstützung kooperativer Dokumentenverarbeitung in Weitverkehrsnetzen. Dissertation an der TU München, 1997

[20] Kirsche, T. et al.: CoDraft: Eine verteilte Architektur zur Unterstützung von Gruppenarbeit durch Multimediale Objekte, Praxis Information und Kommunikation, Stuttgart, 1993

[21] Haake, J.M. Wilson, B.: Supporting collaborative writing of hyperdocuments in SEPIA, Proceedings of the 1992 ACM conference on Computer-supported co-operative work, Toronto, Canada, 1992

[22] Bernstein, P. et al.: Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987.

[23] Haerder, T.: Datenbanksysteme: Konzepte und Techniken der Implementierung.2. Edition. Springer. 2001.

[24] Ignat, C. Norrie, M.: Tree-based model algorithm for maintaining consistency in real-time collaborative editing systems. ACM. Fourth International Work-shop on Collaborative Editing Systems, New Orleans, Louisiana. 2002.


[25] Ellis, C.A. Gibbs, S.J.: Concurrency Control in Groupware Systems. ACM

Proceedings. SIGMOD International Conference on Management of Data. 1989.

[26] Ressel, M. Nitsche-Ruhland, D. et al.: An integrating, transformation-oriented approach to concurrency control and undo in group editors. ACM. Conference on Computer Supported Cooperative Work, 1996.

[27] Sun, C. Jia, X. et al.: Achieving Convergence, Causality-preservation, and Intention-preservation in Real-time Cooperative Editing Systems. ACM. Trans-actions on Computer-Human Interaction, 1998.

[28] Sun, C. Ellis, C.: Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements. ACM Proceedings. ACM conference on Computer supported cooperative work, Seattle, Washington, 1998

[29] Suleiman, M. Cart, M. et al.: Serialization of Concurrent Operations in a Dis-tributed Collaborative Environment.ACM. International Conference on Sup-porting Group Work, 1997.

[30] Fidge, C. J.: Timestamps in message-passing systems that preserve the partial ordering. University of Queensland, Australia. 11th Australian Computer Sci-ence Conference, 1988.

[31] Lamport, L.: Time, clocks and the ordering of events in a distributed sys-tem.Computer Associates, 1978.

[32] Raynal, M. Singhai, M.: Logical Time: Capturing Causality in Distributed Systems. IEEE Computer. S. 49-56. IEEE, 1996.

[33] Pfister, H.-R. Schuckmann, C. Beck-Wilson, J. Wessner, M.: The Metaphor of Virual Rooms in the Cooperative Learning Environment. Proceedings of CoBuild'98, Darmstadt, 1998.

[34] Miao, Y. et al.: An Activity-Oriented Approach to Visually Structured Knowl-edge Representation for Problem-Based Learning in Virtual Learning Environ-ments. COOP'2000 (Fourth International Conference on the Design of Coopera-tive Systems). Sophia Antipolis, Frankreich, 2000.

[35] Streitz, N.A. et al.: DOLPHIN: Integrated Meeting Support across LiveBoards, Local and Remote Desktop Environments. Proceedings of the 1994 ACM Con-ference on Computer-Supported Cooperative Work (CSCW'94), Chapel Hill, N.C., S. 345–358, 1994.

[36] Streitz, N.A. et al.: i-LAND: An interactive Landscape for Creativitiy and Innovation. ACM Conference on Human Factors in Computing Systems (CHI '99). ACM Press, New York, 1999.


[37] Haake, J. Wang, W.: Flexible Support for Business Processes: Extending

Cooperative Hypermedia with Process Support. Information and Software Technology, S. 355–366, 1999.

[38] GMD-IPSI: „Co-operative UML Editor“ http://www.darmstadt.gmd.de/ con-cert/activities/internal/umledit.html , 2000

[39] Schümmer, T. Schümmer, J.: Support for Distributed Teams in eXtreme Pro-gramming, Proceedings of eXtreme Programming and Flexible Processes in Software Engineering - XP2000, Addison Wesley, 2000.

[40] Gerlicher, A.: Erweiterung bestehender Anwendungen um kollaborative Funktionen mit Hilfe des Collaborative Editing Framework for XML (CEFX). Aktuelle Trends in der Softwareforschung. Band 2: Tagungsband zum doIT Software−Forschungstag am 29. Oktober 2004. Fraunhofer IRB Verlag, Stuttgart, 2005.

[41] Dourish, P.: Extending Awareness Beyond Synchronous Collaboration. Posi-tion paper for the CHI’97 Workshop on Awareness in Collaborative Systems, Atlanta, 1997.

[42] Gutwin, C. Roseman, M. Greenberg, S.: A Usability Study of Awareness Widgets in a shared Workspace Groupware System. ACM CHI '96 Conference Companion, 1996

[43] Szwillus, G. Ziegler, J. (Hrsg.): Mensch & Computer 2003: Interaktion in Bewegung.Stuttgart: B. G. Teubner, S. 135-143, 2003.

[44] Beaudouin-Lafon, Michel (ed.): Computer-Supported Cooperative Work. John

Wiley, 1999.

[45] Coleman, D. (ed.): Groupware. Collaborative Strategies for Corportate LANSs and Intranets. Upper Saddle River: Prentice-Hall, 1997.

[46] Crabtree, A.: Designing Collaborative Systems: A Practical Guide to Ethnogra-phy, Springer, 2003

[47] Darses, F. Dieng, R. Simone, C. Zacklad, M. (Hrg.): Cooperative Systems Design, Scenario-Based Design of Collaborative Systems, Proceedings of COOP 2004, Hyères Les Palmiers, Frankreich, 2004

[48] Gerlicher, A. A Framework for Real-Time Collaborative Engineering in the Automotive Industries. Lecture Notes on Computer Science, Proceedings of the Third International Conference on Cooperatiove Design, Visualization and En-gineering, Mallorca, Spain, Springer, September 2006


Links zu Forschungsprojekten

COAST: http://www.opencoast.org/download/

CoWord: http://reduce.qpsf.edu.au/coword/

CoPowerPoint: http://reduce.qpsf.edu.au/copowerpoint/

Reduce: http://reduce.qpsf.edu.au/reduce/index.html

Grace: http://www.cit.gu.edu.au/~scz/projects/grace/

Annodex: http://www.annodex.net/

Croquet: http://www.opencroquet.org/


http://www.opencroquet.org/

Abkürzungen

API Applications Programmers Interface

BLOG Weblog

CMWeb Continuous Media Web

CSCL Computer Supported Cooperative Learning

CSCW Computer Supported Cooperative Work

CVS Concurrent Versioning System

FTP File Transfer Protocol

GPRS General Packet Radio System

HCI Human Computer Interaction / Interface

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IMAP Internet Message Access Protocol

IMAPS Internet Message Access Protocol Secured

IP Internet Protocol

IRC Internet Relay Chat

ISDN Integrated Services Digital Network

MCU Multipoint Control Unit


OT Operational Transformation

P2P Peer To Peer

POP3 Post Office Protocol 3

POP3S Post Office Protocol Secured

RSS Really Simple Syndication

RTCE Real-Time Collaborative Editing

SAMS Synchronous Asynchronous Multisynchronous System

SCC Source Code Control

SIP Session Initialisation Protocol

SMB Server Message Block

SMTP Simple Message Transfer Protocol

SPAM Engl. Dosenfleisch oder unerwünschte E-Mail

SVN Subversion

TCP Transmission Control Protocol

UML Unified Modelling Language

UMTS Universal Mobile Telecommunications System

VoIP Voice over IP

VPN Virtual Private Network

VSS Visual Sourcesafe

WebDAV Web-based Distributed Authoring and Versioning

WfMS Workflow Management System

WWW World Wide Web

WYSIWID What You See Is What I Do

XML Extensible Markup Language


1 Computer Supported Cooperative Work (CSCW) – Kollaborative … · 2013. 9. 18. · „Computer...

Documents

Transcript of 1 Computer Supported Cooperative Work (CSCW) – Kollaborative … · 2013. 9. 18. · „Computer...