UNIVERSITÄT DUISBURG-ESSEN FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN ABTEILUNG INFORMATIK UND ANGEWANDTE KOGNITIONSWISSENSCHAFT

Transkript

1 UNIVERSITÄT DUISBURG-ESSEN FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN ABTEILUNG INFORMATIK UND ANGEWANDTE KOGNITIONSWISSENSCHAFT Diplomarbeit Redesign eines Systems zum Management kollaborativer Sitzungen mit FreeStyler Christopher Krüger Matrikelnummer: xxxxxxxx Abteilung Informatik und angewandte Kognitionswissenschaft Fakultät für Ingenieurwissenschaften Universität Duisburg-Essen 27. März 2013 Betreuer: Prof. Dr. H. U. Hoppe Dipl.-Inform. Adam Giemza Dipl.-Math. Tilman Göhnert

2

3 Inhaltsverzeichnis 1. Einleitung Motivation Aufgabenstellung Aufbau der Arbeit Grundlagen Verteilte Systeme Kommunikationsprotokolle Internet Protocol Transmission Control Protocol User Datagram Protocol Kommunikationsformen in lokalen Netzen IP-Multicast Reliable Multicasting Middleware FreeStyler Plugins Synchronisation Groupware Grundlegende und verwandte Arbeiten AdhocMM (CoolModes) Dokumentenverwaltung für Computer-integrated Classrooms Group Scribbles, SceDer und COML SMART Classroom Suite INiS Edubuntu und Epoptes Konzept Szenario Funktionale und nicht-funktionale Anforderungen Beschreibung des Systems Komponenten Visuelle Sprache Unterstützung der Unterrichtsplanung Unterstützung des Unterrichtsbeginns Unterstützung des Unterrichts Unterstützung des Unterrichtsendes Exkurs: Rechtliche Grundlage für die Erstellung von Screenshots Technische Anforderungen Anforderungen an die Middleware Diskussion verschiedener Middleware-Optionen iii

4 Inhaltsverzeichnis Reliable Multicast Systeme Architektur Implementierung AdhocLib Protokoll-Stack Netzwerk-Subsystem Service Discovery AdhocMm Austeilen und Einsammeln von Arbeitsmappen Sitzungsverwaltung und Betriebsmodi Verwendung bestehender Sitzungen Wiederherstellung einer laufenden Sitzungskonguration Palette und allgemeine Handhabung Knoten und kontextabhängige Optionen AdhocStudent Sitzungsverwaltung Arbeitsmappen verwalten Statistik Palette Voraussetzungen und Empfehlungen für den Einsatz Erprobung des Systems Testszenario und Durchführung Resümee Zusammenfassung und Ausblick Zusammenfassung Ausblick A. Interviews 81 A.1. Kennzahlen und Fakten A.2. Beurteilung der praktischen Relevanz B. Aufgabenstellungen 83 B.1. Lehrer-Szenario B.2. Schüler-Szenario Literaturverzeichnis 85 Eidesstattliche Erklärung 91 iv

5 Abbildungsverzeichnis 2.1. Kommunikationsformen in lokalen Netzwerken Ebenen und Funktionen von Middleware in verteilten Systemen Screenshot des FreeStylers mit geladenem Petri-Netz Plugin Graphische Elemente des AdhocMM Plugins für Cool Modes Screenshot der GroupScribbles GUI Screenshot des Scenario Designer Tools Screenshot der SMART Notebook GUI Screenshot der INiS Management Software Screenshot der Epoptes Management Software Komponenten des Systems Elemente der visuellen Sprache Beispiel für einen durch AdhocMm unterbundenen Graph Versand einer Nachricht an einen Cluster Systemarchitektur mit den Komponenten FreeStyler, MatchMaker und JGroups Übersicht über die wichtigsten Elemente des verwendeten Protokoll-Stacks Schichtenarchitektur des Netzwerk-Subsystems als UML-Klassendiagramm Service Discovery als UML-Sequenzdiagramm Programmstruktur des AdhocMm-Plugins als UML-Klassendiagramm Komponenten der Sitzungsverwaltung als UML-Klassendiagramm Sitzungsstart als UML-Sequenzdiagramm Sitzungsbeitritt als UML-Sequenzdiagramm Dialog zur Auswahl einer bestehenden Sitzung Aufgabenorientierte Reiter der AdhocMm-Palette Kongurationsmöglichkeiten und Statistik innerhalb der AdhocMm-Palette Kontextabhängige Optionen der Knoten Programmstruktur des AdhocStudent-Plugins als UML-Klassendiagramm Screenshot des FreeStylers mit AdhocStudent-Plugin und geladenem Aktivitätsdiagramm Aufbau des Lernszenarios (AdhocMm) AdhocMm im Kollaborationsmodus mit ausgeteilten Arbeitsmappen FreeStyler mit AdhocStudent-Plugin und gekoppeltem Arbeitsbereich Screenshot eines Schülerdesktops mit geönetem Wikipedia-Artikel Sitzungskonguration, die allen Schülern den Zutritt in die Sitzung erlaubt 74 v

6

7 1. Einleitung 1.1. Motivation Der Aufgabenkatalog von Lehrkräften im Schulalltag beinhaltet neben der eigentlichen Vermittlung des Lehrstoes, die Planung und Koordination der Lernaktivitäten der Schülerinnen und Schüler. Hierzu zählt die Vergabe der Arbeitsaufträge, die Bereitstellung der zu bearbeitenden Unterrichtsmaterialien, sowie die Beobachtung des Unterrichtsverlaufs mit entsprechender Unterstützung. Diese Aufgaben werden in kollaborativen Lernszenarien durch die Planung und Organisation der Gruppenarbeiten ergänzt. Kuhn [Kuh08, S. 199 f.] stellt fest, dass sich virtuelle Lernplattformen zwar um die Unterstützung der Lehrkräfte bemühen, diese Systeme allerdings in erster Linie bei langfristigen Arbeitsphasen zu einer Entlastung führen. Kuhn postuliert weiterhin, [...] dass kurzfristige Kollaboration im Schulalltag nicht zum Einsatz kommt, da bisher der administrative und zeitliche Aufwand zu hoch war [...]. Mit Lehrkräften im Rahmen dieser Arbeit durchgeführte Interviews stützen nicht nur diese Aussage, sondern weisen darüber hinaus darauf hin, dass weitere administrative Aktivitäten zu Verzögerungen des Unterrichts führen. Um eine spezische Unterrichtsplanung zu ermöglichen und zeitliche Verzögerungen während der Durchführung zu minimieren, sind spezialisierte Classroom Management Systeme nötig. Um eine hohe Akzeptanz von Lehrkräften zu nden, sollten sich diese Werkzeuge in die bestehenden Lernumgebungen integrieren. Diese Arbeit konzipiert und realisiert ein solches Classroom Management System für die kollaborative Modellierungsumgebung FreeStyler und zielt auf die Unterstützung von Einzelarbeits- und Gruppenarbeitsszenarien ab Aufgabenstellung Ziel der Arbeit ist die Konzeption und Entwicklung eines Systems zum Management kollaborativer Sitzungen. Der Einsatzort für dieses System ist der computergestützte Schulunterricht. Hierbei wird der FreeStyler als zugrundeliegendes Rahmenwerk vorausgesetzt und die zu entwickelnde Software soll die Steuerung von FreeStyler-Instanzen über das Netzwerk ermöglichen. Zur Erfüllung des Ziels ergeben sich die folgenden Teilaufgaben: Anforderungsanalyse Um eine hohe praktische Relevanz der Systemfunktionen zu erzielen, muss eine Erfassung der domänenspezischen Anforderungen erfolgen. Zu diesem Zweck sind Interviews mit Lehrkräften zu führen, die den FreeStyler aktiv im Unterricht einsetzen. 1

8 1. Einleitung Konzeption Diese Teilaufgabe umfasst die Erstellung eines Konzepts für ein Classroom Management System. Dieses System muss die Vorbereitung, Durchführung und Bewertung von kollaborativen Sitzungen ermöglichen. Dies beinhaltet die Reorganisation von Gruppen während des Unterrichts. Darüber hinaus sollen Funktionen entworfen werden, um vorbereitete Dokumente an andere FreeStyler-Instanzen verteilen und wieder zentral einsammeln zu können. Weiterhin soll der Lernfortschritt über entsprechende Monitoring-Werkzeuge verfolgt werden können, um den Schülern bei Bedarf Unterstützung zukommen zu lassen. Auswahl zu verwendender Technologien Um komfortable und störungsfreie Funktionen zur Steuerung von FreeStyler-Instanzen realisieren zu können, müssen die notwendigen Anforderungen an den Kommunikationsprozess identiziert werden. Auf Basis dieser Anforderungen sind geeignete Kommunikationsbibliotheken und -verfahren auszuwählen. Implementierung Mit Hilfe der gewählten Middleware-Lösung ist das konzipierte System als FreeStyler-Plugin umzusetzen. Erprobung des Produkts Das entwickelte System ist zusammen mit ausgewählten Nutzern zu erproben und zu beurteilen Aufbau der Arbeit Die vorliegende Ausarbeitung verfügt über sechs Kapitel. Das aktuelle Kapitel bietet einen ersten Einblick in das Thema dieser Arbeit. Im Anschluss daran werden sowohl die technischen, als auch konzeptionellen Grundlagen vorgestellt, auf denen diese Arbeit aufbaut. Weiterhin erfolgt eine Übersicht über grundlegende und verwandte Arbeiten, die Einuss auf das entwickelte System genommen haben. Kapitel drei stellt verschiedene Anforderungen an ein Classroom Management System und liefert eine Beschreibung der inhaltlichen, als auch technischen Charakteristika des gewählten Ansatzes und stellt die System-Architektur vor. Im vierten Kapitel werden die implementierten Plugins und der Kommunikationsprozess erläutert. Hierbei erfolgt eine Vorstellung der wichtigsten Klassen und Funktionen der einzelnen Komponenten, sowie das Design und die Bedienung der Benutzungsschnittstellen. Abschlieÿend werden einige Besonderheiten des Systems erläutert und Voraussetzungen aufgestellt, die für den Einsatz erfüllt sein müssen. Im Anschluss daran beschreibt Kapitel fünf den Aufbau und das konstruierte Szenario einer technischen Erprobung, die im Rahmen einer unterrichtsähnlichen Situation durchgeführt wurde. Das letzte Kapitel fasst die Ergebnisse der geleisteten Arbeit zusammen und bietet einen Ausblick auf mögliche Arbeiten, die das realisierte System erweitern. 2

9 2. Grundlagen Auf den nachfolgenden Seiten erfolgt eine Beschreibung verschiedener Technologien und Konzepte, die im Rahmen dieser Arbeit von Bedeutung sind. Zu Beginn dieses Kapitels wird eine allgemeine Beschreibung verteilter Systeme geliefert. Daraufhin werden die wichtigsten Kommunikationsprotokolle und - formen vorgestellt und liefern notwendige Kenntnisse um den Begri der Middleware einzuführen. Im Anschluss folgt in Abschnitt 2.2 die Vorstellung der kollaborativen Modellierungsumgebung FreeStyler, die das zugrundeliegende Rahmenwerk für das entwickelte System darstellt. Abschnitt 2.3 liefert eine Beschreibung der Begrie Groupware und Awareness. Abschlieÿend wird das, als Ausgangspunkt für das entwickelte System dienende, Cool Modes-Plugin AdhocMM vorgestellt, sowie einige artverwandte Systeme diskutiert Verteilte Systeme In der heutigen Zeit sind vernetzte Computer allgegenwärtig. Neben dem Arbeitsplatz- PC, welcher mit dem Unternehmensnetzwerk verbunden ist, und dem Internet-fähigen Computer zu Hause, nden sich verteilte Anwendungen auch auf weniger oensichtlichen Geräten, wie beispielsweise Mobiltelefonen, Digitalkameras und innerhalb von Autos [CDK01, S. 5 f.]. Gerade durch diese Vielfältigkeit ergeben sich für verteilte Systeme nur relativ abstrakte Denitionen. So beschreiben Coulouris et al. ein verteiltes System wie folgt [CDK01, S. 2]: We dene a distributed system as one in which hardware or software components located at networked computers communicate and coordinate their actions only by passing messages. So unterschiedlich diese Systeme auch sein mögen, gleichen sie sich doch in der Motivation der Vernetzung. Und zwar sollen Ressourcen von verschiedenen Systemen gemeinsam genutzt werden, wobei der Begri Ressource sowohl Hardware-Komponenten wie Drucker oder Kameras, als auch Informationsobjekte mit einschlieÿt [CDK01, S. 2 f.]. Die oben genannte Denition bietet zwei verschiedene Sichtweisen für die nähere Betrachtung von verteilten Systemen an. Auf der einen Seite können die technischen Aspekte in den Vordergrund gestellt werden. Diese Betrachtungsweise umfasst in der Regel mehrere Computersysteme, welche Rechenoperationen unabhängig voneinander durchführen. Diese Systeme sind über ein bestimmtes Medium miteinander verbunden und auf diese Weise in der Lage, Signale untereinander auszutauschen. Das Medium selbst hat Einuss auf die zur Verfügung stehenden Kommunikationsformen. Verteilte Systeme sind weder in Bezug auf die Art oder Homogenität der eingesetzten Komponenten, noch auf die Art des Mediums beschränkt. 3

10 2. Grundlagen Auf der anderen Seite können verteilte Systeme auf konzeptioneller Ebene betrachtet werden. Hierbei wird die Zusammenarbeit der Komponenten und die entsprechende Koordination in den Fokus gestellt. Diese Betrachtungsweise führt zu einer Klassizierung verteilter Systeme auf Basis ihrer Architektur in zentralisierte und dezentralisierte Systeme. In Abhängigkeit von der Architektur ergeben sich verschiedene Rollen, welche von den einzelnen Komponenten eingenommen werden. Im Folgenden werden zuerst verschiedene Kommunikationsprotokolle und -formen beschrieben, welche im Rahmen dieser Arbeit von Relevanz sind. Daran anschlieÿend werden Einblicke in die verschiedenen Architekturmodelle gewährt und deren Vor- und Nachteile diskutiert. Das dargelegte Wissen bildet das Fundament für die Einführung des Begris Middleware und wird anhand zweier - im Kontext dieser Arbeit relevanten - Middleware-Architekturen vertieft Kommunikationsprotokolle Ein Kommunikationsprotokoll lässt sich als Folge von fest vorgegebenen Schritten eines Nachrichtenaustauschs für einen bestimmten Zweck begreifen [Bra05, S. 62]. Die Spezikation eines Protokolls umfasst sowohl die Sequenzen von Nachrichten, welche zwischen den Kommunikationspartnern ausgetauscht werden, als auch das Datenformat der jeweiligen Nachrichten. Protokolle erfüllen den Zweck eine gemeinsame Basis für die Kommunikation zwischen verschiedenen Instanzen zu schaen und auf diese Weise die Interoperabilität zwischen verschiedenen Systemen sicherzustellen [CDK01, S. 67 f.]. Um eine gemeinsame Grundlage für die Kommunikation zu schaen und hierdurch die Vernetzung von Systemen verschiedener Hersteller zu fördern, wurde von der Internationalen Organisation für Normung (ISO) 1 das Open-Systems-Interconnection Referenzmodell [fsi94] eingeführt. Dieses Modell unterteilt die Kommunikation in die sieben aufeinander aufbauenden Ebenen Physical, Data Link, Network, Transport, Session, Presentation und Application. Für jede Ebene wurden grundsätzliche Aufgaben deniert, auf deren Grundlage eine Klassizierung von Netzwerkprotokollen in eine oder mehrere dieser Schichten erfolgen kann. Im Rahmen dieser Arbeit sind die Ebenen Network und Transport von besonderer Bedeutung und sollen an dieser Stelle genauer beschrieben werden. Network Die Netzwerkschicht ist für die eindeutige Identizierung der Teilnehmer eines Netzwerks und den Auf- und Abbau logischer Verbindungskanäle zwischen Sender und Empfänger zuständig. Dies beinhaltet die Vermittlung der Nachrichten über das globale Kommunikationsnetz (Routing). Darüber hinaus zeichnet die Netzwerkschicht Verantwortung für die Aufteilung der Daten in einzelne Pakete und eine grundlegende Fehlerbehandlung. Als wichtige Vertreter seien hier X.25 [Int96], sowie das im späteren Verlauf näher beschriebene Internet-Protocol (IP) zu nennen [Zen00, S. 313 f.]

11 2.1. Verteilte Systeme Transport Aufgabe der Transportschicht ist die Übermittlung von Nachrichten zwischen logischen Benutzern des Netzwerks. Im weiteren Verlauf werden unter solchen logischen Benutzern laufende Prozesse auf einem Computersystem verstanden. Neben der Adressierung dieser logischen Benutzer, bieten Protokolle dieser Ebene mitunter Qualitätszusicherungen für den Transport der Nachrichten an. Zu den bekanntesten Vertretern zählen das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP) Internet Protocol In der Praxis sind Netzwerke häug in verschiedene Segmente unterteilt um vorhandene Systeme aus Sicherheitsgründen zu isolieren oder die Netzwerklast innerhalb der Segmente gering zu halten und auf diese Weise eine höhere Performance zu erreichen. Die einzelnen Segmente sind physikalisch oder logisch voneinander getrennt und die Kommunikation zwischen den Segmenten ist nur über entsprechende Router möglich. Um Nachrichten zwischen verschiedenen Netzwerken oder Segmenten zu übertragen, kommt in Netzwerken häug das Internet Protocol (IP) zum Einsatz. Hierbei existieren die 1981 denierte Version 4 [Int81b], welche auch als IPv4 bezeichnet wird, und die 1998 standardisierte Version 6 (IPv6) [Int98]. Beide Protokolle sind der Netzwerkschicht des OSI-Referenzmodells zuzuordnen und ermöglichen das sogenannte Internetwork Routing, also die Vermittlung von Paketen zwischen verschiedenen Teilnetzen. Um Hosts über Netzwerkgrenzen hinaus eindeutig zu identizieren und eine Adressierung zu ermöglichen, deniert der IP-Standard sogenannte IP-Adressen. Soll eine Nachricht an einen Host in einem anderen Netzwerk gesendet werden, so wird die Adresse des Empfängers in die zu übermittelnde Nachricht kodiert. Alle Stationen, die eine Nachricht auf dem Weg vom Sender zum Empfänger passiert, nutzen diese Adresse für das Routing der Nachricht durch das Netzwerk. Die Gröÿe des Adressraumes ist abhängig von der eingesetzten IP-Version und liegt im Falle von IPv4 bei 32-Bit, während IPv6 eine Adressierungsgröÿe von 128-Bit verwendet. Diese Adressräume wurden allerdings von der Internet Assigned Numbers Authority (IANA) 2 eingeschränkt, indem bestimmte Adressbereiche speziellen Anwendungsfällen zugeordnet wurden ([Int10] bzw. [Int08a]). So existieren beispielsweise spezielle Adressen für die Adressierung aller Hosts in einem Netzwerk, wie auch einzelner Gruppen. Letztere kommen für das, im weiteren Verlauf dieser Arbeit näher beschriebene, IP-Multicastings zur Anwendung. Beim Internet Protocol handelt es sich um ein verbindungsloses, unzuverlässiges Packet- Delivery-System, das nach Comer [Com03, S. 120] anfällig für folgende Fehler ist: Paketverlust Pakete können auf dem Weg vom Sender zum Empfänger verloren gehen. Dies tritt speziell in stark belasteten Netzwerken oder aufgrund fehlerhafter Netzwerkinstallationen auf

12 2. Grundlagen Paketverzögerung Beispielsweise durch eine hohe Netzwerklast kann es während der Übertragung zu Verzögerungen kommen. Paketduplizierung Der mehrfache Empfang eines Pakets ist möglich, beispielsweise aufgrund störanfälliger Netzwerkhardware. Falsche Reihenfolge der Zustellung Wird die Übertragung von Paketen verzögert oder werden verschiedene Routen verwendet, können Pakete in falscher Reihenfolge beim Empfänger eingehen. Zwar scheinen diese möglichen Fehler auf den ersten Blick auf Schwachpunkte des Designs hinzudeuten, doch erwächst hieraus die groÿe Flexibilität von IP. Der Fokus wurde auf die Vermittlung von Paketen zwischen verschiedenen Netzwerken gesetzt. Werden entsprechende Funktionen zur Fehlerbehandlung benötigt, so können diese bei Bedarf durch höhere Schichten des OSI-Referenzmodells verwirklicht werden. Ein Protokoll, das genau diese Funktionen einführt ist das Transmission Control Protocol Transmission Control Protocol Möchte ein Computerprogramm mit einer entfernten Anwendung kommunizieren, werden die Nachrichten unter Zuhilfenahme der Funktionen der Netzwerkschicht an den Zielrechner übermittelt. Allerdings können auf diesem Rechner mehrere Anwendungsprozesse in der Lage sein, Netzwerknachrichten zu verarbeiten. Um also eine Prozesszu-Prozess-Kommunikation zu ermöglichen, ist ein weiterer Adressierungsmechanismus notwendig. Als Protokoll der Transportschicht des OSI-Referenzmodells ist das Transmission Control Protocol (TCP) [Int81c] für die Prozess-zu-Prozess-Kommunikation zuständig. Zur Adressierung eines entfernten Prozesses werden sogenannte Ports verwendet. Hierbei handelt es sich um 16-Bit lange Nummern, welche in die Nachrichten kodiert werden und eine eindeutige Zuordnung zu einem laufenden Prozess gestatten. Darüber hinaus verfügt TCP über wichtige Charakteristika, die eine Behandlung der in Abschnitt aufgezählten Fehler ermöglichen. Verbindungsorientiert Vor der eigentlichen Datenübertragung führt TCP einen sogenannten Handshake durch, wobei die beiden Hosts Sequenznummern austauschen. Mit Beendigung des Handshakes ist die Verbindung aufgebaut und die eigentliche Datenübertragung kann beginnen. Nach erfolgter Datenübertragung schlieÿen die beiden Teilnehmer die bestehende Verbindung durch einen modizierten Handshake-Mechanismus wieder [Com03, S. 242.]. 6

13 2.1. Verteilte Systeme Zuverlässig Soll eine Nachricht via TCP übertragen werden, sorgt die TCP-Implementierung für eine Aufteilung der Daten in einzelne Segmente, welche mit einer Sequenznummer versehen werden. Passieren die Segmente das Netzwerk auf unterschiedlichen Routen, so nutzt der Empfänger diese Sequenznummern zur Wiederherstellung der richtigen Reihenfolge. Darüber hinaus kann der Zielrechner mit Hilfe dieser Nummern duplizierte Pakete erkennen. Eingehende Pakete müssen vom Empfänger bestätigt werden. Erhält der Sender nach einer bestimmten Zeitspanne keine Bestätigung, sendet er das entsprechende Paket erneut[cdk01, S. 105 f.]. Die von TCP eingeführten Sicherheitsmaÿnahmen ermöglichen den zuverlässigen Transport von Nachrichten, wirken sich allerdings negativ auf die Geschwindigkeit der Datenübertragung aus. Diese Eigenschaften machen TCP zu einer häug verwendeten, aber nicht für alle Bereiche brauchbaren Lösung. Beispiele für Protokolle die auf TCP aufsetzen sind das Hypertext Transfer Protocol (HTTP) [Int81a] zur Übermittlung von Webseiten und das für den -Versand zuständige Simple Mail Transfer Protocol (SMTP) [Int08b] User Datagram Protocol Das User Datagram Protocol (UDP) [Int80] stellt ein weiteres Protokoll der Transportschicht dar, das mit Blick auf eine möglichst hohe Geschwindigkeit konzipiert wurde. Dieses verbindungslose Transportprotokoll bietet neben der ebenfalls durch Ports realisierten Prozess-zu-Prozess-Kommunikation die Möglichkeit, fehlerhaft übertragene Pakete zu erkennen. Die Geschwindigkeit erkauft sich UDP auf Kosten der Qualität, indem auf Mechanismen zur Sortierung oder Retransmission von Paketen verzichtet wird. Üblicherweise kommt UDP in Bereichen zum Einsatz, in denen der Verlust einzelner Datagramme toleriert werden kann. Als Beispiele hierfür seien die Namensauösung des Domain Name System (DNS) ([Int87a] bzw. [Int87b]) und die Umsetzung von Audiound Videostreaming via Real-Time Transport Protocol (RTP) [Int03] genannt Kommunikationsformen in lokalen Netzen Sollen mehrere Komponenten eines verteilten Systems ihre Aktionen koordinieren, so werden Nachrichten zwischen diesen Stationen ausgetauscht. Dabei können verschiedene Kommunikationsformen unterschieden werden, die sich aus der Anzahl der zu kontaktierenden Hosts ergeben. Nach [Cis01, S. 74] ergeben sich für lokale Netzwerke die folgenden Formen: Unicast Soll eine Nachricht an ein einzelnes System gesendet werden, so wird dies als Unicast-Übertragung bezeichnet. Hierfür wird als Ziel der Nachricht die Unicast-Adresse des entfernten Rechners speziziert. Broadcast Sollen hingegen alle Rechner innerhalb des Netzwerks kontaktiert werden, so ist von einer Broadcast-Übertragung die Rede. Zur Adressierung wird eine spezielle Broadcast-Adresse angegeben, welche der Netzwerk-Infrastruktur signalisiert, dass das Paket an alle Stationen geutet werden soll. 7

