COINED – Eine Umgebung für verteiltes Rollenspiel

COINED (Collaborative Object INteraction in EDucation) wurde im Rahmen einer Diplomarbeit als Lösungsansatz für verteiltes Objekt-Rollenspiel konzipiert und entwickelt. Es handelt sich dabei um eine Groupware mit der eine lokale oder verteilte Gruppe von Benutzern gemeinsam Nachrichtenfluss und Objektinteraktionen eines objektorientierten Systems simulieren und visualisieren kann

In COINED können an einem benutzerdefinierten Domänen-Modell konkrete Systemfunktionalitäten rollenspielartig ausgeführt werden. Die Anwender übernehmen die Rollen einzelner Klassen und simulieren die Reaktion der Exemplare dieser Klassen auf empfangene Nachrichten. Die Reaktion eines Objekts auf eine empfangene Nachricht kann dabei Verschiedenes beinhalten, u.a.

· die Erzeugung/Manipulation lokaler Variablen

· eine Zustandsänderung durch Editieren der Attributwerte

· das Senden neuer Nachrichten an andere Objekte

· das Senden einer Antwort an das aufrufende Objekt.

COINED wurde als verteiltes System in Form einer Client-/Server-Architektur realisiert, wobei der Server als standardisierte Webapplikation und der Client als Plugin für das Open-Source Entwicklungsframework Eclipse umgesetzt wurden.

Abbildung 1– COINED Benutzeroberfläche

Der COINED-Client präsentiert sich dem Benutzer in Form einer Eclipse-Perspektive als eine Sammlung verschiedener Sichten (Views), vgl.Abbildung 1. Das Diagramm (1) ist dabei das Kernstück, hier werden Objekte, Beziehungen und Nachrichtenfluss in Diagrammform dargestellt und dynamisch visualisiert. Die Klassenliste (2) und die Objektliste (3) dienen als Klassen- resp. Objekt-Repository. Im Bereich MessageProcessing (4) findet während einer Simulation die Bearbeitung von empfangenen Nachrichten statt und der Bereich MessageHistory (5) liefert einen chronologischen Überblick über alle gesendeten Nachrichten sowie über alle Benutzer-geführten Zuweisungen. Die Buddy-Liste (6) liefert einen Überblick über die Projektteilnehmer und ihre Onlinestati. Der Chat (7) bietet den Teilnehmern die Möglichkeit der synchronen, Simulationsbegleitenden Kommunikation

Im Folgenden werden wir anhand von Beispielszenarien erläutern, wie sich COINED sowohl im didaktischen als auch im Entwurfs-Kontext einsetzen lässt und inwiefern es die jeweiligen Anforderungen erfüllt. Anschließend geben wir einen Überblick über COINEDs Architektur und technische Umsetzung, sowie über die verwendeten Design-Patterns und zeigen auf, inwieweit den technischen Anforderungen entsprochen wird.

1.1 OO-Lehre: Szenario und Lösungsdarstellung

Das folgende Beispielszenario soll den möglichen Einsatz von COINED im Rahmen der Lehre verdeutlichen.

Ein Informatik-Professor an einer Fern-Universität möchte im Rahmen seiner Vorlesung „Einführung in die objektorientierte Programmierung“ seinen Studenten einige OO-Grundkonzepte (insb. Objektinteraktionen und den Message-Passing-Mechanismus) mithilfe eines Rollenspiels verdeutlichen. Bei der Wahl des Rollenspiels entscheidet er sich für ein, aus der Marine Biology Simulation Case Study (MBCS) extrahiertes Szenario, das in der Fachliteratur für die Demonstration von Message-Passing vorgeschlagen wird.

In der MBCS wird, mit Schwerpunkt auf pädagogischen Aspekten, eine Aquarium-Simulationssoftware realisiert. Fische werden einer Umgebung hinzugefügt oder entfernt, haben eine Ausrichtung und Farbe, eine Position und sie können sich bewegen und ihre Positionen wechseln. Das System als Ganzes ist relativ umfangreich und komplex, für das Rollenspiel wird daher nur ein spezielles sehr vereinfachtes Szenario eingesetzt. Es soll den Benutzern klar machen, auf welche Weise die Hauptklasse Fische erzeugt und initialisiert.

Der folgende Ablauf wird dann mit verteilten Rollen (ein Student übernimmt die Rolle des Fisches f1, andere sind env, loc, oder theMBSDemo) durchgespielt. Für jede Rolle wird das Verhalten vorher in Form eines Skriptes genau festgelegt.

An einer Fern-Universität kann ein solches Rollenspiel nun nicht auf klassische Weise im Hörsaal mit anwesenden Studenten durchgespielt werden. Die Fernstudenten sitzen vielmehr verteilt an verschiedenen Orten und nutzen u.a. Rechner mit Internetanschluss zur Kommunikation. Deshalb beschließt der Professor COINED für die Durchführung seines Rollenspiels einzusetzen. Der COINED-Server soll auf einem Rechner in der Universität laufen.

Abbildung 2 - MBCS-Beispielszenario

Die Studenten arbeiten in kleinen Gruppen von jeweils 4 Teilnehmern. Jedes Gruppenmitglied startet seinen eigenen COINED-Client, indem es seine jeweilige Eclipse-Umgebung startet und innerhalb von Eclipse in die COINED-Perspektive wechselt (s. Abbildung 3).

Abbildung 3 – Aktivierung der COINED-Perspektive in Eclipse

Hier loggt er sich zunächst auf dem Server ein und öffnet anschließend das vom Professor vorbereitete Projekt „Aquarium“.

Abbildung 4 – Login und Projektwechsel

Das Projekt enthält bereits alle benötigten Klassen (MBSDemo, Fish, BoundedEnv, Location), aber noch keine Objekte. Zunächst wartet die Gruppe, bis alle Teilnehmer online sind und das Projekt geöffnet haben. Das ist der Fall, wenn in der BuddyListe alle Status-Icons grün sind. In Abbildung 5 sehen wir eine Momentaufnahme aus Alices Sicht: Mary ist offline, Paul ist online und hat das Projekt geöffnet, Peter ist online aber noch nicht im Projekt.

Abbildung 5 – Die BuddyListe aus Alices Sicht:

Die Rollen werden verteilt, Peter soll für Location zuständig sein, Paul für Fish, Mary für BoundedEnv und Alice für theMBSDemo. Diese Zuordnungen werden im ClassView über den Eintrag „Direct this class“ im Kontextmenü einer Klasse vorgenommen (s. Abbildung 6). Innerhalb der COINED-Umgebung trägt der jeweils für eine Klasse zuständige Benutzer die Bezeichnung Director. Nur der Director hat die Befugnis, Objekte aus einer Klasse zu erzeugen und auf Nachrichten zu reagieren.

Abbildung 6 – Rollenzuordnungen im ClassView

Nach erfolgter Zuordnung kann Peter als Director der Klasse Location das Objekt loc erzeugen, Paul erzeugt f1:Fish, Mary env:BoundedEnv und Alice theMBSDemo:MBSDemo. Das Erzeugen eines neuen Objekts geschieht ebenfalls über das Kontextmenü einer Klasse im ClassView.

Vom theMBSDemo-Objekt soll der Nachrichtenfluss starten, deshalb legt Alice als Director von MBSDemo initiale Beziehungen zu den vorhandenen Objekten mithilfe von entsprechenden Attributen fest. Hierzu wechselt sie in den ObjectView und selektiert theMBSDemo. Daraufhin werden die aktuellen Attributwerte in der Objektdetail-Maske angezeigt, wo Alice sie direkt manipulieren kann (s. Abbildung 7)

Abbildung 7 – Editieren von Objektdetails im ObjectView: Alice ist im Begriff, dem Attribut theEnv des Objekts theMBSDemo einen Wert zuzuweisen

