Universität Stuttgart Fakultät Informatik Fakultät Informatik Institut für Parallele und Verteilte Höchstleistungsrechner Universität Stuttgart Breitwiesenstraße 20 - 22 D-70565 Stuttgart Ein Überblick über Verfahren zur rechnergestützten Kooperation Cora Burger, Frank Sembach CR-Klassifikation: H.1, H.4, H.5.3, I.2.11 Fakultätsbericht 7/1994 Technical Report Juli 1994 Ein Überblick über Verfahren zur rechnergestützten Kooperation Kurzfassung Mit der Möglichkeit, kooperatives Arbeiten durch geeignete Software-Werkzeuge zu unterstützen, eröffnet sich ein neues Anwendungsgebiet für verteilte Systeme. Wie die umfangreiche Literatur über Ansätze in den Bereichen ?Computer Supported Cooperative Work? und ?Multi-Agenten-Systeme? für menschliche bzw. maschinelle Kooperationspartner zeigt, besteht seit einiger Zeit ein lebhaftes Interesse an Verfahren zur rechnergestützten Kooperation. Um diese Ansätze untersuchen und vergleichen zu können, wird in der vorliegenden Arbeit eine detaillierte Klassifikation von Kooperationsmodellen und unterstützenden Werkzeugen vorgenommen. Die Ergebnisse dieser Untersuchung werden in ein neues, universelles Kooperationsmodell umgesetzt. Außerdem werden daraus Anforderungen abgeleitet, die an ein universelles Werkzeug zur Kooperationsunterstützung zu stellen sind. Abstract A new application area for distributed systems evolves, driven by the need to support cooperative work. The importance of cooperative applications is demonstrated by the vast number of articles that have been published on this subject so far. There are two main streams of research: one being concerned with computer supported cooperative work and another dealing with the area of intelligent agents. This report gives an overview about tools supporting general cooperative work. To examine and compare current approaches, a detailed taxonomy of cooperation models and support tools is established and applied to existing systems. Based on the results of this classification, a new and general cooperation model is constructed. Furthermore, requirements for a universal tool to support cooperation are derived. Inhaltsverzeichnis 1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Klassifikation bisheriger Kooperationsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Einführendes Beispiel: Fußballspiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Klassifikation von Kooperationsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1 Subjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2 Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 Ziele und Bewertungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.4 Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.5 Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.6 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.7 Koordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.8 Kooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.9 Unterstützte kooperative Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.10 Ergebnisse der Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation . . . . . . . . . . . . 23 3.1 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.1 Basismechanismen für die Kommunikation . . . . . . . . . . . . . . . . . . . . . . 24 3.1.2 Beispiele für Kommunikationswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.3 Klassifikationskriterien für Kommunikationswerkzeuge . . . . . . . . . . . . 27 3.2 Koordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.1 Basismechanismen der Koordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.2 Beispiele für Koordinationswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.3 Klassifikationskriterien für Koordinationswerkzeuge . . . . . . . . . . . . . . . 36 3.3 Kooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.1 Basismechanismen zur Kooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.2 Beispiele für Kooperationswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.3 Architekturaspekte für Kooperationswerkzeuge . . . . . . . . . . . . . . . . . . . 41 3.4 Unterstützung für menschliche Subjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5 Ergebnisse der Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4 Ein universelles Modell zur Rechnerunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5 Anforderungen an ein universelles, kooperationsunterstützendes Werkzeug . . . . . 49 5.1 Anforderungen an die Kommunikationsunterstützung . . . . . . . . . . . . . . . . . . . . 49 5.2 Anforderungen an die Koordinationsunterstützung . . . . . . . . . . . . . . . . . . . . . . . 49 ii 5.3 Anforderungen an die Kooperationsunterstützung . . . . . . . . . . . . . . . . . . . . . . . . 50 5.4 Anforderungen an die Subjektunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7 Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 A Weitere Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.1 Weg zur Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.2 Chef und Untergebener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.3 Käufer und Verkäufer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 A.4 Arbeiter in unterschiedlichen Firmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 A.5 Fußgängerampel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 A.6 Nahrungsbeschaffung durch Büffeljagd oder durch Einkauf im Supermarkt . . . . 56 A.7 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 B Klassifikation von Kooperationsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 B.1 Subjektklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 B.2 Teamklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 B.3 Klassifikation von Zielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 B.4 Klassifikation von Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B.5 Klassifikation von Objektmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 B.6 Klassifikation von Kommunikationsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 B.7 Klassifikation von Koordinationsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 B.8 Unterstützte kooperative Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 C Klassifikation von kooperationsunterstützenden Werkzeugen . . . . . . . . . . . . . . . . . 63 C.1 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.2 Koordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.3 Subjektunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Literaturverzeichnis 1 1 Einleitung Durch zunehmend komplexere Aufgaben einerseits und eine zunehmende Spezialisierung andererseits gewinnt die Kooperation Einzelner immer mehr an Bedeutung. Wie die folgenden Beispiele zeigen, läßt sich dieser Trend in vielen Arbeitsbereichen ablesen: - Arbeit im Büro: mehrere Mitarbeiter aus unterschiedlichen Abteilungen sind in den gleichen Vorgang involviert (z.B. Bestellwesen, Rechnungswesen). - Arbeit im Labor: z.B. ein komplexes Softwarepaket wird durch mehrere Mitarbeiter oder sogar durch mehrere Gruppen gemeinsam erstellt - Industrielle Fertigung (Stichwort der fraktalen Fabrik). Eine Basis zur Unterstützung derartiger Abläufe mit Rechnern bildet eine möglichst vollständige Vernetzung aller Beteiligten (sogenanntes interpersonal computing). Darauf aufbauend können geeignete Automatisierungswerkzeuge für eine weitergehende Unterstützung sorgen. Ansätze in diese Richtung sind unter den Stichworten `Computer supported cooperative work', `Groupware' und in der Verteilten Künstlichen Intelligenz (Multi-Agenten-Systeme) sowie bei der Koordination von Robotern zu finden. Um bisherige Überlegungen zusammenzufassen und eine Basis für weitergehende Arbeiten zu schaffen, traf sich im Herbst 1993 eine Gruppe von acht wissenschaftlichen Mitarbeitern zu mehreren Sitzungen ([BDH+93]). Ziel dieser Treffen war, zunächst ein tieferes Verständnis des Begriffes Kooperation zu gewinnen. Die dabei gewonnenen Erkenntnisse sollten anschließend zur Bewertung existierender, kooperationsunterstützender Werkzeuge eingesetzt werden. Während der einzelnen Treffen wurde anhand von Synonymen und Akronymen sowie durch eingehende Untersuchung von Beispielen für Kooperationen ein eigenes Modell entworfen. Für den vorliegenden Bericht wurde aus der Vielzahl der behandelten Beispiele eines ausgewählt, an dem sich alle der im folgenden behandelten Aspekte einer Kooperation zeigen lassen (die restlichen Beispiele sind in Anhang A zu finden). Diese Aspekte bilden die Grundlage für eine Klassifikation der bisherigen Kooperationsmodelle aus der Literatur (Abschnitt 2 und Anhang B). Im dritten Abschnitt und in Anhang C wird eine Reihe der auf diesen Modellen basierenden Werkzeuge für eine Rechnerunterstützung von Kommunikations-, Koordinations- und Kooperationsabläufen klassifiziert. Im darauf folgenden vierten Abschnitt wird die Struktur und Einordnung des eigenen Modelles beschrieben. Daraus werden Anforderungen an ein universelles Werkzeug abgeleitet, das zur Rechnerunterstützung beliebiger Kooperationen geeignet ist (Abschnitt 5). 2 2 Klassifikation bisheriger Kooperationsmodelle Aus dem Wörterbuch ([Webs86]) läßt sich folgende Definition von Kooperation ablesen: Mehrere Subjekte kooperieren, um ein gemeinsames Ziel zu erreichen. Hierzu führen sie Aktivitäten aus, die auf Objekten operieren und der Erreichung von Teilzielen dienen. Zur Koordination der Teilziele werden diese durch Kommunikation aufeinander und auf das gemeinsame Ziel abgestimmt. Für eine erfolgreiche Kooperation ist es notwendig, daß die Subjekte einen wechselseitigen Nutzen aus der Kooperation ziehen und zumindest in Teilbereichen gleichberechtigte Partner sind. Um diese Begriffe genauer untersuchen zu können wird im folgenden zunächst ein Beispiel für eine Kooperation mit vielen unterschiedlichen Aspekten behandelt (Abschnitt 2.1). Im darauf folgenden Abschnitt wird ein Klassifikationsmodell vorgestellt, anhand dessen bisherige Arbeiten zu diesem Thema eingeordnet werden. Der Übersichtlichkeit halber erfolgt diese Einordnung in Tabellenform in Anhang B. 2.1 Einführendes Beispiel: Fußballspiel An der Kooperation ?Fußballspiel? sind Menschen in unterschiedlichen Rollen beteiligt: - Die beiden Mannschaften, bestehend aus den dazugehörigen Spielern, insbesondere dem Torwart, den Stürmern und Verteidigern. - Schiedsrichter - Funktionäre und Trainer der Vereine - Zuschauer. Diese Menschen sind aus unterschiedlichen Gründen am Fußballspiel interessiert und werden durch unterschiedliche Ziele zur Teilnahme an der entsprechenden Kooperation veranlaßt. Beispiele für solche Ziele sind Spaß, Zeitvertreib, Sieg und damit verbundene finanzielle Gewinne sowie die Einhaltung von Regeln. Diese Ziele und ihre Prioritäten variieren je nach der Rolle des Beteiligten und dem Kontext, in dem gespielt wird. Unter Kontext ist dabei der unterschiedliche Rahmen zu verstehen, in dem gespielt wird (z.B. Straßenfußball, Liga- oder Meisterschaftsspiel, wobei bei letzterem das Ziel ?Sieg? die größte Bedeutung haben dürfte, während im Straßenfußball der mit dem Spiel verbundene Spaß und Zeitvertreib wichtiger ist). Üblicherweise nimmt jeder Beteiligte nach einem konkreten Spiel eine Bewertung vor, indem er seine ursprünglichen Ziele mit dem Ergebnis vergleicht. Dadurch wird sein Verhalten im Hinblick auf zukünftige Kooperationen beeinflußt. 2.2 Klassifikation von Kooperationsmodellen 3 Bedingt durch die das Fußballspiel definierenden Spielregeln herrscht zwischen den beiden Fußballmannschaften einerseits Konkurrenz (jede will gewinnen), andererseits sind sie aber auch zu einer übergeordneten Form der Kooperation gezwungen. Alle Spieler agieren zielgerichtet durch Fortbewegen des Balles. Diese Aktionen erfolgen, je nach Mannschaftszugehörigkeit, koordiniert oder konkurrierend. In einer Fußballmannschaft sind die Rollen des Torwartes, der Stürmer und Verteidiger zunächst a priori festgelegt. Darüberhinaus wird jedoch von jedem einzelnen Spieler erwartet, daß er sich im Hinblick auf das Ziel optimal verhält. Hilfsmittel dabei sind Beobachtungen des Spielverlaufs und verbale Verständigung mit den Mitspielern in Form von Zurufen. In diesem Zusammenhang können Rollen dynamisch verändert werden. Z. B. wird auch ein Verteidiger versuchen, ein Tor zu schießen, wenn sich die Gelegenheit dazu bietet. Es liegt also eine Mischform aus statischer a priori und dynamischer, d.h. zustandsabhängiger Koordination vor. Neben der Kooperation des Fußballspieles an sich bestehen noch weitere Kooperationen zwischen den obengenannten Subjekten. Beispiele dafür sind die von einem Fußballverein mit Spielern und Trainern abgeschlossenen Verträge oder Terminabsprachen zwischen unterschiedlichen Vereinen. 2.2 Klassifikation von Kooperationsmodellen Erste Klassifikationen von Kooperationen und ein Überblick über die damit zusammenhängenden Gebiete sind bereits in [BoGa88], [Levi92] und [vMar92] zu finden. Im folgenden wird ein detailliertes Modell vorgestellt, anhand dessen sich bisherige Modelle umfassender einordnen und bewerten lassen. Aus dem im letzten Abschnitt angeführten Beispiel läßt sich ablesen, daß folgende Elemente an einer Kooperation beteiligt sind oder sein können: - Subjekte, - Gruppen, in denen Subjekte unterschiedliche Rollen annehmen können, - Subjektziele, - die von Subjekten ausgeführten Aktivitäten, die auf Objekten operieren, - verschiedene Formen der Kommunikation, Koordination und Kooperation, möglicherweise mit Kontexten und unterschiedlichen Phasen. 4 2 Klassifikation bisheriger Kooperationsmodelle Im Folgenden werden diese Elemente mit ihren möglichen Ausprägungen vorgestellt. Für die im nächsten Abschnitt (Abschnitt 3) erfolgende Klassifikation von kooperationsunterstützenden Werkzeugen spielt die Ausführlichkeit des Modelles insofern eine Rolle, als ein Werkzeug umso universeller einsetzbar ist, je mehr Aspekte das zugrundeliegende Modell enthält. 2.2.1 Subjekte Damit Subjekte im Rahmen einer Kooperation miteinander kommunizieren können, benötigen sie einen, in diesem Kontext eindeutigen Namen. Außerdem muß das Subjekt zu jedem Zeitpunkt in irgendeiner Form erreichbar sein (vgl. [PaTe91] und [Rang93]). Darüberhinaus lassen sich Subjekte nach den folgenden Kriterien klassifizieren: - Subjekttyp, - Komplexität des verwendeten Modells bezüglich des Subjektwissens und - Wissenserwerb des Subjektes. Subjekte dienen der Modellierung von unterschiedlichen Typen von Subjekten wie menschlichen oder maschinellen Agenten oder Gruppen solcher Subjekte. Auf die Definition eines maschinellen Agenten, d.h. das dafür erforderliche Mindestmaß an ?Intelligenz? wird im Rahmen dieser Arbeit nicht eingegangen. Maschinelle Agenten werden also im wesentlichen nur in ihrer Eigenschaft als Subjekte und Kooperationspartner behandelt. Die Möglichkeit, Subjekte durch Gruppen von Subjekten zu modellieren, ist insofern von besonderer Bedeutung, als die Komplexität von Kooperationen mit der Anzahl der beteiligten Subjekte stark ansteigt und sich nur mit Hilfe von Gruppenbildungen und daraus abgeleiteten Hierarchien beherrschen läßt ([DuLe91], [DuMo91]). Aus diesem Grund wird auf Gruppen im nächsten Abschnitt genauer eingegangen. Bei den einzelnen Subjektmodellen lassen sich je nach Anwendung unterschiedliche Komplexitäten und Anforderungen an das Wissen über sich selbst, über andere Subjekte und über das Umfeld unterscheiden ( vgl. Tabelle B-1). Im einfachsten Fall wird ein Subjekt dadurch definiert, daß es in irgendeiner Form Ziele verwirklichen will und dazu Aktionen anstößt. Derartige Modelle werden vor allem im Bereich des CSCW verwendet. Begründen läßt sich das damit, daß hierbei für Subjekte nur Menschen betrachtet werden und diesen im Rahmen einer rechnergestützten Kooperation ein Freiraum zuzugestehen ist, der durch umfangreichere Modellierungen eingeengt würde. 2.2 Klassifikation von Kooperationsmodellen 5 Im Bereich der verteilten künstlichen Intelligenz dagegen reicht dieser Ansatz nicht aus, da hier maschinelle Agenten erstellt werden sollen, für die eine komplette Modellierung erforderlich ist. Zum Wissen eines Subjektes über sich selbst gehören dabei neben den bereits in einfachen Modellen enthaltenen Zielen insbesondere seine Fähigkeiten (z.B. zur Problemlösung) und die daraus abgeleiteten Rollen. Auf diesen Aspekt wird erst im Abschnitt über Gruppen (Abschnitt 2.2.2) eingegangen, da hierbei der Gruppenkontext eine wesentliche Rolle spielt. Auch das Wissen über andere Subjekte beinhaltet deren Ziele und die aus ihren Fähigkeiten abgeleiteten Rollen. Im Gegensatz zum Wissen eines Subjektes über sich selbst kann jedoch das Wissen über andere Subjekte und die Umwelt allgemein aufgrund der Verteilung der Subjekte und der Eigenschaften des verwendeten Kommunikationsmediums (vgl. Abschnitt 2.2.6) unterschiedlich genau, unterschiedlich vollständig ausgeprägt und unterschiedlich starken Änderungen unterworfen sein. So wird z.B. das Wissen über ein hochdynamisches, sehr umfangreiches System wesentlich unpräziser, unvollständiger und schwerer vorhersagbar sein als das Wissen über ein überschaubares System mit relativ seltenen Zustandsänderungen. Derartigen anwendungsbedingten Gegebenheiten ist sowohl im Modell für das Subjekt als auch im Modell für die zwischen Subjekten verwendete Koordination (s. u.) Rechnung zu tragen. Ein spezielles Beispiel für Wissen über andere Subjekte stellt das von deren Ausfall dar ([KaTa91], [Maze91]; vgl. auch [FrRo94], wo ein derartiges Wissen dazu verwendet wird , die von einem ausgefallenen Subjekt begonnene Arbeit durch ein anderes, noch intaktes fortsetzen zu lassen). Allgemein kann das Wissen über andere entweder fest konfiguriert sein, durch explizite Kommunikation ausgetauscht oder anhand von Beobachtungen erfahren werden. Dementsprechend wird auch zwischen reflektiven Subjekten (feste Konfiguration oder explizite Kommunikation) und reaktiven Subjekten (nur Beobachtungen) unterschieden ([DuMo91], [vMar92]; vgl. auch die Selbstadaption von Subjekten in [FeCa91] und [DuLe91]). Festzuhalten ist, daß das Wissen über sich und andere sowie über die zur Erreichung eines bestimmten Zieles benötigten Aktivitäten und Objekte entweder a priori verfügbar ist oder während einer Kooperation durch Koordinationsvorgänge (vgl. Abschnitt 2.2.7) erworben werden muß. 2.2.2 Team Die im Zusammenhang mit einer bestimmten Kooperation gebildete Gruppe von Subjekten wird häufig als Team bezeichnet und läßt sich charakterisieren durch 6 2 Klassifikation bisheriger Kooperationsmodelle - Entstehung und Teilnahmebedingungen, - Größe, - räumliche und zeitliche Verteilung, - Kontext und - Zusammensetzung. Ein Team entsteht entweder durch externe Einwirkung mit oder ohne Einschränkung der möglichen Teilnehmer oder durch die Initiative eines einzelnen Subjektes. Im zweiten Fall ist einerseits zu unterscheiden, ob zusätzliche Teamteilnehmer aufgenommen werden - durch Einladungen von im Team befindlichen Subjekten oder - durch Anfrage bei Subjekten, die sich im Team befinden und derartige Anfragen auf Zugangsrechte hin prüfen, oder - durch eine Kombination beider Verfahren. Andererseits kann das Recht zu Einladungen bzw. zur Prüfung von Anfragen - auf den Initiator des Teams beschränkt sein oder - jedem bereits ins Team aufgenommenen Mitglied zustehen. Als Beispiele seien die in [BePa93] definierten Alternativen angeführt (vgl. Tabelle B-2 und Tabelle B-3): - Gruppen mit eingeschränkter Teilnahme, in denen über eine Liste festgelegt wird, welche Subjekte teilnehmen dürfen (d. h. externe Einwirkung mit Einschränkungen). Bild 2-1 : Beispiele einer Teamentstehung Kann ich mitmachen? Einladung zum Mitmachen 2.2 Klassifikation von Kooperationsmodellen 7 - Offene Gruppen, an denen jedes beliebige Subjekt ohne irgendwelche Einschränkungen teilnehmen kann (d. h. externe Einwirkung ohne Einschränkungen). - Geschlossene Gruppen, bei denen das initiierende Subjekt über die Teilnahme weiterer Subjekte entscheidet. Nicht-Mitgliedern ist eine Anfrage erlaubt. - Geschützte Gruppen, die außerhalb nicht bekannt sind. Dementsprechend ist keine Anfrage von Nicht-Mitgliedern möglich und das initiierende Subjekt entscheidet von sich aus über die Aufnahme weiterer Teilnehmer. In [BiPa93] wird besonderes Augenmerk auf den Zeitraum zwischen dem Abschicken einer Einladung zur Teilnahme und dem Eintreffen der Antwort aufgrund von Kommunikationsverzögerungen gelegt (vgl. Abschnitte 2.2.6 und 3.4). Die Größe eines Teams ist insofern von Bedeutung, als die Anzahl der zugelassenen Subjekte die Verallgemeinerungsfähigkeit eines Kooperationsmodelles stark einschränken kann (vgl. Tabelle B-4). Während allgemeine Modelle beliebige Teamgrößen zulassen, wird in [KLL+93] lediglich aus Gründen der Überschaubarkeit des Teams eine Größenbeschränkung vorgenommen. Diese Größe kann während einer Kooperation fest sein oder beliebig variieren. So wird in den in Tabelle B-4 in der dritten Spalte aufgeführten Arbeiten zugelassen, daß während einer Kooperation neue Mitglieder in ein Team aufgenommen werden bzw. daß bisherige Mitglieder das Team auf eigenen Wunsch oder auf Wunsch des Teaminitiators verlassen. Dazu sind i.a. spezielle Mechanismen zur Vor- und Nachbereitung von Kommunikationsbeziehungen und Arbeitsumgebungen der Teammitglieder erforderlich. Ein problemloses Ein- und Ausgliedern wird lediglich durch den in [LJS93] beschriebenen Kommunikationsmechanismus ermöglicht (vgl. Abschnitt 2.2.6). Bei variabler Teamgröße ist außerdem zu beachten, daß die Funktionstüchtigkeit noch erhalten bleibt. Dies kann durch Definition einer minimalen Teamgröße wie in [KaTa91] erfolgen. Die in den in Tabelle B-5 aufgeführten Arbeiten vorgestellte räumliche und zeitliche Verteilung beschreibt die Anwesenheit der Teammitglieder über der entsprechenden Dimension und ihre Auswirkung auf die Kommunikation unter den Teammitgliedern (vgl. Abschnitt 2.2.6). Unter Teamkontext versteht [KMW91] u. a. die Teamumgebung, speziell auch die physikalische Umgebung, die Absichten des Teams, die innerhalb des Teams gültigen sozialen Konventionen bezüglich der Infrastruktur (z. B. ?Hackordnung? oder in Kommunikationen verwendete Formalität) oder die Bereitschaft zum Ausprobieren neuer Wege. Hierunter läßt sich auch die in [GSS+93] verwendete Konferenzhierarchie einordnen (Konferenz-, Sitzungsleiter, aktive und passive Sitzungsteilnehmer). Eine wichtige Rolle spielt außerdem, ob zwischen allen Teammitgliedern eine Kommunikationsbeziehung besteht oder ob die Mitglieder nur teilweise vernetzt 8 2 Klassifikation bisheriger Kooperationsmodelle sind. Im zweiten Fall lassen sich durch Nachbarschaftsrelationen unterschiedlich intensive Subjektbeziehungen definieren. So wird z. B. in [DuLe91] eine gewisse Verantwortlichkeit zur Übernahme von Aufgaben der benachbarten Subjekte abgeleitet. Für die Zusammensetzung eines Teams ist zum einen die Homogenität bzw. Heterogenität der Subjekte von Bedeutung. Beispiele für heterogene Teams sind wie in Tabelle B-6 aufgeführt: - Aus menschlichen und maschinellen Subjekten gemischte Teams. Dies schlägt sich in unterschiedlich detaillierten Subjektmodellen nieder (vgl. Abschnitt 2.2.1). - Auf die Lösung unterschiedlicher Aufgaben spezialisierte Subjekte, d.h. Subjekte mit unterschiedlichem Wissen und unterschiedlichen Fähigkeiten (ein extremes Beispiel stellt [KCTL93] dar: ein Team aus einem Generalisten und mehreren Spezialisten). Eng damit verbunden ist die Eignung für unterschiedliche Rollen (s. u.). - Subjekte mit unterschiedlichen Ressourcen wie z. B. unterschiedlichen Arbeitsumgebungen. So wirkt sich im Zusammenhang mit CSCW die Heterogenität von Arbeitsplatzrechnern auf die Visualisierung der von den Subjekten bearbeiteten Objekte aus (vgl. Abschnitte 2.2.5 und 3). In Modellen, in denen Ressourcen eines Subjektes zu dessen Fähigkeiten gerechnet werden, fällt dieser Aspekt mit dem zuletzt genannten zusammen. - Unterschiedliches Kommunikationsverhalten. Beispiele dafür sind unterschiedliche Sprachen, ein unterschiedliches Verständnis von Fakten oder unterschiedliche Kommunikationsmedien. Diese Form der Heterogenität von Teams beeinflußt die in Abschnitt 2.2.6 behandelte Kommunikation zwischen den einzelnen Subjekten. - Unterschiedliche CSCW-Anwendungen, die auf unterschiedlichen Kooperationsmodellen basieren und dementsprechend in der ganzen Architektur kooperationsunterützender Werkzeuge zu berücksichtigen sind (vgl. Abschnitte 3 und 5). Wie diese Beispiele zeigen, kann sich Heterogenität von Teams sowohl positiv (z. B. durch Ergänzung von Subjekten bezüglich ihrer Fähigkeiten und Ressourcen) als auch negativ (z. B. durch Verständnisprobleme) auswirken (vgl. [BoGa88]). Neben der Beschreibung der besonderen Fähigkeiten der einzelnen Subjekte in der Teamzusammensetzung lassen sich auch mögliche Rollen dieser Teilnehmer angeben. Dabei kann gemäß Tabelle B-7 unterschieden werden nach - Teamrelevanz, - Aufgabenrelevanz, - Objektrelevanz. 2.2 Klassifikation von Kooperationsmodellen 9 Außerdem können Rollen kontextspezifisch definiert werden (z. B. im Bereich des in Abschnitt 3.2 beschriebenen Workflow Managements: ?Sekretär einer Abteilung?, wobei ?Abteilung? erst durch den Kontext bestimmt wird). Beispiele für teamrelevante Rollen sind durch Hierarchie vorgegebenes Verhalten oder Rechte bzw. Einschränkungen. So versteht z. B. [Wong93] unter einer Rolle die Position eines Subjektes innerhalb der Gruppenhierarchie und das daraus abgeleitete Interaktionsverhalten: Subjekte verhalten sich unterschiedlich, je nachdem, ob sie mit übergeordneten oder untergeordneten Subjekten kommunizieren. Ein weiteres Beispiel für eine teamrelevante Rolle stellt die eines Teamsprechers dar. Diese wird verwendet zur Einschränkung des Kommunikationsaufwandes bzw. als Schnittstelle eines Teams nach außen ([DuMo91] und [Rü93]). [Wong93] und [DuLe91] verallgemeinern diese Aussage insofern, als sie Organisationen generell als Hilfsmittel zur Einschränkung des Kommunikationsaufwandes ansehen. Aufgabenrelevante Aspekte von Rollen sind z. B. Fähigkeiten von Subjekten, die eine spezielle Eignung zur Aufgabenlösung bedeuten (vgl. [KMW91]), oder Auswahlkriterien für Aufgaben ([BoGa88]). Dementsprechend verwenden [DuMo91] ?Rollen? in dem Sinne, daß sie die Aktivitäten von Subjekten vorgeben (z. B. Producer, Consumer und Transporter). Dagegen definieren Rollen in [BePa93] die im Zusammenhang mit administrativer Kontrolle benötigten Rechte. Objektrelevante Rollenaspekte betreffen die mit unterschiedlichen Objektzugriffen (z. B. lesen, schreiben) benötigten Rechte über der Zeit (vgl. [BePa93]). Allgemein können Rollen fest konfiguriert sein, dynamisch ausgehandelt werden oder variieren (vgl. Tabelle B-15). Außerdem können die daraus resultierenden Verantwortlichkeiten disjunkt oder überlappend sein ([DuLe91]). 2.2.3 Ziele und Bewertungen Ziele lassen sich charakterisieren durch - ihre Abhängigkeit von der Zeit, - ihren Abstraktionsgrad, - ihre Gewichtung und speziell im Zusammenhang mit Kooperationen das darin enthaltene Potential für Kompromisse, - ihre Beziehungen zu Subjekten und Teams (wiederum in Verbindung mit Kooperationen). 10 2 Klassifikation bisheriger Kooperationsmodelle Bezüglich der zeitlichen Abhängigkeit von Zielen kann grundsätzlich unterschieden werden zwischen lang- und kurzfristigen Zielen (vgl. z. B. [BuSu92], [DuLe91]). Dabei variieren kurzfristige Ziele in Abhängigkeit vom Zustand des Gesamtsystems. Ziele von Subjekten können unterschiedlich abstrakt ausgeprägt sein. Wie Tabelle B-9 zeigt, können Ziele definiert werden - über Regeln, - über die Optimierung von Metriken oder über sogenannte Utility-Funktionen, - über Aufgaben oder die Qualität von Aufgabenlösungen, - in Form von Objektzuständen oder - über spezielle Definitionen wie z. B. in [Burk92]. Dort wird eine Abbildung von der Menge der Aktionenfolgen in die Menge der möglichen elementaren Aktionen zur Beschreibung von Zielen verwendet. Darüberhinaus sind auch abstrakte Zielformulierungen möglich ([BoGa88]), wie z. B. beim Fußballspieler das Ziel, seiner eigenen Mannschaft zum Sieg zu verhelfen. Derartige Formulierungen sind erst in aufgaben- oder zustandsbezogene Zielbeschreibungen umzusetzen. Gemäß [Haye93] bestimmt - neben der Vorhersagbarkeit der Umgebung - die Gewichtung eines Zieles, wie detailliert bei der Planung der zur Erreichung dieses Zieles benötigten Aktivitäten vorzugehen ist. Für Kooperationen spielt die Gewichtung von Zielen durch die einzelnen Subjekte noch eine weitere wichtige Rolle. Je stärker ein Subjekt ein bestimmtes Ziel gewichtet, desto weniger gern wird es dieses abschwächen oder womöglich völlig aufgeben wollen. In diesem Sinn gibt die Gewichtung von Zielen die Kompromißbereitschaft von Subjekten im Fall von Konflikten an (vgl. Abschnitt 3.2). Im Zusammenhang mit Kooperationen kann außerdem zwischen egoistischen und altruistischen Zielen unterschieden werden. Ziel der Kooperation kann dementsprechend entweder eine Verwirklichung oder bessere Verwirklichung egoistischer Ziele ([BiPa93]) oder die Erreichung eines übergeordneten, globalen Zieles sein. Letzteres muß nicht notwendigerweise vollständig bekannt sein. So kennen z. B. die Mitglieder von Kooperationsteams in [LJS93] und [SRSF91] nur die jeweiligen Projektionen des globalen Zieles auf ihre lokalen Verhältnisse. Während Ziele häufig den Beginn einer Kooperation einleiten, werden Bewertungen von Ergebnissen zur Laufzeit vorgenommen, um eines der beiden folgenden Ereignisse erkennen zu können: 2.2 Klassifikation von Kooperationsmodellen 11 - Auftreten eines Konfliktes (vgl. [SHK+92]). Dieser Aspekt wird in den Abschnitten 2.2.7 und 3.2.1 näher behandelt. - Kooperationsziel ist erreicht, d.h. die Kooperation kann beendet werden. Im zweiten dieser beiden Fälle kann außerdem bewertet werden, wie gut das Ziel erreicht wurde. Im Fall von zeitabhängigen Zielen ist eine Bewertung sehr einfach möglich: das Ziel ist zum angegebenen Zeitpunkt entweder erreicht oder nicht. Dagegen sind bei zeitunabhängigen Zielen möglicherweise komplexere Bewertungsmechanismen erforderlich. In [Burk92] wird Bewertung als Abbildung der Menge der Aktionenfolgen auf eine halbgeordnete Wertemenge definiert. Die Projektion dieser Abbildung auf ein spezielles Subjekt bildet dann die individuelle Bewertung. [LJS93] verwenden zwei Bewertungskriterien: eine Distanzfunktion, die die Differenz zwischen momentanen und angestrebten Objektzuständen angibt, und das sogenannte Fixpunktkriterium. Letzteres ist erfüllt, wenn nach zweimaliger Ausführung von Aktivitäten keine Änderung der beobachteten Objektzustände festzustellen ist und die lokalen Ziele jedes Subjektes bezüglich der Objektzustände erfüllt sind. Durch Bewertungen der Qualität beim Erreichen von Kooperationszielen wird das Verhalten von Subjekten im Hinblick auf die Teilnahme an zukünftigen Kooperationen beeinflußt. Dieser Aspekt wird in [BiPa93] behandelt, indem Subjekte für ihre Teilnahme belohnt oder bestraft werden. 2.2.4 Aktivitäten Wie bereits erwähnt, dienen Aktivitäten der Verwirklichung von Zielen. Dementsprechend sind folgende Aspekte von Bedeutung: - Wirkung einer Aktivität. Diese kann sich im Fortschritt bezüglich der Ziele, in Zustandsänderungen von Objekten und im Verbrauch von Ressourcen äußern. Gemäß [DuLe91] ist diese Wirkung nicht immer vorhersagbar, was in kooperativer Umgebung in verschärfter Form gilt (vgl. [BoGa88]). - Beziehungen zwischen Aktivitäten. - Zusammenfassung zu Plänen (bezüglich eines bestimmten Zieles). Durch ihre Beziehung zu Zielen hängt die Definition von Aktivitäten eng mit der im letzten Abschnitt behandelten Zieldefinition zusammen. In der ersten Spalte von Tabelle B-10 sind 12 2 Klassifikation bisheriger Kooperationsmodelle Ansätze aufgelistet, in denen Aktivitäten verwendet werden, die der Erfüllung einer Aufgabe dienen. Den gleichen Ansatz verfolgen [CKLM91], konkretisieren Aktivitäten aber, indem sie sie als Nutzung von Ressourcen beschreiben. In [Alba92] und [FiWi92] werden unter Aktivitä- ten allgemeine Dienste verstanden, die ein Subjekt anderen erbringen kann. Neben diesen Definitionsformen gibt es Aktivitäten, die Objekte oder die Gesamtwelt betreffen und deren Zustand verändern (s. Abschnitt 2.2.5 und Tabelle B-10). Entsprechend der betroffenen Objekte werden in [BuSu92] nach außen wirksame Aktivitäten (Senden von Nachrichten, Robotikaktionen) und interne Aktivitäten (Auswertung von Nachrichten, Vorbereitung von Aktivitäten) unterschieden. Aktivitäten können untereinander über die beteiligten Ziele (s. u.), über Subjekte und Objekte (vgl. Abschnitt 2.2.5) zusammenhängen und sich gegenseitig beeinflussen (vgl. [MaCr90] und [NPR92]). Außerdem ist ihre Anordnung über der Zeit von Bedeutung: Aktivitäten können gleichzeitig oder überlappend ausgeführt werden oder sie schließen sich gegenseitig aus. In diesem Fall kann es weitere Einschränkungen bezüglich der Reihenfolge geben oder es ist eine beliebige Reihenfolge zugelassen. Allgemein ist zu unterscheiden zwischen einer Einzelaktivität, die sich z. B. nur auf ein einzelnes Objekt bezieht, und der Zusammenfassung aller Einzelaktivitäten, die zur Erreichung eines Zieles benötigt werden. Eine Abfolge mehrerer Einzelaktivitäten mit einem bestimmten Ziel wird auch als Plan bezeichnet (vgl. Tabelle B-11). Auf diesen Punkt wird im Rahmen von Koordinationen in Abschnitt 2.2.7 genauer eingegangen. Eine im Zusammenhang mit Kooperationen besonders wichtige Form von Aktivität stellt die Kommunikation dar, die in den Abschnitten 2.2.6 und 3.1 behandelt wird. 2.2.5 Objekte Wie im letzten Teilabschnitt erwähnt, wird im Rahmen von Aktivitäten i.a. auf Objekte zugegriffen. Die im Zusammenhang mit rechnergestützten Kooperationen betrachteten Objekte lassen sich mit Hilfe der folgenden Eigenschaften beschreiben: - Existenz innerhalb - außerhalb der Rechnerwelt - Zustand und weitere Eigenschaften - Beziehungen zu Subjekten - elementare - zusammengesetzte Objekte 2.2 Klassifikation von Kooperationsmodellen 13 Elementare Objekte lassen sich in die beiden folgenden Klassen unterteilen: - Informationsträger. Diese lassen sich weiter untergliedern in diskrete (z.B. Text, Graphik) und kontinuierliche (z.B. Audio, Video) Informationsträger. - Außerhalb der Rechnerwelt existierende Objekte wie z. B. Roboter, Werkstücke, Fahrzeuge etc. Darüberhinaus können elementare Informationsträger beliebig zusammengesetzt werden und neue, komplexere Objekte bilden (z. B. Datenbanken, Multimedia-Objekte oder Konversationen gemäß [BePa93]). Objekte werden durch eine spezielle Aktivität erzeugt und durch eine Reihe von beliebig vielen Attributen beschrieben, zu denen auf jeden Fall ein global eindeutiger Name, ein auf die zugehörige Klasse verweisender Typ und eine Zustandsbeschreibung gehören (vgl. z. B. [BePa93]). Während der Lebensdauer eines Objektes kann dessen Zustand durch weitere Aktivitäten ver- ändert werden. Je Objekttyp sind nur bestimmte Arten von Aktivitäten zugelassen, die jedoch nicht alle eine Zustandsänderung verursachen (z. B. eine Aktivität zur Abfrage des Zustandes). Außerdem kann es beliebige Einschränkungen beim Zugriff (z. B. nur sequentieller Zugriff, Löschen nur nach Erzeugen möglich usw.) auf die Objekte geben. Dies ist vor allem im Zusammenhang mit der gemeinsamen Benutzung eines Objektes durch mehrere Subjekte, wie sie im Rahmen von Kooperationen auftritt, von Bedeutung. Im allgemeinen gilt dasjenige Subjekt, das ein Objekt erzeugt, als Eigentümer und darf dementsprechend - alle auf diesem Objekt zugelassenen Aktivitäten ausführen - anderen Subjekten den Zugriff auf das Objekt vorschreiben und gegebenenfalls auch einschränken. Die Einhaltung derartiger Einschränkungen ist durch einen entsprechenden Mechanismus zu gewährleisten. Außer diesen Rechten kommt dem Eigentümer aber auch die Pflicht zu, das Objekt zu einem angemessenen Zeitpunkt (z. B. nach Beendigung einer Kooperation) selbst zu löschen oder löschen zu lassen. Erwähnt werden muß in diesem Zusammenhang, daß teilweise zwischen privaten Objekten, die für alle Subjekte außer dem Eigentümer gesperrt sind, und öffentlichen unterschieden wird ([GSS+93], [RSVW94]). In ähnlicher Weise unterscheiden [OMS+92] zwischen lokalen und globalen Ereignissen: lokale Bildschirmmanipulationen z. B. werden nur für das lokale Subjekt sichtbar, für globale Aktivitäten wird ein bestimmtes Fenster definiert. 14 2 Klassifikation bisheriger Kooperationsmodelle Eine besondere Rolle bei Objektzuständen spielen Fehlersituationen, die je nach Schweregrad (vgl. [SeRo93]) zu behandeln sind. [LJS93] beschreiben die Rückwirkung von Objektausfällen auf Ziele und Aktivitäten. Vor allem im Zusammenhang mit CSCW-Anwendungen spielt neben der Existenz und Veränderbarkeit von Objekten auch noch ihre Darstellung eine wichtige Rolle. In einigen Arbeiten ([GrUr92], [KMW91], [Rü93] und [SeRo93]) wird daher unterschieden zwischen dem Objekt an sich und der Visualisierung bei den einzelnen menschlichen Subjekten, die das Objekt benutzen. Dadurch können Benutzer unterschiedliche Sichten auf ein und dasselbe Objekt haben, die sich aber bezüglich des Objektzustandes gleichen. Falls auch die Gleichheit von Visualisierungen erforderlich ist, kann dies, wie in [SeRo93] geschildert, über Benutzerkopplungen geschehen. Wichtig ist die Möglichkeit der Unterscheidung zwischen Objekt und Visualisierung auch im Zusammenhang mit der bereits in Abschnitt 2.2.2 erwähnten Heterogenität von Arbeitsplatzrechnern, da hier eine Objektkonvertierung zur Anpassung an lokale Verhältnisse unbedingt erforderlich ist (vgl. [GSS+93], [KLL+93] und Abschnitt 3.4). Im Rahmen einer Kooperation werden entweder nur Objekte einer bestimmten Klasse verwendet oder solche aus beliebigen Klassen (vgl. z. B. [SeRo93]). Dabei kann auch ein Objekttyp eine ausgezeichnete Rolle spielen wie z. B. der sogenannte Telepointer in rechnergestützten Konferenz- und kooperativen Editorsystemen ([GSS+93] und [KLL+93]). Aus Gründen der Übersichtlichkeit auf dem Bildschirm ist die Anzahl derartiger Objekte einzuschränken. 2.2.6 Kommunikation Im Rahmen von Kooperationen ist Kommunikation eines der wesentlichen Elemente. Sie läßt sich mit Hilfe der folgenden Eigenschaften beschreiben, die auch auf das Verhalten von darauf aufbauenden Koordinationen und Kooperationen einwirken: - Ressourcenverbrauch und Gefahr von Fehlern - Anzahl Kommunikationspartner - Heterogenes Kommunikationsverhalten der Partner - Ortstransparenz und Synchronität - Verwendete Kommunikationsmedien (Typen, Anzahl) - Adressierungsformen Kommunikation ist grundsätzlich mit einem gewissen Verbrauch von Ressourcen verbunden. Es ist also sorgfältig zwischen der Notwendigkeit von Kommunikationsvorgängen und ihrem 2.2 Klassifikation von Kooperationsmodellen 15 Nutzen abzuwägen. Eine besondere Bedeutung kommt dem Verbrauch an Zeit, d.h. der Kommunikationsverzögerung zu, die Probleme wie z. B. veraltetes Wissen oder zusätzliche Wartezeiten bei Empfängern verursacht. Außerdem ist die Gefahr von Mißverständnissen und Übertragungsverlusten nicht immer völlig auszuschließen. Allen diesen Problemen ist durch geeignete Berücksichtigung im Rahmen von Subjektmodellen und Werkzeugen zur Subjektunterstützung sowie im Rahmen von Koordinationen Rechnung zu tragen (vgl. die in Abschnitt 2.2.7 beschriebenen Formen der Einschränkung von Kommunikationshäufigkeit, die in Abschnitt 5.4 beschriebene Behandlung von Kommunikationsverzögerungen bei der Bildung von Teams oder das in [Maze91] behandelte Verschwinden von Nachrichtenobjekten und die daraus resultierenden Konsequenzen bei Überlegungen von Subjekten). Während Kommunikation im klassischen Fall zwischen einem Sender und einem Empfänger stattfindet, wird im Zusammenhang mit Kooperationen, an denen üblicherweise ein größeres Team beteiligt ist, ein umfangreicheres Modell benötigt. Daher wird häufig auf 1:m oder sogar n:m-Beziehungen übergegangen, wobei gefordert wird, daß Nachrichten bei allen Teilnehmern in der gleichen Reihenfolge eintreffen ([KaTa91]). [Robi94] verlangt darüberhinaus die Möglichkeit einer dynamischen Veränderbarkeit derartiger Kommunikationsbeziehungen, um das in Abschnitt 2.2.2 beschriebene Ein- und Ausgliedern von Teamteilnehmern zu erleichtern. Für eine erfolgreiche Kommunikation ist es erforderlich, daß sich die beteiligten Partner entweder kompatibel verhalten oder daß der verwendete Kommunikationsmechanismus Unterschiede z. B. bezüglich der verwendeten Sprache ausgleicht (vgl. Abschnitte 2.2.2 und 3.1). Unterschieden wird häufig gemäß der in Abschnitt 2.2.2 eingeführten räumlichen und zeitlichen Verteilung von Teams zwischen - Kommunikation für Teamteilnehmer, die sich zur gleichen Zeit am selben bzw. zu beliebigen Zeiten an unterschiedlichen Orten befinden, d.h. eine Form der Ortstransparenz. - Synchroner und asynchroner Kommunikation für Teamteilnehmer, die gleichzeitig bzw. zu unterschiedlichen ([CKLM91]) Zeiten miteinander kommunizieren. Diese binäre Eigenschaft läßt sich zu der in [Rü93] eingeführten Synchronität erweitern, mit der der gewünschte zeitliche Abschluß des Kommunikationsvorganges in stetiger Form definiert werden kann. Kommunikation kann über ein oder mehrere Medien erfolgen. Beispiele dafür sind: ein Shared Workspace (vgl. Abschnitt 3.1 und 3.3) und zusätzliche Nachrichtenkanäle oder Kommunikation im Bereich von Multimedia (vgl. Tabelle B-14). 16 2 Klassifikation bisheriger Kooperationsmodelle Die Kommunikation zwischen Subjekten kann mit direkter Adressierung oder anonym erfolgen. Im ersten Fall gibt der Sender den oder die Namen von gewünschten Empfängern explizit an, im zweiten Fall wird, ähnlich wie beim Schwarzen Brett, eine Botschaft für alle zugänglich, die sich dafür interessieren. Das bedeutet, daß der Sender die Empfänger seiner Botschaft nicht unbedingt kennt, was sicher nicht in jedem Fall wünschenswert ist. Kommunikation mit direkter Adressierung wird häufig auch als explizit bezeichnet und Kommunikation mit anonymer Adressierung dementsprechend als implizit. Wie in [LJS93] gezeigt wird, hat implizite Kommunikation den Vorteil, das in Abschnitt 2.2.2 geschilderte Heterogenitätsproblem bezüglich des unterschiedlichen Kommunikationsverhaltens auf die Beziehungen zwischen Subjekten und Objekten zu beschränken. Wie in Abschnitt 2.2.2 bereits erwähnt wurde, bietet ein solcher Mechanismus sowohl eine gute Lösung der Heterogenitätsproblematik als auch des Ein-/Ausgliederungsproblems in variablen Teams. Andererseits sind zusätzliche Vorkehrungen nötig, um gegebenenfalls die Anonymität von Sendern und Empfängern zu beheben und die Sichtbarkeit von Objektänderungen einzuschränken. 2.2.7 Koordination Kooperationen können durch Koordinationen organisiert und dadurch effizienter gestaltet werden. Andererseits sind Koordinationen aber auch mit Aufwand verbunden, so daß zwischen diesem Aufwand und dem erbringbaren Nutzen abzuwägen ist. Um dies zu ermöglichen, werden Koordinationen im folgenden genauer beschrieben. Eine Koordination läßt sich charakterisieren durch folgende Aspekte: - Anlaß, d.h. Koordinationsbedarf, - Struktur, - Gegenstand, - Zeitpunkt + Detaillierung, - Gültigkeitsdauer und - Kontrolle. Ein Koordinationsbedarf entsteht entweder zu Beginn oder während einer Kooperation durch Vorgabe von Zielen oder die Entdeckung eines Konfliktes. Da ein Konflikt im Rahmen einer Kooperation zu einer mehr oder weniger starken Blockierung eines oder mehrerer Teammitglieder führen kann, sind Konflikte unbedingt zu vermeiden oder zu beheben (vgl. Abschnitt 3.2). 2.2 Klassifikation von Kooperationsmodellen 17 Konflikte können auf unterschiedlichen Ebenen auftreten: neben Zugriffskonflikten gibt es auch Konflikte auf semantischer Ebene. Bei diesen ist gemäß [Wong93] zu unterscheiden zwischen persönlichen und sozialen Konflikten. Während ein persönlicher Konflikt durch inkonsistentes Wissen entsteht, wird ein sozialer Konflikt in dieser Definition dadurch verursacht, daß unterschiedliche Subjekte den gleichen Sachverhalt bezüglich seines Wahrheitsgehaltes unterschiedlich bewerten. Es wird also eine unterschiedliche Logik verwendet. Weitere Beispiele für Konflikte sind (vgl. Tabelle B-16): Zielkonflikt, Verletzung einer beliebigen Bedingung (z. B. auch eine Mehrfachbelegung von Ressourcen) oder ein anwendungsabhängiger Konflikt wie z. B. eine Kollision von Robotern oder fahrerlosen Transportsystemen. Die Struktur einer Koordination wird durch koordinierende und koordinierte Subjekte bestimmt. Dabei sind zwei Fälle zu unterscheiden: 1. Ein Subjekt koordiniert sich selbst. Dieser Fall wird im Rahmen des klassischen Scheduling behandelt (vgl. auch [Haye93], [PYF+92]). 2. Eine Menge von Subjekten wird koordiniert. Im zweiten Fall ist gemäß [DuLe91] nach den Beziehungen unter den Subjekten weiter zu unterscheiden:unteren - Hierarchische (oder als Spezialfall zentrale) Koordination, d.h. ein Subjekt koordiniert jeweils eine Menge von Subjekten (bei hierarchischer Koordination ist weiter zu beachten, ob Informationen in vollem Umfang von einer Ebene zur anderen gereicht werden oder ob abstrahiert bzw. selektiert wird). - Laterale Koordination, d.h. eine Menge von Subjekten koordiniert sich gegenseitig. In diesem Fall stimmen die koordinierenden mit den koordinierten Subjekten überein. Der Koordinationsgegenstand hängt stark von der konkreten Anwendung ab. Es lassen sich jedoch sechs unterschiedliche Klassen erkennen, auf die sich alle Anwendungen teilweise oder auch vollständig abbilden lassen (vgl. Tabelle B-17 ): 1. Koordinationsstruktur (Metalevel-Koordination), wie oben beschrieben, 2. Ziele (vgl. Abschnitte 2.2.3 und 3.2), 3. Pläne, 4. Rollenverteilungen, 5. Ressourcenbelegungen, 6. Zusammenführung von Ergebnissen (vgl. Tabelle C-4). 18 2 Klassifikation bisheriger Kooperationsmodelle Wie bereits in Abschnitt 2.2.4 angedeutet, wird eine Zusammenfassung von Einzelaktivitäten mit einem bestimmten Ziel als Plan bezeichnet. Im allgemeinen Fall enthält ein solcher Plan neben den einzelnen ausgewählten Aktivitäten eine partielle Ordnung über der Zeit, wobei einschränkende Bedingungen zu berücksichtigen sind (vgl. die in Abschnitt 2.2.4 beschriebenen Beziehungen zwischen Aktivitäten). Möglicherweise werden Teilpläne auch in Form von Alternativen definiert, von denen eine in Abhängigkeit vom jeweils gültigen Systemzustand ausgewählt wird. Auf unterschiedliche Detaillierungsgrade von Plänen wird weiter unten im Zusammenhang mit dem Zeitpunkt für die Planerstellung genauer eingegangen. Pläne werden sowohl für einzelne Subjekte als auch für ein ganzes Team erstellt und dementsprechend als individuell bzw. gemeinsam bezeichnet. Im Zusammenhang mit Rollenverteilungen kann nach [Rü93] zwischen elementarer und komplexer Koordination unterschieden werden. Die Grenze zwischen diesen beiden Koordinationsformen wird dann durch die in Abschnitt 2.2.2 eingeführte Relevanz der Rolle (objekt- oder aufgabenrelevant) bestimmt. Dieses Modell wird durch die Einführung beliebiger Prädikate zur Beschreibung von Koordinationen verallgemeinert. Im Zusammenhang mit dem Zeitpunkt und dem Detaillierungsgrad einer Koordination lassen sich die in [Haye93] für den Fall von Planungen für ein einzelnes Subjekt gewonnenen Erkenntnisse verallgemeinern. Dort werden die in Tabelle 2-1 aufgeführten Grenzfälle und ihre Auswirkungen auf das Zusammenspiel zwischen Vorausplanung, Beobachtung und Entscheidung für eine bestimmte Aktivität betrachtet. Falls das Verhalten der Umgebung einigermaßen vorhersagbar ist, ist eine detaillierte Vorausplanung möglich und es ist höchstens minimale Beobachtung erforderlich. Kann das Verhalten der Umgebung dagegen nicht vorhergesagt werden, so kann a priori lediglich eine Grobplanung vorgenommen werden, die angibt, bei welcher Bedingung welche Aktivität auszuführen ist. Zur Laufzeit wird dann aufgrund von Beobachtungen und Vergleich mit den vordefinierten Bedin- Ziele mit starker Gewichtung Ziele mit geringer Gewichtung Verhalten der Umgebung vorhersagbar Detaillierte Vorausplanung, minimale Beobachtung Detaillierte Vorausplanung, keine Beobachtung Verhalten der Umgebung nicht vorhersagbar Vorab nur Grobplanung, Entscheidung nach Beobachtung Keine Vorausplanung, Entscheidung nach Beobachtung (Reflexverhalten) Tabelle 2-1 : Grenzfälle bei Aktivitätsplanungen 2.2 Klassifikation von Kooperationsmodellen 19 gungen ausgewählt. Ein derartiger Aufwand lohnt sich jedoch nur bei Zielen mit starker Gewichtung, die also unter allen Umständen zu erreichen sind. Bei Zielen mit geringer Gewichtung dagegen entfällt die Vorausplanung und es wird bei Bedarf je nach Beobachtung für irgendeine Aktivität entschieden. Den zwischen diesen Grenzfällen liegenden Bereich, in dem jeder beliebige Grad von Zielgewichtung und Vorhersagbarkeit für das Umgebungsverhalten auftreten kann, bezeichnet [Haye93] als strategisch. In diesem Bereich wird je nach Grad der oben genannten Kriterien und Verfügbarkeit von Ressourcen für Vorausplanung und Beobachtung unterschiedlich vorgegangen. Einen ähnlichen Ansatz liefern [DuLe91], die unterschiedliche Detaillierungsgrade von Plänen definieren: major steps gemäß einer langfristigen Strategie, denen spezifische primitive Aktivitäten inkrementell oder als Reaktion auf Zustandsänderungen hinzugefügt werden. Auf diese Weise können Pläne adaptiert werden. Ähnliche Vorgehensweisen sind in [MDS93] und [SRSF91] zu finden. Insgesamt läßt sich festhalten, daß entweder zu Beginn einer Kooperation vollständig oder zumindest teilweise koordiniert wird oder immer wieder während des Verlaufs der Kooperation. In diesem Zusammenhang spielt auch der zur Abstimmung benötigte Kommunikationsaufwand eine wesentliche Rolle. Dieser wird u.a. durch die Häufigkeit von Kommunikationsvorgängen bestimmt. Es ist also zwischen dem durch eine Kommunikation verursachten Aufwand und dem damit für die Koordination erbrachten Nutzen abzuwägen. In [Rü93] kann die Kommunikationshäufigkeit in Abhängigkeit von Aktivitäten definiert werden (Granularität von Aktivitäten). [DLC87], [DuLe91] und [KLL+93] verwenden dazu eine Art Vorabinformation. Indirekten Einfluß auf die Häufigkeit hat auch ein hohes Abstraktionsniveau für die ausgetauschten Nachrichten sowie die Verwendung eines Teamsprechers (vgl. [DuMo91] und Abschnitt 2.2.2). Darüberhinaus kann die Kommunikationshäufigkeit auch durch Definition der Wichtigkeit von Meldungen eingeschränkt werden. Dadurch können weniger wichtige Meldungen unterdrückt werden ([DuLe91]). Die durch eine Koordination ausgehandelten Bedingungen können unterschiedlich lang gelten. In [BoGa88] und [DuMo91] wird dabei unterschieden zwischen - Organisation für längerfristige Festlegungen, - Plan für mittelfristige Festlegungen, - Schedule für direkt auszuführende Festlegungen. Gemäß [DuLe91] dienen Organisationen der besseren Voraussage der Aktivitäten anderer Subjekte, resultieren also in langfristigem Wissen. Wie bereits erwähnt, wird dadurch auch die 20 2 Klassifikation bisheriger Kooperationsmodelle Kommunikationshäufigkeit eingeschränkt. Dagegen sind Organisationen häufig nicht flexibel genug, um stark dynamische Probleme bewältigen zu können. Über die Gültigkeitsdauer eines Koordinationsergebnisses kann also nur in Abhängigkeit von der konkreten Anwendung entschieden werden. Zu den Aufgaben einer Koordination gehört neben der Aushandlung bezüglich eines bestimmten Koordinationsgegenstandes auch die Kontrolle im Hinblick auf die ausgehandelten Bedingungen und die Entdeckung von Konflikten (vgl. Abschnitt 3.2). Im einzelnen sind also die Aktivitäten von Subjekten hinsichtlich der im Plan festgelegten zeitlichen Einschränkungen und Ressourcenbelegung sowie hinsichtlich ihrer Rollenverträglichkeit zu überprüfen. 2.2.8 Kooperation Im Gegensatz zur Koordination zeichnet sich beim Begriff der Kooperation oder dem synonym verwendeten Begriff der Kollaboration in der Literatur noch kein gemeinsames Verständnis ab. Allgemein lassen sich die Modelle in solche aufteilen, in denen Konflikte ausgeschlossen werden, und in solche, in denen Konflikte möglich sind (vgl. die in Abschnitt 3.2 beschriebene Behandlung von Konflikten). Bei [BoGa88] wird Kooperation als derjenige Spezialfall von Koordination definiert, bei dem keine gegensätzlichen Ziele auftreten. Auch [ZlRo91] schließen Konflikte aus, indem für das Vorliegen einer Kooperation gefordert wird, daß sich die geplanten Aktivitäten uneingeschränkt für jedes Subjekt lohnen. [Rü93] versteht unter einer Kooperation lediglich die Instanziierung einer Koordination. Dagegen definieren [BuSu92], [CKLM91], [KSS92] und [Velt93] Kooperation als gemeinsame Nutzung von Ressourcen unterschiedlicher Subjekte. Analog wird auch bei föderativen Datenbanken ([LeOl93]) und beim föderativen Trading ([BeRa91]) vorgegangen. In [GSS+93] erfolgt Kooperation über Starten und Beenden von Multimedia-Anwendungsprogrammen sowie beliebige Eingaben zu diesen Programmen durch unterschiedliche Teammitglieder. In allen diesen Modellen werden i.a. keine Konflikte auf semantischer Ebene behandelt (sondern lediglich die im Rahmen einer elementaren Koordination aufzulösenden Zugriffskonflikte). Nur [Velt93] nennt als weiteren Aspekt von Kooperation eine effektivere oder effizientere Zielerreichung gegenüber Aktivitäten einzelner Subjekte und läßt auch Konflikte zu. Vergleichbar mit diesem Ansatz ist [Alba92], wobei jedoch nicht über die Nutzung von Ressourcen sondern über Dienste kooperiert wird. 2.2 Klassifikation von Kooperationsmodellen 21 Im Gegensatz zu einer derartigen gemeinsamen Nutzung von Ressourcen oder Diensten betont [Klei91] die Bedeutung eines übergeordneten Zieles und [SHK+92] beschreibt Kooperation durch die aus den Subjektzielen entstehenden gemeinsamen Aufgaben. In diesem Modell ist eine Behandlung von Konflikten durch Verhandlungen möglich. 2.2.9 Unterstützte kooperative Anwendungen Einen guten Überblick über Werkzeuge zur Rechnerunterstützung und ihren Einsatz im Bereich CSCW bietet [Rü93]. Mögliche Anwendungen sind dabei Mehrbenutzer-Spiele, Meeting Support, asynchrone und Echtzeit-Konferenz , Strukturierte Konversationen und Büroinformationssysteme. Weitere Arbeiten auf diesem Gebiet behandeln Kooperative Editoren, Kooperatives Systemdesign oder Joint Design und Software-Management sowie Kooperatives Lernen (vgl. Tabelle B-18 und Abschnitt 3.2). Als Spezialfall sei außerdem [PYF+92] angeführt, wo die Koordination und Ausführung von Routinetätigkeiten eines einzelnen Benutzers unterstützt werden. Einen Überblick über Anwendungen im Bereich Verteilte KI bietet [vMar92]. Beispiele für solche Anwendungen sind Theorembeweiser, Verteilte Interpretation, Planung und Kontrolle, Leitsystem für Straßenverkehr, Management für Telefonnetze und Job-Shop Scheduling (vgl. Tabelle B-19). Beispiele aus dem Bereich Robotersysteme und Fabrik der Zukunft sind die in Tabelle B-20 genannten Arbeiten über Roboter und fahrerlose Transportsysteme sowie die über Fertigungsleitstände. 2.2.10 Ergebnisse der Klassifikation Ein wesentliches Ergebnis der Klassifikation ist zunächst, daß das Modell für Kooperation nicht konsolidiert ist (vgl. Abschnitt 2.2.8). Auf die daraus entstehenden Konsequenzen für kooperationsunterstützende Werkzeuge wird in Abschnitt 3.5 eingegangen. Ein weiterer Punkt betrifft die unterschiedlichen Vorgehensweisen in den Bereichen CSCW und VKI: Im Bereich CSCW werden häufig variable Teams zugelassen. Eine Trennung in die drei Schichten Kommunikation - Koordination - Kooperation ist ansatzweise vorhanden, jedoch noch nicht vollständig durch Realisierungen abgesichert. Die Kommunikation erfolgt häufig über 22 2 Klassifikation bisheriger Kooperationsmodelle anonyme Adressierung. Im Fall von Konflikten wird die Behandlung den menschlichen Subjekten überlassen. Dagegen wird im Bereich VKI meist von fest vorgegebenen Teams ausgegangen. Auf die Bedeutung einer Schichtentrennung wird erst in neueren Ansätzen adäquat reagiert. Kommunikation erfolgt zum großen Teil mit direkter Adressierung. Eine Erkennung und Behandlung von Konflikten ist teilweise integriert. 23 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation Die Möglichkeiten der technischen und insbesondere der computerbasierten Unterstützung kooperierender Personengruppen sollen anhand verschiedener derzeit existierender Anwendungen näher untersucht und klassifiziert werden. Wir beschränken uns hier hauptsächlich auf Werkzeuge für menschliche Subjekte, da im Bereich der maschinellen Subjekte die Grenzlinie zwischen der Kooperationsunterstützung und den Subjektaspekten häufig nicht klar gezogen ist (s. Abschnitt 2.2.10). In der obigen Klassifikation von Kooperationsmodellen werden drei Abstraktionsstufen deutlich, auf denen kooperierende Personen miteinander interagieren. Diese drei Schichten wurden als Kommunikation, Koordination und Kooperation bezeichnet. Die Mächtigkeit von Werkzeugen zur Kooperationsunterstützung kann danach beurteilt werden, welcher dieser Schichten sie zugeordnet werden können. Die Grenzlinie zwischen menschlicher Tätigkeit und Computerunterstützung ist in Bild 3-1 dargestellt. Dort wird die wachsende Funktionalität von Kommunikations- über Koordinations- bis hin zu Kooperationswerkzeugen deutlich. Zusätzlich zu diesen Mechanismen, die die Interaktion zwischen Subjekten betreffen, sind subjektspezifische Unterstützungsfunktionen dargestellt, die durch das Vorhandensein der Interaktionsfunktionalität nötig werden. Diese Funktionalität zur Subjektunterstützung ist teilweise schichtspezifisch, kann jedoch von einem Werkzeug über die Schichten hinweg einheitlich gestaltet werden. In den folgenden Abschnitten werden die drei Schichten der Kooperationsunterstützung näher beleuchtet. Dazu werden jeweils Beispiele für technische (v.a. rechnerbasierte) Systeme Bild 3-1 : Hierarchie der Kooperationsunterstützung Kommunikation Koordination Kooperation Subjektunterstützung Subjektunterstützung 24 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation betrachtet, die Funktionen der jeweiligen Schicht enthalten. Aus den Anwendungsbeispielen werden Klassifikationskriterien abgeleitet, anhand derer ein technisches System innerhalb der relevanten Schicht eingeordnet werden kann. Die gefundenen Kriterien werden - wo möglich - in einem sogenannten morphologischen Kasten dargestellt, in dem dann die Anwendungsbeispiele eingeordnet werden. Unter einem morphologischen Kasten versteht man einen mehrdimensionalen Raum orthogonaler Kriterien. Jedes Kriterium weist einen abzählbaren, zu anderen Kriterien disjunkten Wertebereich auf. Jeder Vektor in diesem Raum beschreibt genau eine Ausprägung. Durch Bilden aller Vektoren kann vollständig geprüft werden, ob die Ausprägung bekannt ist, oder ob sie zu neuen Möglichkeiten führt ([Dubb], [Roth82]). In einem weiteren Abschnitt wird die Subjektunterstützung behandelt. 3.1 Kommunikation Grundlage jeder Kooperation ist die Möglichkeit zur Kommunikation. Kommunikationswerkzeuge können direkt zur Unterstützung von Kooperation verwendet werden, wobei die zur Kooperation zusätzlich nötige Funktionalität von den Benutzern erbracht wird. In den nächsten Abschnitten sollen einerseits die Basismechanismen zur Kommunikation in kooperativen Umgebungen dargestellt werden und andererseits anhand einiger Beispiele die Kriterien für die Klassifikation von Kommunikationswerkzeugen ermittelt werden. 3.1.1 Basismechanismen für die Kommunikation Wie Bild 3-2 zeigt, läßt sich jede Kommunikationsform über eine Änderung von Objekten beschreiben: Bild 3-2 : Kommunikationsformen Sender Empfänger Objekt Zustandsändernde Aktivität Aktivität zur Wahrnehmung des Objektzustandes Benachrichtigung über bzw. Präsentation des Objektzustandes 3.1 Kommunikation 25 - ein oder mehrere Sender führen eine zustandsändernde Aktivität aus, - der resultierende Objektzustand wird von einem oder mehreren Empfängern mit oder ohne vorherige Benachrichtigung wahrgenommen. Anhand dieses Modelles lassen sich drei Grundformen von Kommunikation für unterschiedliche Anwendungsbereiche ableiten: Kommunikation zwischen autonomen Agenten im Bereich Verteilter KI, Kommunikation über Blackboards, die eine Zwischenstufe einnimmt, und Kommunikation im Bereich CSCW. Wie im Folgenden genauer beschrieben wird, läßt sich dabei ein Trend ablesen, der von der klassischen Kommunikation mit direkter Adressierung (Sender schickt Objekt vom Typ ?Nachricht? an Empfänger) wegführt zu einer anonymen Adressierung, bei der die Beziehung zwischen Sender und Objekt im Vordergrund steht und Objektänderungen bei beliebig vielen Empfängern sichtbar werden können. Die Vor- und Nachteile dieser Kommunikationsformen sind in Abschnitt 2.2.6 beschrieben. Kommunikationswerkzeuge sorgen für die korrekte und rechtzeitige Zugreifbarkeit der gemeinsamen Objekte und für die Einhaltung der Zugriffsrechte auf die Objekte, betrachten jedoch nicht den Inhalt der Objekte. Im Kooperationsmodell von [Rü93] wird zwischen elementarer (Mikro-) und komplexer (Makro-) Koordination unterschieden (s. Abschnitt 2.2.7). Mikrokoordination regelt den Zugriff auf Objekte, ist also nach unserem Verständnis ein Teil der Kommunikation. Im Bereich der Verteilten KI wird der Begriff der Kommunikation häufig auf die Verwendung der klassischen Kommunikationsform eingeschränkt. Es werden also spezielle Kommunikationsobjekte und -operationen verwendet und die Empfänger werden direkt adressiert (vgl. Tabelle B-18, erste Spalte). Wie in den in Tabelle B-18, zweite Spalte aufgelisteten Arbeiten für den Bereich CSCW und für allgemeine Anwendungen gezeigt wird, kann die Einschränkung auf bestimmte Kommunikationsobjekte und der Einsatz einer direkten Adressierung auch entfallen und es kann über beliebige Zustandsänderungen beliebiger Objekte kommuniziert werden (Konzept des Shared Workspace). Das Konzept von Blackboards wird z.B. von den in Tabelle B-18 in der dritten Spalte aufgelisteten Arbeiten verwendet. Auch hierbei sind n:m anonyme Kommunikationsbeziehungen möglich. 26 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation 3.1.2 Beispiele für Kommunikationswerkzeuge Die folgenden Beispiele für Kommunikationswerkzeuge sollen betrachtet werden: - Das Fernsehen übermittelt Informationen von einer Quelle an eine (große) Anzahl von Empfängern über Video- und Audiokanäle. Die gesendete Information stellt überwiegend natürliche Vorgänge dar. Der Sendezeitpunkt ist normalerweise identisch zum Empfangszeitpunkt, kann jedoch mit Hilfe eines Videorekorders von diesem entkoppelt werden. Die gesendete Information kann entweder zum Sendezeitpunkt entstehen (Liveübertragung) oder vorher produziert und gespeichert worden sein. - Das Telefon dient heute noch überwiegend der Kommunikation zwischen zwei gleichberechtigten Partnern über einen Audiokanal. Die Kommunikationspartner nutzen das Telefon gleichzeitig, um natürliche Sprache live zu übertragen. - Eine herkömmliche Wandtafel dient einer Gruppe von in einem Raum gleichzeitig anwesenden Personen zur Unterstützung einer Diskussion durch graphische und textuelle Darstellungen, wobei normalerweise zu jedem Zeitpunkt eine Person die Tafel ?bedient?. Die kommunizierten Inhalte werden sowohl durch direkten Blick- und Hörkontakt (Gesten, Sprache), als auch durch die Darstellungen an der Wandtafel übertragen. Demgemäß werden sowohl künstlich erzeugte, als auch natürliche Informationen übertragen, die alle live entstehen. Die hinterlassenen Objekte auf der Wandtafel können auch zur nachträglichen Information nicht gleichzeitig anwesender Kommunikationspartner dienen. - Systeme zur Übermittlung von elektronischer Post (email) dienen der asynchronen Übertragung von Nachrichten von einem Sender zu evtl. mehreren Empfängern. Die Nachrichten können aus mehreren Medien zusammengesetzt sein, sind heute jedoch noch überwiegend künstlich erzeugte Texte. Natürliche Inhalte (Sprache, Bilder) können als solche oder in übersetzter Form (z.B. Mitschrift, Beschreibung) integriert werden. Die übertragenen Nachrichten entstehen häufig nahezu live, d.h. sie werden erstellt, um dann sofort abgesandt zu werden. Genauso können aber auch vorgefertigte Nachrichten gesendet werden. Die Standards für Format und Übertragungsprotokoll von Elektronischer Post im Internet sind z.B. in [Post82], [Croc82], [BoFr93] zu finden. - Videokonferenzsysteme verbinden mehrere gleichberechtigte Teilnehmer durch Videound Audiokanäle, wobei alle gleichzeitig senden und empfangen können. Die ausgetauschte Information entsteht auf natürliche Weise und wird live übertragen. Videokonfe- 3.1 Kommunikation 27 renzsysteme, die natürliche Kommunikationskanäle durch Videoverbindungen erweitern sind u.a. in [BHI93], [Gave92], [RKGB92] zu finden. - Ein weiteres Kommunikationswerkzeug, das gut mit einer Videokonferenz kombiniert werden kann, ist die virtuelle elektronische Wandtafel. Mehrere gleichberechtigte Teilnehmer kommunizieren durch die Manipulation graphischer und textueller Objekte auf einer virtuellen Zeichenfläche. Die Objekte entstehen meist live während der Diskussion, können aber auch aus vorgefertigten Vorlagen übernommen werden. Die Teilnehmer kommunizieren normalerweise synchron. Eine asynchrone Arbeitsweise ist jedoch ebenfalls denkbar, bei der Kommunikationspartner die Ergebnisse vorhergehender Sitzungen weiterverarbeiten ([SFB+87]). 3.1.3 Klassifikationskriterien für Kommunikationswerkzeuge An diesen Beispielen werden verschiedene Kriterien sichtbar, die die verschiedenen Ausprä- gungen beschreiben, in denen Kommunikation und damit auch Kommunikationswerkzeuge auftreten können. Diese Kriterien werden in einem morphologischen Kasten zusammengestellt (Bild 3-3). Am Beispiel des Telefons ist der beschreibende Vektor in den morphologischen Kasten eingezeichnet. Um die Übersicht zu wahren, werden die restlichen Vektoren in tabellarischer Form aufgeführt (Tabelle 3-1). Einige der Beispiele zeigen, daß ein Werkzeug in verschiedenen Formen genutzt werden kann, die verschiedene Vektoren im morphologischen Kasten darstellen. Dies ist in der Tabelle dadurch dargestellt, daß zu einem Kriterium mehrere Ausprägungen angegeben sind. Die einzelnen Kriterien des morphologischen Kastens haben folgende Bedeutung: Zeit: Kommunikationspartner können zeitgleich über das Kommunikationswerkzeug verbunden sein (synchron), oder zeitlich versetzt auf die Kommunikationsobjekte zugreifen (asynchron). Weg: Gibt das Verhältnis der Anzahl der sendenden zur Anzahl der empfangenden Kommunikationspartner an. Dieses Verhältnis kann sich während einer ?Sitzung? ändern. Werkzeuge, die auf einer Einbettung von Einbenutzeranwendungen in Kooperationsumgebungen beruhen (als collaboration-transparent oder collaboration-unaware bezeichnet), können zu jedem Zeitpunkt nur 1:n Beziehungen unterstützen, während in den sogennanten collaboration-aware Werkzeugen auch m:n Beziehungen möglich sind. Medium: Stellt die Informationstypen dar, die in den Kommunikationsobjekten enthalten sind. Hier ist zwischen technisch übertragenem Audio bzw. Video und direktem Sicht- bzw. Hörkontakt zu unterscheiden. Die räumliche Nähe zwischen den Kommunikationspartnern ist 28 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation also in diesem Kriterium enthalten. Dieses Kriterium umfaßt auch beliebige Kombinationen der Einzelmedien. Z.B. beinhaltet Fernsehen sowohl Audio als auch Video. Erzeugung: Unterscheidet zwischen natürlich und künstlich entstandenen Informationen. Eine Ersatzdarstellung für natürlich entstandene Informationen - z.B. die Mitschrift einer Rede oder eine Bildbeschreibung - wird als ?übersetzt? bezeichnet. Quelle: Unterscheidet zwischen Informationen, die zum Zeitpunkt des Sendens entstehen und solchen, die vorab erzeugt wurden. Beziehung: Gibt die Beziehung zwischen den Kommunikationspartnern, d.h. deren Rollenverteilung an. ?Master/Slave? bezeichnet eine Beziehung, in der die Initiative von einem Kommunikationspartner ausgeht, während alle anderen eine passive Rolle spielen. Bei einer ?Peer to Peer?-Beziehung sind die Kommunikationspartner gleichberechtigt in der Auslö- sung von Kommunikationsvorgängen. 3.2 Koordination Aus den in Abschnitt 2 beschriebenen Modellen lassen sich die wesentlichen Aufgaben eines Koordinationswerkzeugs ermitteln. Ein solches Werkzeug dient der Abstimmung von Teilzielen inklusive der Planung von Aktivitäten, der Zuweisung von Rollen und Ressourcen an Subjekte und der Überwachung und Zusammenführung der Ergebnisse von Aktivitäten. Wie bereits in Abschnitt 2.2.7 beschrieben, wird diese Funktionalität eingesetzt, um sowohl die Arbeiten eines einzelnen Subjekts als auch die einer Menge von Subjekten zu koordinieren. Eine Subjektmenge kann einerseits eine kooperativ arbeitende Gruppe und andererseits eine Organisa- Bild 3-3 : Morphologischer Kasten: Kommunikation Telefon Zeit synchron asynchron Weg 1 fi 1 1 fi n m fi n Medium Audio (hören) Video (sehen) Text Grafik ? (alle Permutationen der Sinneswahrnehmung) Erzeugung natürlich künstlich übersetzt Quelle playback live Beziehung Master/Slave Peer to Peer sonstige Rollen 3.2 Koordination 29 tion mit hierarchischer Befehlsstruktur sein. In letzterer ist der Koordinationsvorgang zentralisiert, die Aufgaben werden den Ausführenden lediglich mitgeteilt, Meldungen über den Fortschritt gehen von den Ausführenden an den Koordinator. Dagegen ist in kooperativen Szenarien die ganze Gruppe in den Koordinierungsvorgang involviert, wobei auch der Fall eintreten kann, daß eine Gruppe einen Koordinator wählt. In beiden Fällen ist Kommunikation die Grundlage für eine erfolgreiche Koordination, wobei dies im kooperativen Fall wesentlich stärker sichtbar wird, da schon für den eigentlichen Koordinationsprozeß zur Abstimmung von Teilzielen, zur Verteilung von Rollen etc. Kommunikation nötig ist. Im Gegensatz zu Kommunikationswerkzeugen müssen Werkzeuge zur Koordination den Inhalt der involvierten Objekte berücksichtigen (s. die Unterscheidung von Mikro- und Makrokoordination in Abschnitt 3.1, [Rü93]). Die Kriterien, die ein Koordinationswerkzeug charakterisieren, sollen anhand von Basismechanismen und von bekannten Anwendungsklassen ermittelt werden. 3.2.1 Basismechanismen der Koordination In der Literatur sind verschiedene Basismechanismen zu finden, die in Koordinationswerkzeugen verwendet werden. Diese Mechanismen tauchen vor allem im Bereich der verteilten künstlichen Intelligenz auf, sind jedoch auch als Basis für die Koordination menschlicher Subjekte zu erwägen. Zeit Weg Medium Erzeugung Quelle Beziehung Fernsehen synchron 1 fi n Video + Audio natürlich live playback Master/Slave Telefon synchron 1 fi 1 Audio natürlich live Peer to Peer Wandtafel synchron asynchron 1 fi n n fi m Sehen + Hören + Text + Grafik natürlich + künstlich live Peer to Peer Master/Slave E-Mail asynchron 1 fi 1 1 fi n Text Text + ? künstlich übersetzt live playback Peer to Peer Videokonferenz synchron n fi m Video + Audio natürlich live Peer to Peer E-Wandtafel synchron asynchron n fi m Text + Grafik künstlich live playback Peer to Peer Tabelle 3-1 : Morphologische Charakterisierung der Kommunikationsbeispiele 30 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation - Als Low-Level Koordination wird eine Erweiterung des in Bild 3-2 dargestellten Kommunikationsmechanismus bezeichnet, wobei der Empfänger auf die Wahrnehmung eines Objektzustandes (bzw. dessen Änderung) mit einer eigenen Aktion reagiert (vgl. Tabelle B-14). Derartige aktive Nachrichten können verwendet werden, um die möglichen Reaktionen eines Kommunikationspartners auf den Empfang der Nachricht zu strukturieren. Durch die Einschränkung der Bandbreite der möglichen Empfängerreaktionen wird einerseits eine bessere Vorhersagbarkeit der Reaktion für den Sender ermöglicht und andererseits wird die Reaktion für den Empfänger möglichst einfach gestaltet. Einen ersten Schritt in diese Richtung stellen priorisierte Nachrichten dar, die z. B. zur Meldung von bestimmten Ereignissen wie in [BePa93] und [FeCa91] verwendet werden können und damit dem Empfänger eine entsprechende Reaktion nahelegen, aber nicht garantieren. Eine größere Mächtigkeit wird durch Mechanismen erreicht, die typisierte Kommunikationsobjekte verwenden. Beispiele dafür sind: Request-Response-Systeme (vgl. z. B. [AnCh92]), die als computational mail und active mail bezeichneten Erweiterungen des E-Mail-Prinzips (vgl. z. B. [Bore92], [GSS92]) und die sogenannten communicative acts ([Wong93]). Bei Request-Response-Systemen und computational mail werden Interaktionen als Aufträge und Antworten auf die Aufträge modelliert. Ein sehr allgemeines Konzept zur Low-Level Koordination stellen communicative acts dar. Diese typisierten Kommunikationsobjekte beruhen auf der Theorie der Speech Acts (jede Form einer sprachlichen Äußerung erwartet vom Gesprächspartner eine bestimmte Handlung), die auf die Kommunikation zwischen Subjekten angewendet und dementsprechend als communicative act bezeichnet wurde. Das bedeutet, daß ein Sender einen Empfänger durch Versenden eines bestimmten Nachrichtentyps zu einer bestimmten, durch den Nachrichteninhalt genauer spezifizierten Aktion veranlassen möchte. Beispiele dafür sind Nachrichten vom Typ ?Anfrage?, ?Information? oder ?Beschwerde?. Eine Beschwerde deutet auf einen Konflikt und führt zu der in Abschnitt 2.2.7 angedeuteten und im Rahmen dieses Abschnittes noch zu schildernden, zugehörigen Behandlung. Die Zusammensetzung von communicative acts im Hinblick auf ein spezielles Ziel wird als Protokoll bezeichnet. Dies führt zu der im folgenden behandelten Form der high-level Koordination. - Zur High-Level Koordination (vgl. Tabelle B-15) gehören Protokolle, die auf den typisierten Objekten der Low-Level Koordination basieren und bezüglich einem der in Abschnitt 2.2.7 aufgelisteten Gegenstände koordinieren. Unter Protokoll ist dabei eine geordnete Folge von genau definierten Kommunikations- und Berechnungsschritten zu verstehen. In der von [Wong93] eingeführten Terminologie ist ein Protokoll eine Zusammensetzung von elementaren communicative acts mit speziellem Ziel. Als Beispielprotokoll zur Einigung auf gemeinsame Ziele sei die sogenannte preference-based negotiation 3.2 Koordination 31 geschildert: Jedes Subjekt ordnet seine Ziele in einer Liste an und sendet diese an einen Koordinator, der aufgrund von Mehrheiten eine Gesamtordnung erstellt. Als Beispiel für eine Planerstellung sei [DuMo91] angeführt. Dort bedeutet Koordination eine verteilte Suche (z. B. über ein contract-net-Protokoll) im Raum aller möglichen Interaktionsverhaltensweisen von individuellen Subjekten derart, daß eine Sammlung von Verhaltensweisen gefunden wird, die die wichtigsten Ziele zufriedenstellend erfüllt. Unterschieden wird dabei insbesondere zwischen positiven Interaktionen, die bezüglich der zugrundeliegenden Metrik eine bessere Erreichung der Ziele versprechen, und negativen Interaktionen, die auch als Konflikte bezeichnet werden. Beispiele für Protokolle, die eine Rollenverteilung vornehmen, sind: im Rahmen von Master-Slave-Beziehungen verwendete Protokolle, Contract Net (effizientere Variante in [Wong93]), mögliche Verallgemeinerungen wie Contract Net mit Gegenvorschlägen oder das sogenannte Multistage Negotiation. In einigen Ansätzen kann auch ein beliebiges Protokoll eingesetzt werden. Zur Vermeidung von Ineffizienz bei Master-Slave-Protokollen durch fortgesetzte Delegationen fordern [FeCa91] Rückmeldungen an das initiierende Subjekt. Der Zusammenführung von Ergebnissen dient das in [DLC87] und [DuLe91] geschilderte, als functionally accurate and complete bezeichnete Protokoll. Auch das bereits erwähnte Preference-Based Negotiation Protokoll läßt sich hierunter einordnen. - Um eine Kooperation im Fehlerfall zurücksetzen oder sie bei Bedarf nachvollziehen zu können, wird in [KLL+93] und [LJS93] eine Protokollierung vorgenommen. Eine ähnliche Rolle spielt in [Chiu92] die Verwendung einer beliebig verzweigbaren Geschichte zur Verwaltung von Design-Schritten in einer Datenbank. Für eine Protokollierung bestehen folgende Möglichkeiten: - objekt- oder aktivitätsbezogene Protokollierung - Protokollierung je Teammitglied oder durch einen eigenständigen, passiven Teilnehmer, der erst im Fall einer Wiedergabe aktiv wird. Jeder Protokolleintrag enthält einen Zeitstempel und die Kennung des für eine bestimmte Aktivität oder Zustandsänderung verantwortlichen Subjektes. - Im Rahmen einer Konfliktbehandlung können die folgenden Mechanismen beteiligt sein: - Vermeidung von Konflikten oder - Erkennung, Meldung und Lösung von Konflikten. 32 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation Gemäß [Wong93] können Konflikte vermieden werden, indem jeder Teamteilnehmer den Einfluß seiner eigenen Entscheidungen auf andere abschätzt und entsprechend berücksichtigt. Dazu ist besonderes Wissen über die anderen Teamteilnehmer erforderlich (vgl. die in [SRSF91] eingeführten, als ?Schmerzgrenze? interpretierbaren Parameter und die ebenfalls dort verwendeten speziellen Heuristiken). Wie in Abschnitt 2.2.7 erwähnt, können Konflikte im Rahmen einer Koordination erkannt werden. Die zugehörige Überprüfung geschieht immer dann, wenn neue Information zu einem Koordinationsgegenstand verfügbar wird (vgl. [CKLM91] und [LJS93]). Ein spezielles, auf modaler Logik basierendes Verfahren wird in [Diaz92] geschildert. Dieses beinhaltet jedoch nur Aktivitäten, läßt also nur einen sehr beschränkten Anwendungsbereich zu. Wichtige soziale Konflikte (vgl. Abschnitt 2.2.7) sind an alle beteiligten Teamteilnehmer zu melden. Dabei kann unterschiedlich detailliert vorgegangen werden. [KCTL93] schlägt eine Reihe von Möglichkeiten vor, die Empfänger einer Konfliktmeldung zusätzlich über die Bedeutung des Konfliktes zu informieren (z. B. mit Hilfe von Präferenzen oder beliebig detaillierten Erklärungen). Durch dieses zusätzliche Wissen werden Teamteilnehmer in die Lage versetzt, gezielter auf einen Konflikt zu reagieren und möglicherweise zukünftige Konflikte zu vermeiden (s. o.). Falls ein Konflikt gemeldet wurde, so kann eine Suche nach Alternativen eingeleitet werden. Gemäß [Klei91] kann diese sowohl a priori als auch zur Laufzeit vorgenommen werden. Außerdem ist weiter zu unterscheiden, ob bezüglich zukünftiger oder bezüglich bereits durchgeführter Kooperationsschritte nach Alternativen gesucht wird. Letzteres wird als Backtracking bezeichnet und z. B. in [KCTL93] und [SRSF91] behandelt. [Chiu92] unterstützt kooperativ arbeitende Designer von VLSI-Systemen beim Durchspielen verschiedener Lösungen durch Navigationsmöglichkeiten in einer verzweigten Designgeschichte. Im Zusammenhang mit der Planung zukünftiger Kooperationsschritte geben [CKLM91], [Velt93] und [ZlRo91] zwei Möglichkeiten zur Kompromißfindung an: bezüglich der geplanten Aktivitäten oder bezüglich der Ziele, wobei [Velt93] einen hierarchischen Suchraum und unterschiedliche Abstraktionsniveaus zur Einschränkung des Kommunikationsaufwandes verwendet. [Wong93] gibt zwei Protokolle zur Konfliktlösung bei Uneinigkeit in der Zielpräferenz an: bargaining und forcing. Im ersten Fall versucht ein Subjekt, die anderen von einer anderen Ordnung der Ziele zu überzeugen. Falls sich dabei keine Fortschritte mehr erzielen lassen, wird die zuletzt ausgehandelte Ordnung für alle Subjekte verbindlich, unabhängig von deren Einverständnis. 3.2 Koordination 33 [Alba92] löst Konflikte bei Plänen mit Ressourcenbelegung durch Verwendung alternativer Kapazitäten oder die Wahl einer anderen Auftrags- oder Aktivitätsreihenfolge. Eine umfangreichere Suche ermöglichen [DuMo91], die sechs Dimensionen (Ziel, Weg, Ort, Zeit, Grund und Rollenzuteilung) sowie je Dimension unterschiedliche Abstraktionsgrade angeben, entlang derer nach Alternativen gesucht werden kann (wobei Verfahren wie beim partial global planning eingesetzt werden). Als Anwendungsbeispiel dient wie in [FrRo94] die Kollisionsvermeidung von fahrerlosen Transportsystemen und Robotern (in [FrRo94] wird dazu eine Ausweichpflicht definiert). Einen anderen Lösungsweg schlägt [Klei91] vor, indem er analog zu herkömmlichen Wissensbasen für Bereichs- und Kontrollwissen eine zur Konfliktbehandlung definiert. Diese enthält Konfliktklassen auf unterschiedlichen Abstraktionsniveaus mit jeweiligen Vorbedingungen und einem abstrakten ?Rat?, der anhand von Bereichswissen in einen oder mehrere, zum ursprünglichen Plan alternativen, Plan bzw. Pläne umgesetzt wird. Mit Hilfe von Heuristiken und Bereichswissen wird daraus ein möglichst optimaler Plan ausgewählt. 3.2.2 Beispiele für Koordinationswerkzeuge Die folgenden Beispiele bekannter Werkzeuge bzw. Anwendungsklassen sollen näher betrachtet werden: - Ein elektronischer Terminkalender kann zur Verwaltung der Termine einzelner Personen und zur Abstimmung gemeinsamer Termine dienen. Als reines Kommunikationswerkzeug bietet ein solcher Terminkalender gemeinsamen Zugriff auf die Termine der Einzelpersonen. Die Abstimmung geschieht dann ohne Einwirkung des Werkzeugs. Als Koordinationswerkzeug hat ein Terminkalender ein gewisses Verständnis von der Semantik der Termineinträge und kann beim Finden eines gemeinsamen Termins helfen. Das Werkzeug kann hierzu Terminvorschläge machen und diese den Benutzern zur Abstimmung vorlegen. Mit weitergehenden Vollmachten ausgestattet kann der Terminkalender die Termine auch selbständig festlegen. Die Benutzer des Kalenders können den Terminen eines Benutzers und damit auch diesem Benutzer gegenüber in verschiedenen Rollen auftreten (z.B. Eigner der Termine, Chef des Eigners, Sekretär des Eigners). Zwei Beispiele für elektronische Terminkalender zum Einsatz in kooperativen Arbeitsumgebungen finden sich in [GrSa87]. - Workflow Management-Systeme strukturieren die Bearbeitung von (administrativen) Vorgängen, indem sie deren Weg durch verschiedene Instanzen (Bearbeiter) koordinieren. Die Abfolge der einzelnen Bearbeitungsschritte und der zugehörigen Bearbeiter kann fest 34 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation durch das Werkzeug vorgegeben sein, von Entscheidungen innerhalb der einzelnen Bearbeitungsschritte abhängen oder von den Bearbeitern in einem gewissen Rahmen frei gewählt werden. Das Workflow Management-System kann zu einzelnen Entscheidungen Vorschläge machen, manche Entscheidungen sogar selbständig treffen. Hierzu sind die einzelnen Vorgänge mehr oder weniger stark zu formalisieren. Die einzelnen Bearbeiter treten dem System gegenüber in verschiedenen Rollen auf, die überwiegend durch die Aufgaben der Bearbeiter und deren Bezug zu den bearbeiteten Vorgängen definiert sind. Es sind jedoch auch Rollen möglich, die die organisatorische Struktur der Arbeitsgruppe widerspiegeln. Die Rollenzuteilung ist langfristig bis statisch, eine dynamische Änderung von Rollen entsteht z.B. durch Urlaubsvertretung, Beförderung, Umstrukturierung etc. Ein System, das die Definition von flexiblen Büroprozessen zur Abarbeitung in einem Workflow-Management System erlaubt, ist in [KRW90] beschrieben. Systeme zur Verwaltung von Arbeitsplänen in kooperierenden Gruppen sind u.a. in [Busb93] und [GKM93] beschrieben. - CASE-Tools koordinieren den Prozeß der Softwareerstellung (durch eine oder mehrere Personen), indem sie ein mehr oder weniger formales Modell des Entwicklungsprozesses von Software zugrundelegen. CASE-Tools bieten z.B. Hilfestellung bei der Auswahl und Abfolge der Entwurfsschritte und können die korrekte Abarbeitung des zugrundegelegten Entwurfsprozesses überwachen, die eigentlichen Koordinationsentscheidungen werden jedoch von den Benutzern getroffen. CASE-Tools sind sowohl mit als auch ohne die Zuweisung unterschiedlicher Rollen an die Benutzer denkbar. Rollen können dabei die momentane Beziehung des Benutzers zu einzelnen Teilen des Softwareprojekts beschreiben (z.B. Bearbeiter einer Datei). Andererseits können Rollen die generellen Aufgaben des Benutzers beschreiben (z.B. Codierung, Testen) oder die Beziehung zu anderen Teammitgliedern darstellen (z.B. Projektleiter). Mit dem Fortschreiten des Projekts werden sich auch die Rollen der einzelnen Projektmitarbeiter ändern. Ansätze für die Unterstützung kooperativer Arbeit in der Software-Entwicklung finden sich u.a. in [DeRi93] - Kooperative Lernsysteme werden einerseits in hierarchischen Szenarien aus gleichzeitig anwesendem Lehrer (Tutor) und einem oder mehreren Lernenden eingesetzt, wobei die Lernenden nicht unbedingt miteinander in Kontakt stehen müssen. Andererseits können kooperative Lernsysteme auch von einer Gruppe von Lernenden eingesetzt werden, um z.B. Techniken der Gruppenarbeit zu erlernen bzw. einzuüben. Kooperative Lernsysteme können insofern als Koordinationswerkzeuge betrachtet werden, als sie Lehrer und Schüler bei der Auswahl, Planung und Durchführung von zielgerichteten Aktionen unterstützen. Entsprechend der verschiedenen Szenarien sind unterschiedliche Arten von Rollenverteilungen möglich. Einerseits kann das Lehrer-Schüler Verhältnis auf Rollen abgebildet wer- 3.2 Koordination 35 den, andererseits können Schüler in einer Gruppenarbeitssituation verschiedene aufgabenbezogene Rollen einnehmen. Lernsysteme können den Lernprozeß direkt steuern, indem sie den Lernenden auf einem relativ eng vorgegebenen Weg führen oder nur eine überwachende Funktion einnehmen. Die Lerninhalte sind normalerweise soweit formalisiert, daß maschinelle Manipulationen und Auswertungen der Benutzerinteraktion möglich sind. Eine Plattform zur Entwicklung kooperativer Lernsysteme (NESTOR) wird z.B. in [MSc92] beschrieben. - Ferndiagnosesysteme dienen der Kooperation von Systembedienern und entfernten Experten zur Lösung von Problemen und Fehlersituationen in Software- oder Hardwaresystemen. Systembediener und Experten arbeiten gleichzeitig mit vorgegebenen Aufgaben, die sich in verschiedenen Rollen niederschlagen. Das Diagnosesystem kann Hilfestellung zu Auswahl und Ablauf von Diagnoseschritten geben, wird Entscheidungen aber den Benutzern überlassen. - Joint Design Werkzeuge dienen einer Gruppe von gleichzeitig arbeitenden Benutzern zur gemeinschaftlichen Erstellung von Artefakten verschiedenster Art. Üblicherweise können solche Werkzeuge auch von alleine arbeitenden Benutzern verwendet werden. Die Benutzer müssen nicht unbedingt verschiedene Rollen annehmen. Die Interaktionen zwischen den Benutzern und die behandelten Datenobjekte sind meist wenig formalisiert, das Werkzeug hat meist keine Entscheidungskompetenz, kann jedoch evtl. die Einhaltung von Designrichtlinien, gesetzlichen Vorschriften etc. überwachen. In diese Applikationsklasse können sowohl Mehrbenutzer-Editoren (s. [GSW92]) als auch komplexe Systeme zur Verwaltung und Abwicklung großer Designprojekte (s. [NRZ92], [Chiu92], [WoSr93]) eingeordnet werden. Im zweiten Fall spielen häufig die Protokollierung und Auswertung von Design- und Koordinationsentscheidungen (Design Rationale) sowie die Rücksetzbarkeit von Entscheidungen eine wesentliche Rolle. - Teleshopping-Systeme können als Koordinationswerkzeuge betrachtet werden, die einem Verkäufer und einem potentiellen Käufer zur Verhandlung über einen Kaufvertrag dienen. Käufer und Verkäufer verhandeln nicht direkt miteinander, sie müssen daher nicht gleichzeitig mit dem System verbunden sein. Der Verkäufer macht Angebote publik, die den Käufern vom System dargeboten werden. Das System führt den Käufer durch die Angebote, hat jedoch keinen Einfluß auf die Kaufentscheidung. Solche asynchronen Teleshopping- Systeme können sinnvoll um Direktverbindungen zu Kaufberatern, Serviceabteilung etc. erweitert werden. Die Anforderungen solcher und ähnlicher Systeme an Kommunikationssysteme und Softwaretechnik werden in [RKGB92] untersucht. 36 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation 3.2.3 Klassifikationskriterien für Koordinationswerkzeuge Die verschiedenen Ausprägungen von Koordinationsfunktionalität werden wiederum in einem morphologischen Kasten dargestellt (Bild 3-4). Hierbei ist zu beachten, daß zur Erledigung einer bestimmten Koordinationsaufgabe verschiedene Aktionen nötig sind, die möglicherweise unterschiedliche Vektoren im morphologischen Kasten darstellen. Der eingezeichnete Vektor stellt einen Terminkalender dar, der Terminvorschläge machen kann und in dem verschiedene Rollenbeziehungen wie z.B. Chef / Mitarbeiter möglich sind. Die Vektoren für die restlichen Anwendungsbeispiele sind wieder tabellarisch dargestellt (Tabelle 3-2). Die Kriterien in diesem morphologischen Kasten haben folgende Bedeutung: Zeit: Analog zur Kommunikation kann ein Koordinationswerkzeug die gleichzeitige Anwesenheit der Beteiligten erfordern (synchron) oder auch nicht (asynchron). Formalisierung: Die Interaktionen der Benutzer mit dem Werkzeug und untereinander können unterschiedlich stark formalisiert sein. Ein Formalismus schlägt sich dabei in der Interaktion selbst, den betrachteten Koordinationsgegenständen (s. Abschnitt 2.2.7) und der verwendeten Sprache nieder. Die Ausprägung ?strukturiert? beschreibt die Vorstufe eines For- Bild 3-4 : Morphologischer Kasten: Koordination Terminkalender Zeit synchron asynchron Formalisierung informell ? strukturiert ? formal Führung ungeführt Hilfe Überwachung Vorschläge Steuerung Entscheidungskompetenz keine Vorschlag Entscheidung Koordinationsgegenstand Koop.Struktur Ziele Pläne Rollen Ressourcen Ergebnisse Anzahl Benutzer 1 ? 1 > 1 n Rollen nicht vorhanden vorhanden Rollenbezug Objektrelevant Teamrelevant Aufgabenrelevant Rollenzuordnung statisch dynamisch 3.2 Koordination 37 malismus in dem zwar die Struktur von Interaktionen und Kommunikationsobjekten formalisiert ist, nicht jedoch deren Inhalt. Führung: Der Benutzer kann bei der Suche nach Koordinationsentscheidungen vom Werkzeug unterschiedlich stark geführt werden. Ein Werkzeug ohne Führung läßt dem Benutzer völlig freie Hand in der Auswahl und Abfolge von Aktionen. Ein eingebautes Hilfesystem kann die Benutzung des Werkzeugs erleichtern, ohne den Führungsgrad wesentlich zu erhöhen. Zusätzlich kann das Werkzeug die Aktionen eines frei agierenden Benutzers überwachen und im Fehlerfall eingreifen. Der Führungsgrad erhöht sich weiter, wenn das Werkzeug Vorschläge für Benutzeraktionen macht oder sogar eine strikte Benutzerführung vorsieht. Mit steigendem Führungsgrad ist ein Mindestmaß an Formalisierung notwendig, um dem Werkzeug die Möglichkeit zu geben, die Aktionen des Benutzers zu ?verstehen?. Entscheidungskompetenz: Im Gegensatz zum vorigen Kriterium der Führung, das die Unterstützung bei der Suche nach einer Entscheidung beschreibt, geht es hier um das Treffen der Entscheidung. Ein Werkzeug kann lediglich die Infrastruktur zur Entscheidungsfindung bereitstellen (keine Entscheidungskompetenz), es kann Vorschläge für eine Entscheidung machen oder direkt eine bindende Entscheidung treffen. Auch hier gilt, daß für Entschei- Zeit Formalisierung Führung Entscheidungskompetenz Koordinationsgegenstand Anzahl Benutzer Rollen Rollenbezug Rollenzuordnung Terminkalender async. formal Steuerung Vorschlag Entscheidg. Z, P, Ro, Re, E ? 1 ja Objekt + Team dyn. Workflow Management async. formal strukt. Vorschlag Steuerung Vorschlag Entscheidg. S, A, P, (Ro), Re, E >1 ja Objekt + Team + Aufgaben statisch dyn. CASE-Tool async strukt. formal Hilfe Überw. keine Z, P, Ro, Re, E ? 1 ja nein Objekt + Team + Aufgaben dyn. Kooperatives Lernen sync. strukt. Überw. Vorschlag Steuerung Vorschlag Entscheidg. Z, (P), Ro, (Re), E > 1 ja nein Team Aufgaben dyn. statisch Ferndiagnose sync. strukt. Hilfe Vorschlag Z, P, Re, E > 1 ja Aufgaben statisch Joint Design sync. inform. strukt. ungeführt Hilfe Überw. keine S, Z, P, Re, E ? 1 nein Teleshopping async. sync. formal strukt. Steuerung keine Z, P, E 2 >1 ja Aufgaben statisch Tabelle 3-2 : Morphologische Charakterisierung der Koordinationsbeispiele 38 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation dungen oder Vorschläge durch das Werkzeug auf eine gewisse Formalisierung nicht verzichtet werden kann. Koordinationsgegenstand: Dieses Kriterium beschreibt, welche Klassen von Objekten Gegenstand der Koordination sein können. Die aufgeführten Klassen entsprechen der in Abschnitt 2.2.7 aufgeführten Liste von Kooperationsgegenständen. Jede Koordination kann eine beliebige Kombination dieser Gegenstände zum Inhalt haben. In Tabelle 3-2 sind die Koordinationsgegenstände durch ihre Anfangsbuchstaben abgekürzt (S: Kooperationsstruktur, Z: Ziele, P: Pläne, Ro: Rollen, Re: Ressourcen, E: Ergebnisse). Anzahl Benutzer: Dieses Kriterium beschreibt, wieviele verschiedene Benutzer direkt mit dem Werkzeug arbeiten. Einbenutzerwerkzeuge dienen z.B. der Koordination von Arbeitsgruppen durch eine übergeordnete Person (Chef). Bei Mehrbenutzersystemen kann unterschieden werden, ob sie eine festgelegte (n) oder beliebige (? 1) Zahl von Benutzern verlangen und ob sie auch von einer Einzelperson genutzt werden können (? 1) oder nur für den Mehrbenutzerbetrieb geeignet sind (> 1). Rollen: Dieses Kriterium unterscheidet, ob Benutzern verschiedene Rollen zugeordnet werden oder nicht. Die beiden folgenden Kriterien spielen also nur eine Rolle, wenn tatsächlich Rollen verwendet werden. Rollenbezug: Die Unterscheidung verschiedener Rollen kann die Beziehung eines Subjekts zu verschiedenen anderen Einheiten beschreiben. Objektrelevante Rollen differenzieren Subjekte bezüglich ihres Verhältnisses zu den in der Koordination betrachteten Objekten. Aufgabenrelevante Rollen unterscheiden zwischen verschiedenen Aufgaben, die den Subjekten zugewiesen werden. Teamrelevante Rollen beschreiben das Verhältnis der Subjekte untereinander (vgl. Abschnitt 2.2.2). Das Vorhandensein teamrelevanter Rollen bedeutet meist, daß ein Subjekt andere Subjekte als Objekt betrachtet. In einem System können mehrere dieser Rollentypen gleichzeitig auftreten, die unabhängig voneinander Subjekten zugewiesen werden. Die Ausprägungen des Kriteriums Rollenbezug sind also beliebige Kombinationen der drei Rollentypen. Rollenzuordnung: Rollen können den Benutzern fest zugeordnet werden oder im Laufe der Interaktion mit dem Werkzeug wechseln. Bei dynamisch wechselnden Rollen kann evtl. noch zwischen eher langfristigen und eher kurzfristigen Rollenzuordnungen unterschieden werden (vgl. Abschnitt 2.2.7). 3.3 Kooperation Um kooperativ arbeiten zu können, muß es möglich sein, die Aktionen der Kooperationspartner zu koordinieren. Daher sind Koordinationswerkzeuge, wie sie im letzten Abschnitt beschrieben wurden, stets die Grundlage für kooperative Arbeitssysteme. Koordination kann bezüglich der 3.3 Kooperation 39 koordinierenden und koordinierten Subjekte in verschiedenen Modi ablaufen (wie bereits in den Abschnitten 2.2.7 und 3.2 erwähnt): Ein Subjekt kann seine eigenen Aktionen koordinieren; ein Subjekt kann in einem hierarchischen Szenario die Aktionen einer Arbeitsgruppe koordinieren; eine Arbeitsgruppe kann ihre eigenen Aktionen koordinieren. Werkzeuge zur Kooperationsunterstützung können daher als Koordinationswerkzeuge betrachtet werden, die auf die Verwendung durch kooperierende Benutzer im dritten der genannten Modi ausgelegt sind. 3.3.1 Basismechanismen zur Kooperation Die einzelnen Funktionalitäten von Kommunikations- und Koordinationswerkzeugen, die auf kooperatives Arbeiten zugeschnitten sein müssen, werden teilweise in [NPR92] genannt: - Die Datenverwaltung muß auf kooperativen Zugriff ausgelegt sein. Die wesentlichen Aspekte hierzu sind in [GrSa87] zusammengefaßt. Eine ausführliche Sammlung erweiterter Transaktionskonzepte, die teilweise kooperatives Arbeiten unterstützen, stellt [Elma92] dar. - Zugriffskontrolle kann unterstützt werden durch die Kontrolle von Operationen auf abstrakten Datentypen und durch Rollenzuweisung an Benutzer, verknüpft mit Bedingungen für die Ausführbarkeit abstrakter Operationen. - Herkömmliche Verfahren zur Benutzersynchronisation wie Transaktionsmechanismen und Sperrverfahren müssen an das kooperative Umfeld angepaßt werden, in dem normalerweise schwächere Konsistenzbedingungen herrschen. Konsistenzbedingungen sind dann nicht mehr an Lese- und Schreiboperationen auf einfachen Datenobjekten geknüpft, sondern anwendungsspezifisch für abstrakte Datentypen und deren Operationen definierbar. - Die Verfahren zur Verwaltung der Änderungsgeschichte und zum Rücksetzen fehlgeschlagener Operationen müssen an die Gegebenheiten des kooperativen Zugriffs angepaßt werden. Zum Beispiel muß beim Rücksetzen unterschieden werden, wer die zurückzusetzende Operation ausgeführt hat. Ebenso ist es sinnvoll, den Benutzern die Änderungsgeschichte zugänglich zu machen (s. [Chiu92]). - Der Aspekt der Verwaltung des koordinierten Teams muß dahingehend ausgebaut sein, daß das Team sich selbst verwaltet. Zur Koordination der eigentlichen Aufgaben der Teammitglieder kommt also noch die Koordination ihrer Interaktion mit dem Werkzeug und ihrer Koordinationsaufgaben. Teile dieser Funktionalität sind in den Sitzungsverwaltungen der verschiedenen Kooperationsplattformen enthalten (z.B. [DeFr92]). 40 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation - Die Koordination kooperativ ausgeführter Aktivitäten durch das jeweils ausführende Team selbst kann zu einer hierarchischen Struktur aus Teilaktivitäten und den dazu nötigen Koordinationen führen, die weitgehend unabhängig voneinander ablaufen. Zusätzlich können die nicht innerhalb der Kooperation ablaufenden Aktivitäten der Teammitglieder integriert mit den kooperativen Aktivitäten verwaltet werden (vgl. Abschnitt 3.4). Ein Ansatz in diese Richtung findet sich in [Busb93]. 3.3.2 Beispiele für Kooperationswerkzeuge Im Folgenden sollen einige Beispiele für Anwendungen bzw. Plattformen beschrieben werden, die kooperatives Arbeiten unterstützen: - Werkzeuge zur gemeinsamen Nutzung von Einbenutzeranwendungen (Application Sharing Tools) stellen die Ausgaben einer Anwendung allen Benutzern zur Verfügung und steuern das Eingaberecht, das zu jedem Zeitpunkt genau ein Benutzer haben kann. Die gemeinsam benutzte Anwendung stellt im Prinzip ein Kommunikationsobjekt dar. Das Werkzeug liefert dazu noch Kooperationsfunktionalität zur Team- und Sitzungsverwaltung, wie z.B. dynamische Veränderung der Teamzusammensetzung und Weitergabe des Eingaberechts. Diese Funktionen sind speziell auf Kooperation ausgelegte Koordinationsfunktionen. Ein Beispiel für ein derartiges Werkzeug beschreibt [DeFr92]. - Das Konzept eines gemeinsamen Arbeitsbereiches (Shared Workspace) stellt den Benutzern die Abstraktion beliebiger gemeinsam zugänglicher Objekte zur Verfügung. Diese Objekte können als Kommunikationsobjekte aufgefaßt werden. Der gemeinsame Arbeitsbereich synchronisiert die gleichzeitigen Zugriffe der Benutzer (Mikrokoordination). Auch hier sind zusätzliche Kooperationsfunktionen wie Team- und Sitzungsverwaltung notwendig. Konzept und Architektur eines solchen gemeinsamen Arbeitsbereichs wurde in [SeRo93] beschrieben. - Design Datenbanken erweitern die auf konkurrierende Benutzer ausgelegte herkömmliche Datenbankfunktionalität um kooperationsbedingte Funktionen. Der Schwerpunkt liegt dabei auf der Erweiterung der Transaktionssemantik, so daß die Benutzer auf Zwischenergebnisse der Transaktionen ihrer Kooperationspartner zugreifen können. Beispiele für solche Systeme findet man in [NRZ92] und [Chiu92]. 3.4 Unterstützung für menschliche Subjekte 41 3.3.3 Architekturaspekte für Kooperationswerkzeuge Zur Realisierung der beschriebenen Werkzeuge sind die folgenden Architekturaspekte zu beachten: Werkzeugarchitektur: Das Werkzeug kann einer Benutzergruppe eine zentrale Anwendung mit ihren Daten zur Verfügung stellen (zentrale Architektur), es kann Anwendung und Daten bei den Benutzern replizieren (replizierte Architektur), verschiedene unabhängige Anwendungen können zu einem kooperativen System verknüpft werden (verteilte Architektur). Außerdem sind beliebige Mischformen der drei Architekturen denkbar (hybride Architektur). Kooperationstransparenz: Das Wissen über die Interaktion mehrerer Subjekte bezüglich einer Kooperation kann in die Anwendung integriert sein (cooperation aware) oder durch eine Kooperationsschale vor der Anwendung verborgen werden (Cooperation unaware). 3.4 Unterstützung für menschliche Subjekte Die in den letzten Abschnitten geschilderten Werkzeuge bieten Unterstützung für den zwischen Subjekten stattfindenden Teil von Kooperationen. Jedoch erhöht sich die Komplexität durch eine Kooperation auch im privaten Bereich des Subjektes, so daß auch dort unterstützende Mechanismen erforderlich sind (vgl. Tabelle C-5). Diese betreffen zum einen die Darstellung der durch Kooperationen erheblich ansteigenden Datenflut gegenüber dem Subjekt entsprechend seiner persönlichen Wünsche unter Berücksichtigung der zur Verfügung stehenden Ressourcen. Bezüglich dieser Daten ist zu unterscheiden zwischen kooperationsweiten und privaten Verwaltungs- und Anwendungsdaten, die in den drei Schichten Kommunikation - Koordination - Kooperation anfallen. Bei externen Daten sind - je nach Heterogenität der Subjekte und verwendetem Kommunikationswerkzeug - möglicherweise Sprachkonvertierungen erforderlich (vgl. die in [Wong93] geschilderte Verwendung einer globalen Sprache und entsprechender Übersetzungsmechanismen oder die Beschreibungen auf einem Metalevel im Zusammenhang mit der Reflexion von Subjekten wie in [FeCa91]). Transformationen auf einer höheren semantischen Ebene kommen ins Spiel, wenn die durch das Kommunikationsmedium vorgegebenen Hardwareressourcen nicht zur Verfügung stehen. Wenn z. B. für die Ausgabe von Multimediadaten nur ein Faxgerät zur Verfügung steht, müssen die Daten entsprechend umgewandelt werden. So verwendet z. B. [Robi94] Konversionsmechanismen zur Behandlung unterschiedlicher Kommunikationsmedien. 42 3 Klassifikation von Werkzeugen zur rechnergestützten Kooperation Um den Umfang der Daten einigermaßen beherrschen zu können, können Empfängerfilter eingesetzt werden. Wenn der Benutzer dem System gegenüber seine Interessen definieren kann, ist es möglich, unwesentliche Information auszusortieren. Durch Verwendung von Gewichtungen sind dabei unterschiedliche Abstufungen möglich. Je nach momentaner Arbeitslast des Benutzers kann er sich also auf die Anzeige der wichtigsten Informationen beschränken oder sich beliebig viele weitere Informationen zeigen lassen. Wenn man sich die Vielfalt der im Zusammenhang mit Kooperationen entstehenden Daten vergegenwärtigt, so gewinnt die Forderung nach einer übersichtlichen Darstellung nicht nur bezüglich der Quantität sondern auch bezüglich der Qualität ein besonderes Gewicht. So muß die Zugehörigkeit der dargestellten Daten zu den unterschiedlichen Bereichen privat - öffentlich, zu den Mitgliedern des Teams dieser oder jener Kooperation, zu Verwaltung oder Anwendung gut ersichtlich sein. Möglichkeiten dazu sind z. B. unterschiedliche Farben oder Symbole für unterschiedliche Bereiche. Ein weiterer Aspekt betrifft die Semantik der dargestellten Daten. Gemäß [Rü93] können Zustandsänderungen von Objekten entweder semantikerhaltend, syntaxerhaltend oder lediglich deskriptiv bei den Kommunikationspartnern angezeigt werden (vgl. auch Multimedia-Mail- Kommunikation wie z. B. [MSS93] oder die unterschiedlich ausführlichen Konfliktmeldungen gemäß Abschnitt 3.2.1). Außer diesen Darstellungsaspekten ist eine Unterstützung z. B. beim Umschalten zwischen den unterschiedlichen Benutzeraktivitäten oder beim Ein- bzw. Ausgliedern in/aus Teams erforderlich (vgl. Abschnitt 2.2.2). Auch hierbei lassen sich wieder Gewichtungen verwenden, die angeben, mit welcher Dringlichkeit an einer bestimmten Kooperation (vgl. [Rang93]) oder privaten Aktivität zu arbeiten ist. In diesem Zusammenhang bietet sich eine private Koordination an, wie sie in [PYF+92] und [Busb93] beschrieben wird (vgl. Abschnitt 3.3.1). 3.5 Ergebnisse der Klassifikation Die obige Klassifikation zeigt, daß in heute verfügbaren Werkzeugen noch keine durchgehende Kooperationsunterstützung gewährleistet ist. Vor allem zwischen Werkzeugen aus dem Bereich CSCW und VKI-Systemen bestehen beträchtliche Unterschiede in der Kooperationsunterstützung. CSCW- und VKI-Systeme benutzen häufig unterschiedliche Kommunikationsformen, die teilweise durch die jeweils beteiligten Subjekte bestimmt sind. Die Peer-to-Peer Kommunikation 3.5 Ergebnisse der Klassifikation 43 in VKI-Systemen unterstützt die relativ starre Teamstruktur mit überwiegend klar definierten Aufgabenbereichen. Dagegen bietet sich für CSCW-Systeme mit dynamisch veränderlichen Teams die Kommunikation über Shared Workspaces u.ä. an. Ein übergeordnetes Modell, das beide Ansätze verbindet, fehlt großteils. Im Bereich der Koordinationsunterstützung wird der Unterschied zwischen CSCW- und VKI- Systemen sehr deutlich. VKI-Systeme legen sehr großen Wert auf Koordinationsunterstützung, da die wesentliche Aufgabe maschineller Agenten darin besteht, ihre Aufgaben koordiniert abzuarbeiten. Demgegenüber ist die Koordinationsunterstützung in CSCW-Systemen meist nur rudimentär vorhanden, indem die Benutzer dabei unterstützt werden, die durch Kooperation gestiegene Systemkomplexität zu beherrschen. Die Kooperation als solche scheint weniger gut durch Werkzeuge unterstützbar zu sein. Bisherige Kooperationswerkzeuge im Bereich CSCW sind eigentlich Kommunikations- und - in eingeschränktem Maße - Koordinationswerkzeuge, die auf kooperative Nutzung ausgelegt sind. Die bisherige Diskussion beschränkt sich mehr oder weniger auf die Untersuchung unterschiedlicher Architekturen für Kooperationsplattformen und die Unterscheidung kooperativer und kooperationstransparenter Anwendungen. Einige Ansätze im Design-Bereich beschäftigen sich zusätzlich mit Problemen der Datenverwaltung (Synchronisation, Protokollierung, Rücksetzen) in kooperativen Systemen. Die Unterstützung menschlicher Subjekte im Rahmen kooperativer Arbeitssysteme stellt sich mit zunehmender Größe dieser Systeme als wesentliche Funktionalität heraus, die jedoch bisher nur ansatzweise untersucht wurde. 44 4 Ein universelles Modell zur Rechnerunterstützung Um die in Abschnitt 2.2.10 aufgelisteten Mängel beheben zu können, soll zunächst ein universelles Modell erstellt werden, das alle für eine Rechnerunterstützung benötigten Aspekte integriert. Dieses Modell enthält die folgenden Elemente: - Subjekt, Rolle und Rolleninstanz, - Objekt, Aktivität, - Ziel, Teilziele, - Kommunikation, - Koordination, - Kooperation, Kooperationskontext. Im Folgenden werden diese Elemente im einzelnen beschrieben. SUBJEKT ist eine aktiv handelnde Einheit, beispielsweise eine Person (ggf. vertreten durch maschinelle Agenten), eine Organisation oder eine Gruppe von Subjekten (vertreten durch Personen oder maschinelle Agenten). Es sind also unterschiedliche Abstraktionsebenen zugelassen. Ein Subjekt verfügt über eine Menge von Zielen. Neben diesen Grundelementen eines einfachen Subjektmodelles kann ein Subjekt über Rollen verfügen. Es ist Eigentümer oder Mitbenutzer von Objekten. Da Zugriff auf Objekte Wissen bedeutet, läßt sich durch Hinzufügen oder Wegnehmen von Objekten ein beliebig komplexes Subjektmodell erzeugen. Das durch Objekte verfügbare Wissen kann a priori existieren oder durch Kommunikation erworben werden. ROLLE stellt einen Platzhalter für Aufgaben, Rechte, Pflichten, Eigenarten usw. eines Subjekts in einer Kooperation dar. Dieser ist je nach Anwendung auszufüllen. ROLLENINSTANZ dient der Konkretisierung einer Rolle und wird durch bestimmte Aufgaben, Rechten, Pflichten, Eigenarten usw. definiert und kann zu einem oder mehreren Subjekten in Beziehung gesetzt werden. Die entsprechenden Subjekte erhalten dann die durch die Rolleninstanz definierten Eigenschaften. Nach Abschnitt 2.2.2 lassen sich bei Rolleninstanzen team-, aufgaben- und objektrelevante Ausprägungen unterscheiden. OBJEKT ist eine passive Einheit, die einem oder mehreren Subjekten zugänglich ist. Objekte können temporär oder permanent existieren. Sie haben einen Zustand, der durch Aktivitäten manipuliert werden kann (Erzeugen, Vernichten, Zustand ändern). Wie bereits erwähnt, bedeutet der Zugriff auf ein Objekt Wissen. 45 AKTIVITÄT wird durch ein Subjekt initiiert. Sie operiert auf Objekten und kann deren Zustand ändern. Aktivitäten können aus Einzelaktivitäten zusammengesetzt sein. ZIEL bezieht sich auf eine Menge von Objekten und beschreibt einerseits die gewünschten Zustände dieser Objekte und andererseits die Regeln zur Bewertung dieser Zustände. Die Menge der Zustände kann durch eine Bedingung beschrieben werden. Ziele werden durch Aktivitäten erreicht. Da möglicherweise mehrere Aktivitäten zum gleichen Ziel führen, definieren Ziele Äquivalenzklassen von Aktivitäten. Eine Bewertung kann entweder nur entscheiden, ob das Ziel erreicht wurde oder nicht, oder es wird auch bewertet, wie gut das Ziel erreicht wurde. Spezielle Ziele sind: 1. Das Kooperationsziel (Gesamtziel) wird von den Beteiligten einer Kooperation angestrebt und ist entweder - eine Zustandsmenge, deren Erreichen die Kooperation beendet oder - eine permanent aufrechtzuerhaltende Zustandsmenge. 2. Teilziel ist ein durch Koordination von Subjekten abgestimmtes Ziel, welches keinen Endzustand einer Kooperation beschreibt. Die Abstimmung von Teilzielen kann zur Abstimmung von Synchronisationspunkten verwendet werden, d.h. von Punkten, an denen die Aktivitäten der Subjekte neu abgestimmt werden. 3. Subjektive (Teil-) Ziele entstehen aus der Abwägung des Subjektes zwischen individuellem Nutzen zum Aufwand, das Kooperationsziel zu erreichen. Subjektive (Teil-)Ziele sind kein Teil der Kooperation. KOMMUNIKATION zwischen Subjekten erfolgt durch Manipulation von Objekten, die einer bestimmten oder einer beliebigen Menge von Subjekten zugänglich ist. Damit wird einerseits die Kommunikation mit direkter Adressierung und explizitem Nachrichtenaustausch abgedeckt, da Nachrichten gemeinsam zugängliche, temporäre Objekte sind. Andererseits ist auch die Kommunikation mit anonymer Adressierung in der Definition enthalten. Der Begriff der Kommunikation wird außerdem so weit gefaßt, daß auch eine anfängliche Information eines Subjektes von außen (häufig als Konfiguration bezeichnet) mit eingeschlossen wird. Damit ist Kommunikation bei jeder Form von Koordination oder Kooperation involviert und die unterschiedlichen Ausprägungen lassen sich unter einer einheitlichen Sicht zusammenfassen. KOORDINATION kann ein einzelnes Subjekt für sich selbst vornehmen oder sie kann zwischen Subjekten erfolgen, wobei Kommunikation erforderlich ist. Es ist eine beliebige Koordi- 46 4 Ein universelles Modell zur Rechnerunterstützung nationsstruktur zugelassen (hierarchisch oder lateral). In jedem Fall dient die Koordination der Abstimmung von Teilzielen oder Zielen, d.h. der Vorgabe der zu erreichenden Zustände für eine Menge von Objekten, sowie der dazu gehörigen Überwachung. Dabei müssen die Aktivitäten zur Erreichung dieser Zustände (z.B. ?Arbeitsplan? mit Vorgabe der Funktionen für die zu erreichenden Zustandsübergänge) nicht vorgegeben werden, sind aber trotzdem aufgrund der obigen Definition von Zielen als Äquivalenzklassen von Aktivitäten automatisch in der Definition von Koordination enthalten. D.h. ein Teilziel kann auch durch die Aktivitäten definiert werden, durch die es erreicht wird. Die Abstimmung der Teilziele beinhaltet sowohl deren Definition (z.B. Auswahl beteiligter Objekte) als auch ihre Zuweisung zu bestimmten Rolleninstanzen und zu Subjekten. Möglicherweise kann auch ein Zeitintervall festgelegt werden, in dem das Teilziel erreicht werden soll. Die Grenze zwischen Kommunikation und Koordination ist nicht immer leicht zu ziehen, da Kommunikationswerkzeuge in verschiedenem Maße um Funktionen erweitert werden können, die der Koordination zuzuordnen sind. Andererseits benötigt auch die Kommunikation selbst koordinierende Funktionen, um den Zugriff auf die Kommunikationsobjekte zu regeln. Unterschieden werden kann nach den beteiligten Rolleninstanzen (s. o.). Damit läßt sich Koordination in objektorientierte, aufgabenorientierte und teamorientierte Funktionen aufteilen. Objektorientierte Koordination ist für korrekte Zugriffe auf die Kommunikationsobjekte zuständig, ohne die Inhalte der Objekte zu betrachten; sie wird im vorliegenden Modell der Kommunikation zugeordnet. Demgegenüber ist für die aufgabenorientierte Koordination, die sich mit den zu koordinierenden Aktivitäten beschäftigt, ein inhaltliches Verständnis der Kommunikationsobjekte nötig. Im vorliegenden Modell sollen unter Koordination nur der aufgabenorientierte und teamorientierte Teil verstanden werden. Wie bereits erwähnt (Abschnitt 2.2.7), wird in [Rü93] eine ähnliche Unterscheidung zwischen Mikro- und Makrokoordination eingeführt. Bezüglich der weiteren, in 2.2.7 genannten Koordinationsaspekte wie Zeitpunkt, Detaillierungsgrad und Gültigkeit werden keinerlei Einschränkungen vorgenommen. Eine Koordination kann also zu jedem beliebigen Zeitpunkt beliebig detailliert und für jeden beliebigen Zeitraum eingesetzt werden. Koordinationen können sowohl im Rahmen als auch außerhalb von Kooperationen verwendet werden. Außerhalb von Kooperationen erfolgt der die Koordination beinhaltende Kontrollfluß zwischen Subjekten nur in einer Richtung (z.B. Befehle), während er im Rahmen von Kooperationen grundsätzlich in beiden Richtungen erfolgt (Abstimmungen). KOOPERATION läßt sich charakterisieren durch: 47 - Beziehungen zu Zielen, - beteiligte Subjekte, - verwendete Koordinationstypen, - Kooperationsstruktur, - Behandlung von Konflikten, - Protokollierung. Mehrere Subjekte, d.h. mindestens zwei, kooperieren, um ein gemeinsames, u.U. abstraktes Ziel, das Kooperationsziel zu erreichen. Dazu stimmen sie zum einen anhand von Koordinationen die zur Erreichung dieses Zieles benötigten Teilziele ab und führen zum anderen auf Objekten Aktivitäten aus, die der Erreichung der abgestimmtenTeilziele dienen. Dieser Vorgang kann sich wiederholen. Die koordinierte Arbeit kann demzufolge als hierarchischer Baum aus Koordinationsinstanzen und Aktivitäten zur Erreichung von Teilzielen verstanden werden. Die Anzahl, Reihenfolge und Abhängigkeiten zwischen den einzelnen Koordinations- und Aktivitätsphasen müssen jedoch nicht a priori festgelegt sein. Außerdem kann es zu einem Wechsel zwischen Koordinationsphasen und Arbeitsphasen kommen, oder Koordination und Aufgabenerfüllung laufen echt parallel. Dabei bezieht sich die Koordination nicht nur auf die Aufteilung der Aufgaben, sondern auch auf deren permanente Beobachtung bzw. Überwachung. Insgesamt besteht die Kooperation also aus der gemeinsamen Definition des Ziels und aus der nachfolgenden koordinierten Arbeit in Richtung auf dieses Ziel (s. Bild 4-1). Im einzelnen sind folgende Kooperationsphasen beteiligt: Bild 4-1 : Zusammenhang Kooperation und Koordination Kooperation Koordination A1 A2 A3 Koordination A11 A12 A13 48 4 Ein universelles Modell zur Rechnerunterstützung 1. Motivation: Warum wird eine Kooperation eingegangen? Mögliche Gründe dafür sind ein externer Anstoß oder Subjektziele, die nicht Teil der Kooperation sind. Kooperation kann die Erreichung der subjektiven Ziele ermöglichen, vereinfachen oder kostengünstiger machen, beruht also auf einer Mangelsituation im Zusammenhang mit der Zielerreichung. Da zwischen den subjektiven Zielen Konflikte bestehen können, sind möglicherweise Verhandlungen bei der Festlegung des Gesamtzieles erforderlich. 2. Durchführung bis Kooperationsziel erreicht 3. Bewertung des Erfolgs der Kooperation bezüglich des Kooperationszieles 4. Bewertung der Erreichung der Subjektziele Jedes Subjekt kann mehrere Kooperationen eingehen, ohne daß alle beteiligten Subjekte untereinander kooperieren müssen. Es können aber Abhängigkeiten jeglicher Art zwischen verschiedenen Kooperationen bestehen (z.B. Reihenfolgebeziehungen, Überschneidungen bei beteiligten Subjekten; vgl. auch die unterschiedlichen Kooperationen im Zusammenhang mit Fußballspielen wie in Abschnitt 2.1 erläutert). KOOPERATIONSKONTEXT beschreibt die Menge aller betrachteten Subjekte, Objekte und Aktivitäten einer Kooperation. Das eben beschriebene, universelle Kooperationsmodell läßt sich nach den in Abschnitt 2 definierten Klassifikationskriterien folgendermaßen einordnen: Subjektmodell Beliebig komplex konfigurierbar Teammodell Als Teil des Kooperationskontextes beliebig definierbar Zielmodell Über Objektzustände definiert Aktivitätenmodell Bewirken Zustandsänderungen von Objekten Objektmodell Allgemein Kommunikationsmodell Umfaßt alle kooperativen Kommunikationsaspekte Koordinationsmodell Umfaßt alle kooperativen Koordinationsaspekte Kooperationsmodell Umfaßt alle Kooperationsaspekte Tabelle 4-1 : Einordnung des universellen Modelles 49 5 Anforderungen an ein universelles, kooperationsunterstützendes Werkzeug Aus den betrachteten Modellen und Werkzeugen wird deutlich, daß bisher noch kein universelles Kooperationswerkzeug existiert, das sowohl die Kooperation zwischen Menschen als auch zwischen maschinellen Agenten unterstützt. Besonders im Bereich der maschinellen Agenten sollte die Trennung in Kooperationswerkzeug- und Agentenfunktionalität die Systemstruktur vereinfachen. Anhand der bei der Werkzeugklassifikation in Abschnitt 3 gefundenen Designkriterien und anhand des in Abschnitt 4 aufgestellten allgemeinen Modells werden im Folgenden die Anforderungen an ein solches Kooperationswerkzeug aufgestellt. Dieses Werkzeug muß natürlich alle Funktionsbereiche (Kommunikation, Koordination, Kooperation und Subjektunterstützung) beinhalten. 5.1 Anforderungen an die Kommunikationsunterstützung Die im Modell in Abschnitt 4 über die Manipulation gemeinsamer Objekte definierte Kommunikationssemantik sollte so allgemein unterstützt werden, daß beliebige spezifische Kommunikationssemantiken realisierbar sind. Die Sichtbarkeit von Kommunikationsobjekten und Kommunikationsvorgängen muß flexibel spezifizierbar sein. Die verschiedenen, im morphologischen Kasten in Bild 3-3 dargestellten Ausprägungen von Kommunikationsbeziehungen sollten möglichst vollständig vom Werkzeug abgedeckt werden. 5.2 Anforderungen an die Koordinationsunterstützung Die in Abschnitt 3.2.1 beschriebenen Basismechanismen zur Koordination sollten so allgemein unterstützt werden, daß beliebige Koordinationsprotokolle spezifiziert und verwendet werden können. Besonders für menschliche Subjekte sind diese Protokolle in benutzeradäquater Weise anzubieten. Grundmechanismen zur Konfliktbehandlung sind anzubieten, die besonders bei menschlichen Subjekten bisher kaum in Werkzeugen vorgesehen werden. Die im morphologischen Kasten zur Koordination in Bild 3-4 dargestellten möglichen Ausprä- gungen von Koordinationen sollten von einem anpassungsfähigen Werkzeug abgedeckt werden. Insbesondere sollten alle aufgeführten Koordinationsgegenstände vom Werkzeug verwaltbar sein. Ein wesentlicher Aspekt hierbei ist die Meta-Koordination, d.h. die Verwaltung und Abstimmung der Koordinationsstruktur, die vor allem in kooperativen Szenarien eine wesentliche Rolle spielt. 50 5 Anforderungen an ein universelles, kooperationsunterstützendes Werkzeug Die Überwachung der koordinierten Aktivitäten sollte ins Werkzeug integriert sein. Hierzu sind flexible und dynamische Mechanismen zur Interaktion zwischen Koordination und Aktivitäten bereitzustellen. Hier sollte ein breites Spektrum von einmaliger Koordination ohne Überwachung über phasenweise Abwechslung von Koordination und Aktivitäten bis zu gleichzeitig stattfindender Aktivität und Koordination mit beliebigen Interaktionsmöglichkeiten angeboten werden (s. Abschnitt 4). Um Koordinationsentscheidungen nachvollziehbar zu machen, ist eine Protokollierung vorzusehen. Ein Rücksetzen von Koordinationsentscheidungen und gegebenenfalls Aktivitäten sollte ebenfalls vom Werkzeug unterstützt werden. 5.3 Anforderungen an die Kooperationsunterstützung Da Kooperation selbst weniger gut durch Werkzeuge unterstützbar zu sein scheint (s. Abschnitt 3.5), sollte ein universelles Werkzeug vor allem eine breite Palette der in Abschnitt 3.3.1 aufgeführten Basismechanismen zur Verfügung stellen. Bei der Teamverwaltung ist hier besonders auf die Berücksichtigung dynamisch veränderlicher Teams zu achten, die bisher in Agentensystemen kaum vorkommen. Zusätzlich zu diesen Mechanismen sollte Funktionalität zur Verwaltung und Überwachung von Kooperationszielen angeboten werden, die auch die subjektiven Ziele der Kooperationspartner miteinbezieht. Das Werkzeug sollte sowohl kooperationstransparente als auch kooperative Anwendungen unterstützen. Die Architektur sollte dabei an die Gegebenheiten der Arbeitsgruppe und der verwendeten Anwendungen anpaßbar sein. 5.4 Anforderungen an die Subjektunterstützung Die Subjektunterstützung wird sich für maschinelle und menschliche Subjekte sehr stark unterscheiden. Für menschliche Subjekte wird die Unterstützung sehr stark vom jeweiligen Anwendungsfall abhängen, so daß sich allgemeine Funktionen außer den in Abschnitt 3.4 beschriebenen schlecht definieren lassen. Für maschinelle Subjekte findet sich in der Literatur ein Beispiel für die Entscheidungsunterstützung bei unsicherem Wissen durch Kommunikationsverzögerungen (s. [BiPa93]). Um während dieser Zeit nicht handlungsunfähig zu sein, wird das Ergebnis mit Hilfe von Wahrscheinlichkeiten abgeschätzt. Diese Wahrscheinlichkeiten werden anhand eines stochastisch 5.4 Anforderungen an die Subjektunterstützung 51 lernenden Automaten unter Verwendung des tatsächlichen Antwortverhaltens ständig modifiziert. Weitere Mechanismen zur Entscheidungsunterstützung speziell in kooperativer Umgebung sind denkbar. 52 6 Zusammenfassung und Ausblick Wie die umfangreiche Literatur zum Thema des rechnerbasierten kooperativen Arbeitens zeigt, wird diesem Aspekt zunehmend Bedeutung beigemessen. Die vorliegende Arbeit liefert eine detaillierte Klassifikation bisheriger Modelle und Werkzeuge zur rechnergestützten Kooperation und zeigt deren Schwachstellen. Durch Verknüpfung von Aspekten aus den Bereichen CSCW und VKI konnte ein universelles Kooperationsmodell aufgestellt werden, das diese Schwachpunkte behebt. Außerdem wurde eine Reihe von Anforderungen herausgearbeitet, die an ein universelles Werkzeug zur rechnergestützten Kooperation zu stellen sind. Erreicht werden soll dadurch, daß Teams, die beliebig aus menschlichen und maschinellen Subjekten zusammengesetzt sein können, bei ihrer Zusammenarbeit unterstützt werden durch ein Werkzeug, das keine Anwendungs- sondern lediglich die kooperativen Aspekte berücksichtigt und dadurch universell eingesetzt werden kann. Wie bereits in Abschnitt 2.2.1 erwähnt, wird in diesem Zusammenhang nichts über die Eigenschaften maschineller Subjekte ausgesagt. Dementsprechend wird auch nicht entschieden, ob maschinelle Subjekte als gleichberechtigte Kooperationspartner betrachtet werden können. Derartige Fragen sind außerhalb einer Kooperationsunterstützung angesiedelt. Da durch die vorliegende Arbeit nur der Rahmen für zukünftige Untersuchungen abgesteckt werden konnte, verbleibt eine Reihe von offenen Fragen. So ist z. B. noch nicht vollständig geklärt, wie es überhaupt zu einer Kooperation kommt (geplant/zufällig), welche Motivation dahintersteckt (gemeinsame/individuelle Ziele, Nutzen) und ob alle beteiligten Subjekte das gleiche Verständnis von kooperativem Arbeiten haben, d.h. ob sie alle die gleichen ?Spielregeln? verwenden (bzw. welche Konsequenzen ein uneinheitliches Verständnis hat). In diesem Zusammenhang stellt sich auch die Frage nach der Definition und dem Sinn eines Kooperationsgrades (vgl. Abschnitt A.6). In den eingangs erwähnten Brainstorming-Sitzungen wurden folgende Möglichkeiten vorgeschlagen: - Grad des gemeinsamen Handelns - Grad der Kommunikation - Annehmlichkeit für Subjekt i (?Harmonie?) - Kosten-Nutzen-Vergleich mit und ohne Kooperation - Grad der Überdeckung Subjekt-/Kooperationsziele Ein weiterer Aspekt, der bisher nur angedacht aber nicht ausführlich untersucht wurde, ist die in [Velt93] erwähnte Interferenz mehrerer Kooperationen. 53 Noch nicht ausreichend behandelt sind außerdem die Beziehungen von Kooperationen zu Zielen und ihrer Bewertung. Im einzelnen sind dabei die folgenden Fragen zu untersuchen: - Ist die Konkretisierung des Gesamtziels eine Aktivität der Kooperation? - Wie werden Ziele und ihre Erreichung bewertet (Priorisierung)? - Wie beeinflussen Kooperationsbewertungen das zukünftige Kooperationsverhalten? - Wie invariant sind Teil- und Gesamtziele? - Gehört das gemeinsame Ziel in die Definition von Kooperation? Ein weiteres, noch nicht zufriedenstellend gelöstes Problem betrifft die Behandlung von Zielen und Aktivitäten. So sind zum gegenwärtigen Zeitpunkt weder Aussagen darüber, wie ein Gesamtziel in Teilziele zu seiner Realisierung umzusetzen ist (Dekompositionsproblem), noch darüber, wie Aktivitäten zur Erreichung eines Zieles zusammenzusetzen sind, allgemeingültig zu formulieren. Dieses Problem ist jedoch nicht kooperationsspezifisch. Beim Übergang vom Modell einer Kooperation zu einem rechnerbasierten, unterstützenden Werkzeug stellt sich die in [Grud88] behandelte Frage nach den Konsequenzen von Modellierungsfehlern. Insbesondere ist z. B. zu untersuchen, inwieweit sich menschliche Subjekte bei einer Konfliktbehandlung unterstützen lassen. Bezüglich des Werkzeuges selbst sind Probleme wie Verwaltung kooperationsrelevanter Daten, das Zurücksetzen von Kooperationen oder Formen der Subjektunterstützung für maschinelle Subjekte noch nicht zufriedenstellend gelöst. Insgesamt läßt sich feststellen, daß die menschliche Fähigkeit des kooperativen Arbeitens erst ansatzweise verstanden wird und sich daher bis jetzt auch nicht in größerem als dem in dieser Arbeit dargestellten Umfang unterstützen läßt. 7 Danksagung Wir danken Herrn Dr. W. Strommer für seine Anregung zu einer Diskussion über das Thema Kooperation. Weitere Diskussionsteilnehmer waren die Herren I. Barth, G. Dermler, M. Hamhaber, T. Helbig, E. Kovacs und T. Wahl. Ihnen allen sei für die Diskussionsergebnisse als Grundlage der vorliegenden Arbeit sowie für Hinweise bei der schriftlichen Ausarbeitung gedankt. Außerdem gebührt unser Dank Herrn Prof. Dr. K. Rothermel dafür, daß er die Durchführung dieser Arbeit an seinem Lehrstuhl ermöglicht und auch fachlich unterstützt hat. 54 Anhang A Weitere Beispiele In den erwähnten Brainstorming-Sitzungen wurden noch weitere Beispielszenarien untersucht, um die Eigenschaften kooperativer Vorgänge zu durchleuchten. Im Folgenden werden diese Beispiele nur kurz beschrieben. A.1 Weg zur Arbeit Betrachtet wird der Weg zweier Personen P1 und P2 zum jeweiligen Arbeitsplatz. Dabei gibt es die folgenden Möglichkeiten: - P1 und P2 haben keinen gemeinsamen Weg. - P1 und P2 haben ein Stück gemeinsamen Weges, kennen sich aber nicht. - P1 und P2 haben ein Stück gemeinsamen Weges, auf dem sie sich unterhalten oder zusammen einen PKW oder ein öffentliches Verkehrsmittel benutzen. Dabei ist möglicherweise eine Absprache nötig (gemeinsame PKW-Nutzung) oder nicht (z. B. einer der Beiden hat sich verspätet, der andere bittet den Busfahrer zu warten). - P1 und P2 haben ein Stück gemeinsamen Weges, kennen sich, sind aber verstritten, nehmen also bei einer Begegnung keinen Kontakt zueinander auf. Aus diesem Beispiel lassen sich mehrere Aspekte herauslesen. Zum einen kooperieren Personen nur unter bestimmten Voraussetzungen (Fall 3 der obigen Liste). Diese Kooperation kann mit oder ohne Absprache, d.h. mit oder ohne Koordination erfolgen. Untersucht man die Ziele der Personen, so stellt sich heraus, daß in allen Fällen, auch in denen ohne Kooperation, der Weg zum Arbeitsplatz zu bewältigen ist. Eine Kooperation wird eingegangen, um den Weg kurzweiliger oder bequemer zurücklegen zu können. Beide Ziele sind beiden Personen gemeinsam, aber nur das zweite führt zu einer Kooperation. A.2 Chef und Untergebener Ein Chef stellt einen neuen Mitarbeiter ein und weist ihm Aufgaben zur Bearbeitung zu. Er verfolgt dabei Ziele wie das einer Arbeitsentlastung und eines Machtzuwachses, möglicherweise resultierend in einem höheren Gehalt und Karrieresprung. Der neue Mitarbeiter seinerseits verspricht sich vom Eingehen des Arbeitsverhältnisses z. B. ein gutes Gehalt, die Möglichkeit einer Karriere und fachliche Befriedigung. Die Ziele der an einer derartigen Kooperation beteiligten A.3 Käufer und Verkäufer 55 Personen stimmen also im wesentlichen überein. Gemeinsam sollte auch das Kooperationsziel an sich sein, nämlich eine bezüglich eines oder mehrerer Projekte erfolgreiche Zusammenarbeit zwischen dem Chef und seinem Untergebenen. Bei entsprechend motivierten Personen bedeutet eine erfolgreiche Zusammenarbeit, daß der übergeordneten Abteilung, Firma, Nation oder der gesamten Menschheit ein Dienst erbracht wird. Voraussetzung für das Eingehen der Kooperation ist für beide ein positives Ergebnis einer Kosten-Nutzen-Abschätzung, die im Zusammenhang mit einer Vertragsaushandlung steht. Nach dieser Prozedur bearbeitet der neue Mitarbeiter die ihm zugewiesenen Aufgaben, solange er und sein Chef die im Arbeitsvertrag ausgehandelten Bedingungen einhalten. Im Fall eines Konfliktes kann es zu einer Kündigung kommen. Auch an diesem Beispiel zeigt sich, daß durchaus mehrere gemeinsame Ziele existieren können, die aber nicht alle unbedingt in eine Kooperation münden müssen. Außerdem lassen sich unterschiedliche Phasen einer Kooperation ablesen (Vertragsaushandlung, Aufgabenbearbeitung, Kündigung). Als weiterer Aspekt wird der unterschiedlicher Rollen eingeführt (Chef stellt ein und weist Arbeit zu, Untergebener führt Arbeit aus, beide können kündigen). Die Kosten-Nutzen-Abschätzung liefert als Ergebnis, inwieweit die individuellen Ziele mit dem Kooperationsziel übereinstimmen. A.3 Käufer und Verkäufer Ein potentieller Kunde betritt ein Geschäft, um einen bestimmten Gegenstand zu erwerben. Sowohl dieser mögliche Käufer als auch der Verkäufer haben das Ziel, daß der Gegenstand den Besitzer wechselt. Dagegen unterscheiden sich die individuellen Ziele: der Käufer möchte möglichst wenig bezahlen müssen, der Verkäufer möchte einen möglichst hohen Preis erzielen. Dieser Zielkonflikt kann durch eine Verkaufsverhandlung aufgelöst werden. Dies ist aber nicht notwendigerweise der Fall. Es besteht auch die Möglichkeit, daß keine Einigung über den Preis zu erreichen ist und damit auch das Kooperationsziel nicht erfüllt werden kann. A.4 Arbeiter in unterschiedlichen Firmen Angenommen, zwei Firmen kooperieren, z.B. liefert eine Firma Einzelteile, in der anderen werden diese zusammenmontiert. Neben der in den obigen Beispielen gezeigten Kooperation zwischen Menschen kann es also auch eine Kooperation zwischen Gruppen geben. Dazu ist es nicht 56 A Weitere Beispiele erforderlich, daß auch die einzelnen Gruppenmitglieder miteinander kooperieren (obwohl auch diese Möglichkeit einer Kooperation auf allen Hierarchiestufen von Firmen auftreten kann). A.5 Fußgängerampel Bei geeignet ausgelegter Ampeleinrichtung kann ein zweiter Fußgänger z. B. dank einer Lampe sehen, ob der erste, bereits wartende, den Knopf zur Umschaltung schon betätigt hat oder nicht. In diesem Fall wird an der gemeinsam benutzten Einrichtung implizit kooperiert. Der zweite Fußgänger muß den Knopf nicht betätigen und möglicherweise auch nicht so lange warten, falls die Ampel bereits `grün' zeigt, sogar überhaupt nicht. Ermöglicht wird diese implizite Kooperation durch allgemein bekannte Regeln. A.6 Nahrungsbeschaffung durch Büffeljagd oder durch Einkauf im Supermarkt Das Erlegen eines Büffels kann nur durch Zusammenwirken mehrerer Menschen erfolgen. Diese müssen sehr eng kooperieren, um ihr Ziel zu erreichen. Demgegenüber besteht ein Einkauf im Supermarkt im Hinblick auf eine direkte Kooperation lediglich aus der Bezahlung der ausgewählten Waren. An diesem Beispiel wurde die Definition eines Kooperationsgrades erwogen. Aufgrund der subjektiven Bewertung einer solchen Größe wurde dieser Gedankengang jedoch nicht weiter verfolgt. A.7 Brainstorming Bei den in der Einleitung erwähnten Sitzungen, die die Basis für den vorliegenden Bericht bildeten, gab es die folgenden Rollen: Protokollführer, Sitzungsleiter, Diskutierende. Alle Rollen rotierten unter den einzelnen Teilnehmern. Eine Erkenntnis aus dem Wechsel der Sitzungsleiter ist, daß der Sitzungsleiter sich an der Diskussion nicht aktiv beteiligen sondern nur steuernd eingreifen soll (d.h. der Sitzungsleiter muß den Problembereich überblicken). Die dadurch frei werdenden Kapazitäten könnten zur Übernahme der Protokollführung verwendet werden, da auch der Protokollführer nicht in die Diskussion verwickelt sein darf. 57 Anhang B Klassifikation von Kooperationsmodellen B.1 Subjektklassifikation B.2 Teamklassifikation Einfaches Subjektmodell Detailliertes Subjektmodell [Burk92], [MaCr90] , [KSS92] und [Rüde93], [RSVW94] [ALB92], [BoGa88], [BuSu92], [CKLM91], [DuMo91], [FiWi92], [Klei91], [ICM91], [Maze91], [PaTe91], [SHK+92], [ZlRo91] Tabelle B-1 : Komplexität des Subjektmodelles Initiator Beliebiger Teamteilnehmer Einladung [BePa93]: ?geschützte Gruppe? [Rang93] Anfrage (mit/ohne Prü- fung) [KaTa91] Beides [BePa93]: ?geschlossene Gruppe? [GSS+93] [KLL+93] Tabelle B-2 : Interne Teilnahmebedingungen Ohne Einschränkungen Mit Einschränkungen [BePa93]: ?offene Gruppe? [BePa93]: ?über Liste eingeschränkte Gruppe? Tabelle B-3 : Externe Teilnahmebedingungen 58 B Klassifikation von Kooperationsmodellen B.3 Klassifikation von Zielen Beschränkte Teamgröße Beliebige Teamgröße Variable Teamgröße [ZlRo91], [BiPa93] : 2 [KLL+93] : 10 - 15 [KMW91] [CJA94], [GSS+93], [KLL+93], [KaTa91], [Rang93] und [SeRo93] Tabelle B-4 : Teamgröße [GSS+93], [KLL+93], [KMW91], [Robi94], [Rüde93], [SHK+92] Tabelle B-5 : Räumliche und zeitliche Verteilung Menschliche und maschinelle Subjekte Wissen/ Fähigkeiten unterschiedlich Unterschiedliche Ressourcen Unterschiedliche CSCW- Anwendungen Unterschiedliche Kommunikation [LJS93], [Klei91], [PaTe91], [Rang93], [SHK+92] [FeCa91], [KCTL93], [Klei91], [MDS93], [PaTe91], [Wong93] CSCW [NPR92], [Robi94] [FeCa91], [LJS93], [Robi94], [Wong93] Tabelle B-6 : Heterogenität Objektrelevanz Aufgabenrelevanz Teamrelevanz Definierbar [Rüde93] [Rüde93] Verhalten [DuMo91] [Wong93] Rechte/Einschränkungen [BePa93], [GSS+93], [KLL+93] [BePa93], [DLC87], [DuLe91], [DuMo91] Tabelle B-7 : Rollendefinition Egoistische Ziele Altruistische Ziele [BiPa93] [LJS93] und [SRSF91] Tabelle B-8 : Globalität von Zielen B.4 Klassifikation von Aktivitäten 59 B.4 Klassifikation von Aktivitäten Optimierung von Metriken/ Utility- Funktionen Aufgabenbezogen Regeln Objektzustände Spezielle Definitionen [DuMo91], [SRSF91], [Velt93], [ZlRo91] [ALB92], [CKLM91], [FrRo94], [Klei91], [KMW91], [KSS92], [ICM91], [PaTe91], [SHK+92] [BuSu92], [FiWi92] [LJS93] [Burk92] Tabelle B-9 : Definition von Zielen Aufgabenerfüllung/Dienst Zustandsänderung Ressourcennutzung [ALB92], [CKLM91], [FiWi92], [Klei91], [KMW91], [KSS92], [ICM91], [Velt93] und [SHK+92] [MaCr90], [Rüde93], [ZlRo91] [CKLM91] Tabelle B-10 : Wirkung von Aktivitäten [DuLe91], [Haye93], [KCTL93], [Klei91], [LJS93], [MDS93], [PaTe91], [ZlRo91] Tabelle B-11 : Definition von Plänen 60 B Klassifikation von Kooperationsmodellen B.5 Klassifikation von Objektmodellen B.6 Klassifikation von Kommunikationsmodellen B.7 Klassifikation von Koordinationsmodellen Informationsträger Außerhalb der Rechnerwelt existierende Objekte (z. B. Roboter, Fahrzeuge) [BePa93], [BoGa88], [CKLM91], [GSS+93], [Klei91], [KLL+93], [KSS92], [NPR92], [OMS+92], [Robi94], [Rüde93], [Velt93] [BuSu92], [DuLe91], [DuMo91] Tabelle B-12 : Elementare Objektklassen Binäre Synchronität (synchron - asynchron) Kontinuierliche Synchronität [CKLM91], [NPR92], [Robi94] [AnCh92], [Rüde93] Tabelle B-13 : Synchronitätsformen Shared work space und zusätzliche Kanäle Multimediakommunikation [DuLe91], [KCTL93], [PaTe91] [BePa93], [OMS+92], [Robi94] Tabelle B-14 : Mehrere Kommunikationsmedien Statische Zuordnung Variable Zuordnung Dynamische Aushandlung Beliebige Zuordnung [MDS93] [KMW91] [KMW91] [SHK+92] Tabelle B-15 : Dynamik von Rollen B.7 Klassifikation von Koordinationsmodellen 61 Negative Interaktion Mehrfachbelegung von Ressourcen Verletzung einer beliebigen Bedingung Unterschiedliche Logik Anwendungsabhängiger Konflikt [DuMo91] [CKLM91] [KCTL93], [MDS93], [SRSF91] [Diaz92], [Wong93] [DuLe91], [LJS93] Tabelle B-16 : Definition von Konflikt Koordinationsstruktur Ziele Pläne Rollenverteilung Ressourcenbelegung Zusammenführung von Ergebnissen [BoGa88], [DuLe91], [BoGa88], [SHK+92] [ALB92], [BoGa88], [CKLM91], [DuLe91], [DuMo91] [FrRo94], [MDS93], [LJS93], [MaCr90], [SHK+92], [ZlRo91] [BoGa88], [Burk92], [GSS+93], [Klei91], [KLL+93], [Rüde93], [SHK+92] [ALB92], [BoGa88], [SRSF91] [BoGa88], [DLC87], [DuLe91] Tabelle B-17 : Koordinationsgegenstände 62 B Klassifikation von Kooperationsmodellen B.8 Unterstützte kooperative Anwendungen Elektronischer Terminkalender Konferenzsysteme Strukturierte Konversationen und Büroinformationssysteme Kooperative Editoren Kooperatives Systemdesign und Software-Management Spiele [GrSa87], [Rüde93] [GSS+93], [LJS93], [OMS+92], [Rüde93] [Busb93], [GKM93], [KRW90], [KSS92], [Rüde93], [SHK+92] [GSW92], [KLL+93], [OMS+92], [SHK+92] [DeRi93], [WoSr93], [NRZ92] [Rüde93] Tabelle B-18 : Anwendungen im Bereich CSCW Theorembeweiser Verteilte Interpretation, Planung Leitsystem für Straßenverkehr Management für Telefonnetze Job-Shop Scheduling [ICM91] [DLC87], [DuLe91], [KCTL93], [vMar92] [BuSu92] [Velt93] [BiPa93], [SRSF91] Tabelle B-19 : Anwendungen im Bereich VKI Roboter und fahrerlose Transportsysteme Fertigungsleitstand [DLC87], [DuLe91], [DuMo91], [FiWi92], [FrRo94], [MDS93] [ALB92], [PaTe91] Tabelle B-20 : Anwendungen im Bereich Robotersysteme und Fabrik der Zukunft 63 Anhang C Klassifikation von kooperationsunterstützenden Werkzeugen C.1 Kommunikation C.2 Koordination Nachrichten-kommunikation Shared Workspace Blackboardkommunikation [BuSu92], [CKLM91], [DLC87], [DuMo91], [FiWi92], [ICM91], [KSS92], [ICM91], [MDS93], [PaTe91], [SHK+92], [Velt93], [ZlRo91] [GSS93], [KMW91], [PaTe91], [Rüde93], [SeRo93] [ALB92], [Klei91], [Maze91], [MDS93] und [SHK+92] Tabelle C-1 : Kommunikationsformen Remote Procedure Call Active Messaging/ Computational Mail Commutative Act [AnCh92] [Bore92] [Wong93] Tabelle C-2 : Low-Level Koordination Master-Slave Contract-Net Contract-Net mit Counterproposing Multistage- Negotiation Beliebige Protokolle [AnCh92], [FeCa91], [FiWi92], [MDS93] [KSS92], [ICM91], [PaTe91], [Wong93] [DuLe91] [CKLM91] [BuSu92], [SHK+92], [Wong93] Tabelle C-3 : Koordinationsprotokolle für Aufgabenverteilung Functionally Accurate and Complete Preference-based Negotiation [DLC87], [DuLe91] [Wong93] Tabelle C-4 : Koordinationsprotokolle für Ergebniszusammenführung 64 C Klassifikation von kooperationsunterstützenden Werkzeugen C.3 Subjektunterstützung Empfängerfilter Präsentation Verwaltung [BePa93], [NPR92], [PYF+92], [RKGB92] [PaTe91] [Rang93] Tabelle C-5 : Subjektunterstützung 65 Literaturverzeichnis [Alba92] S. Albayrak. TURBOKOM-Projekt: Blackboard-DEC. Künstliche Intelligenz, (1):64 ? 68, März 1992. [AnCh92] D. P. Anderson, P. Chan. COMET: A Toolkit for Multiuser Audio/Video Applications. In International Conference on Distributed Computing Systems, S. 555 ? 562, Juni 1992. [BDH+93] I. Barth, G. Dermler, M. Hamhaber, T. Helbig, E. Kovacs, F. Sembach, W. Strommer, T. Wahl. Koordinationsgespraech "Kooperativ". August bis Oktober 1993. [BePa93] S. Benford, J. Palme. A standard for OSI group communication. Computer Networks and ISDN Systems, (25):933 ? 946, 1993. [BeRa91] M. Bearman, K. Raymond. Federating Traders: An ODP Adventure. International IFIP Workshop on Open Distributed Processing, Oktober 1991. [BHI93] S.A. Bly, S.R. Harrison, S. Irwin. Media Spaces: Video, Audio, and Computing. Communications of the ACM, 36(1):28?47, Januar 1993. [BiPa93] E. A. Billard, J. C. Pasquale. Effects of Delayed Communication in Dynamic Group Formation. IEEE Transactions on Systems, Man, and Cybernetics, 23(5):1265 ? 1275, September/Oktober 1993. [BoFr93] N. Borenstein, N. Freed. MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC1521, September 1993. [BoGa88] A. H. Bond, L. G. Gasser. Readings in Distributed Artificial Intelligence. Morgan Kaufmann Publishers, 1988. [Bore92] N.S. Borenstein. Computational Mail as Network Infrastructure for Computer- Supported Cooperative Work. In CSCW '92 Proceedings, S. 67?74, November 1992. [Burk92] H.-D. Burkhard. Ein Formalismus für Multi-Agenten-Systeme. Künstliche Intelligenz, (1):17?21, März 1992. [Busb93] Uwe Busbach. Kooperation und Koordination in geographisch verteilten Organisationen. In K. Klöckner (Hrsg.), Groupware-Einsatz in Organisationen, GI-FG 2.0.1 ?Personal Computing? Symposium, number 220 in GMD-Studien, S. 81?94, Marburg, September 1993. [BuSu92] B. Burmeister, K. Sundermeyer. Domänen-unabhängiges Kooperatives Problemlösen. Künstliche Intelligenz, (1):12?16, März 1992. [Chiu92] Tzi-cker Chiueh. Papyrus: A History-Based VLSI Design Process Management System. PhD thesis, University of California at Berkeley, November 1992. [CJA94] G. Chung, K. Jeffay, H. Abdel-Wahab. Dynamic participation in a computer-based conferencing system. Computer communications, 17(1):7 ? 16, Januar 1994. 66 Literaturverzeichnis [CKLM91] S. E. Conry, K. Kuwabara, V. R. Lesser, R. A. Meyer. Multistage Negotiation for Distributed Constraint Satisfaction. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1462 ? 1477, November/Dezember 1991. [Croc82] D. Crocker. Standard for the format of ARPA Internet text messages. RFC822, August 1982. [DeFr92] G. Dermler, K. Froitzheim. JVTOS - A Reference Model for a New Multimedia Service. In Proceedings of the 4th IFIP Conference on High-Speed Networks, Liege, Belgium, Dezember 1992. [DeRi93] Prasun Dewan, John Riedl. Toward Computer-Supported Concurrent Software Engineering. IEEE Computer, S. 17?27, Januar 1993. [Diaz92] M. Diaz. A Logical Model of Cooperation. In Proceedings of the 3rd Workshop Future Trends of Distributed Computing Systems, S. 64?70, Taipei, Taiwan, April 1992. [DLC87] E. H. Durfee, V. R. Lesser, D. D. Corkill. Cooperation Through Communication in a Distributed Problem Solving Network. In M. N. Huhns (Hrsg.), Distributed artificial intelligence, S. 29?58. PITMAN PUBLISHING, 1987. [Dubb] Dubbel. Taschenbuch für den Maschinenbau, Kapitel Konstruktion, S. 318. Springer Verlag. [DuLe91] E. H. Durfee, V. R. Lesser. Partial Global Planning. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1167 ? 1183, November/Dezember 1991. [DuMo91] E. H. Durfee, T. A. Montgomery. Coordination as Distributed Search in a Hierarchical Behavior Space. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1363 ? 1378, November/Dezember 1991. [Elma92] Ahmed K. Elmagarmid (Hrsg.). Database Transaction Models for Advanced Applications. Morgan Kaufmann, San Mateo, California, 1992. [FeCa91] J. Ferber, P. Carle. Actors and Agents as Reflective Concurrent Objects: A Mering IV Perspective. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1420 ? 1436, November/Dezember 1991. [FiWi92] K. Fischer, H.-M. Windisch. MAGSY: Ein regelbasiertes Multiagentensystem. Künstliche Intelligenz, (1):22?26, März 1992. [FrRo94] E. Freund, J. Roßmann. Entwicklung und Einsatz intelligenter, autonomer Robotersysteme. it + ti - Informationstechnik und Technische Informatik, 36. Jahrgang(1):24 ? 33, Februar 1994. [Gave92] W.W. Gaver. The Affordances of Media Spaces for Collaboration. In Proceedings, S. 17?24, November 1992. [GKM93] Kaj Gr?nbaek, Morten Kyng, Preben Morgensen. CSCW Challenges: Cooperative Design in Engineering Projects. Communications of the ACM, 36(4):67?77, Juni 1993. [GrSa87] Irene Greif, Sunil Sarin. Data Sharing in Group Work. ACM Transactions on Office Information Systems, 5(2):187?211, April 1987. 67 [Grud88] J. Grudin. Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Interfaces. In Proceedings CSCW '88, S. 85?93, Portland, Oregon, 1988. [GrUr92] T. C. N. Graham, T. Urnes. Relational Views as a Model for Automatic Distributed Implementation of Multi-User Applications. In CSCW '92, S. 59 ? 66, 1992. [GSS92] Y. Goldberg, M. Safran, E. Shapiro. Active Mail - A Framework for Implementing Groupware. In CSCW '92 Proceedings, S. 75?83, November 1992. [GSS+93] T. Gutekunst, T. Schmidt, G. Schulze, J. Schweizer, M. Weber. A Distributed Multimedia Joint Viewing and Tele-Operation Service for Heterogeneous Workstation Environments. In W. Effelsberg, K. Rothermel (Hrsg.), Verteilte Multimedia-Systeme, Band 5 von FOKUS Praxis, Information und Kommunikation, S. 145?159, Stuttgart, Februar 1993. Saur Verlag. [GSW92] I. Greif, R. Seliger, W. Weihl. A Case Study Of CES: A Distributed Collaborative Editing System Implemented in Argus. IEEE Transactions on Software Engineering, 18(9):827?839, September 1992. [Haye93] B. Hayes-Roth. Opportunistic Control of Action in Intelligent Agents. IEEE Transactions on Systems, Man, and Cybernetics, 23(6):1575 ? 1587, November/ Dezember 1993. [ICM91] D. J. Mac Intosh, S. E. Conry, R. A. Meyer. Distributed Automated Reasoning: Issues in Coordination, Cooperation, and Performance. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1307 ? 1316, November/Dezember 1991. [KaTa91] M. F. Kaashoek, A. S. Tanenbaum. Group Communication In The Amoeba Distributed Operating System. In International Conference on Distributed Computing Systems, S. 222 ? 230, Mai 1991. [KCTL93] S. Kambhampati, M. R. Cutkosky, J. M. Tenenbaum, S. H. Lee. Integrating General Purpose Planners and Specialized Reasoners: Case Study of a Hybrid Planning Architecture. IEEE Transactions on Systems, Man, and Cybernetics, 23(6):1503?1518, November/Dezember 1993. [Klei91] M. Klein. Supporting Conflict Resolution in Cooperative Design Systems. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1379 ? 1390, November/ Dezember 1991. [KLL+93] T. Kirsche, R. Lenz, H. Lührsen, K. Mayer-Wegener, H. Wedekind. CoDraft - eine verteilte Architektur zur Unterstützung von Gruppenarbeit durch multimediale Objekte. In GI/ITG Arbeitstreffen Verteilte Multimedia-Systeme, S. 160?173. K.G.Saur, 1993. [KMW91] H. Krasner, J. McInroy, D.B. Walz. Groupware Research and Technology Issues with Application to Software Process Management. IEEE Transactions on Systems, Man, and Cybernetics, 21(4):704?712, Juli/August 1991. [KRW90] B. Karbe, N. Ramsperger, P. Weiss. Support of cooperative work by electronic circulation folders. In Proceedings of the Conference on Office Information Systems, S. 109?117, 1990. 68 Literaturverzeichnis [KSS92] S. Kirn, A. Scherer, G. Schlageter. FRESCO: Föderative Kooperation in Verteilten Wissensbasierten Systemen. Künstliche Intelligenz, (1):68?71, März 1992. [LeOl93] Julio Cesar Perleberg Lerm, Jose Palazzo M. de Oliveira. Cooperative Access to Relational and Object-Oriented Federated Databases. In Proceedings 4th Workshops on Future Trends in Distributed Systems, S. 222?227, 1993. [Levi92] P. Levi. Multiagenten-Systeme. Künstliche Intelligenz, (1):56, März 1992. [LJS93] K.-C. Lee, W. H. Mansfield Jr., A. P. Sheth. A Framework for Controlling Cooperative Agents. Computer, S. 8 ? 15, Juli 1993. [MaCr90] T. W. Malone, K. Crowston. What is Coordination Theory and How Can It Help Design Cooperative Work Systems? In CSCW `90 Conference on Computer- Supported Cooperative Work, S. 357?370. ACM Press, Oktober 1990. [Maze91] M. S. Mazer. Reasoning About Knowledge to Understand Distributed AI Systems. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1333 ? 1346, November/Dezember 1991. [MDS93] D. J. Musliner, E. H. Durfee, K. G. Shin. CIRCA: A Cooperative Intelligent Real- Time Control Architecture. IEEE Transactions on Systems, Man, and Cybernetics, 23(6):1561 ? 1573, November/Dezember 1993. [MüSc92] M. Mühlhäuser, J. Schaper. Project NESTOR: New Approaches to Cooperative Multimedia Authoring / Learning. In I. Tomek (Hrsg.), Computer Assisted Learning, 4th Intyernational Conference, ICCAL '92, Band 602 von Lecture Notes in Computer Science, S. 453?465, Wolfville, Nova Scotia, Canada, Juni 1992. Springer-Verlag. [MSS93] E. Moeller, A. Scheller, G. Schuermann. Der Multimedia-Mail-Teledienst. In W. Effelsberg, K. Rothermel (Hrsg.), Tagungsband GI/ITG Arbeitstreffen Verteilte Multimedia-Systeme, Band 5 von FOKUS Praxis, Information und Kommunikation, S. 206?226, Stuttgart, Februar 1993. Saur Verlag. [NPR92] L. Navarro, W. Prinz, T. Rodden. Open CSCW Systems: Will ODP help? In International Conference on Distributed Computing Systems, S. 547 ? 553, Juni 1992. [NRZ92] Marian H. Nodine, Sridhar Ramaswamy, Stanley B. Zdonik. A Cooperative Transaction Model for Design Databases. In Elmagarmid [Elma92], Kapitel 3, S. 53?85. [OMS+92] T. Ohmori, K. Maeno, S. Sakat, H. Fukuoka, K. Watabe. Distributed Cooperative Control for Sharing Applications Based on Multiparty and Multimedia Desktop Conferencing System: MERMAID. In International Conference on Distributed Computing Systems, S. 538 ? 546, Juni 1992. [PaTe91] J. Y. C. Pan, J. M. Tenenbaum. An Intelligent Agent Framework for Enterprise Integration. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1391 ? 1407, November/Dezember 1991. [Post82] J. Postel. Simple Mail Transfer Protocol. RFC821, August 1982. 69 [PYF+92] M. Palaniappan, N. Yankelovich, G. Fitzmaurice, A. Loomis, B. Haan, J. Coombs, N. Meyrowitz. The Envoy Framework: An Open Architecture for Agents. ACM Transactions on Information Systems, 10(3):233 ? 264, Juli 1992. [Rang93] P. V. Rangan. Video conferencing, file storage, and management in multimedia computer systems. Computer Networks and ISDN Systems, 25:901 ? 919, 1993. [RKGB92] J. Rosenberg, R.E. Kraut, L. Gomez, C.A. Buzzard. Multimedia Communications for Users. IEEE Communications Magazine, S. 20?36, Mai 1992. [Robi94] J. A Robinson. Communications services architecture for CSCW. Computer Communications, 17(5):339 ? 347, Mai 1994. [Roth82] Karlheinz Roth. Konstruieren mit Konstruktionskatalogen : Systematisierung und zweckmäßige Aufbereitung technischer Sachverhalte für das methodische Konstruieren. Springer, Berlin [u.a.], 1982. 475 S. [RSVW94] W. Reinhard, J. Schweitzer, G. Voelksen, M. Weber. CSCW Tools: Concepts and Architectures. IEEE Computer, 27(5):28?36, may 1994. [Rüde93] T. Rüdebusch. CSCW - Generische Unterstützung von Teamarbeit in verteilten DV- Systemen. Deutscher Universitäts Verlag, Wiesbaden, 1993. [SeRo93] F. Sembach, K. Rothermel. TEATIME: Gemeinsamer Arbeitsbereich für kooperativ bearbeitete multimediale Objekte. In GI/ITG Arbeitstreffen Verteilte Multimedia-Systeme, S. 174?188. K.G.Saur, 1993. [SFB+87] M. Stefik, G. Foster, D. Bobrow, K. Kahn, S. Lanning, L. Suchman. Beyond the Chalkboard - Computer Support for Collaboration and Problem Solving in Meetings. Communications of the ACM, 30(1):32?47, Januar 1987. [SHK+92] D. Steiner, H. Haugeneder, M. Kolb, F. Bomarius, A. Burt. Mensch-Maschine Kooperation. Künstliche Intelligenz, (1):59?63, März 1992. [SRSF91] K. Sycara, S. Roth, N. Sadeh, M. Fox. Distributed Constrained Heuristic Search. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1446 ? 1460, November/Dezember 1991. [Velt93] H. Velthuijsen. Distributed Artificial Intelligence for Runtime Feature-Interaction Resolution. IEEE Computer, S. 48?55, August 1993. [vMar92] F. v. Martial. Einführung in die Verteilte KI. Künstliche Intelligenz, (1):6?11, März 1992. [Webs86] Webster's Third New International Dictionary. 1986. [Wong93] S. T. C. Wong. COSMO: A Communication Scheme for Cooperative Knowledgebased Systems. IEEE Transactions on Systems, Man, and Cybernetics, 23(3):809 ? 824, Mai/Juni 1993. [WoSr93] A. Wong, D. Sriram. SHARED: An Information Model for Cooperative Product Development. Research in Engineering Design, 5(1):21?39, 1993. [ZlRo91] G. Zlotkin, J. S. Rosenschein. Cooperation and Conflict Resolution via Negotiation Among Autonomous Agents in Noncooperative Domains. IEEE Transactions on Systems, Man, and Cybernetics, 21(6):1317 ? 1324, November/Dezember 1991.