14 2. Grundlagen Multicast Als Multicast-Übertragung wird der Versand einer Nachricht an eine bestimmte Anzahl von Hosts bezeichnet. Dabei werden spezielle Multicast-Adressen zur Adressierung verwendet, auf deren Grundlage die Netzwerk-Infrastruktur Entscheidungen zum Routing von Paketen trit. Die Unterstützung von Multicasting ist abhängig von der konkreten Hardware. Unicast Broadcast Multicast Abbildung 2.1.: Kommunikationsformen in lokalen Netzwerken IP-Multicast Als eine Form der Point-to-Multipoint-Kommunikation ermöglicht das Multicasting den ezienten Versand von Nachrichten an eine Gruppe von Hosts in einem Netzwerk. Anstatt mehrere einzelne Sendeoperationen durchzuführen, reicht der Versand einer einzelnen Nachricht. Hierdurch ergibt sich eine geringere Netzwerklast, da eine Nachricht eine Kante des Netzwerkgraphen nur einmal passiert. Darüber hinaus ndet die Auslieferung der Nachrichten an die Gruppenteilnehmer in einer kürzeren Zeitspanne statt [CDK01, S. 436 f.]. Auch muss ein Computer kein Wissen über die Mitglieder einer Gruppe haben, um eine Nachricht an alle Mitglieder zu kontaktieren [FJL + 97]. Generell gilt es beim Multicasting zwischen Hardware-Multicasting und IP-Multicasting zu dierenzieren. Hardware-basiertes Multipoint-Delivery ist eine Technik, die auf Data- Link-Ebene des OSI-Modells stattndet und von der eingesetzten Hardware unterstützt werden muss. Zur Adressierung einer Multicast-Gruppe werden spezielle HardwareAdressen verwendet. Die Nachrichten werden von der Netzwerk-Infrastruktur an die Gruppenteilnehmer innerhalb des jeweiligen Netzwerksegments übermittelt [Com03, S. 316 f.]. IP-Multicasting [Int89] stellt eine Abstraktion des Hardware-Multicastings auf Interconnected Networks dar. Zur Adressierung einer Multicast-Gruppe werden IP-Adressen aus einem speziellen Multicast-Adressraum verwendet. Für IPv4 sind diese Adressen dadurch gekennzeichnet, dass die vier höchstwertigen Bits 1110 entsprechen, woraus ein Adressbereich von bis resultiert. Während der Versand von Nachrichten an eine Multicast-Gruppe ohne Weiteres möglich ist, muss ein Computer einer Gruppe explizit beitreten, um Gruppennachrichten zu 8

15 2.1. Verteilte Systeme empfangen. Das Internet Group Management Protocol (IGMP) [Int02] ist für die Teilnahme an einer Multicast-Gruppe zuständig und ermöglicht es einem Host, Nachrichten verschiedener Gruppen zu abonnieren. Ein Rechner informiert die anderen Netzwerkteilnehmer über seine Gruppenmitgliedschaft, indem er eine IGMP-Benachrichtigung mit der entsprechenden Gruppen-Adresse per Multicast versendet. Nun gilt es zwei Fälle zu unterscheiden. Benden sich die Mitglieder der Gruppe alle im gleichen physischen Netzwerk, so wird die weitere Kommunikation komplett durch die, von der Netzwerk-Hardware bereitgestellten Multicasting-Mechanismen durchgeführt. Hierzu zählen Hardware-Multicast, Broadcast bzw. Unicast. Netzwerk-Switches können IGMP-Beitrittsmeldungen zur Verbesserung der Ezienz auswerten und somit Nachrichten gezielt an die Gruppenmitglieder zustellen. Dehnt sich die Multicast-Gruppe hingegen über mehrere Netzwerkpartitionen aus, werden spezielle Multicast-Router zur Weiterleitung der Nachrichten benötigt. Die Router werten die IGMP-Beitrittsmeldungen aus und tauschen untereinander die Multicast- Gruppenmitgliedschaften aus, um Nachrichten gezielt in andere Subnetze zu routen. Darüber hinaus prüfen die Router in regelmäÿigen Abständen, ob noch Mitglieder einer Multicast-Gruppe verbunden sind und aktualisieren entsprechend ihre Routing-Tabellen [Com03, S. 322.]. Ein Host besitzt seit IGMP Version 2 [Int97] die Möglichkeit, eine Gruppe durch eine entsprechende Nachricht aktiv zu verlassen Reliable Multicasting Während der zuverlässige Versand von Unicast-Nachrichten leicht mit Hilfe von TCP realisiert werden kann, bietet der Einsatz dieses Transportprotokolls aufgrund mangelnder Point-to-Multipoint Unterstützung keine gangbare Lösung für IP-Multicasting. Dementsprechend bietet sich für die Entwicklung von IP-Multicast Anwendungen lediglich UDP als Transportprotokoll an [CDK01, S. 154]. Das führt dazu, dass IP-Multicasting per se als unzuverlässige Kommunikationsform anzusehen ist und keine Behandlung der in Abschnitt aufgezeigten Fehler bieten kann. Sollen Nachrichten zuverlässig an eine Gruppe von Hosts übermittelt werden, müssen zusätzliche Verfahren eingeführt werden. Bevor auf Methoden eingegangen wird, die eine zuverlässige Point-to-Multipoint Kommunikation ermöglichen soll der Begri der Zuverlässigkeit genauer untersucht werden. So beschreiben Segall und Awerbuch ein entsprechendes Protokoll als zuverlässig, wenn es die folgenden Eigenschaften aufweist [SA83]: Completeness Alle Zielrechner erhalten die Nachrichten in der Reihenfolge, in der sie vom Quellrechner versandt wurden. Es werden alle Nachrichten empfangen und keine Duplikate einer Nachricht existieren. Finiteness Alle Zielrechner erhalten alle Nachrichten des Empfängers in endlicher Zeit. 9

16 2. Grundlagen Für Point-to-Point Transportprotokolle wie TCP werden diese Eigenschaften durch den Einsatz sogenannter positive acknowledgements (ACK) erzielt. Dabei sendet der Empfänger für einzelne oder mehrere zusammenhängende Pakete eine Empfangsbestätigung an den Sender. Erhält der Sender innerhalb einer bestimmten Zeitspanne keine solche Bestätigung sendet er die Daten erneut. Diese Vorgehensweise lässt sich zwar technisch auf die Point-to-Multipoint-Kommunikation übertragen, bietet allerdings keine skalierbare Fehlerbehandlung. Speziell in gröÿeren Multicast-Gruppen wird der Sender einer Nachricht mit Empfangsbestätigungen der anderen Gruppenmitglieder überutet, weshalb dieses Problem als ACK Implosion bezeichnet wird [Pal03, S. 159]. Stattdessen wird für Reliable Multicasting häug auf die Nutzung von negative acknowledgements (NACK) zurückgegrien, wie z.b. das Pragmatic General Multicast (PGM) Protokoll [Int01]. Hierbei verzichten die Empfänger auf den Versand von Empfangsbestätigungen und senden stattdessen nur Benachrichtigungen falls Pakete ausbleiben. Die Detektion fehlender Pakete geschieht - wie bei positive acknowledgements auch - mit Hilfe der Sequenznummern, welche ebenfalls zur Erkennung von Duplikaten und zur Wiederherstellung der korrekten Reihenfolge verwendet werden [DDC97] Middleware Coulouris, Dollimore und Kindberg beschreiben den Begri Middleware wie folgt [CDK01, S. 16 f.]: The term middleware applies to a software layer that provides a programming abstraction as well as masking the heterogeneity of the underlying networks, hardware, operating systems and programming languages. Demzufolge bietet eine Middleware eine Abstraktion von der zugrundeliegenden Hardund Software der Komponenten eines verteilten Systems. Dies beinhaltet sowohl die Bereitstellung eines Kommunikationsprotokolls zum Nachrichtenaustausch, als auch die Darstellung der zu übermittelnden Daten. Die von der Middleware bereitgestellten Kommunikationsmechanismen abstrahieren von den darunterliegenden Netzwerkprotokollen wie UDP oder TCP und bieten darauf aufbauende komfortablere Programmierschnittstellen an. Eine entsprechende Datenrepräsentation kann den Austausch von Daten zwischen verschiedenen Betriebssystemen ermöglichen. Aus diesen Funktionen wird ersichtlich, dass es sich bei der Middleware um eine Software-Schicht unterhalb der Anwendungsprogramme handelt und auf den Kommunikationsmethoden des jeweiligen Betriebssystems aufsetzt. Eine graphische Darstellung dieser Einordnung ndet sich in Abbildung 2.2. Generell können Middleware-Lösungen in zentralisierte und dezentralisierte Architekturen unterteilt werden. Die reinste Ausprägung einer zentralen Architektur stellt das Client-Server-Modell dar, während Peer-to-Peer-Systeme das andere Ende des Spektrums bilden. Dazwischen existieren eine Vielzahl weiterer Modelle, die Mischformen dieser beiden Ansätze darstellen. Taylor nennt drei Aspekte zur Einteilung von Middleware in eines der Architekturmodelle [Tay04, S. 6.]. 10

17 2.1. Verteilte Systeme Applications RMI, RPC and events Request reply protocol External data representation Middleware layers Operating System Abbildung 2.2.: Ebenen und Funktionen von Middleware in verteilten Systemen (nach [CDK01, S. 167]) Resource Discovery Zu Beginn dieses Kapitels wurde der Einsatz vernetzter Systeme durch die gemeinsame Nutzung von Ressourcen motiviert. Um verfügbare Ressourcen wie zum Beispiel Dienste innerhalb eines verteilten Systems zu nutzen, muss ein Mechanismus zum Aunden dieser Ressourcen existieren. Resource Availability Die Verfügbarkeit von Ressourcen ist ein wichtiger Punkt beim Vergleich verteilter Architekturen und wird sowohl durch die Verteilung der Ressourcen auf verschiedenen Systemen als auch durch den Zugri auf diese beeinusst. Resource Communication Die Kommunikation zwischen einzelnen Ressourcen kann auf zwei Arten erfolgen. Zum einen durch den Einsatz einer Broker-Architektur, bei der die Kommunikation stets über eine zentrale Instanz erfolgt und zum anderen auf Basis von Point-to-Point bzw. Peer-to-Peer Kommunikation, also einem direkten Nachrichtenaustausch zweier Hosts. Beispiele für Middleware-Lösungen sind die im Abschnitt dargestellten Reliable Multicast Systeme. Die in dieser Arbeit vorgestellte Implementierung verwendet zur Kommunikation JGroups, dessen Funktionsweise ebenda beschrieben wird. Nachfolgend soll Remote Method Invocation (RMI) als weiterer Vertreter der Gattung Middleware beschrieben werden, das als Grundlage für das in Abschnitt beschriebene Kopplungsframework MatchMaker fungiert. Remote Method Invocation stellt eine Technologie des Java-Ökosystems zur Unterstützung entfernter Methodenaufrufe dar und ermöglicht den Einsatz verteilter Objekte. Während der Zugri auf Objekte vorher nur innerhalb eines Prozesses möglich war, werden diese Beschränkungen durch RMI aufgehoben. Dabei wird die gesamte Netzwerkkommunikation verborgen, so dass es für den Methodenaufrufer vollkommen transparent ist, ob ein lokales oder entferntes Objekt verwendet wird [HM05, S. 161]. Weitere Systeme zur Unterstützung verteilter Objekte sind zum Beispiel.NET Remoting oder die Common Object Request Broker Architecture (CORBA). Bei Remote Method Invocation handelt es sich um eine zentralisierte Broker-Architektur mit gleich zwei zentralen Komponenten. Zum einen existiert der RMI-Server, der einem 11

18 2. Grundlagen entsprechenden Client einen Dienst - repräsentiert durch ein Objekt - anbietet. Zum anderen gibt es die RMI-Registry, einem speziellen Dienst der den Namen von Diensten auf entfernte Objekte abbildet und somit Resource Discovery ermöglicht. Um den Clients einen Dienst zur Verfügung zu stellen, instanziert der RMI-Server das lokale Objekt und registriert es beim Namensdienst. Möchte ein RMI-Client einen Dienst nutzen, stellt er eine Anfrage mit dem entsprechenden Dienstnamen an die Registry. Sofern in der Registry ein Objekt unter dem Dienstnamen bekannt ist, wird eine Referenz auf das entfernte Objekt an den Client übergeben und daraufhin ein sogenanntes Stub-Objekt erzeugt. Hierbei handelt es sich um ein spezielles Objekt, das die gleiche Schnittstelle wie der entfernte Dienst besitzt und Methodenaufrufe an den RMI-Server des jeweiligen Dienstes weiterleitet. Auf Serverseite ist ein weiteres - als Skeleton bezeichnetes - Objekt für die Ausführung der Methode auf dem realen Dienstobjekt zuständig. Für das aufrufende bzw. aufgerufene Objekt stellen sich Stub und Skeleton als gewöhnliche Objekte dar, die in Wirklichkeit die jeweiligen Parameter und den Rückgabewert (de-)serialisieren und über das Netzwerk austauschen [HM05, S. 162.]. RMI bietet eine einfache und komfortable Möglichkeit zur Realisierung verteilter Systeme. Allerdings bringt der Einsatz auch einige Probleme mit sich. So dauert der Aufruf einer Methode auf einem entfernten Objekt wesentlich länger als auf einem lokalen, was vom Entwickler entsprechend bedacht werden muss. Auch bietet RMI keine asynchronen Methodenaufrufe und der Aufruf blockiert dementsprechend solange, bis der entfernte Rechner die Anfrage ausgeführt hat. Darüber hinaus bietet RMI keinen Mechanismus zum Aunden einer RMI-Registry und muss die Adresse explizit übergeben bekommen FreeStyler Der FreeStyler ist eine - in Java geschriebene - kollaborative Modellierungsumgebung, die auf der Idee der shared workspaces beruht und von der Collide-Gruppe 3 an der Universität Duisburg-Essen entwickelt wurde (siehe [HG02], [Gaÿ03]). Neben dem Einsatz im universitären Rahmen wird der FreeStyler als interaktive Lernumgebung im Schulunterricht der Sekundarstufen I und II verwendet. Zu diesem Zweck bietet er beispielsweise Funktionen zur Unterstützung des mathematisch-naturwissenschaftlichen Unterrichts. Zum Zeitpunkt der Erstellung dieser Arbeit ist Version des Programms aktuell. Als Modellierungstool ermöglicht der FreeStyler dem Benutzer die Externalisierung und Strukturierung seines Wissens. Der Anwender bearbeitet die Inhalte in einzelnen Arbeitsmappen, welche in mehrere Seiten unterteilt werden können und somit eine bessere Übersicht gewährleisten. Darüber hinaus können mehrere Ebenen eingefügt werden, in denen die Inhalte arrangiert werden. Während der Bearbeitung kann auf zwei verschiedene Methoden zur Wissensmodellierung zurückgegrien werden. Auf der einen Seite existiert die Möglichkeit der Freihandeingabe, mit der auf einfache Weise Skizzen oder Annotationen angefertigt werden können. Auf der anderen Seite werden mit dem FreeStyler eine ganze Reihe visueller Sprachen ausgeliefert, die zur Kreation von Modellen verschiedenster Wissensdomänen verwendet werden können. Diese visuellen Sprachen sind in einzelnen

19 2.2. FreeStyler Plugins organisiert und können exibel zur Laufzeit geladen werden. Die erstellten Arbeitsmappen können vom Benutzer in Form von XML-Dateien gespeichert und zu einem späteren Zeitpunkt wieder geladen oder einer anderen Arbeitsmappe angefügt werden. Der Arbeitsbereich des FreeStylers ist in vier Bereiche aufgeteilt. Oben ndet sich die Menüleiste, die den Zugri auf eine ganze Reihe von Funktionen bietet. So nden sich an dieser Stelle unter anderem Funktionen zum Speichern, Laden oder Einfügen von Arbeitsmappen. Darüber hinaus werden Optionen geboten, um getätigte Aktionen rückgängig zu machen, kollaborative Sitzungen zu erstellen oder beizutreten und die FreeStyler- Plugins zu verwalten. Unten bendet sich eine Aktionsleiste zur Konguration der Freihandeingabe und für die Verwaltung von Inhalten, Ebenen und Seiten. Der eigentliche Arbeitsbereich bendet sich auf der linken Seite, während rechts die aktuell geladenen Paletten angezeigt werden. Die Knoten der jeweiligen Modellierungssprache können von der Palette per Drag and Drop in den Arbeitsbereich gezogen werden. Darüber hinaus erhält der Anwender über die Palette Zugri auf die zur Verfügung stehenden Kanten. Abbildung 2.3 zeigt den FreeStyler mit geladenem Petri-Netz Plugin. Abbildung 2.3.: Screenshot des FreeStylers mit geladenem Petri-Netz Plugin Neben dem FreeStyler soll an dieser Stelle das Programm Cool Modes Erwähnung nden. Bei Cool Modes handelt es sich um ein weiteres, von der Collide-Gruppe entwickeltes, Modellierungswerkzeug. Wie der FreeStyler, realisiert Cool Modes Prinzipen von shared workspaces und ist darüber hinaus auf technischer Ebene mit dem FreeStyler verwandt. Hieraus resultiert die Interoperabilität der meisten Plugins zwischen Cool Modes und dem FreeStyler [Pin05]. 13

20 2. Grundlagen Plugins Der FreeStyler stellt ein Rahmenwerk zur Modellierung dar und bietet selbst nur die Möglichkeit der Freihandeingabe und die Darstellung von Bildern innerhalb des Arbeitsbereichs. Die Verwendung verschiedener visueller Sprachen wird durch entsprechende Plugins realisiert. Zu diesem Zweck besitzt der FreeStyler eine exible Plugin-Architektur, die es dem Benutzer erlaubt, den Funktionsumfang zur Laufzeit zu erweitern. Das Programm wird mit einer Vielzahl an Plugins ausgeliefert, wobei sowohl graphbasierte Modellierungsmethoden wie z.b. Petri-Netze und UML-Aktivitätsdiagramme, als auch Modellierungssprachen ohne eigene Graph-Repräsentation unterstützt werden. Als Beispiel hierfür sei die Modellierung von Karnaugh-Veigh-Diagrammen genannt. Als grundlegendes Format zur Beschreibung und Entwicklung von Plugins für FreeStyler (und auch Cool Modes) wird das Reference Frame Konzept angewandt. Dieses Beschreibungsformat ist für die Interoperabilität zwischen FreeStyler und Cool Modes Plugins verantwortlich, indem es der entsprechenden Anwendung auf der technischen Ebene wichtige Informationen über die Elemente und Struktur der dargestellten Sprache liefert. Neben den verfügbaren Knoten und Kanten können im Reference Frame Regeln deniert werden, die die syntaktische Korrektheit der visuellen Sprache gewährleisten [Pin05]. Neben dem Reference Frame beinhaltet ein Plugin typischerweise folgende Komponenten: Knoten und Kanten Je nach visueller Sprache werden ein oder mehrere Knoten angeboten, die durch entsprechende Kanten miteinander verbunden werden können. Dabei obliegt es dem jeweiligen Plugin, Syntaxregeln für die Verbindung der Knoten zu denieren. Palette Als Palette wird die graphische Komponente bezeichnet, die den Zugri auf die Knoten und Kanten der visuellen Sprache zulässt. Darüber hinaus bieten manche Paletten an dieser Stelle weitere Plugin-abhängige Funktionen, wie zum Beispiel den Export in spezielle Modellrepräsentationen oder die Generierung von Programmcode Synchronisation Der FreeStyler stellt ein kollaboratives Modellierungswerkzeug dar, mit dem mehrere Benutzer sowohl synchron, als auch asynchron an einem Dokument arbeiten können. Um dies zu ermöglichen, können mehrere FreeStyler miteinander gekoppelt werden, wodurch die Arbeitsbereiche der Benutzer synchronisiert werden. In der aktuellen Version bietet der FreeStyler die Möglichkeit der dokumentenweisen Kopplung, wodurch alle Seiten der Arbeitsmappe synchronisiert werden. Aus technischer Sicht wird die Synchronisation von Anwendungen durch die Synchronisation der zugrundeliegenden Daten verwirklicht. Für ein Programm, das auf der Model-View-Controller Architektur beruht [Ree79], gleicht dies der Synchronisation der Modelle. Zum Zeitpunkt der Erstellung dieser Arbeit sind zwei Synchronisationsmechanismen für den FreeStyler verfügbar, zum einen die seit dem Jahr 2001 entwickelte Java-Version des MatchMakers und zum anderen die Synchronisation mit Hilfe des Extensible Messaging and Presence Protocol (XMPP) 14

21 2.3. Groupware [Int11a]. Im Folgenden soll die Arbeitsweise der MatchMaker-Architektur näher erläutert werden, da diese Technologie sich über die Jahre als stabile und zuverlässige Lösung etabliert hat. MatchMaker [Jan03] stellt ein, als Client-Server-Architektur realisiertes, Kopplungsframework dar, das auf Java-RMI als zugrundeliegende Middleware aufbaut und zur Synchronisation von Java-Applikationen eingesetzt werden kann. Mit Hilfe des MatchMaker- Clients kann ein Programm die verwendeten Anwendungsobjekte in einer, als Synchronization Tree bezeichneten, Baumstruktur organisieren. Der MatchMaker-Server verwaltet verschiedene Sitzungen und speichert für jede Sitzung eine eigene Kopie dieser hierarchischen Datenstruktur, welche von anderen MatchMaker-Clients abgerufen und repliziert werden kann. Innerhalb einer Sitzung werden die Datenmodelle üblicherweise analog zu der intern verwendeten Datenstruktur des jeweiligen Programms abgelegt. Diese Daten können daraufhin von anderen Anwendungen gelesen, geändert oder gelöscht werden. Soll eine Anwendung sofort darüber informiert werden, dass ein anderes Programm bestimmte Daten verändert hat, so kann sie sich auf Basis des Publish-Subscriber-Architekturmusters [GHJV95] als Sync-Listener für einzelne Knoten oder ganze Teilbäume des Synchronisationsbaums registrieren. Wenn ein Client Änderungen an einem gekoppelten Objekt vornimmt, informiert der MatchMaker-Server nacheinander alle registrierten Anwendungen und sorgt dafür, dass die anderen Teilnehmer die Änderungen übernehmen. Die Replikation des Synchronization Trees auf jedem einzelnen Client bietet den Vorteil, dass Netzwerkprobleme nicht zu Datenverlusten führen, da die Daten lokal vorliegen. Um Inkonsistenzen durch den konkurrierenden Zugri eines Objektes zu vermeiden, erfolgt die Bearbeitung innerhalb des MatchMaker-Servers sequentiell. Dies hat zur Folge, dass MatchMaker Schwächen in der Skalierbarkeit aufweist und sich für kollaborative Sitzungen mit wenigen Personen anbietet Groupware In Abschnitt 2.1 wurde die Vernetzung von Systeme mit dem Wunsch des gemeinsamen Zugris auf Ressourcen motiviert. Diese Beschreibung konzentriert sich auf die technische Natur der Vernetzung. Die interdisziplinäre Domäne Computer Supported Cooperative Work (CSCW) hingegen untersucht den Einsatz (verteilter) Computer-Systeme zur Unterstützung von Gruppenarbeit unter inhaltlichen Gesichtspunkten. Wilson beschreibt CSCW als Begri, der das Verständnis wie Menschen in Gruppen zusammenarbeiten mit den Technologien zur Realisierung von Gruppenarbeit kombiniert [WCB91, S. 6]. Systeme zur Unterstützung rechnergestützter Gruppenarbeit werden unter dem Begri Groupware zusammengefasst. Ellis et al. liefern hierzu die folgende Denition [EGR91]: computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment. Demzufolge werden Gruppen von Personen bei der Bearbeitung einer gemeinsamen Aufgabe durch das Programm unterstützt und interagieren über einen gemeinsamen Arbeitsbereich miteinander. Auf Grundlage dieser Denition kann der in Abschnitt 2.2 beschriebene FreeStyler als Groupware-System betrachtet werden, da mehrere Personen mit Hilfe des Kopplungsmechanismus gemeinsame Modelle erarbeiten können. Die Synchronisation der Arbeitsmappen führt zur Erzeugung eines gemeinsamen Kontextes und 15

22 2. Grundlagen stellt eine weniger strikte Form des What You See Is What I See (WYSIWIS) Ansatzes dar [SBF + 87]. Darüber hinaus existieren eine Reihe weiterer Konzepte und Aspekte kollaborativer Arbeit. Für das in der Arbeit beschriebene System ist der Begri der Awareness ein wichtiger Aspekt und soll im Folgenden erläutert werden. Awareness wird in der deutschsprachigen Literatur auch als Gruppenwahrnehmung bezeichnet (vgl. [BS98] oder [SSU01]) und zielt darauf ab, dem Benutzer Informationen zum Zustand des gesamten Kooperationsprozesses zu liefern. Dies beinhaltet die Darstellung vergangener und aktueller Aktionen [SSU01, S. 335]. Prinz klassiziert die Unterstützung von Awareness in aufgabenorientierte Awareness und soziale Awareness. Unter ersterem versteht er Informationen, die sich auf Änderungen des aktuellen Dokuments oder des gemeinsamen Arbeitsbereichs beziehen, während letzteres Informationen über die Präsenz und Aktivitäten der anderen Gruppenteilnehmer liefert [Pri99]. Nach Borgho und Schlichter [BS98, S. 183] sorgt die Bereitstellung von Awareness-Funktionen dafür, dass Gruppenmitglieder besser über den aktuellen Stand der Gruppenaktivitäten informiert sind. Darüber hinaus wird die Initiierung spontaner, informeller Kommunikation unterstützt, da Gruppenteilnehmer besser über die aktuelle Beschäftigung und Arbeitslast ihrer Partner Bescheid wissen. Sollen Aufgaben kollaborativ bearbeitet werden, ndet in der Regel eine Identikation der Teilaufgaben und eine entsprechende Zuordnung an die einzelnen Arbeitsgruppen statt. Groupware-Systeme können die Koordination dieses Prozesses unterstützen und Optimierungen vornehmen. Für den CSCW-Bereich des Computer Supported Collaborative Learning (CSCL) liefert Kuhn mehrere Beispiele für Aktivitäten, die ein Lehrer während einer kollaborativen Unterrichtsstunde im Schulalltag durchführen muss [Kuh08, S. 199 f.]. Hierzu gehört die Einteilung der Schüler in Gruppen, die Verteilung von Aufträgen und die Bereitstellung von Arbeitsmitteln. Nach Kuhn werden Aufgaben in längerfristig ausgelegten Arbeitsphasen durch Groupware-Lösungen wie BSCL 4 oder Moodle 5 unterstützt und ergeben einen vertretbaren Arbeitsaufwand für die Koordination. Kurzfristig angelegte spontane Kollaborationen hingegen erzeugen einen höheren administrativen und zeitlichen Aufwand und entsprechende Unterstützungsfunktionen nden sich weitaus seltener in Groupware-Systemen Grundlegende und verwandte Arbeiten Im Folgenden wird das AdhocMM -Plugin für Cool Modes erläutert, dessen visuelle Sprache als Grundlage für das in dieser Arbeit entwickelte Konzept dient. Im Anschluss wird ein Document Management System zur Verwaltung von Arbeitsmaterialien, wie z.b. FreeStyler-Arbeitsmappen, vorgestellt. Abschlieÿend werden Beispiele für Classroom Management Systeme geliefert, die zur Koordination von Unterrichtseinheiten eingesetzt werden können und damit einen ähnlichen Funktionsumfang wie das hier entwickelte System besitzen