Jetzt kann die eigentliche Simulation beginnen. Zunächst soll die main()-Methode von theMBSDemo aufgerufen werden. Ein beliebiges Gruppenmitglied ruft „Send Initial Message To“ im Kontextmenü von theMBSDemo auf. Im sich daraufhin öffnenden MsgProcessingView wird in dem „Create New Request“-Dialog theMBSDemo als Empfänger automatisch eingetragen, der Benutzer wählt dessen einzige Methode main und verschickt die Nachricht durch Betätigen den Send-Buttons.

Daraufhin wird der Empfänger der Nachricht (theMBSDemo) aktiviert und die Kontrolle an den Director von theMBSDemo (Alice) übergeben. Visualisiert wird die Aktivierung eines Objekts durch die den Wechsel seiner Hintergrundfarbe und durch die Markierung mit dem Sternsymbol (vgl. Abbildung 8).

Abbildung 8 - Visualisierung des aktiven Objekts und der letzten Nachricht

Alice hat also nun die Kontrolle und muss die empfangene Nachricht im MsgProcessingView verarbeiten und beantworten. Laut Script soll die init()-Methode des Objekts loc aufgerufen werden. Alice muss also die entsprechende Nachricht an das Objekt loc schicken. Loc ist in dem Attribut theLoc gespeichert, also zieht sie dieses Attribut mit der Maus vom ObjectView in das „SendTo“-Feld und wählt dann im Dropdown-Menü „Request Name“ die Nachricht init aus. In der Tabelle darunter belegt sie noch die Parameter mit den gewünschten Werten (2,2).

Abbildung 9 – MessageProcessingView unmittelbar vor dem Senden von init(2,2) an loc

Mit dem Send-Button wird die Nachricht gesendet und die Kontrolle an das empfangende Objekt loc weitergereicht. Peter als Director von loc ist nun für die Bearbeitung der Nachricht zuständig. Per Drag&Drop speichert er die Argumente der Nachricht in locs Attributen und schließt die Bearbeitung mit Betätigung des Finish-Buttons ab. Die Kontrolle geht daraufhin zurück an theMBSDemo, Alice ist wieder am Zug. Sie konstruiert und schickt nun die Nachricht init(env,loc) an das Fisch-Objekt f1. Paul ist Director der Fisch-Klasse, also bekommt er als nächstes die Kontrolle. Die in den Argumenten der empfangenen Nachricht enthaltenen Referenzen auf loc und env legt Paul für die spätere Verwendung in den entsprechenden Feldern von f1 ab. Nachdem der Fisch f1 jetzt das Objekt env kennt und mit ihm kommunizieren kann, sendet Paul die Nachricht randomDirection an env um eine initiale Ausrichtung für den Fisch zu erhalten. Das Objekt env wird aktiviert, Mary hat die Kontrolle. Sie beantwortet die Nachricht mit der Rückgabe einer zufälligen Ausrichtung. Pauls Fisch f1 erhält die Antwort und speichert den Wert in seinem Attribut myDir. In den nächsten Schritten generiert Paul eine zufällige initiale Farbe indem er die Nachricht randomColor an sich selbst sendet und selbst beantwortet. Die Farbe wird im Attribut myColor abgelegt. Damit ist der Fisch soweit initialisiert, dass er der Umgebung hinzugefügt werden kann, also sendet Paul die Nachricht add mit sich selbst als Parameter an das Objekt env. Mary fügt die so erhaltene Referenz auf f1 in die Umgebung ein und gibt die Kontrolle direkt wieder zurück. Paul kann nun seinerseits f1s Bearbeitung der init()-Nachricht von theMBSDemo abschließen, der Kontrollfluss landet damit wieder theMBSDemo. Abbildung 10 zeigt den Stand des Diagramms und der Nachrichtenhistorie zu diesem Zeitpunkt.

Abbildung 10 Protokollierter Nachrichtenfluss am Ende des durchgespielten Szenarios

An diesem Fallbeispiel werden bereits einige der Merkmale deutlich, mit denen COINED Lernprozesse unterstützen kann. Im Folgenden stellen wir nun genauer gegenüber, welche Merkmale jeweils die einzelnen didaktischen Anforderungen (DA) erfüllen.

DA1: Benutzerinteraktion auf Objektebene

In COINED: Direkter Zugriff auf Objekte ist zum einen im ObjectView und zum anderen im DiagramView möglich. Im Diagramm werden die einzelnen Objekte in Form von Rechtecken, ähnlich der Notation in UML-Objekt-Diagrammen, visualiert. Der Objektname, -typ und die sowie Attributnamen und –werte zu einem bestimmten Zeitpunkt werden angezeigt. Assoziationen zwischen Objekten werden über gerichtete Linien visualisiert. Über das Kontextmenü eines Objekts können die Objektdetails und Messagestack des Objekts geöffnet werden, d.h. die Wahl des entsprechenden Menüeintrags aktualisiert den MessageProcessingView bzw. die ObjectDetails-Maske mit den Daten des aktuellen Objekts. Eine andere Sichtweise auf die Objekte findet sich im ObjectView. Hier werden die Objekte eines Projekts listenartig aufgeführt. Die Auswahl der angezeigten Objekte lässt sich über Filter beschränken, z.B. kann der Benutzer nur die von ihm dirigierten Objekten auflisten lassen. Die Selektion eines Objekts der Liste führt zur Anzeige der Details dieses Objekts in der Maske im unteren Teil des ObjectViews. In dieser Maske können die Attributwerte direkt editiert werden, vorausgesetzt, der Benutzer ist auch Director dieses Objekts, bzw der zugehörigen Klasse.

Abbildung 7 zeigt die beiden Objekt-Darstellungsformen: grafisch im Diagramm und listen-artig im ObjectView.

DA2: Kapselung

In COINED: Die Objekte und ihre jeweiligen Attributwerte sind im Diagram-und ObjectView für alle Benutzer sichtbar. Mit diesen Informationen werden die Diagramme aussagekräftiger und können dann Programmflüsse besser visualisieren. Bei der Manipulation von Objekten bleibt COINED dem Prinzip der Kapselung allerdings treu, nur der Director, also der Benutzer, der ein Objekt dirigiert, darf Attribute und -werte dieses Objekts editieren. Alle anderen Benutzer müssen Nachrichten an das Objekt schicken, wenn sie seine Attributwerte verändern wollen. Hier ist ein Filter denkbar, dieser ist jedoch zukünftigen Versionen von COINED vorbehalten.

DA3:Interaktiv Nachrichten senden

In COINED: Methoden können im ClassView eingesehen, angelegt und bearbeitet werden, also explizit auf Klassen- nicht auf Objektebene. Die Methoden einer Klasse bestimmen die möglichen Nachrichten, die an ein Objekt dieser Klasse geschickt werden können. Wenn ein Benutzer eine Nachricht an ein Objekt schicken möchte, zieht er dieses Objekt aus dem ObjectView in das entsprechende Feld im MessageProcessingView. Das Dropdown-Menü Message bietet dann alle Nachrichten, die sich an diese Objekt schicken lassen, zur Auswahl. Für jede Methode, die Klasse des Objekts besitzt, wird die entsprechende Nachricht angezeigt. Nach der Auswahl einer Nachricht werden die Parameterfelder entsprechend der Methodensignatur aktualisiert. Der Benutzer kann den einzelnen Parametern dann konkrete Werte zuweisen, entweder per Drag&Drop oder, im Fall von einfachen Datentypen, durch direkte Eingabe. Gesendete Nachrichten werden im DiagramView visualisiert. Auf der Verbindungslinie zwischen zwei Objekten werden in einer Box alle Nachrichten gelistet die zwischen den Objekten verschickt wurden. Jede Nachricht hat ein Pfeil-Icon, das die Richtung des Nachrichtenflusses symbolisiert. Innerhalb einer Box werden die Nachrichten in absteigender Reihenfolge angezeigt, die aktuellste Nachricht steht dann jeweils oben.

Methoden tauchen also nur im Kontext von Klassen (nämlich im ClassView) und Nachrichten im Kontext von Objekten (im MessageProcessingView arbeitet der Benutzer auf Objektebene, im DiagramView ebenso) auf. Eine Tatsache, welche die Differenzierung von Methode und Nachricht aus Benutzersicht unterstreichen sollte.