23 2.4. Grundlegende und verwandte Arbeiten AdhocMM (CoolModes) AdhocMM [KJHH] stellt ein System zum Management kollaborativer Sitzungen dar, das als Plugin für Cool Modes realisiert wurde. Der Name bezieht sich auf die Zielsetzung, Cool Modes-Sitzungen ad hoc durchführen zu können und bietet sich somit für die spontane Kollaboration im Schulalltag an. Zu diesem Zweck bietet AdhocMM dem Lehrer eine visuelle Sprache zur Planung von kollaborativen Klassenraum-Szenarien und bietet darüber hinaus Funktionen, die den Lehrer während einer Unterrichtsstunde unterstützen. Die Einsatz einer visuellen Repräsentation bietet gerade für neue Benutzer eine geringere Einstiegshürde und eine kurze Einarbeitungszeit. Die visuelle Sprache wird sowohl zur Planung, als auch zur Durchführung von Kollaborationen eingesetzt und besteht aus sieben Elementen. Eine Cool Modes Sitzung wird durch einen session node repräsentiert, welchem zur Identikation verschiedener Sitzungen ein Name zugeordnet werden kann. Jeder Schüler, der mit Cool Modes am Unterricht teilnimmt, wird durch einen user node repräsentiert. Da während der Unterrichtsplanung noch kein Schüler angemeldet ist, existieren sogenannte slot nodes, die als Platzhalter fungieren. Zur Identikation eines Schülers, der im Unterricht diesen Platz einnehmen soll, kann einem solchen Knoten ein Name zugeordnet werden. Um die Arbeitsmappe einer Sitzung während des Unterrichts zu speichern, kann der Lehrer einen database node mit dem Sitzungsknoten verbinden und das Dokument auf seinen Rechner exportieren. Neben diesen vier Knotentypen werden drei Kanten angeboten, um die Elemente zu verbinden. Zur Verknüpfung eines database nodes mit einem session node wird eine database edge gezogen. Für die Zuordnung eines Schülers bzw. Platzhalters bieten sich dem Lehrer die Kantentypen force-edge und is-allowed-edge an. Die force-edge führt dazu, dass das Cool Modes-Programm des Schülers automatisch der entsprechenden Sitzung beitritt, weshalb ein user node nur mit einem session node verbunden werden kann. Die is-allowed-edge hingegen kann einen Schüler mit mehreren Sitzungen verbinden. Möchte der Schüler einer Sitzung beitreten, werden ihm die so verbundenen Sitzungen zur Auswahl gestellt. Abbildung 2.4 bietet eine Übersicht über die graphische Repräsentation dieser Elemente. database-edge Force-edge slot-node database-node session-node is-allowed-edge user-node Abbildung 2.4.: Graphische Elemente des AdhocMM Plugins für Cool Modes Mit Hilfe der angebotenen Sprache kann der Lehrer die Sitzungen kongurieren und ver- 17

24 2. Grundlagen walten. Änderungen des Graphen, wie z.b. das Hinzufügen einer force-edge werden sofort auf die Cool Modes-Instanz des Schülers angewandt. Eine fertige Konguration kann gespeichert und wiederverwendet werden, weshalb eine solche AdhocMM als Learning Design Template angesehen werden kann. Darüber hinaus kann eine solche Arbeitsmappe als IMS/LD Dokument exportiert werden. Das AdhocMM-Plugin bildet die Schnittstelle zur Planung und Koordination der Gruppenarbeit. Auf Seiten des Schülers kommt kein spezielles Plugin zum Einsatz. Stattdessen wurden die Funktionen direkt in Cool Modes integriert. Für die Kommunikation zwischen AdhocMM und den Cool Modes der Schüler kommt Java-RMI zur Anwendung. Da RMI kein Service Discovery anbietet, macht sich das AdhocMM Plugin durch den Versand von Multicast-Nachrichten mit den Schülerrechnern bekannt Dokumentenverwaltung für Computer-integrated Classrooms Document Management Systeme stellen im Allgemeinen Funktionen zur Verwaltung von Arbeitsmaterialien bereit. Zum Portfolio solcher Systeme gehört die Verteilung, der Austausch und das Einsammeln von Dokumenten. Das in [BBB + 02] vorgestellte System realisiert diese Funktionen unter Berücksichtigung der speziellen Bedingungen in einem Computer-integrated Classroom. Dabei hebt es sich durch verschiedene Aspekte von typischen Document Management Systemen ab, wie der Unterstützung von Kollaboration und Bereitstellung von Monitoring-Funktionen. Auf die Dokumente kann sowohl im Unterricht, als auch von zu Hause aus zugegrien werden. Zur Vorbereitung des Unterrichts verwendet der Lehrer das als Session Control bezeichnete Tool, um Kurse zu erstellen und zu organisieren. Hierbei können sowohl Sitzungen angelegt, als auch Arbeitsmaterialien eingestellt werden. Darüber hinaus bieten sich dem Lehrer administrative Funktionen, wie die Vergabe von Zugrisrechten auf die eingestellten Dokumente. Die Schüler verwenden den in Abschnitt 2.2 beschriebenen FreeStyler, um sich am System anzumelden, einer vom Lehrer erstellten Sitzung manuell beizutreten und Aufgaben gemeinsam zu bearbeiten. Dabei kommt MatchMaker als zugrundeliegendes System für die Synchronisation der Sitzungen zur Anwendung. Per Session Control kann der Lehrer das Unterrichtsmaterial an die Schüler austeilen und einsammeln, wobei die Dokumente in einem zentralen Repository abgelegt werden, das als Document Archive bezeichnet wird. Möchte der Lehrer während des Unterrichts auf die Arbeitsmappe einer Sitzung zugreifen, z.b. um der Klasse eine Lösung zu präsentieren, bietet Session Control die Möglichkeit zum Beitritt an. Die Inhalte können daraufhin via Beamer oder Blackboard allen Schülern sichtbar gemacht werden. Neben diesen Funktionen zur Unterstützung von face-to-face Lernszenarien wird der Zugri auf das erstellte Material auch auÿerhalb des Klassenraums ermöglicht, wobei wiederum der FreeStyler zum Einsatz kommt Group Scribbles, SceDer und COML Group Scribbles 6 ist eine kollaborative Lernplattform, die für den Einsatz im Klassenraum konzipiert wurde. Sie bietet Schülern und Lehrern die Möglichkeit, ihre Ideen in

25 2.4. Grundlegende und verwandte Arbeiten Form von Haftnotizen mit entsprechenden handgeschriebenen Zeichnungen oder Notizen auszudrücken und auf einem virtuellen Zeichenpapier zu organisieren. Die Verwendung der Haftnotizen-Metapher wurde bewusst eingesetzt, da die Gröÿe des Zeichenbereichs gerade ausreicht um einzelne Gedanken oder Konzepte auszudrücken. Die als Scribbles bezeichneten Haftnotizen können auf öentlichen schwarzen Brettern angepinnt und so für andere Teilnehmer verfügbar gemacht werden. Zur Organisation innerhalb der öentlichen Bereiche bietet Group Scribbles die Möglichkeit der Gruppierung, Kategorisierung und Sortierung von Scribbles [BDP + 07]. Ein wichtiges Konzept von Group Scribbles stellt die Trennung in einen privaten und verschiedene öentliche Arbeitsbereiche dar. Der private Bereich bietet dem Benutzer die Möglichkeit, neue Haftnotizen zu erstellen und zu gestalten. Wenn die Arbeit beendet ist, kann der Benutzer das erstellte Scribble publizieren, indem er es per Drag and Drop in einen öentlichen Arbeitsbereich zieht. Abbildung 2.5 bietet einen Screenshot, aus dem die graphische Repräsentation der Scribbles und die Anordnung der Oberäche in den privaten Bereich (unten) und den ausgewählten öentlichen Bereich Buery entnommen werden kann. Abbildung 2.5.: Screenshot der GroupScribbles GUI mit Einteilung in privaten Bereich (unten) und öentlichen Bereich (oben) (Quelle: [SRI10]) Zur Koordination des Unterrichts bietet Group Scribbles dem Lehrer die Möglichkeit, verschiedene Bereiche anzulegen und auf diese Weise eine manuelle Gruppeneinteilung vorzunehmen. Vorbereitetes Arbeitsmaterial oder in Scribbles verfasste Aufgabenbeschrei- 19

26 2. Grundlagen bungen können vor Unterrichtsbeginn an die entsprechenden Bretter gepinnt werden. Niramitranon et al. [NSGL07] haben ein Classroom Management System entworfen, das die Planung von Unterrichtseinheiten ermöglicht, in denen GroupScribbles eingesetzt werden soll. Zusätzlich zu der Planung wird der Lehrer bei der Durchführung des Unterrichts unterstützt. Hierzu wurden die folgenden Komponenten entwickelt. Die Basis für die Unterrichtsplanung bildet die Classroom Orchestration Modelling Language (COML). Hierbei handelt es sich um eine XML-basierte Sprache, die für die Spezikation von Lernszenarien konzipiert wurde. Ein Lernszenario besteht aus einer Reihe von Unterrichtsaktivitäten, die durch Aussagen der Form Role performs Activities within an Environment beschrieben werden. Damit die Benutzer die XML-Dateien nicht per Hand erstellen müssen, existiert mit dem Programm Scenarios Designer Tool (SceDer) ein eigener Editor, der in Abbildung 2.6 dargestellt ist. Jede Aktivität wird durch eine eigene Zeile repräsentiert. Die Beschreibung einer Aktivität orientiert sich an der oben genannten Aussageform. Dabei stehen die Rollen Schüler, Lehrer und Gruppen zur Auswahl. Diese Rollen werden verwendet, um den Akteur und den Empfänger der Aktivität zu beschreiben. Als jeweilige Aktion kann der Benutzer zwischen den Kategorien Frage, Antwort, Diskussion und Sonstiges wählen und diese textuell näher erläutern. Darüber hinaus kann einer Aktivität ein Dokument, wie z.b ein Bild, zugeordnet werden, das während des Unterrichts an die Schüler ausgeteilt wird. Als Environment wird das schwarze Brett bezeichnet, in dem die Bearbeitung stattndet. Um Gruppenarbeiten zu planen und verschiedene Arbeitsaufträge zu vergeben, wird für jede Gruppe eine eigene Aktivität beschrieben und dieser ein eigenes schwarzes Brett zugewiesen. Wenn die Unterrichtsplanung abgeschlossen ist, kann das Szenario als COML-Datei exportiert werden. Abbildung 2.6.: Screenshot des Scenario Designer Tools 20

27 2.4. Grundlegende und verwandte Arbeiten Die dritte Komponente des Systems wird durch das Collaborative Runtime System gebildet. Dieses System hat die Aufgabe, COML-Dateien zu interpretieren und daraufhin die GroupScribbles Funktionen aufzurufen, die zur Umsetzung des Lernszenarios benötigt werden. Hierzu gehören beispielsweise die Erstellung von schwarzen Brettern für die einzelnen Aktivitäten und das Laden der Unterrichtsmaterialien. Die Benutzungsschnittstelle für den Lehrer und die Schüler wird durch GroupScribbles gestellt. Dabei wurde die Oberäche um zusätzliche Anzeigen und Operationen erweitert, mit denen der Lehrer z.b. COML-Dateien laden oder zwischen den verschiedenen Aktivitäten wechseln kann. Darüber hinaus wurde eine eigene Monitoring-Komponente entwickelt, die dem Lehrer einen Überblick bietet, welche Aktivitäten von den Schülern bereits beendet wurden SMART Classroom Suite SMART Classroom Suite 7 ist eine proprietäre Lernsoftware-Kollektion der Firma SMART Technologies, die in Face-to-Face Lernszenarien zum Einsatz kommen kann und den Lehrer bei der Durchführung kollaborativer Unterrichtseinheiten unterstützt. Im einzelnen besteht die Lernsuite aus den Komponenten SMART Notebook, SMART Notebook SE (Student Edition), SMART Sync und SMART Response. Das Programm SMART Notebook (SE) wurde für Schüler konzipiert und ermöglicht die Erstellung interaktiver Arbeitsmappen. Arbeitsmappen sind in mehrere Seiten aufgeteilt und können Bilder, Videos und Audiodaten enthalten. Darüber hinaus können interaktive Elemente, Tabellen und Freihandzeichnungen angefertigt und auf Webseiten zugegrien werden [SMA12a]. Abbildung 2.7 zeigt eine Arbeitsmappe mit zwei interaktiven Elementen zum Stoppen der Zeit (rechts) und zur Übersetzung von Wörtern (links). Die erstellten Dokumente können über das Programm organisiert werden. Der Lehrer kann die restlichen drei Programme einsetzen, um den Unterricht zu verwalten. SMART Notebook bietet neben den erläuterten Funktionen von SMART Notebook (SE) zur Erstellung von Arbeitsmappen zusätzlich die Möglichkeit, bereits existierende Dokumente während des Unterrichts an die Schüler zu verteilen oder Dokumente einzusammeln. SMART Sync bietet weitere Funktionen, um den kollaborativen Unterricht zu gestalten. Hierzu gehören die Demonstration bestimmter Konzepte oder Beispiele mit Hilfe einer Screen-Broadcasting Funktion, die Koordination von Gruppenarbeiten und Monitoring-Funktionen, wie eine Thumbnail-Ansicht aller Schüler-Desktops. SMART Response liefert dem Lehrer Funktionen zur Erstellung von Fragebögen, um den Wissensstand der Schüler zu erfassen [SMA11a]. Für die gemeinsame Arbeit mehrerer Schüler bietet die SMART Sync Komponente die Möglichkeit, Schüler in zufällige Gruppen einzuteilen. Die Schüler können sich die Bildschirminhalte der anderen Gruppenmitglieder anzeigen lassen und sich mit Hilfe einer Gruppenchat-Funktion über Probleme und Ideen austauschen [SMA11b]. Die erläuterten Funktionen zielen auf die Unterstützung des Lehrers während des Unterrichts. So kann der Lehrer mit diesem System Dokumente verwalten und die Schüler während der Arbeit durch Monitoring- und Kommunikationsfunktionen unterstützen

28 2. Grundlagen Abbildung 2.7.: Screenshot der SMART Notebook GUI mit zwei interaktiven Elementen (Quelle: [SMA12b]) INiS Bei INiS handelt es sich um eine didaktische Netzwerkmanagement-Suite für Microsoft Windows, die von der Firma TriNeT entwickelt wurde [Tri12]. INiS empehlt sich für den Einsatz in Face-to-Face Unterrichtssituationen. Die Schüler verwenden beliebige Programme zur Bearbeitung der Aufgaben, wie z.b. Texteditoren oder Tabellenkalkulationen. Die INiS-Software läuft als Hintergrundanwendung auf den Schülerrechnern und bietet einem Lehrerrechner verschiedene Funktionen zur Betreuung der Schüler. Der Lehrer nutzt während des Unterrichts ein spezielles Managementprogramm zur Verwaltung der Schülerrechner. Abbildung 2.8 zeigt einen Screenshot der Management-Oberäche. Die INiS-Funktionen können in die vier Kategorien Überwachung, Betreuung, Kommunikation und UserAdmin unterteilt werden. Zur Überwachung kann sich der Lehrer in einer Raumübersicht die angemeldeten Schüler anzeigen lassen. Hierbei können die Rechner entsprechend der Position im Klassenraum angeordnet werden. Meldet sich ein Schüler an, wird er in der Übersicht an dem jeweiligen Rechner angezeigt. Neben der Statusanzeige kann sich der Lehrer die Bildschirminhalte mehrerer Schülerrechner in einer Übersicht anzeigen lassen und einen Überblick über die Aktivitäten erhalten. Darüber hinaus können die aktuellen Prozesse und Druckaufträge, sowie die Adressen der besuchten Internetseiten angezeigt werden. Zur Betreuung der Schüler während des Unterrichts wird dem Lehrer die Möglichkeit geboten, sich den Bildschirm eines Schülerrechners anzeigen zu lassen. Während in der 22

29 2.4. Grundlegende und verwandte Arbeiten oben erwähnten Übersicht nur wenig Platz für die Darstellung der Schüler-Desktops verfügbar ist, wird in diesem Fall der komplette Bildschirm zur Anzeige genutzt. Um einen Schüler bei der Bearbeitung einer Aufgabe zu unterstützen, kann der Bildschirmbereich mit Hilfe einer speziellen Malfunktion annotiert oder die Kontrolle über den entfernten Rechner übernommen werden. Sollen Ideen oder Lösungen der Klasse präsentiert werden, wird dem Lehrer die Möglichkeit geboten, den Bildschirminhalt des Lehrerrechners oder eines Schülerrechners an alle Computer zu übertragen. Um die Bearbeitung der Aufgabe kurzzeitig zu unterbrechen und die ungeteilte Aufmerksamkeit der Schüler zu erhalten, können die Arbeitsstationen der Schüler über die Management-Software gesperrt werden. Darüber hinaus bietet INiS für den Unterricht verschiedene Kommunikationsfunktionen. So kann der Lehrer Textmitteilungen an einzelne oder alle Schüler senden. Sollen die Schüler Fragen an den Lehrer richten können, ohne dabei die Mitschüler zu stören, kann hierfür eine Chat-Funktion genutzt werden. Diese Funktion bietet auch eine Unterstützung von Chatrooms und kann verwendet werden, um Gruppenarbeiten durchzuführen. Soll Arbeitsmaterial vom Lehrerrechner aus an alle Schüler ausgeteilt oder eingesammelt werden, kann dies über den INiS Dateibrowser erfolgen. Die Dateien werden dabei über das Netzwerk übertragen und in einem speziellen Ordner im Dateisystem abgelegt. Unter der Kategorie UserAdmin ndet sich die Benutzerverwaltung, die beispielsweise die Möglichkeit bietet, neue Benutzer anzulegen oder Kennwörter zurückzusetzen. Für die Benutzerverwaltung kommt ein existierender Verzeichnisdienst, wie z.b. Microsoft Active Directory, zur Anwendung. Abbildung 2.8.: Screenshot der INiS Management Software mit geöneter Raumübersicht (Quelle: [Tri12]) 23

30 2. Grundlagen Wie anhand dieser Beschreibung zu erkennen ist, zeichnet sich INiS besonders durch die Monitoring und Betreuungsfunktionen aus und kommt aus diesem Grund üblicherweise während des Unterrichts zum Einsatz Edubuntu und Epoptes Edubuntu 8 ist eine Linux-Distribution, die speziell für den Sektor Schule und Bildung entwickelt wird. Diese Zielsetzung macht sich besonders durch die mitgelieferte Sammlung freier Software bemerkbar. Mit dem Betriebssystem werden ein Reihe von Lernprogrammen ausgeliefert, wie z.b. die Softwaresammlung GCompris [GCo13], der Funktionenplotter KAlgebra [KAl13] und der physikalische Simulator Step [Ste13]. Neben der Lernsoftware gehört die Open Source Software SchoolTool [Sch13] zur Verwaltung von Stundenplänen und Kontaktdaten zum Lieferumfang. Um auch in Schulen mit älteren Rechnern einsatzfähig zu sein und darüber hinaus eine einfache Systemverwaltung zu erlauben, bringt Edubuntu eine eigene Terminal-Server Implementierung mit [Bä07]. Um die Verwaltung von Klassenraumsituationen mit Edubuntu zu unterstützen, wird mit der Distribution die Classroom Management Software Epoptes [Epo13] ausgeliefert. Dieses System besteht aus drei Komponenten.Auf dem Schülersystem läuft eine Client- Anwendung, die auf Steuerungsbefehle des Lehrerrechners wartet und diese daraufhin ausführt. Diese Clients bauen beim Start eine Verbindung zu einem Server auf. Der Server ist für den Versand der Steuerbefehle an die Clients zuständig und kann über eine entsprechende Bedienoberäche verwaltet werden. Diese Bedienoberäche kann vom Lehrer verwendet werden, um sich die Desktops der Schüler anzuzeigen und diese fernzusteuern. Darüber hinaus kann der Bildschirminhalt an alle weiteren Clients übermittelt werden. Der Lehrer kann auÿerdem Nachrichten an die Schüler senden und sie somit bei der Bearbeitung der Aufgaben unterstützen. Möchte der Lehrer die volle Aufmerksamkeit der Schüler erhalten, kann er die Bildschirme der Schülerrechner sperren. Zusätzlich zu diesen Monitorings- und Betreuungsfunktionen kann der Lehrer auf den Schülerrechnern sowohl Shell-befehle ausführen, als auch Webseiten önen lassen. Wenn an einem Server Schüler verschiedener Klassen arbeiten, können diese in verschiedenen Gruppen organisiert werden. Auf diese Weise kann die Screen-Broadcasting auf bestimmte Rechner begrenzt werden. Abbildung 2.9 zeigt einen Screenshot von Epoptes, in dem verschiedene Gruppen eingerichtet wurden und auf der linken Seite zu erkennen sind. Die rechte Seite bietet einen Überblick über die angemeldeten Schüler. Wie anhand dieser Beschreibung zu erkennen ist, stellt Edubuntu die eigentlichen Lern- Werkzeuge bereit, die während des Unterrichts zum Einsatz kommen können. Epoptes erweitert das System daraufhin um die Funktionen eines Classroom Management Systems und bietet hierbei ähnliche Funktionen wie das zuvor beschriebene INiS. Es sei allerdings darauf hingewiesen, dass Epoptes zum Zeitpunkt der Erstellung dieser Arbeit über keine Funktionen zur Dokumentenverwaltung verfügt

31 2.4. Grundlegende und verwandte Arbeiten Abbildung 2.9.: Screenshot der Epoptes Management Software (Quelle: [Epo13]) 25

32

33 3. Konzept Der Einsatz von Computern im Unterricht wird in der heutigen Zeit häug als wichtige Vorbereitung auf den späteren Arbeitsalltag angesehen. Neben der Online-Recherche können Computer in verschiedenen Unterrichtsfächern zur Erstellung von Modellen oder Durchführung von Experimenten und der damit einhergehenden Vertiefung des Wissens eingesetzt werden. Das im vorangegangenen Kapitel beschriebene Programm FreeStyler kann mit Hilfe entsprechender Plugins beispielsweise für stochastische Experimente oder zur Modellierung von Petri-Netzen im Mathematik- oder Informatikunterricht verwendet werden. Allerdings darf nicht auÿer Acht gelassen werden, dass die Nutzung entsprechender Systeme im Schulunterricht einen erhöhten Planungs- und Administrationsaufwand für den Lehrer mit sich bringt. Neben der Vorbereitung des eigentlichen Lerninhalts kommt die Verwaltung der digitalen Arbeitsmaterialien und die Modellierung von kollaborativen Unterrichtseinheiten hinzu. Ein Classroom Management System sollte dementsprechend den Fokus darauf legen, eine einfache und komfortable Unterrichtsplanung zu ermöglichen und darüber hinaus die zeitlichen Verzögerungen durch verschiedene administrative Aktivitäten während des Unterrichts zu verringern. Hierzu kann z.b. das Austeilen und Einsammeln der digitalen Unterrichtsmaterialien zu Beginn bzw. am Ende der Unterrichtsstunde, sowie die Bekanntgabe der Gruppeneinteilungen in kollaborativen Lernszenarien gezählt werden. Im Verlauf dieses Kapitels wird ein Konzept für ein Classroom Management System vorgestellt, das den Lehrer im rechnergestützten Unterricht mit dem FreeStyler unterstützt und die zeitlichen Verzögerungen zu minimieren versucht. Zu Beginn dieses Kapitels erfolgt die Vorstellung des zugrundeliegenden Szenarios, das als Grundlage für das in dieser Arbeit entwickelte Konzept dient. Hierbei werden prototypische Aktivitäten des Lehrers und der Schüler beschrieben, die während der Planung und Durchführung einer Unterrichtsstunde entstehen. Daraufhin werden verschiedene Anforderungen deniert, die ein System zur Unterstützung des Szenarios erfüllen muss (3.2). Die Erläuterung des umzusetzenden Konzepts beginnt in Abschnitt 3.3 mit der Identikation der einzelnen Unterrichtsphasen und der Systemkomponenten. Die jeweiligen Aufgaben und Funktionen werden anhand der aufgezeigten Phasen beschrieben und bilden den Ausgangspunkt für die in Abschnitt 3.4 denierten technischen Anforderungen an eine Middleware. Nach der Auswahl eines entsprechenden Frameworks wird zum Abschluss dieses Kapitels in Abschnitt 3.5 die Architektur des Systems skizziert Szenario Das zu unterstützende Szenario beginnt damit, dass der Lehrer zu Hause oder im Lehrerzimmer die nächste Unterrichtsstunde vorbereitet. Er stellt zuerst Überlegungen an, ob in der Stunde Einzel- oder Gruppenarbeit eingesetzt werden soll und entschlieÿt sich für eine Kombination beider Methoden. Er verwendet den FreeStyler in Verbindung mit 27

34 3. Konzept dem Classroom Management Plugin, um seine Ideen mit Hilfe einer visuellen Sprache in zwei verschiedenen Arbeitsmappen zu formulieren. Zuerst erstellt er eine Arbeitsmappe für die Einzelarbeit und überlegt sich, dass er die zu dem Thema bereits vorbereiteten FreeStyler-Dokumente zu Beginn des Unterrichts an die Schüler austeilen wird, woraufhin die Schüler mit der Arbeit beginnen. Die Einzelarbeit soll nur einen Teil der Unterrichtszeit in Anspruch nehmen, während die Schüler in der restlichen Zeit mit Hilfe des FreeStyler-Sitzungsmechanismus in Gruppen zusammenarbeiten sollen. Hierfür erzeugt er eine weitere Arbeitsmappe und überlegt sich, dass für die anstehenden Aufgaben eine Gruppengröÿe von drei Schülern pro Gruppe angemessen ist. Er erstellt die einzelnen Gruppen und teilt die Schüler anhand ihrer Benutzerkennungen in die jeweiligen Gruppen ein. Daraufhin ordnet er den einzelnen Gruppen je eine weitere FreeStyler-Arbeitsmappe zu, welche während des Unterrichts ausgeteilt und gemeinsam bearbeitet werden soll. Nachdem der Lehrer die beiden Arbeitsmappen auf einem USB-Stick gespeichert hat, ist er mit der Vorbereitung des Unterrichts fertig. Zu Beginn des Unterrichts laden Schüler und Lehrer den FreeStyler. Der Lehrer lädt nun die erste vorbereitete Arbeitsmappe vom USB-Stick, woraufhin das System automatisch im Einzelarbeitsmodus startet. Bereits angemeldete Schüler werden automatisch erkannt und im Graph angezeigt, sofern dies in der Arbeitsmappe modelliert wurde. Alle übrigen Schüler werden in der Palette des Classroom Management Plugins angezeigt und können vom Lehrer in den Arbeitsbereich gezogen werden. Im Anschluss verteilt der Lehrer die Arbeitsmappen an die Schüler und teilt ihnen mündlich den Arbeitsauftrag für die Einzelarbeit mit. Während die Schüler an den Dokumenten arbeiten, kann der Lehrer den Lernfortschritt mit Hilfe des FreeStyler-Plugins verfolgen, das ihm eine Übersicht darüber liefert, aus wie vielen Knoten und Kanten die Modelle der Schüler bestehen. Erkennt der Lehrer in dieser Übersicht einen Schüler, der bisher verhältnismäÿig wenig an seinem Modell gearbeitet hat, kann er über das System einen Screenshot des Schülerrechners anfordern und ihn gegebenenfalls animieren, seine Aufmerksamkeit verstärkt auf die Bearbeitung der Aufgabe zu lenken. Sobald die Zeit für die Einzelarbeit abgelaufen ist, nutzt der Lehrer das System, um die Arbeitsmappen der Schüler einzusammeln und auf seinem Rechner zu speichern. Für den zweiten Teil der Unterrichtsstunde lädt der Lehrer die Arbeitsmappe für die Gruppenarbeit. Auch hier werden die Schüler automatisch erkannt und den einzelnen Gruppen zugeordnet. Um die kollaborative Arbeit zu starten, trägt der Lehrer die Adresse des Synchronisationsservers ein und wechselt in den Kollaborationsmodus, wodurch die Schüler-FreeStyler automatisch den kongurierten Sitzungen beitreten. Nun kann der Lehrer die Arbeitsunterlagen über das System austeilen und den Schülern mündlich den Arbeitsauftrag erläutern. Daraufhin beginnen die Schüler die erörterte Aufgabe innerhalb ihrer Gruppe mit Hilfe des FreeStylers zu bearbeiten. Der Lehrer kann wiederum den Lernfortschritt der Sitzungen erfassen und darüber hinaus laufenden Sitzungen beitreten und die erarbeiteten Lösungen mit Hilfe eines Beamers präsentieren. Sowohl vor, als auch während der Kollaboration kann der Lehrer die Gruppenkonstellation verändern, um z.b. auf fehlende Schüler zu reagieren. Am Ende der Unterrichtsstunde sammelt der Lehrer die erstellten Dokumente ein, um sie gegebenenfalls in der nächsten Stunde wiederzuverwenden. 28

35 3.2. Funktionale und nicht-funktionale Anforderungen 3.2. Funktionale und nicht-funktionale Anforderungen Kuhn et al. [KJHH] haben für die Verwaltung computerbasierter Gruppenarbeiten verschiedene funktionale und nicht-funktionale Anforderungen identiziert, die auch für das in dieser Arbeit erstellte System Gültigkeit besitzen. Als funktionale Anforderungen für ein Classroom Management System werden die folgenden Punkte beschrieben: (a) grouping and rearranging of cooperation (b) synchronizing of common workspaces/learning places (c) monitoring, protocolling and archiving (d) [...] presentation and (e) (re-)use of results Diese Anforderungen decken bereits einen Groÿteil der im Szenario vorgestellten Funktionen ab. Um einen Einblick in die Aufgaben eines Lehrers während einer computergestützten Unterrichtsstunde und den damit einhergehenden Aufwand zu gewinnen, wurden vor der Konzeptionsphase Interviews mit Lehrern geführt. Für diese Interviews haben sie zwei Lehrkräfte zur Verfügung gestellt, die den FreeStyler aktiv im Unterricht einsetzen. Den Interviewpartnern wurde die Aufgabe zuteil, die praktische Relevanz verschiedener möglicher Funktionen zu bewerten. Darüber hinaus wurden diese Interviews genutzt, um sich einen Überblick über die jeweiligen Unterrichtssituationen zu verschaen. Dies beinhaltet die Erfassung von Informationen über die durchschnittliche Klassengröÿe, die Ausstattung der Computerräume und die aktuell eingesetzten Systeme zur Verwaltung der Unterrichtsmaterialien. Die Ergebnisse dieser Interviews können im Anhang begutachtet werden. Besonders hervorzuheben ist hierbei die aktuelle Verwaltung der Arbeitsunterlagen. Zu diesem Zweck kommen Sekundärsysteme wie Moodle oder File-Server zum Einsatz, mit deren Hilfe die FreeStyler-Arbeitsmappen den Schülern verfügbar gemacht werden. Auch die Abgabe der bearbeiteten Dokumente erfolgt am Ende der Unterrichtsstunde über diese Systeme, wobei die Arbeitsmappen von den Schülern manuell eingepegt werden. Auf Basis dieser Interviews wurden die bisher aufgestellten Anforderungen um zwei weitere Aspekte erweitert. Diese Anforderungen lassen sich dem Bereich der Document Management Systeme zuordnen und vervollständigen den Katalog der funktionalen Anforderungen. (f) Verteilung von Arbeitsmaterialien an einzelne Schüler oder Gruppen (g) Einsammeln von Arbeitsmaterialien an einzelne Schüler oder Gruppen Während sich das in Abschnitt beschriebene System für Cool Modes allein auf die Speicherung der Arbeitsmappen der Sitzungen konzentrierte, wird durch die hier aufgestellten Anforderungen auch die Verteilung vorbereiteter Arbeitsmappen an Sitzungen gefordert. Darüber hinaus soll das zu entwickelnde System nicht mehr auf den Einsatz in Gruppenarbeitsszenarien beschränkt werden, sondern muss auch nicht-kollaborative Unterrichtssituationen unterstützen. Auf diese Weise wird eine wesentlich spezischere Modellierung der Klassenraumsituation ermöglicht. Darüber hinaus bietet sich der Vorteil, dass das Arbeitsmaterial nicht mehr mit Sekundärsystemen an die Schüler verteilt und manuell in den FreeStyler geladen werden muss. 29

36 3. Konzept Neben den dargestellten Funktionen sollte ein Classroom Management System weiteren Anforderungen genügen, um von Lehrern für die Unterrichtsplanung und -durchführung akzeptiert zu werden. Nach Kuhn et al. ergeben sich... other (non-functional) requirements concerning handling, performance, reliability and added value. Diese Eigenschaften zielen darauf ab, die Usability (dt. Gebrauchstauglichkeit) eines Designs zu erhöhen und beeinussen sowohl die Einarbeitungszeit, als auch die Zeit, um den aktuellen Zustand des Systems zu erfassen und entsprechende Aktivitäten durchzuführen. Die Verwendung einer visuellen Sprache zur Planung und Verwaltung von Unterrichtsstunden zielt - ebenso wie das gewählte Design der einzelnen Komponenten - darauf ab, Aufgaben eektiv, ezient und zur Zufriedenheit des Nutzers ausführen zu können Beschreibung des Systems Das in dieser Arbeit vorgestellte System dient dazu, die Planung und Koordination des Unterrichts zu unterstützen. Es werden verschiedene Arbeitsphasen durchlaufen, die es durch ein entsprechendes Programm zu berücksichtigen gilt. Folgende Phasen werden durch das hier beschriebene Konzept berücksichtigt: Planung In dieser Phase plant der Lehrer einzelne Unterrichtsstunden im Vorhinein. Hierzu können die Art der Zusammenarbeit, wie auch der Einsatz bestehender Arbeitsunterlagen gezählt werden. Unterrichtsbeginn Der Lehrer und die Schüler haben ihre Plätze im Klassenraum eingenommen und die Computer gestartet. Diese Phase umfasst Aktivitäten, die vor dem eigentlichen Unterricht durchgeführt werden müssen. Unterricht In dieser Phase bearbeiten die Schüler mit dem FreeStyler entweder einzeln oder in Gruppen die vom Lehrer gestellten Aufgaben. Der Lehrer verfolgt das Unterrichtsgeschehen und greift gegebenenfalls aktiv ein. Unterrichtsende Wenn sich die Unterrichtsstunde dem Ende zuneigt, fallen für den Lehrer zusätzliche Aktivitäten an. Diese Aufgaben müssen beendet sein, bevor die Computer heruntergefahren werden können. Um den Lehrer bestmöglich zu unterstützen, sollte ein Classroom Management System zu einer Reduzierung des administrativen Aufwandes beitragen. Im weiteren Verlauf werden die notwendigen Komponenten des in dieser Arbeit entwickelten Systems identiziert und die zum Management bereitgestellte visuelle Sprache erläutert. Im Anschluss erfolgt anhand der soeben vorgestellten Arbeitsphasen eine Beschreibung der Funktionen des konzipierten Systems. 30

37 3.3. Beschreibung des Systems Komponenten Um das Konzept dieses Systems zu beschreiben, erscheint es sinnvoll, den Fokus zuerst auf die Parteien zu richten, die mit dem System arbeiten werden. Für die hier zugrunde gelegte Klassenraumsituation können die beiden Rollen Lehrer und Schüler identiziert werden. Diese Rollen bringen unterschiedliche Aufgaben und Aktivitäten mit sich. Der Lehrer nimmt im Unterricht den koordinierenden Part ein und steuert den Unterrichtsverlauf, während ein Schüler vom Lehrer Aufgaben gestellt bekommt und diese bearbeitet. Es liegt nahe, ein entsprechendes System anhand dieser Rollen aufzuteilen. Für das im Rahmen dieser Arbeit entwickelte System wird zwischen zwei Komponenten unterschieden, die ihren Dienst innerhalb der FreeStyler-Umgebung verrichten. Die erste Komponente wird vom Lehrer für die Planung und Koordinierung des Unterrichts verwendet und bietet eine visuelle Sprache, um diese Aufgaben durchzuführen. Sie kommuniziert über das Netzwerk mit den Schülerrechnern und versendet entsprechende Instruktionen. Auf den Computern der Schüler kommt die zweite Komponente zum Einsatz, welche die Instruktionen empfängt und verarbeitet. Diese beiden Komponenten werden im Folgenden als AdhocMm bzw. AdhocStudent bezeichnet und sind in Form von zwei FreeStyler-Plugins realisiert. Da das Unterrichts-Management in den Vordergrund gerückt werden soll, wurde der Name des Management-Plugins bewusst von AdhocMM in AdhocMm geändert. AdhocMm AdhocStudent Lehrer Schüler Abbildung 3.1.: Komponenten des Systems Der generelle Ansatz die Schülerrechner über ein entsprechendes Plugin zu verwalten, basiert auf dem in Abschnitt beschriebenen System zum Management kollaborativer Sitzungen mit Cool Modes. Allerdings wurden in dieser Arbeit sowohl auf technologischer, als auch auf konzeptioneller Ebene Veränderungen und Anpassungen dieses Konzepts vorgenommen, um heutigen Anforderungen an eine wartbare und portable Architektur gerecht zu werden und die in Abschnitt 3.2 beschriebenen funktionalen Anforderungen zu erfüllen. Das von Kuhn et al. entwickelte System setzt auf die Verwendung eines Plugins zur Koordinierung der Schülerrechner. Die entsprechenden Funktionen auf Seiten der Schüler, welche für die Interpretation der Kommandos zuständig sind, wurden hingegen direkt innerhalb von Cool Modes realisiert. Neben einem erhöhten Wartungsbedarf durch diese enge Integration, ist die mangelnde Portabilität ein entscheidender Nachteil des gewählten Systemdesigns. Diese Probleme liefern die wichtigsten Argumente für die Entscheidung, die notwendigen Funktionen in zwei FreeStyler-Plugins umzusetzen. 31

38 3. Konzept Während das AdhocMm-Plugin in allen Phasen zum Einsatz kommt, ndet die Unterrichtsplanung ohne Beisein der Schüler statt, weshalb die AdhocStudent-Komponente sich auf die Unterstützung der drei Phasen vom Beginn bis zum Ende des Unterrichts konzentriert. An dieser Stelle soll bereits auf eine Besonderheit des AdhocMm-Plugins aufmerksam gemacht werden. Dieses Plugin unterscheidet zwischen zwei verschiedenen Betriebsmodi. Hierbei handelt es sich um den Planungs-/Einzelarbeitsmodus und den Kollaborationsmodus, wobei nach dem Start des Plugins der Planungs-/Einzelarbeitsmodus aktiviert wird. Der Unterschied wird im weiteren Verlauf bei der Vorstellung der Unterstützungsfunktionen für die einzelnen Arbeitsphasen verdeutlicht Visuelle Sprache Für die Modellierung von Unterrichtsszenarien können sowohl Metasprachen - wie IMS Learning Design [IMS03] - zur textuellen Beschreibung, als auch Systeme mit einer graphischen Notation wie das in Abschnitt erläuterte SceDer zum Einsatz kommen. Dabei besitzen Systeme mit einer visuellen Repräsentation den Vorteil der schnelleren Erlernbarkeit und bieten sich eher für die spontane Nutzung durch Lehrer an [KJHH]. Aus diesem Grund kommt für diese Arbeit die graphische Modellierung, basierend auf der von Kuhn et al. entwickelten AdhocMM -Notation, zur Anwendung. Dabei wurden entsprechende Anpassungen und Erweiterungen vorgenommen, um den in Abschnitt 3.2 dargelegten Anforderungen gerecht zu werden. Diese visuelle Sprache bildet das wichtigste Instrument für die Planung und Verwaltung (kollaborativer) Unterrichtseinheiten mit Hilfe des entwickelten Systems und hebt sich durch seine Flexibilität von der, in Abschnitt vorgestellten, rudimentären Gruppenverwaltung ab. Im Folgenden sollen die einzelnen Sprachelemente im Detail besprochen werden. Abbildung 3.2 liefert eine Übersicht über die, in gewohnter FreeStyler-Manier als Knoten und Kanten dargestellten, graphischen Elemente. SessionNode MaterialEdge MaterialNode AllowEdge ForceEdge PlaceNode UserNode Abbildung 3.2.: Elemente der visuellen Sprache des AdhocMm-Plugins Zur Beschreibung eines Schülers, der aktuell nicht am System angemeldet ist, wird der PlaceNode verwendet. Dieser übernimmt dieselbe Platzhalter-Funktion, die der slot node im entsprechenden Cool Modes-Vorgänger zur Aufgabe hatte. Während die Schüler 32

39 3.3. Beschreibung des Systems zur heutigen Zeit häug eigene Benutzerkennungen erhalten, um sich am Betriebssystem anzumelden, gibt es ebenfalls Schulen oder Klassenräume in denen keine zentrale Benutzerverwaltung im Einsatz ist und die Schüler sich mit einem Standardkonto einloggen. Um die Identikation eines Schülers in beiden Fällen zu gewährleisten, kann einem PlaceNode entweder ein Benutzername oder ein Hostname zugeordnet werden. Ist ein Schüler am System angemeldet, wird dieser durch einen UserNode symbolisiert. Damit der Lehrer einen Schüler in beiden möglichen Szenarien, Anmeldung durch ein Standardkonto oder mittels eigener Benutzerkennung, eindeutig identizieren kann, werden innerhalb des Knotens Benutzername, Rechnername und IP-Adresse angezeigt. Sollen mehrere durch entsprechende Knoten repräsentierte Schüler kollaborativ in Sitzungen arbeiten, werden die Knoten mit einem SessionNode verbunden. Dieser Knoten dient als Repräsentant einer Sitzung und verfügt über zwei Bezeichner. Der erste Bezeichner wird durch den Lehrer gewählt und dazu genutzt, die Sitzung zu beschreiben. Diese Beschreibung ist auch auf Seiten der Schüler erkennbar. Ein solcher Bezeichner muss nicht notwendigerweise eindeutig sein und kann jederzeit geändert werden. Auf der anderen Seite wird ein Identier benötigt, der die Sitzung eindeutig identiziert und in Abschnitt näher beschrieben wird. Die Semantik der bisher vorgestellten Knoten ist mit den Elementen des Cool Modes- Plugins identisch. Der database node ist hingegen durch den MaterialNode ersetzt worden, um den Verwaltungsaspekt der Unterrichtsmaterialien hervorzuheben. Der Lehrer kann diesen Knoten einsetzen, um Arbeitsmappen zu speichern und zu verteilen. Neben den vier beschriebenen Knoten gehören drei Kantentypen zum Sprachumfang. Die AllowEdge und die ForceEdge können verwendet werden, um einen UserNode bzw. PlaceNode mit einem SessionNode zu verbinden. Soll einem Schüler der Beitritt in mehrere verschiedene Sitzungen gestattet werden, zwischen denen er nach Belieben wechseln kann, so kann der Lehrer mehrere AllowEdges verwenden und den Schüler-Knoten mit den entsprechenden SessionNodes verbinden. In diesem Fall kann sich der Schüler auch dazu entschlieÿen, an keiner Sitzung teilzunehmen. Möchte der Lehrer hingegen forcieren, dass der Schüler an einer bestimmten Sitzung teilnimmt, verwendet er die ForceEdge als Verbindung. Aufgrund dieser Semantik kann ein User- oder PlaceNode auch nur mit einer ForceEdge verbunden werden. Auch die Kombination der beiden Kantentypen gestattet keine sinnvolle Interpretation und wird vom System unterbunden. Beide Kanten werden standardmäÿig als gestrichelte Linie dargestellt. Um zu visualisieren, dass ein Schüler der entsprechenden Sitzung beigetreten ist, wird eine durchgezogene Linie verwendet. Ein MaterialNode kann mit Hilfe von MaterialEdges mit allen anderen Knotentypen verbunden werden. Auf diese Weise kann der Lehrer Arbeitsmaterial sowohl an einzelne Schüler, als auch an Sitzungen austeilen und einsammeln. Um Mehrdeutigkeiten zu vermeiden, können Knoten allerdings nicht mit mehreren MaterialNodes verbunden werden. Darüber hinaus ist es nicht gestattet, einen Material-Knoten mit einem User- oder PlaceNode zu verbinden, der bereits eine Verbindung zu einem SessionNode besitzt. Dieses Fehlerszenario kann in Abbildung 3.3 nachvollzogen werden. Auch die MaterialEdge verwendet zwei Visualisierungen. Nachdem eine solche Kante erstellt wurde, wird eine gestrichelte Linie zwischen den Knoten angezeigt. Wenn eine Arbeitsmappe an den Schüler bzw. die Sitzung ausgeteilt wird, wird zur Darstellung eine durchgezogene Linie verwendet. Die Darstellung der MaterialEdge ist von der ausgewählten Datei abhängig und verändert sich, falls dem MaterialNode eine andere Datei zugewiesen wird. 33

40 3. Konzept Abbildung 3.3.: Beispiel für einen Graph, der durch das AdhocMm-Plugin unterbunden wird Diese Knoten und Kanten stellen die syntaktischen Elemente der visuellen Sprache dar. Ein modelliertes Lernszenario kann somit die Komponenten Schüler, Gruppen und Unterrichtsmaterialien enthalten. Die graphische Notation bietet sich für die Planung von Unterrichtszenarien an und bietet somit einen Mehrwert gegenüber den in Abschnitt 2.4 vorgestellten Systemen SMART Classroom Suite, INiS und Epoptes. Die Modellierung von expliziten Gruppenkonstellationen ist eine Funktion, die dieses System vom Scenario Designer Tool unterscheidet. SceDer verfügt über keine Möglichkeit, die Mitglieder einer Gruppe explizit zu denieren. Stattdessen legt das System für jede Gruppe ein schwarzes Brett an, dass die Schüler selbstständig auswählen müssen Unterstützung der Unterrichtsplanung Während der Planungsphase verwendet der Lehrer das AdhocMm-Plugin, um die verschiedenen Unterrichtssituationen zu modellieren. Über die Palette hat er Zugri auf die SessionNodes und PlaceNodes, die in den Arbeitsbereich gezogen werden können. Die Palette bietet ebenfalls die Möglichkeit, Allow- und ForceEdges zu zeichnen und somit die Platzhalter den einzelnen Sitzungen zuzuordnen. Durch den Einsatz der gerade beschriebenen Elemente ist der Lehrer in der Lage die Anzahl und Gröÿe der Gruppen zu denieren (vgl. technische Anforderung (f)). Um darzustellen, dass FreeStyler-Arbeitsmappen ausgeteilt werden sollen, können über die Palette MaterialNodes in den Arbeitsbereich gezogen und unter Zuhilfenahme der MaterialEdges mit einer beliebigen Anzahl an Place- und SessionNodes verbunden werden. Einem einzelnen MaterialNode wird hierbei eine bestimmte Arbeitsmappe zugewiesen, die an die verbundenen Parteien ausgeteilt wird. Sollen verschiedene Dokumente ausgeteilt werden, wird dies durch mehrere MaterialNodes modelliert. Plant der Lehrer die bearbeiteten Dokumente von den Schülern einzusammeln, kommt zu diesem Zweck ebenfalls der MaterialNode zum Einsatz. Somit können die Arbeitsmappen in einer weiteren Unterrichtsstunde problemlos wiederverwendet werden. Diese Funktionen gehen über den Funktionsumfang des Cool Modes AdhocMM-Plugins hinaus - das nur die Speicherung von Sitzungen erlaubte - und erfüllen die Anforderungen (e) bis (g). Diese sieben Elemente bilden die Grundlage, um verschiedene kollaborative Klassenraumsituationen zu beschreiben. Kommt in einer Unterrichtsstunde hingegen ausschlieÿlich 34

41 3.3. Beschreibung des Systems Einzelarbeit zum Einsatz, kann auf die SessionNodes und die entsprechenden Allow- und ForceEdges verzichtet werden. Nachdem der Lehrer die Modellierung der Unterrichtssituation beendet hat, muss er die erstellte AdhocMm-Arbeitsmappe speichern, um sie in der nächsten Unterrichtsstunde zu verwenden und eventuell als Vorlage für künftige Lehreinheiten zu verwahren. Hierfür werden dem Lehrer zwei Möglichkeiten zur Speicherung geboten. So kann er die übliche Speicherfunktion des FreeStylers nutzen und eine gewöhnliche Arbeitsmappe erzeugen. Diese Datei enthält allerdings ausschlieÿlich Verweise auf die entsprechenden Dokumente der MaterialNodes. Zwar wäre es technisch möglich, diese Dateiinhalte in die AdhocMm- Arbeitsmappe zu kodieren, allerdings erscheint ein weiterer Exportmechanismus, der die Speicherfunktion des FreeStylers aufruft, besser geeignet. Diese lose Kopplung sorgt dafür, dass das Plugin von der konkreten Implementierung der FreeStyler-Speicherroutine unabhängig bleibt. Um alle Unterlagen gebündelt zu speichern, bietet die Palette des AdhocMm-Plugins Zugri auf diese zusätzliche Export-Funktion. Hierbei wird eine einzelne gepackte Datei erzeugt, die neben dem Modell alle notwendigen Dokumente enthält. Auf diese Weise wird die einfache und komfortable Übertragung einer AdhocMm- Arbeitsmappe auf einen anderen Rechner ermöglicht Unterstützung des Unterrichtsbeginns Zu Beginn der Unterrichtsstunde fallen eine Reihe Aufgaben an, bevor der Lehrer mit dem eigentlichen Unterricht beginnen kann. Hierzu zählen Aktivitäten wie die Überprüfung, ob alle Schüler ihren FreeStyler geönet haben und die Organisation des Arbeitsmaterials. Sollen die Schüler kollaborativ arbeiten, kommen Aktivitäten wie der Start des Synchronisationssystems und die Sitzungskonguration hinzu. Für diese Aktivitäten bietet das in dieser Arbeit beschriebene System verschiedene Funktionen an. Nach der Anmeldung am Betriebssystem starten der Lehrer und die Schüler den FreeStyler mit entsprechendem AdhocMm- bzw. AdhocStudent-Plugin. Damit der Lehrer die Schülerrechner verwalten kann, müssen sich die einzelnen Komponenten zuerst einmal nden. Zu diesem Zweck kommt ein Service Discovery Mechanismus auf Basis von IP- Multicasting zum Einsatz, der in Abschnitt näher beschrieben wird. Dieser Prozess ndet ohne Zutun der Benutzer statt und beugt somit Kongurationsfehlern und damit einhergehenden Verzögerungen vor. Mit Hilfe des AdhocMm-Plugins kann der Lehrer einen Überblick über die Schüler gewinnen, die das AdhocStudent-Plugin geladen und sich bei seinem System bekannt gemacht haben. Jeder Schüler wird als UserNode innerhalb der Palette angezeigt. Da es sich hierbei um einen gewöhnlichen Knoten handelt, kann dieser per Drag and Drop in die Arbeitsmappe gezogen werden. Wird ein solcher Knoten gelöscht, wird dieser wieder der Palette hinzugefügt. Zwar nimmt die Darstellung der Benutzer als UserNodes relativ viel Platz innerhalb der Palette in Anspruch, doch bietet sich die vertraute Darstellung als Knoten im FreeStyler-Kontext an und erfüllt somit die Erwartungshaltung des Benutzers. Wird eine vorbereitete Arbeitsmappe geladen, werden die PlaceNodes automatisch durch die entsprechenden UserNodes ersetzt. Um eine Zuordnung zwischen diesen beiden Knotentypen herzustellen, verwendet AdhocMm die Benutzerkennung und den Hostnamen des Schülerrechners. Der Mechanismus, der zur Ersetzung von PlaceNodes zuständig ist, 35