DA4: Interaktiv Objekte erzeugen

In COINED: Klassen und Objekte werden jeweils in verschiedenen Views (ClassView und ObjectView) verwaltet. Beide Views sind als Master-Details-Blöcke konzipiert, d.h. es gibt auf der einen Seite eine Listendarstellung aller Elemente und auf der anderen Seite eine Detailmaske (vgl. Abbildung 6, Abbildung 7). Die Selektion eines Listenelements zeigt dann die Details dieses Elements in dieser Detailmaske an. Im ClassView lassen sich in der Detailmaske Attribute (Name und Typ) und Methoden einer selektierten Klasse einsehen, erzeugen und/oder editieren. In den Details des ObjectViews werden die Attribute (Name und Typ) und die konkreten Attributwerte von Objekten angezeigt, die Editierbarkeit beschränkt sich an dieser Stelle aber auf die Attributwerte. Neue Objekte werden im ClassView durch direkte Instanziierung von Klassen erzeugt. Um ein Objekt einer bestimmten Klasse zu erzeugen, selektiert man die Klasse und wählt im Kontextmenü den Eintrag „Create New Object“. Das Erzeugen von Objekten ist nur dem Director der Klasse des Objekts gestattet.

Die strikte Trennung von Klassen- und Objektraum, und die Beschränkungen der Editiermöglichkeiten im jeweiligen Kontext (Attributname/-typ und Methoden im ClassView, Attributwerte im ObjectView) sollen den Anwender dabei unterstützen, sauber zwischen Objekten und Klassen zu differenzieren zu können.

DA5: Beziehungen

In COINED: Ein Objekt kann Nachrichten nicht an beliebige Objekte verschicken, sondern nur so an solche, zu denen es in einer Beziehung steht. Das sendende Objekt muss das empfangende Objekt kennen. Diese Kenntnis kann sich z.B. aus einem Attributwert, einem Parameter oder einer lokalen Variable des aktuellen Messagestacks des Objekts herleiten. In COINED initiiert der Benutzer das Senden einer Nachricht, indem er ein Objekt per Drag&Drop in den MessageProcessingView zieht. Der Drag&Drop-Mechanismus wurde dabei so umgesetzt, dass ausschließlich Attribute, Parameter und lokale Variablen des aktuellen Objekts als DragSource zugelassen werden. Somit besteht also für den Benutzer überhaupt keine Möglichkeit, Nachrichten an unbekannte Objekte zu senden.

DA6: Kommunikationsmedium für den Wissenstransfer

a) Graphische Visualisierung als Kommunikationsunterstützung

In COINED werden Nachrichtenfluss und Objektinteraktion in Diagrammen visualisiert. Diese Diagramme können später als Kommunikationsgrundlage dienen und zu Dokumentationszwecken eingesetzt werden

b) Protokolle der Interaktion als Kommunikationsunterstützung

Der vollständige Nachrichtenfluss und alle Benutzerinteraktionen werden persistent in der Datenbank gespeichert und im HistoryView zur Anzeige gebracht. Diese Informationen dokumentieren den vollständigen Ablauf der Simulationen und bieten den Anwender eine gemeinsame Kommunikationsbasis aufgrund der weiterführende Design-Entscheidungen getroffen werden können.

DA7: Unterstützung verteilter und lokaler Lehre

COINED wurde mit dem Schwerpunkt auf der Unterstützung von verteilter Gruppenarbeit konzipiert. Mehrere (lokale oder verteilte) Benutzer arbeiten gruppenweise in gemeinsamen Sessions an Projekten. Dabei muss die Arbeit natürlich nicht zwingend als Multi-User-Session erfolgen, Single-User Betrieb ist ebenso möglich.

COINEDs Client-/Server-Kommunikation basiert letztlich auf TCP/IP, damit kann es sowohl im LAN (lokale Lehre, eine Gruppe arbeitet mit vernetzten Rechnern in einem Seminarraum) als auch übers Internet (verteilte Lehre, Lernende sitzen an verschiedenen Orten an Rechnern mit Internetanschluss) eingesetzt werden.

DA8: Flexible Reaktion auf neue Erkenntnisse

Da Änderungen am Modell innerhalb von COINED schnell und einfach umgesetzt werden können, ist es möglich mit relativ wenig Aufwand die neuen Erkenntnis in alternative Modelle einfließen zu lassen und diese im Szenario-Rollenspiel zu testen.

DA9: Rollenspiel

COINED unterstützt interaktives Szenario-Rollenspiel. Benutzer übernehmen die Rolle von Objekten und senden, empfangen und bearbeiten Nachrichten. Der Nachrichtenfluss und Objektzuständen werden in einem RPD visualisiert. Beim Senden einer Nachricht gibt ein Objekt die Kontrolle an den Empfänger der Nachricht ab. Erst mit dem Erhalt der Antwort bekommt der Sender die Kontrolle zurück. Objekte, die auf Antworten warten, also Teil des aktuellen Execution Stacks sind, signalisieren diesen Zustand über das farbige Director-Icon. Bei allen anderen Objekten ist das Icon leicht transparent.

1.2 OO-Entwicklung: Szenario und Lösungsdarstellung

Neben dem Einsatz in der Lehre bietet sich im Bereich der Softwareentwicklung eine weitere Einsatzmöglichkeit von COINED. Das folgende Szenario soll exemplarisch verdeutlichen, wie COINED als unterstützendes Werkzeug in der Entwurfsphase eines Softwareprojekts eingesetzt werden kann.

Eine Autovermietung gibt bei einer auswärts ansässigen Softwareentwicklungsfirma die Entwicklung eines neuen Verwaltungssystems in Auftrag. Das System soll die für Autovermietungen üblichen Funktionalitäten erfüllen, dazu gehört u.a. die Verwaltung des Fahrzeug- und Kundenbestands, das Reservieren oder Ein- und Auschecken von Fahrzeugen, etc. Die Entwicklung soll in einem heterogenen Team aus Mitarbeitern der Softwarefirma und Mitarbeitern der Autovermietung erfolgen. Letztere sollen in den gesamten Entwicklungsprozess (insb. auch in der Entwurfsphase) aktiv einbezogen werden.

Im Vorfeld, in einer ersten Analysephase hat das Team bereits Use Cases identifiziert und, z.B. unter zu Hilfenahme von CRC-Karten, ein elementares, informales Modell entwickelt, das jetzt in einer Designphase konkretisiert und verfeinert werden soll.

Abbildung 11 –Autovermietung: Use Cases und CRC-Karten

Es gibt noch Unklarheiten bzgl. des genauen Modells, die beteiligten Klassen und Objekte sowie ihr Verhalten und ihre Interaktion müssen noch genauer identifiziert werden. Die Entwurfsphase beinhaltet unter anderem auch, dass bestimmte Implementierungsfragen geklärt werden. Es müssen Entscheidungen zu den tatsächlichen Klassen getroffen werden, ihre Eigenschaften müssen auf konkrete Attribute und Methoden abgebildet werden, für das Zustandekommen von Beziehungen müssen geeignete Umsetzungsformen (durch Konstruktion, Senden von Argumenten, Empfang von Antworten), gefunden werden. Das Modell wird in der Designphase immer wieder geändert, verschiedene Designalternativen werden durchgetestet. Am Ende sollen aus dem Modell Java-Klassenrümpfe generiert werden.

Nicht alle Teammitglieder können bei den nun anstehenden Sitzungen vor Ort sein, um face-to-face miteinander zu kommunizieren und Entwurfsentscheidungen wie sonst üblich auf Papier oder Whiteboards zu diskutieren. Deshalb sucht man nach Möglichkeiten einen verteilten Entwurfsprozess zu unterstützen und den Teilnehmern Remote-Zugriff bzw. -Einstieg in gemeinsame Entwurfssitzungen zu bieten. Man entscheidet sich für den Einsatz von COINED. Der COINED-Server wird in der Software-Firma aufgesetzt und so in die Netz-Infrastruktur integriert, dass die Teammitglieder sich über das Internet von verschiedenen Orten mit den, auf ihren Laptops und Desktop-PCs installierten, Clients einloggen können.

Im ersten Schritt versuchen die Anwender die Artefakte des Analysemodells auf eine möglichst einfache Art innerhalb von COINED abzubilden, so dass ein erstes Designmodell in Form eins Projekts mit Klassen und Objekten entsteht. In diesem Projekt werden dann die verschiedene Use Cases „durchgespielt“.

Zur Illustration des konkreten Einsatzes von COINED schauen wir uns den Use Case „Kfz mieten“ genauer an.

Unser Team besteht aus John, Jack, Jill und Joe. Alle halten sich an verschiedenen Orten auf. Joe hatte sich bereit erklärt ein initiales Projekt mit einer ersten Umsetzung der CRC-Karten anzulegen. Dieses Projekt soll nun als Ausgangsbasis für die weitere, gemeinsame Entwicklung dienen. Die Teammitglieder loggen sich zu einem verabredeten Zeitpunkt aus der COINED-Perspektive ihrer Eclipse-Umgebungen am Server ein und öffnen das Projekt „Autovermietung“. Folgende Klassen hat Joe bereits angelegt:

Kfz - Die Fahrzeuge, die vermietet werden können (ID, Typ, istVerfügbar, miete())
Vermietung– Verwaltet den Fahrzeug- und Kundenbestand (kfzListe, sucheKfz(), kundenListe, sucheKunde())
Mitarbeiter - Nimmt Kundenaufträge entgegen, wie Fahrzeuganfragen, Vermietungen und Rückgaben (ID, Name, mieten(), zurückgeben(), kollaboriert mit Vermietung).
Kunde(ID, Name, gemietete Fahrzeuge, ausstehende Gebühren

Den etwas konkreteren Ablauf eines „Kfz mieten“-Szenarios hat das Team schon während der Analyse vorher besprochen, Joe hatte eine textuelle Beschreibung per Email verteilt.

Max Muster mietet bei einem Mitarbeiter das Kfz mit der ID “PB-PK 123“. Max Mustermann ist registrierter Kunde mit der ID 321. Das Kfz ist verfügbar. Nach dem Mieten hat das Kfz den Status „nicht verfügbar“ und es ist beim Kunden Max Muster als gemietetes Kfz eingetragen.

Nachdem das Team komplett angemeldet ist und das Projekt geöffnet hat (erkennbar an den Status-Icons in der BuddyListe), vergewissert sich Joe über den integrierten Chat als erstes, dass auch alle die entsprechende Szenario-Beschreibung erhalten und vor sich liegen haben. Bei der Gelegenheit wird gleich die Rollenverteilung geklärt, Jack übernimmt die Rolle der Vermietung, Joe spielt die Kunden, Jill ist für die Kfz und John für die Mitarbeiter zuständig. Alle führen die jeweilige Zuordnung gleich in COINED durch (über das Kontextmenü im ClassView, vgl. Abbildung 6)

Abbildung 12 – ChatView: Joe, Jack, Jill und John besprechen die Rollenverteilung

Ähnlich wie Testdaten für TestCases in einer JUnit-Testumgebung innerhalb der setUp()-Methode initialisiert werden, müssen auch für die Szenarien in COINED initiale Daten vorbereitet werden. Das Erzeugen von Testdaten kann z.B. das Anlegen bestimmter Objekte und das Vorbelegen von Attributwerten umfassen. In unserem Beispiel muss das Team also zunächst entsprechend initiale Objekte anlegen, bevor die Simulation starten kann. Jeder erzeugt die erforderlichen Objekte der Klasse für die er als Director zuständig ist und weist gegebenenfalls initiale Attributwerte zu (John: derMitarbeiter, Jack: dieVermietung, Jill: kfz1 und Joe: kunde1). Neue Objekte werden über das Kontextmenü einer Klasse im ClassView erzeugt.

Abbildung 13 – Autovermietung: Initialisierte Objekte

Das Szenario soll mit dem initialen Senden der Nachricht mieten(kundenID=“321“, kfzID=“PB-PK 123“) starten. Stellvertretend für die Systemkomponente (z.B. Systemeingaben über das GUI), von der die Bearbeitungsabläufe später tatsächlich ausgelöst werden sollen, gibt es in COINED das theActor-Objekt. Jedes Objekt hat in seinem Kontextmenü den Eintrag „Send Initial Message To“ über den sich eine initiale Nachricht von theActor an dieses Objekt schicken lässt. Diesen Weg nutzt Joe nun um das Rollenspiel und den Mietvorgang anzustoßen (vgl. Abbildung 14)

Abbildung 14 – Autovermietung: Initiierung, Bearbeitung und Darstellung der ersten Nachricht

John (derMitarbeiter) muss für die Bearbeitung der Anfrage das entsprechende Kunden- und Kfz-Objekt ermitteln. Er stellt fest, dass er selbst nicht über die entsprechenden Informationen verfügt, und auch keine Assoziation zu einem Objekt besitzt, von dem er diese Information bekommen könnte. Ein Blick auf das Diagramm offenbart schnell, dass das Objekt dieVermietung als Verwalter der Kfz und Kundenlisten der richtige Ansprechpartner wäre. Im Chat bespricht John kurz mit dem Team, dass er seinem Objekt gerne eine initiale Referenz auf dieVermietung in Form eines Attributwertes anlegen würde. Da für die Klasse Mitarbeiter sowieso die Responsibilities sucheKfz und sucheKunde vorgesehen sind und spätestens bei deren Umsetzung die Vermietung als Collaborator erforderlich sein wird, stimmen alle sofort zu. John erzeugt also für seine Mitarbeiter-Klasse im ClassView das neue Attribut vermietung vom Typ Vermietung. Er wechselt wieder zurück in den Object-View und weist dem Attribut den konkreten Wert dieVermietung zu. Im Diagramm erscheint eine blaue gerichtete Verbindungslinie, die symbolisiert, dass das Objekt derMitarbeiter das Objekt dieVermietung nun kennt und mit ihm interagieren kann. John kann nun also die Suchanfragen stellen, er schickt die Nachricht sucheKfz(„PB-PK123“) an dieVermietung. Damit geht die Kontrolle an Jack, dieser beantwortet die Nachricht indem er das entsprechende Objekt kfz1 per Drag&Drop aus seinen privaten Attributen auf das Anwortfeld zieht und durch Klicken des Finish-Buttons die Kontrolle zurückgibt.

John speichert das erhaltene Fahrzeug kfz1 in einer lokalen Variablen um ihm im nächsten Schritt eine Verfügbarkeitsanfrage senden zu können. Er initiiert die Nachricht diesmal nicht per Drag&Drop sondern über das Kontextmenü der Variable („Send Message To“). Beide Wege sind gleichwertig und führen zum Formular („Create a New Outgoing Request“), in dem das adressierte Objekt, hier jetzt also kfz1, vorgepromptet ist. Bei der Sichtung des Dropdown-Menüs mit den für die Klasse Kfz definierten Nachrichten stellt John fest, das es die Nachricht istVerfügbar() noch nicht gibt. Also gibt er den Namen der Nachricht manuell ein. Er könnte noch Parameter angeben, aber er benötigt keine und schickt die neue Nachricht ab. Jill erhält die Kontrolle und muss nun auf die neue Nachricht reagieren. Sie könnte die Nachricht mit Do-Not-Understand beantworten und so verwerfen. Aber sie sieht sofort, dass es noch keine andere Methode zur Abfrage des privaten verfügbar-Attributs von Kfz gibt. Also akzeptiert sie die Nachricht, indem sie sie erwartungsgemäß beantwortet. Sie zieht den Wert von verfügbar in das Antwortfeld und beendet die Bearbeitung. Im Hintergrund wird damit automatisch eine neue der Nachricht entsprechende Methode in die Klasse Kfz eingefügt.

Der weitere Ablauf des Szenarios geht ohne weitere Besonderheiten über die Bühne. John schickt die Nachricht mieten() an kfz1, woraufhin Jill den Verfügbarkeits-Status von kfz1 auf false setzt. John lässt sich das Kunden-Objekt kunde1 mittels der Nachricht sucheKunde(„321“) von dieVermietung zurückgeben. Mit Senden der Nachricht mieteKfz (kfz1) aktiviert er das Objekt kunde1 von Joe. Joe trägt das übergebene Argument kfz1 in die Liste der gemieteten Fahrzeuge ein und gibt die Kontrolle zurück. Damit kann John nun die Bearbeitung der initialen mieten() Nachricht vom Actor-Objekt abschließen.

Abbildung 15 Nachrichtenhistorie und Diagramm am Ende des Szenarios

Nach dem Abschluss des Rollenspiels kann sich das Team die genaue Chronologie des Nachrichtenflusses und alle getätigten Zuweisungen im MessageHistoryView noch einmal vor Augen führen. Dort ist auch die hierarchische Struktur des Nachrichtenstacks gut erkennbar.

Jack merkt an, dass die Objektinteraktion ingesamt sehr „Mitarbeiter-lastig“ ist - ein Sachverhalt, den man am Diagramm schnell nachvollziehen kann. Man diskutiert kurz alternative Möglichkeiten, z.B. könnte der Mitarbeiter seine Kommunikation mit dem Kfz-Objekt an das Kunden-Objekt delegieren, bleibt dann aber bei der ursprünglichen Version.

Abbildung 16 – Codegenerierung: Assistent und Java-Perspektive mit generierten Klassen-Stubs

Das Team spielt nun noch verschiedene andere Szenarien wie„Kfz zurückgeben“ durch, testet so das Modell und bessert es gegebenenfalls nach. Von der finalen Version ist Joe so begeistert, dass er gerne direkt dem Implementieren loslegen möchte. Dafür lässt er sich von COINED Java-Klassenrümpfe mit Methoden und Attributen aus dem Modell generieren (s. Abbildung 16). Sein Eclipse wechselt dabei automatisch in die Java-Perspektive in der Joe gleich auf die generierten Klassen zugreifen und diese ausprogrammieren kann.

Das vorgestellte Nutzungsszenario illustriert bereits wie COINED einige der Anforderungen die sich im Entwurfskontext ergeben unterstützen kann. Während der Simulation offenbaren sich die Unzulänglichkeiten des Modells auf relativ natürliche Art und Weise, notwendige Artefakte werden identifiziert. So werden beispielsweise intuitiv die fehlende Beziehung zwischen Mitarbeiter und Vermietung (EA4), und die benötigte Nachricht istVerfügbar() (EA3) aufgedeckt.

Im Folgenden betrachten wir noch einmal genauer, wie COINED die einzelnen Anforderungen, die sich im Entwurfskontext ergeben, umsetzt.

EA1: Identifikation der Objekte

EA2: Identifikation der Nachrichten

EA3: Reaktion auf Nachrichten

EA4: Identifikation der Objektbeziehungen

Bei der Simulation der Szenario-Rollenspiele arbeiten die Benutzer direkt auf Objektebene und bewegen sich eben gerade explorierend durch den Objekt-Raum. Die zur Umsetzung einer bestimmten Systemfunktionalität benötigten Objekte werden schnell identifiziert (EA1). Auch die benötigten Nachrichten(EA2), die Reaktionen der Empfänger (EA3) und die erforderlichen Beziehungen zu anderen Objekten um Nachrichten senden können (EA4), können während der Simulation aufgedeckt werden. Im AU

Ein besonderes, EA2 unterstützendes, Merkmal von COINED ist die Möglichkeit der Ad-Hoc-Methodengenerierung. Damit ist es möglich, unbekannte Nachrichten an Objekte zu verschicken. Der Sender generiert eine benutzerdefinierte Nachricht mit neuem Namen und Parametern. Der Empfänger hat die Möglichkeit mit Do-Not-Understand zu antworten, dann geht die Kontrolle zum Sender zurück und die neue Nachricht/Methode wird verworfen. Der Empfänger kann die Nachricht aber auch akzeptieren, indem er sie auf die im MsgProcessingView übliche Weise bearbeitet und beantwortet. In der Klasse des Empfängers wird dann automatisch eine der Nachricht entsprechenden Methode angelegt.

EA5: Testmöglichkeiten

Mit COINED lassen sich verschieden Systemfunktionalitäten rollenspielartig simulieren. Diese Simulationen können auch als Tests betrachtet werden. Sie dienen dazu Inkonsistenzen und Fehler im Modell aufzudecken.

EA6: Kommunikationsmedium für den Wissenstransfer

a) Graphische Visualisierung als Kommunikationsunterstützung