42 3. Konzept bietet dabei nicht nur die einmalige Ersetzung während des Ladevorganges einer Arbeitsmappe, sondern führt auch Ersetzungen bei sogenannten Late-Comern durch. Am Ende von Abschnitt wurde bereits erwähnt, dass das AdhocMm-Plugin zwei verschiedene Modi unterscheidet. Während die bisher erläuterten Konzepte von dem gerade aktivierten Modus unberührt bleiben, wird den Besonderheiten der Verwaltung kollaborativer Sitzungen mit Hilfe des Kollaborationsmodus Rechnung getragen. Dieser kann über die Palette aktiviert und auch wieder deaktiviert werden, wodurch der Planungsmodus erneut aktiviert wird. Die Aktivierung des Kollaborationsmodus bewirkt, dass die kongurierten Sitzungen gestartet werden. Dies hat zur Folge, dass das AdhocMm-Plugin Nachrichten über das Netzwerk an die AdhocStudent-Instanzen sendet und ihnen die aktuellen Sitzungsdaten mitteilt. Neben der Adresse und dem Port des MatchMaker-Servers beinhaltet dies die verfügbaren Sitzungen für jeden Schüler. Das AdhocStudent-Plugin wertet die Nachricht aus und präsentiert dem Benutzer diese Sitzungen. Ist mit Hilfe von AllowEdges der Zutritt zu mehreren Sitzungen erlaubt, so werden die Namen der Sitzungen in der Palette zur Auswahl gestellt und der Benutzer kann diesen manuell beitreten. Darüber hinaus kann der Benutzer die gerade aktive Sitzung über die Palette auch wieder verlassen. Für den Fall, dass eine ForceEdge verwendet wurde, tritt der entsprechende FreeStyler direkt der Sitzung bei. Der Benutzer kann diese Sitzung nicht selbstständig verlassen. Damit der Benutzer diese Einschränkungen nicht umgehen kann, wird die übliche FreeStyler-Sitzungsverwaltung in der Menüleiste ausgeblendet. Als weitere Aufgabe dieser Phase wurde die Verteilung von Arbeitsmappen an die Schüler aufgezählt. Um dem Lehrer die Wahl zu lassen, zu welchem Zeitpunkt die Arbeitsmappen ausgeteilt werden sollen, wurde auf eine automatische Verteilung verzichtet. Stattdessen erfolgt die Ausgabe manuell über eine Schaltäche des MaterialNodes. Daraufhin übermittelt das AdhocMm-Plugin die Arbeitsmappe über das Netzwerk an die AdhocStudent- Rechner. Um einem möglichen Datenverlust vorzubeugen, wird die aktuelle Arbeitsmappe des Schülers nicht ersetzt. Stattdessen werden die Seiten an die aktuelle Arbeitsmappe oder Sitzung angefügt. Dieses Vorgehen bietet dem Lehrer zusätzliche Flexibilität, da er während der Unterrichtsstunde mehrere Aufgaben nacheinander austeilen kann und die Schüler problemlos auf die vorher bearbeiteten Aufgaben zugreifen können. Gerade die direkte Verteilung von Dokumenten in bestehende FreeStyler Arbeitsmappen bietet eine komfortablere und ezientere Handhabung im Vergleich zu dem in Abschnitt vorgestellten INiS. Darüber hinaus ist hierfür kein zusätzliches Programm notwendig, wie dies bei der in Abschnitt beschriebenen Dokumentenverwaltung für Computer-integrated Classrooms der Fall ist Unterstützung des Unterrichts Nachdem eventuellen Sitzungen beigetreten und das Arbeitsmaterial ausgeteilt wurde, kann der eigentliche Unterricht beginnen. Auch während des Unterrichts kann der Lehrer auf Funktionen des Systems zurückgreifen. Möchte der Lehrer wissen, welche sonstigen Programme ein Schüler zur Lösung der Aufgaben verwendet, kann er über den User- Node einen Screenshot des Schülerrechners anfertigen lassen. Daraufhin wird eine Nachricht über das Netzwerk gesendet und das entsprechende AdhocStudent-Plugin fertigt ein Bildschirmfoto an. Der Screenshot wird an den Lehrerrechner übertragen und in einem eigenen Fenster angezeigt. An dieser Stelle sei darauf hingewiesen, dass diese Funktion 36

43 3.3. Beschreibung des Systems unter rechtlichen Aspekten nicht unproblematisch ist. Die rechtliche Grundlage für den Einsatz dieser Funktion wird am Endes dieses Abschnitts erläutert. Über eine Schaltäche des SessionNodes kann der Lehrer einer bestehenden Sitzung beitreten und sich einen Eindruck über das von der Gruppe erstellte Modell verschaen. Um den Überblick über die verschiedenen geöneten Sitzungen zu behalten, wird jede Sitzung in einem neuen FreeStyler geönet. Dieser tritt beim Start automatisch der jeweiligen Sitzung bei. Sowohl die Anfertigung von Screenshots, als auch der Beitritt einer Sitzung stellen dem Lehrer Monitoring-Funktionen zur Verfügung und zielen auf die Erfüllung der Anforderung (c) ab. Darüber hinaus kann der Beitritt einer Sitzung zum Einsatz kommen, wenn der Lehrer das Modell einer bestimmten Sitzung über einen Beamer präsentieren möchte (vgl. Anforderung (d)). Während sich die bisher vorgestellten Funktionen auf den statischen Aspekt der Planung von Gruppenarbeiten konzentrieren, bietet das hier vorgestellte System darüber hinaus die Möglichkeit, die Gruppenkonstellation während des Unterrichts zu ändern. An dieser Stelle kommen die vorher bereits erwähnten Modi zum Einsatz. Sollen die vom Lehrer getätigten Änderungen der Gruppenkonstellationen sofort angewendet werden, wird hierfür der Kollaborationsmodus aktiviert. Möchte der Lehrer die aktuelle Gruppenkonstellation stattdessen in aller Ruhe bearbeiten, ohne dass die Änderungen sofort wirksam werden, so verwendet er den Planungs-/Einzelarbeitsmodus. Hierbei kann exibel zwischen diesen beiden Modi gewechselt werden, wobei die Aktivierung des Kollaborationsmodus das System in das aktuelle Modell überführt. Im Folgenden wird eine Übersicht über die verschiedenen Aktionen des AdhocMm-Plugins und die jeweilige Reaktion auf Seiten der AdhocStudent-Komponente geliefert, wenn der Kollaborationsmodus aktiv ist. Hinzufügen einer AllowEdge Palette angezeigt. Die neue Sitzung wird innerhalb der AdhocStudent- Hinzufügen einer ForceEdge Das AdhocStudent-Plugin veranlasst den FreeStyler des Schülers, der Sitzung beizutreten. Löschen einer AllowEdge Die Sitzung wird aus der Palette des AdhocStudent-Plugins entfernt. Falls der FreeStyler aktuell Mitglied der Sitzung ist, beendet er seine Mitgliedschaft. Der FreeStyler des Schülers verlässt die entsprechende Sit- Löschen einer ForceEdge zung. Löschen eines SessionNode Die AdhocStudent-Instanzen führen in Abhängigkeit von der gelöschten Kante die jeweilige Aktion aus. 37

44 3. Konzept Löschen eines UserNode Falls der FreeStyler mit einer Sitzung verbunden ist, wird diese verlassen. Darüber hinaus wird die Liste der verfügbaren Sitzungen geleert. Diese direkte Rekonguration ist eine Eigenschaft die das in Abschnitt dargestellte Classroom Management System für GroupScribbles nicht bieten kann. Die SMART Classroom Suite kann zwar Schüler während des Unterrichts in Gruppen zusammenfassen, bietet aber lediglich die Möglichkeit, randomisierte Gruppierungen zu erstellen. Damit das Laden einer AdhocMm-Arbeitsmappe die aktuell laufenden Sitzungen nicht beeinusst, wird das System nach dem Ladevorgang automatisch in den Planungs-/Einzelarbeitsmodus überführt. Ein geladene Sitzungskonguration muss somit explizit aktiviert werden. Neben diesen Aktionen ist die Situation vorstellbar, dass der Lehrer eine im Vorhinein auf dem Synchronisationsserver erstellte Sitzung nutzen möchte. Hierbei stellt sich allerdings das Problem, dass für eine solche Sitzung noch kein SessionNode existiert. Zu diesem Zweck kann der Lehrer über die AdhocMm-Palette einen neuen SessionNode in den Arbeitsbereich ziehen und diesem eine bestehende Sitzung zuordnen. Daraufhin kann er die Sitzung wie gewohnt verwenden. Darüber hinaus soll im Rahmen dieser Arbeit auch der, in Abschnitt 2.3 erläuterte, Aspekt der Awareness Beachtung nden. Der FreeStyler bietet dem Benutzer zum aktuellen Zeitpunkt bereits die Möglichkeit, sich unterhalb der Palette einen Thumbnail der aktuellen Seite anzeigen zu lassen. Diese Funktion hilft dem Benutzer dabei, den Überblick über ein gröÿeres Modell zu behalten und Änderungen anderer Benutzer zu verfolgen, auch wenn diese in anderen Teilen des Arbeitsbereichs stattnden. Diese Anzeige zielt darauf ab, eine aufgabenorientierte Awareness im Programm herzustellen. Um darüber hinaus eine soziale Awareness zu erzeugen, wird im AdhocStudent-Plugin eine Liste der anderen Teilnehmer der aktuellen Sitzung geliefert. Diese Übersicht wird innerhalb der Palette angezeigt, sobald der Schüler einer Sitzung beigetreten ist Unterstützung des Unterrichtsendes Kurz vor Ende der Unterrichtsstunde müssen die, von den Schülern bearbeiteten, Dokumente eingesammelt werden. Das im Rahmen dieser Arbeit entwickelte Classroom Management System bietet dem Lehrer eine entsprechende Funktion an. Über den Material- Node können die Arbeitsmappen aller damit verbundenen UserNodes und SessionNodes angefordert werden. Die AdhocStudent-Plugins versenden die Arbeitsmappen daraufhin an den Lehrerrechner. Da die Möglichkeit besteht, dass Schüler bereits vorher den FreeStyler beenden, wird die Arbeitsmappe darüber hinaus bei Beendigung des Programms an den Lehrerrechner übermittelt. Um das Risiko von Datenverlusten zu minimieren, gehört darüber hinaus eine Option zum automatischen Speichern der Arbeitsmappen auf dem Lehrerrechner zum Funktionsumfang. Das Intervall für die Speicherung kann über die AdhocMm-Palette festgelegt werden Exkurs: Rechtliche Grundlage für die Erstellung von Screenshots Nach Ÿ3 Absatz 2 des Bundesdatenschutzgesetzes (BDSG) [BDS] fallen unter den Begri personenbezogener Daten [...] Einzelangaben über persönliche oder sachliche Verhältnis- 38

45 3.4. Technische Anforderungen se einer bestimmten oder bestimmbaren natürlichen Person. Hierunter fallen Einzeldaten, die die Zuordnung zu einer Person ermöglichen und umfassen somit auch Screenshots von Schülerrechnern, da diese Benutzerkennungen, Hostnamen oder sonstige, zur Identikation nutzbare, Informationen enthalten können. Das BDSG nennt in Ÿ3a für ein Datenverarbeitungssystem die Zielsetzung [...] so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen und erklärt die Erhebung, Verarbeitung und Nutzung personenbezogener Daten nur dann für zulässig, falls eine andere Rechtsvorschrift dies erlaubt oder der Betroene einwilligt (Ÿ4 Absatz 1). Dies hat zur Folge, dass der Lehrer nur Screenshots anfertigen darf, sofern er sich im Vorhinein eine schriftliche Einwilligung der Schüler oder, falls diese noch minderjährig sind, der Erziehungsberechtigten eingeholt hat [LO.03] Technische Anforderungen Während in den bisherigen Ausführungen stets davon ausgegangen wurde, dass die beiden Systemkomponenten irgendwie Nachrichten über das Netzwerk austauschen können, ist der erste Teil dieses Abschnitts den notwendigen Anforderungen an eine entsprechende Middleware gewidmet. Es werden verschiedene Lösungsansätze vorgestellt und diskutiert, die für die Kommunikation zwischen den Komponenten eingesetzt werden könnten. Zum Abschluss erfolgt eine Übersicht über konkrete Toolkits und eine Gegenüberstellung der Vor- und Nachteile Anforderungen an die Middleware Wie in Abschnitt bereits angedeutet wurde, bedarf das bisher skizzierte System - neben dem Versand einzelner Nachrichten - einen Mechanismus, um andere Ressourcen in einem Netzwerk zu identizieren. Darüber hinaus bietet die AdhocMm-Komponente den Schülerrechnern das Management kollaborativer Sitzungen und die Verwaltung von Arbeitsmaterialien an. Diese Charakteristika entsprechen den in Abschnitt genannten Middleware-Aspekten Resource Discovery, Resource Availability und Resource Communication. Für das zu in dieser Arbeit entwickelte System ergeben sich die folgenden Anforderungen an eine Middleware: (i) Service Discovery (ii) Zuverlässiger Nachrichtenversand mit FIFO-Eigenschaft (iii) Organisation in Gruppen (iv) Benachrichtigung der Gruppenmitglieder bei Join und Leave (ggf. auch Crash) (v) Unterstützung paralleler Kommunikation (vi) Ezienter Nachrichtenversand an mehrere Empfänger Unter Service Discovery versteht sich in diesem Zusammenhang die spontane Kommunikation, bei der sich AdhocMm- und AdhocStudent-Instanzen ohne zusätzliche Infrastruktur, wie z.b. zentrale Namensdienste, selbstständig erkennen und organisieren. Während des Kommunikationsprozesses sollte die eingesetzte Middleware die in Abschnitt

46 3. Konzept aufgelisteten Übertragungsfehler kompensieren und eine vollständige Übertragung der Daten unter Einhaltung der Paketreihenfolge ermöglichen. Für die Bereitstellung der, in Abschnitt Unterstützung des Unterrichts (3.3.5) beschriebenen, Übersicht über die Mitglieder der aktuellen Sitzung, bietet sich eine Organisation von Hosts in Gruppen an. Die Mitglieder der Gruppe sollten automatisch informiert werden, sobald ein neuer Host der Gruppe beitritt oder diese verlässt. Um eine performante Nachrichtenübertragung gewährleisten zu können, sollte der Versand und die Verarbeitung von Nachrichten parallel erfolgen. Dies beinhaltet den gleichzeitigen Versand von Daten an mehrere Teilnehmer, wie dies z.b. bei der Übermittlung von Arbeitsmappen im Einzelunterricht der Fall ist Diskussion verschiedener Middleware-Optionen Soll eine Anwendung dahingehend erweitert werden, dass sie sich - über den Austausch von Nachrichten - mit anderen Systemen koordiniert, bietet sich der Einsatz bereits bestehender Kommunikationslösungen an. Neben der Zeitersparnis ergibt sich durch diese Vorgehensweise der Vorteil, dass die verwendeten Netzwerkfunktionen bereits seit längerer Zeit im Einsatz und dementsprechend erprobt sind. Da der FreeStyler zur Sitzungssynchronisation bereits über zwei Mechanismen verfügt, um mit anderen Computern zu kommunizieren, liegt die Überlegung zur Verwendung dieser Funktionen nahe. Wie in Abschnitt beschrieben wurde, verfügt der FreeStyler zum gegenwärtigen Zeitpunkt über Synchronisationsclients für MatchMaker und XMPP. Die Synchronisation von Arbeitsmappen mit dem Extensible Messaging and Presence Protocol (XMPP) wird innerhalb des FreeStylers durch einen eigenen XMPP-Client unterstützt. XMPP bietet von sich aus bereits die Möglichkeit zum Austausch strukturierter Daten zwischen zwei oder mehreren Hosts an [Int11a]. In [Int11b] wird eine Beschreibung der Instant Messaging Funktionalitäten von XMPP geliefert, wie z.b. die Anzeige des Online-Status einzelner Mitglieder. Diese Möglichkeit bieten sich speziell zur Erfüllung der Anforderungen (iii) und (iv) an. Als zugrundeliegendes Transportprotokoll kommt TCP zur Anwendung und erfüllt somit die Anforderung (ii). Darüber hinaus unterstützt XMPP die parallele Kommunikation, vorausgesetzt es kommt eine entsprechend skalierbare Server-Implementierung zum Einsatz. Aufgrund der folgenden Nachteile wurde davon abgesehen, XMPP für die Kommunikation einzusetzen: XMPP bietet von sich aus kein Service Discovery an. Zwar existiert eine entsprechende Erweiterung [XMP08], doch müsste diese Funktion im aktuellen Client erst noch implementiert werden. Während die Erweiterung technisch problemlos umsetzbar ist, widerspricht sie allerdings der im vorigen Abschnitt geäuÿerten Idee, eine bereits erprobte Technologie zu verwenden. Darüber hinaus würde die Festlegung auf XMPP zu einer Abhängigkeit von einem speziellen Kopplungsmechanismus führen. Die Wartung des FreeStyler XMPP-Clients wäre somit existenziell für die Funktionstüchtigkeit des hier vorgestellten Systems. Die zweite Möglichkeit ist die Verwendung von MatchMaker zur Kommunikation. Während XMPP für den Austausch von Nachrichten konzipiert wurde, kann die Kommunikation per MatchMaker indirekt über spezielle Kommunikationsobjekte erfolgen. Hierbei wird ein Objekt im Synchonization Tree abgelegt und alle Gruppenmitglieder registrieren sich als SyncListener auf diesem Teilbaum. Um eine Nachricht an andere Hosts zu übermitteln, werden die Daten in einem speziellen Attribut des Kommunikationsobjekts abgelegt. Der MatchMaker-Server fungiert im Folgenden als eine Art Message-Broker 40

47 3.4. Technische Anforderungen und synchronisiert das Objekt auf allen registrierten Clients. Somit kann der bereits existierende MatchMaker-Client zum Nachrichtenversand verwendet werden. In diesem Fall sorgt der MatchMaker Server dafür, dass die Nachrichten zuverlässig und in der richtigen Reihenfolge am Ziel ankommen. Verschiedene Gruppen können durch unterschiedliche Kommunikationsobjekte im Sync-Tree realisiert werden, wobei sogar Hierarchien abgebildet werden könnten. Darüber hinaus bietet MatchMaker Benachrichtigungen, wenn ein Client eine Sitzung betritt oder verlässt. Wie die vorherige Option, kommt auch MatchMaker aus folgenden Gründen nicht als Middleware in Frage: Zum einen bietet MatchMaker keinen Service Discovery an, wodurch diese Funktion eigens implementiert werden müsste. Zum anderen würde das System, wie im vorigen Absatz bereits geschildert, von einem bestimmten Kopplungsmechanismus abhängig gemacht werden. Das entscheidende Kriterium für die Ablehnung liegt allerdings in der Funktionsweise des MatchMaker-Servers selbst. Wird ein Objekt verändert, so propagiert der Server diese Änderung sequentiell an alle registrierten Clients. Da für die Verarbeitung intern nur ein einziger Thread zum Einsatz kommt, können während dieser Zeit keine weiteren Änderungen durchgeführt werden. Diese Eigenschaft widerspricht der Anforderung (v) an eine parallele Kommunikation und führt speziell bei der Übertragung von gröÿeren Daten wie Screenshots oder Unterrichtsmaterialien zu erheblichen Verzögerungen während der Arbeit an gekoppelten Arbeitsmappen. Aufgrund der geschilderten Probleme wurde auf die Verwendung der bereits integrierten Kommunikationsroutinen verzichtet. Stattdessen wird eine neue Middleware eingeführt, deren Auswahl sich an den weiter oben beschriebenen Anforderungen orientiert. In Abschnitt wurden die beiden grundsätzlichen Architekturmodelle für Middleware- Lösungen vorgestellt. Zentralisierte Systeme, wie z.b. die meisten Java Message Service (JMS) [Sun02] Implementierungen, bieten zwar häug Unterstützung für die Point-to- Multipoint Kommunikation, benötigen hierfür allerdings zusätzliche Infrastruktur. So kommen üblicherweise eigene Server-Anwendungen zum Einsatz, um Nachrichten an alle Empfänger zu übermitteln. Aus diesem Grund wird für dieses System eine dezentrale Architektur eingesetzt. Da sich das vorliegende Szenario auf den Einsatz in lokalen Netzwerken konzentriert, bietet sich die Multicast-Technologie als leichtgewichtige Middleware- Lösung an. Das in Abschnitt beschriebene IP-Multicasting kommt in verschiedenen Einsatzgebieten, wie z.b. Universal Plug and Play, für das Service Discovery zur Anwendung und erfüllt bereits eine Mehrzahl der oben genannten Anforderungen. Nicht erfüllt werden der zuverlässige Nachrichtenversand unter Einhaltung der Paketreihenfolge und der Erhalt von Benachrichtigungen, wenn ein Host eine Gruppe betritt oder verlässt. Um diese Lücke zu schlieÿen, bieten sich Reliable Multicast Systeme zur Verwendung an, die im folgenden Abschnitt besprochen werden sollen Reliable Multicast Systeme In der heutigen Zeit gehört die Unterstützung von IP-Multicasting zum Portfolio aller gängigen Programmiersprachen. Als zugrundeliegendes Transportprotokoll kommt in aller Regel UDP zur Anwendung, dass einen unzuverlässigen Versand von Datagrammen an eine Multicast-Gruppe bietet. Muss der Kommunikationsprozess weiteren Eigenschaften genügen, wie die Vollständigkeit der übertragenen Daten und die Einhaltung der korrekten Reihenfolge, werden üblicherweise spezielle Reliable Multicast Toolkits eingesetzt. 41

48 3. Konzept Darüber hinaus liefern solche Toolkits eine Erweiterung der ursprünglichen Multicast- Gruppen, wodurch die vorherige Anonymität aufgelöst wird. Anwendungen können die aktuellen Mitglieder einer Gruppe erfragen und erhalten Benachrichtigungen, sobald ein neues Mitglied die Gruppe betritt oder ein bestehendes Mitglied die Gruppe verlässt. Für die in dieser Arbeit entwickelten Komponenten wird die Programmiersprache Java eingesetzt, weshalb im Folgenden eine Übersicht über entsprechende Java Toolkits gegeben werden soll. Appia Communication Framework Das Appia Framework 1 besteht aus einem Systemkern und einer Menge von Protokollen. Dabei stellt der Kern die Kommunikations-API für die Anwendungsentwicklung bereit und verfügt über einen Protokoll-Stack, der exibel konguriert werden kann. Je nachdem, welche Eigenschaften für die Kommunikation erforderlich sind, wird der Stack mit den entsprechenden Protokollen konguriert. Zum Umfang des Frameworks gehören unter anderem Protokolle zur Paket-Retransmission und zur Sortierung von Paketen. Der Einsatz des Appia Frameworks ist allerdings problematisch, da das letzte Release im Januar 2011 veröentlicht wurde, woraufhin es nahezu keinerlei Aktivität im Versionsverwaltungssystem, Bug Tracker und den Mailing Listen gab. NeEM NeEM 2 steht für Network-friendly Epidemic Multicast und stellt eine Implementierung des Probabilistic Multicasting Konzepts dar, das häug auch als Gossip-based Multicasting bezeichnet wird. Hierbei wird auf Basis von TCP Point-to-Point Verbindungen ein Overlay Netzwerk erstellt. Der Nachrichtenversand erfolgt baumartig, indem jeder Host, der eine Nachricht empfängt, diese an bestimmte andere Hosts weiterleitet, sofern diese die Nachricht noch nicht erhalten haben. Diese Verfahrensweise bietet eine skalierbare Lösung zur Gruppenkommunikation, wodurch NeEM auch in groÿen Netzwerken zum Einsatz kommen kann [PRM + 03]. Allerdings besitzt dieses System keine Kenntnis über den Status aller Gruppenmitglieder, sondern nur über eine bestimmte Anzahl. Die aktuellste Version wurde im Februar 2010 veröentlicht und der Aktivität im Versionsverwaltungssystem nach zu schlieÿen, wurde die Entwicklung eingestellt. Allerdings wurde während der Entstehung dieser Arbeit der NeEM-Quellcode auf GitHub migriert und die Entwicklung anscheinend wieder aufgenommen. Spread Das Spread Toolkit 3 stellt eine Multi-Broker Architektur dar, die aus mindestens einem Daemon zur Verteilung der Nachrichten besteht. Ein solcher Daemon nimmt Nachrichten von Clients entgegen und sendet diese per Broadcast oder Multicast an die anderen Rechner des Netzwerks. Generell kann auf jedem Host ein solcher Daemon laufen, der darüber hinaus von mehreren lokalen Prozessen verwendet werden kann und auf diese Weise den Verwaltungsaufwand für die Gruppenmitgliedschaft reduziert [ADMA + 04]. Spread wird zum Zeitpunkt der Erstellung dieses Arbeit aktiv weiterentwickelt. Als Nachteil dieses Toolkits ist die Limitierung der Nachrichtengröÿe auf 100 Kilobytes zu nennen

49 3.5. Architektur JGroups JGroups 4 stellt ein weiteres Reliable Multicast System dar, das unter anderem als grundlegendes Clustering-Framework im JBoss J2EE Application Server 5 eingesetzt wird. Ähnlich wie das Appia Application Framework bietet JGroups einen frei kongurierbaren Protokoll-Stack und eine Vielzahl von Protokollen an, um die Kommunikation ganz an die Bedürfnisse der zu entwickelnden Anwendung anzupassen. JGroups bietet innerhalb einer Multicast-Gruppe ein eigenes Gruppenkonzept, das als Cluster bezeichnet wird und ermöglicht den Einsatz mehrerer Cluster in einer Multicast-Gruppe. Wie Appia und Spread liefert auch JGroups Informationen über den Status der einzelnen Gruppenmitglieder und benachrichtigt die Anwendung bei einer Veränderung. Name Multicasting-Art Beliebige Nachrichtengröÿe Entwicklung Appia IP-Multicasting Ja inaktiv NeEM Epidemic-Multicasting Ja (inaktiv) Spread IP-Multicasting nur Unicast aktiv JGroups IP-Multicasting Ja aktiv Tabelle 3.1.: Gegenüberstellung der Java Reliable Multicast Frameworks Tabelle 3.1 liefert einen kompakten Überblick über die verschiedenen Frameworks und die Eigenschaften, die Einuss auf die Wahl des konkreten Systems genommen haben. Hierbei ist zum einen eine aktive Entwicklung des Systems in die Entscheidung eingeossen, da somit die Wahrscheinlichkeit erhöht wird, dass Bugs in dem entsprechenden System von den Entwicklern behoben werden. Diesen Punkt konnten zur Zeit der Entscheidungs- ndung lediglich das Spread Toolkit und JGroups für sich beanspruchen. Zum anderen darf es von Seiten des Systems nicht zu Limitierungen der Nachrichtengröÿe kommen, da auch gröÿere Datenmengen, wie z.b. FreeStyler Arbeitsmappen, verteilt werden sollen. Dieser Aspekt spricht gegen die Verwendung von Spread. Diese Eigenschaften waren die ausschlaggebenden Faktoren für die Wahl von JGroups als Middleware-Lösung Architektur Nachdem JGroups als zugrundeliegende Middleware ausgewählt wurde, soll an dieser Stelle die Beschreibung der Systemarchitektur erfolgen. Wie bereits erwähnt besteht das System aus den beiden FreeStyler-Plugins AdhocMm und AdhocStudent, die sich an den Rollen von Lehrern und Schülern orientieren. Die im Folgenden skizzierte Architektur besteht aus einem Lehrerrechner, auf dem der FreeStyler in Kombination mit dem AdhocMm-Plugin zum Einsatz kommt und einer entsprechenden Anzahl an Schülerrechnern, die den FreeStyler mit geladenem AdhocStudent-Plugin ausführen. Sollen kollaborative Sitzungen verwaltet werden, wird zusätzlich noch ein MatchMaker-Server benötigt. Alle Rechner sind über ein Netzwerk miteinander verbunden, welches die Kommunikation mit Hilfe von Multicast-Nachrichten zwischen allen Teilnehmern unterstützt. Die Anzahl der Schülerrechner wird in erster Linie durch die Skalierbarkeit des MatchMaker-Servers limitiert (vgl ). Während der gesamte Synchronisationsprozess über diesen Server