In COINED werden Nachrichtenfluss und Objektinteraktion in Diagrammen visualisiert. Diese Diagramme können später als Kommunikationsgrundlage dienen und zu Dokumentationszwecken eingesetzt werden

b) Protokolle der Interaktion als Kommunikationsunterstützung

EA7: Unterstützung lokaler und verteilter Teams

Analog zu DA7 - COINED wurde mit dem Schwerpunkt auf der Unterstützung von verteilter Gruppenarbeit konzipiert. Mehrere (lokale oder verteilte) Benutzer arbeiten gruppenweise in gemeinsamen Sessions an Projekten. Dabei muss die Arbeit natürlich nicht zwingend als Multi-User-Session erfolgen, Single-User Betrieb ist ebenso möglich. COINEDs Client-/Server-Kommunikation basiert letztlich auf TCP/IP, damit kann es sowohl im LAN (lokale Lehre, eine Gruppe arbeitet mit vernetzten Rechnern in einem Seminarraum) als auch übers Internet (verteilte Lehre, Lernende sitzen an verschiedenen Orten an Rechnern mit Internetanschluss) eingesetzt werden.

EA8: Potenzieller Mehrwert

Ein konkreter Mehrwert, den die Nutzung von COINED bietet, liegt in der Möglichkeit der Code-Generierung. Aus dem entworfenen Modell können Klassenrümpfe erzeugt werden, die dann als Grundlage für die spätere Implementierung dienen.

Ein indirekterer Mehrwert kann sich bzgl. der Qualität des Designs ergeben. Wenn die Möglichkeit, verschiedene Design-Alternativen zu testen, intensiv genutzt wird, führt das dazu, dass der resultierende Entwurf später weniger anfällig auf Änderungen reagiert. Auch die Wahrscheinlichkeit während der späteren Implementierung in Probleme, die auf schlechten Entwurfsentscheidungen basieren, zu geraten, verringert sich.

EA9: Flexible Reaktion auf neue Erkenntnisse

Da Änderungen am Modell innerhalb von COINED schnell und einfach umgesetzt werden können, ist es möglich mit relativ wenig Aufwand verschiedene Design-Alternativen zu testen. So können neue Erkenntnisse gewonnen und das Design flexibel angepasst werden.

EA10: Nachvollziehbarkeit

In COINED: Der HistoryView listet alle gesendeten Nachrichten und alle Zuweisungen chronologisch in einer Baumdarstellung auf. Die einzelnen Eben des Baum lassen sich je nach gewünschtem Detailgrad auf oder zu klappen. Über Filter kann die Anzeige auf Zuweisungen oder Nachrichten beschränkt werden. Die Nachrichten sind aufsteigend durchnummeriert. Zu jeder Nachricht lassen sich über ein Kontextmenü Details wie Quell- und Zielobjekt, Parameter, und Zeitstempel anzeigen. Über den HistoryView ist der Nachrichtenfluss also vollständig nachvollziehbar.

Die durchgehende Nummerierung der Nachrichten findet sich auch in ihrer Repräsentation im Diagramm. Diese Ansicht ist allerdings eher für eine ausschnittartige Betrachtung des Programmflusses geeignet, aus Gründen der Übersichtlichkeit wird nur eine benutzerdefinierte Anzahl von aktuellen Nachrichten zwischen zwei Objekten angezeigt.

1.3 Konzeptionelle Lösung der technischen Anforderungen

In diesem Abschnitt betrachten wir die technische Umsetzung der Lösung. In 1.3.1 stellen wir kurz die Architektur von COINED vor und erläutern im Einzelnen den Bezug zu den technischen Anforderungen des kollaboratives Rollenspiels. In 1.3.2 gehen wir auf die, in der Lösung verwendeten Entwurfsmuster aus dem Bereich der von Schümmer & Lukosch (2007) vorgestellten Computer Mediated Interaction Pattern ein.

1.3.1 Technischer Überblick und Architektur

Wie anfangs bereits erwähnt, wurde COINED als verteiltes Mehrbenutzer-System in Form einer Client-/ Server-Architektur realisiert, wobei der Server die zentrale Instanz ist, welche die Zusammenarbeit der Clients untereinander koordiniert.

Der COINED-Server ist eine, der Java-Servlet-Spezifikation entsprechende, Webapplikation, die in einem beliebigen Standard-ServletContainer eingesetzt werden kann. Die Client-/Server-Kommunikation erfolgt zum einen über eine WebService-Schnittstelle (Update- und Datenrequests) und zum anderen über eine JMS-Schnittstelle (Update-Notifications). Der WebService basiert auf der SOAP-Implementation Axis und als JMS-konformer Messaging-Dienst wird ActiveMQ eingesetzt. Zur persistenten Datenhaltung wird eine MySQL-Datenbank verwendet.

Der COINED-Client wurde als Plugin für das Open-Source Entwicklungsframework Eclipse in der Version 3.2 umgesetzt. Eclipse und Eclipse-Plugins (und damit auch COINED) sind in Java implementiert und somit weitestgehend plattformunabhängig. Für die grafische Diagrammdarstellung wird das Zeichnungs- und Layout-Plugin Draw2D (ein Teil des GEF-Frameworks) verwendet.

In Abbildung 17 findet sich eine vereinfachte schematische Darstellung der Architektur.

Abbildung 17 – Schematische Darstellung von COINEDs Architektur

Die Identifizierung der Clients und die Authorisierung der Zugriffe auf den WebService werden über ein Sessionmanagement geregelt. Den entsprechenden Ablauf beim Start eines Clients kann man sich folgendermaßen vorstellen.

Zunächst muss sich der Benutzer am System authentifzieren indem er sich mit seinen Account-Daten (Nickname, Passwort) über einen Login-Dialog am Server anmeldet. Kann der Server die Anmeldedaten validieren, generiert er für den Client eine neue Session und gibt die SessionID zurück. Der Client muss danach alle weiterführenden Server-Requests mit dieser SessionID versehen, damit der Server eindeutige Zuordnungen von Requests und Clients machen und die Gültigkeit prüfen kann.

Die eigentliche kollaborative Umgebung betritt der Benutzer erst mit dem Öffnen/Erzeugen eines COINED-Projekts. Beim erstmaligen Betreten eines Projekts, wird ein Request an den Server abgesetzt, der dafür sorgt, dass der Benutzer automatisch als Projektmitglied eingetragen wird. Der Server sendet Update-Notifications über das neue Mitglied an alle Clients, die zurzeit im gleichen Projekt registriert sind, diese Clients fordern daraufhin die Daten des neuen Mitglieds vom Server an und aktualisieren die graphische Darstellung in den Benutzerlisten im BuddyListView.

Bei dieser Beschreibung erkennt man bereits wie COINED mit Update-Requests und Update-Notifications arbeitet. Ein Mechanismus, der immer verwendet wird, wenn ein Client eine Datenänderung vornimmt. Zur genaueren Illustration der Kommunikationsstrukturen skizzieren wir nun das generelle Muster, nach dem das System auf Benutzerinteraktionen mit Artefakten reagiert und entsprechende Datenmanipulationen umsetzt.

Abbildung 18 – Ablauf bei einer Datenänderung

1. Über das GUI eines Clients wird ein Artefakt manipuliert. Das kann z.B. das Verändern einen Attributwerts oder das Senden einer neuen Nachricht sein.

2. Ein entsprechender Update-Request mit den zu ändernden Daten wird an den Server durchgereicht

a. View stellt Anfrage beim Model

b. Model delegiert an Cache

c. Cache stellt Request an WebService

3. Auf Server-Seite gibt der für den Request zuständige Businesshandler die im Request übermittelte SessionID zur Prüfung an den SessionManager weiter. Der SessionManager validiert die Session und liefert die mit der Session assoziierten Client-Informationen, wie User- und ProjektID, zurück.

4. Bei positiver Validierung delegiert der Businesshandler die zu ändernden Daten an den entsprechenden DB-Mapper.

5. Die DB-Mapper überträgt die gewünschte Änderung persistent in den Datenbestand der Datenbank.

6. War der DB-Eintrag erfolgreich, informiert der Businesshandler den serverseitigen ChannelManager.

7. Der ChannelManager informiert alle Clients, die am gleichen Projekt interessiert sind (auch den Client, von dem die Änderung ausging), über die erfolgte Änderung, indem er eine Update-Notification im entsprechenden Topic veröffentlicht. Auf Clientseite lauscht ein ChannelManager auf Nachrichten in den Topics des aktuellen Projekts und nimmt diese Update-Notification in Empfang.

8. Verteilung der Update-Nachicht innerhalb der Clients

a. ChannelManager informiert MessageController

b. MessageController informiert alle an der Nachricht interessierten Listener

9. Der Cache entfernt ggf. eine alte ungültige Version des Artefakts

10. Anforderung der neuen, geänderten Daten vom Server

a. Views fragen beim Model an.

b. Model delegiert an Cache

c. Cache holt die Daten über den WebService vom Server

11. Der Server holt die Daten aus der DB

a. Der Businesshandler delegiert die Anfrage an die entsprechende DB-Finder-Klasse

b. Der Finder liest die Daten aus der DB

12. Nachdem die ausgelesenen Daten an den Client zurückgegeben und an Model und Views verteilt worden sind, wird die Darstellung der Daten im GUI aktualisiert

Abbildung 18 stellt das Zusammenspiel von grafisch dar.

Es folgt eine detailliertere Gegenüberstellung von COINEDs Merkmalen und den technischen Anforderungen (TA), die sich bei der Umsetzung eines kollaboratives Rollenspiel ergeben.

TA1: Gemeinsame Sicht auf ein Diagramm

In COINED: Alle Benutzer, die gemeinsam ein Projekt bearbeiten, haben die gleiche Sicht auf das zugehörige Diagramm. Änderungen am Diagramm werden vom Server an die Clients mittels entsprechender Update-Notifcations propagiert. Änderungen können dabei sowohl räumlicher Natur (Objekte sind per Drag&Drop verschieb-/positionierbar) als auch inhaltlicher Natur sein (geänderte Objektzustände, geänderter Aktivitätsstaus, neue Nachrichten, etc.) Die Clients werten die Notifications aus, holen sich die neuen Daten vom Server und updaten ihre Diagrammdarstellung entsprechend.

TA2: Kommunikationsmedium für den Wissenstransfer

a: Graphische Visualisierung als Kommunikationsunterstützung

In COINED werden Nachrichtenfluss und Objektinteraktion in Diagrammen visualisiert. Diese Diagramme können später als Kommunikationsgrundlage dienen und zu Dokumentationszwecken eingesetzt werden

b: Protokolle der Interaktion als Kommunikationsunterstützung

TA3: Synchrone Kommunikation

COINED besitzt einen integrierten Chat. Chatnachrichten werden persistent und mit Bezug zum jeweils aktiven Objekt abgespeichert. Die Chatnachrichten werden in einer eigenen Ansicht jeweils mit Nickname, User-Icon und Zeitstempel angezeigt.

TA4: Awareness

In COINED: (a) In der Buddyliste wird rechts neben dem Benutzerbild jedes Benutzers sein Onlinestatus mit einem roten, grünen oder gelben Icon dargestellt. Rot bedeutet: Benutzer ist nicht eingeloggt – Gelb: Benutzer ist eingeloggt, befindet sich aber zurzeit in einem anderen Projekt – Grün: Benutzer ist eingeloggt und hat das gleiche Projekt geöffnet.