50 3. Konzept läuft, kommt zur Verwaltung der Schülerrechner JGroups zum Einsatz. Bevor die Architektur des Systems genauer betrachtet wird, ist es sinnvoll, das grundsätzliche Konzept von JGroups genauer zu betrachten. JGroups realisiert ein eigenes Gruppenkonzept auf Basis von IP-Multicast Gruppen. Die Gruppen innerhalb von JGroups werden auch als Cluster bezeichnet und besitzen einen Cluster-Namen zur Identikation. Hosts können diesen Clustern beitreten und Nachrichten an einzelne oder alle Mitglieder versenden. Dabei wird der Betrieb mehrerer Cluster innerhalb einer Multicast-Gruppe unterstützt und ein Computer kann zur gleichen Zeit in mehreren Clustern Mitglied sein kann. Technisch bedingt wird eine Cluster-Nachricht innerhalb der Multicast-Gruppe an alle Mitglieder gesendet, allerdings nur von denjenigen Hosts verarbeitet, die auch Mitglied des entsprechenden Clusters sind. Abbildung 3.4 zeigt den Versand einer Nachricht von Host A an einen Cluster. Zwar erhalten die Hosts B, C, D und E die Nachricht ebenfalls, allerdings wird diese nur von Host B und Host C verarbeitet. Der Versand von Nachrichten an mehrere Teilnehmer kommt innerhalb des Systems in verschiedenen Situationen zur Anwendung. Darüber hinaus bietet der Einsatz von JGroups-Clustern einen weiteren entscheidenden Vorteil. Die Mitglieder eines Clusters tauschen in einem regelmäÿigen Intervall Nachrichten untereinander aus und prüfen auf diese Weise, welche Hosts noch online und funktionstüchtig sind. Auf dieser Grundlage kann innerhalb der Plugins erkannt werden, ob ein Schülerrechner online oder oine ist. C l u s t e r Host A Host B Host C M u l t i c a s t G r u p p e Host D Host E Abbildung 3.4.: Versand einer Nachricht an einen Cluster Um die Verwaltung von Schülerrechnern zu ermöglichen, muss der Lehrerrechner zuerst einmal erfahren, welche Computer sich aktuell im gleichen Netzwerk benden und den FreeStyler mit AdhocStudent-Plugin gestartet haben. Zu diesem Zweck treten sowohl AdhocMm, als auch AdhocStudent zu Beginn dem Management-Cluster bei und führen einen, im nächsten Kapitel genauer beschriebenen, Service Discovery-Mechanismus durch. Hierbei werden dem AdhocMm-Plugin die notwendigen Informationen über den jeweils angemeldeten Schüler geliefert. Während der Management-Cluster bereits ausreicht, um die Einzelarbeit zu ermöglichen, kommen für das Sitzungsmanagement neben dem MatchMaker-Server noch weitere Cluster zum Einsatz. Für jede aktive Sitzung wird ein eigener Session-Cluster angelegt, dem sowohl der AdhocMm-Computer als auch die 44

51 3.5. Architektur teilnehmenden AdhocStudent-Rechner beitreten. Ein Session-Cluster wird von AdhocMm dazu verwendet, die an einer Sitzung teilnehmenden Schüler zu erkennen. Darüber hinaus nutzt das AdhocStudent-Plugin diesen zur Anzeige aller Mitglieder der aktuellen Sitzung. Aus Abbildung 3.5 kann entnommen werden, dass sich alle Hosts im Management-Cluster benden. Darüber hinaus sind zwei Sitzungen auf dem MatchMaker-Server aktiv, denen jeweils zwei Schüler angehören. Die Schülerrechner nden sich, genau wie der Lehrerrechner auch, in dem jeweiligen Sitzungs-Cluster wieder. MatchMaker Session01 Session02 FreeStyler Schüler A Schüler B Schüler C Schüler D Lehrer JGroups Session01-Cluster Management-Cluster Session02-Cluster Abbildung 3.5.: Systemarchitektur mit den Komponenten FreeStyler, MatchMaker und JGroups 45

52

53 4. Implementierung Das in Kapitel 3 beschriebene Konzept nutzt eine Aufteilung des Systems in zwei Komponenten, um den einzelnen Benutzerrollen gerecht zu werden. Während diese Aufteilung auf konzeptioneller Ebene ausreichend ist, wurde für die Implementierung des Systems eine dritte Komponente hinzugefügt. Neben den FreeStyler-Plugins AdhocMm und AdhocStudent wurde zusätzlich eine Bibliothek mit dem Namen AdhocLib entwickelt, die gemeinsam genutzten Code der Plugins beinhaltet. Dieses Kapitel gibt Auskunft über die wichtigsten Klassen und die eingesetzten Verfahren, die zur Realisierung des Konzepts entwickelt wurden. Abschnitt 4.1 beginnt mit einer Beschreibung der elementaren Kommunikationsaspekte, die durch AdhocLib bereitgestellt werden. Daran anschlieÿend werden Einzelheiten der Plugins AdhocMm (4.2) und AdhocStudent (4.3) besprochen. Am Ende des Kapitels werden die Voraussetzungen für den Einsatz des Systems festgestellt (4.4) AdhocLib Die AdhocLib Bibliothek wurde entwickelt, um eine Trennung des Netzwerk-Subsystems von den restlichen Komponenten zu erzielen und somit keine Abhängigkeiten zwischen den beiden Plugins zu schaen. Kernelemente sind hierbei eine auf JGroups aufbauende Gruppenkommunikation und eine Reihe von Nachrichtenformaten. Bei den entsprechenden Nachrichten handelt es sich um Java-Objekte, die zur Laufzeit erzeugt und von den Kommunikationspartnern während der Übertragung serialisiert bzw. deserialisiert werden Protokoll-Stack Die gesamte Kommunikation zwischen der AdhocMm- und der AdhocStudent-Komponente wird mit Hilfe von JGroups realisiert. Zu diesem Zweck treten die Komponenten nach dem Start dem Management-Cluster bei. Auf Implementierungsebene bietet JGroups ein Channel-Objekt als Schnittstelle für den Zugri auf einen Cluster an. Ein solcher Channel verwendet den im letzten Kapitel erwähnten Protokoll-Stack, um spezielle Eigenschaften der Kommunikation, wie z.b. Retransmission und Ordering, zu realisieren. Nach der Kon- guration des Protokoll-Stacks kann einem Channel durch Angabe des Cluster-Namens beigetreten werden. Daraufhin ist es über entsprechende Methoden möglich, Nachrichten an einen einzelnen Empfänger oder an alle Teilnehmer des Clusters zu übermitteln. Um Nachrichten zu empfangen oder Änderungen des Gruppenstatus zu erhalten, implementiert eine Anwendung spezielle Interfaces und registriert sich als Listener für die jeweiligen Events. 47

54 4. Implementierung Das in dieser Arbeit entwickelte System verwendet eine Reihe verschiedener Protokolle, um den in Abschnitt 3.4 beschriebenen technischen Anforderungen zu genügen. Abbildung 4.1 liefert eine Übersicht über die wichtigsten Protokolle des verwendeten Protokoll- Stacks. Die Grundlage der gesamten Nachrichtenübertragung bildet das Transportprotokoll UDP. Das PING Protokoll kommt beim Gruppenbeitritt eines Hosts zum Einsatz, um andere Mitglieder aufzunden. Ausfälle einzelner Gruppenmitglieder werden mit Hilfe des FD-ALL Protokolls erkannt. Hierbei werden in einem regelmäÿigen Intervall Heartbeat-Nachrichten per Multicast versandt und den anderen Mitgliedern auf diese Weise mitgeteilt, dass der Host noch erreichbar ist. Das NAKACK2-Protokoll führt Sequenznummern beim Versand einzelner Pakete ein. Diese stellen die Grundlage für die Nutzung von negative acknowledgements dar und ermöglichen sowohl den erneuten Nachrichtenversand bei Paketverlusten, als auch die Wiederherstellung der ursprünglichen Paketreihenfolge. Das GMS-Protokoll verwendet die darunter bendlichen Protokolle des Stacks, um die eigentlichen Group Membership-Funktionen bereitzustellen. Dies beinhaltet entsprechende Benachrichtigungen für den Fall, dass ein Mitglied die Gruppe betritt oder verlässt oder ein Host z.b. durch einen Systemabsturz nicht mehr verfügbar ist. Anwendung GMS NAKACK2 FD_ALL PING UDP P r o t o k o l l S t a c k Abbildung 4.1.: Übersicht über die wichtigsten Elemente des verwendeten Protokoll- Stacks Netzwerk-Subsystem Zur Erfüllung der bisher vorgestellten Funktionen wurden im Rahmen dieser Arbeit verschiedene Klassen für den Zugri auf die Gruppenfunktionalität implementiert. Diese Klassen wurden mit dem Ziel entworfen, den entwickelten Plugins eine komfortable Schnittstelle für die Gruppenkommunikation zu bieten und den Netzwerk-Code in einzelne Klassen zu kapseln. Zu diesem Zweck wurden für die Kommunikation mehrere Abstraktionsgrade identiziert und durch entsprechende Schichten innerhalb des Netzwerk- Subsystems abgebildet. Die unterste Ebene wird als hostspezische Schicht bezeichnet. Ihre zentrale Klasse lautet AdhocGroup. Hierbei handelt es sich um eine Fassade, die JGroups-eigene Details bezüglich der Gruppenverwaltung verdeckt und eine eigene Schnittstelle für den Zugri auf eine Gruppe bereitstellt. Der Zugri auf das eigentliche Channel-Objekt wird hierbei vor dem Aufrufer verborgen. Dies ist speziell unter dem Gesichtspunkt sinnvoll, dass JGroups eine - für die hier vorliegenden Bedürfnisse - unpassende Repräsentation für Statusänderungen verwendet. JGroups nutzt spezielle Objekte, die als Views bezeichnet werden und Auskunft darüber liefern, welche Hosts sich zu einem bestimmten Zeitpunkt in der 48

55 4.1. AdhocLib Gruppe benden. Ändert sich der Gruppenstatus, indem ein Mitglied eine Gruppe betritt oder verlässt, wird der neue Status durch ein weiteres View-Objekt repräsentiert. Adhoc- Group übernimmt hierbei die Aufgabe, die neue View mit der vorherigen zu vergleichen und daraufhin Events für jeden Host zu erzeugen, der die Gruppe betreten oder verlassen hat. Darüber hinaus werden Methoden für den synchronen und asynchronen Versand von Unicast-Nachrichten, sowie den asynchronen Versand von Multicast-Nachrichten bereitgestellt. Ein Host wird innerhalb dieser Schicht durch die Klasse AdhocHost repräsentiert und verwendet zur Adressierung der Mitglieder einen von JGroups bereitgestellten eindeutigen Identier. Eine solche ID wird von einem Host bei jedem Beitritt einer Gruppe neu berechnet. Hieraus ergibt sich, dass ein Host nach einem erneuten Gruppenbeitritt eine andere ID erhält. Die zweite Ebene wird als benutzerspezische Schicht bezeichnet, deren wichtigste Klasse durch AdhocExtendedGroup dargestellt wird. Diese Klasse greift über eine entsprechende Schnittstelle auf die darunterliegende Schicht zu und bietet ihrerseits eine Schnittstelle für die darüber liegende Schicht an. AdhocExtendedGroup verwendet auf der einen Seite die Events von AdhocGroup, um darüber Buch zu führen, welche Benutzer aktuell in der Gruppe angemeldet sind. Ein Benutzer wird auf dieser Ebene durch die Klasse AdhocMember repräsentiert. Zur Identikation wird ein spezieller User-Identier verwendet, der innerhalb des Netzwerks eindeutig ist. Diese benutzerspezische Adressierung führt dazu, dass der Nachrichtenversand an einen bestimmten Benutzer transparent von dem jeweiligen Computer erfolgt. Auf diese Weise kann sich ein Schüler bei technischen Problemen ohne Weiteres an einer anderen Arbeitsstation anmelden. Die Anwendung bekommt lediglich Informationen darüber, dass sich der Benutzer ab und kurze Zeit später wieder anmeldet. Dies bietet den Vorteil, dass sich das Programm nicht damit auseinandersetzen muss, wie der Benutzer nach dem erneuten Beitritt zu adressieren ist. Auf der anderen Seite ndet auf dieser Ebene das Service Discovery statt, bei dem sich jede neue AdhocStudent-Instanz nach dem Start beim AdhocMm-Rechner anmeldet und für den Betrieb notwendige Informationen austauscht. Da die AdhocExtendedGroup von beiden Plugins verwendet wird, wurden innerhalb dieser Klasse zwei unterschiedliche Verfahrensweisen realisiert. Das jeweilige Verhalten wird während der Instanziierung durch ein spezielles Flag festgelegt. Das AdhocStudent-Plugin tritt einer Gruppe als normaler Host bei, der die Dienste des Lehrerrechners in Anspruch nimmt und infolgedessen als Client bezeichnet werden soll. AdhocMm verwaltet die Clients innerhalb einer Gruppe und nimmt dementsprechend die Rolle des GroupManagers ein. Die jeweilige Rolle hat Einuss auf die Aktionen, die ein Host innerhalb des Kommunikationsprozesses ausführt. Diese Rollen werden während der Beschreibung des Service Discovery Prozesses und dem Beitritt eines Clients in eine Sitzung erneut aufgegrien. Die beiden Plugins stellen unterschiedliche Anforderungen an den Kommunikationsprozess. Aus diesem Grund bietet die dritte Schicht plugin-spezische Schnittstellen für die entwickelten Komponenten an. Diese Schnittstellen werden durch zwei verschiedene Klassen implementiert, die für die Gruppenverwaltung zuständig sind. Für das AdhocStudent- Plugin kommt die Klasse AdhocGroupClient zum Einsatz, welche die initiale Verbindung zum Management-Cluster herstellt und darüber hinaus den Beitritt in einen Session- Cluster ermöglicht. Diese Klasse stellt eine passende Schnittstelle für die Steuerungsfunktionen des AdhocStudent-Plugins bereit und ermöglicht somit z.b. die Übermittlung der aktuellen Arbeitsmappe oder eines Screenshots an den Lehrerrechner. Den Gegenpart für das AdhocMm-Plugin übernimmt die Klasse AdhocGroupManager, die Methoden für 49

56 4. Implementierung den Beitritt in den Management-Cluster und beliebig viele Session-Cluster anbietet. Auf dieser Seite werden entsprechende Methoden angeboten, mit denen Arbeitsmappen komfortabel verteilt und eingesammelt oder ein Screenshot angefordert werden kann. Das UML-Klassendiagramm in Abbildung 4.2 liefert eine Übersicht über die beschriebenen Ebenen und ihre jeweiligen Klassen, wobei diese Darstellung auf die wichtigsten Aspekte reduziert wurde. Host-Ebene Benutzer-Ebene Plugin-Ebene +connect() : void +joinsessiongroup(eing. groupid : string) : Future<Boolean> +leavesessiongroup(eing. groupid : string) : void +publishsessionconfig() : void +requestscreenshot(eing. userid : string) : void +collectworkspaces() : void 1..* -groupid : String AdhocGroupManager 1 AdhocExtendedGroup +getmembers() : List<AdhocMember> +joingroup() : void +leavegroup() : void +sendunicast(eing. userid : string, eing. msg : IMessage) : void +sendunicast(eing. userid : string, eing. msg : IMessage) : IMessage +sendunicasttogroupmanager(eing. msg : IMessage) : void +sendmulticast(eing. msg : IMessage) : void * AdhocGroup «interface» -channel : org.jgroups.channel IMessage +getidentifier() : org.jgroups.channel UUID String +gethost(eing. id : string) : AdhocHost +gethosts() : List<AdhocHost> +join() : void +leave() : void +sendunicast(eing. dest : AdhocHost, eing. msg : IMessage) : IMessage +sendunicastasync(eing. dest : AdhocHost, eing. msg : IMessage) : void +sendmulticastasync(eing. msg : IMessage) : void Workspace AdhocGroupClient +connect() : void +joinsessiongroup(eing. groupid : string) : Boolean +leavesessiongroup() : void +sendscreenshot(eing. data : byte[]) : void +sendworkspace(eing. ws : Workspace) : void 1 1..* AdhocMember +gethost(eing. userid : string) : AdhocHost +gethostname() : String +getuseridentifier() : String 1 1..* 1 AdhocHost +getuuid() : UUID +getipaddress() : String Abbildung 4.2.: Schichtenarchitektur des Netzwerk-Subsystems als UML- Klassendiagramm Um die Netzwerklast zu reduzieren, greift der AdhocGroupManager auf verschiedene Arten der Nachrichtenübermittlung zurück. Hierbei kommt, je nach Art der zu übertragenden Nachricht, entweder Unicast oder Multicast für den Versand zum Einsatz. Darüber hinaus erweitert der Plugin-spezische Layer den Versand von Multicast-Nachrichten um die Möglichkeit, mehrere Empfänger zu adressieren. Zwar wird eine Multicast-Nachricht von allen Gruppenmitgliedern empfangen, allerdings nur von den Adressaten verarbeitet. Um dieses Verfahren zu veranschaulichen, sollen nachfolgend einige Nachrichtentypen und deren Versand näher erläutert werden. ServiceAnnouncement Der GroupManager verwendet zu Beginn des Service Discovery- Prozesses ein ServiceAnnouncement, um die Mitglieder einer Gruppe darüber zu informieren, dass eine AdhocMm-Instanz verfügbar ist. Diese Nachricht wird per Multicast an alle Rechner des Management-Clusters gesendet. Das Service Discovery wird im nächsten 50

57 4.1. AdhocLib Abschnitt genauer erläutert. ScreenshotRequest Fordert der Lehrer über das AdhocMm-Plugin einen Screenshot von einem Rechner an, so wird ein ScreenshotRequest per Unicast an den entsprechenden Rechner übermittelt. Die Antwort in Form einer ScreenshotResponse-Nachricht wird von AdhocStudent ebenfalls per Unicast übertragen. DistributeWorkspace Die DistributeWorkspace-Nachricht ist ein Beispiel für eine Nachricht, die sowohl an einen, als auch an mehrere Rechner übermittelt werden kann. Die Art der Übertragung ist davon abhängig, wie vielen Schülern der Lehrer eine Arbeitsmappe austeilen möchte und wie viele Schüler diese Arbeitsmappe bereits bekommen haben. Die User-Identier der Empfänger werden in der Nachricht kodiert und sobald mindestens zwei Schüler das Dokument bekommen sollen, wird dieses per Multicast übertragen Service Discovery Damit der Lehrerrechner in der Lage ist, die entsprechenden Rechner der Schüler zu verwalten, müssen sich die jeweiligen Komponenten kennen und über die Rolle des jeweils anderen informiert sein. Dieser Prozess wird als Service Discovery bezeichnet und zu Beginn der Kommunikation von jeder Komponente durchgeführt. Die gemeinsame Grundlage für die Kommunikation wird hierbei durch den Management-Cluster gebildet, dem AdhocMm- und AdhocStudent-Plugin nach dem Ladevorgang beitreten. Wie im vorigen Abschnitt bereits erläutert, nehmen diese Komponenten innerhalb des Kommunikationsprozesses die Rolle des GroupManagers respektive GroupClients ein. Für den Gruppenbeitritt eines Hosts können vier verschiedene Fälle unterschieden werden, die sich aus der entsprechenden Rolle und dem Status der Gruppe ergeben. Unter dem Gruppenstatus ist hierbei zu verstehen, ob vorher bereits ein Host beigetreten ist und die jeweilige andere Rolle eingenommen hat. Tabelle 4.1 zeigt die vier Möglichkeiten auf. Hierbei wird ein Host, der zu spät kommt, als Late-Comer bezeichnet. Rolle Late-Comer Kommentar GroupManager Nein Bisher kein Client in der Gruppe GroupManager Ja Client bereits in der Gruppe Client Nein Bisher kein GroupManager in Gruppe Client Ja GroupManager bereits in der Gruppe Tabelle 4.1.: Die vier Fälle für den Beitritt eines Hosts in eine Gruppe Während diese vier Fälle in der Implementierung des Systems einzeln betrachtet wurden, resultieren für das entwickelte Protokoll die beiden nachfolgend beschriebenen Situationen, die je zwei Fälle zusammenführen. Hierbei stellt entweder der GroupManager oder ein GroupClient den Late-Comer dar. Tritt der GroupManager einer Gruppe bei, sendet er zuerst eine ServiceAnnouncement- Nachricht per Multicast, um sich bereits vorhandenen AdhocStudent-Rechnern bekannt zu machen. Diese Nachricht signalisiert den anderen Teilnehmern, dass der Host als 51

58 4. Implementierung GroupManager für diese Gruppe gestartet wurde und den Teilnehmern seine Dienste anbietet. Empfängt ein Client ein solches ServiceAnnouncement, antwortet er mit einem entsprechenden ClientAnnouncement, welches per Unicast direkt an den GroupManager gesendet wird, um nicht unnötig Netzwerklast zu produzieren. Ein solches ClientAnnouncement enthält Informationen über den Hostnamen und den User-Identier. Für den Identier wird die Methode getusername der Klasse info.collide.user.user verwendet und bieten somit den Vorteil, dass ein eventuell verwendeter FreeStyler-Authentizierungsmechanismus direkt unterstützt wird. Der GroupManager empfängt die Nachricht und prüft daraufhin, ob er bereits ein anderes ClientAnnouncement mit dem gleichen User-Identier erhalten hat. Ist dies der Fall, generiert er durch Anfügen einer entsprechenden Nummer eine neue ID und sorgt auf diese Weise für deren Eindeutigkeit. Der GroupManager speichert den User-Identier intern ab und versendet im Anschluss eine ClientEstablishment-Nachricht mit diesem Identier. Die Nachricht wird hierbei an alle Gruppenteilnehmer versendet, damit auf der einen Seite der jeweilige Host über seinen - eventuell geänderten - User-Identier Bescheid bekommt und auf der anderen Seite alle weiteren Hosts Informationen über das neue Mitglied erhalten. ManagementCluster AdhocStudent:1 AdhocMm System: Gruppe beitreten System: Gruppe beitreten ClientAnnouncement AdhocStudent:2 ServiceAnnouncement ServiceAnnouncement ClientAnnouncement User ID registrieren ClientEstablishment ClientEstablishment System: Gruppe beitreten ClientAnnouncement ClientAnnouncement User ID registrieren ClientEstablishment ClientEstablishment ClientEstablishment JGroups Unicast Multicast Abbildung 4.3.: Service Discovery als UML-Sequenzdiagramm In der zweiten Situation stellt der Client den Late-Comer dar. Beim Beitritt in den Management-Cluster besitzt er keine Informationen über die einzelnen Mitglieder. Aus diesem Grund sendet er ein ClientAnnouncement mit seinen Informationen als Multicast an die Gruppe. Sobald der GroupManager diese Nachricht empfängt, reagiert er - wie bereits zuvor auch - mit einem ClientEstablishment und teilt somit allen Gruppenteil- 52

59 nehmern die Daten des neuen Mitglieds mit AdhocMm Der gesamte Service Discovery Prozess ist in Abbildung 4.3 als UML-Sequenzdiagramm dargestellt. Zur besseren Übersicht, welche Nachrichten per Multicast an die Gruppe gesendet werden, wurde neben der farblichen Visualisierung eine eigene Lebenslinie für den Management-Cluster verwendet. Im oberen Teil dieses Diagramms ist die Situation skizziert, dass der GroupManager nach einem GroupClient dem Management-Cluster beitritt, während der untere Teil die Situation abdeckt, in der eine weitere AdhocStudent- Instanz den Late-Comer darstellt. Wie aus dem Sequenzdiagramm entnommen werden kann, werden alle Aufrufe asynchron ausgeführt AdhocMm Während die meisten Funktionen des AdhocMm-Plugins bereits in Kapitel 3 erläutert wurden, soll an dieser Stelle auf die Details der Umsetzung eingegangen werden. Das Klassendiagramm in Abbildung 4.4 bietet einen Überblick über die wichtigsten Klassen von AdhocMm und die Beziehungen zwischen diesen Klassen. Auch dieses Klassendiagramm konzentriert sich auf die wichtigsten Aspekte und Methoden. Für das Verständnis der Programmstruktur ist besonders die Klasse AdhocController hervorzuheben. Diese Klasse bietet der Palette, sowie den einzelnen Knoten eine Schnittstelle für AdhocMmspezische Funktionen, wie die Erzeugung eines Screenshots oder die Verteilung der Arbeitsmappen an. Damit all diese Elemente unkompliziert auf die bereitgestellten Funktionen zugreifen können, wurde der AdhocController als Singleton realisiert. Je nach aufgerufener Funktion sorgt der Controller selbst für die Durchführung der Aufgabe oder delegiert die Aufgabe an spezielle Worker-Klassen. So ist die Anforderung eines Screenshots beispielsweise eine Aufgabe, für die lediglich eine ScreenshotRequest-Nachricht an einen einzelnen AdhocStudent-Rechner versendet werden muss. In diesem Fall ruft der Controller selbst die Funktion des AdhocGroupManagers auf. Darüber hinaus existieren komplexere Aufgaben, deren Umsetzung in eigene Klassen gekapselt wurde und in den nachfolgenden Abschnitten erläutert werden. Neben dem direkten Aufruf einzelner Funktionen erhält der AdhocController Benachrichtigungen, wenn Allow- oder ForceEdges hinzugefügt oder gelöscht werden. Die Klasse GraphController hat unter anderem die Aufgabe, Veränderungen des Graphs zu überwachen und entsprechende Events zu erzeugen. In Abhängigkeit davon, ob der Kollaborationsmodus aktiviert ist, übermittelt der AdhocController die neue Gruppenkonstellation an die Schülerrechner Austeilen und Einsammeln von Arbeitsmappen Die Klasse WorkspaceDistributor ist für die Verteilung der Arbeitsmappen zuständig. Zu diesem Zweck existiert die Methode distribute, welche alle Empfänger ermittelt und daraufhin die zu übertragende Datei von der Festplatte lädt. Als Empfänger berücksichtigt die Methode sowohl UserNodes, die direkt mit dem MaterialNode verbunden sind, als auch UserNodes, die mit einem SessionNode verbunden und Mitglied dieser Sitzung sind. Da mehrere Schüler Mitglied der Sitzung seien können, wird einer der UserNodes zufällig ausgewählt. Die resultierende DistributeWorkspace-Nachricht wird mit Hilfe des AdhocGroupManagers an die Schülerrechner versendet. Empfängt eine AdhocStudent- Instanz die Nachricht, fügt sie die Seiten des entsprechenden Dokuments an die aktuelle 53