(b) Während einer Simulation kann man im Diagramm erkennen welches Objekt aktiv ist (Hintergrundfarbe wechselt von Gelb zu Orange, Stern erscheint vor dem Objektnamen). Da in der Repäsentation eines Objekts immer auch das Icon seines Directors angezeigt wird, kann jeder Benutzer jederzeit sehen, wer die aktuelle Kontrolle hat.

TA5: Modellierung von Rollen

In COINED: Ein Benutzer kann sich über das Kontextmenü im ClassView zum Director einer Klasse erklären. Damit übernimmt er die Kontrolle über die Klasse sowie alle zugehörigen Objekte, und er kann neue Objekte der Klasse erzeugen. Der Director ist für das Verhalten der Objekte einer Klasse verantwortlich. Wenn eins seiner Objekte eine Nachricht erhält, übernimmt er die Rolle des Objekts und bearbeitet und beantwortet die Nachricht. Die Director-Rollen werden durch die Anzeige der entsprechenden Benutzer-Icons visualisiert, sowohl in den Klassenrepräsentationen im ClassView, als auch in den Objektrepräsentationen im ObjectView und im DiagramView.

TA6: Synchronisation des Diagramms

Wie in TR1 beschrieben, werden Änderungen am Diagramm per Update-Notifications vom Server an die Clients propagiert. Wenn nun ein Benutzer an einem Client in einem Simulationschritt eine neue Nachricht abschickt, teilt der Client dem Server dieses Vorhaben über einen entsprechenden Request mit, die Nachricht wird als Parameter übergeben. Der Server speichert die Nachricht persistent in der DB ab und schickt anschließend Update-Notifications an alle betroffenen Clients. Die Clients werten die empfangene Notifcation aus und stellen einen Request an den Server um die Daten der neuen Nachricht abzurufen. Erst dann wird das GUI aktualisiert. JMS sorgt dafür das Notifications in der richtigen Reihenfolge ausgewertet werden

TA6: Code-Generierung

Im ClassView lässt sich auf Knopfdruck aus den, in der COINED-eigenen informalen Notation definierten, Klassen Java-Quellcode generieren. Es wird, sofern noch nicht existent, ein Eclipse-Projekt mit Java-Klassenrümpfe, Attribute und Methoden eingeschlossen, erzeugt. Die Integration von COINED in Eclipse ermöglicht es der Umgebung, mit der Generierung automatisch von der COINED-Perspektive in die Java-Perspektive zu wechseln. Der Anwender hat dort dann die Möglichkeit Eclipse in seiner klassischen Funktion als Java-IDE zu nutzen und er kann direkt mit der Auszuprogrammierung der Klassen beginnen.

Während der Simulation eines Progammablaufs werden sowohl die gesendeten Nachrichten, als auch die, von den Benutzern im Zuge der Nachrichtenbearbeitung vorgenommen, Zuweisungen aufgezeichnet, im HistoryView visualisiert und in der Datenbank persistent gespeichert. Diese Informationen können z. B als Grundlage für die Generierung von JUnit-Testcase dienen.

TA7: Visualisierung des Interaktionsflusses

Im Diagramm wird der Interaktions-/bzw. Nachrichtenfluss graphisch visualisiert. Die dynamische Hervorhebung (Hintergrundfarbe, Stern-Icon) des jeweils aktiven Objekts und der letzten Nachricht fokussiert den Blick des Anwenders auf den aktuellen Stand der Simulation. Nachrichten sind in absteigender Reihenfolge mit ihren Nummern an den Verbindungslinien zwischen Objekten aufgelistet. Um die Übersichtlichkeit des Diagramms im Falle vieler Nachrichten nicht einzuschränken, kann die Anzahl der angezeigten Nachrichten pro Verbindung über eine Benutzereinstellung individuell eingestellt werden. Anhand der Nachrichtennummern kann der Fluss schnell nachvollzogen werden.

TA9: History

Wie bereits in TA6 erwähnt, werden während der Simulation eines Progammablaufs sowohl die gesendeten Nachrichten als auch die, von den Benutzern im Zuge der Nachrichtenbearbeitung vorgenommenen, Zuweisungen aufgezeichnet und im HistoryView chronologisch aufgelistet. Der Nachrichtenfluss kann hier also vollständig nachvollzogen werden.

TA10: Usermanagement

In COINED müssen Benutzer sich über einen Login-Dialog mit ihren Accountinformationen (Nickname und Passwort) am COINED-Server authentifizieren, bevor sie den kooperativen Arbeitsbereich betreten dürfen. Vor der ersten Benutzung muss jeder Benutzer einen eigenen Account anlegen. Nach der erfolgreichen Authentifizierung kann der Benutzer ein Projekt öffnen, er nimmt damit automatisch an der aktuellen kooperativen Session der Projektmitglieder teil. Beim erstmaligen Betreten eines Projekts wird der Benutzer automatisch als Projektmitglied eingetragen und er wird entsprechend in der Buddyliste des Projekts aufgeführt. Benutzerinformationen, Projekte und die entsprechenden Zuordnungen werden vom Server verwaltet und persistent in der Datenbank gespeichert.

T11: Persistenz

COINED wurde als Client-/Server-Architektur umgesetzt. Alle Informationen (Benutzer, Projekte, Artefakte, Zuordnungen) werden immer zentral und persistent vom Server in einer SQL-Datenbank gespeichert. Dabei müssen Datenbank und COINED-Server nicht notwendigerweise auf demselben System laufen. Durch die zentrale, persistente Speicherung kann der asynchrone Zugriff unterstützt werden. So können die Anwender auch beim asynchronen Zugriff auf gemeinsame Projekte immer den letzten aktuellen Stand abrufen. Die Benutzer können zu jedem Zeitpunkt von jedem Ort (über das Internet) mit dem System arbeiten, unabhängig vom Online-Status anderer Gruppenmitglieder und einzelner Clients.

1.3.2 Verwendete Patterns und ihr Zusammenspiel

Groupwaresysteme unterstützen Gruppenprozesse, sie koordinieren die Kommunikation und die Kollaboration innerhalb von Gruppen. In „Patterns for Computer-Mediated Interaction" von Schümmer & Lukosch (2007) werden spezielle Entwurfsmuster (Pattern) für die Entwicklung von Groupwaresystem definiert. Im Folgenden geben wir eine Übersicht darüber, welche dieser Pattern in COINED verwendet wurden.

In COINED müssen Benutzer sich über einen Login-Dialog mit ihren Accountinformationen (Nickname und Passwort) am COINED-Server authentifizieren, bevor sie den gemeinsamen Arbeitsbereich betreten dürfen. So ist das System in der Lage, innerhalb der kooperativen Sessions jede Aktion einem bestimmten Benutzer zuzuordnen. Das ist eine der Grundvoraussetzungen, um Benutzer identifizierbar werden zu lassen.

Der angemeldeten Benutzer wird zum einen durch den Fettdruck seines Namens in der Repräsentation im BuddylistView und zum anderen durch die Anzeige in der Titelzeile des Eclipse-Fensters („logged in as <username>“) kenntlich gemacht.

Virtual Me

Jeder Anwender kann zur Beschreibung seiner virtuellen Identität ein Profil bearbeiten. In dem Profil hat er die Möglichkeit persönliche Informationen wie Email-Adresse, vollen Namen, sowie ein Bild zu hinterlegen. Dieses Bild wird dann überall zur visuellen Repräsentation des Benutzers verwendet, sowohl in der Buddyliste also auch in den Darstellungen seiner Klassen und Objekte. Wenn ein Benutzer kein eigenes Bild hinterlegt, wird ein Default-Bild angezeigt.

Shared Editor

Anwender können gleichzeitig Objekt-Positionen manipulieren. per Mediated Upates wird die Darstellung an allen Clients synchronisiert. Objekt-Positionen werden persistent in der Datenbank gespeichert.

Semantische Objekt-Manipulationen finden nicht konkurrierend statt, da ausschließlich der Director schreibenden Zugriff auf ein Objekt hat.

Floor Control

Der in COINED verwendete Kontrollflussmechanismus (nur der Director des gerade aktiven Objekts darf editieren) kann als Variante dieses Patterns ausgeleget werden.

Room

COINED-Projekte können als eine Ausprägung des Room-Patterns angesehen werden. Ein Projekt enthält Artefakte und Benutzer. Artefakte und Zustände werden persistent in der DB gespeichert, Projekte können sowohl synchron als auch asynchron bearbeitet werden. Zwischen den Benutzern eines Projekts existiert ein synchroner Kommunikationskanal, der integrierte Chat.

Embedded Chat

Mit dem Chat im ChatView bietet COINED den Anwendern die Möglichkeit der synchronen Kommunikation. Das Chatten erfolgt Projekt-bezogen, d.h. es werden nur Nachrichten von Projektteilnehmern verschickt und angezeigt. Die Nachrichten werden persistent in der Datenbank gespeichert.

User List

Wenn ein Benutzer ein COINED-Projekt öffnet, wird der BuddyListView mit den visuellen Repräsentationen aller Projektteilnehmer aktualisiert. Jeder Teilnehmer wird mit Namen und Benutzerbild aufgeführt. Ein Icon signalisiert jeweils den aktuellen Online-/Projekt-Status eines Benutzers. (Offline, Online und nicht das gleiche Projekt geöffnet, Online und gleiches Projekt geöffnet). Spezielle ClientListener überwachen die Zustände der Clients und sorgen für die dynamische Aktualisierung der Status-Icons, sowohl in Fällen in denen Benutzer sich ordnungsgemäß am Server an-/abmelden und Projekte betreten, als auch bei unerwarteten Fällen wie Verlust von Netzwerkverbindungen oder Systemabstürzen.

Über die BuddyListe ist also für jedes Projektmitglied klar erkennbar, wer sich aktuell mit im Projekt befindet und damit an der gemeinsamen Session teilnimmt. Dieses Bewusstsein fördert den freieren Umgang der Benutzer mit den gemeinsamen Artefakten.

Wir verwenden hier letztendlich eine Variante des User List Patterns, da die Benutzerrepäsentation nicht komplett aus der Liste entfernt wird, wenn ein Benutzer die Session, bzw. das Projekt verlässt, sondern stattdessen das Status-Icon entsprechend aktualisiert wird.

Interactive User Info

Über das Kontextmenü der Benutzerrepräsentationen im BuddyListView können die Benutzerprofile eingesehen werden.

Activity Log

In COINED wird eine sehr eingeschränkte Version des Patterns verwendet. Bestimmte modifizierende Benutzer-Aktivitäten (Zuweisungen, Nachrichten) werden im HistoryView protokolliert.

Persistent Session

In COINED arbeiten die Benutzer in kooperativen Sessions an Projekten. Die Ergebnisse (Artefakte, Zustandsänderungen, Abläufe) werden persistent auf dem Server in der Datenbank gespeichert. Dadurch wird es möglich die kooperativen Aktivitäten der letzten Session später zu reviewen oder fortzuführen. Es werden nur die Daten der jeweils letzten Session eines Projekts verwaltet, der Zugriff auf ältere Sessions wird nicht unterstützt.

State Transfer (aka “What’s up”)

Wenn ein Benutzer ein Projekt öffnet, wird der aktuelle Projektzustand vom Server geladen und zur Anzeige gebracht. Dass der Server immer über die aktuellste Version der gemeinsamen Daten verfügt, wird dadurch sichergestellt, dass Änderungen grundsätzlich erst wirksam werden, wenn sie erfolgreich in die DB weggeschrieben konnten. So können Benutzer problemlos zu einer laufenden kooperativen Sitzung dazustoßen, sie starten immer mit dem aktuellen Stand und konsistenten Daten.

Centralized Objects

Alle Artefakte (Klassen, Objekte, Nachrichten,…) werden zentral in einer Datenbank verwaltet. Der Server koordiniert die konkurrierenden Zugriffe und stellt die Artefakte auf Anfrage über eine Webservice-Schnittstelle bereit. Änderungen an gemeinsamen Artefakten kommuniziert der Server mithilfe von Update-Notifications über eine JMS-Schnittstelle an die interessierten Clients

Remote Subscription

Zur Verteilung von Nachrichten, die Änderungen am gemeinsamen Datenbestand betreffen, verwendet COINED Publish/Subscribe-Messaging, realisiert mit JMS (Java Messaging Service). Wenn ein Benutzer ein Projekt betritt, registriert sich der Client beim Server als Konsument für alle projekt-spezifischen Nachrichten. Die Nachrichten sind in Topics (ClassInfo, ObjectInfo, MessageInfo, UserInfo, usw) organisiert, die der Client jeweils abonniert. Wenn nun eine Änderung am Datenbestand ausgeführt wird, veröffentlicht der Server eine Update-Benachrichtung im entsprechenden Topic und das System sorgt dafür, dass alle Clients, die dieses Topic abonniert haben, die Nachricht erhalten.

Replicated Objects (aka “Replicate for Speed”)

Jeder Client verfügt über einen lokalen Cache, der die Artefakte aus den Ergebnissen der Serveranfragen zwischenspeichert. Klassen, die Daten benötigen, stellen Anfragen an den Cache, der diese wiederum an den Server weiterleitet, wenn er sie aktuell nicht bedienen kann. Der Cache erhält Update-Notifications vor allen anderen Message-Listenern, so dass er betroffene Artefakte entfernen kann und keine ungültigen Daten enthält. Wenn der nächste Zugriff auf ein nicht (oder nicht mehr) vorhandenes Artefakt erfolgt, wird es neu vom Server geladen. Auf die gecacheten Daten gibt es nur lesenden Zugriff. Modifikationen erfolgen immer erst nach Serverkommunikation.

Mediated Updates

Der Server ist die zentrale Instanz an der Clients sich anmelden und für den Empfang von Update-Nachrichten registrieren. Wenn ein Client lokale Daten manipuliert, schickt er einen Update-Request an den Server. Nach erfolgreicher Umsetzung des Requests verteilt der Server Update-Notifications an alle betroffenen Clients, genauer gesagt, er veröffentlicht die Nachricht in dem relevanten Topic und per JMS wird die Nachricht dann an alle Subscriber des Topics verteilt.

Der Server übernimmt hier also die Rolle des Mediators, der dafür sorgt, dass Update-Notfications zwischen Clients propagiert werden. Die Clients müssen sich untereinander nicht kennen.

Distributed Command

In COINED werden die Server-Requests zum Ändern und Abrufen der gemeinsamen Daten mithilfe eines WebServices realisiert. Ein Client ruft eine entfernte Service-Methode auf und der Server führt diese dann aus.

Commands werden allerdings nicht an Clients weitergeleitet, insofern handelt es sich nur um eine eingeschränkte Variante des Patterns.

Zusammenspiel der Patterns

Die verwendeten Patterns machen deutlich, dass COINEDs Hauptaugenmerk auf der zielgerichteten Unterstützung von synchroner verteilter Gruppenarbeit liegt. Eine verteilte Gruppe von Benutzern arbeitet in Projekten gemeinsam an zentral verwalteten Artefakten. Das Zusammenspiel der Patterns soll für die Umsetzung wichtiger Groupware-Konzepte sorgen, gerade auch im Umgang mit verteilten Gruppen. In verteilten Gruppen ist es z.B besonders wichtig, den Gruppenmitgliedern die Anwesenheit der anderen bewusst zu machen. Motivationsförderndes Gruppengefühl verliert sich leicht, wenn die Mitglieder alleine an verschiedenen Orten vor ihren Rechnern sitzen. Deshalb verwendet COINED bewusst einige Patterns, die auf die Förderung und den Erhalt des Gruppenbewusstseins abzielen (Virtual Me, User List, Interactive User Info, Sender Recognition,…).

Weitere Effekte, die im Zusammenspiel der Patterns angestrebt werden, sind die Anregung und Unterstützung weiterer Gruppenprozesse, wie Diskussion, Entscheidungsfindung und Kommunikation zwischen Gruppenmitgliedern.