60 4. Implementierung Arbeitsmappe respektive Sitzung an. Daraufhin übernimmt der Synchronisationsserver die Aufgabe, die neuen Seiten an die anderen Sitzungsteilnehmer zu übertragen. Zusätzlich speichert der Distributor die Information, welche Schüler und Sitzungen die Arbeitsmappe erhalten haben. Diese Information wird verwendet, um eine Arbeitsmappe nicht mehrfach an den gleichen Schüler bzw. die gleiche Sitzung auszuteilen. «interface» info.collide.graph.event.graphlistener «interface» AdhocGraphListener GraphController +addadhocgraphlistener(eing. listener : AdhocGraphListener) : void AdhocController +getinstance() : AdhocController +startsessions(eing. host : String, eing. port : int) : void +collectworkspaces(eing. mns ClientAnnouncement WorkspaceMessage : List<MaterialNode>) : void +distributeworkspace(eing. ForceEdgeAdhocGraphListener ExtendedCouplingClient mn : List<MaterialNode>) AllowEdge : void +requestscreenshot(eing. userid : String) : void +allowedgeadded(eing. allowedge : AllowEdge) : void +allowedgeremoved(eing. allowedge : AllowEdge) : void +forceedgeadded(eing. forceedge : ForceEdge) : void +forceedgeremoved(eing. forceedge : ForceEdge) : void «uses» 1 1 SessionRecreator SessionManager «uses» +handleclientannouncement(eing. ca : ClientAnnouncement) : void «uses» AdhocGroupManager «uses» «uses» 1 WorkspaceDistributor +distribute(eing. mn : MaterialNode) : void 1 WorkspaceCollector +collect(eing. materialnodes : List<MaterialNode>) : void +collected(eing. userid : String, eing. workspace : WorkspaceMessage) : void Abbildung 4.4.: Programmstruktur des AdhocMm-Plugins als UML-Klassendiagramm Sollen Arbeitsmappen von den Schülern eingesammelt werden, zeichnet sich hierfür die Klasse WorkspaceCollector verantwortlich, welche über die Methode collect verfügt. Nach dem Aufruf wird aus den verbundenen User- und SessionNodes eine Liste der Empfänger erstellt. Um die Arbeitsmappe einer Sitzung einzusammeln, wird wiederum nur ein einziger UserNode bemüht, dessen User-Identier gespeichert wird. Die Liste der Empfänger wird der entsprechenden AdhocGroupManager Methode übergeben, welche eine CollectWorkspace-Nachricht an die Schülerrechner versendet. Da der AdhocController innerhalb des AdhocMm-Plugins für den Empfang der Nachrichten zuständig ist, leitet er jede eingehende Arbeitsmappe mit Hilfe der collected Methode an den WorkspaceCollector weiter. Diese Methode speichert das Dokument auf der Festplatte und erzeugt einen Vermerk, dass diese erhalten wurde. Da es generell möglich ist, dass ein Schülerrechner während der Übertragung die Verbindung verliert oder ausgeschaltet wird, startet der WorkspaceCollector nach dem Versand der CollectWorkspace-Nachricht einen Timer. 54

61 4.2. AdhocMm Nach Ablauf einer entsprechenden Zeitspanne wird geprüft, ob die Arbeitsmappen aller Sitzungen empfangen wurden. Falls Arbeitsmappen fehlen, fordert der Collector - unter Berücksichtigung der bereits verwendeten Empfänger - ein anderes Mitglied der Sitzung dazu auf, die Arbeitsmappe zu übertragen und startet einen neuen Timer Sitzungsverwaltung und Betriebsmodi Die eigentliche Verwaltung der Sitzungen ndet innerhalb der Klasse SessionManager des AdhocMm-Plugins statt. Hierbei fallen verschiedene Aufgaben in die Zuständigkeit des SessionManagers. Zuerst einmal muss er den AdhocStudent-Instanzen mitzuteilen, welchen Sitzungen sie beitreten können bzw. sollen. Daraufhin nimmt er aktiv am Beitrittsprozess teil, indem er einem AdhocStudent-Rechner mitteilt, ob eine Sitzung bereits besteht oder erst erstellt werden muss. Wird die AdhocMm-Arbeitsmappe geändert, sendet der SessionManager eine Nachricht mit der aktualisierten Sitzungskonguration an die Schülerrechner und weist sie auf diese Weise beispielsweise an, die aktuelle Sitzung zu verlassen. Während die bisherige Kommunikation ausschlieÿlich über JGroups erfolgt ist, kommt für den SessionManager ein weiterer Kommunikationskanal hinzu. Hierbei handelt es sich um eine Verbindung zum Synchronisationsserver, für die der CouplingController zum Einsatz kommt. Diese Verbindung ist notwendig, da der SessionManager Kenntnis darüber benötigt, welche Sitzungen bereits erstellt wurden. Zusätzlich verfügt der SessionManager über eine Referenz auf den AdhocGroupManager, um mit den AdhocStudent-Rechnern zu kommunizieren. Dieser Aufbau kann in Abbildung 4.5 nachvollzogen werden. SessionManager +startsessionmanagement(eing. credentials : ServerCredentials) : void +stopsessionmanagement() UserNode ServerCredentials : void +issessionstarted() : Boolean ExtendedCouplingClient +getsessionswithoutsessionnode() : List<String> +updateuserssessionconfigasync(eing. un : UserNode) : void «uses» * CouplingController -couplingclient : ExtendedCouplingClient +getsessions() : List<String> AdhocGroupManager «uses» SessionWorker +addusertoqueue(eing. userid : string) : void +start() : void Abbildung 4.5.: Komponenten der Sitzungsverwaltung als UML-Klassendiagramm In Abschnitt wurde bereits auf die Unterschiede zwischen Planungs-/Einzelarbeitsmodus und Kollaborationsmodus eingegangen. Dabei wurde festgestellt, dass Änderungen der Sitzungskonguration nur bei aktiviertem Kollaborationsmodus auf die Schülerrechner angewendet werden. Auf Code-Ebene ist die Unterscheidung zwischen diesen beiden Modi durch ein boolesches Flag des SessionManagers realisiert und wird über die Methode issessionstarted abgerufen. Nach dem Start bendet sich das AdhocMm-Plugin im Planungs-/Einzelarbeitsmodus und die Methode liefert dementsprechend false. Das Management kollaborativer Sitzungen wird mit Hilfe der Methode startsession aktiviert, woraufhin der SessionManager eine neue Instanz des CouplingControllers erzeugt und eine Verbindung zum Synchronisationsserver aufbaut. Im nächsten Schritt wird die 55

62 4. Implementierung aktuelle Sitzungskonguration aus der Arbeitsmappe ausgelesen, wobei die UserNodes, SessionNodes und die entsprechenden Verbindungen Beachtung nden. Für jeden Session- Node wird geprüft, ob die entsprechende Sitzung bereits angelegt wurde. Hierzu werden die aktuell verfügbaren Sitzungen des Synchronisationsservers durch die getsessions Methode des CouplingControllers abgerufen und zwischengespeichert. Wie in Abschnitt bereits erwähnt wurde, wird eine eindeutige Bezeichnung für die Identikation der Sitzungen benötigt. Eine solche ID wird im weiteren Verlauf als Group-Identier bezeichnet und kommt sowohl als Sitzungsname auf dem Synchronisationsserver, als auch zur Identikation des Sitzungs-Clusters zum Einsatz. Die Eindeutigkeit muss gewährleistet sein, um Kollisionen der Sitzungsnamen zu vermeiden. Würde der Identier stattdessen deterministisch vergeben werden, wären Situationen denkbar, in denen SessionNodes in verschiedenen AdhocMm-Arbeitsmappen auf die gleiche Sitzung verweisen und Schüler bei der Verwendung dieser Arbeitsmappen unbeabsichtigt einer bestehenden Sitzung beitreten. Ist für einen SessionNode noch keine Sitzung vorhanden, wird ein neuer Group-Identier in Form einer UUID generiert. Nachdem alle Sitzungen über einen eigenen Group-Identier verfügen, weist der SessionManager den AdhocGroupManager an, den einzelnen Sitzungs-Clustern beizutreten. Ab diesem Zeitpunkt kann das AdhocMm- Plugin anderen Hosts den Beitritt in eine Sitzung weisen. Da die AdhocStudent-Instanzen allerdings über keine (aktuelle) Sitzungskonguration verfügen, wird im nächsten Schritt eine Nachricht vom Typ SessionConfig erzeugt. Diese Nachricht beinhaltet die Adresse und Portnummer des Synchronisationsservers, sowie ein Modell der Sitzungskonguration. Das Modell enthält für jeden Schüler Informationen über die für ihn verfügbaren Sitzungen. Auÿerdem ist in dem Modell vermerkt, ob der Beitritt in diese Sitzungen verpichtend ist (vgl. ForceEdge in Abschnitt 3.3.2). Die SessionConfig wird daraufhin an die entsprechenden AdhocStudent-Rechner übermittelt, wobei der AdhocGroupManager, wie in Abschnitt beschrieben, auf Basis der Empfängerzahl über die Übertragungsform entscheidet. Abbildung 4.6 stellt den Prozess des Sitzungsstarts in Form eines UML-Sequenzdiagramms dar. Nachdem ein Schülerrechner eine SessionConfig-Nachricht mit einer Liste von Sitzungen erhalten hat, kann er einer Sitzung beitreten. Zu diesem Zweck tritt das AdhocStudent- Plugin dem jeweiligen Sitzungs-Cluster bei, dessen Name sich durch den Group-Identier ergibt. Wie im letzten Absatz erläutert wurde, ist der SessionManager zu diesem Zeitpunkt bereits dem Cluster beigetreten. Da einem Host beim Beitritt in einen Cluster allerdings von JGroups ein neuer Host-Identier zugewiesen wurde (vgl. Abschnitt 4.1.2), müssen die beiden Rechner den Service Discovery-Mechanismus erneut durchführen. Erst nach diesem Prozess kennt der GroupManager den User-Identier. Sobald der Schülerrechner identiziert ist, ndet der eigentliche Sitzungsbeitritt statt. Zu diesem Zweck verwendet der SessionManager für jede Sitzung einen eigenen SessionWorker. Diese Klasse wurde entwickelt, um die Sitzungserzeugung und den gleichzeitigen Beitritt mehrerer Rechner zu koordinieren. Um den Prozess der Sitzungserzeugung zu synchronisieren, verwaltet der SessionWorker die neuen Mitglieder in einer Queue. Aus dieser Queue wird jeweils der nächste User-Identier entnommen und der entsprechenden AdhocStudent- Instanz eine JoinSession-Nachricht gesendet. Diese Nachricht enthält eine Information, ob die Sitzung bereits erzeugt wurde. Der SessionWorker wartet daraufhin, bis der Schülerrechner die Sitzung entweder erstellt oder betreten hat und mit einer SessionJoined- Nachricht antwortet. Bleibt eine solche Antwort aus, delegiert der SessionWorker die Aufgabe an den nächsten Host in der Queue. Dieser Prozess des Sitzungsbeitritts ist in Form eines UML-Sequenzdiagramms in Abbildung 4.7 dargestellt. 56

63 4.2. AdhocMm AdhocMm MM-Server AdhocStudent Kollaborationsmodus aktiviert getsessions() Liste aller Sitzungen generiere GroupID Session-Cluster System: Gruppe beitreten SessionConfig JGroups Unicast MatchMaker Abbildung 4.6.: Sitzungsstart als UML-Sequenzdiagramm AdhocMm Session-Cluster AdhocStudent MM-Server System: Gruppe beitreten System: Gruppe beitreten Service Discovery Service Discovery JoinSession joinsession() SessionJoined JGroups Unicast MatchMaker Service Discovery Abbildung 4.7.: Sitzungsbeitritt als UML-Sequenzdiagramm 57

64 4. Implementierung Neben dem Sitzungsbeitritt muss das AdhocMm-Plugin die AdhocStudent-Instanzen zusätzlich über Änderungen der aktuellen Sitzungskonguration informieren. Um über Veränderungen des Graphen informiert zu werden, registriert sich der AdhocController beim GraphController auf entsprechende Events. Hierbei werden vier Events berücksichtigt und zwar für das Hinzufügen oder Löschen einer Allow- bzw. ForceEdge. Wird stattdessen ein Knoten gelöscht, werden zuvor alle mit diesem Knoten verbundenen Kanten entfernt und entsprechende Events erzeugt. Demzufolge reicht die Berücksichtigung der Kanten-Ereignisse aus. Bendet sich das AdhocMm-Plugin im Kollaborationsmodus und erhält ein solches Event, ruft der AdhocController die updateuserssessionconfigasync- Methode des SessionManagers auf. Daraufhin erzeugt der SessionManager, wie beim Sitzungsbeitritt auch, auf Basis der aktuellen Arbeitsmappe eine SessionCong-Nachricht und übermittelt diese an den jeweiligen AdhocStudent-Rechner. Ist der Kollaborationsmodus bereits aktiviert und die Sitzungskonguration soll bearbeitet werden, ohne dass Änderungen direkt auf die Schülerrechner angewendet werden, kann erneut in den Planungs-/Einzelarbeitsmodus gewechselt werden. Zu diesem Zweck ruft der AdhocController die stopsessionmanagement-methode des SessionManagers auf und stoppt somit die Sitzungsverwaltung. Dies hat lediglich zur Folge, dass Änderungen der Sitzungskonguration nicht mehr übermittelt werden. Da das AdhocMm-Plugin die Sitzungs-Cluster nicht verlässt, bleibt die Funktionstüchtigkeit der bestehenden Konguration erhalten und die Schüler können nach wie vor zwischen den erlaubten Sitzungen wechseln Verwendung bestehender Sitzungen In manchen Situationen kann der Bedarf bestehen, eine bereits existierende Sitzung des MatchMaker-Servers zu verwenden. Dies ist z.b. dann der Fall, wenn in einer vorherigen Unterrichtsstunde bereits Sitzungen erstellt wurden, die immer noch auf dem Synchronisationsserver vorhanden sind oder mit Hilfe des MatchMaker Persistenz-Mechanismus wiederhergestellt wurden. Da in einer AdhocMm-Arbeitsmappe nicht zwangsläug entsprechende SessionNodes vorhanden sind, können neue SessionNodes in den Arbeitsbereich gezogen und den vorhandenen Sitzungen zugeordnet werden. Zur Auswahl einer Sitzung verfügt ein SessionNode über eine Schaltäche, mit der eine Instanz vom Typ SessionChooserDialog erzeugt und angezeigt wird. Der Dialog verwendet die Methode getsessionswithoutsessionnode des SessionManagers, um eine Liste der Sitzungen zu erhalten, zu denen noch kein SessionNode vorhanden ist. Hierbei verwendet der Session- Manager den CouplingController zum Abruf der verfügbaren Sitzungen vom Synchronisationsserver und durchsucht daraufhin den FreeStyler-Arbeitsbereich nach entsprechenden SessionNodes. Abbildung 4.8 zeigt einen Screenshot des SessionChooserDialogs mit zwei verfügbaren Sitzungen. Die Sitzungsnamen sind entsprechende UUIDs, wie in Abschnitt beschrieben. Da eine FreeStyler-Sitzung zum gegenwärtigen Zeitpunkt nicht über Metadaten verfügt, kann die vom Lehrer eingegebene Beschreibung der Sitzung (vgl. Abschnitt 3.3.2) nicht wiederhergestellt werden. Abschlieÿend sei erwähnt, dass das AdhocMm-Plugin über eine Verbindung zum Kopplungsserver verfügen muss, um die aktuellen Sitzungen abrufen zu können. Aus diesem Grund ist diese Funktion nur im Kollaborationsmodus verfügbar. 58

65 4.2. AdhocMm Abbildung 4.8.: Dialog zur Auswahl einer bestehenden Sitzung Wiederherstellung einer laufenden Sitzungskonguration Da auf heutigen Systemen eine Vielzahl verschiedener Programme zur Anwendung kommen, besteht immer die Gefahr, dass das Betriebssystem oder ein Programm abstürzt. Muss der Computer in einem solchen Fall neu gestartet werden, kann die aktuelle Arbeitsmappe nicht in allen Fällen vorher gespeichert werden. Aus diesem Grund bietet das AdhocMm-Plugin die Möglichkeit, das Modell einer laufenden Sitzungskonguration wiederherzustellen. Wie bereits erläutert, sendet das AdhocMm-Plugin nach dem Ladevorgang ein ServiceAnnouncement an den Management-Cluster. Verfügt ein Schülerrechner zu diesem Zeitpunkt über eine Sitzungskonguration, kann das AdhocStudent-Plugin diese Konguration dem anschlieÿenden ClientAnnouncement anfügen. Sobald eine solche Nachricht vom AdhocController des AdhocMm-Plugins empfangen wird, ruft dieser die handleclientannouncement-methode des SessionRecreator auf. Der SessionRecreator blendet einen modalen Fragedialog ein und erwartet eine Entscheidung des Benutzers, ob die aktuell laufende Sitzungskonguration wiederhergestellt werden soll. Währenddessen eingehende Sitzungskongurationen werden vom SessionRecreator zwischengespeichert. Wird die Rekonguration aktiviert, werden im Arbeitsbereich auf Basis der eingegangenen Sitzungsinformationen SessionNodes und UserNodes erzeugt und in zwei Reihen angeordnet. Die Knoten werden unter Verwendung der erhaltenen Informationen mit entsprechenden Allow- und ForceEdges verbunden. Abschlieÿend aktualisiert der SessionRecreator die Adresse und den Port des Synchronisationsservers in der Palette und aktiviert den Kollaborationsmodus Palette und allgemeine Handhabung Die Palette des AdhocMm-Plugins ermöglicht nicht nur den Zugri auf die Elemente der visuellen Sprache, sondern stellt dem Lehrer auch Statusinformationen und Kongurationsmöglichkeiten bereit. Dabei ist die Palette in zwei Bereiche eingeteilt. Im oberen Bereich benden sich vier verschiedene Reiter, die sich - sofern möglich - an den verschiedenen Arbeitsphasen und den entsprechenden Aufgaben orientieren. Hierbei wird allgemein zwischen den Phasen Unterrichtsvorbereitung und Unterricht unterschieden. 59

66 4. Implementierung Diese Aufteilung wurde gewählt, um während der Arbeit mit dem Plugin möglichst wenig zwischen den verschiedenen Tabs wechseln zu müssen. Der untere Bereich der Palette enthält mehrere Schaltächen, um die in Abschnitt vorgestellten Kanten zu zeichnen oder zu löschen. Da diese Aktionen sowohl während der Planungsphase, als auch im Unterricht Verwendung nden, sind die Schaltächen vom geöneten Tab unabhängig. Für die Vorbereitung des Unterrichts bietet der in Abbildung 4.9a dargestellte Reiter Vorbereitung Zugri auf die wichtigsten Elemente dieser Phase. Hierbei handelt es sich um SessionNodes, PlaceNodes und MaterialNodes. Während des Unterrichts zeichnet der Reiter Unterricht für die Verwaltung der Schülerrechner verantwortlich. Sobald ein Schüler das AdhocStudent-Plugin lädt und der Service Discovery Prozess abgeschlossen ist, erzeugt AdhocMm einen entsprechenden UserNode, der entweder in diesem Tab angezeigt wird oder einen PlaceNode in der Arbeitsmappe ersetzt. Der Lehrer kann somit einen Überblick über die angemeldeten Schüler gewinnen. Zusätzlich bietet die Palette die Möglichkeit, die einzelnen UserNodes direkt in den Arbeitsbereich zu ziehen und somit zu verwalten. UserNodes, die aus der Arbeitsmappe gelöscht werden, werden automatisch wieder dem Reiter Unterricht hinzugefügt. Darüber hinaus ndet sich in diesem Tab die Möglichkeit, zwischen Planungs-/Einzelarbeitsmodus und Kollaborationsmodus zu wechseln. (a) Vorbereitung (b) Unterricht Abbildung 4.9.: Aufgabenorientierte Reiter der AdhocMm-Palette Die beiden vorgestellten Reiter beherbergen alle Knoten der visuellen Sprache, welche in gewohnter Manier in den Arbeitsbereich gezogen werden können. Um den, in Abschnitt 60

67 4.2. AdhocMm 3.2 beschriebenen, nicht-funktionalen Anforderungen einer komfortabel nutzbaren und performanten Handhabung des Systems gerecht zu werden, wurde für das AdhocMm- Plugin eine eigene Drag and Drop-Funktionalität entwickelt. Wenn Knoten über den Drag and Drop-Mechanismus des FreeStylers in den Arbeitsbereich gezogen werden, prüft die Klasse GraphController, ob sich an dieser Stelle ein weiterer Knoten bendet. Ist dies der Fall, so wird in Abhängigkeit von dem darunterliegenden Knoten automatisch eine Kante gezogen und der Knoten neu ausgerichtet. Tabelle 4.2 zeigt für je zwei Knoten die erzeugte Kante an. Für die Repositionierung der Knoten wurde ein Algorithmus entwickelt, der eine pyramidenförmige Ausrichtung realisiert. Dabei werden die Knoten in Reihen untereinander angeordnet, wobei jede Reihe zwei Elemente mehr als die vorherige enthält. Die Ausrichtung innerhalb einer Reihe beginnt in der Mitte und breitet sich alternierend in beide Richtungen aus. Zusätzlich zu der automatischen Kantenerzeugung bietet der Drag and Drop-Mechanismus den direkten Austausch von PlaceNodes an, wenn ein UserNode auf einem Place- Node abgelegt wird. Diese Funktion bietet sich gerade für solche Situationen an, in denen der Lehrer die exakten Benutzerkennungen und Hostnamen während der Unterrichtsplanung nicht kannte. In diesem Fall kann er die PlaceNodes in relativ kurzer Zeit manuell ersetzen. SessionNode UserNode PlaceNode MaterialNode SessionNode - ForceEdge ForceEdge MaterialEdge UserNode ForceEdge - - MaterialEdge PlaceNode ForceEdge - - MaterialEdge MaterialNode MaterialEdge MaterialEdge MaterialEdge - Tabelle 4.2.: Automatische Verbindung von Knoten per Drag and Drop Neben den bisher beschriebenen Reitern verfügt die AdhocMm-Palette über zwei weitere Tabs. Unter Einstellungen ndet sich eine Kongurationsmaske für den MatchMaker- Server. Zu wählen ist hierbei zwischen der Option, einen eigenen Server zu starten oder einen bereits gestarteten Server zu verwenden. Diese Einstellungen werden bei der Aktivierung des Kollaborationsmodus interpretiert. Soll ein eigener MatchMaker-Server erzeugt werden, wird dieser in einem eigenen Thread gestartet. Darüber hinaus kann über den Einstellungsbereich der Speicherpfad für eingesammelte Arbeitsmappen festgelegt und das automatische Speichern der Arbeitsmappen (de-)aktiviert werden. Die Auto- Save Funktion ist standardmäÿig aktiviert und löst in dem eingestellten Intervall den Speichermechanismus für alle MaterialNodes aus. Diese Option bietet sich an, um Zwischenstände zu erstellen oder im Fall von technischen Problemen über ein Backup der Arbeitsmappen zu verfügen. Wie in Kapitel 3 bereits erläutert, kann über die Palette ein Import und Export von AdhocMm-Arbeitsmappen erfolgen. Die Arbeitsmappe mitsamt aller auszuteilenden Dokumente wird in einem Zip-Archiv verpackt und kann somit komfortabel auf einen anderen Rechner übertragen werden. Während des Import-Vorgangs wird die AdhocMm-Arbeitsmappe entpackt und geladen. Soll im Anschluss ein Dokument an die Schüler verteilt werden, wird zuerst innerhalb der Zip-Datei nach der passenden Datei gesucht. Abbildung 4.10a zeigt einen Screenshot des Einstellungen-Reiters. Der Statistik-Reiter kann benutzt werden, um sich einen Überblick über den aktuellen Lernfortschritt zu verschaen. Zu diesem Zweck wird dem Benutzer eine Statistik mit 61

68 4. Implementierung der Anzahl der Knoten und Kanten in den einzelnen Arbeitsmappen präsentiert. Hierbei wird für jede Sitzung ein einzelner Eintrag erzeugt, der permanent angezeigt wird. Unterhalb der Sitzungen werden dynamisch Einträge für die Schüler angezeigt, die sich in keiner Sitzung benden. Tritt ein Schüler einer Sitzung bei, wird der Eintrag des Schülers entfernt, da seine Knoten- und Kantenanzahl über die entsprechende Sitzung verfügbar ist. Für die Anzeige eines Eintrags wird ein gestapeltes Säulendiagramm verwendet, das eine schnelle Erfassung der Gesamtanzahl an Elementen ermöglicht, ohne den Zugri auf die Einzelwerte zu verlieren. Das AdhocMm-Plugin bezieht die Daten von den einzelnen AdhocStudent-Instanzen. Jedes Mal wenn ein Schüler ein Element in der Arbeitsmappe erzeugt oder entfernt, wird eine Nachricht per Unicast an den AdhocMm-Rechner versendet, der daraufhin die Statistik aktualisiert. Für die Darstellung der Statistik kommt die Diagramm-Bibliothek JCharts 1 zur Anwendung. Ein Beispiel solch einer Statistik ist in Abbildung 4.10b zu sehen. (a) Einstellungen (b) Statistik Abbildung 4.10.: Kongurationsmöglichkeiten und Statistik innerhalb der AdhocMm- Palette Knoten und kontextabhängige Optionen Der Einsatz einer visuellen Sprache für das AdhocMm-Plugin wurde mit der besseren Erlernbarkeit und einer entsprechend kürzeren Einarbeitungszeit motiviert. Allerdings

69 4.2. AdhocMm benötigt ein solches Modell relativ viel Platz zur Darstellung der Elemente, sowie der jeweils verfügbaren Informationen und Operationen. Diesem Problem wurde im Rahmen dieser Arbeit durch die Entwicklung eines kontextabhängigen Icon-Panels Rechnung getragen. Hierbei handelt es sich um eine zusätzliche Leiste unterhalb des Knotens, die eingeblendet wird, sobald der Mauszeiger über den Knoten fährt und beim Verlassen wieder ausgeblendet wird. Abhängig vom jeweiligen Knoten werden verschiedene Icons angezeigt, die durch einen Mausklick aktiviert werden können. Diese Icon-Panels kommen bei SessionNodes, MaterialNodes und UserNodes zur Anwendung und sind in Abbildung 4.11 dargestellt. Bestehende Sitzung verwenden Sitzung beitreten Austeilen Arbeitsmappe auswählen Einsammeln Screenshot anfordern Abbildung 4.11.: Kontextabhängige Optionen der Knoten Über den links dargestellten SessionNode kann der entsprechenden Sitzung beigetreten werden, sofern diese bereits erstellt wurde. Durch einen Klick auf das Icon wird ein neuer FreeStyler geönet, der die Adresse und den Port des Servers, sowie den Sitzungsnamen per Parameter übergeben bekommt und automatisch der Sitzung beitritt. In diesem Zusammenhang wurde der FreeStyler um den Parameter -s <server> <port> <session> <user> erweitert. Die zweite Schaltäche kann verwendet werden, um eine bereits auf dem MatchMaker-Server existierende Sitzung zu verwenden. Das entsprechende Verfahren wurde in Abschnitt beschrieben. Der UserNode bietet dem Benutzer die Möglichkeit, einen Screenshot anzufertigen. Wie am Ende von Abschnitt bereits beschrieben wurde, wird daraufhin eine Nachricht an die entsprechende AdhocStudent-Instanz gesendet, die den Screenshot anfertigt und an den Lehrerrechner übermittelt. Der Screenshot wird in einem neuen Fenster angezeigt und kann daraufhin auf der lokalen Festplatte gespeichert werden. Um einen schnelleren Überblick über den Inhalt - speziell bei sehr hohen Bildschirmauösungen - zu ermöglichen, wird der Screenshot mit Hilfe der Java-Bibliothek imgscalr 2 skaliert. Die Skalierung kann per Mausklick auf das Bild oder über das Menü deaktiviert werden. Auf der rechten Seite der Abbildung ndet sich der MaterialNode mitsamt Icon-Panel wieder. Dem Benutzer bieten sich hierbei drei Optionen. Mit der ersten Schaltäche kann er die Arbeitsmappen der verbundenen Schüler und Sitzungen einsammeln. Durch die Aktivierung dieser Schaltäche versendet AdhocMm eine CollectWorkspace-Nachricht, woraufhin die AdhocStudent-Instanzen die aktuelle Arbeitsmappe an diesen Rechner senden. Um eine Arbeitsmappe zu verteilen, muss diese zuerst über die mittlere Schaltäche

70 4. Implementierung ausgewählt werden. Im Anschluss daran kann die Arbeitsmappe per Klick auf das dritte Icon ausgeteilt werden AdhocStudent Das AdhocStudent-Plugin stellt den Gegenpart zu AdhocMm dar und ist dafür zuständig, die vom Lehrerrechner empfangenen Kommandos umzusetzen. Nach dem Start stellt es eine Verbindung zum AdhocMm-Rechner her, um sich anzumelden und auf Management- Kommandos zu warten. Darüber hinaus verfügt das Plugin über eine Palette, die zur Darstellung von Informationen eingesetzt wird. Diese Palette bietet dem Schüler auÿerdem die Möglichkeit, zwischen verschiedenen Sitzungen zu wechseln, sofern dies durch das aktuelle Lernszenario unterstützt wird. Im Folgenden sollen die Programmstruktur und die bereitgestellten Funktionen vorgestellt werden. «interface» info.collide.freestyler.general.event.closelistener «interface» info.collide.graph.event.graphlistener SessionModel AdhocController ServerCredentials +getinstance() : AdhocController +joinsession(eing. session : SessionModel) : void +leavesession() : void 1 1 «uses» AdhocGroupClient 1 1 StatisticsCounter +getnodes() : int +getedges() : int «interface» info.collide.freestyler.general.event.documentlistener CouplingController +createsession(eing. sc : ServerCredentials, eing. sessionname : String) : void +joinsession(eing. sc : ServerCredentials, eing. sessionname : String) : void +leavesession() : void Abbildung 4.12.: Programmstruktur des AdhocStudent-Plugins als UML- Klassendiagramm Die zentrale Schnittstelle für diese Aufgaben wird durch die Klasse AdhocController gebildet. Wie das entsprechende Pendant auf Seiten des AdhocMm-Plugins auch, wurde die Controller-Klasse als Singleton realisiert. Neben dem komfortablen Zugri ergibt sich hierdurch ein weiterer Vorteil. Wird das Plugin gestartet und im späteren Verlauf aus der Palette entfernt, bleibt das entsprechende Objekt im Speicher bestehen und ist weiterhin aktiv. Auf diese Weise bleibt die Management-Funktionalität auch nach dem Entfernen erhalten. Ein erneutes Laden der Palette verwendet darüber hinaus denselben AdhocController. Dieses Verfahren wird zwar zum aktuellen Zeitpunkt nicht zwangsweise benötigt, da ein Plugin vom FreeStyler nicht vollständig entfernt wird, doch ist dieser 64

71 4.3. AdhocStudent Mechanismus hinsichtlich zukünftiger Änderungen robust. Für die Umsetzung der in Kapitel 3.3 beschriebenen Funktionen verwendet der AdhocController die drei nachfolgend erläuterten Komponenten. Für die Kommunikation kommt der in Abschnitt beschriebene AdhocGroupClient zum Einsatz. Mit Hilfe dieses Clients wird dem Management-Cluster nach dem Ladevorgang beigetreten und daraufhin eine AdhocMm-Instanz gesucht. Ist ein solcher Rechner vorhanden, wird auf entsprechende Management-Nachrichten gewartet. Der Empfang einer Nachricht erzeugt ein - vom Nachrichtentyp abhängiges - Event, welches daraufhin vom AdhocController verarbeitet wird. Zur Sitzungsverwaltung nutzt der AdhocController die Klasse CouplingController, die eine Fassade für die entsprechenden FreeStyler-Mechanismen darstellt. Dies beinhaltet Methoden zum Erzeugen, Betreten und Verlassen einzelner Sitzungen. Die dritte wichtige Klasse trägt den Namen StatisticsCounter und liefert die Anzahl der Knoten und Kanten, die für die AdhocMm-Statistik verwendet werden. Ein entsprechendes UML-Klassendiagramm steht in Abbildung 4.12 zur Verfügung. Nachfolgend sollen die wichtigsten Anwendungsfälle des AdhocStudent-Plugins beschrieben und die Palette vorgestellt werden Sitzungsverwaltung Der AdhocController ist für das Management der Sitzungen auf Seiten des AdhocStudent- Plugins zuständig und führt die notwendigen Aktionen aus, um Sitzungen beizutreten oder zu verlassen. Um überhaupt einer Sitzung beitreten zu können, muss zuerst eine SessionConfig-Nachricht empfangen werden. Sobald ein Host eine solche Sitzungskonguration empfängt, prüft der AdhocController, ob für den User-Identier Sitzungsdaten enthalten sind. In Abhängigkeit von dieser Sitzungskonguration entscheidet der Controller, ob er eine Sitzung entweder automatisch betritt oder die verfügbaren Sitzungen in der Palette zum manuellen Beitritt präsentiert. Die genaue Vorgehensweise kann als Pseudo-Code in Listing 1 nachvollzogen werden. Der aufgelistete Pseudo-Code nutzt die beiden recht allgemein gehaltenen Operationen join session und leave session. Diese Operationen entsprechen den AdhocController- Methoden joinsession bzw. leavesession. Neben dem Aufruf beim Empfang einer Sitzungskonguration werden diese Methoden ebenfalls verwendet, wenn der Benutzer eine Sitzung über die Palette betreten oder verlassen möchte. Um einer Sitzung beizutreten, muss der AdhocController mehrere Schritte ausführen. Wie in Abschnitt beschrieben, tritt das AdhocStudent-Plugin zuerst dem jeweiligen Sitzungs-Cluster bei und führt daraufhin den Service Discovery Prozess aus. Anschlieÿend übermittelt der AdhocMm-Rechner eine JoinSession-Nachricht mit einer Information, ob die Sitzung bereits existiert oder noch erstellt werden muss. In Abhängigkeit davon verwendet der AdhocController entweder die createsession oder joinsession Methode des CouplingControllers. Der CouplingController nutzt den FSCouplingManager des FreeStylers, um entweder eine neue Sitzung zu erstellen oder einer bestehenden beizutreten. Da neue Sitzungen innerhalb des FreeStylers bisher ausschlieÿlich interaktiv erzeugt wurden, musste der FSCouplingManager entsprechend erweitert werden. Für den Fall, dass eine neue Sitzung erzeugt werden soll, erstellt der CouplingController zuvor einen neuen Workspace. Somit wird sichergestellt, dass die resultierende Sitzung 65

72 4. Implementierung receive session cong if session cong has forced session then if is not in session then join session else if currentsession!= forcedsession then leave session join session end if end if else if is in session then if currentsession not in allowed sessions then leave session end if end if display allowed sessions end if Listing 1: Pseudocode zur Verarbeitung einer SessionCong-Nachricht eine einzelne leere Seite enthält. Anschlieÿend benachrichtigt das AdhocStudent-Plugin den Lehrerrechner mit Hilfe einer SessionJoined-Nachricht. Soll eine Sitzung hingegen verlassen werden, ruft der AdhocController die entsprechenden leavesession und leavesessiongroup Methoden der Klassen CouplingController bzw. AdhocGroupClient auf und verlässt somit die Sitzung und den Sitzungs-Cluster. Abschlieÿend soll die Vorgehensweise diskutiert werden, wenn eine neue Sitzung durch das AdhocStudent-Plugin erstellt wird. Während es sinnvoll erscheint, dass das AdhocMm- Plugin eine neue Arbeitsmappe für die Sitzung erzeugt, bevor die Schüler-FreeStyler der Sitzung beitreten, konnte dieses Vorgehen im Rahmen dieser Arbeit nicht umgesetzt werden. Hierzu wären tiefgreifende Veränderungen des FreeStylers nötig, da eine neue MatchMaker-Sitzung mit einer leeren Arbeitsmappe erzeugt werden müsste, während der FreeStyler zur gleichen Zeit eine AdhocMm-Arbeitsmappe geladen hält. Auf Implementierungsebene liegt das Problem darin begründet, dass der für die Ablage der Arbeitsmappenstruktur im Sychronization-Tree zuständige DocumentController eine eigene Referenz auf das FreeStyler-Objekt besitzt. Diese Referenz wird verwendet, um auf alle Seiten des FreeStylers zuzugreifen und diese zu synchronisieren. Da der FreeStyler während der Erzeugung einer neuen Sitzung auf dem Synchronisationsserver allerdings die Seiten mit der AdhocMm-Konguration geönet hat, würden diese ebenfalls in der Sitzung erstellt werden. Aus diesem Grund wurde die Entscheidung getroen, die Sitzung auf Seiten des AdhocStudent-Plugins anzulegen Arbeitsmappen verwalten Werden Arbeitsmappen an die AdhocStudent-Rechner ausgeteilt, so geschieht dies durch eine DistributeWorkspace-Nachricht. Der AdhocController ist dafür zuständig, die Nachricht entgegenzunehmen und das Dokument zu laden. Zu diesem Zweck wird die bereits 66

73 4.3. AdhocStudent existierende Funktion des FreeStylers verwendet, welche die Seiten eines Dokuments an die aktuelle Arbeitsmappe anhängt. Diese Operation wird sowohl für die Einzelarbeit, als auch während der Teilnahme an einer Sitzung verwendet. Wie in Abschnitt bereits erläutert wurde, ist in letzterem Fall eine einzelne AdhocStudent-Instanz für das Einfügen des Dokuments zuständig. Die eigentliche Verteilung an die restlichen Gruppenmitglieder erfolgt durch den Synchronisationsmechanismus. Die Speicherung der Arbeitsmappen wurde bereits in Abschnitt erläutert. Allerdings ist es möglich, dass einzelne Schüler ihren FreeStyler am Ende der Unterrichtsstunde schlieÿen, bevor der Lehrer die Arbeitsmappen einsammeln kann. Aus diesem Grund wurde der FreeStyler um einen Event-Mechanismus erweitert, der registrierte Komponenten bei Beendigung des Programms benachrichtigt. Der AdhocController registriert sich dementsprechend als CloseListener und versendet die Arbeitsmappe in diesem Fall an den Lehrerrechner Statistik Damit der Lehrerrechner die aktuelle Anzahl an Knoten und Kanten eines Schüler- FreeStylers anzeigen kann, werden entsprechende Änderungen der Arbeitsmappe vom AdhocController an den AdhocMm-Computer übermittelt. Sind mehrere Schüler Mitglied einer Sitzung, wird diese Aufgabe von einem einzelnen Teilnehmer übernommen, um das Netzwerk nicht unnötig zu belasten. Hierbei ist der AdhocStudent-Rechner für die Übertragung zuständig, der den alphabetisch niedrigsten User-Identier besitzt. Die aktuellen Werte werden in Kombination mit dem User- und Group-Identier in Form einer Statistics-Nachricht übertragen. Um die aktuelle Anzahl an Knoten und Kanten zu erhalten, verwendet der AdhocController die Klasse StatisticsCounter. Der Counter besitzt für diese Werte einzelne Zähl-Variablen, welche nach jedem Hinzufügen und Löschen eines Elements aktualisiert werden. Darüber hinaus führt diese Klasse eine komplette Zählung aller Elemente durch, sobald ein Dokument geladen oder hinzugefügt bzw. eine Seite gelöscht wird. Um über diese Ereignisse informiert zu werden, ist der StatisticsCounter als GraphListener und DocumentListener registriert Palette Die Palette des AdhocStudent-Plugins ist in drei Bereiche unterteilt, die dem Schüler verschiedene Informationen und Operationen zur Verfügung stellen. Im oberen Bereich nden sich Informationen zum aktuellen Status des Systems. Hierzu zählt die Anzeige des aktuellen User-Identiers und ein Statustext, der darüber Auskunft gibt, ob der Lehrerrechner gefunden oder eine Sitzung erfolgreich betreten wurde. Ist der Schüler Mitglied einer Sitzung, wird auÿerdem die vom Lehrer eingegebene Sitzungsbeschreibung und die Anzahl der Teilnehmer angezeigt. Falls es sich bei der aktuellen Sitzung um eine erlaubte Sitzung handelt, kann diese über einen entsprechenden Button wieder verlassen werden. Im mittleren Bereich ndet sich eine Liste mit den aktuell verfügbaren Sitzungen. Ist der Zugang zu mehreren Sitzungen gestattet, kann eine Sitzung ausgewählt und dieser durch Betätigung eines Buttons beigetreten werden. Der untere Bereich wird erst angezeigt, sobald der AdhocStudent-FreeStyler an einer 67

74 4. Implementierung Sitzung teilnimmt. Hier wird die in Abschnitt beschriebene Liste aller Sitzungsmitglieder angezeigt und somit die soziale Awareness für den Schüler hergestellt. Die Information, welche Mitglieder sich aktuell in der Sitzung benden, wird über den Sitzungs- Cluster bezogen. Dieses Vorgehen wurde gewählt, damit der Lehrer einer Sitzung beitreten kann, ohne in der Liste aufgeführt zu werden. Abbildung 4.13 liefert einen Screenshot des FreeStylers mit geöneter AdhocStudent-Palette. Im Bild ist zu erkennen, dass der Schüler mit dem User-Identier Fritz Mitglied einer Sitzung ist. Diese Sitzung wurde vom Lehrer als Session1 bezeichnet und enthält insgesamt vier Mitglieder. Der Schüler hat darüber hinaus die Erlaubnis, der Sitzung Session2 beizutreten. Abbildung 4.13.: Screenshot des FreeStylers mit AdhocStudent-Plugin und geladenem Aktivitätsdiagramm 4.4. Voraussetzungen und Empfehlungen für den Einsatz Um das in dieser Arbeit entwickelte System in der Praxis einzusetzen, müssen verschiedene Bedingungen erfüllt sein. Der Einsatz eines Reliable Multicast Systems als Middleware stellt bereits die erste dieser Bedingungen. Damit die Rechner miteinander kommunizieren können, muss die Netzwerk-Infrastruktur IP-Multicasting unterstützen. Hierbei werden Multicast-Nachrichten von Netzwerk-Switches ohne Weiteres an die angeschlossenen Computer übermittelt. In Umgebungen, in denen eine Aufteilung in verschiedene Subnetze vorliegt, müssen die Router die Weiterleitung von Multicast-Paketen unterstützen. Für den Einsatz in mehreren Klassenräumen zur gleichen Zeit, muss die Nutzung verschiedener Multicast-Adressen vorausgesetzt werden. Findet keine solche Trennung statt, zeigt das AdhocMm-Plugin nicht nur die Schüler des jeweiligen Klassenraums an. Die 68

75 4.4. Voraussetzungen und Empfehlungen für den Einsatz Multicast-Adresse kann über die FreeStyler-Kongurationsdatei mit Hilfe des Parameters adhoc.multicast.addr geändert werden. Standardmäÿig wird die Adresse verwendet. Darüber hinaus darf eine eventuell vorhandene Firewall eingehende Multicast-Pakete nicht verwerfen. Hierbei muss die Firewall den Empfang von UDP-Paketen auf Port akzeptieren. Sollte der Port bereits vergeben sein, kann dieser über die Kongurationsdatei des FreeStylers mit dem Parameter adhoc.multicast.port geändert werden. Ein weiterer Punkt betrit den Java Netzwerk-Stack. Die Java-Runtime nutzt standardmäÿig den IPv6-Stack, mit dem JGroups allerdings zum aktuellen Zeitpunkt nicht kompatibel ist. Dementsprechend muss der Einsatz der IPv4-Implementierung forciert werden. Während dies unter Windows und Mac OS X Systemen auch zur Laufzeit erfolgen kann, muss dem FreeStyler auf Linux-Systemen der Parameter -Djava.net.preferIPv4Stack =true beim Start übergeben werden. Das Startskript FreeStyler.sh wurde im Rahmen dieser Arbeit entsprechend angepasst. Um das System in der Praxis einzusetzen, empehlt sich der Einsatz einer angepassten FSHistory.xml mit allen benötigten Plugins. Dies ist nötig, da der FreeStyler über keinen Mechanismus verfügt, um das Plugin eines unbekannten Elements in einer Sitzung zu erkennen und automatisch zu laden. Wird die FSHistory-Datei nicht angepasst, können solche Knoten und Kanten einer Sitzung nicht dargestellt werden. Beim letzten Punkt handelt es sich nicht um eine Bedingung, sondern eher um eine Empfehlung für den Einsatz. Sollen kollaborative Sitzungen über das AdhocMm-Plugin verwaltet werden, kann ein MatchMaker-Server entweder automatisch durch das Plugin oder manuell als separate Anwendung gestartet werden. Im ersten Fall wird der MatchMaker lediglich in einem neuen Thread gestartet, weshalb die Verfügbarkeit des Synchronisationsservers an die Laufzeit des FreeStylers gebunden ist. Muss der FreeStyler neu gestartet werden, gehen infolgedessen die Sitzungen verloren. Aus diesem Grund ist der manuelle Start des MatchMaker-Servers in aller Regel vorzuziehen. Zwar wurde entsprechender Programmcode implementiert, um den Server aus AdhocMm als eigenen Prozess zu starten, doch musste dieser auskommentiert werden. Ein auf diese Weise gestarteter MatchMaker-Server lief nach dem Start instabil. 69

76

77 5. Erprobung des Systems Neben der Konzeption und Implementierung wurde das System im Rahmen dieser Arbeit auf Funktionstüchtigkeit geprüft. Um einen Bezug zu dem in Kapitel 3.1 vorgestellten Szenario herzustellen, wurde eine ktive Unterrichtssituation konstruiert, die verschiedene Aspekte des Szenarios aufgreift. Für die Erprobung des Systems nahm ein wissenschaftlicher Mitarbeiter der Collide-Gruppe die Rolle des Lehrers ein. Die Rollen der Schüler wurden von fünf studentischen Hilfskräften ausgefüllt. Das Testszenario berücksichtigt die Rollen des Lehrers und der Schüler durch verschiedene Aufgabenstellungen und soll im folgenden Abschnitt vorgestellt werden. Im Anschluss daran erfolgt eine Bewertung dieser technischen Erprobung (5.2) Testszenario und Durchführung Die Aufgabenstellung des Lehrers bestand aus mehreren Teilen. Zuerst sollte der Match- Maker-Server und der FreeStyler mit AdhocMm-Plugin gestartet werden. Daraufhin musste das AdhocMm-Plugin so konguriert werden, dass der gestartete MatchMaker- Server verwendet wird. Sobald diese vorbereitenden Maÿnahmen abgeschlossen waren, stellte sich dem Lehrer die Aufgabe, ein einfaches Lernszenario mit Hilfe der AdhocMm- Elemente zu modellieren. Diese Aufgabe umfasste zwei Teile, um sowohl das Management kollaborativer Sitzungen, als auch die Verwaltungsfunktionen für Einzelarbeiten zu erproben. Zum einen galt es eine Sitzung, bestehend aus zwei Schülern, einzurichten. Zum anderen sollten drei weitere Schüler den FreeStyler in Einzelarbeit verwenden. Allen Parteien sollte darüber hinaus eine präparierte FreeStyler-Arbeitsmappe ausgeteilt werden. Abbildung 5.1 zeigt einen Screenshot, in dem dieser Aufbau nachgestellt wurde. Nachdem das Lernszenario im FreeStyler modelliert wurde, sollte der Lehrer entsprechende Aufgaben ausführen, um den Unterricht zu starten. Hierzu gehörte der Start der Sitzung durch die Aktivierung des Kollaborationsmodus. Darüber hinaus sollte der Lehrer die Arbeitsmappe austeilen, welche von den Schülern zu bearbeiten war. Das Resultat dieser Aufgabe wurde in Abbildung 5.2 nachgestellt. Anhand der durchgezogenen Linien ist zu erkennen, dass die beiden Schüler der Sitzung beigetreten sind und das Dokument an die Sitzung und die einzelnen Schüler ausgeteilt wurde. Sobald die Arbeitsmappen ausgeteilt wurden, bekamen die Schüler eine eigene Aufgabenstellung, die mit dem FreeStyler bearbeitet werden sollte. Ziel der Aufgabe war es, die betrieblichen Abläufe einer Smartphone-Reklamation als Aktivitätsdiagramm zu modellieren. Dabei setzte sich die Aufgabenstellung aus zwei Teilen zusammen, die verschiedene Bereiche des Diagramms beschrieben. Diese Aufteilung wurde verwendet, um den Teilnehmern der kollaborativen Sitzung einen Ansatzpunkt für die Arbeitsteilung zu bieten. In der ausgeteilten Arbeitsmappe waren bereits einige Aktivitäten erzeugt worden, darunter ein Knoten, der den Schnittpunkt der beiden Teilaufgaben darstellte. Abbildung 71

78 5. Erprobung des Systems Abbildung 5.1.: Aufbau des Lernszenarios (AdhocMm) Abbildung 5.2.: AdhocMm im Kollaborationsmodus mit ausgeteilten Arbeitsmappen 72

79 5.1. Testszenario und Durchführung 5.3 zeigt einen FreeStyler mit AdhocStudent-Plugin und der ausgeteilten Arbeitsmappe. In der Palette ist zu erkennen, dass dieser Schüler Mitglied der Sitzung ist und ein weiterer Schüler an der Sitzung teilnimmt. Abbildung 5.3.: FreeStyler mit AdhocStudent-Plugin und gekoppeltem Arbeitsbereich Während sich die Schüler an die Modellierung der Aktivitätsdiagramme begaben, lieferte die Aufgabenstellung des Lehrers eine Liste mit Aktivitäten, die er während des Unterrichts ausführen sollte. Zuerst sollte er die Monitoring-Funktionen verwenden, um sich einen Überblick über den Lernfortschritt und die Aktivitäten der Schüler zu verschaffen. Neben der Nutzung der Statistik-Funktion wurden hierzu Screenshots der Schüler- Desktops angefertigt. Darüber hinaus sollte der Lehrer der Sitzung beitreten und Annotationen in der Arbeitsmappe einfügen. Abbildung 5.4 zeigt einen Screenshot, der während der Erprobung des Systems erstellt wurde. In diesem Bild ist zu erkennen, dass der Schüler für die Bearbeitung der Aufgabe den Wikipedia-Artikel zum Thema Aktivitätsdiagramme zu Hilfe genommen hat. Nachdem der Lehrer sich einen Überblick über den Lernfortschritt verschat hatte, sollten die Arbeitsmappen aller Schüler auf dem Lehrerrechner gesichert werden, um im Anschluss die Sitzungskonguration zu verändern. Diese neue Konguration sollte es allen Schülern ermöglichen, der vorhandenen Sitzung beizutreten und das erstellte Aktivitätsdiagramm zu begutachten. Diese neue Sitzungskonguration wurde in Abbildung 5.5 nachgestellt, bei der bereits vier von fünf Schülern der Sitzung beigetreten sind. 73

80 5. Erprobung des Systems Abbildung 5.4.: Screenshot eines Schülerdesktops mit geönetem Wikipedia-Artikel Abbildung 5.5.: Sitzungskonguration, die allen Schülern den Zutritt in die Sitzung erlaubt 74